feat: Wiki-fication of 00_Raw data (Batch #4 - Next.js, Atomic Style, CI/CD, CLS, Rendering)

2026-04-26 20:33:12 +09:00
parent 2181ccdbfc
commit 9a94689531
12 changed files with 324 additions and 15 deletions
@@ -0,0 +1,22 @@
+# [[Component Lifecycle]]
+
+## 📌 Brief Summary
+컴포넌트 라이프사이클(Component Lifecycle)은 컴포넌트가 렌더링되고, 업데이트되며, 마운트 해제(unmount)되는 일련의 과정을 의미합니다. 최신 함수형 React에서는 `useEffect`와 같은 훅(Hook)을 사용하여 라이프사이클에 따른 부수 효과(side effects)를 관리하며, 클래스형 컴포넌트에서는 `componentDidCatch`와 같은 특정 라이프사이클 메서드를 활용합니다 [1, 2]. 특히 컴포넌트가 마운트 해제될 때 적절한 정리(cleanup) 작업을 수행하는 것은 메모리 누수를 방지하고 애플리케이션의 안정성을 유지하는 데 필수적입니다 [3].
+
+## 📖 Core Content
+* **함수형 컴포넌트와 `useEffect` 훅 활용**
+  최신 React의 함수형 컴포넌트에서는 주로 `useEffect`를 통해 라이프사이클과 관련된 부수 효과(side effects)를 처리합니다. 흔히 발생하는 문제 중 하나는 이벤트 리스너나 구독(subscription)과 같은 효과를 컴포넌트 마운트 해제 시 정리(cleanup)하지 않는 것입니다 [1]. 이러한 정리 누락은 시간이 지남에 따라 성능 저하와 메모리 누수(Memory Leak)를 유발할 수 있으므로, `useEffect`에서 항상 정리 함수를 반환하여 컴포넌트가 언마운트될 때 리소스가 해제되도록 해야 합니다 [1, 4].
+
+* **클래스형 컴포넌트의 라이프사이클 메서드와 에러 경계(Error Boundaries)**
+  클래스형 컴포넌트는 고유한 라이프사이클 메서드를 가집니다. `static getDerivedStateFromError()` 또는 `componentDidCatch()` 중 하나 이상을 정의하면 해당 클래스 컴포넌트는 하위 트리의 에러를 포착하는 '에러 경계(Error Boundary)' 역할을 수행하게 됩니다 [2]. 에러 경계는 하위 컴포넌트 트리의 렌더링 중, 생성자 내부, 그리고 라이프사이클 메서드 내부에서 발생하는 에러를 포착합니다 [5]. 하위 컴포넌트의 `componentDidUpdate`와 같은 라이프사이클 메서드 안에서 에러가 발생하더라도, 이는 가장 가까운 에러 경계로 정상적으로 전파되어 애플리케이션 전체가 멈추는 것을 방지합니다 [6].
+
+* **컴포넌트 언마운트 시 메모리 누수 예방**
+  SPA(Single Page Application) 환경에서 컴포넌트 라이프사이클 주기를 이해하는 것은 메모리 누수 탐지 및 예방에 매우 중요합니다 [7]. 컴포넌트가 언마운트될 때 등록된 이벤트 리스너를 제거하지 않으면 참조가 계속 유지되어 가비지 컬렉션(Garbage Collection)이 이루어지지 않습니다 [3, 7]. 이를 방지하기 위해 React에서는 `useEffect`의 반환 함수에서 정리를 수행하고, Vue에서는 `beforeUnmount` 라이프사이클 단계에서 감시자(watchers)와 이벤트 리스너를 파괴하는 등 각 프레임워크의 라이프사이클에 맞춘 적절한 정리 패턴을 구현해야 합니다 [3].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[React Hooks]], [[useEffect]], [[Error Boundaries]], [[Memory Leaks]]
+- **Projects/Contexts:** [[Single Page Applications (SPAs)]], [[Frontend Performance Optimization]]
+- **Contradictions/Notes:** 제공된 소스에서는 라이프사이클의 모든 단계를 포괄적으로 설명하기보다는, 주로 함수형 컴포넌트의 마운트 해제 시 메모리 누수 방지(useEffect의 cleanup)와 클래스형 컴포넌트의 에러 핸들링(Error Boundaries) 맥락에서 라이프사이클의 특정 측면을 집중적으로 다루고 있습니다.
+
+---
+*Last updated: 2026-04-26*
@@ -0,0 +1,23 @@
+# [[Scalable React Architecture]]
+
+## 📌 Brief Summary
+확장 가능한 리액트 아키텍처(Scalable React Architecture)는 애플리케이션의 복잡성 증가, 팀의 확장, 장기적인 유지보수 요구를 원활하게 수용할 수 있도록 프론트엔드 시스템을 설계하는 방법론입니다 [1-4]. 단순한 파일 유형별 폴더 구성을 넘어 기능(Feature) 또는 도메인 기반의 구조인 기능 분할 설계(Feature-Sliced Design)를 채택하는 방향으로 진화해 왔습니다 [5, 6]. 이 아키텍처는 명시적인 경계 설정, 결합도 감소, 일관된 명명 규칙 적용 및 적절한 상태 관리를 통해 높은 성능과 개발 속도를 유지하는 것을 목표로 합니다 [3, 6-12].
+
+## 📖 Core Content
+
+*   **아키텍처의 필요성과 실패 요인:** 리액트 앱이 커질수록 비즈니스 로직이 UI 컴포넌트로 새어나가거나, 상태 소유권이 불분명해지고, 기능 간 암묵적인 의존성이 생기는 문제가 흔히 발생합니다 [2, 13]. 확장 가능한 아키텍처는 결합도(Coupling)를 낮추고 응집도(Cohesion)를 높이며, 모듈과 퍼블릭 API의 명확한 경계를 설정하여 인지 부하를 줄이고 안전한 성장을 가능하게 합니다 [3].
+*   **폴더 구조의 진화 (유형 기반에서 기능 기반으로):** 컴포넌트, 훅, 서비스를 각각의 폴더로 모아두는 전통적인 파일 유형 기반 구조는 단일 기능을 수정할 때 여러 폴더를 오가야 하므로 대규모 확장에 불리합니다 [7, 14-16]. 2025년 기준의 모던 리액트 프로젝트는 연관된 컴포넌트, 훅, 로직, 타입을 하나의 도메인/기능 폴더 내에 배치하는 기능 기반(Feature-Based) 구조를 권장합니다 [6, 16, 17].
+*   **기능 분할 설계 (Feature-Sliced Design, FSD):** FSD는 프론트엔드 애플리케이션을 위해 설계된 아키텍처 방법론으로, 코드를 기술적 유형이 아닌 범위(Scope)와 책임(Responsibility)에 따라 구성합니다 [5, 18, 19]. 앱(app) -> 페이지(pages) -> 위젯(widgets) -> 기능(features) -> 엔티티(entities) -> 공유(shared)로 이어지는 계층 모델을 가지며, 상위 계층이 하위 계층에만 의존할 수 있는 단방향 의존성 규칙을 엄격히 적용합니다 [8, 9, 18]. 또한 각 슬라이스는 단일 진입점(`index.ts`)만을 노출하는 '퍼블릭 API 규칙'을 통해 내부 구현을 캡슐화합니다 [20-22].
+*   **클린 코드 및 SOLID 원칙 적용:** 리액트 컴포넌트의 유지보수성을 높이려면 SOLID, DRY, KISS, YAGNI와 같은 소프트웨어 공학 원칙이 필요합니다 [21, 23-26]. 예를 들어 단일 책임 원칙(SRP)에 따라 컴포넌트가 300줄을 넘어가면 여러 개의 작은 컴포넌트로 분리해야 하며, 반복되는 로직은 커스텀 훅으로 추출(DRY)하여 단순하게 유지(KISS)해야 합니다 [23, 25, 27, 28].
+*   **상태 관리와 성능 최적화:** 확장 가능한 아키텍처에서는 상태를 지역 상태, 전역 애플리케이션 상태, 서버 캐시 상태 등으로 엄격히 구분합니다 [29, 30]. 자주 변경되는 상태를 기본 Context API로 관리하면 불필요한 리렌더링 폭풍(Re-render storm)이 발생할 수 있으므로, 상태 슬라이스를 선택(Selector)할 수 있는 Zustand나 대규모 팀에 적합한 Redux 같은 전문 도구를 사용하는 것이 성능에 유리합니다 [31-34]. 더불어 Vite의 `manualChunks`나 `React.lazy`를 이용한 코드 스플리팅을 통해 초기 번들 크기를 줄이는 것도 핵심 전략입니다 [35-38].
+*   **명명 규칙 및 거버넌스(Governance):** 확장되는 팀 내 혼란을 막기 위해 엄격한 폴더 및 파일 명명 규칙이 적용됩니다. 리액트 컴포넌트는 PascalCase, 일반 파일/폴더는 OS 호환성을 위해 kebab-case, 훅과 유틸리티 함수는 camelCase를 사용합니다 [39-44]. 또한 ESLint, Prettier, Husky 같은 도구를 통해 아키텍처 규칙과 포맷팅을 CI/CD 파이프라인에서 자동 강제(Governance)합니다 [45, 46].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Feature-Sliced Design]], [[Clean Code and SOLID Principles]], [[Frontend Folder Structure]], [[React State Management]], [[Frontend Performance Optimization]]
+- **Projects/Contexts:** [[Bulletproof React]] (생산 환경에 적합한 단순하고 확장 가능한 리액트 아키텍처 베스트 프랙티스를 모아둔 오픈소스 레퍼런스 [10])
+- **Contradictions/Notes:** 
+  - 기능 기반 구조(Feature-Based Structure)가 확장성 측면에서 매우 권장되지만, 매우 작은 소규모 프로젝트나 초보자에게는 오버엔지니어링(Overkill)일 수 있으며 초기에는 플랫(Flat) 구조가 적합할 수 있습니다 [15, 47].
+  - Context API는 추가 의존성 없이 상태를 공유할 수 있어 유용하지만, 자주 변경되는 데이터에 사용할 경우 성능이 심각하게 저하되므로 Zustand나 Redux로 대체해야 한다는 명확한 제약 사항이 여러 소스에서 강조됩니다 [31, 33, 34, 48].
+
+---
+*Last updated: 2026-04-26*
@@ -0,0 +1,25 @@
+# [[Sentry/LogRocket Monitoring]]
+
+## 📌 Brief Summary
+Sentry와 LogRocket은 프론트엔드 애플리케이션에서 발생하는 에러를 추적하고 사용자 세션을 모니터링하여 프로덕션 환경의 디버깅을 돕는 대표적인 클라우드 기반 모니터링 도구입니다 [1-3]. Sentry는 지능형 에러 그룹화와 에러 발생까지의 경로(Breadcrumb)를 추적하는 등 개발자 중심의 에러 관리에 탁월한 반면, LogRocket은 Redux 상태 변화와 전체 DOM을 포함하는 고해상도 세션 리플레이 기능에 특화되어 있습니다 [2, 4, 5]. 두 도구 모두 복잡한 분산 프론트엔드 시스템의 가시성(Observability)을 확보하고 신속하게 근본 원인을 파악하는 데 필수적인 역할을 합니다 [5, 6].
+
+## 📖 Core Content
+**Sentry: 개발자 중심의 에러 트래커 (Developer-First Error Tracker)**
+*   **핵심 기능:** Sentry의 가장 큰 강점은 '지능형 에러 그룹화(Intelligent error grouping)'입니다 [2]. 중복되는 에러의 홍수 속에서 유사한 에러를 자동으로 묶어 고유한 문제에 집중할 수 있게 해줍니다 [2, 5]. 또한 '이동 경로(Breadcrumb trail)' 기능을 통해 콘솔 로그, 네트워크 요청, 사용자 상호작용 등 에러 발생 전까지의 정확한 이벤트 시퀀스를 캡처합니다 [2].
+*   **장단점:** 넉넉한 무료 티어를 제공하며 100개 이상의 SDK 통합을 지원하여 개발자 경험이 매우 뛰어납니다 [7]. NextJS 환경 기준 회원가입부터 첫 에러 캡처까지 약 8분밖에 걸리지 않을 정도로 설정이 직관적입니다 [8]. 반면 대규모 사용자 기반으로 확장 시 에러, 리플레이, 성능 모니터링 등에 대한 다중 미터링 요금제가 복잡해질 수 있으며, 세션 리플레이 기능은 전문 도구에 비해 성숙도가 낮습니다 [7]. 최근에는 Sentry MCP 기능을 도입하여 단순 에러 복사를 넘어 실제 프로덕션 컨텍스트를 기반으로 한 스마트 디버깅과 수정 제안 기능을 추가하고 있습니다 [9].
+
+**LogRocket: 세션 리플레이 선구자 (The Session Replay Pioneer)**
+*   **핵심 기능:** 단순한 에러 로깅을 넘어 모든 사용자 세션을 화면 녹화기처럼 기록합니다 [3]. 전체 DOM, Redux/Vuex 상태 변경, 헤더 및 응답이 포함된 네트워크 요청, 성능 지표까지 상세하게 캡처하여 복잡한 버그를 디버깅할 때 최고의 컨텍스트를 제공합니다 [4, 5].
+*   **장단점:** 고해상도 세션 리플레이와 상태(State) 검사 기능은 독보적이지만, 기본적으로 "모든 것을 캡처"하는 방식을 취하고 있어 민감한 데이터를 가리는(Redact) 프라이버시 설정 작업에 많은 시간이 소요됩니다 [4, 10]. 또한 Sentry에 비해 애플리케이션 번들 크기에 미치는 성능 영향이 더 크고, 대규모 사용 시 월 69달러에서 수천 달러까지 비용이 비싸지는 단점이 있습니다 [10, 11].
+
+**도입 시 성능 및 개인정보 보호 고려사항**
+*   로깅 도구를 선택할 때는 단순히 스티커 가격뿐만 아니라 번들 크기로 인한 성능 저하(추가 로드 시간 발생)와 프라이버시 설정에 들어가는 팀의 시간을 총 비용으로 고려해야 합니다 [12, 13].
+*   민감한 데이터를 자동으로 마스킹하는 개인정보 보호 기능이 기본적으로 적용되는 도구를 선택하는 것이 프라이버시 규제가 강화되는 현재 환경에서 필수적입니다 [12].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Error Handling]], [[Performance Optimization]], [[Observability]], [[Debugging Frontend Applications]]
+- **Projects/Contexts:** [[Scalable Frontend Systems]], [[Production Monitoring]]
+- **Contradictions/Notes:** 소스에 따르면 Sentry는 설정이 빠르고 초기 비용(무료 티어) 면에서 단순 로깅 요구사항에 가장 적합한 옵션으로 꼽히는 반면, LogRocket은 세션과 상태에 대한 압도적인 컨텍스트를 제공하지만 번들 크기에 미치는 성능 악영향과 기본 설정에서의 프라이버시 침해 우려(모든 것 캡처)라는 상반된 트레이드오프를 가지고 있습니다 [7, 10, 12, 14].
+
+---
+*Last updated: 2026-04-26*
@@ -1,29 +1,31 @@
 ---
