2nd/10_Wiki/Topics_Blog/Code Splitting.md

# [[Code Splitting|Code Splitting]]

## 📌 Brief Summary
큰 자바스크립트 번들을 더 작은 청크(chunk) 단위로 나누어 사용자가 필요로 할 때(on demand) 로드하는 프로세스입니다 [1, 2]. 모든 애플리케이션 코드를 초기에 한 번에 다운로드하는 대신, 필요한 파일만 먼저 불러오게 하여 초기 번들 크기를 극적으로 줄일 수 있습니다 [2, 3]. 결과적으로 초기 페이지 로드 속도를 향상시키고, 애플리케이션의 체감 성능을 개선하는 핵심적인 프론트엔드 최적화 기법입니다 [1, 4].

## 📖 Core Content
* **라우트 기반 분할 (Route-level Code Splitting):** 가장 일반적이고 효과적인 접근 방식입니다. 사용자가 특정 라우트로 이동할 때만 해당 페이지의 코드를 다운로드하도록 하여 초기 로딩 시 불필요한 코드 다운로드를 방지합니다 [1, 2, 5].
* **컴포넌트 수준 지연 로딩 (Component-level Lazy Loading):** 차트, 지도, 리치 텍스트 에디터처럼 크고 무거운 컴포넌트나 드물게 사용되는 모달, 설정 패널 등을 렌더링이 필요한 시점에만 로드하도록 분리합니다 [6, 7]. React에서는 `React.lazy()`와 동적 임포트(dynamic imports), 그리고 `<Suspense>`를 활용해 이를 쉽게 구현할 수 있습니다 [4, 6, 8].
* **벤더 라이브러리 분할 (Vendor Splitting):** Vite(내부적으로 Rollup 사용) 등의 번들러를 사용할 때 `manualChunks` 옵션을 통해 React 코어 라이브러리나 차트 등 무거운 벤더 코드를 별도의 파일로 분할합니다 [5, 9, 10]. 벤더 라이브러리는 자주 변경되지 않기 때문에 브라우저 캐싱 효율을 극대화할 수 있습니다 [5, 11].
* **번들러의 자동화 지원:** 최신 번들러(Webpack, Vite)는 코드 내에 작성된 동적 임포트(`import()`)를 감지하면 자동으로 해당 코드를 별도의 청크로 분리합니다 [4, 6].

## ⚖️ Trade-offs & Caveats
* **필수 컴포넌트에 대한 오남용 금지:** 페이지에 즉시 필요한 스크롤 없이 볼 수 있는(above-the-fold) 핵심 컴포넌트나, 렌더링 속도가 빨라야 하는 요소에는 지연 로딩과 코드 분할을 피해야 합니다 [7]. 오히려 첫 화면을 그리는 시간을 지연시킬 수 있습니다.
* **사용자 경험 저하 방지 (Fallback UI 필요):** 코드를 동적으로 불러오는 동안 네트워크 지연이 발생할 수 있습니다. 따라서 `<Suspense>`를 사용해 모듈이 로드되는 동안 스피너나 스켈레톤과 같은 Fallback UI를 제공해야 합니다 [5, 8]. 
* **네트워크 요청 증가의 위험:** 너무 잘게 코드를 분할하면 오히려 수많은 네트워크 요청이 발생해 오버헤드가 발생할 수 있습니다. 따라서 번들 크기를 시각적으로 분석할 수 있는 `rollup-plugin-visualizer` 등의 도구를 사용해 500kB 이상의 큰 청크를 타겟으로 식별하고 적절하게 분할해야 합니다 [12, 13].

## 🔗 Knowledge Connections

### Related Concepts

#### [아키텍처/기반 기술]
- [[Lazy Loading|Lazy Loading]]
  - 연결 이유: 코드 분할이 번들을 쪼개는 행위라면, 지연 로딩(Lazy Loading)은 그 쪼개진 코드를 필요 시점에 로드하는 기술적 방법론입니다 [2, 3].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 분할된 코드가 언제 브라우저로 전송되고 애플리케이션에 병합되는지 이해할 수 있습니다 [8].
- [[Core Web Vitals|Core Web Vitals]]
  - 연결 이유: 코드 분할을 적용하는 주된 성능적 목적은 초기 자바스크립트 실행을 최소화하여 LCP(Largest Contentful Paint)와 INP(Interaction to Next Paint) 같은 핵심 웹 지표를 향상시키는 데 있습니다 [1, 8, 14].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 최적화 결과가 실제 사용자의 체감 성능 및 페이지 측정 지표에 어떻게 긍정적 영향을 주는지 평가할 수 있습니다 [15].

