번들러와 번들링

학습 목표

번들러는 작성 방식보다 배포 산출물의 동작으로 판단해야 합니다.
같은 소스라도 어떤 출력으로 묶었는지에 따라 실행 동작이 달라질 수 있다는 점이 핵심입니다.

번들링이란 무엇인가

번들링은 모듈 단위의 코드를 배포 가능한 산출물로 재조합하는 과정입니다.
목적은 단순히 파일 수를 줄이는 데 있지 않고, 요청 수·캐시 단위·실행 경계를 함께 조절해 체감 성능을 맞추는 데 있습니다.

왜 하는가

1. 과도한 모듈 분할이 만드는 요청 폭증을 줄입니다.
2. 캐시 갱신 단위를 의도적으로 정해 재배포 비용을 낮춥니다.
3. 개발 단계의 모듈 구분은 유지하면서도 배포 단계에서 성능 경계를 조정합니다.

번들러 핵심 동작

번들러는 번들링을 넘어 다음을 수행합니다.

• 진입점 기준 의존성 그래프 구성
• 실행 순서가 성립하는 형태로 모듈 배치
• 사용되지 않는 코드 제거(트리셰이킹)
• 코드 분할과 압축

브라우저 실행 단과 번들 산출 단

• 브라우저는 번들 결과물을 실행 대상 단위로 처리합니다.
• 즉, 코드 리뷰 대상은 소스뿐 아니라 출력 번들입니다.
• 소스와 번들 출력은 실행 타이밍이 다를 수 있습니다.
• side effect의 실제 실행 구간은 특히 번들 단계에서 바뀔 수 있습니다.

형식 변환과 호환

번들러는 브라우저가 읽어 실행할 수 있도록 모듈과 포맷을 정렬합니다.
CJS/ESM 경계가 혼재한 코드는 결과 번들에서 바인딩 노출 방식이 달라질 수 있어 출력 검증이 필요합니다.
대표적인 번들러들은 서로 출력 규칙이 다르므로, “동작 같은데도 왜 다를까”를 번들 결과 기준으로 확인해야 합니다.

정리하면 CJS는 module.exports에 담긴 객체를 중심으로 동작하고, ESM은 내보내기 바인딩을 중심으로 동작합니다.
둘 다 의도대로 쓰면 맞게 동작하지만, 결과 번들에서 이 경계가 섞이면 default/named 노출, 갱신 반영, 초기화 타이밍 판단이 달라질 수 있습니다.

브라우저 지원 범위 차이는 번들 파이프라인에서 처리됩니다.
예를 들어 구형 브라우저를 지원해야 하면 출력 정합성 조정(transpile)과 런타임 API 보강(polyfill)이 함께 적용됩니다.
즉, 브라우저 호환성은 “번들 출력 설정 + 타깃 브라우저 정책”의 결과로 관리됩니다.

실무 점검 포인트

번들러는 출력물이 곧 실행 단위이므로, 변경 전 마지막 점검은 소스가 아니라 번들을 기준으로 합니다.

• 브라우저 타깃에 맞는 출력 정합성 상태인지(transpile, polyfill) 먼저 확인합니다.
• side effect가 있는 모듈이 의도한 타이밍에 실행되는지 번들 산출물 기준으로 점검합니다.