-id: SYS-COMP-ADA-001
+id: SYS-COMP-ACC-GLOBAL-001
 category: "[[10_Wiki/💡 Topics/AI]]"
 confidence_score: 1.0
-tags: [accessibility, compliance, ada, wcag, pour-principles, inclusive-design, digital-governance]
+tags: [accessibility, compliance, ada, eaa, wcag-2-2, pour-principles, digital-inclusive, legal-risk]
 last_reinforced: 2026-04-26
 ---

-# [[ADA Website Compliance (ADA 웹사이트 규정 준수)]]
+# [[ADA and EAA Accessibility Compliance (글로벌 디지털 접근성 규정 준수)]]

 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> "장애 유무와 관계없이 모든 인간이 디지털 공간의 정보를 공평하게 소유하게 하고, 기술적 표준(WCAG)을 통해 법적 리스크를 비즈니스 신뢰도로 전환하라" — 미국 장애인법(ADA)을 기반으로 한 디지털 콘텐츠의 보편적 접근성 보장 체계.
+> "디지털 장벽을 허물어 모든 인간의 평등한 정보 접근권을 보장하고, ADA(미국)와 EAA(유럽)라는 강력한 법적 표준을 통해 글로벌 비즈니스의 윤리적/법적 정당성을 확보하라" — WCAG 2.2를 기반으로 한 웹 및 모바일 접근성의 글로벌 통합 가이드라인.

 ## 📖 구조화된 지식 (Synthesized Content)