#### [구현/활용 도구]
- React.lazy() and Suspense
  - 연결 이유: React 애플리케이션에서 컴포넌트 레벨 및 라우트 레벨의 동적 코드 분할을 구현하기 위해 사용하는 공식 API입니다 [6, 8].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 동적 임포트 처리 과정에서의 비동기 UI 렌더링 흐름과 예외(지연) 처리 방식을 배울 수 있습니다 [5].
- Vite (Rollup)
  - 연결 이유: 개발 및 프로덕션 환경에서 자바스크립트 애플리케이션을 번들링하고 실제 물리적인 청크 파일들로 분리해 내는 도구입니다 [9, 11].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 번들러의 `manualChunks` 설정을 통해 어떻게 벤더 라이브러리와 애플리케이션 코드를 효율적으로 나누어 브라우저 캐싱을 활용할 수 있는지 이해할 수 있습니다 [5].

### Deeper Research Questions
- 라우트 기반 분할과 컴포넌트 기반 분할을 어느 정도 비율로 적용해야 초기 렌더링 성능과 이후 탐색 시의 네트워크 지연 간의 균형을 이룰 수 있는가?
- Vite나 Webpack 환경에서 `manualChunks`를 설정할 때, 브라우저의 HTTP/2 및 HTTP/3 다중화(multiplexing) 환경을 고려한 가장 이상적인 청크 개수와 크기는 무엇인가?
- 동적 청크(chunk)를 로드하는 도중 사용자의 네트워크 연결이 끊기거나 에러가 발생할 경우, React Error Boundaries와 결합하여 어떻게 안정적인 Fallback 경험을 설계할 것인가?
- 코드 분할로 인해 컴포넌트가 지연 로드될 때, 해당 컴포넌트가 의존하는 상태(Context, Zustand 등)는 로드 시점에 어떻게 동기화되는가?
- Above-the-fold UI에 잘못 지연 로딩을 적용했을 때 LCP 점수에 미치는 악영향을 확인하려면 브라우저 개발자 도구의 성능(Performance) 패널에서 어떤 지표를 중점적으로 모니터링해야 하는가?

### Practical Application Contexts
- **Implementation:** React 코드에서 `import { Chart } from 'chart.js'`와 같은 정적 임포트를 제거하고, `const HeavyComponent = React.lazy(() => import('./HeavyComponent'))`로 감싸서 특정 버튼이 눌리거나 라우트가 전환될 때 렌더링되게 구현합니다 [4, 6, 8].
- **System Design:** 아키텍처 설계 시, 모든 코드가 포함된 하나의 `index.js` 모놀리스 번들 대신, Vite의 `vite.config.ts`에서 `manualChunks` 설정을 통해 React 코어 및 무거운 서드파티 라이브러리를 별개의 캐싱 가능한 청크로 분리하도록 설계합니다 [5, 10].
- **Operation / Maintenance:** CI/CD 파이프라인이나 로컬 빌드 과정에 `rollup-plugin-visualizer` 등의 번들 분석 도구를 연결하여 시각적 트리맵을 확인하고, 500kB를 초과하는 거대 청크가 발견되면 추가적인 분할 대상을 식별하여 최적화합니다 [4, 12, 13].
- **Learning Path:** 우선 React의 번들링 개념을 이해한 후, 동적 임포트 구문 활용 -> `React.lazy()` 및 `<Suspense>` 적용 -> 라우터에 코드 분할 결합 -> 번들 분석기 및 Core Web Vitals 측정을 통한 효과 검증 순서로 지식을 확장합니다 [6, 8].
- **My Project Relevance:** 프로젝트 규모가 커짐에 따라 메인 자바스크립트 번들이 수 메가바이트 단위로 무거워져 모바일 기기 등에서 로딩 속도 저하 현상이 보일 경우, 즉각적으로 라우트 기반 코드 분할과 차트/에디터 등 무거운 UI의 지연 로딩을 도입하여 LCP 문제를 해결할 수 있습니다 [3, 14, 16].

### Adjacent Topics
- [[Tree Shaking (번들 크기 최적화)|Tree Shaking]]
  - 확장 방향: 코드 분할이 필요한 코드를 '쪼개어' 가져오는 방식이라면, 트리 쉐이킹은 사용되지 않는 죽은 코드(Dead Code) 자체를 번들에서 '제거'하여 초기 번들 크기를 줄이는 상호 보완적인 최적화 기법입니다 [17, 18].
- Server Components (Next.js)
  - 확장 방향: 클라이언트 사이드의 코드 분할에서 더 나아가, 아예 정적인 UI 렌더링을 서버에서 처리하여 클라이언트로 보내는 자바스크립트 번들의 양 자체를 획기적으로 줄이거나 제거하는 최신 아키텍처 접근법입니다 [19-21].

---
*Last updated: 2026-04-30*