WEB

bundler

프로일기꾼 2024. 8. 21. 00:39

webpack

  • 현재 30억 회 이상 다운로드되었을 만큼 강력한 위상을 갖고 있지만, 항상 2가지 한계가 뒤따른다.
  • 배포 환경에서 인내 가능한 선을 넘는 느린 속도 / 복잡하고 어려운 설정



Rollup.js, ESM(esmodule) 지원 번들러의 등장 - 2015

  • Rollup은 경량화와 번들 최적화를 중점에 둔 esm 모듈 번들러
  • 당시 webpack에는 없던 esm(esmodule)을 지원
    • esm 방식의 모듈 import는 의존성 파악을 하는 것이 구조적으로 명확하게 알 수 있다.
  • 번들 사이즈 경량화와 최적화에 중점을 둔 번들러
  • 현재 각광받고 있는 프론트엔드 빌드 도구인 Vite 번들의 내장 번들러로서도 사용되고 있다.



parcel, zero-configuration 번들러의 등장 - 2017

  • 'Parcel은 webpack과 Rollup에서 해야하는 복잡한 설정 없이 바로 사용할 수 있는 번들러'라는 목표로 탄생
  • zero configuration의 특징을 갖고 있어, 낮은 러닝 커브를 갖고 있음
  • 멀티 코어 처리를 활용하여 빠른 빌드 시간을 제공하고 파일 시스템 캐시를 사용하여 재빌드 시간을 단축시킴

그러나...
  • 세밀한 최적화나 커스터마이징에 한계가 존재
  • 프로젝트의 규모가 커질수록 파일 수와 의존성이 급격히 증가하여 캐시 관리와 멀티 코어 리소스를 효율적으로 사용하는데에 어려움이 있다.



esbuild, 100배 빠른 번들러의 등장 - 2020

  • esbuild 번들러는 빌드 도구 성능에 새로운 시대를 열고, 사용하기 쉬운 번들러를 만들기 위해 탄생
  • 인터프리터 언어인 javascript로 구현되어 있는 webpack과 달리, esbuild는 컴파일 언어인 Go로 구현되어 있다.
  • 그러나 아직 1.0.0 버전에 도달하지 못했다는 것, es5를 완벽히 지원하지 않는다는 것을 단점으로 꼽을 수 있다.



Snowpack, 빠른 웹 개발을 위한 프론트엔드 빌드 툴의 등장 - 2019

  • snowpack은 ESM을 활용하고 개발 서버에 중점을 둔 빌드 툴로, 번들링하지 않는 개발을 핵심 개념으로 갖고 있다.
  • 빠른 개발 서버를 구축하는 데에 중점을 두고 있다.
  • 웹팩 롤업과 같은 기존 번들러들은 코드의 수정이 발생하면 변경된 파일을 다시 빌드하고, 전체 파일에 대한 번들링을 진행
  • 그러나 snowpack은 코드의 변경이 발생할 경우 해당 파일만 리빌드하고 캐시로 갖고 있도록 구현되었다.



Vite, 빛처럼 빠른 프론트엔드 빌드 툴 등장 - 2020

  • ESM을 이용한 개발서버와 Rollup 최적화 빌드 커맨드를 제공하는 프론트엔드 빌드 툴
  • 그동안 제안된 다른 좋은 아이디어나 도구들을 재조합/통합하고, 부족했던 부분을 보완하거나 사용하기 더 편하게 개선하는 방식으로 개발된 모듈 번들러(Vite 공홈 Says, 웹 개발의 메타 프레임워크).


  • Vite는 기본적으로 Snowpack이 제시했던 패러다임과 접근 방식을 따르고 있다.
  • 기존의 번들러들이 가지고 있던 문제는 모든 소스 코드와 모듈들을 포함한 코드 베이스 전체를 하나로 번들링하고, 일련의 빌드 프로세스를 거친 다음 번들된 코드를 브라우저에 제공하는 너무 무겁고 비효율적인 작업을 한다는 것이였다.
  • 이러한 프로세스는 코드가 업데이트되면 전체 파이프라인을 처음부터 다시 거쳐야 했기에, 코드 베이스의 규모가 커질 수록 업데이트 시간도 선형적으로 증가했다.


  • 그래서 Snowpack'필요해서가 아니라 원하기 때문에 번들러를 사용할 수 있어야 한다'는 철학으로, 개발 환경에서는 번들링을 하지 않기로 한다. 이것이 가능해진 배경으로는 브라우저에서 네이티브 모듈(ECMAScript Module, ESM)을 사용할 수 있게 되었다는 점이 있다. 이 덕분에 프로덕션 빌드에서는 기존과 같이 webpack을 사용해 완성된 코드 베이스를 만들고, 개발 환경에서는 빠른 수정이 중요하였기에 번들링을 배제하고 모듈 각각을 별도로 빌드해서 수정이 발생한 파일만 업데이트하는 방식(Hot Module Replace, HMR)으로 퍼포먼스를 해결하고 하였다.


  • Snowpackd 내에서 특히 esbuild라는 도구의 도움으로 빌드 타임을 최소화하는데에 결정적인 역할을 하였다. 왜냐하면 esbuild는 Go 기반으로 개발되어 webpack에 비해 빌드 속도가 최대 100배 가량 빨랐기 때문에, 두드러진 개선이 가능했다. 그러나 esbuild는 어디까지나 빌드만 할 수 있는 도구이기에, 이외의 여러 기능들(eg, 트랜스파일링, 코드 스플리팅, 트리 쉐이킹, HMR 등..)을 제공해줄 수 있는 webpack같은 도구가 여전히 필요했다.
  • 이러한 이유로 webpack을 사용하는 것이 필수불가결한 선택지인 것처럼 보였지만,,, webpack과의 연동 과정에서 버그나 호환성 문제가 발생하는 등 다소의 불안정성이 발생하였고, 이 지점에서 ViteSnowpack을 일종의 계승/흡수하는 형태로 이어나가게 되었다. 그리고 Snowpack은 개발이 중단되고 Vite 생태계로 편입되었다. 특히 Vite는 그동안 제시된 다른 대안이었던 Rollup, Parcel과 같은 도구들까지 통합한 형태였기에 webpack의 새로운 대안이 될 수 있었다.

