feat: Knowledge Gardening Milestone 500 (Batch #26 - Halfway to half!)

00_Raw/CI-CD Pipeline.md

@@ -0,0 +1,18 @@
+# [[CI/CD Pipeline]]
+
+## 📌 Brief Summary
+CI/CD 파이프라인은 프론트엔드 시스템 엔지니어링에서 코드 품질을 엄격하게 관리하고 배포를 자동화하기 위해 사용되는 핵심 시스템입니다 [1]. 주요 브랜치(main)에 코드를 병합하기 전에 코드 리뷰, 린팅, 시각적 회귀 테스트, 메모리 누수 검사 등을 자동으로 수행하여 애플리케이션의 안정성을 보장합니다 [2-4]. 이를 통해 개발 팀은 작은 단위의 빈번한 업데이트 문화를 유지하고 예측 가능하며 안정적인 배포 환경을 구축할 수 있습니다 [1, 2].
+
+## 📖 Core Content
+- **Git 워크플로우와의 통합 및 필수 관문:** 현대의 개발 팀은 짧은 수명의 피처 브랜치(feature branch)에서 작업하며, 성공적인 동료 리뷰와 CI/CD 검사를 통과한 후에만 main 브랜치에 코드를 병합하도록 강제합니다 [2]. 팀 규모가 커지거나 트렁크 기반 개발(Trunk-based development)을 도입할 경우, 강력한 CI 환경을 구축하는 것이 필수적입니다 [5, 6]. 
+- **자동화된 거버넌스와 품질 관리:** CI/CD 파이프라인은 개발자의 로컬 환경과 프로덕션 서버(주로 Linux) 간의 대소문자 구분 불일치로 인한 빌드 실패를 사전에 차단합니다 [7]. 또한 Husky와 같은 도구를 활용한 git hook과 연계하여 커밋 전 린팅, 포맷팅, 타입 검사를 실행함으로써 고품질의 코드만 저장소에 병합되도록 하는 자동화된 거버넌스를 제공합니다 [1, 8].
+- **UI 및 접근성 회귀 테스트 자동화:** Happo나 Chromatic 같은 도구를 CI 파이프라인에 통합하여 모든 풀 리퀘스트(PR)마다 Storybook 스토리의 시각적 테스트(Visual tests) 및 접근성 테스트를 자동으로 실행할 수 있습니다 [4, 9, 10]. CI 단계에서 시각적 변경 사항에 대한 피드백을 제공하여 의도치 않은 UI 버그가 병합되는 것을 방지합니다 [10, 11].
+- **성능 및 메모리 누수 방지:** 개발 중 발생할 수 있는 메모리 누수 문제를 프로덕션 환경에 도달하기 전에 조기에 발견하기 위해, Puppeteer 등을 사용한 메모리 누수 감지 테스트를 CI 파이프라인에 통합하여 자동화합니다 [3, 12].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Git Workflow]], [[Visual Regression Testing]], [[Memory Leak Detection]], [[Trunk-based Development]]
+- **Projects/Contexts:** [[Frontend Engineering Governance]], [[Scalable React Architecture]]
+- **Contradictions/Notes:** 소스에는 CI/CD를 활용한 테스트 자동화(시각적 테스트, 메모리 누수 검사 등)의 중요성과 원칙은 잘 명시되어 있으나, CI/CD 환경(예: GitHub Actions, Jenkins 등)을 구성하기 위한 구체적인 스크립트 작성법에 대해서는 소스에 관련 정보가 부족합니다.
+
+---
+*Last updated: 2026-04-26*

00_Raw/Conventional Commits.md

@@ -0,0 +1,29 @@
+# [[Conventional Commits]]
+
+## 📌 Brief Summary
+Conventional Commits는 일관성 있는 코드 히스토리 관리를 위해 지정된 커밋 메시지 작성 표준 규약입니다 [1, 2]. 일반적으로 `type(scope): description`의 구조를 가지며, 코드에 어떤 변경이 발생했고 그 이유가 무엇인지를 명확히 전달하는 데 목적이 있습니다 [1, 2]. 이 표준을 적용하면 코드의 변경 내역을 쉽게 훑어볼 수 있는(scannable) 히스토리를 구성할 수 있으며, 릴리즈 노트 작성의 자동화를 가능하게 합니다 [1].
+
+## 📖 Core Content
+- **기본 포맷**: 커밋 메시지는 `type(scope): description`의 형식을 엄격하게 따릅니다 [1].
+- **주요 커밋 타입(Types)** [1, 2]:
+  - `feat`: 새로운 기능의 추가
+  - `fix`: 버그 수정
+  - `docs`: 문서 관련 변경 사항
+  - `style`: 코드 스타일 변경 (포맷팅 등 기능에 영향을 주지 않는 변경)
+  - `refactor`: 버그 수정이나 새로운 기능 추가를 포함하지 않는 코드 리팩토링
+  - `test`: 테스트 코드의 추가 또는 업데이트
+  - `chore`: 유지보수 작업 등 기타 작업
+- **작성 원칙**:
+  - 커밋 메시지는 코드의 '무엇(what)'이 '왜(why)' 변경되었는지 명확하게 설명해야 합니다 [2].
+  - 커밋은 작고(small) 논리적인 단위로 의미 있게(meaningful) 작성되어야 합니다 [3, 4]. (예: `fix: handle null response in login API` [4] 또는 `feat: add login form` [3])
+- **도입 효과**:
+  - 소규모 팀의 기능 브랜치(feature-branch) 워크플로우에서 적용 시 변경 사항 파악이 쉬워지고 코드 리뷰가 단순해집니다 [3, 4].
+  - 릴리즈 노트 생성을 자동화할 수 있으며, 팀원 누구나 프로젝트 히스토리를 직관적으로 이해할 수 있게 돕습니다 [1].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Git Workflow]], [[Branching Strategies]], [[Code Review]], [[Clean Code Principles]]
+- **Projects/Contexts:** [[Team Collaboration]], [[Engineering Scalable Frontend Systems]], [[Version Control]]
+- **Contradictions/Notes:** 소스 간의 모순점은 발견되지 않았으며, 소규모 팀 워크플로우부터 대규모 프론트엔드 시스템 아키텍처까지 공통으로 일관된 커밋 명명 규칙(Conventional Commits) 사용을 적극 권장하고 있습니다.
+
+---
+*Last updated: 2026-04-26*

