서론

🌟 별 하나에 글 하나 프로젝트

저번 글에서는 PM을 Yarn berry로 결정한 이유를 알아보고, 모노레포를 구성한 과정을 살펴보았다. 이번 글에서는 번들러가 무엇인지, 프로젝트에서 빌드 툴로 Vite를 선택한 이유를 알아보자.

Bundler?

이미지 출처 - 동네마트

위 사진보다 번들러를 더 잘 표현할 수 있는 사진이 있을까? 번들러의 역할은 여러 모듈을 단일 파일로 묶어주는 역할을 수행한다.

이미지 출처 - Webpack 공식 홈페이지

과자 네 봉지를 마트에서 구매해 집에 들고간다고 생각해보자. 과자 봉지들이 낱개로 존재하는 것보다는 번들로 묶여있는 편이 집에 들고가기 수월할 것이다.
브라우저도 똑같다. 스크립트 파일들이 수많은 모듈로 이루어져있으면, 각각의 파일들을 요청하고 받아오는 오버헤드가 정말 커질 수도 있다. 정말 그런지 테스트해보자.

간단한 테스트

이 테스트는 번들러의 필요성을 체감해보기 위한 초 간단한 테스트이다. 약간의 비약은 있을 수 있지만, 번들러의 필요성을 느끼기에는 충분한 테스트라고 생각된다.

먼저 다섯개의 js 파일을 불러오는 프로젝트이다. 각각의 js 파일은 간단하게 콘솔에 숫자 하나씩을 출력하는 스크립트이다.

VSCode의 live server 를 통해 프로젝트를 실행해보자.

의도한 대로 콘솔에 숫자가 잘 출력되는 모습이다. 크롬의 개발자 도구(F12)에서 Network 탭을 이용하면 서버와의 데이터를 주고받는 과정을 살펴볼 수 있다. 한 번 확인해보자.

각 스크립트들을 잘 가져오고 있는 모습이다. Time 부분을 보면 각각의 스크립트를 가져오는데 소요된 시간을 확인할 수 있고, Finish 부분을 통해 HTML, JS의 Blocking, Non Blocking 리소스가 모두 다운로드 되는데 까지 소요된 시간을 확인할 수 있다.
이 예시에서는 923 ms의 시간이 소요되었다. 그렇다면 이 다섯개의 스크립트를 하나로 합쳐보자.

다섯개의 스크립트를 bundle.js라는 이름으로 합쳐주었다. 이외의 다른점은 하나도 없다.

스크립트도 마찬가지로 콘솔에 숫자를 출력할 뿐이다. 이번에는 하나의 스크립트에서 수행한다는 점만이 차이이다.

결과도 전혀 다를것이 없다. 그렇다면 Network 탭을 한 번 확인해보자.

Finish 이벤트가 발생할 때까지의 시간차이가 보이는가? 아까 스크립트 파일이 5개 존재했을 때는 923 ms의 시간이 필요했지만, 같은 내용으로 하나의 파일을 불러오는데 까지는 907 ms의 시간이 소요되었다.

---

결론
같은 내용일지라도 여러개의 스크립트를 요청하고 받아오는 것과, 하나의 파일을 요청하고 받아오는 것은 기본적인 request와 response에 소요되는 시간때문에 차이가 발생한다. 위처럼 정말 간단한 예시에서는 체감하기 어려울 정도의 차이지만, 만약 스크립트가 굉장히 복잡해지고, 크기가 커지고, 파일의 개수가 늘어나면 그 많은 모듈을 요청하고 받아오는데에는 많은 시간이 필요해질 수도있다. 따라서 우리는 많은 모듈을 하나의 파일로 묶어줄 번들러가 필요한 것이다.

👔 즉 번들러는 우리가 직접 하나의 파일로 정리하지 않아도, 각각 모듈의 의존성, 함수 변수의 중복이름 등을 모두 알아서 처리, 단일 파일로 묶어주는 고마운 친구이다.

추가로, 번들러를 이용하면 ES6 모듈(import, export)을 지원하지 않는 브라우저에서 ES6 모듈을 사용해도 번들러가 알아서 잘 처리해준다! 또한 번들된 결과물을 추가로 난독화하는 등의 플러그인들을 수많이 지원하고 있으니 안쓸 이유가 없지않는가 👏

번들러도 종류가 많아요

이미지 출처 - npm trends

번들러도 많은 종류가 존재한다. 아마 가장 유명한 친구들은 위 세가지 정도인 것으로 알고 있다. 역시나 가장 인기가 많은 것은 웹팩인것으로 확인할 수 있다. 이제 각각의 번들러들의 특징을 알아보자.

Webpack

이미지 출처 - 위키피디아

웹팩은 출시된지 벌써 10년이 넘은 이 바닥의 고인물이다. 그런 만큼 이용자 수도 가장 많고, 그에 따라 커뮤니티가 굉장히 크다. 이말은 트러블 슈팅에도 용이하고, 지원이 뒷받혀준다는 말이다. 웹팩의 특징을 나열해 보면 다음과 같다.

