번들러(Bundle)란 뭐고, 왜 필요할까? — 요즘 번들러/빌드 툴 비교 가이드

한 줄 결론부터

• 새 웹앱(React/Vue/Svelte) 시작 → Vite
• npm 라이브러리 제작 → Rollup
• 빌드 속도가 1순위 → esbuild
• Webpack 기반 대형 프로젝트 → Rspack

번들러 선택은 "성능"보다 우리 팀의 병목이 뭔지에 달려 있다.

---

번들러가 뭐고, 왜 필요해졌나?

번들러는 흩어진 파일들(모듈/의존성)을 분석해서, 브라우저가 먹기 좋은 형태로 하나(또는 몇 개)의 결과물로 묶어주는 도구다.

그리고 요즘 번들러는 단순히 "묶기"만 하는 게 아니라, 트랜스파일(TS → JS)·폴리필·코드 스플리팅·트리 쉐이킹·압축까지 빌드 파이프라인 전체를 맡는 경우가 많다.

질문을 이렇게 바꾸면 이해가 빨라진다:

"브라우저는 왜 내가 만든 프로젝트 구조 그대로 못 읽을까?"

1) 모듈/의존성이 너무 많다

현대 프론트엔드는 앱 코드, UI 라이브러리, 유틸, 폴리필... 파일이 기본 수백 개다. 이걸 그대로 로드하면 네트워크 비용이 커진다.

번들러는 이를 적절히 묶고(번들), 필요한 것만 나눠서 로드하게 도와준다.

[💡 잠깐! 이 용어는?] 코드 스플리팅(Code Splitting): 한 번에 다 받지 않고, 페이지/기능 단위로 나눠서 필요한 순간에만 받게 하는 방식.

2) 개발 경험(DX)이 훨씬 중요해졌다

개발 중에는 바꾼 파일이 바로 반영돼야 한다. 그래서 HMR 같은 기능이 중요해졌고, 그걸 잘 하기 위해선 모듈 그래프를 이해하는 도구가 필요하다.

[💡 잠깐! 이 용어는?] HMR(Hot Module Replacement): 서버 재시작 없이, 바뀐 모듈만 갈아끼워서 화면을 즉시 갱신하는 개발 기능.

3) 프로덕션 최적화는 '선택'이 아니라 '생존'

프로덕션에서는 로딩 0.3초가 사용자/매출/SEO에 영향을 준다.

번들러는 트리 쉐이킹(안 쓰는 코드 제거), minify(압축), splitChunks(초기 로드 감소) 같은 최적화로 "체감 속도"를 만든다.

[💡 잠깐! 이 용어는?] 트리 쉐이킹(Tree Shaking): import 했지만 실제로 안 쓰는 코드를 빌드 결과에서 빼는 최적화.

---

그래서 번들러는 실제로 뭘 하나?

비유하면 번들러는 이삿짐 센터 같다.

짐(모듈)을 확인하고 → 불필요한 건 버리고(트리 쉐이킹) → 박스별로 분류하고(코드 스플리팅) → 압축해서(minify) → 트럭에 싣는(결과물 생성) 과정이다.

구체적으로는 이 6단계를 거친다:

1. 엔트리 포인트에서 시작해
2. import/require를 따라가며 의존성 그래프를 만들고
3. 각 파일을 필요하면 변환(트랜스파일)
4. 중복 제거/최적화(트리 쉐이킹)
5. 결과를 chunk 단위로 쪼개고
6. 최종 산출물을 만든다.

그래서 "묶기"보다는 컴파일러에 가깝다고 보는 게 맞다.

---

요즘 번들러/빌드 툴 후보들

한 가지 함정이 있다.

요즘은 '번들러'와 '개발 서버'가 섞여서 이야기되는 경우가 많다. 예를 들어 Vite는 개발 서버(빠른 HMR) + 프로덕션 번들(내부적으로 Rollup)을 같이 제공한다.

