[Vite] Code Splitting 전략 - 번들 크기 최적화하기(manualChunks)

[Vite] Code Splitting 전략 - 번들 크기 최적화하기(manualChunks)

📖 들어가며

웹 애플리케이션이 커질수록 번들 크기도 함께 커지게 됩니다. 이는 초기 로딩 시간에 직접적인 영향을 미치죠.

Vite에서 제공하는 Code Splitting 기능을 활용하면 이 문제를 효과적으로 해결할 수 있습니다.

 

해당 글에서는 manualChunks에 대해서만 다룹니다.

왜 Code Splitting이 필요할까?

웹 애플리케이션을 빌드하면 모든 Javascript 코드가 하나의 큰 파일로 번들링 됩니다.

하지만 이 상황은 아래 문제들을 일으킬 수 있습니다.

• 긴 초기 로딩 시간: 사용자가 첫 페이지를 보기 전에 모든 코드를 다운로드해야 합니다.
• 불필요한 리소스 낭비: 당장 필요하지 않은 코드도 함께 불러옵니다.
• 비효율적인 캐싱: 작은 코드 변경에도 전체 번들을 다시 다운로드해야 합니다.
• 메모리 사용량 증가: 불필요한 코드까지 메모리에 로드됩니다.

이러한 문제를 해결하기 위해 코드를 적절히 분할할 필요가 있습니다. 특히

• 자주 변경되는 코드와 그렇지 않은 코드를 분리
• 특정 페이지에서만 필요한 코드는 해당 페이지 접속 시에만 불러올 수 있도록.
• 큰 라이브러리들은 별도의 청크로 분리

등 프로젝트 상황에 맞게 기준을 세우는 것이 중요합니다.

그래서 나는 왜 manualChunks가 필요했는가?

이미 프로젝트에 lazy Loading, Dynamic Import 기법 등 필요한 부분에 대해서 적용된 상태였습니다만..

manualChunks 설정 적용 전 build 결과물

위 이미지는 build 된 파일들의 결과입니다.

 

젤 하단의 index.js를 보시면 용량이 3MB 초과한 것을 볼 수 있습니다.

 

제가 담당한 프로젝트 특성상 한 페이지에 많은 기능을 담당할 수밖에 없는 구조이고, 제일 많은 기능을 담당하는 페이지이긴 했으나,

불필요하게 용량이 크다고 생각했습니다.

 

이렇게 되면 위에서 언급한 문제들을 겪는 상황을 맞이하게 됩니다.

manualChunks란?

manualChunks는 Vite(실제로는 Rollup)에서 제공하는 코드 분할 기능입니다.

빌드 시점에 어떤 모듈들을 하나의 청크로 묶을지 직접 제어할 수 있게 해 주죠.

 

예를 들어, 다음과 같은 상황을 생각해 봅시다.

• React와 관련 라이브러리들이 하나의 파일로
• UI 컴포넌트 라이브러리들이 또 다른 파일로
• 용량이 크고 잘 변하지 않는 외부 라이브러리를 다른 파일로
• 나머지 node_modules가 별도의 파일로

이렇게 코드를 분리하고 싶다면 manualChunks를 사용하면 됩니다.

 

기본적인 설정 방법은 아래와 같습니다. 매우 간단합니다.

