Storybook 빌더 비교 (Vite, Webpack)

최근까지 Storybook 6 버전을 사용하다가 7 버전 마이그레이션을 살펴보던 도중, Vite 또한 스토리북의 빌더로 사용이 가능한 것을 알게 되었습니다. Vite가 빠르고 사용하기 편하다, 등의 이야기는 많이 접하고 있었는데, 구체적으로 어떤 면에서 유리한지를 스토리북, Vite의 공식문서를 보면서 가볍게 정리해 보았습니다.

Vite

Vite

Vite는 개발 서버 시작 속도를 개선한 바가 있는데, 이는 의존성과 소스코드를 분리하기 때문이라고 합니다.

• 의존성 - esbuild를 이용하여 사전에 번들링 합니다. esbuild는 Go로 작성되어 있어 JS 기반의 번들러보다 속도 면에서 유리합니다.
• 소스코드 - 브라우저가 번들러의 역할을 대신하는 느낌으로, 요청이 있는 경우에만 코드를 변환하여 제공합니다.
• HMR - 매번 수정이 생길 때마다 개발 서버를 완전히 다시 빌드하면 비용이 많이 들기 때문에 HMR을 지원하는 번들러가 많습니다. Vite는 수정이 발생한 부분의 모듈에 대해서만 재연결을 시도하기 때문에 앱의 크기와 상관없이 속도가 일정하게 빠릅니다.
• HTTP header - 304 Not Modified와 캐시를 이용하여 불필요한 요청, 응답 작업을 줄이고 있습니다.

Storybook Vite vs Webpack

Storybook Performance: Vite vs Webpack

스토리북에서는 기존 webpack 방식의 빌드와 vite의 빌드 퍼포먼스를 비교하였는데, 글을 간단하게 요약하면 이렇습니다.

• cold start - 사전 세팅이나 설정 없이 완전 바닥부터 시작하는 걸 의미로 원래는 자동차 엔진이 예열되지 않은 상태로 차량이 시동이 걸리는 것을 서버에 비유한 것입니다. 스토리북은 빌더 성능을 테스트하기 위해 개발 서버를 cold start 했다고 합니다.
• 개발 서버의 실행 자체는 Vite가 빠르지만 첫 페이지 로드가 느리다고 합니다. Vite는 모든 모듈을 번들하지 않고 전송하기 때문에 서버 자체는 빠르게 실행되지만 브라우저가 요청을 모두 처리하는 데는 더 오래 걸리기 때문에 최종적으로 사용자가 페이지를 보는 데까지는 시간이 더 걸립니다.
• 전반적으로 Vite가 Rollup 기반으로 tree shaking 등도 엄격하게 진행하기 때문에 build, load 등이 더욱 오래 걸립니다.
• HMR은 Vite 가 훨씬 빠르지만, 웹팩에서도 lazy compilation을 적용하면 거의 비슷한 속도가 난다고 합니다. Vite 또한 코드 스플리팅을 잘 적용해 줘야 HMR의 퍼포먼스를 더욱 높일 수 있습니다.

결론

Vite가 사용법이 간단하고 웹팩에 비해 최신 번들러이지만, 빌더 선택 시 반드시 Vite가 정답은 아니라고 느껴집니다. 프로젝트의 형태나 크기, 사용자가 개발 서버에서 중점으로 두는 기능이 어떤 점인지에 따라 아직까지도 웹팩이 더 우위에 있는 부분도 분명 존재합니다. Vite가 최신 기술이기에 당연히 유리한 부분이 많다고 생각하여 막연히 교체하려던 중 알아보게 되었는데, 기술 선정은 항상 철저한 비교를 통해 장단점을 명확히 알고 진행해야겠다는 생각이 많이 들었습니다.