00_Raw/Core Web Vitals.md

@@ -1,34 +1,26 @@
 # [[Core Web Vitals]]
 
 ## 📌 Brief Summary
-Core Web Vitals는 웹사이트의 실제 사용자 경험을 객관적으로 측정하기 위해 Google이 설정한 표준화된 성능 지표입니다 [1]. 2025년 기준, 이 지표는 주로 페이지의 로딩 성능을 나타내는 LCP, 상호작용의 반응성을 측정하는 INP, 그리고 시각적 안정성을 평가하는 CLS로 구성됩니다 [1-3]. 이 지표들은 Google의 SEO(검색 엔진 최적화) 순위 알고리즘에 직접적으로 반영되며, 웹사이트의 전환율과 이탈률 등 핵심 비즈니스 성과에 막대한 영향을 미칩니다 [4-7].
+Core Web Vitals는 사용자가 체감하는 웹 애플리케이션의 속도와 시각적 안정성을 측정하는 표준화된 성능 지표이다 [1, 2]. 주요 지표로는 페이지의 시각적 콘텐츠 로드 완료를 측정하는 LCP(Largest Contentful Paint), 사용자의 입력에 대한 반응성을 측정하는 INP(Interaction to Next Paint)와 FID(First Input Delay), 그리고 시각적 안정성을 나타내는 CLS(Cumulative Layout Shift)가 포함된다 [2-4]. 현대 프론트엔드 개발에서는 단순한 코드 실행 속도 최적화를 넘어 실제 사용자 경험에 직접적인 영향을 미치는 Core Web Vitals를 관리하는 것이 핵심 과제로 다루어지고 있다 [1].
 
 ## 📖 Core Content
-*   **핵심 지표 및 2025년 기준 임계값:**
-    *   **LCP (Largest Contentful Paint):** 뷰포트 내에서 가장 큰 콘텐츠 요소(주로 히어로 이미지나 큰 텍스트 블록)가 화면에 표시되는 데 걸리는 시간을 측정합니다 [3, 8, 9]. 사용자가 페이지의 주요 내용을 인식하는 속도를 뜻하며, 일반적으로 2.5초 미만이어야 "좋음(Good)"으로 평가됩니다 [3, 10, 11].
-    *   **INP (Interaction to Next Paint):** 2025년에 기존의 FID(First Input Delay)를 공식적으로 대체한 지표로, 클릭이나 탭 등 사용자의 모든 상호작용부터 브라우저가 시각적 피드백(다음 프레임)을 렌더링하기까지의 전체 지연 시간을 포괄적으로 측정합니다 [2, 12, 13]. 일반적으로 200ms 미만을 유지해야 합니다 [10, 11, 13].
-    *   **CLS (Cumulative Layout Shift):** 페이지 로드 중 텍스트나 버튼 등이 예기치 않게 이동하는 현상을 측정하여 시각적 안정성을 평가합니다 [8, 14]. 0.1 미만의 점수를 받아야 사용자에게 쾌적한 경험을 제공하는 것으로 간주됩니다 [11, 14, 15].
-    *   **FCP (First Contentful Paint):** 첫 번째 텍스트나 이미지가 화면에 그려지는 시점을 측정하여 초기 로딩 체감 속도를 확인합니다 [16].
+- **핵심 지표의 정의 및 최적화 기법**
+  - **LCP (Largest Contentful Paint) & FCP (First Contentful Paint):** LCP는 가장 큰 시각적 콘텐츠의 로딩 완료 시점을, FCP는 사용자가 콘텐츠를 처음 보게 되는 시점을 측정한다 [4]. 라우트 수준의 코드 스플리팅을 통해 초기 자바스크립트 번들 크기를 줄임으로써 LCP와 FCP 지표를 획기적으로 향상시킬 수 있다 [5, 6]. 또한, React Compiler를 도입하여 초기 로드 시간을 단축하고 LCP를 향상한 실제 프로덕션 성공 사례(예: Wakelet의 10% 개선)도 존재한다 [7].
+  - **INP (Interaction to Next Paint) & FID (First Input Delay):** 이 지표들은 사용자 입력에 대한 애플리케이션의 반응성을 측정한다 [2, 4]. 수천 개의 데이터가 있는 리스트를 렌더링할 때 가상화(Virtualization) 기법을 적용하면, 화면의 뷰포트에 보이는 항목만 렌더링하여 스크롤 중 메인 스레드의 과부하를 막고 응답성을 유지할 수 있어 INP 점수에 긍정적인 영향을 미친다 [5, 8].
+  - **CLS (Cumulative Layout Shift):** 페이지가 로드되는 동안 발생하는 예상치 못한 레이아웃 이동을 측정하여 시각적 안정성을 평가하는 지표이다 [2].
 
