# Webpack → Vite: 번들러 마이그레이션 이야기

> Clean Markdown view of GeekNews topic #6164. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=6164](https://news.hada.io/topic?id=6164)
- GeekNews Markdown: [https://news.hada.io/topic/6164.md](https://news.hada.io/topic/6164.md)
- Type: news
- Author: [hiddenest](https://news.hada.io/@hiddenest)
- Published: 2022-03-16T13:53:35+09:00
- Updated: 2022-03-16T13:53:35+09:00
- Original source: [engineering.ab180.co](https://engineering.ab180.co/stories/webpack-to-vite)
- Points: 27
- Comments: 4

## Topic Body

서비스 출시 후 5년 동안 사용하던 Webpack을 Vite로 옮기며 있었던 이야기를 공유합니다. 부족한 부분이 많지만 재밌게 읽어주신다면 감사하겠습니다.  
  
---  
  
### Webpack의 장점과 웹 생태계의 변화  
Webpack은 지난 10년간 개발, 관리되며 생태계가 잘 갖춰져 있음.  
Create React App 등 많은 곳에서도 쓰이고 있으며, IIFE 방식으로 모듈을 묶어주어 여러 브라우저를 지원함.  
  
하지만, 5년 간 서비스 내의 기능이 3배 가까이 늘어나며 빌드 시간이 늘어나는 등 개발 경험이 나빠짐. 그리고 웹 생태계 발전으로 ES Module의 지원 등 다양한 변화가 있었음.  
  
  
### Bundler + Native  
최근 1~2년 사이에 Native의 힘을 빌려 번들링, 트랜스파일링 하는 것이 떠오르기 시작함. 싱글 스레드인 JS의 처리 한계를 뛰어넘기 위한 시도가 이뤄짐.  
Golang 기반의 [esbuild](https://esbuild.github.io/), Rust 기반의 [SWC](https://github.com/swc-project/swc) 등이 대표적임.  
  
  
### 1차 시도: esbuild만을 사용한 번들링  
당시 안정성, 플러그인 등 생태계를 고려하여 esbuild를 기반으로 하는 번들러 사용을 결정함. 그리고 esbuild 자체의 성능이 어느 정도인지 알아보려고 함.  
패키지 설치 후 빌드 스크립트를 돌렸더니, 기존 210초 정도 소요되던 빌드가 2.16초 만에 끝남. **100배 정도 빠른 빌드 속도**를 보임.  
  
하지만 EmotionJS 사용을 위해 Babel을 적용하면 10배 느려짐.  
그리고 esbuild가 HMR을 지원하지 않아 사용이 어렵다고 판단함. 직접 HMR을 구현할 수도 있었지만, 공수, 유지/보수/관리 비용이 많이 든다고 생각했음.  
  
  
### 2차 시도: Vite를 사용한 번들링  
[Vite](https://vitejs.dev/)의 컨셉은 Dependencies와 Source code를 분리한다는 점임.  
Dependencies는 설치 후 내용이 바뀌지 않으니 esbuild로 미리 트랜스파일링. Source code는 빈번하게 바뀌므로 ESM으로 로딩. 빌드 결과는 캐싱하여 빠른 개발 빌드가 가능하게 함.  
  
Vite에서 제공하는 템플릿 사용하여 쉽게 마이그레이션 진행. 몇 가지 이슈가 있었지만 금방 해결하였으며, Webpack보다 훨씬 짧고 간결한 설정을 할 수 있게 됨.  
  
---  
  
### 번들러 마이그레이션 결과  
Netlify에서의 빌드 시간 측정 시 평균 250초 → 평균 90초. **기존의 36% 수준**으로 줄어듦.  
설정 파일이 간결해지면서 팀원들이 이를 활용한 커스텀 빌드 환경을 손쉽게 만들어 능률 향상됨.  
  
더 나은 개선을 위해 Babel 의존 없는 CSS-in-JS 라이브러리로 교체, Monorepo 적용을 해볼 수 있음.  
생태계의 경우, SWC가 안정화될 경우 Babel을 교체할 수 있을 것이며, [TypeScript Type Checker 역시 Native로 포팅 중임](https://kdy1.dev/posts/2022/1/tsc-go).  
  
### 교훈  
- 크게 보이던 작업도 작게 나누어 테스트하고 많이 의논하면 쉽게 풀린다.  
- 지금 메이저하게 쓰고 있는 도구도 생태계의 발전으로 금방 사라질 수 있다.  
- 좋은 접근성이 좋은 환경을 만들어준다.

## Comments



### Comment 9277

- Author: ifmkl
- Created: 2022-03-17T09:59:46+09:00
- Points: 1

esbuild 속도 놀랍네요 .

### Comment 9279

- Author: hiddenest
- Created: 2022-03-17T10:58:44+09:00
- Points: 1
- Parent comment: 9277
- Depth: 1

esbuild 메인 홈페이지에서도 10-100x 빠르다는 점을 내세우는 것을 보고 긴가민가했었는데, 실제로 보니까 충격적이더라고요!

### Comment 9271

- Author: [deleted]
- Created: 2022-03-16T14:34:20+09:00
- Points: 1

[삭제된 댓글입니다]

### Comment 9272

- Author: hiddenest
- Created: 2022-03-16T15:10:22+09:00
- Points: 1
- Parent comment: 9271
- Depth: 1

저도 그런 시대가 오길 정말 기대하고 있어요! 정말 개발하기 좋아질 것 같아요 :)