// vite.config.js
export default defineConfig({
  build: {
    rollupOptions: {
      output: {
       manualChunks(id) {
        if (id.includes('node_modules')) {
          return 'vendor';
        }
      }
    }
  }
})

현재 프로젝트에 위와 같이 설정을 하고 build를 하게 되면 결과는 어떻게 될까요?

node_modules가 포함하고 있는 것들은 vender.js에 모두 포함되었습니다!

기존에 제일 큰 용량을 차지하던 index.js의 크기는 이전 보다 약 71%가 감소되었습니다.

 

라이브러리를 떼어내서 index.js의 용량 자체는 개선되었으나, 다른 문제가 또 있습니다.

node_modules가 포함하고 있는 것들에 대해서 하나의 파일로 묶어 버리게 되면, 만약 외부 라이브러리가 하나 수정되고 build를 하게 되면 vendor.js가 새롭게 생성됩니다.

이렇게 되면 사용자 입장에서 큰 용량을 가지고 있는 vendor.js에 대해서 새롭게 다운로드를 하게 되겠죠.

즉, 작은 변경에도 큰 파일을 다운로드하게 되는 상황입니다.

당장 필요하지 않은 라이브러리도 처음부터 로드되고, 캐시 활용 효율이 떨어질 수 있습니다.

개선된 Code Splitting 전략

그럼 어떻게 조금 더 개선할 수 있을까요?

더 세밀한 제어가 필요하다면, 라이브러리의 특성에 따라 chunks를 나눌 수 있습니다.

즉, 단순히 node_modules만 분리하는 것이 아닌, 라이브러리 별로 분리하는 것입니다.

 

여기서부터는 프로젝트 특성에 맞춰서 기준을 잘 세워야 합니다.

저는 그래서 우선 vite-bundle-visualizer 를 이용하여 용량이 상대적으로 크고 잘 변하지 않는 라이브러리부터 분리를 해봤습니다. 

• pdf 관련 기능을 담당하는 라이브러리
• lottie 관련 라이브러리

가 용량을 크게 차지하더라고요.

그리고, 이 라이브러리들을 업데이트하는 등의 상황이 거의 일어나지 않아서 우선 적용해 보았습니다.

추가 설정 후 build 결과물

기존 매우 큰 vendor에 대해서도 청크 분할이 되었습니다.

약 2MB 정도 감소되었네요.

 

이렇게 함으로써 예를 들어, pdf가 필요한 상황에만 해당 라이브러리를 불러와서 사용할 수 있게 되었습니다.

 

여기서 추가로 React 의존성만 묶는다던지, UI 관련 라이브러리만 묶는 등의 기준을 세울 수 있겠죠?

 

이 방식에도 주의할 점이 몇 가지 있습니다.

1. 청크가 많아질수록 병렬 HTTP 요청도 증가합니다.
2. 네트워크 상태가 좋지 않은 환경에서는 오히려 성능이 저하될 수 있습니다.

그래서 위에서 말씀드린 것처럼, 기준을 명확하게 세우고 청크 구성을 신중하게 설계해야 합니다.

 

한번 정리를 해볼까요?

아래는 예시입니다.

manualChunks를 전혀 사용하지 않았을 때:

build/
  └── index.12345.js     # 모든 코드가 하나의 파일 (애플리케이션 코드 + 라이브러리 전체) (7,200kb | gzip: 2,100kb)

단순히 node_modules만 분리했을 때:

build/
  ├── index.1234.js      # 애플리케이션 코드 (920kb | gzip: 268kb)
  └── vendor.5678.js     # 모든 node_modules 라이브러리 (4,994kb | gzip: 1,448kb)

라이브러리별로 분리했을 때:

build/
  ├── index.1234.js       # 애플리케이션 코드 (920kb | gzip: 268kb)
  ├── lottie-lib.abc.js   # lottie 관련 (600kb | gzip: 150kb)
  ├── pdf-lib.def.js     # PDF 관련 (1,000kb | gzip: 343kb)
  └── common-vendor.ghi.js  # 기타 라이브러리 (3,000kb | gzip: 1,000kb)
  └── ...  # 기타 파일

이런 식으로 분리가 됩니다.

결론

작은 설정 변경으로 사용자 경험을 크게 개선할 수 있어요.

Code Splitting은 강력한 성능 최적화 도구지만, 프로젝트의 특성에 맞게 적절히 사용하는 것이 중요합니다.

실제 프로젝트에 적용할 때는 번들 분석 도구를 활용하여 최적의 분할 전략을 찾는 것을 추천드립니다.

 

그리고 manualChunks에만 의존하는 것이 아닌, 적절한 코드 스플리팅이 적용 되어 있다면 더 큰 효과를 볼 수 잇습니다.

manualChunks 한번 적용해 보세요!