-*   **비즈니스 및 SEO에 미치는 영향:**
-    *   Core Web Vitals는 Google의 페이지 경험(Page Experience) 알고리즘에서 약 25-30%의 순위 가중치를 가지는 강력한 SEO 랭킹 요소입니다 [6].
-    *   성능이 "나쁨"에서 "좋음"으로 전면 개선될 경우, 평균 전환율이 25% 증가하고 이탈률이 35% 감소하며 사용자당 수익이 30% 향상되는 등 즉각적인 비즈니스 ROI를 창출합니다 [7, 17].
-    *   페이지 로드가 1초 지연될 경우 전환율이 최대 7%까지 감소할 수 있으므로 강력한 최적화가 필수적입니다 [5, 18].
+- **자바스크립트 번들 크기와 성능의 상관관계**
+  - 자바스크립트 번들이 과도하게 크면(예: 압축 후 500KB 이상) 다운로드 및 파싱에 시간이 오래 걸리고 메인 스레드를 차단하여 FCP, LCP, INP 등 모든 Core Web Vitals 지표를 악화시킨다 [6, 9].
+  - 이를 방지하기 위해 `React.lazy`와 `Suspense`를 활용한 지연 로딩(Lazy Loading) 패턴이나 Vite의 `manualChunks`를 사용하여 무거운 서드파티 라이브러리를 별도의 파일로 분할하는 전략이 권장된다 [6, 10, 11].
 
-*   **성능 최적화 전략 (Optimization Strategies):**
-    *   **LCP 최적화:** WebP나 AVIF 같은 차세대 이미지 포맷을 사용하고, 정적 자산에 CDN을 활용하며, 서버 응답 시간(TTFB)을 단축해야 합니다 [8, 14, 19]. React와 같은 프레임워크를 사용할 경우 SSR(Server-Side Rendering)을 도입하여 브라우저에 완성된 HTML을 빠르게 전달해야 합니다 [20, 21].
-    *   **INP 최적화:** JavaScript 실행 시간 축소가 가장 중요합니다. 무거운 연산은 Web Workers로 오프로드하고, 메인 스레드를 차단하는 긴 작업(Long Tasks)은 50ms 이하의 작은 단위로 쪼개야 합니다 [12, 13, 22, 23]. 또한, 사용하지 않는 서드파티 스크립트를 제거하고 코드 스플리팅(Code Splitting) 및 지연 로딩(Lazy Loading)을 적용하는 것이 권장됩니다 [24, 25].
-    *   **CLS 최적화:** 모든 이미지와 동영상 요소에 명시적인 너비 및 높이(width/height) 속성을 지정하고, 동적 광고나 임베드 콘텐츠가 로드될 공간을 CSS로 미리 확보해야 합니다 [14, 16, 26]. 폰트 로딩 시 텍스트 깜빡임이나 레이아웃 이동을 방지하기 위해 `font-display: swap` 또는 `optional`을 사용하며, 애니메이션 시에는 레이아웃 재계산을 유발하지 않도록 `transform` 속성을 활용합니다 [27-29].
-
-*   **테스트 및 모니터링 도구:**
-    *   개별 페이지에 대한 빠른 실험실/필드 데이터 확인 및 최적화 추천을 받기 위해 Google PageSpeed Insights를 사용합니다 [30].
-    *   개발 및 디버깅 목적으로는 Chrome DevTools에 내장된 Lighthouse 도구를 활용하여 병목 현상을 파악합니다 [31, 32].
-    *   실제 사용자 모니터링(RUM)을 위해서는 Google Search Console의 Core Web Vitals 리포트를 통해 웹사이트 전체의 성능을 지속적으로 추적하고, GTmetrix나 Datadog RUM 등을 함께 활용할 수 있습니다 [32-34].
+- **성능 측정 및 실제 사용자 모니터링 (RUM)**
+  - 성능 병목 현상을 식별하기 위해 개발 단계에서 Lighthouse, WebPageTest, Chrome DevTools 등과 같은 도구를 사용하여 지표를 확인해야 한다 [2, 12, 13].
+  - 합성 테스트(Synthetic testing) 환경이 놓칠 수 있는 다양한 기기 및 네트워크 환경에서의 성능 문제를 파악하기 위해, Sentry, SigNoz, LogRocket, DebugBear 혹은 Web Vitals JS와 같은 플랫폼을 이용해 실제 사용자 모니터링(Real User Monitoring, RUM)을 지속적으로 수행하는 것이 필수적이다 [3, 12, 14, 15].
 
 ## 🔗 Knowledge Connections
