Turbopack vs Webpack vs Vite의 선택 문제가 2026년에 정말로 흥미로워졌습니다. Turbopack은 이제 프로덕션 준비가 완료되었으며 Next.js 16의 기본 번들러입니다. Vite는 내부를 Rolldown으로 전환하고 있는데, Rolldown은 Rust 기반 엔진으로 GitLab의 빌드를 7배 더 빠르게 만들었습니다. 그리고 Webpack은 어떨까요? JavaScript의 현황 2025 설문에 따르면 개발자의 86%는 여전히 Webpack을 사용하지만 실제로 좋아하는 개발자는 14%뿐입니다. 꽤 큰 격차네요.
이것은 단순히 "Vite는 빠르고 Webpack은 느리다"라는 표면적인 글이 아닙니다. 출처와 함께 실제 벤치마크 수치, 나란히 비교한 설정 파일, 다른 곳에서는 다루지 않는 번들 크기 회귀 데이터, 실제로 사용할 수 있는 의사결정 프레임워크를 얻게 됩니다. Webpack에 머물러 있는 팀을 위해 Rspack도 네 번째 선택지로 다루겠습니다. JavaScript 패키지 매니저 비교를 따라오셨다면 우리가 미묘한 차이를 회피하지 않는다는 것을 알 것입니다. 그리고 현재 번들러 생태계에는 이러한 미묘한 이해가 많이 필요합니다.
한눈에 보는 빠른 요약, Turbopack vs Webpack vs Vite
요약하자면 이렇습니다. Next.js로 구축하고 가능한 한 빠른 HMR을 원한다면 Turbopack을 선택하세요. 모든 프레임워크에서 가장 유연하고 만족스러운 개발 경험을 원한다면 Vite를 선택하세요. 포기할 수 없는 커스텀 플러그인이 있는 복잡한 엔터프라이즈 코드베이스가 있다면 Webpack을 유지하거나 (또는 Rspack으로 전환해도 됩니다) 됩니다.
해당 표는 핵심을 담고 있지만, 세부사항이 중요합니다. 특히 Turbopack의 번들 크기 트레이드오프와 Vite에서 일어나고 있는 Rolldown 혁명이 그렇습니다. 자세히 살펴봅시다.
Turbopack이란 무엇인가?
Turbopack은 JavaScript와 TypeScript의 증분 번들러로, Rust로 작성되었으며 Vercel이 Next.js에 내장했습니다. Next.js 도구체인 내에서 Webpack의 후속 도구입니다. Next.js 16부터 next dev와 next build 모두의 기본 번들러이므로 새 프로젝트는 설정 없이 사용할 수 있습니다.
공식 Next.js 문서에 따르면 Turbopack은 Next.js 15에서 개발 안정화되었고, 15.3~15.5에서 프로덕션 빌드 지원을 추가했으며, 16.0에서 기본값으로 변경했습니다(현재 안정화 라인: 16.2). Vercel은 Webpack과 비교하여 최대 10배 더 빠른 Fast Refresh와 2~5배 더 빠른 프로덕션 빌드를 보고합니다.
주요 사항:
- Vercel이 개발했으며 Rust로 작성되었고 컴파일을 위해 SWC를 사용합니다.
- Next.js 16의 기본 번들러이며, Webpack이 필요하면
--webpack플래그로 선택 해제할 수 있습니다. - 함수 수준까지 캐싱하고 지연 번들링하므로 실제로 변경된 부분만 다시 계산합니다.
- 현재는 Next.js 전용이며 Webpack 로더는 지원하지만 Webpack 플러그인은 지원하지 않습니다.
JavaScript 번들러의 작동 원리 (그리고 2026년에 중요한 이유)
번들러는 소스 파일, JavaScript, TypeScript, CSS, 이미지를 가져와 브라우저용으로 패키징합니다. 개념은 단순하지만 방식은 근본적으로 세 가지 다른 접근 방식으로 나뉘어졌습니다.
- 전통적 번들링(Webpack): 전체 의존성 그래프를 사전에 분석하고 모든 것을 함께 번들링한 후 제공합니다. 철저하지만 특히 콜드 스타트에서 느립니다.
- 네이티브 ES 모듈(Vite): 개발 중에 Vite는 번들링을 완전히 건너뜁니다. 파일을 네이티브 ES 모듈(ESM)로 브라우저에 직접 제공하며, 개별 파일만 필요에 따라 변환합니다. 프로덕션의 경우 Rollup (또는 Vite 8의 Rolldown)을 사용하여 최적화된 번들을 생성합니다.
- 증분 계산(Turbopack): Rust를 사용한 SWC로 작성된 Turbopack은 함수 수준에서 캐싱하고 변경된 부분만 정확히 다시 계산합니다. 모든 것을 기억하는 똑똑한 재빌드 시스템이라고 생각하시면 됩니다.
2026년이 전환점처럼 느껴지는 이유는 무엇일까요? 생태계가 구체적으로 변했기 때문입니다. Turbopack은 8,302개의 Next.js 통합 테스트를 모두 통과했으며 기본 프로덕션 번들러가 되었습니다. Vite 8은 esbuild와 Rollup 모두를 Rolldown으로 대체하고 있으며, Rolldown은 개발과 프로덕션을 위한 단일 Rust 기반 컴파일러입니다. 그리고 Webpack은 2026 로드맵을 발표했습니다. 여전히 유지되고 진화하고 있지만 더 이상 새 프로젝트의 기본 선택지가 아닙니다.
공통 주제는 무엇일까요? Rust입니다. Turbopack (SWC를 통해)과 Vite 8 (Rolldown을 통해) 모두 이제 Rust 기반 컴파일을 사용합니다. 성능 한계가 모두에게 상향 이동했습니다.
개발 경험, 개발 서버, HMR, 그리고 일상 워크플로우
이것이 매일 느끼게 될 것입니다. 코드를 작성하는 입장에서 보면 개발 서버 시작, 핫 리로드 속도, 일반적인 워크플로우 부드러움이 모든 프로덕션 벤치마크보다 중요합니다.
개발 서버 콜드 스타트
먼저 정확한 숫자부터 시작하겠습니다. farm-fe 벤치마크 리포지토리는 동일한 하드웨어(M1 Pro, 1,000개의 React 컴포넌트)에서 모든 주요 번들러를 테스트합니다:
다음은 콜드 스타트 데이터를 시각화한 것입니다. Vite의 ESM 네이티브 접근 방식이 어떻게 놀라운 우위를 제공하는지 주목하세요:
"개발 서버 콜드 스타트 (1,000개의 React 컴포넌트)"
Vite가 콜드 스타트에서 Turbopack을 이기는 것에 놀랐습니까? 대부분의 사람들이 그렇습니다. Vite의 네이티브 ESM 접근 방식은 미리 어떤 것도 번들링할 필요가 없다는 의미입니다. 그냥 파일을 제공하기 시작할 뿐입니다. Turbopack의 증분 계산 엔진은 첫 실행에서 더 많은 설정 작업을 수행하지만, 이 투자는 HMR 속도에서 보상받습니다. 다음 요점으로 넘어갑시다.
HMR 속도
Hot Module Replacement (HMR)는 Turbopack의 아키텍처가 정말로 빛나는 곳입니다. 파일을 저장하면 Turbopack은 프로젝트 크기에 관계없이 변경된 정확한 함수만 다시 계산합니다. 10,000개의 모듈에서도 약 50ms의 업데이트를 전달합니다. Vite는 대부분의 프로젝트에서 빠르게 유지되지만 매우 큰 코드베이스에서는 300~400ms로 변할 수 있습니다. 브라우저가 여전히 변경된 ESM 모듈 체인을 가져오고 평가해야 하기 때문입니다.
Webpack은 어떨까요? 일관되게 500ms~1.6s 범위입니다. 작은 프로젝트의 경우 견딜 만합니다. 수천 개의 컴포넌트가 있는 모노레포의 경우 개발자들이 다른 선택지를 찾는 이유입니다.
"10배 빠르다" 논쟁
Turbopack이 "Vite보다 10배 빠르다"는 Vercel의 주장을 본 적이 있을 것입니다. Evan You (Vite의 creator)는 이를 직접 이의를 제기했습니다. 벤치마크가 SWC를 사용한 Turbopack과 Babel (SWC 아님)을 사용한 Vite를 비교했으며, 비현실적인 20,000개 모듈 합성 테스트를 사용했고, 숫자를 유리하게 반올림했다고 지적했습니다.
둘 다 SWC를 사용하여 동등하게 테스트하면 격차가 급격히 좁혀집니다. Turbopack은 매우 큰 프로젝트에서 HMR이 더 빠르지만, "10배"가 실제 이야기는 아닙니다.
결론: Vite는 대부분의 프로젝트의 개발 시작에서 승리합니다. Turbopack은 규모에서 HMR 일관성에서 승리합니다. 프로젝트에 5,000개 미만의 모듈이 있으면 (대부분 그렇습니다) 의미 있는 HMR 차이를 느끼지 못할 것입니다. 거대한 Next.js 앱에서 작업하고 있다면 Turbopack의 상수 시간 HMR은 정말 인상적입니다.
프로덕션 빌드 성능, 속도 vs 출력 품질
개발 속도는 헤드라인을 차지하지만, 프로덕션 빌드는 사용자가 경험하는 것입니다. 그리고 여기서 이야기가 복잡해집니다.
빌드 속도 벤치마크
Turbopack은 빠릅니다. CatchMetrics의 Cal.com 벤치마크 (Next.js 15.5, 실제 프로덕션 애플리케이션)에서 Turbopack은 152초로 빌드된 반면 Webpack은 187초로 약 19% 더 빠릅니다. 더 작은 프로젝트에서는 격차가 더 극적입니다: Makerkit은 Next.js 16으로 5.7초 대 24.6초를 측정했으며, 4.3배 개선입니다.
Vite의 프로덕션 빌드 속도는 대부분의 프로젝트에서 Webpack과 비슷하지만, Vite 8의 Rolldown이 나오면서 그것이 큰 폭으로 변할 예정입니다(Rolldown 섹션에서 자세히).
"프로덕션 빌드 시간 비교"
참고: 차트의 0 값은 해당 도구가 특정 프로젝트에 대해 벤치마크되지 않았음을 의미합니다(Turbopack은 Next.js에서만 작동하며, Vite는 Cal.com 코드베이스에서 테스트되지 않았습니다).
번들 크기: 숨겨진 트레이드오프
다음은 대화를 바꾸는 데이터 포인트입니다. CatchMetrics는 Turbopack이 더 빠르게 빌드되지만 훨씬 더 큰 번들을 생성한다는 것을 발견했습니다:
다시 읽어보세요: Webpack과 비교하여 First-load JS가 72% 증가했으며, 모든 경로에서 더 많은 JavaScript가 배송되었습니다. 모든 킬로바이트가 Core Web Vitals 점수에 영향을 주는 성능에 민감한 애플리케이션의 경우 심각한 트레이드오프입니다. 더 빠른 빌드, 더 큰 번들입니다.
Tree-Shaking 및 코드 분할
...