Webpack 빌드에 날개를 달아줄 Esbuild-Loader

Webpack 의 Babel-Loader 를 Esbuild-Loader 로 바꿔 빌드 시간을 얼마나 줄일 수 있는지 상황별로 실측한 글이다. 개발 서버 최초 컴파일, HMR 리빌드, 로컬 프로덕션 빌드, CI 빌드 네 가지를 나눠 비교한다.

핵심 포인트

웹팩은 소스 한 줄만 고쳐도 엔트리부터 의존성 그래프를 다시 구성해 전체를 리빌드하며, 그 과정에서 모든 JS 가 Babel-Loader 전처리를 다시 거친다.
번들링 방식 자체를 바꾸기 어렵다면 전처리 시간을 줄이는 것이 대안이라는 것이 글의 출발점이다.
Esbuild-Loader 는 Webpack 빌드의 Transpilation 과 Minification 단계에 더 빠른 대안을 제공한다고 스스로 소개한다.
프로덕션 빌드의 상대적 차이가 개발 빌드보다 훨씬 컸는데, 두 상황의 변인은 Minify 절차 유무다. 즉 Minify 도 전체 빌드 타임에서 큰 몫을 차지한다.
결론은 많게는 3배 이상의 시간 절약이며, 핸들링하기 어려운 사이드이펙트가 없다면 교체를 권한다.

상세 정리

배경 설명: 웹팩은 기본적으로 자바스크립트만 처리할 수 있고 HTML·CSS·이미지·폰트를 모듈로 다루려면 전처리기가 필요한데 그 역할이 로더다.
Babel 이 필요한 이유는 모든 브라우저가 최신 ECMAScript 스펙을 지원하지 못해 소스를 트랜스파일해야 하기 때문이다.
측정 방법의 한계를 솔직히 밝힌다. 로더·플러그인별 처리 시간을 재는 라이브러리를 쓰려 했으나 웹팩 5 이상에서 구동이 어려워, 설정에서 로더만 바꾸고 빌드 시 기본 출력되는 컴파일 완료 시간을 수집했다.
절대 시간은 프로젝트 규모와 하드웨어에 의존하므로 의미를 두지 말고, 두 로더의 상대 비교만 보라고 미리 못 박는다.
비교 항목 넷: 개발 서버 구동을 위한 최초 컴파일, HMR 동작을 위한 리빌드, 로컬 머신에서의 빌드 명령, GitHub Actions CI 환경에서의 빌드.
프로덕션 빌드는 Terser 를 쓰는 구성과 Esbuild 의 Minify 를 쓰는 구성을 나눠 진행했다.
왜 빠른가 ①: Esbuild 는 Go 로 작성됐다. 자바스크립트는 인터프리터 언어라 실행 시점에 한 줄씩 기계어로 변환하지만, Go 는 컴파일 단계에서 미리 변환해 둔다.
왜 빠른가 ②: 싱글 스레드인 자바스크립트는 한 번에 한 파일씩 순차 처리해야 하지만, Go 는 공유 메모리 환경에서 멀티 스레드로 동작해 여러 파일을 동시에 번들링·트랜스파일할 수 있다.
다만 현재는 웹팩의 로더 형태로만 쓰고 있어 Transpile 과 Minify 절차만 위임하고 있다는 단서를 붙인다.
실행 근거로 전체 빌드 로그 링크를 함께 공개한다.
권유의 톤도 신중하다. 모듈 번들러를 통째로 교체하는 것은 수정 범위가 크지만, 같은 번들러 안에서 로더·플러그인만 바꿔 테스트하는 것은 작업 비용 대비 효과가 크다고 정리한다.