Webpack

"webpack is a static module bundler for modern JavaScript applications."

— Webpack 공식 문서 슬로건

현대 웹 개발의 빌드 인프라를 일궈낸 전설적인 개척자이자, 보일러플레이트 없이 밑바닥부터 설정을 짜려다가는 수많은 개발자들의 머리털을 사정없이 솎아내는 무자비한 설정 복잡성 지옥의 원조. 실무에서 웹팩 설정을 능숙하게 커스텀하고 튜닝할 줄 아는 사람은 팀 내에서 '웹팩 주술사' 또는 '연금술사'로 불리며 신비로운 경외의 대상이 된다

1. 개요

Webpack은 현대 자바스크립트 애플리케이션을 위한 오픈소스 정적 모듈 번들러(Module Bundler)다. 브라우저가 아직 ES6 모듈 시스템(ESM)을 이해하지 못하던 시절, 수십 개로 쪼개진 자바스크립트 소스코드와 CSS, 이미지, 폰트 등의 에셋들을 의존성 그래프(Dependency Graph)를 그려가며 추적한 뒤, 웹 브라우저가 가장 좋아하는 몇 개의 최적화된 파일로 합치고 패키징해 주는 현대 프론트엔드 빌드 아키텍처의 초석을 닦았다.(...)

2. 웹팩을 굴리는 4대 기둥: Entry, Output, Loader, Plugin

2.1. 거대한 조립 공장의 네 가지 핵심 바퀴

웹팩은 단순한 텍스트 합치기 도구가 아니다. 일련의 정교한 가공 처리를 거치는 조립 공장에 가깝다. 이 공장을 굴리기 위한 4가지 핵심 설정 개념이 존재한다.

  1. Entry (진입점): 웹팩이 의존성 그래프를 그리기 시작할 최초의 출발 파일(보통 index.js).
  2. Output (출력): 가공이 끝난 최종 번들 파일을 어떤 이름의 파일로, 어떤 디렉터리에 뱉어낼지 지정하는 설정.
  3. Loader (로더): 자바스크립트밖에 모르는 순진한 웹팩에게 CSS, 이미지, 심지어 TypeScript나 JSX 같은 외계어(?) 파일들을 읽고 변환할 수 있는 능력을 부여해 주는 일종의 번역기 (예: css-loader, babel-loader).
  4. Plugin (플러그인): 번들링된 결과물에 대해 추가적인 가공 처리를 해주는 전역 작업반장. 코드 압축(Minify), 난독화, 환경 변수 주입 등 강력한 빌드 타임 연금술을 수행한다 (예: HtmlWebpackPlugin).(...)

이 4대 기둥의 조합을 완벽히 이해하는 것이 프론트엔드 빌드 마스터가 되는 유일한 통로이지만, 그 유연성이 너무나도 극단적인 탓에 설정 파일이 괴물처럼 비대해지는 역효과를 낳았다.

3. 설정 헬(Config Hell)과 번들링 속도의 한계

3.1. 개발자를 미치게 만드는 웹팩 주술

웹팩의 악명 높은 별명은 단연 '설정 헬(Configuration Hell)'이다. 프로젝트 규모가 커지면 빌드 성능을 올리기 위해 트리 셰이킹(Tree Shaking), 코드 스플리팅(Code Splitting), 해싱(Hashing), 캐싱 설정을 덧붙여야 한다. 이 과정에서 각 패키지와 로더의 버전 호환성이 꼬여 수백 줄의 에러 로그를 뿜어대기 일쑤며, 어설프게 설정을 고쳤다가는 브라우저 화면이 하얗게 변하는 백화 현상을 겪게 된다.1

3.2. 느려지는 빌드, 세대교체의 서막

또한 웹팩은 소스코드를 수정할 때마다 전체 의존성 그래프를 다시 그리거나 메모리에 무거운 가상 모듈을 빌드하는 방식을 취한다. 프로젝트의 소스 파일이 수천 장을 넘어가면, 로컬 개발 서버를 한 번 띄우는 데 30초에서 1분이 넘게 걸리고, 코드 한 줄 고칠 때마다 핫 모듈 리플레이스먼트(HMR)가 몇 초씩 걸리는 기형적인 현상이 벌어졌다.

이러한 무거움과 비대함은 결국 2020년대 들어 Esbuild와 Rollup을 무기로 들고 나온 Vite 같은 초고속 차세대 빌드 도구들에게 왕좌를 넘겨주게 되는 역사적 단초를 제공했다.2

4. 관련 밈 및 드립

4.1. Webpack Config 주술사 (The Webpack Wizard)

회사나 오픈소스 프로젝트에서 아무도 감히 건드리지 못하는 영역인 'webpack.config.js'를 홀로 다스리는 사람을 부르는 경외와 해학의 밈.

수년 동안 온갖 레거시 라이브러리와 복잡한 플러그인 세팅이 층층이 쌓여 거대한 고대 유적처럼 변해버린 웹팩 설정 파일은, 자칫 오타 하나라도 내는 순간 전체 빌드 파이프라인이 즉사하는 저주가 걸려 있다. 이 저주를 풀고 빌드 경량화에 성공한 시니어 개발자는 팀 내에서 거의 종교적인 숭배를 받으며, '제발 웹팩 파일을 건드리지 말고 밤새 기도나 하자'는 자조적인 짤방이 널리 돌아다닌다.(...)

5. 여담

  • CRA의 안락한 감옥: 과거 리액트 입문자들의 절대적인 사랑을 받았던 Create React App(CRA)은, 사실 베일 뒤에 수백 줄짜리 웹팩 설정을 꽁꽁 감춰두고 개발자들을 보호하던 시스템이다. 여기에 숨겨진 웹팩 설정을 직접 뜯어고치기 위해 npm run eject를 실행하는 행위는, 평화롭던 매트릭스 세계를 탈출해 진짜 지옥을 마주하는 빨간 약으로 묘사되곤 했다.
  • 토비아스 코퍼스의 마이크로소프트행: 웹팩의 창시자 토비아스 코퍼스는 오랜 시간 동안 막대한 인프라 기여에 비해 턱없이 부족한 후원금에 시달리며 눈물겹게 오픈소스를 유지해 오다, 2020년 마이크로소프트에 정식 입사하여 전폭적인 지원을 받으며 웹팩 개발에 전념하게 되었다.
  • Next.js와의 밀월과 Turbopack: 리액트 프레임워크의 대세인 Next.js는 오랫동안 내부 빌더로 웹팩을 사랑해 왔으나, 웹팩의 속도적 한계를 극복하기 위해 최근 Rust 언어로 밑바닥부터 다시 짠 초고속 후속작 Turbopack을 개발하여 웹팩 생태계의 자연스러운 세대교체를 준비하고 있다.(...)

6. 관련 문서

각주

  1. 실제로 소스맵(Source Map) 설정이나 압축 플러그인(Terser) 세팅이 미세하게 꼬이면, 에러가 발생한 소스코드의 실제 위치를 브라우저 디버거가 전혀 짚어내지 못해 디버깅 난이도가 수직 상승한다.

  2. 그럼에도 불구하고 웹팩은 지난 10년간 축적된 수천 개의 플러그인 생태계와 안정적인 레거시 지원이라는 압도적 해자를 가지고 있어, 여전히 대다수 금융권이나 대기업의 엔터프라이즈 프로젝트에서는 든든한 대들보로 사용 중이다.