자바스크립트 번들이 뚱뚱해지는 세 가지 근본 원인

번들 크기, 왜 계속 문제가 되는가

프론트엔드 개발자라면 누구나 한 번쯤 번들 분석기를 열어보고 경악한 경험이 있을 겁니다. 분명 간단한 기능만 만들었는데 번들 크기는 수 MB를 넘어가고, 사용자가 첫 화면을 보기까지 수 초가 걸립니다. 이 글에서 다루는 "자바스크립트 비대화의 세 기둥(Three Pillars of JavaScript Bloat)"은 이 문제의 구조적 원인을 정리한 분석입니다.

자바스크립트 번들 크기가 중요한 이유부터 짚어봅시다. 브라우저는 JS 파일을 다운로드한 후 파싱하고, 컴파일하고, 실행해야 합니다. CSS나 이미지와 달리 JS는 메인 스레드를 블로킹할 수 있어서, 번들이 클수록 사용자 인터랙션이 지연됩니다. 특히 모바일 환경에서는 네트워크 속도뿐 아니라 CPU 파싱 비용도 무시할 수 없습니다. 같은 1MB 파일이라도 이미지 1MB와 JS 1MB는 성능에 미치는 영향이 완전히 다릅니다.

첫 번째 기둥: 불필요한 폴리필과 트랜스파일링

첫 번째 원인은 이미 대부분의 브라우저가 지원하는 기능에 대해 여전히 폴리필을 포함시키는 관행입니다. ES2015 문법이 나온 지 10년이 넘었지만, 많은 프로젝트의 빌드 설정은 여전히 IE11이나 오래된 브라우저를 타겟으로 트랜스파일링합니다. Babel 설정에서 targets를 제대로 지정하지 않으면, async/await 같은 네이티브 문법을 regenerator-runtime으로 변환하면서 수십 KB가 추가됩니다.

이것은 단순한 설정 문제가 아닙니다. core-js 같은 폴리필 라이브러리는 전체를 포함하면 수백 KB에 달합니다. browserslist 설정을 현실적으로 관리하고, 실제 사용자의 브라우저 분포를 확인한 후 불필요한 폴리필을 제거하는 것만으로도 상당한 크기 절감이 가능합니다. 하지만 많은 팀이 "혹시 모르니까" 보수적으로 설정하고 잊어버리는 경우가 많습니다.

두 번째 기둥: 무분별한 의존성 추가

npm 생태계의 편리함은 양날의 검입니다. 간단한 유틸리티 함수 하나를 위해 거대한 라이브러리를 통째로 설치하는 패턴이 만연합니다. 대표적인 예가 lodash입니다. _.get() 하나를 쓰기 위해 lodash 전체를 import하면 70KB 이상이 번들에 포함됩니다. lodash-es를 사용하고 tree-shaking을 활용하면 줄일 수 있지만, 많은 프로젝트에서 이조차 제대로 설정되어 있지 않습니다.

더 근본적인 문제는 "직접 구현하면 버그가 생길 수 있으니 라이브러리를 쓰자"는 문화입니다. 물론 복잡한 로직(날짜 처리, 암호화 등)은 검증된 라이브러리를 쓰는 것이 맞습니다. 하지만 배열에서 유니크한 값을 추출하거나 객체를 딥클론하는 정도의 작업까지 외부 의존성을 추가할 필요가 있을까요? JavaScript의 네이티브 API(structuredClone, Set, Array.prototype.at 등)가 상당히 풍부해진 지금, 의존성을 추가하기 전에 네이티브로 해결 가능한지 먼저 확인하는 습관이 필요합니다.

패키지의 의존성 트리도 문제입니다. 내가 설치한 패키지 하나가 내부적으로 10개의 다른 패키지에 의존하고, 그 중 일부는 중복되거나 더 이상 관리되지 않는 경우도 흔합니다. npm ls나 번들 분석 도구로 실제 번들에 무엇이 포함되는지 정기적으로 점검하는 것이 좋습니다.

세 번째 기둥: 프레임워크 런타임의 비용

세 번째 원인은 프레임워크 자체의 런타임 크기입니다. React만 해도 react + react-dom의 minified gzip 크기가 약 40KB입니다. 여기에 상태 관리 라이브러리, 라우터, UI 컴포넌트 라이브러리를 추가하면 프레임워크 레이어만으로 수백 KB가 됩니다.

이 영역에서 최근 주목할 만한 흐름은 "제로 런타임" 또는 "최소 런타임" 프레임워크의 부상입니다. Svelte는 컴파일 타임에 대부분의 작업을 처리해서 런타임 코드를 최소화하고, Astro는 기본적으로 JS를 전송하지 않다가 필요한 부분만 하이드레이션합니다. Qwik은 resumability라는 개념으로 초기 JS 로드를 거의 제로에 가깝게 줄입니다. 이런 프레임워크들이 나오는 것 자체가 "JS 비대화"가 얼마나 심각한 업계 문제인지를 보여줍니다.

한국 개발자에게 주는 시사점

한국은 모바일 트래픽 비중이 매우 높고, 특히 커머스나 핀테크 서비스에서 초기 로딩 속도가 사용자 이탈률에 직접적인 영향을 미칩니다. Core Web Vitals 점수가 검색 순위에도 영향을 주는 상황에서 번들 최적화는 선택이 아니라 필수입니다.

당장 실무에서 할 수 있는 것들로는, 첫째 npx browserslist로 현재 프로젝트의 타겟 브라우저를 확인하고 불필요하게 낮은 버전을 제거하는 것, 둘째 webpack-bundle-analyzer나 source-map-explorer로 번들 구성을 시각화해보는 것, 셋째 import 구문을 점검해서 tree-shaking이 제대로 동작하는지 확인하는 것이 있습니다.