- **추출된 패턴:** "Universal Access and Regulatory Alignment" — 민권법인 ADA와 기술 표준인 WCAG(최소 Level AA)를 결합하여, 모든 사용자의 '인식, 운용, 이해, 견고성'을 보장하는 인클루시브 디자인 패턴.
- **핵심 원칙 (POUR Principles):**
-    - **Perceivable (인식의 용이성):** 이미지 대체 텍스트(Alt Text) 제공, 영상 자막 탑재 등 정보의 감각적 인식 보장.
-    - **Operable (운용의 용이성):** 키보드 전용 탐색 보장, 충분한 조작 시간 제공, 발작 유발 콘텐츠 배제.
-    - **Understandable (이해의 용이성):** 텍스트 가독성 확보, 예측 가능한 UI 동작, 입력 오류 수정 지원.
-    - **Robust (견고성):** 보조 기술(화면 판독기 등) 및 최신 브라우저와의 높은 호환성 유지.
- **의의:** 차별 없는 정보 접근권이라는 사회적 가치 실현과 동시에, 접근성 소송(Lawsuits)으로부터 비즈니스를 보호하고 검색 엔진 최적화(SEO) 효과를 덤으로 얻는 전략적 필수 요건.
+- **추출된 패턴:** "Harmonized Global Standards and Proactive Inclusivity" — 미국(ADA)의 WCAG 2.1 AA 권고와 유럽(EAA 2025)의 EN 301 549 표준을 통합하여, 코드 레벨에서부터 보편적 설계(Universal Design)를 관철시키는 패턴.
+- **글로벌 규제 현황:**
+    - **ADA (Americans with Disabilities Act):** 미국 내 모든 디지털 콘텐츠의 접근성 의무화. 최근 소송 건수 급증 추세.
+    - **EAA (European Accessibility Act):** 2025년 6월 발효. 유럽 내 전자상거래, 뱅킹 등 주요 서비스의 접근성 준수 강제.
+- **WCAG 2.2 핵심 업데이트 (2023):**
+    - **Focus Not Obscured:** 레이어 등에 의해 포커스 표시가 가려지지 않아야 함.
+    - **Dragging Movements:** 복잡한 드래그 동작에 대한 단일 클릭 대안 제공 필수.
+    - **Accessible Authentication:** 기억력에 의존하지 않는 로그인 방식(생체 인식 등) 권장.
+- **의의:** 장애인뿐만 아니라 고령자, 일시적 부상자, 저속 인터넷 사용자 등 모든 잠재 고객의 이탈을 방지하고 브랜드 가치를 고양함.

 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