=> Vite는 Snowpack과 동일하게 빌드도구로 esbuild를 채택하였으며, 프로덕션 빌드에는 Rollup을 사용하여 webpack처럼 통합적인 기능을 제공하였다. HMR은 ESM으로 HTTP 캐싱을 활용해 구현하여 업데이트 속도가 매우 빠른 환경을 제공하였다. 또한 기본적으로 최적화된, 단순한 설정이 제공되어 러닝 커브에 대한 부담도 상대적으로 적었다.



Turbopack, Vite 보다 5배 빠른 Rust 기반 Webpack 후속 번들러 등장 - 2022

  • Next.js, SWC 등을 만든 vercel에서 제작한 공식 webpack 후속 번들러
  • nextjs 13 버전이 발표되면서 새로운 번들러인 turbopack이라는 도구가 함께 소개되면서 화제가 되었다.
  • vercel이 개발하였으며, rust로 개발된 번들러인 turbo를 기반으로 한 차세대 자바스크립트 모듈 번들러이다.
  • webpack의 창시자인 Tobias Koppers가 리드하는 프로젝트이다.
  • js로 개발되어 성능 상 한계를 갖고 있었던 webpack에 비해, rust로 개발된 만큼 극적인 성능 향상(특히 application의 규모가 크면 클수록)이 있다.
  • 이는 '동일한 작업을 두 번 수행하지 않는' 캐싱과 메모이제션을 활용한 아키텍처 덕분이라고 한다.
  • 기존의 번들러로 SSR 기능을 사용하는 것은 각 런타임 환경에 대해 컴파일러를 생성하고 번들을 연결하여 통신을 관리하는 것에 대한 유지 보수 비용의 부담이 존재하여, 이를 해결하고자 자체 번들 시스템을 구현하였다고 한다.
  • Turbopack은 함수 수준의 캐싱을 제공하는 터보 엔진을 구현하였다.



아래는 공식적으로 vercel에서 발표하고 있는 turbopack의 효율이다.

  • webpack 대비 700배 빠른 업데이트 속도
  • webpack 대비 4배 빠른 콜드 스타트(초기 실행 속도)
  • Vite 대비 10배 빠른 업데이트 속도
  • RSC에 대한 지원

=> 이러한 성능을 낼 수 있었던 것은 트랜스파일러인 Babel, 맹글러인 terser를 마이그레이션하고 개발에 필요한 최소한의 리소스만 번들링하는 등의 방법으로 속도를 개선했다고 한다.



그렇다면 Vite가 아닌 Turbopack을 쓰는게 좋지 않나?

  • turbopack 만이 갖는 이점이 존재하나, 아직 베타 버젼이며, vite와 비교했을 때 플러그인 생태계와 안정성 부분에 대한 차이 또한 명확히 존재하는 것이 사실이기에 production에 사용하기 위한 번들러로서는 아직 고려해야할 것이 많은 도구이다.





cf) 참고 아티클

'WEB' 카테고리의 다른 글

ESLint & Prettier  (0) 2024.08.21
Husky  (0) 2024.08.21
프론트엔드 배포 가능한 환경 목록  (0) 2024.08.20
GNB, LNB, FNB  (0) 2022.11.28
단일 장애점(Single Point of Failure, SPoF)  (0) 2022.11.08