번들러가 무엇인가요? 왜 필요한가요? with WebPack, Rollup, Vite, Turbopack
2026. 1. 22. 15:15ㆍProgramming/JavaScript
프론트엔드를 개발하다보면, 웹팩, 번들링 이런 단어들을 자주 접하게 됩니다.
다만 개발 구현에만 허덕이던 초초초짜 주니어 시절에는 나중얘기로 미뤄두기만 했었죠
번들링에 대해 알면 알수록 클라이언트 시스템에 대한 전반적인 아키텍쳐도 이해할 수 있고,
성능과는 어떤 연관성이 있는지 어떤 필요성이 있는지 알게되어 포스팅으로 남겨보려합니다.
번들러란?
모듈 시스템 등장 배경
초기의 웹 개발은 HTML, CSS, JavaScript 파일을 각각 작성한 뒤
HTML에서 <script> 태그를 통해 JavaScript 파일을 직접 불러오는 방식이었습니다.
이 과정에서 파일 간 의존성 순서(삽입 순서)부터 전역 스코프 오염까지
모든 것을 개발자가 직접 관리해야 하면서 프로젝트 규모가 커질수록 유지보수는 점점 어려워졌습니다.
이러한 문제를 해결하기 위해 모듈 단위 개발 방식이 생겨났습니다.
- CommonJS : 동기 방식으로 require를 사용해 모듈을 불러오고 module.exports를 통해 모듈 API를 정의하는 방식
// add.js
module.exports.add = (x, y) => x + y;
// main.js
const { add } = require('./add');
add(1, 2);
- ECMAScript Modules (ESM) : 비동기 방식으로 export와 import 문법을 통해 모듈을 명시적으로 내보내고 가져오는 방식 (ES6환경)
// add.js
export function add(x, y) {
return x + y
}
// main.js
import { add } from './add.js';
add(1, 2);
번들러 등장 배경
하지만 이러한 모듈 구조를 그대로 브라우저에 배포할 수는 없습니다.
과거 브라우저 환경에서는 ESM과 같은 모듈 문법을 지원하지 않아
모듈 단위로 나누어 개발한 코드를
브라우저에서 실행 가능한 형태로 다시 묶는 과정이 필요했습니다.
이러한 개발 환경과 브라우저 실행 환경 사이의 간극을 해결하기 위해
등장한 개념이 바로 번들링(Bundling) 입니다.
번들링 과정 및 역할
번들링은 단순히 파일을 합치는 작업이 아니라,
모듈 간의 관계를 분석하고 이를 기반으로 코드를 재구성하는 일련의 과정입니다.
의존성 분석 → 그래프 생성 → 병합 → 최적화 → 결과물 생성
1. 먼저 번들러는 엔트리 포인트(entry point) 부터 시작하여
import 구문을 따라가며 애플리케이션이 의존하고 있는 모든 모듈을 분석합니다.
2. 이후 분석된 의존성 정보를 바탕으로
각 모듈이 어떻게 연결되어 있는지를 나타내는
의존성 그래프(dependency graph) 를 생성합니다.
이 그래프에는 어떤 모듈이 어떤 모듈을 참조하고 있는지가 구조적으로 정리됩니다.
3. 의존성 그래프가 만들어지면,
번들러는 이를 기반으로 모듈을 정렬하고
최소한의 파일 개수로 병합하는 번들링 단계를 수행합니다.
이 과정에서 각 모듈의 코드는 서로 간섭하지 않도록 함수 스코프로 감싸져 하나의 실행 단위로 구성됩니다.
4. 그 다음, 생성된 의존성 그래프를 활용해
실제로 사용되지 않는 코드를 제거하는 Tree Shaking과 같은 최적화 작업이 이루어집니다.
5. 마지막으로 번들러는 번들링된 JavaScript 파일과 함께
디버깅을 위한 소스맵(source map) 을 포함한 최종 결과물을 생성합니다.
이러한 과정과 더불어 번들러는 아래의 추가 역할을 수행하기도 합니다.
- 모듈 코드 번들링
- 코드 압축 및 난독화
- 트랜스파일러 및 polyfill 을 연계해 구현 브라우저에서 최신 JS 지원
- code splitting : chunk 형태로 번들파일 구성 → 당장 필요한 코드만 활용
- Tree Shaking
- HMR (Hot Module Replacement) : 새로고침 없이 자동 코드 변경 감지 → 최신 모듈 코드 자동 반영
그렇다면 이제 대표적인 번들러들을 살펴보겠습니다-
webpack 이란?
2012년부터 사용되기 시작한 JavaScript 번들러로,
플러그인 기반 구조와 함께 높은 확장성과 유연성을 바탕으로
대규모·엔터프라이즈급 웹 프로젝트에서 오랫동안 표준처럼 사용되는 번들러입니다.
Webpack의 특징
- 가장 방대한 생태계와 커뮤니티
- Code Splitting (lazy loading) 지원
- Loader와 Plugin 기반 아키텍처
- Loader를 통해 파일을 변환하고,Plugin을 통해 빌드 전반을 세밀하게 제어
- Loader는 HTML, CSS, Images, 폰트 같은 자원을 변환할 수 있도록 도와주는 속성
- Plugin은 webpack의 동작에 추가 기능을 제공하는 속성
- Loader는 파일을 해석하는 것에 관여하고 Plugin은 결과물(output)의 형태를 바꿔준다.
- Tree Shaking 지원
- Hot Module Replacement(HMR)
Webpack의 단점
Webpack의 가장 큰 장점은 높은 유연성과 구성 가능성이지만,
이는 동시에 단점이 되기도 합니다.
- 설정이 복잡하고 진입 장벽이 높음
- 개발 모드에서도 전체 의존성 그래프를 기반으로 빌드하기 때문에
대규모 프로젝트에서는 초기 빌드 및 재빌드 시간이 오래 걸릴 수 있음 - cache-loader, thread-loader 등 최적화 옵션을 적용하더라도
구조적인 한계로 인해 체감 속도 개선에는 한계가 존재
webpack.config.js 예시
module.exports = {
entry: './src/index.js', // Entry point
output: {
filename: 'bundle.js', // Output bundle
path: path.resolve(__dirname, 'dist'),
},
module: {
rules: [
{ test: /\.css$/, use: ['style-loader', 'css-loader'] },
{ test: /\.js$/, exclude: /node_modules/, use: 'babel-loader' },
],
},
mode: 'development',
};
Rollup이란?
ES 모듈(ESM)을 중심으로 설계된 JavaScript 번들러로,
하나의 소스 코드를 다양한 실행 환경에 맞는 번들로 생성하는 데 강점을 가진 도구입니다.
특히 라이브러리 빌드에 최적화되어 있고
출력 품질과 번들 크기 측면에서 높은 평가를 받아왔습니다.
Rollup의 특징
- ES 모듈(ESM) 중심 설계
- 다양한 출력 포맷 지원
- ESM은 정적 구조를 가지기 때문에, 빌드 시점에 의존성 분석이 명확하게 가능합니다.
- ESM의 정적 특성을 활용하여 더 정밀한 tree shaking을 수행합니다.
- 사용되지 않는 코드를 단순히 문자열 수준에서 제거하는 것이 아니라
의존성 그래프와 AST 분석을 통해 번들에 포함할 모듈 자체를 결정합니다.
- 깔끔한 번들 구조 (Flat Output)
- Webpack은 각 모듈을 함수로 감싸 런타임에 로딩하는 구조를 가지는 반면,
- Rollup은 가능한 한 평탄한(flat) 구조의 번들을 생성합니다.
- 소규모 번들을 위한 최적화된 output
- 생성된 번들의 크기를 줄이기 위해 축소, 압축, 코드 분할 등 다양한 최적화 기술 사용
- 이로 인해 특히 대역폭이 제한된 네트워크에서 로딩 시간이 빨라지고 end-user 성능이 향상된다.
- 하나의 코드베이스로부터 다양한 출력 포맷 지원
- Code splitting 지원 및 다양한 플러그인 생태계
rollup.config.js 예시
import commonjs from '@rollup/plugin-commonjs';
import resolve from '@rollup/plugin-node-resolve';
import { terser } from 'rollup-plugin-terser';
const production = !process.env.ROLLUP_WATCH;
export default {
input: 'src/main.js',
output: {
file: 'public/bundle.js',
format: 'iife',
sourcemap: true,
},
plugins: [
resolve(),
commonjs(),
production && terser(),
],
}
Vite 란?
Vite는 Vue.js의 창시자인 Evan You가 개발한 프론트엔드 빌드 도구입니다.
기존 번들러의 느린 개발 서버 경험을 개선하기 위해 만들어졌으며,
특히 개발 속도와 개발자 경험(DX) 에 초점을 맞추고 있습니다.
Vite는 흔히 “번들러”로 분류되지만,
정확히 말하면 개발 서버와 빌드 전략을 새롭게 설계한 도구에 가깝다고 합니다.
특히 개발 환경에서는 번들링 없이 Native ESM 기반으로
브라우저가 모듈을 직접 요청하기에 즉각적인 개발 서버 시작이 가능합니다.
프로덕션 빌드에서는 Rollup을 사용해 번들링하여 최적화된 정적 파일 생성합니다.
Vite의 특징
- Native ES Module 기반
- 번들링 없이 브라우저가 모듈을 직접 요청
- 실제로 import된 코드만 처리하여 즉각적인 개발 서버 시작
- 빠른 트랜스파일링
- Go 언어로 작성된 esbuild를 사용하여 의존성 사전 번들링 및 코드 변환을 고속으로 수행
- 효율적인 HMR
- 애플리케이션 전체를 다시 로드하지 않고 변경된 모듈만 즉시 교체
- CSS 빌드 최적화
- CSS도 모듈 단위로 처리
- 불필요한 재빌드 최소화
esbuild란?
esbuild는 Go 언어로 작성된 초고속 JavaScript 빌드 도구로,
Vite에서 다음과 같은 역할을 수행합니다.
- 의존성 사전 번들링 / 빠른 트랜스파일링 / 개발 중 반복 작업 최소화
다만 esbuild는 번들링 결과의 세밀한 제어에는 한계가 있기 때문에,
Vite는 개발 환경에서는 esbuild, 프로덕션 빌드에서는 Rollup을 사용하는 구조를 채택하고 있습니다.
vite.config.js
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
export default defineConfig({
plugins: [react()],
server: {
port: 3000,
},
});
Turbopack이란?
Turbopack은 Webpack의 핵심 개발자인 Tobias Koppers(Vercel) 가 설계한
차세대 JavaScript 번들러입니다.
Next.js를 중심으로 한 대규모 애플리케이션의 개발 성능 문제를 해결하기 위해 만들어졌습니다.
Turbopack은
단순한 속도 개선이 아니라 번들링 방식 자체를 재설계한 도구라고 합니다.
또한 Vercel이 말하기를.. Turbopack은 다음과 같은 성능을 목표한다고 하죠
- 콜드 스타트 기준 Webpack 대비 최대 700배 빠른 개발 서버 시작
- 대규모 프로젝트에서 Vite 대비 최대 10배 빠른 핫 업데이트
Turbopack의 특징
- Unified Graph (통합 그래프)
- client와 server처럼 여러 출력 환경을 지원하는 Next.js에서
클라이언트와 서버 모듈을 하나의 그래프(Unified Graph)에서 통합 관리합니다. - webpack의 경우 최소 두개의 별도 컴파일러를 실행해야합니다.
즉 클라이언트, 서버에서 두 번 파싱 되는 등 여러 추가적인 오버헤드가 발생합니다. - turbopack은 컴파일러가 서버, 클라이언트를 직접 인식하도록 하는 것
특정 import를 서버 ↔︎ 클라이언트의 전환으로 표시해 둘 수 있어
turbopack은 서버/클라이언트 컴포넌트/서버 함수까지 효율적으로 번들링 할 수 있습니다.
- client와 server처럼 여러 출력 환경을 지원하는 Next.js에서
- Bundling vs Native ESM
- Native ESM은 번들링없이 브라우저에 의존하므로 큰 규모의 앱에서는 과도한 네트워크 요청으로 느려질 수 있습니다.
- turbopack은 개발 환경에서도 번들링을 수행하며, 큰 규모에서도 빠르게 번들링의 최적화합니다.
- Incremental Computation (증분 계산)
- Turbopack은 작업을 여러 코어(cpu)에 걸쳐 병렬화하고, 결과를 함수 수준까지 캐싱합니다.
- 파일 변경 시 전체 의존성 그래프 재계산이 아닌, 변경된 연산 노드만 재계산합니다.
- Lazy bundling
- 개발 서버에서 실제로 요청된 것만 번들링
- Rust 기반 아키텍처
- 높은 병렬 처리 성능 / 낮은 메모리 오버헤드 / 안정적인 캐싱 구조
- Next.js와의 강한 친화성
- Webpack / Vite처럼 독립적인 번들러라기보다는
- Next.js(App Router, RSC, Streaming) 와 같은 프레임워크 런타임의 일부에 가까운 역할을 합니다.
Turbopack의 단점과 한계
- 아직 생태계가 제한적
- Webpack 수준의 플러그인 호환성은 미흡
- 사실상 Next.js 전용 번들러에 가까운 포지션
따라서 현재 시점에서는
Webpack이나 Vite를 완전히 대체한다기보다는,
Next.js 중심 개발 환경에서의 차세대 선택지로 보는 것이 적절합니다.
Webpack / Rollup / Vite / Turbopack 간단 비교
| 구분 | Webpack | Rollup | Vite | Turbopack |
| 핵심 포지션 | 범용 애플리케이션 번들러 | 라이브러리 번들러 | 개발 서버 중심 빌드 도구 | Next.js 전용 차세대 번들러 |
| 주요 목적 | 복잡한 앱 번들링 | 작고 깔끔한 번들 생성 | 빠른 개발 경험(DX) | 대규모 앱의 초고속 개발 |
| 개발 서버 | 번들 기반 | 번들 기반 | Native ESM (번들 없음) | Incremental 계산 |
| 초기 실행 속도 | 느림 | 보통 | 매우 빠름 | 매우 빠름 |
| HMR | 지원 (무거움) | 제한적 | 매우 빠름 | 매우 빠름 |
| Tree Shaking | 지원 | 매우 강력 | Rollup 기반 | 구조적으로 최적화 |
| 프로덕션 빌드 | Webpack 자체 | Rollup 자체 | Rollup 사용 | Turbopack |
| 설정 복잡도 | 높음 | 중간 | 낮음 | 매우 낮음 |
| 생태계 성숙도 | 매우 높음 | 높음 | 높음 | 아직 제한적 |
| 대표 사용 사례 | 대규모 웹 앱 | 라이브러리 배포 | SPA / 모던 프론트엔드 | Next.js(App Router) |
이렇게 번들러의 개념부터 대표적인 번들러들을 살펴봤습니다-
우리가 개발에 사용하는 export import 구문이 어떻게 생겨났고,
브라우저 입장에서 코드들이 어떻게 불러와지는지 살펴볼 수 있었습니다.
또한, 이런 번들링이 성능과 개발 생산성과는 어떤 연관이 있는지도 배울 수 있었네요!
읽어주셔서 감사합니다-
참고자료
Bundler (Webpack, Rollup, Vite, Parcel) 를 비교해보자
Bundler 번들러가 뭔데? 웹 어플리케이션을 개발하기 위해 필요한 HTML, CSS, JS 등의 모듈화된 자원들을 모아서, 하나의 파일로 결합(번들링)하는 도구. 왜 필요해? 기존 전통적인 자바스크립트 개발
velog.io
https://toss.tech/article/frontend-esbuild-hmr
ESBuild를 위한 HMR, 직접 만들기
프론트엔드 개발 경험을 향상시키는 HMR(Hot Module Replacement)의 원리와 다양한 번들러가 HMR을 어떻게 지원하는지 살펴보고, ESBuild 기반 번들러를 직접 개발한 과정을 소개드려요.
toss.tech
https://talent500.com/blog/vite-vs-turbopack-vs-webpack-fastest-bundler/
Vite vs Turbopack vs Webpack: Fastest JavaScript Bundler Comparison
Compare Vite, Turbopack, and Webpack to find the fastest JavaScript bundler. See benchmarks, use cases, and code examples to pick the best tool for your web project.
talent500.com
https://toss.tech/article/commonjs-esm-exports-field
CommonJS와 ESM에 모두 대응하는 라이브러리 개발하기: exports field
Node.js에는 두 가지 Module System이 존재합니다. 토스 프론트엔드 챕터에서 운영하는 100개가 넘는 라이브러리들은 그것에 어떻게 대응하고 있을까요?
toss.tech
https://yoonocean.tistory.com/71
모듈 번들러를 사용하는 이유
React 같은 최신 라이브러리나 프레임워크를 사용하면, 기본적으로 Webpack 이나 Vite 같은 모듈 번들러를 기본적으로 사용하게 됩니다. 그럴만한게, 보통 처음에 CRA 나 create vite 같은 명령어를 통해
yoonocean.tistory.com
https://dachaes-devlogs.tistory.com/56
[모듈 번들러] 프론트엔드 필수 도구의 개념과 대표 번들러 비교
모듈 번들러(Module Bundler) 현대 웹 개발에서는 수많은 자바스크립트 파일과 다양한 자산(CSS, 이미지, 폰트 등)을 효율적으로 관리하고 최적화할 필요가 있습니다. 이런 복잡도를 해결하고, 효율적
dachaes-devlogs.tistory.com
https://hooeverything.tistory.com/entry/Web-turbopack
[Web][Next.js] turbopack
이번 포스트에서는 Next.js 에서 사용하는 turbopack 이 무엇인지, 어떤 특징을 갖고 있고 왜 빠르게 동작하는지 알아본다.공식문서 app router 15.5.4 버전을 기준으로 작성하였다. 미리 알아두면 좋은
hooeverything.tistory.com
'Programming > JavaScript' 카테고리의 다른 글
| [JavaScript]자바스크립트_스코프 클로저 (0) | 2021.08.09 |
|---|---|
| [JavaScript]자바스크립트 호이스팅 (0) | 2021.08.03 |
| [JavaScript]자바스크립트 블록 스코프 (0) | 2021.08.02 |
| [JavaScript]자바스크립트 함수 스코프 (0) | 2021.07.31 |
| [JavaScript]자바스크립트, 렉시컬 스코프 (0) | 2021.07.28 |