이력서와 포트폴리오를 구성하며, 채용 공고에서 자주 확인할 수 있는 '빌드' 란을 확인하였다.
위와 같은 형태로 빌드 과정에서 사용하는 번들러에 대한 정보를 제공하는데, 정작 프로젝트를 진행하면서 번들러를 설치하거나 특정 목적을 가지고 변경해본 경험이 없어, 제대로 이해하지 못하고 있었다.
오늘은 번들러에 대한 정보와 언제 사용하는지에 대해서 알아보고자 한다.
Bundle
: 꾸러미, 묶음, 보따리등의 의미
번들러(Bundler)는 여러 파일로 나눠져있는 자바스크립트 파일 (.js)
을 번들이라는 말 그대로 하나로 합치는 역할을 수행하는 도구이다.
과거에는 브라우저(Browser)에서 ES Modules
를 지원하지 않았기 때문에 자바스크립트 파일이 나눠져있는 것을 읽을 수 없었다. 이 때문에 번들링(Bundling)
하나의 파일로 코드를 모두 병합하는 번들링이 필요했다.
ES6
부터는 export
와 import
문을 사용하여 분리된 자바스크립트 파일끼리도 접근이 가능하게 되었기 때문에 <script type="module">
태그와 같이 로드가 가능해졌다.
"그럼 이제 번들러는 필요 없는거 아닌가?"
그럼에도 불구하고, 위와 같이 쓰는 방식에는 많은 제약이 있고, 일부 브라우저에서는 지원하지 않을 수도 있다.
위와 같은 전통적인 이유 외에도 번들러를 쓰는 이유들은 아래와 같다.
또한, 과거와 달리 현재 웹 애플리케이션에서는 많은 외부 라이브러리
와 모듈
들을 사용하고 있기 때문에, 의존성 관리가 필요하다.
번들러는 의존성 관리를 위해 모듈을 분석하고, 최적의 순서로 파일을 결합하여 합리적으로 의존성을 해결한다.
코드 스플리팅
번들러는 필요할 때에만 코드를 로드할 수 있도록 청크를 나누어 로드 시간을 줄여준다.
이는 초기 로딩 속도를 개선하고 사용자가 느끼는 성능을 향상시키는 효과를 가져올 수 있다.
트리 쉐이킹
사용되지 않는 코드를 제거하여 최종 번들의 크기를 줄이는 등, 불필요한 자원의 로드를 방지하며 성능을 향상시킨다.
애셋 최적화
이미지, 폰트 등의 애셋 파일 크기를 줄여, 로딩 시간을 단축시킬 수 있다.
캐싱
적절한 캐싱 설정을 통해 변경되지 않는 정보에 대해서 브라우저가 재사용할 수 있도록 하는 방식을 사용하기도 한다.
최근의 다양한 번들러들은 최신 자바스크립트 문법을 구 버전의 브라우저에서도 동작할 수 있도록 코드를 변환하기도 한다.
이는 Babel과 같이 소스 코드를 다른 프로그래밍 언어로 변환해주는 트랜스파일러(Transpiler)
형태의 번들러와 함께 동작한다. 최신 형태의 ES6+
코드를 ES5
로 변환하는 등 호환성을 유지하는데 도움을 준다.
이렇듯 번들러는 현대의 개발 과정에서 다양한 목적에 사용되고 있다.
이쯤 되면 의문점이 생긴다.
"기존에 개발했던 프로젝트에서는 어떻게 번들러 설정 없이도 정상적인 빌드가 되었을까?"
Next.js 공식 문서에 따르면, Next.js 12 버전 이상 부터는 기본 트랜스파일러로 SWC를 사용하고 있음을 알 수 있다.
프로젝트 내부의 yarn.lock
파일을 확인해보면, 위와 같이 SWC로 구성된 트랜스파일러를 확인할 수 있다.
또한, Next.js는 기본 번들러로 webpack을 사용하고 있다. next.config.js
에서 webpack을 커스터마이징 할 수 있으며, 아래와 같은 형태를 종종 볼 수 있다.
module.exports = {
webpack: (config, { buildId, dev, isServer, defaultLoaders, webpack }) => {
// 여기서 config는 기본 Webpack 설정입니다.
// Webpack 설정을 커스터마이징한 경우 이 부분에서 확인할 수 있습니다.
return config;
},
};
위와 같이 웹팩 설정을 따로 하지 않아도, Next.js 프로젝트의 yarn.lock
파일에 webpack이 포함되어있는 모습을 확인할 수 있다.
npm 트렌드에서 bundler라고 검색한 이후, 자동완성되는 번들러들을 확인해보았다.
webpack
이 압도적이라고 하나, 최근에는 ESBuild
또한 많은 영향력을 끼치고 있는 것으로 보인다.
Go
언어로 작성되어, 웹팩보다 100배 빠르다는 점을 감안하면 트렌드가 바뀌고 있는 것 같다.
번들러의 종류와 내용에 대해 정말 잘 정리된 글이 있어 첨부한다.
[Bundler] JavaScript 번들러 그리고 Webpack , Parcel , Rollup , Vite... (2)
해당 글의 정리 부분을 인용하자면, 아래와 같다.
webpack
광범위한 개발 레퍼런스를 활용하고 많은 서드파티를 필요로 하는 복잡한 어플리케이션이라면.
rollup
ES6 모듈 형식으로 빌드 결과물을 출력하여 라이브러리나 패키지에 활용하고 싶다면. 트리 쉐이킹과 같이 효율성을 고려해야 하는 프로젝트라면.
vite
SPA를 생성하기 위한 Vue CLI/CRA를 대체할 거리를 찾고있다면.
parcel
복잡한 설정을 피하고 간단한 애플리케이션을 만들고 싶다면.
오늘은 번들러의 이론적인 부분만 확인하여, 빌드 시간이나 결과물의 차이를 체감하지는 못하고 있다.
이후에 프로젝트 빌드 시간을 줄이고, bundle-analyzer
와 같은 도구를 사용하여 어떤 차이가 있고, 얼마나 최적화할 수 있는지 실험하는 과정을 가져봐도 재미있는 시간이 될 것 같다.
[Javascript] ES Module
번들러(Bundler)란?
프론트엔드 개발에서의 번들러의 역할과 최적화 전략