-- **Related Topics:** [[LCP (Largest Contentful Paint)]], [[INP (Interaction to Next Paint)]], [[CLS (Cumulative Layout Shift)]], [[SEO]], [[Web Performance Optimization]], [[Server-Side Rendering (SSR)]]
-- **Projects/Contexts:** [[Google Page Experience 2025]], [[React SEO Guide]]
-- **Contradictions/Notes:** 2025년 기준 Core Web Vitals의 "좋음(Good)" 임계값과 관련하여 소스 간 의견 충돌이 존재합니다. 대다수의 소스는 기존 기준인 LCP < 2.5초, INP < 200ms, CLS < 0.1을 유지한다고 명시하지만 [1, 3, 10, 11, 13], 일부 소스는 2025년에 기준이 더욱 엄격해져 LCP < 2.0초, INP < 150ms, CLS < 0.08, FCP < 1.5초를 충족해야 한다고 주장합니다 [35].
+- **Related Topics:** [[Performance Optimization]], [[Code Splitting]], [[Real User Monitoring (RUM)]], [[React Compiler]]
+- **Projects/Contexts:** [[Frontend Performance Debugging]], [[React Application Scaling]]
+- **Contradictions/Notes:** 제공된 소스 전반에 걸쳐 Core Web Vitals의 중요성과 최적화 기법에 대한 견해는 일치하며 상충하는 내용은 없습니다. 
 
 ---
 *Last updated: 2026-04-26*

00_Raw/Next.js.md

@@ -1,18 +1,22 @@
 # [[Next.js]]
 
 ## 📌 Brief Summary
-Next.js는 React 기반의 웹 애플리케이션 프레임워크로, 서버 사이드 렌더링(SSR), 정적 사이트 생성(SSG), 그리고 증분 정적 재생성(ISR)을 기본적으로 지원합니다 [1-3]. 이는 기본 React의 클라이언트 사이드 렌더링(CSR)이 가지는 검색 엔진 최적화(SEO) 및 초기 로딩 속도의 한계를 극복하기 위해 고안되었습니다 [4, 5]. 성능 중심의 웹 아키텍처 구축과 우수한 코어 웹 바이탈(Core Web Vitals) 점수 달성에 널리 사용되며 사용자 경험 및 비즈니스 성과를 높이는 필수적인 플랫폼으로 평가받습니다 [1, 2, 6].
+Next.js는 확장 가능하고 유지 관리가 용이한 코드베이스를 구축하기 위해 체계적인 라우팅 및 파일 명명 규칙을 제공하는 React 프레임워크입니다 [1]. 특히 최신 App Router 환경에서는 React 서버 컴포넌트(RSC)를 활용하여 클라이언트 측 자바스크립트 전송량을 줄이고 초기 로딩 및 하이드레이션(Hydration) 속도를 최적화합니다 [2-4]. 체계적인 폴더 구조와 라우트 그룹 기능을 통해 프론트엔드 성능 최적화와 대규모 애플리케이션의 확장을 원활하게 지원하는 현대적인 개발 도구로 평가받고 있습니다 [5-7].
 
 ## 📖 Core Content
