웹 개발에서 이해하는 번들러

2022년 가장 핫했던 번들러는 무엇이였을까요?

js에서 번들러하면 빼놓을 수 없는게 webpack 입니다. React프로젝트를 하면서 CRA를 입력했을때 나오는것도 webpack 이죠. 하지만 이 webpack 다들 만족하면서 사용하시나요?

stateofjs 에서 build-tools 에 대해 조사한 결과가 있습니다. 만족도에 대한 내용인데 놀랍게도 webpack 은 바닥에 있었습니다..

https://2022.stateofjs.com/ko-KR/libraries/build-tools/

17년도만 해도 95%의 모습을 보여주던 webpack 이 어쩌다 이렇게까지 만족도가 떨어지게 되었을까요? 그리고, vite와 esbuild는 왜 이렇게 만족도가 높을까요?

모듈 번들러

우선 내용을 파악하기 전 모듈 번들러가 무엇인지부터 알고 가는게 좋을 것 같습니다.

지피티 선생님은 Module Bundler란

여러 모듈로 나누어진 소스 코드를 하나로 묶어주는 도구로, 웹 애플리케이션의 구조를 효과적으로 관리하고 로딩 성능을 최적화하는 역할을 한다.

라고 정의해주셨습니다. 이름 그대로인 것이죠.

웹 개발에서는 js파일, css 파일 등 여러 리소스를 하나로 합쳐서 단일 파일을 만드는 것이 번들러의 역할입니다. 이렇게 합쳐진 하나의 파일을 로드하면서 웹 사이트는 동작하게 됩니다.

Webpack

Webpack은 모듈 번들러로서, 웹 애플리케이션을 개발할 때 여러 개의 파일로 나뉜 소스 코드를 하나의 번들로 묶어주는 도구입니다.

2018년 webpack 은 v4로 릴리즈 되었고, 당시 다양한 SPA가 급부상하게 되면서 “대웹팩시대”가 열리게 되었습니다.

직관적인 설정

webpack 의 설정은 매우 직관적입니다. entry와 output을 명시하고, 어떤 loader, plugin을 사용할 것인지 명시해주면 됩니다.

기본 구성 파일 생성 (webpack.config.js):

Webpack 설정 파일을 생성하여 진행합니다. 이 파일에는 entry, output, loader, plugin 등의 설정이 들어갑니다.

진입점(entry) 설정:

웹팩은 어디에서부터 번들링을 시작할지를 알아야 합니다. 이를 entry 속성을 통해 설정합니다.


module.exports = {
  entry: './src/index.js',
  // ...
};

번들 결과물(output) 설정:

번들된 파일의 경로와 이름을 설정합니다.


module.exports = {
  // ...
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'bundle.js',
  },
};

로더 및 플러그인 설정:

필요한 로더와 플러그인을 설정하여 각종 파일을 처리하고 최적화합니다.

빌드 실행:

설정이 완료되면 명령어를 통해 빌드를 실행합니다.


npx webpack

이러한 단계를 거치면 지정한 진입점에서 시작하여 모든 의존성을 포함한 번들이 생성됩니다. 번들은 설정한 출력 경로에 저장되어 사용됩니다.

webpack은 만족도에 비해 사용량은 압도적으로 1등입니다. 그렇다는 것은 커뮤니티가 활성화 되어있고, 많은 레퍼런스를 확인할 수 있다는 것이죠.

그렇지만 만족도 측면에서는 상당히 좋지 않은 것을 확인할 수 있습니다. 왜 그럴까요? 그 이유는 크게 2가지로 예상할 수 있습니다.

강력한 기능을 가졌지만 학습 곡선이 다소 높다.

큰 프로젝트의 경우 초기 빌드 시간이 길 수 있다.

별거 아닌 것 같지만, 2번의 경우 다른 번들러를 사용하면서 체감할 수 있습니다. 바로 만족도 1등과 2등인 vite와 esbuild로 말이죠.

esbuild

webpack은 기본적으로 javascript를 기반으로 번들링을 합니다. 그렇기 때문에 javascript 언어의 성능상 한계를 가지고 있죠. 그 문제를 해결하기 위해 esbuild가 등장했습니다.

esbuild는 go로 작성되었고 js 기반의 번들러보다 최대 100배까지 빠른 퍼포먼스를 보여줍니다.

webpack5와 비교했을때 비교할 수 없을 정도로 빠르다는 것을 알 수 있습니다. 추가적으로

캐시가 필요 없는 최고의 속도

JavaScript, CSS, TypeScript 및 JSX 내장

CLI, JS, Go를 위한 간단한 API

ESM 및 CommonJS 모듈 번들

CSS 모듈을 포함한 CSS 번들

트리 쉐이킹, 축소 및 소스 맵

로컬 서버, 감시 모드 및 플로그인

을 지원한다고 합니다. (https://esbuild.github.io/ 공식 사이트 참고..)

그럼 여기서 갖는 의문.. 왜 사람들은 webpack 에서 esbuild로 갈아타지 않는 것일까?

그것은 아직도 esbuild는 정식 릴리즈가 나오지 않고 있습니다. 물론, 상당히 많은 부분의 기능을 제공합니다. 실무에서 사용해도 괜찮을 정도의 기능들이죠, 하지만 아직 안정성 관련 이슈가 있습니다.

vite

사실 vite를 번들러로 봐야하는지에 대해 의문을 가지고 있었습니다. vite는 esbuild로 파일을 통합하고, rollup을 통해 번들링하는 녀석이기 때문이죠.

하지만 가져온 이유는 vite가 esbuild의 단점을 커버쳐줄 수 있다는 측면에서 번들러로서 역할을 한다 생각해서 가져오게 되었습니다.

공식문서 (Vite를 사용해야 하는 이유) 를 통해 vite에 대해 더 이해할 수 있을 것입니다. vite는 개발 구동 시간이 거의 없다 싶을 정도로 매우 빠릅니다.

또한 esbuild와 다르게 css 빌드에도 최적화 되어있죠. esbuild의 단점중에 아직 css 빌드가 완벽하지 않다는 것이 있었으나, vite는 해소된 것 같습니다.

그렇기 때문에 요즘 많이 vite를 사용하고 있는 추세인 것 같습니다. 실제로 사용량도 webpack, gulp 뒤에 바로 vite가 있을 정도입니다.

지금의 회사에서도 vite로 옮긴 프로젝트가 하나 있습니다. 로컬 개발 서버가 정말 빠르게 동작하고 아직까진 만족하면서 사용하고 있습니다.

“대웹팩시대”가 도래한 만큼 아직까진 실 사용 측면에선 webpack 을 이길 번들러가 없을 것 같다는 생각입니다. 정말 많은 레퍼런스가 있고, 러닝 커브가 있어도 직관적인 설정만 할 줄 알아도 커버가 가능한 수준이기 때문이죠.

하지만 점점 웹팩을 다룰 일이 생기다 보니.. 전문적인 지식이 필요하게 되고 그렇게 점점 벽을 느끼고 있습니다. msw 작업하면서 webpack 과 babel 을 직접 건들이면서 설정했었는데. 정말 너무너무 힘들었던 경험이였습니다.

그렇기 때문에 좀 더 vite, esbuild와 같은 차세대 번들러들이 좀 더 성장한다면 사용적인 측면에서도, 속도 측면에서도 정말 유용하게 개발에만 몰두할 수 있지 않을까 생각합니다.

감사합니다.