1. 간편한 설정

   

웹팩은 webpack.config.js라는 파일을 통해 여러가지를 설정할 수 있다. 이 파일은 굉장히 직관적이고 따로 설정해줄 것이 많지 않아 간편하게 구성할 수 있다. 이마저도 CRA(Create-React-App)와 같은 빌드 셋업 툴들을 활용하면 정말 건드릴 것이 크게 없다.

2. 방대한 플러그인과 로더
   상기했듯 강력한 개발 커뮤니티와 방대한 생태계가 존재하므로 많은 플러그인과 로더를 지원한다. 다양한 플러그인과 로더들이 오픈소스로도 개발되고 있다.
3. 코드 스플리팅
   공식문서에서 Webpack의 가장 매력적인 기능 중 하나라고 소개하는 기능이다. 이 기능을 사용하여 코드를 다양한 번들로 분할하고, 요청에 따라 로드 또는 병렬로 로드한다. 이는 로드 시간에 큰 영향을 끼칠 수 있다. 자세한 내용은 공식문서가 정말 잘 설명해주고 있으니 꼭 읽어보자.
   Code Splitting
4. 강력한 개발 서버
   웹팩이 지원하는 개발 서버는 매 코드 변경마다 빌드된 결과물을 확인할 수 있는 강력한 툴이다. 실제 번들링 된 결과물을 테스트해볼 수 있으니 상당히 유용하다.

Rollup

이미지 출처 - Rollup 공식 홈페이지

Rollup은 2017년에 출시한 모듈 번들러이다. 공식 문서를 살펴보면 알겠지만 작은 코드조각을 더 크고 복잡한 라이브러리, 어플리케이션을 만들어준다는 것을 강조한다. Rollup의 특징을 살펴보자.

1. 빌드 결과물을 ES6 모듈 형태로 출력할 수 있다.
   아마 Rollup의 가장 큰 특징 중 하나일 것이다. ES6 모듈 형태로 결과물을 출력할 수 있으므로 라이브러리나 패키지에 활용할 수 있다. 이미 Vue와 같은 라이브러리들이 Rollup을 활용해 번들링을 진행중이다.
2. 호이스팅
   웹팩은 각 모듈을 함수로 감싸고 평가한다. 즉 전역스코프에 있던 변수들을 지역변수로 변경해 줌으로써 변수이름 충돌을 방지하는 것이다. 하지만 Rollup은 코드들을 동일한 수준으로 평가하고, 번들링을 한번에 진행하므로 웹팩보다 속도가 빠르다. 변수이름 충돌 문제는 식별자를 통해 방지한다.

Rollup은 웹팩보다는 가볍고 빠르지만, 웹팩이 조금 더 안정적이라고 할 수 있다. 일반적으로 라이브러리나 패키지등을 개발하고 있다면 Rollup을, 복잡한 종속성, 높은 안전성이 요구되는 어플리케이션을 개발한다면 웹팩을 이용한다.

ESBuild

이미지 출처 - esbuild 공식 홈페이지

ESBuild는 2020년에 출시된 차세대 번들러로써, 빠른 성능으로 최근 받고 있다. 공식 홈페이지에 들어가자마자 속도 그래프를 보여주는 것이 성능을 정말 중요시한다는 것을 확인할 수 있다.

이미지 출처 - esbuild 공식 홈페이지

ESBuild의 가장 큰 특징은 역시 성능이다. 그렇다면 ESBuild는 어떻게 이렇게 빠른것인가? 공식문서를 살펴보면 그 의문을 해소할 수 있다.
Why is esbuild fast?
공식 문서에서는 ESBuild가 빠른이유로 다음을 이야기하고 있다.

1. Go 언어로 작성됨
   다른 대부분의 번들러들은 자바스크립트로 작성되어있다. 그 태생적 한계를 Go언어로 해결한 것이 ESBuild이다. Go언어는 간결함, 병렬성, 성능을 중시하는 언어로, 병렬성을 고려하지 않고 설계된 자바스크립트보다 훨씬 나은 성능을 뽑아낼 수 있다.
2. 병렬성
   Go언어의 강력한 병렬성을 적극 활용한 알고리즘들을 다수 활용하고 있다고 한다.
3. 자체 Parser 이용
   공식 TypeScript 컴파일러를 파서로 이용하는 다른 번들러들과는 다르게, 처음부터 성능을 염두에 두고 설계된 자체 파서를 이용한다고 한다.
4. 효율적인 메모리 사용
   데이터 접근 최소화로 메모리 액세스 횟수를 줄여 효율성을 증대시켰다고 한다.

이러한 이유들이 합쳐져 ESBuild는 다른 번들러들보다 몇배씩이나 빠른 성능을 보여준다.

CRA vs Vite