-* **하이브리드 렌더링(Hybrid Rendering):** Next.js는 단일 애플리케이션 내에서 페이지별 특성에 따라 렌더링 방식을 유연하게 정의할 수 있습니다 [7]. `getServerSideProps`를 활용하여 실시간으로 HTML을 생성하는 SSR, 빌드 타임에 정적 HTML을 생성하여 초고속으로 전송하는 SSG, 그리고 캐시된 정적 페이지를 백그라운드에서 업데이트하여 TTFB(Time to First Byte) 성능과 콘텐츠의 최신성을 모두 확보하는 ISR 환경을 제공합니다 [4, 5, 8-10].
-* **강력한 SEO 지원:** SPA(Single Page Application)의 취약점인 메타 데이터 관리를 위해 기본 제공되는 `next/head` 컴포넌트를 사용해 라우트별 동적 메타 태그 삽입이 가능하며, `next-sitemap` 패키지를 통한 사이트맵 자동 생성 기능을 지원합니다 [1, 2, 11, 12]. 검색 엔진 봇이 자바스크립트 실행을 대기할 필요 없이 렌더링이 완료된 HTML과 메타데이터, 구조화된 데이터를 즉시 응답받으므로 크롤링 효율이 극대화됩니다 [4, 5].
-* **성능 및 코어 웹 바이탈(Core Web Vitals) 최적화:** 라우트 기반의 코드 분할(Code splitting)을 자동으로 수행하여 초기 다운로드 자바스크립트 번들의 크기를 획기적으로 줄입니다 [13, 14]. 또한 `next/image` 컴포넌트를 사용하면 WebP, AVIF 같은 차세대 이미지 포맷 변환, 자동 리사이징 및 지연 로딩(Lazy loading)이 적용되어 LCP(Largest Contentful Paint)와 CLS(Cumulative Layout Shift) 점수를 효과적으로 개선할 수 있습니다 [15, 16]. 세밀한 수화(Hydration) 제어를 통해 페이지를 더 빠르게 상호작용 가능하게 만듭니다 [17].
-* **입증된 비즈니스 성과:** 전통적인 클라이언트 사이드 렌더링(CSR) 환경의 Create React App 구조에서 Next.js 기반의 ISR로 전자상거래 사이트를 마이그레이션한 실제 사례가 있습니다. 해당 사례에서 TTFB는 200ms에서 50ms로 단축되었고 LCP는 1.8초로 개선되었으며, 메인 번들 크기가 1.8MB에서 320KB로 감소했습니다 [15, 16, 18, 19]. 이 최적화를 통해 제품 페이지 색인율이 40%에서 95%로 크게 상승하였고, 결과적으로 오가닉 트래픽은 70%, 오가닉 검색을 통한 수익은 75% 증가하는 성과를 거두었습니다 [15, 16, 18, 19].
+* **라우팅 및 특수 파일 명명 규칙:** 
+  Next.js는 라우팅과 앱 구조를 정의하기 위해 엄격한 파일 명명 규칙을 사용합니다 [5]. 라우트를 위한 `page.js`, 공유 레이아웃을 위한 `layout.js`, 커스텀 에러 처리를 위한 `error.js`, 로딩 상태를 위한 `loading.js`가 핵심 파일로 사용됩니다 [1]. 일반적인 파일명은 OS 간 호환성과 URL 가독성을 위해 kebab-case(예: `user-profile.tsx`)를 사용해야 하며, 파일 내부의 React 컴포넌트 이름은 PascalCase를 사용합니다 [8, 9]. 또한 동적 라우팅에는 `[param]`, 포괄적(Catch-all) 라우팅에는 `[...param]` 형식을 사용합니다 [1].
+
+* **기능 기반 폴더 구조와 라우트 그룹 (Route Groups):** 
+  대규모 앱에서는 기능(Feature)을 기준으로 폴더를 구성하여(예: `features/auth/components/login-form.tsx`) 코드의 응집도와 확장성을 높이는 것이 권장됩니다 [1, 6]. 더불어 폴더명을 괄호로 감싸는 라우트 그룹 기능(예: `(marketing)`)을 활용하면, 실제 URL 경로에 영향을 주지 않으면서도 연관된 라우트들을 논리적으로 묶고 특정 그룹에만 개별적인 레이아웃(`layout.tsx`)을 설정할 수 있습니다 [10, 11].
+
+* **성능 최적화 및 서버 컴포넌트 (RSC):** 
+  Next.js의 App Router(v13 이후)에서는 React 서버 컴포넌트(React Server Components)가 통합되어 있어 불필요한 클라이언트 측 JS 코드를 제거할 수 있습니다 [3, 4]. 서버 컴포넌트는 서버에서만 렌더링되고 데이터베이스나 API에서 직접 데이터를 가져올 수 있어, JS 번들 크기를 줄이고 초기 화면 그리기(First Paint) 및 상호작용성(TTI)을 크게 향상시킵니다 [4, 12]. 읽기 전용의 정적 UI는 서버 컴포넌트로 구성하고, 모달이나 입력 폼 등 상호작용이 즉각적으로 필요한 요소에만 제한적으로 클라이언트 컴포넌트를 사용하는 아키텍처 패턴이 중요합니다 [13].
 
 ## 🔗 Knowledge Connections
-- **Related Topics:** `[[Server-Side Rendering (SSR)]]`, `[[Static Site Generation (SSG)]]`, `[[Incremental Static Regeneration (ISR)]]`, `[[Core Web Vitals]]`, `[[Client-Side Rendering (CSR)]]`
-- **Projects/Contexts:** `[[E-commerce Migration Case Study]]`, `[[Strapi Launchpad demo]]`
-- **Contradictions/Notes:** 순수 React 앱(CSR)은 자바스크립트 렌더링 지연과 빈 초기 HTML 구조로 인해 검색 엔진의 2차 색인 단계를 거쳐야 하는 불리함과 색인 누락의 위험이 있지만, Next.js를 도입한 서버 기반 렌더링은 검색 엔진 봇의 자바스크립트 실행 의존성을 원천적으로 제거하여 크롤링 이슈를 해결합니다 [4, 5, 20-23].
+- **Related Topics:** [[React Server Components]], [[Frontend Folder Structure]], [[Code Splitting]], [[React]]
+- **Projects/Contexts:** [[Next.js App Router]], [[Frontend Performance Optimization]]
+- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
 
 ---
 *Last updated: 2026-04-26*

00_Raw/Pull Request Workflow.md