- **과거 데이터와의 충돌:** 과거에는 '접근성 위젯(Overlay)'이 법적 방패가 될 것으로 오해했으나, 실제 정책상 이러한 위젯은 근본적 해결책이 아니며 소송의 타겟이 되고 있음. 코드를 근본적으로 수정하는 '네이티브 접근성' 정책이 유일한 정답임.
- **정책 변화:** Antigravity 프로젝트는 모든 UI 컴포넌트 개발 시 WCAG 2.1 AA 표준 감사를 빌드 파이프라인에 포함하며, 시각 장애인 에이전트의 접근성 시뮬레이션을 필수로 거치는 정책을 시행함.
+- **과거 데이터와의 충돌:** 과거에는 '접근성 위젯(Overlay)'이 법적 방패가 될 것으로 보았으나, 2025년 기준 소송의 22% 이상이 위젯 설치 사이트를 대상으로 함. 따라서 '코드 레벨의 직접 수정'만이 유일한 안전 정책임.
+- **정책 변화:** Antigravity 프로젝트는 모든 UI 컴포넌트에 대해 WCAG 2.2 AA 수동 테스트와 스크린 리더 검증을 의무화하며, 유럽 시장 진출을 위해 EAA 표준을 기본 아키텍처에 반영함.

 ## 🔗 지식 연결 (Graph)
