번들러를 "파일 합치기 도구" 정도로만 알고 있는지, 아니면 트랜스파일·스플리팅·트리 쉐이킹을 포함한 최적화 파이프라인으로 이해하고 있는지를 가른다.
번들러는 import로 얽힌 모듈 그래프를 따라가 의존성을 해석하고, 브라우저가 효율적으로 실행할 산출물(JS·CSS·에셋)로 다시 만든다. 단순히 파일을 합치는 게 아니라 트랜스파일링, 코드 스플리팅, 트리 쉐이킹, 해시 파일명, 소스맵까지 묶어 처리한다. ESM이 표준이 된 지금도 프로덕션에서는 요청 수·실행 비용·호환성 문제를 해결하기 위해 번들·청크 전략이 필요하다. 현대 프런트엔드는 "코드를 짜는 일"과 "코드를 전달하는 일"을 같은 무게로 다룬다.
번들 분석 도구로 사이즈를 줄여 본 경험이 있다면 트리 쉐이킹이 깨지는 import 패턴이나 청크 분리 결정을 구체적인 사례로 풀어낼 수 있다
lodash 같은 라이브러리에서 부분 import로 바꿔 번들이 줄어든 경험이 있다면 ESM·사이드 이펙트 이야기로 자연스럽게 이어갈 수 있다
webpack에서 rollup·Vite로 이전하며 차이를 직접 확인한 경험이 있다면 도구 선택 기준의 근거로 사용할 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.