🙇🏻♂️ 이 글을 정리하는 이유
오늘은 프론트엔드 번들러인 Webpack, Vite, Bun 각각의 특징과 차이점을 정리해보려 합니다.
저는 프론트엔드 프로젝트를 진행하면서 Webpack과 Vite와 Bun을 모두 사용해 본 경험이 있습니다.
프로젝트를 세팅할 때 번들러 선택은 항상 중요한 고민이었고, 그동안의 경험을 바탕으로 정리해보려 합니다.
이전에 작성한 Webpack 관련 글에서 번들링의 개념과 필요성에 대해 다뤘기 때문에, 번들러의 탄생 배경과 번들링이 어떤것인지 왜 필요한지에 대한 부분은 넘어가도록 하겠습니다.
🤔 Webpack 너는 누구니?
Webpack은 JS의 대표적인 모듈 번들러입니다.
JS 모듈들을 하나의 번들 파일로 묶어 관리와 로딩 성능을 향상시켜줍니다.
HTTP 요청 수를 줄여 초기 로딩 속도를 개선하는 데 효과적입니다.
그리고 로더(loader)를 통해 CSS와 IMG, 폰트 파일들을 하나의 번들 파일로 묶어주는 기능을 지원합니다. HTML 파일 역시 플러그인을 통해 자동 생성 및 주입이 가능합니다.
그만큼 Webpack은 프론트엔드 성능에 있어서 아주 강력한 성능을 보여주죠.
또한 Webpack의 설정을 통해 지원하는 기능들도 많습니다.
📌 Webpack이 지원하는 기능들
- HMR
HMR은 브라우저를 새로 고치지 않고도 변경된 모듈만 실시간으로 반영되도록 도와주는 기능입니다. 스타일이나 컴포넌트 변경 사항을 즉시 확인할 수 있어, 개발 생산성을 크게 향상 시킬수 있습니다. - Tree shaking
트리 쉐이킹은 사용되지 않는 코드를 제거하여 최종 번들 크기를 줄여주는 최적화 기법입니다. 또한 Webpack의 production 모드에서는 이 기능을 자동으로 적용합니다. - Code Spliting
코드 스플리팅은 애플리케이션을 여러 개의 번들로 나누어, 필요한 시점에 필요한 코드만 로드할 수 있도록 하는 기법입니다. 예를 들어, 과자 한봉지가 있는데 이것을 소분하고 싶어서 그릇에 소분해 두면 그것이 바로 코드 스플리팅이라고 할 수 있는거겠죠? - Lazy Loading
Lazy Loading은 코드 스플리팅을 통해 나뉘어진 모듈들을, 실제로 필요한 시점에 로딩하도록 하는 방식입니다.
예를 들어, 초기 로딩 시 모든 코드를 한 번에 불러오는 것이 아니라, 특정 페이지에 접근했을 때 해당 기능만 불러와 실행되도록 합니다. 이를 통해 초기 로딩 속도를 개선할 수 있습니다.
그런데, 이런 Webpack을 두고 왜(?) 다른 Vite와 Bun을 사용할까요?
❌ Webpack의 단점
그렇다면 Webpack의 단점은 어떤게 있을까요?
단점 리스트.
- 느린 번들링 속도
가장 중요한 부분은 Webpack은 Vite와 Bun에 비해 느린 번들링 속도가 큰 단점입니다.
웹팩은 프로젝트 전체를 분석해서 번들링하기 때문에, 초기 빌드 속도가 느린것이 특징입니다.
이것은 프로젝트의 규모가 커질수록 그 속도가 체감될 수준이죠. - 복잡한 설정
webpack.config.js는 유연하고 강력한 만큼 설정이 복잡해지고, 학습량도 많습니다.
그렇기 때문에 세팅을 하는 과정이 오래 걸리는 단점이 존재합니다.
- 상대적으로 느린 HMR
HMR 기능은 있지만, Vite와 Bun과 비교하면 상대적으로 느리거나 번거롭게 느껴질 수 있습니다. 그 이유는 Webpack은 전체 구조를 바라보고, vite와 bun은 바뀐 모듈만 바라본다 라고 생각하시면 됩니다. - ESM 기반이 아닌 CommonJS 기반의 Webpack
Webpack은 ESM에 친화적이지 않습니다. Webpack은 CommonJS 기반으로 설계 되었습니다. 그리고 추후에 ESM이 지원된것이죠. 그렇기 때문에 당연히 vite와 bun과 같이 ESM에 친화적인 번들이 더 자연스러운것이 사실입니다.
이러한 단점을 보완하기 위해 나온 것이 바로 Vite와 Bun입니다.
각각의 특징을 한번 알아보죠.
⭐️ Vite너는 누구니?
Vite는 차세대 프론트엔드 개발 도구입니다.
차세대 라는 단어부터 뭔가를 대체하기 위해 나온것을 알수있겠죠?
이런 vite의 특징으로는 빠른 개발 서버와 효율적인 번들링을 제공하는 툴 이라는 점 입니다.
Webpack의 단점과 비교해 Vite를 선택해야 하는 이유를 살펴보겠습니다.
Vite 써야하는 이유
-
빠른 개발 속도
Webpack은 변경 시 전체 프로젝트를 다시 분석해 번들링하지만, Vite는 개발 중 번들링을 하지 않고 변경된 파일만 빠르게 반영합니다. 프로젝트가 커질수록 이 장점이 크게 느껴집니다. -
복잡한 설정 없이 바로 사용 가능
Webpack은 webpack.config.js를 설정해야합니다. 그 과정에서 loader와 플러그인 세팅 등의 시간이 많이 걸립니다.
반면 vite는 npm create vite를 통해 프로젝트 템플릿부터 개발 서버까지 바로 구축합니다. 즉, 개발자가 바로 개발에 집중할수 있는 환경을 제공하는것이죠. -
ESM 기반의 Vite
앞서 설명한 것처럼 Webpack은 CommonJS 기반으로 설계되었습니다.
이 때문에 ESM 지원은 나중에 추가된 방식이며, 완전히 자연스러운 형태가 아닙니다.
반면 Vite는 처음부터 ESM 기반으로 설계되어, import, export 문법을 네이티브하게 지원합니다. 또한 브라우저의 ESM 기능을 적극 활용하여 빠르고 효율적인 개발 환경을 제공할수 있다는 점이 있죠.
4.두 개의 엔진을 사용하는 Vite
두 개의 엔진이라는 말은 Vite는 개발 중 과 빌드 할 때와의 차이가 존재합니다.
✅ 개발 중 (ESM 기반 번들 없이 작동) :
개발 중에서는 ESM 기반 개발 서버를 작동합니다. 즉, 코드를 브라우저가 직접 모듈 단위로 가져가기 때문에 번들링을 하지않아 빠릅니다.
( 저장하면 브라우저가 바뀐 파일만 다시 요청해서 보여주는 형식 <- 이게 빠른 이유)
✅빌드 할 때 (Rollup 사용) :
빌드 시에는 Rollup을 사용해, 트리 쉐이킹과 코드 스플리팅 등 최적화를 적용한 번들 파일을 생성할수 있습니다. 그래서 Webpack 그 이상으로 성능 좋은 번들 결과물을 만들어 낼수 있다는 겁니다!
- 더 나은 DX
위에 내용들의 중복된 내용일수 있겠지만, 이 모든것은 DX와의 연관도 큽니다.
vite는 빠른 반영 속도와 직관적인 설정 방식을 보여주고 있습니다. 이러한 부분은 개발자의 편의성을 생각하여 만든것이기도 합니다.
복잡한 설정 없이 바로 개발을 할수 있고, 변경 사항 또한 빠르게 반영하여 더 나은 개발 환경을 보장합니다.
이렇기 때문에 vite의 사용량이 증가할수 밖에 없는 이유들이겠죠?
그렇다고 Webpack이 완전히 쓰이지 않고있는가?
절대 아닙니다. 지금도 아주 많이 쓰이고 있어요.
- 기업 프로젝트 혹은 레거시 프로젝트의 상당수가 webpack을 사용하고 있습니다.
- 복잡한 설정이 필요한 대규모 서비스 또한 역시 webpack의 유연한 설정이 더 유리하게 작용할수 있습니다.
- 또한 플러그인의 생태계가 webpack이 더 방대하다는 점에있어서 더 많은것을 커버할수 있다라는 것입니다!
🚀 Webpack vs Vite 결론
누가 더 좋고 나쁘다의 문제가 아닙니다. 중요한 것은 자신의 프로젝트의 성격에 맞는 번들러를 선택하는 것입니다. 그것을 알기 위해서 이 글을 작성하는것 입니다.
저라면 이제는 이렇게 생각할거 같습니다.
- 간단한 프로젝트라면 복잡한 설정이 필요 없는 Vite가 더 효율적일 수 있습니다.
- 반대로 복잡한 요구사항이 있는 프로젝트에서는 Webpack의 확장성과 플러그인 생태계를 활용하는 것이 더 적합할 수 있다라고 판단합니다.
저희는 이제 어떤 상황에서 webpack 혹은 vite 고민해야하는 그런 지식(?) 들이 생겼습니다.
이제 남은거는 Bun입니다!
🍞 Bun 너는 누구니?
Bun은 제가 인턴 당시 새로 투입되는 프로젝트의 번들러가 Bun이였습니다.
그때부터 Bun을 활용하여 개발을 했습니다.
Bun은 최근 주목받는 런타임이자 번들러입니다.
이게 무슨 말인가? 라고 생각하실수 있습니다. 즉, Node.js를 대체하기 위해 나왔다고 생각하시면 됩니다. 번들링, 트랜스파일링, 테스트 실행, 패키지 매니저 기능까지 모두 하나로 통합한 올인원 도구라고 생각하시면 됩니다. (정말 엄청 납니다...👍👍👍)
Bun 특징
- 엄청난 속도
앞에 webpack의 속도 문제를 개선하기 위해 나온 vite또한 빠르다고 하지않았나요? 라고 하실수 있지만 Bun은 더 빠른 속도를 자랑하고 있습니다. Rust로 개발되었으며, Bun이 webpack과 vite보다 빠를수 있는 점은 js의 파싱, 번들링, 실행까지 모두 하나의 프로세스에서 수행하며, 네이티브로 구현된 런타임 덕분에 최소한의 자원 소모를 통한 처리 속도 극대화를 진행합니다. - Node.js 대체
또한 bun은 자체 런타임을 가지고 있습니다. 그말은 Node.js가 필요없다는 것입니다. bun의 명령문을 통해 실행, 테스트, 번들링이 가능한겁니다. - 통합 도구 제공
bun install, bun run, bun test 등의 다양한 커맨드를 제공합니다. 즉, npm, yarn을 대체할 수 있는 패키지 매니저 역할을 수행할수 있다는 점이 특징입니다. - 간단한 설정
bun또한 설정 파일 없이 바로 실행 가능하며, 기본적으로 빠른 성능을 제공하기 때문에 추가 설정이 거의 필요 없다 라고 할수있으니 DX적인 측면에서 우수합니다. - ESM 지원
Bun은 ESM을 기본적으로 지원합니다. 또한 CommonJS 호환도 가능합니다. 그렇기 때문에 최신 JS에 더 유리한 환경을 가지고 있습니다.
하지만 이러한 성능의 Bun 역시 고려해야하는 부분들이 존재합니다..!!
❗ Bun의 고려사항
- 정보가 적다
아직까지는 Bun의 대한 정보가 적습니다. Webpack과 vite에 비하면 상당히 적은 편이죠.
그래서 다양한 시나리오에 대처하는 방식 또한 쉽지 않을수 있습니다. - 호환성
Bun은 Node.js를 대체 하기 위해 나왔지만, node.js 기반 패키지와 호환성의 문제가 생길수 있습니다. 그러므로 프로젝트에 도입 전 사전 검증은 필수 처럼 보입니다.
🖥️ 번들러 기능 비교
| 항목 | Webpack | Vite | Bun |
|---|---|---|---|
| 초기 빌드 속도 | 느림 | 빠름 | 매우 빠름 |
| 설정 복잡도 | 높음 | 낮음 | 매우 낮음 |
| ESM 지원 | 제한적 | 완전 지원 | 완전 지원 |
| 개발 서버 | 자체 devServer | ESM 기반 빠른 서버 | 자체 런타임 |
| 생태계 | 매우 방대 | 성장 중 | 초기 단계 |
| 학습 난이도 | 높음 | 쉬움 | 쉬움 (단, 정보는 적음) |
지금까지 Webpack과 vite 그리고 Bun의 기능 비교를 표로 정리해 보았습니다.
이렇게 하나씩 공부를 하고 표까지 정리해보니 번들러에 대한 이해가 쉽더라구요!
💡 느낀점
성능만 보고 번들러를 선택하는 것은 위험할 수 있습니다.
무조건 Webpack보다 Vite와 Bun이 낫다기보다는 자신의 프로젝트에 어떤 도구가 가장 적합한지를 파악하는 것이 중요합니다.
이 글을 통해 다양한 번들러의 특성과 차이를 이해하고, 상황에 맞는 도구를 선택할 수 있는 개발자가 되셨길 바랍니다. (저 자신이 이러한 목표를 이루고자 작성해보았습니다 ㅎ)
실습과 프로젝트 적용 예시는 분량상 이번 글에 담지 않았지만, 이해 쉽게 정리가 된다면 추후 글로 정리해볼 예정입니다.
글 읽어주셔서 감사합니다 ☺️