@@ -0,0 +1,22 @@
+# [[Pull Request Workflow]]
+
+## 📌 Brief Summary
+Pull Request(PR) 워크플로우는 기능 브랜치에서 작업한 코드를 메인 코드베이스에 병합하기 전, 코드의 품질과 안정성을 검증하고 팀원들과 논의하는 핵심 협업 프로세스입니다. 이 과정은 동료의 코드 리뷰, 자동화된 테스트 통과 여부 확인, 시각적 회귀 테스트 등을 포함하여 버그나 UI 결함이 운영 환경에 배포되는 것을 방지합니다. 소규모 팀부터 대규모 프로젝트에 이르기까지 코드 병합 전에 리뷰를 필수화하여 항상 배포 가능한 상태의 안정적인 메인 브랜치를 유지하는 데 필수적인 역할을 합니다 [1-3].
+
+## 📖 Core Content
+* **작고 집중된 PR 유지:** 
+  PR은 단일 논리적 변경 사항이나 작업에만 집중해야 하며, 가능한 한 작은 규모(예: 200줄 미만)로 유지해야 합니다. 수천 줄의 코드는 리뷰어가 제대로 검토하기 어렵기 때문에, PR을 작게 쪼개는 것이 빠르고 철저한 코드 리뷰를 가능하게 합니다 [4-6].
+* **티켓 ID 및 명확한 맥락 제공:** 
+  PR을 생성할 때는 변경된 내용(What), 변경한 이유(Why), 그리고 UI 변경이 있을 경우 스크린샷을 반드시 포함해야 합니다 [4]. 또한 커밋 메시지와 브랜치 이름에 티켓 ID(예: PROJ-123)를 포함시키면 PR이 자동으로 티켓과 연결되어 코드 변경 사항과 비즈니스 요구사항 간의 추적성(Traceability)을 확보할 수 있으며, 리뷰어가 맥락을 쉽게 파악할 수 있습니다 [7-9].
+* **필수 리뷰 및 병합(Merge) 규칙:** 
+  메인 브랜치(main)에 직접 코드를 푸시하는 것은 금지되며, 변경 사항은 반드시 PR을 통해 반영되어야 합니다 [4, 10, 11]. 최소 1명 이상의 팀원에게 코드 리뷰 및 승인을 받아야 하며, 병합 전 모든 자동화된 CI/CD 테스트 검사가 통과되어야 합니다 [4, 5, 12]. 병합 시에는 주로 스쿼시 머지(Squash merge)를 사용하여 커밋 히스토리를 깔끔하게 유지하고, 병합이 완료된 기능 브랜치는 자동으로 삭제하도록 설정하는 것이 권장됩니다 [4, 10, 12].
+* **시각적 리뷰 및 접근성 검사 자동화:** 
+  최신 프론트엔드 PR 워크플로우에서는 Storybook과 함께 Chromatic이나 Happo 같은 시각적 회귀 테스트(Visual Regression Testing) 도구를 CI 파이프라인에 통합합니다 [13-15]. PR이 열리면 도구가 자동으로 UI 컴포넌트의 스크린샷을 찍어 기존 기준선(baseline)과 픽셀 단위로 비교합니다 [16, 17]. 의도치 않은 레이아웃 변화나 접근성(Accessibility) 위반이 발견되면 PR에 경고(Flag)를 표시하여 병합 전 개발자가 이를 확인하고 수정하도록 강제합니다 [13, 14, 18].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Git Branching Strategies]], [[Visual Regression Testing]], [[Clean Code Principles]], [[Storybook]]
+- **Projects/Contexts:** [[GitHub Flow]], [[Feature Branch Workflow]], [[CI/CD Pipeline Integration]]
+- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (제공된 소스들 간에 PR 워크플로우에 대한 모순된 주장은 존재하지 않으며, 모두 '작은 PR, 철저한 리뷰, 자동화된 테스트'라는 공통된 모범 사례를 강조하고 있습니다.)
+
+---
+*Last updated: 2026-04-26*

00_Raw/Suspense.md

@@ -1,19 +1,18 @@
 # [[Suspense]]
 
 ## 📌 Brief Summary
-`Suspense`는 React 애플리케이션에서 `React.lazy()`와 함께 사용되어 지연 로딩(Lazy Loading) 및 코드 분할(Code Splitting)을 구현할 때 필수적으로 사용되는 컴포넌트입니다 [1]. 이 컴포넌트는 동적으로 로드되는 컴포넌트가 준비될 때까지 기다리는 동안 사용자에게 보여줄 로딩 상태(fallback UI)를 선언적으로 정의합니다 [1, 2]. 결과적으로 초기 자바스크립트 번들 크기를 줄이고, 페이지의 로딩 속도와 전반적인 사용자 경험을 향상시키는 데 핵심적인 역할을 합니다 [2, 3].
+React에서 제공하는 내장 도구로, 주로 `React.lazy()`와 함께 사용되어 애플리케이션의 코드 분할(Code Splitting) 및 지연 로딩(Lazy Loading)을 구현하는 데 핵심적인 역할을 합니다 [1, 2]. 동적으로 불러오는 모듈이나 데이터가 로드되는 동안 사용자에게 보여줄 대체 UI(예: 로딩 스피너, 스켈레톤 상태)를 정의합니다 [3, 4]. 이를 통해 초기 JavaScript 번들 크기를 줄이고 사용자 경험과 렌더링 성능을 최적화할 수 있습니다 [2, 3].
 
 ## 📖 Core Content