- [[Web-Accessibility]], [[POUR-Principles]], [[Inclusive-Design]], [[SEO-Foundations]]
- **Raw Source:** [[00_Raw/ADA Website Compliance.md]]
+- [[Web-Accessibility]], [[POUR-Principles]], [[Inclusive-Design]], [[User-Centered-Design-Approach]]
+- **Raw Source:** [[00_Raw/ADA Website Compliance.md]], [[00_Raw/Accessibility Compliance (ADA-EAA).md]], [[00_Raw/Accessibility Compliance (WCAG).md]]
@@ -0,0 +1,28 @@
+---
+id: UX-AI-ADAPTIVE-001
+category: "[[10_Wiki/💡 Topics/AI]]"
+confidence_score: 1.0
+tags: [ux, ai, personalization, adaptive-ux, predictive-ux, progressive-disclosure, user-engagement]
+last_reinforced: 2026-04-26
+---
+
+# [[AI Personalization and Adaptive UX (AI 개인화 및 적응형 UX)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> "정적인 인터페이스를 사용자의 실시간 의도와 맥락에 반응하는 살아있는 유기체로 변모시키고, 개별 사용자에게 최적화된 최단 경로를 동적으로 제시하라" — AI와 데이터 분석을 통해 사용자별 맞춤형 경험을 실시간으로 구현하는 고도화된 UX 전략.
+
+## 📖 구조화된 지식 (Synthesized Content)
+- **추출된 패턴:** "Contextual Fluidity and Predictive Guidance" — 사용자의 과거 행동 데이터, 현재 세그먼트, 실시간 인터랙션을 분석하여 인터페이스의 구성 요소, 난이도, 기능을 동적으로 재구성하는 패턴.
+- **주요 구현 기법:**
+    - **Adaptive Learning Paths:** 학습자의 성취도에 따라 콘텐츠의 난이도와 진행 경로를 실시간으로 조정.
+    - **Progressive Disclosure:** 사용자의 숙련도나 역할에 따라 복잡한 기능을 단계적으로 노출하여 인지 과부하 방지.
+    - **Predictive Interfaces:** 다음에 필요할 것으로 예측되는 버튼이나 정보를 미리 강조하거나 배치.
+- **의의:** '모두를 위한 하나의 디자인(One-size-fits-all)'에서 벗어나, 초개인화(Hyper-personalization)를 통해 이탈률을 낮추고 전환율 및 고객 생애 가치(LTV)를 극대화함.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **과거 데이터와의 충돌:** 과거에는 정해진 규칙 기반(Rule-based)의 개인화에 머물렀으나, 현재는 실시간 머신러닝 모델이 사용자의 미세한 마이크로 인터랙션을 학습하여 즉각적으로 반응하는 '지능형 적응' 정책으로 진화함.
+- **정책 변화:** Antigravity 프로젝트는 '개인화와 프라이버시의 균형' 정책을 준수하며, 모든 개인화 데이터 수집 시 사용자에게 투명하게 고지하고 스스로 최적화 수준을 결정할 수 있는 옵션을 제공함.
+
+## 🔗 지식 연결 (Graph)
+- [[User-Centered-Design]], [[A-B-Testing-and-Data-Driven-UX]], [[Predictive-UX]], [[Micro-interactions]], [[Ethical-Decision-Making]]
+- **Raw Source:** [[00_Raw/AI 개인화 및 적응형 UX.md]], [[00_Raw/Adaptive UX.md]]
@@ -0,0 +1,29 @@
+---
+id: FE-STYLE-ATOMIC-001
+category: "[[10_Wiki/💡 Topics/AI]]"
+confidence_score: 1.0
+tags: [css, frontend, atomic-css, design-systems, tailwindcss, utility-first, scalability]
+last_reinforced: 2026-04-26
+---
+
+# [[Atomic Styling and Design Systems (아토믹 스타일링과 디자인 시스템)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> "스타일을 더 이상 '페이지' 단위로 설계하지 말고, 더 이상 쪼갤 수 없는 '원자(Utility)' 단위로 파편화하여 조합함으로써 전역 스타일의 오염을 방지하고 개발 속도를 무한히 확장하라" — Tailwind CSS 등으로 대변되는 유틸리티 퍼스트(Utility-first) 스타일링 패러다임.
+
+## 📖 구조화된 지식 (Synthesized Content)
+- **추출된 패턴:** "Composition Over Cascading" — CSS의 전통적인 상속(Cascading)과 복잡한 선택자 구조를 배제하고, 클래스 하나가 하나의 스타일 속성만을 담당하게 하여 컴포넌트 레벨에서 스타일을 조합하는 패턴.
+- **주요 특징:**
+    - **Single Responsibility Class:** `flex`, `p-4`, `text-center` 등 명확한 기능을 가진 클래스 사용.
+    - **No Side Effects:** 한 곳의 스타일 수정이 다른 곳에 영향을 주지 않는 격리된 환경 제공.
+    - **Minimal Bundle Size:** 사용된 유틸리티 클래스만 빌드 결과물에 포함하여 CSS 파일 크기 최소화.
+    - **Constraint-based Design:** 정의된 디자인 토큰(Spacing, Colors) 내에서만 스타일을 선택하게 강제하여 디자인 일관성 유지.
+- **의의:** 대규모 프로젝트에서 CSS의 복잡도를 선형적으로 유지하며, 디자인 시스템의 컴포넌트를 빠르고 안전하게 구축할 수 있게 함.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **과거 데이터와의 충돌:** 과거에는 HTML과 CSS의 분리(Separation of Concerns)를 지향했으나, 아토믹 스타일링 정책은 스타일과 구조를 한곳에 모으는 '결합(Co-location)'을 통한 유지보수 효율 정책으로 전향함.
+- **정책 변화:** Antigravity 프로젝트는 UI 개발 시 Tailwind CSS v4 기반의 아토믹 스타일링을 기본 정책으로 채택하며, 인라인 스타일 사용을 금지하고 오직 사전 정의된 원자 클래스만을 활용함.
+
+## 🔗 지식 연결 (Graph)
+- [[Design-System]], [[Tailwind-CSS-v4-도입]], [[Software-Architecture-Patterns]], [[Clean-Code-Principles]]
+- **Raw Source:** [[00_Raw/Atomic Styling.md]]
@@ -0,0 +1,29 @@
+---
+id: OPS-CICD-CORE-001
+category: "[[10_Wiki/💡 Topics/AI]]"
+confidence_score: 1.0
+tags: [devops, cicd, automation, continuous-integration, continuous-deployment, delivery-pipeline, reliability]
+last_reinforced: 2026-04-26
+---
+
+# [[CI/CD Pipeline Foundations (CI/CD 파이프라인 기초)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> "코드 변경이 사용자에게 도달하기까지의 전 과정을 자동화된 검증 루프로 연결하여, 배포의 리스크를 줄이고 개발의 속도를 물리적 한계까지 밀어붙여라" — 지속적 통합(CI)과 지속적 제공/배포(CD)를 통해 소프트웨어의 품질과 출시 속도를 극대화하는 현대 개발의 필수 인프라.
+
+## 📖 구조화된 지식 (Synthesized Content)
+- **추출된 패턴:** "Automated Verification and Incremental Delivery" — 코드가 커밋되는 순간부터 빌드, 테스트, 스테이징, 운영 환경 배포까지의 모든 수동 개입을 제거하고 가시성을 확보하는 패턴.
+- **파이프라인 구성 요소:**
+    - **Continuous Integration (CI):** 코드 병합 시 자동 빌드 및 유닛/통합 테스트 수행. 충돌을 조기에 발견.
+    - **Continuous Delivery:** 검증된 코드를 수동 승인 후 운영 환경에 배포 가능한 상태로 유지.
+    - **Continuous Deployment (CD):** 모든 테스트를 통과한 코드를 실제 사용자에게 자동으로 즉시 배포.
+    - **Quality Gates:** 린팅(Linting), 보안 스캔, 코드 커버리지 등의 지표가 충족되어야 다음 단계로 진행.
+- **의의:** 배포 주기를 단축(Daily or hourly)시키고, 장애 발생 시 롤백(Rollback) 시간을 최소화하여 비즈니스의 기민함과 시스템의 안정성을 동시에 확보함.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **과거 데이터와의 충돌:** 과거에는 정기적인 '배포일'을 정해 대규모 업데이트를 수행했으나, 현대 CI/CD 정책은 작고 잦은 배포(Small & Frequent)를 통해 리스크를 분산시키는 정책을 최우선으로 함.
+- **정책 변화:** Antigravity 프로젝트는 모든 저장소에 대해 'Pull Request 기반의 자동 CI'를 강제하며, 메인 브랜치 병합 시 즉시 에지(Edge) 환경에 배포되는 CD 파이프라인을 구축함.
+
+## 🔗 지식 연결 (Graph)
+- [[Software-Architecture-Patterns]], [[Technical-Debt-Management]], [[Cloud-Infrastructure]], [[Infrastructure-as-Code-IaC]]
+- **Raw Source:** [[00_Raw/CI-CD Pipeline.md]]
@@ -0,0 +1,31 @@
+---
+id: CS-RETAIL-ALLBIRDS-001
+category: "[[10_Wiki/💡 Topics/AI]]"
+confidence_score: 1.0
+tags: [case-study, ecommerce, allbirds, pwa, performance-optimization, sustainability, storytelling, conversion-rate]
+last_reinforced: 2026-04-26
+---
+
+# [[Case Study: Allbirds PWA Redesign (사례 연구: Allbirds PWA 리디자인)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> "기술적 고성능(PWA)과 가치 기반 스토리텔링(지속 가능성)을 제품 상세 페이지에 수평적으로 통합하여, 단순한 '구매'를 브랜드 미션에 대한 '동참'으로 승격시켜라" — 웹 성능 향상과 브랜드 가치 전달의 완벽한 조화를 통해 폭발적인 비즈니스 성장을 이뤄낸 이커머스 혁신 사례.
+
+## 📖 구조화된 지식 (Synthesized Content)
+- **핵심 과제:** 사용자 구매 흐름을 방해하지 않으면서 Allbirds의 핵심 가치인 '지속 가능성' 메시지를 효과적으로 전달하고, 모바일 로딩 속도를 획기적으로 개선하는 것.
+- **혁신적 UX/기술 전략:**
+    - **Value-Integrated UI:** 지속 가능성 지표를 '회사 소개' 페이지에 가두지 않고, 제품 기능 설명 바로 옆에 배치하여 고객 신뢰도와 투명성 확보.
+    - **PWA Architecture 도입:** 프로그레시브 웹 앱 기술을 활용하여 즉각적인(Near-instantaneous) 페이지 로딩 속도 구현.
+- **정량적 비즈니스 성과:**
+    - **Performance:** 페이지 로드 속도 **89% 향상**, 이탈률(Bounce Rate) **34% 감소**.
+    - **Conversion:** 환경 중시 소비자층의 전환율 **23% 증가**.
+    - **Revenue:** 리디자인 후 첫 분기에만 **230만 달러**의 추가 수익 창출.
+- **의의:** 웹 성능(Engineering)과 가치 전달(Branding)의 결합이 어떻게 직접적인 수익 창출로 이어지는지를 증명한 현대 이커머스의 벤치마킹 모델.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **과거 데이터와의 충돌:** 과거에는 고성능 이미지와 풍부한 스토리텔링이 속도 저하를 유발한다고 보았으나, Allbirds 사례는 PWA 기술을 통해 '풍부한 경험'과 '빠른 속도'가 양립 가능하다는 것을 증명함.
+- **정책 변화:** Antigravity 프로젝트는 모든 이커머스 관련 에이전트 설계 시 Allbirds의 '지점 통합형 가치 전달' 모델을 표준으로 채택하며, PWA를 기본 웹 앱 아키텍처로 강제함.
+
+## 🔗 지식 연결 (Graph)
+- [[Progressive-Web-App-PWA]], [[Conversion-Rate-Optimization-CRO]], [[Modern-Website-Architecture]], [[User-Experience-UX-Design]]
+- **Raw Source:** [[00_Raw/Allbirds E-commerce Redesign.md]], [[00_Raw/Allbirds PWA Redesign.md]]
@@ -0,0 +1,33 @@
+---
+id: PERF-CWV-CLS-001
+category: "[[10_Wiki/💡 Topics/AI]]"
+confidence_score: 1.0
+tags: [core-web-vitals, cls, performance, ux, visual-stability, frontend-optimization, seo]
+last_reinforced: 2026-04-26
+---
+
+# [[Cumulative Layout Shift: CLS (누적 레이아웃 이동)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> "사용자가 읽거나 클릭하려는 순간 콘텐츠가 춤추듯 이동하는 '시각적 불안정성'을 제거하고, 0.08초 이내의 고정된 안정감을 제공하여 인지적 마찰을 차단하라" — 페이지의 전체 수명 동안 발생하는 예기치 않은 레이아웃 이동을 측정하는 Core Web Vitals의 핵심 사용자 경험 지표.
+
+## 📖 구조화된 지식 (Synthesized Content)
+- **추출된 패턴:** "Predictive Space Allocation and Visual Isolation" — 콘텐츠가 로드되기 전에 브라우저가 필요한 공간을 미리 예약하여, 데이터 로딩 전후의 시각적 불일치를 제로로 만드는 패턴.
+- **CLS 발생의 주요 원인:**
+    - **Sizeless Images/Ads:** 크기가 지정되지 않은 이미지나 동적 광고가 로드되면서 주변 콘텐츠를 밀어냄.
+    - **Dynamic Content Injection:** 배너나 툴팁이 기존 콘텐츠 위쪽에 갑자기 삽입됨.
+    - **FOIT/FOUT:** 웹 폰트 로딩 지연으로 인한 텍스트 크기 및 줄바꿈 변경.
+- **CLS 최적화 전략:**
+    - **Explicit Dimensions:** 모든 미디어 요소에 `width`, `height` 또는 `aspect-ratio` 명시.
+    - **Placeholder Reservation:** 광고 및 동적 요소 슬롯에 `min-height`를 활용한 공간 확보.
+    - **CSS Transform:** 위치 이동 애니메이션 시 레이아웃 재계산을 유발하지 않는 `transform` 속성 사용.
+    - **Font Display:** `font-display: swap` 설정을 통해 텍스트 구조 변동 최소화.
+- **의의:** 시각적 안정성을 확보함으로써 오클릭(Misclick)을 방지하고, 검색 엔진 랭킹 점수를 높이며 사용자의 신뢰도를 향상시킴.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **과거 데이터와의 충돌:** 과거에는 CLS 우수 기준이 0.1이었으나, 2025년 Google 정책 업데이트를 기점으로 0.08 미만(25% 강화)으로 더욱 엄격해짐.
+- **정책 변화:** Antigravity 프로젝트는 모든 UI 컴포넌트에 대해 'Zero Layout Shift' 정책을 강제하며, 빌드 타임에 이미지 크기 미지정 요소를 자동 검출하여 오류를 발생시키는 정책을 시행함.
+
+## 🔗 지식 연결 (Graph)
+- [[Core-Web-Vitals]], [[LCP-Largest-Contentful-Paint]], [[INP-Interaction-to-Next-Paint]], [[Web-Performance-Optimization]], [[SEO-Foundations]]
+- **Raw Source:** [[00_Raw/CLS (Cumulative Layout Shift).md]]
@@ -0,0 +1,29 @@
+---
+id: FE-NEXT-APP-ROUTER-001
+category: "[[10_Wiki/💡 Topics/AI]]"
+confidence_score: 1.0
+tags: [nextjs, react, app-router, server-components, ssr, partial-rendering, web-architecture]
+last_reinforced: 2026-04-26
+---
+
+# [[Next.js App Router Architecture (Next.js 앱 라우터 아키텍처)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> "서버 중심의 라우팅 아키텍처를 통해 클라이언트 JavaScript 번들을 최소화하고, 서버 컴포넌트(RSC)를 기반으로 데이터 페칭과 렌더링의 패러다임을 재정립하라" — React Server Components를 기본으로 채택하여 웹 성능과 개발자 경험을 동시에 혁신한 Next.js의 차세대 라우팅 시스템.
+
+## 📖 구조화된 지식 (Synthesized Content)
+- **추출된 패턴:** "Server-First Rendering and Granular Hydration" — 모든 컴포넌트를 기본적으로 서버에서 렌더링하고 필요한 인터랙션 부분만 클라이언트 컴포넌트로 선언하여, 클라이언트로 전송되는 JS 양을 획기적으로 줄이는 패턴.
+- **주요 핵심 기술:**
+    - **React Server Components (RSC):** 서버에서만 실행되어 클라이언트 번들에 포함되지 않는 컴포넌트. 직접적인 DB 접근 가능.
+    - **Streaming & Suspense:** 전체 페이지가 준비될 때까지 기다리지 않고, 렌더링된 조각(Chunk)을 점진적으로 클라이언트에 전송.
+    - **Layouts & Nested Routing:** 상태를 유지하면서 UI의 특정 부분만 업데이트하는 계층적 구조 지원.
+    - **Caching & Revalidation:** 데이터 요청을 자동으로 메모이제이션하고 전략적으로 갱신(ISR 등).
+- **의의:** 기존 Pages Router의 한계를 넘어 복잡한 데이터 의존성을 가진 대규모 애플리케이션에서도 최상의 LCP와 TTI를 보장함.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **과거 데이터와의 충돌:** 과거 Pages Router에서는 `getServerSideProps`를 통해 최상단에서만 데이터를 가져왔으나, App Router 정책은 컴포넌트 레벨에서 비동기(async/await)로 데이터를 직접 페칭하는 정책으로 전환됨.
+- **정책 변화:** Antigravity 프로젝트는 모든 신규 대시보드 및 웹 엔진 구축 시 App Router 아키텍처를 표준으로 채택하며, 클라이언트 컴포넌트 사용을 최소화하여 성능 임계치를 관리함.
+
+## 🔗 지식 연결 (Graph)
+- [[Web-Rendering-Strategies-CSR-vs-SSR]], [[Server-Side-Rendering-SSR]], [[React-Architecture]], [[Performance-Optimization]]
+- **Raw Source:** [[00_Raw/App Router.md]]
@@ -0,0 +1,29 @@
+---
+id: FE-DS-BASEWEB-001
+category: "[[10_Wiki/💡 Topics/AI]]"
+confidence_score: 1.0
+tags: [uber, baseweb, design-system, react, overrides-pattern, styletron, scalability, accessibility]
+last_reinforced: 2026-04-26
+---
+
+# [[Uber Base Web Design System (우버 베이스 웹 디자인 시스템)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> "수백 개의 내부 앱을 일관된 디자인 언어로 통합하고, '오버라이드(Overrides)' 패턴을 통해 컴포넌트의 유연성과 API의 간결함 사이의 모순을 해결하라" — 우버에서 개발한, 극도의 커스터마이징과 접근성을 보장하는 엔터프라이즈급 React UI 프레임워크.
+
+## 📖 구조화된 지식 (Synthesized Content)
+- **추출된 패턴:** "Granular Override and Observability-driven Governance" — 컴포넌트 내부의 모든 하위 요소에 접근할 수 있는 고유한 오버라이드 인터페이스를 제공하고, 시스템의 채택률을 데이터로 측정하여 디자인 품질을 관리하는 패턴.
+- **핵심 혁신 요소:**
+    - **Overrides Pattern:** 'Prop Soup' 문제를 해결하기 위해 컴포넌트의 스타일과 구조를 하위 요소 단위로 정밀하게 조정할 수 있는 단일 prop 제공.
+    - **Styletron Integration:** 런타임에 아토믹 CSS를 생성하여 성능을 최적화하고 스타일 충돌 방지.
+    - **Design Observability:** 'Base Counter' 도구를 통해 실제 프로젝트에서의 컴포넌트 사용 비율을 측정하고 디자인 거버넌스 구현.
+    - **Native Accessibility:** 키보드 내비게이션, 화면 판독기 호환성 및 ARIA 역할을 기본적으로 완벽 지원.
+- **의의:** 대규모 조직에서 개발 속도를 3배 향상시키고 시각적 불일치를 4배 감소시키는 등, 엔지니어링 효율성과 디자인 일관성의 양립 가능성을 증명함.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **과거 데이터와의 충돌:** 과거 UI 라이브러리는 모든 요구사항을 별도의 Prop으로 처리하려 했으나, Base Web 정책은 '오버라이드'라는 단일 통로를 통해 무한한 확장성을 제공하는 정책으로 전환함.
+- **정책 변화:** Antigravity 프로젝트는 복잡한 SaaS 대시보드 구축 시 Base Web의 오버라이드 철학을 참고하며, 모든 디자인 시스템 컴포넌트에 대해 '사용자 정의 가능성(Customizability)' 점수를 매겨 관리함.
+
+## 🔗 지식 연결 (Graph)
+- [[Design-System]], [[Atomic-Styling-and-Design-Systems]], [[Web-Accessibility]], [[Reusable-UI-Components]], [[Scalable-UI-Systems]]
+- **Raw Source:** [[00_Raw/Base Web.md]]
@@ -0,0 +1,29 @@
+---
+id: FE-REND-STRAT-001
+category: "[[10_Wiki/💡 Topics/AI]]"
+confidence_score: 1.0
+tags: [csr, ssr, rendering, web-architecture, seo, lcp, hydration, hybrid-rendering]
+last_reinforced: 2026-04-26
+---
+
+# [[Web Rendering Strategies: CSR vs SSR (웹 렌더링 전략: CSR vs SSR)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> "초기 로딩의 속도(SSR)와 인터랙션의 매끄러움(CSR) 사이에서 비즈니스 목적에 최적화된 지점을 선택하고, 하이브리드 접근법을 통해 검색 엔진과 사용자 모두를 만족시켜라" — 웹 애플리케이션의 성능, SEO, 사용자 경험을 결정짓는 핵심 아키텍처 선택 가이드.
+
+## 📖 구조화된 지식 (Synthesized Content)
+- **추출된 패턴:** "Purpose-driven Rendering Allocation" — 검색 노출이 중요한 공용 페이지는 SSR로, 복잡한 상태 관리가 필요한 대시보드는 CSR로 할당하거나, 이를 혼합하여 사용하는 패턴.
+- **렌더링 방식 비교:**
+    - **CSR (Client-Side Rendering):** 브라우저에서 JS로 UI 구성. SPA에 적합하며 매끄러운 화면 전환 제공. 단, 초기 로드 속도가 느리고 SEO에 불리함.
+    - **SSR (Server-Side Rendering):** 서버에서 완성된 HTML 전송. 초기 LCP가 빠르고 SEO에 매우 유리함. 단, 서버 부하 증가 및 수화(Hydration) 지연 가능성 존재.
+    - **SSG (Static Site Generation):** 빌드 타임에 정적 파일 생성. 가장 빠른 성능 제공. 정적 마케팅 페이지에 최적.
+- **핵심 지표 영향:** SSR은 LCP(최대 콘텐츠 페인팅)를 개선하는 반면, CSR은 TTI(상호작용 시작 시간) 이후의 탐색 경험을 강화함.
+- **의의:** 기술적 제약을 넘어 비즈니스 수익(전환율)과 직결되는 최적의 렌더링 전략을 수립할 수 있게 함.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **과거 데이터와의 충돌:** 과거에는 CSR과 SSR 중 하나를 선택하는 이분법적 논리가 지배적이었으나, 현재 정책은 Next.js 등 프레임워크를 활용해 페이지/컴포넌트 단위로 렌더링 방식을 혼합하는 '하이브리드/아일랜드 아키텍처' 정책으로 진화함.
+- **정책 변화:** Antigravity 프로젝트는 모든 공용 콘텐츠에 대해 'SSR-First'를 원칙으로 하며, 인증된 영역에 한해 'CSR-Hydration' 전략을 부분적으로 허용함.
+
+## 🔗 지식 연결 (Graph)
+- [[Core-Web-Vitals]], [[Nextjs-App-Router-Architecture]], [[Single-Page-Application-SPA]], [[SEO-Foundations]], [[Server-Side-Rendering-SSR]]
+- **Raw Source:** [[00_Raw/Client-Side Rendering (CSR) vs Server-Side Rendering (SSR).md]]