Turbopack과 Webpack을 비교하며 번들러를 선정하는 과정을 통해서, 기술 도입은 단순히 빠르거나 새로운 것이라는 이유로 선정하는 것이 적절하지 않다는 것을 깨달았습니다. 실제로 Turbopack의 속도나 효율성은 큰 장점이지만 아직 실험 단계에 있다는 문제가 있는데, 실제 서비스를 운영하게 될 경우에는 예측 가능한 빌드 결과가 굉장히 중요한 요소이기 때문에 Webpack을 fallback 처리하여 안정성을 보완하였습니다. 따라서 앞으로도 각 환경의 목적에 맞는 도구를 잘 따져보고 선정하는 것이 진정한 기술적인 의사결정이라는 생각이 들었고, 앞으로도 새로운 기술을 검토할 때 단순한 성능 비교가 아니라 실질적인 운영 관점에서의 리스크와 이점을 함께 고민해보려고 합니다.
7. Turbopack (dev) + Webpack (prd)
7-1. 선정 이유
- Turbopack은 Next.js 팀(Vercel)이 개발한 Webpack의 차세대 번들러로, Rust 기반의 병렬 처리 구조를 통해 개발 환경에서 압도적으로 빠른 HMR과 빌드 속도를 제공합니다.
- Next.js 15부터는 Turbopack이 기본 dev 번들러로 채택되었으며, 실시간 피드백이 중요한 환경에서 생산성을 극대화할 수 있습니다. 하지만 프로덕션 환경에서는 Turbopack이 아직 실험적인 기능으로 간주되며, 일부 기능(이미지 최적화, PWA 플러그인, dynamic route 등)에서 불안정하거나 예상치 못한 이슈가 발생할 수 있습니다.
- 반면 Webpack은 Next.js의 공식 번들러로 오랜 시간 검증된 안정성과 생태계 호환성을 갖추고 있으며, SSR, SEO, 이미지 처리 등 다양한 기능에서 확실한 신뢰성을 제공합니다.
7-2. dev/prd 환경별 번들러 전략
| 환경 | 사용 번들러 | 이유 |
| 개발(dev) | Turbopack | HMR, 빠른 rebuild 속도 → 개발자 경험 극대화 가능 |
| 배포(prd) | Webpack (fallback) | 안정적인 빌드, 플러그인 호환성, 이미지 최적화 등 검증된 프로덕션 안정성 |
→ 이러한 이유로 개발(dev) 환경에서는 Turbopack, 프로덕션(prd) 환경에서는 Webpack을 fallback으로 사용하는 전략을 선택했습니다. dev 환경에서의 실행 속도로 개발자의 경험을 극대화하면서 prd 환경의 안정적인 배포를 보장하는 선택이라고 생각합니다.
7-3. Turbopack vs Webpack
| 항목 | Turbopack (dev) | Webpack (prd) |
| 개발 속도 (HMR) | 매우 빠름 (Rust 병렬 처리) | 느림 (의존성 많을수록 느림) |
| 번들 성능 (빌드) | 아직 실험적 | 안정적 |
| 플러그인 호환성 | 일부 제한 (next-pwa 미지원) | 매우 넓음 |
| 이미지 최적화 | 일부 이슈 존재 | next/image 완전 지원 |
| 중첩 라우팅 / SSR | 대응 가능하나 불안정 케이스 존재 | 안정적 |
| 도입 안정성 | Next.js 15 dev default | Next.js 전 버전까지 공식 빌드 번들러 |
참고로 Vite는 React 기반 SPA에서 매우 뛰어난 성능을 보이지만, Next.js와의 공식 호환이 없고 SSR 구조가 필요한 프로젝트에서는 적용이 어렵기 때문에 비교 대상에서 제외하였습니다.
7-4. Turbopack이 Webpack보다 빠른 이유는?
Turbopack은 Webpack의 후속으로 Rust 언어 기반의 번들러입니다. 기존 Webpack이 JavaScript로 작성되어 단일 스레드 처리 방식이었던 반면, Turbopack은 멀티 스레드 병렬 처리를 통해 컴파일과 번들링을 동시에 수행할 수 있어 속도 면에서 압도적인 차이를 보인다는 장점이 있습니다.
또한 Incremental Bundling 구조를 통해 변경된 파일만 다시 번들링하기 때문에, 개발 중 파일이 많아져도 전체를 다시 빌드하지 않고 수정된 부분만 빠르게 반영할 수 있습니다.
실제로 Vercel 공식 자료에 따르면, 4코어 기준 Webpack 대비 28% 빠르고 16코어에서는 60%, 30코어에서는 83%까지 빠른 빌드 성능을 보여주었습니다.
'👩🏻💻 Develop > Document' 카테고리의 다른 글
| [설계 문서] shadcn/ui 선정하기 (0) | 2025.10.09 |
|---|---|
| [설계 문서] Axios 1.8.4 선정 이유 (0) | 2025.10.07 |
| [설계 문서] Zustand? Tanstack Query? 전역 상태 관리 라이브러리 선정하기 (0) | 2025.10.05 |
| [설계 문서] 서비스에 최적화된 TailwindCSS 4.0 선택하기 (0) | 2025.10.01 |
| [설계 문서] TypeScript를 선택한 이유 (vs JavaScript) (0) | 2025.09.29 |