-* **로딩 상태의 선언적 관리:** `Suspense` 컴포넌트는 `fallback` 속성을 사용하여 내부의 컴포넌트가 로드되는 동안 화면에 표시할 UI(예: 로딩 스피너, 스켈레톤 스크린 등)를 지정합니다 [1, 2, 4]. 이를 통해 사용자에게 명확한 피드백을 제공할 수 있습니다 [2].
-* **유연한 로딩 경계(Boundaries) 제어:** 여러 개의 지연 로딩 컴포넌트를 단일 `Suspense` 경계로 감싸 한 번에 로딩 상태를 관리할 수 있습니다 [5]. 또한, 중첩된(Nested) `Suspense` 경계를 설정하여 UI의 각 부분이 독립적으로 로드되도록 세밀하게 제어함으로써 반응성이 뛰어난 인터페이스를 구성할 수 있습니다 [5].
-* **웹 성능 및 Core Web Vitals 개선:** `React.lazy()`와 `Suspense`를 결합하여 라우트 수준이나 무거운 특정 컴포넌트를 분할(Code Splitting)하면, 사용자가 다운로드해야 하는 초기 자바스크립트 페이로드가 감소합니다 [2, 6]. 이는 LCP(Largest Contentful Paint) 속도를 높이고 TTI(Time to Interactive)를 줄여 최적의 웹 성능을 달성하는 데 기여합니다 [2, 6].
-* **점진적 하이드레이션 및 SSR 통합:** `Suspense`는 React 18의 스트리밍 서버 사이드 렌더링(Streaming SSR)과 자연스럽게 통합됩니다 [7]. 가시적인 컴포넌트부터 먼저 하이드레이션(Progressive Hydration)을 수행하여 초기 상호작용 지연 시간을 줄이고 INP 및 CLS 지표의 악화를 방지하는 데 활용됩니다 [8, 9].
-* **구현 시 주의사항:** `React.lazy()`를 통해 동적으로 임포트한 컴포넌트를 렌더링할 때는 반드시 `Suspense`로 감싸야 하며, 이를 누락하는 것은 애플리케이션에 오류를 유발하는 대표적인 실수입니다 [2, 10]. 
+*   **지연 로딩(Lazy Loading)과 번들 크기 최적화**: 모던 프론트엔드 애플리케이션은 규모가 커짐에 따라 JavaScript 번들 크기가 증가하여 초기 로드 시간이 느려지는 문제가 발생합니다 [1, 2]. `Suspense`를 `React.lazy()` 함수와 함께 사용하면 대시보드, 차트, 지도와 같이 무거운 컴포넌트나 거의 사용되지 않는 뷰를 필요할 때만 온디맨드(on-demand) 방식으로 로드할 수 있습니다 [1, 3, 5]. 이 접근 방식은 초기 번들 크기를 잠재적으로 20~70%까지 감소시키며, TTI(Time to Interactive) 및 Core Web Vitals 지표를 개선하는 데 기여합니다 [1-3].
+*   **라우트 레벨의 코드 분할(Route-level Code Splitting)**: Vite와 같은 번들러를 사용하는 React 프로젝트에서 각 페이지 라우트 요소를 `<Suspense>`로 감싸면, 전체 애플리케이션 코드가 한 번에 로드되는 것을 방지할 수 있습니다 [6, 7]. 결과적으로 각 페이지는 개별 청크(chunk) 파일로 분리되어, 사용자가 해당 경로로 이동할 때만 다운로드되도록 최적화됩니다 [7, 8].
+*   **대체 UI(Fallback UI) 제공**: 지연 로딩 중인 컴포넌트가 준비될 때까지 화면이 비어있거나 애플리케이션이 멈춘 것처럼 보이지 않도록, `<Suspense>` 컴포넌트의 `fallback` 속성을 통해 로딩 인디케이터나 스켈레톤 UI를 제공합니다 [3]. 
+*   **동시성 렌더링(Concurrent Rendering)과의 시너지**: React 18의 동시성 기능(예: `useTransition`)과 결합하여 사용할 경우, 데이터가 로드되거나 무거운 필터링 작업이 진행되는 동안 즉각적인 사용자 상호작용(타이핑, 클릭 등)을 차단하지 않으면서도 안정적으로 `fallback` UI를 표시할 수 있습니다 [4].
 
 ## 🔗 Knowledge Connections
-- **Related Topics:** [[Code Splitting]], [[Lazy Loading]], [[React.lazy()]], [[Core Web Vitals]], [[Progressive Hydration]]
-- **Projects/Contexts:** [[프론트엔드 웹 성능 최적화(Frontend Performance Optimization)]], [[React Router 기반 라우팅 및 SSR 구축]]
-- **Contradictions/Notes:** 소스 간의 모순점은 발견되지 않았으며, 제공된 모든 소스에서 React 애플리케이션의 번들 사이즈 최적화 및 로딩 UI 처리에 `Suspense`가 필수적인 도구라고 일관되게 설명하고 있습니다.
+- **Related Topics:** [[React.lazy()]], [[Code Splitting]], [[Lazy Loading]], [[Performance Optimization]], [[Concurrent Features]]
+- **Projects/Contexts:** [[Vite + React 성능 최적화]], [[프론트엔드 애플리케이션 렌더링 병목 개선]]
+- **Contradictions/Notes:** 필수적인 어보브 더 폴드(above-the-fold) 컴포넌트나 즉시 화면에 렌더링되어야 하는 빠른 UI 요소에는 `Suspense`와 지연 로딩을 적용하는 것을 피해야 합니다 [5].
 
 ---
 *Last updated: 2026-04-26*

00_Raw/Vite.md

@@ -0,0 +1,17 @@
+# [[Vite]]
+
+## 📌 Brief Summary
+Vite는 2025년 현재 현대적인 React 애플리케이션을 위한 표준 빌드 도구로 자리 잡은 강력한 도구입니다 [1, 2]. 개발 중에는 모든 코드를 미리 번들링하지 않고 브라우저에 네이티브 ES 모듈(ESM) 형태로 직접 제공하여 즉각적인 서버 시작과 매우 빠른 HMR(Hot Module Replacement)을 지원합니다 [2, 3]. 프로덕션 배포 시에는 내부적으로 Rollup을 사용하여 코드 스플리팅 및 트리 쉐이킹이 적용된 최적화된 번들을 생성하며, 과거의 Create React App이나 Webpack을 대체하여 프론트엔드 성능을 극대화합니다 [1, 2, 4, 5].
+
+## 📖 Core Content
+- **핵심 아키텍처 및 동작 원리:** Vite는 개발 환경과 프로덕션 환경에서 각기 다른 하이브리드 아키텍처를 사용합니다 [4]. 개발 중에는 네이티브 ES 모듈을 활용해 필요한 파일만 로드하므로 프로젝트 규모가 커져도 개발 환경이 빠르게 유지됩니다 [2, 3, 6]. 또한 기존 Babel 대신 Rust 기반의 컴파일러인 SWC를 사용하여 JSX와 TypeScript 파일을 거의 즉시 컴파일하여 개발 경험을 크게 향상시킵니다 [3, 7, 8]. 반면 프로덕션 빌드 시에는 Rollup을 활용하여 불필요한 코드를 제거하고 에셋을 최적화하여 가벼운 번들을 생성합니다 [4].
+- **성능 최적화 및 번들 관리:** 규모가 큰 애플리케이션에서는 메인 번들 크기가 커져 로딩 속도와 웹 성능 지표(Core Web Vitals)에 악영향을 미칠 수 있습니다 [9]. 기본적으로 Vite는 앱 코드와 모든 패키지 의존성을 하나의 파일로 묶기 때문에 "500kB 초과" 경고가 발생할 수 있습니다 [10, 11]. 이를 해결하기 위해 `vite.config.js`에서 `manualChunks`를 설정하여 React 핵심 라이브러리나 차트 등의 무거운 벤더 코드를 별도의 파일로 분리하고, 브라우저 캐싱 효율을 높이는 것이 강력히 권장됩니다 [5, 11-14]. 이와 함께 `React.lazy()` 및 동적 임포트를 활용하여 라우트 단위 코드 스플리팅을 구현하면 초기 화면 렌더링 속도를 크게 단축할 수 있습니다 [14, 15].
+- **고급 구성 및 플러그인 생태계:** Vite의 기본 설정은 의도적으로 최소화되어 있지만, 설정 파일을 통해 확장성과 구조적인 제어가 가능합니다 [7]. 모듈 참조를 깔끔하게 유지하기 위한 경로 별칭(Path Aliases) 설정, `VITE_` 접두사를 이용한 클라이언트 측 환경 변수 보안 관리, CORS 문제를 피하기 위한 자체 서버 프록시 기능 등을 지원합니다 [12, 16]. 더 나아가, SVG를 컴포넌트처럼 다루게 해주는 `vite-plugin-svgr`, PWA를 지원하는 `vite-plugin-pwa`, 빌드된 번들 크기를 시각적으로 분석하게 돕는 `rollup-plugin-visualizer` 등의 플러그인들을 통해 프론트엔드 워크플로우를 고도화할 수 있습니다 [15, 17-19].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Rollup]], [[Code Splitting]], [[React.lazy()]], [[Performance Optimization]]
+- **Projects/Contexts:** [[React Frontend Architecture]], [[Large-scale Application Refactoring]]
+- **Contradictions/Notes:** 소스에 따르면 Vite가 기본적으로 매우 빠른 성능을 제공하지만, 대규모의 실무 앱으로 확장할 때에는 개발자가 수동으로 `manualChunks` 분리와 지연 로딩(Lazy Loading)을 직접 구성해 거대한 청크(Large Chunks) 생성을 방지해야만 최적의 로딩 성능을 보장할 수 있다고 강조합니다 [10, 11, 14, 20].
+
+---
+*Last updated: 2026-04-26*