그래서 선택도 "번들러만"이 아니라 "툴체인"으로 결정하는 경우가 많다.

---

비교표 (빠르게 결론 내기)

도구	한 줄 요약	강점	주의점
Vite	개발 서버+번들(Rollup)	DX 최고, HMR 빠름	대규모/특수 케이스는 설정 이해 필요
Rollup	라이브러리 번들 강자	ESM 중심, 트리쉐이킹 강함	앱 개발 서버는 별도 필요
esbuild	매우 빠른 번들러/트랜스파일러	속도, 심플함	고급 최적화/플러그인 생태계는 비교적 제한
Webpack	레거시+대기업 표준	생태계/레퍼런스 압도	설정/학습 비용 큼
Rspack	Webpack 호환 고속 대안	Webpack 설정 호환 + 속도	완전 동일 호환은 케이스별 검증 필요
Turbopack	Next.js 생태계 지향	Next와 통합 방향	아직은 '모든 케이스'에서 성숙도 확인 필요
Parcel	설정 적고 빠른 스타트	제로 설정 경험	특수 튜닝은 제한적일 수 있음

포인트: "최고의 번들러"가 아니라 우리 팀의 병목에 맞는 번들러를 고르는 게 핵심이다.

---

상황별 추천

1) 신규 웹앱(React/Vue/Svelte) 시작

대부분의 팀은 Vite가 가장 무난하다.

• 빠른 개발 서버
• 플러그인 생태계
• 프로덕션 번들 안정성

비유하면 Vite는 잘 차려진 밀키트 같다. 재료(플러그인)도 준비되어 있고, 조리법(설정)도 간단하다.

2) npm에 배포할 라이브러리 제작

Rollup 또는 Rollup 기반 툴이 여전히 강하다.

• ESM/CJS 번들 전략
• 트리 쉐이킹
• 번들 크기 컨트롤

3) "빌드가 너무 느리다"가 1순위

• 빠른 변환/번들이 목적이면 esbuild가 체감이 좋다.
• Webpack 프로젝트라면 Rspack을 실험해볼 가치가 있다.

4) Webpack 기반 대형 레거시

당장 갈아엎기보단:

• Webpack 최적화(캐시/스플릿)
• Rspack 단계적 전환

같이 리스크를 줄이는 접근이 현실적이다.

---

선택 체크리스트 (팀 회의용)

아래 질문에 "예"가 많으면 그쪽이 유리하다.

Vite가 맞는 경우

• 새 프로젝트다
• DX(개발 속도)가 중요하다
• React/Vue/Svelte를 사용한다

Rollup이 맞는 경우

• npm 라이브러리를 배포한다
• 번들 크기 컨트롤이 중요하다
• ESM 중심 빌드가 필요하다

esbuild/Rspack이 맞는 경우

• 빌드 시간이 병목이다
• 기존 Webpack 설정이 있다 (Rspack)
• 심플한 변환/번들만 필요하다 (esbuild)

Webpack을 유지하는 경우

• 대규모 레거시 프로젝트다
• 기존 설정이 안정적이다
• 마이그레이션 리스크를 감수하기 어렵다

---

마무리

번들러 선택은 결국 팀의 반복 작업을 얼마나 줄여주느냐에 달려 있다.

• DX(개발 속도) → Vite
• 라이브러리 품질/번들 컨트롤 → Rollup
• 체감 속도(빌드) → esbuild
• 레거시 표준 → Webpack
• Webpack의 고속 대안 → Rspack

그리고 제일 좋은 방법은, 작은 프로젝트 하나로 직접 써보는 거다. 비교표보다 체감이 빠르다.

---

참고:

• Vite: https://vitejs.dev/
• Rollup: https://rollupjs.org/
• esbuild: https://esbuild.github.io/
• Webpack: https://webpack.js.org/
• Rspack: https://rspack.dev/
• Turbopack: https://turbo.build/pack