Webpack로 빌드 환경 구성하며 이해한 선택 기준

문제/동기

• React를 사용하며 "왜 어떤 경우에는 Vite, 어떤 경우에는 Webpack을 쓰는가?"라는 의문이 생김.
• 공식 문서와 자료를 참고해 Webpack 기반으로 빌드 환경을 직접 구성하며 동작 원리를 체득하고, 도구 선택 기준을 정리하고자 함.

환경

• 프로젝트: 빌드 도구 학습/실습용 설정 구성
• 스택: React, TypeScript, Webpack 5, Babel
• Node: LTS 버전(예: 18.x)

학습/실습 과정

1. 기본 설정 작성
   • entry/output/mode/devtool/resolve를 분리하고 개발/배포 모드를 스위칭.
   • 개발 시 소스맵(devtool), 별칭(alias)로 import 경로 단순화.
2. 로더 구성(파일을 JS로 변환)
   • babel-loader 또는 ts-loader로 TS/JS 트랜스파일.
   • css-loader+style-loader로 CSS 번들링, asset modules로 이미지/폰트 처리.
3. 플러그인 구성(번들 생명주기 확장)
   • HtmlWebpackPlugin으로 HTML 템플릿 주입, DefinePlugin으로 환경변수 주입.
   • 프로덕션에서 정리/최적화 플러그인 적용.
4. 코드 스플리팅/캐싱 전략
   • splitChunks, runtimeChunk: 'single', contenthash로 장기 캐싱 최적화.
   • 동적 import로 라우트 단위 청크 분리.
5. 개발 경험 개선
   • webpack-dev-server와 HMR로 빠른 피드백 루프 확보.

핵심 설정 포인트(요약)

• 로더는 "각 파일을 JS로 변환"하는 역할, 플러그인은 "번들링 과정 자체를 확장".
• 개발/배포 설정 분리(devtool, 압축, 캐싱), 아티팩트 이름에 contenthash 사용.
• 큰 의존성은 청크 분리, 라우트별 코드 스플리팅으로 초기 로드 시간 단축.

선택 기준: Vite vs Webpack

• Vite
  • 네이티브 ESM+esbuild 기반으로 개발 서버가 매우 빠름, 설정 복잡도 낮음.
  • SPA/라이브러리 개발 등 일반적인 요구에 적합, 최초 생산성 높음.
• Webpack
  • 레거시/복잡한 커스터마이징, 정밀한 번들 파이프라인 제어가 필요할 때 유리.
  • 커스텀 로더/플러그인, 세밀한 청크·캐싱 전략, SSR/마이크로프론트엔드 등 고급 시나리오에 강점.

검증

• 개발 서버 기동/변경 반영 시간, HMR 체감 속도 확인.
• 번들 사이즈와 청크 수, 초기 로드 대비 지연 로드 효과 비교.
• 프로덕션 빌드 시간 및 캐시 적중 여부(파일 해시 변경) 확인.

배운 점

• 빌드 도구는 "파일 변환(로더)"과 "과정 확장(플러그인)"의 조합으로 이해하면 복잡성이 줄어든다.
• 요구사항이 단순하면 Vite로 빠르게 시작하고, 파이프라인 제어가 필요해질수록 Webpack의 장점이 부각된다.
• 코드 스플리팅/캐싱을 염두에 둔 설계가 성능과 유지보수성을 동시에 끌어올린다.

참고

• Webpack 공식 문서, Vite 공식 문서, 각 로더/플러그인 레퍼런스