어떤 문제가 생길까
모듈 순환 의존성: 정상처럼 보이는 한 사례만으로는 동작 범위를 이해하기 어렵습니다. 대표 입력에서는 문제없다가 경계값, 느린 응답, 배포 직후처럼 조건이 달라질 때 결과가 바뀔 수 있습니다.
ES module cycle은 live binding을 제공하지만 초기화 전 binding 접근과 side effect 순서 때문에 runtime 오류나 undefined가 생길 수 있습니다.
원인을 이해하는 기준
이벤트 루프, heap, prototype과 비동기 작업 큐를 가진 JavaScript 실행 환경에서 어느 경계가 결과를 결정하는지 먼저 봅니다. 두 module·package가 서로 import하는지, runtime 초기화 순서가 필요한지, 단순 type 의존인지 나눠 dependency graph에서 cycle을 확인합니다.
| 구분 | 짧은 예시 |
|---|---|
| 기대 결과 | 모듈 순환 의존성: 정상 조건에서 사용자가 받아야 할 결과 |
| 실제 결과 | 같은 입력에서 처음 달라진 값·상태·오류 |
| 판별 자료 | Performance profile, heap snapshot, allocation timeline, long task와 promise rejection을 재현 입력과 함께 수집한다 |
적용 예시와 확인
작업 수명주기와 소유권을 명시하고 입력·반복·동시성·출력 크기에 상한을 둔다. 공통 계약을 더 안쪽 module로 옮기거나 소유 방향을 하나로 정합니다. 지연 import나 forward reference는 경계를 바로 세울 수 없을 때만 제한적으로 사용합니다.
대표 사례 하나, 값이 달라지는 경계 하나, 예상 가능한 실패 하나를 같은 순서로 확인합니다. 정답뿐 아니라 실행 시간, 할당량, GC, 이벤트 루프 지연과 취소 후 남은 작업을 비교한다. 깨끗한 환경에서 build·test를 실행하고 두 module을 서로 다른 순서로 불러도 초기화 값과 dependency resolution이 같게 유지되는지 확인합니다.
공식 문서와 적용 범위
문서의 기본값과 동작은 version에 따라 달라질 수 있습니다. 현재 runtime·framework version, 실제 입력과 요청 흐름에서 다시 확인합니다.