Update: 2026-04-30 22:59

2026-04-30 23:01:12 +09:00
parent c36c0644a1
commit b845959200
31 changed files with 1268 additions and 42 deletions
@@ -0,0 +1,44 @@
+## 📌 Brief Summary
+Bundle Size Optimization(번들 크기 최적화)은 클라이언트로 전송되는 자바스크립트 자산의 물리적 용량을 최소화하여 초기 로딩 성능(LCP)과 런타임 반응성(TBT/INP)을 개선하는 기술적 공정이다. 코드 분할(Code Splitting), 지연 로딩(Lazy Loading), 트리 쉐이킹 등을 통해 브라우저의 파싱 및 실행 오버헤드를 근본적으로 줄이는 것을 목표로 한다.
+
+## 📖 Core Content
+1. **번들 팽창의 원인 진단**
+   - 단일 엔트리 포인트(`index.js`)에 모든 종속성(React, heavy libraries)이 결합된 구조.
+   - 무분별한 Eager Import와 거대한 전이적 종속성(Transitive Dependencies)으로 인한 메인 스레드 점유율 상승.
+2. **코드 분할 및 지연 로딩 (Strategic Splitting)**
+   - `React.lazy()`와 `<Suspense>`를 활용하여 특정 라우트나 무거운 UI 요소(차트, 모달 등)를 독립적인 청크(Chunk)로 분리.
+   - 사용자가 필요로 하는 시점에만 코드를 로드하여 초기 번들 페이로드를 획기적으로 절감.
+3. **벤더 분할 전략 (Vendor Splitting)**
+   - Vite/Rollup의 `manualChunks` 설정을 통해 자주 변경되지 않는 핵심 라이브러리(React 등)를 별도의 청크로 고정.
+   - 브라우저 캐싱 효율을 극대화하여 재방문자의 로딩 속도를 가속화.
+4. **서버 컴포넌트(RSC)를 통한 근본적 절감**
+   - 상호작용이 없는 정적 UI를 서버에서 렌더링하여 클라이언트로 전송되는 JS 페이로드를 '0'으로 수렴시키는 아키텍처 적용.
+5. **분석 및 정제 도구 활용**
+   - `rollup-plugin-visualizer` 또는 Webpack Bundle Analyzer를 통해 번들 내부의 'Bloat'을 시각적으로 식별하고 제거.
+
+## ⚖️ Trade-offs & Caveats
+- **워터폴(Waterfall) 현상**: 지연 로딩을 남발할 경우 청크 간의 의존성으로 인해 순차적 로딩 지연이 발생하여 체감 성능이 오히려 저하될 수 있다.
+- **네트워크 요청 수 증가**: 번들을 너무 작게 쪼개면 HTTP 요청 수가 급증하여 네트워크 오버헤드가 발생할 수 있으므로 적절한 청크 사이즈(예: 30KB~100KB) 유지가 필요하다.
+- **캐시 무효화 관리**: 청크 분할 전략이 잘못될 경우 작은 코드 수정에도 모든 벤더 청크의 해시가 변경되어 캐시 효율이 떨어질 수 있다.
+
+## 🔗 Knowledge Connections
+### Related Concepts
+- **Code Splitting**: 번들을 물리적으로 분리하는 구현 패턴 (관계: 실천 방법)
+- **Core Web Vitals**: 번들 최적화의 성공 여부를 측정하는 정량적 지표 (관계: 성능 평가)
+- **Hydration**: 번들 크기가 클수록 직접적으로 지연되는 클라이언트 활성화 과정 (관계: 직접 영향)
+
+### Deeper Research Questions
+1. Vite의 `manualChunks` 설정 시 변동 주기가 다른 라이브러리들을 어떻게 그룹화하는 것이 캐시 히트율에 가장 유리한가?
+2. `React.lazy`를 비동기 데이터 페칭 로직과 결합할 때 레이턴시를 최소화하는 프리페칭(Prefetching) 전략은?
+3. 트리 쉐이킹이 작동하지 않는 CommonJS 기반 라이브러리를 ESM 환경에서 어떻게 효율적으로 격리할 것인가?
+4. 서버 컴포넌트 환경에서 클라이언트 번들에 의도치 않게 포함되는 서버 사이드 로직을 어떻게 정적으로 감지할 것인가?
+5. 번들 압축 기법(Gzip vs Brotli)과 번들 크기 최적화 사이의 실제 사용자 로딩 시간 상관관계는?
+
+### Practical Application Contexts
+- **Vite Configuration**: `vite.config.ts`에서 Rollup 옵션을 조정하여 벤더 청크 분리.
+- **Performance Budgeting**: CI/CD 단계에서 특정 번들 사이즈 초과 시 빌드를 실패하게 만드는 성능 예산 설정.
+
+### Adjacent Topics
+- **Brotli / Gzip Compression**
+- **Tree Shaking & ES Modules**
+- **HTTP/2 & HTTP/3 Multi-plexing**
@@ -0,0 +1,43 @@
+## 📌 Brief Summary
+프론트엔드 관측성(Frontend Observability) 및 로깅 시스템은 다양한 브라우저와 기기 환경에서 실행되는 웹 애플리케이션의 런타임 동작을 가시화하는 기술이다. 단순한 에러 추적을 넘어 세션 리플레이, 분산 추적, 지능형 에러 그룹화를 통해 복잡한 프로덕션 오류의 원인을 심층 분석하고 서비스 안정성을 보장하는 것을 목표로 한다.
+
+## 📖 Core Content
+1. **관측성의 핵심 기능**
+   - **세션 리플레이 (Session Replay)**: 에러 발생 전의 DOM 변경, 네트워크 요청, 상태 변화를 영상처럼 재생하여 재현 경로를 파악한다.
+   - **지능형 에러 그룹화**: 노이즈가 되는 중복 에러를 묶어 실제 해결이 필요한 고유 이슈에 집중하게 한다.
+   - **분산 추적 (Distributed Tracing)**: 프론트엔드 에러를 백엔드 트레이스와 연결하여 풀스택 관점의 장애 원인을 진단한다.
+2. **주요 도구 및 특징**
+   - **Sentry**: 개발자 친화적인 에러 추적 및 브레드크럼(Breadcrumb) 기능 제공.
+   - **LogRocket**: 강력한 세션 리플레이와 상태 변화 기록에 특화.
+   - **Datadog RUM**: 대규모 환경의 풀스택 관측성 및 지표 통합 관리.
+   - **SigNoz & Grafana**: OpenTelemetry 기반의 개방형 표준 준수 및 벤더 종속 방지.
+3. **도입 시 고려사항**
+   - **성능 오버헤드**: 로깅 SDK가 브라우저 로드 타임에 미치는 영향(최대 120ms 등)을 검토해야 한다.
+   - **개인정보 보호**: 민감한 데이터 유출을 막기 위한 데이터 마스킹 및 프라이버시 제어 설정이 필수적이다.
+
+## ⚖️ Trade-offs & Caveats
+- **비용 vs 가시성**: Datadog 등 일부 유료 도구는 데이터 수집량에 따라 비용이 기하급수적으로 증가하므로, 중요 로그만 선별적으로 수집하는 전략이 필요하다.
+- **성능 저하**: 모든 사용자 상호작용을 기록하는 도구는 브라우저의 메인 스레드 점유율을 높여 사용자 경험을 저해할 수 있다.
+- **설계 복잡성**: 세션 리플레이 도구 도입 시 개인정보 보호를 위한 복잡한 마스킹 규칙 설정이 운영 부담으로 작용할 수 있다.
+
+## 🔗 Knowledge Connections
+### Related Concepts
+- **OpenTelemetry**: 벤더 종속 없는 데이터 표준 (관계: 기술 기반)
+- **Session Replay**: 디버깅 컨텍스트 확보 (관계: 주요 기능)
+- **Distributed Tracing**: 풀스택 장애 진단 (관계: 확장 기능)
+
+### Deeper Research Questions
+1. SDK 도입이 실제 사용자의 TBT(Total Blocking Time) 및 LCP(Largest Contentful Paint)에 미치는 정량적 영향은?
+2. 세션 리플레이 데이터 수집 시, 보안 규제(GDPR, CCPA)를 준수하면서 실무에 필요한 정보를 확보하는 최적의 마스킹 전략은?
+3. 서버 사이드 렌더링(SSR) 환경에서 클라이언트와 서버 로그를 유기적으로 연결하기 위한 트레이스 ID 전파 기법은?
+4. 오픈소스 기반 관측성 도구(SigNoz 등)를 자체 구축할 때 발생하는 인프라 유지보수 비용과 관리형 서비스(Sentry 등)의 비용 편익 분석은?
+5. 수만 개의 유사 에러 중 '비즈니스에 치명적인 에러'를 실시간으로 우선순위화하는 AI 기반 그룹화 알고리즘의 원리는?
+
+### Practical Application Contexts
+- **프로덕션 장애 디버깅**: 재현이 어려운 간헐적 버그나 사용자 환경 의존적 에러 신속 해결.
+- **성능 모니터링**: 사용자 세션 데이터 분석을 통한 실제 로딩 병목 구간 식별 및 개선.
+
+### Adjacent Topics
+- **Web & Performance Optimization**
+- **Frontend Security & Privacy**
+- **Error Boundaries & Resilience**
@@ -0,0 +1,39 @@
+## 📌 Brief Summary
+Vite 빌드 번들 최적화는 초기 로딩 속도와 캐시 효율을 극대화하기 위해 JavaScript 번들 크기를 줄이고 로딩 구조를 최적화하는 과정이다. Rollup 옵션을 통한 벤더 라이브러리 분리(`manualChunks`)와 지연 로딩(`React.lazy`)을 결합하여, 사용자가 필요한 시점에 필요한 코드만 다운로드하도록 설계하는 것이 핵심이다.
+
+## 📖 Core Content
+1. **대규모 번들 이슈 해결**
+   - 기본적으로 하나의 거대한 `index.js`로 묶이는 문제를 해결하여 FCP, LCP 등 Core Web Vitals 지표를 개선한다.
+2. **manualChunks를 통한 벤더 분리**
+   - 자주 바뀌지 않는 `react`, `react-dom` 등 외부 라이브러리를 별도 청크로 분리하여 브라우저 캐싱 효율을 극대화한다.
+3. **라우트 레벨 코드 스플리팅**
+   - `React.lazy`와 `<Suspense>`를 활용해 페이지 단위로 코드를 쪼개어 초기 진입 시 다운로드되는 리소스를 최소화한다.
+4. **번들 시각화 및 분석**
+   - `rollup-plugin-visualizer`를 통해 번들 내부를 시각적으로 분석하고, 불필요하게 비대해진 모듈을 찾아 트리 쉐이킹(Tree-shaking)을 적용하거나 대체한다.
+
+## ⚖️ Trade-offs & Caveats
+- **청크 파편화**: 번들을 너무 잘게 쪼갤 경우 HTTP 요청 횟수가 급증하여 오히려 네트워크 병목과 Waterfall 현상이 발생할 수 있다.
+- **개발 vs 프로덕션 차이**: Vite는 개발 시 네이티브 ESM을 사용하지만 프로덕션은 Rollup을 사용하므로, 빌드 결과물에서만 발생하는 성능 이슈나 경고를 상시 확인해야 한다.
+- **캐시 무효화**: 벤더 번들을 너무 크게 묶으면 라이브러리 하나만 업데이트해도 거대한 벤더 파일 전체의 캐시가 무효화되는 트레이드오프가 있다.
+
+## 🔗 Knowledge Connections
+### Related Concepts
+- **Rollup**: Vite의 프로덕션 빌드 엔진 (관계: 구동 원리)
+- **React.lazy & Suspense**: 코드 스플리팅의 실천 수단 (관계: 구현 도구)
+- **Core Web Vitals**: 최적화의 최종 목적지 (관계: 성능 지표)
+
+### Deeper Research Questions
+1. `manualChunks`를 세밀하게 설정할 때, 네트워크 오버헤드를 최소화하면서 캐시 히트율을 극대화하는 최적의 청크 크기 기준은?
+2. Vite의 ESM 기반 개발 서버와 Rollup 기반 빌드 환경 간의 차이로 인해 발생하는 'Silent Errors' 사례와 방지책은?
+3. 동적 임포트로 쪼개진 청크들을 사용자가 클릭하기 전에 미리 불러오는 'Prefetching' 전략의 Vite 자동화 방법은?
+4. 트리 쉐이킹이 작동하지 않는 CommonJS 기반 라이브러리를 ESM으로 안전하게 변환하거나 대체하는 가이드라인은?
+5. HTTP/2 또는 HTTP/3 환경에서 다수의 작은 청크 전송이 번들링된 하나의 큰 파일 전송보다 유리해지는 구체적 조건은?
+
+### Practical Application Contexts
+- **성능 경고 해결**: "Chunks are larger than 500 kB" 빌드 경고 발생 시 즉각적인 대응.
+- **사용자 경험 개선**: 느린 네트워크 환경의 사용자를 위한 초기 로딩 최적화 및 안정적 인터랙션 제공.
+
+### Adjacent Topics
+- **Service Worker & Caching Strategy**
+- **React Server Components (RSC)**
+- **Modern Build Tools (Turbopack, Rspack) Comparison**