위와 같은 번들러들을 포함해 개발 서버 지원, 바벨, 린트 등의 복잡한 툴 설정을 한 번에 깔끔하게 처리해주는 빌드 툴로 CRA(Create-React-App)와 최근 각광받는 Vite가 존재한다. 이 둘을 비교해보고 우리 프로젝트에 Vite를 도입하기로 한 이유를 알아보자.

CRA

이미지 출처 - CRA 공식 홈페이지

CRA는 React 앱을 만들때 가장 쉽고 간편하게 접근할 수 있는 빌드 툴이다. 공식 문서에서 제안하는 특징들은 다음과 같다.

1. 쉬운 사용
   복잡하고 많은 빌드 툴들을 배우고 설정할 필요 없이 즉시 앱 개발에 돌입할 수 있게 해준다.CRA를 통해 빌드 도구가 아닌 코드에 집중할 수 있게 해주는 것을 강조하고 있다.
2. 하나의 의존성
   CRA를 통해 모든 요소들이 복잡한 버전 불일치 없이 원활하게 작동하는지 테스트할 수 있다.
3. No Lock-in
   CRA는 내부적으로 웹팩을 사용한다. 추가적인 설정을 원하면 CRA에서 eject를 통해 구성 파일을 직접 편집할 수 있다.

리액트를 처음 배울 때 반드시 사용하게 되는 가장 친숙한 빌드 툴이 아닐까 싶다. 간단하고, 배워야할 것이 딱히 없다시피 하다.

Vite

이미지 출처 - 위키피디아

이번 글의 주인공인 Vite("비트"로 읽는다. "바이트"가 아니다!)이다. Vite는 2020년 새롭게 출시된 빌드 툴로, 속도와 성능에 중점을 둔 차세대 프론트엔드 도구를 표방하고 있다.

Vite aims to address these issues by leveraging new advancements in the ecosystem: the availability of native ES modules in the browser, and the rise of JavaScript tools written in compile-to-native languages.
Why Vite

Vite는 브라우저에서의 네이티브 ES모듈 가용성과 네이티브 언어로 컴파일되는 JavaScript 도구의 발전 등 생태계의 새로운 진보를 활용한 느린 개발서버의 생산성 문제를 해결하는 것을 목표로 하고 있다고 한다.
즉 수천 개의 모듈이 포함되는 대규모 프로젝트에서 발생하는 성능 문제를 해결하는 것이 주된 목표라는 것이다.

실제로 웹팩을 이용하는 CRA는 이러한 대규모 프로젝트에서 개발서버를 가동하는데 몇 분(!)씩 걸리는 일도 발생한다. Vite가 어떻게 이 문제를 해결했는지는 공식문서에 잘 나와있다. 간단하게 요약하면 다음과 같다.

1. 의존성과 소스코드의 분리

   

이미지 출처 - Vite 공식 홈페이지
매 번 모든 전체 코드를 번들링하던 기존방식과 다르게, 개발 중에 자주 변경되지 않는 의존성(패키지)와 소스코드를 따로 처리한다. 의존성은 esbuild를 통해 빠르게 사전 번들링하고, 소스코드는 네이티브 ES module을 통해 처리한다.
네이티브 ES module을 중심으로 개발 서버를 구축함에 따라 매번 모든 코드를 번들링하는 것이 아닌, 필요에 따라 소스코드를 변환하고 제공할 수 있다. 이를 통해 상당히 효율적으로 모든 작업을 처리할 수 있다.
2. 비동기 청크 로딩 최적화

이미지 출처 - Vite 공식 홈페이지
빌드 시에, 모든 Direct import 구문에 대해 사전 로드를 수행함으로써 낭비되는 네트워크 왕복을 줄이도록 구성한다. 이를 통해 더 빠른 빌드를 경험할 수 있다. 위 사진의 예시에서 기존에는 A가 모두 파싱된 이후에야 C의 필요성을 알게되고 C를 요청하지만, Vite는 A를 가져올 때 C를 함께 병렬적으로 가져오도록 해주는 것이다.

이러한 방식들로 하여금 Vite는 성능상에 큰 이점을 갖고있다.

결론

아직까지 Vite 생태계보다는 웹팩을 사용하는 CRA의 생태계가 큰 것은 부정할 수 없다. 유용한 플러그인, 로더, 방대한 양의 자료와 커뮤니티를 생각하면 CRA도 매력적인 선택이지만, 우리의 프로젝트는 3D 렌더링이 주 기능이 될 예정이고, 부하를 많이 주는 작업이 다수 존재할 것으로 예상되어 성능상 이점이 있는 Vite를 사용하는 것이 개발 생산성에 있어 합리적이라고 판단했다.

Refereces

Webpack 공식 홈페이지
Rollup 공식 홈페이지
ESBuild 공식 홈페이지
CRA 공식 홈페이지
Vite 공식 홈페이지
차세대 번들러 비교 및 분석 (feat. webpack, rollup, esbuild, vite)
롤업과 웹팩의 차이점
4 Reasons Why You Should Prefer Vite Over Create-React-App (CRA)