FrontEnd Roadmap 08 - Module Bundlers(Vite, Webpack, Rollup)

SANGHYUN KIM·2025년 3월 16일

frontend-roadmap

목록 보기

8/9

작성하는 프로젝트는 번들러에 의해서 압축이되고 경량화 된다. 지금까지 프로젝트를 하면서 가볍게 넘겼던 이들의 역할을 조금 알아보려고 한다.

Frontend Roadmap에 있는 정의에 따르면 “여러 JavaScript 파일과 해당 종속성을 단일 파일로 결합을 하는 도구“라고 한다.

근데 왜 만들어졌을까?

궁금해서 GPT의 도움을 조금 받아봤다.

JavaScript는 원래 간단한 역할을 하기 위해서 만들어졌지만, 갈수록 다양한 역할을 수행하게 되었다.
반복되는 코드를 줄이고 편의성을 위해서 라이브러리가 만들어지기 시작하고 다음 문제들이 발생했다.

파일 개수가 많아지면서 HTTP 요청 증가
- 파일은 <script>태그를 활용하여 개별적으로 요청
- 100개면 100개의 개별 요청이며, 당시 HTTP/1.1 환경에서 동시 처리 개수가 제한적
전역 네임스페이스 오염
- 모든 스크립트가 전역 스코프를 공유
- 규모가 커질 수록 전역 스코프 공유로 인한 문제 발생 가능성
의존성 관리의 어려움
- 의존성은 수동으로 관리
- 예를 들어, main.js에서 utils.js를 사용한다고 하면 HTML에서 아래와 같이 순서 보장
```
<script src="utils.js"></script> 
<script src="main.js"></script> 
```

위 문제들을 해결하기 위해 나온 것이 번들러(Bundler)라고 한다

A-1-Q-1. 지금도 단일 파일로 합치는 것이 정답인가?

사실 이 부분에 대해서도 생각을 해보지 않았지만 GPT가 같이 알려줘서 정리를 한다.

현재 우리가 개발하는 브라우저의 환경은 대부분 HTTP/2 이상의 프로토콜을 사용하고 있다. 2 버전 이상부터는 병렬 처리가 되기에 기존보다 빠른 환경을 느낄 수 있다.

이런 상황에서 “항상” 하나로 묶는 것이 더 좋을까?
아니다. 항상 좋지는 않다. 오히려 반대로 요즘에는 코드 스플리팅을 권장하는 추세이다.
필요한 스크립트들만 빠르게 불러와서 초기 로드 속도를 줄이는 것이 더 좋다.

번들링은 두 가지 단계로 나뉜다.
1️⃣ 의존성 그래프 생성 (Dependency Graph Generation)
2️⃣ 최종 번들링 (Bundling)

의존성 그래프 생성
1. entry file을 기준으로 프로젝트 내부 모든 파일 간의 관계를 매핑하기 시작
2. 매핑을 하면서 의존 파일들의 의존성도 추적하여 매핑
3. 매핑하는 과정에 모든 파일에 고유한 ID를 부여면서 최종적으로 의존성 그래프 생성
4. 이 과정이 필요한 이유:
  1. 모듈 로드 순서 정렬: 브라우저가 특정 함수 요청할 때, 필요한 의존성을 불러올 수 있게 순서 정리
  2. 네이밍 충돌 방지: 고유 ID부여 및 의존성 파악을 했기에 함수명이 충돌하지 않도록 방지
  3. 사용되지 않는 파일 감지: 사용되지 않는 불필요한 파일 제거
최종 번들링
1. 의존성 그래프를 활용하여 여러 개의 코드 파일을 하나로 통합
2. 필요한 함수 및 module.exports 객체를 삽입
3. packing하여 브라우저가 실행할 수 있는 정적 파일을 생성

Frontend Roadmap 기준으로 현재 나와 있는 번들러들은 총 6개이며 이 중에 Vite와 esbuild를 권장한다고 되어 있다.

그래도 25년에 적으니 State of JavaScript에서 발표한 build tools 중에 상위 3가지를 한번 보려고 한다.

번들러를 이야기하면 절때 빠질 수 없는 선두주자이다.
당시 다양한 빌드 도구들이 있었지만 다음 이유로 빌드 도구의 선두주자가 되었다.

다양한 지원 모듈 시스템:
- CommonJS, AMD, ES module을 전부 다 지원
코드 스플리팅 및 트리 쉐이킹 지원
- 필요한 파일만 로드할 수록 지원하여 최적화에 도움
모든 리소스를 모듈로 처리 가능
- Browserify는 JS 파일만 번들링할 수 있었지만, Webpack은 CSS, 이미지, 폰트 등 모든 파일을 모듈처리
React, Vue, Angular의 초기 개발 설정에 기본적으로 같이 추가되어 설치

장점:

단점:

현재 가장 빠르게 확장되고 선호되는 번들링 라이브러리다.
Vite는 다음 두 가지 문제를 해결하기 위해서 만들어졌다.

개발 시 느린 구동속도
- native ES module 시스템을 활용하여 변경된 파일을 컴파일 후 전달이 아닌 변경된 파일을 바로 브라우저 전달
느린 빌드 속도
- Rollup을 활용하여 빌드시간 단축 및 최적화

장점:

가볍고 빠르다: Native ESM system을 활용하기 무척 빠르며, 개발에 필요한 최소의 기능만 지원한다. 필요하면 plugin을 설치하여 확장하는 방식이다
다양한 프레임워크 지원: Vite는 React, Vue, Preact 등과 같이 library 지원도 하지만 meta framework인 Remix와도 같이 사용될 수 있다

또한, CRA가 deprecated됨에 따라 SPA생성에 기본으로 잡혀가고 있다.

단점:

오래된 브라우저 미지원: Vite의 놀라운 속도는 browser의 native ESM system에 의존한다. 오래된 브라우저에서 실행시킬 수 없다는 단점은 있다

ES Module을 기반으로 번들링이 되며 트리 쉐이킹을 셀링 포인트로 가지고 있는 번들러이다. 또한, 이 블로그에 따르면 확장이라는 키워드로 인하여 현재 많은 라이브러리들이 채택하여 사용 중이라고 한다.(실제로도 공식 사이트에서 많은 라이브러리에서 사용 중이라고 기재)

장점: