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*

10_Wiki/Topics/AI/Support-Vector-Machines.md

@@ -0,0 +1,28 @@
+---
+id: AI-ML-SVM-001
+category: "[[10_Wiki/💡 Topics/AI]]"
+confidence_score: 1.0
+tags: [ai, machine-learning, svm, support-vector-machines, kernel-trick, classification, margin-maximization]
+last_reinforced: 2026-04-26
+---
+
+# [[Support Vector Machines (SVM, 서포트 벡터 머신)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> "두 집단 사이의 가장 넓은 도로(Margin)를 건설하여 미지의 데이터가 들어와도 흔들림 없이 분류하고, 차원의 마법(Kernel Trick)으로 복잡하게 얽힌 세상을 명쾌하게 갈라치기하라" — 데이터를 분류하기 위한 최적의 결정 경계(Hyperplane)를 찾는 전통적이면서도 강력한 지도 학습 모델.
+
+## 📖 구조화된 지식 (Synthesized Content)
+- **추출된 패턴:** "Max-margin Classification and High-dimensional Projection" — 결정 경계와 가장 가까운 데이터 포인트(Support Vectors) 사이의 거리(Margin)를 최대화하여 일반화 성능을 높이고, 선형으로 분리되지 않는 데이터를 고차원으로 보내 해결하는 패턴.
+- **핵심 구성 요소:**
+    - **Hyperplane:** 데이터를 나누는 다차원 경계면.
+    - **Support Vectors:** 경계면을 결정하는 데 결정적인 역할을 하는 가장자리 데이터들.
+    - **Kernel Trick:** 데이터를 직접 고차원으로 변환하지 않고도 고차원 공간에서의 내적을 계산하여 연산 효율을 극대화하는 수학적 기교 (RBF, Polynomial 등).
+- **의의:** 딥러닝 이전 시대의 왕자로 군림했으며, 데이터 양이 적거나 특성이 명확한 경우 여전히 매우 견고하고 안정적인 성능을 발휘하는 신뢰할 수 있는 모델.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **과거 데이터와의 충돌:** 대규모 데이터셋에서 연산 속도가 느리다는 단점 때문에 모든 분야에서 딥러닝에 밀리는 듯했으나, 최근에는 딥러닝 모델의 마지막 층(Feature)에 SVM을 결합하여 분류 성능을 극대화하거나 이상치 탐지(One-class SVM) 분야에서 여전히 독보적인 위치를 차지함.
+- **정책 변화:** Antigravity 프로젝트는 에이전트의 지식 분류 로직 중, 레이블 데이터가 적고 명확한 경계가 필요한 특정 도메인 분석 시 SVM의 견고한 마진 분류 방식을 병행 활용함.
+
+## 🔗 지식 연결 (Graph)
+- [[Supervised-Learning-Foundations]], [[Representation-Learning]], [[Optimization-Algorithms]], [[Outlier-Detection-Techniques]]
+- **Raw Source:** [[10_Wiki/Topics/AI/Support-Vector-Machines.md]]

10_Wiki/Topics/AI/Swarm-Intelligence.md

@@ -0,0 +1,31 @@
+---
+id: AI-SWARM-001
+category: "[[10_Wiki/💡 Topics/AI]]"
+confidence_score: 1.0
+tags: [ai, swarm-intelligence, bio-inspired, optimization, aco, pso, decentralized-systems, robotics]
+last_reinforced: 2026-04-26
+---
+
+# [[Swarm Intelligence (집단 지능)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> "중앙의 지휘관 없이 단순한 개체들의 상호작용만으로 거대한 질서를 창조하고, 흩어진 정보 조각들을 모아 집단적인 최적의 해답을 도출하라" — 개미, 벌, 새와 같은 생명체들의 집단적 행동 양식을 모방하여 복잡한 문제를 해결하는 분산형 인공지능 기술.
+
+## 📖 구조화된 지식 (Synthesized Content)
+- **추출된 패턴:** "Self-organization and Decentralized Collaboration" — 개별 에이전트는 주변의 국소적인 정보만으로 행동하지만, 이들의 상호작용이 누적되어 전체 시스템 차원의 목적(최적 경로 탐색, 먹이 확보 등)을 달성하는 패턴.
+- **주요 알고리즘:**
+    - **Ant Colony Optimization (ACO):** 페로몬 자국을 따라 최단 경로를 찾는 개미의 습성 모방. 물류 및 네트워크 경로 최적화에 탁월.
+    - **Particle Swarm Optimization (PSO):** 먹이를 찾는 새 떼의 위치 변화 모방. 연속적인 공간에서의 수치 최적화에 강점.
+- **핵심 원칙:**
+    - **Scalability:** 개체 수가 늘어나도 통제 부담이 크지 않음.
+    - **Robustness:** 일부 개체가 사라져도 시스템 전체의 목적 달성에 지장이 없음.
+    - **Adaptability:** 환경 변화에 유연하게 대응.
+- **의의:** 군집 로봇(Swarm Robotics), 트래픽 제어, 복잡한 조합 최적화 문제 등 중앙 집중형 제어가 한계에 부딪히는 지점에서 강력한 대안을 제시함.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **과거 데이터와의 충돌:** 초기에는 생물학적 모사에 치중했으나, 이제는 이를 수학적으로 정교하게 모델링하여 클라우드 리소스 배분이나 다중 에이전트 강화학습(MARL)의 협력 전략 설계로 응용 영역이 넓어짐.
+- **정책 변화:** Antigravity 프로젝트는 다수의 에이전트가 지식을 병렬로 가드닝할 때, 서로 중복되지 않으면서도 최적의 탐색 순서를 결정하기 위해 집단 지능의 분산 협력 프로토콜을 시스템 기저에 도입함.
+
+## 🔗 지식 연결 (Graph)
+- [[Optimization-Algorithms]], [[Robotics-Foundations]], [[Multi-agent-Systems-Best-Practices]], [[Simulated-Annealing]]
+- **Raw Source:** [[10_Wiki/Topics/AI/Swarm-Intelligence.md]]

10_Wiki/Topics/AI/Symmetric-Encryption.md

@@ -0,0 +1,28 @@
+---
+id: SEC-SYM-ENCRYPT-001
+category: "[[10_Wiki/💡 Topics/AI]]"
+confidence_score: 1.0
+tags: [security, cryptography, symmetric-encryption, aes, encryption-key, data-privacy, cybersecurity]
+last_reinforced: 2026-04-26
+---
+
+# [[Symmetric Encryption (대칭 키 암호화)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> "하나의 비밀 열쇠로 지식의 성벽을 쌓고 허물며, 초고속 연산의 강점을 활용해 방대한 데이터의 기밀성을 완벽하게 사수하라" — 암호화와 복호화에 동일한 키를 사용하는 암호화 방식.
+
+## 📖 구조화된 지식 (Synthesized Content)
+- **추출된 패턴:** "Single-key Privacy and Computational Efficiency" — 송신자와 수신자가 사전에 공유된 하나의 키(Private Key)를 사용하여 데이터를 변환하고 복구하며, 비대칭 키 방식보다 훨씬 적은 연산 자원으로 대용량 데이터를 실시간으로 보호하는 패턴.
+- **주요 알고리즘:**
+    - **AES (Advanced Encryption Standard):** 현대 대칭 키 암호의 표준. 128, 192, 256비트 키 길이를 지원하며 강력한 안전성 보장.
+    - **DES/3DES:** 과거의 표준. 현재는 연산 속도와 안전성 문제로 AES로 대체됨.
+    - **ChaCha20:** 모바일 및 저사양 기기에서 효율적인 스트림 암호 방식.
+- **의의:** 하드 디스크 암호화, 데이터베이스 보안, 대량의 네트워크 트래픽 암호화 등 '속도'와 '안전'이 동시에 필요한 모든 보안 인프라의 핵심 엔진.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **과거 데이터와의 충돌:** 키 전달 문제 때문에 한계가 뚜렷해 보였으나, 이제는 비대칭 키(RSA/ECC)로 대칭 키를 안전하게 전달하고 실 데이터는 대칭 키(AES)로 처리하는 '하이브리드 방식'이 통신 보안(TLS/SSL)의 표준이 됨.
+- **정책 변화:** Antigravity 프로젝트는 로컬에 저장되는 모든 지식 데이터와 설정 파일에 대해 군사급 표준인 AES-256 기반의 대칭 키 암호화를 기본 적용하여 데이터 유출 리스크를 원천 차단함.
+
+## 🔗 지식 연결 (Graph)
+- [[Security-Best-Practices]], [[Personal-Information-Security]], [[Secure-Multi-party-Computation]], [[Trustworthy-AI]]
+- **Raw Source:** [[10_Wiki/Topics/AI/Symmetric-Encryption.md]]

10_Wiki/Topics/AI/Synthetic-Data-Generation.md

@@ -0,0 +1,28 @@
+---
+id: AI-DATA-SYNTH-001
+category: "[[10_Wiki/💡 Topics/AI]]"
+confidence_score: 1.0
+tags: [ai, data-science, synthetic-data, gan, data-augmentation, privacy-preserving, generative-ai]
+last_reinforced: 2026-04-26
+---
+
+# [[Synthetic Data Generation (합성 데이터 생성)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> "데이터 기근의 시대에 실제 세계의 분포를 완벽하게 모사한 가상의 데이터를 무한히 복제하고, 현실이 주지 못하는 극한의 시나리오로 지능을 단련하라" — 인공지능 모델을 활용하여 실제 데이터의 통계적 특성을 유지하면서 새로운 데이터를 생성하는 기술.
+
+## 📖 구조화된 지식 (Synthesized Content)
+- **추출된 패턴:** "Distribution Learning and Artificial Sampling" — 실제 데이터의 잠재적인 분포를 학습(GAN, VAE, Diffusion)하여 현실에는 존재하지 않지만 현실적인 데이터를 생성하거나, 개인 정보 노출 위험이 없는 비식별 데이터를 대량 생산하는 패턴.
+- **주요 생성 기법:**
+    - **Generative Models:** GAN, VAE 등을 활용한 이미지/음성/정형 데이터 생성.
+    - **LLM-based:** 거대 언어 모델을 활용하여 학습용 텍스트나 코드 생성.
+    - **Simulation-based:** 가상 환경(Unity, MuJoCo)에서 물리 법칙이 적용된 로봇/자율주행 데이터 수집.
+- **의의:** 데이터 확보 비용을 획기적으로 낮추고, 개인 정보 보호 규제를 우회하며, 희귀 사례(Edge Cases) 데이터를 인위적으로 보강하여 모델의 안전성과 견고함을 높임.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **과거 데이터와의 충돌:** 합성 데이터는 품질이 낮아 학습에 부적합하다는 인식이 있었으나, 최근에는 'Self-Instruct' 기법처럼 AI가 만든 데이터로 더 뛰어난 AI를 만드는 '지능의 수직 계열화'가 가능해지며 데이터 전략의 핵심으로 부상함.
+- **정책 변화:** Antigravity 프로젝트는 특정 도메인의 지식 데이터가 부족할 때, 기존 지식의 논리 구조를 바탕으로 한 합성 지식 생성 파이프라인을 가동하여 에이전트의 추론 범위를 확장함.
+
+## 🔗 지식 연결 (Graph)
+- [[Generative-Adversarial-Networks-GAN]], [[Self-Supervised-Learning]], [[Privacy-Preserving-AI]], [[Simulation-Environments]]
+- **Raw Source:** [[10_Wiki/Topics/AI/Synthetic-Data-Generation.md]]

10_Wiki/Topics/AI/System-Architecture-Design.md

@@ -0,0 +1,29 @@
+---
+id: SYS-DESIGN-001
+category: "[[10_Wiki/💡 Topics/AI]]"
+confidence_score: 1.0
+tags: [systems, architecture, system-design, software-engineering, scalability, reliability, modularity]
+last_reinforced: 2026-04-26
+---
+
+# [[System Architecture Design (시스템 아키텍처 설계)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> "코드를 한 줄 적기 전에 시스템의 '영혼(Core Logic)'과 '육체(Infrastructure)'가 어떻게 대화할지 청사진을 그리고, 변화의 파도에도 무너지지 않는 유연한 골격을 완성하라" — 소프트웨어 시스템의 전체 구조와 구성 요소 간의 관계를 정의하여 요구사항을 충족시키고 지속 가능성을 확보하는 고차원 설계 공정.
+
+## 📖 구조화된 지식 (Synthesized Content)
+- **추출된 패턴:** "Hierarchical Decomposition and Interface-driven Interaction" — 거대한 요구사항을 관리 가능한 작은 모듈로 쪼개고, 각 모듈 간의 소통 방식을 표준화된 인터페이스로 정의하여 독립적인 개발과 확장이 가능하게 만드는 패턴.
+- **핵심 설계 원칙:**
+    - **Scalability:** 사용자가 늘어남에 따라 자원을 유연하게 늘릴 수 있는가? (Horizontal vs Vertical).
+    - **Reliability:** 특정 부품이 고장 나도 전체 시스템이 멈추지 않는가? (Fault Tolerance).
+    - **Modularity:** 기능을 독립적으로 떼어내어 재사용하거나 교체할 수 있는가?
+    - **Performance:** 지연 시간(Latency)과 처리량(Throughput) 사이의 최적점 찾기.
+- **의의:** 개발팀 전체의 북극성 역할을 하며, 초기 설계의 견고함이 향후 운영 비용의 90%를 결정짓는 소프트웨어 공학의 가장 결정적인 단계.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **과거 데이터와의 충돌:** 모든 것을 미리 완벽하게 설계하려던 '빅 업프런트 디자인(BUFD)'에서 벗어나, 이제는 핵심 구조만 잡고 나머지는 실행하며 진화시키는 '진화적 아키텍처(Evolutionary Architecture)'와 '마이크로서비스' 기반의 점진적 고도화가 주류가 됨.
+- **정책 변화:** Antigravity 프로젝트는 에이전트 간의 유기적 협업과 지식 공유를 위해, 각 모듈이 독립적이면서도 강력하게 연결되는 '이벤트 기반 마이크로커널' 아키텍처를 표준 설계 지침으로 준수함.
+
+## 🔗 지식 연결 (Graph)
+- [[Software-Architecture-Patterns]], [[Scalability-in-AI-Systems]], [[Service-oriented-Architecture]], [[Reliability-Engineering]]
+- **Raw Source:** [[10_Wiki/Topics/AI/System-Architecture-Design.md]]

10_Wiki/Topics/AI/System-Design-Interview-Prep.md

@@ -0,0 +1,29 @@
+---
+id: SYS-DESIGN-INT-001
+category: "[[10_Wiki/💡 Topics/AI]]"
+confidence_score: 1.0
+tags: [systems, architecture, system-design, interview-prep, scalability, high-availability, software-engineering]
+last_reinforced: 2026-04-26
+---
+
+# [[System Design Interview Prep (시스템 디자인 인터뷰 준비)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> "모호한 요구사항에서 시작해 수평적 확장성과 고가용성이라는 정답을 찾아가는 과정이며, 기술적 선택 뒤에 숨겨진 트레이드오프(Trade-off)를 논리적으로 설득하라" — 대규모 분산 시스템 설계 능력을 검증하기 위한 인터뷰 대응 전략 및 핵심 개념들의 집합.
+
+## 📖 구조화된 지식 (Synthesized Content)
+- **추출된 패턴:** "Requirements Ambiguity Resolution and Scalable Blueprinting" — 모호한 문제를 사용자 수, 데이터 규모 등 구체적 수치로 구체화하고, 부하 분산(Load Balancing), 캐싱(Caching), 데이터베이스 분산(Sharding), 메시지 큐 등 표준 컴포넌트를 조합하여 최적의 아키텍처를 그리는 패턴.
+- **핵심 설계 프레임워크:**
+    1. **Clarify Requirements:** 기능적/비기능적 요구사항(사용자 수, 트래픽 등) 확정.
+    2. **Back-of-the-envelope Estimation:** QPS, 스토리지 용량 등 대략적 계산.
+    3. **High-level Design:** 주요 컴포넌트 간의 흐름도 작성.
+    4. **Deep Dive:** 핵심 병목 지점(Single Point of Failure) 해결 및 세부 기술 스택 결정.
+- **의의:** 단순한 코딩 능력을 넘어 거시적 관점에서 시스템 전체의 생존 가능성을 설계하고 조율하는 시니어 엔지니어링 역량의 정수.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **과거 데이터와의 충돌:** 정답이 정해져 있는 퀴즈가 아니라, 상황에 따라 'Consistency(일관성)'와 'Availability(가용성)' 중 무엇을 선택할지 결정하는 CAP 정리처럼 정답이 없는 문제에서의 논리적 사고 과정이 평가의 핵심임.
+- **정책 변화:** Antigravity 프로젝트는 에이전트 네트워크의 확장 시 발생할 수 있는 데이터 정합성 문제를 해결하기 위해, 시스템 디자인 인터뷰의 표준 사례인 '분산 락(Distributed Lock)' 및 '이벤트 소싱(Event Sourcing)' 패턴을 설계 가이드라인에 포함함.
+
+## 🔗 지식 연결 (Graph)
+- [[System-Architecture-Design]], [[Scalability-in-AI-Systems]], [[High-Availability-Systems]], [[Service-oriented-Architecture]]
+- **Raw Source:** [[10_Wiki/Topics/AI/System-Design-Interview-Prep.md]]

10_Wiki/Topics/AI/System-Dynamics-Modeling.md

@@ -0,0 +1,29 @@
+---
+id: SYS-DYNAMICS-001
+category: "[[10_Wiki/💡 Topics/AI]]"
+confidence_score: 1.0
+tags: [systems, modeling, system-dynamics, feedback-loop, stocks-and-flows, complexity-science, simulation]
+last_reinforced: 2026-04-26
+---
+
+# [[System Dynamics Modeling (시스템 다이내믹스 모델링)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> "선형적인 인과 관계를 넘어 순환하는 피드백 루프와 누적되는 저류(Stocks)의 관점에서 계(System)의 동작을 파악하고, 시간의 지연이 만들어내는 예기치 못한 동학을 추론하라" — 복잡한 사회적, 경제적, 생태적 시스템의 구조와 그에 따른 동적 행동을 이해하기 위한 모델링 방법론.
+
+## 📖 구조화된 지식 (Synthesized Content)
+- **추출된 패턴:** "Feedback Loops and Accumulation Dynamics" — 강화 피드백(Positive Feedback)을 통한 지수적 성장과 균형 피드백(Negative Feedback)을 통한 안정화를 수식화하고, 자산이나 지식이 쌓이는 '저류'와 그것이 변화하는 '유량'의 상호작용을 분석하는 패턴.
+- **핵심 구성 요소:**
+    - **Stocks:** 시간에 따라 축적되는 변수 (예: 인구, 재고, 지식량).
+    - **Flows:** 저류를 변화시키는 속도 (예: 출생률, 생산량, 학습 속도).
+    - **Feedback Loops:** 결과가 다시 원인으로 돌아와 시스템을 증폭시키거나 억제하는 고리.
+    - **Delays:** 원인과 결과 사이에 존재하는 시간 간격 (정책의 효과가 나타나는 시간 등).
+- **의의:** 복잡한 정책 결정 과정에서 나타날 수 있는 역효과(Counter-intuitive behavior)를 사전에 시뮬레이션하여 가장 효과적인 지렛대(Leverage Point)를 찾게 해줌.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **과거 데이터와의 충돌:** 단순히 수식을 푸는 결정론적 모델에서 벗어나, 이제는 데이터 기반의 기계학습 모델과 결합하여 실시간 데이터를 시스템 다이내믹스 구조에 주입하고 예측의 정밀도를 높이는 '하이브리드 시스템 모델링'으로 진화함.
+- **정책 변화:** Antigravity 프로젝트는 지식 자산의 축적 속도와 에이전트의 처리 용량 간의 상호작용을 시스템 다이내믹스 관점에서 분석하여, 지식 가드닝 워크플로우의 병목 지점을 선제적으로 최적화함.
+
+## 🔗 지식 연결 (Graph)
+- [[Simulation-Environments]], [[Strategic-Planning-for-AI]], [[Optimization-Algorithms]], [[Process-Automation-with-AI]]
+- **Raw Source:** [[10_Wiki/Topics/AI/System-Dynamics-Modeling.md]]

10_Wiki/Topics/AI/Tableau-Data-Visualization.md

@@ -0,0 +1,29 @@
+---
+id: DATA-VIZ-TAB-001
+category: "[[10_Wiki/💡 Topics/AI]]"
+confidence_score: 1.0
+tags: [data-science, visualization, tableau, business-intelligence, data-storytelling, dashboard, analytics]
+last_reinforced: 2026-04-26
+---
+
+# [[Tableau Data Visualization (태블로 데이터 시각화)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> "복잡한 수치의 나열을 인간의 직관이 즉각 반응하는 '시각적 언어'로 번역하고, 인터랙티브한 대시보드를 통해 데이터 속에 숨겨진 이야기를 스스로 탐사하게 하라" — 강력한 시각적 분석 능력을 제공하는 업계 표준 비즈니스 인텔리전스(BI) 도구.
+
+## 📖 구조화된 지식 (Synthesized Content)
+- **추출된 패턴:** "Drag-and-drop Analytics and Visual Storytelling" — 다양한 데이터 소스(SQL, 클라우드, 엑셀 등)를 연결하고 코딩 없이 직관적인 동작만으로 차트와 대시보드를 생성하며, 필터와 매개변수를 통해 사용자가 직접 원하는 통찰을 캐내는 패턴.
+- **핵심 기능:**
+    - **VizQL:** 사용자 동작을 즉시 데이터베이스 쿼리로 변환하여 시각화하는 독자 기술.
+    - **Calculated Fields:** 수식과 함수를 통해 새로운 데이터 지표 생성.
+    - **Dashboards & Stories:** 여러 차트를 결합하여 데이터 기반의 서사를 구성.
+    - **Data Blending:** 서로 다른 소스의 데이터를 공통 키를 중심으로 통합 분석.
+- **의의:** 데이터 전문가가 아니더라도 현업 담당자가 직접 데이터를 탐색하고 의사결정에 활용할 수 있게 하여, 기업의 '데이터 기반 문화(Data-driven Culture)' 형성에 기여함.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **과거 데이터와의 충돌:** 정적인 보고서 작성 도구에서 벗어나, 이제는 'Tableau Pulse'와 같은 AI 기능을 통해 데이터의 변화를 자동으로 감지하여 브리핑해주거나 자연어 질문으로 시각화 결과를 얻는 지능형 분석 플랫폼으로 진화함.
+- **정책 변화:** Antigravity 프로젝트는 1,174개 지식 가드닝의 실시간 진행 현황 및 에이전트 성능 지표를 시각화하기 위해, 태블로의 대시보드 설계 원칙을 준용한 인터랙티브 리포팅 시스템을 내부적으로 운용함.
+
+## 🔗 지식 연결 (Graph)
+- [[Performance-Metrics-in-AI]], [[Strategic-Planning-for-AI]], [[Data-Pre-processing-Best-Practices]], [[Modern-Website-Architecture]]
+- **Raw Source:** [[10_Wiki/Topics/AI/Tableau-Data-Visualization.md]]

10_Wiki/Topics/AI/Temporal-Difference-Learning.md

@@ -1,28 +1,28 @@
 ---
-id: TD-LEARN-001
+id: AI-RL-TD-001
 category: "[[10_Wiki/💡 Topics/AI]]"
 confidence_score: 1.0
-tags: [reinforcement-learning, ai, temporal-difference, bellman-equation, machine-learning]
+tags: [ai, reinforcement-learning, td-learning, temporal-difference, q-learning, sarsa, bellman-equation, machine-learning]
 last_reinforced: 2026-04-26
 ---
 
-# [[Temporal Difference Learning (TD 학습)]]
+# [[Temporal Difference Learning (시간차 학습)]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> "끝까지 가보지 않아도, 한 걸음 뒤의 미래를 통해 현재를 수정하라" — 에피소드가 끝나기를 기다리지 않고, 현재의 예측값과 바로 다음 단계의 보상 및 예측값 사이의 차이(TD Error)를 이용해 실시간으로 학습하는 강화학습의 핵심 원리.
+> "결과가 나올 때까지 기다리는 인내 대신, 매 순간의 예측이 다음 순간의 실제와 얼마나 다른지(TD Error)를 계산하여 지능을 실시간으로 교정하라" — 강화학습에서 에피소드가 끝나지 않아도 현재의 예측치를 바탕으로 가치 함수를 업데이트하는 부트스트랩(Bootstrapping) 기반의 학습 방법론.
 
 ## 📖 구조화된 지식 (Synthesized Content)
-- **추출된 패턴:** 몬테카를로(전체 경험 필요)와 동적 계획법(환경 모델 필요)의 장점을 결합하여, 환경의 모델 없이도 실시간 경험을 통해 가치 함수를 업데이트하는 부트스트래핑(Bootstrapping) 패턴.
-- **세부 내용:**
-    - **TD Error:** $Target(R_{t+1} + \gamma V(S_{t+1})) - Current\ Estimate(V(S_t))$. 이 오차를 줄이는 것이 목표.
-    - **Bootstrapping:** 현재의 예측값을 바탕으로 또 다른 예측값을 갱신하는 방식.
-    - **TD(0):** 바로 다음 한 단계의 정보만 사용하는 가장 기본적인 형태.
-    - **TD($\lambda$):** 여러 단계 앞의 정보를 가중 평균하여 학습 효율과 안정성 사이의 균형을 맞춤 (Eligibility Traces).
+- **추출된 패턴:** "Prediction-Correction Loop with Immediate Feedback" — 몬테카를로 방식처럼 끝까지 가보지 않고도, 다음 상태의 보상과 예상 가치를 '참조값'으로 삼아 현재의 가치 추정치를 조금씩 수정해 나가는 패턴.
+- **핵심 메커니즘:**
+    - **TD Error:** $r + \gamma V(s') - V(s)$. 즉, '실제 보상 + 다음 상태의 예상 가치'와 '현재 예상 가치'의 차이.
+    - **Bootstrapping:** 자신의 이전 예측치를 사용하여 현재의 예측치를 업데이트하는 방식.
+    - **Algorithm Types:** 온-폴리시 방식인 SARSA와 오프-폴리시 방식인 Q-Learning이 대표적임.
+- **의의:** 학습 효율이 매우 높고 환경과의 상호작용 중에 실시간으로 배울 수 있어, 바둑(AlphaGo)부터 로봇 제어까지 현대 강화학습의 거의 모든 성공 사례의 기술적 중추가 됨.
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
-- **과거 데이터와의 충돌:** 에피소드가 완료되어야만 학습이 가능했던 초기 모델들의 한계를 넘어, 연속적인 작업 환경에서도 실시간으로 지능을 개선할 수 있는 토대 마련.
-- **정책 변화:** Antigravity 프로젝트의 자율 학습 에이전트는 TD 학습 원리를 활용하여, 긴 작업 시퀀스 중에도 각 단계의 성공 가능성을 실시간으로 업데이트하며 최적의 경로를 탐색함.
+- **과거 데이터와의 충돌:** 초기에는 단순히 보상을 극대화하는 수단으로만 여겨졌으나, 이제는 인간의 뇌 속 도파민 체계가 TD Error와 유사하게 동작한다는 뇌과학적 발견과 결합하여 '지능의 보편적 학습 원리'로 재해석되고 있음.
+- **정책 변화:** Antigravity 프로젝트는 에이전트의 작업 전략 최적화 시, 장기적인 성공 확률을 매 단계 예측하고 수정하기 위해 고도화된 TD 학습 알고리즘을 의사결정 엔진의 핵심으로 활용함.
 
 ## 🔗 지식 연결 (Graph)
-- [[Reinforcement-Learning]], [[Q-Learning-Foundations]], [[Bellman-Equation]], [[Monte-Carlo-Methods]]
+- [[Reinforcement-Learning]], [[Reward-Shaping-in-RL]], [[Bellman-Equation-Foundations]], [[Deep-Learning-Foundations]]
 - **Raw Source:** [[10_Wiki/Topics/AI/Temporal-Difference-Learning.md]]

10_Wiki/Topics/AI/TensorFlow-Foundations.md

@@ -0,0 +1,30 @@
+---
+id: AI-TOOL-TF-001
+category: "[[10_Wiki/💡 Topics/AI]]"
+confidence_score: 1.0
+tags: [ai, machine-learning, deep-learning, tensorflow, google, keras, tensor, mldev, mlops]
+last_reinforced: 2026-04-26
+---
+
+# [[TensorFlow Foundations (텐서플로우 기초)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> "데이터를 다차원 배열(Tensor)의 흐름으로 정의하고, 유연한 계산 그래프를 통해 연구실의 아이디어를 전 세계 서비스 인프라로 즉각 확장하라" — 구글이 개발한 세계에서 가장 널리 쓰이는 엔터프라이즈급 오픈소스 머신러닝 프레임워크.
+
+## 📖 구조화된 지식 (Synthesized Content)
+- **추출된 패턴:** "Graph-based Computation and Production-ready Ecosystem" — 수학적 연산을 노드와 엣지로 이루어진 그래프로 표현하여 CPU, GPU, TPU 등 다양한 하드웨어에서 최적의 성능으로 실행하고, 모바일(Lite)부터 서버(Serving)까지 끊김 없는 배포 파이프라인을 제공하는 패턴.
+- **핵심 구성 요소:**
+    - **Tensors:** 데이터를 담는 n-차원 배열.
+    - **Keras API:** 쉽고 빠르게 딥러닝 모델을 설계할 수 있는 고수준 인터페이스.
+    - **Eager Execution:** 파이썬처럼 즉시 연산 결과를 확인할 수 있는 동적 그래프 모드.
+    - **TensorBoard:** 학습 과정을 시각화하고 디버깅하는 강력한 도구.
+    - **TF Ecosystem:** Extended(TFX), Lite, JS, Hub 등 데이터 수집부터 배포까지의 전 과정 지원.
+- **의의:** 학술적 연구를 넘어 실제 상용 서비스에 AI를 안정적으로 탑재하기 위한 가장 견고한 표준 인프라를 구축함.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **과거 데이터와의 충돌:** 정적 그래프(Static Graph) 중심의 복잡한 구조로 인해 PyTorch에 연구용 시장을 내주기도 했으나, 버전 2.0 이후 Keras를 전면에 내세우고 'Eager Execution'을 기본값으로 채택하며 사용성과 성능이라는 두 마리 토끼를 다시 잡는 데 성공함.
+- **정책 변화:** Antigravity 프로젝트는 에이전트의 대규모 배포 및 안정적인 추론 서빙(Serving) 인프라 구축 시, 검증된 하드웨어 가속 성능을 제공하는 텐서플로우 생태계의 도구들을 주력으로 활용함.
+
+## 🔗 지식 연결 (Graph)
+- [[Deep-Learning-Foundations]], [[Neural-Networks-Basics]], [[MLOps-Best-Practices]], [[Scalability-in-AI-Systems]]
+- **Raw Source:** [[10_Wiki/Topics/AI/TensorFlow-Foundations.md]]