diff --git a/00_Raw/A2A (Agent-to-Agent).md b/00_Raw/A2A (Agent-to-Agent).md
new file mode 100644
index 00000000..2fcef8a8
--- /dev/null
+++ b/00_Raw/A2A (Agent-to-Agent).md	
@@ -0,0 +1,62 @@
+# [[A2A (Agent-to-Agent)]]
+
+## 📌 Brief Summary
+A2A (Agent-to-Agent)는 독립적인 AI 에이전트들 사이 또는 서로 다른 에이전트 하니스(Agent Harness) 간의 원격 작업 위임, 통신 및 조정을 표준화하기 위해 설계된 오픈 프로토콜이다 [1-5]. 2025년 Google에 의해 도입된 이 프로토콜은 HTTPS와 Server-Sent Events(SSE)를 전송 계층으로 활용하여 장기 실행 작업의 진행 상황 스트리밍과 상태 유지(Stateful) 상호작용을 지원한다 [1, 3, 6-8]. 주로 실행 루프(E-component)의 다중 에이전트 오케스트레이션 기능을 지원하며, 에이전트가 다른 에이전트의 내부 구현을 알 필요 없이 안전하게 하위 작업을 위임할 수 있도록 돕는다 [2, 4].
+
+## 📖 Core 소스 Content
+**프로토콜 아키텍처 및 통신 모델**
+A2A는 HTTPS와 Server-Sent Events(SSE)를 통해 원격 에이전트 간의 피어투피어(Peer-to-Peer) 수준 통신을 지원한다 [1, 3, 9, 10]. 기본적으로 상태 유지 세션(Stateful sessions)과 작업 ID 관리를 지원하여 원격 에이전트가 긴 시간 동안 처리해야 하는 작업의 진행 상황을 비동기적으로 스트리밍할 수 있다 [6-8]. 또한 메시지와 아티팩트를 명시적으로 분리하여, 결과물을 단순한 채팅 메시지가 아닌 구조화된 작업 아티팩트(Task Artifact) 형태로 반환하도록 규정한다 [8].
+
+**발견(Discovery) 메커니즘 및 통합 경계**
+A2A 프로토콜을 사용하는 하니스는 '에이전트 카드(Agent Card)'를 통해 자신이 호스팅하는 에이전트의 기능(Capabilities)과 통신 인터페이스를 명시적으로 선언한다 [2, 4, 5, 8]. 이를 통해 위임하는 에이전트(Delegating agent)는 동적으로 작업에 적합한 외부 에이전트를 검색하고 위임할 수 있다 [5]. 이 과정에서 A2A는 에이전트와 도구 간 통신을 담당하는 MCP(Model Context Protocol)와 상호보완적 스택을 형성한다 [11-14]. 즉, 하니스와 하니스 간의 통신은 A2A가 담당하고, 하니스 내부의 도구 호출은 MCP가 담당하여 시스템의 역할 분리를 명확히 한다 [12, 14].
+
+**보안, 위임 및 거버넌스(Governance)**
+A2A는 임시방편적인 메시지 전달이 아닌, 명확한 작업 경계, 권한 부여 범위(Authorization scopes), 완료 신호 등을 갖춘 감사 가능한(Auditable) 통신을 제공한다 [15, 16]. OAuth 흐름과 HTTPS 강제화를 통해 보안 모델의 완성도를 높였으며 [6, 7], 엔터프라이즈 환경에서는 고위험 에이전트와 저위험 에이전트 간의 위임 경계를 통제하기 위한 신뢰 경계(Trust boundaries) 및 위임 체인의 깊이 제한(Depth limits) 설정이 강제된다 [17-19].
+
+## ⚖️ Trade-offs & Caveats
+A2A의 통신 방식은 네트워크 기반(HTTPS/SSE)이므로, 교차 네트워크 에이전트 위임 시 최소 50~200ms의 대기 시간(Latency)이 발생한다 [6, 7]. 이는 하니스 로컬 내부에서 도구를 호출하는 MCP(2~15ms 대기 시간)와 비교할 때 상대적으로 느린 속도이므로, 지연 시간에 민감한 단일 하니스 내 통합 작업보다는 분산된 에이전트 간의 원격 위임에 제한적으로 사용하는 것이 적합하다 [6, 7].
+
+또한, 에이전트 간 통신은 '교차 에이전트 프롬프트 인젝션(Cross-agent prompt injection)'이라는 새로운 보안 취약점을 야기할 수 있다 [20, 21]. 손상된 에이전트가 A2A 메시지 버스를 통해 동료 에이전트에게 악의적인 지시를 보낼 수 있으므로, 하니스 계층에서 메시지 스키마 유효성 검사 및 에이전트 신원 확인(Agent identity verification) 메커니즘을 엄격하게 구현해야 한다 [20, 21]. 마지막으로, A2A 작업 위임 시 포함된 권한 정보가 수신 측 하니스의 내부 MCP 도구 권한으로 어떻게 번역되어야 하는지에 대한 통합 경계 표준이 아직 불명확하여, 배포 시 추가적인 통합 코드가 요구된다는 제약이 있다 [12, 14].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [아키텍처/기반 기술]
+- [[Agent Harness]]
+  - 연결 이유: A2A 통신을 중재하고 상태 일관성, 접근 제어, 권한 부여 등의 거버넌스를 런타임에 집행하는 기반 인프라이다 [2, 4, 22].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 다중 에이전트 환경에서 에이전트의 자율적 통신이 어떻게 하니스의 통제(E-component의 오케스트레이션 및 L-component의 라이프사이클 훅) 아래에서 안전하게 관리되는지 이해할 수 있다 [2, 4, 23].
+
+- [[Model Context Protocol (MCP)]]
+  - 연결 이유: 에이전트와 외부 시스템/도구를 연결하는 표준으로, 에이전트 간 연결을 담당하는 A2A와 결합하여 전체 에이전트 통신 스택(Communication Stack)을 형성한다 [5, 11, 13].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 하니스 인프라 내에서 도구 호출(MCP)과 작업 위임(A2A)이 어떻게 아키텍처적으로 분리되고 상호 작용하는지, 그 책임의 경계를 명확히 이해할 수 있다 [12, 14].
+
+- [[Multi-Agent Orchestration]]
+  - 연결 이유: 다수의 에이전트가 특정 작업을 완수하기 위해 토폴로지(Topology)를 구성하고 협력하는 프로세스로, A2A는 이를 네트워크를 넘어 원격으로 구현하는 핵심 기술이다 [2, 4, 5, 17].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 단일 에이전트의 실행 루프를 넘어, 에이전트의 신원 관리, 메시지 유효성 검사 및 공유 상태의 일관성 보장과 같은 복합적인 거버넌스 과제를 파악할 수 있다 [2, 4, 24, 25].
+
+#### [구현/활용 도구]
+- [[Agent Card]]
+  - 연결 이유: A2A 프로토콜 내에서 각 에이전트가 자신의 기능, 역할, 통신 인터페이스를 정의하고 선언하는 검색 메커니즘(Discovery mechanism)이다 [2, 4, 8].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 원격 하니스에 위치한 에이전트들이 사전에 내부 구조를 알지 못하더라도, 어떻게 동적으로 기능을 검색하고 작업을 요청할 수 있는지 그 원리를 파악할 수 있다 [2, 4, 5].
+
+### Deeper Research Questions
+- A2A가 제공하는 작업 사양(Task Specification) 및 권한 모델은 하니스 내부의 도구 실행 계층인 MCP의 세분화된 접근 권한(Permissions)으로 어떻게 매핑되고 변환되는가?
+- 교차 에이전트 프롬프트 인젝션(Cross-agent prompt injection) 공격을 방어하기 위해 A2A 메시지 버스와 하니스 정책 엔진은 어떤 수준의 스키마 유효성 검사와 신원 인증을 구현해야 하는가?
+- A2A 위임 체인(Delegation Chain)에서 발생할 수 있는 무한 루프나 교착 상태(Deadlock)를 방지하기 위해 오케스트레이터 에이전트는 어떤 관측 가능성(Observability) 및 강제 종료 알고리즘을 갖추어야 하는가?
+- IBM의 ACP(Agent Communication Protocol)가 정의하는 의도(Intent) 통신과 A2A의 작업 위임(Task Delegation) 통신은 상호 배타적인가, 아니면 단일 에이전트 시스템 내에서 계층화되어 통합될 수 있는가?
+- 원격 하니스 간 A2A 스트리밍(SSE 기반) 대기 시간(Latency)은 음성 에이전트나 실시간 응답이 필요한 에이전틱 애플리케이션의 아키텍처 설계에 어떤 제약을 가하는가?
+
+### Practical Application Contexts
+- **Implementation:** Google의 A2A 표준 명세에 따라 하니스 인프라에 HTTPS 및 SSE 기반의 엔드포인트를 구현하여, 원격 에이전트에 장기 실행 작업을 위임하고 아티팩트 형태의 결과물과 비동기 진행 스트림을 수신한다 [2, 6-8].
+- **System Design:** 에이전트 통신 스택 설계 시, 내부 도구 접근은 지연 시간이 짧은 MCP 어댑터에 맡기고, 다른 서브 시스템이나 원격 에이전트로의 위임은 A2A 어댑터를 사용하도록 아키텍처의 책임을 명확히 분리한다 [26, 27].
+- **Operation / Maintenance:** 다중 에이전트 연합 환경에서 A2A 호출 트랜잭션, 위임 깊이, 권한 범위를 중앙 하니스 관리 도구(예: Agent 365, Admin Center)에 기록하여 연쇄적 오류나 에이전트 오남용을 모니터링한다 [17, 19, 28].
+- **Learning Path:** 단일 에이전트 하니스의 구성(시스템 프롬프트, 도구 레지스트리)을 먼저 학습한 후, 분산 에이전트 시스템에서 A2A 에이전트 카드를 통한 서비스 검색 및 OAuth2 기반의 신원 확인 방식을 학습한다 [2, 6, 7].
+- **My Project Relevance:** 복합적인 엔터프라이즈 워크플로우를 자동화하기 위해 각 부서의 특화 에이전트(인사, 재무, IT 등)가 서로의 데이터를 안전하게 요청하고 작업을 위임해야 할 때, A2A 프로토콜을 도입하여 각자의 하니스 격리성을 유지하면서도 표준화된 소통 채널을 구축하는 데 활용할 수 있다.
+
+### Adjacent Topics
+- [[Agent Communication Protocol (ACP)]]
+  - 확장 방향: 작업 위임 및 아티팩트 생성에 초점을 맞춘 A2A와 달리, 고수준의 대화(Dialogue) 및 의도(Intent) 전달을 목표로 하는 ACP의 차이점과 하니스 통신 스택 내에서의 계층적 관계를 비교 연구한다 [1, 3, 29, 30].
+
+---
+*Last updated: 2026-05-01*
\ No newline at end of file
diff --git a/00_Raw/Agent Harness.md b/00_Raw/Agent Harness.md
new file mode 100644
index 00000000..8a602ef4
--- /dev/null
+++ b/00_Raw/Agent Harness.md	
@@ -0,0 +1,84 @@
+# [[Agent Harness]]
+
+## 📌 Brief Summary
+**AI 에이전트 하네스(Agent Harness)**는 대규모 언어 모델(LLM)을 감싸서 외부 세계와 상호작용할 수 있도록 통제하고 지원하는 소프트웨어 인프라스트럭처이자 런타임 제어 계층입니다. 단순히 모델을 호출하는 것을 넘어 실행 루프, 도구 관리, 컨텍스트 유지, 상태 관리, 보안 및 평가 기능을 통합하여 에이전트가 장기적이고 복잡한 작업을 자율적이고 신뢰성 있게 수행하도록 돕습니다. 모델이 논리적 추론을 담당하는 '두뇌'라면, 하네스는 모델이 환경과 소통하고 안전한 제약 내에서 행동하도록 돕는 '신체 및 환경 인프라'로 기능하며, 최근 AI 개발의 초점이 프롬프트 최적화에서 하네스 설계(Harness Engineering)로 이동하고 있습니다.
+
+## 📖 Core Content
+소스 데이터에 따르면, 신뢰할 수 있는 에이전트 시스템을 구축하기 위해 에이전트 하네스는 다음과 같은 핵심 역할을 수행합니다.
+
+- **하네스의 공식적 정의 (The 6-Component Framework)**
+  연구 및 산업계에서는 에이전트 하네스를 **H = (E, T, C, S, L, V)**의 6가지 런타임 거버넌스 구성 요소로 정의합니다.
+  - **E (Execution Loop, 실행 루프):** 관찰-생각-행동(observe-think-act) 주기를 오케스트레이션하며 다중 턴의 실행 흐름, 에러 복구 및 종료 조건을 제어합니다.
+  - **T (Tool Registry, 도구 레지스트리):** 에이전트가 외부 세계에 개입할 수 있도록 타입이 지정되고 검증된 도구 카탈로그(API, 파일 제어 등)를 유지하고 도구 호출을 라우팅/모니터링합니다.
+  - **C (Context Manager, 컨텍스트 관리자):** 컨텍스트 윈도우로 들어가는 정보를 필터링하고 우선순위를 정하며, 메모리 압축(Compaction) 및 검색 전략을 관리합니다.
+  - **S (State Store, 상태 저장소):** 에이전트의 실행 턴(Turn) 및 세션 간의 작업 관련 상태를 영속적으로 저장하고 부분적 실패 시 복구를 지원합니다.
+  - **L (Lifecycle Hooks, 수명주기 훅):** 인증, 로깅, 정책 시행 및 관찰을 위해 에이전트 호출 전후를 가로채는(Intercept) 제어 지점입니다.
+  - **V (Evaluation Interface, 평가 인터페이스):** 벤치마크 및 오프라인 분석을 위해 실행 궤적(Trajectory), 중간 상태, 성공 신호를 표준화된 형태로 캡처합니다.
+
+- **하네스 엔지니어링 패러다임의 진화**
+  AI 엔지니어링은 '프롬프트 엔지니어링(2022-2024)'에서 모델이 보는 정보를 관리하는 '컨텍스트 엔지니어링(2025)'을 거쳐, 에이전트의 전체 실행 환경 및 제어 인프라를 설계하는 **'하네스 엔지니어링(2026)'**으로 진화했습니다. 현재 선도적인 AI 시스템의 신뢰성은 모델의 지능(Model Capability)만으로 결정되지 않으며, 모델과 하네스가 결합된 품질이 성능의 상한을 결정합니다.
+
+- **보안 및 런타임 제어 메커니즘**
+  하네스는 본질적으로 불확실성을 가진 LLM의 출력을 결정론적(Deterministic) 환경에서 제어합니다. 이를 위해 **샌드박싱(Sandboxing)**을 통해 코드 실행 환경을 논리적/물리적으로 격리하고, 에이전트의 '과도한 권한(Excessive Agency)'과 '간접 프롬프트 인젝션(Indirect Prompt Injection)'과 같은 보안 위협을 수명주기 훅(L) 및 도구 승인 파이프라인(Human-in-the-loop)을 통해 방어합니다. 
+
+## ⚖️ Trade-offs & Caveats
+
+- **도구 접근성(Capability) vs 보안 및 격리(Security):** 
+  에이전트 하네스에 폭넓은 도구(네트워크, 파일시스템 쓰기 등)를 제공하면 유용성은 극대화되지만, 동시에 간접 프롬프트 인젝션이나 예기치 않은 시스템 파괴와 같은 공격 표면이 급증합니다. 반면, 엄격한 마이크로VM 샌드박싱이나 권한 최소화 원칙을 강제하면 보안성은 높아지지만, 에이전트의 작업 지연 시간(Latency)이 증가하고 운영 인프라의 복잡성이 커지는 반대 급부가 발생합니다.
+- **컨텍스트 유지(Retention) vs 비용 및 부패(Context Rot):**
+  긴 작업 세션 동안 모든 실행 기록과 도구 결과를 컨텍스트에 유지하면 모델의 장기적 추론에 유리해 보이지만, 실제로는 컨텍스트 윈도우 희석 현상(Attention Dilution)과 기하급수적인 토큰 비용 증가를 유발하는 **'컨텍스트 부패(Context Rot)'**가 발생합니다. 반대로 메모리 압축(Compaction)이나 부분 요약을 공격적으로 수행하면, 이후 에이전트가 작업을 재개할 때 필수적인 세부 정보나 데이터 출처(Provenance)를 상실할 위험이 존재합니다.
+- **다중 에이전트 오케스트레이션(Multi-Agent) 오버헤드:**
+  역할이 분리된 여러 하위 에이전트(Subagents)를 하네스로 연결(Orchestrator-Worker 패턴 등)하면 병렬 처리와 컨텍스트 격리에 매우 유리합니다. 그러나, 에이전트 간의 통신(메시지 라우팅), 상태 공유 일관성, 권한 위임 관리 등 분산 시스템 수준의 복잡성이 추가되며, 단일 에이전트 구성보다 토큰 소비량이 최대 15배 이상 증가할 수 있어 비용 대비 효율성을 철저히 계산해야 합니다.
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [관계 유형 A: 아키텍처/기반 기술]
+- [[Model Context Protocol (MCP)]]
+  - 연결 이유: 하네스의 도구 레지스트리(T-component)가 외부 데이터 소스 및 도구와 통신할 때 사용하는 Anthropic 주도의 표준 개방형 프로토콜입니다.
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 하네스가 어떻게 모델과 종속성을 분리하여 수많은 API와 엔터프라이즈 도구를 안전하고 규격화된 방식(JSON-RPC 기반)으로 탐색하고 실행하는지 구체적으로 이해할 수 있습니다.
+
+- [[Agent-to-Agent Protocol (A2A)]]
+  - 연결 이유: MCP가 '에이전트-도구' 간의 연결을 담당한다면, A2A는 다중 에이전트 하네스에서 '에이전트-에이전트' 간의 작업 위임 및 원격 통신을 표준화하는 Google 주도의 프로토콜입니다.
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 하네스의 실행 루프(E-component)가 단일 컨텍스트를 넘어 외부 또는 원격의 특화 에이전트들에게 하위 작업을 어떻게 오케스트레이션하는지 파악할 수 있습니다.
+
+- [[Context Engineering]]
+  - 연결 이유: 프롬프트 엔지니어링의 다음 단계로, 하네스가 에이전트의 컨텍스트 윈도우에 진입하는 정보를 필터링, 압축, 우선순위화하는(C-component) 핵심 설계 철학입니다.
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 긴 시간 실행되는 작업에서 발생하는 '컨텍스트 부패'를 방지하고, 검색 증강(RAG)과 가상 페이징(Virtual Paging)을 통해 토큰 비용을 어떻게 억제하는지 알 수 있습니다.
+
+#### [관계 유형 B: 구현/활용 도구]
+- [[Sandboxing (MicroVMs/Containers)]]
+  - 연결 이유: 하네스 내부에서 에이전트가 생성한 코드나 도구 호출을 격리된 상태로 실행하게 만드는 인프라 기술입니다.
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 에이전트의 자율적 실행이 호스트 시스템을 파괴하거나 보안을 침해하지 않도록 방어하는 실행 계층(Docker, E2B 등)의 중요성을 확인할 수 있습니다.
+
+- [[Plan-Execute-Verify (PEV) Loop]]
+  - 연결 이유: 하네스 내부에서 에이전트의 작업을 통제하는 핵심 실행 파이프라인 패턴입니다.
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 에이전트가 단순히 생성하고 확인(Generate-and-check)하는 것을 넘어, 하네스가 어떻게 명시적인 계획 단계와 실행, 그리고 자동화된 검증(Verification) 사이에 하드 게이트(Hard gates)를 두어 신뢰성을 높이는지 이해할 수 있습니다.
+
+### Deeper Research Questions
+
+- 다중 에이전트 하네스(Multi-Agent Harness) 아키텍처에서 에이전트 간 공유 상태(Shared State)의 일관성을 유지하고, 손상된 에이전트(Byzantine fault)로 인한 연쇄 오류(Cascade failure)를 분산 시스템 수준에서 어떻게 방어할 수 있는가?
+- '컨텍스트 부패(Context Rot)' 문제를 해결하기 위해 하네스의 컨텍스트 관리자(C-component)가 수행하는 '적응형 압축(Adaptive Context Compaction)' 기법은 실제 토큰 비용 절감 및 정보 손실률 측면에서 검색 증강(RAG)과 비교하여 어떠한 정량적 트레이드오프를 갖는가?
+- MCP(Model Context Protocol)를 T-component에 적용하고 A2A(Agent-to-Agent)를 E-component에 적용하는 이중 프로토콜 스택 아키텍처에서, 두 프로토콜 간의 교차 인증(Authentication) 및 보안 경계는 어떻게 설계되어야 하는가?
+- 하네스 내부에서 실행되는 샌드박싱 환경(예: MicroVM 기반 코드 실행)과 외부 API를 직접 호출하는 방식 중, 복잡한 데이터 변환 및 검증 과제에서 에이전트 성능(Pass@1)과 지연 시간(Latency)에 각각 어떤 영향을 미치는가?
+- '하네스-모델 결합(Harness-Model Coupling)' 현상, 즉 특정 모델이 특정 하네스 생태계(예: Native SDK)에서만 월등한 성능을 발휘하는 현상을 객관적으로 측정하고 평가하기 위한 교차 하네스 벤치마크(Cross-Harness Evaluation)의 표준화 조건은 무엇인가?
+- 코드 기반의 결정론적 하네스와 비교하여, 자연어로 제어 규칙을 명세하는 '자연어 기반 에이전트 하네스(Natural-Language Agent Harnesses, NLAH)'는 이식성과 형식적 검증(Formal Verification) 측면에서 시스템 신뢰성을 어떻게 보장할 수 있는가?
+
+### Practical Application Contexts
+
+- **Implementation:** LangGraph, CrewAI, AutoGen 등의 프레임워크나 OpenClaw, DeepAgents 같은 풀스택 하네스 환경을 구현할 때, 도구 레지스트리 설정, 파일 시스템 상태 연결, 메모리 저장소 연동 등을 실제 코드로 구현하고 통합하는 과정에 적용됩니다.
+- **System Design:** 소프트웨어 아키텍트는 AI 기반 애플리케이션 설계 시, 단순히 프롬프트를 개선하는 것에 의존하지 않고 E, T, C, S, L, V의 6대 컴포넌트를 기반으로 런타임 제어, 상태 영속성, 멀티 에이전트 오케스트레이션 토폴로지 등 전체 인프라 스트럭처의 거시적 구조를 기획합니다.
+- **Operation / Maintenance:** 프로덕션 환경에서는 AgentOps, Langfuse와 같은 도구를 통해 L-component와 V-component를 모니터링하며 세션 토큰 비용, 실행 궤적(Trace), 무한 루프, 컨텍스트 상태를 실시간으로 추적하고 사후 디버깅 및 감사(Auditing)를 수행합니다.
+- **Learning Path:** LLM 프롬프트 작성과 RAG(검색 증강 생성)에 익숙해진 엔지니어가 에이전트의 안정성을 확보하기 위해 필수적으로 학습해야 하는 상위 단계입니다. 운영체제(OS)의 커널과 스케줄러를 이해하듯 AI 에이전트의 통제 환경 구축을 학습하는 경로입니다.
+- **My Project Relevance:** 현재 자율적으로 동작하는 코딩 에이전트나 비즈니스 자동화 봇을 개발 중이라면, 모델의 오류로 인한 시스템 파괴를 막는 샌드박싱 적용, MCP를 통한 확장성 높은 사내 API 연동, 그리고 휴먼-인-더-루프(HITL) 기반의 승인 게이트웨이 도입 등 프로젝트의 신뢰성과 기업 보안 컴플라이언스를 확보하는 데 직결됩니다.
+
+### Adjacent Topics
+
+- [[LLM Evaluation Frameworks]]
+  - 확장 방향: 단순히 하네스 인프라를 구축하는 것을 넘어, SWE-bench, HAL, AgencyBench 등 하네스 내부에서 에이전트의 복잡한 실행 궤적(Trajectory)을 객관적이고 재현 가능하게 평가하고 측정하는 벤치마킹 방법론으로의 확장.
+- [[Agentic Cybersecurity]]
+  - 확장 방향: 간접 프롬프트 인젝션 방어, 메모리 포이즈닝 방지, 최소 권한 원칙 기반의 도구 접근 제어 등 자율적 에이전트가 초래할 수 있는 새로운 형태의 사이버 보안 위협과 방어 아키텍처(예: OpenClaw PRISM, OAP) 연구로의 확장.
+
+---
+*Last updated: 2026-05-01*
\ No newline at end of file
diff --git a/00_Raw/Agent Skills (Anthropic).md b/00_Raw/Agent Skills (Anthropic).md
new file mode 100644
index 00000000..b62a41f5
--- /dev/null
+++ b/00_Raw/Agent Skills (Anthropic).md	
@@ -0,0 +1,61 @@
+# [[Agent Skills (Anthropic)]]
+
+## 📌 Brief Summary
+Agent Skills는 2025년 12월 Anthropic이 공개한 오픈 표준(agentskills.io)으로, 에이전트가 특정 워크플로우를 실행하는 방법을 학습할 수 있도록 재사용 및 이식 가능한 스킬 패키지를 지정합니다. 원자적(atomic)인 개별 도구 호출을 표준화하는 MCP(Model Context Protocol)와 달리 워크플로우와 수명 주기(Lifecycle) 수준의 상호 운용성을 다룹니다. 이를 통해 스킬 라이브러리를 특정 하네스에 종속된 사유적(proprietary) 아티팩트에서 독립적인 하네스 간 이식 및 배포가 가능한 오픈 생태계 자원으로 탈바꿈시킵니다.
+
+## 📖 Core Content
+- **아키텍처 스택에서의 위치 (L-Component 통합)**: Agent Skills는 하네스 설계에서 도구 레지스트리(T-component)가 아닌 수명 주기 및 워크플로우 관리(L-component) 계층에서 작동합니다. 단일 도구 작업(Tool invocation)을 처리하는 MCP와 결합하여, 하위 수준의 도구 실행과 상위 수준의 워크플로우 조합을 분리하는 자연스러운 '2계층 프로토콜 스택(two-layer protocol stack)'을 형성합니다.
+- **패키지 구성 및 구조**: 각 스킬은 `SKILL.md` 명세 파일, 실행 가능한 스크립트, 그리고 리소스 파일이 포함된 디렉토리 형태로 구성됩니다. 이는 에이전트가 획득하고 적용할 수 있는 개별적인 역량(discrete capability)을 정의합니다.
+- **상호 운용성 (Interoperability & Portability)**: 스킬 패키지에 대한 표준 포맷을 제공함으로써, 한 조직에서 생성된 스킬을 Cursor, VS Code, Goose, OpenCode, Amp 등 독립적인 여러 에이전트 하네스에서 즉시 채택하고 배포할 수 있습니다. Anthropic의 자체 Agent SDK 역시 Agent Skills를 일급 객체(first-class constructs)로 통합합니다.
+- **인프라 및 거버넌스 효과**: 에이전트 워크플로우를 공식적인 인프라 컴포넌트로 규격화함으로써 중대한 거버넌스 효과를 창출합니다. 구체적으로 (1) 하네스 간 스킬 이식성, (2) 워크플로우 패턴의 버전 관리 및 폐기(deprecation), (3) 워크플로우의 전제 조건 및 실패 모드에 대한 명시적 문서화, (4) 모델 변경과 무관하게 워크플로우 수준의 성능 개선에 대한 재현 가능한 평가를 가능하게 합니다. 
+
+## ⚖️ Trade-offs & Caveats
+소스에 관련 정보가 부족합니다. (Agent Skills 개별 기술의 명시적인 부작용이나 단점에 대해서는 소스 데이터 내에 구체적으로 서술되어 있지 않습니다. 다만 일반적인 스킬 라이브러리 운용과 관련하여, 지나치게 방대한 스킬 문서를 제한 없이 로드할 경우 컨텍스트 윈도우가 오염되고 노이즈가 발생해 선택 품질이 저하될 수 있으며, 에이전트가 스스로 생성한 스킬(self-generated skills)의 경우 신뢰성이 보장되지 않아 하네스 차원의 큐레이션 및 검증(quality-gate) 메커니즘이 필요하다는 제약이 언급됩니다.)
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [프로토콜 및 상호 운용성 표준]
+- [[MCP (Model Context Protocol)]]
+  - 연결 이유: Agent Skills와 함께 2계층 프로토콜 스택을 구성하는 핵심 기술입니다.
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: MCP가 원자적인 외부 도구 및 데이터 소스 연결을 담당하는 반면, Agent Skills는 여러 MCP 도구들을 조합하여 "어떤 조건에서 어떻게 적용할지"에 대한 다단계 워크플로우를 어떻게 지시하는지 그 차이와 상호보완성을 이해할 수 있습니다.
+
+#### [하네스 아키텍처 및 기반 기술]
+- [[L-component (Lifecycle hooks)]]
+  - 연결 이유: Agent Skills가 작동하고 통합되는 에이전트 하네스의 거버넌스 계층입니다.
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 스킬이 단순한 도구 등록(T-component)을 넘어 에이전트의 작업 흐름, 정책 시행, 다단계 실행을 관리하는 상위 인프라로서 어떻게 동작하는지 이해할 수 있습니다.
+- [[Context Engineering]]
+  - 연결 이유: 이식 가능한 스킬을 에이전트가 활용하려면 컨텍스트 윈도우에 스킬 메타데이터와 내용을 효과적으로 주입해야 합니다.
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: `SKILL.md`와 같은 지식 아티팩트가 컨텍스트 오버헤드를 막기 위해 어떻게 점진적 공개(Progressive disclosure)나 지연 로딩(Lazy loading) 방식으로 에이전트에게 제공되는지 파악할 수 있습니다.
+
+#### [에이전트 메모리 및 지속성]
+- [[Skill Library]]
+  - 연결 이유: Agent Skills가 모여 에이전트의 절차적 지식(Procedural knowledge)을 구성하는 영구적인 저장소 역할을 합니다.
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 일회성 프롬프트가 아닌, 세션을 초월하여 재사용 가능한 워크플로우 지식이 에이전트의 능력 성장에 어떻게 기여하는지 이해할 수 있습니다.
+
+### Deeper Research Questions
+
+- MCP가 원자적 도구 호출을, Agent Skills가 다단계 워크플로우를 담당하는 2계층 구조에서 오류 발생 시 디버깅 및 추적(Tracing)은 각 계층에서 어떻게 분리되어 처리되는가?
+- 에이전트가 경험을 통해 스스로 진화시킨 스킬(Evolved skills)을 SKILL.md 표준 포맷으로 출력하고 검증하여 영구적인 스킬 라이브러리에 등록하기 위한 하네스 수준의 파이프라인(Quality-gate)은 무엇인가?
+- Agent Skills를 통해 서로 다른 프레임워크(예: LangGraph, OpenClaw 등) 간에 스킬을 이식할 때, 각 하네스의 고유한 메모리나 상태 관리(State management) 차이로 인해 발생하는 충돌은 어떻게 해결되는가?
+- 조직 내 다양한 도메인 지식을 Agent Skills 패키지로 모듈화하여 배포할 때, 에이전트가 상황에 맞는 스킬만 적재적소에 검색하고 로드하게 만드는(Progressive disclosure) 최적의 검색 아키텍처는 무엇인가?
+- 모델의 추론 능력 향상이 아닌, Agent Skills 적용과 같은 '워크플로우(Harness) 최적화'만으로 해결할 수 있는 에이전트 한계의 상한선은 어디까지인가?
+
+### Practical Application Contexts
+
+- **Implementation:** 개발자는 단일 프롬프트를 작성하는 대신, 특정 작업 수행 규칙, 예외 처리, 관련 스크립트를 포함하는 `SKILL.md` 디렉토리를 생성하여 에이전트의 역량을 모듈화하여 배포할 수 있습니다.
+- **System Design:** 도구(Tool) 인프라를 설계할 때, 단순 API 연동은 MCP 서버로 구축하고, 해당 API들을 엮어 복잡한 비즈니스 로직을 수행하는 과정은 Agent Skills로 추상화하여 시스템을 두 계층으로 분리 설계합니다.
+- **Operation / Maintenance:** 특정 팀이 개발한 버그 수정 절차나 코드 리뷰 체크리스트 등을 표준 Agent Skills 패키지로 관리하여, 조직 내 다양한 하네스 툴(예: VS Code, Cursor 등)을 사용하는 모든 개발자 에이전트가 일관된 워크플로우를 공유하고 버전을 관리하게 합니다.
+- **Learning Path:** 에이전트 시스템 학습 시 기본 모델 API 호출 $\rightarrow$ MCP를 통한 외부 데이터/도구 연동 $\rightarrow$ Agent Skills를 통한 워크플로우 및 수명 주기 제어 순으로 하네스 엔지니어링의 깊이를 확장해 나갑니다.
+- **My Project Relevance:** 다중 에이전트(Multi-agent) 시스템이나 자동화 개발 파이프라인을 구축할 때, 반복되는 작업 패턴(예: CI/CD 오류 자동 복구 워크플로우)을 Agent Skills 표준으로 패키징하여 이식성을 높이고, 모델을 교체하더라도 기존 작업 방식을 그대로 유지할 수 있도록 활용할 수 있습니다.
+
+### Adjacent Topics
+
+- [[A2A (Agent-to-Agent Protocol)]]
+  - 확장 방향: Agent Skills가 '어떻게 워크플로우를 실행할 것인가'에 대한 지식의 표준이라면, A2A는 여러 에이전트 간에 '작업(Task)을 어떻게 위임하고 통신할 것인가'에 대한 프로토콜 표준입니다. 워크플로우 실행과 원격 에이전트 위임 간의 상호 작용 구조를 확장하여 조사할 수 있습니다.
+- [[Agent-Computer Interface (ACI)]]
+  - 확장 방향: 에이전트가 코드를 편집하고 터미널과 상호작용하기 위한 전용 인터페이스 설계 개념으로, Agent Skills 내부의 실행 스크립트나 도구들이 에이전트의 추론에 적합하게 어떻게 구성되어야 하는지 인터페이스 최적화 관점에서 확장할 수 있습니다.
+
+---
+*Last updated: 2026-05-01*
\ No newline at end of file
diff --git a/00_Raw/Agent State Store.md b/00_Raw/Agent State Store.md
new file mode 100644
index 00000000..44b552ec
--- /dev/null
+++ b/00_Raw/Agent State Store.md	
@@ -0,0 +1,64 @@
+# [[Agent State Store]]
+
+## 📌 Brief Summary
+Agent State Store(S-component)는 에이전트 하네스(Agent Harness) 아키텍처의 6대 핵심 구성 요소 중 하나로, 에이전트의 다중 턴(multi-turn) 및 세션 간 상태 지속성을 관리하는 시스템이다 [1, 2]. 이는 작업 관련 상태를 저장하여 실행 루프가 부분적인 실패(partial failures)로부터 복구할 수 있도록 지원한다 [2, 3]. 단순한 단기 로그 저장을 넘어, 에이전트가 경험을 추상화하여 절차적·에피소드적 지식으로 저장하고 후속 작업에 안전하게 활용할 수 있도록 통제하는 인프라 역할을 수행한다 [4-6].
+
+## 📖 Core Content
+* **역할과 기능:** 상태 저장소는 모델의 제한된 컨텍스트 윈도우를 넘어 에이전트가 장기적인 작업을 수행할 수 있도록 지원하는 기반이다 [5, 6]. 이는 초기 LLM 에이전트 프레임워크(예: AutoGPT, BabyAGI)들이 다중 단계 작업 중단을 겪을 때 발생하던 '상태 상실(state loss)' 문제를 방지하는 필수적인 런타임 거버넌스(runtime governance)이다 [7, 8].
+* **메모리 계층 및 구조:** 현대 하네스는 작업 메모리(working memory), 에피소드 메모리(episodic memory), 시맨틱 메모리(semantic memory), 절차적 메모리(procedural memory) 등의 형태로 상태를 관리한다 [9-11]. 예를 들어 Voyager의 스킬 라이브러리처럼 재사용 가능한 절차적 능력을 저장하거나, Reflexion처럼 실패한 실행 추적에서 얻은 자기 비판(self-critiques)을 에피소드 버퍼에 저장하여 자가 개선을 돕는다 [4, 12-14].
+* **파일 시스템 및 아티팩트(Artifact) 저장:** 프로덕션급 하네스 시스템(예: DeepAgents)에서는 파일 시스템이나 가상 아티팩트 저장소를 기본 작업 메모리 기판(working-memory substrate)으로 취급한다 [15, 16]. 대규모 도구 출력값이나 중간 작업 결과물을 프롬프트 컨텍스트에서 제외하여 아티팩트로 오프로드(offload)하고, 다중 에이전트 간의 상태를 공유하거나 복구하는 데 활용한다 [15, 16].
+* **추론 결합 지속성(Inference-Coupled Persistence):** S-component에 기록되는 내용은 종종 모델의 추론을 통해 생성된 능동적 결과물(예: 자기 반성 평가, 유도된 워크플로 스킬 등)이다 [17, 18]. 이로 인해 하네스는 저장 방식 메커니즘뿐만 아니라, 오염되거나 잘못된 지식이 영구 저장소에 기록되지 않도록 저장 내용의 품질(quality)도 직접 관리해야 하는 의무를 지닌다 [17, 18].
+
+## ⚖️ Trade-offs & Caveats
+* **메모리 오염(Memory Poisoning) 및 보안 취약점:** 에이전트가 영구 저장소(S-component)에 콘텐츠를 기록할 권한을 가질 때, 공격자가 악의적인 프롬프트나 잘못된 신념을 주입하면 세션 경계를 넘어 지속되는 치명적인 보안 벡터가 형성된다 [19-22]. 이를 방지하려면 L-component(Lifecycle Hooks)를 통해 쓰기 시점에 엄격한 데이터 검증이 이루어져야 하지만, 현재 대부분의 프로덕션 하네스는 이를 제대로 구현하지 못하고 있다 [20, 23, 24].
+* **메모리 팽창(Memory Bloat)과 검색 품질 저하:** 장기 실행 에이전트의 경우, 관련성이 떨어지는 정보가 S-component에 무분별하게 축적되면 향후 검색 시 신호 대비 잡음비(signal-to-noise ratio)가 하락한다 [25, 26]. Ebbinghaus 망각 곡선이나 적절한 스케줄링 정책에 의한 요약 및 축출(eviction)이 없으면 '컨텍스트 부패(Context Rot)'가 발생하여 토큰 비용이 비선형적으로 증가하고 추론 능력이 저하된다 [27-30].
+* **표준화된 인터페이스의 부재 및 다중 에이전트 일관성 문제:** MCP(Model Context Protocol)를 통해 도구(T-component) 인터페이스가 표준화되는 추세와 달리, S-component는 각 하네스마다 독립적으로 재구현되어 이식성(portability)이 없다 [31, 32]. 이로 인해 다중 에이전트 환경에서 원자적 문서 전달(atomic document handoffs), 에이전트 레지스트리 가용성, 동시 쓰기로 인한 상태 충돌 해결 등의 일관성(Consistency) 보장이 매우 취약하다 [33-36].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [관계 유형 A (아키텍처/기반 기술)]
+- [[Execution Loop (E-component)]]
+  - 연결 이유: 상태 전이와 루프 제어를 담당하는 E-component는 각 단계마다 상태를 S-component에 언제 기록(commit)할지 결정하며, 실행 오류 시 S-component로부터 복구 상태를 읽어온다 [1, 37].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 하네스의 상태 전이(State Transition) 의미론과 부분적 실패 복구(Rollback/Recovery) 메커니즘.
+- [[Context Manager (C-component)]]
+  - 연결 이유: S-component에 저장된 대규모 장기 상태나 과거 추적 데이터 중에서 모델에 지금 당장 필요한 정보만 필터링하여 컨텍스트 윈도우에 주입(Injection)하는 정책을 관장한다 [1, 38, 39].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 메모리 검색 지연 시간 문제 및 컨텍스트 압축(Compaction)과 상태 보존 간의 데이터 파이프라인.
+- [[Lifecycle Hooks (L-component)]]
+  - 연결 이유: S-component의 쓰기 경계(Write boundary)에서 악의적 콘텐츠나 신뢰할 수 없는 데이터가 저장되지 않도록 검증하고, 접근 제어를 시행하는 정책 적용 계층이다 [1, 20].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 상태 관리에서의 보안 격리(Security Isolation) 및 메모리 오염 방지 전략.
+
+#### [관계 유형 B (구현/활용 도구)]
+- [[Filesystem/Artifact Store]]
+  - 연결 이유: 많은 현대 하네스 시스템(예: DeepAgents)이 토큰 예산을 지키기 위해 대용량 도구 출력이나 작업 이력을 컨텍스트에 직접 넣는 대신, 파일 시스템이나 가상 아티팩트 저장소를 S-component 기판으로 사용한다 [15, 16].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 컨텍스트 오버플로우 관리 및 오프보딩(Offloading)을 통한 복구 가능성 확보.
+- [[Agent Workflow Memory (AWM)]]
+  - 연결 이유: 단순히 과거의 사건(Episodic)을 저장하는 것을 넘어, 완료된 작업 궤적에서 재사용 가능한 워크플로 추상화를 유도하여 저장하는 발전된 절차적 상태 저장(Procedural memory) 형태이다 [27, 40, 41].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 장기 실행 에이전트의 워크플로 최적화 및 지속적 학습(Continual learning).
+
+### Deeper Research Questions
+
+- 에이전트가 S-component에 데이터를 쓸 때, 악의적인 프롬프트 주입이나 데이터 유출을 유도하는 '메모리 오염(Memory Poisoning)'을 방지하기 위해 L-hook 수준에서 어떤 검증 구조를 설계해야 하는가?
+- 다중 에이전트 앙상블에서 공유 상태(Shared State)에 대한 동시 쓰기(Concurrent writes)가 발생할 때, S-component는 분산 시스템의 어떤 일관성 모델(Consistency model, 예: 선형가능성)을 채택해야 충돌을 방지할 수 있는가?
+- 모델의 추론 과정을 거쳐 메모리가 생성되는 '추론 결합 지속성(Inference-Coupled Persistence)' 구조에서, 모델의 오류나 환각이 절차적/에피소드적 영구 저장소에 전이되지 않도록 보장하는 품질 게이트(Quality-gate)는 어떻게 구성해야 하는가?
+- MCP(Model Context Protocol)가 도구(Tool) 통합을 표준화한 것처럼, S-component의 상태 유지 및 메모리 관리 API를 표준화하여 여러 프레임워크 간에 에이전트 메모리를 이식(Portability)할 수 있는 방안은 무엇인가?
+- 100만 개 이상의 토큰을 처리하는 거대 컨텍스트 창 모델 환경에서, S-component의 역할은 단순한 '정보 보존 및 압축'에서 '주목도 스케줄링(Attention/Salience Scheduling)'으로 어떻게 진화해야 하는가?
+
+### Practical Application Contexts
+
+- **Implementation:** 코딩 에이전트나 연구 에이전트를 개발할 때, 메모리 내 상태(in-memory state)에 의존하지 않고 JSONL 파일 로그, SQLite 기반 데이터베이스 또는 Git 분기(branch)를 활용하여 작업 이력을 체크포인트 단위로 영구 기록하는 기능을 구현한다.
+- **System Design:** 장기 실행 작업 도중 런타임 오류, 네트워크 타임아웃, 예기치 않은 컨테이너 종료가 발생하더라도, S-component에 저장된 세션 상태를 복원(Wake & Resume)하여 처음부터 다시 시작하지 않도록 하는 내결함성(Fault-tolerance) 아키텍처를 설계한다.
+- **Operation / Maintenance:** 프로덕션 환경에서 에이전트가 지속 작동함에 따라 불필요하게 쌓이는 '좀비 메모리'를 방지하기 위해, Ebbinghaus 망각 곡선이나 최신성(Recency)/관련성(Relevance)에 기반한 메모리 요약 및 축출(Eviction) 파이프라인을 운영한다.
+- **Learning Path:** 단순 챗봇의 대화 컨텍스트 유지(Conversation History)를 넘어서서, 에이전트 운영 체제(Agent OS) 모델에서 제안하는 가상 메모리 페이징(Virtual Paging) 메커니즘과 영구 저장소 구조 설계론을 학습한다.
+- **My Project Relevance:** 복잡한 다중 단계 목표를 수행하는 에이전트 시스템 도입 시, 토큰 초과로 인한 '컨텍스트 부패(Context Rot)' 문제를 선제적으로 해결하고 모델의 이전 결정 논리를 안전하게 저장·재참조할 수 있는 인프라 레이어를 구축하는 데 직접적으로 적용할 수 있다.
+
+### Adjacent Topics
+
+- [[Vector Database / Semantic Search]]
+  - 확장 방향: S-component에 누적된 방대한 상태 로그나 에피소드 중, 현재 직면한 문제 해결에 가장 관련성이 높은 과거 경험(메모리)을 빠르고 의미론적으로 검색하여 컨텍스트에 주입하는 기술로 확장.
+- [[Model Context Protocol (MCP)]]
+  - 확장 방향: 외부 도구 및 시스템과의 연결을 표준화하는 MCP의 발전 양상을 참고하여, 향후 분산 하네스 간의 S-component 상태 상속 및 권한 전파 프로토콜의 표준화 논의로 확장.
+
+---
+*Last updated: 2026-05-01*
\ No newline at end of file
diff --git a/00_Raw/Agent-Computer Interfaces (ACI).md b/00_Raw/Agent-Computer Interfaces (ACI).md
new file mode 100644
index 00000000..1fa97c72
--- /dev/null
+++ b/00_Raw/Agent-Computer Interfaces (ACI).md	
@@ -0,0 +1,67 @@
+# [[Agent-Computer Interfaces (ACI)]]
+
+## 📌 Brief Summary
+**Agent-Computer Interface (ACI)**는 AI 에이전트가 실행 환경과 상호작용하는 방식을 규정하기 위해 에이전트 하네스(Agent Harness)가 설계한 인터페이스 계층입니다 [1, 2]. 이 인터페이스는 에이전트가 사용할 수 있는 명령어 세트, 수신하는 상태 표현, 파싱해야 하는 에러 포맷 등을 결정합니다 [2]. ACI의 설계는 기초 모델(Underlying model)의 품질과 독립적으로 에이전트의 계획 성능과 역량을 결정짓는 핵심 요소로 작용합니다 [1, 2].
+
+## 📖 Core Content
+
+*   **하네스의 고유 권한 및 책임:** ACI는 전적으로 에이전트 하네스에 의해 설계 및 통제됩니다 [2]. 에이전트 모델 자체는 자신에게 주어진 명령어 세트를 변경하거나, 수신하는 상태 표현을 재설계하거나, 에러 포맷을 바꿀 권한이 없습니다 [2]. 따라서, ACI를 설계하는 것은 모델 자체의 기능 문제가 아니라 하네스 엔지니어링의 주요 책임으로 간주됩니다 [2, 3].
+*   **성능에 미치는 결정적 영향:** SWE-agent의 연구 등에서 입증되었듯, ACI 설계는 에이전트 역량의 '1차 결정 요인(first-order determinant)'입니다 [1]. 부실하게 설계된 ACI는 모델의 추론 실패가 아니라, 올바른 추론을 구조적으로 표현하기 어렵게 만듦으로써 높은 에러율을 유발합니다 [1, 4]. 즉, ACI의 구조적 설계가 모델 자체의 역량보다 계획 성능에 더 큰 영향을 미칩니다 [2].
+*   **필수 설계 요구사항:** 효과적인 ACI가 되기 위해 하네스는 다음과 같은 요소들을 제공해야 합니다 [3].
+    *   각 행동 이후의 **모호하지 않은 명확한 상태 표현(unambiguous state representations)** 제공.
+    *   복구 가능한 실패와 복구 불가능한 실패를 구별할 수 있는 **구조화되고 파싱 가능한 에러 메시지(structured, parseable error messages)** 반환.
+    *   모델이 유효한 행동 순서를 추측할 필요가 없도록 하는 **최소한이되 완전한 명령어 어휘(minimal but complete command vocabulary)** 노출.
+    *   돌이킬 수 없는 행동이 실행되기 전에, 계획 승인 게이트(plan approval gate)를 통해 점검받을 수 있는 **검증 가능한 계획 포맷(checkable plan formats)** 제시.
+*   **도메인 특화 및 권한 제어:** ACI는 모델에 범용적인 bash 셸을 그대로 제공하는 대신, 목적에 맞게 특화된(purpose-built) 인터페이스를 제공할 수 있습니다 [5]. 예를 들어 SWE-agent의 ACIface 모델은 소프트웨어 엔지니어링 작업에 적절하도록 파일 뷰어, 검색, 편집 도구를 명시적 상태 제약과 함께 제공합니다 [5, 6]. 이는 에이전트가 전체 도구 카탈로그에 접근하는 것을 막고, 실행 전 역량을 제한(pre-execution capability restriction)하여 안전성을 높이는 패턴입니다 [6, 7].
+
+## ⚖️ Trade-offs & Caveats
+
+*   **인터페이스 세금(Interface Tax)의 발생 위험:** ACI가 모호한 상태 표현이나 불충분한 에러 메시지를 반환하도록 잘못 설계될 경우, 모델의 계획 예산(planning budget)에 이른바 '인터페이스 세금'이 부과됩니다 [2]. 모델은 실제 당면한 작업에 대해 추론하는 대신, 하네스가 어떤 의미로 이러한 응답을 반환했는지 유추하는 데 유한한 토큰과 연산 자원을 낭비하게 됩니다 [2].
+*   **특화(Specialization) vs. 범용성(Generality)의 균형:** 도메인에 특화된 제한적 셸 인터페이스(예: ACIface)를 노출하면 보안과 정확도는 높아지지만, 모델이 원래 하네스에 존재하는 전체 도구 카탈로그를 활용하지 못하게 되는 제약이 따릅니다 [6]. 따라서 ACI는 에이전트의 잠재력을 제한하지 않도록 "최소한이되 완전한(minimal but complete)" 명령어 세트를 구성해야 하는 까다로운 설계 균형을 요구합니다 [3].
+*   **하네스에 대한 완벽한 종속:** 모델은 ACI의 결함(예: 잘못된 에러 피드백 형식, 누락된 도구 명령어)을 스스로 우회하거나 수정할 수 없습니다 [2]. 이는 에이전트의 성공 여부가 전적으로 하네스를 개발한 엔지니어의 인터페이스 설계 역량에 종속된다는 것을 의미합니다 [2].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [관계 유형 A: 아키텍처/기반 기술]
+*   [[Agent Harness]]
+    *   연결 이유: ACI는 에이전트 하네스가 전적으로 설계하고 관리하는 인터페이스이므로 하네스의 핵심 책임 영역에 속합니다 [2].
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 지능형 모델이 아닌 하네스 인프라가 어떻게 에이전트의 실행 환경과 행동을 제어하고 인터페이스를 구성하는지 근본적인 원리를 파악할 수 있습니다 [1, 2].
+*   [[Execution Environment]]
+    *   연결 이유: ACI는 에이전트가 실행 환경과 상호작용하는 방식을 규정하는 접점(Interface)입니다 [1].
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 인터페이스 설계가 실제 컨테이너나 샌드박스 같은 실행 환경에서 에이전트의 성능 및 에러율에 미치는 독립적인 영향을 이해할 수 있습니다 [1].
+
+#### [관계 유형 B: 설계 원칙 및 제약]
+*   [[Interface Tax]]
+    *   연결 이유: 모호하거나 불충분한 ACI 설계는 에이전트의 계획 예산(planning budget)을 낭비하게 만드는 '인터페이스 세금'을 부과합니다 [2].
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 인터페이스 설계의 결함이 어떻게 에이전트의 추론 토큰과 시스템 자원(예산)을 고갈시키는지 경제적, 성능적 측면에서 파악할 수 있습니다 [2].
+*   [[Capability Restriction]]
+    *   연결 이유: ACI 설계(예: SWE-agent의 ACIface)는 에이전트가 전체 도구를 다 보도록 두는 대신 작업에 적합한 제한된 셸 인터페이스만 노출하도록 제약을 가합니다 [6].
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 하네스가 실행 전 단계(pre-execution)에서 어떻게 에이전트의 행동 반경을 좁혀 오류를 줄이고 시스템을 보호하는지 알 수 있습니다 [6, 7].
+
+### Deeper Research Questions
+
+*   범용 bash 셸 대신 도메인에 특화된 ACI를 설계할 때, "최소한이되 완전한(minimal but complete)" 명령어 어휘를 결정하는 정량적 평가 기준이나 프레임워크는 무엇인가?
+*   모호한 상태 표현과 불충분한 에러 메시지가 부과하는 '인터페이스 세금(Interface Tax)'을 모델의 추론 토큰 및 시간 비용 측면에서 어떻게 정량적으로 측정할 수 있는가?
+*   ACI의 강력한 권한 및 도구 노출 제약(예: ACIface 모델)이 에이전트의 자율적 탐색(Autonomous exploration) 및 문제 해결 창의성에 미치는 부정적인 영향을 어떻게 최소화할 수 있는가?
+*   복구 가능한 실패(recoverable)와 복구 불가능한 실패(unrecoverable)를 구분하여 반환하는 ACI의 에러 포맷 설계가 에이전트의 자체 수정(Self-correction) 사이클 속도에 미치는 구체적인 영향은 무엇인가?
+*   다양한 모델 제공자(OpenAI, Anthropic 등)의 상이한 기능, 컨텍스트 제한, 함수 호출 규격을 모두 수용할 수 있는 범용 ACI 설계는 어떻게 가능한가?
+
+### Practical Application Contexts
+
+*   **Implementation:** SWE-agent와 같은 시스템을 구현할 때, 모델이 임의의 시스템 명령어를 사용하게 두지 않고, 파일 뷰어나 검색 도구 등 목적에 맞게 특화된(purpose-built) 제한적 셸 인터페이스(ACI)를 구축하여 에이전트를 제어합니다 [5, 6].
+*   **System Design:** 에이전트가 돌이킬 수 없는 파괴적인 행동을 실행하기 전에, 인간이나 정책 게이트가 계획을 검토할 수 있도록 명확하고 검증 가능한 계획 포맷(checkable plan formats)을 생성하도록 ACI를 설계합니다 [3].
+*   **Operation / Maintenance:** 모델이 작업 실패 이유를 명확히 인지할 수 있도록, 시스템 로그에서 단순히 원시 오류를 던지는 대신 복구 가능한 에러와 불가능한 에러를 구분해 파싱 가능한 구조화된 형태의 에러 메시지를 반환하도록 로깅 시스템을 유지보수합니다 [3].
+*   **Learning Path:** 에이전트를 개발할 때 모델의 프롬프트나 파라미터를 개선하는 데만 몰두하지 않고, 모델이 환경과 상호작용하는 '접점(Interface)'의 설계가 에이전트의 성능과 에러율을 결정하는 핵심 변수임을 학습합니다 [1, 2].
+*   **My Project Relevance:** 개인 프로젝트에서 에이전트에 자율성을 부여할 때, 범용 터미널 환경을 그대로 노출하는 대신 엄격한 제약과 상태 피드백을 제공하는 ACI 계층을 도입하여 에이전트의 무한 루프, 환각, 권한 남용을 방지하는 아키텍처로 활용할 수 있습니다 [2, 3, 5].
+
+### Adjacent Topics
+
+*   [[Context Engineering]]
+    *   확장 방향: ACI가 에이전트에게 제공하는 상태 표현이나 에러 메시지가 결국 에이전트의 컨텍스트 윈도우로 유입되므로, 이 정보를 어떻게 효율적으로 압축하고 우선순위를 매길 것인지 컨텍스트 관리 기법으로 조사 범위를 확장할 수 있습니다.
+*   [[Agent Harness Security]]
+    *   확장 방향: ACIface 모델이 도구 노출을 제약하여 보안을 높이는 것처럼, 하네스 수준에서의 샌드박싱 구조, 권한 제어, 파괴적 행동에 대한 가드레일 설계 기술 전반으로 확장이 가능합니다.
+
+---
+*Last updated: 2026-05-01*
\ No newline at end of file
diff --git a/00_Raw/Agent-to-Agent (A2A).md b/00_Raw/Agent-to-Agent (A2A).md
new file mode 100644
index 00000000..1e3a8850
--- /dev/null
+++ b/00_Raw/Agent-to-Agent (A2A).md	
@@ -0,0 +1,53 @@
+# [[Agent-to-Agent (A2A)]]
+
+## 📌 Brief Summary
+Agent-to-Agent (A2A)는 다중 에이전트 시스템에서 서로 다른 에이전트나 하네스 간의 작업 위임 및 상호 통신을 표준화하기 위해 설계된 오픈 프로토콜입니다 [1-3]. 주로 HTTPS, JSON-RPC, Server-Sent Events(SSE)를 활용하여 상태 기반의 작업 관리와 실시간 스트리밍을 지원합니다 [3-6]. 에이전트 하네스 엔지니어링 관점에서 A2A는 개별 도구 호출(MCP)을 넘어 에이전트 간의 오케스트레이션 및 조정 경계(E-컴포넌트)를 담당하는 핵심 인프라 기술입니다 [7, 8].
+
+## 📖 Core 소 Content
+*   **비대칭적 계층 위임 구조**: A2A 프로토콜은 본질적으로 비대칭적(asymmetric) 특성을 가집니다. 위임하는 하네스와 위임받는 하네스가 서로 다른 역할을 수행하며, 이는 다중 하네스 환경에서 주(Main) 에이전트가 하위 작업을 원격 에이전트에게 위임하는 계층적(hierarchical) 구조에 최적화되어 있습니다 [9, 10].
+*   **에이전트 검색(Discovery) 메커니즘**: 각 하네스는 자신이 호스팅하는 에이전트의 기능(capability)과 통신 인터페이스를 명시하는 **'에이전트 카드(Agent Card)'**를 제공하며, 이를 통해 시스템은 필요한 기능을 가진 다른 에이전트를 동적으로 탐색하고 작업을 할당할 수 있습니다 [9-11].
+*   **메시지와 아티팩트의 분리**: A2A 프로토콜은 통신 과정에서 단순한 메시지(messages)와 결과물인 아티팩트(artifacts)를 명시적으로 분리합니다. 작업의 결과는 채팅 메시지 형태가 아니라 명확한 형태의 작업 아티팩트로 반환되는 것을 원칙으로 삼아 하네스 내부의 아티팩트 우선(artifact-first) 설계와 강력한 호환성을 가집니다 [11].
+*   **프로토콜 스택에서의 역할**: 에이전트가 고수준의 의도를 교환하는 데는 ACP(Agent Communication Protocol)가, 구체적인 도구를 호출할 때는 MCP(Model Context Protocol)가 사용되며, **A2A는 그 중간에서 작업 위임(task delegation)을 관장**하여 일관된 하네스 통신 스택을 형성합니다 [12, 13].
+
+## ⚖️ Trade-offs & Caveats
+*   **네트워크 지연(Latency)의 한계**: A2A는 인터넷 규모의 조직 간 통신을 전제로 설계되어 원격 에이전트 위임 시 약 **50-200ms의 네트워크 지연 시간**이 발생합니다. 이는 로컬 프로세스에서 2-15ms 만에 처리되는 MCP 기반 도구 호출에 비해 훨씬 느리므로, 긴밀하고 빈번한 상호작용이 필요한 루프보다는 규모가 큰 작업의 원격 위임에 제한적으로 사용해야 합니다 [5, 6].
+*   **권한 변환의 표준화 부재**: A2A를 통해 전달된 원격 작업 지시가 로컬 환경의 MCP 도구 권한(permission grants)으로 어떻게 안전하게 맵핑되어야 하는지에 대한 **명시적인 통합 경계가 아직 프로토콜 수준에서 정의되어 있지 않습니다**. 이로 인해 현재 배포자들은 A2A와 MCP 사이의 권한 변환 로직을 임시방편(ad-hoc)으로 직접 구현해야 하는 보안 및 유지보수의 부담을 가집니다 [14, 15].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [통신 및 통합 프로토콜]
+*   **[[MCP (Model Context Protocol)]]**
+    *   연결 이유: A2A가 에이전트 간의 통신을 담당한다면, MCP는 에이전트 하네스와 외부 도구 간의 호출 경계를 표준화하여 상호 보완적인 통신 스택을 구성하기 때문입니다 [7, 8, 16, 17].
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 하네스 내부의 로컬 도구 접근(MCP)과 하네스 외부로의 작업 위임(A2A)이 어떻게 분리되어 동작하는지 아키텍처를 이해할 수 있습니다 [14, 15].
+
+*   **[[ACP (Agent Communication Protocol)]]**
+    *   연결 이유: IBM에서 제안한 프로토콜로, 하네스 간의 고수준 의도(intent) 통신에 초점을 맞추며, 향후 A2A와 하나의 표준으로 통합(merge)되는 생태계적 연관성을 가지기 때문입니다 [12, 13, 18].
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 하위 작업 지시(A2A)를 넘어 에이전트 간 고수준의 자율적 목표 전달 메커니즘을 파악할 수 있습니다 [12, 13].
+
+#### [하네스 아키텍처 구성 요소]
+*   **[[Execution Loop (E-component)]]**
+    *   연결 이유: 다중 에이전트 시스템에서 A2A 프로토콜은 에이전트 간의 실행 루프를 조율하고 조정하는 E-컴포넌트의 다중 에이전트 오케스트레이션 기능을 외부 네트워크로 확장한 것이기 때문입니다 [7-10].
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 단일 에이전트의 관찰-생각-행동 루프가 A2A 위임 호출을 통해 어떻게 병렬 또는 원격 서브 에이전트로 분기(fan-out)되는지 이해할 수 있습니다 [9, 10].
+
+### Deeper Research Questions
+*   A2A의 50-200ms 네트워크 지연 시간이 잦은 피드백과 상태 공유를 요구하는 다중 에이전트 기반 협업 워크플로우 성능에 어떠한 영향을 미치는가? [5, 6]
+*   A2A 프로토콜을 통해 하네스 간 작업 위임 시 수신 측 하네스가 A2A의 작업 승인 정보를 로컬 MCP 서버의 안전한 권한 정책으로 변환(Translation)하기 위한 표준 아키텍처는 어떻게 구성되어야 하는가? [14, 15]
+*   A2A와 같은 신뢰된 에이전트 간 메시지 채널을 악용한 교차 에이전트 프롬프트 인젝션(Cross-agent prompt injection) 공격을 하네스의 거버넌스 계층에서 어떻게 식별하고 차단할 것인가? [19, 20]
+*   대규모 엔터프라이즈 환경에서 Agent Card를 이용한 분산 에이전트 검색(Discovery) 메커니즘은 보안과 상태 가용성을 유지하며 어떻게 동적으로 스케일링될 수 있는가? [9-11]
+*   A2A의 비대칭적(Asymmetric) 통신 모델이 자율적인 P2P 협력 토폴로지와 비교할 때, 계층형 오케스트레이터-워커 패턴에서 가져오는 제어 역학(Control dynamics)의 구체적인 장점과 한계는 무엇인가? [9, 10]
+
+### Practical Application Contexts
+*   **Implementation:** HTTPS 및 Server-Sent Events(SSE) 기술을 기반으로 A2A 어댑터를 구현하여 원격 에이전트 간에 작업(Task) 구조체와 진행 상태, 그리고 결과 아티팩트를 실시간으로 스트리밍하는 시스템을 구축합니다 [3, 4, 11].
+*   **System Design:** 주(Main) 에이전트의 하네스가 로컬 기능은 내부의 MCP 커넥터로 처리하고, 조직 외부의 원격 특화 에이전트에게는 A2A 인터페이스를 통해 하위 작업을 위임하도록 책임을 철저히 분리하는 멀티 프로토콜 아키텍처를 설계합니다 [9, 10, 16, 17, 21].
+*   **Operation / Maintenance:** 하네스 간 분산 호출이 이루어지는 구조이므로, A2A 경계를 넘어가는 권한 위임 체인에 대한 감사 로그(Audit log)를 남기고, 50-200ms 지연 시간에 대응하기 위한 재시도 및 중단(Cancellation) 정책 등 장애 복구 런타임을 유지보수해야 합니다 [5, 6, 11, 22].
+*   **Learning Path:** 에이전트 하네스 엔지니어링 학습 시, 단일 에이전트의 도구 연동(MCP)을 먼저 익힌 뒤 시스템이 수평적으로 확장되는 단계에서 원격 에이전트 간 오케스트레이션 메커니즘(A2A) 및 의도 교환(ACP) 스택을 학습하는 로드맵을 따릅니다 [12, 13].
+*   **My Project Relevance:** 소스에 특정 사용자 프로젝트와 관련된 정보가 부족하므로 일반적인 적용 맥락을 서술합니다. 만약 다중 모델이나 타 조직의 자율 에이전트와 연동해야 하는 대규모 시스템을 기획한다면, 하네스 내부에 A2A 어댑터(Adapter)를 채택하여 벤더 종속성 없이 외부 에이전트를 유연하게 호출하고 통제하는 기반으로 활용할 수 있습니다 [11, 23].
+
+### Adjacent Topics
+*   **[[Distributed Systems]]**
+    *   확장 방향: 다중 에이전트 시스템이 A2A를 통해 서로 통신하게 되면 본질적으로 분산 시스템과 동일한 과제(동시성 제어, 공유 상태 일관성, 메시지 라우팅, 비잔틴 결함 허용 등)를 직면하게 되므로, 이를 분산 시스템 설계 패턴 관점으로 확장하여 연구할 수 있습니다 [24-27].
+
+---
+*Last updated: 2026-05-01*
\ No newline at end of file
diff --git a/00_Raw/Agentic Software Engineering.md b/00_Raw/Agentic Software Engineering.md
new file mode 100644
index 00000000..5236ab38
--- /dev/null
+++ b/00_Raw/Agentic Software Engineering.md	
@@ -0,0 +1,63 @@
+# [[Agentic Software Engineering]]
+
+## 📌 Brief Summary
+에이전틱 소프트웨어 엔지니어링(Agentic Software Engineering)은 개발자가 직접 코드를 작성하는 역할에서 코드를 자율적으로 작성하는 AI 에이전트를 오케스트레이션하고 방향을 설정하는 역할로 진화하는 소프트웨어 개발 패러다임입니다 [1-3]. 이 환경에서 대형 언어 모델(LLM)은 단일 응답을 생성하는 것을 넘어 자율적으로 계획을 세우고 코드를 디버깅하며 소프트웨어 시스템을 구축하는 에이전트로 작동합니다 [4, 5]. 이러한 에이전트가 환각이나 탈선 없이 신뢰성 있게 작업을 수행할 수 있도록 실행 환경, 도구 제어, 메모리, 안전장치 등을 제공하는 '에이전트 하네스 엔지니어링(Agent Harness Engineering)'이 이 패러다임의 핵심 인프라 기반을 형성합니다 [6-8].
+
+## 📖 Core Content
+
+*   **개발자 역할의 변화 (From Implementer to Orchestrator)**: 2026년 이후 소프트웨어 개발의 핵심은 코드를 작성하는 것(syntax)에서 AI 에이전트가 안전하게 코드를 작성할 수 있도록 아키텍처와 제어 시스템을 설계하는 것으로 변화했습니다 [1-3]. 인간은 고차원적인 시스템 아키텍처 설계와 결과물 검증 및 전략적 방향 지시에 집중하고, 에이전트는 반복적이고 전술적인 구현을 담당합니다 [1, 2].
+*   **에이전트 하네스의 필수성 (The Necessity of Agent Harnesses)**: LLM 자체는 상태(State)를 유지하거나 코드를 실행하거나 외부 API를 호출할 수 없는 단순한 확률적 추론 엔진에 불과합니다 [6, 9, 10]. 이를 자율적인 코딩 에이전트로 변환하려면 실행 루프(E), 도구 레지스트리(T), 컨텍스트 관리자(C), 상태 저장소(S), 수명주기 훅(L), 평가 인터페이스(V) 등 6가지 거버넌스 구성 요소를 제공하는 '하네스(Harness)' 인프라가 필수적입니다 [7, 8, 11, 12].
+*   **다중 에이전트 및 PEV 루프 (Multi-agent & PEV Loop)**: 복잡한 코드 작성 작업은 계획(Plan), 실행(Execute), 검증(Verify)으로 역할을 분리하는 PEV 루프나 다중 에이전트 오케스트레이션(Orchestrator-worker 패턴 등)을 통해 관리됩니다 [13-15]. 이를 통해 에이전트는 환각이나 작업 이탈 없이 명시적인 계획과 린터(Linter), CI 검사와 같은 기계적인 승인 절차 내에서만 작업을 수행합니다 [13, 14, 16].
+*   **실행 환경 및 샌드박스 (Execution Environments & Sandboxing)**: 코딩 에이전트는 컨테이너나 마이크로 VM과 같은 격리된 샌드박스 환경에서 파일 읽기/쓰기, 셸 명령어 실행, LSP(Language Server Protocol)를 통한 시맨틱 코드 분석 등의 도구를 사용합니다 [17-19]. 또한, 리소스 소모가 큰 물리적 Docker 환경 대신, LLM을 활용하여 코드 실행 결과를 시뮬레이션하고 검증하는 'SWE-World'와 같은 도커 프리(Docker-Free) 가상 하네스 환경도 에이전트 훈련 및 평가에 적극 활용되고 있습니다 [20-22].
+
+## ⚖️ Trade-offs & Caveats
+
+*   **자율성(Capability)과 격리/보안(Security/Isolation) 간의 트레이드오프**: 코딩 에이전트가 현실적인 엔지니어링 문제를 해결하려면 셸 명령어 실행이나 파일 시스템 접근과 같은 광범위한 도구 권한이 필요하지만, 이는 간접 프롬프트 인젝션(Indirect Prompt Injection)이나 샌드박스 탈출과 같은 심각한 시스템 보안 취약점을 발생시킵니다 [23, 24]. 반대로 강력한 보안 및 격리 조치(예: 엄격한 마이크로 VM 환경 적용)를 강제하면 에이전트의 지연 시간과 운영 비용이 크게 증가하여 완벽한 파레토 최적점(Pareto-optimal point)을 찾기 어렵습니다 [23, 24].
+*   **컨텍스트 보존(Context Retention)과 컴퓨팅 경제성(Compute Economics)의 상충**: 장기 실행 에이전트(Long-running agents)가 과거의 코드 수정 내역과 도구 실행 결과를 모두 컨텍스트 윈도우에 보존하도록 하면 토큰 소비량이 기하급수적으로 늘어나 '컨텍스트 부패(Context rot)'가 발생하며 추론 능력이 희석됩니다 [25-27]. 반대로 토큰 최적화를 위해 컨텍스트를 너무 공격적으로 요약(Compaction)하거나 삭제하면 에이전트가 이전의 결정 맥락이나 중요한 코드 레퍼런스를 상실하는 정보 손실의 부작용이 발생합니다 [28, 29].
+*   **하네스-모델 결합(Harness-Model Coupling) 편향성**: 에이전트 시스템의 실제 신뢰성이나 코드 벤치마크 평가 점수는 모델 단독의 지능이 아니라 모델과 하네스 간의 상호작용 품질에 의해 크게 좌우됩니다 [30, 31]. 동일한 성능의 모델이라도 하네스의 환경 설정, 에러 메시지 래핑 방식, 도구 제공 설계가 미흡할 경우 작업에 실패할 확률이 매우 높으며, 이는 평가 과정에서 모델 자체의 능력 부족으로 오인될 위험이 존재합니다 [32, 33].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [관계 유형 A (아키텍처 및 인프라 기반 기술)]
+- [[Agent Execution Harness]]
+  - 연결 이유: 텍스트를 출력하는 언어 모델을 자율적으로 행동하는 에이전트로 변환하는 핵심 런타임 제어 인프라이기 때문입니다 [11, 12, 34].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 상태 보존, 실행 루프 관리, 컨텍스트 제어, 보안 강제 등 하네스의 6대 거버넌스가 모델 성능과 신뢰성을 어떻게 결정짓는지 파악할 수 있습니다 [11, 12, 35].
+- [[Model Context Protocol (MCP)]]
+  - 연결 이유: 에이전트 하네스가 외부 데이터베이스, 파일 시스템, 서드파티 애플리케이션 등 외부 도구와 통신하는 방식을 표준화하는 개방형 프로토콜이기 때문입니다 [36-38].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: AI가 외부 시스템과 툴을 호출하는 복잡한 권한 및 도구 레지스트리 관리 구조를 상호 운용 가능한 형태로 단순화하는 통합 원리를 이해할 수 있습니다 [39, 40].
+
+#### [관계 유형 B (실행 제어 및 평가 아키텍처 패턴)]
+- [[Plan-Execute-Verify (PEV) Loop]]
+  - 연결 이유: 코딩 에이전트가 단일 프롬프트가 아닌 구조화된 계획 수립, 제한된 실행, 엄격한 코드 검증을 거치도록 강제하는 핵심 하네스 소프트웨어 패턴이기 때문입니다 [13, 14].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 단순히 코드를 생성하고 확인하는(Generate-and-check) 방식의 한계를 극복하고, 자동화된 피드백 루프를 통해 에이전트의 실패를 복구하는 메커니즘을 배울 수 있습니다 [14].
+- [[SWE-World]]
+  - 연결 이유: 리소스가 많이 소모되는 무거운 물리적 Docker 실행 환경 대신, LLM 모델을 활용하여 코드 탐색 및 유닛 테스트 실행 결과를 시뮬레이션하는 도커 프리(Docker-Free) 에이전트 훈련 프레임워크이기 때문입니다 [20, 22].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 비용과 인프라의 한계로 인해 대규모 에이전트 강화학습(RL)이나 평가가 어려웠던 문제를, 가상 피드백 시뮬레이션을 통해 확장성 있게 해결하는 방법을 이해할 수 있습니다 [22, 41].
+
+### Deeper Research Questions
+
+- 대규모 다중 에이전트(Multi-agent) 시스템 환경에서 에이전트 간의 공유 상태(Shared state) 일관성을 유지하고, 한 에이전트의 결함이나 오류가 다른 에이전트로 연쇄 전파(Cascading failures)되는 것을 방지하기 위한 하네스 계층의 격리 아키텍처는 어떻게 설계되어야 하는가? [42-44]
+- 100만 토큰 이상의 초장기 문맥(Ultra-long-context) LLM이 등장했음에도 불구하고, 컨텍스트 압축(Compaction)과 정보의 현저성(Salience) 관리가 여전히 에이전트 하네스 설계에서 가장 중요한 제약 조건이자 필수 엔지니어링 영역으로 작용하는 실증적 원리는 무엇인가? [45, 46]
+- 소프트웨어 엔지니어링 에이전트를 위한 코드 실행 샌드박스에서 성능(지연 시간 최소화 및 캐시 최적화)과 보안(마이크로VM 수준의 커널 접근 제어 등) 간의 극단적인 트레이드오프를 가장 효율적으로 해결할 수 있는 런타임 인프라 구성 방안은 무엇인가? [23, 24]
+- SWE-bench와 같은 코드 해결 벤치마크 평가 시, 모델 자체의 지능적 추론 능력과 하네스의 물리적 환경(실행 환면 래핑, 도구 스키마 최적화 등)이 성능 결과에 미치는 영향을 정량적으로 완전히 분리하여 측정할 수 있는 표준화된 방법론은 무엇인가? [32, 33]
+- 런타임에 동적으로 새로운 도구를 탐색하고 호출할 수 있는 MCP(Model Context Protocol) 환경에서, 예상치 못한 도구 권한의 조합(Capability escalation)으로 발생하는 간접 프롬프트 인젝션 등의 보안 취약점을 사전에 차단하기 위한 하네스 수준의 권한 제어 모델은 어떻게 구축해야 하는가? [47, 48]
+
+### Practical Application Contexts
+
+- **Implementation:** 개발자가 명령줄(CLI) 인터페이스나 IDE에 통합된 에이전트 환경(예: OpenDev)을 구축하여, 자율 코딩 에이전트가 격리된 샌드박스 내에서 파일 편집, 구조적 린팅, 테스트 실행을 안전하게 반복하도록 구현합니다 [49, 50].
+- **System Design:** 소프트웨어 개발 시 기획을 담당하는 Planner 에이전트, 코드를 구현하는 Generator 에이전트, 통합 테스트 및 검증을 수행하는 Evaluator 에이전트로 역할을 철저히 분리한 다중 에이전트 오케스트레이션 파이프라인 아키텍처를 설계합니다 [51-53].
+- **Operation / Maintenance:** LangSmith, AgentOps 등의 전문 옵저버빌리티(Observability) 및 평가 도구를 적용하여 런타임 환경에서 장기간 실행되는 에이전트의 컨텍스트 초과 상태, 도구 호출 실패율, 루프 중단 지점 등을 투명하게 모니터링하고 추적합니다 [54, 55].
+- **Learning Path:** 단순한 일회성 프롬프트 튜닝(Prompt Engineering)에서 벗어나, 에이전트가 문맥을 유지하도록 돕는 컨텍스트 엔지니어링(Context Engineering)과, 최종적으로 린터 강제, 메모리 지속성 등을 통합해 에이전트를 통제하는 하네스 엔지니어링(Harness Engineering)으로 기술 스택과 학습 패러다임을 진화시킵니다 [56, 57].
+- **My Project Relevance:** 소스에 관련 정보가 부족합니다. (개인의 특정 프로젝트나 사적 맥락에 연관된 내용은 제공된 소스 데이터 내에 기술되어 있지 않습니다).
+
+### Adjacent Topics
+
+- [[Retrieval-Augmented Generation (RAG)]]
+  - 확장 방향: RAG는 단순히 정적인 문서에서 텍스트를 검색하여 모델에 지식을 주입하는 수동적인 방식이었다면, 이를 넘어 에이전트가 코드베이스 구조를 파악하고 여러 검색 도구를 거쳐 동적으로 정보를 직접 획득해나가는 'Agentic Search(에이전트적 탐색)' 및 연속적 지식 통합 아키텍처로 확장할 수 있습니다 [58-60].
+- [[Agent-to-Agent (A2A) Protocol]]
+  - 확장 방향: MCP가 개별 에이전트와 외부 도구/데이터 간의 연결을 돕는 표준이라면, A2A 프로토콜은 서로 다른 하네스에 속하거나 원격으로 분산된 다수의 에이전트 인스턴스 간에 작업을 위임하고 상태를 동기화하며 통신하기 위한 상호운용성 네트워크 표준 기술로 확장할 수 있습니다 [37, 61].
+
+---
+*Last updated: 2026-05-01*
\ No newline at end of file
diff --git a/00_Raw/Agile Software Development in Small Teams.md b/00_Raw/Agile Software Development in Small Teams.md
new file mode 100644
index 00000000..b8fce13b
--- /dev/null
+++ b/00_Raw/Agile Software Development in Small Teams.md	
@@ -0,0 +1,70 @@
+# [[Agile Software Development in Small Teams]]
+
+## 📌 Brief Summary
+소규모 팀(예: 2~5인)에서의 애자일 소프트웨어 개발은 프로세스 오버헤드를 최소화하고 빠른 피드백 루프를 유지하는 것을 핵심으로 합니다 [1, 2]. 복잡한 워크플로우(예: Git-Flow) 대신 가벼운 기능 브랜치(Feature-Branch)나 트렁크 기반(Trunk-Based) 개발을 채택하여 충돌을 방지합니다 [3, 4]. 또한, YAGNI(You Aren't Gonna Need It) 원칙과 기능 기반의 구조(Feature-Based Structure)를 적용하여 오버엔지니어링을 피하고 코드의 확장성과 유지보수성을 확보합니다 [5, 6].
+
+## 📖 Core Content
+
+*   **가벼운 브랜칭 워크플로우 (Lightweight Branching Workflows)**
+    *   소규모 팀의 경우, 무겁고 복잡한 Git-Flow보다는 '단순 기능 브랜치 워크플로우(Simple Feature-Branch Workflow)'나 '짧은 수명의 기능 브랜치를 활용한 트렁크 기반 개발(Trunk-Based Development)'이 가장 적합합니다 [1-3].
+    *   이를 통해 과도한 프로세스 부담 없이 코드 안정성을 지키고, 긴 브랜치 유지로 인한 대규모 병합 충돌을 피할 수 있습니다 [4, 7, 8].
+
+*   **소규모 애자일 팀을 위한 핵심 규칙 (Key Rules for Collaboration)**
+    *   **안정적인 메인 브랜치 유지:** `main` (또는 `master`) 브랜치는 항상 배포 가능하고 안정적인 상태를 유지해야 하며, 직접 푸시(Direct push)를 금지하는 보호 정책(Branch protection)을 적용해야 합니다 [1-3, 9].
+    *   **단일 작업 브랜치와 원자적 커밋:** 모든 새로운 기능이나 버그 수정은 `main`에서 분기된 짧은 수명의 브랜치에서 진행하며(예: `feature/login-page`), 하나의 커밋에는 하나의 논리적 변경(Atomic Commits)만 담아야 합니다 [2, 3, 10, 11].
+    *   **코드 리뷰와 병합 (PR & Merge):** 작업이 완료되면 Pull Request(PR)를 생성하고, 최소 1명 이상의 동료 리뷰와 CI 테스트 통과를 거쳐야만 병합할 수 있습니다 [9-12]. 병합 시에는 커밋 히스토리를 깔끔하게 유지하기 위해 Squash Merge를 권장하며, 병합된 브랜치는 자동으로 삭제합니다 [9, 10, 12, 13].
+
+*   **애자일 환경의 소프트웨어 설계 원칙과 구조**
+    *   **YAGNI 원칙:** 애자일 환경에서는 "You Aren't Gonna Need It(당장 필요하지 않은 기능은 만들지 말라)" 원칙이 필수적입니다. 실현되지 않을 수 있는 미래의 사용 사례를 위해 복잡한 기능을 미리 개발하는 것을 지양하여 불필요한 코드와 유지보수 부담을 줄여야 합니다 [5, 14].
+    *   **기능 기반 구조 (Feature-Based Structure):** 기술적인 파일 유형이 아닌 비즈니스 기능(Feature)을 중심으로 코드를 폴더화하는 접근 방식은 애자일 개발 방법론과 매우 잘 맞습니다 [6, 15]. 기능들이 독립적으로 생성 및 구현될 수 있어 팀이 코드를 확장할 때 마찰이 적습니다 [6].
+
+## ⚖️ Trade-offs & Caveats
+*   **단순성 vs. 구조적 한계:** 가벼운 기능 브랜치 전략이나 트렁크 기반 개발은 소규모 팀(2~5명)에게 배우기 쉽고 프로세스 오버헤드가 적다는 강력한 장점이 있지만 [4, 8], 팀 규모가 크게 성장하거나 엄격히 예정된 릴리스 일정을 관리해야 하는 대규모 프로젝트에서는 한계가 있을 수 있습니다. 이 경우 무겁더라도 Git-Flow와 같은 릴리스/개발 브랜치가 분리된 전략이 필요할 수 있습니다 [4, 16].
+*   **Trunk-Based Development의 높은 요구사항:** 트렁크 기반 개발은 빠른 통합을 가능하게 하지만, 팀원 간의 긴밀한 조율과 강력한 지속적 통합(CI) 환경 구축이 필수적입니다 [4, 8]. 강력한 CI 파이프라인 없이 빈번한 병합만 시도할 경우, 오히려 `main` 브랜치의 안정성이 위협받을 수 있습니다.
+*   **YAGNI의 부작용:** YAGNI 원칙은 낭비되는 노력을 줄여주지만, 시스템의 전반적인 밑그림이나 미래의 확장성을 너무 고려하지 않고 개발할 경우(Oversimplify) 나중에 대대적인 아키텍처 수정이 필요해질 위험(Trade-off)도 존재합니다 [17].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [Workflow & Version Control (버전 관리 및 협업 방식)]
+- [[Feature-Branch Workflow]]
+  - 연결 이유: 2~5인 규모의 소규모 팀에서 충돌을 최소화하고 가벼운 프로세스를 유지하기 위해 가장 널리 권장되는 핵심 Git 브랜치 전략이기 때문입니다 [2, 3].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 짧은 수명의 브랜치 관리와 Pull Request를 통한 비동기 코드 리뷰가 팀의 민첩성에 미치는 영향.
+- [[Trunk-Based Development]]
+  - 연결 이유: 숙련된 소규모 팀이 빠른 피드백과 CI/CD의 효율을 극대화하기 위해 선택할 수 있는 대안적 애자일 워크플로우입니다 [1, 4].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 브랜치 분리를 최소화하고 빈번하게 코드를 병합하는 것이 통합 문제를 어떻게 예방하는지.
+
+#### [Software Engineering Principles (소프트웨어 공학 원칙)]
+- [[YAGNI (You Aren't Gonna Need It)]]
+  - 연결 이유: 애자일 환경에서 낭비를 줄이고 현재의 요구사항에만 집중하게 함으로써, 빠르고 가벼운 개발 주기를 유지하도록 돕는 핵심 설계 원칙입니다 [5, 17].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 과도한 사전 설계(Over-engineering)를 방지하여 개발 속도를 높이는 철학적 배경.
+- [[Feature-Based Structure]]
+  - 연결 이유: 컴포넌트를 기술적 역할이 아닌 비즈니스 기능(Feature) 단위로 묶어 독립성을 부여하는 구조로, 기능 단위로 개발과 배포를 반복하는 애자일 방법론과 직결됩니다 [6, 15].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 코드베이스의 응집도(Cohesion)를 높이고 독립적인 기능 확장을 가능하게 하는 폴더 구조 설계법.
+
+### Deeper Research Questions
+
+- 소규모 애자일 팀이 성장하여 대형 팀(예: 10명 이상)이 될 때, 경량화된 Feature-Branch 워크플로우에서 Git-Flow와 같은 복잡한 워크플로우로 전환해야 하는 구체적인 임계점과 징후는 무엇인가?
+- 소규모 팀이 Trunk-Based Development를 도입하기 위해 필수적으로 갖춰야 하는 CI/CD 파이프라인의 성숙도와 자동화 테스트의 커버리지 수준은 어느 정도인가?
+- 프론트엔드 환경에서 Feature-Based Structure(혹은 Feature-Sliced Design)를 도입할 때, 공통 로직(Shared concerns)의 경계를 어떻게 정의해야 애자일 팀의 개발 속도 저하를 막을 수 있는가?
+- YAGNI 원칙을 엄격하게 적용하면서 발생하는 기술 부채(Technical Debt)를 애자일 스프린트 내에서 안전하게 관리하고 리팩토링하는 체계적인 방법은 무엇인가?
+- Pull Request 기반의 협업에서, 병합 지연을 방지하고 빠른 피드백을 유도하기 위한 이상적인 PR 크기 제한(예: 코드 라인 수)과 Atomic Commit 강제 방법은 무엇인가?
+
+### Practical Application Contexts
+
+- **Implementation:** 개발자는 작업을 시작할 때 `main` 브랜치에서 짧은 수명의 브랜치를 생성하고, 기능을 구현한 뒤 작고 논리적인 단위(Atomic Commits)로 쪼개어 자주 커밋합니다 [10, 13].
+- **System Design:** 애플리케이션의 폴더 구조를 도메인이나 기능(Feature) 기준으로 설계하여, 소규모 팀원이 각자 다른 기능을 동시에 개발하더라도 서로의 코드 영역을 침범하지 않도록 합니다 [6].
+- **Operation / Maintenance:** GitHub 등 저장소 설정에서 `main` 브랜치 보호(Branch Protection) 기능을 활성화하고, 최소 1명의 코드 리뷰 승인과 자동화 테스트(CI) 통과를 필수 병합 조건으로 강제하여 프로덕션 안정성을 확보합니다 [9].
+- **Learning Path:** 소규모 프로젝트 팀을 구성할 때, 처음부터 무거운 룰을 강요하기보다 단일 기능 브랜치 생성, Pull Request를 통한 리뷰, Squash Merge를 이용한 깔끔한 히스토리 관리 등 핵심 워크플로우부터 학습시킵니다 [1, 13, 18].
+- **My Project Relevance:** 현재 진행 중인 2-5인 규모 프로젝트에 불필요한 미래 확장을 대비한 코드를 작성하지 않는 YAGNI 원칙과, `feat/*`, `fix/*` 형태의 단순한 브랜치 전략을 도입하면 병합 충돌을 줄이고 빠르게 결과물을 낼 수 있습니다 [2, 4, 16].
+
+### Adjacent Topics
+
+- [[Continuous Integration (CI)]]
+  - 확장 방향: 소규모 팀이 짧은 주기의 코드 병합(Merge)을 안전하게 수행할 수 있도록 뒷받침하는 자동화된 빌드 및 테스트 환경 구축 가이드로 확장.
+- [[Conventional Commits]]
+  - 확장 방향: 팀원 간의 변경 사항 커뮤니케이션을 일관되게 만들고 (`feat:`, `fix:` 등), 향후 릴리스 노트를 자동화하는 데 도움이 되는 커밋 작성 표준 규칙 탐구.
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Atomic Commits.md b/00_Raw/Atomic Commits.md
new file mode 100644
index 00000000..b96104e2
--- /dev/null
+++ b/00_Raw/Atomic Commits.md	
@@ -0,0 +1,53 @@
+# [[Atomic Commits]]
+
+## 📌 Brief Summary
+Atomic Commits(원자적 커밋)는 한 번의 커밋에 오직 하나의 논리적 변경 사항(logical change)만을 포함시키는 코드 기록 방식입니다 [1]. 예를 들어, 로그인 버튼을 추가하는 작업과 로그아웃 버튼을 추가하는 작업을 하나의 커밋에 묶지 않고 별도의 커밋으로 분리하는 것을 의미합니다 [1]. 이를 통해 코드 리뷰 과정을 단순화하고 프로젝트의 수정 내역(history)을 명확하게 유지할 수 있습니다 [1].
+
+## 📖 Core 단락 Content
+*   **단일 책임 원칙 적용**: 한 번의 커밋은 오직 하나의 논리적인 변경 사항만을 구현해야 합니다 [1, 2]. 로그인 기능을 수정하면서 동시에 연관 없는 다른 버그를 수정하는 식의 작업을 지양합니다 [1].
+*   **리뷰 및 히스토리 관리의 이점**: 커밋을 작고 의미 있는(small and meaningful) 단위로 유지하면, 동료가 코드를 리뷰할 때 변경된 의도를 쉽게 파악할 수 있어 코드 리뷰가 단순해집니다 [1, 3]. 또한, 추후 문제가 발생했을 때 변경 이력을 추적하거나 되돌리기 수월해집니다 [1].
+*   **워크플로우 내의 역할**: 소규모 팀에서 Feature Branch 워크플로우를 사용할 때, 최신 메인 브랜치를 가져온 후 기능 브랜치 내에서 빈번하고 원자적인 커밋(Make atomic commits)을 생성하는 것이 핵심 규칙으로 권장됩니다 [2, 4]. 
+
+## ⚖️ Trade-offs & Caveats
+소스에 관련 정보가 부족합니다. (제공된 소스에서는 원자적 커밋이 코드 리뷰와 히스토리 관리를 단순화한다는 장점만 언급되어 있을 뿐, 이로 인해 발생할 수 있는 부작용, 제약 사항 또는 반대 급부에 대한 설명은 포함되어 있지 않습니다 [1].)
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [협업 및 브랜칭 전략]
+- [[Feature Branching]]
+  - 연결 이유: 원자적 커밋은 주로 메인 브랜치에서 분기된 '기능 브랜치(Feature branch)' 내에서 코드를 작성할 때 적용되는 핵심 규칙입니다 [1, 4].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 새로운 기능이나 버그 수정을 독립된 브랜치에서 개발할 때, 어떻게 작업을 단일 논리 단위로 분리하여 커밋할지 구조적인 흐름을 이해할 수 있습니다 [1, 5].
+
+- [[Pull Request (PR)]]
+  - 연결 이유: 원자적 커밋들을 모아 하나의 기능 브랜치를 완성한 후, 이를 메인 브랜치에 병합하기 위해 PR을 생성하게 됩니다 [1-3].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 원자적 커밋이 실제 코드 리뷰 과정에서 팀원의 빠른 피드백과 승인을 얻는 데 어떻게 기여하는지 이해할 수 있습니다 [1-3].
+
+#### [커밋 및 병합 기법]
+- [[Squash Merge]]
+  - 연결 이유: 여러 개의 원자적 커밋이 쌓인 기능 브랜치를 메인 브랜치로 병합할 때, 전체 히스토리를 깔끔하게 유지하기 위해 Squash Merge 전략이 권장됩니다 [3, 4, 6].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 원자적 커밋으로 상세하게 쪼개진 작업 내역을 최종적으로 병합할 때 어떻게 단일 기능 단위로 다시 정리할 수 있는지 파악할 수 있습니다 [3, 6].
+
+### Deeper Research Questions
+- 단일 논리적 변경(Logical change)의 경계를 구분하고 원자적 커밋을 구성하는 명확한 기준은 무엇인가? [1, 2]
+- 잦은 원자적 커밋(Commit frequently)이 기능 브랜치(Feature branch)의 리뷰 과정에 미치는 구체적인 영향은 무엇인가? [1, 2]
+- 원자적 커밋과 Conventional Commits (예: `feat:`, `fix:`) 작성 규칙은 어떻게 상호 작용하여 커밋의 의미를 명확하게 하는가? [2, 7]
+- 원자적 커밋들로 구성된 브랜치를 메인 브랜치에 병합할 때, 일반 Merge와 Squash Merge 중 어떤 것이 히스토리 관리에 더 적합한가? [3, 4, 6]
+- 작고 독립적인 원자적 커밋을 지속적으로 생성하는 것이 여러 개발자의 동시 작업 시 충돌(Conflict) 예방에 어떤 영향을 미치는가? [8, 9]
+
+### Practical Application Contexts
+
+- **Implementation:** 로그인 버튼 추가와 로그아웃 버튼 추가를 한 번에 커밋하지 않고, 각각 분리하여 별개의 커밋으로 코드를 저장할 때 직접적으로 적용됩니다 [1].
+- **System Design:** 소스에 관련 정보가 부족합니다.
+- **Operation / Maintenance:** 명확히 분리된 커밋 내역을 통해 프로젝트의 수정 이력을 쉽게 추적하고 유지보수 중 발생하는 코드 리뷰의 복잡성을 줄이는 데 사용됩니다 [1].
+- **Learning Path:** 소규모 개발 팀에 적합한 가볍고 충돌 없는 Git 브랜칭 워크플로우를 학습하는 과정에서 필수적인 기본 수칙으로 학습됩니다 [1, 8].
+- **My Project Relevance:** 팀 프로젝트에서 기능 브랜치를 생성하고 작업할 때, `fix: handle null response in login API`와 같이 작고 의미 있는 커밋 단위를 유지함으로써 팀원들의 빠르고 효과적인 코드 리뷰를 지원하기 위해 적용할 수 있습니다 [3, 7].
+
+### Adjacent Topics
+
+- [[Conventional Commits]]
+  - 확장 방향: 원자적 커밋의 목적을 더욱 명확히 하기 위해 `feat:`, `fix:`, `chore:` 등의 접두사를 활용하여 커밋 메시지를 구조화하는 방법을 함께 조사할 수 있습니다 [2, 7, 10].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Automated Governance.md b/00_Raw/Automated Governance.md
new file mode 100644
index 00000000..630c4289
--- /dev/null
+++ b/00_Raw/Automated Governance.md	
@@ -0,0 +1,59 @@
+# [[Automated Governance]]
+
+## 📌 Brief 코약 Summary
+Automated Governance(거버넌스 자동화)는 코딩 표준과 아키텍처 규칙을 수동으로 관리하는 대신 자동화된 도구를 통해 시스템적으로 강제하는 방법론입니다 [1, 2]. 이는 팀 협업의 기반이 되며, 개발자가 파일을 찾을 때 겪는 혼란을 없애고 환경 설정 불일치로 인한 오류를 방지합니다 [1]. 주로 ESLint, Prettier, Husky와 같은 도구와 CI/CD 파이프라인을 활용하여 고품질의 코드만 저장소에 병합되도록 보장합니다 [2, 3].
+
+## 📖 Core Content
+* **자동화 도구의 필요성:** 코딩 표준을 수동으로 강제하는 것은 매우 비효율적입니다 [2]. 현대의 프론트엔드 프로젝트는 ESLint와 Prettier를 활용하여 코드 위반 사항을 자동으로 찾아내고 수정합니다 [2].
+* **아키텍처 경계의 자동 강제:** ESLint 규칙을 세부적으로 구성하여 특정 임포트 패턴을 금지할 수 있습니다 [2]. 예를 들어, 하나의 기능(feature)이 다른 기능의 내부 모듈을 직접 임포트하지 못하도록 차단함으로써, Feature-Sliced Design(FSD)과 같은 아키텍처 경계를 시스템적으로 강제할 수 있습니다 [2].
+* **Git 훅(Hooks)을 통한 사전 차단:** Husky와 같은 도구를 구현하여 Git 훅을 설정합니다 [2]. 이를 통해 코드가 커밋되기 전에 린팅, 포맷팅, 타입 검사를 자동으로 실행하여, 기준을 통과한 고품질의 코드만이 리포지토리에 반영되도록 합니다 [2].
+* **지속적 통합(CI/CD) 파이프라인 적용:** 팀의 성공적인 거버넌스는 로컬 환경의 린팅 뿐만 아니라 강력한 CI/CD 파이프라인을 통한 자동화에 달려 있습니다 [3]. 시각적 회귀 테스트(Visual tests) 등의 자동화 도구 역시 CI 파이프라인의 PR 검사(PR checks)와 연동되어 의도치 않은 UI 버그가 병합되는 것을 차단합니다 [4].
+
+## ⚖️ Trade-offs & Caveats
+* **소스에 관련 정보가 부족합니다.** 
+* 제공된 소스에서는 거버넌스 자동화(Automated Governance)의 단점이나 부작용에 대해 직접적으로 명시하고 있지 않습니다. 다만, 구조적 엄격성을 위해 ESLint 설정, Husky 초기 구축, CI/CD 통합 등 **다양한 자동화 도구를 셋업하는 추가적인 환경 구성 작업이 요구**된다는 점을 확인할 수 있습니다 [2, 3]. 또한 규칙 위반을 커밋이나 PR 단계에서 엄격하게 차단하므로 [2, 4], 팀 전체가 이 강제된 규칙(예: FSD 아키텍처 규칙)을 명확히 이해하고 따르지 않으면 개발 흐름에 제약이 생길 수 있다는 점을 유추할 수 있습니다.
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [구현/활용 도구]
+- [[ESLint and Prettier]]
+  - 연결 이유: 코딩 표준 위반을 자동으로 식별하고 수정하며 거버넌스 자동화를 직접적으로 수행하는 핵심 도구입니다 [2].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 아키텍처 경계(예: 기능 간 임포트 금지)를 스크립트 수준에서 어떻게 자동화하고 통제하는지 구체적인 원리를 이해할 수 있습니다 [2].
+
+- [[Husky]]
+  - 연결 이유: 코드 커밋 이전에 린팅, 포맷팅, 타입 검사 등의 거버넌스 규칙을 강제로 실행하게 해주는 Git 훅(Hook) 관리 도구입니다 [2].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 잘못된 코드가 원격 저장소에 도달하기 전, 개발자의 로컬 환경에서 선제적으로 문제를 차단하는 파이프라인을 이해할 수 있습니다 [2].
+
+#### [아키텍처/프로세스]
+- [[Feature-Sliced Design (FSD)]]
+  - 연결 이유: 도구를 통한 거버넌스(Automated Governance)가 궁극적으로 지키고자 하는 엄격한 계층 구조 및 모듈화 방법론입니다 [2, 5].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 왜 ESLint와 같은 도구를 활용하여 모듈 간의 단방향 의존성 규칙을 강제해야만 대규모 시스템이 붕괴하지 않는지 구조적인 이유를 알 수 있습니다 [2, 5].
+
+- [[CI/CD 파이프라인]]
+  - 연결 이유: 자동화된 린팅, 테스트 및 거버넌스 규칙이 풀 리퀘스트(PR) 단계에서 검증되는 중앙화된 시스템입니다 [3, 4].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 개별 개발자의 환경을 넘어, 팀 단위의 협업 워크플로우에서 코드 품질이 어떻게 지속적으로 유지되고 보호되는지 파악할 수 있습니다 [3, 4].
+
+### Deeper Research Questions
+- ESLint 규칙을 구체적으로 어떻게 설정해야 Feature-Sliced Design(FSD)에서 요구하는 계층 간의 '단방향 의존성'을 자동으로 강제할 수 있는가?
+- 로컬 환경에서의 Husky 기반 Pre-commit 훅과 CI/CD 서버에서의 검증 파이프라인은 어떤 기준으로 역할을 분담하여 효율성을 높일 수 있는가?
+- 자동화된 린팅과 엄격한 거버넌스가 소규모 프로젝트 초기 속도에 미치는 영향과, 이를 상쇄하기 위한 적절한 도입 시점은 언제인가?
+- 코딩 표준 외에, 자동화 도구(Storybook visual tests 등)를 CI에 연동할 때 발생하는 오탐(Flake/Noise)을 최소화하기 위한 방법은 무엇인가?
+- 상태 관리(State Management) 라이브러리 사용 시 발생하는 아키텍처 위반(예: 글로벌 스토어의 무분별한 접근) 또한 Automated Governance를 통해 제어할 수 있는가?
+
+### Practical Application Contexts
+- **Implementation:** 프로젝트 설정 시 ESLint와 Prettier를 최우선으로 구성하고, Husky를 활용해 `git commit` 명령어가 실행될 때 자동으로 코드 포맷팅 및 타입 에러를 검출하도록 구현합니다 [2].
+- **System Design:** FSD 아키텍처를 도입할 때, 개발자의 실수로 기능(features) 간 의존성이 엉키지 않도록 ESLint 룰(rule) 설계 시 각 폴더의 임포트 범위를 제한하는 아키텍처 보호망을 설계합니다 [2, 5].
+- **Operation / Maintenance:** CI 서버 설정에서 PR 생성 시 Storybook 스크린샷 테스트 및 코드 린터를 통과해야만 Main 브랜치로 병합(Merge)할 수 있도록 상태 검사(PR checks)를 운영합니다 [3, 4].
+- **Learning Path:** 단순한 React 기능 구현을 넘어서, 팀 프로젝트 협업을 위해 코드 컨벤션을 맞추는 도구(Linting)와 Git 훅(Hooks) 사용법을 익히는 다음 단계 학습으로 이어집니다 [2].
+- **My Project Relevance:** 다수의 팀원이 동시에 작업하는 환경이거나, 코드가 방대해지는 확장 단계(Scalable phase)에서 리뷰어의 수동적인 확인 부담을 줄이고 안정성을 보장하기 위해 즉각적으로 프로젝트에 도입해야 하는 필수 환경 세팅입니다 [2, 6].
+
+### Adjacent Topics
+- [[Git Branching Strategies]]
+  - 확장 방향: 엄격하게 검증된 코드만이 합쳐지도록 지원하는 GitHub Flow 등의 브랜치 전략과 풀 리퀘스트(PR) 문화에 대한 이해로 나아갑니다 [7, 8].
+- [[React Compiler]]
+  - 확장 방향: 코드 스타일과 임포트 규칙을 강제하는 'Governance'를 넘어, 리렌더링 최적화(Memoization) 자체를 빌드 타임에 컴파일러가 '자동화'해주는 최신 성능 자동화 영역으로 관심사를 확장합니다 [9, 10].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/CI-CD Pipeline Integration.md b/00_Raw/CI-CD Pipeline Integration.md
new file mode 100644
index 00000000..60367a24
--- /dev/null
+++ b/00_Raw/CI-CD Pipeline Integration.md	
@@ -0,0 +1,61 @@
+# [[CI/CD Pipeline Integration]]
+
+## 📌 Brief 파Summary
+CI/CD 파이프라인 통합은 프론트엔드 개발 환경에서 코드 품질을 일관되게 유지하고 배포 프로세스를 자동화하기 위한 핵심 인프라입니다 [1, 2]. 개발자가 기능 브랜치에서 작성한 코드가 메인 브랜치로 병합(Merge)되기 전에 린팅, 포맷팅, 타입 검사 및 자동화된 UI 회귀 테스트 등의 검사를 의무적으로 통과하도록 강제합니다 [2, 3]. 이를 통해 운영체제 간 파일명 대소문자 구분 문제로 인한 빌드 실패나 의도치 않은 UI 결함이 프로덕션에 배포되는 것을 사전에 차단합니다 [4, 5].
+
+## 📖 Core Content
+- **빌드 안정성 보장 및 에러 예방:**
+  프론트엔드 프로젝트에서 파일명 규칙(예: 파일명은 kebab-case, 컴포넌트는 PascalCase)을 엄격히 지키지 않으면, 대소문자를 구분하지 않는 로컬 운영체제(Windows, macOS)에서는 정상 작동하더라도 대소문자를 엄격히 구분하는 CI/CD 파이프라인(주로 Linux 환경)에서는 빌드 실패를 유발합니다 [3, 4]. 파이프라인은 이러한 환경 불일치 오류를 방지하는 1차 방어선 역할을 합니다.
+- **Pull Request (PR) 자동화 검사:**
+  GitHub Flow와 같은 모던 브랜치 워크플로우에서 CI/CD 파이프라인은 PR의 최종 품질 통제 관문(Gate) 역할을 합니다 [6]. PR이 열리면 CI 파이프라인이 자동으로 테스트를 실행하며, 모든 검사(Checks)를 통과하고 동료의 리뷰를 마친 후에만 메인 브랜치 병합을 허용합니다 [2, 7, 8]. 
+- **시각적 회귀 및 접근성 테스트 통합:**
+  CI 워크플로우(예: GitHub Actions, GitLab Pipelines 등)에 Chromatic이나 Happo와 같은 도구를 통합하여 자동화된 시각적 테스트(Visual Regression Testing)와 접근성 테스트(Accessibility Testing)를 수행할 수 있습니다 [5, 9, 10]. 코드가 변경되면 파이프라인 내에서 실제 브라우저 환경을 모방하여 UI 컴포넌트의 스크린샷을 캡처하고, 이를 기존 기준점(Baseline)과 픽셀 단위로 비교합니다 [11, 12]. 레이아웃이나 색상에 의도치 않은 변경이 발생하면 PR에 실패 배지(Badge)를 달아 수동 리뷰를 강제합니다 [5, 10].
+- **워크플로우 연계 및 릴리스 배포:**
+  단순한 브랜칭 워크플로우를 사용할 경우, 메인 브랜치는 항상 안정적이고 배포 가능한 상태를 유지해야 합니다 [13]. CI/CD는 메인 브랜치에 코드가 병합됨과 동시에 자동으로 프로덕션에 배포(Deploy from main)하도록 설정되며, 커밋 메시지 규칙(Conventional Commits)을 기반으로 릴리스 노트를 자동화하는 데에도 활용됩니다 [6, 14].
+
+## ⚖️ Trade-offs & Caveats
+**소스에 관련 정보가 부족합니다.** (제공된 소스에는 CI/CD 파이프라인 자체의 아키텍처적 단점이나 구축 비용 등에 대한 심층적인 논의가 포함되어 있지 않습니다.)
+다만, 파이프라인에 통합된 시각적 테스트(Visual Testing) 기능과 관련하여 다음과 같은 기술적 제약 및 관리 요소가 존재합니다:
+- **Flaky Tests 및 오탐(False Positives):** UI 테스트 특성상 애니메이션, 비동기 에셋 로딩 등으로 인해 불안정한 테스트 결과가 발생할 수 있습니다 [9, 15].
+- **노이즈 관리 필요:** 이미지 압축 노이즈나 브라우저 안티앨리어싱 차이 등 의도치 않은 미세한 차이로 인해 CI가 실패하는 것을 막기 위해, 색상 허용 오차(color-delta tolerance)를 적절히 설정해야만 파이프라인이 중단되는 것을 방지할 수 있습니다 [9, 16].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [관계 유형 A: 개발 워크플로우 및 형상 관리]
+- [[Git Branching Strategies]]
+  - 연결 이유: CI/CD 통합은 팀의 브랜칭 전략(특히 Trunk-based 또는 GitHub Flow)과 맞물려 작동하며, 짧은 주기의 브랜치가 생성되고 병합될 때마다 코드를 검증하는 기반이 됩니다 [13, 14].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: CI/CD 파이프라인이 메인 브랜치 보호(Branch protection) 및 배포 자동화에 어떻게 기여하는지 워크플로우 관점에서 이해할 수 있습니다 [2, 17].
+
+#### [관계 유형 B: 품질 보증 및 자동화 도구]
+- [[Visual Regression Testing]]
+  - 연결 이유: CI/CD 파이프라인 내부에서 UI 버그가 프로덕션에 도달하는 것을 방지하기 위해 스토리북(Storybook)과 함께 자동으로 실행되는 핵심 테스트 프로세스입니다 [5, 18].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 파이프라인이 단순히 코드 에러만 잡는 것을 넘어 픽셀 단위의 UI 레이아웃, 반응형 디자인, 접근성(A11y)까지 어떻게 검증하는지 파악할 수 있습니다 [11, 18].
+
+#### [관계 유형 C: 코드 컨벤션 및 정적 분석]
+- [[Linting and Governance]]
+  - 연결 이유: CI/CD 환경이나 그 이전(Git Hook 단계)에 Husky, ESLint, Prettier 등을 통해 아키텍처 규칙(예: Feature 간 잘못된 임포트)과 명명 규칙을 강제로 검증합니다 [3, 19].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 자동화된 파이프라인이 개발자의 수동 리뷰 부담을 줄이고 프로젝트의 거버넌스를 시스템적으로 어떻게 유지하는지 알 수 있습니다 [3].
+
+### Deeper Research Questions
+- 대소문자를 구분하지 않는 개발자의 로컬 OS 환경과 엄격하게 구분하는 CI/CD 리눅스 서버 환경 간의 빌드 실패(Build Failure) 격차를 해결하기 위한 파이프라인 설정 기법은 무엇인가?
+- CI/CD 환경에서 Chromatic이나 Happo를 활용한 시각적 회귀 테스트 수행 시 발생하는 속도 저하를 최소화하고, 다중 브라우저 병렬 테스트를 효율적으로 구성하는 아키텍처는 무엇인가?
+- 대규모 React 프로젝트에서 Feature-Sliced Design(FSD) 원칙을 도입했을 때, CI 파이프라인의 ESLint 룰(Rule) 설정을 통해 컴포넌트 간의 잘못된 의존성(Coupling)을 어떻게 자동 차단할 수 있는가?
+- 커밋 메시지 규약(Conventional Commits)을 통해 CI/CD 파이프라인에서 시맨틱 버저닝(Semantic Versioning)과 릴리스 노트를 완전히 자동화하는 구체적인 워크플로우 구성 방법은 무엇인가?
+
+### Practical Application Contexts
+- **Implementation:** GitHub Actions, GitLab Pipelines, CircleCI 등의 CI 제공 환경에 Happo 또는 Chromatic을 연동하는 스텝을 추가하고 인증을 위한 환경 변수(Project Token)를 구성하여 시각적 검증을 자동화합니다 [10].
+- **System Design:** 애플리케이션의 `main` 브랜치를 보호(Protected Branch) 상태로 설정하고, 1명 이상의 동료 리뷰와 CI 테스트(린팅, 단위 테스트, 시각적 테스트)를 통과해야만 병합(Merge)이 가능한 강제적 시스템(Gate)을 설계합니다 [2, 17].
+- **Operation / Maintenance:** CI 과정에서 UI 변경 사항이 감지되면 리뷰어가 변경 내용을 확인하고, 의도된 변경일 경우 로컬이나 CI 대시보드에서 새로운 베이스라인(Baseline)으로 승인(Accept)하여 테스트 기준을 갱신합니다 [20, 21].
+- **Learning Path:** React 컴포넌트 및 로컬 상태 개발 ➔ 정적 분석 도구(ESLint) 및 Git Hooks(Husky) 적용 ➔ 브랜치 관리 전략 도입 ➔ **CI/CD 파이프라인 구축 및 Storybook UI 테스트 연동** ➔ 프로덕션 자동 배포.
+- **My Project Relevance:** 팀 단위 프로젝트를 진행할 때 각자의 환경 차이로 인한 빌드 에러를 막고, 복잡한 로직 및 UI가 포함된 코드가 수동 확인의 한계로 인해 버그를 발생시키는 것을 미연에 방지하기 위해 즉시 설정해야 할 핵심 개발 인프라입니다.
+
+### Adjacent Topics
+- [[Storybook]]
+  - 확장 방향: CI 파이프라인에서 렌더링하고 테스트할 UI 컴포넌트들을 격리된 환경에서 문서화하고 인터랙션을 정의하는 기반 도구로서의 활용법 탐구 [12, 22].
+- [[Husky & Git Hooks]]
+  - 확장 방향: 원격 CI 파이프라인에 코드가 도달하기 전, 개발자의 로컬 환경에서 커밋을 시도하는 시점에 미리 코드 품질 검증(Linting/Formatting)을 강제하는 방법 탐구 [3].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Chrome DevTools.md b/00_Raw/Chrome DevTools.md
new file mode 100644
index 00000000..46995bbb
--- /dev/null
+++ b/00_Raw/Chrome DevTools.md	
@@ -0,0 +1,65 @@
+# [[Chrome DevTools]]
+
+## 📌 Brief Summary
+Chrome DevTools는 개발자가 웹 애플리케이션의 메모리 사용량을 모니터링하고 성능 문제를 디버깅할 수 있도록 돕는 브라우저 내장 도구 세트이다 [1, 2]. 성능 패널, 메모리 패널, 작업 관리자(Task Manager) 등을 통해 메모리 누수(Memory leak), 메모리 팽창(Memory bloat), 잦은 가비지 컬렉션(Garbage collection)과 같은 문제를 시각화하고 식별할 수 있다 [3]. 이 도구를 활용하여 JavaScript 실행 시간, 프레임 렌더링, DOM 노드 상태 등을 실시간으로 분석함으로써 최적화된 사용자 경험을 제공할 수 있다 [4].
+
+## 📖 Core Content
+Chrome DevTools는 메모리 문제 및 애플리케이션 성능을 진단하는 데 다양한 도구와 기능을 제공한다.
+
+*   **Chrome 작업 관리자 (Task Manager):** 실시간으로 페이지의 메모리 사용량을 모니터링하는 데 사용되는 시작점이다 [5]. 'Memory footprint' 열은 DOM 노드가 저장되는 OS 메모리를 나타내며, 이 수치가 증가하면 DOM 노드가 생성되고 있음을 뜻한다 [6]. 'JavaScript Memory' 열의 괄호 안 라이브 숫자는 도달 가능한 객체가 사용하는 JS 힙 메모리를 의미하며, 이 수치가 증가하면 새로운 객체가 생성되거나 기존 객체가 커지고 있음을 나타낸다 [6].
+*   **성능 패널 (Performance Panel):** 시간 경과에 따른 애플리케이션의 메모리 사용량 및 렌더링 동작을 시각화한다 [7]. JS 힙, 문서, DOM 노드, 리스너, GPU 메모리 사용량을 그래프로 표시하며, 강제 가비지 컬렉션 버튼을 통해 베이스라인을 설정할 수 있다 [8, 9]. 또한 JS 실행 시간, 프레임 렌더링, 페인트 및 레이아웃 이동 등을 추적하여 애플리케이션의 렌더링 병목 현상을 파악할 수 있다 [4, 10].
+*   **메모리 패널 (Memory Panel):**
+    *   **힙 스냅샷 (Heap Snapshots):** 특정 시점에 페이지의 JS 객체와 DOM 노드 간의 메모리 분포를 보여준다 [11]. 특히 JavaScript 코드에서 여전히 참조하고 있어 가비지 컬렉션이 되지 않는 분리된 DOM 노드(Detached DOM nodes)를 찾는 데 효과적이다 [12, 13]. 여러 스냅샷을 비교(Comparison 뷰)하여 메모리 사용량이 계속 증가하는 객체(Delta 값이 양수인 객체)를 찾아 누수를 식별할 수 있다 [14].
+    *   **할당 타임라인 (Allocation Timelines / Instrumentation on timeline):** JS 힙에 새로운 메모리가 할당되는 시점을 실시간으로 추적한다 [15, 16]. 파란색 막대는 새로운 할당을 의미하며, 회색으로 변하지 않고 남아 있는 파란색 막대는 메모리에 계속 남아 있는 객체를 나타내어 메모리 누수 후보를 특정할 수 있다 [16, 17].
+    *   **할당 샘플링 (Allocation sampling):** JavaScript 함수별로 메모리가 어떻게 할당되었는지 분석하며, 가장 많은 메모리를 할당한 함수를 상단에 표시한다 [18].
+*   **서버사이드 디버깅:** Node.js 애플리케이션의 경우 `chrome://inspect`를 통해 V8 인스펙터 프로토콜에 연결하여, 서버사이드 코드에서도 클라이언트와 동일한 Chrome DevTools 메모리 프로파일링 기능을 사용할 수 있다 [19].
+
+## ⚖️ Trade-offs & Caveats
+Chrome DevTools의 힙 스냅샷 기능을 사용할 때, 스냅샷을 캡처하고 처리 및 로드하는 데 일정 시간이 소요될 수 있다는 성능적 제약이 있다 [11]. 그 외 Chrome DevTools의 사용에 따른 직접적인 부작용이나 기술적 선택의 반대 급부에 대해서는 소스에 관련 정보가 부족합니다.
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [성능 분석 및 최적화]
+- [[Memory Leak]]
+  - 연결 이유: Chrome DevTools의 핵심 활용 목적 중 하나는 시간이 지남에 따라 메모리 사용량이 계속 증가하는 메모리 누수 현상을 진단하고 수정하는 것이다 [3, 20].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 힙 스냅샷 간의 객체 Delta 값 비교나 타임라인의 파란색 막대 분석을 통해 어떻게 누수 객체를 식별하는지에 대한 원리를 이해할 수 있다 [14, 16].
+
+- [[Garbage Collection]]
+  - 연결 이유: 브라우저가 불필요한 메모리를 회수하는 과정이며, 이 작업이 너무 자주 발생하면 스크립트 실행이 일시 중지되어 애플리케이션에 지연 현상이 발생한다 [3, 20].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: DevTools에서 성능 기록 시작 전후로 강제 가비지 컬렉션을 실행하여 메모리 변화량을 정확히 측정하고(베이스라인 설정), 불필요한 객체가 제대로 수거되는지 확인하는 맥락을 이해할 수 있다 [8, 14].
+
+#### [데이터 구조 및 상태 관리]
+- [[Detached DOM Nodes]]
+  - 연결 이유: DOM 트리에서는 제거되었으나 JavaScript가 여전히 참조를 유지하고 있어 가비지 컬렉션되지 못하는 노드들로, React와 같은 컴포넌트 기반 UI에서 발생하는 흔한 메모리 누수 원인이다 [12, 13].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 힙 스냅샷에서 "Detached"를 필터링하고 유지 경로(Retainer paths)를 추적해야 하는 이유를 이해할 수 있다 [11, 21].
+
+#### [관련 디버깅 도구]
+- [[React Profiler]]
+  - 연결 이유: Chrome DevTools 성능 패널과 함께 사용되어, 어떤 컴포넌트가 언제 렌더링되었고 렌더링에 얼마나 시간이 걸렸는지를 식별하는 데 사용되는 도구이다 [22, 23].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 브라우저 수준의 메모리 및 렌더링 성능 분석(Chrome DevTools)과 React 프레임워크 수준의 렌더링 병목 현상 분석(React Profiler)을 어떻게 결합하여 최적화에 적용하는지 이해할 수 있다 [4, 23].
+
+### Deeper Research Questions
+
+- 잦은 가비지 컬렉션(Garbage Collection) 현상이 발생하여 UI가 끊길 때, Chrome DevTools의 할당 타임라인(Allocation Timeline)을 활용하여 원인이 되는 함수의 메모리 할당 패턴을 어떻게 구체적으로 식별할 수 있는가?
+- 클라이언트 사이드뿐만 아니라 Node.js 백엔드 환경에서 메모리 누수가 의심될 때, `chrome://inspect`를 활용한 V8 인스펙터 프로토콜 분석은 기존 브라우저 디버깅과 어떤 실무적인 차이점과 한계를 가지는가?
+- 애플리케이션이 보유 기기의 메모리 한계를 초과하여 일관되게 느려지는 '메모리 팽창(Memory Bloat)'과 계속해서 사용량이 증가하는 '메모리 누수(Memory Leak)'를 Chrome 작업 관리자와 힙 스냅샷으로 정확하게 구분하는 기준은 무엇인가?
+- Detached DOM 노드나 클로저(Closure)에 의한 유지 참조 문제가 발생했을 때, 힙 스냅샷의 유지 경로(Retainer paths) 패널을 분석하여 가장 효율적으로 참조 고리를 끊어내는 아키텍처 개선 방법은 무엇인가?
+- Chrome DevTools의 성능 패널을 통해 수집한 렌더링 시간, 프레임 드롭 등의 데이터와 React Profiler의 결과를 매핑하여 복잡한 컴포넌트 트리의 렌더링 병목 현상을 정확히 짚어내는 방법론은 무엇인가?
+
+### Practical Application Contexts
+
+- **Implementation:** 개발 중인 애플리케이션의 이벤트 릭(Event leak)이나 데이터 잔존 여부를 확인하기 위해 할당 타임라인 기록 기능을 켜고 사용자 상호작용 후 강제 가비지 컬렉션을 실행해보는 과정에서 사용된다.
+- **System Design:** 컴포넌트 마운트 해제 시 제거되지 않은 이벤트 리스너(Event listener)나 클로저로 인해 메모리에 객체가 남지 않도록, 프레임워크 라이프사이클(예: React의 useEffect cleanup) 설계를 강제하는 지표로 활용된다.
+- **Operation / Maintenance:** 프로덕션 환경에서 장시간 사용 시 애플리케이션이 느려지거나 크래시가 발생한다는 사용자 제보를 받았을 때, 힙 스냅샷을 캡처 및 비교하여 메모리 누수를 진단하고 사후 디버깅을 수행하는 데 필수적으로 적용된다.
+- **Learning Path:** 프론트엔드 개발자가 JavaScript의 메모리 관리 메커니즘과 가비지 컬렉션 원리를 시각적으로 이해하고, 성능 최적화의 기본기를 다지기 위한 핵심 학습 도구로 활용된다.
+- **My Project Relevance:** 현재 유지보수 중인 프로젝트나 새로 구축하는 프론트엔드 시스템에서, 불필요한 DOM 노드 및 거대한 JavaScript 번들로 인한 초기 로딩 및 런타임 성능 저하를 방지하기 위한 정기 성능 감사 도구로 직접 적용할 수 있다.
+
+### Adjacent Topics
+
+- [[Core Web Vitals]]
+  - 확장 방향: Chrome DevTools 성능 패널에서 측정하는 데이터를 바탕으로 First Input Delay (FID), Interaction to Next Paint (INP) 등 실제 사용자 경험(UX) 품질을 나타내는 Core Web Vitals 지표를 종합적으로 평가하고 최적화하는 전략으로 확장할 수 있다.
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Clean Code and SOLID Principles.md b/00_Raw/Clean Code and SOLID Principles.md
new file mode 100644
index 00000000..36c11673
--- /dev/null
+++ b/00_Raw/Clean Code and SOLID Principles.md	
@@ -0,0 +1,68 @@
+# [[Clean Code and SOLID Principles]]
+
+## 📌 Brief Summary
+Clean Code와 SOLID 원칙은 소프트웨어 개발에서 유지보수성, 가독성, 확장성을 높이기 위해 사용되는 핵심 설계 원칙이다 [1]. SOLID는 SRP, OCP, LSP, ISP, DIP의 5가지 원칙으로 구성되어 명확하고 잘 조직된 소프트웨어 구조를 안내하며, 객체 지향뿐만 아니라 React의 함수형 컴포넌트에도 유효하게 적용된다 [1, 2]. 더불어 DRY, KISS, YAGNI와 같은 Clean Code 원칙들은 불필요한 코드 중복과 복잡성을 줄여, 코드를 단순하고 예측 가능하며 테스트하기 쉽게 만들어준다 [3, 4].
+
+## 📖 Core Content
+
+**SOLID 원칙의 React 적용**
+*   **단일 책임 원칙 (SRP - Single Responsibility Principle):** 컴포넌트나 커스텀 훅은 변경되어야 할 이유가 단 하나여야 한다 [5]. 컴포넌트가 너무 많은 역할을 수행하거나 크기가 300줄을 넘어갈 경우, UI 컴포넌트(예: UserProfile, UserPosts)나 커스텀 훅으로 비즈니스 로직을 분리해야 한다 [2, 5].
+*   **개방-폐쇄 원칙 (OCP - Open/Closed Principle):** 기존 코드를 수정하지 않고도 새로운 기능을 추가할 수 있어야 한다 [6]. React에서는 컴포넌트 합성(Composition), `children` prop, 혹은 렌더 프롭스(render-props)를 활용하여 기존 컴포넌트를 건드리지 않고 기능을 확장할 수 있다 [2, 7, 8].
+*   **리스코프 치환 원칙 (LSP - Liskov Substitution Principle):** 하위 타입은 상위 타입을 무리 없이 대체할 수 있어야 한다 [6]. 현대 React는 클래스 상속을 거의 사용하지 않지만, 서브 컴포넌트가 기본 컴포넌트의 자리를 매끄럽게 대체할 수 있도록 설계하는 방식으로 이 원칙을 적용한다 [2, 8].
+*   **인터페이스 분리 원칙 (ISP - Interface Segregation Principle):** 컴포넌트는 사용하지 않는 props에 의존해서는 안 된다 [2, 7]. 거대한 객체를 통째로 props로 넘기기보다는, 해당 컴포넌트가 실제로 사용하는 명확하고 작은 단위의 데이터만 전달해야 한다 [7, 8].
+*   **의존성 역전 원칙 (DIP - Dependency Inversion Principle):** 구체적인 구현(Concretions)이 아닌 추상화에 의존해야 한다 [2]. 컴포넌트 간 직접적인 결합을 피하고, props나 Context를 통해 의존성을 주입받아 사용한다 [2, 8].
+
+**추가적인 Clean Code 원칙**
+*   **DRY (Don't Repeat Yourself):** 동일한 코드를 두 번 작성하지 않고 재사용 가능한 로직을 커스텀 훅이나 고차 컴포넌트(HOC)로 추출한다 [4, 9]. 단, 성급한 추상화를 피하기 위해 패턴이 최소 세 번 이상 반복될 때 추출하는 것이 권장된다 [10].
+*   **KISS (Keep It Simple, Stupid):** 복잡성보다 단순성을 최우선으로 해야 한다 [4]. 컴포넌트와 함수를 '단순하고 바보같이(simple and dumb)' 유지하며, 불필요한 조기 최적화를 피해야 한다 [9, 11].
+*   **YAGNI (You Aren't Gonna Need It):** 미래에 사용될지도 모른다는 이유로 기능을 미리 구현하지 않는다 [4, 12]. 현재 컴포넌트나 요구사항에 반드시 필요한 기능만 구현하여 유지보수해야 할 죽은 코드(dead code)를 방지한다 [9, 13].
+
+## ⚖️ Trade-offs & Caveats
+*   **SOLID 도입의 복잡성:** SOLID 원칙을 도입하면 코드가 고도로 체계화되고 유지보수성이 향상되지만, 초기 설계 단계에서는 구조가 지나치게 복잡하게 느껴질 수 있다 [14].
+*   **DRY 원칙과 과도한 추상화:** 코드의 중복을 줄여주지만, 무분별하게 적용할 경우 지나치게 복잡한 추상화(overly complex abstractions)를 초래하여 코드를 이해하기 더 어렵게 만들 수 있다 [10, 14].
+*   **KISS 원칙의 지나친 단순화:** 디버깅을 쉽게 하고 직관적인 코드를 만들 수 있으나, 때로는 복잡한 비즈니스 요구사항에 대한 해결책을 너무 단순화(oversimplify)할 위험이 존재한다 [14].
+*   **YAGNI와 확장성 간과:** 낭비되는 노력을 줄이고 기민하게 대응할 수 있도록 돕지만, 현재에만 너무 집중한 나머지 미래의 확장성(future scalability)을 간과할 가능성이 있다 [14].
+*   **Clean Code 유지를 위한 규율:** 읽고 유지보수하기 쉬운 코드를 작성하려면 팀 전체의 지속적인 노력과 강력한 규율(discipline)이 요구된다 [14].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [소프트웨어 엔지니어링 아키텍처 원칙]
+- [[Feature-Sliced Design]]
+  - 연결 이유: 코드를 기술적인 파일 단위가 아니라 비즈니스 기능(Feature)이나 도메인 중심으로 분리하여 SRP(단일 책임 원칙) 및 관심사 분리를 아키텍처 수준에서 실현한다 [15-17].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 거대한 프론트엔드 프로젝트에서 하위 레이어만 참조할 수 있도록 의존성을 제어(DIP와 유사)하여, 독립적인 코드 모듈화를 구축하는 방법을 배울 수 있다 [16, 17].
+
+#### [React 구현 패턴 및 기술]
+- [[Custom Hooks]]
+  - 연결 이유: React에서 DRY 원칙을 실현하고 비즈니스 로직을 UI와 분리하여 SRP를 충족시키는 가장 효과적인 리팩토링 단위이자 도구이다 [10, 18].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 데이터 페칭, 폼(Form) 처리 등의 복잡한 논리를 커스텀 훅으로 분리함으로써 컴포넌트를 단순하게(KISS) 유지하는 패턴을 이해할 수 있다 [9].
+- [[Component Composition]]
+  - 연결 이유: OCP(개방-폐쇄 원칙)를 React에서 구현하기 위한 핵심 패턴으로, 기존 컴포넌트의 내부 코드를 수정하지 않고 `children`을 통해 새로운 기능을 조합 및 확장할 수 있게 해준다 [7, 8].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: React 환경에서 상속 없이 합성만을 사용하여 유연하고 재사용 가능한 UI 구조를 어떻게 설계하는지 파악할 수 있다.
+
+### Deeper Research Questions
+
+- React의 함수형 프로그래밍 패러다임에서 클래스 상속을 전제로 한 LSP(리스코프 치환 원칙)는 컴포넌트 설계 시 구체적으로 어떻게 재해석되고 적용되어야 하는가?
+- DRY 원칙을 지키기 위해 공통 로직을 추상화할 때, 지나친 추상화를 경계하는 KISS 원칙과 충돌한다면 이를 조율하기 위한 실무적인 기준(예: Rule of three) 외에 어떤 척도가 있는가?
+- ISP(인터페이스 분리 원칙)를 위배하여 거대한 Props 객체를 하위 컴포넌트로 전달할 때 발생하는 불필요한 리렌더링 문제를 React 최적화 기법으로 어떻게 극복할 수 있는가?
+- Feature-Sliced Design(FSD)과 같이 계층과 규칙이 엄격한 아키텍처를 도입할 때, YAGNI 원칙을 함께 적용하여 오버엔지니어링을 피하는 방법은 무엇인가?
+- SRP를 준수하기 위해 300줄 이상의 React 컴포넌트를 다수의 작은 컴포넌트로 분리할 때 발생하는 Props 드릴링(Prop Drilling) 문제를 아키텍처 측면에서 어떻게 효율적으로 해결할 수 있는가?
+
+### Practical Application Contexts
+
+- **Implementation:** 300줄이 넘는 비대해진 React 컴포넌트를 리팩토링할 때, 상태 관리나 API 호출 로직은 커스텀 훅으로, 독립적인 UI 요소는 개별 컴포넌트로 쪼개어 SRP와 Clean Code를 실현한다 [5, 18].
+- **System Design:** 소프트웨어 설계 초기 단계에서는 당장 필요하지 않은 미래 기능까지 포함하지 않고(YAGNI), 대신 새로운 요구사항이 생겼을 때 쉽게 덧붙일 수 있도록 컴포넌트 합성을 활용한 OCP 구조를 설계한다 [7, 9].
+- **Operation / Maintenance:** ESLint 및 Prettier와 같은 도구와 Husky를 연동하여 CI/CD 파이프라인에서 코드가 커밋되기 전 Clean Code 규칙과 파일 명명 규칙이 자동 준수되도록 강제한다 [19].
+- **Learning Path:** 처음 React를 배울 때는 KISS 원칙에 입각한 단순한 컴포넌트 작성을 연습하고, 점차 DRY를 위한 커스텀 훅 분리를 거쳐 SOLID 원칙이 결합된 대규모 아키텍처 설계로 학습을 확장한다.
+- **My Project Relevance:** 현재 작업 중인 코드베이스에서 사용되지 않는 방대한 객체 속성이 props로 전달되고 있지 않은지 점검하여(ISP 적용), 코드 결합도를 낮추고 유지보수성을 극대화하는 리팩토링 작업에 즉시 적용할 수 있다.
+
+### Adjacent Topics
+
+- [[State Management Architecture]]
+  - 확장 방향: 컴포넌트 레벨에서의 책임 분리를 넘어, Context API, Zustand, Redux 등 전역 상태 관리 라이브러리를 활용할 때 각 도메인의 상태와 비즈니스 로직을 어떻게 분리(SRP)하고 의존성을 관리할지 탐구한다.
+- [[Frontend Performance Optimization]]
+  - 확장 방향: Clean Code와 모듈 분리(예: 코드 스플리팅, 지연 로딩)가 React 컴포넌트의 불필요한 렌더링을 방지하고 프론트엔드 성능(Core Web Vitals)을 어떻게 향상시키는지 연계하여 조사한다.
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Context API to Zustand Migration.md b/00_Raw/Context API to Zustand Migration.md
new file mode 100644
index 00000000..d21786f7
--- /dev/null
+++ b/00_Raw/Context API to Zustand Migration.md	
@@ -0,0 +1,54 @@
+# [[Context API to Zustand Migration]]
+
+## 📌 Brief Summary
+Context API에서 Zustand로의 마이그레이션은 React 애플리케이션의 렌더링 성능 저하를 방지하고 상태 관리 구조를 단순화하기 위해 수행되는 아키텍처 개선 작업입니다 [1-3]. 전역 상태 변경 시 이를 구독하는 모든 컴포넌트가 불필요하게 재렌더링되는 Context API의 태생적 한계를 극복하기 위해 진행됩니다 [1, 2]. 상태의 특정 조각(slice)만 구독할 수 있는 선택자(Selector) 패턴을 제공하는 Zustand를 도입함으로써, 점진적으로 프로젝트의 확장성과 최적화를 달성할 수 있습니다 [3-5].
+
+## 📖 Core Content
+*   **Context API의 성능적 한계 (Re-render 문제)**: Context API는 근본적으로 '브로드캐스트 시스템'으로 작동합니다 [1, 6]. Context가 가진 여러 상태 값 중 하나만 변경되더라도, `useContext`를 통해 해당 Context를 구독하고 있는 모든 하위 컴포넌트가 재렌더링됩니다 [2, 3]. 이러한 특성으로 인해 실시간 데이터나 사용자 입력과 같이 빈번하게 변경되는 상태(Dynamic state)를 다룰 때 애플리케이션 성능이 크게 저하되는 일명 '재렌더링 폭풍(Re-render storm)'이 발생할 수 있습니다 [7-9].
+*   **Zustand를 통한 성능 최적화 (Selector Pattern)**: Zustand는 상태와 업데이트 로직을 React 컴포넌트 트리 외부에 존재하는 평범한 JavaScript 객체(store)로 분리합니다 [10]. Zustand의 핵심은 컴포넌트가 전체 스토어를 구독하는 것이 아니라, 선택자(Selector) 함수를 사용하여 필요한 특정 상태 조각(slice)에만 구독할 수 있다는 점입니다 [1, 3]. 이를 통해 개발자는 성능 저하 없이 글로벌 상태를 안전하게 관리할 수 있습니다 [3].
+*   **하이브리드 상태 관리 아키텍처**: 마이그레이션 과정에서 모든 Context를 Zustand로 교체할 필요는 없습니다 [11]. 테마(다크/라이트 모드)나 다국어 설정(Locale), 기능 플래그(Feature flag)처럼 애플리케이션 로드 시 한 번 설정되고 거의 변경되지 않는 정적인 설정 값에는 여전히 Context API가 훌륭한 선택지입니다 [11, 12]. 반면 장바구니, 알림 시스템, UI 상태 등 동적인 애플리케이션 상태는 Zustand 스토어에서 관리하도록 책임을 분리하는 것이 이상적인 모범 사례입니다 [11, 13].
+*   **점진적 마이그레이션(Incremental Migration) 전략**: 대규모 코드베이스에서 전체 상태를 한 번에 재작성(Rewrite)하는 것은 매우 위험합니다 [4]. 대신, 애플리케이션 내의 알림 기능처럼 단순한 유틸리티부터 시작하여 결제 흐름과 같은 복잡한 도메인으로 스토어를 하나씩 천천히 이전하는 점진적 접근법이 권장됩니다 [4]. 이를 통해 새로운 기능 개발을 멈추지 않으면서도 레거시 아키텍처를 안전하게 현대화할 수 있습니다 [4].
+
+## ⚖️ Trade-offs & Caveats
+*   **유연성으로 인한 일관성 저하 위험**: Zustand는 상용구(Boilerplate)가 거의 없고 설계가 매우 유연하기 때문에, 팀 내에 엄격한 코드 컨벤션이 없다면 심각한 일관성 문제로 이어질 수 있습니다 [14-16]. 예를 들어 팀원들이 각각 콜백, 프로미스, 커스텀 미들웨어 등 각기 다른 방식으로 비동기 처리를 구현하여 코드베이스가 혼란스러워질 수 있습니다 [15, 17].
+*   **구독 및 선택자(Selector) 관리의 어려움**: Zustand를 사용하더라도 올바른 선택자 패턴을 적용하지 않으면 컴포넌트 구독이 폭발적으로 늘어나 성능 이슈가 재발할 수 있습니다 [16, 18]. 팀 내 모든 개발자가 선택자 사용 규칙을 숙지해야 하는 오버헤드가 발생합니다 [18].
+*   **엔터프라이즈 환경에서의 한계점**: 애플리케이션이 매우 거대해지거나 10명 이상의 큰 팀이 작업할 경우, Zustand의 자유로움보다는 Redux가 제공하는 단일 진실 공급원(Single source of truth)과 강제된 구조, 강력한 미들웨어 생태계, 브라우저 디버깅 도구가 더 적합할 수 있습니다 [19-21]. 따라서 Zustand로 마이그레이션한 이후에도, 프로젝트 복잡성이 특정 임계점을 넘으면 다시 Redux로의 고통스러운 마이그레이션을 계획해야 할 수 있습니다 [21, 22].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [아키텍처/기반 기술 (Architecture & Infrastructure)]
+- [[Selector Pattern]]
+  - 연결 이유: Context API가 가진 전체 재렌더링의 맹점을 극복하고, Zustand가 효율적으로 상태를 구독하게 해주는 핵심 디자인 패턴입니다 [1, 3].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 상태 관리 라이브러리가 React 렌더링 사이클에 개입하여 렌더링 범위를 최소화하는 내부 메커니즘 [3].
+
+- [[Re-render Storm]]
+  - 연결 이유: Context API 기반의 프로젝트에서 마이그레이션을 결심하게 만드는 가장 치명적인 성능적 부작용입니다 [7, 8].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 불필요하게 깊은 렌더링 트리가 프론트엔드 성능과 UX(체감 속도, INP 등)에 미치는 악영향 [2, 7, 8].
+
+#### [구현/활용 도구 (Implementation & Tools)]
+- [[Incremental Migration]]
+  - 연결 이유: 대형 리팩토링이나 구조적 마이그레이션을 진행할 때 리스크를 최소화하기 위해 현업에서 권장하는 적용 방식입니다 [4].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 기능 개발 속도와 코드베이스 개선이라는 두 가지 목표를 동시에 달성하는 안정적인 엔지니어링 전략 [4].
+
+### Deeper Research Questions
+- Zustand의 선택자(selector) 패턴을 사용할 때 얕은 비교(shallow comparison)와 깊은 비교(deep comparison)를 어떻게 적용해야 컴포넌트 재렌더링을 가장 효과적으로 차단할 수 있는가?
+- 점진적 마이그레이션(Incremental Migration)을 진행하는 동안 Context API와 Zustand가 공존할 때, 두 상태 저장소 간의 상태 동기화 및 단일 진실 공급원(Single Source of Truth) 원칙을 어떻게 유지할 것인가?
+- Zustand가 제공하는 유연성이 단점으로 변모하는 대규모 비동기 상태 관리 상황에서, Redux(또는 RTK Query)로의 2차 마이그레이션이 필수적인 임계점은 구체적으로 언제인가?
+- Zustand 스토어의 구조를 애플리케이션 전체를 다루는 '단일 글로벌 스토어'와 도메인 단위로 쪼개는 '다중 스토어'로 나눌 때 각각의 성능과 유지보수 측면의 장단점은 무엇인가?
+- Context API와 Zustand를 하이브리드 패턴으로 운용할 때, 시스템 디자인 관점에서 전역 Provider의 깊이(Depth) 문제를 어떻게 방지할 수 있는가?
+
+### Practical Application Contexts
+- **Implementation:** React의 `useContext` 및 하위 컴포넌트를 감싸는 `Provider` 패턴 코드를 제거하고, `create()` 함수를 이용해 컴포넌트 외부에 모듈화된 Zustand 스토어를 정의하여, 선택자 함수로 필요한 상태만 가져오도록 코드를 수정합니다 [10, 23].
+- **System Design:** 아키텍처 설계 시, 변경이 드문 정적 전역 데이터(다크 모드, 로케일, 기능 플래그 등)는 기존 Context API 트리에 남겨두고, 사용자와 상호작용이 잦은 데이터(장바구니, 사용자 입력 등)는 Zustand 스토어로 분리하는 '역할 분리 시스템(투트랙)'을 구축합니다 [11-13].
+- **Operation / Maintenance:** 레거시 코드베이스 개선 시 리스크를 최소화하기 위해 '전체 재작성'을 지양하고 한 번에 하나의 스토어(예: 알림 기능부터 시작)씩 Zustand로 전환하는 점진적 전략을 채택하여 서비스 연속성을 보장합니다 [4].
+- **Learning Path:** 처음 React의 데이터 흐름과 Prop Drilling 문제를 이해하기 위해 내장 기능인 Context API를 충분히 학습한 후, 실제 프로젝트에서 렌더링 성능 이슈를 겪어본 시점에 Zustand를 도입하는 것이 최적의 학습 곡선을 형성합니다 [24].
+- **My Project Relevance:** 타인이 작성한 기존 React 프로젝트(학사 졸업 논문 등)를 리팩토링할 때, 복잡하게 얽혀있는 전역 상태와 무거운 Redux 구현체, 혹은 과도하게 남용된 Context API를 파악해 Zustand 같은 경량화 라이브러리로 대체하여 클라이언트 상태(Client State)를 단순화할 수 있습니다 [5, 9, 25].
+
+### Adjacent Topics
+- [[TanStack Query (React Query)]]
+  - 확장 방향: Zustand는 주로 전역 '클라이언트 상태(Client State)'를 관리하기 위한 도구이므로, API를 통한 비동기 데이터나 캐싱, 로딩 처리 등을 담당하는 '서버 상태(Server State)' 관리 도구인 TanStack Query와 어떻게 결합하여 완전한 상태 관리 아키텍처를 구현할 수 있는지 확장하여 학습합니다 [1, 25].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Context Engineering.md b/00_Raw/Context Engineering.md
new file mode 100644
index 00000000..fed671a9
--- /dev/null
+++ b/00_Raw/Context Engineering.md	
@@ -0,0 +1,73 @@
+# [[Context Engineering]]
+
+## 📌 Brief Summary
+Context Engineering(컨텍스트 엔지니어링)은 대규모 언어 모델(LLM) 기반 에이전트가 긴 작업을 수행할 때 컨텍스트 윈도우에 진입하는 정보를 능동적으로 큐레이션하고 구조화하는 시스템 설계 패러다임이다 [1-3]. 이는 단일 턴의 지시문을 최적화하는 프롬프트 엔지니어링(Prompt Engineering)을 넘어, 다중 턴에 걸쳐 어떠한 정보를 보존, 압축, 검색 및 주입할지를 결정하여 모델의 추론 환경을 관리한다 [1, 2]. 에이전트 하네스 엔지니어링(Agent Harness Engineering)의 핵심 하위 레이어인 컨텍스트 관리자(C-component)를 통해 구현되며, 에이전트의 신뢰성 향상과 토큰 비용 최적화, 그리고 보안 유지에 결정적인 역할을 한다 [4-6].
+
+## 📖 Core Content
+
+*   **프롬프트 엔지니어링에서의 진화:** AI 에이전트 시스템의 발전은 '무엇을 말할 것인가(Prompt Engineering)'에서 '어떤 정보를 보여줄 것인가(Context Engineering)'를 거쳐, '어떤 환경을 구축할 것인가(Harness Engineering)'로 진화했다 [1, 3, 7-10]. Context Engineering은 에이전트의 작업 기간이 길어지면서 발생하는 지시 사항의 표류(instruction drift)와 컨텍스트 부패(context rot)를 해결하기 위해 등장했다 [3, 9].
+*   **능동적 지식 필터로서의 역할:** Context Engineering은 단순한 정보의 수동적 전달 경로가 아니라, 모델이 성취할 수 있는 바를 결정하는 능동적 인식 필터(active epistemic filter)로 작동한다 [11, 12]. 하네스는 잘림(Truncation), 요약(Summarization), 검색 증강(Retrieval-augmented), 지식 그래프(Knowledge graph), 행동으로서의 메모리(Memory-as-action) 등의 전략을 통해 컨텍스트를 스케줄링한다 [13-17].
+*   **초장문 컨텍스트 모델(Ultra-long-context models) 대응:** 100만 토큰 이상의 윈도우를 가진 모델이 등장했음에도, 시퀀스 길이가 길어지면 초기나 중간에 위치한 정보에 대한 주의력이 떨어지는 '주의력 희석(attention dilution)' 현상이 발생한다 [18, 19]. 따라서 Context Engineering의 주요 과제는 단순히 '무엇을 남길 것인가(retention)'에서 '무엇을 돋보이게 할 것인가(salience)'로 이동했으며, 모델의 주의력이 가장 강한 위치에 중요 정보를 배치하는 구조적 닻(attention anchors)이나 계층적 정보 구성이 필요하다 [18, 19].
+*   **적응형 컨텍스트 압축(Adaptive Context Compaction):** 토큰 예산이 고갈될 때 발생하는 시스템 충돌을 막기 위해, 컨텍스트 압력에 따라 5단계(70% 경고, 80% 관찰 마스킹, 85% 빠른 가지치기, 90% 공격적 마스킹, 99% 전체 요약)의 점진적인 압축 파이프라인을 운영한다 [20-22]. 대규모 도구 출력(예: 수천 줄의 코드나 로그)은 컨텍스트를 과도하게 점유하므로, 이를 파일 시스템이나 스크래치 파일로 오프로딩(offloading)하고 모델에는 짧은 요약과 파일 참조(reference)만 남긴다 [22-25].
+*   **이중 메모리 아키텍처(Dual-Memory Architecture):** 전략적 사고를 위한 컨텍스트와 단기 실행을 위한 컨텍스트의 충돌을 피하기 위해, 전체 대화 이력을 요약한 일화적 메모리(Episodic memory)와 최근 몇 번의 상세 교환 기록을 그대로 유지하는 작업 메모리(Working memory)를 분리하여 함께 주입(Combined injection)한다 [26-28].
+*   **런타임 맥락 주입(Context-Injected Recovery & Reminders):** 긴 세션에서 에이전트가 초기 지시를 잊는 것을 막기 위해, 도구 실행의 실패나 특정 이벤트 발생 시 적절한 시스템 알림(System Reminders) 및 오류 복구 지침을 컨텍스트에 즉시 주입하여 행동을 교정한다 [29-31].
+
+## ⚖️ Trade-offs & Caveats
+
+*   **정보 보존과 보안의 상충 관계 (Retention-Security Coupling):** 컨텍스트 윈도우를 길게 유지하면 에이전트의 작업 연속성과 성능은 향상되지만, 외부에서 주입된 악의적 페이로드(간접 프롬프트 주입)가 시스템 내에 더 오래 체류하게 되어 보안 위험이 크게 증가한다. 반면 보안을 위해 짧게 유지하면 작업 성능이 저하되는 딜레마가 있다 [32-34].
+*   **컨텍스트 부패 (Context Rot) 및 토큰 비용:** 무분별하게 컨텍스트를 누적하면 모델의 정확도가 떨어질 뿐만 아니라 토큰 소비량이 작업 복잡도와 무관하게 초선형적(superlinear)으로 증가하여 경제적 비용이 기하급수적으로 커진다 [35-37]. 
+*   **검색 지연 (Retrieval Latency Injection):** 모든 기록을 저장하고 필요할 때 검색하는 RAG 방식은 정보 손실을 피할 수 있지만, 긴 수평선의 작업에서는 각 단계마다 검색 쿼리를 실행해야 하므로 선형적으로 누적되는 심각한 지연 시간(Latency)을 초래한다 [38, 39].
+*   **압축 시 데이터 출처(Provenance) 상실:** 컨텍스트의 요약 및 압축은 정보의 밀도를 높이지만, 해당 정보가 어디에서 왔는지에 대한 출처 데이터를 조용히 폐기할 위험이 있다 [40, 41]. 이를 보완하지 않으면 환각이나 오류 발생 시 디버깅이 불가능해진다 [42].
+*   **적대적 콘텐츠의 검색 게임화 (Retrieval gaming):** 외부 콘텐츠를 검색해 컨텍스트를 구성할 때, 공격자가 예상되는 미래 쿼리와 의미적 유사성이 높도록 악의적 지시사항을 조작하면, 하네스가 이를 가장 관련성 높은 정보로 착각하여 우선적으로 컨텍스트에 주입할 위험이 있다 [43, 44].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [관계 유형 A: 아키텍처/기반 기술]
+- [[Agent Harness (에이전트 하네스)]]
+  - 연결 이유: Context Engineering이 실제로 작동하고 관리되는 상위 인프라 구조이기 때문이다 [8, 10, 45].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 컨텍스트 관리가 단순히 프롬프트를 다듬는 것을 넘어, 어떻게 실행 루프, 도구 레지스트리, 메모리 스토어와 결합하여 안전하고 통제된 자율 에이전트 환경을 구성하는지 이해할 수 있다 [4, 46].
+
+- [[C-component (Context Manager)]]
+  - 연결 이유: 에이전트 하네스 구조 내에서 Context Engineering 정책(압축, 검색, 우선순위 할당 등)을 전담하여 집행하는 핵심 거버넌스 모듈이다 [46, 47].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 매 턴마다 모델의 컨텍스트 윈도우에 어떤 정보가 어떻게 필터링되어 들어가는지 구체적인 메커니즘을 파악할 수 있다 [4, 47].
+
+- [[Adaptive Context Compaction (적응형 컨텍스트 압축)]]
+  - 연결 이유: Context Engineering이 토큰 예산 초과(OOM)를 방지하기 위해 채택하는 필수적인 세부 최적화 기법이다 [21, 22].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 70%부터 99%까지의 점진적 압력 한계치에 따라 관찰 내용 마스킹, 빠른 가지치기, 전체 요약 등이 어떻게 단계적으로 적용되는지 알 수 있다 [22, 48].
+
+#### [관계 유형 B: 최적화 및 문제 현상]
+- [[Context Rot (컨텍스트 부패)]]
+  - 연결 이유: 효율적인 Context Engineering이 부재할 때 장기 실행 에이전트가 겪게 되는 핵심 실패 모드이기 때문이다 [35-37].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 하네스가 왜 적극적인 퇴거(eviction) 정책과 정보 압축을 스케줄링해야만 초선형적인 비용 증가와 모델의 지시 망각을 막을 수 있는지 근본적인 이유를 배울 수 있다 [36, 37, 49].
+
+- [[Indirect Prompt Injection (간접 프롬프트 주입)]]
+  - 연결 이유: 에이전트가 외부 문서를 검색해 컨텍스트에 포함시키는 과정에서 발생하는 치명적인 시스템 보안 취약점이다 [50, 51].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: Context Engineering 설계 시 지시(instruction) 데이터와 정보(data) 데이터를 어떻게 분리하고 출처(provenance)를 추적해야 하는지에 대한 보안적 필요성을 이해할 수 있다 [50, 51].
+
+### Deeper Research Questions
+
+- 100만 토큰 이상의 초장문 컨텍스트를 지원하는 모델에서 '주의력 희석(Attention Dilution)'을 최소화하기 위해 하네스 레벨에서 구조적 닻(Attention Anchors)을 어떻게 효율적으로 배치하고 스케줄링할 수 있는가?
+- 컨텍스트 보존 기간이 길어질수록 성능이 향상되지만 동시에 악의적 프롬프트의 체류 시간이 증가하는 상충 관계(Retention-Security Coupling)를 수학적으로 모델링하고 공동 최적화(Joint Optimization)하는 프레임워크는 어떻게 구축할 수 있는가?
+- 에이전트가 자체적으로 컨텍스트를 편집하고 압축하는 '행동으로서의 메모리(Memory-as-action)' 방식은 하네스가 중앙에서 강제하는 규칙 기반 요약(Rule-based Summarization) 방식과 비교하여 경제성 및 정확도 면에서 어떤 차이를 보이는가?
+- 대규모 도구 실행 결과나 로그를 파일 시스템 등 외부 아티팩트 저장소로 오프로딩(offloading)할 때, 모델이 필요시 지연 없이 다시 해당 정보를 검색할 수 있도록 의미적 포인터(semantic pointer)를 어떻게 구성해야 하는가?
+- 컨텍스트 압축(Compaction) 과정에서 불가피하게 발생하는 데이터 출처(Provenance)의 손실을 방지하고, 에이전트가 요약된 컨텍스트를 기반으로 추론할 때 발생할 수 있는 환각을 어떻게 교정할 수 있는가?
+
+### Practical Application Contexts
+
+- **Implementation:** LangChain의 DeepAgents 프레임워크처럼 시스템 프롬프트를 단일 거대 파일로 제공하지 않고 미들웨어 아키텍처를 사용하여 조건별(우선순위, 모델 벤더별)로 모듈화하여 동적 주입 및 검증 루프를 구성한다 [52-54].
+- **System Design:** 도구 출력 결과(예: 수천 줄의 코드 분석 결과)를 컨텍스트에 그대로 넣지 않고, 8,000자 이상의 출력은 스크래치 파일에 저장한 후 모델에는 메타데이터(예: "파일 읽기 완료, 142줄, 4,831자")와 참조 핸들만 제공하도록 도구 결과 최적화(Tool Result Optimization) 파이프라인을 설계한다 [23-25, 55].
+- **Operation / Maintenance:** 모델 API가 보고하는 실제 프롬프트 토큰 사용량(prompt_tokens)을 기준으로, 현재 사용량이 80%에 도달하면 과거 도구 출력결과를 참조로 대체(마스킹)하고 99% 도달 시 LLM을 사용해 전체 대화 이력을 요약하는 모니터링 시스템을 운영한다 [20-22].
+- **Learning Path:** 처음에는 단일 프롬프트 최적화(Prompt Engineering)부터 시작하여, 에이전트가 여러 세션을 넘나들며 작업할 때 어떤 기억을 남기고 버릴지 설계하는 Context Engineering을 익히고, 최종적으로 이를 인프라 레벨의 강제 규칙으로 승격시키는 Harness Engineering으로 학습을 확장한다 [1, 3, 7, 8, 56].
+- **My Project Relevance:** 복잡한 소프트웨어 엔지니어링 문제를 해결하는 코딩 에이전트를 구축할 때, 토큰 한도 초과(OOM) 방지와 지속적인 목표 인지를 위해 에피소드 메모리(Episodic Memory) 요약과 작업 메모리(Working Memory) 유지를 분리 적용하는 데 직접적으로 활용할 수 있다 [26-28].
+
+### Adjacent Topics
+
+- [[Prompt Engineering]]
+  - 확장 방향: 단일 턴 상호작용에서 어떻게 지시를 전달할 것인가에 대한 모델 최적화 기법으로, 다중 턴에서 구조적 정보 배치를 다루는 Context Engineering 이전 단계의 기반 지식으로 확장할 수 있다 [1, 6, 7].
+- [[Retrieval-Augmented Generation (RAG)]]
+  - 확장 방향: 제한된 컨텍스트 예산 내에서 외부 지식을 언제, 어떻게 쿼리하고 주입할 것인지에 대한 구체적인 메커니즘을 탐구하는 방향으로 심화할 수 있다 [57, 58].
+
+---
+*Last updated: 2026-05-01*
\ No newline at end of file
diff --git a/00_Raw/DRY.md b/00_Raw/DRY.md
new file mode 100644
index 00000000..c6381252
--- /dev/null
+++ b/00_Raw/DRY.md
@@ -0,0 +1,60 @@
+# [[DRY]]
+
+## 📌 Brief Summary
+DRY(Don't Repeat Yourself)는 동일한 코드를 두 번 작성하지 않고 기존 코드를 재사용해야 한다는 핵심 소프트웨어 개발 원칙입니다 [1]. 코드의 중복을 피하고 이를 별도의 컴포넌트나 함수로 분리하여 향후 코드의 유지보수와 수정을 용이하게 만드는 것을 목표로 합니다 [2]. React 환경에서는 주로 공통 로직을 커스텀 훅(Custom Hooks)이나 고차 컴포넌트(Higher-Order Components)로 추출하는 방식으로 구현됩니다 [3, 4].
+
+## 📖 Core Content
+*   **중복 제거의 이점**: 코드를 작성할 때 중복을 피하면 향후 요구사항 변경 시 유지보수가 훨씬 쉬워집니다 [2]. 중복된 코드가 많으면 코드를 변경할 때 여러 곳을 찾아 수정해야 하지만, DRY 원칙을 지키면 단일 위치(one place)에서만 변경 사항을 적용하면 되기 때문입니다 [2].
+*   **React에서의 구현 방법**: 반복적인 로직이 존재하는 애플리케이션에서는 재사용 가능한 로직을 추출해야 합니다 [4]. React에서는 이를 주로 커스텀 훅(Custom Hooks)이나 고차 컴포넌트(Higher-Order Components, HOC)를 생성하여 처리합니다 [3, 4].
+*   **적절한 추상화 타이밍**: 성급한 최적화를 방지하고 코드를 단순하게 유지하기 위해, 특정 코드 패턴이 최소 '3번' 반복될 때까지 기다렸다가 추상화(abstraction)를 진행하는 것이 권장되는 가이드라인입니다 [3].
+
+## ⚖️ Trade-offs & Caveats
+*   **과도한 추상화의 위험성**: 중복을 줄이려는 노력으로 인해 추상화가 지나치게 복잡해질 수 있는 부작용이 있습니다 [5]. 
+*   **KISS 원칙과의 충돌**: 재사용 가능한 추상화를 만들었지만, 그 결과물이 원래의 반복된 코드보다 이해하기 더 어려워진다면 이는 추상화의 목적을 상실한 것입니다 [3]. 이 경우 코드를 단순하게 유지하라는 "KISS (Keep It Simple, Stupid)" 원칙을 위반하게 됩니다 [3].
+*   **유연성 저하 우려**: Feature-Sliced Design과 같은 최신 프론트엔드 아키텍처에서는 DRY 원칙의 준수와 특정 기능에 맞춘 로컬 커스터마이징(local customization) 사이에서 적절한 균형을 유지해야 한다고 강조합니다 [6]. 즉 무조건적인 중복 제거가 능사는 아닙니다.
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [소프트웨어 엔지니어링 원칙]
+- [[KISS]]
+  - 연결 이유: DRY 원칙을 강박적으로 적용하여 추상화를 진행하다 보면 코드가 지나치게 복잡해져 이 KISS(Keep It Simple, Stupid) 원칙에 위배될 수 있습니다 [3].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 효율적인 코드 작성에 있어 중복 제거(DRY)와 코드의 단순성(KISS) 사이의 트레이드오프와 균형점을 이해할 수 있습니다.
+- [[YAGNI]]
+  - 연결 이유: DRY 원칙과 함께 언급되며(You Aren't Gonna Need It), 코드 리팩토링 시 불필요한 코드를 줄이는 기준이 됩니다 [7, 8].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 당장 필요하지 않은 미래를 대비해 미리 추상화하지 말라는 개념을 통해 '3번 반복 시 추상화'라는 DRY 적용 시점을 명확히 이해할 수 있습니다 [3].
+
+#### [React 구현/활용 도구]
+- [[Custom Hooks]]
+  - 연결 이유: React 애플리케이션에서 코드 중복을 피하고 공통 로직을 추출할 때 가장 널리 권장되는 수단입니다 [3, 4].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 상태 관리나 라이프사이클과 같은 React 고유의 로직을 어떻게 재사용 가능한 형태로 분리(DRY)할 수 있는지 배울 수 있습니다.
+- [[Higher-Order Components]]
+  - 연결 이유: 커스텀 훅과 함께 React 내에서 반복되는 컴포넌트 로직을 재사용하고 DRY 원칙을 준수하기 위한 구현 도구입니다 [4].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: UI 렌더링 측면에서 컴포넌트의 중복 코드를 어떻게 추상화하는지 이해할 수 있습니다.
+
+### Deeper Research Questions
+
+- React 애플리케이션에서 DRY 원칙을 지키기 위해 로직을 무분별하게 커스텀 훅으로 분리했을 때 발생할 수 있는 렌더링 성능 이슈는 무엇인가?
+- '3번 반복되면 추상화하라'는 가이드라인 외에, 과도한 추상화(Over-abstraction)를 진단할 수 있는 코드 리뷰 상의 지표는 무엇이 있는가?
+- Feature-Sliced Design과 같이 도메인 단위로 기능을 격리하는 구조에서, 전역적인 DRY 원칙 준수와 도메인 간 결합도(Coupling) 최소화 목표는 어떻게 상충하며 어떻게 해결할 수 있는가?
+- 컴포넌트의 UI 구조적 중복과 비즈니스 로직적 중복을 해소하는 구체적인 React 패턴(Render Props, HOC, Custom Hooks)은 각각 어느 상황에 최적화되어 있는가?
+- DRY 원칙에 따라 하나의 유틸리티 함수나 공유 컴포넌트를 변경했을 때, 이를 참조하는 다른 모듈들(Blast Radius)에 미치는 부작용을 사전에 테스트하고 제어하는 방법론은 무엇인가?
+
+### Practical Application Contexts
+
+- **Implementation:** React로 화면을 구현할 때, 서로 다른 페이지에서 동일한 데이터 페칭 방식이나 폼 처리 로직을 사용 중이라면 이를 `useFetch`나 `useForm`과 같은 커스텀 훅으로 빼내어 코드 중복을 제거합니다 [3, 4].
+- **System Design:** 프로젝트의 폴더 구조를 잡을 때 공통 로직을 재사용할 수 있도록 `shared` 또는 `utils` 같은 전역적인 레이어를 두어 중복 코드를 최소화하고 재사용성을 촉진합니다 [6, 9].
+- **Operation / Maintenance:** 중복 로직을 별도의 함수나 컴포넌트로 관리하면 특정 API 스펙이나 UI 정책이 변경될 때 수십 개의 파일을 수정할 필요 없이 단 한 곳만 수정하여 애플리케이션 전체에 반영할 수 있습니다 [2].
+- **Learning Path:** 처음부터 완벽하게 중복이 없는 코드를 작성하려 하기보다는 일단 코드를 작성한 뒤, 같은 패턴이 3번 이상 반복되는 것을 목격했을 때 리팩토링을 통해 추상화하는 훈련을 합니다 [3].
+- **My Project Relevance:** React 코드베이스를 리팩토링(refactoring)하는 과제 수행 시, DRY 및 YAGNI 원칙을 척도로 삼아 Lint를 설정하고, 흩어진 유사 함수들을 작고 명확한 재사용 모듈로 통합하는 것을 목표로 할 수 있습니다 [7].
+
+### Adjacent Topics
+
+- [[SOLID]]
+  - 확장 방향: 객체 지향 및 함수형 프로그래밍에서 코드 품질을 높이는 5대 원칙으로, DRY와 함께 React 컴포넌트 구조화(단일 책임 원칙 등)를 학습하는 데 도움이 됩니다 [10, 11].
+- [[Clean Code]]
+  - 확장 방향: 중복 제거(DRY)뿐만 아니라 명확한 네이밍, 함수 크기 축소 등 코드의 가독성과 유지보수성을 총체적으로 향상시키는 원칙을 더 넓게 포괄합니다 [1, 4].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Debugging.md b/00_Raw/Debugging.md
new file mode 100644
index 00000000..b28d7147
--- /dev/null
+++ b/00_Raw/Debugging.md
@@ -0,0 +1,70 @@
+# [[Debugging]]
+
+## 📌 Brief Summary
+디버깅(Debugging)은 소프트웨어 시스템, 특히 복잡한 프론트엔드 환경에서 발생하는 런타임 에러, 메모리 누수, 불필요한 리렌더링 등의 문제를 식별하고 해결하는 필수적인 과정입니다 [1], [2], [3], [4]. 현대의 디버깅은 단순한 `console.log` 확인을 넘어, 클라우드 기반 로깅 도구와 메모리 프로파일러, 브라우저 개발자 도구를 활용하는 고도화된 시스템 모니터링 및 분석 작업으로 진화했습니다 [5], [6], [7]. 효과적인 디버깅 체계의 구축은 애플리케이션의 성능 저하와 중단을 방지하고 쾌적한 사용자 경험을 유지하는 핵심 기술입니다 [1], [2], [8].
+
+## 📖 Core Content
+* **프론트엔드 에러 모니터링 및 클라우드 도구 활용:**
+  현대의 프론트엔드 디버깅은 Sentry, LogRocket, Datadog RUM과 같은 클라우드 기반 로깅 및 관측(Observability) 도구를 통해 이루어집니다 [5]. Sentry는 에러 그룹화 및 콘솔 로그, 네트워크 요청, 사용자 상호작용을 포괄하는 브레드크럼(Breadcrumbs)을 제공합니다 [9]. LogRocket은 세션 리플레이 기능을 통해 Redux/Vuex 상태 변화와 네트워크 요청 헤더 등 사용자의 전체 세션을 녹화하듯 추적하여 복잡한 버그의 원인을 진단하게 돕습니다 [10]. Datadog RUM은 프론트엔드 에러를 백엔드 트레이스와 연계하여 종단간(End-to-end) 디버깅을 지원합니다 [11], [12].
+* **메모리 누수(Memory Leaks) 및 블로트(Bloat) 디버깅:**
+  자바스크립트 환경에서 할당된 메모리가 해제되지 않으면 메모리 누수나 블로트 현상이 발생합니다 [1], [13]. 디버깅 시 Chrome 작업 관리자(Task Manager)를 통해 DOM 노드 생성 수치와 JS 힙(Heap) 메모리 사용량의 실시간 증가 추이를 모니터링할 수 있습니다 [14], [15]. 더 깊은 분석을 위해 Chrome DevTools의 Memory 탭에서 'Heap Snapshot'을 촬영한 뒤 두 시점의 스냅샷을 비교(Comparison 뷰)하여 델타(Delta) 값이 양수인 객체를 찾아냅니다 [6], [16]. 이를 통해 분리된 DOM 트리(Detached DOM nodes), 축적된 이벤트 리스너, 클로저로 유지된 참조(Closure-retained references) 등 가비지 컬렉션(GC)을 방해하는 누수 패턴을 식별합니다 [17], [18], [19].
+* **React 렌더링 성능 및 상태 관리 디버깅:**
+  불필요한 리렌더링 이슈를 디버깅하기 위해 React DevTools의 Profiler나 `why-did-you-render` 라이브러리를 사용합니다 [4], [20]. 이를 통해 어떤 컴포넌트가 언제, 얼마의 렌더링 시간을 소모했고, 어떤 프롭스나 상태 변화가 원인인지 시각적으로 분석할 수 있습니다 [4], [21]. 복잡한 상태 관리 시스템을 디버깅할 때는, Redux DevTools를 통해 상태 기록 검사, 액션 리플레이 등 시간 여행(Time-travel) 디버깅 기능을 사용하여 버그를 신속히 추적합니다 [22], [23].
+* **Error Boundaries를 활용한 장애 억제 및 대체 UI:**
+  React 16부터 도입된 Error Boundaries는 하위 컴포넌트 트리의 렌더링 과정에서 발생하는 JavaScript 에러를 포착하여 전체 앱이 빈 화면("white screen of death")으로 크래시되는 것을 방지합니다 [24], [3]. 이 클래스 컴포넌트는 에러 발생 시 내부 상태를 업데이트하여 사용자에게 친숙한 대체 UI(Fallback UI)를 렌더링하고 모니터링 도구에 에러 정보를 로깅하는 디버깅 안전망 역할을 수행합니다 [24], [8].
+
+## ⚖️ Trade-offs & Caveats
+* **클라우드 로깅 툴 도입의 제약 및 비용:** LogRocket과 같이 사용자 세션을 모두 캡처하는 도구는 민감한 데이터가 노출될 수 있어 프라이버시 설정 작업에 긴 시간이 소요되며, 번들 사이즈 및 로딩 성능에 악영향(오버헤드)을 줄 수 있습니다 [10], [25], [26]. Datadog RUM 등의 도구는 대규모 트래픽 발생 시 데이터 수집(Ingest)과 인덱싱 비용 측면에서 요금 구조가 복잡하고 비용이 급증할 위험이 있습니다 [27], [28].
+* **React Compiler 활용 시 디버깅 가시성 저하:** React Compiler를 적용하면 자동으로 메모이제이션 최적화가 이루어지지만, 컴파일러가 블랙박스처럼 작동하게 됩니다 [29], [7]. `React.memo`나 `useMemo` 등 명시적인 코드가 사라지므로, 개발자가 예상치 못한 리렌더링이 발생했을 때 직관적인 코드 분석이 어려워지고 전적으로 Profiler에 의존해 디버깅을 수행해야 하는 단점이 있습니다 [7].
+* **Error Boundaries의 포착 범위 한계:** Error Boundaries는 렌더링, 생명주기 메서드, 생성자 내부의 에러는 포착하지만, 이벤트 핸들러, 비동기 코드(예: `setTimeout`, `Promises`), 서버 사이드 렌더링(SSR), 혹은 Error Boundary 자체에서 발생하는 에러는 포착하지 못합니다 [30], [31]. 이러한 에러를 디버깅하고 처리하기 위해서는 개별적으로 `try/catch` 구문을 삽입해야만 합니다 [32], [33].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [프론트엔드 모니터링 및 진단 환경]
+- [[Cloud Logging Tools]]
+  - 연결 이유: 콘솔 로그만으로 파악할 수 없는 프로덕션 환경의 실사용자 에러와 성능 저하를 디버깅하기 위해 사용하는 클라우드 솔루션.
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: Sentry, LogRocket 등을 활용하여 사용자의 환경적 변수, 세션 리플레이, 상태 추적, 에러 그룹화 기법을 통한 디버깅 워크플로우 설계 방법 [9], [34], [35].
+
+#### [메모리 및 성능 분석 도구]
+- [[Heap Snapshots]]
+  - 연결 이유: 자바스크립트의 메모리 사용 구조를 스냅샷 형태로 분석하여 메모리 누수 객체를 디버깅하는 핵심 도구.
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 브라우저 개발자 도구의 '비교(Comparison)' 및 'Detached DOM' 탐색 기능을 이용해, 제거된 요소를 참조하고 있는 클로저 등 구체적 누수 원인을 찾아내는 시각적 추적 원리 [17], [6], [16].
+- [[React Profiler]]
+  - 연결 이유: 애플리케이션의 렌더링 지연 시간과 불필요한 렌더링 횟수를 진단하고 디버깅하는 내장 분석 도구.
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 컴포넌트 렌더링 시간, 렌더 트리 시각화, 그리고 React Compiler 도입 후 자동 메모이제이션 성공 여부 진단 방법 [36], [4], [37].
+
+#### [디버깅 설계 패턴 및 상태 관리 기술]
+- [[Time-Travel Debugging]]
+  - 연결 이유: 상태 변경 로그를 통해 앱의 과거 상태를 재현(Replay)하며 논리적 오류를 디버깅하는 개발자 편의 기능.
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: Redux DevTools 생태계에서 지원하는 엄격한 상태 변화 추적 메커니즘과, 이를 지원하지 않는 단순 Context API 환경의 한계 [22], [23].
+- [[Error Boundaries]]
+  - 연결 이유: 선언적인 React 환경에서 UI의 렌더링 런타임 에러를 격리하고 포착하기 위한 디버깅 방어막.
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 앱 전체 붕괴를 방지하는 기능적 특성과, 런타임 에러 상황을 Sentry 등 모니터링 툴에 자동으로 로깅하도록 연결하는 구조 설계 [24], [38], [8].
+
+### Deeper Research Questions
+
+- 프론트엔드 모니터링 솔루션(LogRocket, Sentry 등)을 프로젝트에 연동할 때, 로깅 오버헤드가 초기 로딩 및 Core Web Vitals 지표(LCP, INP 등)에 미치는 구체적인 악영향과 최적화 전략은 무엇인가?
+- Chrome DevTools의 Heap Snapshot과 Allocation Timeline을 결합하여 복잡한 단일 페이지 애플리케이션(SPA)의 미세한 메모리 누수를 효과적으로 추적하는 워크플로우는 어떻게 구성할 수 있는가?
+- React Error Boundaries가 비동기 코드나 이벤트 핸들러의 에러를 잡지 못하는 브라우저 이벤트 루프 기반의 구조적 원인은 무엇이며, 이를 극복하는 최적의 통합 에러 처리 아키텍처는 어떻게 구현되는가?
+- React Compiler 도입 이후 컴파일 타임 최적화 환경에서, 기존 수동 메모이제이션(`useMemo`, `React.memo`) 환경과 비교해 디버깅 방식과 성능 추적 패러다임은 어떻게 변화하는가?
+- Redux의 Time-Travel Debugging을 Zustand와 같은 경량 상태 관리 라이브러리 환경에서도 유사한 수준으로 구현하고 활용할 수 있는 DevTools 통합 방안은 무엇인가?
+
+### Practical Application Contexts
+
+- **Implementation:** React 컴포넌트 최적화를 위해 개발 단계에서 `React DevTools Profiler` 및 `why-did-you-render` 플러그인을 활용해 불필요한 리렌더링을 유발하는 프롭스(Props)와 상태를 찾아 리팩토링합니다 [20], [21].
+- **System Design:** 애플리케이션 디자인 시 대시보드나 외부 위젯 등 불안정한 컴포넌트 단위마다 세분화된 `Error Boundaries`를 래핑하여 특정 구간에서 에러가 발생해도 전체 UI가 살아있도록 견고하게 시스템을 설계합니다 [39], [40].
+- **Operation / Maintenance:** 운영 중인 서비스에 Sentry를 연동하여 에러 브레드크럼을 수집하고, LogRocket의 세션 리플레이로 크래시 직전 사용자의 정확한 클릭/입력 동작과 상태를 파악하여 버그를 신속하게 디버깅합니다 [9], [34], [10], [35].
+- **Learning Path:** Chrome DevTools를 통한 메모리 및 작업 관리자(Task Manager) 확인법을 숙지하고 [14], React의 리렌더링 메커니즘과 Profiler 사용법을 배운 뒤 [41], [4], 점진적으로 Redux/Zustand 등 상태 관리 라이브러리의 DevTools를 활용한 타임 트래블 디버깅으로 학습을 확장합니다 [23].
+- **My Project Relevance:** 현재 진행 중인 프론트엔드 프로젝트에서 발생하는 메모리 누수 탐지(Detached DOM Nodes 추적)와 성능 병목 현상을 해결하는 데 Chrome DevTools 및 Profiler 기술을 즉각 적용해 볼 수 있으며, 에러 바운더리를 통한 프로덕션 레벨 안정성을 확보할 수 있습니다.
+
+### Adjacent Topics
+
+- [[Performance Optimization]]
+  - 확장 방향: 디버깅 과정에서 발견된 병목 현상(메모리 누수, 과도한 렌더링, 무거운 번들 청크)을 해결하기 위한 구체적인 코드 스플리팅, 지연 로딩(Lazy Loading), 에셋 최적화 등의 아키텍처 개선 기법 탐구.
+- [[State Management Architecture]]
+  - 확장 방향: 디버깅의 복잡성을 낮추고 상태 변화의 추적성을 높이기 위해, Redux, Zustand, React Context API 등 여러 상태 관리 라이브러리의 동작 원리와 도입 트레이드오프(Trade-offs) 비교.
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Detached DOM Nodes.md b/00_Raw/Detached DOM Nodes.md
new file mode 100644
index 00000000..72778d9f
--- /dev/null
+++ b/00_Raw/Detached DOM Nodes.md	
@@ -0,0 +1,63 @@
+# [[Detached DOM Nodes]]
+
+## 📌 Brief Summary
+Detached DOM Nodes(분리된 DOM 노드)란 페이지의 DOM 트리에서는 제거되었으나, 자바스크립트 코드 내에서 여전히 참조를 유지하고 있어 가비지 수집(Garbage Collected) 대상이 되지 못하는 DOM 요소를 의미합니다 [1, 2]. 이러한 노드는 불필요하게 메모리를 계속 점유하게 되어 자바스크립트 애플리케이션에서 성능 저하와 메모리 누수(Memory Leak)를 일으키는 주요 원인이 됩니다 [1]. 개발자는 Chrome DevTools의 힙 스냅샷(Heap Snapshots)과 같은 프로파일링 도구를 사용하여 이 노드들을 식별하고 디버깅할 수 있습니다 [3, 4].
+
+## 📖 Core Content
+*   **발생 원리 및 정의:** DOM 노드는 페이지의 DOM 트리와 자바스크립트 코드 양쪽 모두에서 참조가 없을 때만 가비지 수집기로부터 회수될 수 있습니다 [1]. 만약 문서(Document)에서는 노드가 삭제되었지만 자바스크립트 변수나 객체가 해당 노드를 계속 참조하고 있다면, 그 노드는 '분리된(Detached)' 상태가 되어 메모리에 잔류합니다 [1].
+*   **컴포넌트 환경에서의 주요 원인:** React와 같은 모던 컴포넌트 기반 UI 개발에서 매우 빈번하게 발생하는 문제입니다 [2]. 주로 컴포넌트가 언마운트될 때 `useEffect`의 반환 함수(cleanup 함수)에서 이벤트 리스너를 제거하지 않거나 상태 구독을 해제하지 않아, 더 이상 화면에 보이지 않는 DOM 요소가 메모리에 묶여 있게 되는 경우에 발생합니다 [2, 3]. 또한, 클로저(Closure)가 부모 스코프의 변수를 살려두어 불필요하게 큰 객체(DOM 포함)의 참조를 유지하는 패턴도 원인이 됩니다 [5].
+*   **진단 및 분석 기법:**
+    *   **힙 스냅샷(Heap Snapshots):** Chrome DevTools의 Memory 패널을 사용해 특정 시점의 메모리 상태를 스냅샷으로 찍을 수 있습니다 [4]. 사용자 액션 전후로 스냅샷을 캡처한 뒤 이를 비교(Comparison view)하고, 클래스 필터에 'Detached'를 검색하여 메모리에 고립된 DOM 트리를 찾아냅니다 [2-4, 6].
+    *   **객체 식별 및 참조 경로:** 스냅샷의 Objects 창에서 해당 분리된 노드를 클릭하면, `detachedTree`와 같이 이 노드를 붙잡고 있는 실제 자바스크립트 변수를 확인할 수 있습니다 [7]. GC 루트(GC root)로부터의 거리(Distance)를 살펴보면 해당 객체를 메모리에서 해제하기 위해 어떤 참조 체인을 끊어야 하는지 파악할 수 있습니다 [5].
+    *   **Detached Elements 프로필:** 'Detached elements' 프로파일을 기록하여 자바스크립트 코드가 참조하고 있는 분리된 정확한 HTML 노드와 그 개수를 확인할 수도 있습니다 [8].
+
+## ⚖️ Trade-offs & Caveats
+자바스크립트 변수에 DOM 노드를 의도적으로 보관하는 것은 빠른 DOM 조작이나 재사용을 위한 캐싱(Caching) 전략 등 성능 최적화의 기술적 선택일 수 있습니다. 하지만 이 방식은 적절한 시점에 참조를 해제하지 않을 경우 치명적인 메모리 누수(Memory Leak)를 유발한다는 뚜렷한 제약 사항이자 부작용(Caveat)을 갖습니다 [1, 7, 9]. 
+
+특히 힙 스냅샷(Heap Snapshot)이나 할당 타임라인(Allocation Timeline)을 통해 분리된 DOM 노드를 추적하는 과정은 디버깅 관점에서 매우 강력하지만, 스냅샷 생성과 분석에 시간이 소요되며 실시간으로 메모리 할당을 모니터링하는 경우 브라우저 성능에 부하를 줄 수 있다는 한계가 있습니다 [4, 10]. (이외에 분리된 DOM 노드를 활용하는 기술적 선택에 따른 반대 급부에 관해서는 소스에 관련 정보가 다소 부족합니다.)
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [문제 원인 및 현상 (Problem & Symptoms)]
+*   [[Memory Leaks]]
+    *   연결 이유: 분리된 DOM 노드는 자바스크립트 환경에서 발생하는 메모리 누수의 가장 흔한 형태 중 하나입니다 [1].
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 가비지 컬렉터가 수집하지 못한 메모리가 누적되면서 애플리케이션 속도가 느려지고 결국 탭이나 앱이 멈추거나 충돌(crash)하는 현상 및 그 진단 방법 [9, 11].
+*   [[Garbage Collection]]
+    *   연결 이유: 분리된 DOM 노드가 계속 메모리를 차지하는 근본적인 이유가 가비지 컬렉션의 동작 방식과 연관되어 있습니다 [1, 9].
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 자바스크립트 엔진이 더 이상 참조(Reference)가 없는 메모리만 회수한다는 원칙과, 참조가 어떻게 유지되는지에 대한 메모리 관리 메커니즘 [9].
+
+#### [분석 및 디버깅 도구 (Analysis & Debugging Tools)]
+*   [[Heap Snapshots]]
+    *   연결 이유: 애플리케이션 내 분리된 DOM 트리를 찾아내기 위해 사용되는 핵심 도구입니다 [4].
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 특정 순간의 메모리 상태를 찍어 사용자 동작 전후의 변화량(Delta)을 비교하고, 어떠한 자바스크립트 변수(Retainers)가 객체의 수명을 연장하고 있는지 파악하는 실무적인 프로파일링 기법 [3, 5, 6].
+*   [[Chrome DevTools Memory Panel]]
+    *   연결 이유: 힙 스냅샷 분석, Allocation Timeline 기록 및 Detached elements 프로필을 실행할 수 있는 브라우저 내장 디버깅 환경입니다 [4, 8, 10].
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 프론트엔드 환경에서 자바스크립트 힙 메모리를 다양한 방법(실시간 할당 추적, 함수별 메모리 할당, GC 발생 빈도)으로 모니터링하고 분석하는 전반적인 프로세스 [8, 10, 12].
+
+### Deeper Research Questions
+
+*   모던 컴포넌트 프레임워크(예: React)에서 DOM 이벤트 리스너 누적과 클로저 참조 외에 분리된 DOM 노드를 가장 자주 유발하는 안티 패턴은 무엇인가? [2, 3, 5]
+*   의도적인 DOM 노드 캐싱(Caching)을 통한 렌더링 성능 최적화와 메모리 누수(분리된 DOM 노드) 사이의 경계를 시스템 설계 관점에서 어떻게 조율할 수 있는가? [1, 9]
+*   힙 스냅샷(Heap Snapshots)의 'Retainers' 패널에서 보여주는 GC 루트(GC Root)로부터의 거리(Distance) 정보는 참조 연결을 해제할 때 어떤 구체적인 지침을 제공하는가? [5]
+*   자동화된 CI(Continuous Integration) 파이프라인에서 Puppeteer 등을 활용하여 애플리케이션의 분리된 DOM 노드 발생(메모리 누수) 여부를 선제적으로 테스트하고 방지하는 구체적인 파이프라인 구성 방법은 무엇인가? [13]
+*   메모리 캐시 관리를 위해 일반 객체(Object) 대신 `WeakMap`을 사용하는 것이 분리된 DOM 노드와 같은 누수 문제를 예방하는 데 어떻게 기여하는가? [13]
+
+### Practical Application Contexts
+
+*   **Implementation:** React 애플리케이션 개발 중, `useEffect` 내부에서 추가한 타이머, 구독(subscription), 이벤트 리스너 등은 컴포넌트 언마운트 시 반환하는 cleanup 함수에서 반드시 제거하여 DOM 노드가 메모리에 고립되는 것을 방지합니다 [3, 13].
+*   **System Design:** 캐시 기능을 구현할 때 DOM 요소나 큰 객체를 메모리에 보관해야 한다면, 참조가 없을 때 자동으로 가비지 컬렉션이 되도록 `WeakMap`을 활용하는 설계 패턴을 도입합니다 [13].
+*   **Operation / Maintenance:** 장시간 실행되는 탭에서 속도 저하 버그 리포트가 발생할 경우, 유지보수 개발자는 Chrome DevTools를 열고 강제 가비지 컬렉션(휴지통 아이콘 클릭)을 수행한 뒤, 의심되는 액션 전후의 힙 스냅샷을 찍고 비교하여 잔류한 "Detached" 노드들을 색출하는 디버깅 워크플로우를 진행합니다 [4, 6].
+*   **Learning Path:** 프론트엔드 성능 최적화 학습 단계에서 자바스크립트 가비지 컬렉션과 메모리 누수의 기본 원리를 학습한 다음, Chrome DevTools 사용법을 익혀 실제 작성한 애플리케이션에 존재하는 분리된 DOM 노드를 시각적으로 식별하고 제거해 보는 과정으로 학습을 전개합니다 [1, 6, 9].
+*   **My Project Relevance:** 현재 진행 중인 프론트엔드 웹 애플리케이션 최적화 작업 중, 라우팅 변경이나 모달 창을 열고 닫을 때 메모리 사용량이 계속 증가한다면 메모리 프로파일링 도구를 사용하여 분리된 DOM 트리가 발생하고 있는지 즉시 진단하고 해결할 수 있습니다.
+
+### Adjacent Topics
+
+*   [[Performance Profiling]]
+    *   확장 방향: 분리된 DOM 노드 탐지 같은 메모리 이슈 외에도 크롬 DevTools의 Performance 탭을 이용해 자바스크립트 실행 시간, 긴 작업(Long tasks), 렌더링(paint) 지연 등 전반적인 프론트엔드 실행 성능 병목을 찾아내는 기법으로 확장합니다 [14, 15].
+*   [[React Component Lifecycle Cleanup]]
+    *   확장 방향: React 애플리케이션 특성상, 이벤트 리스너나 외부 상태 구독을 해제하지 않는 등 컴포넌트 생명주기 관리 실패가 분리된 DOM 노드로 이어집니다. 올바른 컴포넌트 해제 패턴 및 Hooks(`useEffect`) 활용법을 깊이 있게 파악합니다 [3, 13].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Error Handling.md b/00_Raw/Error Handling.md
new file mode 100644
index 00000000..416792da
--- /dev/null
+++ b/00_Raw/Error Handling.md	
@@ -0,0 +1,64 @@
+# [[Error Handling]]
+
+## 📌 Brief Summary
+React 애플리케이션에서의 Error Handling은 자바스크립트 에러로 인해 전체 앱이 중단되거나 백지 화면이 나타나는 것을 방지하는 기술입니다 [1, 2]. 핵심 메커니즘인 에러 바운더리(Error Boundaries)를 통해 하위 컴포넌트 트리에서 발생한 렌더링 에러를 포착하고, 대신 대체 UI(Fallback UI)를 보여줍니다 [1]. 이벤트 핸들러나 비동기 작업에서 발생하는 에러는 에러 바운더리가 처리할 수 없으므로 전통적인 `try/catch` 블록과 결합하여 포괄적인 에러 관리를 수행합니다 [3-5].
+
+## 📖 Core Content
+*   **에러 바운더리(Error Boundaries)의 동작 원리:** 
+    에러 바운더리는 하위 컴포넌트의 렌더링, 생명주기 메서드, 생성자에서 발생하는 에러를 잡는 특별한 React 클래스 컴포넌트입니다 [1, 5]. `static getDerivedStateFromError()` 메서드를 사용하여 에러 발생 시 상태를 업데이트하여 Fallback UI를 렌더링하고, `componentDidCatch()` 메서드를 사용하여 에러 정보를 로깅합니다 [6]. 이를 통해 특정 UI 부분에 버그가 있더라도 나머지 애플리케이션은 안정적으로 유지됩니다 [7].
+*   **에러 포착의 한계 (예외 사항):** 
+    에러 바운더리는 트리에서 자신의 아래에 있는 컴포넌트의 에러만 포착할 수 있으며, 자기 자신에서 발생한 에러는 포착하지 못합니다 [8]. 또한, 이벤트 핸들러, 비동기 코드(예: `setTimeout` 또는 Promise), 서버 사이드 렌더링(SSR) 중 발생하는 에러는 포착할 수 없습니다 [5, 6].
+*   **이벤트 핸들러와 비동기 코드의 에러 처리:** 
+    이벤트 핸들러는 렌더링 중에 실행되지 않으므로, 여기서 에러가 발생해도 React는 여전히 화면에 무엇을 표시해야 할지 알고 있습니다 [4]. 따라서 이러한 경우에는 자바스크립트의 표준 명령형 코드 에러 처리 방식인 `try/catch` 문을 직접 사용해야 합니다 [3-5].
+*   **포착되지 않은 에러(Uncaught Errors)의 결과:** 
+    React 16부터는 에러 바운더리에 의해 포착되지 않은 에러가 발생할 경우, 손상된 UI를 그대로 두는 것이 보안이나 오작동(예: 잘못된 송금 금액 표시, 엉뚱한 사람에게 메시지 전송 등) 측면에서 더 위험하다고 판단하여 전체 React 컴포넌트 트리를 마운트 해제(Unmount)합니다 [9, 10].
+*   **프로덕션 모니터링 및 디버깅:** 
+    에러 바운더리는 단순히 UI를 복구하는 것을 넘어, Sentry, LogRocket, SigNoz 등과 같은 프론트엔드 에러 로깅 서비스와 결합하여 프로덕션 환경의 에러를 기록하는 데 사용됩니다 [11]. 이 도구들은 지능형 에러 그룹화, 세션 리플레이, 전체 스택 트레이스를 제공하여 원인 파악을 돕습니다 [12-14].
+
+## ⚖️ Trade-offs & Caveats
+*   **클래스 컴포넌트 강제:** 에러 바운더리는 오직 클래스 컴포넌트로만 만들 수 있습니다 [5, 8]. 현대의 React 코드베이스가 대부분 함수형 컴포넌트와 Hooks로 작성된다는 점을 고려하면 이질적인 구조가 될 수 있으며, 함수형으로 사용하려면 `react-error-boundary`와 같은 별도의 래퍼(Wrapper) 라이브러리에 의존해야 하는 제약이 있습니다 [5].
+*   **전역 vs 지역 에러 바운더리의 딜레마:** 앱 전체를 하나의 에러 바운더리로 감싸면 설정은 쉽지만, 작은 컴포넌트 하나의 오류로 인해 전체 UI가 Fallback으로 대체되어 사용자 경험이 저하될 수 있습니다 [11, 15]. 반대로 서드파티 위젯, 복잡한 폼 등 불안정한 요소를 개별적으로 감싸면(Granularity) 특정 영역만 에러 처리되어 나머지 앱을 사용할 수 있지만, 이를 설계하고 배치하는 작업의 복잡도와 관리 비용이 증가합니다 [9, 11, 15].
+*   **완벽한 보호의 불가능:** 앞서 언급된 것처럼 에러 바운더리는 비동기 로직이나 이벤트 핸들러의 에러를 잡지 못하므로, 애플리케이션의 성격상 데이터 페칭 등 비동기 로직이 많을 경우 에러 바운더리만으로는 시스템의 중단을 완전히 막을 수 없으며, 모든 상호작용 지점에 방어적인 로직(`try/catch`)을 추가해야 하는 수고가 따릅니다 [3, 4].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [아키텍처/기반 기술]
+- [[Error Boundaries]]
+  - 연결 이유: React 애플리케이션에서 선언형 UI 렌더링 중 발생하는 자바스크립트 에러를 처리하는 중심 메커니즘이기 때문입니다 [1].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 앱의 크래시를 방지하고 손상된 컴포넌트 대신 정상적인 대체 화면을 렌더링하는 React만의 에러 복구 전략을 파악할 수 있습니다 [1, 2, 10].
+
+- [[Component Lifecycle]]
+  - 연결 이유: 에러 바운더리를 구현하기 위해서는 React 클래스 컴포넌트의 특정 생명주기 메서드(`getDerivedStateFromError`, `componentDidCatch`)가 필수적으로 요구되기 때문입니다 [6].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 렌더링 단계에서 어떻게 에러를 잡고 컴포넌트 상태를 업데이트하는지 내부 동작을 심층적으로 이해할 수 있습니다 [3, 6].
+
+#### [구현/활용 도구]
+- [[Cloud Logging Tools]]
+  - 연결 이유: 사용자 브라우저(프로덕션)에서 발생한 에러를 개발자가 인지하고 분석하기 위해서는 Sentry, LogRocket, Datadog 같은 외부 모니터링 툴 통합이 필수적이기 때문입니다 [11, 12, 14].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 발생한 에러의 스택 트레이스 추적, 사용자 세션 리플레이를 통한 상황 복원 등 심화된 에러 추적 기법을 배울 수 있습니다 [12-14].
+
+- [[try/catch]]
+  - 연결 이유: 에러 바운더리로 처리할 수 없는 이벤트 핸들러, 비동기 통신 코드 내의 에러를 처리하는 표준 자바스크립트 방식이기 때문입니다 [3-5].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 선언형 에러 처리(Error Boundary)와 명령형 에러 처리(try/catch)의 역할 분담과 차이를 명확히 구분할 수 있습니다 [3, 4].
+
+### Deeper Research Questions
+- 이벤트 핸들러나 비동기 함수(예: setTimeout, Promise) 내부의 에러가 React의 렌더링 사이클에서 벗어나 에러 바운더리에 포착되지 않는 근본적인 아키텍처적 이유는 무엇인가?
+- 함수형 컴포넌트 시대에서 클래스 컴포넌트 기반의 에러 바운더리가 갖는 한계점은 무엇이며, 커뮤니티(예: `react-error-boundary` 등)는 이를 어떻게 극복하고 있는가?
+- 대규모 애플리케이션에서 페이지 레벨, 위젯 레벨 등 여러 겹으로 에러 바운더리를 중첩 배치(Nesting)할 때 에러가 상위로 전파(Propagate)되는 규칙과 효과적인 배치 전략은 무엇인가?
+- SSR(Server-Side Rendering) 환경을 지원하는 프레임워크(예: Next.js)에서는 클라이언트 중심의 React 에러 바운더리 외에 서버 측 에러를 어떻게 통합 관리하는가?
+- Sentry와 같은 외부 로깅 도구는 최소화(Minified)된 프로덕션 빌드 파일에서 에러가 났을 때, 어떻게 원래 컴포넌트와 발생 위치를 정확히 매핑하여 알려주는가?
+
+### Practical Application Contexts
+- **Implementation:** React 컴포넌트 작성 시 하얀 화면이 뜨는 것을 막기 위해 최상단이나 불안정한 서드파티 위젯 주위에 `ErrorBoundary` 클래스 컴포넌트를 작성하고 `fallback UI` 프로퍼티를 설정합니다 [2, 9, 15]. 비동기 호출 시에는 반드시 `try/catch`로 감싸 별도의 에러 처리를 구현합니다 [3, 5].
+- **System Design:** 페이스북 메신저의 예시처럼, 사이드바, 정보 패널, 메시지 입력창 등 독립적인 기능을 각각 에러 바운더리로 감싸 한 기능이 고장 나도 시스템의 다른 기능은 계속 상호작용 가능하도록 설계합니다 [15, 16].
+- **Operation / Maintenance:** 프로덕션에 배포된 애플리케이션에 Sentry 같은 관측성(Observability) 도구를 연결해 에러 바운더리의 `componentDidCatch`에서 에러를 전송하도록 구성하여 사용자 불만 접수 이전에 버그를 식별하고 디버깅합니다 [11, 14].
+- **Learning Path:** 자바스크립트의 기본적인 `try/catch` 명령형 에러 처리 방식을 먼저 숙지하고, 이후 React의 컴포넌트 생명주기와 에러 바운더리를 결합한 선언적 에러 처리 기법을 학습하며, 마지막으로 클라우드 로깅 툴 통합을 배웁니다.
+- **My Project Relevance:** 현재 진행 중인 프로젝트의 복잡성에 맞게 치명적인 오류로부터 앱 전체 크래시를 방지할 에러 바운더리의 배치 위치를 결정하고, 미처 파악하지 못한 프로덕션 에러의 모니터링 체계를 도입하는 데 직접적으로 적용할 수 있습니다.
+
+### Adjacent Topics
+- [[State Management]]
+  - 확장 방향: Redux, Zustand 등의 전역 상태 관리 도구 내에서 발생하는 비동기 데이터 페칭 에러나 데이터 정규화(Normalization) 과정의 예외가 UI 에러 바운더리와 어떻게 상호 작용하며 처리되는지 확장하여 연구할 수 있습니다.
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Feature Branch Workflow.md b/00_Raw/Feature Branch Workflow.md
new file mode 100644
index 00000000..7d0a438a
--- /dev/null
+++ b/00_Raw/Feature Branch Workflow.md	
@@ -0,0 +1,73 @@
+# [[Feature Branch Workflow]]
+
+## 📌 Brief Summary
+Feature Branch Workflow는 새로운 기능 추가나 버그 수정과 같은 모든 단일 작업을 메인(`main`) 브랜치에서 파생된 독립적인 단기(short-lived) 브랜치에서 수행하는 버전 관리 전략입니다 [1, 2]. 이 접근 방식은 메인 브랜치의 코드가 항상 배포 가능하고 안정적인 상태를 유지하도록 보장합니다 [1-3]. 코드를 병합하기 전에는 반드시 Pull Request(PR)와 동료의 코드 리뷰, 그리고 자동화된 테스트를 거치도록 요구하여 충돌을 방지하고 코드 품질을 유지하는 데 초점을 맞춥니다 [4, 5].
+
+## 📖 Core Content
+* **브랜치 운영 및 역할:**
+  * `main` 브랜치는 항상 안정적이고 배포 가능한 상태를 유지해야 하며, 개발자가 `main`에 직접 커밋하는 것은 엄격히 금지됩니다 [1-3, 6].
+  * 새로운 작업(기능, 버그 수정 등)을 시작할 때마다 `main`에서 파생된 전용 기능 브랜치(Feature Branch)를 생성하여 작업을 분리합니다 [1, 2].
+  * 각 기능 브랜치는 수명이 짧아야 하며, 하나의 브랜치에서는 오직 하나의 논리적 변경 사항(Atomic Commits)만 구현해야 합니다 [4, 5, 7].
+
+* **병합 프로세스와 품질 관리:**
+  * 기능 개발이 완료되면 `main` 브랜치를 향해 Pull Request(PR)를 생성해야 합니다 [4, 5].
+  * 코드를 병합하기 위해서는 최소 1명의 동료 리뷰(Peer Review) 승인과 CI(Continuous Integration) 테스트 통과가 필수적입니다 [4, 5, 8, 9].
+  * 병합 시에는 전체 커밋 이력을 깔끔하게 유지하기 위해 "스쿼시 머지(Squash and merge)" 전략을 주로 사용하며, 병합 후에는 해당 기능 브랜치를 자동으로 삭제합니다 [5, 6, 8, 9].
+
+* **명명 규칙 및 추적성(Traceability):**
+  * 브랜치 이름은 수행할 작업을 명확하게 식별할 수 있도록 `feature/<short-description>` 또는 `bugfix/<short-description>`과 같이 짧고 목적이 드러나는 형식을 사용해야 합니다 [2, 4, 7].
+  * 이슈 트래커(JIRA, GitHub Issues 등)를 사용할 경우, `feature/PROJ-123-user-auth`처럼 티켓 ID를 브랜치 이름과 커밋 메시지에 포함시켜 코드 변경 사항과 비즈니스 요구사항 간의 양방향 추적이 가능하게 해야 합니다 [10-12].
+
+## ⚖️ Trade-offs & Caveats
+* **부작용 및 제약 사항 (Trade-offs):**
+  * `main` 브랜치에 직접 커밋하는 방식에 비해서는 PR을 생성하고 리뷰를 기다려야 하는 최소한의 프로세스 오버헤드가 발생합니다 [3, 13, 14].
+* **반대 급부 및 안티 패턴 (Caveats & Anti-patterns):**
+  * **수명이 긴 브랜치(Long-lived branches):** 브랜치를 수 주 동안 열어두는 것은 이 워크플로우의 가장 큰 안티 패턴이며, 심각한 머지 충돌을 유발합니다 [13, 15, 16].
+  * **동기화 실패:** 대규모 충돌을 방지하기 위해 개발자는 매일 작업 시작 전과 작업 도중에 수시로 `main` 브랜치의 최신 변경 사항을 자신의 브랜치로 가져와(Pull/Rebase) 점진적으로 충돌을 해결해야 합니다 [5, 14, 15].
+  * **거대한 PR:** 한 번에 너무 많은 변경을 포함하는 거대한 커밋과 PR은 빠른 피드백을 방해하므로, PR 크기를 가급적 작게(예: 200줄 이하) 유지하는 규율이 필요합니다 [8, 17].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [아키텍처/기반 기술]
+- [[Trunk-Based Development]]
+  - 연결 이유: Feature Branch Workflow보다 빠른 코드 통합을 목표로 할 때 도입할 수 있는 대안적 브랜칭 전략입니다 [18, 19].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 숙련된 팀이 기능 플래그(Feature Flags)를 활용하여 메인 브랜치에 직접 작은 변경을 지속적으로 커밋하는 방식과 Feature Branch Workflow의 속도 및 안정성 차이를 이해할 수 있습니다 [19].
+
+- [[Git Flow]]
+  - 연결 이유: 소규모 팀에 적합한 Feature Branch Workflow와 대조되는, 훨씬 무겁고 복잡한 기존의 대규모 브랜칭 전략입니다 [14, 18].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 예정된 릴리스 일정이 있거나 규모가 큰 프로젝트에서 왜 `develop` 및 `release` 브랜치가 추가로 요구되는지, 그리고 작은 팀에게는 왜 이것이 오버헤드가 되는지 알 수 있습니다 [18, 20].
+
+#### [구현/활용 도구]
+- [[Pull Request (PR)]]
+  - 연결 이유: Feature Branch Workflow에서 격리된 코드를 `main`으로 병합하기 전 반드시 거쳐야 하는 핵심 게이트웨이입니다 [4, 5, 7].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 코드 리뷰를 습관화하고, 단독 병합을 방지하며, CI 도구와 결합하여 어떻게 코드 품질을 방어하는지 이해할 수 있습니다 [5, 7, 21].
+
+- [[Conventional Commits]]
+  - 연결 이유: 피처 브랜치에서 수행하는 커밋 메시지의 명확성과 일관성을 보장하기 위한 업계 표준 규칙입니다 [4, 21].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: `feat:`, `fix:`, `chore:` 등의 접두사를 사용하여 커밋의 의도를 명확히 하고, 브랜치의 작업 내역을 빠르고 쉽게 파악하는 방법을 배울 수 있습니다 [21, 22].
+
+### Deeper Research Questions
+- Feature Branch Workflow에서 브랜치 수명이 길어질 때 필연적으로 발생하는 머지 충돌을 최소화하기 위한 구체적인 브랜치 동기화(Sync) 전략은 무엇인가?
+- 팀의 규모가 3-5명에서 10명 이상의 다수 팀으로 커질 때, Feature Branch Workflow는 어떻게 확장되거나 다른 전략(예: Git Flow, GitLab Flow)으로 전환되어야 하는가?
+- Pull Request의 코드 크기가 과도하게 커지는 것을 방지하고, 이를 "원자적 커밋(Atomic Commits)" 단위로 유지하게 만드는 실무적인 가이드라인은 무엇인가?
+- CI/CD 파이프라인에서 Feature Branch Workflow를 지원하기 위해, PR 생성 시 병목을 일으키지 않으면서 필수적으로 수행해야 하는 자동화된 검사(lint, test 등)의 적정선은 어디인가?
+- 개발자가 브랜치명과 커밋 메시지에 티켓 ID(JIRA 등)를 누락하지 않도록 Git Hooks나 플랫폼(GitHub, GitLab) 설정을 통해 어떻게 강제할 수 있는가?
+
+### Practical Application Contexts
+
+- **Implementation:** 소규모 팀(2~5명) 프로젝트 시작 시, 리포지토리 설정에서 `main` 브랜치에 직접 푸시하지 못하도록 보호(Branch Protection)를 걸고, 모든 작업을 `feature/` 또는 `bugfix/`로 명명된 브랜치에서 시작하도록 세팅합니다 [2].
+- **System Design:** 버전 관리 시스템(GitHub)과 이슈 트래커(JIRA, Linear)를 연동하도록 설계하여, 개발자가 `feature/PROJ-123` 형태의 브랜치명으로 코드를 올리면 이슈 트래커에 PR 상태와 커밋 내역이 자동으로 추적되게 만듭니다 [11, 23, 24].
+- **Operation / Maintenance:** 관리의 효율성을 위해, 메인 브랜치로 PR이 성공적으로 병합된 이후에는 해당 피처 브랜치가 자동으로 삭제(Auto-delete merged branches)되도록 저장소 설정을 유지합니다 [6-8].
+- **Learning Path:** 처음 팀 프로젝트를 경험하는 초보 개발자들은 로컬 환경에서의 단독 작업을 넘어, 기능별로 브랜치를 분리하고 PR을 통해 동료의 리뷰를 받는 과정을 통해 올바른 협업의 기초를 다집니다 [18, 25].
+- **My Project Relevance:** 현재 진행 중인 프로젝트에서 기능 병합 시 코드 충돌이 잦거나 배포 브랜치가 자주 고장난다면, 이 워크플로우를 채택하여 코드가 안정성을 확보한 상태에서만 메인 브랜치에 합류하도록 규칙을 정립할 수 있습니다 [1, 2, 14].
+
+### Adjacent Topics
+- [[Continuous Integration (CI)]]
+  - 확장 방향: 피처 브랜치의 PR이 생성될 때마다 해당 코드가 안정적인지 자동으로 테스트하고 빌드하여 병합 가능 여부를 시스템적으로 검증하는 파이프라인 구축 방법으로 이해를 확장합니다.
+- [[GitHub Flow]]
+  - 확장 방향: Feature Branch Workflow와 매우 유사하지만, GitHub 환경과 지속적 배포(Continuous Deployment)에 더 최적화된 단순한 형태의 워크플로우로 개념을 확장하여 비교해 봅니다.
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Feature-Branch Workflow.md b/00_Raw/Feature-Branch Workflow.md
new file mode 100644
index 00000000..5800692c
--- /dev/null
+++ b/00_Raw/Feature-Branch Workflow.md	
@@ -0,0 +1,70 @@
+# [[Feature-Branch Workflow]]
+
+## 📌 Brief Summary
+`Feature-Branch Workflow`는 메인 브랜치(main/master)를 항상 안정적이고 배포 가능한 상태로 유지하며, 새로운 기능 개발 및 버그 수정 등의 모든 작업을 짧은 수명을 가진 독립적인 피처 브랜치(feature branch)에서 수행하는 버전 관리 협업 방식이다 [1-4]. 개발이 완료된 변경 사항은 풀 리퀘스트(Pull Request)를 통해 코드 리뷰와 테스트를 거친 후 메인 브랜치로 병합된다 [5-7]. 이 워크플로우는 소규모 팀에 매우 적합하며, 코드 충돌을 방지하고 품질을 유지하면서도 Git-Flow와 같은 무거운 프로세스의 오버헤드를 피할 수 있게 해준다 [1, 8, 9].
+
+## 📖 Core Content
+- **기본 구조 및 원칙:** 
+  항상 배포 가능한 상태인 `main` 브랜치를 중심으로 작동한다 [2-4]. 개발자는 새로운 작업(기능 추가, 버그 수정 등)을 시작할 때마다 `main`에서 새로운 브랜치를 생성하며, `main` 브랜치에 직접 커밋(Direct push)하는 것은 엄격히 금지된다 [4, 5, 10].
+- **브랜치 명명 규칙 (Naming Conventions):** 
+  브랜치의 목적을 명확히 알 수 있도록 짧고 서술적인 이름을 사용한다. 구조적 관리를 위해 접두사(`feature/`, `bugfix/`, `chore/` 등)를 사용하며 [6, 11, 12], 추적성을 높이기 위해 JIRA나 GitHub의 티켓 ID를 포함하는 것이 권장된다 (예: `feature/PROJ-123-user-auth`, `bugfix/GH-456-login-fix`) [13, 14]. 
+- **커밋 및 통합 (Commits & Merging):** 
+  한 번에 하나의 논리적 변경사항만 커밋하는 원자적 커밋(Atomic Commits)을 지향하며, 커밋을 작고 빈번하게 수행한다 [6, 11, 15]. 기능 구현이 완료되면 풀 리퀘스트(PR)를 열어 최소 1명 이상의 팀원에게 리뷰를 받아야 하며, CI 테스트 통과 후 병합한다 [4-7]. 커밋 히스토리를 깔끔하게 유지하기 위해 '스쿼시 병합(Squash Merge)' 방식을 주로 사용하며, 병합 완료 후 피처 브랜치는 즉시 삭제한다 [5, 7, 16].
+- **충돌 방지 (Conflict Prevention):** 
+  대규모 병합 충돌을 피하기 위해 작업 중인 피처 브랜치에 `main` 브랜치의 최신 변경 사항을 자주 가져와(pull 또는 rebase) 동기화하며, 충돌을 점진적으로 해결한다 [7, 8].
+- **풀 리퀘스트(PR) 에티켓:** 
+  PR은 리뷰가 용이하도록 작게 유지해야 한다 (가능하면 200줄 미만). PR 내용에는 무엇이 변경되었는지, 왜 변경되었는지, 그리고 UI 변경 시 스크린샷 등을 포함하여 리뷰어에게 충분한 맥락을 제공해야 한다 [5, 17].
+
+## ⚖️ Trade-offs & Caveats
+- **브랜치 수명 관리의 중요성:** 피처 브랜치가 오랫동안 병합되지 않고 유지될 경우(Long-lived feature branches), 메인 브랜치와의 코드 차이가 기하급수적으로 커져 심각한 대규모 병합 충돌(Merge conflicts)이 발생할 위험이 있다 [10, 18]. 따라서 피처 브랜치는 단일 논리적 변경에만 집중하여 가급적 짧은 수명(Short-lived)을 유지해야 한다 [2, 19, 20].
+- **병합 전 절차로 인한 병목 현상:** 아무리 작고 간단한 변경이라도 풀 리퀘스트 생성, 동료 리뷰, CI/CD 체크를 거쳐야 한다 [10, 11]. 이는 코드 품질을 보장하지만, 아주 사소한 수정조차도 즉각적인 적용이 지연되는 병목이 될 수 있다 (팀에 따라 사소한 수정은 `main`에 직접 커밋하는 예외를 두기도 한다 [8]).
+- **복잡한 릴리스 관리의 한계:** 여러 기능이 하나로 묶여 특정 스케줄에 따라 배포되어야 하는 대규모 프로젝트의 경우, `main` 브랜치 하나만 운영하는 단순 피처 브랜치 워크플로우는 관리가 어려울 수 있다. 이 경우 Git-Flow 같은 더 무거운 구조가 요구된다 [9].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [버전 관리 / 통합 아키텍처]
+- [[Pull Request (PR)]]
+  - 연결 이유: 피처 브랜치에서의 작업물을 메인 브랜치로 병합하기 전, 코드 리뷰와 자동화된 테스트를 진행하는 핵심 관문이다 [6, 11].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 팀 내 피드백 루프 작동 방식, 코드 품질 유지 매커니즘, 그리고 안전한 코드 통합 절차.
+- [[Squash Merge]]
+  - 연결 이유: 피처 브랜치에서 발생한 여러 개의 자잘한 커밋을 하나의 의미 있는 커밋으로 압축하여 메인 브랜치에 병합하는 전략이다 [5, 7].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 메인 브랜치의 깃 히스토리(Git history)를 깔끔하고 가독성 높게 유지하는 원리.
+- [[Continuous Integration (CI)]]
+  - 연결 이유: PR이 생성되었을 때 메인 브랜치에 병합되기 전 자동화된 테스트(예: 린팅, 빌드 검증)를 수행하여 코드가 안전한지 확인하는 방어 시스템이다 [4, 5].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: `main` 브랜치의 상태를 '항상 배포 가능(Always stable)'하게 유지하는 기술적 보장 방법.
+
+#### [개발 방법론 / 규약]
+- [[Ticket IDs Traceability]]
+  - 연결 이유: 브랜치 이름과 커밋 메시지에 JIRA나 GitHub Issues와 같은 티켓 ID(예: PROJ-123)를 포함시켜 코드 변경 사항을 비즈니스 요구사항과 직접적으로 연결한다 [13, 16].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 코드 변경의 배경 파악, 리뷰어의 맥락 이해 지원, 요구사항 구현 추적성 확보.
+- [[Conventional Commits]]
+  - 연결 이유: `feat:`, `fix:`, `chore:` 등 표준화된 형식을 사용하여 커밋 메시지를 작성하는 규칙으로, 피처 브랜치의 변경 내역을 일관성 있게 소통한다 [6, 17, 21].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 커밋 히스토리의 가독성 향상 및 자동화된 릴리스 노트 생성의 기반.
+
+### Deeper Research Questions
+
+- 대규모 병합 충돌을 피하기 위해, 피처 브랜치 워크플로우 내에서 브랜치의 수명(Lifetime)을 기술적/절차적으로 짧게 강제하려면 어떤 방법들을 적용할 수 있는가?
+- 단순한 피처 브랜치 워크플로우를 사용하다가, 팀 규모가 커지고 스케줄링된 정기 릴리스가 필요해질 때 Git-Flow 등으로의 마이그레이션을 어떻게 점진적으로 수행할 수 있는가?
+- 로컬 피처 브랜치에서 `main` 브랜치의 최신 변경 사항을 동기화할 때, `git merge main`과 `git rebase main`을 사용하는 것의 실질적인 장단점 및 권장 사례는 무엇인가?
+- 원자적 커밋(Atomic Commits) 규칙을 개발 팀 내에서 효과적으로 정착시키기 위해 코드 리뷰 과정이나 CI 도구에서 어떤 검증 기준을 세울 수 있는가?
+- 긴급하게 프로덕션 환경의 버그(Hotfix)를 수정해야 할 경우, 피처 브랜치 워크플로우 내에서 `main`의 안정성을 해치지 않으면서 가장 빠르고 안전하게 배포하는 흐름은 무엇인가?
+
+### Practical Application Contexts
+
+- **Implementation:** GitHub 레포지토리 설정에서 `main` 브랜치에 직접 커밋을 막는 보호 기능(Branch protection)을 활성화하고, 최소 1명의 리뷰와 CI 통과를 필수로 설정하여 프로세스를 강제한다 [5]. 브랜치 이름은 `{type}/{ticket-id}-{description}` 형식을 사용한다 [14].
+- **System Design:** 변경된 UI 코드가 시스템 디자인에 악영향을 주지 않도록, PR 리뷰 단계에서 Storybook 및 Chromatic과 같은 시각적 회귀 테스트(Visual regression testing) 도구를 연동하여 검증을 자동화한다 [22].
+- **Operation / Maintenance:** 문제가 발생했을 때 문제의 원인이 되는 커밋을 롤백(Revert)하거나 추적하기 쉽도록, Squash Merge 옵션만을 허용하여 커밋 단위를 기능별로 정리하고 병합된 브랜치는 자동 삭제(Auto-delete) 옵션을 켜둔다 [5, 7, 11].
+- **Learning Path:** 2~5인 규모의 소규모 학생 팀이나 스타트업 프로젝트에서 버전 관리를 시작할 때 가장 먼저 도입하여 Git 협업의 기초(브랜치 생성, 커밋, PR, 리뷰, 머지)를 학습하는 용도로 적합하다 [3, 9].
+- **My Project Relevance:** 팀원들이 겹치는 파일을 수정하다 코드가 유실되는 것을 막고, PR을 통한 코드 리뷰 문화 정착으로 전체적인 코드 품질과 팀원의 이해도를 상향 평준화하는 기본 협업 모델로 도입할 수 있다.
+
+### Adjacent Topics
+
+- [[Trunk-Based Development]]
+  - 확장 방향: 피처 브랜치의 수명을 수 시간 이내로 극단적으로 줄이고, 메인 브랜치(Trunk)로 아주 빈번하게 병합하는 방식이다 [9]. 강력한 CI와 기능 토글(Feature flags)이 뒷받침되는 시니어 팀을 위한 심화 협업 워크플로우로 비교 학습할 수 있다 [9, 20].
+- [[Git-Flow]]
+  - 확장 방향: `develop`, `release`, `hotfix` 등 더 복잡하고 분리된 브랜치 계층을 가지는 전략이다 [9]. 소규모 팀의 단순한 피처 브랜치 워크플로우가 대규모 엔터프라이즈 환경 및 정기 배포 환경으로 확장될 때 어떻게 변모하는지 학습할 수 있다 [9, 23].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Folder Structure.md b/00_Raw/Folder Structure.md
new file mode 100644
index 00000000..2d165975
--- /dev/null
+++ b/00_Raw/Folder Structure.md	
@@ -0,0 +1,74 @@
+# [[Folder Structure]]
+
+## 📌 Brief Summary
+폴더 구조(Folder Structure)는 소프트웨어 프로젝트 내에서 파일과 디렉터리를 논리적으로 조직하는 아키텍처적 기반을 의미합니다 [1, 2]. 최신 프론트엔드 개발에서는 단순한 파일 유형 기반(File-Type Based) 구조의 한계를 극복하기 위해, 비즈니스 도메인이나 기능(Feature)을 중심으로 모듈화하는 방향으로 진화해 왔습니다 [3, 4]. 잘 설계된 폴더 구조는 애플리케이션의 유지보수성, 확장성, 팀 협업 효율을 극대화하고 기술 부채를 줄이는 데 핵심적인 역할을 합니다 [2, 5-9].
+
+## 📖 Core Content
+
+- **기존 구조의 한계와 진화**: 과거에는 컴포넌트, 훅, 스타일 등을 각각의 기술적 파일 유형별 폴더에 모아두는 방식(File-Type Based Structure)을 주로 사용했습니다 [3, 10]. 이 방식은 소규모 앱에서는 설정이 직관적이지만, 애플리케이션이 커질수록 하나의 기능을 수정하기 위해 여러 폴더를 탐색해야 하므로 개발자의 인지 부하를 높이고 스파게티 코드를 유발합니다 [3, 10].
+- **기능 기반 조직(Feature-Based Organization)**: 2025년 현재 업계 표준은 비즈니스 기능(도메인)을 중심으로 코드를 구성하는 방식입니다 [4, 11]. `src/features/` 디렉터리 하위에 특정 기능(예: 인증, 대시보드)과 관련된 컴포넌트, 훅, API 로직, 타입을 모아두어 높은 응집도와 모듈 독립성을 확보합니다 [11, 12].
+- **권장되는 하이브리드 폴더 구조**: 대규모 확장이 가능한 React 프로젝트는 파일 유형과 기능을 결합한 하이브리드 디렉터리 구조를 권장합니다 [13]. 대표적인 `src/` 하위 구성은 다음과 같습니다:
+  - `assets/`: 이미지, 폰트 등 여러 기능에서 공유되는 정적 미디어 리소스 [13, 14].
+  - `components/`: 버튼, 모달 등 도메인에 종속되지 않고 재사용되는 공통 UI 컴포넌트 [11, 14, 15].
+  - `features/`: 도메인별 특정 비즈니스 로직 및 UI가 캡슐화된 모듈 [11, 12, 15].
+  - `pages/` (또는 `routes/`): 라우팅에 매핑되는 페이지 레벨 컴포넌트 [16, 17].
+  - `hooks/`, `services/`, `utils/`: 공통 커스텀 훅, 외부 API 통신 및 비즈니스 로직, 헬퍼 함수 [12, 17-20].
+  - `store/` (또는 `context/`): 전역 상태 관리 로직 [16-18].
+- **Feature-Sliced Design (FSD)**: 기능 기반 구조를 더 엄격한 아키텍처 방법론으로 발전시킨 형태입니다 [21, 22]. 코드를 `app`, `pages`, `widgets`, `features`, `entities`, `shared`라는 명확한 계층(Layer)으로 나눕니다 [23, 24]. 상위 계층이 하위 계층에만 의존할 수 있다는 단방향 의존성 규칙을 강제하여 순환 참조와 아키텍처의 붕괴를 막습니다 [22, 23].
+- **네이밍 컨벤션과 거버넌스**: 폴더 구조는 엄격한 명명 규칙과 결합될 때 효과적입니다. 운영체제 간(Windows/Mac vs Linux) 대소문자 구분 문제로 인한 CI/CD 빌드 실패를 막기 위해 파일과 폴더명은 주로 `kebab-case`를 사용하며, React 컴포넌트 명칭은 `PascalCase`를 사용하는 것이 표준입니다 [25-30]. Next.js에서는 `(folderName)` 형태를 사용하여 URL 경로에 영향을 주지 않고 논리적으로 라우트를 그룹화하는 패턴도 활용됩니다 [31, 32].
+
+## ⚖️ Trade-offs & Caveats
+기능 기반(Feature-based) 구조나 Feature-Sliced Design(FSD)과 같은 고도화된 폴더 구조는 소규모 프로젝트나 초보자에게는 과도한 오버헤드(Overkill)가 될 수 있습니다 [33]. 단순한 앱에 적용할 경우 불필요한 하위 폴더와 중복된 구조를 무수히 생성하게 되어 오히려 개발 속도를 저하시킬 수 있습니다 [33]. 
+
+특히 FSD 구조를 도입할 경우, 특정 모듈이 어느 계층에 속해야 하는지("이 모듈이 feature인가 widget인가?")를 결정하는 데 있어 의미론적 논쟁과 인지적 오버헤드가 발생합니다 [34]. 또한, 팀 전체가 이 방법론과 계층 규칙을 명확히 이해하고 문서화하지 않으면, 개발자들이 규칙을 무시하고 모든 코드를 최하단인 `shared` 폴더에 쏟아부어 오히려 버그를 양산하고 코드 변경 시의 영향 범위(Blast radius)를 통제 불능으로 만들 위험이 큽니다 [34, 35]. 
+
+추가로, 모듈 내부를 캡슐화하기 위해 진입점을 하나로 통일하는 배럴 파일(Barrel files, 예: `index.ts`를 통한 Public API 노출) 패턴은 내부 리팩토링을 안전하게 만들어주지만, 번들링(Bundling)이나 트리 쉐이킹(Tree-shaking) 과정에서 원치 않는 모듈까지 불러와 성능상 불이익을 초래할 수 있다는 단점이 존재합니다 [34, 36, 37].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [아키텍처/기반 기술]
+- [[Feature-Sliced Design]]
+  - 연결 이유: Folder Structure를 단순한 디렉터리 분리가 아닌, 계층(Layer)과 슬라이스(Slice) 기반의 엄격한 아키텍처 방법론으로 승격시킨 개념이기 때문입니다 [21-24].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 단방향 의존성 원칙과 모듈 캡슐화를 통해 대규모 React 앱이 어떻게 스파게티 코드를 방지하는지 이해할 수 있습니다 [23, 37].
+- [[Separation of Concerns]]
+  - 연결 이유: Folder Structure를 UI 렌더링, 비즈니스 로직, 상태 관리 등으로 나누는 핵심 소프트웨어 공학 원리입니다 [8, 30].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 왜 `components/`와 `services/`, `store/` 폴더를 분리해야 하는지 그 근본적인 이유를 알 수 있습니다 [30].
+- [[Domain-Driven Design]]
+  - 연결 이유: 프론트엔드 코드의 폴더를 기술적 유형이 아닌 비즈니스 도메인(기능) 중심으로 나누는 데 논리적 기반을 제공합니다 [12, 38].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: `features/` 폴더 내에 코드를 응집시키는 것이 비즈니스 요구사항 변화에 어떻게 유연하게 대처하게 하는지 파악할 수 있습니다 [38].
+
+#### [구현/활용 도구]
+- [[Naming Conventions]]
+  - 연결 이유: 일관된 명명 규칙은 폴더 구조의 가독성과 예측 가능성을 완성하는 필수 요소입니다 [25, 26, 30, 39].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 왜 폴더명은 `kebab-case`를 쓰고 컴포넌트는 `PascalCase`를 써야 CI/CD 파이프라인에서 오류가 나지 않는지 이해할 수 있습니다 [25, 40].
+- [[State Management]]
+  - 연결 이유: 폴더 구조에서 전역 상태(`store/`, `context/`)와 지역/기능 상태(`features/`)를 어디에 위치시킬지 결정하는 핵심 요소입니다 [16, 18, 19, 41, 42].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: Zustand, Context API 등 관리 도구에 따라 전역 인프라 상태와 도메인 상태를 분리 배치하는 전략을 학습할 수 있습니다 [43].
+
+### Deeper Research Questions
+
+- Feature-Sliced Design(FSD)에서 하위 계층이 상위 계층을 참조하지 못하도록 ESLint 규칙을 통해 어떻게 단방향 의존성을 강제할 수 있는가?
+- 배럴 파일(`index.ts`)을 이용한 Public API 패턴이 Webpack이나 Vite의 트리 쉐이킹(Tree-shaking) 최적화에 미치는 정확한 부작용과 그 해결책은 무엇인가?
+- '인증(Auth)'과 같이 애플리케이션 전반에 걸쳐 사용되는 교차 절단 관심사(Cross-cutting concerns)는 기능 기반(Feature-based) 폴더 구조에서 어떻게 분리하고 배치해야 코드 응집도를 잃지 않는가?
+- 소규모 프로젝트(Flat structure)에서 대규모 프로젝트(Feature-Sliced Design)로 폴더 구조를 마이그레이션해야 하는 구체적인 임계점(컴포넌트 수, 팀 규모 등)이나 코드 스멜 지표는 무엇인가?
+- Next.js의 App Router에서 제공하는 Route Grouping `(folder)` 문법과 기존의 기능 기반 폴더 분리(`features/`) 패턴을 어떻게 충돌 없이 조화롭게 설계할 수 있는가?
+
+### Practical Application Contexts
+
+- **Implementation:** 운영체제(Windows vs Linux)에 따른 대소문자 구분 이슈를 방지하기 위해 폴더와 파일명 생성 시 일관된 `kebab-case`를 적용하는 규칙을 프로젝트 린팅 룰에 설정합니다 [25-27].
+- **System Design:** 프로젝트 설계 초기 단계에서 `features/` 폴더를 정의하여 UI 요소와 비즈니스 로직의 경계를 명확히 하고, 공통 컴포넌트는 오직 Presentation 역할만 수행하도록 시스템을 구조화합니다 [11, 44].
+- **Operation / Maintenance:** 새로운 개발자가 팀에 합류했을 때, 기능별로 고립된 폴더 구조를 통해 전체 코드를 파악하지 않고도 자신이 맡은 도메인(`features/auth` 등)만 분석하여 즉시 유지보수 업무에 투입될 수 있도록 돕습니다 [6].
+- **Learning Path:** 처음 React를 학습할 때는 Flat 구조로 시작하여 기본기를 익히고, 프로젝트가 커짐에 따라 File-Type Based 구조를 거쳐 최종적으로 Feature-Based 또는 FSD 아키텍처로 진화하는 순차적 학습이 권장됩니다 [4, 9, 10, 33].
+- **My Project Relevance:** 현재 진행 중인 또는 계획된 React 프로젝트의 규모와 팀원의 숙련도를 평가하여, 지나치게 복잡한 FSD를 바로 도입하기보다는 `features/`와 `components/`를 결합한 하이브리드 방식을 적용해 점진적인 모듈화를 시도하는 지표로 삼을 수 있습니다.
+
+### Adjacent Topics
+
+- [[Code Splitting]]
+  - 확장 방향: 폴더 구조를 라우트나 기능 단위로 명확히 나누면, Vite나 Webpack을 이용해 해당 모듈들을 독립적인 청크(Chunk)로 나누어 지연 로딩(Lazy Loading)하는 최적화 전략으로 자연스럽게 확장할 수 있습니다 [45, 46].
+- [[Micro-Frontends]]
+  - 확장 방향: 모놀리식 단일 폴더 구조가 감당할 수 없을 만큼 거대해진 엔터프라이즈 환경에서, 아예 독립적으로 배포 및 운영 가능한 프론트엔드 애플리케이션으로 분할하는 극단적 아키텍처 방법론으로 확장됩니다 [21].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Frontend Application Stability.md b/00_Raw/Frontend Application Stability.md
new file mode 100644
index 00000000..038d3a71
--- /dev/null
+++ b/00_Raw/Frontend Application Stability.md	
@@ -0,0 +1,68 @@
+# [[Frontend Application Stability]]
+
+## 📌 Brief 단기 요약
+Frontend Application Stability(프론트엔드 애플리케이션 안정성)는 현대의 복잡한 웹 애플리케이션이 런타임 오류, 성능 저하 및 메모리 누수를 우아하게 처리하며 신뢰성 있게 작동하는 상태를 의미합니다 [1-3]. 이를 달성하기 위해서는 단일 컴포넌트의 오류가 전체 애플리케이션의 크래시(예: 흰 화면)로 이어지는 것을 막는 방어 기제와 효율적인 메모리 관리, 그리고 예측 가능한 아키텍처 설계가 필수적입니다 [2, 4, 5]. 결과적으로 안정적인 시스템은 예상치 못한 결함이 발생하더라도 앱의 나머지 부분을 상호작용 가능한 상태로 유지하며 사용자 경험을 보호합니다 [6, 7].
+
+## 📖 Core Content
+*   **에러 경계(Error Boundaries)를 통한 장애 격리:** React 애플리케이션은 렌더링 중 오류가 발생하면 기본적으로 전체 컴포넌트 트리를 마운트 해제하여 빈 화면을 노출합니다 [8, 9]. 이를 방지하기 위해 Error Boundary(클래스 컴포넌트 형태)를 사용하여 하위 트리에서 발생하는 JavaScript 에러(렌더링, 생명주기 메서드, 생성자 내부)를 포착하고 대체 UI(Fallback UI)를 렌더링합니다 [2, 9]. 대시보드, 서드파티 위젯, 복잡한 폼 등 불안정한 UI 섹션을 개별 Error Boundary로 감싸면 한 컴포넌트에 버그가 있어도 앱의 나머지 기능은 정상 작동합니다 [4, 6, 8].
+*   **메모리 누수 관리와 성능 안정성:** 애플리케이션이 장시간 실행될 때 할당된 메모리가 해제되지 않고 누적되는 메모리 누수(Memory Leak)는 모바일 기기에서의 앱 정지나 성능 저하의 주원인입니다 [3, 10, 11]. 컴포넌트가 마운트 해제될 때 제거되지 않은 이벤트 리스너나 DOM 트리에서 분리되었으나 JavaScript 참조가 남아있는 'Detached DOM nodes', 클로저(Closure)에 의해 유지되는 불필요한 참조 등이 대표적인 원인입니다 [12-14]. 이를 방지하기 위해 `useEffect` 내에서 정리(Cleanup) 함수를 실행해야 하며 [15], 객체 캐싱 시 가비지 컬렉션이 가능한 `WeakMap`을 활용할 수 있습니다 [16].
+*   **의존성 제어와 아키텍처 모듈화:** 비즈니스 로직과 UI 컴포넌트가 무분별하게 섞이고 암묵적인 의존성이 생기면 애플리케이션 구조가 붕괴됩니다 [17, 18]. FSD(Feature-Sliced Design) 같은 아키텍처는 코드를 기능(Scope) 단위로 구성하고 단방향 의존성(상위 레이어는 하위 레이어에 의존할 수 있으나 역은 불가)을 강제합니다 [19]. 이러한 규칙은 순환 참조를 제거하고 코드 변경 시 다른 모듈에 미치는 부작용(Side effect)을 차단하여 코드베이스의 안정성을 높입니다 [19, 20].
+*   **모니터링 및 가시성 확보:** 프로덕션 환경에서의 안정성을 유지하려면 사용자 환경에서 발생하는 에러를 포착하는 로깅 도구가 필요합니다 [21, 22]. Sentry, LogRocket, Datadog 같은 클라우드 도구들은 단순한 스택 트레이스를 넘어, 네트워크 요청, 사용자 상호작용, Redux/Zustand 상태 변화를 포함한 '세션 리플레이(Session Replay)'를 제공하여 복잡한 버그의 근본 원인을 추적할 수 있게 합니다 [22-26].
+*   **워크플로우 및 배포 안정성:** Git 플로우 환경에서 main 브랜치의 배포 안정성을 유지하려면 기능 브랜치(Feature branch) 단위로 작업을 분리하고 Pull Request 단계에서 코드 리뷰를 거쳐야 합니다 [27-29]. 특히 Storybook과 Happo 같은 도구를 연동하면, 시각적 회귀(Visual Regression)와 접근성 테스트를 통해 의도치 않은 UI 변경이나 결함이 프로덕션에 배포되는 것을 사전에 차단할 수 있습니다 [30-32].
+
+## ⚖️ Trade-offs & Caveats
+*   **Error Boundaries의 포착 한계:** Error Boundaries는 선언적인 렌더링 내의 에러는 포착하지만 이벤트 핸들러 내부, 비동기 코드(`setTimeout` 등), 서버 사이드 렌더링, 혹은 Error Boundary 컴포넌트 자체에서 발생한 에러는 잡아내지 못합니다 [33-35]. 이러한 경우 기존의 명령형 `try/catch` 블록을 수동으로 사용해 대응해야 합니다 [34, 36].
+*   **모니터링 도구의 성능 부하 및 비용:** 세션 리플레이와 상세한 프론트엔드 로깅을 제공하는 도구(예: LogRocket, Datadog)는 상세한 디버깅 컨텍스트를 제공하는 이점이 있으나, 번들 크기를 증가시키고 페이지 로드 시간을 최대 120ms까지 지연시킬 수 있는 성능 상의 트레이드오프가 있습니다 [37-39]. 또한, 트래픽이 높은 서비스에서는 데이터 수집(Ingest) 및 인덱싱(Index)에 막대한 비용이 발생할 수 있으므로, 로그 볼륨을 조절하는 등의 타협이 필요합니다 [40-42].
+*   **아키텍처 엄격성에 따른 학습 곡선:** FSD나 엄격한 폴더 분리 정책은 애플리케이션의 장기적 안정성을 돕지만, 초기 진입 장벽이 높습니다 [43, 44]. 개발자가 컴포넌트 중심 사고에서 '기능(Feature)' 중심 사고로 전환해야 하며, 작은 프로젝트에서는 불필요한 추상화나 오버엔지니어링으로 느껴질 수 있습니다 [43, 45, 46].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [관계 유형 A (아키텍처/기반 기술)]
+- [[Feature-Sliced Design]]
+  - 연결 이유: 대규모 애플리케이션에서 코드의 모듈성과 단방향 의존성을 강제하여 구조적 붕괴로 인한 불안정성을 방지합니다 [19, 47, 48].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 비즈니스 로직, 공유 UI, 엔티티를 명확한 계층(Layers)으로 나누고 외부 인터페이스(Public API)만을 노출시켜 의존성을 관리하는 원리 [19, 20, 49].
+
+- [[React Error Boundaries]]
+  - 연결 이유: 런타임 렌더링 에러가 발생했을 때 앱 전체가 정지하는 것을 막고, 사용자에게 유연한 대처 방안을 제공하는 핵심 방어 수단입니다 [2, 7, 9].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: React 컴포넌트 생명주기 내에서 에러를 전파하고 대체 화면(Fallback UI)으로 복구하는 선언적 에러 처리 방식 [33, 34, 50].
+
+- [[Memory Leaks]]
+  - 연결 이유: 애플리케이션이 장시간 사용될 때 메모리 한계를 초과하여 앱이 멈추거나 충돌(Crash)하게 만드는 주요 원인입니다 [10, 11].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 분리된 DOM 노드(Detached DOM nodes)나 해제되지 않은 이벤트 리스너가 JavaScript 가비지 컬렉터를 방해하는 메커니즘 [12, 13, 51].
+
+#### [관계 유형 B (구현/활용 도구)]
+- [[Cloud Logging Tools]]
+  - 연결 이유: 프로덕션 환경의 프론트엔드 에러와 성능 이슈를 가시화하고 실시간으로 모니터링하여 문제 해결 속도를 극대화합니다 [21, 22].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 세션 리플레이(Session Replay), 에러 자동 그룹화, 분산 추적(Distributed Tracing)을 통한 복잡한 버그 컨텍스트의 해석 과정 [23-25, 52].
+
+- [[Chrome DevTools Memory Profiler]]
+  - 연결 이유: 눈에 보이지 않는 메모리 누수와 객체 유지(Retention) 상태를 실시간으로 진단하여 안정성을 개선하는 분석 도구입니다 [5, 11].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 힙 스냅샷(Heap Snapshot)의 델타(Delta) 값 비교 및 할당 타임라인(Allocation Timeline)을 통해 누수 원인 객체를 역추적하는 방법 [5, 53, 54].
+
+### Deeper Research Questions
+
+- React Error Boundaries가 비동기 로직이나 이벤트 핸들러에서 발생하는 예외를 본질적으로 포착하지 못하는 React의 렌더링 아키텍처적 이유는 무엇인가?
+- 프론트엔드 환경에서 WeakMap을 활용한 캐시 관리가 클로저(Closure)로 인해 발생하는 메모리 누수를 구체적으로 어떻게 예방하는가?
+- 대규모 팀 환경에서 Feature-Sliced Design(FSD) 도입 시, 인증(Auth)과 같은 횡단 관심사(Cross-cutting concerns)를 레이어 원칙에 위배되지 않게 배치하는 최적의 방법은 무엇인가?
+- 프로덕션 환경에 Sentry나 LogRocket을 적용할 때, Core Web Vitals(특히 TBT, INP 등) 저하를 최소화하면서도 필요한 로그를 확보하기 위한 최적의 샘플링 비율과 설정 전략은 무엇인가?
+- 전역 상태 관리 도구(Context API vs. Zustand 등)의 선택이 불필요한 리렌더링 폭주를 유발하여 앱의 성능적 안정성에 미치는 구조적인 차이는 무엇인가?
+
+### Practical Application Contexts
+
+- **Implementation:** React 컴포넌트를 작성할 때 서드파티 라이브러리나 복잡한 데이터를 다루는 위젯은 개별 Error Boundary로 감싸 오류를 국소화(Isolate)하고, `useEffect` 훅 내부의 이벤트 구독은 반드시 해제(Cleanup)하여 메모리 누수를 방지합니다 [4, 8, 15, 16].
+- **System Design:** 애플리케이션의 폴더 구조를 기술 스택 기준이 아닌 기능(Feature/Domain) 기반 또는 FSD 구조로 설계하여 모듈 간의 암묵적인 얽힘을 막고 장기적인 유지보수성을 보장합니다 [48, 55, 56].
+- **Operation / Maintenance:** Sentry 또는 Datadog RUM을 CI/CD 파이프라인과 통합하여, 새로운 배포 직후 발생하는 고유한 런타임 오류나 퍼포먼스 저하를 세션 리플레이를 통해 즉각적으로 인지하고 핫픽스를 수행합니다 [22-24, 52].
+- **Learning Path:** 우선 React의 렌더링 동작 원리와 생명주기 메서드를 학습한 뒤, Error Boundaries 구현 -> Chrome DevTools를 활용한 Memory Leak 분석 기법 -> FSD 같은 확장 가능한 아키텍처 패턴 순서로 시스템 레벨의 안정성 설계 능력을 키웁니다 [2, 9, 47, 53].
+- **My Project Relevance:** 현재 유지보수 중이거나 개발 중인 프로젝트의 `main` 브랜치 안정성을 위해 Pull Request 시 Storybook 및 Happo를 통한 시각적 회귀 테스트(Visual Regression Test) 자동화를 연동하고, 불안정한 페이지 구역에 Error Boundary를 씌워 사용자의 이탈을 방지할 수 있습니다 [8, 30, 31].
+
+### Adjacent Topics
+
+- [[React Performance Optimization]]
+  - 확장 방향: 안정성 유지뿐 아니라 `React.memo`, `useMemo`, `useCallback`, 가상화(Virtualization) 등을 통해 불필요한 리렌더링을 차단하고 런타임 성능을 극대화하는 실행 레벨의 최적화 기법 탐구 [57-60].
+- [[Git Workflow & Governance]]
+  - 확장 방향: 안정적인 배포와 버전 관리를 담보하기 위한 Feature Branching, GitHub Flow, Conventional Commits 등 협업 규칙 및 CI/CD 품질 게이트(Quality gates) 적용 방안 [29, 61-63].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Frontend Engineering Governance.md b/00_Raw/Frontend Engineering Governance.md
new file mode 100644
index 00000000..713f17b3
--- /dev/null
+++ b/00_Raw/Frontend Engineering Governance.md	
@@ -0,0 +1,60 @@
+# [[Frontend Engineering Governance]]
+
+## 📌 Brief Summary
+Frontend Engineering Governance는 일관된 네이밍 규칙, 프로젝트 표준, 자동화된 린팅 도구 및 엄격한 Git 워크플로우를 통해 프론트엔드 프로젝트의 코드 품질과 협업 효율성을 유지하는 체계적인 접근 방식입니다 [1, 2]. 수동적인 코드 리뷰에 의존하는 대신 ESLint, Prettier, Husky와 같은 도구를 활용하여 아키텍처 경계를 보호하고 코드 품질 검증을 자동화하는 데 중점을 둡니다 [3]. 이를 통해 잠재적인 버그와 아키텍처의 붕괴를 예방하고 예측 가능하며 확장 가능한 소프트웨어 개발 환경을 보장합니다 [4, 5].
+
+## 📖 Core Content
+*   **네이밍 규칙 및 표준화 (Naming Conventions):** 대소문자를 구분하는 환경(예: Linux 기반 운영 서버)에서 빌드 실패를 방지하기 위해 파일 및 폴더 이름은 `kebab-case`를 사용합니다 [6]. 리액트 컴포넌트는 `PascalCase`, 사용자 정의 훅(Custom Hooks)과 일반 변수 및 함수는 `camelCase`, 상수는 `UPPER_SNAKE_CASE`로 표준화하여 가독성을 높이고 파일의 목적을 명확히 합니다 [3, 7-9].
+*   **자동화된 툴 기반 거버넌스 (Governance through Tooling):** 수동적인 코드 표준 강제는 비효율적이므로, 현대적인 프로젝트는 ESLint와 Prettier를 활용하여 위반 사항을 자동으로 찾아 수정합니다 [3]. 특히 ESLint 규칙을 구성하여 특정 임포트 패턴(예: 한 기능이 다른 기능의 내부를 직접 임포트하는 것)을 금지함으로써 Feature-Sliced Design(FSD)과 같은 아키텍처의 계층적 경계를 엄격하게 강제할 수 있습니다 [3].
+*   **Git 훅(Git Hooks)을 통한 사전 방지:** Husky와 같은 도구를 도입하여 코드가 리포지토리에 커밋되기 전에 린팅, 코드 포맷팅, 타입 검사를 필수적으로 실행합니다 [3]. 이를 통해 품질이 낮은 코드나 규칙을 위반한 코드가 코드베이스에 들어오는 것을 원천 차단합니다 [3].
+*   **협업 워크플로우 및 Git 거버넌스 (Git Governance):** 개발자는 메인 브랜치에 직접 커밋하지 않고 짧은 수명의 기능 브랜치(Feature Branch)를 사용하며, 동료의 코드 리뷰와 CI/CD 검사를 통과한 후에만 병합(Merge)합니다 [4]. 커밋 메시지는 'Conventional Commits' 규격(`feat:`, `fix:`, `docs:`, `refactor:`, `chore:`)을 준수하여 가독성을 높이고 릴리스 노트 자동화를 돕습니다 [10]. 또한, 추적성을 높이기 위해 브랜치 이름과 커밋 메시지에 티켓 ID(예: `PROJ-123`)를 포함합니다 [11, 12].
+*   **시각적 리뷰 및 PR 품질 관리 (Visual Reviews):** 풀 리퀘스트(PR)는 단일 작업에 초점을 맞춰 작게 유지해야 합니다 [10]. Storybook 및 Chromatic과 같은 도구를 CI 파이프라인에 통합하여, PR이 열릴 때마다 시각적 회귀 테스트(Visual regression testing)를 자동으로 수행하고 의도치 않은 UI 변경이 없는지 검증합니다 [13-15].
+
+## ⚖️ Trade-offs & Caveats
+강력한 린팅 규칙 및 자동화된 거버넌스는 프로젝트 초기에 도구 설정(ESLint, Husky, CI 연동 등)에 많은 시간 투자를 요구하며, 개발자들에게 다소 가파른 러닝 커브를 줄 수 있습니다 [3, 16]. 엄격한 규칙으로 인해 단순한 기능 구현이나 프로토타이핑 시에도 부가적인 린트 에러 수정 및 아키텍처 규칙 준수가 강제되어 초기 개발 속도를 늦출 수 있습니다 [3]. 또한, 작은 규모의 팀이나 단순한 프로젝트의 경우 지나치게 복잡한 Git Flow나 과도한 시각적 회귀 테스트 설정은 불필요한 관리 오버헤드(Overhead)를 발생시킬 수 있으므로, 팀의 성숙도와 프로젝트 규모에 맞는 적절한 수준의 규칙(예: 단순한 Feature-Branch 워크플로우)을 채택하는 것이 중요합니다 [17, 18].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [관계 유형 A (아키텍처/기반 기술)]
+*   [[Feature-Sliced Design (FSD)]]
+    *   연결 이유: 프론트엔드 코드의 스코프와 책임을 명확히 구분하고 계층 간의 단방향 의존성을 거버넌스 규칙으로 강제해야 하는 아키텍처이기 때문입니다 [19, 20].
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: ESLint 규칙을 통해 모듈 간 임포트를 어떻게 제한하여 시스템의 구조적 붕괴를 막을 수 있는지에 대한 실질적 이해 [3].
+*   [[Conventional Commits]]
+    *   연결 이유: 명확한 Git 거버넌스를 위해 필수적으로 채택되는 커밋 메시지 작성 표준이기 때문입니다 [10].
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 팀 전체의 커밋 히스토리를 깔끔하게 유지하고, 릴리스 자동화 파이프라인을 구축하는 방법 [10, 21].
+
+#### [관계 유형 B (구현/활용 도구)]
+*   [[ESLint and Prettier]]
+    *   연결 이유: 수동 리뷰의 비효율성을 제거하고 코딩 표준과 아키텍처 규칙을 자동으로 강제하는 거버넌스의 핵심 도구입니다 [3].
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 프로젝트 내 네이밍 규칙 일관성 유지 및 아키텍처 경계 위반 방지를 코드로 자동화하는 방법 [3].
+*   [[Husky]]
+    *   연결 이유: 개발자가 코드를 커밋하기 전(Pre-commit)에 거버넌스 규칙(린팅, 포맷팅)을 무조건적으로 통과하도록 훅(Hook)을 걸어주는 도구이기 때문입니다 [3].
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 잘못된 코드가 원격 리포지토리로 푸시되는 것을 원천적으로 차단하는 프론트엔드 품질 게이트웨이 구성 [3].
+*   [[Visual Regression Testing (Chromatic)]]
+    *   연결 이유: 컴포넌트 기반 프론트엔드에서 코드가 변경될 때 UI가 깨지지 않았는지 풀 리퀘스트(PR) 단계에서 검증하는 시각적 품질 거버넌스 수단입니다 [13, 15].
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: Storybook과 연동하여 코드 리뷰 과정에서 인간이 놓치기 쉬운 픽셀 단위의 시각적 변경 사항을 자동으로 감지하는 원리 [22, 23].
+
+### Deeper Research Questions
+*   ESLint를 활용해 Feature-Sliced Design의 단방향 의존성(Unidirectional dependencies) 규칙을 구체적으로 어떻게 설정하고 강제할 수 있는가?
+*   Husky와 같은 Git 훅 도구를 도입했을 때 개발자 경험(Developer Experience)을 저해하지 않으면서도 필수 검사를 실행하는 최적의 속도 최적화 방법은 무엇인가?
+*   소규모 3인 팀에서 대규모 엔터프라이즈 팀으로 성장함에 따라 Git 브랜칭 전략과 리뷰 거버넌스 규칙은 단계별로 어떻게 진화해야 하는가?
+*   단일 리포지토리에 방대한 코드가 존재하는 경우(Monorepo), 도메인별 거버넌스 규칙을 어떻게 분리하여 적용할 수 있는가?
+*   기존의 레거시 프로젝트(거버넌스가 없는 상태)에 자동화된 린팅, 네이밍 규칙, 티켓 ID 시스템을 업무 중단 없이 점진적으로 도입하기 위한 마이그레이션 전략은 무엇인가?
+
+### Practical Application Contexts
+*   **Implementation:** 프로젝트 초기 세팅 시 Prettier, ESLint, Husky를 설치하여 코드 스타일과 네이밍 규칙을 정의하고, 개발자의 로컬 환경에서 자동으로 코드가 포맷팅 및 검증되도록 내재화합니다 [3].
+*   **System Design:** FSD와 같은 아키텍처를 설계할 때, 하위 계층이 상위 계층을 임포트하지 못하도록 시스템적인 린트(Lint) 룰을 함께 설계하여 아키텍처의 의도가 무너지지 않게 보호합니다 [3].
+*   **Operation / Maintenance:** PR(Pull Request) 템플릿과 Conventional Commits을 의무화하고, 브랜치명에 이슈 티켓 번호(예: `feature/PROJ-123-user-auth`)를 삽입하게 하여 유지보수 시 변경 이력과 기획 의도를 쉽게 추적할 수 있도록 운영합니다 [10, 24].
+*   **Learning Path:** React 문법과 컴포넌트 생태계를 익힌 후, 협업을 위한 클린 코드 원칙과 Git 전략을 학습하고, 이를 실제 프로젝트에 강제하기 위한 환경 구축(ESLint 설정 등)으로 나아가는 과정에 필수적입니다 [3, 25].
+*   **My Project Relevance:** 현재 진행 중이거나 앞으로 도입될 팀 프로젝트에서 개발자 간 코드 스타일 충돌과 불명확한 커밋 로그로 인한 문제를 방지하기 위해 직접 Git 훅을 설정하고 PR 규칙을 도입할 수 있습니다 [3, 26].
+
+### Adjacent Topics
+*   [[Clean Code Principles (SOLID, DRY, KISS, YAGNI)]]
+    *   확장 방향: 거버넌스가 규칙의 "도구적 강제"라면, 클린 코드는 개발자가 그 구조 안에서 컴포넌트를 분리하고 함수를 작성할 때 준수해야 할 근본적인 사고방식과 철학을 이해하도록 확장됩니다.
+*   [[CI/CD Pipelines]]
+    *   확장 방향: 로컬 환경의 Git 훅을 넘어 클라우드 환경(GitHub Actions 등)에서 풀 리퀘스트를 자동으로 검증, 빌드, 시각적 테스트 및 배포하는 지속적 통합/배포 파이프라인 개념으로 이해를 넓힙니다.
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Frontend Scalable Architecture.md b/00_Raw/Frontend Scalable Architecture.md
new file mode 100644
index 00000000..561d0034
--- /dev/null
+++ b/00_Raw/Frontend Scalable Architecture.md	
@@ -0,0 +1,75 @@
+# [[Frontend Scalable Architecture]]
+
+## 📌 Brief Summary
+프론트엔드 확장 가능 아키텍처(Frontend Scalable Architecture)는 비즈니스 로직과 UI 컴포넌트의 결합을 방지하고 애플리케이션의 성장을 안전하게 도모하는 구조적 방법론이다 [1]. 단순한 렌더링 속도 최적화를 넘어 상태 소유권 명확화, 명시적 의존성 관리, 기능(Feature) 중심의 모듈화를 통해 예측 가능한 코드베이스의 확장을 목표로 한다 [1, 2]. 현대적인 아키텍처는 Feature-Sliced Design(FSD)과 같은 계층적 모델을 도입하여 팀 간 협업 효율을 높이고 장기적인 유지보수성을 극대화한다 [3].
+
+## 📖 Core Content
+- **기능(Feature) 기반 조직과 FSD (Feature-Sliced Design):**
+  과거의 기술 파일 타입(컴포넌트, 훅, 스타일 등) 기준 폴더 구조는 애플리케이션이 커질수록 탐색과 유지보수를 어렵게 만든다 [4, 5]. 2025년 기준 표준은 비즈니스 기능(도메인)을 중심으로 코드를 구성하는 것이다 [6]. 특히 FSD는 앱을 7개의 계층(`shared`, `entities`, `features`, `widgets`, `pages`, `app`)으로 나누어 상위 계층이 하위 계층에만 의존하게 하는 **단방향 의존성**을 강제한다 [7]. 또한 `index.ts`를 유일한 진입점으로 사용하는 Public API 규칙을 통해 내부 로직을 캡슐화한다 [8, 9].
+
+- **SOLID 및 클린 코드 원칙의 적용:**
+  React 컴포넌트 개발 시 단일 책임 원칙(SRP)을 적용하여 역할이 많은 대형 컴포넌트(예: 300줄 이상)를 작고 집중된 형태의 컴포넌트로 분리한다 [10]. 개방-폐쇄 원칙(OCP)은 `children`이나 `render props`를 통한 합성으로 구현하며, 인터페이스 분리 원칙(ISP)을 통해 사용하지 않는 거대한 Props 객체 전달을 방지하여 결합도를 낮춘다 [11]. 또한 DRY(중복 방지) 원칙과 KISS(단순성 유지) 원칙 간의 균형을 잡아 과도한 추상화를 방지한다 [12].
+
+- **파편화 및 전문화된 상태 관리:**
+  거대한 단일 스토어 방식에서 벗어나 상태 특성에 맞는 도구를 분리하여 선택한다. 로컬 상태는 `useState`를, 애플리케이션 전역 상태는 렌더링 최적화를 위해 Context API 대신 `Zustand`나 `Jotai`를 활용하며, 서버 상태(캐시, 네트워크 동기화)는 `TanStack Query`를 사용하여 API 네트워크 계층과 UI를 분리한다 [13-16].
+
+- **빌드 타임 성능 및 번들링 최적화:**
+  Vite를 사용하여 개발 중에는 네이티브 ES 모듈을 제공해 즉각적인 반영을 얻고, 프로덕션에서는 Rollup을 통한 `manualChunks` 설정과 `React.lazy`를 활용해 경로(Route) 수준의 코드 스플리팅을 적용한다 [17-20]. 특히 2025년에 안정화된 React Compiler는 불필요한 리렌더링 방지를 위한 메모이제이션을 빌드 타임에 자동으로 처리해주어 수동 최적화(`useMemo`, `useCallback`)로 인한 코드 복잡도를 획기적으로 줄여준다 [18, 21, 22].
+
+- **안정성 및 오류 복구 인프라:**
+  애플리케이션의 일부가 실패하더라도 전체가 멈추지 않도록 React Error Boundaries를 불안정한 UI 섹션에 전략적으로 배치한다 [23, 24]. 프로덕션 단계에서는 Sentry, LogRocket 같은 도구를 결합하여 메모리 누수, 분리된 DOM 노드 파악, 세션 리플레이를 통한 에러 모니터링 체계를 구축한다 [25-27].
+
+## ⚖️ Trade-offs & Caveats
+- **상태 관리 도구의 선택 (Context vs Zustand vs Redux):** Context API는 기본 내장 도구라는 장점이 있으나, 상태 값의 일부만 변경되어도 해당 컨텍스트를 구독하는 모든 컴포넌트가 리렌더링되는 치명적인 성능 저하를 유발한다 [28, 29]. 반면 Zustand는 선택자(Selector) 패턴으로 이 문제를 해결하고 구조가 가볍지만, 너무 유연하여 팀 내 규칙이 부재할 경우 전역 상태와 비동기 로직이 중구난방이 되는 부작용(Store Soup)을 낳을 수 있다 [30-32]. Redux는 엄격한 패턴을 제공하여 대규모 팀에 안정적이나, 과도한 보일러플레이트로 초기 개발과 MVP 구현 속도를 크게 늦춘다 [33, 34].
+- **성능 최적화의 함정:** `React.memo`나 `useCallback`을 무분별하게 사용하면 메모이제이션을 판단하는 얕은 비교 처리에 비용이 더 발생해 오히려 성능을 악화시킬 수 있다 [35, 36]. 
+- **FSD 아키텍처의 오버헤드:** Feature-Sliced Design은 명확한 캡슐화와 분리 구조를 제공하지만, 특정 모듈이 'feature'인지 'widget'인지 경계를 구분하기 모호한 상황 등 시맨틱 결정을 위한 커뮤니케이션 오버헤드가 발생하며, 새로운 팀원에게는 가파른 학습 곡선으로 작용한다 [37, 38].
+- **마이크로 프론트엔드(Micro-Frontends):** 조직적인 확장성을 해결하고 독립적인 배포를 가능하게 하지만, 런타임 통합의 복잡성, 성능 오버헤드 증가, 파편화된 개발자 경험을 초래하므로 기본 아키텍처라기보다는 최후의 수단으로 간주해야 한다 [3].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [아키텍처 및 방법론]
+- [[Feature-Sliced Design]]
+  - 연결 이유: 대규모 프론트엔드 앱의 구조를 기술 계층이 아닌 비즈니스 도메인(기능) 중심으로 나누고, 엄격한 계층 구조를 제공하는 핵심 아키텍처이기 때문 [3, 7].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 폴더 구조화, 캡슐화를 위한 Public API 제어 전략, 단방향 의존성을 통한 결합도 감소 원리 [7, 8].
+- [[SOLID Principles in React]]
+  - 연결 이유: 확장성 있는 컴포넌트와 훅 설계를 위한 근본적인 소프트웨어 엔지니어링 가이드라인이기 때문 [9].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: SRP(단일 책임 원칙)와 ISP(인터페이스 분리 원칙)를 활용해 결합도는 낮추고 응집도는 높은 컴포넌트를 분리해내는 실무적 기법 [10, 11].
+
+#### [상태 관리 및 성능 최적화 도구]
+- [[Zustand]]
+  - 연결 이유: Context API의 '리렌더링 폭포' 한계를 극복하고 Redux의 복잡성을 피하면서 전역 상태를 효과적으로 스케일링하는 대안이기 때문 [29, 32].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: Selector 패턴이 컴포넌트의 특정 상태 구독을 제어하여 어떻게 렌더링 최적화를 달성하는지에 대한 메커니즘 [32].
+- [[React Compiler]]
+  - 연결 이유: 2025년 기준 개발자가 수동으로 수행하던 메모이제이션(`useMemo`, `useCallback` 등) 작업을 빌드 타임에 자동화하여 코드 복잡도를 획기적으로 낮춰주는 도구이기 때문 [21, 22].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 개별 JSX 요소의 세밀한 메모이제이션 작동 방식과 서드파티 라이브러리에 대응하기 위한 최적화 제약 조건 [39, 40].
+- [[React Error Boundaries]]
+  - 연결 이유: 확장 가능한 대규모 애플리케이션에서 특정 하위 모듈이나 컴포넌트의 런타임 오류가 전체 애플리케이션의 크래시로 이어지는 것을 막는 핵심 안정화 장치이기 때문 [23, 24].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 에러의 선언적 격리와 Fallback UI 제공을 통해 프로덕션 환경의 UX와 회복력을 강화하는 방식 [41, 42].
+
+### Deeper Research Questions
+
+- Feature-Sliced Design(FSD)에서 Cross-cutting concern(교차 관심사)을 완벽히 격리하는 것이 현실적으로 어려운 이유는 무엇이며, 이를 상위 계층에서 어떻게 컴포지션(Composition)으로 해결해야 하는가?
+- React Compiler가 빌드 타임에 메모이제이션을 자동화함에도 불구하고, 서드파티 라이브러리(예: TanStack Query 등)가 반환하는 불안정한 참조(Unstable References)가 있을 때 왜 여전히 수동 메모이제이션이 필요한가?
+- Context API가 유발하는 '리렌더링 폭포 현상'을 우회하기 위해 설계된 Zustand의 Selector 패턴은 내부적으로 어떻게 필요한 상태 변화만 감지하고 컴포넌트를 업데이트하는가?
+- Vite 환경에서 `manualChunks`와 `React.lazy`를 결합하여 거대한 번들(Large Chunks)을 분리해 낼 때, 이러한 전략이 Core Web Vitals(특히 LCP 및 INP)에 미치는 실제 브라우저 동작 메커니즘은 어떠한가?
+- 대규모 애플리케이션에서 마이크로 프론트엔드(Micro-Frontends) 도입 시 발생하는 런타임 통합의 성능 오버헤드는 FSD와 같은 모놀리식 모듈형 아키텍처와 비교하여 어떠한 한계를 가지는가?
+
+### Practical Application Contexts
+
+- **Implementation:** 코드를 구현할 때 비즈니스 도메인 단위로 폴더를 생성(Feature 폴더)하며, 300줄이 넘어가는 컴포넌트는 단일 책임 원칙(SRP)에 따라 작은 UI 요소와 커스텀 훅으로 분리하여 작성한다 [6, 10, 43].
+- **System Design:** 모듈 간 결합도를 최소화하기 위해 하위 계층(예: shared, entities)에서 상위 계층(예: features, pages)을 참조하지 못하도록 ESLint 규칙으로 단방향 의존성을 강제하고, 각 폴더의 접근 창구를 `index.ts`로 캡슐화(Public API 규칙)하여 아키텍처를 설계한다 [7, 8, 44].
+- **Operation / Maintenance:** 프로덕션 환경에서 Sentry를 통해 Error Boundary가 잡지 못한 에러를 모니터링하고, 크롬 DevTools의 메모리 스냅샷이나 LogRocket과 같은 디버깅 툴로 이벤트 리스너 미해제에 따른 Detached DOM 메모리 누수를 지속적으로 추적 및 유지보수한다 [25-27].
+- **Learning Path:** React 코어 원리와 상태 관리의 한계(Context API 병목 현상) 인지 → 확장성을 고려한 아키텍처 원칙(FSD, SOLID) 학습 → 도메인 분리 도구 적용(Zustand, TanStack Query) → 성능 및 번들링 최적화(React Compiler, Vite 코드 스플리팅) 순서로 학습 로드맵을 구성한다 [45].
+- **My Project Relevance:** 소스에 관련 정보가 부족합니다.
+
+### Adjacent Topics
+
+- [[Core Web Vitals]]
+  - 확장 방향: 프론트엔드 아키텍처에서의 코드 스플리팅과 리소스 지연 로딩 최적화 기법이 실제 사용자 체감 속도(LCP, INP, CLS 등)에 미치는 영향을 측정하고 데이터 기반으로 모니터링하는 전략으로 확장 [17, 46].
+- [[Git Branching Workflow]]
+  - 확장 방향: 엄격하게 구조화된 대형 코드베이스를 여러 팀원과 함께 충돌 없이 개발하기 위한 깃 브랜칭 전략(GitHub Flow 적용 여부), Conventional Commits 작성법 및 CI/CD 품질 검증 파이프라인으로 확장 [47, 48].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Functional Components.md b/00_Raw/Functional Components.md
new file mode 100644
index 00000000..d4cdfc2e
--- /dev/null
+++ b/00_Raw/Functional Components.md	
@@ -0,0 +1,72 @@
+# [[Functional Components]]
+
+## 📌 Brief Summary
+Functional Components(함수형 컴포넌트)는 과거 클래스 기반 컴포넌트를 대체하여 현대 React 애플리케이션 개발의 표준으로 자리 잡은 핵심 UI 작성 단위입니다 [1, 2]. 자체적으로 상태(state)와 부수 효과(side effect)를 관리하기 위해 `useState`, `useEffect` 등의 React 훅(Hooks)과 결합하여 사용됩니다 [3-5]. 강력하고 유연한 기능성을 제공하지만, 자체적으로 Error Boundary(에러 경계) 역할을 할 수 없다는 명확한 구조적 제약도 존재합니다 [6, 7].
+
+## 📖 Core Content
+
+*   **훅(Hooks)을 통한 상태 및 로직 관리:** 
+    함수형 컴포넌트는 `useState`, `useReducer`, `useEffect` 등을 사용하여 상태 관리와 부수 효과를 처리합니다 [3-5]. 훅은 반드시 컴포넌트 내부의 최상단에서만 호출되어야 하며 루프나 조건문 내에서 사용되어서는 안 됩니다 [8].
+*   **레거시 코드베이스의 현대화 기준:** 
+    React 코드베이스를 리팩토링할 때 클래스 기반 컴포넌트를 함수형 컴포넌트와 훅으로 전환하는 것은 가장 효과적인 아키텍처 개선(solid win)으로 평가받습니다 [2].
+*   **소프트웨어 공학 원칙(SOLID & Clean Code)의 적용:** 
+    클래스에서 함수형으로 형태가 변했더라도 단일 책임 원칙(SRP) 등은 여전히 유효합니다 [1]. 컴포넌트가 300줄 이상 길어지거나 상태 관리, 데이터 페칭, UI 렌더링 책임을 동시에 가지게 된다면, 책임을 분리하여 더 작은 함수형 컴포넌트나 커스텀 훅으로 쪼개야 합니다 [1, 9, 10]. 이는 코드의 반복을 줄이는 DRY 원칙과 복잡성을 줄이는 KISS 원칙을 달성하는 데 필수적입니다 [11, 12].
+*   **컴포넌트의 참조(Reference) 동작 및 렌더링 주의점:**
+    함수형 컴포넌트 내부에서 JSX의 props로 인라인 익명 함수(`() => {...}`)를 직접 넘기는 것은 지양해야 합니다 [13, 14]. 함수형 컴포넌트는 렌더링될 때마다 내부의 인라인 함수 인스턴스를 새로 생성하므로, 자식 컴포넌트에 새로운 참조(Reference)가 전달되어 불필요한 리렌더링을 유발하기 때문입니다 [14, 15]. 
+
+## ⚖️ Trade-offs & Caveats
+
+*   **Error Boundary로써의 사용 불가 (제약 사항):**
+    함수형 컴포넌트의 가장 큰 제약 중 하나는 자체적으로 Error Boundary(에러 경계) 역할을 할 수 없다는 점입니다. 자식 컴포넌트의 에러를 잡기 위해 사용되는 `getDerivedStateFromError` 또는 `componentDidCatch` 생명주기 메서드를 사용할 수 없으므로, 에러 처리를 위해서는 여전히 클래스 컴포넌트를 구현하거나 `react-error-boundary`와 같은 외부 라이브러리 래퍼(Wrapper)를 사용해야 합니다 [6, 7].
+*   **메모리 누수와 클로저(Closure)로 인한 부작용:**
+    함수형 컴포넌트와 훅을 사용할 때 클로저 특성으로 인해 오래된 변수나 객체가 메모리에 유지되는 'Stale Closure' 문제가 발생할 수 있습니다 [16, 17]. 특히 `useEffect` 내부에서 이벤트 리스너를 구독(subscribe)하고 언마운트 시 클린업(cleanup) 함수로 제거하지 않으면 심각한 메모리 누수로 이어집니다 [18-20].
+*   **과도한 훅 사용으로 인한 복잡성(Trade-off):**
+    무분별한 `useEffect` 사용은 애플리케이션의 잦은 리렌더링을 유발하여 퍼포먼스를 크게 떨어뜨릴 수 있습니다 [21]. 또한 성능을 높이겠다고 `useCallback`과 `useMemo`를 모든 곳에 남용하는 것은 오히려 메모이제이션 비교에 드는 오버헤드가 더 커질 수 있으므로, Chrome DevTools 및 React Profiler를 통한 성능 측정이 선행된 후 꼭 필요한 곳에만 적용해야 합니다 [22-24].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [관계 유형 A: 아키텍처 및 핵심 기술]
+- `[[React Hooks]]`
+  - 연결 이유: 함수형 컴포넌트가 단순한 UI 렌더링 함수를 넘어 라이프사이클 및 상태 관리를 할 수 있게 만들어주는 핵심 메커니즘이기 때문입니다 [3].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: `useState`와 `useEffect`를 통한 상태 및 부수 효과 관리, 의존성 배열(dependency array)의 올바른 사용법 및 렌더링 사이클 [3, 4, 21].
+
+- `[[SOLID Principles]]`
+  - 연결 이유: 함수형 컴포넌트를 설계하고 리팩토링할 때 코드를 모듈화하는 기준점(예: 단일 책임 원칙)을 제공합니다 [1, 25].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 거대한 함수형 컴포넌트를 비즈니스 로직(Custom Hooks)과 순수 UI 컴포넌트로 분리하는 클린 코드(Clean Code) 패턴 [1, 10, 11].
+
+#### [관계 유형 B: 최적화 및 활용 도구]
+- `[[Memoization (React.memo, useMemo, useCallback)]]`
+  - 연결 이유: 함수형 컴포넌트는 상위 컴포넌트 렌더링 시 기본적으로 함께 재실행되므로, 이를 제어하기 위한 수동 최적화 기법이 필수적으로 수반됩니다 [26, 27].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 함수와 객체의 참조 안정성(Reference Equality), 불필요한 리렌더링 차단 원리 및 잘못된 사용으로 인한 오버헤드 위험성 [14, 24, 28].
+
+- `[[Error Boundaries]]`
+  - 연결 이유: 함수형 컴포넌트의 명확한 기술적 한계를 나타내는 기능으로, 렌더링 중 발생하는 런타임 오류를 우회 처리하기 위한 기법입니다 [7, 29].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 함수형 컴포넌트 트리를 붕괴시키지 않고, 오류 발생 시 부분적으로 폴백(fallback) UI를 제공하는 애플리케이션 안정성 확보 방법 [30, 31].
+
+### Deeper Research Questions
+
+- 함수형 컴포넌트 도입으로 사라진 클래스 컴포넌트의 라이프사이클 메서드(예: `componentDidMount`, `componentDidUpdate`)는 `useEffect` 내부에서 내부적으로 어떻게 대체되고 스케줄링되는가?
+- 함수형 컴포넌트에서 클로저(Closure) 동작으로 인해 발생하는 메모리 누수와 'Stale Closure' 문제를 Chrome DevTools (Memory Profiler)를 사용해 어떻게 추적하고 해결할 수 있는가?
+- 자동 메모이제이션을 지원하는 `React Compiler`의 도입이 안정화될 경우, 개발자가 함수형 컴포넌트 코드를 작성하는 패턴(기존의 `useMemo`, `useCallback` 의존성 탈피 등)에 어떤 근본적인 변화가 일어나는가?
+- 왜 React 아키텍처 상 Error Boundary 기능은 함수형 컴포넌트와 훅으로 원형 그대로 구현될 수 없으며, 클래스 컴포넌트의 생명주기에만 종속되도록 설계되었는가?
+- 함수형 컴포넌트에 의존성 역전 원칙(DIP)과 단일 책임 원칙(SRP)을 적용하여 UI, 서버 상태(TanStack Query), 전역 상태(Zustand)를 완벽히 격리하는 가장 모범적인 코드 구조는 무엇인가?
+
+### Practical Application Contexts
+
+- **Implementation:** 클래스 컴포넌트를 배제하고 `useState`와 `useEffect`를 사용해 최신 리액트 표준에 맞춰 화면 단위와 UI 요소를 구현합니다 [2, 3].
+- **System Design:** 로직과 뷰의 강결합을 피하기 위해, 데이터 페칭과 비즈니스 로직은 별도의 Custom Hook이나 서비스 계층으로 분리하고 함수형 컴포넌트는 시각적 렌더링(Presentation) 기능만 수행하도록 시스템을 설계합니다 [9, 32].
+- **Operation / Maintenance:** 함수형 컴포넌트 내부에서 익명 함수 및 인라인 객체가 남용되지 않도록 ESLint(`eslint-plugin-react-hooks`) 및 `why-did-you-render` 같은 도구를 CI/CD 파이프라인에 통합해 불필요한 렌더링 누수를 막습니다 [33-35].
+- **Learning Path:** (기초) JSX와 함수형 컴포넌트의 이해 ➔ (중급) React Hooks 기반 상태/라이프사이클 제어 및 커스텀 훅 분리 ➔ (고급) Memoization 기법, Closure 함정 극복 및 React Compiler 동작 원리 파악 [3, 36-38].
+- **My Project Relevance:** 현재 레거시 코드로 이루어진 React 프로젝트를 리팩토링해야 할 경우, 클래스 컴포넌트를 모두 함수형 컴포넌트로 변환(Migration)하고 불필요한 로직을 커스텀 훅으로 들어내어 가독성 및 성능을 최적화하는 첫 번째 마일스톤으로 활용할 수 있습니다 [2, 9, 39].
+
+### Adjacent Topics
+
+- `[[React Compiler]]`
+  - 확장 방향: 개발자가 함수형 컴포넌트에서 수동으로 처리하던 `useMemo`와 `useCallback`의 불편함을 빌드 타임에 자동으로 분석해 최적화(Auto-memoization)해주는 미래의 React 성능 개선 도구의 원리 이해 [37, 40].
+- `[[Feature-Sliced Design (FSD)]]`
+  - 확장 방향: 수백 개의 함수형 컴포넌트와 커스텀 훅들이 얽힌 거대한 코드베이스를 도메인(Domain)과 기능(Feature) 단위의 계층 구조로 명확하게 모듈화하는 스케일링 방법론 탐구 [41-43].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Functional Programming in React.md b/00_Raw/Functional Programming in React.md
new file mode 100644
index 00000000..14f6dac9
--- /dev/null
+++ b/00_Raw/Functional Programming in React.md	
@@ -0,0 +1,65 @@
+# [[Functional Programming in React]]
+
+## 📌 Brief Summary
+React에서의 함수형 프로그래밍은 사용자 인터페이스(UI)를 상태(State)와 속성(Props)의 순수 함수(Pure function)로 표현하는 아키텍처 패러다임입니다 [1]. 클래스 기반 컴포넌트에서 벗어나 함수형 컴포넌트와 Hooks를 활용하여 상태 및 부작용(Side effects)을 관리하며, 이를 통해 코드의 예측 가능성과 테스트 용이성을 극대화합니다 [2, 3]. 불변성(Immutability)을 유지하고 렌더링 중 부작용을 배제하는 것이 이 패러다임이 정상적으로 동작하기 위한 핵심 규칙입니다 [4].
+
+## 📖 Core Content
+*   **순수 함수로서의 UI (UI as Pure Functions):** 
+    React의 JSX와 선언적 렌더링 구조는 UI를 컴포넌트 트리의 관점에서 생각하도록 권장하며, 각 컴포넌트는 상태와 props를 받아 UI를 반환하는 순수 함수 역할을 수행합니다 [1]. 이는 코드의 예측 가능성을 높이고 테스트를 쉽게 만듭니다 [1].
+*   **함수형 컴포넌트와 Hooks 패러다임:** 
+    React 생태계는 과거의 클래스 기반 설계에서 함수형 프로그래밍 구조로 전환되었습니다 [3]. 함수형 컴포넌트 내에서 상태(State)와 부작용을 제어하기 위해 React Hooks(`useState`, `useEffect` 등)가 도입되었으며, 이는 비즈니스 로직과 렌더링을 깔끔하게 분리하는 강력한 수단을 제공합니다 [2, 5]. 
+*   **불변성과 부작용 격리 (Immutability & Side-effect Isolation):** 
+    함수형 React의 기본 규칙은 렌더링 과정 중 데이터의 불변성을 유지하고 부작용을 배제하는 것입니다 [4]. 데이터 통신이나 구독과 같은 부작용은 `useEffect` 훅 내부로 명시적으로 격리하여, 렌더링 자체는 순수하게 유지해야 합니다 [6, 7].
+*   **고차 컴포넌트 (Higher-Order Components, HOC):** 
+    함수형 프로그래밍의 고차 함수 개념을 차용한 패턴으로, 하나의 컴포넌트를 인자로 받아 추가적인 기능을 부여한 새로운 컴포넌트를 반환하는 함수입니다 [8]. 이를 통해 컴포넌트 간의 로직을 함수 수준에서 재사용할 수 있습니다 [8].
+
+## ⚖️ Trade-offs & Caveats
+*   **렌더링 주기와 참조 안정성(Reference Stability) 문제:** 함수형 컴포넌트는 렌더링 시마다 함수 내부의 모든 변수와 함수를 새로 생성합니다 [9, 10]. JSX 내부에 익명 함수나 인라인 객체를 남용하면, 얕은 비교(Shallow comparison)를 수행하는 자식 컴포넌트(`React.memo` 등)에 매번 새로운 참조가 전달되어 불필요한 리렌더링을 유발하는 부작용이 있습니다 [11, 12].
+*   **오래된 클로저 (Stale Closures):** 함수형 패러다임에서 비동기 작업 등을 수행할 때, 함수가 과거의 렌더링 시점의 상태를 "기억"하는 클로저 특성으로 인해 최신 상태가 반영되지 않는 버그(Stale Closures)가 발생하기 쉽습니다 [13, 14].
+*   **최적화 도구의 남용 (Overhead of Memoization):** 불필요한 렌더링을 막기 위해 `useCallback`, `useMemo` 등을 무분별하게 사용하면, 의존성 배열을 비교하고 캐싱하는 비용이 컴포넌트를 단순히 다시 렌더링하는 비용보다 오히려 더 커져 성능을 저하시킬 수 있습니다 [12, 15].
+*   **부작용 정리 누락으로 인한 메모리 누수:** `useEffect` 내부에서 발생한 구독(Subscription)이나 이벤트 리스너 등을 반환(cleanup) 함수로 정리하지 않으면, 함수형 컴포넌트가 언마운트된 후에도 참조가 남아 애플리케이션의 성능을 저하시키는 심각한 메모리 누수를 초래합니다 [7, 16, 17].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [아키텍처/기반 기술]
+- [[Pure Function]]
+  - 연결 이유: React의 렌더링 철학은 UI를 상태와 Props의 순수 함수로 취급하는 것에서 출발합니다 [1].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 입력값이 동일하면 항상 동일한 UI를 렌더링해야 한다는 원칙과 React Compiler가 작동하기 위한 전제 조건 [1, 4].
+- [[Immutability]]
+  - 연결 이유: React가 컴포넌트의 변경 사항을 감지(Diffing)하고 렌더링 최적화를 수행하기 위한 필수 규칙입니다 [4, 18].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 상태를 직접 수정하지 않고 새로운 참조를 반환해야만 `React.memo`와 같은 최적화가 올바르게 작동하는 원리 [11, 18].
+
+#### [구현/활용 도구]
+- [[React Hooks]]
+  - 연결 이유: 순수 함수형 컴포넌트에 상태 유지와 부작용 처리 능력을 부여하는 핵심 구현체입니다 [2].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 의존성 배열(Dependency array)의 관리와 클로저(Closure)를 활용한 상태 캡처 메커니즘 [6, 19].
+- [[React Compiler]]
+  - 연결 이유: 함수형 컴포넌트가 React의 규칙(불변성, 부작용 없음)을 준수할 경우, 수동 메모이제이션 없이도 빌드 타임에 자동으로 코드를 최적화해 주는 도구입니다 [4, 20, 21].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 렌더링 결과물을 캐싱하여 수동으로 `useMemo`나 `useCallback`을 작성해야 하는 부담을 줄이는 방식 [22, 23].
+
+### Deeper Research Questions
+- React 컴파일러가 함수형 컴포넌트의 렌더링 부작용(side effects)과 불변성(immutability)을 어떤 방식의 정적 분석을 통해 검증하고 자동 메모이제이션을 수행하는가?
+- 함수형 컴포넌트의 비동기 작업 처리 시 빈번하게 발생하는 '오래된 클로저(Stale Closures)' 문제는 클래스 컴포넌트의 `this` 참조 방식과 비교하여 어떤 구조적 차이에서 비롯되는가?
+- React의 함수형 컴포넌트에서 참조 안정성(Reference Equality) 결여가 `React.memo`의 얕은 비교(Shallow comparison)에 미치는 구체적인 성능 저하 과정은 무엇인가?
+- 함수형 기반의 대규모 애플리케이션에서 Context API와 Zustand 같은 전역 상태 관리 도구는 리렌더링 통제(Selector 패턴 유무) 측면에서 어떤 성능적 아키텍처 차이를 보이는가?
+- 커스텀 훅(Custom Hooks)으로 비즈니스 로직을 추상화할 때 발생하는 DRY(Don't Repeat Yourself) 원칙과 KISS(Keep It Simple, Stupid) 원칙 간의 트레이드오프를 어떻게 조율해야 하는가?
+
+### Practical Application Contexts
+- **Implementation:** React 컴포넌트를 설계할 때 단일 책임 원칙(SRP)을 준수하여 300줄 이상의 거대한 함수를 작고 순수한 컴포넌트로 분리하고, 부작용은 `useEffect` 내부로 명시적으로 격리하여 구현해야 합니다 [3, 6, 24].
+- **System Design:** 로직과 UI 렌더링 관심사를 분리하기 위해, 재사용 가능한 상태 로직은 'Custom Hooks' 디렉토리(예: `useAuth`, `useFetch`)에 모으고 순수 UI는 'Components' 폴더로 구조화하는 설계를 적용합니다 [25, 26].
+- **Operation / Maintenance:** 함수형 컴포넌트 기반 애플리케이션 운영 시 메모리 누수가 의심되면, Chrome DevTools의 Memory 프로파일러를 사용하여 훅 정리(cleanup) 누락으로 인한 '분리된 DOM 노드(Detached DOM Nodes)'나 닫힌 클로저 참조를 추적하여 유지보수합니다 [7, 17, 27].
+- **Learning Path:** 우선 React Hooks의 기본 규칙과 함수 생명주기(클로저, 의존성 배열)를 숙지한 뒤, 메모이제이션(`useMemo`, `React.memo`)을 통한 렌더링 최적화 기법을 배우고, 이후 상태 관리 시스템(Zustand 등) 설계로 나아가는 경로가 권장됩니다 [2, 28, 29].
+- **My Project Relevance:** 오래된 클래스 컴포넌트 기반 레거시 코드를 기능형 컴포넌트와 커스텀 훅으로 리팩토링(Refactoring)하여 코드 가독성과 모듈성을 개선하고, 로직 중복을 제거(DRY)하는 실무 과정에 직결됩니다 [5, 26].
+
+### Adjacent Topics
+- [[React Hooks Pitfalls]]
+  - 확장 방향: 함수형 컴포넌트에서 의존성 배열 누락, 잘못된 상태 업데이트, 정리(cleanup) 누락 등 Hooks를 사용할 때 빈번하게 겪는 안티패턴과 방어적 프로그래밍 방법 탐구 [6, 7, 19].
+- [[React Performance Optimization]]
+  - 확장 방향: 함수형 아키텍처에서 빈번한 리렌더링을 막기 위한 지연 로딩(`React.lazy`), 가상화(Virtualization), 그리고 수동 메모이제이션의 한계 돌파 전략 연구 [30-32].
+- [[Feature-Sliced Design (FSD)]]
+  - 확장 방향: 단순히 기능적(Functional)으로 분리된 컴포넌트와 훅들을 애플리케이션의 비즈니스 도메인 관점에서 계층(Layers)과 슬라이스(Slices)로 규격화하여 확장 가능한 아키텍처로 조합하는 방법론 [33-35].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Git Flow.md b/00_Raw/Git Flow.md
new file mode 100644
index 00000000..e2fb0b11
--- /dev/null
+++ b/00_Raw/Git Flow.md	
@@ -0,0 +1,63 @@
+# [[Git Flow]]
+
+## 📌 Brief Summary
+Git Flow는 주로 정기적인 릴리스(scheduled releases) 일정이 있는 대규모 프로젝트에 유용한 소프트웨어 개발 브랜칭 전략입니다. 이 워크플로우는 코드를 안전하게 통합하고 배포하기 위해 `main` 브랜치 외에 `develop`, `release` 등 명확한 목적을 가진 여러 브랜치를 구조적으로 분리하여 사용합니다. 그러나 복잡도가 높기 때문에 소규모 팀이나 빠른 통합이 필요한 환경에서는 오버헤드가 발생할 수 있습니다.
+
+## 📖 Core Content
+*   **Git Flow의 핵심 구조:** Git Flow는 `main` 브랜치 외에 새로운 통합(integration) 브랜치인 `develop` 브랜치를 생성하여 사용합니다. 새로운 기능(Feature)을 개발할 때는 이 `develop` 브랜치를 기반으로 작업하며, 기능 개발이 완료되면 다시 `develop` 브랜치에 병합(Merge)합니다 [1].
+*   **릴리스 관리:** 배포 준비를 위해 별도의 `release` 브랜치를 추가로 사용합니다 [1, 2]. 이를 통해 대규모 프로젝트에서 정해진 일정에 따른 릴리스를 체계적으로 관리하고, 최종 테스트 및 배포 준비 과정을 다른 기능 개발과 격리할 수 있습니다 [1, 3].
+*   **다른 브랜칭 전략과의 비교 및 마이그레이션:** Git Flow는 GitHub Flow, GitLab Flow, Trunk-Based Development, Feature Branch Workflow 등과 함께 널리 쓰이는 주요 브랜칭 전략 중 하나입니다 [4]. 팀의 요구사항이 변함에 따라 다른 전략으로 마이그레이션이 가능합니다. 예를 들어 더 단순한 관리가 필요하면 릴리스 브랜치를 없애고 `develop`을 `main`에 통합하여 GitHub Flow로 넘어가거나, 반대로 체계적인 구조가 필요할 경우 `develop`과 `release` 브랜치를 추가하여 Git Flow로 전환할 수 있습니다 [1, 2].
+*   **모범 사례의 적용:** Git Flow를 사용할 때도 보편적인 Git 워크플로우 모범 사례(Best Practices)를 따라야 합니다. 의미 있는 짧은 브랜치명 사용, 티켓 ID(예: PROJ-123) 포함, Pull Request(PR)를 통한 코드 리뷰, 그리고 브랜치 병합 후 삭제 등을 철저히 지켜야 합니다 [5-8].
+
+## ⚖️ Trade-offs & Caveats
+*   **오버헤드와 복잡성:** Git Flow는 관리해야 할 브랜치의 종류가 많고 규칙이 엄격하여 프로세스 오버헤드를 발생시킵니다 [9, 10]. 2~5명 규모의 소규모 팀이나 초보자에게는 너무 무거운(heavy) 전략이며, 오히려 개발 속도를 늦출 수 있습니다 [3, 11, 12].
+*   **통합 속도 및 충돌 문제:** 여러 브랜치 계층(`feature` -> `develop` -> `release` -> `main`)을 거쳐야 하므로 코드 병합과 배포 속도가 Trunk-Based Development나 단순한 Feature Branch 워크플로우에 비해 느려집니다 [2, 3]. 수명이 긴 브랜치가 발생할 확률이 높아 큰 머지 충돌(Merge Conflict)을 겪을 위험이 있습니다 [10, 13].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [관계 유형 A (아키텍처/기반 전략)]
+- [[GitHub Flow]]
+  - 연결 이유: Git Flow보다 더 단순한 대안으로 자주 비교되며, Git Flow에서 릴리스 브랜치와 `develop` 브랜치를 제거하여 `main`으로 직접 병합하는 형태로 마이그레이션할 수 있습니다 [2].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 브랜칭 전략의 복잡도를 낮추고 배포 주기를 단축하여 보다 민첩한 개발을 수행하는 방법.
+- [[Trunk-Based Development]]
+  - 연결 이유: 강력한 CI와 짧은 수명의 브랜치를 활용하여 매우 빠른 통합을 추구하는 전략으로, 복잡하고 무거운 Git Flow와 극명하게 대비됩니다 [2, 3].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 브랜치 계층을 최소화하여 통합 충돌을 줄이고, 빠른 주기로 코드를 배포하는 방식.
+- [[Feature Branch Workflow]]
+  - 연결 이유: 모든 변경 사항을 `main`이 아닌 특정 기능(Feature)을 위한 전용 브랜치에서 작업하는 방식으로, Git Flow를 포함한 대부분의 브랜칭 전략의 기반이 되는 핵심 개념입니다 [5, 12, 14].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 논리적 단위로 코드를 격리하고 충돌을 방지하며 작업 내역을 명확히 하는 원리.
+
+#### [관계 유형 B (구현/거버넌스 도구)]
+- [[Pull Request (PR)]]
+  - 연결 이유: Git Flow의 복잡한 브랜치 환경(예: feature에서 develop으로 병합)에서 코드를 병합하기 전에 동료 리뷰를 거치게 하는 필수적인 품질 통제 관문입니다 [7, 15].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 팀 내 코드 품질 유지, 지식 공유 및 병합 전 결함 차단 메커니즘.
+- [[Conventional Commits]]
+  - 연결 이유: 수많은 브랜치와 커밋이 얽히는 Git Flow에서 커밋 메시지를 규격화(`feat:`, `fix:`, `chore:` 등)하여 기록을 명확히 하고 릴리스 관리를 용이하게 합니다 [15, 16].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 대규모 프로젝트에서 코드 변경 이력을 일관되게 추적하고 관리하는 규약.
+
+### Deeper Research Questions
+
+- Git Flow의 `develop` 브랜치와 `main` 브랜치를 장기간 분리하여 운영할 때 필연적으로 발생하는 머지 충돌(Merge Conflict)을 최소화하기 위한 구체적인 동기화 전략은 무엇인가?
+- 소규모 팀이 단일 브랜치 또는 단순 Feature Branch Workflow에서 Git Flow로 전환(Migration)해야 하는 가장 적절한 조직적, 비즈니스적 타이밍과 기준은 무엇인가?
+- Git Flow 환경에서 긴급한 운영 서버 버그 수정(Hotfix)이 발생했을 때, `main`과 `develop` 브랜치 양쪽에 안전하고 신속하게 반영하기 위한 절차는 어떻게 구성되는가?
+- Git Flow와 Trunk-Based Development의 브랜치 수명(Lifetime) 차이가 CI/CD 파이프라인의 구축 및 자동화 테스트 횟수에 구체적으로 어떤 영향을 미치는가?
+- 추적성을 위해 티켓 ID(예: JIRA)를 브랜치와 커밋에 사용할 때, 복잡한 릴리스 브랜치(Release Branch) 단계에서 여러 티켓의 변경 사항 누락을 방지하는 모범 관행은 무엇인가?
+
+### Practical Application Contexts
+
+- **Implementation:** 대규모 프로젝트에서 `main` 브랜치는 항상 안정적이고 배포 가능한 상태로 보호하며, 실질적인 개발 통합은 `develop` 브랜치를 생성하여 관리합니다 [1, 12]. 모든 커밋과 브랜치명에는 티켓 ID를 포함시켜 요구사항과의 추적성을 확보합니다 [7].
+- **System Design:** 예약된 릴리스 스케줄을 지원하는 소프트웨어 아키텍처에 적합하며, 배포 전에 `release` 브랜치를 통해 최종 QA와 버전 태깅(Tagging)을 수행할 수 있도록 파이프라인을 설계합니다 [1, 3, 7].
+- **Operation / Maintenance:** 브랜치 보호(Branch Protection), 리뷰어 필수 지정, CI 상태 체크 기능을 활용하여 `develop` 브랜치의 코드 품질을 보장하며, 머지 후에는 작업이 끝난 브랜치를 자동 삭제하여 리포지토리를 깔끔하게 유지합니다 [5, 13].
+- **Learning Path:** 처음부터 Git Flow를 도입하기보다는, 가벼운 Feature Branch Workflow 또는 GitHub Flow로 기본기를 다진 후, 릴리스 관리의 복잡성이 증가함에 따라 점진적으로 `develop`과 `release` 브랜치 개념을 학습하고 도입하는 것이 권장됩니다 [1-3].
+- **My Project Relevance:** 현재 진행 중인 프로젝트의 팀 규모와 배포 주기에 따라 채택 여부를 결정해야 합니다. 팀원이 3~5명인 소규모 환경이라면 오버헤드가 큰 Git Flow보다는 짧은 수명의 Feature 브랜치와 결합된 더 단순한 워크플로우가 유리합니다 [3, 10, 14].
+
+### Adjacent Topics
+
+- [[CI/CD (Continuous Integration/Continuous Deployment)]]
+  - 확장 방향: Git Flow의 여러 브랜치(`develop`, `release`, `main`) 환경에 맞춰 단계별로 자동화된 테스트 및 배포 파이프라인을 어떻게 다르게 구축하는지 탐구.
+- [[Agile Methodology]]
+  - 확장 방향: Git Flow의 릴리스 브랜치 운용이 애자일의 스프린트(Sprint) 주기 및 이슈 트래커(Issue Tracker)와 어떻게 통합되어 소프트웨어 릴리스 프로세스를 형성하는지 분석.
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Git Workflow for Frontend Teams.md b/00_Raw/Git Workflow for Frontend Teams.md
new file mode 100644
index 00000000..f51a735a
--- /dev/null
+++ b/00_Raw/Git Workflow for Frontend Teams.md	
@@ -0,0 +1,68 @@
+# [[Git Workflow for Frontend Teams]]
+
+## 📌 Brief Summary
+프론트엔드 팀을 위한 Git 워크플로우는 코드 변경 사항을 체계적으로 관리하여 충돌을 방지하고 협업을 촉진하며 안정적인 배포 환경을 유지하기 위한 구조화된 접근 방식이다 [1-3]. 주요 전략으로는 기능 브랜치(Feature-branch), 깃허브 플로우(GitHub Flow), 트렁크 기반(Trunk-based) 개발 등이 있으며, 이들은 짧은 수명의 브랜치, 명확한 명명 규칙 및 커밋 컨벤션, 동료 리뷰가 포함된 풀 리퀘스트(PR)를 공통으로 강조한다 [2, 4, 5]. 잘 구현된 워크플로우는 잠재적인 혼란을 예측 가능한 고품질 업데이트의 흐름으로 변환하는 핵심 역할을 한다 [2].
+
+## 📖 Core Content
+* **브랜칭 전략 (Branching Strategies)**: 2~5명 규모의 소규모 팀은 오버헤드가 큰 Git Flow 대신 심플한 기능 브랜치(Feature-branch) 워크플로우나 트렁크 기반 개발을 주로 채택한다 [6-8]. 이러한 워크플로우는 항상 배포 가능한 안정적인 `main` 브랜치를 기반으로 하며, `main`으로의 직접적인 커밋은 엄격히 제한된다 [9, 10].
+* **브랜치 관리 및 명명 규칙 (Branch Management & Naming)**: 브랜치는 수명이 짧아야 하고, 단일 논리적 변경에만 집중해야 하며, 병합 후에는 자동으로 삭제되어야 한다 [9, 11]. 브랜치 이름은 서술적이어야 하며, 변경 사항의 추적성을 높이기 위해 이슈/티켓 ID(예: `feature/PROJ-123-user-auth`, `bugfix/GH-456-login-fix`)를 포함하는 것이 권장된다 [12, 13].
+* **커밋 규칙 (Commits)**: 각 커밋은 하나의 논리적 변경 사항만 포함하는 원자적 커밋(Atomic Commits) 형태여야 한다 [14]. 가독성 높은 히스토리 유지와 릴리스 노트 자동화를 위해 `feat:`, `fix:`, `docs:`, `refactor:`, `chore:` 등을 사용하는 'Conventional Commits' 포맷을 따른다 [11, 15, 16].
+* **풀 리퀘스트 및 병합 (PR & Merging)**: 철저한 리뷰를 위해 PR은 가급적 작은 크기(예: 200줄 이하)로 유지해야 한다 [9]. 병합 전에는 최소 한 명의 동료 리뷰어 승인과 CI/CD 테스트 통과가 필수적으로 요구된다 [9, 10]. 깔끔한 `main` 브랜치 히스토리를 유지하기 위해 스쿼시 병합(Squash merge)이 널리 권장된다 [9, 17]. 또한, Storybook이나 Chromatic과 같은 도구를 사용하여 시각적 회귀(Visual regression) 검토를 PR 과정에 연동할 수 있다 [18].
+* **충돌 방지 (Conflict Prevention)**: 개발자는 대규모 병합 충돌이 누적되는 것을 막기 위해 `main` 브랜치의 최신 변경 사항을 자주 가져와(pull/rebase) 자신의 기능 브랜치를 동기화하고, 충돌을 점진적으로 해결해야 한다 [7, 17].
+
+## ⚖️ Trade-offs & Caveats
+* **트렁크 기반 vs Git Flow**: 트렁크 기반 개발은 빠른 피드백과 통합을 가능하게 하지만, 지속적인 통합(CI)을 완벽히 구축한 경험 많은 팀에게 적합하다 [8]. 반면, Git Flow는 정기적인 릴리스를 수행하는 대규모 프로젝트에 강력한 구조를 제공하지만, 소규모 팀이 도입하기에는 복잡성과 절차적 오버헤드가 커서 진행 속도를 늦추는 부작용(Trade-off)이 있다 [6, 8].
+* **브랜치 수명 (Branch Lifespan)**: 기능 브랜치가 분리되어 오래 유지될수록 병합 충돌의 위험이 기하급수적으로 커진다. 이를 막기 위해 짧은 수명의 브랜치를 유지하면 빈번한 PR 생성과 코드 동기화로 인한 문맥 전환(Context switching) 오버헤드가 발생하지만, 장기적으로 파괴적인 충돌과 리팩토링 비용을 예방하는 반대 급부가 있다 [7, 19].
+* **엄격한 규칙 vs 유연성**: 모든 브랜치와 커밋에 티켓 ID를 강제하고 Conventional Commits를 따르게 하면 개발자에게 규율을 요구하지만, 이를 간과할 경우 코드 변경의 맥락과 요구 사항의 추적성(Traceability)을 완전히 상실하게 되는 한계점이 존재한다 [20].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [아키텍처/기반 기술]
+- [[Trunk-Based Development]]
+  - 연결 이유: 무거운 Git Flow에 대비되는 경량화 전략의 대표적 사례이기 때문이다 [6, 8].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 메인 브랜치에 코드를 자주, 작게 밀어 넣음으로써 대규모 병합 충돌을 피하고 빠른 코드 통합을 이루는 원리.
+- [[Git Flow]]
+  - 연결 이유: 개발 브랜치, 릴리스 브랜치 등을 두는 전통적이고 복잡한 브랜칭 모델이기 때문이다 [6, 8, 21].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 단순한 워크플로우를 넘어 특정 스케줄과 버전에 따른 복잡한 배포 관리가 필요할 때 요구되는 구조적 접근.
+- [[GitHub Flow]]
+  - 연결 이유: 안정적인 메인 브랜치와 PR 기반의 기능 브랜치를 사용하는 대중적인 전략이기 때문이다 [5, 22].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 추가적인 통합 브랜치(develop 등) 없이 기능 브랜치에서 바로 테스트를 거쳐 `main`으로 병합되는 지속적 배포의 흐름.
+
+#### [구현/활용 도구]
+- [[Conventional Commits]]
+  - 연결 이유: 프로젝트의 커밋 이력을 직관적으로 파악할 수 있게 돕는 표준화된 포맷이기 때문이다 [11, 15].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 일관된 커밋 형식이 어떻게 릴리스 노트 자동화 및 코드 히스토리 스캐닝으로 이어지는지에 대한 메커니즘.
+- [[Pull Requests (PR)]]
+  - 연결 이유: 코드가 메인 브랜치로 통합되기 전 검증을 거치는 핵심 관문이기 때문이다 [14, 15].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 팀 내 코드 리뷰, 자동화된 테스트(CI) 확인 등 품질 게이트(Quality Gate)로서의 작동 방식.
+- [[Visual Regression Testing]]
+  - 연결 이유: 프론트엔드 환경의 특성상 PR 단계에서 UI 시각적 검증 도구 연동이 중요하게 다뤄지기 때문이다 [18].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: Chromatic과 같은 도구를 통해 CSS, 레이아웃 변경이 예기치 않게 다른 컴포넌트에 미치는 영향을 PR 단계에서 감지하는 방법.
+
+### Deeper Research Questions
+
+- 기능 브랜치(Feature-branch) 워크플로우에서 트렁크 기반(Trunk-based) 개발로 원활하게 마이그레이션하기 위해 팀은 어떤 단계적 절차를 거쳐야 하는가?
+- 짧은 수명의 기능 브랜치를 안전하게 자동 병합(Auto-merge)하도록 지원하려면 CI/CD 파이프라인과 테스트 자동화를 어떻게 구성해야 하는가?
+- 스토리북 및 Chromatic을 활용한 시각적 회귀 테스트(Visual Regression Testing) 도구를 PR 리뷰 주기에 병목 현상 없이 최적으로 통합하는 방법은 무엇인가?
+- 여러 커밋이 하나로 압축되는 스쿼시 병합(Squash Merge)을 사용할 때, 특정 세부 변경 사항을 감사(Audit)하거나 추적하는 데 발생하는 구조적 한계점은 무엇인가?
+- 메인 브랜치를 항상 배포 가능한 상태로 유지하기 위해 기능 플래그(Feature Flags)는 기능 브랜치 워크플로우와 어떻게 상호 작용하는가?
+
+### Practical Application Contexts
+
+- **Implementation:** 새로운 기능이나 버그 수정을 진행할 때 티켓 ID가 포함된 짧은 수명의 브랜치를 생성하고, 의미 있는 단위로 원자적 커밋을 수행하며, 잦은 `pull`을 통해 `main`과의 충돌을 선제적으로 예방한다.
+- **System Design:** GitHub, GitLab 등의 저장소 설정에서 `main` 브랜치 보호 규칙(Branch protection)을 설정하여 직접 커밋을 차단하고, 병합 전 최소 1명의 코드 리뷰와 CI 통과를 강제하는 구조를 설계한다.
+- **Operation / Maintenance:** PR 병합(Merge) 시 자동으로 기능 브랜치가 삭제되도록 시스템을 구성하고, 스쿼시 병합(Squash merge)을 통해 프로젝트의 커밋 트리를 간결하게 유지한다.
+- **Learning Path:** 소규모 프로젝트나 프론트엔드 입문자는 복잡한 Git Flow 대신, `main` 브랜치와 단일 `feature` 브랜치를 활용하는 단순한 기능 브랜치 워크플로우부터 학습하는 것이 권장된다.
+- **My Project Relevance:** 팀 내 코드 리뷰 에티켓을 정립하고, JIRA 등 이슈 트래커의 티켓 번호를 커밋 메시지와 연동하며, Storybook을 PR 검토 과정에 연동하여 UI 버그를 사전에 차단하는 규칙을 수립하는 데 직접적으로 적용할 수 있다.
+
+### Adjacent Topics
+
+- [[Continuous Integration / Continuous Deployment (CI/CD)]]
+  - 확장 방향: PR 생성, 커밋 푸시와 같은 Git 이벤트가 어떻게 빌드, 테스트, 배포 파이프라인을 자동으로 트리거하고 개발 피드백 루프를 단축하는지 조사.
+- [[Storybook & Component-Driven Development]]
+  - 확장 방향: 격리된 컴포넌트 환경이 어떻게 버전 관리 시스템(Git)과 연동되어 PR 리뷰어에게 시각적 컨텍스트를 제공하는지에 대한 구체적 사례 탐구.
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/GitHub Flow in Small Teams.md b/00_Raw/GitHub Flow in Small Teams.md
new file mode 100644
index 00000000..9958d9ca
--- /dev/null
+++ b/00_Raw/GitHub Flow in Small Teams.md	
@@ -0,0 +1,61 @@
+# [[GitHub Flow in Small Teams]]
+
+## 📌 Brief Summary
+GitHub Flow in Small Teams(소규모 팀을 위한 GitHub Flow)는 무거운 프로세스 오버헤드 없이 코드 충돌을 방지하고 빠른 피드백을 촉진하는 경량화된 브랜칭 전략이다 [1-3]. 이 워크플로우는 항상 배포 가능한 상태를 유지하는 `main` 브랜치와 특정 기능 개발이나 버그 수정을 위해 생성되는 수명이 짧은 피처 브랜치(Feature Branch)를 중심으로 운영된다 [2, 4]. 개발된 코드는 반드시 Pull Request(PR)와 최소 1명 이상의 동료 리뷰(Peer Review)를 거친 후 스쿼시(Squash) 등의 방식으로 병합되어 코드베이스의 안정성과 깔끔한 히스토리를 보장한다 [5-7].
+
+## 📖 Core Content
+*   **메인 브랜치 보호 (Main Branch Protection)**: `main` (또는 `master`) 브랜치는 항상 안정적이고 즉시 배포 가능한 상태를 유지해야 하며, 이 브랜치로의 직접적인 푸시(Push)나 커밋은 금지된다 [2, 4-6]. 이를 보장하기 위해 GitHub 설정에서 `main` 브랜치 보호 규칙을 활성화하여, 병합 전 필수 리뷰와 최신 상태 유지를 강제해야 한다 [5].
+*   **단기 피처 브랜치 (Short-lived Feature Branches)**: 새로운 작업, 기능 추가, 또는 버그 수정 시 무조건 `main`에서 파생된 개별 피처 브랜치를 생성한다 [4, 6, 8]. 브랜치 이름은 `feature/`, `bugfix/`, `chore/` 등의 명확한 접두사와 짧은 설명, 그리고 이슈 추적을 위한 티켓 ID(예: `feature/PROJ-123-login`)를 결합하여 작성한다 [9-11].
+*   **원자적 커밋과 규격화 (Atomic & Conventional Commits)**: 커밋은 자주 이루어져야 하며, 하나의 커밋에는 단 하나의 논리적 변경 사항만 담아야 한다 [5, 8, 9]. `feat:`, `fix:`, `docs:` 등을 사용하는 Conventional Commits 형식을 적용해 변경 내용과 그 이유를 명확하게 기록하는 것이 권장된다 [9, 12].
+*   **Pull Request (PR)와 동료 리뷰 (Peer Review)**: 기능 구현이 완료되면 `main`을 향해 PR을 생성한다 [7, 9]. PR의 크기는 가급적 작게(예: 200줄 이하) 유지하여 리뷰 속도와 질을 높인다 [5]. 병합을 위해서는 팀원 중 최소 1명 이상의 리뷰 및 승인이 필수적이며, 자동화된 CI 테스트를 모두 통과해야 한다 [5, 7, 9].
+*   **동기화와 충돌 방지 (Syncing & Conflict Prevention)**: 대규모 병합 충돌을 피하기 위해 개발자는 작업 시작 전 항상 `main`의 최신 코드를 가져오고(Pull), 작업 중인 피처 브랜치에 자주 `rebase` 또는 병합하여 동기화된 상태를 유지해야 한다 [3, 7].
+*   **병합 및 정리 (Merge and Cleanup)**: 병합 시에는 스쿼시 병합(Squash merge)을 사용하여 `main`의 커밋 히스토리를 한 줄로 깔끔하게 유지하는 전략이 선호된다 [5, 7, 13]. 병합이 완료된 피처 브랜치는 리포지토리를 정돈하기 위해 자동으로 삭제되도록 설정한다 [5, 8].
+
+## ⚖️ Trade-offs & Caveats
+이 전략은 거대한 Git Flow 방식이 가지는 복잡성을 제거하고 협업의 속도와 유연성을 크게 높인다는 장점이 있다 [3, 14]. 하지만 피처 브랜치가 장기화(Long-lived)될 경우 나중에 병합할 때 극심한 코드 충돌을 유발할 수 있으므로, 브랜치의 수명을 며칠 이내로 짧게 유지하는 규율이 필수적이다 [15]. 또한, 빠른 속도에 치중하여 코드 리뷰를 건너뛰거나 테스트가 깨진 코드를 병합하는 등의 안티 패턴을 주의해야 한다 [15, 16]. 작은 팀에서는 매우 효율적이지만 정기적인 릴리스 일정이 엄격하거나 팀 규모가 커질 경우 관리에 한계가 올 수 있으며 [14], 매우 사소하고 작은 수정 사항의 경우 매번 PR을 거치는 것이 과도한 오버헤드로 느껴질 여지도 있다 [3].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [아키텍처/기반 기술]
+- [[Short-Lived Feature Branches]]
+  - 연결 이유: GitHub Flow에서 작업을 격리하는 핵심 단위이다 [2, 4].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 브랜치가 오래 유지될 때 발생하는 통합의 고통을 피하고, 작은 단위의 기능 개발과 빠른 배포 사이클을 달성하는 원리를 이해할 수 있다.
+
+#### [구현/활용 도구]
+- [[Pull Request (PR)]]
+  - 연결 이유: 코드가 `main`으로 병합되기 전 거쳐야 하는 필수 관문이자 소통의 장이다 [5, 8].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 소규모 팀에서 동료 리뷰(Peer Review)와 CI(지속적 통합) 자동화를 결합하여 코드 품질을 방어하는 메커니즘을 파악할 수 있다.
+- [[Conventional Commits]]
+  - 연결 이유: 커밋 메시지를 명확히 규격화하여 PR 리뷰와 코드 관리를 돕는 관례이다 [9, 12].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: `feat:`, `fix:` 등의 접두사를 통해 코드 변경의 의도를 명확히 소통하고, 나아가 자동화된 릴리스 노트 생성의 기반을 마련하는 방법을 배울 수 있다.
+- [[Squash Merge]]
+  - 연결 이유: PR을 `main`에 병합할 때 선호되는 전략이다 [5, 7, 13].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 피처 브랜치에서 발생한 여러 자잘한 커밋들을 하나의 의미 있는 커밋으로 압축하여 `main` 브랜치의 히스토리를 깨끗하게 유지하는 방법을 알 수 있다.
+- [[Ticket ID Traceability]]
+  - 연결 이유: 브랜치 이름과 커밋에 이슈 트래커(JIRA, GitHub Issues 등)의 ID를 포함시키는 모범 사례이다 [17, 18].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 코드 변경 사항이 어떤 비즈니스 요구사항이나 버그 리포트와 연결되어 있는지 비즈니스적 문맥(Context)을 쉽게 추적하는 원리를 이해할 수 있다.
+
+### Deeper Research Questions
+- 소규모 팀(2~5명)이 중대형 팀(10명 이상)으로 스케일업할 때, GitHub Flow의 어떤 지점에서 병목(예: 리뷰 적체, 충돌 빈도 증가)이 발생하며 이를 어떻게 극복해야 하는가?
+- Pull Request의 크기를 리뷰가 용이한 200줄 이하로 유지하기 위해, 개발 초기 단계에서 작업을 어떻게 분할(Task Breakdown)해야 효과적인가?
+- CI/CD 파이프라인과 GitHub Flow를 연동할 때, `main` 브랜치의 '항상 배포 가능한 상태(Always Deployable)'를 기술적으로 완벽히 보장하기 위해 어떤 테스트 및 자동화 전략이 필요한가?
+- 장기 실행 브랜치(Long-running branches)를 방지하기 위한 대안으로 기능 플래그(Feature Flags)를 도입할 경우, 기존 GitHub Flow 워크플로우를 어떻게 변경해야 하는가?
+- 리뷰 인력이 부족한 소규모 팀에서 동료 리뷰의 병목을 줄이고 빠른 피드백 루프를 유지하기 위해 도입할 수 있는 문화적 또는 도구적 해결책은 무엇인가?
+
+### Practical Application Contexts
+- **Implementation:** 3~5인 규모의 프로젝트 초기 세팅 시, 리포지토리 설정에서 `main` 브랜치 보호 옵션을 켜고, 직접 푸시를 제한하며, 최소 1명의 Approve와 CI 통과를 강제하는 룰을 적용하여 구축할 수 있다 [5, 7].
+- **System Design:** GitHub Actions 등의 CI 환경을 구성하여 PR이 열렸을 때 자동으로 린팅, 포맷팅, 유닛 테스트를 실행해 리뷰어의 부담을 덜어주도록 시스템을 설계한다 [19, 20].
+- **Operation / Maintenance:** PR 병합이 완료된 브랜치를 GitHub의 'Auto-delete merged branches' 기능을 통해 자동으로 삭제하여 불필요한 브랜치가 쌓이는 것을 방지하고 리포지토리를 청결하게 유지한다 [5, 8].
+- **Learning Path:** Git 기초 (브랜치 생성, 커밋) -> GitHub Flow 사이클 이해 (브랜치 파생 -> 원자적 커밋 -> PR -> 리뷰 -> 병합) -> 팀 내 명명 규칙 및 Conventional Commits 숙달 -> CI/CD 자동화 연동 순으로 학습을 진행한다.
+- **My Project Relevance:** 현재 참여 중인 프론트엔드/백엔드 협업 프로젝트에서 코드 통합 시 발생하는 충돌을 최소화하고, 서로의 코드를 안전하게 리뷰하며 안정적인 프로덕션 버전을 유지하는 핵심 프로세스로 즉시 도입할 수 있다 [14, 20].
+
+### Adjacent Topics
+- [[Git Flow]]
+  - 확장 방향: 정기적이고 계획적인 릴리스 일정이 존재하거나, 프로젝트 규모가 커서 `develop` 및 `release` 브랜치 등 더 엄격하고 세분화된 브랜칭 모델이 필요할 때 적용할 수 있는 대안 전략 비교 [14, 21].
+- [[Trunk-Based Development]]
+  - 확장 방향: CI/CD 성숙도가 높고 기능 플래그(Feature Flag)를 적극 사용하는 팀에서, 피처 브랜치의 수명을 극단적으로 줄이거나 아예 없이 메인라인에 하루에도 여러 번 병합하는 가장 빠른 통합 방식 탐색 [14, 22].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Incremental Migration.md b/00_Raw/Incremental Migration.md
new file mode 100644
index 00000000..3dc8ce3c
--- /dev/null
+++ b/00_Raw/Incremental Migration.md	
@@ -0,0 +1,53 @@
+# [[Incremental Migration]]
+
+## 📌 Brief 시 Summary
+**Incremental Migration(점진적 마이그레이션)**은 오래된 기술이나 아키텍처에서 새로운 기술로 전환할 때, 전체 시스템을 한 번에 재작성(complete rewrite)하는 대신 단계적으로 이동하는 전략을 의미합니다 [1]. 한 번에 모든 것을 변경하는 위험을 최소화하고, 아키텍처를 현대화하는 동안에도 기능 개발을 지속할 수 있게 해주는 **"재작성(rewrite)이 아닌 리팩토링(refactor)"** 철학에 기반합니다 [1]. 대표적인 예로, Context API에서 Zustand로 상태 관리를 전환할 때 알림과 같은 단순한 유틸리티부터 시작하여 결제 흐름과 같은 복잡한 도메인으로 점진적으로 영역을 넓혀가는 방식이 있습니다 [1].
+
+## 📖 Core Content
+*   **전면 재작성의 위험성 회피:** 기존 기술에서 새로운 기술로 전환할 때, 애플리케이션 전체를 한 번에 갈아엎는 전면 재작성(complete rewrite)은 너무 높은 위험을 수반합니다. 점진적 마이그레이션은 이 리스크를 우회하는 권장 접근법입니다 [1].
+*   **단계적 전환 (스토어 단위 이동):** 한 번에 하나의 스토어(store)씩 이동하는 방식이 효과적입니다 [1]. 알림(notifications)과 같은 상대적으로 단순하고 독립적인 유틸리티성 상태부터 시작하여, 점진적으로 장바구니나 체크아웃 흐름(checkout flow) 같은 복잡한 핵심 도메인으로 전환을 진행합니다 [1].
+*   **기능 개발과 아키텍처 현대화의 병행:** 이 접근법의 핵심적인 이점은 리팩토링 철학을 기반으로 하기 때문에, 시스템 구조를 현대화하는 중에도 비즈니스 요구사항에 맞춘 새로운 기능 개발을 중단 없이 계속할 수 있다는 점입니다 [1].
+*   **커스텀 훅(Custom Hook)을 활용한 리팩토링 단위화:** 모던 React 환경에서 리팩토링의 주요 단위는 커스텀 훅입니다 [2]. 거대한 컴포넌트 내부에서 로직을 추출해 훅으로 분리함으로써 모듈성과 테스트 가능성을 높이며, 이를 통해 점진적인 구조 개선 및 마이그레이션을 안전하게 수행할 수 있습니다 [2].
+
+## ⚖️ Trade-offs & Caveats
+소스 내에서 점진적 마이그레이션 자체의 심각한 부작용을 명시하고 있지는 않으나, 전환을 시도하는 기술과 조직 상황에 따라 마이그레이션 경로(Migration Paths)별 난이도와 한계가 존재합니다 [3].
+*   **기술 스택별 전환 난이도의 차이:** Context API에서 Zustand로의 전환은 비교적 쉽다(Easy)고 평가되지만, Zustand에서 Redux로의 점진적 전환은 고통스러울 수 있으며(Painful), Redux에서 Zustand로 전환하는 것은 가능하지만 위험(Possible but risky)이 따릅니다 [3].
+*   **기술 변경 시점의 모호함:** 규모 확장 단계(Scaleup, 50-500명)의 기업에서는 Zustand 같은 도구를 사용하다가 한계에 부딪힐 때 Redux로의 마이그레이션을 계획해야 하는데 [4], 이처럼 언제 점진적 마이그레이션을 결단하고 시작해야 하는지에 대한 구조적 고민과 전환 부하가 발생할 수 있습니다. 
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [관계 유형 A: 아키텍처/기반 기술]
+- [[Context API]]
+  - 연결 이유: 점진적 마이그레이션의 주요 출발점(레거시 기술) 사례로 소스에서 언급되었습니다 [1].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 마이그레이션 이전의 레거시 상태 관리가 어떤 문제를 겪는지 파악하고, 왜 단순한 도메인부터 전환을 시작해야 하는지에 대한 당위성을 이해할 수 있습니다.
+- [[Zustand]] / [[Redux]]
+  - 연결 이유: 마이그레이션의 목적지 또는 전환 경로에 해당하는 상태 관리 기술들입니다 [1, 3, 4].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 각 기술 간의 전환이 쉬운지(Easy), 고통스러운지(Painful) 파악하여 조직 규모에 맞는 목표 아키텍처를 어떻게 설정하고 이동할 것인지 판단할 수 있습니다.
+
+#### [관계 유형 B: 구현/리팩토링 도구]
+- [[Custom Hooks]]
+  - 연결 이유: 모던 React에서 구조를 점진적으로 변경할 때 사용하는 '리팩토링의 핵심 단위(primary unit)'입니다 [2].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 거대한 컴포넌트의 비즈니스 로직을 UI와 어떻게 분리하여 모듈성과 테스트 용이성을 확보하는지 실무적인 구현 관점에서 이해할 수 있습니다.
+
+### Deeper Research Questions
+- 기존 상태 관리(예: Context API)와 신규 상태 관리(예: Zustand)가 공존하는 점진적 마이그레이션 과정에서, 두 상태 간의 동기화나 의존성은 어떻게 처리해야 안전한가?
+- Zustand에서 Redux로의 마이그레이션이 특히 "고통스럽다(Painful)"고 평가되는 아키텍처적, 구현적 차이점은 무엇인가?
+- 마이그레이션과 신규 기능 개발을 병행할 때 발생할 수 있는 브랜치(Branch) 충돌이나 통합 문제를 해결하기 위한 Git Workflow는 어떻게 구성되어야 하는가?
+- 대규모 애플리케이션에서 커스텀 훅 단위로 로직을 분리하는 리팩토링을 진행할 때 성능 저하(오버헤드)를 유발하지 않는 최적화 방법은 무엇인가?
+- 시스템의 일관성을 유지하기 위해, 한 기술에서 다른 기술로의 '점진적 마이그레이션'이 최종 완료되었다고 판단하는 기준(Definition of Done)은 어떻게 정의해야 하는가?
+
+### Practical Application Contexts
+- **Implementation:** React 코드베이스에서 새로운 상태 관리 라이브러리를 도입할 때, 전체를 교체하지 않고 에러 알림 등 아주 독립적인 단위 기능부터 새로운 스토어에 연결해 나가는 방식으로 구현을 진행합니다 [1].
+- **System Design:** 소프트웨어를 현대화할 때, 빅뱅(Big Bang) 방식이 아니라 기존 서비스가 지속적으로 운영 및 확장되면서 레거시와 신규 아키텍처가 공존할 수 있는 설계 원칙을 수립합니다 [1].
+- **Operation / Maintenance:** 기능 개발 부서와 아키텍처 개선 부서가 분리되지 않고, 유지보수 일정 내에서 기능 배포와 기술 부채(Technical Debt) 감소를 동시에 이뤄내도록 운영합니다 [1].
+- **Learning Path:** 큰 컴포넌트를 분해하여 Custom Hook으로 독립시키는 연습을 통해, 향후 코드 마이그레이션에 필요한 모듈화 역량을 학습합니다 [2].
+- **My Project Relevance:** 현재 진행 중인 프로젝트에서 구형 라이브러리(또는 패턴)를 최신 기술로 업그레이드해야 하는 태스크가 주어졌을 때, 비즈니스 영향을 최소화하는 점진적 적용 로드맵을 작성하는 데 활용할 수 있습니다.
+
+### Adjacent Topics
+- [[Technical Debt Management (기술 부채 관리)]]
+  - 확장 방향: 점진적 마이그레이션은 결과적으로 기술 부채를 통제하고 해결하기 위한 여러 전략 중 하나이므로, 시스템이 노후화됨에 따라 기술 부채를 어떻게 측정, 관리, 상환하는지에 대한 넓은 관점의 엔지니어링 전략으로 학습을 확장할 수 있습니다 [1].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/JSON-RPC 2.0.md b/00_Raw/JSON-RPC 2.0.md
new file mode 100644
index 00000000..83c8ea59
--- /dev/null
+++ b/00_Raw/JSON-RPC 2.0.md	
@@ -0,0 +1,56 @@
+# [[JSON-RPC 2.0]]
+
+## 📌 Brief Summary
+JSON-RPC 2.0은 AI 에이전트 하네스 환경에서 모델(클라이언트)과 외부 도구 및 리소스(서버) 간의 통신을 표준화하는 기반 메시징 교환 프로토콜입니다. 주로 MCP(Model Context Protocol) 및 ACP(Agent Client Protocol)와 같은 에이전트 통신 표준의 기본 데이터 계층을 구성하여 메시지의 구조와 의미(Semantics)를 정의합니다. 요청(Request)과 응답(Response)을 고유 ID로 연관 짓고, 응답을 기대하지 않는 단방향 알림(Notification) 전송을 지원하여 에이전트와 외부 시스템 간의 결정론적 상호작용을 가능하게 합니다.
+
+## 📖 Core Content
+* **데이터 계층의 메시지 구조화:** JSON-RPC 2.0은 에이전트 하네스와 외부 도구 간의 통신을 위한 데이터 계층(Data layer) 프로토콜로 기능합니다. 클라이언트와 서버는 JSON-RPC 2.0 형식을 사용하여 서로 요청을 보내고 적절히 응답합니다. 특히 고유한 `id` 필드를 사용하여 요청과 응답 간의 상호 연관성(correlation)을 보장하며, 통신의 타입 안정성(Type safety)과 명확성을 확보합니다 [1-4].
+* **알림(Notification) 시맨틱 지원:** 응답을 요구하지 않는 단방향 상태 업데이트를 위해 JSON-RPC 2.0의 알림 메시지를 지원합니다. 이 알림 메시지에는 `id` 필드가 포함되지 않는 것이 특징입니다. 이를 통해 서버는 도구 목록의 변경 사항이나 실시간 동적 업데이트를 연결된 클라이언트(AI 애플리케이션)에 즉각적으로 통지할 수 있습니다 [3, 5, 6].
+* **전송 계층(Transport Layer)과의 결합:** JSON-RPC 2.0 메시지는 통신 메커니즘을 정의하는 전송 계층을 통해 전달됩니다. 주로 로컬 프로세스 간 직접 통신을 위해 네트워크 오버헤드가 없는 표준 입출력(stdio)을 사용하거나, 원격 서버와의 통신 및 실시간 데이터 스트리밍을 위해 Server-Sent Events(SSE)가 결합된 HTTP POST를 사용하여 전송됩니다 [7].
+* **하네스 및 에이전트 프로토콜의 표준 기반:** Anthropic의 MCP는 Language Server Protocol(LSP)의 메시지 흐름 개념을 재사용하며 JSON-RPC 2.0 기반 위에서 동작합니다 [8]. 또한 에이전트와 IDE 클라이언트 간의 통신을 표준화하는 ACP(Agent Client Protocol) 역시 JSON-RPC 2.0을 사용하며, OpenAI의 Codex 하네스는 모든 클라이언트 표면에 에이전트 런타임을 노출하기 위해 stdio 기반의 JSON-RPC/JSONL 프로토콜(Item/Turn/Thread 프로토콜)을 구현했습니다 [9, 10].
+
+## ⚖️ Trade-offs & Caveats
+* **지연 시간과 확장성의 트레이드오프:** JSON-RPC 2.0을 stdio(표준 입출력) 전송과 결합하여 로컬 도구를 호출할 경우 2~15ms의 매우 낮은 지연 시간으로 단일 하네스 에이전트의 긴밀한 통합 루프에 최적화된 성능을 제공합니다. 하지만 이는 다중 테넌트(Multi-tenant) 또는 원격 환경으로 확장할 때 불리하며, 이 경우 JSON-RPC를 HTTP+SSE 전송으로 넘겨 처리해야 하므로 50~200ms 이상의 네트워크 지연이 발생할 수 있습니다 [11, 12].
+* **프로토콜 자체의 보안 및 상태 관리 한계:** JSON-RPC 2.0 프로토콜 자체에는 상태 저장(Stateful) 세션 관리 기능이나 네임스페이스 스푸핑(Tool spoofing)을 방지하는 보안 모델이 내장되어 있지 않습니다. 따라서 JSON-RPC를 도입하는 에이전트 하네스는 프로토콜 계층에만 의존해서는 안 되며, 악의적인 도구 주입이나 권한 남용을 방지하기 위해 하네스의 수명주기 훅(Lifecycle Hooks, L-component)을 통한 강력한 사전/사후 검증 정책을 추가로 직접 구현해야 합니다 [13-15].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [관계 유형 A (아키텍처/기반 기술)]
+* [[Model Context Protocol]] (MCP)
+  * 연결 이유: AI 에이전트와 외부 데이터, 도구를 연결하는 개방형 표준으로 JSON-RPC 2.0을 기본 데이터 통신 프로토콜로 사용합니다 [1, 3].
+  * 이 개념을 통해 더 깊게 이해할 수 있는 부분: JSON-RPC 2.0이 실제 에이전트 런타임에서 도구 탐색(Discovery), 실행(Execution), 자원 접근에 활용되는 구체적인 데이터 교환 스키마를 이해할 수 있습니다.
+* [[Agent Client Protocol]] (ACP)
+  * 연결 이유: 코딩 에이전트와 IDE 등의 클라이언트 애플리케이션 간의 통합을 표준화하기 위해 JSON-RPC 2.0을 사용하는 프로토콜입니다 [9].
+  * 이 개념을 통해 더 깊게 이해할 수 있는 부분: 에이전트 하네스의 실행 루프(E-component)가 사용자 인터페이스와 상호작용하고 상태 업데이트 및 취소(Cancellation) 명령을 관리하는 방식을 파악할 수 있습니다.
+
+#### [관계 유형 B (구현/전송 매커니즘)]
+* [[stdio transport]]
+  * 연결 이유: JSON-RPC 2.0 메시지를 네트워크 오버헤드 없이 로컬 머신에서 가장 빠르게 전송하기 위해 사용되는 표준 입출력 전송 방식입니다 [7].
+  * 이 개념을 통해 더 깊게 이해할 수 있는 부분: 단일 하네스 내에서 도구 실행(T-component) 지연 시간을 밀리초 단위로 최소화하기 위한 시스템 레벨의 최적화 기법을 이해할 수 있습니다.
+* [[Lifecycle Hooks]] (하네스 L-component)
+  * 연결 이유: JSON-RPC 2.0을 기반으로 통신하는 도구 및 서버에 대해, 실제 실행 권한을 통제하고 정책을 집행(Policy enforcement)하는 하네스의 필수 보안/거버넌스 계층입니다 [13, 14, 16].
+  * 이 개념을 통해 더 깊게 이해할 수 있는 부분: 단순히 JSON-RPC 메시지를 주고받는 것을 넘어, 엔터프라이즈 하네스 환경에서 도구 호출을 신뢰할 수 있도록 보장하는 방어 계층을 어떻게 구축하는지 배울 수 있습니다.
+
+### Deeper Research Questions
+* 다중 에이전트(Multi-agent) 시스템에서 JSON-RPC 2.0 기반의 알림(Notification) 메시지는 에이전트 간의 작업 상태(Task graph)를 동기화하는 데 어떤 방식으로 활용될 수 있는가?
+* JSON-RPC 2.0 메시지를 처리하는 에이전트 하네스의 실행 루프(E-component)는 네트워크 시간 초과(Timeout)나 스키마 불일치 등 외부 도구 서버의 실패를 어떻게 분류하고 복구(Retry/Graceful degradation)하는가?
+* 로컬 프로세스 간의 JSON-RPC 통신(stdio)과 분산 환경에서의 HTTP 통신 간에 트랜잭션의 상태와 컨텍스트 출처(Provenance)를 보존하기 위해 하네스 설계는 어떻게 변경되어야 하는가?
+* JSON-RPC 2.0 포맷을 통해 오가는 대용량 도구 출력 결과를 프롬프트 윈도우 한계 내에서 처리하기 위해, 하네스의 컨텍스트 관리자(C-component)는 어떤 계층적 요약 및 아티팩트 분리 전략을 사용하는가?
+
+### Practical Application Contexts
+* **Implementation:** MCP 서버 구축 시 JSON-RPC 2.0 규격에 맞춰 `tools/list`, `tools/call` 등 고유 ID를 포함한 요청과 결과를 처리하는 핸들러를 코드로 구현합니다.
+* **System Design:** 에이전트 하네스 설계 시, 로컬 보안 샌드박스 내부의 도구는 stdio 기반 JSON-RPC로 연결하고 원격 에이전트 간 위임은 HTTP 기반으로 처리하도록 전송 계층을 분리하는 하이브리드 아키텍처를 도입합니다.
+* **Operation / Maintenance:** 하네스의 평가 인터페이스(V-component)나 관측 가능성(Observability) 시스템을 통해 JSON-RPC 2.0 메시지 페이로드의 로그를 캡처하여, 에이전트의 실행 궤적(Trajectory)과 도구 호출 실패 원인을 추적 및 디버깅합니다.
+* **Learning Path:** LLM 모델의 출력이 외부 세계와 상호작용하기 위해 어떻게 구조화된 명령으로 변환되는지 이해하고자 할 때, 기반이 되는 JSON-RPC 2.0 사양을 학습하고 이를 적용한 MCP 아키텍처 스펙으로 나아갑니다.
+* **My Project Relevance:** 맞춤형 AI 업무 자동화 에이전트를 구축할 때, 내부 데이터베이스나 레거시 API를 JSON-RPC 2.0 기반의 표준 MCP 서버로 래핑(Wrapping)하여 특정 에이전트 프레임워크 종속성 없이 범용적으로 통신하도록 통합합니다.
+
+### Adjacent Topics
+* [[Language Server Protocol]] (LSP)
+  * 확장 방향: JSON-RPC를 기반으로 하는 또 다른 주요 표준으로, 코딩 에이전트 하네스가 복잡한 소프트웨어 프로젝트 환경에서 시맨틱 코드 분석 및 심볼 탐색(find_symbol 등)을 효율적으로 수행하기 위해 어떻게 도구화하는지 그 개념을 연장할 수 있습니다.
+* [[Agent-to-Agent Protocol]] (A2A)
+  * 확장 방향: 에이전트와 도구 간 통신(MCP)이 아닌, 원격 에이전트 간의 위임과 상호작용을 처리하는 통신 규약으로서 다중 에이전트 하네스 오케스트레이션 계층에 대한 이해를 확장할 수 있습니다.
+
+---
+*Last updated: 2026-05-01*
\ No newline at end of file
diff --git a/00_Raw/JavaScript Memory Management.md b/00_Raw/JavaScript Memory Management.md
new file mode 100644
index 00000000..fd73ce66
--- /dev/null
+++ b/00_Raw/JavaScript Memory Management.md	
@@ -0,0 +1,66 @@
+# [[JavaScript Memory Management]]
+
+## 📌 Brief Summary
+자바스크립트 메모리 관리는 할당된 메모리가 더 이상 필요하지 않을 때 가비지 컬렉터(Garbage Collector)를 통해 자동으로 메모리를 회수하는 과정을 의미합니다 [1]. 그러나 참조가 남아있어 메모리가 해제되지 않으면 메모리 누수(Memory Leak)가 발생하며, 이는 점진적인 성능 저하나 애플리케이션 멈춤 현상을 유발합니다 [1-3]. 효과적인 메모리 관리를 위해서는 Chrome DevTools와 같은 도구를 사용하여 분리된 DOM 노드나 정리되지 않은 이벤트 리스너 등을 식별하고 해결해야 합니다 [4-6].
+
+## 📖 Core 소스 Content
+- **가비지 컬렉션과 메모리 누수:** 자바스크립트는 사용되지 않는 메모리를 자동으로 회수하는 가비지 컬렉터를 제공하지만, 객체에 대한 참조(Reference)가 남아있는 한 메모리는 해제되지 않습니다 [1]. 필요 없는 메모리가 계속 누적되면 애플리케이션의 메모리 사용량이 지속적으로 증가하는 메모리 누수가 발생합니다 [1, 3].
+- **메모리 문제의 3가지 유형:** 
+  1. **메모리 누수(Memory Leak):** 페이지의 버그로 인해 시간이 지남에 따라 메모리 사용량이 점진적으로 증가하여 성능이 악화되는 현상입니다 [2].
+  2. **메모리 팽창(Memory Bloat):** 최적의 페이지 속도를 위해 필요한 것보다 너무 많은 메모리를 사용하여 일관되게 성능이 저하되는 현상입니다 [2].
+  3. **잦은 가비지 컬렉션(Frequent Garbage Collections):** 브라우저가 메모리를 회수하기 위해 스크립트 실행을 자주 일시 중지시키면서, 성능이 지연되거나 멈춘 것처럼 보이는 현상입니다 [2].
+- **주요 메모리 누수 패턴:**
+  - **분리된 DOM 노드(Detached DOM Nodes):** 문서(DOM 트리)에서는 제거되었지만 자바스크립트 변수에서 여전히 참조하고 있어 가비지 컬렉션의 대상이 되지 못하는 노드입니다 [4, 6].
+  - **이벤트 리스너 누적:** 컴포넌트가 언마운트될 때 적절히 제거되지 않은 이벤트 리스너들이 메모리에 계속 축적되는 현상입니다 [6]. React에서는 `useEffect`에서 정리(Cleanup) 함수를 반환하지 않을 때 흔히 발생합니다 [7, 8].
+  - **클로저로 유지되는 참조(Closure-Retained References):** 클로저(Closure)가 부모 스코프의 변수를 계속 살려두어 대규모 객체를 불필요하게 메모리에 유지하는 경우입니다 [9].
+- **탐지 및 디버깅 도구:**
+  - **Chrome Task Manager:** DOM 노드가 저장되는 OS 메모리를 나타내는 'Memory footprint'와 도달 가능한 자바스크립트 객체가 사용하는 메모리를 나타내는 'JavaScript Memory'의 실시간 사용량을 모니터링합니다 [10].
+  - **힙 스냅샷(Heap Snapshots):** 특정 시점의 메모리 분산 상태를 캡처합니다 [11]. 두 스냅샷을 비교하여 크기가 계속 증가하는(Delta 값이 양수인) 객체를 찾고, 해당 객체가 삭제될 경우 해제될 메모리 크기(Retained Size)를 파악할 수 있습니다 [5, 12].
+  - **할당 타임라인(Allocation Timeline):** 메모리 할당 패턴을 실시간으로 분석하여 어떤 함수나 작업이 메모리 누수를 유발하는지 추적합니다 [13-15].
+- **예방 전략:** 캐시 관리 시 객체 대신 `WeakMap`을 사용하여 가비지 컬렉션이 정상적으로 이루어지도록 하고, Puppeteer를 이용해 CI 파이프라인에 자동화된 메모리 누수 테스트를 통합할 수 있습니다 [16].
+
+## ⚖️ Trade-offs & Caveats
+브라우저가 가비지 컬렉션을 수행할 때는 모든 스크립트 실행이 일시 중지(Pause)된다는 제약 사항이 있습니다 [2]. 따라서 메모리 할당을 과도하게 하거나 메모리 팽창이 발생하면 잦은 가비지 컬렉션이 트리거되어 사용자 경험(UX)상 앱이 자주 멈추는 듯한 심각한 부작용을 초래합니다 [2]. 반면, 성능 최적화나 캐싱을 목적으로 객체나 데이터를 클로저 메모리에 길게 보관하는 기술적 선택을 할 경우, 적절한 시점에 참조를 해제하거나 `WeakMap`을 사용하지 않으면 애플리케이션 충돌(Crash)이나 탭 멈춤 현상을 유발하는 치명적인 메모리 누수(Trade-off)로 이어질 위험이 있습니다 [3, 9, 16]. 또한 메모리 프로파일링을 위한 힙 스냅샷 캡처 및 처리는 상당한 로드 시간이 소요될 수 있습니다 [11].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [아키텍처/기반 기술]
+- [[Garbage Collection]]
+  - 연결 이유: 자바스크립트의 메모리 관리는 더 이상 참조되지 않는 메모리를 자동으로 회수하는 가비지 컬렉션 메커니즘에 전적으로 의존합니다 [1].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 브라우저가 도달 가능한(Reachable) 객체를 판단하는 기준과 스크립트 실행이 정지되는 타이밍을 이해할 수 있습니다 [1, 2, 10].
+- [[Detached DOM Nodes]]
+  - 연결 이유: 현대적인 컴포넌트 기반 UI(예: React, Vue)에서 메모리 누수를 일으키는 가장 흔한 원인 중 하나입니다 [4, 6].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: JS 변수의 참조가 어떻게 OS 메모리에 위치한 DOM 트리의 가비지 컬렉션을 방해하는지 파악할 수 있습니다 [4, 10].
+
+#### [구현/활용 도구]
+- [[Heap Snapshot]]
+  - 연결 이유: Chrome DevTools에서 메모리 누수의 정확한 원인(Retainer path)을 찾기 위해 필수적으로 사용되는 프로파일링 도구입니다 [5, 11].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: Shallow size(객체 자체의 크기)와 Retained size(참조가 끊길 시 회수되는 크기)의 차이를 이해하고 메모리 해제 효과를 분석할 수 있습니다 [5, 12].
+- [[useEffect Cleanup]]
+  - 연결 이유: React 프레임워크 환경에서 이벤트 리스너나 구독(Subscription)으로 인한 메모리 누수를 예방하기 위한 핵심 구현 패턴입니다 [7, 8, 16].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 컴포넌트 생명주기와 연동하여 자원(Resource)을 올바르게 해제하는 방법을 체득할 수 있습니다 [7, 16].
+
+### Deeper Research Questions
+- 자바스크립트 가비지 컬렉터의 도달 가능성(Reachability) 판단에서 'GC Roots'는 구체적으로 어떤 객체들을 포함하며 어떻게 탐색되는가?
+- Chrome DevTools의 Heap Snapshot에서 식별할 수 있는 Shallow size와 Retained size의 정확한 기술적 차이점과 분석 시의 활용법은 무엇인가?
+- Node.js 서버 환경에서 V8 inspector protocol을 이용한 메모리 프로파일링은 브라우저 클라이언트 환경의 디버깅과 어떻게 다르며 어떤 특수한 누수 패턴이 존재하는가?
+- WeakMap을 활용한 캐싱 메커니즘은 일반 Map과 비교하여 내부적으로 어떻게 가비지 컬렉션을 허용하는가?
+- React 컴포넌트 최적화(예: `useMemo`, `useCallback`)로 인해 메모리에 유지되는 객체 참조가 가비지 컬렉션 주기와 전체 애플리케이션의 메모리 팽창에 미치는 영향은 무엇인가?
+
+### Practical Application Contexts
+- **Implementation:** React 컴포넌트 개발 시 `useEffect` 훅 내부에서 이벤트 리스너, WebSocket, 타이머 등을 등록할 때 반드시 해제(Cleanup) 함수를 반환하도록 구현하여 컴포넌트 언마운트 시 메모리 누수를 방지합니다 [7, 8, 16]. 캐시 객체가 필요할 때는 `WeakMap`을 도입하여 자동 메모리 관리를 유도합니다 [16].
+- **System Design:** 대규모 데이터나 복잡한 UI를 다룰 때, 클로저가 불필요하게 거대한 컨텍스트 객체에 대한 참조를 유지하지 않도록 컴포넌트 스코프와 상태 레이어 구조를 설계해야 합니다 [9].
+- **Operation / Maintenance:** 프로덕션 환경에서 앱의 성능 저하나 멈춤 현상이 보고되면, Chrome Task Manager로 메모리 발자국(Memory footprint) 증가 추이를 실시간 모니터링하고 Heap Snapshot을 비교 분석(Delta 값 확인)하여 누수 지점을 찾아냅니다 [5, 11, 17]. CI 파이프라인에 Puppeteer를 통한 자동화된 메모리 테스트를 구축합니다 [16].
+- **Learning Path:** 자바스크립트 참조와 클로저의 동작 원리 이해 -> 브라우저의 가비지 컬렉션 메커니즘 학습 -> Chrome DevTools를 활용한 Heap Snapshot 및 Allocation Timeline 분석 실습 -> 프레임워크(React) 특화 메모리 최적화 패턴 적용.
+- **My Project Relevance:** React 코드베이스 리팩토링 과정에서 잘못 구현된 커스텀 훅이나 상태 관리 로직으로 인한 메모리 누수가 없는지 점검하고, 안정적이고 확장 가능한 프론트엔드 아키텍처를 구축하는 데 필수적으로 적용되어야 합니다.
+
+### Adjacent Topics
+- [[React Performance Optimization]]
+  - 확장 방향: 메모리 관리뿐만 아니라 `React.memo`, `useCallback` 등을 통한 불필요한 렌더링 최적화가 어떻게 자바스크립트 객체의 불필요한 재생성과 메모리 할당을 줄이는 데 기여하는지 살펴봅니다 [18-20].
+- [[Core Web Vitals]]
+  - 확장 방향: 메모리 팽창이나 잦은 가비지 컬렉션으로 인한 메인 스레드 블로킹이 INP(Interaction to Next Paint) 및 TBT(Total Blocking Time)와 같은 실제 웹 성능 지표에 미치는 영향을 조사합니다 [21-23].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/KISS.md b/00_Raw/KISS.md
new file mode 100644
index 00000000..e1252ceb
--- /dev/null
+++ b/00_Raw/KISS.md
@@ -0,0 +1,58 @@
+# [[KISS]]
+
+## 📌 Brief Summary
+KISS("Keep It Simple, Stupid" 또는 "leave the code simple and dumb")는 복잡성보다 단순성을 항상 우선시해야 한다는 소프트웨어 엔지니어링 원칙입니다 [1-3]. 과도한 추상화나 불필요한 복잡성을 피하고, 코드를 직관적이고 이해하기 쉽고 간단하게 유지하는 것을 핵심 목표로 삼습니다 [2-4]. 이 원칙은 특히 빠른 프로토타이핑(Quick prototyping)이나 단순한 애플리케이션 개발에 적합하며, React 컴포넌트 개발 시 조기 최적화(premature optimization)를 피하고 예측 가능성을 높이는 데 사용됩니다 [1, 5].
+
+## 📖 Core 소스
+*   **단순성 추구:** KISS 원칙은 코드를 "단순하고 멍청하게(simple and dumb)" 남겨두라는 의미입니다 [3]. 코드를 복잡하게 만들지 말고, 특정 함수나 컴포넌트가 너무 커질 경우 더 작고 이해하기 쉬운 논리적인 단위로 분할할 것을 권장합니다 [3].
+*   **과도한 추상화 경계:** 코드를 재사용하기 위한 추상화가 원래의 중복 코드보다 오히려 이해하기 어려울 정도로 복잡해진다면, 이는 목적을 잃고 KISS 원칙을 위반한 것입니다 [4]. 
+*   **React에서의 활용:** React 애플리케이션에서 컴포넌트 로직을 불필요하게 꼬지 않고 명확히 구현함으로써, 코드가 상호 간에 결합되지 않고(decoupled) 예측 가능하도록(predictable) 유지하는 데 필수적인 역할을 합니다 [1, 5].
+
+## ⚖️ Trade-offs & Caveats
+KISS 원칙을 준수하면 코드가 간단하고 직선적이어서 디버깅이 쉬워진다는 강력한 장점이 있습니다 [6]. 
+
+그러나 다음과 같은 한계와 제약 사항(Trade-offs)이 존재합니다:
+*   **과도한 단순화의 위험:** 이 원칙에만 지나치게 몰두할 경우 문제에 대한 해결책 자체를 너무 단순화(oversimplify)하여, 애플리케이션의 요구 사항을 충족시키지 못하거나 미래의 확장성을 떨어뜨릴 수 있습니다 [6].
+*   **DRY 원칙과의 충돌:** "자신을 반복하지 말라"는 DRY(Don't Repeat Yourself) 원칙과 종종 균형을 이루어야 합니다. 중복을 피하기 위해 코드를 계속 추상화하다 보면 복잡성이 증가하여 결국 KISS 원칙을 어기게 될 수 있으므로, 적절한 선에서 단순성을 유지하는 통찰이 필요합니다 [4].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [소프트웨어 설계 원칙 (Software Design Principles)]
+- [[DRY (Don't Repeat Yourself)]]
+  - 연결 이유: 코드를 깔끔하게 유지하기 위해 KISS와 함께 언급되는 핵심 원칙입니다. 과도한 DRY 적용은 KISS 위반으로 이어지므로 상호 보완적인 관계에 있습니다 [2, 4].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 코드 중복 제거와 추상화의 복잡성 사이에서 발생하는 기술적 트레이드오프 [4].
+
+- [[YAGNI (You Aren't Gonna Need It)]]
+  - 연결 이유: 당장 필요하지 않은 기능은 추가하지 말라는 원칙으로, 불필요한 로직을 배제하여 코드를 단순하게 유지한다는 점에서 KISS 원칙의 철학과 깊이 연결됩니다 [2, 7].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 애자일 개발 환경이나 요구 사항이 변하는 스타트업 프로젝트에서 불필요한 작업과 조기 최적화를 피하는 방법 [2, 5].
+
+#### [React 구현 및 코드 품질 (Implementation & Code Quality)]
+- [[Clean Code]]
+  - 연결 이유: KISS 원칙을 적용하는 궁극적인 목적은 유지보수가 쉽고 가독성이 높은 클린 코드를 작성하는 데 있기 때문입니다 [2].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 복잡성을 배제하고 중첩 구조를 피하며 명확한 코드를 작성하는 실무적인 가이드라인 [2, 8].
+
+### Deeper Research Questions
+
+- React 컴포넌트를 설계할 때 KISS 원칙을 위반하는 '과도한 추상화'의 구체적인 판단 기준은 무엇인가? [4]
+- KISS 원칙과 DRY 원칙이 충돌할 때, 어느 시점에 추상화를 멈추고 코드 중복을 허용하는 것이 유지보수에 더 유리한가? [4]
+- KISS 원칙을 고수하여 해결책을 '과도하게 단순화(oversimplify)'했을 때, 프로젝트의 확장성(Scalability) 측면에서 발생할 수 있는 구체적인 한계는 무엇인가? [6]
+- 빠르고 단순한 프로토타이핑을 위해 KISS 원칙을 주로 적용한 이후, 대규모 아키텍처로 점진적으로 확장하려면 어떤 구조적 변화가 필요한가? [5]
+- 컴포넌트가 비대해질 때 KISS 원칙에 따라 "작고 이해하기 쉬운 논리적 부분"으로 분할하기 위한 React 생태계의 최적의 패턴은 무엇인가? [3]
+
+### Practical Application Contexts
+
+- **Implementation:** React 컴포넌트를 작성할 때, 로직을 단순하게 유지하고 조기 최적화를 지양합니다. 컴포넌트가 너무 커지면 더 작고 이해하기 쉬운 함수나 단위로 나눕니다 [3, 5].
+- **System Design:** 빠르고 간단한 프로토타이핑(Quick prototyping)이나 구조가 단순한 애플리케이션을 설계할 때 주된 원칙으로 채택됩니다 [5].
+- **Operation / Maintenance:** 코드를 직선적이고 바보 같을 정도로 단순하게 유지하여, 버그 발생 시 빠르고 쉽게 디버깅할 수 있도록 운영 환경을 개선합니다 [3, 6].
+- **Learning Path:** 복잡성을 덜어내는 방법을 배우기 위해 SOLID, DRY, YAGNI 등과 함께 프론트엔드 엔지니어링의 필수 기초 설계 원칙으로 학습합니다 [1, 9].
+- **My Project Relevance:** React 프로젝트에서 코드를 리팩터링할 때 불필요하게 복잡해진 공통 훅(Hook)이나 유틸리티가 없는지 점검하고, 이해하기 어려운 코드는 직관적으로 재작성하는 데 활용할 수 있습니다 [4, 5].
+
+### Adjacent Topics
+
+- [[SOLID Principles]]
+  - 확장 방향: 단순성을 넘어서, 크고 복잡한 대규모 애플리케이션이 요구하는 구조화 및 확장성을 충족하기 위해 객체지향/함수형 설계 원칙(단일 책임 원칙, 의존성 역전 등)이 어떻게 함께 조화를 이루는지 탐구합니다 [5, 9, 10].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Large-scale React Applications.md b/00_Raw/Large-scale React Applications.md
new file mode 100644
index 00000000..135fc56a
--- /dev/null
+++ b/00_Raw/Large-scale React Applications.md	
@@ -0,0 +1,84 @@
+# [[Large-scale React Applications]]
+
+## 📌 Brief Summary
+대규모 React 애플리케이션(Large-scale React Applications)은 단순한 UI 렌더링을 넘어 확장성, 유지보수성, 고성능이 요구되는 복잡한 분산 소프트웨어 시스템입니다 [1]. 애플리케이션의 규모가 커짐에 따라 비즈니스 로직 누수, 상태 소유권 혼란, 은연중의 의존성 결합 등의 아키텍처 붕괴가 발생할 수 있습니다 [2, 3]. 이를 방지하기 위해 기능 기반의 엄격한 폴더 구조(Feature-Sliced Design), 체계적인 전역 상태 관리, 자동화된 빌드 최적화 및 엄격한 코드 거버넌스 원칙의 적용이 필수적입니다 [1, 4-6].
+
+## 📖 Core Content
+
+*   **기능 기반 아키텍처 및 폴더 구조 (Feature-Based Architecture)**
+    *   기존의 기술적 파일 유형(components, hooks 등)별 폴더 구조는 애플리케이션이 확장될수록 논리가 흩어져 유지보수성에 치명적입니다 [7, 8]. 2025년 기준 산업 표준은 비즈니스 기능 단위로 코드를 묶는 구조이며, 특히 **기능 분할 설계(Feature-Sliced Design, FSD)**가 강력한 확장성을 제공합니다 [4, 9, 10].
+    *   FSD는 `app`, `pages`, `widgets`, `features`, `entities`, `shared` 계층으로 코드를 구분하며, 하위 계층이 상위 계층을 참조할 수 없는 단방향 의존성을 강제하여 예측 가능한 확장을 가능하게 합니다 [4].
+*   **규모에 맞는 상태 관리 (State Management at Scale)**
+    *   **Context API**는 데이터 전송에는 유용하지만, 상태 변경 시 해당 컨텍스트를 구독하는 모든 컴포넌트를 리렌더링시키므로 상태가 빈번하게 변하는 대규모 앱에는 적합하지 않습니다 [11-13].
+    *   팀 규모가 5~15명 수준인 중간 이상의 앱에서는 필요한 상태 조각(slice)만 구독하여 불필요한 렌더링을 방지하는 **Zustand**가 효율적입니다 [13-15]. 
+    *   500개 이상의 컴포넌트와 복잡한 비동기 작업, 10명 이상의 개발자가 참여하는 대규모 환경에서는 일관된 패턴 강제, 시계열 디버깅(Time-travel debugging) 등 강력한 구조를 제공하는 **Redux(RTK)**가 산업 표준으로 작동합니다 [16-18].
+*   **성능 엔지니어링 최적화 (Performance Engineering)**
+    *   거대한 JavaScript 번들 크기를 줄이기 위해 `React.lazy`와 `Suspense`를 활용하여 라우트(Route) 및 무거운 컴포넌트 단위로 **코드 분할(Code Splitting)**을 적용해야 합니다 [19-21].
+    *   Vite 기반 프로젝트에서는 `manualChunks`를 설정하여 React 코어 라이브러리와 같이 자주 변경되지 않는 벤더 모듈을 분리, 브라우저 캐싱 효율을 극대화할 수 있습니다 [22, 23].
+    *   데이터가 많은 대용량 목록은 윈도잉(Windowing/Virtualization) 기법을 사용하여 뷰포트에 보이는 항목만 렌더링함으로써 DOM 과부하를 방지합니다 [24, 25].
+*   **복원력 및 디버깅 체계 (Resilience & Debugging)**
+    *   **에러 바운더리(Error Boundaries)**를 대시보드나 서드파티 위젯 등 핵심/불안정 영역에 개별적으로 씌워, 하나의 오류가 앱 전체를 마비시키는 '흰 화면(White screen of death)' 현상을 방지해야 합니다 [26-29].
+    *   Chrome DevTools의 Heap Snapshot과 Allocation Timeline을 통해 분리된 DOM 노드(Detached DOM nodes)나 해제되지 않은 이벤트 리스너로 인한 **메모리 누수(Memory Leak)**를 주기적으로 점검합니다 [30-32].
+*   **클린 코드 및 코드 거버넌스 (Governance & Clean Code)**
+    *   단일 책임 원칙(SRP)을 바탕으로 비대해진 컴포넌트를 잘게 쪼개고, ESLint 및 Husky를 연동하여 의존성 규칙이나 명명 규칙(파일은 `kebab-case`, 컴포넌트는 `PascalCase`) 위반을 자동화된 CI/CD 파이프라인에서 차단해야 합니다 [5, 33-36].
+
+## ⚖️ Trade-offs & Caveats
+
+*   **상태 관리 도구의 유연성 vs 구조적 강제성**: Zustand는 보일러플레이트가 없어 개발 속도를 높여주지만, 고도의 유연성 탓에 대규모 팀에서는 비동기 처리 로직이나 미들웨어 패턴이 제각각으로 분열되는 혼란(Store Soup)을 초래할 위험이 있습니다 [37-39]. 반면 Redux는 보일러플레이트가 비대하다는 단점이 있으나, 장기적인 관점에서는 이 '구조' 자체가 팀의 일관성을 강제하여 심각한 버그를 방지하는 역할을 합니다 [17, 18, 40].
+*   **수동 메모이제이션 최적화의 오버헤드**: `React.memo`, `useCallback`, `useMemo`는 불필요한 렌더링을 막아주지만 비교 연산이라는 추가 비용이 발생합니다. 최적화 대상 컴포넌트의 렌더링 비용이 저렴하거나 props가 수시로 변하는 경우, 메모이제이션 비용이 렌더링 비용을 초과하여 오히려 성능이 하락하는 역효과가 발생할 수 있습니다 [41, 42]. 
+*   **React Compiler 도입의 맹점**: React Compiler는 빌드 타임에 메모이제이션을 자동화하여 코드의 가독성을 대폭 개선합니다 [43, 44]. 그러나 이는 어떻게 최적화되었는지 알기 힘든 블랙박스로 동작하기 때문에 성능 문제 디버깅을 어렵게 만들며, 매번 새로운 객체를 반환하는 일부 서드파티 라이브러리(예: React Router, TanStack Query 등)의 훅과 충돌하여 최적화가 무력화될 수 있습니다 [45, 46].
+*   **기능 분할 설계(FSD)의 초기 오버헤드**: FSD 아키텍처는 코드의 모듈화를 극대화하지만, 특정 모듈이 '기능(feature)'인지 '위젯(widget)'인지 분류하기 위한 의미론적 논의에 시간이 소모될 수 있으며, 팀원 전체가 이 방법론을 온전히 이해하지 못할 경우 오히려 공유 폴더(`shared`)에 코드가 무분별하게 쌓이는 부작용이 발생할 수 있습니다 [47, 48].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [아키텍처 및 구조 설계]
+- [[Feature-Sliced Design]]
+  - 연결 이유: 대규모 React 애플리케이션의 파편화를 방지하기 위해 각광받는 최신 도메인/기능 기반 아키텍처 방법론입니다 [49, 50].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 확장 가능한 프로젝트의 폴더 구조와 컴포넌트 간 단방향 의존성 규칙의 실질적 적용 방법을 학습할 수 있습니다 [4].
+- [[SOLID Principles]]
+  - 연결 이유: 객체 지향 원칙이지만 React의 함수형 컴포넌트 분리 및 훅(Hook) 설계에 동일하게 적용되어 유지보수성을 극대화합니다 [51, 52].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 거대한 컴포넌트를 언제, 어떻게 분리해야 하는지(단일 책임 원칙)와 Props의 올바른 전달 방식(인터페이스 분리 원칙)을 이해할 수 있습니다 [33, 53].
+
+#### [상태 관리 및 성능 최적화]
+- [[Redux]] / [[Zustand]]
+  - 연결 이유: 앱의 규모, 팀의 크기, 상태 변경 빈도에 따라 아키텍처에서 가장 중요한 기술적 선택지가 됩니다 [15, 54, 55].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 리렌더링 최적화, 스토어 분할 전략, 상태 관리 도구의 구조적 보일러플레이트가 가지는 실제 효용성을 비교할 수 있습니다 [13, 18, 56].
+- [[Code Splitting]]
+  - 연결 이유: 대형 앱에서 기하급수적으로 커지는 JavaScript 번들 크기를 제어하여 초기 로딩 성능(FCP, TTI)을 보장하는 핵심 기술입니다 [19, 57].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: `React.lazy`와 번들러(Vite/Webpack)를 활용하여 라우트나 컴포넌트를 온디맨드로 지연 로딩하는 메커니즘을 파악할 수 있습니다 [21, 23].
+- [[React Compiler]]
+  - 연결 이유: 수동으로 작성하던 `useMemo`, `useCallback` 등을 빌드 타임에 자동화하여 대규모 코드베이스의 가독성과 성능을 혁신하는 최신 도구입니다 [43, 58].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: React의 렌더링 동작 방식과 안정적 참조(Stable References)의 중요성을 더 깊이 통찰할 수 있습니다 [45, 59].
+
+#### [안정성 보장 및 디버깅]
+- [[Error Boundaries]]
+  - 연결 이유: 런타임 오류로부터 시스템 전체가 붕괴하는 것을 막고, 사용자에게 예비 UI를 제공하는 '방어적 프로그래밍'의 핵심입니다 [26, 60].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: React 생명주기 내 에러 포착 원리와 비동기 에러와의 차이점을 이해할 수 있습니다 [61, 62].
+
+### Deeper Research Questions
+
+- 대규모 프로젝트에서 Feature-Sliced Design의 단방향 의존성(Unidirectional dependencies) 규칙이 깨지지 않도록 ESLint를 구성하는 구체적인 방법은 무엇인가?
+- Redux의 막대한 보일러플레이트 비용이 Zustand의 유연성으로 인한 '유지보수 혼란' 비용을 역전하는 정확한 조직적, 기술적 임계점은 어디인가?
+- React Compiler가 안정적인 객체 참조를 반환하지 않는 서드파티 라이브러리(TanStack Query, React Router 등)와 만났을 때 성능 최적화가 무력화되는 현상을 구조적으로 어떻게 우회할 수 있는가?
+- Chrome DevTools의 Heap Snapshot을 통해 식별되는 'Detached DOM nodes' 기반 메모리 누수의 주요 발생 패턴과, 이를 React 컴포넌트 생명주기 내에서 완벽하게 해제(Cleanup)하는 전략은 무엇인가?
+- 기존의 단순 기능별 폴더 구조(Flat structure)에서 Feature-Sliced Design 아키텍처로 안전하게 점진적 마이그레이션을 수행하기 위한 절차적 리팩토링 전략은 무엇인가?
+
+### Practical Application Contexts
+
+- **Implementation:** 파일과 컴포넌트의 명명 규칙(파일은 `kebab-case`, React 컴포넌트는 `PascalCase`)을 통합하여 CI/CD 파이프라인에서 OS 간 대소문자 구분 문제로 인한 빌드 에러를 미연에 방지합니다 [34-36, 63].
+- **System Design:** 초기 기획 단계에서 애플리케이션의 확장 가능성을 고려하여 FSD(Feature-Sliced Design)를 도입해 컴포넌트 간의 결합도를 낮추고 도메인별 응집도를 높인 설계를 구성합니다 [2, 4].
+- **Operation / Maintenance:** Sentry 및 LogRocket 등의 클라우드 로깅 도구를 연동하고 Error Boundaries를 전략적으로 배치하여, 프로덕션 환경의 UI 크래시를 격리하고 버그 발생 경로를 시각적으로 추적 가능하게 운영합니다 [26, 64, 65].
+- **Learning Path:** 단순 Prop Drilling을 막기 위한 Context API 학습에서 출발해, 렌더링 최적화가 필요할 때 Zustand를 익히고, 궁극적으로 10인 이상의 대규모 팀 환경을 가정하여 Redux 및 RTK Query를 활용하는 방향으로 학습을 고도화합니다 [66, 67].
+- **My Project Relevance:** 현재 소속된 프론트엔드 프로젝트의 병목 현상(비대한 번들, 무분별한 리렌더링, 파일 구조의 파편화)을 진단하고, `React.memo` 남용 제거, Vite `manualChunks` 적용, 기능별 폴더 재구성 등 구체적인 리팩토링의 지침으로 활용할 수 있습니다 [22, 68-70].
+
+### Adjacent Topics
+
+- [[Next.js Server Components]]
+  - 확장 방향: 대규모 React 앱에서 클라이언트 측 JavaScript 번들 크기를 극단적으로 줄이고, 클라이언트 상태 관리의 필요성을 데이터 패칭 단계에서 서버로 이관하는 아키텍처적 패러다임 전환을 탐구합니다 [71, 72].
+- [[Micro-Frontends]]
+  - 확장 방향: 단일 모노리틱(Monolithic) React 애플리케이션의 한계를 넘어, 독립적으로 배포 및 실행 가능한 여러 팀의 프론트엔드 조각들을 하나의 앱으로 결합하여 조직의 확장성을 극대화하는 방법을 연구합니다 [50, 73].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Legacy Codebase Refactoring.md b/00_Raw/Legacy Codebase Refactoring.md
new file mode 100644
index 00000000..fa8d378d
--- /dev/null
+++ b/00_Raw/Legacy Codebase Refactoring.md	
@@ -0,0 +1,70 @@
+# [[Legacy Codebase Refactoring]]
+
+## 📌 Brief Summary
+Legacy Codebase Refactoring(레거시 코드베이스 리팩터링)은 시간이 지남에 따라 노후화된 애플리케이션의 코드를 동작 변화 없이 점진적으로 개선하여 구조를 현대화하는 작업입니다 [1]. 단순히 코드를 수정하는 것에 그치지 않고 시스템의 유지보수성을 높이며 기술 부채를 관리하는 핵심 과정입니다 [1]. React 생태계에서는 주로 클래스형 컴포넌트를 함수형 컴포넌트(Hooks)로 전환하거나, 노후화된 상태 관리 라이브러리를 최신 도구로 마이그레이션하며, 코드베이스에 테스트 및 정적 분석 도구를 통합하는 방식으로 진행됩니다 [1-3].
+
+## 📖 Core Content
+* **점진적 마이그레이션 전략 (Incremental Migration):** 
+  레거시 시스템을 한 번에 모두 재작성하는 것은 위험성이 큽니다 [1]. 따라서 "재작성하지 말고 리팩터링하라(refactor, do not rewrite)"는 철학을 바탕으로, 기존의 기능 개발을 계속하면서 상태 관리 스토어나 아키텍처를 하나씩 점진적으로 이동하는 전략이 권장됩니다 [1].
+* **테스트 주도 접근 및 동작 보장:**
+  리팩터링을 시작하기 전에 반드시 단위 테스트나 UI 테스트 스위트를 작성해야 합니다 [4, 5]. 테스트 코드는 기존 코드의 역할을 이해하게 도와주며, 리팩터링 과정에서 발생할 수 있는 기능 파손(regression)을 즉시 파악할 수 있도록 합니다 [4, 6].
+* **React 특화 리팩터링 체크리스트:**
+  * **컴포넌트 및 로직 전환:** 클래스 기반 컴포넌트를 함수형 컴포넌트와 훅(Hooks)으로 교체하고, TypeScript를 점진적으로 도입합니다 [2, 7].
+  * **상태 관리 현대화:** 불필요한 `useEffect`를 제거하고, 복잡한 전역 스토어를 대체하기 위해 서버 상태는 Tanstack Query로, 클라이언트 전역 상태는 Context나 Zustand로 역할을 분리합니다 [2].
+  * **사용자 정의 훅 단위의 추출:** 복잡한 컴포넌트 내부에 혼재된 로직을 사용자 정의 훅(Custom Hooks)으로 분리해 모듈화와 테스트 용이성을 극대화합니다 [1, 8].
+  * **최적화 도구 정리:** React 19와 같은 최신 버전을 활용할 경우, 코드를 어지럽히는 불필요한 `useMemo`나 `useCallback` 등을 제거할 수 있습니다 [9].
+* **비즈니스 로직 분석 및 코드 품질 표준화:**
+  리팩터링 전 비즈니스 로직과 전역 UI 스토어의 역할을 완전히 이해하고, 전역 레벨에서 로컬 레벨로 분석을 좁혀 나가야 합니다 [8, 10]. 더불어 CSS 스타일 방식을 한 가지로 통일하고 [11, 12], ESLint(eslint-plugin-react 등)를 적용하여 코드 컨벤션을 강제함으로써 코드 스멜을 방지해야 합니다 [3].
+
+## ⚖️ Trade-offs & Caveats
+* **전체 재작성(Rewrite) vs 점진적 마이그레이션:** 
+  코드베이스가 매우 작을 경우 완전히 처음부터 새로 작성하는 것이 빠르고 쉬울 수 있습니다 [5]. 그러나 복잡한 애플리케이션에서는 전체 재작성이 막대한 자원과 위험을 수반하므로, 기능 배포를 멈추지 않는 점진적 마이그레이션을 선택해야만 하는 제약이 따릅니다 [1].
+* **TypeScript 도입에 따른 인지적 오버헤드:** 
+  리팩터링 시 TypeScript 도입은 장기적으로 오류를 줄여주지만, 경험이 부족한 팀원에게는 새로운 복잡성 레이어로 작용할 수 있습니다. 따라서 상황에 맞춰 단일 파일씩 점진적으로 변환하는 타협(Trade-off)이 필요합니다 [7].
+* **사전 테스트 작성의 비용:** 
+  기존 코드의 회귀(Regression)를 막기 위해 테스트 코드 작성이 강력히 권장되지만, 얽혀있는 기존 레거시 코드에 단위 테스트를 추가하는 작업은 초기 리팩터링 시간을 크게 지연시킬 수 있습니다 [4-6].
+* **계층형 아키텍처의 리팩터링 한계:**
+  기존 레거시가 기능 기반이 아닌 기술적 유형(컴포넌트, 훅 등) 단위의 폴더로 나뉜 계층형 아키텍처(Layered Architecture)를 따를 경우, 단일 기능을 리팩터링할 때 관련된 여러 파일이 흩어져 있어 추적 및 수정이 극도로 번거로울 수 있습니다 [13].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [아키텍처/기반 기술]
+* [[Feature-Sliced Design]]
+  * 연결 이유: 레거시 코드베이스의 스파게티 코드를 해결하고, 의존성을 단방향으로 제한하여 확장 가능한 프로젝트 구조로 재편하는 현대적 아키텍처 방법론입니다 [14-16].
+  * 이 개념을 통해 더 깊게 이해할 수 있는 부분: 리팩터링 중 컴포넌트 간 결합도를 줄이고 코드를 기능 및 비즈니스 도메인 단위로 명확하게 분리하는 방법을 학습할 수 있습니다 [15].
+* [[Custom Hooks]]
+  * 연결 이유: React 리팩터링의 핵심 단위(Primary unit)로, 비즈니스 로직을 UI와 분리하는 도구입니다 [1, 17].
+  * 이 개념을 통해 더 깊게 이해할 수 있는 부분: `useFetch`나 `useForm`처럼 거대한 컴포넌트 속 반복되는 로직을 어떻게 단위 테스트 가능한 모듈로 추출할 수 있는지 이해할 수 있습니다 [17].
+
+#### [구현/활용 도구]
+* [[TypeScript]]
+  * 연결 이유: 노후화된 JavaScript 코드베이스를 현대화할 때 정적 타입 검사를 통해 런타임 오류를 방지하기 위해 필수적으로 권장되는 도구입니다 [2, 7].
+  * 이 개념을 통해 더 깊게 이해할 수 있는 부분: 리팩터링 과정에서 발생할 수 있는 예기치 못한 데이터 구조 변화나 Props 전달 오류를 어떻게 컴파일 타임에 차단할 수 있는지 파악할 수 있습니다.
+* [[ESLint]]
+  * 연결 이유: 리팩터링 시 팀의 일관성을 유지하고, 코드 스멜 및 안티 패턴을 자동으로 식별하기 위한 정적 분석 및 컨벤션 도구입니다 [3, 18].
+  * 이 개념을 통해 더 깊게 이해할 수 있는 부분: `eslint-plugin-react-hooks` 등 플러그인을 활용해 아키텍처 규칙과 React 권장 사항을 개발 과정에서 어떻게 자동 강제할 수 있는지 확인할 수 있습니다 [3, 18].
+
+### Deeper Research Questions
+* 레거시 클래스형 컴포넌트의 생명주기 메서드(예: `componentDidUpdate`, `componentDidMount`)를 `useEffect`를 포함한 훅(Hooks) 기반으로 리팩터링할 때 가장 안전하게 부작용(Side-effect)을 제어하는 방법은 무엇인가?
+* 테스트 코드가 전무하고 컴포넌트 결합도가 높은 대규모 레거시 React 앱에서, 가장 먼저 도입해야 하는 효율적인 최소 단위 테스트 전략(예: UI 스냅샷 테스트 vs 기능 단위 테스트)은 무엇인가?
+* Context API로 무겁게 관리되어 리렌더링 이슈가 발생하는 전역 상태를 Zustand나 TanStack Query로 점진적으로 마이그레이션할 때, 전환 과정 중 상태의 동기화를 어떻게 유지할 수 있는가?
+* 하나의 컴포넌트 파일에 API 통신, 상태 변경, DOM 렌더링 로직이 혼재된 상태에서 단일 책임 원칙(SRP)을 준수하도록 로직을 쪼갤 때, 올바른 추상화 기준은 어떻게 세우는가?
+* 전체 앱을 중단하지 않고 React 버전을 올리거나 폴더 구조(Feature-Sliced Design 등)를 도입하기 위해, 기존 코드와 새로운 코드 아키텍처를 한 프로젝트 내에서 병존시키는 전략은 무엇인가?
+
+### Practical Application Contexts
+* **Implementation:** 기존에 방치된 `useState`와 `useEffect`를 활용한 데이터 페칭 로직을 Tanstack Query로 분리 및 이관하고, 인라인 스타일링이나 중구난방인 CSS를 특정 패턴 하나로 통일하는 실제적인 코드 정리 작업.
+* **System Design:** Redux에 의존하던 방대한 보일러플레이트를 제거하고, 애플리케이션의 상태를 '서버 상태(데이터 통신)'와 '클라이언트 상태(UI 토글 등)'로 설계적으로 분리함.
+* **Operation / Maintenance:** 기능 추가 프로세스를 멈추지 않고, 하나의 Store나 하나의 컴포넌트 단위로 분할하여 점진적으로 새 브랜치를 병합해가는 Git 기반의 무중단 리팩터링 파이프라인.
+* **Learning Path:** 레거시 React의 단점 분석 -> UI 및 단위 테스트 전략 수립 -> Custom Hooks 작성 및 SOLID 원칙 학습 -> 상태 관리 현대화 -> 폴더/아키텍처 설계 순으로 점진적인 심화 학습.
+* **My Project Relevance:** 오래전에 개발되어 유지보수성이 극도로 떨어지는 기존 프로젝트를 이어받아 기능 추가를 하거나 버그를 픽스해야 할 때, 코드를 안전하게 해체하고 모듈화하는 지침으로 활용.
+
+### Adjacent Topics
+* [[SOLID Principles]]
+  * 확장 방향: 리팩터링 과정에서 각 컴포넌트와 모듈이 '단일 책임(SRP)'이나 '인터페이스 분리(ISP)' 원칙을 통해 어떻게 의존성을 낮추고 유연하게 구성될 수 있는지에 대한 심화 이해.
+* [[State Management]]
+  * 확장 방향: 리팩터링 시 Redux, Context API, Zustand, TanStack Query 등 각각의 상태 관리 라이브러리가 가진 성능 특징(리렌더링 문제 해결 등)을 비교 분석하여 최적의 기술 스택을 선정하는 과정 탐구.
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Legacy React Codebase Modernization.md b/00_Raw/Legacy React Codebase Modernization.md
new file mode 100644
index 00000000..4001bf46
--- /dev/null
+++ b/00_Raw/Legacy React Codebase Modernization.md	
@@ -0,0 +1,70 @@
+# [[Legacy React Codebase Modernization]]
+
+## 📌 Brief Summary
+레거시 리액트 코드베이스 현대화(Legacy React Codebase Modernization)는 유지보수성과 확장성을 확보하기 위해 기존의 낡은 코드를 최신 리액트 표준과 아키텍처로 개선하는 과정입니다. 이 작업은 안전한 변경을 위한 단위 테스트 작성을 시작으로, 클래스형 컴포넌트의 함수형 전환, 타입스크립트(TypeScript) 도입, 그리고 서버 및 클라이언트 상태 관리 도구의 최적화를 포함합니다. 한 번에 모든 것을 다시 작성하는 위험을 피하기 위해 커스텀 훅을 활용하여 비즈니스 로직을 분리하는 등 점진적인 마이그레이션(Incremental Migration) 방식을 채택하는 것이 핵심입니다. [1-3]
+
+## 📖 Core Content
+* **테스트 기반 접근 (Test-Driven Approach)**: 
+  레거시 코드를 현대화하기 전에 가장 먼저 해야 할 일은 유닛 테스트(Unit Test)나 UI 테스트 스위트를 작성하는 것입니다. 이는 코드 구조 변경 중 기존 기능이 망가지는 것을 방지하고, 개발자가 기존 코드의 동작 방식을 정확히 이해하도록 돕는 방어선 역할을 합니다 [2, 4, 5].
+* **최신 리액트 패턴 적용**:
+  과거의 클래스 기반 컴포넌트를 함수형 컴포넌트와 훅(Hooks)으로 마이그레이션해야 합니다. 또한, 자바스크립트 기반이라면 타입스크립트(TypeScript)를 도입하여 타입 안정성을 확보하고, 불필요한 `useEffect` 사용을 제거하여 최신 리액트 및 관련 라이브러리 버전으로 업데이트해야 합니다 [3].
+* **상태 관리 도구의 분리 및 현대화**:
+  전역 클라이언트 상태와 서버 상태를 분리하는 것이 필수적입니다. 무거운 Redux 구현체를 제거하고, 서버 상태를 처리하기 위해 TanStack Query (React Query)를 추가하는 것이 권장됩니다 [3]. 남은 클라이언트의 로컬/전역 상태는 Context API나 Zustand를 활용하여 관리 범위를 명확히 합니다 [3].
+* **점진적 마이그레이션 (Incremental Migration)**:
+  애플리케이션 전체를 한 번에 재작성(Rewrite)하는 것은 위험하므로, 한 번에 하나의 상태 스토어나 모듈씩 전환하는 점진적 방식이 선호됩니다 [1]. 이를 위해 거대한 컴포넌트에서 비즈니스 로직을 분리하여 커스텀 훅(Custom Hooks)으로 추출하는 것이 리팩터링의 주요 단위가 됩니다 [6, 7].
+* **코드 품질 도구의 도입 및 표준화**:
+  일관성 없는 코드를 정리하기 위해 ESLint와 같은 정적 분석 도구(예: `eslint-plugin-react`, `eslint-plugin-react-hooks`)를 도입해야 합니다 [8]. 이와 함께 일관성 없이 작성된 CSS 규칙(외부 CSS, 컴포넌트 CSS 등)을 단일한 표준 방식으로 통일하여 예측 가능성을 높여야 합니다 [9-11].
+
+## ⚖️ Trade-offs & Caveats
+* **점진적 개선 vs 전면 재작성 (Incremental Refactoring vs. Full Rewrite)**: 
+  레거시 코드의 규모가 작다면 애플리케이션을 처음부터 완전히 새로 작성하는 것이 더 쉬울 수 있습니다 [4]. 그러나 규모가 큰 애플리케이션에서 완전한 재작성을 시도하는 것은 비즈니스 로직 누락 및 심각한 위험을 수반하므로 기능 개발과 병행할 수 있는 점진적 개선을 선택해야 합니다 [1].
+* **TypeScript 도입의 복잡성 증가**: 
+  안정성을 높이기 위해 TypeScript를 도입하는 것은 강력히 권장되지만, 익숙하지 않은 개발자에게는 인지적 오버헤드와 복잡성의 새로운 층을 추가하는 것이 될 수 있습니다. 따라서 전체 적용보다는 파일 단위로 점차적으로 도입하는 것이 더 안전한 선택일 수 있습니다 [12].
+* **상태 관리 마이그레이션 비용**: 
+  Context API에서 Zustand로의 전환은 비교적 수월하지만, 복잡도가 증가해 Zustand에서 Redux로 넘어가거나, 반대로 Redux에서 Zustand로 전환하는 과정은 코드베이스 전체의 아키텍처에 깊게 관여하므로 마이그레이션이 매우 고통스럽거나(Painful) 위험(Risky)할 수 있습니다 [13].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [관계 유형 A: 아키텍처/기반 기술]
+- [[Incremental Migration]]
+  - 연결 이유: 코드를 리팩터링할 때 반드시 따라야 하는 방법론이자 철학입니다. [1]
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 기존 애플리케이션의 동작을 망가뜨리지 않고, 단일 커스텀 훅이나 스토어 단위로 코드를 분리하며 안전하게 현대화하는 전략을 학습할 수 있습니다.
+- [[Single Responsibility Principle (SRP)]]
+  - 연결 이유: 레거시 컴포넌트가 가지는 복합적인 책임(상태 관리, 렌더링, 데이터 페칭 등)을 쪼개는 핵심 척도입니다. [14]
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 복잡하고 거대한 컴포넌트를 왜 작고 독립적인 여러 컴포넌트나 훅으로 나누어야 하는지 그 근본적인 이유를 이해할 수 있습니다.
+
+#### [관계 유형 B: 구현/활용 도구]
+- [[Unit Testing]]
+  - 연결 이유: 리팩터링 작업 전에 기존 비즈니스 로직을 보호하기 위해 선행되어야 하는 기술입니다. [2, 5]
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 안전한 코드 리팩터링 환경을 구축하고, 코드가 예상대로 동작하는지 검증하여 회귀 버그(Regression)를 방지하는 방법을 알 수 있습니다.
+- [[TanStack Query]]
+  - 연결 이유: 기존의 비효율적인 전역 상태 관리(예: Redux)에서 서버 상태 관리를 덜어내어 구조를 최신화하는 핵심 도구입니다. [3, 15]
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 클라이언트 상태와 서버 API 상태를 철저하게 분리함으로써 컴포넌트 및 로직의 결합도를 낮추는 방식을 배울 수 있습니다.
+- [[ESLint]]
+  - 연결 이유: 코드 품질과 리액트의 권장 사항(Hooks 규칙 등)을 자동으로 강제하여 기술 부채를 방지합니다. [8, 16]
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 자동화된 정적 분석을 통해 다수의 개발자가 일관성 있게 현대화된 코드를 작성하도록 관리하는 거버넌스 메커니즘을 이해할 수 있습니다.
+
+### Deeper Research Questions
+- 레거시 클래스 기반 컴포넌트를 함수형 컴포넌트와 훅(Hooks)으로 마이그레이션할 때, 부작용을 최소화할 수 있는 안전한 디자인 패턴과 점진적 적용 방법은 무엇인가?
+- 기존의 복잡한 Context API 또는 Redux 상태를 서버 상태(TanStack Query)와 클라이언트 상태(Zustand 등)로 분할할 때 발생하는 가장 흔한 충돌 포인트와 해결책은 무엇인가?
+- 대규모 JavaScript 기반 React 프로젝트에 TypeScript를 점진적으로 도입할 때, 파일 간 의존성에 따른 타입 오류 폭포(Type Error Cascade) 현상을 어떻게 억제할 것인가?
+- 단위 테스트(Unit Testing) 커버리지가 매우 낮거나 전무한 코드베이스에서, 핵심 비즈니스 로직을 파악하고 최우선적으로 테스트를 작성해야 하는 기준은 어떻게 설정해야 하는가?
+- 비대한 단일 리액트 컴포넌트를 분리할 때, 'KISS'와 'DRY' 원칙 간의 충돌(지나친 추상화로 인한 복잡도 증가)을 예방하기 위한 구체적인 가이드라인은 무엇인가?
+
+### Practical Application Contexts
+- **Implementation:** 비대해진 기존 클래스 컴포넌트를 분석하여 UI 파트와 로직 파트를 분리하고, 불필요한 `useEffect`를 걷어낸 뒤 `useMemo`, `useCallback`과 커스텀 훅을 활용하여 기능별로 재작성합니다. [3, 6]
+- **System Design:** 애플리케이션의 상태를 도메인에 따라 분리 기획합니다. UI 토글이나 테마 같은 단순 상태는 Context API를, 다이나믹한 상태는 Zustand를, API 응답 데이터는 TanStack Query로 분산 설계합니다. [3, 17, 18]
+- **Operation / Maintenance:** ESLint(eslint-plugin-react 등)를 파이프라인에 구축하여 개발자들이 기존 스타일이 아닌 새로운 React Hooks의 규칙을 강제적으로 준수하도록 운영합니다. [8]
+- **Learning Path:** 리액트의 기본 원리 학습 후 -> 소형 컴포넌트 단위 테스트 작성 방법 -> TypeScript 적용법 -> 클라이언트/서버 상태 관리 도구 패러다임 차이로 확장해 나가는 순서로 학습합니다. [2, 3, 12]
+- **My Project Relevance:** 현재 유지보수하고 있는 복잡한 기존 React 시스템의 개편 작업에서 '테스트 커버리지 확보 -> TS 도입 -> 상태 도구 분리 -> 커스텀 훅 추상화' 순의 안정적인 마이그레이션 로드맵을 구축할 수 있습니다.
+
+### Adjacent Topics
+- [[Feature-Sliced Design]]
+  - 확장 방향: 레거시 코드베이스의 폴더 및 파일 구조를 기능(Feature)과 도메인 중심으로 철저히 분리하여, 리팩터링 이후의 지속 가능한 폴더 구조 아키텍처로 확장 학습할 수 있습니다.
+- [[React Compiler]]
+  - 확장 방향: React 19의 등장과 함께, 레거시 코드에 수동으로 작성된 메모이제이션(`React.memo`, `useMemo`)을 자동으로 최적화하는 툴링이 어떻게 적용될 수 있는지 성능 관점에서 탐구할 수 있습니다.
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Legacy React Codebase Refactoring.md b/00_Raw/Legacy React Codebase Refactoring.md
new file mode 100644
index 00000000..5d383037
--- /dev/null
+++ b/00_Raw/Legacy React Codebase Refactoring.md	
@@ -0,0 +1,70 @@
+# [[Legacy React Codebase Refactoring]]
+
+## 📌 Brief Summary
+레거시 React 코드베이스 리팩토링은 기존 소프트웨어의 동작을 온전히 보존하면서, 코드의 가독성, 유지보수성, 확장성을 개선하기 위해 내부 구조를 재설계하는 과정입니다 [1]. 이 과정은 회귀 오류를 막기 위한 단위 테스트(Unit Test) 작성부터 시작하여, 클래스 기반 컴포넌트를 함수형 및 훅(Hooks)으로 전환하고, 상태 관리 도구를 현대화(예: Redux에서 TanStack Query나 Zustand로 마이그레이션)하는 작업을 포함합니다 [2, 3]. 성공적인 리팩토링은 전체를 한 번에 갈아엎는 재작성(Rewrite)을 피하고, 커스텀 훅을 통해 UI와 비즈니스 로직을 분리하는 등 점진적(Incremental)인 최적화를 수행하는 데 초점을 맞춥니다 [1, 4].
+
+## 📖 Core Content
+*   **비즈니스 로직 파악 및 단위 테스트 선행:**
+    레거시 리팩토링의 첫걸음은 애플리케이션의 비즈니스 로직과 전역 UI 스토어에 보관된 데이터를 파악하여 멘탈 모델(Mental model)을 그리는 것입니다 [5]. 코드를 수정하기 전 단위 테스트(Unit tests)나 UI 테스트 제품군을 먼저 작성하여, 리팩토링 과정(TS 변환, 훅 전환, 라이브러리 업그레이드 등)에서 기존 기능이 손상되지 않았음을 검증해야 합니다 [2, 6, 7].
+*   **모던 React 패러다임으로의 전환:**
+    기존 코드베이스에 존재하는 클래스형 컴포넌트를 함수형 컴포넌트와 훅으로 마이그레이션합니다 [3]. 프로젝트가 JavaScript로만 이루어져 있다면 TypeScript로 점진적으로 전환하고, 오래되거나 사용 중단(deprecated)된 라이브러리를 업데이트합니다 [3]. 또한, 불필요한 `useEffect` 사용을 모두 제거하고, 코드에 혼재되어 있는 CSS 스타일링 방식(외부 CSS, 인라인 style, sx 등)을 한두 가지의 표준 방식(예: CSS modules)으로 통일합니다 [3, 8, 9].
+*   **상태 관리 도구의 책임 분리:**
+    과거 단일 전역 스토어(예: Redux)에 뭉쳐있던 상태들을 분리합니다. 서버 상태(Server state) 관리를 위해서는 TanStack Query를 추가하여 Redux 의존도를 줄이고, 클라이언트 측 전역 상태는 Context API나 Zustand로 관리하며, 지역 상태(Local state)는 가급적 각 컴포넌트 내부로 격리하는 것이 모범 사례입니다 [3].
+*   **점진적 마이그레이션(Incremental Migration)과 커스텀 훅:**
+    리팩토링 시 애플리케이션 전체를 한 번에 재작성(rewrite)하는 것은 매우 위험합니다. "재작성이 아닌 리팩토링(refactor, do not rewrite)" 철학에 따라, 하나의 스토어나 단순한 기능(예: 알림)부터 시작해 결제 흐름과 같은 복잡한 도메인으로 하나씩 점진적 마이그레이션을 진행해야 합니다 [1]. 이 과정에서 '커스텀 훅'을 주요 리팩토링 단위로 사용하여, 거대한 컴포넌트에서 데이터 페칭이나 폼 처리와 같은 비즈니스 로직을 분리해 모듈성과 테스트 용이성을 높입니다 [4].
+*   **규칙 기반의 관리 및 자동화:**
+    ESLint(eslint-plugin-react, eslint-plugin-react-hooks 등)를 도입하여 코드 스타일과 모범 사례를 강제하고, 팀 차원의 일관된 코드 품질을 유지합니다 [10]. 더 나아가 Claude Code 같은 AI 도구를 활용해 코드베이스를 평가받고 작은 단위의 PR(Pull Request)을 생성하게 함으로써 리팩토링 시간을 단축할 수 있습니다 [11, 12].
+
+## ⚖️ Trade-offs & Caveats
+*   **전면 재작성(Rewrite) vs 점진적 리팩토링:** 
+    기존 앱의 규모가 매우 작다면 오히려 바닥부터 새 앱을 작성하는 것이 리팩토링보다 쉽고 빠를 수 있습니다 [6]. 그러나 규모가 큰 앱의 경우 재작성은 리스크가 너무 크므로, 기능 개발을 멈추지 않은 상태에서 아키텍처를 현대화하는 '점진적 마이그레이션' 방식을 택해야 합니다 [1].
+*   **추상화와 단순성의 충돌 (DRY vs KISS):**
+    DRY(Don't Repeat Yourself) 원칙에 따라 중복 코드를 추출하는 것은 좋지만, 과도한 추상화는 원본 코드를 여러 번 반복하는 것보다 오히려 디버깅과 이해를 더 어렵게 만들어 KISS(Keep It Simple, Stupid) 원칙을 위배하게 될 부작용이 있습니다 [13]. 따라서 패턴이 최소 세 번 이상 반복되기 전까지는 조기 최적화나 복잡한 추상화를 피하는 것이 좋습니다 [13].
+*   **새로운 도구(TypeScript 등) 도입의 오버헤드:**
+    타입스크립트를 추가하거나 새로운 상태 관리 패턴을 입히는 것은 안전성을 높이지만, 코드베이스에 복잡성을 더하고 팀원들에게 인지적 부하를 줍니다 [14]. 따라서 개발자들의 숙련도를 고려하여 JS 파일을 TS 파일로 한 개씩 점진적으로 변환하는 식의 접근이 권장됩니다 [14].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [관계 유형 A (아키텍처/기반 기술)]
+- [[Feature-Sliced Design]]
+  - 연결 이유: 레거시 코드의 난해한 폴더 구조를 해결하기 위해, 코드를 기술적 계층이 아닌 비즈니스 기능(Feature)과 책임 범위에 따라 분할하는 최신 아키텍처 방법론이기 때문입니다 [15, 16].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 거대하고 강하게 결합된 컴포넌트들을 응집도 높은 모듈로 쪼개는 기준과 단방향 의존성 구조를 설계하는 방법 [16].
+- [[SOLID Principles]]
+  - 연결 이유: 단일 책임 원칙(SRP) 등은 복잡하게 얽힌 컴포넌트 로직을 더 작고 한 가지 일만 하는 컴포넌트로 리팩토링하는 데 핵심적인 가이드라인을 제공합니다 [17].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 거대한 컴포넌트가 언제, 그리고 왜 훅과 하위 컴포넌트로 분리되어야 하는지에 대한 객관적 판단 기준 [11, 17].
+
+#### [관계 유형 B (구현/활용 도구)]
+- [[Unit Testing]]
+  - 연결 이유: 코드를 리팩토링할 때 기존 로직이 망가지지 않았음을 보장하기 위해 선행되어야 하는 가장 중요한 실무 도구이기 때문입니다 [2, 7].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 코드베이스를 안전하게 해체하고 모듈화하기 위한 테스트 기반 접근법과 회귀 버그 방어 전략 [7].
+- [[Zustand]]
+  - 연결 이유: 기존 레거시 앱에서 흔히 발생하는 Context API의 불필요한 렌더링 문제나, 무겁고 복잡한 Redux 코드를 리팩토링할 때 가장 권장되는 경량 상태 관리 라이브러리이기 때문입니다 [3, 18, 19].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 상태를 분리하고 셀렉터(Selector) 패턴을 적용하여 글로벌 상태 변경 시 발생하는 성능 병목을 해결하는 원리 [20, 21].
+
+### Deeper Research Questions
+
+- 레거시 클래스형 컴포넌트의 라이프사이클 메서드(`componentDidMount`, `componentDidUpdate` 등)를 함수형 컴포넌트의 훅(`useEffect` 등)으로 변환할 때, 논리적 오류 없이 1:1로 매핑하거나 구조를 개선하는 구체적인 패턴은 무엇인가?
+- 점진적 마이그레이션을 진행할 때, 레거시 시스템의 Redux 스토어와 새로운 시스템의 Zustand/TanStack Query 상태를 시스템 장애나 충돌 없이 공존시키는 방법은 무엇인가?
+- UI 리팩토링 과정에서 레이아웃이나 색상 등 의도치 않은 시각적 회귀(Visual regression)를 방지하기 위해 Storybook 및 Chromatic과 같은 도구를 어떻게 CI 파이프라인에 통합할 수 있는가?
+- FSD(Feature-Sliced Design) 아키텍처를 기존 레거시 코드베이스에 적용하려 할 때, 여러 기능(Feature) 간에 교차하여 사용되는 횡단 관심사(Cross-cutting concerns)는 어디에 어떻게 배치해야 하는가?
+- React 코드베이스에서 `useEffect`의 오용이 대표적인 안티패턴으로 꼽히는 이유는 무엇이며, 이를 식별해 내고 대체 패턴(파생 상태, 이벤트 핸들러 등)으로 리팩토링하는 기준은 무엇인가?
+
+### Practical Application Contexts
+
+- **Implementation:** 거대한 단일 파일로 작성된 컴포넌트(300줄 이상)나 혼재된 스타일(인라인, 외부 파일)을 가진 레거시 코드를 식별한 후, ESLint 린터를 추가해 규칙을 세우고 공통 로직을 커스텀 훅으로 분리하는 작업에 즉시 적용할 수 있습니다.
+- **System Design:** 프로젝트의 폴더 구조를 기존의 기술 중심(components, hooks, styles) 구조에서 도메인 및 기능 중심(features 내부에 각 도메인 배치) 구조로 재편성하여 확장성을 갖춘 아키텍처로 탈바꿈시킵니다.
+- **Operation / Maintenance:** 기능 배포를 중단하지 않고 운영 중인 시스템에서 "한 번에 하나의 스토어" 단위로 코드를 점진적으로 리팩토링하며, 변경 사항에 대해 CI/CD 환경에서 테스트 통과 여부를 검증합니다.
+- **Learning Path:** React 기초 장난감 앱(Toy app)을 직접 만들어 생태계를 이해한 뒤, SOLID 및 DRY 원칙을 학습하고, 커스텀 훅과 테스트 작성법을 익힌 후 실제 레거시 코드를 개선하는 방향으로 학습 로드맵을 설계합니다.
+- **My Project Relevance:** 다른 개발자들이 작성한 오래된 코드를 인수받아 유지보수해야 할 때, 코드를 무작정 뜯어고치는 대신 비즈니스 로직을 우선 매핑하고 단위 테스트를 짜며 AI 도구의 도움을 받아 점진적으로 구조를 정돈하는 실무 지침으로 활용할 수 있습니다.
+
+### Adjacent Topics
+
+- [[TanStack Query (React Query)]]
+  - 확장 방향: 기존의 전역 상태 관리 도구(Redux)에서 관리하던 '서버 상태'를 떼어내어, 어떻게 효율적으로 데이터 페칭(fetching), 캐싱, 그리고 동기화 처리를 자동화할 수 있는지 탐구합니다.
+- [[React Performance Optimization]]
+  - 확장 방향: 코드를 리팩토링하는 과정에서 `React.memo`, `useMemo`, `useCallback`과 같은 메모이제이션 기법을 적재적소에 배치해 컴포넌트의 렌더링 성능을 극대화하는 방안으로 이해를 넓힙니다.
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Memoization.md b/00_Raw/Memoization.md
new file mode 100644
index 00000000..ae189b17
--- /dev/null
+++ b/00_Raw/Memoization.md
@@ -0,0 +1,61 @@
+# [[Memoization]]
+
+## 📌 Brief Summary
+Memoization(메모이제이션)은 입력값이 변경되지 않았을 때 계산 결과나 컴포넌트의 렌더링 결과를 캐싱하여 재사용하는 성능 최적화 기법이다 [1]. React에서는 `React.memo`, `useMemo`, `useCallback`과 같은 API를 통해 수동으로 제어할 수 있으며, 불필요한 리렌더링을 방지하여 애플리케이션의 반응성을 향상시킨다 [1, 2]. 최근에는 React Compiler를 통해 빌드 타임에 자동으로 더 세밀한 단위의 메모이제이션을 삽입하여 수동 관리의 복잡성을 줄이는 방식도 도입되었다 [2-4].
+
+## 📖 Core Content
+*   **수동 메모이제이션 기법:** 개발자는 컴포넌트 전체의 렌더링 결과를 캐싱하기 위해 `React.memo`를, 계산 비용이 높은 파생 데이터(derived data)를 캐싱하기 위해 `useMemo`를, 함수 참조를 캐싱하기 위해 `useCallback`을 사용한다 [1, 2]. `React.memo()`는 고차 컴포넌트(HOC)로 작동하며, 전달받는 prop이 변경되지 않으면 렌더링을 건너뛰고 마지막 결과를 재사용한다 [5, 6].
+*   **참조 안정성(Reference Stability)과 얕은 비교(Shallow Comparison):** React는 리렌더링 여부를 결정할 때 prop에 대해 얕은 비교를 수행한다 [7]. 내용이 동일하더라도 매 렌더링마다 새롭게 생성되는 객체나 인라인 함수는 새로운 참조로 인식되어 메모이제이션을 무력화한다 [7-9]. 따라서 `useMemo`와 `useCallback`은 이러한 값과 함수의 참조를 안정적으로 유지하여 하위 컴포넌트의 불필요한 렌더링을 방지하는 데 핵심적인 역할을 한다 [7, 10].
+*   **자동화된 메모이제이션 (React Compiler):** React Compiler는 빌드 시 코드를 분석하고 자동으로 메모이제이션 로직을 삽입하는 최신 도구이다 [2, 3]. 컴포넌트 전체를 래핑하는 기존 수동 방식과 달리, 개별 JSX 요소와 연산을 독립적으로 캐싱하는 더 세밀한 수준(granular level)의 최적화를 수행한다 [4, 11]. 이를 통해 개발자는 메모이제이션 코드로 인한 혼란 없이 직관적이고 깔끔한 React 코드를 작성할 수 있다 [3, 11].
+*   **적용 기준:** 메모이제이션은 순수 컴포넌트이거나 빈번하고 피할 수 없는 리렌더링이 발생하는 경우, 복잡한 DOM을 렌더링하거나 값비싼 연산(정렬, 필터링 등)을 수행할 때 적용해야 한다 [6, 12]. 측정 없이 무분별하게 적용하는 것은 지양해야 하며, React Profiler 등을 통해 실질적인 성능 저하가 증명되었을 때만 사용해야 한다 [12, 13].
+
+## ⚖️ Trade-offs & Caveats
+*   **비교 연산 오버헤드:** 메모이제이션은 공짜가 아니다. React는 이전 prop을 저장하고, 새로운 prop과 비교하며, 업데이트 여부를 결정하는 오버헤드를 부담해야 한다 [14]. 렌더링 자체가 빠르고 prop이 자주 변경되는 컴포넌트의 경우, 메모이제이션을 위한 비교 단계가 실제 렌더링보다 더 많은 컴퓨팅 자원을 소모할 수 있다 [12, 14].
+*   **수동 관리의 한계:** 수동 메모이제이션은 코드를 복잡하게 만들고, 종속성 배열을 잘못 관리하거나 객체 참조를 실수로 갱신하여 메모이제이션 체인을 깨뜨리는 등의 휴먼 에러를 유발하기 쉽다 [2, 15].
+*   **React Compiler의 제약 사항:**
+    *   **React 규칙의 엄격한 준수:** 컴파일러가 정상적으로 최적화를 수행하려면 불변성 유지, 렌더링 중 부작용(Side effects) 방지 등 "Rules of React"를 엄격히 따라야 한다 [16, 17].
+    *   **서드파티 라이브러리 호환성:** 매 렌더링마다 새로운 객체 참조를 반환하는 커스텀 훅(예: TanStack Query의 `useMutation`, React Router의 `useLocation` 등)은 컴파일러의 메모이제이션 체인을 단절시킨다 [18, 19]. 이 경우 결국 수동 메모이제이션이 필요할 수 있다 [19, 20].
+    *   **디버깅 가시성 저하:** 컴파일러는 블랙박스처럼 동작하기 때문에, 컴포넌트가 예상치 않게 리렌더링될 때 최적화 실패 원인을 코드 상에서 즉각적으로 파악하기 어렵다 [21]. 또한 React 개발자 도구의 'Memo ✨' 배지는 컴파일러가 코드를 처리했음을 의미할 뿐, 런타임에 실제로 최적화가 성공하여 리렌더링이 방지되었음을 보장하지 않아 혼동을 줄 수 있다 [18].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [아키텍처/기반 기술]
+- [[React Compiler]]
+  - 연결 이유: 수동 메모이제이션의 복잡성을 줄이고 빌드 타임에 자동으로 세밀한 메모이제이션 로직을 삽입하여 성능을 최적화하는 도구이다 [3, 4].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 개발자가 수동으로 작성하던 `useMemo`와 `useCallback`이 빌드 프로세스 내에서 어떻게 추상화되고 최적화되는지 파악할 수 있다 [4, 11, 20].
+
+- [[Shallow Comparison]] (얕은 비교)
+  - 연결 이유: `React.memo`가 리렌더링 여부를 판단할 때 기본적으로 사용하는 평가 방식이다 [6, 7].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 내용이 같은 객체나 인라인 함수가 왜 새로운 prop으로 취급되어 메모이제이션을 실패하게 만드는지 그 원리를 이해할 수 있다 [7-9].
+
+#### [구현/활용 도구]
+- [[React Profiler]] & [[why-did-you-render]]
+  - 연결 이유: 컴포넌트의 렌더링 횟수, 소요 시간, 그리고 불필요한 렌더링 트리거를 식별하여 메모이제이션이 필요한 지점을 찾아내는 진단 도구들이다 [22-25].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 맹목적인 최적화 대신 객관적 측정 데이터에 기반한 전략적 메모이제이션 적용 방법을 배울 수 있다 [13, 26].
+
+### Deeper Research Questions
+- React Compiler의 자동화된 캐싱 메커니즘은 기존의 컴포넌트 레벨 메모이제이션(`React.memo`)과 비교할 때, 어떻게 개별 JSX 요소 수준의 세밀함(granularity)을 달성하는가?
+- `React.memo`에 사용자 정의 비교 함수(Custom Comparison Function)를 적용하는 깊은 비교 방식이 얕은 비교에 따른 렌더링 비용 절감보다 성능상 불리해지는 임계점은 어디인가?
+- TanStack Query나 Material UI와 같이 불안정한(Unstable) 객체 참조를 반복적으로 반환하는 라이브러리를 사용할 때, React Compiler의 한계를 우회하고 불필요한 리렌더링을 막는 최적의 아키텍처 패턴은 무엇인가?
+- `useCallback`과 `useMemo`를 오남용하여 성능 오버헤드를 유발하는 주요 안티패턴은 무엇이며, 프로파일링을 통해 메모이제이션의 손익분기점을 어떻게 판단할 수 있는가?
+- React Context API의 상태 업데이트로 발생하는 전역적인 리렌더링 폭포(Re-render Cascade) 현상을 방지하기 위해, Context 분리(Splitting)와 메모이제이션 기법을 어떻게 조합해야 하는가?
+
+### Practical Application Contexts
+- **Implementation:** 계산 비용이 높은 필터링 로직에 `useMemo`를 적용하고, 하위의 메모이제이션된 컴포넌트로 전달되는 이벤트 핸들러에는 `useCallback`을 적용해 참조 안정성을 보장한다 [12, 27]. JSX 내의 익명 함수 사용을 지양하여 렌더링마다 새로운 참조가 생성되는 것을 막는다 [9, 28].
+- **System Design:** 프로젝트에 React Compiler를 도입하기 전, 코드베이스가 "Rules of React"를 준수하도록 `eslint-plugin-react-hooks`를 설정하여 린팅을 통해 코드를 통제한다 [17].
+- **Operation / Maintenance:** 지속적인 성능 모니터링을 위해 개발 중에는 React Profiler와 `why-did-you-render`를 사용해 불필요한 렌더링을 잡고, 프로덕션 환경에서는 INP(Interaction to Next Paint) 같은 Core Web Vitals 지표를 추적해 메모이제이션의 실질적 이점을 확인한다 [22-24, 29].
+- **Learning Path:** 리렌더링의 4가지 주요 원인(State, Props, Context, Parent Render)을 파악하고 [30], 얕은 비교의 원리를 학습한 뒤 `React.memo`, `useMemo`의 수동 적용법을 거쳐 React Compiler의 동작 원리를 이해하는 순서로 학습한다 [3, 7, 30].
+- **My Project Relevance:** 복잡한 대시보드나 리스트 등에서 데이터를 필터링하거나 UI와 상호작용할 때 발생하는 심각한 화면 끊김 현상과 메모리 누수를 해결하기 위해 이 원리들을 도입할 수 있다 [12, 31].
+
+### Adjacent Topics
+- [[Code Splitting & Lazy Loading]]
+  - 확장 방향: 메모이제이션이 런타임에 불필요한 컴포넌트 재렌더링을 방지한다면, 이 기법은 애플리케이션 초기 로드 시 JavaScript 번들 크기를 줄여 성능을 끌어올리는 렌더링/로딩 아키텍처 최적화 기법이다 [7, 32, 33].
+- [[State Management Libraries (Zustand/Jotai)]]
+  - 확장 방향: 잦은 상태 변경으로 인한 Context API의 광범위한 리렌더링을 방지하기 위해, 메모이제이션 대신 Selector(선택자) 패턴을 사용하여 상태의 특정 부분만 구독하게 만드는 대안적 상태 관리 기법이다 [34, 35].
+- [[Concurrent Rendering]]
+  - 확장 방향: 메모이제이션으로도 해결하기 벅찬 무거운 UI 렌더링이 발생할 때, `useTransition` 및 `useDeferredValue`를 사용하여 렌더링의 우선순위를 조정하고 UI의 반응성을 유지하는 진보된 성능 최적화 방법론이다 [36-38].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Memory Leak Detection.md b/00_Raw/Memory Leak Detection.md
new file mode 100644
index 00000000..5ebcc2c6
--- /dev/null
+++ b/00_Raw/Memory Leak Detection.md	
@@ -0,0 +1,73 @@
+# [[Memory Leak Detection]]
+
+## 📌 Brief Summary
+메모리 누수(Memory Leak)란 애플리케이션이 메모리를 할당한 후 해당 메모리가 더 이상 필요하지 않음에도 불구하고 해제하지 않아 발생하는 현상입니다 [1]. 이로 인해 시간이 지남에 따라 메모리 소비가 지속적으로 증가하며, 결국 성능 저하, 브라우저 탭 멈춤 또는 크래시 등을 유발하게 됩니다 [2]. 주로 문서에서 제거된 DOM 노드, 정리되지 않은 이벤트 리스너, 클로저에 의해 의도치 않게 유지되는 객체 참조 등이 주요 원인으로 작용합니다 [3, 4].
+
+## 📖 Core 소스 Content
+**증상 및 식별**
+*   메모리 누수는 애플리케이션의 성능이 시간이 지남에 따라 점진적으로 저하되거나, 메모리 사용량이 안정화(plateau)되지 않고 계속 증가하는 증상으로 나타납니다 [1, 2, 5].
+*   Chrome Task Manager를 사용해 실시간 메모리 사용량을 확인할 수 있습니다. 'Memory footprint'는 DOM 노드와 같은 OS 메모리를 의미하며, 'JavaScript Memory'의 괄호 안 숫자는 연결된(reachable) 객체들이 사용하는 JS 힙(heap)의 크기를 나타내어, 이 수치가 계속 증가하면 누수일 가능성이 높습니다 [6, 7].
+
+**디버깅 및 분석 도구**
+*   **Heap Snapshots (힙 스냅샷):** Chrome DevTools의 Memory 패널을 이용해 특정 시점의 메모리 분포를 캡처합니다 [8, 9]. 의심되는 작업을 수행하기 전후로 스냅샷을 찍고 비교(Comparison view)하여 양의 Delta 값을 가지는 객체를 식별할 수 있습니다 [9]. 'Detached' 필터 검색을 통해 DOM 트리에서 분리되었으나 JavaScript 참조로 인해 메모리에 남아있는 노드를 찾을 수 있습니다 [3, 8].
+*   **Allocation Timeline (할당 타임라인):** 실시간 메모리 할당 패턴을 분석합니다 [10, 11]. 파란색 막대는 새로운 할당을, 회색 막대는 해제된 메모리를 나타내며, 파란색 막대가 지속적으로 회색으로 변하지 않으면 누수 객체임을 암시합니다 [11].
+*   **Performance Recordings:** 시간 경과에 따른 페이지의 메모리 사용량을 시각화하며, 노드 수나 JS 힙 그래프가 우상향하는 패턴을 보일 때 누수를 의심할 수 있습니다 [12, 13].
+
+**주요 발생 패턴**
+*   **Detached DOM Nodes:** DOM 문서에서 제거되었으나 JavaScript 내 변수 등에 의해 참조가 유지되어 가비지 컬렉터가 수집하지 못하는 노드입니다 [3, 14].
+*   **이벤트 리스너 및 구독 누적:** 컴포넌트 마운트 해제 시 리스너나 옵저버블 구독을 정리(cleanup)하지 않는 경우 발생합니다 (예: React의 `useEffect` 정리 함수 누락, Angular의 구독 해제 누락) [3, 15, 16].
+*   **클로저(Closure) 유지:** 클로저가 부모 스코프의 변수를 살려두어 불필요하게 큰 객체 참조가 유지되는 경우 발생합니다 [4].
+
+**예방 전략**
+*   데이터 캐싱 시 가비지 컬렉션을 방해하지 않도록 객체 대신 `WeakMap`을 사용합니다 [16].
+*   개발 과정 또는 CI 파이프라인에 Puppeteer를 활용한 자동화된 메모리 누수 감지 테스트를 통합합니다 [16].
+
+## ⚖️ Trade-offs & Caveats
+*   **메모리 팽창(Bloat)과의 구별:** 애플리케이션 성능이 시간이 지남에 따라 나빠지는 메모리 누수와 달리, 단순히 최적화되지 않아 지속적으로 성능이 나쁜 '메모리 팽창(Memory Bloat)'을 구별해야 합니다 [5]. 이 기준은 기기 성능에 따라 달라지므로, 대상 사용자의 기기 환경을 고려한 측정 기준이 필요합니다 [17].
+*   **분석 과정의 복잡성:** 힙 스냅샷을 찍고 분석하는 과정은 로딩 처리에 시간이 소요될 수 있으며, 가비지 컬렉션(GC) 루트로부터의 거리와 Retainer path를 분석하는 것은 원인을 찾는 데 추가적인 학습 곡선이 요구됩니다 [4, 8].
+*   **강제 GC의 필요성:** 정확한 메모리 누수 식별 및 패치 후 확인을 위해서는 스냅샷을 캡처하거나 성능 녹화를 시작하기 전후에 반드시 수동으로 강제 가비지 컬렉션(휴지통 아이콘 클릭 등)을 실행하여, 정상적으로 해제된 객체를 누수 데이터에서 배제해야 합니다 [9, 12, 18].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [분석 및 모니터링 도구]
+- [[Chrome DevTools]]
+  - 연결 이유: Memory 패널의 Heap Snapshot, Allocation Timeline 등 메모리 누수를 진단하기 위한 핵심 기능을 제공하는 필수 환경입니다 [8-10].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 브라우저 내부에서 객체 메모리가 어떻게 할당되고, GC 루트가 참조를 어떻게 추적하는지에 대한 실제적 디버깅 흐름.
+
+#### [주요 누수 원인/아키텍처]
+- [[Detached DOM Nodes]]
+  - 연결 이유: DOM 트리에선 제거되었으나 JS 코드에서 참조를 유지해 가비지 컬렉터가 수집하지 못하는, 가장 대표적인 메모리 누수 패턴입니다 [3, 14].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 프런트엔드 애플리케이션(특히 SPA)에서 UI 업데이트 및 컴포넌트 마운트 해제 시 발생하는 메모리 낭비 메커니즘.
+- [[Garbage Collection]]
+  - 연결 이유: JS는 가비지 컬렉터를 통해 사용되지 않는 메모리를 자동으로 회수하지만, GC 루트(root)에 참조가 남아있으면 이 과정이 방해를 받아 누수가 발생합니다 [1, 4].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: Shallow size와 Retained size의 차이점 및 메모리 관리의 근본적인 한계 [18].
+
+#### [예방 및 캐싱 전략]
+- [[WeakMap]]
+  - 연결 이유: 캐시를 구현할 때, 강한 참조를 남기지 않아 가비지 컬렉션을 방해하지 않는 이상적인 메모리 관리 기법으로 제시됩니다 [16].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: JavaScript 환경에서 메모리를 안전하게 관리하며 데이터를 캐싱하는 고급 아키텍처 패턴.
+
+### Deeper Research Questions
+- Chrome DevTools의 힙 스냅샷(Heap Snapshot)에서 명시되는 Shallow Size와 Retained Size의 정확한 차이점은 무엇이며, 디버깅 과정에서 각각 어떻게 활용되는가?
+- React의 `useEffect` 클린업(cleanup) 함수 누락이 프런트엔드에서 메모리 누수를 유발하는 기술적 원리는 무엇이며, 이를 방지하기 위한 프레임워크별 모범 사례는 무엇인가?
+- 서버 사이드(Node.js) 애플리케이션에서 발생하는 메모리 누수는 클라이언트 사이드(브라우저) 환경과 비교했을 때 원인 및 디버깅 방법(V8 inspector protocol 활용) 측면에서 어떤 차이가 있는가?
+- Puppeteer를 활용한 자동화된 메모리 누수 테스트 스크립트를 CI/CD 파이프라인에 구축할 때 유의해야 할 기술적 제약 사항은 무엇인가?
+- 메모리 누수(Memory Leak)와 메모리 팽창(Memory Bloat)을 개발 과정에서 조기에 식별하고 구별하기 위한 가장 정량적이고 신뢰할 수 있는 지표는 무엇인가?
+
+### Practical Application Contexts
+- **Implementation:** React, Vue 등의 SPA 프레임워크 개발 시, 컴포넌트가 언마운트되는 시점(`useEffect` return 함수, `beforeUnmount` 등)에 이벤트 리스너와 타이머, 옵저버블 구독을 명시적으로 해제하는 클린업 코드를 작성합니다 [15, 16].
+- **System Design:** 장기 실행되는 캐시 시스템 구축 시, 누수로 인한 성능 저하를 방지하기 위해 일반 객체(Object) 대신 `WeakMap`을 도입하여 GC가 정상적으로 이루어지도록 설계합니다 [16].
+- **Operation / Maintenance:** 프로덕션 환경의 복잡한 사용자 상호작용 후 성능 저하가 보고되면, Chrome Task Manager와 Performance 탭을 사용해 주기적인 강제 GC 이후에도 우상향하는 'JavaScript Memory' 지표를 확인하는 유지보수 절차를 수립합니다 [6, 7, 12].
+- **Learning Path:** Chrome DevTools의 'Memory' 탭에서 스냅샷을 캡처하고 'Comparison' 뷰를 통해 'Delta' 및 'Retained Size'를 분석하는 실습을 거쳐, 메모리 성능 개선의 기초를 다집니다 [9, 18].
+- **My Project Relevance:** 모바일이나 저사양 기기에서 사용자들의 대시보드 무한 스크롤 및 화면 전환 중 앱 크래시 현상이 발생할 경우, Detached DOM 또는 쌓여 있는 이벤트 리스너가 있는지 타임라인 프로파일링을 통해 점검해야 합니다 [2, 3, 14].
+
+### Adjacent Topics
+- [[Core Web Vitals]]
+  - 확장 방향: 메모리 누수로 인해 브라우저의 메인 스레드가 과부하에 걸리거나 가비지 컬렉션이 빈번하게 발생하여 실행을 중단시킬 때, 이것이 INP(Interaction to Next Paint)와 같은 사용자 체감 성능 지표에 어떻게 치명적인 영향을 미치는지 분석합니다.
+- [[React Server Components (RSC)]]
+  - 확장 방향: 클라이언트 측에 전송되는 JavaScript의 양 자체를 줄이고 상호작용 상태 관리를 서버로 옮김으로써, 브라우저 단의 메모리 누수 및 팽창 위험을 아키텍처 수준에서 어떻게 경감시킬 수 있는지 탐구합니다.
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Memory Leak.md b/00_Raw/Memory Leak.md
new file mode 100644
index 00000000..af3ca129
--- /dev/null
+++ b/00_Raw/Memory Leak.md	
@@ -0,0 +1,78 @@
+# [[Memory Leak]]
+
+## 📌 Brief Summary
+메모리 누수(Memory Leak)란 애플리케이션이 메모리를 할당한 후 더 이상 필요하지 않음에도 불구하고 이를 해제하지 않아 메모리에 계속 축적되는 현상이다 [1]. 자바스크립트의 가비지 컬렉터(Garbage Collector)는 사용하지 않는 메모리를 자동으로 회수하지만, 변수 등에 참조가 남아있을 경우 이를 회수할 수 없어 누수가 발생한다 [1]. 이로 인해 애플리케이션을 장시간 사용할수록 메모리 사용량이 점진적으로 증가하며, 성능 저하, 탭의 멈춤 현상, 심각한 경우 앱 충돌(Crash)을 유발하게 된다 [2-4].
+
+## 📖 Core Content
+*   **발생 메커니즘과 주요 원인 패턴**
+    자바스크립트 및 React 애플리케이션에서 메모리 누수는 주로 불필요하게 남아있는 참조(Reference) 때문에 발생한다 [1]. 
+    대표적인 패턴은 다음과 같다.
+    *   **분리된 DOM 노드(Detached DOM Nodes):** DOM 트리에서는 제거되었으나, 자바스크립트 코드 내의 변수 등에서 여전히 해당 노드를 참조하고 있어 가비지 컬렉션이 불가능한 경우이다 [5, 6].
+    *   **이벤트 리스너 누적(Event Listener Accumulation):** 컴포넌트가 언마운트(Unmount)될 때 등록되었던 이벤트 리스너를 적절히 해제하지 않으면 메모리에 계속 쌓이게 된다 [6]. React의 경우 `useEffect` 내에서 구독(Subscription)이나 리스너를 생성한 뒤 정리(Cleanup) 함수를 반환하지 않을 때 빈번하게 발생한다 [7-9].
+    *   **클로저를 통한 참조 유지(Closure-Retained References):** 자바스크립트 클로저가 부모 스코프의 변수를 계속 살려두어, 불필요하게 거대한 객체가 메모리를 차지하게 만들 수 있다 [10].
+
+*   **진단 및 분석 방법**
+    메모리 누수를 파악하기 위해 Chrome DevTools의 Memory 패널을 핵심적으로 사용할 수 있다 [11].
+    *   **힙 스냅샷(Heap Snapshots):** 특정 시점의 메모리 상태를 촬영하여 비교(Comparison view)할 수 있다. 두 스냅샷 사이에서 꾸준히 양수 델타(Delta) 값을 갖는 객체를 찾아 누수를 판별하며, 'Detached'로 검색하여 분리된 DOM 트리를 찾아낸다 [11, 12]. 객체를 선택한 후 'Retainers' 패널을 통해 어떤 참조가 해당 객체를 메모리에 붙잡고 있는지 추적할 수 있다 [10, 13].
+    *   **할당 타임라인(Allocation Timelines):** 애플리케이션과 상호작용할 때 실시간으로 메모리 할당 패턴을 확인한다. 파란색 막대로 표시된 할당 내역이 가비지 컬렉션 후에도 회색으로 변하지 않고 영구적으로 남는다면 누수로 의심할 수 있다 [14-16].
+    *   **성능 모니터링:** Chrome 작업 관리자(Task Manager)나 Performance 패널을 통해 자바스크립트 힙(JS heap) 크기나 노드 개수가 작업 이후에도 이전보다 증가된 상태로 끝나는지 확인한다 [17-19].
+
+*   **해결 및 예방 전략**
+    메모리 누수를 해결하기 위해 분리된 객체나 노드를 참조하는 자바스크립트 변수를 찾아, 해당 참조가 더 이상 필요 없을 때 제거해야 한다 [13]. 객체 기반의 캐시를 구현할 때는 가비지 컬렉션을 방해하지 않는 `WeakMap`을 사용하는 것이 권장된다 [9]. React 프레임워크에서는 `useEffect` 훅에서 정리(cleanup) 함수를 반환하거나 이벤트 리스너를 올바르게 해제하는 패턴을 반드시 지켜야 하며, CI 파이프라인에서 Puppeteer 등을 활용하여 자동화된 메모리 테스트를 구축하는 것으로 사전에 방지할 수 있다 [7, 9].
+
+## ⚖️ Trade-offs & Caveats
+소스에 관련 정보가 부족합니다.
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [발생 원인 및 증상 (Causes & Phenomena)]
+- [[Detached DOM Nodes]]
+  - 연결 이유: 자바스크립트 프론트엔드 환경에서 메모리 누수를 발생시키는 가장 흔하고 주요한 원인 중 하나로 상세하게 다뤄진다 [5, 6].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: HTML 문서의 DOM 트리에서는 제거되었으나, 자바스크립트 메모리 상에는 데이터가 묶여 있는 상태를 파악하여 컴포넌트 해제 시 참조 관리의 중요성을 이해할 수 있다 [5, 13].
+
+- [[Closure-Retained References]]
+  - 연결 이유: 자바스크립트의 언어적 특성인 클로저가 어떻게 메모리를 해제하지 못하게 막는지 설명하는 원인 패턴이다 [10].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 스코프 체인으로 인해 필요 이상으로 큰 객체나 데이터가 가비지 컬렉터로부터 살아남는 구조적 누수 현상을 분석할 수 있다 [10].
+
+#### [진단 및 구현 도구 (Diagnostics & Tools)]
+- [[Chrome DevTools Memory Profiler]]
+  - 연결 이유: 힙 스냅샷(Heap snapshot)과 할당 타임라인(Allocation Timeline) 등 메모리 누수를 직접적으로 찾아내고 디버깅하는 핵심 도구이다 [11, 16].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 객체 간의 참조 경로(Retainer Path)를 추적하고, 증가하는 메모리의 근본 원인이 되는 자바스크립트 변수를 시각적으로 찾아내는 기법을 습득할 수 있다 [10, 12, 15].
+
+- [[useEffect Cleanup]]
+  - 연결 이유: React 애플리케이션에서 구독이나 이벤트를 관리할 때 누수를 예방하기 위해 프레임워크 차원에서 필수적으로 요구되는 해결 패턴이다 [7-9].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 함수형 컴포넌트의 생명주기와 부수 효과(Side effect) 관리 원리를 이해하고, 리소스 누출을 막는 안전한 코딩 방식을 익힐 수 있다 [7, 9].
+
+- [[WeakMap]]
+  - 연결 이유: 메모리 누수 방지 전략으로 객체 캐시 구조를 설계할 때 사용하도록 직접적으로 권장되는 자바스크립트 내장 객체이다 [9].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 객체에 대한 강한 참조(Strong Reference)를 만들지 않아 가비지 컬렉터가 원활하게 작동하도록 돕는 메모리 최적화 자료구조의 원리를 배울 수 있다 [9].
+
+### Deeper Research Questions
+
+- 자바스크립트 가비지 컬렉터(Garbage Collector)의 참조 카운팅(Reference Counting)과 표시-쓸기(Mark-and-Sweep) 알고리즘은 각각 어떤 조건 하에 메모리 해제 가능성을 판단하는가?
+- 부모 컴포넌트가 언마운트될 때, 자식 컴포넌트 내부의 클로저(Closure)가 부모 스코프의 상태를 캡처하고 있을 경우 정확히 어떤 경로를 통해 메모리 릭이 발생하는가?
+- 일반적인 `Object` 혹은 `Map`을 사용한 상태 데이터 캐싱과 `WeakMap`을 사용한 캐싱 간의 가비지 컬렉션 타이밍과 런타임 성능 차이는 어떠한가?
+- Chrome DevTools의 Retainer 패널에서 표시되는 'Distance from GC root'가 디버깅 과정에서 갖는 의미는 무엇이며, 참조 트리를 역추적할 때 이를 어떻게 해석해야 하는가?
+- Puppeteer를 활용한 자동화된 메모리 테스트(Automated Memory Testing) 환경을 CI/CD에 구축할 때, 테스트 실패(누수 발생)를 판정하기 위한 적절한 메모리 증가 임계값(Threshold)은 어떻게 설정하는가?
+
+### Practical Application Contexts
+
+- **Implementation:** React 컴포넌트를 작성할 때, `useEffect` 안에서 이벤트 리스너를 추가하거나 외부 데이터를 구독한 경우, 반드시 해당 리스너나 구독을 취소하는 함수를 반환(return)하여 메모리가 회수될 수 있게 코드를 구현해야 한다 [7, 9].
+- **System Design:** 방대한 양의 데이터를 임시로 캐싱하거나 DOM 요소와 메타데이터를 매핑해야 하는 시스템을 설계할 경우, 일반 객체가 아닌 `WeakMap`을 도입하여 캐시가 가비지 컬렉션을 방해하지 않도록 아키텍처를 구성해야 한다 [9].
+- **Operation / Maintenance:** 프로덕션에 배포된 애플리케이션에서 시간이 지날수록 앱이 버벅이거나 크래시가 발생한다는 사용자 보고가 있다면, 즉시 Chrome DevTools의 Memory 패널을 켜서 Heap Snapshot의 Comparison 뷰를 이용해 양수의 델타 값을 가진 객체를 추적해야 한다 [4, 11].
+- **Learning Path:** 자바스크립트 기반 앱의 성능 튜닝을 학습할 때 렌더링 최적화를 넘어서, "가비지 컬렉션의 이해 -> Detached DOM과 클로저 누수 패턴 파악 -> DevTools를 활용한 프로파일링" 순으로 메모리 관리 기법을 익히는 학습 경로를 설정할 수 있다 [1, 5, 11].
+- **My Project Relevance:** 현재 유지보수 중인 SPA 프로젝트에 복잡한 라우팅과 무거운 위젯이 포함되어 있다면, 라우트 이동 후에도 이전 페이지의 데이터가 메모리에 남아있는지 확인하기 위해 할당 타임라인(Allocation Timeline) 분석과 이벤트 리스너 제거 여부를 점검하는 데 적용할 수 있다 [6, 14].
+
+### Adjacent Topics
+
+- [[Garbage Collection in JavaScript]]
+  - 확장 방향: 자바스크립트 엔진 내부에서 도달 가능성(Reachability)을 기준으로 객체를 어떻게 수집하고 관리하는지에 대한 기반 지식 방향으로 확장.
+- [[React Hooks Lifecycle]]
+  - 확장 방향: 메모리 해제의 시점이 되는 `useEffect`의 정리(Cleanup) 동작을 정확히 이해하기 위해, 컴포넌트의 마운트, 업데이트, 언마운트 생명주기와 의존성 배열의 동작 원리 탐구.
+- [[Web Performance Optimization]]
+  - 확장 방향: 메모리 누수 외에도 불필요한 리렌더링 방지, 코드 스플리팅, 번들 사이즈 축소 등 프론트엔드 전반의 성능 최적화 및 사용자 경험(UX) 개선 기법으로 확장.
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Memory Leaks.md b/00_Raw/Memory Leaks.md
new file mode 100644
index 00000000..5e3ce246
--- /dev/null
+++ b/00_Raw/Memory Leaks.md	
@@ -0,0 +1,75 @@
+# [[Memory Leaks]]
+
+## 📌 Brief Summary
+메모리 누수(Memory Leaks)는 애플리케이션이 메모리를 할당한 후, 더 이상 필요하지 않음에도 불구하고 자바스크립트의 가비지 컬렉터(Garbage Collector)가 이를 회수하지 못해 발생하는 현상입니다 [1]. 이는 개발자가 코드 내에서 더 이상 사용하지 않는 객체나 DOM 노드에 대한 참조(Reference)를 해제하지 않을 때 발생하며, 시간이 지남에 따라 애플리케이션의 메모리 사용량이 지속적으로 증가하게 만듭니다 [1, 2]. 결과적으로 사용자 인터페이스가 느려지고, 브라우저 탭이 멈추거나 앱이 강제 종료되는 치명적인 성능 저하를 초래합니다 [2-4].
+
+## 📖 Core 대Content
+* **발생 원리 및 주요 패턴:**
+  자바스크립트에서 가비지 컬렉터는 남아있는 참조가 없을 때만 메모리를 자동으로 회수합니다 [1]. 최신 자바스크립트 프레임워크 환경에서 메모리 누수를 일으키는 가장 흔한 원인은 다음과 같습니다:
+  * **Detached DOM Nodes:** 문서(DOM 트리)에서는 제거되었으나, 자바스크립트 변수에서 계속 참조하고 있어 메모리에서 해제되지 못하는 고아(Orphaned) 노드입니다 [5-7].
+  * **이벤트 리스너 누적:** 컴포넌트가 마운트 해제(Unmount)될 때 등록된 이벤트 리스너를 제거하지 않아 지속적으로 축적되는 현상입니다 [7].
+  * **클로저(Closure)에 의한 참조:** 클로저가 부모 스코프의 변수를 계속 유지하여 불필요하게 큰 객체들을 메모리에 남겨두는 경우입니다 [8].
+  * **React 특화 요인:** `useEffect` 훅(Hook)을 사용할 때 정리(Cleanup) 함수를 반환하지 않아 이벤트 리스너나 구독(Subscription) 자원이 컴포넌트 소멸 후에도 남아있는 경우가 대표적인 원인입니다 [5, 9].
+
+* **증상 및 감지:**
+  메모리가 단순히 많이 사용되는 '메모리 블로트(Memory Bloat)'와 달리, 메모리 누수는 일정한 작업 부하 속에서도 메모리 소비가 지속적으로 증가하여 안정되지 않는 특성이 있습니다 [2, 4]. 주요 증상으로는 잦은 가비지 컬렉션으로 인한 스크립트 실행 일시 정지(Jank), 시간이 지날수록 느려지는 성능, 기능 종료 후에도 감소하지 않는 메모리 점유율 등이 있습니다 [2, 4, 10, 11].
+
+* **디버깅 및 프로파일링 방법:**
+  * **Chrome Task Manager:** 애플리케이션의 실시간 'JavaScript Memory' 사용량을 모니터링하여 누수 여부의 첫 단서를 잡습니다 [12, 13].
+  * **Heap Snapshots (힙 스냅샷):** Chrome DevTools를 이용해 여러 시점의 스냅샷을 찍고 비교(Comparison view)하여 지속적으로 증가하는 객체(Delta 값이 양수)를 찾습니다. 'Detached'를 검색하여 고아 DOM 노드를 찾고, GC 루트로부터 어떤 참조(Retainers)가 객체를 유지하고 있는지 추적합니다 [8, 11, 14, 15].
+  * **Allocation Timeline (할당 타임라인):** 실시간으로 메모리 할당 패턴을 파악하여 파란색 막대가 나타난 후 회색으로 변하지 않고 유지되는(메모리가 해제되지 않는) 구간을 확인합니다 [16-18].
+  * **Performance Recordings:** 시간에 따른 메모리 사용량을 시각화하며, 강제 가비지 컬렉션을 수행한 후에도 JS 힙(Heap) 크기가 시작 시점보다 높게 유지되면 누수를 의심할 수 있습니다 [19, 20].
+
+* **예방 전략:**
+  객체 캐시를 관리할 때는 가비지 컬렉션이 가능한 `WeakMap`을 사용해야 합니다 [21]. 또한 CI 파이프라인에 Puppeteer 등을 활용한 자동화된 메모리 누수 감지 테스트를 통합하고, 각 프레임워크의 생명주기(예: React의 `useEffect` 반환부, Vue의 `beforeUnmount` 등)에 맞는 적절한 정리(Cleanup) 패턴을 준수해야 합니다 [21].
+
+## ⚖️ Trade-offs & Caveats
+소스에 관련 정보가 제한적이나, 메모리 누수 최적화 및 디버깅에는 다음과 같은 제약과 개발 리소스 측면의 트레이드오프가 존재합니다:
+* **디버깅 복잡성 및 리소스 소모:** Chrome DevTools의 힙 스냅샷 비교와 할당 타임라인 분석은 개발 과정에서 상당한 시간과 체계적인 분석 능력을 요구합니다. 또한 GC 루트로부터의 참조 경로(Retainer Path)를 수동으로 추적해야 하므로 복잡성이 높습니다 [8, 11, 22].
+* **자료 구조의 제약:** 메모리 누수를 예방하기 위해 표준 객체(Object) 캐시 대신 `WeakMap`을 사용하면, 참조가 해제될 수 있다는 장점은 있으나 반복(Iteration)이 불가능하고 키(Key)를 객체로만 설정해야 하는 등의 기능적 제약이 따릅니다 [21].
+* **프로덕션 환경에서의 비용:** 프로덕션 환경에 도달하기 전 개발 단계에서 정기적으로 메모리를 프로파일링하지 않으면, 프로덕션 단계에서는 진단하기 훨씬 어렵고 수정하는 데 훨씬 더 큰 비용이 발생합니다 [22].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [분석 및 진단 도구]
+- [[Chrome DevTools Memory Profiler]]
+  - 연결 이유: 메모리 누수를 감지, 진단, 추적하기 위한 가장 핵심적인 실무 도구입니다 [3, 11].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 힙 스냅샷과 할당 타임라인을 통해 애플리케이션의 메모리 분배 현황을 시각적으로 파악하고, GC(가비지 컬렉터)가 회수하지 못한 객체의 원인을 분석하는 방법을 이해할 수 있습니다 [11, 14, 16].
+
+#### [프론트엔드 아키텍처 및 현상]
+- [[Detached DOM Nodes]]
+  - 연결 이유: 컴포넌트 기반 UI 개발에서 가장 빈번하게 발생하는 메모리 누수 패턴입니다 [6, 7].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 노드가 DOM 트리에서 제거되었음에도 불구하고 자바스크립트 변수 등에 의한 참조가 남아있어 메모리 누수를 유발하는 원리와 이를 방지하기 위한 참조 해제 방법을 알 수 있습니다 [6, 7, 15].
+- [[Garbage Collection]]
+  - 연결 이유: 자바스크립트 메모리 누수의 근본 원인은 가비지 컬렉터의 동작 방식(참조가 없어야 메모리 회수)과 직결됩니다 [1, 2].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 메모리가 시스템에 반환되는 시점과 잦은 가비지 컬렉션이 스크립트 실행을 일시 중단시켜(Pause) 렌더링 성능에 미치는 영향을 파악할 수 있습니다 [2, 23].
+
+#### [React 패턴 및 구현]
+- [[useEffect Cleanup]]
+  - 연결 이유: React 애플리케이션 내에서 구독 해제 및 이벤트 리스너 제거 실패로 인한 메모리 누수를 막는 직접적인 해결책입니다 [5, 9, 21].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 함수형 컴포넌트의 생명주기 관리와 컴포넌트 언마운트 시 부수 효과(Side-effects)를 안전하게 처리하는 메커니즘을 이해할 수 있습니다 [9, 21].
+
+### Deeper Research Questions
+- 가비지 컬렉션의 동작 원리와 비교하여, 클로저(Closure)에 의해 참조가 유지되는 메모리 누수는 구체적으로 DevTools의 Retainer 패널에서 어떻게 추적할 수 있는가?
+- 캐시 관리에 `WeakMap`을 사용하는 전략이 전통적인 `Map`이나 객체 리터럴을 사용할 때의 메모리 보존 방식과 기술적으로 어떻게 다른가?
+- 프로덕션 파이프라인(CI/CD) 환경에서 Puppeteer를 활용하여 메모리 누수를 자동으로 테스트하고 잡아내는 구체적인 구현 방법론은 무엇인가?
+- 메모리 블로트(Memory Bloat)와 메모리 누수(Memory Leak)를 구분하기 위해 Chrome Task Manager에서 관찰해야 하는 주요 지표와 패턴은 어떻게 다른가?
+- React 이외의 모던 프레임워크(예: Angular의 `takeUntil`, Vue의 `beforeUnmount` 등)에서는 메모리 누수 방지를 위해 어떤 구조적 패턴을 사용하는가?
+
+### Practical Application Contexts
+- **Implementation:** React 컴포넌트를 작성할 때, `useEffect` 내에서 설정한 타이머나 외부 라이브러리 이벤트 리스너는 반드시 반환(return) 함수를 통해 해제하여 메모리 누수를 차단해야 합니다 [7, 9, 21].
+- **System Design:** 장기 실행되는 SPA 환경에서는 컴포넌트 트리가 자주 변경되므로, 데이터 캐싱 계층 설계 시 `WeakMap`을 도입하여 전역 상태에서 제거된 객체가 자연스럽게 메모리에서 소멸되도록 설계합니다 [21].
+- **Operation / Maintenance:** 프로덕션 앱에서 사용자가 장시간 이용 후 '앱이 멈추거나 느려짐'을 보고할 경우, 개발팀은 크롬 개발자 도구의 Performance 탭 및 Memory 패널을 켜서 유저 시나리오를 재현하고 힙 스냅샷 간의 Delta를 비교하여 유지되고 있는 객체(Retained Size)를 디버깅합니다 [2, 11].
+- **Learning Path:** 자바스크립트의 참조 및 스코프(Closure) 기초 학습 -> 프레임워크의 생명주기 훅(useEffect 등) 이해 -> Chrome DevTools를 활용한 Memory Profiling 기법 숙달 -> CI 환경에서의 자동화 테스트 구축 단계로 나아갑니다 [9, 11, 21].
+- **My Project Relevance:** 현재 진행 중인 React 코드베이스 리팩토링 시, 기존 학생들이 작성한 코드 중 `useEffect`의 반환 함수 누락이나 불필요한 이벤트 리스너 중복 등록을 식별하고 개선하여 앱의 장기적인 구동 안정성을 확보하는 데 필수적인 지식입니다 [9, 24, 25].
+
+### Adjacent Topics
+- [[Memory Bloat]]
+  - 확장 방향: 메모리 누수처럼 계속 증가하지는 않지만, 초기부터 최적의 페이지 속도를 위해 필요한 수준보다 과도하게 많은 메모리를 사용하는 상태를 진단하고 최적화하는 방법으로 확장이 가능합니다 [2, 10].
+- [[Core Web Vitals]]
+  - 확장 방향: 잦은 가비지 컬렉션과 메모리 누수로 인해 스크립트 실행이 지연되면서 FID(First Input Delay)나 INP(Interaction to Next Paint) 같은 실제 사용자 체감 성능 지표에 미치는 영향을 심층적으로 분석할 수 있습니다 [23, 26].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Model Context Protocol (MCP).md b/00_Raw/Model Context Protocol (MCP).md
new file mode 100644
index 00000000..ec3d1bd8
--- /dev/null
+++ b/00_Raw/Model Context Protocol (MCP).md	
@@ -0,0 +1,78 @@
+# [[Model Context Protocol (MCP)]]
+
+## 📌 Brief Summary
+Model Context Protocol(MCP)은 2024년 11월 Anthropic이 도입한 오픈 소스 표준 프로토콜로, LLM 기반 AI 시스템이 외부 데이터 소스, 도구, 시스템과 통합되는 방식을 표준화합니다[1]. 이 프로토콜은 AI 애플리케이션의 "USB-C 포트" 역할을 하여, 각 시스템마다 맞춤형 커넥터를 구축해야 했던 기존의 "N×M" 데이터 통합 문제를 해결합니다[2-4]. 에이전트 하네스 엔지니어링 관점에서 MCP는 하네스의 도구 레지스트리(T-컴포넌트)를 외부 상호운용성 계층으로 분리하여, 맞춤형 통합 코드 없이도 에이전트가 동적으로 도구를 검색하고 실행할 수 있는 표준 인프라를 제공합니다[5-7].
+
+## 📖 Core Content
+
+*   **아키텍처 및 구성 요소**
+    MCP는 명확한 클라이언트-서버 아키텍처를 따릅니다[8].
+    *   **MCP Host:** AI 애플리케이션(예: Claude Code, IDE) 자체로, LLM이 포함되어 있으며 여러 MCP 클라이언트를 관리합니다[9, 10].
+    *   **MCP Client:** Host 내부에 위치하여 LLM의 요청을 MCP 서버가 이해할 수 있게 번역하고 통신을 유지합니다[9, 10].
+    *   **MCP Server:** 로컬 또는 원격으로 실행되며, LLM에게 컨텍스트와 데이터, 도구 기능을 제공하는 외부 서비스입니다[11, 12].
+    이들은 JSON-RPC 2.0을 전송 계층으로 사용하여 통신하며, 로컬 환경에서는 표준 입출력(stdio)을, 원격 환경에서는 Server-Sent Events(SSE)를 포함한 Streamable HTTP를 사용합니다[12-14].
+
+*   **에이전트 하네스에서의 역할 (T-컴포넌트 표준화)**
+    MCP는 에이전트 하네스 설계에서 중대한 아키텍처적 전환을 의미합니다. 기존 하네스 내부의 사유 데이터 구조였던 도구 레지스트리를 표준화된 상호운용 계층으로 대체합니다[6, 15]. 하네스는 MCP 클라이언트로 작동하고 도구 제공자는 MCP 서버로 작동함으로써, 하네스는 개별 도구의 구현 세부 사항에 결합(coupling)되지 않고 도구의 발견(capability negotiation), 스키마 검증, 호출(dispatch)을 표준화된 방식으로 거버넌스할 수 있습니다[5, 7].
+
+*   **기본 기능 (Primitives)**
+    MCP는 서버가 클라이언트에게 제공할 수 있는 세 가지 핵심 프리미티브를 정의합니다[16, 17].
+    1.  **Tools (도구):** AI가 외부 시스템에서 조치를 취할 수 있는 실행 가능한 함수 (예: 파일 조작, API 호출).
+    2.  **Resources (리소스):** AI 애플리케이션에 컨텍스트를 제공하는 데이터 소스.
+    3.  **Prompts (프롬프트):** LLM과의 상호작용을 구조화하는 재사용 가능한 템플릿.
+    반대로 클라이언트 측에서도 서버가 호스트 LLM을 사용하거나(Sampling), 사용자 입력을 요청(Elicitation)하거나, 디버깅 메시지를 로깅(Logging)할 수 있는 프리미티브를 제공합니다[18].
+
+*   **A2A(Agent-to-Agent) 프로토콜과의 상호 보완성**
+    MCP는 도구 통합(Agent-to-Tool)에 최적화되어 하네스의 T-컴포넌트 경계를 담당합니다. 반면 Google이 개발한 A2A 프로토콜은 하네스 간의 에이전트 위임 및 오케스트레이션(E-컴포넌트)을 담당합니다[5, 7, 19, 20]. 두 프로토콜은 경쟁 관계가 아닌 보완적 계층으로 작용하여 완전한 형태의 에이전트 통신 스택을 형성합니다[5, 7].
+
+## ⚖️ Trade-offs & Caveats
+
+*   **네임스페이스 충돌 및 도구 스푸핑(Spoofing) 위협**
+    MCP 사양에는 현재 강력한 네임스페이스 격리 기능이 없습니다. 이로 인해 서로 다른 제공자의 동일한 이름을 가진 도구가 기존의 신뢰할 수 있는 도구를 소리 없이 덮어쓰는(shadowing) 스푸핑 공격 성공률이 100%에 달한다는 분석 결과가 있습니다. 하네스가 MCP를 채택할 때는 프로토콜 수준에서 해결할 수 없는 이 취약점을 하네스 자체의 보안 계층(L-컴포넌트)에서 네임스페이스 격리를 통해 보완해야 합니다[21-23].
+*   **보안 경계 및 '간접 프롬프트 인젝션' 위험**
+    MCP를 통해 접근할 수 있는 도구의 출력을 신뢰할 수 있는 것으로 기본 가정해서는 안 됩니다[24, 25]. 악의적인 웹페이지나 외부 데이터를 읽어올 때 숨겨진 지시어가 포함되어 에이전트의 목표를 하이재킹하는 '간접 프롬프트 인젝션' 공격의 주요 표적이 될 수 있습니다[26, 27]. 하네스는 도구 출력이 LLM 컨텍스트에 주입되기 전에 반드시 출력을 검증해야 합니다.
+*   **무상태(Stateless) 세션 및 권한 부여의 한계 (2026년 기준)**
+    MCP는 서버 인증을 위해 OAuth를 지원하지만, 현재 도구 호출 전반에 걸친 상태 저장 세션(Stateful Session) 관리나, 특정 도구 접근에 대한 세밀한 단위의 권한 부여(authorization) 계층이 프로토콜 내에 표준화되어 있지 않습니다[28, 29]. 또한 원격 배포를 위한 Streamable HTTP 사용 시 상태 기반 헤더가 로드 밸런서와 충돌하는 등 세션 관리의 복잡성이 증가하는 제약이 있습니다[14].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [관계 유형 A: 아키텍처/기반 기술]
+*   `[[Agent Harness]]`
+    *   연결 이유: MCP 클라이언트를 탑재하여 도구와 에이전트(LLM) 사이의 통신을 실질적으로 제어하고 상태를 유지하는 핵심 런타임 인프라.
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: MCP가 제공하는 도구를 에이전트가 남용하지 않도록 제어하는 실행 루프(E-컴포넌트)와 라이프사이클 훅(L-컴포넌트) 등 전반적인 거버넌스 메커니즘 [5, 30, 31].
+*   `[[A2A (Agent-to-Agent)]]`
+    *   연결 이유: MCP가 도구/데이터를 위한 인터페이스라면, A2A는 에이전트 간의 작업 위임 및 오케스트레이션을 위한 프로토콜로 MCP와 통신 스택을 구성함.
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 단일 하네스를 넘어 멀티 에이전트 환경에서 에이전트가 다른 하네스의 에이전트를 호출할 때 사용되는 프로토콜 설계 및 비대칭적 역할 모델 [5, 7, 19, 20, 32-35].
+
+#### [관계 유형 B: 구현/활용 도구]
+*   `[[JSON-RPC 2.0]]`
+    *   연결 이유: MCP의 데이터 계층에서 클라이언트-서버 간 메시지 구조와 통신 의미(semantics)를 정의하는 기본 기반 프로토콜.
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 동기적 응답과 비동기적 알림(Notifications)이 MCP 데이터 전송에서 어떻게 처리되는지 [12, 13, 36, 37].
+*   `[[Agent Skills (Anthropic)]]`
+    *   연결 이유: MCP가 개별 원자적(atomic) 도구 실행을 처리한다면, Agent Skills는 다단계 도구 워크플로우를 포장하는 표준.
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: MCP의 저수준(low-level) 통합을 기반으로 하네스의 L-컴포넌트(라이프사이클) 수준에서 도구들을 어떻게 구성하고 휴대 가능한 형태로 배포하는지 [38-41].
+
+### Deeper Research Questions
+*   MCP와 같은 표준화된 도구 통합 프로토콜 환경에서, 상이한 신뢰 수준을 가진 여러 MCP 서버가 반환하는 데이터를 컨텍스트 윈도우 내에서 안전하게 격리하고 검증할 수 있는 하네스 레벨의 보안 메커니즘은 무엇인가?
+*   무상태(stateless)를 기본으로 하는 MCP 서버의 도구 호출 결과물들을 에이전트가 여러 턴에 걸쳐 기억하도록 만들기 위해, 하네스의 상태 저장소(S-컴포넌트)와 MCP를 어떻게 결합해야 하는가?
+*   네임스페이스 충돌을 악용한 MCP의 도구 스푸핑(Tool spoofing) 취약점을 해결하기 위해 에이전트 하네스는 도구 레지스트리 단계에서 어떤 추가적인 식별 및 서명 검증 과정을 거쳐야 하는가?
+*   MCP(Agent-to-Tool)와 A2A(Agent-to-Agent) 사이의 통합 경계에서, A2A를 통해 전달받은 작업 권한(Authorization) 정보를 MCP 서버의 도구 실행 권한으로 어떻게 안전하게 변환하여 매핑할 것인가?
+*   로컬 통신(stdio)과 원격 통신(Streamable HTTP) 사이에서, 에이전트 하네스의 도구 실행 지연 시간(latency) 차이가 LLM의 의사 결정 및 계획 루프(E-컴포넌트) 성능에 어떤 영향을 미치는가?
+
+### Practical Application Contexts
+*   **Implementation:** 애플리케이션 개발 시, 각 벤더별(API마다) 맞춤형 커넥터를 일일이 작성할 필요 없이, 표준화된 JSON-RPC 기반의 단일 MCP 클라이언트만 구현하면 Google Calendar, Notion 등 다양한 외부 서버와 즉시 연동할 수 있습니다 [4, 42, 43].
+*   **System Design:** 에이전트 시스템을 설계할 때 도구와 데이터의 목록을 하네스 내부에 정적으로 유지하지 않고, 런타임에 외부 MCP 서버로부터 동적으로 발견(Discovery)하고 스키마를 렌더링하도록 분리하여 확장성과 모델 불가지론(agnostic)을 확보합니다 [5, 6].
+*   **Operation / Maintenance:** 새로운 데이터 저장소나 API 도구가 추가될 때 핵심 에이전트 코드를 재배포할 필요 없이 독립적인 MCP 서버만 배포 및 연결하면 되므로 인프라 관리의 오버헤드가 크게 줄어듭니다 [6, 44].
+*   **Learning Path:** 단순한 함수 호출(Function Calling)에서부터 특정 도메인 RAG, 대규모 API 통합(ToolLLM)을 거쳐 최종적으로 개방형 표준 프로토콜(MCP)로 도구 레지스트리 인프라가 진화하는 과정을 학습하는 지표가 됩니다 [45].
+*   **My Project Relevance:** 소스에 관련 정보가 부족합니다.
+
+### Adjacent Topics
+*   `[[RAG (Retrieval-Augmented Generation)]]`
+    *   확장 방향: 단순한 문맥 검색 및 텍스트 증강을 목표로 하는 수동적 RAG 시스템에서 나아가, MCP를 통한 외부 시스템 내 작업 '실행(Execution)' 및 양방향 상호작용으로 확장하는 방법론의 비교 연구 [46-50].
+*   `[[Agent-Computer Interface (ACI)]]`
+    *   확장 방향: 도구 및 터미널 환경에 접근하는 언어 모델을 위해 인터페이스(오류 메시지 처리, 상태 표현, 반환 형식)를 하네스가 어떻게 최적화해야 하는지를 다루는 설계 원칙 [51, 52].
+
+---
+*Last updated: 2026-05-01*
\ No newline at end of file
diff --git a/00_Raw/Next.js 및 Server Components 적용 프로젝트.md b/00_Raw/Next.js 및 Server Components 적용 프로젝트.md
new file mode 100644
index 00000000..12ae26c5
--- /dev/null
+++ b/00_Raw/Next.js 및 Server Components 적용 프로젝트.md	
@@ -0,0 +1,60 @@
+# [[Next.js 및 Server Components 적용 프로젝트]]
+
+## 📌 Brief Summary
+Next.js의 App Router와 결합된 React Server Components(RSC)를 활용하여 클라이언트 측 자바스크립트 번들 크기를 줄이고 초기 로드 속도를 향상시키는 아키텍처 및 성능 최적화 접근법입니다 [1, 2]. 정적인 UI와 상호작용이 필요한 UI를 명확히 분리하고, 서버에서 직접 데이터를 패칭하여 애플리케이션의 성능을 극대화합니다 [2, 3].
+
+## 📖 Core Content
+* **Next.js 파일 기반 라우팅 및 폴더 구조**: Next.js는 `page.js`(라우트), `layout.js`(공유 레이아웃), `error.js`(사용자 정의 에러), `loading.js`(로딩 상태)와 같은 특수 파일 명명 규칙을 통해 애플리케이션의 라우팅과 구조를 정의합니다 [4]. 관련된 파일을 모아두는 기능 기반 폴더(Feature-Based Folders)와 `(folderName)` 형태의 라우트 그룹(Route Groups)을 활용하면, URL 경로에 영향을 주지 않으면서도 유지보수성과 확장성이 뛰어난 코드베이스를 구성할 수 있습니다 [5-7].
+* **React Server Components (RSC)의 특징**: 서버 컴포넌트는 오로지 서버에서만 렌더링되며, 클라이언트로 자바스크립트 코드를 전송하지 않습니다 [2]. 클라이언트 측에서의 로딩 과정 없이 데이터베이스나 API로부터 데이터를 직접 패칭할 수 있습니다 [2, 3].
+* **클라이언트 컴포넌트와의 분리 및 조합**: 상호작용이 필요한 UI(예: 모달, 입력 폼, 드롭다운 등)는 파일 상단에 `"use client"` 지시어를 선언하여 클라이언트 컴포넌트로 명시해야 합니다 [3, 8]. 모범 사례로는 기본적으로 모든 컴포넌트를 서버 컴포넌트로 사용하고, 필요한 부분만 클라이언트 동작을 추가(opt-in)하는 방식이 권장됩니다 [8].
+* **성능 및 사용자 경험 향상**: 상호작용이 불필요한 레이아웃이나 정적 뷰를 서버에 렌더링함으로써 클라이언트로 전송되는 자바스크립트 번들 크기를 획기적으로 줄입니다 [3]. 이는 초기 페인트(First Paint) 속도와 하이드레이션(Hydration) 시간을 단축시켜 모바일이나 저성능 기기에서의 체감 성능을 대폭 개선합니다 [3, 8].
+
+## ⚖️ Trade-offs & Caveats
+* **라우터 및 런타임 제약**: Server Components는 Next.js의 기존 Pages Router에서는 사용할 수 없으며, 반드시 App Router 환경에서만 작동합니다 [9]. 또한 Node.js나 Edge 런타임이 필요하며, 정적 내보내기(static export) 환경에서는 지원되지 않습니다 [9].
+* **상태 및 생명주기 훅 사용 불가**: 서버 컴포넌트 내부에서는 `useState`, `useEffect`와 같은 로컬 상태 및 생명주기 관리 훅이나 클라이언트 전용 외부 라이브러리를 사용할 수 없습니다 [9].
+* **경계(Boundary) 관리의 복잡성**: 서버 컴포넌트와 클라이언트 컴포넌트를 함께 구성할 때 이 둘 사이의 경계를 매우 신중하게 관리해야 합니다 [9]. 서로 다른 특성을 가진 컴포넌트를 잘못 중첩하거나 구성하면 최적화 효과를 잃거나 애플리케이션이 의도대로 동작하지 않을 수 있습니다 (이 경계 간 데이터 직렬화 등 세부적인 제약에 대해서는 소스에 관련 정보가 부족합니다).
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [관계 유형 A (아키텍처 및 라우팅)]
+- [[Next.js App Router]]
+  - 연결 이유: React Server Components를 기본적으로 활용하고 적용하기 위해 요구되는 Next.js의 최신 라우팅 및 아키텍처 환경입니다 [1, 9].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 라우트 단위의 코드 스플리팅 방식과 `page.js`, `layout.js` 중심의 파일 기반 렌더링 파이프라인.
+- [[Route Groups]]
+  - 연결 이유: URL 구조에 영향을 주지 않으면서 관련된 라우트나 레이아웃을 묶기 위해 `(folderName)` 포맷을 사용하는 Next.js의 폴더 조직 방법론입니다 [6].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 대규모 Next.js 프로젝트에서 서로 다른 팀이나 기능의 라우트 충돌 없이 관심사를 분리하는 논리적 디렉토리 설계 방법 [7].
+
+#### [관계 유형 B (성능 최적화 및 로딩)]
+- [[Code Splitting 및 Lazy Loading]]
+  - 연결 이유: 초기 번들 사이즈를 줄이고 필요한 코드만 지연 로딩하는 최적화 기법입니다. Server Components 또한 불필요한 번들을 제거한다는 점에서 목적을 공유합니다 [10, 11].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: `React.lazy`와 `Suspense`를 통한 클라이언트 측 코드 스플리팅과 서버 컴포넌트를 통한 서버 측 번들 삭감의 차이점 및 시너지 효과.
+- [[Hydration]]
+  - 연결 이유: 서버 측에서 렌더링된 정적 HTML이 클라이언트에서 상호작용 가능한 상태로 활성화되는 과정입니다 [3].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: Server Components가 정적 마크업에 대해서는 자바스크립트를 전송하지 않음으로써 이 하이드레이션 비용을 어떻게 혁신적으로 줄이는지 그 원리.
+
+### Deeper Research Questions
+- Next.js의 서버 컴포넌트와 클라이언트 컴포넌트 경계를 교차하여 데이터를 Props로 전달할 때 발생하는 직렬화(Serialization) 제약은 어떻게 해결해야 하는가? (소스에 관련 정보가 부족합니다.)
+- `(folderName)` 형태의 라우트 그룹을 활용해 다중 루트 레이아웃을 구성할 경우, 서로 다른 루트 레이아웃 간 내비게이션 시 브라우저의 전체 페이지 로드(Full Page Load) 문제를 회피할 수 있는 설계 방법은 무엇인가? [7]
+- 클라이언트 컴포넌트 트리 내부에 서버 컴포넌트를 렌더링해야 할 경우, 컴포넌트 합성(Composition)과 `children` prop을 활용하는 구체적이고 올바른 구현 패턴은 무엇인가? [2]
+- 상태 관리 라이브러리(Zustand, Redux 등)나 React Context를 서버 컴포넌트와 혼용해야 할 때, 데이터의 일관성을 유지하기 위한 최적의 아키텍처는 무엇인가? (소스에 관련 정보가 부족합니다.)
+- 기존 Pages Router 기반으로 개발된 레거시 앱을 Next.js App Router와 Server Components로 점진적으로 마이그레이션하기 위한 안전한 전환 전략은 무엇인가? (소스에 관련 정보가 부족합니다.)
+
+### Practical Application Contexts
+
+- **Implementation:** 페이지의 대부분을 구성하는 헤더, 제품 목록, 설명 등은 서버 컴포넌트로 유지하고, 사용자와 상호작용하는 '장바구니 추가(Add To Cart)' 버튼 등에만 `"use client"`를 선언하여 클라이언트 컴포넌트로 분리합니다 [3].
+- **System Design:** 애플리케이션의 디렉토리를 구축할 때, 기능(Feature) 별로 폴더를 생성하여 해당 기능에 관련된 라우트, 컴포넌트, 유틸리티를 한 곳에 응집시키는 Feature-Based 구조로 라우팅과 아키텍처를 결합합니다 [5].
+- **Operation / Maintenance:** `(marketing)`, `(shop)`과 같은 Route Groups를 활용하여 관련 경로들을 논리적으로 분리함으로써 여러 팀이 협업할 때 발생하는 충돌을 방지하고 코드베이스의 탐색을 용이하게 합니다 [6, 7].
+- **Learning Path:** Next.js의 파일 시스템 기반 라우팅(예: `page.tsx`, `layout.tsx` 규칙)을 먼저 학습한 뒤, 클라이언트와 서버 환경에서의 컴포넌트 동작 차이(제약 사항과 이점)를 분석하는 방식으로 나아갑니다 [4, 8, 9].
+- **My Project Relevance:** 복잡한 대시보드나 이커머스 등 대규모 렌더링이 필요한 뷰에서, 데이터 위주의 읽기 전용 UI는 서버에서 미리 완성하고 실시간 필터나 입력 요소만 클라이언트로 넘기는 구조를 채택하여 TTI(Time To Interactive)와 로딩 성능을 직접적으로 개선할 수 있습니다 [3, 8].
+
+### Adjacent Topics
+
+- [[React Concurrent Features]]
+  - 확장 방향: `useTransition` 및 `useDeferredValue` 등 React 18의 동시성 렌더링 기능이 Server Components와 결합되어 어떻게 더욱 매끄러운 UX와 인터랙션을 제공하는지에 대한 심층 탐구 [12-14].
+- [[Feature-Sliced Design (FSD)]]
+  - 확장 방향: 대규모 애플리케이션 코드를 비즈니스 논리에 따라 명확히 슬라이싱하는 아키텍처 방법론으로, Next.js의 기능 기반 폴더 구조 및 App Router와 어떻게 조화롭게 통합될 수 있는지 조사 [5, 15].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Observability.md b/00_Raw/Observability.md
new file mode 100644
index 00000000..0169202b
--- /dev/null
+++ b/00_Raw/Observability.md
@@ -0,0 +1,66 @@
+# [[Observability]]
+
+## 📌 Brief 실전 Summary
+Observability(관찰 가능성)는 프론트엔드부터 백엔드까지 분산 시스템 전반에 걸친 애플리케이션의 동작과 성능을 가시화하고 모니터링하는 기능입니다 [1, 2]. 단순한 에러 로깅을 넘어 로그(Logs), 메트릭(Metrics), 분산 트레이스(Traces)를 단일 플랫폼으로 통합하여 시스템의 상태를 종합적으로 이해할 수 있게 합니다 [3]. 이를 통해 개발자는 프로덕션 환경에서 발생하는 복잡한 버그나 성능 병목의 근본 원인을 파악하고, 사용자 경험을 모니터링하여 시스템의 안정성을 유지할 수 있습니다 [1, 4].
+
+## 📖 Core Content
+*   **통합 가시성(Unified Observability):** 현대적인 Observability 플랫폼은 로그, 메트릭, 트레이스를 한 곳에서 확인할 수 있는 전체적인 모니터링(Full-stack visibility)을 제공합니다 [3]. 예를 들어, SigNoz와 같은 도구는 OpenTelemetry를 기반으로 하여 이러한 통합 환경을 제공합니다 [3, 5].
+*   **엔드투엔드 트레이싱(End-to-end Tracing):** 프론트엔드와 백엔드 간의 모니터링 간극을 메워주는 핵심 기능입니다 [1]. 프론트엔드에서 에러를 클릭하면 해당 요청이 백엔드 서비스, 데이터베이스, 서드파티 API를 통과하는 전체 과정을 분산 트레이싱을 통해 추적할 수 있어 복잡한 분산 시스템 디버깅에 필수적입니다 [1, 5].
+*   **프로덕션 모니터링 및 디버깅 기능:** 
+    *   **세션 리플레이(Session Replay):** LogRocket, Sentry 등의 도구는 에러가 발생하기 전 사용자의 행동, DOM의 변화, 네트워크 요청 및 상태 변화 등을 녹화하여 일반적인 스택 트레이스만으로는 알 수 없는 맥락(Context)을 제공합니다 [4, 6, 7].
+    *   **지능형 에러 그룹화(Intelligent Error Grouping):** 중복되는 수많은 에러들의 노이즈를 줄여 개발자가 고유하고 치명적인 이슈에만 집중할 수 있도록 돕습니다 [4, 6].
+*   **오픈 표준 기반(Open Standards):** 특정 벤더에 종속되지 않기 위해 OpenTelemetry와 같은 개방형 표준을 사용하는 추세입니다 [8, 9]. Grafana나 SigNoz 같은 툴은 이 오픈 표준을 기반으로 구축되어 다양한 데이터 소스와 결합할 수 있는 유연성을 제공합니다 [3, 5, 8].
+
+## ⚖️ Trade-offs & Caveats
+*   **비용과 가시성 간의 균형(Cost vs. Visibility):** Datadog 등 일부 플랫폼은 로그의 데이터 수집(Ingest)과 검색을 위한 인덱싱(Index)에 각각 별도의 비용을 청구하는 "이중 가격 책정(Two-part tariff)" 구조를 가집니다 [10]. 이는 대규모 트래픽에서 비용을 급증시킬 수 있으며, 비용 절감을 위해 20%의 로그만 인덱싱하게 되면 장애 발생 시 80%의 중요한 디버깅 데이터가 검색되지 않는 치명적인 제약이 발생합니다 [11].
+*   **성능 저하(Performance Impact):** 모니터링을 위해 삽입된 로깅 도구들은 애플리케이션의 번들 사이즈를 증가시키고 초기 로딩 시간을 최대 120ms까지 지연시킬 수 있어, 전자상거래와 같이 성능에 민감한 사이트에서는 가벼운 옵션을 선택해야 하는 반대 급부가 있습니다 [2, 12, 13].
+*   **프라이버시 및 보안 제약(Privacy Concerns):** 세션 리플레이처럼 "모든 것을 기록"하는 접근 방식은 기본적으로 민감한 사용자 데이터까지 수집할 수 있는 위험이 있습니다 [7, 13]. 따라서 규제 준수를 위해 민감 데이터를 철저히 마스킹(Masking)해야 하는 초기 설정 및 관리의 부담이 따릅니다 [7, 9, 14].
+*   **설정 및 학습 곡선(Setup Complexity):** SaaS 제품 대신 오픈소스 기반이나 자체 호스팅(Self-hosted) Observability 도구(SigNoz, Grafana 등)를 선택할 경우, 데이터 통제력과 확장성은 높아지지만 시스템을 구축하고 유지보수하기 위한 DevOps 전문 지식과 높은 기술적 학습 곡선이 요구됩니다 [5, 8, 15, 16].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [관계 유형 A (아키텍처/기반 기술)]
+*   [[OpenTelemetry]]
+    *   연결 이유: SigNoz, Grafana 등 최신 Observability 도구들이 기반으로 삼고 있는 오픈 표준 아키텍처이기 때문입니다 [3, 8].
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 특정 벤더 종속성(Vendor Lock-in) 없이 로그, 메트릭, 분산 트레이스를 표준화된 방식으로 수집하고 통합하는 원리를 이해할 수 있습니다 [5, 9].
+*   [[Distributed Tracing]]
+    *   연결 이유: 프론트엔드 에러와 백엔드 처리 흐름을 연결하는 Observability의 핵심 요소입니다 [1, 5].
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 분산 시스템 아키텍처 내에서 단일 사용자 요청이 어떻게 여러 서비스와 데이터베이스를 거치는지 추적 식별자(Trace IDs)로 연결하는 메커니즘을 파악할 수 있습니다 [1, 5].
+
+#### [관계 유형 B (구현/활용 도구)]
+*   [[Session Replay]]
+    *   연결 이유: Sentry, LogRocket 등의 툴을 통해 사용자의 행동, DOM 변화, Redux/Zustand 상태를 녹화하여 시각적으로 보여주는 기능입니다 [4, 7, 14].
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 일반적인 스택 트레이스만으로는 재현하기 힘든 프로덕션 환경의 UI 에러 맥락과 원인을 분석하는 방법을 이해할 수 있습니다 [4].
+*   [[Intelligent Error Grouping]]
+    *   연결 이유: 대규모 애플리케이션의 Observability 플랫폼(Sentry 등)에서 로그 노이즈를 줄이는 필수 기능입니다 [4, 6].
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 수많은 중복 에러 로그를 분석 가능한 단위로 묶어 고유한 문제를 식별하고 해결 우선순위를 정하는 방법을 이해할 수 있습니다 [4, 6].
+
+### Deeper Research Questions
+
+*   Datadog 등의 플랫폼이 지닌 Ingest와 Index 이중 과금 문제를 피하기 위해, SigNoz와 같은 자체 호스팅(Self-hosted) OpenTelemetry 인프라를 구축할 때 수반되는 실제 인프라 및 DevOps 운영 비용은 상용 SaaS와 비교해 어느 정도인가? [10, 11, 16]
+*   OpenTelemetry 표준을 사용할 때, 프론트엔드의 사용자 상호작용 로그와 백엔드의 분산 트레이스(Trace IDs)는 네트워크 계층을 통해 구체적으로 어떻게 상관관계(Correlation)가 형성되는가? [1, 5]
+*   LogRocket의 세션 리플레이 기능이 전체 DOM과 상태(State)를 기록할 때 발생하는 번들 크기 증가와 메인 스레드 성능 저하(Performance Impact)를 완화할 수 있는 프론트엔드 아키텍처 차원의 최적화 전략은 무엇인가? [2, 9, 13]
+*   프론트엔드 로깅 시스템이 사용자 화면을 기록할 때, 개인정보 보호 규정 강화를 대비해 민감한 사용자 데이터(Sensitive Data)를 클라이언트 사이드에서 안전하게 자동 마스킹(Masking)하는 알고리즘은 어떻게 구현되는가? [9, 13, 14]
+*   Sentry의 지능형 에러 그룹화(Error Grouping) 기능은 발생한 에러의 스택 트레이스와 메타데이터를 어떤 기준으로 비교 분석하여 수천 개의 노이즈 로그를 단일 고유 이슈로 압축해 내는가? [4, 6]
+
+### Practical Application Contexts
+
+*   **Implementation:** 애플리케이션을 배포하기 전 Sentry, LogRocket, Datadog RUM, SigNoz 등 서비스 규모와 비용에 맞는 로깅 도구를 연동하고, 에러 그룹화 및 세션 리플레이를 활성화하여 트래킹 환경을 구축합니다 [4, 7, 14, 17].
+*   **System Design:** 시스템 초기 설계 시 벤더 종속성을 방지하기 위해 OpenTelemetry 규격을 채택하고, 프론트엔드의 트래픽 로그가 백엔드 마이크로서비스로 원활히 이어지도록 Trace ID 기반의 로깅 파이프라인을 설계합니다 [3, 8, 9].
+*   **Operation / Maintenance:** 운영 중인 서비스에 "White screen of death"나 성능 병목 현상이 발생할 때, Observability 대시보드의 에러 트래커와 Heap Snapshots 등을 활용하여 근본 원인(메모리 누수, API 지연 등)을 식별하고 복구합니다 [4, 18, 19].
+*   **Learning Path:** 콘솔 로그(`console.log`)에 의존하는 기초적인 디버깅에서 벗어나, Chrome DevTools를 활용한 메모리 분석, Sentry를 통한 에러 캐칭, 궁극적으로 시스템 전반의 Metrics/Traces/Logs 통합 관리에 이르는 역량 성장 경로를 따릅니다 [4, 18, 20].
+*   **My Project Relevance:** 현재 작업 중인 확장 가능한 프론트엔드 프로젝트(Scalable Frontend System)에 Observability 인프라를 적용할 때, 비용(Pricing)과 프라이버시(Privacy controls), 성능(Performance impact)이라는 핵심 트레이드오프를 고려한 최적의 도구 스택을 선정하는 데 기여합니다 [2, 9, 21, 22].
+
+### Adjacent Topics
+
+*   [[Core Web Vitals]]
+    *   확장 방향: Observability의 연장선으로, 사용자 경험과 성능 모니터링에 직결되는 지표인 LCP, FID, CLS, INP 측정 및 최적화 기법으로 지식을 확장합니다 [23-25].
+*   [[React Error Boundaries]]
+    *   확장 방향: Observability 툴이 에러를 감지하고 수집하는 것을 넘어, 프론트엔드 애플리케이션 코드 단에서 이러한 에러를 어떻게 격리하고 Fallback UI를 보여주어 앱의 전체 크래시를 방지할 수 있는지 설계 패턴을 알아봅니다 [19, 26, 27].
+*   [[Memory Management & Garbage Collection]]
+    *   확장 방향: 프로덕션 모니터링 도구를 통해 감지된 '점진적 성능 저하'의 주원인인 메모리 누수(Memory Leaks)와 Detached DOM 노드 이슈를 근본적으로 해결하기 위한 자바스크립트 엔진의 동작 원리 학습으로 확장합니다 [18, 28, 29].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Plan-Execute-Verify (PEV) Loop.md b/00_Raw/Plan-Execute-Verify (PEV) Loop.md
new file mode 100644
index 00000000..8261937c
--- /dev/null
+++ b/00_Raw/Plan-Execute-Verify (PEV) Loop.md	
@@ -0,0 +1,70 @@
+# [[Plan-Execute-Verify (PEV) Loop]]
+
+## 📌 Brief Summary
+PEV(Plan-Execute-Verify) 루프는 에이전트의 계획 수립과 실행을 분리하고, 검증을 구조화된 피드백 루프로 강제하는 3단계 에이전트 아키텍처 패턴이다 [1]. 이 패턴은 대형 언어 모델(LLM)이 복잡한 다단계 문제를 단 한 번의 시도로 해결하도록 요구하는 대신, 작업을 명시적인 계획으로 분해(Plan)하고, 그 계획의 경계 내에서 실행(Execute)하며, 결과물을 계획 및 외부 품질 기준과 대조하여 검증(Verify)하도록 지시한다 [1]. 이를 통해 에이전트의 자율적 비결정성(non-determinism)을 통제하고 신뢰할 수 있는 실행 결과를 보장한다 [2].
+
+## 📖 Core Content
+PEV 루프는 전통적인 '생성 후 검사(Generate-and-Check)' 방식과 구조적으로 구별되는 특성을 가지며, 각 단계에서 에이전트의 자율성을 제한하고 검증을 강제한다 [3].
+
+*   **Plan (계획 단계)**: 
+    *   에이전트가 즉시 코드를 생성하거나 행동하는 대신, 문제를 명시적으로 분해하고 수용 기준(acceptance criteria)을 포함한 계획을 수립한다 [1, 3].
+    *   계획 단계에서 자유도(degrees of freedom)를 줄임으로써, 동일한 작업에 대해 매번 다른 추론 경로가 생성되는 비결정성 문제를 해결한다 [2].
+*   **Execute (실행 단계)**: 
+    *   에이전트의 실행 범위는 수립된 계획에 의해 엄격하게 제한된다 [3].
+    *   모든 도구 호출(tool call) 시마다 하네스 게이트가 작동한다. 실행 전 게이트(Pre-execution gates)는 도구 호출이 이루어지기 전에 개입하여 해당 도구가 알려진 도구인지, 인자가 유효한지, 사용자 승인이 필요한지, 요청된 작업 범위가 작업 공간 내에 있는지를 확인하고 범위를 벗어난 호출을 차단한다 [2, 3].
+*   **Verify (검증 단계)**: 
+    *   사후 검증(Post-hoc only)에 그치지 않고, 실행 전, 런타임, 실행 후 및 계획 일치성(plan alignment) 전반에 걸쳐 검증이 이루어진다 [3].
+    *   단순한 이진 합격/실패(binary pass/fail)가 아니라, 컨텍스트가 포함된 에러 메시지를 에이전트의 추론 과정으로 다시 피드백(feedback)하여 자기 수정을 돕는다 [3].
+    *   표준 테스트 러너(test runner)로는 파악할 수 없는 아키텍처적 질문들(예: 기존 인증 미들웨어를 사용했는가, 아니면 새로 만들었는가? 응답 형식 규칙을 따랐는가?)을 평가하는 '계획 일치성(plan alignment)' 검증 게이트가 존재한다 [2].
+
+## ⚖️ Trade-offs & Caveats
+PEV 루프 아키텍처를 도입할 때 다음과 같은 제약 사항 및 트레이드오프가 존재한다.
+
+*   **실행 오버헤드 증가**: 에이전트가 단일 패스로 문제를 해결하는 것을 명시적으로 차단하고 계획-실행-검증의 3단계를 강제하므로, 간단한 작업에서도 시스템의 복잡도와 처리 대기 시간(Latency)이 증가할 수 있다 [1, 3].
+*   **하네스 유지보수 부담**: PEV 루프가 제대로 작동하기 위해서는 런타임 및 실행 전후의 여러 단계에서 도구 호출을 차단하거나 허용하는 게이트(gates)를 촘촘하게 설계해야 한다. 인간은 결과물 자체를 리뷰하는 대신 하네스를 유지보수하고 영향력이 큰 결정 지점에서 승인하는 역할을 맡게 되어, 초기 인프라(하네스) 구축 및 관리 비용이 크게 증가한다 [3].
+*   **검증 로직 구현의 어려움**: 코드가 실행되는지 여부를 판단하는 테스트 스위트 외에도, 에이전트가 수립된 계획과 기존 아키텍처 규칙을 준수했는지 확인하는 '계획 일치성(plan alignment)' 검증 로직을 하네스에 별도로 구축해야 하는 기술적 어려움이 따른다 [2].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [아키텍처/패턴 (Architecture / Pattern)]
+- [[Generate-and-Check]]
+  - 연결 이유: PEV 패턴과 대비되는 전통적인 에이전트 실행 방식이기 때문이다.
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 계획 없이 자유롭게 실행한 후 사후 검증(Post-hoc)과 이진 피드백(binary pass/fail)만 제공하는 방식이 가진 한계를 이해하고, PEV 루프의 구조적 필요성을 명확히 할 수 있다 [3].
+
+- [[Agent Harness]]
+  - 연결 이유: PEV 루프는 에이전트 하네스가 제공하는 결정론적 제어(게이트, 피드백 루프) 위에서 작동하는 하네스 설계 패턴이기 때문이다.
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 언어 모델(LLM) 자체의 지능을 넘어, 주변을 둘러싼 실행 환경과 규칙(하네스)이 에이전트의 신뢰성을 어떻게 보장하는지 이해할 수 있다 [1].
+
+#### [검증 및 제어 메커니즘 (Verification & Control Mechanisms)]
+- [[Pre-execution gates]]
+  - 연결 이유: PEV 루프의 실행(Execute) 단계에서 에이전트의 도구 호출을 실제로 통제하는 핵심 하네스 메커니즘이기 때문이다.
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 에이전트가 승인되지 않은 도구를 사용하거나 작업 범위를 벗어난 행동을 시도할 때, 시스템이 이를 실행 전에 결정론적으로 어떻게 차단하는지 파악할 수 있다 [2].
+
+- [[Plan alignment]]
+  - 연결 이유: PEV 루프의 검증(Verify) 단계에서 중요하게 다루어지는 평가 기준으로, 에이전트 산출물의 아키텍처적 일관성을 의미하기 때문이다.
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 단순히 단위 테스트를 통과하는 것을 넘어, 기존 코드베이스의 규칙이나 구조(예: 미들웨어 재사용, 응답 포맷)를 준수했는지 검증하는 심층적인 평가 방식을 이해할 수 있다 [2].
+
+### Deeper Research Questions
+- 단순한 Generate-and-Check 패턴과 비교하여, PEV 루프 아키텍처를 사용할 때 필연적으로 증가하는 API 호출 횟수 및 토큰 소모 비용을 하네스 레벨에서 어떻게 최적화할 수 있는가?
+- 실행 전 게이트(Pre-execution gates)는 에이전트의 도구 인자(argument) 및 접근 권한의 유효성을 어떠한 결정론적(deterministic) 방식으로 평가하는가?
+- 코드 테스트 러너(test runner)로는 확인 불가능한 '계획 일치성(Plan alignment)' 및 아키텍처 준수 여부를 자동화된 하네스 게이트로 구현하기 위해 어떤 기술적 접근이 필요한가?
+- PEV 루프를 통해 에이전트에게 제공되는 '컨텍스트가 포함된 에러 피드백'은 에이전트의 자가 수정(self-correction) 성공률을 얼마나 향상시키는가?
+- 계획 단계(Plan)에서 자유도를 의도적으로 제한하는 것이, 예기치 않은 창의적 해법을 도출할 수 있는 에이전트의 능력을 저해하는 부작용(Trade-off)은 없는가?
+
+### Practical Application Contexts
+- **Implementation:** 복잡한 소프트웨어 개발 작업을 자율 에이전트에게 위임할 때, 한 번의 프롬프트로 전체 코드를 짜게 하지 않고 요구사항 분석 및 계획서 작성, 승인, 실행, 검증의 다단계 워크플로우로 나누어 구현할 때 적용된다.
+- **System Design:** 에이전트가 호스트 시스템에서 파괴적인 도구(예: 셸 명령어, 파일 덮어쓰기)를 무분별하게 사용하는 것을 막기 위해 툴 호출 인터셉터(Pre-execution gates)를 설계할 때 활용된다.
+- **Operation / Maintenance:** 인간 작업자가 에이전트가 만든 코드를 일일이 리뷰하는 방식에서 벗어나, 에이전트의 계획을 승인하고 하네스 검증 규칙을 유지보수하는 방향으로 운영 모델을 전환할 때 핵심적인 기준이 된다.
+- **Learning Path:** LLM을 단순한 추론 엔진을 넘어, 엔터프라이즈 환경에서 안전하게 배포 가능한 '신뢰할 수 있는 워크엔진'으로 격상시키는 하네스 엔지니어링의 핵심 아키텍처 패턴을 학습할 때 필수적이다.
+- **My Project Relevance:** 다중 에이전트 시스템이나 자율 코딩 에이전트를 개발할 때, 에이전트가 무한 루프에 빠지거나 엉뚱한 라이브러리를 임의로 생성하여 사용하는 문제(환각)를 통제하기 위한 파이프라인 설계에 직접적으로 적용 가능하다.
+
+### Adjacent Topics
+- [[Self-verification]]
+  - 확장 방향: 에이전트가 외부의 하네스 피드백뿐만 아니라 스스로 자신의 산출물을 평가하고 비판(critique)하여 수정하는 메커니즘이 PEV의 검증 단계와 어떻게 통합되는지 탐구.
+- [[Human-in-the-Loop (HITL)]]
+  - 확장 방향: PEV 루프 내에서 인간이 개입해야 하는 영향력이 큰 결정 지점(high-leverage decision points)을 어떻게 식별하고 승인 워크플로우를 설계할지에 대한 연구.
+
+---
+*Last updated: 2026-05-01*
\ No newline at end of file
diff --git a/00_Raw/Production Environment Observability.md b/00_Raw/Production Environment Observability.md
new file mode 100644
index 00000000..193a48de
--- /dev/null
+++ b/00_Raw/Production Environment Observability.md	
@@ -0,0 +1,63 @@
+# [[Production Environment Observability]]
+
+## 📌 Brief Summary
+Production Environment Observability(운영 환경 관측성)는 실제 배포된 애플리케이션에서 발생하는 복잡한 버그, 성능 저하, 오류를 추적하고 디버깅하기 위해 시스템의 상태에 대한 가시성을 확보하는 것을 의미합니다 [1, 2]. 이는 수천 가지의 다양한 브라우저 환경과 기기에서 실행되는 프론트엔드 코드의 한계를 극복하기 위해 에러 트래킹, 세션 리플레이, 분산 추적(Distributed Tracing) 등의 기술을 활용합니다 [3-5]. 단순한 오류 수집을 넘어 프론트엔드 로그와 백엔드 트레이스를 연결하여 전체 스택의 성능과 문제의 근본 원인을 파악하는 데 필수적인 역할을 합니다 [5, 6].
+
+## 📖 Core Content
+*   **지능형 에러 그룹화 (Intelligent Error Grouping):** 프로덕션 환경에서는 동일한 에러가 수없이 발생할 수 있습니다. Sentry와 같은 도구는 중복되는 에러의 노이즈를 줄이고 유사한 에러를 자동으로 그룹화하여, 개발자가 실제 사용자에게 영향을 미치는 고유한 문제에 집중할 수 있도록 돕습니다 [2, 7].
+*   **세션 리플레이 (Session Replay):** 에러가 발생하기 전 사용자가 수행한 정확한 동작, DOM 트리의 상태 변화, Redux/Vuex 상태, 네트워크 요청 및 콘솔 로그 등을 비디오처럼 녹화하여 제공합니다 [4, 8]. 이는 콘솔 로그나 사용자 스크린샷만으로는 재현하기 힘든 엣지 케이스를 디버깅하는 데 매우 유용합니다 [3, 8].
+*   **엔드투엔드 분산 추적 (End-to-End Distributed Tracing):** 프론트엔드 모니터링을 백엔드 APM(Application Performance Monitoring)과 연결합니다. 프론트엔드 에러를 클릭하면 백엔드 서비스, 데이터베이스, 서드파티 API를 관통하는 요청의 흐름을 추적할 수 있어 복잡한 분산 시스템 디버깅에 필수적입니다 [5, 9].
+*   **오픈 스탠다드 및 통합 관측 (Open Standards & Unified Observability):** 특정 벤더에 종속되지 않기 위해 OpenTelemetry와 같은 오픈 스탠다드 기반의 도구(SigNoz, Grafana)가 사용됩니다 [6, 10]. 이를 통해 트레이스, 메트릭, 로그를 단일 플랫폼에서 관리하고 데이터 소유권을 유지할 수 있습니다 [11].
+*   **사용자 개인정보 보호 (Privacy Controls):** 세션 리플레이나 로그 수집 시 비밀번호나 개인 식별 정보(PII)가 함께 전송될 위험이 있으므로, 민감한 데이터를 자동으로 마스킹하고 필터링하는 개인정보 보호 설정이 필수적으로 요구됩니다 [4, 12].
+
+## ⚖️ Trade-offs & Caveats
+*   **성능 영향 (Performance Impact):** 관측성 도구의 에이전트가 프론트엔드 번들에 포함되면 추가적인 로드 타임(테스트 기준 최대 120ms 추가)이 발생하여 애플리케이션 성능 및 Core Web Vitals에 악영향을 줄 수 있습니다 [13-15]. 가벼운 모니터링과 상세한 데이터 수집 사이에서 번들 사이즈 타협이 필요합니다 [12, 15].
+*   **프라이버시 위험 (Privacy Concerns):** LogRocket처럼 '모든 것을 캡처'하는 것을 기본값으로 하는 도구는 민감한 데이터가 수집될 위험성이 크기 때문에, 이를 방지하기 위한 세심한 설정 작업에 많은 시간이 소요됩니다 [8, 14].
+*   **비용 확장성 문제 (Pricing Reality & Cost):** 트래픽이 높은 애플리케이션의 경우 Datadog과 같은 플랫폼의 요금 체계(수집과 인덱싱을 따로 과금하는 구조)로 인해 비용이 기하급수적으로 증가할 수 있습니다 [16, 17]. 비용 절감을 위해 전체 로그의 일부(예: 20%)만 인덱싱하게 되면, 장애 발생 시 필요한 80%의 디버깅 데이터를 검색할 수 없는 반대급부가 발생합니다 [18].
+*   **러닝 커브 및 설정 복잡도 (Setup Complexity):** OpenTelemetry 기반의 오픈소스(Grafana, SigNoz 등)는 벤더 종속(Vendor Lock-in)을 방지하고 유연성이 뛰어나지만, 목적에 맞게 사전 구축된 SaaS에 비해 초기 설정이 복잡하고 DevOps 전문 지식이 요구됩니다 [10, 19, 20].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [아키텍처/기반 기술]
+- [[OpenTelemetry]]
+  - 연결 이유: 특정 모니터링 벤더에 종속되지 않고 트레이스, 메트릭, 로그를 수집 및 표준화하기 위해 사용하는 오픈 소스 규격입니다 [6, 10].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 확장 가능한 모니터링 시스템 아키텍처를 설계하고 SigNoz나 Grafana가 어떻게 데이터를 통합하는지 이해할 수 있습니다.
+
+- [[Distributed Tracing]]
+  - 연결 이유: 프론트엔드의 사용자 상호작용에서 시작된 요청이 백엔드의 어느 지점에서 병목이나 에러를 일으키는지 연결하는 기술입니다 [5, 6].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 풀스택 애플리케이션의 엔드투엔드 가시성 확보 원리를 이해할 수 있습니다.
+
+#### [구현/활용 도구]
+- [[Session Replay]]
+  - 연결 이유: 프로덕션 환경의 디버깅을 위해 사용자 환경의 DOM, 네트워크, 상태 변화를 그대로 녹화하는 모니터링 도구의 핵심 기능입니다 [4, 21].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 재현 불가능한 프로덕션 에러의 원인을 시각적으로 역추적하는 방법을 알 수 있습니다.
+
+- [[Error Boundaries]]
+  - 연결 이유: React 내부에서 발생하는 렌더링 에러를 포착(catch)하고 애플리케이션의 전체 크래시를 방지하며, 포착된 에러를 외부 모니터링 서비스(Sentry 등)로 전송할 수 있는 컴포넌트입니다 [22, 23].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 클라이언트 단의 에러 핸들링과 관측성 툴킷 간의 연동 방식을 이해할 수 있습니다.
+
+### Deeper Research Questions
+- 성능 오버헤드(번들 사이즈 증가 등)와 세션 리플레이, 분산 추적 등 고해상도 관측성을 유지하는 것 사이의 최적의 균형점은 어떻게 찾아야 하는가?
+- Datadog의 '수집 및 인덱싱(Ingest and Index)' 이중 과금 모델과 같은 비용 구조를 피하면서 대규모 트래픽에서 로그 검색 효율을 유지할 수 있는 아키텍처 대안은 무엇인가?
+- 프론트엔드 모니터링 도구에서 수집되는 민감한 사용자 정보(PII)의 유출을 원천적으로 차단하기 위한 기술적 구현 및 자동 마스킹 기법은 무엇인가?
+- OpenTelemetry 표준을 기존 상용 서비스(Sentry, LogRocket 등)의 생태계에서 적용하거나 마이그레이션할 때 발생하는 기술적 한계는 무엇인가?
+- Sentry와 같은 도구의 '지능형 에러 그룹화'는 브라우저와 OS 파편화 속에서 어떻게 고유한 에러와 중복 에러를 기술적으로 판별하는가?
+
+### Practical Application Contexts
+- **Implementation:** React 기반 프로젝트 도입 시 에러 발생 가능성이 높은 컴포넌트를 `Error Boundaries`로 감싸고, Sentry나 SigNoz SDK를 연동하여 프로덕션 에러 로그 및 스택 트레이스를 자동으로 수집하도록 구현합니다 [4, 24].
+- **System Design:** 초기에는 무료 SaaS를 사용하다가 서비스 스케일이 커지면 벤더 종속성과 비용 문제를 고려해 OpenTelemetry와 SigNoz 기반의 자체 호스팅 인프라로 모니터링 시스템을 설계합니다 [6, 12, 25].
+- **Operation / Maintenance:** 새벽 2시에 발생하는 프로덕션 장애 신고에 대해, 사용자의 스크린샷에 의존하는 대신 모니터링 툴의 세션 리플레이와 백엔드 트레이스 데이터를 통해 즉각적으로 근본 원인을 파악하고 대응합니다 [3, 15].
+- **Learning Path:** 단순한 `console.log` 디버깅에서 출발하여, 에러 바운더리와 로컬 디버깅 툴을 익히고, 최종적으로 클라우드 로깅 도구와 풀스택 분산 추적 시스템의 활용법을 학습하는 방향으로 나아갑니다 [3, 15].
+- **My Project Relevance:** 현재 진행 중이거나 계획 중인 애플리케이션 배포 시, 사용자 경험(UX)을 저해하는 보이지 않는 에러나 렌더링 성능 저하를 능동적으로 탐지하기 위한 모니터링 파이프라인 구축에 직접적으로 적용 가능합니다.
+
+### Adjacent Topics
+- [[Core Web Vitals]]
+  - 확장 방향: 운영 환경 모니터링의 목적 중 하나가 성능 측정에 있으므로, LCP, FID, CLS 등 프론트엔드 런타임 성능 지표를 어떻게 측정하고 최적화하는지 확장하여 조사할 수 있습니다 [26, 27].
+
+- [[Memory Leaks]]
+  - 확장 방향: 관측성 도구가 성능 저하의 징후를 감지했을 때, 크롬 개발자 도구의 Heap Snapshot 등과 연계하여 실제 메모리 누수를 진단하고 디버깅하는 방법론으로 확장할 수 있습니다 [28, 29].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Production Monitoring and Observability.md b/00_Raw/Production Monitoring and Observability.md
new file mode 100644
index 00000000..ff946970
--- /dev/null
+++ b/00_Raw/Production Monitoring and Observability.md	
@@ -0,0 +1,67 @@
+# [[Production Monitoring and Observability]]
+
+## 📌 Brief Summary
+**Production Monitoring and Observability(프로덕션 모니터링 및 관측성)**는 애플리케이션이 실제 운영 환경에서 작동하는 방식과 성능, 에러를 추적하고 이해하는 과정을 의미합니다 [1-3]. 이는 단순한 오류 로깅을 넘어, 로그(Logs), 메트릭(Metrics), 트레이스(Traces)를 통합하여 복잡한 시스템의 병목 현상과 버그의 근본 원인을 파악하는 것을 포함합니다 [4]. 개발자는 이를 통해 사용자 경험을 저해하는 문제를 사전에 발견하고, 데이터를 기반으로 성능 최적화와 안정성을 보장할 수 있습니다 [3, 5, 6].
+
+## 📖 Core Content
+
+*   **Real User Monitoring (RUM) 및 성능 추적:**
+    실제 사용자의 디바이스와 네트워크 환경에서 발생하는 성능 데이터를 수집하는 기능입니다 [6, 7]. 종합적인 테스트 환경에서는 놓치기 쉬운 실제 성능 문제(예: First Contentful Paint(FCP), Interaction to Next Paint(INP) 등의 Core Web Vitals 지표)를 추적하여 최적화 대상을 식별합니다 [6, 7].
+*   **지능형 에러 추적 및 로깅:**
+    프론트엔드 환경은 매우 다양한 브라우저와 디바이스 조건에서 실행되므로 `console.log`에만 의존하는 것은 한계가 있습니다 [8]. Sentry와 같은 도구는 **지능형 에러 그룹화(Intelligent Error Grouping)**를 통해 중복된 에러의 노이즈를 줄여주며, 콘솔 로그, 네트워크 요청, 사용자 상호작용 등의 Breadcrumb를 제공하여 에러의 근본 원인 파악을 돕습니다 [2, 9]. React 애플리케이션의 경우 **Error Boundaries**를 구성하여 UI 충돌을 방지함과 동시에 Sentry, LogRocket 등의 툴에 에러의 상세 정보를 로깅합니다 [10, 11].
+*   **통합 관측성(Unified Observability)과 분산 추적(Distributed Tracing):**
+    Datadog RUM이나 New Relic, SigNoz 같은 도구들은 프론트엔드 에러와 백엔드 서비스 트레이스(Trace)를 연결하여 복잡한 분산 시스템에서의 End-to-End 디버깅을 가능하게 합니다 [4, 12, 13]. 특히 **OpenTelemetry** 표준을 기반으로 구축된 도구들은 특정 벤더 종속(Vendor lock-in) 없이 트레이스, 메트릭, 로그를 한 곳에서 상관 분석(Correlate)할 수 있도록 지원합니다 [4, 14, 15].
+*   **세션 리플레이 (Session Replay):**
+    LogRocket과 같은 도구는 사용자의 세션을 비디오처럼 녹화할 뿐만 아니라, DOM 변경, Redux/Zustand 상태 변화, 네트워크 요청 및 응답 등을 함께 기록합니다 [2, 16, 17]. 이는 재현하기 어려운 복잡한 상호작용 버그를 해결할 때 매우 강력한 디버깅 컨텍스트를 제공합니다 [2, 17].
+
+## ⚖️ Trade-offs & Caveats
+*   **성능 저하 (Performance Impact):** 모니터링 도구의 에이전트는 애플리케이션 번들 크기를 상당히 증가시킬 수 있으며, 일부 도구는 페이지 로드 시간을 최대 120ms까지 지연시킬 수 있습니다 [5, 18, 19]. 따라서 성능이 중요한 서비스(예: 이커머스)에서는 가벼운 옵션을 선택하거나 신중하게 도입해야 합니다 [5].
+*   **데이터 스케일링에 따른 비용 문제 (Cost at Scale):** SaaS 기반 모니터링 툴은 트래픽과 로그 볼륨에 따라 비용이 기하급수적으로 증가할 수 있습니다 [18-20]. 예를 들어, Datadog은 데이터 수집(Ingest)과 검색을 위한 인덱싱(Index) 요금을 분리하여 부과하므로, 비용 절감을 위해 주요 로그의 80%를 인덱싱하지 못해 중요한 디버깅 데이터를 놓치는 딜레마가 발생할 수 있습니다 [21, 22].
+*   **개인정보 보호 위험 (Privacy Concerns):** Session Replay 등 화면 및 로그를 기록하는 도구들은 설정이 잘못될 경우 비밀번호, 개인정보 등 민감한 데이터를 수집할 수 있습니다 [17, 19, 23]. 세계적인 개인정보 보호 규정 강화에 맞춰 민감한 데이터를 자동으로 마스킹하는 도구를 선택하거나 꼼꼼하게 프라이버시 설정을 구성해야 합니다 [17, 24].
+*   **도입 복잡성 (Setup Complexity):** OpenTelemetry를 기반으로 하는 Grafana나 SigNoz와 같은 도구는 강력한 유연성을 제공하고 벤더 종속을 피할 수 있지만, 목적에 맞게 인프라를 직접 구성하고 대시보드를 구축해야 하므로 SaaS 도구에 비해 높은 학습 곡선과 DevOps 전문 지식을 요구합니다 [14, 24-26].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [아키텍처 및 기반 기술]
+*   [[OpenTelemetry]]
+    *   연결 이유: 측정 데이터(Log, Metric, Trace) 수집 및 계측을 위한 오픈소스 표준 프레임워크입니다 [4, 14].
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 특정 모니터링 공급자(SaaS)에 종속되지 않고 유연한 통합 관측성 생태계를 구축하는 방법과 원리를 파악할 수 있습니다 [4, 14, 15, 24].
+*   [[Real User Monitoring (RUM)]]
+    *   연결 이유: 실제 사용자가 경험하는 애플리케이션 환경의 프론트엔드 로드 시간과 상호작용 지연 등을 측정하는 관측 시스템입니다 [3, 6, 12].
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 실험실 환경(Synthetic Testing)에서 발견하기 어려운 다양한 디바이스 및 네트워크 환경에서의 성능 병목(Core Web Vitals)을 식별하고 개선하는 과정을 이해할 수 있습니다 [6, 7].
+
+#### [구현 및 활용 도구]
+*   [[Error Boundaries]]
+    *   연결 이유: React 컴포넌트 트리 하위에서 발생한 런타임 자바스크립트 오류를 포착하는 메커니즘입니다 [10, 27].
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 앱 전체가 크래시되는 것을 막는 동시에, 포착된 에러를 Sentry나 LogRocket과 같은 프로덕션 모니터링 시스템으로 전송하여 안정적인 장애 추적 시스템을 구축하는 방법을 이해할 수 있습니다 [10, 11].
+*   [[Session Replay]]
+    *   연결 이유: 사용자가 애플리케이션에서 행동한 정확한 순서와 화면 상태를 다시 재생할 수 있는 기능입니다 [16, 23].
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 단순히 스택 트레이스를 보는 것을 넘어 Redux/Zustand 등의 상태 변화 흐름과 DOM 상호작용 전체 컨텍스트를 활용한 강력한 디버깅 기법을 학습할 수 있습니다 [2, 17].
+
+### Deeper Research Questions
+
+*   모니터링 SDK를 번들에 포함할 때 발생하는 성능 오버헤드(로딩 타임, 번들 크기 증가)를 최소화하기 위해 Code Splitting이나 Web Worker를 활용해 최적화하는 방법은 무엇인가?
+*   Datadog이나 Sentry의 비용(Pricing) 급증 문제를 완화하기 위해, 불필요한 로그 생성을 줄이거나 프론트엔드 환경에서 로그를 동적으로 샘플링(Sampling)하는 전략은 무엇인가?
+*   Session Replay 도구를 적용할 때 글로벌 컴플라이언스(GDPR 등)를 준수하기 위하여, DOM의 텍스트와 Input 값을 어떤 메커니즘으로 자동 식별하고 마스킹(Redaction) 처리해야 하는가?
+*   프론트엔드 클라이언트에서 발생한 API 호출 에러를 백엔드 MSA(Microservices Architecture) 환경의 Distributed Trace ID와 어떻게 결합하여 End-to-End 가시성을 달성할 수 있는가?
+*   OpenTelemetry 표준을 도입하여 프론트엔드 로깅 인프라를 자가 호스팅(Self-hosted)하는 경우와 SaaS를 사용하는 경우, 실제 운영 복잡도 및 TCO(총소유비용) 측면에서 어떤 차이가 발생하는가?
+
+### Practical Application Contexts
+
+*   **Implementation:** React 애플리케이션 개발 시 Error Boundaries 컴포넌트를 구현하고, 이 안에서 Sentry API 또는 LogRocket 초기화 코드를 연결하여 미처 잡지 못한 런타임 예외가 클라우드 로깅 도구로 자동 전송되도록 구현합니다 [9, 11].
+*   **System Design:** 시스템 설계 초기 단계에서 관측성(Observability) 전략을 수립할 때, 벤더 종속성을 피하기 위해 프론트엔드와 백엔드의 로깅/추적 규격을 OpenTelemetry 기반으로 통일하고, Trace ID를 HTTP 헤더로 전파하는 구조를 설계합니다 [4, 14, 15].
+*   **Operation / Maintenance:** 프로덕션 배포 이후 Vercel Analytics, Sentry 등의 RUM 대시보드를 통해 LCP, INP, FCP 등 Core Web Vitals 메트릭을 주기적으로 모니터링하며, 메모리 누수나 무한 리렌더링 같은 런타임 성능 저하 요인을 발견하고 개선합니다 [7, 28].
+*   **Learning Path:** 로컬 환경에서 React DevTools와 Chrome Task Manager를 이용해 병목 및 메모리를 분석하는 방법을 익힌 뒤 [29-31], Sentry를 활용한 에러 트래킹, 최종적으로 OpenTelemetry 기반의 풀스택 트레이싱 생태계를 학습하는 순으로 확장합니다.
+*   **My Project Relevance:** 현재 프론트엔드 프로젝트를 스케일링하거나 상용 배포를 준비 중이라면, 기능 고도화와 함께 Sentry 같은 도구를 통합하여 에러 대응 속도를 높이고, 개인정보 마스킹 설정을 반드시 검토하여 프로덕션 준비를 완료하는 데 직접적으로 적용됩니다 [11, 23, 24].
+
+### Adjacent Topics
+
+*   [[Core Web Vitals]]
+    *   확장 방향: 프로덕션 성능 모니터링의 척도가 되는 주요 사용자 중심 성능 지표(LCP, INP, CLS 등)의 정의와 측정 방식, 이를 최적화하기 위한 방법론으로 이해를 확장합니다 [7, 32].
+*   [[Frontend Performance Optimization]]
+    *   확장 방향: RUM 및 모니터링으로 발견된 성능 문제를 실제 코드로 해결하기 위한 React 컴파일러 활용, Code Splitting, Lazy Loading 및 메모이제이션 전략(useMemo, useCallback 등)으로 연결합니다 [33-35].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Production Monitoring.md b/00_Raw/Production Monitoring.md
new file mode 100644
index 00000000..72eacfd2
--- /dev/null
+++ b/00_Raw/Production Monitoring.md	
@@ -0,0 +1,64 @@
+# [[Production Monitoring]]
+
+## 📌 Brief Summary
+Production Monitoring(프로덕션 모니터링)은 실제 서비스가 배포된 프로덕션 환경에서 발생하는 애플리케이션의 동작과 오류, 그리고 사용자 경험을 추적하고 시스템의 가시성(Observability)을 확보하는 과정입니다. 모던 웹 애플리케이션에서는 복잡한 분산 환경과 다양한 사용자 기기에서 발생하는 이슈를 해결하기 위해, 단순한 로그를 넘어 오류 그룹화, 세션 리플레이, 풀스택 분산 추적(Distributed Tracing) 기능을 제공하는 클라우드 모니터링 도구를 활용합니다. 이를 통해 개발자는 사용자에게 영향을 미치는 문제를 신속히 파악하고, 성능 저하나 오류의 근본 원인을 효과적으로 디버깅할 수 있습니다 [1-3].
+
+## 📖 Core Content
+*   **관측성과 오류 추적의 필요성:** 현대의 웹 애플리케이션은 다양한 브라우저와 모바일 환경에서 실행되며 500KB가 넘는 번들로 구성되기도 합니다. 이러한 환경에서 특정 조건(예: Safari 브라우저에서 다크 모드 사용 시 등)에서만 발생하는 오류를 단순한 사용자 스크린샷이나 백엔드 로그만으로 파악하는 것은 불가능에 가깝기 때문에 전용 프론트엔드 로깅 플랫폼의 도입이 필수적입니다 [1, 2].
+*   **주요 모니터링 도구 및 특징:**
+    *   **Sentry:** 개발자 친화적인 에러 트래커로, 유사한 오류를 묶어주는 지능형 오류 그룹화(Intelligent Error Grouping)와 오류 발생까지의 콘솔 로그, 네트워크 요청 등을 보여주는 빵부스러기(Breadcrumb trail) 기능이 뛰어납니다 [3-5].
+    *   **LogRocket:** 오류 로깅을 넘어 화면을 녹화하듯 DOM 변화, Redux/Vuex 상태 변경, 네트워크 응답 등을 기록하여 사용자 행동을 완벽히 재현하는 세션 리플레이(Session Replay) 기술에 강점이 있습니다 [3, 6, 7].
+    *   **Datadog RUM:** 프론트엔드의 오류를 백엔드 서비스, 데이터베이스, 서드파티 API까지 연결하여 보여주는 엔드투엔드 분산 추적(Distributed tracing)을 통해 복잡한 시스템의 연관 관계를 분석하는 데 유용합니다 [3, 8].
+    *   **SigNoz & Grafana:** 특정 벤더에 종속되지 않는 개방형 표준인 OpenTelemetry를 기반으로 하며, 로그, 메트릭, 트레이스를 단일 플랫폼에서 일관되게 제공하여 유연성과 데이터 소유권을 보장합니다 [9-12].
+*   **성능 모니터링(Performance Monitoring):** 이들 도구는 단순히 오류만 잡는 것이 아니라 Core Web Vitals(LCP, FID, CLS) 모니터링을 지원하여 메모리 누수, 느린 렌더링 등 앱의 전반적인 성능 상태를 지속적으로 관측할 수 있게 돕습니다 [13-15].
+
+## ⚖️ Trade-offs & Caveats
+*   **비용(Pricing) 및 가시성의 딜레마:** 데이터 수집량이 증가하면 모니터링 도구의 비용이 기하급수적으로 증가합니다. 특히 Datadog과 같이 데이터 수집(Ingest)과 검색을 위한 인덱싱(Index)에 각각 요금을 부과하는 모델의 경우, 비용 절감을 위해 전체 로그의 일부만 인덱싱하게 되고, 이로 인해 정작 장애 발생 시 필요한 중요 데이터를 검색할 수 없는 상황이 발생할 수 있습니다 [3, 16, 17].
+*   **애플리케이션 성능 저하(Performance Impact):** 완벽한 모니터링과 세션 리플레이를 위해 삽입된 SDK는 애플리케이션의 번들 크기를 증가시키며, 이로 인해 초기 로드 시간이 최대 120ms까지 지연될 수 있습니다. 로딩 속도가 중요한 서비스(예: 이커머스)에서는 가벼운 로깅 도구를 선택해야 합니다 [13, 18-20].
+*   **개인정보 보호 및 보안(Privacy Concerns):** LogRocket처럼 사용자 세션의 모든 DOM과 상태를 기록하는 도구는, 설정이 올바르지 않을 경우 사용자의 비밀번호나 금융 정보 같은 민감 데이터를 그대로 캡처할 위험이 있습니다. 데이터 수집 시 민감 정보를 철저히 마스킹하도록 개인정보 보호 제어에 상당한 노력을 기울여야 합니다 [5, 7, 18, 19].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [아키텍처/기반 기술]
+- [[OpenTelemetry]]
+  - 연결 이유: SigNoz나 Grafana 같은 모니터링 도구들이 특정 벤더(Vendor lock-in)에 종속되지 않기 위해 채택하고 있는 관측성 관련 개방형 표준 기술입니다 [10, 11, 19].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 모니터링 시스템 구축 시 유연성을 높이고 데이터 소유권을 유지할 수 있는 아키텍처 설계 방법을 이해할 수 있습니다.
+
+- [[Distributed Tracing]]
+  - 연결 이유: 프론트엔드의 오류나 지연 현상을 백엔드 인프라와 데이터베이스의 트랜잭션까지 추적하여 근본 원인을 파악하게 해주는 기술입니다 [8, 11, 12].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 마이크로서비스나 풀스택 환경에서 로그가 어떻게 연결되고 상관관계(Correlation)를 가지는지 이해할 수 있습니다.
+
+#### [구현/활용 도구]
+- [[Session Replay]]
+  - 연결 이유: 프로덕션 환경에서 오류 발생 전후의 사용자 화면 조작, 네트워크 요청, 상태(State) 변화를 비디오처럼 재현하여 재현하기 힘든 버그를 파악하게 해줍니다 [3, 5-7].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 단순히 스택 트레이스만으로 해결할 수 없는 사용자 인터랙션 기반의 문제를 디버깅하는 워크플로우를 이해할 수 있습니다.
+
+- [[Intelligent Error Grouping]]
+  - 연결 이유: 수천 개의 오류 로그가 발생했을 때 유사한 오류를 자동으로 하나의 그룹으로 묶어 개발자의 피로도를 줄여주는 기능입니다 [3, 4].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 대규모 프로덕션 환경의 노이즈 속에서 가장 시급한 문제를 선별하고 우선순위를 정하는 방법을 배울 수 있습니다.
+
+### Deeper Research Questions
+- OpenTelemetry 표준을 적용한 모니터링 아키텍처(SigNoz, Grafana)는 기존 상용 도구(Datadog, Sentry)와 비교해 장기적인 데이터 보관 및 쿼리 비용을 어떻게 절감할 수 있는가?
+- 세션 리플레이 기술을 프로덕션에 적용할 때 브라우저의 메인 스레드 점유율과 네트워크 대역폭 소비를 최소화하기 위한 구체적인 최적화 기법은 무엇인가?
+- Datadog의 '수집(Ingest)'과 '인덱싱(Index)'의 이중 과금 구조 하에서 클라우드 예산을 통제하면서도 크리티컬한 로그의 가시성을 확보하는 샘플링 전략은 어떻게 구성해야 하는가?
+- 프로덕션 환경에서 발생한 프론트엔드 상태(예: Redux, Zustand) 에러를 Sentry의 Breadcrumb trail(이동 경로)과 어떻게 통합해야 컴포넌트 재렌더링의 원인을 가장 정확하게 역추적할 수 있는가?
+- Session Replay 솔루션 도입 시 GDPR 등 글로벌 개인정보 보호 규제를 준수하기 위해 민감 데이터를 클라이언트 단에서 누락 없이 마스킹할 수 있는 자동화된 아키텍처는 어떻게 구현하는가?
+
+### Practical Application Contexts
+- **Implementation:** React 애플리케이션의 최상단 오류 바운더리에 Sentry나 LogRocket 등의 SDK를 통합하여, 비동기 로직이나 렌더링 중 발생하는 예기치 못한 에러를 캡처하고 서버로 전송하도록 구현합니다. [3, 5, 7]
+- **System Design:** 프론트엔드의 로깅 트래픽(RUM)에 고유 Trace ID를 부여하고, 이를 백엔드의 APM(Application Performance Monitoring)과 연결하여 엔드투엔드 분산 추적이 가능하도록 전체 관측성 파이프라인을 설계합니다. [8, 11, 12]
+- **Operation / Maintenance:** 앱이 프로덕션에 배포된 후 발생하는 메모리 누수나 Core Web Vitals 점수 하락을 모니터링 대시보드에서 실시간으로 감지하고, 에러 그룹화 도구를 통해 빈도가 높은 이슈부터 점진적으로 해결하여 시스템 안정성을 높입니다. [1-3, 14]
+- **Learning Path:** 처음에는 브라우저의 Chrome DevTools 및 로컬 로깅으로 시작하여, 점차 React Error Boundaries를 통한 에러 격리를 익힌 뒤, Sentry나 SigNoz 같은 클라우드 기반 프로덕션 모니터링 플랫폼 연동으로 학습 범위를 확장해 나갑니다. [1, 2, 21-42]
+- **My Project Relevance:** 현재 진행 중인 프로젝트 규모와 팀의 예산을 고려하여 적합한 도구를 선정해야 합니다. 초기 단계라면 넉넉한 무료 티어를 제공하는 Sentry나 오픈소스인 SigNoz Cloud가 적합하며, 민감한 사용자 정보를 다루는 서비스라면 데이터 마스킹 설정을 필수로 적용해야 합니다. [13, 19, 43, 44]
+
+### Adjacent Topics
+- [[Error Boundaries in React]]
+  - 확장 방향: 모니터링 도구가 캡처한 에러가 발생했을 때, 애플리케이션 전체가 '백지 화면(White screen of death)'으로 크래시 되는 것을 방지하고 Fallback UI를 보여주어 사용자 경험을 보호하는 React 자체의 오류 처리 매커니즘을 알아봅니다 [45-47].
+
+- [[Core Web Vitals]]
+  - 확장 방향: 프로덕션 환경에서 단순한 오류뿐만 아니라, 사용자의 체감 성능을 좌우하는 렌더링 속도와 시각적 안정성(LCP, FID, CLS 등)을 측정하고 모니터링하는 방법을 이해합니다 [14, 15, 48].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Pull Request (PR).md b/00_Raw/Pull Request (PR).md
new file mode 100644
index 00000000..37673484
--- /dev/null
+++ b/00_Raw/Pull Request (PR).md	
@@ -0,0 +1,56 @@
+# [[Pull Request (PR)]]
+
+## 📌 Brief Summary
+Pull Request(PR)는 기능 브랜치(Feature Branch)에서 작업한 코드 변경 사항을 메인 브랜치(`main`)로 병합하기 전에 팀원들의 코드 리뷰와 품질 검증을 거치도록 하는 핵심 협업 프로세스입니다 [1-3]. PR은 단순한 코드 병합 요청을 넘어, 동료의 검토를 촉진하고 버그나 UI 회귀(regression)가 운영 환경에 도달하는 것을 방지하는 품질 관리의 최종 관문 역할을 수행합니다 [3-5]. 아주 작은 변경 사항이라도 일관되게 PR을 생성하는 것은 팀 내 건전한 코드 리뷰 습관과 규율을 형성하는 데 필수적입니다 [4].
+
+## 📖 Core Content
+* **PR의 핵심 목적과 구성:** PR은 코드 리뷰와 협업이 이루어지는 중심 공간입니다. 올바른 PR은 단순히 코드만 올리는 것이 아니라 '무엇이 변경되었는지', '왜 변경되었는지' 명확히 서술해야 하며, UI에 변화가 있다면 스크린샷을 포함해야 합니다 [1]. 또한, PR 이름이나 설명에 JIRA 등의 티켓 ID(예: PROJ-123)를 포함시키면 코드 변경 사항과 비즈니스 요구사항을 연결하는 추적성(Traceability)을 확보할 수 있어, 리뷰어가 변경의 맥락을 빠르게 파악할 수 있습니다 [6, 7].
+* **PR 크기 관리:** PR은 가급적 200줄 이하의 작은 크기로 유지하고, 하나의 논리적 변경 사항(Atomic commit)에만 집중하는 것이 매우 중요합니다 [1, 2, 4]. 리뷰어가 한 번에 2,000줄이 넘는 코드를 감사(Audit)하는 것은 비효율적이며, 크기가 작은 PR일수록 빠르고 철저한 검토가 가능합니다 [3].
+* **병합 전 필수 조건 (Safeguards):** PR을 `main` 브랜치에 병합하기 위해서는 몇 가지 안전장치를 거쳐야 합니다. 일반적으로 브랜치 보호(Branch protection) 설정을 통해 최소 1명 이상의 동료 승인(Peer Review)을 요구합니다 [1, 2, 4, 8]. 또한, 병합 전 CI 파이프라인의 모든 자동화된 테스트가 성공적으로 통과해야만 합니다 [1, 2, 9]. 
+* **시각적 리뷰 (Visual Review):** 프론트엔드 환경에서는 일반적인 코드 리뷰 외에 시각적 리뷰가 필수적입니다. Storybook, Chromatic, Happo와 같은 도구를 CI 파이프라인에 통합하여 PR 생성 시 자동으로 시각적 회귀 테스트(Visual Regression Testing) 및 접근성 테스트를 수행할 수 있습니다 [5, 10-12]. 의도치 않은 레이아웃 변화나 색상 변경이 발생하면 PR에 경고(Badge)가 표시되어 병합을 막고 수동 검토를 유도합니다 [5, 13].
+* **병합 전략과 사후 처리:** PR 리뷰가 완료되어 병합할 때는 전체 히스토리를 깔끔하게 유지하기 위해 스쿼시 병합(Squash Merge)을 사용하는 것이 권장됩니다 [1, 8, 14]. 병합이 끝난 기능 브랜치는 저장소를 깔끔하게 유지하기 위해 즉시(또는 자동) 삭제해야 합니다 [1, 4, 8, 14].
+
+## ⚖️ Trade-offs & Caveats
+* **작업 오버헤드 증가:** 모든 코드 변경 사항(심지어 아주 단순한 오타 수정 등)에 대해서도 PR을 생성하고 동료의 리뷰 및 CI 검사를 기다려야 하므로, 극도로 빠른 개발과 배포가 필요한 상황에서는 이러한 절차가 프로세스 오버헤드로 작용하여 개발 속도를 늦출 수 있습니다 [4, 15].
+* **리뷰 지연 병목 현상:** PR의 크기를 작게 쪼개지 않고 방치하여 거대한 PR이 생성될 경우, 리뷰어가 코드를 파악하고 승인하는 데 너무 많은 시간이 소요되며 리뷰의 질이 하락합니다 [3].
+* **병합 충돌(Merge Conflicts) 위험:** 기능 브랜치를 짧게 유지(Short-lived)하지 않고 오랫동안 작업한 뒤 뒤늦게 PR을 열게 되면, 그 사이 `main` 브랜치에 쌓인 다른 팀원들의 코드와 크게 엇갈리게 되어 해결하기 어려운 대규모 병합 충돌이 발생할 수 있습니다 [8, 14-16].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [협업 및 브랜칭 전략]
+- [[Feature Branch Workflow]]
+  - 연결 이유: PR은 독립된 기능 브랜치에서 안전하게 작업을 마친 후 `main` 브랜치로 통합하기 위해 필수적으로 거치는 프로세스이기 때문입니다 [2, 17, 18].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 브랜치를 논리적인 단위로 분리하고 짧은 주기로 관리하여 어떻게 PR 과정에서의 충돌을 줄이고 협업 효율을 높이는지 이해할 수 있습니다 [8, 15, 18].
+
+#### [코드 품질 및 검증 도구]
+- [[Visual Regression Testing]]
+  - 연결 이유: 프론트엔드 코드의 PR 병합 전 단계에서 UI 변경이나 레이아웃 붕괴를 잡아내는 핵심적인 자동화 테스트 기법입니다 [5, 10].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: Happo나 Chromatic이 어떻게 PR 워크플로우에 결합되어 리뷰어의 부담을 덜고 시각적 안정성을 보장하는지 파악할 수 있습니다 [5, 11].
+- [[Squash Merge]]
+  - 연결 이유: PR을 메인 브랜치에 승인 및 병합할 때 복잡한 중간 커밋 내역을 하나로 정리하여 Git 히스토리를 깔끔하게 관리하는 병합 전략입니다 [1, 8, 14].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 여러 번의 자잘한 커밋이 PR 단위를 기준으로 어떻게 하나의 의미 있는 단위로 압축되는지 이해할 수 있습니다 [1, 8].
+
+### Deeper Research Questions
+- 대규모 팀에서 PR 리뷰의 철저함을 유지하면서도 병합 지연 시간(Lead Time)을 최소화할 수 있는 워크플로우 자동화 방법은 무엇인가?
+- 극히 사소한 변경(오타 수정 등)에 대해 PR 프로세스를 건너뛰고 메인 브랜치에 직접 커밋(Direct push)하는 예외를 두는 것이 장기적으로 코드베이스 안정성에 어떤 영향을 미치는가?
+- Happo나 Chromatic 같은 시각적 테스트 도구들을 CI 파이프라인의 PR 체크에 연동할 때 발생하는 테스트 실행 시간 증가와 비용 문제는 어떻게 최적화할 수 있는가?
+- PR 단계에서 심각한 병합 충돌(Merge Conflict)이 발생했을 때, 이를 해결하고 리뷰어에게 변경 이력을 명확히 전달하기 위한 효과적인 Git Rebase 전략은 무엇인가?
+- PR 이름과 커밋 메시지에 Ticket ID(예: JIRA) 작성을 강제하는 정책이 장애 발생 시 원인 추적과 롤백 프로세스에 어떻게 기여하는가?
+
+### Practical Application Contexts
+- **Implementation:** 새로운 기능이나 버그 픽스 작업 시 `main` 브랜치에 직접 코드를 푸시하지 않고, 새 브랜치를 만들어 작업을 완료한 후 PR을 열어 무엇을 바꿨는지 스크린샷과 함께 상세히 작성합니다 [1, 14].
+- **System Design:** GitHub 등에 Branch Protection Rule을 설정하여, PR이 1명 이상의 승인을 받고 모든 단위 테스트 및 CI 린트 검사를 통과해야만 병합(Merge) 버튼이 활성화되도록 시스템을 설계합니다 [1, 19].
+- **Operation / Maintenance:** 운영 중 장애가 발생하면 과거 PR 기록과 포함된 Ticket ID를 검색하여, 해당 코드가 어떤 비즈니스 요구사항에 의해 추가되었고 누가 리뷰했는지 신속히 맥락을 파악합니다 [6, 7].
+- **Learning Path:** Git을 학습하는 주니어 개발자들은 개인 프로젝트를 진행할 때도 `main` 브랜치에 직접 커밋하는 대신 PR을 열고 스스로 코드 리뷰를 진행하는 방식을 연습하여 실무 협업 표준에 익숙해집니다 [4, 18].
+- **My Project Relevance:** 현재 진행 중인 소규모 팀 프로젝트에 Feature Branch와 결합된 가벼운 PR 워크플로우를 도입하고, '작은 PR 크기 유지', 'Squash Merge 사용', '병합 후 브랜치 삭제' 규율을 적용합니다 [8, 15, 16].
+
+### Adjacent Topics
+- [[Continuous Integration (CI)]]
+  - 확장 방향: PR이 생성되거나 업데이트될 때마다 자동으로 코드를 빌드하고 테스트를 수행하여, 리뷰어가 로직 검토에만 집중할 수 있도록 돕는 자동화 인프라로 확장 학습.
+- [[Code Review]]
+  - 확장 방향: PR이라는 공간 내에서 팀원 간에 효과적이고 건설적인 피드백을 주고받는 커뮤니케이션 기술과 리뷰 문화를 조성하는 방법으로 확장 학습.
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/RAG (Retrieval-Augmented Generation).md b/00_Raw/RAG (Retrieval-Augmented Generation).md
new file mode 100644
index 00000000..bb1e4f4d
--- /dev/null
+++ b/00_Raw/RAG (Retrieval-Augmented Generation).md	
@@ -0,0 +1,56 @@
+# [[RAG (Retrieval-Augmented Generation)]]
+
+## 📌 Brief Summary
+RAG(Retrieval-Augmented Generation)는 AI 모델이 텍스트를 생성하기 전에 신뢰할 수 있는 외부 지식 기반이나 데이터 소스에서 관련 정보를 검색하여 프롬프트를 증강하는 기술입니다. 에이전트 시스템에서는 환각(hallucination)을 크게 줄이고 답변을 사실적 정보로 보강하는 역할을 합니다. 현대의 에이전트 하네스 엔지니어링(Agent Harness Engineering) 맥락에서는 RAG가 단순한 전처리 단계를 넘어, 에이전트가 자율적으로 필요할 때 정보를 점진적으로 가져오는 동적인 도구 호출(Tool Call) 및 컨텍스트 관리 전략으로 진화하고 있습니다.
+
+## 📖 Core Content
+*   **수동적 검색에서 자율적 도구 호출로의 진화 (Agentic RAG):**
+    과거의 RAG는 사용자 쿼리를 기반으로 문서 전체를 한 번에 주입하는 정보 검색 컴포넌트에 가까웠습니다. 그러나 에이전트 환경(예: A-RAG)에서는 RAG를 하네스 도구 설계 문제로 재구성합니다. 검색된 문서를 파이프라인 시작 시점에 일괄 주입하는 대신, 하네스는 키워드 검색, 의미론적 검색, 청크 읽기 등의 검색 도구를 에이전트에게 노출하여, 에이전트가 각 추론 단계에서 필요한 정보만 점진적이고 능동적으로 가져오도록 설계합니다.
+*   **검색 증강 컨텍스트 관리 (Retrieval-Augmented Context Management):**
+    장기 실행(Long-horizon) 에이전트를 위한 지배적인 컨텍스트 관리 접근법입니다. 하네스는 에이전트의 전체 상호작용 기록을 요약하여 발생할 수 있는 정보 손실을 방지하기 위해, 모든 상호작용을 저장하고 각 단계에서 관련된 하위 집합(subset)만을 검색해 컨텍스트 윈도우에 주입합니다. 하네스는 문서의 단순 저장을 넘어 압축 및 추출 과정을 분리하는 파이프라인(예: Haystack 프레임워크 등)을 통해 에이전트의 인지 부하를 줄입니다.
+*   **그래프 구조와의 결합 (GraphRAG):**
+    기본적인 RAG(Baseline RAG)는 여러 정보 조각의 공통 속성을 가로질러 점들을 연결해야 하는 복잡한 질문에 답하거나, 대규모 데이터에서 요약된 의미론적 개념을 전체적으로 이해하는 데 한계를 보입니다. 이를 해결하기 위해 최신 하네스 설계에서는 의미론적 회상(Semantic recall)을 위한 벡터 검색과 관계 추론을 위한 그래프 탐색(Graph traversal), 그리고 진실 데이터를 위한 구조화된 쿼리(SQL/API)를 결합하여 사용합니다.
+*   **MCP와의 상호 보완적 역할:**
+    RAG가 정보의 '수동적 검색(Passive Retrieval)'을 통해 텍스트 생성 전 사실적 정확성을 높이는 데 주력한다면, MCP(Model Context Protocol)는 에이전트가 외부 시스템에서 작업을 '실행(Action)'하고 동적으로 양방향 상호작용을 할 수 있도록 하는 표준입니다. 하네스는 이 두 가지를 결합하여 정보 검색과 작업 실행 능력을 모두 갖춘 에이전트 인프라를 구축합니다.
+
+## ⚖️ Trade-offs & Caveats
+*   **검색 지연 시간의 누적 (Retrieval Latency Injection):** 장기 실행 작업의 경우 매 단계마다 모델 추론 전 저장된 기록에 대한 검색 쿼리가 필요합니다. 대규모 벡터 데이터베이스의 콜드 스타트나 시맨틱 검색 지연 시간이 선형적으로 누적되면 전체 작업 시간에 심각한 오버헤드를 발생시킵니다. 하네스는 인덱스 예열(pre-warming)이나 중복 쿼리 방지 캐싱을 통해 이를 관리해야 합니다.
+*   **적대적 콘텐츠에 의한 검색 게임화 (Retrieval Gaming by Adversarial Content):** 에이전트의 저장소에 외부 콘텐츠가 주입될 수 있는 경우, 공격자는 향후 검색 쿼리와 의미론적 유사성을 극대화하도록 조작된 콘텐츠를 삽입할 수 있습니다. 이는 에이전트의 결정적인 작업 순간에 악의적 지시문이 최우선으로 검색되게 만듭니다. 이를 방지하려면 하네스는 의미론적 유사성뿐만 아니라 정보 출처(Provenance)의 신뢰도에 따른 가중치를 부여해야 합니다.
+*   **토큰 비용 절감 vs 검색 품질 분산 (Token Cost vs Retrieval Variance):** 초장기 컨텍스트(Ultra-long-context) 모델에 모든 데이터를 그대로 주입하는 방식은 충실도(Fidelity)는 높으나 막대한 토큰 비용이 발생합니다. 반면 RAG는 토큰 비용을 크게 줄이는 대신 쿼리 공식화(Query formulation)와 검색 알고리즘의 품질에 에이전트의 성능이 극도로 의존하게 되는 위험을 안고 있습니다.
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [관계 유형 A: 아키텍처/기반 기술]
+*   [[Context Engineering]]
+    *   연결 이유: RAG는 에이전트의 제한된 컨텍스트 윈도우에 필요한 정보만을 선별하여 주입하기 위한 핵심적인 컨텍스트 엔지니어링 전략입니다.
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 하네스가 에이전트의 토큰 예산을 어떻게 관리하고, 무분별한 컨텍스트 부패(Context Rot)를 막기 위해 검색된 데이터를 언제 어떻게 주입하는지 이해할 수 있습니다.
+*   [[Agentic Search]]
+    *   연결 이유: 고정된 RAG 파이프라인에서 벗어나, 에이전트가 직접 다단계 검색을 계획하고 실행하는 능동적 검색 과정입니다.
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: RAG가 단순 전처리 과정이 아니라, 에이전트 하네스의 실행 루프(Execution Loop) 내에서 도구 호출(Tool Call) 형태로 통합되는 방식을 파악할 수 있습니다.
+
+#### [관계 유형 B: 구현/활용 도구]
+*   [[Model Context Protocol (MCP)]]
+    *   연결 이유: RAG가 주로 지식 기반에서 데이터를 '검색'하는 목적이라면, MCP는 에이전트가 외부 시스템과 데이터를 주고받거나 '작업을 수행'하기 위한 양방향 프로토콜 통신 표준입니다.
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 에이전트 하네스에서 정보 검색(RAG)과 외부 환경에 대한 시스템 통합/실행(MCP)이 각각 어떤 경계를 가지고 상호작용하는지 명확히 구분할 수 있습니다.
+
+### Deeper Research Questions
+*   에이전트가 자체적으로 생성한 장기 상호작용 기록을 RAG로 검색할 때, 하네스는 모델의 현재 정보 요구를 정확히 반영하기 위해 쿼리 공식화(Query Formulation)를 모델에 위임할 것인가, 아니면 자체적인 정책으로 제어할 것인가?
+*   악의적인 데이터가 검색을 통해 에이전트의 컨텍스트 윈도우에 주입되는 '검색 게임화(Retrieval Gaming)'를 방어하기 위해, 하네스는 출처 기반(Provenance-weighted) 검색 아키텍처를 어떻게 구현해야 하는가?
+*   수백만 토큰의 컨텍스트 윈도우를 지원하는 모델(Long-context models)의 등장 상황에서, RAG 기반 하네스는 검색 지연 시간 오버헤드와 장문 컨텍스트 직접 주입의 컴퓨팅 비용 간의 트레이드오프를 어떻게 최적화해야 하는가?
+*   검색(Retrieval) 행위가 에이전트의 추론 흐름을 방해하지 않고 독립적으로 작동하도록 서브 에이전트(Subagent)에게 RAG 역할을 위임하는 오케스트레이션 설계는 시스템 안정성에 어떠한 영향을 미치는가?
+
+### Practical Application Contexts
+*   **Implementation:** 방대한 문서 저장소나 지식 기반 위에서 작동하는 에이전트를 구축할 때, Haystack과 같은 데이터 파이프라인 프레임워크나 벡터 데이터베이스를 하네스의 RAG 컴포넌트로 통합하여 구축합니다.
+*   **System Design:** 에이전트의 실행 루프 내에서, RAG를 정적인 파이프라인이 아닌 키워드 검색, 의미론적 검색 도구 등의 집합으로 추상화하여 모델이 필요에 맞게 능동적으로 도구(Tool)를 호출하도록 설계합니다.
+*   **Operation / Maintenance:** 운영 환경에서는 RAG 검색 시 발생하는 지연 시간(Latency)이 전체 에이전트 작업 시간에 미치는 영향을 모니터링하고, 검색 인덱스 예열(Pre-warming) 및 검색 결과 캐싱 최적화를 지속적으로 관리해야 합니다.
+*   **Learning Path:** 기본 RAG 파이프라인 메커니즘 학습 ➔ 지식 그래프를 활용한 GraphRAG 접근법 이해 ➔ 에이전트가 스스로 검색을 제어하는 에이전틱 RAG(Agentic RAG) 설계 패턴으로의 확장.
+*   **My Project Relevance:** 엔터프라이즈 사내 지식 기반 챗봇이나 복잡한 코드베이스를 탐색하는 자율 코딩 에이전트(Autonomous Coding Agent)를 설계할 때, 장기 메모리 소실을 막고 정확한 참조 데이터를 제공하기 위해 하네스 층위에 RAG 메커니즘을 내재화하는 데 핵심적으로 활용됩니다.
+
+### Adjacent Topics
+*   [[GraphRAG]]
+    *   확장 방향: 단순한 벡터 유사도 검색의 한계를 극복하고, 복잡한 문서 간의 관계를 매핑하여 다단계(Multi-hop) 추론을 가능하게 하는 지식 그래프 기반의 검색 증강 모델로 이해를 확장합니다.
+
+---
+*Last updated: 2026-05-01*
\ No newline at end of file
diff --git a/00_Raw/React App Prototypes and Startups.md b/00_Raw/React App Prototypes and Startups.md
new file mode 100644
index 00000000..6d240716
--- /dev/null
+++ b/00_Raw/React App Prototypes and Startups.md	
@@ -0,0 +1,57 @@
+# [[React App Prototypes and Startups]]
+
+## 📌 Brief 신Summary
+React 앱 프로토타입 및 스타트업 환경에서의 프론트엔드 개발은 시장에 빠르게 최소 기능 제품(MVP)을 출시하면서도 향후 확장이 가능하도록 유연성과 단순성을 유지하는 것이 핵심입니다 [1, 2]. 스타트업 프로젝트는 요구사항이 자주 변경되므로 초기부터 과도한 엔지니어링이나 무거운 라이브러리 도입을 피하고 필요한 기능만 구현하는 접근이 권장됩니다 [3-5]. 초기 프로토타입 단계에서는 가벼운 상태 관리 도구와 단순한 구조를 사용하여 빠른 개발 속도를 확보하고, 제품이 성공하여 규모가 커질 때 점진적으로 아키텍처를 고도화하는 전략이 유효합니다 [2, 4, 6].
+
+## 📖 Core Content
+- **초기 상태 관리 전략 (State Management for MVPs):** 스타트업이나 프로토타입 제작 시 상태 관리 도구의 선택은 개발 속도에 큰 영향을 미칩니다. 순수 React Context API는 초기 설정이 빠르고 외부 의존성이 없어 극초기 프로토타입에 유리할 수 있으나, 규모가 커지면 렌더링 성능 문제가 발생합니다 [6, 7]. 스타트업에 가장 추천되는 도구는 **Zustand**입니다. 보일러플레이트가 적어 수주 내에 제품을 출시할 수 있는 빠른 개발 속도를 제공하며, 이후 제품이 성공하여 확장될 때도 무리 없이 대응할 수 있는 최적의 솔루션("Goldilocks solution")입니다 [1, 2, 8]. 반면 Redux는 초기 구조 설정에 시간이 많이 들어 프로토타입에는 과도(overkill)하며 출시를 지연시킬 수 있습니다 [3, 4].
+- **단순한 구조와 YAGNI 원칙 적용:** 스타트업 프로젝트는 요구사항이 끊임없이 변화하는 환경입니다 [5]. 따라서 "You Aren't Gonna Need It"(YAGNI) 원칙을 적용하여 현재 당장 필요한 기능만 구현하고, 미래를 위해 미리 복잡한 기능을 추가하지 않는 것이 중요합니다 [5]. 또한 소규모 프로토타입의 경우, 기술적 파일 유형 기반(Flat Structure 등) 폴더 구조로 시작하는 것이 직관적이고 빠르지만 [9], 기능이 확장될 경우 도메인이나 기능 기반(Feature-based) 구조로 전환하여 유지보수성을 확보해야 합니다 [10, 11].
+- **초기 모니터링 및 로깅 구축:** 자금이 제한적인 스타트업의 경우, Sentry의 무료 티어(월 5만 건 오류 등)나 SigNoz Cloud(월 $49 시작 등)와 같이 기본 기능이 충실하고 비용 효율적인 프론트엔드 로깅 도구를 초기부터 도입하여 프로덕션 환경의 이슈를 선제적으로 파악하며 시작하는 것이 권장됩니다 [12-14].
+
+## ⚖️ Trade-offs & Caveats
+- **빠른 개발 vs. 기술 부채 (Technical Debt):** 초기 프로토타입의 개발 속도를 높이기 위해 '단순함'에만 치중하여 아키텍처 규칙 없이 임의의 위치에 파일을 추가하며 코드를 작성하면, 단기적으로는 빠를 수 있으나 향후 스파게티 코드가 되어 유지보수와 확장에 극심한 어려움을 겪는 기술 부채가 발생합니다 [15, 16].
+- **Context API의 한계와 리렌더링 비용:** "Zero dependency"라는 장점 때문에 프로토타입 전역 상태 관리에 Context API를 섣불리 도입하기 쉽습니다. 하지만 실시간 데이터나 상태 변경이 잦아질 경우, 해당 Context를 구독하는 모든 하위 컴포넌트에서 불필요한 리렌더링 폭풍(re-render storm)이 발생해 대시보드가 멈추는 등 심각한 성능 저하를 초래할 수 있습니다 [6, 7, 17].
+- **상태 관리 도구 이전의 위험성:** MVP를 성공적으로 출시한 이후 스케일업(50~500명 규모) 단계에 도달했을 때, Zustand에서 Redux 등 엄격한 패턴의 도구로 아키텍처를 마이그레이션하는 것은 매우 고통스럽고(Painful) 큰 위험이 따릅니다 [2, 18]. 너무 이른 최적화는 독이 되지만, 전환 타이밍(window)을 놓치면 리팩토링 비용이 걷잡을 수 없이 커집니다 [2, 19].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [아키텍처/기반 기술]
+- [[Context API]]
+  - 연결 이유: 가장 빠르고 추가 의존성 없이 프로토타입을 시작할 수 있는 기본 도구이지만, 빈번한 상태 변경 시 스케일업의 병목이 되는 기술입니다 [6, 7].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 구독 중인 모든 컴포넌트가 리렌더링되는 문제와, 왜 중대형 앱에서 별도의 상태 관리 도구가 필요한지 근본적인 이유를 이해할 수 있습니다 [7, 20].
+- [[YAGNI Principle]]
+  - 연결 이유: 요구사항이 수시로 변하는 스타트업 환경에서 개발 낭비를 막고 민첩성을 유지하기 위한 핵심 소프트웨어 설계 원칙입니다 [5].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 초기 프로토타입 개발 시 오버엔지니어링을 피하고 현재 필요한 최소 기능만 설계하는 클린 코드 철학을 이해할 수 있습니다 [5, 21].
+
+#### [구현/활용 도구]
+- [[Zustand]]
+  - 연결 이유: 스타트업과 MVP 개발에서 빠른 개발 속도를 챙기면서도 향후 앱 확장에 유연하게 대처할 수 있는 최적의 상태 관리 라이브러리로 적극 추천됩니다 [1, 2, 8].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 보일러플레이트 없이도 선택자(Selector) 패턴을 통해 불필요한 렌더링을 방지하는 성능 최적화 기법을 배울 수 있습니다 [1, 22].
+
+### Deeper Research Questions
+
+- 스타트업에서 Zustand로 MVP를 구축한 이후, 앱의 규모가 커짐에 따라 Redux나 더 엄격한 아키텍처로 전환해야 하는 정확한 시점(Window)과 기술적 한계 지표는 무엇인가?
+- 극초기 프로토타입 개발 단계에서 Flat Structure 등 단순한 폴더 구조를 채택했을 때, 향후 Feature-based 구조로 리팩토링하기 가장 용이하게 코드를 결합(Coupling)하지 않는 방법은 무엇인가?
+- 한정된 리소스를 가진 스타트업이 Sentry와 같은 에러 트래킹 도구를 도입할 때, 비용(무료 티어 한도 등) 초과를 막으면서도 치명적인 크래시를 놓치지 않기 위한 Error Boundary의 전략적 배치 방법은 무엇인가?
+- MVP 개발에서 YAGNI 원칙을 적용하여 기능 확장을 억제하면서도, 컴포넌트의 단일 책임 원칙(SRP) 같은 최소한의 SOLID 원칙을 위배하지 않으려면 어떤 코드 리뷰 기준이 필요한가?
+- React Context API를 통해 개발한 프로토타입 대시보드에서 리렌더링 폭풍(Re-render storm)이 발생했을 때, 이를 Zustand로 점진적 마이그레이션(Incremental Migration)하는 가장 안전한 단계별 절차는 무엇인가?
+
+### Practical Application Contexts
+
+- **Implementation:** 스타트업 초기 MVP 개발 시, 보일러플레이트가 많은 Redux 대신 Zustand를 도입하여 단기간 내에 핵심 기능을 구현하고 제품 출시 속도를 극대화합니다 [2, 4].
+- **System Design:** 시스템 설계 초기에는 YAGNI 원칙을 따라 당장 필요한 기능과 상태 구조만 설계하고, 미래를 대비한 불필요한 추상화나 과도한 전역 상태 생성을 지양합니다 [5, 21].
+- **Operation / Maintenance:** 프로토타입 프로덕션 배포 직후, Sentry와 같은 클라우드 로깅 도구를 설정하여 사용자 환경에서 발생하는 JavaScript 예외와 크래시를 수집하고 문제를 수정합니다 [23, 24].
+- **Learning Path:** React 입문 시 Context API를 통해 전역 상태의 기본을 학습한 후, 프로토타입을 확장하며 성능적 한계(리렌더링 문제)를 경험하고 Zustand와 같은 실용적 도구를 도입하는 순서로 학습합니다 [18, 25].
+- **My Project Relevance:** 빠른 시장 반응 검증이 필요한 신규 서비스를 기획 중일 때, 위 전략들을 지침으로 삼아 초기 개발 스택(Zustand + 단순 폴더 구조)을 가볍게 가져가면서도 런칭 후 스케일업을 위한 기술 부채를 통제할 수 있습니다.
+
+### Adjacent Topics
+
+- [[Feature-Sliced Design (FSD)]]
+  - 확장 방향: 프로토타입 단계를 넘어 앱과 개발팀이 성장할 때, 기능과 도메인 중심으로 모듈 간 의존성을 엄격히 격리하여 대규모 프론트엔드 아키텍처의 복잡성을 관리하는 방법을 학습합니다 [26-28].
+- [[Frontend Cloud Logging Tools]]
+  - 확장 방향: 프로토타입 출시 후 실제 사용자의 버그를 추적하기 위해 Sentry, LogRocket, SigNoz 등 다양한 클라우드 모니터링 툴의 기능(Session Replay 등)과 비용(Pricing Reality) 구조를 비교하여 스타트업에 적합한 도구를 선정합니다 [12-14, 29].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/React Development.md b/00_Raw/React Development.md
new file mode 100644
index 00000000..9d1a97fb
--- /dev/null
+++ b/00_Raw/React Development.md	
@@ -0,0 +1,71 @@
+# [[React Development]]
+
+## 📌 Brief 소스 Summary
+React Development는 사용자 인터페이스를 구축하기 위한 효율적이고 유연한 JavaScript 라이브러리 활용 기술이다 [1]. 최근의 프론트엔드 엔지니어링에서는 컴포넌트 최적화, 상태 관리 메커니즘, 확장 가능한 아키텍처(Feature-Sliced Design) 및 자동 메모이제이션 도구(React Compiler)를 결합하여 복잡한 대규모 애플리케이션을 구축하는 방향으로 발전하고 있다 [2-4]. 효과적인 개발과 확장을 위해서는 관심사의 명확한 분리, 엄격한 네이밍 규칙, 그리고 성능 최적화에 대한 체계적인 접근이 필수적이다 [5-8].
+
+## 📖 Core Content
+*   **아키텍처 및 폴더 구조**: 애플리케이션의 규모가 커짐에 따라 파일 유형별 분리보다 도메인이나 기능(Feature) 중심으로 폴더를 구성하는 것이 권장된다 [9, 10]. 현대적인 구조론인 Feature-Sliced Design(FSD)은 앱을 App, Pages, Widgets, Features, Entities, Shared 등의 레이어로 나누고, 상위 레이어가 하위 레이어에만 의존하도록 단방향 규칙을 강제한다 [11-13].
+*   **상태 관리 메커니즘**: 상태의 빈도와 복잡성에 따라 도구를 분리하는 것이 추세다 [14]. 테마나 로케일처럼 자주 변하지 않는 글로벌 상태는 내장 Context API를 사용하고, 자주 변경되어 불필요한 리렌더링을 막아야 하는 상태는 선택자(selector)를 제공하는 Zustand 같은 경량 라이브러리를 사용한다 [15-18]. 거대한 팀과 복잡한 비동기 로직이 얽혀 있는 경우 Redux가 구조화를 돕고, 서버 API 상태 동기화는 TanStack Query(React Query)가 담당한다 [19-21].
+*   **성능 및 렌더링 최적화**: 2025년 기준 도입된 React Compiler는 빌드 타임에 AST를 분석하여 `useMemo`, `useCallback`, `React.memo` 등 수동 메모이제이션을 자동으로 처리하고 불필요한 렌더링을 방지한다 [3, 22, 23]. 런타임 성능을 위해서는 `React.lazy`와 `Suspense`를 활용한 코드 스플리팅을 적용하며, Vite 환경에서는 `manualChunks`를 통해 벤더(vendor) 라이브러리를 분할하여 번들 크기를 최적화한다 [24-26].
+*   **에러 처리와 메모리 관리**: 하위 컴포넌트 트리의 렌더링 에러로 인해 앱 전체가 하얗게 질리는 현상을 막기 위해 Error Boundary를 사용해 Fallback UI를 보여주고 격리한다 [27, 28]. 런타임 중의 메모리 누수(예: 클로저에 묶인 참조, 분리된 DOM 노드 등)는 Chrome DevTools의 Heap Snapshot 및 Allocation Timeline을 활용해 모니터링하고 수정한다 [29-31].
+*   **컨벤션 및 소프트웨어 공학 원칙**: React 함수형 컴포넌트에도 SOLID(특히 단일 책임 원칙, SRP)와 DRY, KISS, YAGNI 원칙을 적용해 거대한 컴포넌트를 분리해야 한다 [32-34]. 파일명은 OS 호환성을 고려해 `kebab-case`를, 컴포넌트 이름은 `PascalCase`를, 함수와 훅은 `camelCase`를 사용하는 것이 표준 네이밍 컨벤션이다 [5, 35-37].
+
+## ⚖️ Trade-offs & Caveats
+*   **React Compiler의 맹점**: React Compiler가 수동 메모이제이션의 수고를 덜어주지만, TanStack Query나 React Router와 같이 렌더링마다 불안정한 객체 참조를 의도적으로 반환하는 서드파티 라이브러리를 사용할 경우 최적화 체인이 깨져 리렌더링이 발생할 수 있다 [38, 39]. 또한 최적화 과정이 블랙박스 형태이므로, 렌더링 성능 이슈 발생 시 코드에 명시된 훅을 확인하는 대신 React Profiler를 파헤쳐야 하는 등 디버깅이 더 까다로워진다 [40].
+*   **Context API vs 외부 상태 관리**: Context API는 React 내장 기능으로 의존성 추가 없이 'Prop-drilling'을 해결할 수 있으나, 컨텍스트 값이 변경될 때 값을 사용하는 모든 하위 컴포넌트를 무조건 리렌더링시키는 성능적 단점이 있다 [16, 18]. 반면 Zustand 같은 라이브러리는 렌더링 성능 최적화에는 탁월하지만, 아키텍처가 너무 유연하여 대규모 팀에서는 패턴이 파편화될 수 있는 위험성을 동반한다 [17, 41]. 
+*   **Error Boundary의 포착 한계**: Error Boundary는 컴포넌트의 렌더링 및 생명주기 내부의 에러는 훌륭하게 잡아내지만, 이벤트 핸들러(`onClick` 등) 내부의 로직, 비동기 콜백(`setTimeout`), 혹은 서버 사이드 렌더링(SSR) 중 발생하는 에러는 포착하지 못한다 [42, 43]. 따라서 별도의 자바스크립트 `try/catch`가 병행되어야 한다 [44].
+*   **Feature-Sliced Design 도입의 부작용**: 도메인 중심으로 파일을 관리하는 방식은 대규모 시스템에서 유지보수성을 극대화하지만, 작은 규모의 앱이나 팀에서는 너무 많은 폴더 뎁스와 구조적 규칙이 과도한 엔지니어링(Over-engineering)으로 이어져 초기 개발 속도를 늦출 수 있다 [45, 46].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [아키텍처 및 폴더 설계]
+- [[Feature-Sliced Design]]
+  - 연결 이유: 컴포넌트를 단순 파일 유형이 아닌 도메인/기능 스코프에 따라 분리하고 레이어 간 의존성 방향을 강제하여 React 앱의 대규모 확장성을 확보하는 아키텍처 방법론이기 때문 [11, 47].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 거대한 프론트엔드 시스템에서 컴포넌트 간 결합도를 낮추고 비즈니스 로직의 응집도를 높이는 설계 철학.
+
+- [[SOLID Principles in React]]
+  - 연결 이유: 단일 책임 원칙(SRP)과 인터페이스 분리 원칙(ISP) 등 전통적인 객체지향 설계 원칙을 React의 함수형 컴포넌트와 훅에 적용하여 클린 코드를 작성하는 방법을 제시하기 때문 [32, 33].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 너무 많은 책임을 지는 300줄 이상의 비대해진 컴포넌트를 관심사별로 분리하는 기준.
+
+#### [상태 관리 및 최적화 도구]
+- [[React Compiler]]
+  - 연결 이유: `useMemo`, `useCallback`과 같은 수동 성능 최적화를 개발자가 직접 작성하지 않아도 빌드 타임에 AST를 분석해 자동으로 JSX와 계산 결과를 메모이제이션하는 2025년 주요 도구이기 때문 [3, 22, 23].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: React의 렌더링 주기에서 불필요한 계산이 어떻게 캐싱되고 컴포넌트 트리의 업데이트를 방지하는지에 대한 빌드 단계 최적화 원리.
+
+- [[Zustand vs Context API]]
+  - 연결 이유: Context API가 초래하는 불필요한 전역 렌더링(리렌더링 폭포) 문제를 Zustand가 독립적인 스토어와 상태 선택자(Selector)를 통해 어떻게 해결하는지를 비교하는 핵심 개념이기 때문 [16, 48].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 전역 상태의 변경 빈도에 따라 적절한 상태 관리 도구를 선택하는 기준과 React 렌더링 비용을 줄이는 방법.
+
+#### [디버깅 및 에러 제어]
+- [[Error Boundaries]]
+  - 연결 이유: 애플리케이션의 특정 UI 요소에서 발생한 자바스크립트 런타임 에러가 전체 화면을 중단시키는 것을 막기 위한 가장 핵심적인 컴포넌트 기반 예외 처리 방식이기 때문 [27, 28].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 선언적 UI 프레임워크에서 예측할 수 없는 오류가 발생했을 때 이를 어떻게 격리하고 Fallback 화면을 띄울 것인가에 대한 처리 패턴.
+
+### Deeper Research Questions
+
+- React Compiler가 빌드 시점에 코드를 자동 메모이제이션함에도 불구하고, 개발자가 `useMemo`나 `useCallback`을 의도적으로 수동 배치해야 하는 구체적인 엣지 케이스는 무엇인가?
+- 대규모 애플리케이션에서 Feature-Sliced Design(FSD)을 적용할 때, 여러 기능(Feature) 도메인이 공통적으로 상호작용해야 하는 교차 관심사(Cross-cutting Concerns) 문제는 어떻게 해결해야 하는가?
+- 상태 업데이트 빈도가 높은 데이터는 Zustand로, 정적 설정은 Context API로 관리할 때, 두 상태 시스템 간의 데이터를 동기화하거나 결합하여 컴포넌트에 주입하는 모범적인 하이브리드 아키텍처는 무엇인가?
+- 이벤트 리스너의 미해제나 클로저로 인해 발생하는 메모리 누수(Memory Leaks) 현상을 Chrome DevTools의 힙 스냅샷(Heap Snapshot) 기능으로 탐지하고 개선하는 구체적 절차는 무엇인가?
+- Vite 기반의 React 프로젝트에서 `manualChunks`를 활용한 의존성 분할이 Core Web Vitals (LCP, INP) 개선에 미치는 영향을 측정하고 분석하는 최적화 프로세스는 무엇인가?
+
+### Practical Application Contexts
+
+- **Implementation:** React 컴포넌트를 생성할 때 운영체제 간 빌드 오류를 방지하기 위해 파일과 폴더명은 `kebab-case`(예: `user-profile.tsx`)를 사용하고 컴포넌트와 인터페이스 명은 `PascalCase`를 따른다. 너무 많은 책임을 갖는 컴포넌트는 SRP에 따라 뷰와 로직으로 분리한다 [5, 33, 35, 36].
+- **System Design:** 코드를 파일 유형(`components`, `hooks`)별로 단순 나열하지 않고 `features/auth/`와 같이 비즈니스 기능별 모듈로 묶어 결합도를 낮추는 Feature-Sliced Design 구조를 채택한다. 각 기능 폴더는 `index.ts`를 통한 Public API만 노출해 캡슐화를 강화한다 [10, 11, 32, 49].
+- **Operation / Maintenance:** 컴포넌트 크래시를 대비하여 독립적인 단위(예: 차트, 폼)마다 Error Boundary를 씌워 장애를 격리하고, 에러 모니터링 플랫폼(Sentry, LogRocket)을 연동하여 런타임 안정성을 확보한다. 또한 메모리 프로파일링으로 Detached DOM Node가 있는지 주기적으로 감시한다 [29, 50-52].
+- **Learning Path:** React 기초 동작과 컴포넌트 분리를 이해한 뒤 → Context API를 이용해 전역 상태를 다루다가 발생하는 리렌더링 이슈를 체감 → Zustand나 Redux 같은 상태 도구를 학습 → 메모리 누수 디버깅 및 React Compiler, FSD 같은 시스템 아키텍처 스케일업 순으로 심화 학습한다 [53].
+- **My Project Relevance:** React 레거시 코드를 리팩토링할 경우, 제일 먼저 렌더링 비용을 높이는 과도한 Context API를 Zustand로 마이그레이션하고, 거대한 컴포넌트 트리를 단일 책임 원칙에 맞춰 분리하여 팀 단위 협업과 테스트가 용이한 아키텍처로 탈바꿈할 수 있다.
+
+### Adjacent Topics
+
+- [[Core Web Vitals & Web Performance]]
+  - 확장 방향: 프론트엔드의 성능 최적화(코드 스플리팅, 레이지 로딩)가 실제 사용자의 화면 표출 속도(LCP)와 상호작용 속도(INP) 등 브라우저 지표와 어떻게 직결되는지 모니터링 기술과 연계하여 탐구 [54, 55].
+
+- [[Vite & Rollup Bundling Strategies]]
+  - 확장 방향: React 작성 코드가 운영 환경에 배포되기 전 Vite와 Rollup을 통해 어떻게 ES 모듈 파싱과 청크 분할(`manualChunks`)이 이루어져 캐싱 효율을 극대화하는지 빌드 도구 관점에서 탐구 [22, 25].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/React Project Git Governance.md b/00_Raw/React Project Git Governance.md
new file mode 100644
index 00000000..3a65c3c3
--- /dev/null
+++ b/00_Raw/React Project Git Governance.md	
@@ -0,0 +1,66 @@
+# [[React Project Git Governance]]
+
+## 📌 Brief Summary
+React 프로젝트 Git 거버넌스는 협업 환경에서 코드 품질을 유지하고 충돌을 방지하기 위해 정의된 브랜치 생성, 커밋 메시지 작성, 풀 리퀘스트(PR) 관리 등의 규칙과 워크플로우를 의미합니다. 소규모 및 대규모 팀에서 메인 브랜치의 안정성을 배포 가능한 상태로 지속 유지하며, 기능 브랜치(Feature Branch) 운용, 티켓 ID 연동, Conventional Commits, 그리고 자동화된 시각적 회귀 테스트(Visual Regression Testing) 등을 통합하여 빠른 피드백 루프와 명확한 추적성을 확보하는 데 중점을 둡니다.
+
+## 📖 Core Content
+*   **브랜치 전략 (Branching Strategies):** 소규모 팀(2~5명)의 경우 복잡한 Git-Flow 워크플로우보다는 '보호된 메인 브랜치를 갖춘 단순 기능 브랜치 워크플로우(Feature-branch workflow)' 또는 단기 기능 브랜치를 활용하는 '트렁크 기반(Trunk-based) 워크플로우'가 권장됩니다. `main` 브랜치는 항상 안정적이고 즉시 배포 가능한 상태여야 하며, 개발자는 절대 `main` 브랜치에 직접 커밋해서는 안 됩니다.
+*   **브랜치 명명 규칙 (Branch Naming Conventions):** 설명이 명확한 짧은 이름을 사용하되, `feature/`, `bugfix/`, `chore/` 등의 유형 접두사를 사용합니다. 이슈 추적성(Traceability)을 위해 JIRA 등의 티켓 ID를 포함하는 것이 좋습니다(예: `feature/PROJ-123-user-auth`). 단어 구분에는 언더스코어(_) 대신 하이픈(-)을 사용하고, 소문자로 통일합니다.
+*   **커밋 규칙 (Commit Rules):** 하나의 커밋은 하나의 논리적 변경사항만 포함하는 원자적 커밋(Atomic Commit)이어야 합니다. 커밋 메시지는 'Conventional Commits' 사양(`feat:`, `fix:`, `refactor:` 등)을 따라 작성하여 히스토리를 쉽게 스캔하고 릴리스 노트를 자동화할 수 있게 합니다. 변경된 내용(What)과 그 이유(Why)를 명확히 작성해야 합니다.
+*   **PR(Pull Request) 및 병합(Merging) 규칙:** 코드를 병합하기 전 반드시 PR을 생성해야 하며, 최소 1명 이상의 동료 코드 리뷰 승인과 CI 테스트 통과가 필수입니다. PR은 빠르고 철저한 리뷰를 위해 단일 작업에 집중된 작은 크기로 유지해야 합니다. 병합 시에는 커밋 히스토리를 깔끔하게 유지하기 위해 스쿼시 병합(Squash Merge)을 주로 사용하며, 병합 후에는 기능 브랜치를 자동 삭제하여 리포지토리를 정리합니다.
+*   **시각적 리뷰 및 자동화 (Visual Reviews):** 프론트엔드/React의 특성에 맞춰 Storybook과 Chromatic 같은 도구를 사용하여 PR 단계에서 시각적 회귀 테스트(Visual Regression Testing)를 수행합니다. 이를 통해 의도치 않은 UI 레이아웃, 여백, 색상 변경 등의 시각적 결함이 프로덕션에 병합되는 것을 선제적으로 차단합니다.
+
+## ⚖️ Trade-offs & Caveats
+*   **엄격한 규칙 vs 개발 오버헤드:** PR 생성, 티켓 ID 필수 포함, 최소 1인 리뷰 요구, CI/CD 빌드 및 테스트 통과 등의 엄격한 규칙은 코드 품질과 안정성을 크게 높이지만, 아주 작고 사소한 수정조차 동일한 프로세스를 거쳐야 하므로 개발 및 배포 속도에 오버헤드를 발생시킬 수 있습니다.
+*   **스쿼시 병합(Squash Merge)의 단점:** 스쿼시 병합은 메인 브랜치의 히스토리를 한 줄로 깔끔하게 유지해주지만, 개발자가 개별 기능 브랜치 내에서 작업하며 남겼던 세세한 커밋 단위의 논리적 흐름이나 히스토리는 메인 브랜치에서 추적하기 어려워집니다.
+*   **장기 브랜치(Long-lived Branches)의 위험:** 권장되는 '단기 기능 브랜치' 원칙을 어기고 기능 브랜치를 너무 오래 유지할 경우, 메인 브랜치와의 동기화가 크게 틀어져 추후 거대한 병합 충돌(Merge Conflict)이 발생하며 이를 해결하는 데 막대한 시간이 소모됩니다.
+*   **Trunk-based 개발 전환 시의 요구사항:** 빠른 통합을 위해 Trunk-based 개발로 전환하려면 팀원 간의 긴밀한 조율과 높은 숙련도가 필요합니다. 또한 완료되지 않은 기능이 사용자에게 노출되지 않도록 기능 플래그(Feature Flags)를 도입하고 강력한 테스트 환경을 갖추어야 하는 추가적인 관리 부담이 따릅니다.
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [관계 유형 A: 아키텍처/기반 기술]
+- [[Feature-branch workflow]]
+  - 연결 이유: 소규모 React 팀에서 코드 충돌을 줄이고 메인 브랜치 안정성을 유지하기 위한 가장 권장되는 기본 Git 브랜치 전략입니다.
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 독립적인 기능 개발을 격리하고 안전하게 통합(Merge)하는 전체 수명 주기 원리.
+- [[Conventional Commits]]
+  - 연결 이유: 커밋 메시지 형식을 표준화하여 자동화된 릴리스 노트 작성과 명확한 코드 히스토리 관리를 가능하게 하는 핵심 거버넌스 규칙입니다.
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: `feat`, `fix`, `chore` 등 커밋 타입의 정확한 의미와 기계가 읽을 수 있는(machine-readable) 히스토리 관리 방법.
+
+#### [관계 유형 B: 구현/활용 도구 및 프로세스]
+- [[Pull Request (PR) Etiquette]]
+  - 연결 이유: 코드가 메인 브랜치에 병합되기 전 코드 품질을 검증하는 최종 관문이자, 팀원 간의 비동기적 소통과 코드 리뷰가 이루어지는 프로세스입니다.
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: PR 크기를 작게 유지하여 리뷰 속도와 정확성을 높이는 협업 최적화 방법.
+- [[Visual Regression Testing]]
+  - 연결 이유: React UI 컴포넌트의 시각적 변경사항(레이아웃, 색상 등)을 PR 단계에서 자동으로 감지하고 리뷰하여 UI 결함을 방지하는 프론트엔드 특화 테스트입니다.
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: Storybook과 Chromatic을 이용한 자동화된 UI 리뷰 워크플로우 및 시각적 차이 비교 원리.
+- [[Squash Merge]]
+  - 연결 이유: 병합 시 기능 브랜치의 여러 커밋을 단일 커밋으로 압축하여 메인 브랜치 히스토리를 정리하는 권장 병합 전략입니다.
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 브랜치 병합 전략의 차이점과 버전 기록 가독성 향상.
+
+### Deeper Research Questions
+
+- Git-Flow, GitHub Flow, Trunk-Based Development 각각의 워크플로우는 React 프로젝트의 규모, 배포 주기, 팀 성숙도에 따라 어떻게 다르게 적용되어야 하는가?
+- 단기 기능 브랜치(Short-lived feature branches)를 유지하기 위해 프론트엔드 개발자가 React 컴포넌트 및 기능 단위를 작게 분할(Task breakdown)하는 가장 효과적인 기준은 무엇인가?
+- Conventional Commits 사양을 프론트엔드 CI/CD 파이프라인(예: 릴리스 버전 자동 펌핑, 체인지로그 자동 생성)과 연동할 때 발생하는 기술적 이점과 구성 상의 제약 사항은 무엇인가?
+- React UI 컴포넌트에 대한 PR 리뷰 시, 전통적인 코드 리뷰(Code Review)와 Chromatic 등을 통한 시각적 리뷰(Visual Review)는 프로세스 상에서 어떻게 결합하여 시너지를 내는가?
+- 지속적인 통합 및 배포(CI/CD)를 위해 Trunk-based 개발을 도입할 때, React 아키텍처 내에서 기능 플래그(Feature Flags)를 어떻게 설계하고 적용해야 하는가?
+
+### Practical Application Contexts
+
+- **Implementation:** React 프로젝트 초기 세팅 시, Husky 등을 사용하여 Git 프리커밋 훅(pre-commit hooks)을 설정함으로써 Conventional Commits 형식과 브랜치 명명 규칙을 팀 전체에 강제할 수 있습니다.
+- **System Design:** 지라(Jira)와 같은 티켓 발행 시스템과 GitHub/GitLab을 연동하여, 생성된 모든 PR과 커밋 내역이 특정 비즈니스 요구사항(티켓 ID)과 1:1로 매핑 및 추적 가능하도록 시스템을 구축합니다.
+- **Operation / Maintenance:** 저장소의 `main` 브랜치에 브랜치 보호 규칙(Branch Protection Rule)을 적용하여, 직배포를 원천 차단하고 반드시 1인 이상의 코드 리뷰 승인과 CI 빌드/테스트(예: ESLint, Storybook 테스트) 통과를 요구하도록 운영합니다.
+- **Learning Path:** 개인 프로젝트에서부터 '새로운 기능 브랜치 생성 -> 의미 있는 원자적 커밋 작성 -> PR 생성 -> 코드 리뷰 시뮬레이션 -> 스쿼시 병합'의 전체 사이클을 체화하고, 점차 시각적 테스트 도구를 PR 리뷰 파이프라인에 통합하는 방법을 학습합니다.
+- **My Project Relevance:** 현재 진행 중인 소규모 React 프로젝트에 복잡한 Git-Flow 대신 제안된 '보호된 메인 브랜치를 지닌 기능 브랜치 워크플로우'를 프로젝트 규칙으로 즉각 도입하여 브랜치 관리 비용과 병합 충돌을 최소화할 수 있습니다.
+
+### Adjacent Topics
+
+- [[CI/CD Pipelines in Frontend]]
+  - 확장 방향: Git 거버넌스를 통해 엄격히 관리되어 병합된 코드가 이후 어떻게 자동으로 빌드, 테스트, 배포되는지 프론트엔드 파이프라인 전체의 구축 방법론을 탐구합니다.
+- [[React Component Testing Strategies]]
+  - 확장 방향: PR을 병합하기 전 CI에서 필수적으로 통과해야 하는 테스트(Unit, Integration, E2E)의 종류와 React 생태계에서 이를 효과적으로 구현하는 전략을 조사합니다.
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/React Suspense.md b/00_Raw/React Suspense.md
new file mode 100644
index 00000000..423c968d
--- /dev/null
+++ b/00_Raw/React Suspense.md	
@@ -0,0 +1,52 @@
+# [[React Suspense]]
+
+## 📌 Brief Summary
+[[React Suspense]]는 `React.lazy()`와 함께 사용되어 동적으로 가져오는 컴포넌트(지연 로딩)의 로딩 상태를 처리하는 React의 기능입니다 [1-3]. 모듈이나 데이터가 로드되는 동안 사용자에게 보여줄 대체 UI(Fallback UI, 예: 로딩 스피너나 스켈레톤 화면)를 정의하는 역할을 합니다 [2]. 이를 통해 초기 번들 크기를 줄이고 애플리케이션의 로딩 속도와 인지되는 성능(Perceived Performance)을 크게 향상시킬 수 있습니다 [2, 4].
+
+## 📖 Core Content
+*   **지연 로딩(Lazy Loading)과의 결합**: 대용량 JavaScript 번들을 분할하기 위해 `React.lazy()`를 사용하여 컴포넌트를 필요한 시점에 비동기적으로 불러올 때, 그 불러오는 시간 동안 렌더링될 UI를 `<Suspense>` 컴포넌트의 `fallback` 속성으로 지정합니다 [1, 2].
+    *   *구현 예시:* `const Dashboard = React.lazy(() => import('./Dashboard'));` 후 `<Suspense fallback={<Spinner />}> <Dashboard /> </Suspense>` 형태로 사용합니다 [1, 2].
+*   **라우트 및 무거운 기능 분할**: 라우트 수준의 컴포넌트나 무거운 UI 블록(예: 대시보드, 차트, PDF 뷰어 등)을 동적 임포트(Dynamic Import)로 전환한 뒤, 각 라우트 엘리먼트를 `<Suspense>`로 감싸면 각 페이지가 독립적인 청크(Chunk)가 되어 사용자가 해당 페이지로 이동할 때만 코드가 다운로드됩니다 [3, 5, 6].
+*   **동시성 기능(Concurrent Features)과의 통합**: React 18 이후의 동시성 훅인 `useTransition` 등과 결합하여 사용할 수 있습니다. 이를 통해 무거운 데이터 필터링 등의 작업이 진행되는 동안 즉각적인 사용자 상호작용(입력 등)을 차단하지 않고 백그라운드 작업으로 처리하며, 필요에 따라 Suspense의 Fallback UI를 표시할 수 있습니다 [7, 8].
+
+## ⚖️ Trade-offs & Caveats
+*   **적용 위치의 제한 (Above-the-fold 주의)**: 모든 컴포넌트에 지연 로딩과 Suspense를 무분별하게 적용해서는 안 됩니다. 페이지 초기 로드 시 즉시 보여야 하는 핵심 콘텐츠(Above-the-fold)나 렌더링 속도가 빨라 즉각적으로 표시되어야 하는 요소에는 Suspense를 통한 지연 로딩 적용을 피해야 합니다 [5].
+*   **기타 제약 사항**: 소스에 관련 정보가 부족합니다. (제공된 소스 데이터 내에서는 Suspense 자체의 깊은 기술적 한계나 서버 사이드 렌더링 시의 복잡한 부작용 등에 대한 구체적인 언급은 없으며, 주로 번들 최적화를 위한 긍정적인 활용법 위주로 설명되어 있습니다.)
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [관계 유형 A (아키텍처/기반 기술)]
+*   [[Code Splitting]]
+    *   연결 이유: 거대한 JavaScript 번들을 작은 단위의 청크(Chunk)로 쪼개는 아키텍처 기법으로, Suspense를 도입하는 핵심 목적입니다 [4, 9].
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 브라우저가 불필요한 코드를 다운로드하지 않게 하여 FCP(First Contentful Paint) 등의 성능 지표를 개선하는 원리.
+*   [[Concurrent Rendering]]
+    *   연결 이유: Suspense는 동시성 렌더링 기능(`useTransition`, `useDeferredValue`)과 함께 사용되어 렌더링 작업의 우선순위를 조정하고 UI 차단(Jank)을 방지하는 데 활용됩니다 [8, 10].
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: React가 백그라운드에서 렌더링 작업을 일시 중지, 중단, 재개하는 메커니즘.
+
+#### [관계 유형 B (구현/활용 도구)]
+*   [[React.lazy()]]
+    *   연결 이유: 컴포넌트의 동적 임포트(Dynamic Import)를 가능하게 해주는 함수로, 항상 `<Suspense>`와 짝을 이루어 사용됩니다 [1-3].
+    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 런타임에 클라이언트가 코드를 온디맨드(On-demand) 방식으로 요청하여 렌더링 트리에 주입하는 방법.
+
+### Deeper Research Questions
+*   React Suspense를 활용한 데이터 패칭(Data Fetching) 로딩 처리는 기존 `useEffect` 기반의 로딩 상태(isLoading) 관리와 비교하여 렌더링 성능 및 코드 복잡도 면에서 어떤 차이를 만들어내는가?
+*   Next.js의 서버 컴포넌트(Server Components) 아키텍처 환경에서 Suspense 경계(Boundaries)는 스트리밍(Streaming) 렌더링과 어떻게 상호작용하는가?
+*   다수의 `<Suspense>` 컴포넌트가 부모-자식 관계로 중첩되어 있을 때, Fallback UI가 화면에 나타나는 우선순위와 렌더링 동작 방식은 어떻게 결정되는가?
+*   Above-the-fold 콘텐츠에 Suspense를 잘못 적용했을 때 발생하는 LCP(Largest Contentful Paint) 성능 저하의 구체적인 브라우저 렌더링 메커니즘은 무엇인가?
+*   에러 경계([[Error Boundaries]]) 컴포넌트와 Suspense를 결합하여 지연 로딩(Lazy Loading) 중 네트워크 오류가 발생했을 때 이를 어떻게 우아하게 복구(Graceful Degradation)할 수 있는가?
+
+### Practical Application Contexts
+*   **Implementation:** `React.lazy()`를 이용해 라우트나 무거운 차트 컴포넌트를 분리하고, 이를 사용하는 부모 컴포넌트 단에 `<Suspense fallback={<LoadingSpinner />}>`를 감싸어 모듈 다운로드 대기 시간을 시각적으로 처리합니다 [2, 3].
+*   **System Design:** Vite나 Webpack 같은 모던 번들러 환경에서 동적 임포트를 설계할 때, 라우트 단위별 코드 스플리팅을 아키텍처의 기본 표준으로 삼아 메인 번들 사이즈를 줄입니다 [3, 9, 11].
+*   **Operation / Maintenance:** 애플리케이션 운영 중 웹팩 번들 아날라이저(Webpack Bundle Analyzer)나 브라우저의 Network 탭을 통해 Suspense 적용 이후 JS 청크 분할이 제대로 이루어졌는지 지속적으로 프로파일링 및 모니터링합니다 [12].
+*   **Learning Path:** React 훅과 상태 관리에 대한 이해를 마친 후, 성능 최적화를 위한 `React.lazy` 학습 -> `Suspense`의 Fallback 처리 -> React 18 동시성 기능 도입 순으로 확장해 나갑니다.
+*   **My Project Relevance:** 방대한 React 레거시 코드베이스를 리팩토링할 때, 가장 무거운 라우트나 자주 사용되지 않는 어드민 뷰 등에 Suspense를 도입하여 초기 로드 시간 및 번들 크기 경고(예: 500kB 초과 경고)를 해결하는 데 적용할 수 있습니다 [5, 13].
+
+### Adjacent Topics
+*   [[Error Boundaries]]
+    *   확장 방향: Suspense가 '로딩 중' 상태를 선언적으로 처리한다면, Error Boundaries는 렌더링 중 또는 지연 로딩 시 발생하는 '실패/에러' 상태를 처리합니다. 두 개념을 나란히 적용하여 견고한 UI 컴포넌트 트리를 구성하는 패턴으로 확장이 가능합니다 [14-16].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/React 애플리케이션 예외 및 에러 처리.md b/00_Raw/React 애플리케이션 예외 및 에러 처리.md
new file mode 100644
index 00000000..7dde2e26
--- /dev/null
+++ b/00_Raw/React 애플리케이션 예외 및 에러 처리.md	
@@ -0,0 +1,63 @@
+# [[React 애플리케이션 예외 및 에러 처리]]
+
+## 📌 Brief Summary
+React 애플리케이션 예외 및 에러 처리는 런타임 중 발생하는 JavaScript 에러로 인해 애플리케이션 전체가 멈추거나 빈 화면(White screen of death)이 표시되는 것을 방지하는 메커니즘입니다. 핵심적으로 'Error Boundary(에러 경계)' 컴포넌트를 사용하여 UI의 렌더링 에러를 포착하고 안전한 폴백(Fallback) UI를 제공하며, Sentry 등 프론트엔드 로깅 도구와 결합하여 프로덕션 환경의 에러를 모니터링하고 복원력을 확보합니다.
+
+## 📖 Core Content
+
+*   **Error Boundary의 개념 및 동작 원리:** Error Boundary는 하위 컴포넌트 트리의 렌더링, 생명주기 메서드 및 생성자에서 발생하는 JavaScript 에러를 포착하는 React의 특수 클래스 컴포넌트입니다 [1, 2]. `static getDerivedStateFromError()` 메서드를 통해 에러 발생 후 폴백 UI를 렌더링하도록 상태를 업데이트하며, `componentDidCatch()` 메서드를 사용하여 에러 정보를 로깅합니다 [3].
+*   **에러 포착의 한계 (잡지 못하는 에러):** Error Boundary는 컴포넌트의 선언적 렌더링 과정에서 발생하는 에러만 포착합니다. 즉, 이벤트 핸들러(Event handlers), 비동기 코드(`setTimeout` 등), 서버 사이드 렌더링(SSR), 그리고 Error Boundary 자체에서 발생한 에러는 포착하지 못합니다 [3, 4]. 이벤트 핸들러의 경우 일반적인 자바스크립트의 `try / catch` 구문을 사용하여 에러를 처리해야 합니다 [5, 6].
+*   **컴포넌트 트리 마운트 해제 정책:** React 16부터는 Error Boundary에 의해 포착되지 않은 에러가 발생할 경우, 손상된 UI를 그대로 노출하는 것(예: 잘못된 대상에게 메시지가 보내지는 현상 등)이 더 큰 문제를 유발할 수 있다고 판단하여 전체 React 컴포넌트 트리를 마운트 해제(unmount)시킵니다 [7, 8]. 
+*   **전략적 배치 (Granularity):** 단일 Error Boundary로 앱 전체를 감싸는 대신, 서드파티 위젯, 차트, 복잡한 폼 등 불안정할 수 있는 섹션 단위로 개별적인 Error Boundary를 배치하는 것이 권장됩니다. 이를 통해 특정 컴포넌트가 다운되더라도 나머지 UI 부분은 계속 상호작용 가능한 상태를 유지할 수 있습니다 [7, 9, 10].
+*   **클라우드 로깅 도구를 활용한 모니터링:** 프로덕션 환경에서는 Error Boundary와 Sentry, LogRocket, SigNoz 등의 프론트엔드 모니터링 툴을 결합하여 사용해야 합니다 [10-12]. 이러한 도구들은 중복 에러를 지능적으로 그룹화하고, 세션 리플레이 기능 및 컴포넌트 스택 트레이스를 제공하여 로컬 밖에서 일어난 예외 상황을 정확하게 디버깅할 수 있게 해줍니다 [11-14].
+
+## ⚖️ Trade-offs & Caveats
+*   **클래스 컴포넌트의 강제성:** 최신 React 개발이 훅(Hooks)을 활용한 함수형 컴포넌트 위주로 이루어짐에도 불구하고, Error Boundary 자체는 반드시 클래스 컴포넌트로만 작성해야 한다는 제약이 있습니다 [4, 15]. (`react-error-boundary`와 같은 외부 라이브러리를 통해 훅 기반 래퍼로 우회할 수는 있습니다 [4]).
+*   **보이지 않는 에러의 치명성 vs. 빈 화면의 위험성:** 포착되지 않은 에러 발생 시 컴포넌트를 마운트 해제하는 정책은 사용자에게 '빈 화면'을 보여줄 수 있는 위험(UX 저하)을 감수하는 것입니다. 이는 오작동하는 UI를 남겨두어 발생할 수 있는 심각한 비즈니스 논리적 오류를 막기 위한 기술적 반대 급부(Trade-off)입니다 [8].
+*   **성능 모니터링 도구의 오버헤드:** Sentry나 LogRocket과 같이 상세한 세션 리플레이와 에러 트래킹을 제공하는 도구를 도입하면 강력한 디버깅 컨텍스트를 얻을 수 있으나, 번들 사이즈 증가 및 일부 도구의 경우 최대 120ms의 추가 로딩 시간을 유발하는 성능적 부작용이 발생할 수 있습니다 [16-18].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [아키텍처 및 기반 기술]
+- [[Error Boundaries]]
+  - 연결 이유: React 애플리케이션의 선언적 에러 처리를 위한 핵심 내장 기능입니다.
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: `getDerivedStateFromError`와 `componentDidCatch`의 동작 원리 및 선언형 UI 모델에서 예외가 전파되는 방식.
+- [[Fallback UI]]
+  - 연결 이유: 에러가 발생했을 때 애플리케이션의 크래시를 숨기고 사용자 경험을 보호하는 대체 렌더링 기술입니다.
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 예외 발생 시나리오에서도 시스템의 일부를 격리시켜 정상적인 서비스를 이어가게 만드는 UI/UX 설계.
+
+#### [구현 및 활용 도구]
+- [[Sentry / LogRocket]]
+  - 연결 이유: Error Boundary에서 잡아낸 에러 및 포착하지 못한 런타임 에러를 중앙 서버로 수집하고 시각화해 주는 클라우드 관측성 도구입니다.
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 소스 맵(Source Map)을 활용한 스택 트레이스 복원 및 세션 리플레이(Session Replay)를 통한 실사용자 에러 컨텍스트 파악.
+- [[Memory Leaks (메모리 누수)]]
+  - 연결 이유: 직접적인 에러 스로우(Throw)를 발생시키진 않지만 애플리케이션 크래시나 성능 저하, UI 먹통을 유발하는 치명적인 예외적 결함입니다.
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: `useEffect`의 클린업 누락 등으로 인해 분리된 DOM 노드(Detached DOM nodes)가 발생하여 메모리가 회수되지 않는 현상 및 이를 Chrome DevTools의 Heap Snapshot으로 추적하는 방법 [19-22].
+
+### Deeper Research Questions
+
+- React 16의 '포착되지 않은 에러 시 전체 컴포넌트 트리 마운트 해제'라는 설계 결정이, 데이터 손실에 민감한 금융권 등의 애플리케이션에서 실제로 어떤 장단점을 가지는가?
+- 비동기 코드(Async) 및 이벤트 핸들러(Event Handler)에서 발생하는 에러를 Error Boundary 패턴과 어떻게 단일화(Unify)하여 중앙 집중식으로 관리할 수 있는가?
+- LogRocket이나 Sentry와 같은 프론트엔드 로깅 도구를 도입할 때, 민감한 사용자 개인정보(PII)가 캡처되는 것을 막으면서도 유효한 에러 스택을 수집하는 최적화 방법은 무엇인가?
+- 함수형 패러다임이 정착된 현재, React 팀이 Error Boundary 기능을 훅(Hook) 생태계에 직접 편입시키지 않는 구조적 이유는 무엇인가?
+- Feature-Sliced Design (FSD) 아키텍처를 사용할 때, Error Boundary를 Feature 레벨에 배치할 것인가 아니면 Widget 및 Pages 레벨에 배치할 것인가에 대한 전략적 기준은 무엇인가?
+
+### Practical Application Contexts
+
+- **Implementation:** React 클래스 컴포넌트를 활용해 재사용 가능한 Error Boundary 컴포넌트를 작성하고, 그 내부에 자식 컴포넌트(`children`)를 렌더링하며, 이벤트 핸들러 내에는 반드시 `try/catch` 구문을 별도로 구현합니다.
+- **System Design:** 대규모 애플리케이션 기획 시 전체 화면을 감싸는 전역 에러 핸들러와 더불어 탭, 모달, 차트, 서드파티 위젯 등 격리 가능한 요소마다 지역적 Error Boundary를 설계하여 장애 영향을 최소화(Blast radius 제한)합니다.
+- **Operation / Maintenance:** 프로덕션 환경에 Sentry와 같은 Observability 툴을 연동하고, 에러 바운더리 내 `componentDidCatch`에서 해당 툴의 로거를 호출하여 에러 발생 빈도와 사용자 세션을 모니터링/운영합니다.
+- **Learning Path:** 컴포넌트 생명주기 및 렌더링 흐름 이해 ➔ Error Boundary 작성법 숙지 ➔ 예외 상황(렌더링 중 에러 vs 이벤트 처리 중 에러) 구분 방법 학습 ➔ 로깅 라이브러리를 통한 프로덕션 모니터링으로 학습을 전개합니다.
+- **My Project Relevance:** 현재 개발 중인 React 앱에서 특정 컴포넌트 내부의 사소한 데이터 결함으로 인해 앱 전체가 다운되는 현상(빈 화면)을 방지하고 서비스 안정성을 높이기 위해 즉시 적용해야 합니다.
+
+### Adjacent Topics
+
+- [[Frontend Observability (프론트엔드 관측성)]]
+  - 확장 방향: 단순 에러 캐치를 넘어서 Tracing, Metrics 시각화 등을 통해 애플리케이션의 상태와 백엔드와의 통합 통신 과정 전체를 모니터링(예: Datadog RUM, Grafana 등)하는 아키텍처로 지식을 확장할 수 있습니다.
+- [[React Performance Optimization (성능 최적화)]]
+  - 확장 방향: 렌더링 중 발생하는 예외뿐만 아니라, 과도한 리렌더링이나 잘못 사용된 React 훅(예: 의존성 배열 오류)으로 인해 애플리케이션 응답성이 저하되고 최종적으로 크래시를 유발하는 이슈를 디버깅하는 방법론으로 확장합니다.
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Rules of React.md b/00_Raw/Rules of React.md
new file mode 100644
index 00000000..e9577971
--- /dev/null
+++ b/00_Raw/Rules of React.md	
@@ -0,0 +1,64 @@
+# [[Rules of React]]
+
+## 📌 Brief Summary
+'Rules of React'는 리액트 컴포넌트가 렌더링 사이클에서 예측 가능한 동작을 하도록 보장하기 위해 준수해야 하는 엄격한 가이드라인입니다 [1]. 이 규칙의 핵심은 렌더링 중 불변성(immutability)을 유지하고 사이드 이펙트(side effects)를 발생시키지 않는 것입니다 [2]. 또한 훅(Hooks)을 조건문 없이 컴포넌트 최상단에서만 호출해야 한다는 'Rules of Hooks'를 포괄하며 [3], 최근의 React Compiler가 빌드 타임에 코드를 자동으로 최적화(메모이제이션)하기 위해서는 이 규칙의 엄격한 준수가 필수적입니다 [1].
+
+## 📖 Core Content
+*   **렌더링의 예측 가능성 보장**: 리액트 컴포넌트는 모든 렌더링에서 일관되고 예측 가능한 동작을 해야 합니다 [1]. 이를 위해 컴포넌트의 렌더링 과정은 사이드 이펙트 없이 순수(pure)해야 하며, 상태와 데이터의 불변성(immutability)을 철저히 지켜야 합니다 [2].
+*   **Rules of Hooks (훅의 규칙)**: 리액트의 상태와 생명주기를 다루는 훅 사용 시 반드시 지켜야 하는 핵심 세부 규칙입니다 [3].
+    *   **최상단 호출**: 훅은 항상 리액트 함수의 최상단(top level)에서만 호출되어야 합니다 [3].
+    *   **조건부 호출 금지**: 조건문, 루프(loops), 중첩된 함수 내부에서 무조건적으로 훅이 호출되어서는 안 됩니다 [3].
+    *   **올바른 호출 위치**: 일반 자바스크립트 함수 내에서는 훅을 호출할 수 없으며, 반드시 리액트 함수형 컴포넌트나 커스텀 훅(Custom Hooks) 내부에서만 호출해야 합니다 [3].
+    *   **순서 일관성**: 모든 렌더링에서 훅의 이름과 호출 순서가 동일하게 유지되어야 합니다 [3].
+*   **정적 분석 및 린팅(Linting) 도구의 활용**: 'Rules of React' 위반을 방지하고 예측 가능한 코드를 강제하기 위해 정적 분석 도구를 사용해야 합니다 [1]. 특히 ESLint의 `eslint-plugin-react-hooks` 플러그인(`recommended` 또는 `recommended-latest` 프리셋)을 설정하여 빌드 전에 오류를 잡아내는 것이 권장됩니다 [1].
+*   **React Compiler와의 연관성**: 2025년 기준 안정화된 React Compiler는 코드가 'Rules of React'를 따른다고 가정하고 작동합니다 [1]. 정적 분석을 통해 규칙을 준수하는 코드 요소(JSX, 훅 등)에 자동으로 세밀한 메모이제이션 로직을 주입합니다 [1, 4]. 만약 규칙을 위반한 코드가 발견되면, 컴파일러는 코드를 망가뜨리지 않기 위해 해당 부분의 최적화(auto-memoization)를 안전하게 건너뜁니다 [1, 5].
+
+## ⚖️ Trade-offs & Caveats
+'Rules of React'를 시스템적으로 강제할 때 직면하는 가장 큰 제약은 기술 부채가 쌓인 레거시 코드베이스(Legacy Codebases)에서의 도입 비용입니다 [6]. 기존의 대규모 프로젝트에는 컴포넌트 라이프사이클이나 훅 사용 시 'Rules of React'를 위반하는 코드가 여러 곳에 흩어져 있는 경우가 많습니다 [6]. 새로운 React Compiler를 도입해 자동 최적화 이점을 얻으려면, 컴파일러가 제대로 작동하기 전에 이러한 규칙 위반 사항을 모두 찾아내어 수정하는 대규모 리팩토링이 요구됩니다 [6]. 
+또한, 서드파티 라이브러리(예: TanStack Query, Material UI 등)가 렌더링마다 새로운 객체 참조를 반환하도록 설계된 경우, 컴파일러가 규칙에 기반하여 캐싱을 시도하더라도 이를 우회하여 불필요한 리렌더링을 유발할 수 있으므로, 여전히 수동 메모이제이션 훅을 조합해 사용해야 하는 한계가 존재합니다 [6, 7].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [아키텍처/기반 기술]
+- [[React Compiler]]
+  - 연결 이유: React Compiler는 소스 코드가 'Rules of React'를 준수한다는 가정하에 빌드 타임 자동 메모이제이션을 수행하는 도구입니다 [1].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 규칙을 준수할 때 얻을 수 있는 구체적인 성능 향상(INP 개선 등)과 컴파일러의 세분화된 최적화 작동 원리를 이해할 수 있습니다 [4, 8].
+- [[Immutability & Side Effects]]
+  - 연결 이유: 'Rules of React'의 가장 핵심적인 근본 원칙이 바로 렌더링 중 불변성 유지와 사이드 이펙트 방지입니다 [2].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 왜 리액트가 렌더링을 예측 가능하게 유지해야 하며, 부수 효과가 렌더링 성능에 어떤 악영향을 미치는지 원론적으로 파악할 수 있습니다.
+
+#### [구현/활용 도구]
+- [[eslint-plugin-react-hooks]]
+  - 연결 이유: 개발자가 실수로 'Rules of React'를 위반하지 않도록 정적 분석을 통해 경고하고 규칙을 강제하는 필수 ESLint 플러그인입니다 [1].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 린팅 도구가 컴파일 타임에 코드의 컨텍스트를 어떻게 분석하여 훅의 호출 순서와 조건부 실행을 막는지 실무적 관점에서 알 수 있습니다.
+- [[React Hooks]]
+  - 연결 이유: Rules of React의 가장 대표적인 하위 규칙인 'Rules of Hooks'의 직접적인 대상입니다 [3].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 함수형 컴포넌트 내에서 상태(State)와 생명주기를 다룰 때 왜 최상단 호출 및 무조건적 호출이 필요한지 설계적 관점을 제공합니다 [3].
+
+### Deeper Research Questions
+
+- React Compiler는 정적 분석 과정에서 'Rules of React' 위반 여부를 구체적으로 어떻게 판별하며, 위반 시 컴파일러는 내부적으로 어떤 Fallback 전략을 취하는가?
+- 레거시 애플리케이션에서 흩어져 있는 'Rules of React' 위반 코드를 React Compiler 친화적으로 리팩토링하기 위한 점진적 마이그레이션(Incremental Migration) 전략은 무엇인가?
+- 훅(Hooks)의 내부 구현체 구조상, 호출 순서가 변경되거나 조건부로 호출될 때 리액트 엔진에서 정확히 어떤 메모리 참조 에러가 발생하는가?
+- `eslint-plugin-react-hooks` 플러그인은 정규 자바스크립트 함수와 커스텀 훅을 구문 분석 트리에 기반하여 어떻게 정확하게 식별해 내는가?
+- 서드파티 라이브러리가 유도하는 규칙 위반(의도적인 불안정 참조 반환)과 React Compiler 간의 충돌을 해결하기 위한 최적의 우회(workaround) 패턴은 무엇인가?
+
+### Practical Application Contexts
+
+- **Implementation:** 리액트 함수형 컴포넌트를 작성할 때, 모든 `useState`, `useEffect` 등의 훅을 조건문이나 반복문 내부가 아닌 컴포넌트 최상단 계층에 선언하여 상태 관리 코드를 구현합니다 [3].
+- **System Design:** 애플리케이션의 렌더 트리 전반에서 순수성(purity)을 보장하기 위해 데이터 가공 및 부수 효과 발생 지점을 렌더링 사이클 밖(예: 이벤트 핸들러나 미들웨어)으로 분리하는 아키텍처를 설계합니다 [2].
+- **Operation / Maintenance:** CI/CD 파이프라인에 ESLint 설정을 통합하여 `eslint-plugin-react-hooks`를 통해 'Rules of React' 위반 코드가 프로덕션 브랜치에 병합(merge)되는 것을 자동화된 방식으로 차단합니다 [1].
+- **Learning Path:** 리액트 초심자가 함수형 컴포넌트를 학습할 때, 훅의 사용법보다 먼저 렌더링 원리와 'Rules of Hooks'를 학습하여 추후 발생할 수 있는 난해한 버그를 방지합니다 [3].
+- **My Project Relevance:** React Compiler를 적용하여 대규모 애플리케이션의 성능을 최적화하기 전, 기존 코드베이스 전반에 걸친 'Rules of React' 위반 사례들을 분석하고 이를 안전하게 리팩토링하는 기반 작업에 직결됩니다 [6].
+
+### Adjacent Topics
+
+- [[Automatic Memoization]]
+  - 확장 방향: 'Rules of React'를 준수함으로써 달성할 수 있는 React Compiler의 핵심 기능으로, 수동 메모이제이션(`useMemo`, `useCallback`)과의 성능 차이 및 추상화 원리를 심층적으로 비교합니다 [4, 8].
+- [[Technical Debt]]
+  - 확장 방향: 레거시 코드에서 규칙을 위반한 구조적 부채가 새로운 최적화 도구(React Compiler 등)의 도입을 어떻게 가로막고 유지보수 비용을 증가시키는지 탐구합니다 [6].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Scalable React Apps.md b/00_Raw/Scalable React Apps.md
new file mode 100644
index 00000000..701fafc8
--- /dev/null
+++ b/00_Raw/Scalable React Apps.md	
@@ -0,0 +1,82 @@
+# [[Scalable React Apps]]
+
+## 📌 Brief 단기 Summary
+Scalable React Apps(확장 가능한 리액트 앱)는 애플리케이션의 규모가 커지고 팀 단위의 협업이 증가함에 따라 발생하는 아키텍처 붕괴, 성능 저하, 유지보수성 하락 문제를 방지하기 위해 견고하게 설계된 시스템을 의미합니다 [1-3]. 이를 위해 코드를 단순히 파일 유형별로 묶는 방식에서 벗어나 비즈니스 도메인 및 기능(Feature) 중심으로 구조화하고 명확한 의존성 규칙을 부여합니다 [4, 5]. 또한, 효율적인 상태 관리 도구의 도입, 렌더링 최적화 기술, 그리고 SOLID와 같은 클린 코드 원칙을 통합하여 장기적으로 유지 및 확장 가능한 프론트엔드 환경을 구축하는 것이 핵심입니다 [6-9].
+
+## 📖 Core Content
+
+*   **아키텍처 및 폴더 구조 (Architecture & Folder Structure)**
+    *   앱 규모가 커질수록 파일 유형(components, hooks 등)에 따른 폴더 구조는 코드 파편화를 일으켜 유지보수를 어렵게 만듭니다 [10-12].
+    *   확장성을 위해 비즈니스 로직과 UI를 기능(Feature)이나 도메인 단위로 캡슐화하는 구조(Feature-Based Structure)가 권장됩니다 [5, 13].
+    *   대표적으로 **Feature-Sliced Design (FSD)** 방법론이 있으며, 이는 `app`, `pages`, `widgets`, `features`, `entities`, `shared`의 계층 모델을 제공하고, 하위 계층이 상위 계층을 참조하지 못하도록 '단방향 의존성'을 강제하여 결합도를 낮춥니다 [14, 15]. 각 슬라이스는 `index.ts`를 통한 단일 Public API만을 노출하여 내부 구현을 캡슐화해야 합니다 [7, 16].
+*   **클린 코드 및 코딩 표준 (Clean Code & Standards)**
+    *   확장 가능한 코드베이스를 위해 **SOLID, DRY, KISS, YAGNI** 원칙이 필수적입니다 [7, 17]. 예를 들어, 단일 책임 원칙(SRP)에 따라 비즈니스 로직과 데이터 페칭(Data fetching)을 커스텀 훅으로 분리하고 컴포넌트는 UI 렌더링에만 집중해야 합니다 [18-20].
+    *   팀 협업을 위해 일관된 명명 규칙(Naming Convention)을 적용해야 합니다. 컴포넌트는 `PascalCase`, 폴더와 파일명은 OS 호환성을 위해 `kebab-case`, 커스텀 훅이나 유틸리티 함수는 `camelCase`를 사용하는 것이 권장됩니다 [21-25].
+*   **상태 관리 아키텍처 (Advanced State Management)**
+    *   상태 관리는 하나로 통합하기보다 데이터 성격에 따라 파편화(Fragmentation)하여 관리해야 합니다 [8].
+    *   **Context API:** 다크 모드, 언어 설정 등 변경이 거의 없는 정적 글로벌 상태에 적합합니다 [26, 27]. 하지만, 값이 변할 때마다 이를 구독하는 모든 하위 컴포넌트가 리렌더링되므로, 빈번하게 변경되는 상태에는 부적합합니다 [28, 29].
+    *   **Zustand / Redux:** 알림, 장바구니 등 동적 상태 관리에는 컴포넌트가 필요한 상태 조각(Slice)만 선택(Select)해 리렌더링을 방지할 수 있는 Zustand가 효과적입니다 [30-32]. 10명 이상의 대규모 팀이나 복잡한 비동기 작업이 많은 경우 엄격한 패턴과 구조를 강제하는 Redux가 더 나은 선택일 수 있습니다 [33-35].
+    *   **서버 상태 분리:** API에서 가져온 서버 데이터는 클라이언트 상태와 분리하여 TanStack Query (React Query) 같은 라이브러리로 캐싱 및 동기화를 전담하게 합니다 [36, 37].
+*   **성능 최적화 (Performance Engineering)**
+    *   초기 로딩 속도 최적화를 위해 Vite와 같은 최신 번들러를 사용하고, `manualChunks`를 통해 벤더(Vendor) 라이브러리를 분리하거나 `React.lazy()`와 `Suspense`를 결합하여 라우트 및 컴포넌트 단위의 코드 스플리팅을 구현해야 합니다 [38-42].
+    *   대용량 리스트 렌더링 시에는 고유하고 안정적인 `key`를 사용하고, `react-window` 등을 활용한 가상화(Virtualization) 기술로 DOM 노드 수를 관리해야 합니다 [40, 43, 44].
+    *   2025년 이후 안정화된 **React Compiler**는 빌드 타임에 컴포넌트 트리를 분석하여 자동으로 세밀한 메모이제이션(JSX 요소 단위)을 수행함으로써, 수동으로 작성하던 `useMemo`, `useCallback`, `React.memo`의 유지보수 부담을 없애고 불필요한 리렌더링을 방지합니다 [39, 45, 46].
+*   **안정성 및 디버깅 (Resilience & Debugging)**
+    *   **Error Boundaries:** 하위 컴포넌트 트리의 렌더링 에러를 포착하고 Fallback UI를 띄워 전체 앱의 "백지화(White screen)"를 막는 역할을 합니다. 대시보드나 서드파티 위젯처럼 에러 발생률이 높은 섹션을 격리하는 데 유용합니다 [47-49].
+    *   Sentry, LogRocket, Datadog 같은 클라우드 로깅 툴을 활용하여 프로덕션 환경의 메모리 누수와 에러를 추적하고 모니터링해야 합니다 [50, 51].
+
+## ⚖️ Trade-offs & Caveats
+*   **Feature-Sliced Design (FSD)의 초기 오버헤드:** FSD는 결합도를 극적으로 낮추지만, 처음 도입 시 "이 기능은 Feature인가, Widget인가?"를 결정하는 의미론적 토론이 필요하며 초기 학습 곡선이 가파릅니다 [52, 53]. 소규모 프로젝트에서는 과도한 엔지니어링이 될 수 있습니다 [54].
+*   **Context API vs 외부 상태 관리 도구:** Context API는 서드파티 의존성 없이 쉽게 적용 가능하지만, 데이터의 일부만 변해도 구독하는 모든 컴포넌트가 강제 리렌더링되는 성능 결함(Re-render storm)을 가집니다 [28, 29]. 반대로 Zustand는 빠르고 보일러플레이트가 없지만 유연성이 너무 뛰어나 팀 규칙이 없으면 코드 파편화가 발생할 수 있으며 [55], Redux는 구조적 안정성이 높지만 초기 설정과 보일러플레이트 코드가 방대합니다 [34, 56].
+*   **메모이제이션(`React.memo`, `useMemo`)의 역효과:** 불필요한 렌더링을 막기 위해 모든 곳에 메모이제이션을 적용하는 것은 안티패턴입니다. React가 이전 Props와 현재 Props를 비교하는 데 드는 비용이 컴포넌트를 단순히 다시 렌더링하는 비용보다 클 수 있습니다 [57]. 렌더링이 가볍고 자주 변경되는 컴포넌트에는 오히려 성능 저하를 초래합니다 [58, 59].
+*   **React Compiler의 한계:** 자동으로 메모이제이션을 해주는 강력한 도구지만, 내부가 블랙박스로 작동하여 예상치 못한 리렌더링 발생 시 원인을 파악하기 어려워 디버깅이 복잡해질 수 있습니다 [60]. 또한 항상 불안정한 참조(새 객체)를 반환하는 서드파티 라이브러리와는 메모이제이션 체인이 깨지는 호환성 문제가 있습니다 [61].
+*   **과도한 추상화(DRY 원칙의 오용):** 중복을 피하기 위해(DRY) 코드를 무리하게 추상화하면 직관성을 중시하는 KISS(Keep It Simple, Stupid) 원칙에 위배됩니다. 재사용 가능한 추상화가 원래의 반복적인 코드보다 이해하기 복잡해진다면 구조적으로 실패한 것입니다 [62].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [관계 유형 A: 아키텍처 및 설계 방법론 (Architecture & Design)]
+- [[Feature-Sliced Design (FSD)]]
+  - 연결 이유: 확장 가능한 프론트엔드 시스템 구축을 위해 단순히 파일 유형별 분리가 아닌, 비즈니스 도메인 기반으로 계층(Layer)을 명확히 나누는 최신 아키텍처이기 때문입니다 [4, 63].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 모듈 간의 단방향 의존성 규칙, Public API 캡슐화, 그리고 대규모 협업 시 코드의 구조적 충돌을 막는 방법을 이해할 수 있습니다 [14-16].
+- [[SOLID Principles]]
+  - 연결 이유: 객체지향의 원칙들이지만, 이를 React 함수형 프로그래밍에 맞게 재해석하여 유지보수성을 크게 높이는 기준이 되기 때문입니다 [7, 64].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 거대한 컴포넌트를 단일 책임 원칙(SRP)에 따라 어떻게 커스텀 훅과 작은 컴포넌트로 분해하는지 학습할 수 있습니다 [18, 20].
+
+#### [관계 유형 B: 최적화 및 안정성 도구 (Optimization & Resilience Tools)]
+- [[React Compiler]]
+  - 연결 이유: 개발자가 수동으로 진행하던 `useMemo`, `useCallback` 기반의 최적화를 빌드 타임에 자동으로 처리해주는 혁신적인 도구이기 때문입니다 [45, 46].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: React 트리의 세밀한 렌더링 최적화 구조 및 서드파티 라이브러리가 렌더링 사이클에 미치는 영향을 파악할 수 있습니다 [46, 61].
+- [[State Management]]
+  - 연결 이유: 확장성을 확보하려면 로컬 상태, 글로벌 상태, 서버 상태의 성격에 맞춰 Zustand, Redux, TanStack Query 등을 분할 적용해야 하기 때문입니다 [8, 65].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: Context API의 렌더링 병목 현상 원리와 이를 해결하는 상태 선택자(Selector) 패턴을 깊게 파악할 수 있습니다 [29, 32].
+- [[Error Boundaries]]
+  - 연결 이유: 앱 규모가 클수록 개별 위젯이나 컴포넌트의 오류가 전체 앱을 마비시키는 것을 방지하기 위한 핵심적인 에러 핸들링 기법이기 때문입니다 [47, 48].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 런타임 에러의 격리 및 복원력 있는 UI 설계 방법과 모니터링 툴(Sentry 등)의 연동 방식을 이해할 수 있습니다 [49, 66].
+
+### Deeper Research Questions
+
+- Feature-Sliced Design(FSD)을 적용할 때 인증(Auth)과 같이 여러 도메인에 걸쳐 발생하는 공통 관심사(Cross-cutting concerns)를 레이어 내에서 어떻게 모듈화하고 관리해야 하는가?
+- 대규모 애플리케이션에서 Context API를 Zustand나 Redux로 마이그레이션할 때, 기능 개발을 멈추지 않고 점진적으로 리팩토링하는 전략은 무엇인가?
+- React Compiler 적용 후, 의도적으로 매 렌더링마다 새로운 참조(Unstable Reference)를 반환하는 서드파티 훅 라이브러리와의 충돌을 어떻게 식별하고 우회할 수 있는가?
+- Chrome DevTools의 Heap Snapshot 및 Allocation Timeline을 활용하여 컴포넌트 언마운트 이후에도 남아있는 Detached DOM Node에 의한 메모리 누수를 추적하는 정확한 방법은 무엇인가?
+- 대용량 데이터를 처리하는 과정에서 Virtualization(가상화) 기법을 사용할 때, 동적 높이를 가진 요소들이 스크롤 중 발생시키는 레이아웃 시프트(CLS)를 어떻게 최소화할 수 있는가?
+
+### Practical Application Contexts
+
+- **Implementation:** React 컴포넌트를 작성할 때 네이밍 컨벤션을 확립(컴포넌트는 `PascalCase`, 파일은 `kebab-case`)하고, 300줄 이상의 비대해진 컴포넌트는 단일 책임 원칙(SRP)에 따라 여러 기능별 훅과 순수 UI로 분할합니다 [18, 21, 24].
+- **System Design:** 초기 폴더 구조를 세팅할 때 단순히 components, hooks 묶음이 아니라, 인증, 대시보드 등의 비즈니스 도메인 단위로 기능을 격리(Feature-based)하고 단방향 의존성을 띄게 설계하여 향후 기능 추가 시 혼란을 방지합니다 [5, 13, 67].
+- **Operation / Maintenance:** 운영 중인 서비스가 예측 불가능한 렌더링 오류로 인해 "하얀 화면(White Screen of Death)"을 출력하는 것을 막기 위해 주요 위젯 단위마다 Error Boundary를 감싸 격리하고, 발견된 에러는 Sentry 등을 통해 스택 트레이스로 로깅합니다 [47-49].
+- **Learning Path:** 우선 React의 렌더링 메커니즘과 Hooks의 동작 원리를 명확히 이해한 후, Context API의 리렌더링 한계를 체감해 봅니다. 이후 Zustand나 TanStack Query 같은 특화된 상태 관리 라이브러리로 전환하는 과정을 거치며, 최종적으로 FSD 같은 아키텍처 패턴을 학습하는 순서가 권장됩니다 [68, 69].
+- **My Project Relevance:** 현재 진행 중이거나 앞으로 계획된 React 기반 프로덕트가 단순히 한두 페이지가 아니라 장기적인 확장을 목표로 한다면, 본 문서의 FSD 폴더 구조, 상태 관리 분할 전략, Vite 번들 분할(`manualChunks`) 지침을 바로 실무에 적용하여 부채(Technical Debt)를 조기에 차단할 수 있습니다 [70-72].
+
+### Adjacent Topics
+
+- [[Server Components (Next.js)]]
+  - 확장 방향: 클라이언트 사이드에서 처리해야 할 자바스크립트 번들의 크기를 근본적으로 줄이기 위해, 서버 측에서 데이터 페칭과 렌더링을 완전히 끝마친 뒤 결과물만 넘겨주는 최신 프레임워크 생태계로 지식을 확장할 수 있습니다 [73, 74].
+- [[Micro-Frontends]]
+  - 확장 방향: 단일 모놀리식 구조(SPA)조차 한계에 부딪힐 정도의 대형 엔터프라이즈 환경에서, 프론트엔드 자체를 여러 개의 독립적인 애플리케이션으로 분리하고 팀별 자율적 배포가 가능하게 만드는 아키텍처 수준의 연구로 확장할 수 있습니다 [4].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Sentry and LogRocket Integration.md b/00_Raw/Sentry and LogRocket Integration.md
new file mode 100644
index 00000000..eaa8644e
--- /dev/null
+++ b/00_Raw/Sentry and LogRocket Integration.md	
@@ -0,0 +1,53 @@
+# [[Sentry and LogRocket Integration]]
+
+## 📌 Brief Summary
+Sentry와 LogRocket은 현대 프론트엔드 애플리케이션의 프로덕션 환경에서 오류를 추적하고 사용자 경험(UX)을 모니터링하기 위해 활용되는 대표적인 클라우드 기반 로깅 도구입니다. Sentry는 지능적인 오류 그룹화와 이벤트 시퀀스 캡처에 특화되어 있으며, LogRocket은 전체 DOM과 상태 변경 사항을 비디오처럼 기록하는 고해상도 세션 리플레이에 중점을 둡니다. React 애플리케이션에서는 Error Boundary 패턴과 결합하여, 런타임 오류 시 크래시를 방지함과 동시에 상세한 디버깅 컨텍스트를 캡처하는 용도로 통합됩니다.
+
+## 📖 Core 단락 Content
+* **오류 추적 및 상태 기록 도구로서의 특징:** Sentry는 개발자 중심의 오류 추적(Error Tracker) 도구로, 오류 발생까지의 콘솔 로그, 네트워크 요청, 사용자 상호 작용 등의 정확한 시퀀스를 보여주는 브레드크럼(Breadcrumb) 트레일 기능을 제공하며 유사한 오류를 지능적으로 그룹화하여 노이즈를 줄여줍니다 [1-3]. 반면 LogRocket은 세션 리플레이의 개척자로서, 단순한 오류 로깅을 넘어 Redux나 Vuex의 상태 변경, 네트워크 요청 및 전체 DOM을 기록하여 복잡한 버그 디버깅에 필수적인 풍부한 컨텍스트를 제공합니다 [3-5].
+* **프로덕션 애플리케이션 내 통합:** 이러한 도구들은 React의 Error Boundary와 통합되어 주로 사용됩니다. 애플리케이션 코드의 특정 컴포넌트가 실패할 때 Error Boundary가 이를 잡아내어 대체 UI를 보여주고, 동시에 백그라운드에서 Sentry나 LogRocket과 같은 도구가 오류 세부 정보와 당시의 상황을 로깅하여 모니터링 도구로 전송하게 됩니다 [6].
+* **두 도구 간의 직접적 통합에 대한 한계:** 소스에 Sentry와 LogRocket 두 도구 자체를 상호 연결하는 직접적인 연동(Integration) 방법에 대한 구체적인 정보는 부족합니다. 대신, 이 두 도구는 프론트엔드 아키텍처에 모니터링 계층을 추가하기 위한 대안 혹은 보완적 도구 세트로 비교되며 평가됩니다 [1, 2, 4, 5, 7-10].
+
+## ⚖️ Trade-offs & Caveats
+* **Sentry 도입의 트레이드오프:** Sentry는 설치와 통합이 매우 빠르고 사용하기 쉽다는 장점이 있으나, 규모가 커질 경우(에러 볼륨, 리플레이, 성능 모니터링 등 다중 지표 사용 시) 가격 구조가 복잡하고 비싸질 수 있습니다 [2, 9]. 또한, 성능 모니터링 기능(Web Vitals 등)을 추가할 경우 번들 크기에 상당한 부담을 줄 수 있으며, 전문적인 세션 리플레이 기능은 아직 다른 특화 도구에 비해 성숙도가 낮을 수 있습니다 [9].
+* **LogRocket 도입의 트레이드오프:** LogRocket은 압도적인 디버깅 컨텍스트를 제공하지만, 기본적으로 '모든 것을 캡처'하는 방식을 취하므로 프라이버시 이슈에 민감합니다. 민감한 데이터가 노출되지 않도록 설정하는 데 상당한 시간이 필요합니다 [5, 10]. 또한, 유료 플랜의 규모가 커질 때 유지 비용이 매우 비싸며 번들 크기와 성능 측면에서도 애플리케이션에 미치는 영향이 큰 편입니다 [10].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [프론트엔드 모니터링 및 옵저버빌리티 도구]
+- [[Session Replay]]
+  - 연결 이유: LogRocket의 핵심 기능이자 Sentry의 기능 중 하나로, 사용자의 웹 상호 작용을 화면 녹화처럼 재현하는 기술입니다 [2, 4].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 단순히 에러 스택을 보는 것을 넘어 사용자 화면에서 어떤 동작 시퀀스가 에러를 유발했는지 추적하는 맥락 기반 디버깅 프로세스를 이해할 수 있습니다.
+- [[Error Grouping]]
+  - 연결 이유: Sentry가 제공하는 핵심 킬러 기능으로, 수많은 에러 로그 속에서 유사한 문제들을 자동으로 묶어줍니다 [1, 3].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 대규모 트래픽을 처리하는 애플리케이션에서 동일한 버그로 인한 로그 노이즈를 어떻게 감소시키고 관리 효율성을 높이는지 파악할 수 있습니다.
+
+#### [React 아키텍처 및 오류 관리]
+- [[React Error Boundaries]]
+  - 연결 이유: React 앱에서 모니터링 도구(Sentry, LogRocket 등)와 결합하여, 런타임 오류를 캐치하고 사용자에게 Fallback UI를 띄워주는 동시에 오류 정보를 원격 로깅하는 데 사용됩니다 [6, 11].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 코드베이스 내에서 모니터링 도구들이 실제 어떻게 안전하게 통합되고 호출되는지의 아키텍처적 위치를 이해할 수 있습니다.
+
+### Deeper Research Questions
+- Sentry의 지능형 오류 그룹화 기술은 구체적으로 어떤 기준과 알고리즘을 통해 수많은 에러 로그의 중복을 판별하는가?
+- LogRocket의 DOM 및 상태 변경 '전체 캡처' 방식에서, 비밀번호 및 PII(개인식별정보)와 같은 민감 데이터를 자동으로 마스킹하는 구체적인 프라이버시 제어 매커니즘은 어떻게 동작하는가?
+- Sentry의 성능 모니터링 기능과 LogRocket 라이브러리를 React 애플리케이션에 통합했을 때, 초기 로드 시간과 번들 크기에 미치는 성능 페널티를 정량적으로 최소화할 수 있는 최적화 방법은 무엇인가?
+- Datadog RUM과 같은 Full-Stack 옵저버빌리티 도구와 비교할 때, 프론트엔드에 특화된 Sentry와 LogRocket이 제공하는 기술적, 경제적 한계는 무엇인가?
+- React Error Boundary 내부에서 외부 모니터링 서비스로 에러를 전송할 때 발생하는 비동기 네트워크 비용과 장애를 안전하게 격리하는 방법은 무엇인가?
+
+### Practical Application Contexts
+- **Implementation:** React 컴포넌트 트리의 핵심 경계(예: 대시보드, 서드파티 위젯 영역)에 Error Boundary 컴포넌트를 배치하고, `componentDidCatch` 등의 생명주기 내에 Sentry나 LogRocket 로깅 API를 호출하여 구현합니다 [6, 12, 13].
+- **System Design:** 초기 스타트업 단계에서는 넉넉한 무료 티어를 제공하는 Sentry로 시작하여 인프라 비용을 줄이고, 서비스가 고도화되고 복잡한 상태 디버깅이 필요해지면 고해상도 세션 리플레이를 지원하는 LogRocket의 도입을 검토하는 방향으로 시스템을 설계합니다 [9, 10, 14].
+- **Operation / Maintenance:** 프로덕션 환경에서 원인을 알 수 없는 1%의 특수 브라우저/기기 버그가 발생했을 때, Sentry로 에러를 알림 받고 LogRocket의 Redux 상태 추적 및 리플레이를 통해 사용자 환경을 그대로 재현하며 운영상의 장애를 해결합니다 [1, 5, 15].
+- **Learning Path:** 단순한 `console.log` 디버깅 방식을 넘어, 클라우드 기반 프론트엔드 에러 트래커(Sentry) 통합 방법을 배우고, 이후 세션 리플레이(LogRocket) 도구를 도입하면서 프라이버시 데이터 마스킹과 번들 사이즈 최적화의 중요성을 깨닫게 됩니다 [7, 16, 17].
+- **My Project Relevance:** 프론트엔드 코드베이스가 점점 방대해짐에 따라 버그 추적이 어려워지는 프로젝트 환경에서, Sentry나 LogRocket 중 팀의 예산과 요구사항에 맞는 로깅 도구를 선택 및 통합하여 안정성과 유지 보수성을 대폭 향상시킬 수 있습니다 [7, 14].
+
+### Adjacent Topics
+- [[Datadog RUM (Real User Monitoring)]]
+  - 확장 방향: 프론트엔드 로그만 수집하는 것을 넘어, 발생한 오류를 백엔드 서비스 트레이스, 데이터베이스 쿼리까지 이어지게 하는 엔드투엔드 분산 트레이싱 기술로의 확장 [18, 19].
+- [[SigNoz & OpenTelemetry]]
+  - 확장 방향: Sentry나 LogRocket과 같은 상용 SaaS 툴의 한계(비용 및 벤더 종속성)를 극복하기 위해, 오픈소스 표준인 OpenTelemetry를 기반으로 직접 호스팅하는 옵저버빌리티 대안 솔루션을 탐색하는 방향 [16, 20, 21].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Single Page Applications (SPAs).md b/00_Raw/Single Page Applications (SPAs).md
new file mode 100644
index 00000000..ed290af1
--- /dev/null
+++ b/00_Raw/Single Page Applications (SPAs).md	
@@ -0,0 +1,49 @@
+# [[Single Page Applications (SPAs)]]
+
+## 📌 Brief Summary
+소스에 관련 정보가 부족합니다. (제공된 소스에서는 SPA의 개념을 직접적으로 정의하거나 설명하지 않으며, 특정 컴포넌트 수명 주기에서의 메모리 누수 문제 [1]나 React 앱 구조에 관한 참조 문서 제목 [2]으로만 간략히 언급되어 있습니다.)
+
+## 📖 Core Content
+소스에 관련 정보가 부족합니다. 
+
+## ⚖️ Trade-offs & Caveats
+소스에 관련 정보가 부족합니다.
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [관계 유형 A (성능 및 디버깅)]
+- [[Memory Leaks]]
+  - 연결 이유: 소스에서 SPA 환경의 특정 사용자 상호작용 및 컴포넌트 수명 주기 동안 발생하는 메모리 누수를 식별하는 방법을 핵심적인 성능 문제로 다루고 있기 때문입니다 [1].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: SPA 내부에서 DOM 노드가 문서에서 제거되었음에도 JavaScript에서 참조되어 남아있는 현상(Detached DOM Nodes), 이벤트 리스너 누적, 클로저 참조 등 SPA가 장시간 실행될 때 애플리케이션의 속도를 늦추고 충돌을 일으키는 원리를 이해할 수 있습니다 [1, 3].
+
+#### [관계 유형 B (아키텍처 및 기반 기술)]
+- [[React Architecture]]
+  - 연결 이유: 대규모 SPA 구축에 주로 사용되는 React 애플리케이션의 구조적 한계를 극복하고 확장성을 확보하기 위한 설계 방법론이 소스의 주요 내용이기 때문입니다 [4-6].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: SPA 시스템을 단순히 기술적 파일 타입(components, hooks 등)으로 분리하는 것을 넘어, 비즈니스 기능(Features)과 도메인 스코프를 중심으로 분리하는 Feature-Sliced Design(FSD)과 같은 프론트엔드 설계 원칙을 이해할 수 있습니다 [5, 7, 8].
+
+### Deeper Research Questions
+- SPA 컴포넌트의 수명 주기(lifecycle) 동안 발생하는 메모리 누수의 구체적인 패턴(예: 이벤트 리스너 누적, 클로저 참조 등)을 어떻게 효과적으로 추적하고 프레임워크별(React, Vue 등)로 어떻게 예방할 수 있는가? [1, 9]
+- 확장 가능한 대규모 SPA를 구축할 때, 기술적 역할 기반의 분리(MVC)가 아닌 기능(Feature) 기반의 계층형 디렉토리 구조(FSD)를 채택함으로써 얻는 유지보수성과 의존성 관리의 이점은 무엇인가? [5, 8, 10, 11]
+- SPA에서 전역 상태 관리를 위해 기본 Context API를 사용할 때 발생하는 불필요한 리렌더링 문제를 Zustand나 Redux 같은 상태 관리 도구가 내부적으로 어떻게 해결하는가? [12, 13]
+- SPA의 번들 크기를 줄이고 초기 로딩 성능(LCP, FCP 등)을 개선하기 위한 경로 기반의 코드 스플리팅(Code Splitting)과 지연 로딩(Lazy Loading) 전략은 실제 빌드 도구(Vite 등) 환경에서 어떻게 구현되는가? [14-16]
+- SPA와 대비되는 SSR(Server Side Rendering) 또는 Native 모바일 앱 구조는 어떠한 프로젝트 요구사항에 따라 선택되어야 하는가? [2]
+
+### Practical Application Contexts
+- **Implementation:** SPA 컴포넌트가 언마운트(unmount)될 때 이벤트 리스너나 구독(subscription)이 제대로 제거되지 않으면 메모리 누수가 지속적으로 누적되므로, React의 경우 `useEffect`의 반환(cleanup) 함수에서 적절한 정리 작업을 구현해야 합니다 [1, 9, 17].
+- **System Design:** 대규모 SPA 시스템 설계 시 Feature-Sliced Design(FSD) 원칙을 도입하여, 각 기능(Feature)이 명확한 퍼블릭 API(`index.ts`)를 통해서만 외부 모듈과 통신하도록 캡슐화함으로써 모듈 간 결합도(Coupling)를 낮추고 예측 가능한 시스템을 설계해야 합니다 [18-20].
+- **Operation / Maintenance:** 운영 중인 SPA에서 사용 시간이 길어짐에 따라 성능이 지속적으로 저하되거나 브라우저 탭이 멈추는 현상이 보고될 경우, Chrome DevTools의 Heap Snapshot이나 Allocation Timeline을 활용해 점진적으로 증가하는 메모리 누수를 찾아 디버깅해야 합니다 [21-23].
+- **Learning Path:** 소스에 관련 정보가 부족합니다.
+- **My Project Relevance:** 소스에 관련 정보가 부족합니다.
+
+### Adjacent Topics
+- [[Feature-Sliced Design (FSD)]]
+  - 확장 방향: SPA가 비대해질 때 발생하는 구조적 복잡성을 해결하기 위해, 계층(Layer), 슬라이스(Slice), 세그먼트(Segment)로 코드를 나누고 단방향 의존성을 강제하는 방법론 탐구 [5, 7].
+- [[React Performance Optimization]]
+  - 확장 방향: 대규모 SPA에서 빈번하게 일어나는 렌더링 병목 현상을 제어하기 위한 `React.memo`, `useCallback`, 가상화(Virtualization), 그리고 React Compiler를 활용한 빌드 타임 메모이제이션 기법 학습 [24-26].
+- [[State Management Libraries]]
+  - 확장 방향: SPA 내에서 데이터 흐름을 효율적으로 관리하기 위해 Context API, Zustand, Redux의 아키텍처적 차이와 프로젝트 규모에 따른 올바른 도구 채택 기준 비교 [27-29].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Single Responsibility Principle.md b/00_Raw/Single Responsibility Principle.md
new file mode 100644
index 00000000..84df9046
--- /dev/null
+++ b/00_Raw/Single Responsibility Principle.md	
@@ -0,0 +1,62 @@
+# [[Single Responsibility Principle]]
+
+## 📌 Brief Summary
+SRP(단일 책임 원칙)는 컴포넌트, 함수 또는 모듈이 단 하나의 책임이나 목적만을 가져야 한다는 소프트웨어 설계 원칙입니다 [1-3]. 본래 객체 지향 프로그래밍의 클래스 설계를 위한 원칙이지만, React와 같은 함수형 코드에서도 '하나의 코드는 오직 하나의 작업만 수행해야 한다'는 개념으로 번역되어 널리 적용됩니다 [3]. 코드가 변경되어야 하는 이유는 단 하나뿐이어야 하며, 이를 통해 코드의 품질을 향상시키고 애플리케이션의 유지보수성을 크게 높일 수 있습니다 [3, 4].
+
+## 📖 Core Content
+*   **개념과 적용의 핵심:** SRP는 장난감 상자에서 각 장난감이 자신만의 특별한 위치를 가지듯, 코드의 각 부분이 오직 한 가지의 특정한 일만 수행하도록 제한하는 원칙입니다 [1]. React 개발 환경에서는 컴포넌트나 훅(hook)이 변경되어야 할 이유가 명확히 하나만 존재하도록 설계해야 함을 의미합니다 [2, 4].
+*   **식별 방법 (코드 스멜):** 컴포넌트가 300줄을 넘어가는 등 과도하게 커진다면, 이는 상태 관리(managing state), 데이터 페칭(fetching data), 복잡한 JSX 렌더링 등 너무 많은 작업을 동시에 수행하고 있다는 신호일 수 있습니다 [4]. 모든 것을 한 곳에서 처리하려는 거대한 컴포넌트를 만드는 것은 흔한 설계 함정입니다 [5].
+*   **React에서의 구현 방법:**
+    *   **컴포넌트 분할:** 거대한 로직을 가진 큰 컴포넌트를 더 작고 명확한 목적을 가진 컴포넌트로 분리합니다. 예를 들어, `UserDashboard` 컴포넌트를 `UserProfile`, `UserPosts`, `UserNotifications`로 나누는 방식입니다 [3, 4].
+    *   **함수 추출:** 특정 작업을 별도의 범용 함수(general-purpose functions)로 분리합니다 [3].
+    *   **Custom Hook 활용:** 컴포넌트 내에 혼재된 비즈니스 로직이나 상태 관리 로직을 사용자 정의 훅(custom hooks)으로 이동시킵니다 [3]. 범용적이고 재사용 가능한 컴포넌트는 공유 폴더에, 기능별 컴포넌트는 해당 기능 디렉토리에 유지합니다 [5].
+*   **기대 효과:** 코드를 작고 집중된 형태의 컴포넌트로 리팩토링하면 테스트 가능성(testability)과 코드의 명확성이 크게 향상됩니다 [4]. 또한, 단일 목적을 가진 작은 컴포넌트들은 프로그램의 여러 영역에서 재사용하고 유지보수하기가 훨씬 쉽습니다 [5].
+
+## ⚖️ Trade-offs & Caveats
+소스에 단일 책임 원칙(SRP) 자체에 대한 구체적인 부작용이나 제약 사항(Trade-offs)에 대한 관련 정보가 부족합니다. 다만 SRP가 포함된 전체 SOLID 원칙에 대해서는, 코드를 고도로 유지보수하기 쉽고 조직적으로 만들어주지만 초기에는 적용하기 복잡하게 느껴질 수 있다(May initially feel complex)는 점이 제약 사항으로 언급되어 있습니다 [6]. 
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [소프트웨어 설계 및 기반 원칙]
+- [[SOLID Principles]]
+  - 연결 이유: SRP는 SOLID를 구성하는 5가지 설계 원칙 중 첫 번째 핵심 요소입니다 [7].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 객체 지향 프로그래밍에서 시작된 이 원칙들이 대규모 애플리케이션의 구조화와 확장성에 어떻게 종합적으로 기여하는지 이해할 수 있습니다 [8].
+- [[Clean Code]]
+  - 연결 이유: 읽기 쉽고 유지보수하기 쉬운 코드를 작성하기 위한 원칙으로, 코드를 명확하고 단순하게 작성할 것을 강조하는 SRP와 긴밀하게 연관됩니다 [2, 9].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 단일 책임을 지키면서도 어떻게 변수명, 컴포넌트 구조 등을 읽기 쉽게 다듬을 수 있는지 실천적 방법을 이해할 수 있습니다 [9].
+
+#### [React 패턴 및 활용 도구]
+- [[Custom Hooks]]
+  - 연결 이유: React에서 컴포넌트가 너무 많은 책임을 가질 때 데이터 페칭이나 상태 관리 로직을 UI로부터 분리해내는 핵심 수단입니다 [3].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: SRP를 실제 React 환경에서 적용하여 UI 렌더링 로직과 비즈니스 로직을 분리하는 구현 패턴을 깊게 파악할 수 있습니다 [3].
+- [[Component Composition]]
+  - 연결 이유: 하나의 큰 역할을 하는 컴포넌트를 여러 개의 독립된 책임을 가진 서브 컴포넌트로 분할하고 조합하는 방식입니다 [4, 5].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: OCP(개방-폐쇄 원칙)와 SRP를 동시에 만족시키며, 레고 블록처럼 유연하게 UI를 조립하고 재사용성을 높이는 방법을 이해할 수 있습니다 [2, 4].
+
+### Deeper Research Questions
+
+- 컴포넌트가 여러 책임을 수행하는지(예: 300줄 초과) 판단할 때, '단일 책임'의 경계(Boundary)를 어떻게 정의하고 평가해야 하는가?
+- React 컴포넌트에서 상태 관리 책임을 분리하기 위해 Custom Hook을 사용하는 것 외에, 전역 상태 관리 라이브러리(Zustand, Context API 등)를 도입하는 것이 SRP 관점에서 어떤 영향을 미치는가?
+- Feature-Sliced Design (FSD)와 같은 모듈형 아키텍처에서 SRP는 각 Layer(공유, 엔티티, 기능 등)에 어떻게 적용되며, 모듈 간 결합도를 낮추는 데 어떤 역할을 하는가?
+- 비즈니스 로직이 강하게 결합된 거대한 레거시 React 컴포넌트를 SRP 원칙에 따라 분리할 때, 회귀(Regression)를 방지하기 위한 가장 안전한 리팩토링 및 테스트 전략은 무엇인가?
+- SRP를 극단적으로 적용하여 컴포넌트와 훅을 너무 잘게 분해했을 때 발생할 수 있는 파일 구조 및 Props 전달의 복잡성은 어떻게 해결할 수 있는가?
+
+### Practical Application Contexts
+
+- **Implementation:** React 컴포넌트를 작성할 때 코드 라인 수가 지나치게 길어지거나(예: 300줄 초과) 로직이 복잡해지면, 데이터 페칭, 상태 관리 로직을 Custom Hooks로 추출하고 UI 렌더링을 쪼개어 단일 책임만 갖도록 구현합니다 [3, 4].
+- **System Design:** 폴더 구조를 설계할 때 컴포넌트가 모든 것을 처리하도록 두지 않고, 재사용 가능한 공통 컴포넌트는 공유(Shared) 폴더에, 특정 기능에 종속된 컴포넌트는 Feature 디렉토리에 명확히 격리하여 배치합니다 [5].
+- **Operation / Maintenance:** 버그가 발생했을 때 코드가 단일 책임 원칙에 따라 분리되어 있다면, 문제가 UI 렌더링에 있는지 상태 관리에 있는지 추적하기 쉬워져 유지보수 속도와 정확성을 크게 높입니다 [4-6].
+- **Learning Path:** React의 기본 개념(State, Props, JSX)을 익힌 후, 애플리케이션 규모가 커짐에 따라 발생하는 스파게티 코드를 해결하기 위해 Clean Code와 SOLID 원칙(특히 SRP)을 학습하고 이를 코드 리팩토링에 적용해 보는 방식으로 나아갑니다 [7-9].
+- **My Project Relevance:** 거대한 대시보드 애플리케이션 등을 구축할 때, 전체를 하나의 페이지나 컴포넌트로 짜지 않고 `UserProfile`, `UserPosts`, `UserNotifications` 등 독립적인 목적을 가진 컴포넌트들로 세분화하여 테스트와 유지보수를 용이하게 만듭니다 [4].
+
+### Adjacent Topics
+
+- [[DRY (Don't Repeat Yourself)]]
+  - 확장 방향: 코드를 단일 책임으로 쪼갠 후, 중복되는 로직(예: 동일한 데이터 페칭 방식 등)을 식별하고 이를 재사용 가능한 함수나 훅으로 통합하는 최적화 방향으로 이해를 확장할 수 있습니다 [9, 10].
+- [[KISS (Keep It Simple, Stupid)]]
+  - 확장 방향: 단일 책임 원칙을 지키기 위해 코드를 분리하는 과정에서, 지나친 추상화로 인해 구조가 불필요하게 복잡해지지 않도록(단순함을 유지하도록) 돕는 보완적인 설계 원칙으로 학습을 확장할 수 있습니다 [9, 10].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Small vs Large Frontend Teams.md b/00_Raw/Small vs Large Frontend Teams.md
new file mode 100644
index 00000000..f9d83ea7
--- /dev/null
+++ b/00_Raw/Small vs Large Frontend Teams.md	
@@ -0,0 +1,68 @@
+# [[Small vs Large Frontend Teams]]
+
+## 📌 Brief Summary
+프론트엔드 개발에서 팀의 규모(Small vs Large)는 아키텍처, 워크플로우, 상태 관리 도구, 그리고 거버넌스의 선택을 좌우하는 핵심 기준입니다. 소규모 팀은 빠른 개발 속도와 유연성을 위해 오버헤드가 적은 도구와 단순한 구조를 선호하는 반면, 대규모 팀은 복잡성을 제어하고 일관성을 유지하기 위해 엄격한 패턴, 확장 가능한 아키텍처, 그리고 자동화된 규칙 강제를 필요로 합니다 [1-4].
+
+## 📖 Core 소 Content
+* **브랜칭 전략 및 워크플로우 (Branching & Workflow):**
+  * **소규모 팀 (2~5명):** 무거운 Git-Flow 대신 가벼운 기능 브랜치(Feature-branch) 워크플로우나 짧은 수명의 트렁크 기반 개발(Trunk-based workflow)이 가장 적합합니다 [5-7]. 이는 프로세스 오버헤드를 최소화하고 충돌을 방지하며 코드의 안정성을 유지하는 데 유리합니다 [1, 8, 9].
+  * **대규모 팀:** 소규모 팀에게는 무겁게 느껴지는 Git-Flow 같은 전략이, 정해진 릴리스 일정을 가진 대규모 프로젝트나 대규모 팀에서는 유용한 구조를 제공합니다 [1].
+
+* **상태 관리 도구의 선택 (State Management):**
+  * **소규모 및 중규모 팀 (5~15명):** Zustand와 같이 보일러플레이트가 적고 유연하며 가벼운 도구가 "골디락스(Goldilocks)" 솔루션으로 작용하여 빠른 제품 출시(MVP)를 돕습니다 [10, 11].
+  * **대규모 팀 (10명 이상):** 팀이 커지면 Zustand의 높은 유연성은 개발자마다 비동기 처리나 상태 관리 방식을 다르게 구현하게 만들어 '통합의 혼란(integration chaos)'을 초래할 수 있습니다 [3, 12]. 대규모 팀에서는 강력한 패턴을 강제하는 Redux가 산업 표준이며, 초기 보일러플레이트가 오히려 버그를 잡고 일관성을 유지하는 '구조적 역할'을 합니다 [13-15].
+
+* **아키텍처 확장성 (Architecture Scalability):**
+  * **소규모 애플리케이션:** 파일 타입 기반(예: components, hooks 등)의 단순한 계층형 구조나 평면적(Flat) 구조로 시작할 수 있습니다 [16, 17]. 
+  * **대규모 팀 및 애플리케이션:** 코드가 커지면 기존 구조는 스파게티 코드를 유발합니다 [18]. 대규모 팀은 기능 분할 설계(Feature-Sliced Design, FSD)를 통해 팀원들이 서로 간섭하지 않고 독립적인 슬라이스(Slice) 단위로 병렬 작업을 수행할 수 있도록 해야 합니다 [19, 20]. 더 거대한 엔터프라이즈 시스템에서는 팀의 자율성을 위해 마이크로 프론트엔드(Micro-Frontends)를 채택하기도 합니다 [21, 22].
+
+* **거버넌스와 협업 규칙 (Governance & Standards):**
+  * 대규모 팀은 협업 시 파일 탐색의 혼란을 막기 위해 파일/폴더 네이밍 컨벤션(예: 컴포넌트는 PascalCase, 파일은 kebab-case)을 엄격히 준수해야 합니다 [23, 24]. 또한, 아키텍처 경계를 침범하지 않도록 ESLint와 Prettier, Husky(Git hooks)를 활용해 규칙을 자동화하고 강제하는 것이 필수적입니다 [24].
+
+## ⚖️ Trade-offs & Caveats
+* **유연성 vs 일관성 (Flexibility vs. Consistency):** Zustand와 같은 가벼운 상태 관리나 느슨한 폴더 구조는 소규모 팀에게 개발 속도를 제공하지만(장점), 대규모 팀에서는 각기 다른 구현 방식으로 인해 유지보수 악몽을 초래합니다(단점/부작용) [3, 25]. 반대로 Redux나 FSD는 대규모 팀의 디버깅 시간과 충돌을 줄여주지만, 소규모 팀에게는 과도한 학습 곡선과 보일러플레이트(오버헤드)로 작용합니다 [26-29].
+* **프로세스 오버헤드 vs 안정성 (Process Overhead vs. Stability):** 소규모 팀은 1명의 리뷰어와 스쿼시 머지(Squash Merge)를 활용하는 단순한 Pull Request 규칙만으로도 충분히 안정성을 확보할 수 있습니다 [30, 31]. 하지만 조직이 커지면 이러한 단순한 규칙만으로는 복잡한 릴리스 관리가 어려워져 무거운 Git-Flow나 엄격한 CI/CD 제약이 필요해집니다 [1].
+* **아키텍처의 과도한 설계 (Over-engineering):** 아주 작은 프로젝트에 FSD나 마이크로 프론트엔드를 도입하는 것은 과도한 복잡성(런타임 오버헤드, 폴더 구조의 중복 등)을 유발하는 반면, 성장이 예상되는 앱에서 초기 설계를 간과하면 나중에 리팩토링이라는 큰 기술 부채를 떠안게 됩니다 [21, 29].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [아키텍처/기반 기술]
+- [[Feature-Sliced Design]]
+  - 연결 이유: 대규모 랙트(React) 애플리케이션에서 비즈니스 도메인과 기능 단위로 프로젝트를 분할하는 아키텍처 방법론이기 때문입니다 [32, 33].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 대규모 팀이 어떻게 서로 코드 충돌 없이 독립적인 기능(Slice)을 병렬로 개발하고 유지보수할 수 있는지 이해할 수 있습니다 [20].
+- [[Micro-Frontends]]
+  - 연결 이유: 대규모 엔터프라이즈 시스템에서 팀 단위의 완전한 자율성과 독립적 배포를 보장하기 위해 사용되는 아키텍처이기 때문입니다 [21, 22].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 대규모 조직 확장에 따른 아키텍처 선택의 한계와, 그로 인해 발생하는 런타임 통합 및 성능 오버헤드의 Trade-off를 배울 수 있습니다 [21].
+
+#### [구현/활용 도구]
+- [[Redux]] vs [[Zustand]]
+  - 연결 이유: 팀의 규모(5~15명 vs 10명 이상)에 따라 가장 극명하게 선택이 갈리는 상태 관리 패러다임이기 때문입니다 [10, 14].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 보일러플레이트 코드가 소규모 팀에게는 짐이 되지만, 대규모 팀에서는 어떻게 버그를 예방하고 일관성을 유지하는 '구조적 안전망'이 되는지 파악할 수 있습니다 [14, 15].
+- [[Feature Branch Workflow]]
+  - 연결 이유: 2~5인 규모의 소규모 팀에게 가장 권장되며, 복잡한 Git-Flow를 피하면서도 코드를 안정적으로 유지할 수 있는 브랜칭 전략이기 때문입니다 [1, 7, 34].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 팀이 작을 때 필수적인 최소한의 코드 리뷰, 브랜치 생명 주기 관리, 그리고 머지 전략(Squash Merge)을 학습할 수 있습니다 [30].
+
+### Deeper Research Questions
+- 소규모 팀에서 Zustand를 사용하다가 애플리케이션과 팀 규모가 커질 때(Scaleup), Redux로 마이그레이션해야 하는 기술적 임계점(Technical Wall)을 어떻게 식별할 수 있는가?
+- 대규모 팀 환경에서 Feature-Sliced Design(FSD)의 계층(Layer) 간 단방향 의존성 규칙을 위반하지 않도록, ESLint 등 자동화 도구를 어떻게 구체적으로 구성할 수 있는가?
+- Git-Flow가 대규모 팀에 적합하다고 알려져 있으나, 트렁크 기반 개발(Trunk-Based Development)을 대규모 팀에 안전하게 적용하여 통합 속도를 높이기 위한 CI/CD 파이프라인의 필수 요건은 무엇인가?
+- 마이크로 프론트엔드(Micro-Frontends) 구조가 제공하는 팀 자율성의 이점 대비, 런타임 성능 저하와 파편화를 방지하기 위해 대규모 팀이 갖춰야 할 중앙 거버넌스(Governance) 전략은 무엇인가?
+- 상태 관리 로직(State)과 UI 컴포넌트의 결합도가 높은 기존 레거시 코드를, 대규모 팀의 협업에 적합한 구조(단일 책임 원칙 준수)로 리팩토링하기 위한 점진적 마이그레이션 패턴은 무엇인가?
+
+### Practical Application Contexts
+- **Implementation:** 팀의 인원수에 따라 워크플로우와 도구를 다르게 도입합니다. 3인 팀이라면 Feature Branch 워크플로우와 Zustand를 사용하고, 10인 이상의 복잡한 프로젝트라면 엄격한 네이밍 컨벤션과 Redux를 도입합니다.
+- **System Design:** 초기 단계의 프로젝트라도 향후 팀이 확장될 것을 고려하여, 단순한 파일 유형 기반 폴더 구조보다는 기능 기반(Feature-based) 조직 구성을 염두에 두고 시스템 디렉토리를 설계해야 기술 부채를 줄일 수 있습니다.
+- **Operation / Maintenance:** 대규모 팀에서는 개발자 간 코드 스타일 충돌과 아키텍처 훼손을 막기 위해 ESLint, Prettier, Husky를 설정하여 커밋 및 PR 단계에서 코드 품질 검증을 자동화(Operation)해야 합니다.
+- **Learning Path:** 프론트엔드 학습자는 먼저 Context API와 단순한 파일 구조로 소규모 프로젝트의 흐름을 익힌 뒤, 협업 시 발생하는 문제를 체감하며 Redux, FSD, CI/CD 자동화 같은 대규모/엔터프라이즈 패턴으로 학습을 확장하는 것이 좋습니다.
+- **My Project Relevance:** 현재 진행 중인, 혹은 기획 중인 프로젝트의 참여 인원과 향후 유지보수 기간을 평가하여 초기부터 도입해야 할 툴(예: 과도한 구조화 방지 vs 엄격한 규칙 선적용)을 결정하는 지표로 활용할 수 있습니다.
+
+### Adjacent Topics
+- [[Code Governance and Linting]]
+  - 확장 방향: 대규모 팀 환경에서 사람이 일일이 리뷰하기 힘든 아키텍처 규칙과 네이밍 컨벤션을 자동화된 도구(ESLint, Git Hooks 등)로 어떻게 통제하고 관리하는지 탐구합니다.
+- [[Technical Debt Management]]
+  - 확장 방향: 소규모 팀 시절에 속도를 위해 타협했던 코드(예: 전역 상태의 남용, 거대한 컴포넌트)를 대규모 팀 구조에 맞게 점진적으로 리팩토링하고 분리하는 실무적 접근법을 연구합니다.
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/State Management Libraries.md b/00_Raw/State Management Libraries.md
new file mode 100644
index 00000000..15cb2aed
--- /dev/null
+++ b/00_Raw/State Management Libraries.md	
@@ -0,0 +1,78 @@
+# [[State Management Libraries]]
+
+## 📌 Brief Summary
+상태 관리 라이브러리는 프론트엔드 애플리케이션에서 컴포넌트 간 데이터를 공유하고 로컬 UI, 기능(Feature), 엔티티 상태 등 다양한 형태의 애플리케이션 상태를 효율적으로 관리하기 위한 도구이다 [1, 2]. 과거의 단일 Redux 스토어 방식에서 벗어나, 현재는 목적과 데이터 유형에 따라 Zustand, Jotai, TanStack Query와 같이 특화된 라이브러리들을 조합하여 사용하는 파편화된 접근법이 표준으로 자리 잡고 있다 [2-4]. 각 라이브러리는 팀의 크기, 애플리케이션의 복잡도, 렌더링 성능 요구사항에 따라 명확한 트레이드오프를 가진다 [5, 6].
+
+## 📖 Core Content
+
+*   **Context API (내장 상태 공유)**
+    *   React의 내장 솔루션으로 종속성이 없는 것이 특징이며, 'Prop Drilling' 문제를 해결하기 위해 도입되었다 [7, 8].
+    *   주로 테마(라이트/다크 모드), 로케일, 기능 플래그 등 업데이트 빈도가 낮고 정적인 전역 상태를 공유하는 데 적합하다 [9, 10].
+    *   '브로드캐스트 시스템'처럼 작동하여 값이 변경될 때마다 해당 컨텍스트를 구독하는 모든 컴포넌트가 다시 렌더링되므로, 빈번하게 변경되는 상태 관리에는 부적합하다 [3, 7, 11].
+*   **Zustand (경량 스토어 라이브러리)**
+    *   Redux의 장점을 가져오면서도 보일러플레이트를 줄인 경량화된 스토어 라이브러리이다 [12, 13].
+    *   스토어가 React 컴포넌트 트리 외부에 독립된 모듈로 존재하며, '선택자(Selector) 패턴'을 사용해 컴포넌트가 관심 있는 특정 상태 조각이 변경될 때만 리렌더링되도록 보장한다 [3, 14, 15].
+    *   컴포넌트 50~500개, 개발자 5~15명 규모의 중간 크기 프로젝트에 가장 적합한 도구로 평가받는다 [16].
+*   **Redux (엔터프라이즈급 상태 컨테이너)**
+    *   불변성 업데이트, 액션 디스패치, 리듀서를 갖춘 예측 가능한 상태 컨테이너로, 500개 이상의 컴포넌트나 10명 이상의 팀이 작업하는 대규모 애플리케이션에 필수적이다 [17, 18].
+    *   과거에는 막대한 보일러플레이트가 단점이었으나, RTK Query를 통한 강력한 비동기 처리 도입과 함께 일관된 아키텍처 패턴을 강제함으로써 팀 내 혼란을 방지한다 [19, 20].
+    *   상태 이력을 추적하고 재생할 수 있는 시간 여행 디버깅(Time-travel debugging)을 지원하는 등 DevTools 생태계가 매우 강력하다 [19, 21].
+*   **서버 상태 관리 (TanStack Query)**
+    *   최신 상태 관리 아키텍처에서는 클라이언트 상태와 API에서 가져오는 '서버 상태'를 완전히 분리한다 [3].
+    *   TanStack Query(React Query)는 네트워크 요청의 캐싱, 동기화, 무한 스크롤, 낙관적 업데이트(Optimistic updates) 및 로딩/에러 사이클 처리를 담당하여 서버 상태 관리의 사실상 표준으로 사용된다 [3, 4, 22].
+
+## ⚖️ Trade-offs & Caveats
+*   **Context API의 한계와 리렌더링 폭풍 (Re-render Storm)**
+    *   초기 설정이 쉽고 번들 크기가 0KB라는 이점이 있으나, 상태 객체 내의 단일 속성만 변경되어도 이를 구독하는 **모든** 컴포넌트가 불필요하게 리렌더링되는 치명적인 부작용이 있다 [7, 11, 23]. 이로 인해 실제 상용 대시보드 환경에서 심각한 화면 멈춤 현상 등 성능 저하를 유발할 수 있다 [7]. 또한 시간 여행 디버깅 도구가 없고 비동기 작업 시 클로저(Closure)가 오래된 상태를 참조하는 문제가 발생할 수 있다 [21, 24].
+*   **Zustand의 유연성이 초래하는 파편화**
+    *   사용이 매우 자유롭고 가볍지만, Redux처럼 엄격하게 강제하는 미들웨어 패턴이나 아키텍처 규칙이 없다 [25, 26]. 팀 규모가 커지면 비동기 처리나 상태 업데이트 방식을 개발자마다 다르게 작성하는 'Store Soup' 현상과 일관성 붕괴(Integration Chaos)가 발생할 수 있다 [25-27].
+*   **Redux의 오버엔지니어링**
+    *   엄격한 구조 덕분에 대규모 팀에서 버그를 예방하고 예측 가능성을 높일 수 있지만, 초기 보일러플레이트와 학습 곡선이 매우 가파르다 [17, 23, 28]. 소규모 프로젝트나 빠른 MVP 개발 단계에서 채택할 경우 불필요하게 개발 속도를 저하시키는 오버엔지니어링이 된다 [23].
+*   **번들 크기에 대한 오해**
+    *   라이브러리 선택 시 단순히 번들 크기(Context 0KB, Zustand 2.2KB, Redux 4.3KB)만을 기준으로 삼는 것은 잘못된 지표 최적화이다 [5, 9]. 번들 크기를 아끼려다 부적절한 도구를 선택하면(예: Context로 복잡한 상태 관리), 이후 리렌더링 최적화와 디버깅에 수주의 개발 시간을 낭비하게 되는 역효과가 발생한다 [7, 9].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [관계 유형 A (상태 및 데이터 아키텍처)]
+- [[Server State]]
+  - 연결 이유: 현대 프론트엔드 아키텍처에서는 전역 애플리케이션 상태와 외부 API에서 가져오는 서버 상태를 구분하여 다루기 때문이다 [3].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 데이터를 캐싱, 동기화, 무효화하는 과정이 순수 클라이언트 상태 관리와 어떻게 본질적으로 다른지 이해할 수 있다 [3, 22].
+- [[Local State]]
+  - 연결 이유: 전역 상태 관리 라이브러리를 도입하더라도, 컴포넌트 내부에 국한된 상태(예: UI 토글, 폼 입력값 등)는 여전히 `useState` 등으로 관리되어야 하기 때문이다 [1, 2].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 어떤 데이터를 전역 스토어에 넣고 어떤 데이터를 로컬에 남겨두어야 하는지(상태 소유권 경계)를 결정하는 아키텍처 설계 능력 [1, 29].
+
+#### [관계 유형 B (성능 및 최적화 메커니즘)]
+- [[Selector Pattern]]
+  - 연결 이유: Zustand와 같은 라이브러리가 Context API의 리렌더링 폭풍 문제를 극복하는 핵심 기술적 원리이다 [3, 15].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 컴포넌트가 자신이 필요로 하는 특정 상태 조각(Slice)만을 명시적으로 구독하여 불필요한 렌더링을 차단하는 메커니즘 [11, 15].
+- [[Prop Drilling]]
+  - 연결 이유: 상태 관리 라이브러리와 Context API가 프론트엔드 생태계에 등장하게 된 근본적인 문제 상황이다 [8].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 상태를 필요로 하지 않는 중간 컴포넌트들을 거쳐 데이터를 전달할 때 발생하는 결합도 증가 문제와 유지보수의 어려움 [8].
+
+### Deeper Research Questions
+
+- Zustand의 선택자(Selector) 패턴은 내부적으로 React의 렌더링 사이클과 어떻게 분리되어 동작하며, 정확히 어떤 원리로 불필요한 리렌더링을 차단하는가?
+- TanStack Query(서버 상태)와 Zustand/Redux(클라이언트 전역 상태)를 혼합하여 사용할 때, 두 상태 영역 간의 데이터 동기화 및 의존성 관리는 어떤 아키텍처 패턴으로 구현해야 하는가?
+- 대규모 팀에서 Redux의 엄격한 구조(Action, Reducer, RTK Query)가 비동기 로직의 일관성을 어떻게 강제하며, 이것이 Zustand의 자유도와 비교하여 유지보수성 측면에서 구체적으로 어떤 이점을 제공하는가?
+- Context API와 Zustand를 한 애플리케이션 내에서 결합하여(예: 정적 테마는 Context, 동적 데이터는 Zustand) 하이브리드 형태로 구성할 때 고려해야 할 최적화 및 구조적 한계는 무엇인가?
+- 프론트엔드 아키텍처론(예: Feature-Sliced Design)을 적용할 때, 전역 상태 관리 라이브러리의 스토어(Store) 코드는 애플리케이션의 어느 계층(Layer)에 배치해야 기능 간 결합도를 최소화할 수 있는가?
+
+### Practical Application Contexts
+
+- **Implementation:** 정적인 설정(테마, 다국어 설정)은 별도의 종속성이 없는 Context API로 구현하고, 장바구니나 알림 시스템처럼 빈번하게 업데이트되는 동적 데이터는 성능을 위해 Zustand나 Redux를 구현하여 분리 적용한다 [30, 31].
+- **System Design:** 애플리케이션의 상태를 분석하여 로컬 UI 상태, 기능(Feature) 상태, 전역 인프라 상태로 명확히 분류하고, 각 데이터의 성격에 맞는 라이브러리를 채택하도록 아키텍처 경계를 설계한다 [1, 32].
+- **Operation / Maintenance:** 애플리케이션이 중간 규모일 때는 Zustand로 빠르게 기능을 배포(MVP)하되, 프로젝트가 대규모로 성장하고 비동기 상태가 복잡해져 한계에 부딪히면 유지보수와 디버깅을 위해 Redux로 마이그레이션할 타이밍을 운영 측면에서 계획한다 [27, 33].
+- **Learning Path:** React의 기본 데이터 흐름을 이해하기 위해 먼저 Context API를 학습하고 직접적인 한계(리렌더링 문제)를 겪어본 후, 외부 상태 관리 도구인 Zustand나 Redux로 나아가는 순차적 학습이 개념 파악에 효과적이다 [34].
+- **My Project Relevance:** 현재 진행 중인 프로젝트를 리팩토링할 때, 서버 통신 데이터는 TanStack Query를 도입하여 로딩/에러/캐싱을 위임하고, 클라이언트 상태는 불필요한 Context 대신 Zustand를 도입해 렌더링 성능과 코드를 최적화할 수 있다 [4, 35].
+
+### Adjacent Topics
+
+- [[Feature-Sliced Design]]
+  - 확장 방향: 전역 상태의 의존성을 줄이고, 기능(Feature)과 도메인별로 코드와 상태 로직을 모듈화하여 확장성을 극대화하는 프론트엔드 전용 아키텍처 방법론 탐구 [36, 37].
+- [[React Performance Profiling]]
+  - 확장 방향: 상태 관리 라이브러리 교체 전후의 리렌더링 횟수와 렌더링 시간을 React DevTools Profiler나 why-did-you-render 같은 도구를 사용해 수치적으로 시각화하고 최적화하는 기법 학습 [7, 38, 39].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Storybook Component Testing.md b/00_Raw/Storybook Component Testing.md
new file mode 100644
index 00000000..2827c708
--- /dev/null
+++ b/00_Raw/Storybook Component Testing.md	
@@ -0,0 +1,66 @@
+# [[Storybook Component Testing]]
+
+## 📌 Brief 시 Summary
+Storybook 컴포넌트 테스트는 프론트엔드 개발 과정에서 컴포넌트를 독립적인 환경에서 구축하고 시각적 회귀(Visual Regression) 및 접근성(Accessibility)을 자동화하여 검증하는 방법론입니다 [1-3]. 실제 브라우저 환경에서 렌더링된 컴포넌트의 스냅샷을 캡처하여 기존의 '정상' 기준선(baseline)과 비교함으로써, 의도치 않은 UI 변경이나 접근성 위반을 Pull Request(PR) 단계에서 즉각적으로 잡아낼 수 있습니다 [2-5]. 테스트 코드를 직접 작성하지 않아도 스토리를 기반으로 시각적 픽셀 변경을 검증하므로, 코드 유지보수성과 리뷰 효율성을 크게 높여줍니다 [3].
+
+## 📖 Core Content
+* **컴포넌트 격리 및 시각적 테스트(Visual Testing):**
+  Storybook은 개발자가 UI 컴포넌트를 독립적으로 분리하여 구축할 수 있게 해줍니다 [1]. 시각적 테스트는 Storybook의 각 스토리를 실제 브라우저(Chrome, Safari, Firefox 등)에서 렌더링한 후 픽셀 단위로 캡처하여 기존 기준선과 비교하는 방식으로 이루어집니다 [2, 3]. HTML 마크업 블롭(blob)을 비교하는 기존의 스냅샷 테스트(Snapshot testing)와 달리, 사용자가 실제로 경험하는 픽셀을 테스트하므로 거짓 양성(false positive)을 줄이고 보다 정확한 검증이 가능합니다 [6].
+* **인터랙션 테스트(Interaction Testing)와의 결합:**
+  인터랙션 테스트는 이벤트, 상태, 접근성 등 컴포넌트의 동작(behavior)을 검증하는 반면, 시각적 테스트는 레이아웃, 색상, 타이포그래피 등의 외관(appearance)을 검증합니다 [7]. 인터랙션 테스트를 통해 로딩, 에러, 호버 등의 다양한 UI 상태를 시뮬레이션한 후, 각 상태에 대해 시각적 스냅샷을 촬영함으로써 동작과 시각적 검증을 하나의 워크플로우로 결합할 수 있습니다 [8, 9].
+* **접근성(Accessibility) 회귀 테스트:**
+  시각적 테스트를 실행할 때 추가적인 테스트 코드 작성 없이 접근성 회귀 테스트를 함께 실행할 수 있습니다. 이를 통해 시각적 변경 사항과 함께 새로운 접근성 위반 사항을 동시에 포착할 수 있습니다 [8, 9].
+* **플랫폼 및 도구 생태계:**
+  Storybook은 Chromatic(Storybook 메인테이너가 만든 클라우드 서비스)이나 Happo와 같은 도구를 통해 시각적 테스트를 기본적으로 지원합니다 [2, 3]. 이들 도구는 병렬 테스트, 다양한 뷰포트 크기 지원, 애니메이션 제거 및 비동기 에셋 대기 기능을 제공하여 테스트 결과를 안정적으로 유지합니다 [2, 4].
+
+## ⚖️ Trade-offs & Caveats
+* **테스트의 불안정성(Flakiness) 및 노이즈:** 
+  시각적 테스트는 렌더링된 픽셀을 비교하기 때문에 이미지 압축, 안티앨리어싱(anti-aliasing), 애니메이션, 비동기 폰트 및 에셋 로딩 등으로 인해 미세한 픽셀 차이가 발생할 수 있습니다 [4, 10]. 이를 해결하기 위해 도구 자체에서 애니메이션을 음소거(silence)하거나, 시각적 변경에 대한 '색상-델타 허용 오차(color-delta tolerance)'를 설정하여 사소한 차이를 무시하도록 구성해야 하는 제약이 있습니다 [4, 9, 10].
+* **클라우드 서비스 의존도:**
+  Chromatic이나 Happo와 같은 시각적 회귀 테스트 도구는 클라우드 환경에서 실제 브라우저를 구동하여 캡처를 수행하므로, 이를 자동화 워크플로우(CI/CD)에 연동하고 최적의 성능을 얻기 위해 외부 서비스 가입 및 인증 토큰(Environment variables) 관리가 필수적입니다 [5, 11].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [테스트 유형 및 방법론 (Testing Types & Methodologies)]
+- [[Visual Regression Testing]]
+  - 연결 이유: Storybook 컴포넌트 테스트의 핵심 원리로, 코드 변경 전후의 UI 픽셀 렌더링 결과를 비교하는 기술입니다 [2, 6].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: HTML 마크업만 비교할 때 발생하는 한계점을 극복하고, 실제 사용자가 보는 화면의 결함을 어떻게 추적하는지 이해할 수 있습니다.
+- [[Snapshot Testing]]
+  - 연결 이유: 시각적 테스트와 자주 비교되는 테스트 방식으로, 주로 렌더링된 마크업(HTML 블롭)을 저장하고 비교합니다 [6].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 시각적으로는 변경이 없지만 코드 구조가 바뀌었을 때 발생하는 거짓 양성(false positive) 오류의 원인을 파악할 수 있습니다.
+- [[Interaction Testing]]
+  - 연결 이유: Storybook 내에서 컴포넌트의 특정 이벤트나 상태(예: 클릭, 입력, 호버 등)를 시뮬레이션하는 테스트입니다 [7, 8].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 컴포넌트의 복잡한 동작 상태를 먼저 구현한 뒤 그 결괏값에 대한 시각적 스냅샷을 찍는 워크플로우를 이해할 수 있습니다.
+
+#### [테스트 및 배포 도구 (Tools & Infrastructure)]
+- [[Chromatic]] / [[Happo]]
+  - 연결 이유: Storybook의 시각적 테스트 및 접근성 검증을 실제 크로스 브라우저 환경에서 자동화해 주는 대표적인 서비스 및 플러그인입니다 [2, 3].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 허용 오차(tolerance) 설정, 애니메이션 제어 등 테스트 노이즈를 줄이는 실무적인 메커니즘을 배울 수 있습니다.
+- [[CI/CD Integration]]
+  - 연결 이유: Storybook 시각적 테스트는 GitHub, GitLab, CircleCI 등의 CI 파이프라인에 통합되어 PR 단계에서 변경 사항을 검증합니다 [4, 5].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 프론트엔드 팀이 코드를 병합하기 전 UI 버그를 차단하는 자동화된 게이트웨이 시스템을 이해할 수 있습니다.
+
+### Deeper Research Questions
+- Storybook의 시각적 테스트(Visual tests)와 마크업 기반의 스냅샷 테스트(Snapshot tests) 간의 구체적인 성능 및 유지보수 비용의 차이는 무엇인가?
+- Chromatic이나 Happo 같은 도구는 동적인 애니메이션이나 비동기 데이터 로딩으로 인해 발생하는 테스트 실패(Flaky tests)를 기술적으로 어떻게 방지하는가?
+- 상호작용 테스트(Interaction testing)를 통해 도출된 여러 UI 상태를 시각적 회귀 테스트와 연동할 때, 테스트 커버리지 측면에서 어떤 한계점이 존재하는가?
+- 다수의 뷰포트 크기와 크로스 브라우저 환경에서 Visual Regression Testing을 실행할 때 발생하는 CI 파이프라인의 병목 현상은 어떻게 최적화할 수 있는가?
+- 접근성 회귀 테스트(Accessibility regression testing)가 시각적 테스트 워크플로우에 통합될 때, 구체적으로 어떤 접근성 위반(예: 명도 대비, ARIA 속성 등)을 캡처할 수 있는가?
+
+### Practical Application Contexts
+- **Implementation:** React 등 UI 컴포넌트 개발 시, 컴포넌트 단위로 Storybook 스토리를 작성하고 `@chromatic-com/storybook` 또는 Happo 플러그인을 설치하여 `chromatic.config.json` 설정을 통해 프로젝트에 적용합니다 [2, 11, 12].
+- **System Design:** 프론트엔드 팀의 협업 아키텍처에 시각적 리뷰 시스템을 도입하여, 로컬 환경에서만이 아닌 클라우드 브라우저(크롬, 사파리 등) 렌더링 결과를 기준으로 디자인 시스템의 일관성을 유지하도록 설계합니다 [2, 5].
+- **Operation / Maintenance:** CI 파이프라인에서 PR이 생성될 때마다 테스트를 실행하고, 변경 사항이 있을 시 🟡(노란색)으로 표시되는 픽셀 차이를 담당자가 확인 후 ✅(승인) 처리하여 새로운 Baseline을 갱신하는 방식으로 운영합니다 [13, 14].
+- **Learning Path:** 기초적인 Storybook 컴포넌트 렌더링 작성법 습득 → Interaction Testing을 통한 상태 제어 학습 → Chromatic/Happo 등을 연동한 자동화 Visual Testing 및 CI 환경 구축 순으로 학습합니다.
+- **My Project Relevance:** 타인이 작성한 레거시 React 코드를 리팩토링하거나(TS 마이그레이션, Hooks 변환, 패키지 업데이트 등), CSS 방식(Tailwind, CSS Modules 등)을 표준화할 때 기존 UI가 의도치 않게 깨지는 것을 방지하는 안전망(UI test suite)으로 반드시 활용해야 합니다 [1, 15].
+
+### Adjacent Topics
+- [[Component-Driven UI]]
+  - 확장 방향: 페이지나 화면 전체가 아닌, 애플리케이션을 작은 컴포넌트 단위부터 상향식(Bottom-up)으로 개발하는 개념으로, Storybook의 존재 이유와 맞닿아 있습니다.
+- [[Pull Request (PR) Code Review]]
+  - 확장 방향: 로직 코드 리뷰뿐만 아니라, CI와 연동된 시각적 디프(diff) 도구를 통해 UI 및 디자인 변경을 팀원들과 효과적으로 시각적으로 리뷰하는 문화로 확장될 수 있습니다.
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Technical Debt Management.md b/00_Raw/Technical Debt Management.md
new file mode 100644
index 00000000..05a3e708
--- /dev/null
+++ b/00_Raw/Technical Debt Management.md	
@@ -0,0 +1,63 @@
+# [[Technical Debt Management]]
+
+## 📌 Brief Summary
+기술 부채 관리(Technical Debt Management)는 개발자가 장기적인 코드 구조보다 단기적인 개발 속도를 우선시할 때 축적되는 비효율적인 코드를 예방하고 재구성하는 지속적인 과정입니다 [1]. 최신 프론트엔드 환경에서 이를 관리하려면 엄격한 폴더 아키텍처와 명명 규칙을 적용하고, 애플리케이션의 기존 동작을 유지하면서 구조를 개선하는 점진적인 리팩토링 전략을 채택해야 합니다 [1-3]. 궁극적으로 작성된 "모든 코드는 기술 부채"라는 인식을 바탕으로, 잉여 코드를 제거하고 구조를 현대화하는 데 집중하는 것이 핵심입니다 [4].
+
+## 📖 Core Content
+*   **원인과 예방 (Causes and Prevention):**
+    기술 부채는 개발 과정에서 구조적 원칙을 무시하고 파일을 무분별하게 배치할 때 조용히 스며들며, 장기적으로 유지보수의 혼란을 초래합니다 [1]. 이를 예방하려면 일관성 있는 폴더 구조를 갖추어 개발자에게 규율을 부여하고, 일관된 명명 규칙(Naming Conventions)을 적용하여 시간이 지남에 따라 쌓이는 기술 부채를 줄여야 합니다 [1, 3].
+*   **점진적 리팩토링 전략 (Incremental Refactoring Strategy):**
+    애플리케이션이 오래될수록 코드베이스를 건강하게 유지하기 위해 리팩토링이 필수적입니다 [2]. 전체 시스템을 완전히 다시 작성(Complete rewrite)하는 것은 위험도가 매우 높기 때문에, "재작성이 아닌 리팩토링(refactor, do not rewrite)" 철학을 기반으로 한 번에 하나의 모듈이나 스토어씩 변경하는 점진적 마이그레이션을 수행해야 합니다 [2]. 
+*   **커스텀 훅을 통한 모듈화 (Custom Hooks as Refactoring Units):**
+    React 개발에서 리팩토링의 주요 단위는 커스텀 훅(Custom Hook)입니다 [5]. 복잡한 컴포넌트에서 데이터 페칭이나 폼 핸들링 등의 비즈니스 로직을 추출하여 훅으로 분리하면, UI와 로직이 분리되어 코드를 독립적으로 테스트하기 쉬워지고 기술 부채가 완화됩니다 [5].
+*   **아키텍처 부채 관리 (Architectural Debt Management):**
+    기능 분할 설계(Feature-Sliced Design, FSD)와 같은 아키텍처 방법론을 도입하면 각 모듈을 다른 부분에 대한 부작용(Side effects) 없이 독립적으로 수정하거나 리팩토링할 수 있습니다 [6]. 명확한 경계와 단방향 의존성을 강제함으로써, 새로운 기능 추가나 성능 최적화 작업 시 아키텍처 부채가 누적되는 것을 방지합니다 [6, 7].
+
+## ⚖️ Trade-offs & Caveats
+*   **전면 재작성(Complete Rewrite)의 위험성:** 오래된 기술이나 구조를 한 번에 교체하는 것은 매력적으로 보일 수 있으나, 기존의 안정성을 훼손할 위험이 커서 권장되지 않으며 느리더라도 점진적으로 개선해야 하는 제약이 따릅니다 [2].
+*   **과도한 추상화의 역효과:** 코드의 중복을 줄이기 위한 DRY(Don't Repeat Yourself) 원칙을 너무 일찍 적용하면, 코드가 지나치게 복잡해지는 과도한 추상화라는 새로운 기술 부채를 낳을 수 있습니다 [8]. 패턴이 세 번 반복될 때까지 기다렸다가 추상화하는 것이 조기 최적화로 인한 부작용을 막는 방법입니다 [9].
+*   **단순성(Simplicity) 중심 조기 최적화의 함정:** 초기 개발 속도와 단순성을 위해 손쉬운 도구(예: 전역 상태에 무분별한 Context API 사용)를 선택하는 것은, 애플리케이션이 커졌을 때 고통스러운 대규모 리팩토링을 유발할 수 있습니다 [10].
+*   **기능 분할 설계의 초기 도입 비용:** Feature-Sliced Design 같은 엄격한 구조는 대규모 앱의 부채를 막는 데 탁월하지만, 소규모 프로젝트나 경험이 적은 팀에게는 학습 곡선이 가파르고 불필요한 오버헤드로 작용할 수 있습니다 [11, 12].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [아키텍처/기반 기술]
+- [[Feature-Sliced Design]]
+  - 연결 이유: 프로젝트를 기능과 도메인 스코프에 따라 분할하여, 코드를 변경할 때 시스템 전체로 파급 효과가 퍼지는 것을 막고 부채를 국소화합니다 [6, 13].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 예측 가능한 의존성 경계를 설계하여 어떻게 대규모 리팩토링을 안전하게 수행할 수 있는지 이해할 수 있습니다.
+- [[Incremental Migration]]
+  - 연결 이유: 레거시 기술을 현대화할 때 전체를 폐기하는 대신 점진적으로 부채를 청산해 나가는 가장 실용적이고 권장되는 방식입니다 [2].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 새로운 기능 개발과 기술 부채 상환을 동시에 진행하는 실무 전략을 파악할 수 있습니다.
+
+#### [구현/코드 품질 원칙]
+- [[DRY (Don't Repeat Yourself)]]
+  - 연결 이유: 중복 코드 제거는 부채 관리의 기본이지만, 맹목적인 적용은 코드를 'KISS' 원칙에서 멀어지게 하여 오히려 유지보수 부채를 증가시킵니다 [8, 9].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 올바른 추상화 타이밍과 원칙 간의 상충 관계(Trade-off)를 배울 수 있습니다.
+- [[Custom Hooks]]
+  - 연결 이유: 뚱뚱해진 React 컴포넌트를 작고 테스트 가능한 단위로 쪼개는 핵심적인 리팩토링 도구입니다 [5].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: UI 컴포넌트에서 비즈니스 로직과 상태 관리를 분리하는 실용적인 기법을 배울 수 있습니다.
+
+### Deeper Research Questions
+- 전체 시스템을 점진적으로 마이그레이션(Incremental Migration)할 때, 신구 상태 관리 도구(예: Context API와 Zustand) 간의 데이터 동기화 및 하위 호환성을 어떻게 유지할 것인가?
+- 대규모 모놀리식(Monolithic) 폴더 구조를 가진 레거시 프로젝트에 [[Feature-Sliced Design]]을 도입하기 위한 가장 안전하고 효율적인 단계별 절차는 무엇인가?
+- "모든 코드는 기술 부채다"라는 관점에서, 사용되지 않는 데드 코드(Dead Code)나 불필요한 렌더링 요소를 자동 식별하여 제거하기 위해 어떤 분석 도구(Profiler 등)를 활용할 수 있는가?
+- 추상화를 적용하는 기준이 되는 'Rule of Three(세 번 반복 시 추상화)'를 복잡한 프론트엔드 비즈니스 로직에 적용할 때 마주치는 한계와 예외 사례는 무엇인가?
+- 초기 스타트업 환경에서 시장 출시 속도를 높이기 위해 발생하는 '의도적인 기술 부채'를 추후 상환하기 위해 개발팀이 도입해야 할 프로세스는 무엇인가?
+
+### Practical Application Contexts
+- **Implementation:** 비대해진 React 컴포넌트 내부에서 상태 관리나 API 호출 로직을 발견했을 때, 이를 별도의 Custom Hook으로 추출하여 UI 로직을 단순화하고 테스트 가능성을 높이는 리팩토링을 수행합니다 [4, 5].
+- **System Design:** 프로젝트 셋업 단계에서 미리 명명 규칙(Naming Convention)과 기능 단위의 폴더 아키텍처를 강제하여, 개발자들이 아무 폴더에나 파일을 추가하여 발생하는 구조적 부채를 사전에 차단합니다 [1, 3].
+- **Operation / Maintenance:** 상태 관리 라이브러리를 마이그레이션할 때 전체 앱을 한 번에 바꾸지 않고 알림(Notification) 기능 등 작은 유틸리티부터 시작하여 결제 흐름 같은 복잡한 도메인으로 단계적으로 리팩토링을 진행합니다 [2].
+- **Learning Path:** 리팩토링을 학습할 때 먼저 코드에 단위 테스트(Unit Tests)를 작성하여 기존의 동작을 보장한 뒤에, SOLID 원칙과 Clean Code 원칙을 염두에 두고 레거시 코드를 작게 분할해 나가는 방법을 훈련합니다 [14, 15].
+- **My Project Relevance:** 현재 유지보수하거나 인수받은 낡은 코드베이스를 개선해야 한다면, 우선 기능별로 코드를 그룹화하고 중복 코드를 찾아내어 점진적으로 덜어내는 방향(Remove surplus)으로 작업을 설계합니다 [4, 16].
+
+### Adjacent Topics
+- [[Automated Testing]]
+  - 확장 방향: 기술 부채를 리팩토링하는 과정에서 애플리케이션의 동작이 깨지지 않았음을 자동으로 검증하여 리팩토링의 안정성을 보장하는 방법.
+- [[Static Code Analysis (ESLint/Prettier)]]
+  - 확장 방향: 정적 분석 도구를 CI/CD 파이프라인에 통합하여 아키텍처 규칙과 클린 코드 원칙을 자동 강제함으로써 기술 부채의 유입을 원천 차단하는 방안.
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Technical Debt.md b/00_Raw/Technical Debt.md
new file mode 100644
index 00000000..12529a8b
--- /dev/null
+++ b/00_Raw/Technical Debt.md	
@@ -0,0 +1,57 @@
+# [[Technical Debt]]
+
+## 📌 Brief Summary
+기술 부채(Technical Debt)는 단기적인 개발 속도를 위해 구조를 무시하거나 임시방편으로 코드를 작성할 때 장기적으로 발생하는 코드의 혼란과 유지보수 비용을 의미합니다 [1]. 궁극적으로 작성된 "모든 코드는 기술 부채(All code is tech debt)"로 간주될 수 있으며, 불필요한 잉여 코드를 제거하는 것이 중요합니다 [2]. 대규모 애플리케이션에서는 일관된 명명 규칙, 확장 가능한 아키텍처 도입, 그리고 지속적인 리팩토링을 통해 기술 부채를 관리하고 축소할 수 있습니다 [1, 3, 4].
+
+## 📖 Core Content
+* **기술 부채의 발생 원인:** 개발자가 파일 구조 설계를 건너뛰고 단기적으로 "그냥 이 파일을 여기에 두자"는 식으로 코드를 작성하면 단기적으로는 빠를 수 있으나, 장기적으로는 아키텍처의 붕괴와 심각한 기술 부채를 초래합니다 [1]. 또한 사용하지 않는 과도한 기능이나 코드를 남겨두는 것도 부채가 됩니다 [2].
+* **구조적 접근을 통한 부채 관리:** 
+  * **Feature-Sliced Design (FSD):** 애플리케이션을 도메인과 기능 범위에 따라 슬라이스하여 단방향 의존성을 강제합니다. 이 구조는 다른 기능에 부작용을 주지 않고 각 모듈을 독립적으로 수정하거나 재작성할 수 있게 하여 아키텍처적 기술 부채를 방지합니다 [5, 6].
+  * **명명 규칙 준수 (Naming Conventions):** 케밥 케이스(kebab-case)나 파스칼 케이스(PascalCase) 등 일관성 있고 명확한 파일 명명 규칙을 적용하는 것만으로도 장기적으로 기술 부채를 크게 줄이고 팀원 간의 협업을 쉽게 만듭니다 [4].
+* **리팩토링과 부채 상환:** 애플리케이션이 오래됨에 따라 코드베이스를 건강하게 유지하기 위해 전문적인 리팩토링이 필수적입니다. 이는 코드를 "고치는" 것이 아니라 동작을 유지하면서 구조를 개선하는 작업입니다 [3]. 특히 큰 컴포넌트의 비즈니스 로직을 '커스텀 훅(Custom Hooks)'으로 분리하는 것이 현대 React에서 리팩토링의 주요 단위가 됩니다 [7].
+
+## ⚖️ Trade-offs & Caveats
+기술 부채를 해결하기 위해 구형 기술에서 새 기술로 시스템을 이전할 때, **완전한 재작성(Complete rewrite)을 시도하는 것은 너무 위험한 선택(too risky)**이 될 수 있습니다 [3]. 대신 아키텍처를 현대화하면서도 기능 개발을 계속할 수 있도록 알림 같은 단순한 유틸리티부터 시작해 복잡한 도메인으로 나아가는 "재작성이 아닌 리팩토링(refactor, do not rewrite)" 형태의 점진적 마이그레이션을 채택해야 하는 제약이 따릅니다 [3]. 
+또한, 중복 코드를 줄이기 위해(DRY 원칙) 지나치게 추상화하면 코드가 원래의 반복된 형태보다 이해하기 어려워져 KISS(Keep It Simple, Stupid) 원칙을 위배하고 새로운 형태의 구조적 부채와 복잡성을 낳을 수 있다는 부작용이 있습니다 [8, 9].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [아키텍처 및 설계 원칙]
+- [[Feature-Sliced Design]]
+  - 연결 이유: 아키텍처의 책임을 분리하고 모듈화를 강제하여 코드 수정 시 부작용을 없앰으로써, 기술 부채 누적을 원천적으로 차단하는 방법론이기 때문입니다 [6, 10].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 대규모 React 시스템에서 기술 부채 없이 확장 가능한 구조를 설계하는 방법과 레이어(Layer), 슬라이스(Slice) 기반의 단방향 의존성 원리 [10, 11].
+
+- [[KISS and YAGNI]]
+  - 연결 이유: 코드를 단순하게 유지(KISS)하고, 미래에 필요할지도 모른다는 이유로 불필요한 기능(YAGNI)을 미리 구현하지 않음으로써 유지보수해야 할 부채 자체를 생성하지 않기 때문입니다 [8, 12].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 애자일 환경에서 사장되는 코드(Dead code)를 줄이고 지나친 추상화를 피하는 방법 [12].
+
+#### [코드 유지보수 및 관리]
+- [[Refactoring]]
+  - 연결 이유: 누적된 기술 부채를 해결하고 코드베이스를 건강하게 유지하기 위한 직접적이고 필수적인 실천 방식이기 때문입니다 [3].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 커스텀 훅(Custom hook)을 단위로 비즈니스 로직과 UI를 격리하는 기술 및 점진적 마이그레이션(Incremental migration) 전략 [3, 7].
+
+### Deeper Research Questions
+
+- 완전한 재작성(rewrite)의 위험성을 피하기 위해 점진적 마이그레이션(incremental migration)을 통해 기술 부채를 해결하는 구체적인 실무적 절차는 어떠한가?
+- DRY(Don't Repeat Yourself) 원칙의 과도한 적용이 오히려 코드 복잡성을 증가시키고 새로운 기술 부채를 생성하는 경계선은 어디인가?
+- 컴포넌트의 크기가 커짐에 따라 단일 책임 원칙(SRP)을 적용해 기술 부채를 식별하고 분리하는 효과적인 기준은 무엇인가?
+- 대규모 프로젝트에서 엄격한 폴더 계층과 파일 명명 규칙(Naming Conventions)이 기술 부채 감소에 기여하는 메커니즘은 무엇인가?
+- "모든 코드는 기술 부채다"라는 관점에서, 유지보수 측면의 부채를 줄이기 위해 제거해야 할 잉여 코드(Surplus code)를 식별하는 방법은 무엇인가?
+
+### Practical Application Contexts
+
+- **Implementation:** 파일이나 컴포넌트를 만들 때 단기적인 개발 속도를 위해 구조 없이 배치하는 것을 지양하고, 일관된 명명 규칙과 폴더 구조를 철저히 지켜 추후 발생하는 부채를 예방합니다 [1, 4]. 잉여 코드는 부채이므로 식별하여 제거합니다 [2].
+- **System Design:** Feature-Sliced Design과 같은 기능/도메인 중심의 계층형 아키텍처를 도입하여, 각 기능 단위가 서로 암묵적인 결합 없이 독립적으로 리팩토링될 수 있도록 시스템을 구성합니다 [6, 13].
+- **Operation / Maintenance:** 레거시 코드를 최신 상태로 관리할 때 시스템 전체를 엎는 대신(Rewrite 지양), 로컬 상태부터 글로벌 상태 관리까지 한 번에 하나의 스토어나 모듈씩 점진적으로 이동하는 리팩토링을 수행합니다 [3, 7].
+- **Learning Path:** React를 학습할 때 단순히 컴포넌트를 렌더링하는 것을 넘어 SOLID, DRY, KISS, YAGNI와 같은 소프트웨어 엔지니어링 원칙을 접목하여, 읽기 쉽고 부채가 적은 Clean Code 작성법을 훈련합니다 [14, 15].
+- **My Project Relevance:** React 코드베이스를 관리하거나 넘겨받아 리팩토링할 때, 가장 먼저 거대한 컴포넌트에서 비즈니스 로직을 추출해 Custom Hooks로 분리하여 유지보수성과 테스트 가능성을 높이는 작업부터 착수합니다 [7].
+
+### Adjacent Topics
+
+- [[Automated Governance]]
+  - 확장 방향: ESLint, Prettier, Husky와 같은 자동화 툴을 통해 팀원들의 실수나 임의적인 코드 구조 변경을 막아 기술 부채가 축적되는 것을 시스템적으로 방지하는 방법으로 지식을 확장할 수 있습니다 [16].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Trunk-based Development.md b/00_Raw/Trunk-based Development.md
new file mode 100644
index 00000000..50d564cc
--- /dev/null
+++ b/00_Raw/Trunk-based Development.md	
@@ -0,0 +1,56 @@
+# [[Trunk-based Development]]
+
+## 📌 Brief Summary
+Trunk-based Development는 개발자들이 짧은 주기로 작은 변경 사항을 중앙의 주 브랜치(주로 `main` 브랜치)에 지속적으로 병합하는 경량화된 브랜칭 워크플로우입니다 [1, 2]. 이 전략은 코드의 대규모 병합 충돌을 방지하고 코드의 빠른 통합(fast integration)을 달성하는 것을 목표로 합니다 [3, 4]. 주로 강력한 지속적 통합(CI) 환경을 갖춘 경험 많은 개발 팀에게 가장 적합한 방식이며, Git Flow와 같은 무거운 오버헤드를 피하고자 할 때 사용됩니다 [5].
+
+## 📖 Core Content
+- **핵심 원칙**: 메인 브랜치(`main`)는 직접적인 푸시(direct push)가 금지되며, 언제나 안정적이고 즉시 배포 가능한 상태(always stable, deployable)를 유지해야 합니다 [1, 2, 6].
+- **단기 브랜치 운영 (Short-lived branches)**: 각 작업(Task) 당 하나의 브랜치를 생성하며, 변경 사항을 작게 유지하여 아주 짧은 주기(수일 내)에 메인 브랜치로 병합해야 합니다 [1, 2, 4].
+- **빠른 통합 및 기능 플래그**: 개발자는 변경 사항을 작게 나누어 빠르게 커밋하며, 아직 완성되지 않은 기능은 기능 플래그(Feature flags)를 활용해 메인 브랜치에 병합하더라도 운영 환경에 영향을 주지 않도록 제어합니다 [4].
+- **품질 보증 (PR 및 코드 리뷰)**: 코드를 병합하기 전에는 항상 풀 리퀘스트(PR)를 열어야 하며, 최소 1명 이상의 동료 리뷰(Peer Review)와 CI(지속적 통합) 테스트 통과가 필수 조건입니다 [2, 7].
+- **히스토리 관리**: 깔끔한 커밋 히스토리를 유지하기 위해 스쿼시 병합(Squash merge)을 사용하며, 병합이 완료된 후에는 해당 기능 브랜치를 자동으로 삭제하여 레포지토리를 정리합니다 [2, 7].
+
+## ⚖️ Trade-offs & Caveats
+이 워크플로우는 무거운 프로세스 오버헤드를 제거하여 빠른 피드백을 제공하고, 장기 실행 브랜치(long-running branches)에서 발생하는 심각한 병합 충돌을 방지한다는 장점이 있습니다 [3, 8, 9]. 그러나 이러한 이점에는 분명한 반대 급부가 따릅니다. 먼저, 팀원들 간의 매우 긴밀한 조율(coordination)과 높은 규율이 요구됩니다 [3]. 두 번째로, 오류가 있는 코드가 병합되는 것을 막기 위해 매우 강력한 테스트 자동화와 CI 인프라가 필수적이며, 이러한 이유로 초보자보다는 숙련된 팀(very experienced teams)에게 적합합니다 [5]. 마지막으로 미완성 기능을 빠르게 병합하기 위해 기능 플래그(Feature flags)를 관리해야 하는 추가적인 복잡성과, 이를 뒷받침할 강력한 테스트 커버리지가 강제된다는 기술적 제약 사항이 있습니다 [4].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [워크플로우 및 통합 아키텍처]
+- [[Continuous Integration (CI)]]
+  - 연결 이유: Trunk-based Development에서 짧은 주기로 코드를 병합할 때 메인 브랜치의 안정성을 검증하기 위한 필수 전제 조건입니다 [2, 5].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 자동화된 테스트가 통과해야만 병합을 허용하는 과정이 어떻게 빌드 실패와 버그를 사전에 차단하는지 이해할 수 있습니다.
+
+#### [구현 및 코드 관리 도구]
+- [[Feature Flags]]
+  - 연결 이유: Trunk-based Development에서 코드 통합 속도를 높이기 위해, 아직 완성되지 않은 기능을 메인 브랜치에 안전하게 병합하는 데 사용되는 핵심 도구입니다 [4].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 코드의 배포(Deployment)와 기능의 릴리스(Release)를 기술적으로 어떻게 분리하여 관리할 수 있는지 파악할 수 있습니다.
+- [[Squash Merge]]
+  - 연결 이유: 짧은 수명의 브랜치를 자주 병합함에 따라 지저분해질 수 있는 메인 브랜치의 커밋 이력을 하나의 의미 있는 커밋으로 압축하여 깔끔하게 유지하는 병합 전략입니다 [2, 7, 10].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 잦은 통합 상황에서 코드 리뷰와 히스토리 추적을 용이하게 하는 Git 이력 관리 방법을 배울 수 있습니다.
+
+### Deeper Research Questions
+- Feature Branch 기반 전략에서 Trunk-based Development로 마이그레이션할 때, 개발팀의 코드 리뷰 문화와 CI 테스트 프로세스는 구체적으로 어떻게 변화해야 하는가?
+- 미완성 기능을 통합하기 위해 기능 플래그(Feature flags)를 과도하게 사용할 경우 발생할 수 있는 기술 부채(Technical debt)는 무엇이며, 이를 어떻게 청산할 수 있는가?
+- Trunk-based Development를 적용할 때, 스쿼시 병합(Squash merge)을 통해 깔끔한 메인 히스토리를 유지하는 것과 개별 작업 단위의 상세한 디버깅 추적성을 확보하는 것 사이의 균형은 어떻게 맞춰야 하는가?
+- 경험이 적은 팀(초보 팀)이 Trunk-based Development를 도입했을 때 겪을 수 있는 가장 치명적인 문제점은 무엇이며, 이를 완화하기 위한 단계적 도입 방법은 무엇인가?
+- 대규모 오픈소스 프로젝트나 대형 엔터프라이즈 환경에서 Trunk-based Development가 Git Flow 방식에 비해 가지는 구조적 한계점은 무엇인가?
+
+### Practical Application Contexts
+
+- **Implementation:** 작업을 매우 작은 단위 논리적 변경(atomic commits)으로 나누어 브랜치를 생성하고, 기능 플래그를 활용해 미완성 코드라도 지속적으로 메인 브랜치에 병합하는 방식으로 구현합니다 [4, 11].
+- **System Design:** 코드가 메인 브랜치로 병합되기 전 자동으로 코드를 검증하는 강력한 CI(지속적 통합) 파이프라인과 브랜치 보호 규칙(Branch protection)을 시스템적으로 설계하고 연동해야 합니다 [5, 7].
+- **Operation / Maintenance:** '병합 후 브랜치 자동 삭제(Auto-delete merged branches)' 설정을 켜고, 직접 푸시(direct push)를 금지하여 메인 브랜치를 항상 배포 가능한 깔끔한 상태로 유지보수합니다 [7, 11].
+- **Learning Path:** 처음에는 단순한 Feature Branch 워크플로우를 통해 작은 커밋과 PR 과정을 익히고, CI가 강화되고 브랜치 수명을 수일 내로 단축할 수 있는 확신이 들 때 Trunk-based 전략으로 점진적으로 이관하는 것이 좋습니다 [4, 5].
+- **My Project Relevance:** 소스에 관련 정보가 부족합니다.
+
+### Adjacent Topics
+
+- [[Git Flow]]
+  - 확장 방향: Trunk-based Development와 대비되는 무겁고 복잡한 브랜칭 전략으로, 왜 소규모 팀이나 빠른 배포를 원하는 팀이 이 전략 대신 Trunk-based를 선택하는지 두 전략 간의 구조적 차이와 트레이드오프를 확장하여 비교해 볼 수 있습니다 [4, 5].
+- [[Feature Branch Workflow]]
+  - 확장 방향: 소규모 팀에 가장 친화적인 기본 워크플로우로, 이 전략의 브랜치 수명을 극단적으로 줄였을 때 어떻게 Trunk-based Development로 진화하게 되는지 연결하여 학습할 수 있습니다 [4, 12].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/Vite and Bundling.md b/00_Raw/Vite and Bundling.md
new file mode 100644
index 00000000..39e67535
--- /dev/null
+++ b/00_Raw/Vite and Bundling.md	
@@ -0,0 +1,63 @@
+# [[Vite and Bundling]]
+
+## 📌 Brief Summary
+Vite는 Webpack을 대체하며 프론트엔드 개발의 새로운 표준으로 자리 잡은 모던 빌드 도구입니다 [1, 2]. 개발 단계에서는 브라우저에 네이티브 ES 모듈(ESM) 형태로 코드를 직접 제공하여 즉각적인 서버 시작과 빠른 핫 모듈 교체(HMR)를 지원합니다 [2-4]. 프로덕션 배포 시에는 내부적으로 Rollup을 사용하여 코드를 분할하고 최적화된 번들을 생성함으로써 초기 로딩 속도를 높이고 애플리케이션의 성능을 최적화합니다 [5-7].
+
+## 📖 Core Content
+*   **하이브리드 아키텍처:** Vite는 개발 단계에서 전체 코드를 미리 번들링하지 않고 네이티브 ES 모듈(ESM)을 브라우저에 바로 서빙합니다 [4]. 이 과정에서 esbuild나 SWC(Rust 기반 컴파일러)를 사용해 JSX와 TypeScript를 거의 즉시 컴파일합니다 [2, 4]. 반면, 배포할 때는 Rollup을 사용하여 자동 코드 분할과 미사용 코드 제거(Tree-shaking)가 적용된 가볍고 최적화된 프로덕션 번들을 생성합니다 [5, 6].
+*   **거대한 청크(Large Chunks) 문제:** 기본 설정에서 Vite는 앱 코드와 모든 `node_modules` 종속성(React, 서드파티 라이브러리 등)을 하나의 거대한 `index.js` 파일로 묶어 제공합니다 [8]. 이는 모바일 기기에서의 파싱 지연과 비효율적인 캐시 무효화 등 성능 저하를 초래하며, 종종 빌드 시 "500 kB 초과" 경고를 발생시킵니다 [7, 9].
+*   **수동 청크 분할 (manualChunks):** 위 문제를 해결하기 위해 `vite.config.js`의 Rollup 옵션 중 `manualChunks`를 설정할 수 있습니다 [10, 11]. React 핵심 라이브러리나 차트 도구 등 무거운 벤더(Vendor) 패키지를 별도의 파일로 분리하면, 해당 코드는 자주 변경되지 않으므로 브라우저가 장기 캐싱을 할 수 있어 다운로드 효율이 극대화됩니다 [6, 11, 12].
+*   **동적 임포트와 지연 로딩 (Code Splitting & Lazy Loading):** `React.lazy`와 `<Suspense>`를 결합하여 라우트 수준에서 코드를 분할(Code Splitting)할 수 있습니다 [11, 13]. 이 기법을 통해 사용자가 특정 라우트나 기능에 접근할 때만 해당 청크를 다운로드하게 만들 수 있으며, 이는 초기 로딩 번들 크기를 획기적으로 줄여줍니다 [13-16].
+*   **번들 크기 분석:** 프로젝트의 번들 구성을 시각적으로 분석하기 위해 `rollup-plugin-visualizer`를 설정할 수 있습니다 [13, 16]. 빌드 후 시각화된 트리맵을 통해 필요 이상으로 큰 패키지나 불필요한 코드를 식별하여 최적화 기회를 찾을 수 있습니다 [16, 17].
+
+## ⚖️ Trade-offs & Caveats
+*   **과도한 플러그인 사용 시의 성능 저하:** Vite에서 플러그인을 지나치게 많이 사용하면 개발 서버의 속도가 느려질 수 있습니다. 환경을 쾌적하게 유지하려면 설정을 가볍고 필수적으로 유지해야 합니다 [17].
+*   **브라우저 캐싱 의존도:** 개발 모드에서 모듈 로딩 성능을 위해 브라우저 캐싱에 크게 의존합니다. 개발자 도구에서 캐시를 비활성화하면 Vite의 성능 이점을 잃을 수 있습니다 [17].
+*   **지연 로딩(Lazy Loading) 남용의 부작용:** 코드 분할은 유용하지만 남용할 경우 오히려 사용자 경험을 해칠 수 있습니다. 사용자가 접속하자마자 즉시 봐야 하는 'Above-the-fold(스크롤 없이 볼 수 있는 상단 영역)'의 필수 컴포넌트는 지연 로딩을 피하고 초기 번들에 포함시켜야 합니다 [18].
+*   **사전 번들링 제어의 필요성:** Vite는 개발 속도를 위해 외부 종속성을 사전에 번들링(Pre-bundling)하지만, 대규모 앱이나 특이한 구조의 패키지가 섞여 있을 경우 속도 저하가 올 수 있습니다. 이런 경우 `optimizeDeps`를 세심하게 제어해야 합니다 [13, 19].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [아키텍처/기반 기술]
+- [[Rollup]]
+  - 연결 이유: Vite가 프로덕션 빌드와 번들링을 수행할 때 백엔드 엔진으로 사용하는 번들러입니다 [5, 6].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: Vite의 `manualChunks` 기능이 어떻게 동작하는지, 캐시 효율성을 위한 청크 분할 기법의 원리를 명확하게 파악할 수 있습니다 [6, 10, 11].
+- [[Native ES Modules (ESM)]]
+  - 연결 이유: Vite가 개발 모드에서 프로젝트 파일들을 번들링하지 않고 브라우저에 바로 전달하는 방식입니다 [2-4].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 기존의 Webpack과 달리 Vite가 앱 규모에 상관없이 즉각적인 HMR(Hot Module Replacement)과 빠른 구동 속도를 달성하는 핵심 원리를 이해할 수 있습니다 [3, 4].
+- [[SWC]]
+  - 연결 이유: Babel을 대체하여 Vite의 React 플러그인 내에서 코드를 고속으로 컴파일하는 Rust 기반 컴파일러입니다 [4, 20].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 대규모 프로젝트에서 개발 빌드와 리프레시 시간을 획기적으로 줄이는 최신 컴파일 성능 최적화의 기술적 기반을 알 수 있습니다 [19-21].
+
+#### [구현/활용 도구]
+- [[Code Splitting]]
+  - 연결 이유: 무거운 메인 번들을 작은 청크 단위로 나누는 최적화 전략의 핵심입니다 [8, 13, 14].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: `React.lazy`와 결합해 코드를 온디맨드(On-demand)로 불러오며, 초기 로딩 속도와 자바스크립트 페이로드 크기를 개선하는 방법을 깊게 이해할 수 있습니다 [11, 13, 15, 22].
+
+### Deeper Research Questions
+
+- 개발 단계에서 Native ESM으로 서빙하는 방식과 프로덕션에서 Rollup으로 번들링하는 방식의 아키텍처적 차이로 인해 발생할 수 있는 빌드 불일치(Build Inconsistency) 문제와 그 해결 방법은 무엇인가?
+- `manualChunks`를 설정할 때, 벤더 라이브러리를 하나로 묶는 것과 여러 개의 청크로 잘게 쪼개는 것 중 브라우저 파싱 및 캐시 효율 측면에서 이상적인 기준(Threshold)은 어떻게 결정해야 하는가? [7, 11]
+- 라우트 레벨의 지연 로딩(Lazy Loading)을 구현할 때, 다음 라우트 이동 시 로딩 지연을 막기 위해 브라우저의 `preload` 또는 `prefetch` 힌트를 어떻게 결합하는 것이 효율적인가? [23, 24]
+- Vite 환경에서 대용량 서드파티 라이브러리의 불필요한 코드를 완전히 제거하기 위해, 트리 쉐이킹(Tree-shaking)을 극대화할 수 있는 모듈 임포트 패턴은 무엇인가? [17]
+- `optimizeDeps`를 통한 사전 번들링 처리 과정에서, 개발 환경 속도를 심각하게 떨어뜨릴 수 있는 '특이한 패키지(Unusual Dependencies)'의 기술적 특징은 무엇인가? [13, 19]
+
+### Practical Application Contexts
+
+- **Implementation:** React + Vite 프로젝트 시작 시 `vite.config.js`에 `@vitejs/plugin-react-swc`를 도입하여 빠른 빌드 환경을 구축하고, 절대 경로 패스 별칭(Path Aliases)을 설정하여 모듈 관리 효율을 높입니다 [20, 21]. `rollup-plugin-visualizer`를 추가해 빌드 결과물의 사이즈를 정기적으로 체크합니다 [13, 25].
+- **System Design:** 초기 아키텍처 설계 시부터 애플리케이션 코드를 도메인 및 라우트별로 분리하고, `manualChunks`를 구성해 React 엔진 등 무거운 라이브러리와 애플리케이션 비즈니스 로직이 독립된 파일로 번들링 되도록 브라우저 캐싱 전략을 세웁니다 [6, 10, 11].
+- **Operation / Maintenance:** 프로덕션 빌드 파이프라인에서 "Some chunks are larger than 500 kB" 경고를 모니터링 체계에 통합합니다. 경고 발생 시 `stats.html` 파일을 분석하여 어떤 패키지가 메인 번들을 비대화시키는지 파악하고 동적 임포트로 리팩터링합니다 [8, 9, 16].
+- **Learning Path:** 우선 브라우저의 ES 모듈 처리 방식과 Vite의 핵심 개발 철학을 배운 뒤, Rollup의 번들링 개념을 익힙니다. 이후 React의 `Suspense` 및 `React.lazy`를 통한 코드 스플리팅 패턴을 프로젝트에 직접 적용하는 순서로 학습합니다 [3, 4, 13].
+- **My Project Relevance:** 거대한 자바스크립트 번들이 사용자 기기에 부담을 주는 대시보드나 스토어프론트 구축 시, Vite 번들링 최적화를 적용하여 초기 다운로드 시간을 줄이고 성능 점수(LCP, INP 등)를 극대화하는 직접적인 해결책으로 활용할 수 있습니다 [7, 22, 26].
+
+### Adjacent Topics
+
+- [[Core Web Vitals]]
+  - 확장 방향: 번들 최적화 및 지연 로딩이 FCP(First Contentful Paint), LCP(Largest Contentful Paint), INP(Interaction to Next Paint)와 같은 구체적 성능 지표를 어떻게 개선하는지에 대한 측정 방법 및 연관성 탐구 [7, 14, 22, 26].
+- [[Micro-Frontends]]
+  - 확장 방향: 번들링 최적화의 연장선으로 단일 거대 애플리케이션(Monolith)을 여러 개의 독립된 빌드/배포 단위로 쪼개는 아키텍처적 진화 방향에 대한 심층 연구 [27].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/YAGNI.md b/00_Raw/YAGNI.md
new file mode 100644
index 00000000..3ec47b1a
--- /dev/null
+++ b/00_Raw/YAGNI.md
@@ -0,0 +1,52 @@
+# [[YAGNI]]
+
+## 📌 Brief Summary
+YAGNI는 "You Aren't Gonna Need It(당신은 그것이 필요하지 않을 것이다)"의 약자로, 미래에 필요할지도 모르는 기능을 미리 구현하지 말라는 소프트웨어 엔지니어링 원칙입니다 [1, 2]. 개발자는 오직 현재의 요구사항에만 집중해야 하며, 나중에 사용될 수도 있다는 이유만으로 복잡한 기능을 사전에 추가하는 것을 피해야 합니다 [1, 3]. 이 원칙을 통해 개발자는 시간 낭비를 줄이고, 유지보수해야 할 코드의 양과 복잡성을 최소화할 수 있습니다 [1, 4].
+
+## 📖 Core Content
+*   **핵심 개념 및 목적**: YAGNI는 현재 명확히 요구되지 않은 기능에 대해 개발 시간을 낭비하지 않도록 돕는 실용주의적 방법론입니다 [3]. 미래를 대비해 선제적으로 작성한 추가 기능은 결국 실제 사용되지 않을 확률이 높으며, 추후 요구사항이 변경되면 애써 작성한 코드가 아예 불필요해질 수도 있습니다 [3]. 
+*   **React 및 프론트엔드 생태계에서의 적용**: React 컴포넌트를 개발할 때, 현재 컴포넌트가 당장 필요로 하는 기능과 속성(props)만을 먼저 구현하는 방식으로 적용됩니다 [5]. 확장성은 추후 실제로 그 기능이 필요해졌을 때 고려하여 덧붙이는 형태를 취합니다 [5].
+*   **적용 환경**: 특히 요구사항이 빠르고 빈번하게 변경되는 애자일(Agile) 개발 환경이나 스타트업 프로젝트에서 매우 중요한 원칙으로 작용합니다 [1, 5]. 현재 기능에 집중함으로써 프로젝트의 방향 전환 시 불필요한 레거시 코드가 발목을 잡는 것을 방지합니다.
+
+## ⚖️ Trade-offs & Caveats
+YAGNI 원칙을 준수하면 개발 과정에서 낭비되는 노력(wasted effort)을 크게 줄일 수 있고 시스템 내에 방치되는 데드 코드(dead code)를 최소화할 수 있다는 강력한 장점이 있습니다 [1, 4]. 
+
+하지만 반대 급부(Trade-off)로 **미래의 확장성(future scalability)을 간과할 위험**이 있습니다 [4]. 당장의 요구사항에만 지나치게 초점을 맞추다 보면, 추후 시스템을 대규모로 확장하거나 근본적인 변경이 필요할 때 기존 구조가 유연하게 대응하지 못하여 오히려 더 큰 리팩토링 비용을 초래할 수 있는 제약 사항이 존재합니다 [4].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [소프트웨어 엔지니어링 원칙 (Software Engineering Principles)]
+- [[KISS]]
+  - 연결 이유: "Keep It Simple, Stupid"의 약자로, 코드를 단순하게 유지하고 복잡성을 피하라는 원칙이므로 YAGNI와 방향성을 공유합니다 [2, 6].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: YAGNI가 기능의 '추가 여부(개발할 것인가 말 것인가)'를 결정한다면, KISS는 개발하기로 결정된 기능을 '얼마나 단순하게 구현할 것인가'를 규정하여 클린 코드 작성을 돕습니다 [2].
+- [[DRY]]
+  - 연결 이유: "Don't Repeat Yourself"의 약자로, YAGNI, KISS와 함께 반복을 줄이고 유지보수성을 높이는 또 다른 핵심 원칙으로 묶여 언급됩니다 [2, 6].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 중복 코드를 제거하기 위해 추상화(Custom Hooks 등)를 도입할 때, 과도한 추상화(Over-engineering)로 이어지지 않도록 YAGNI 원칙과 어떻게 상호 보완적으로 작용해야 하는지 이해할 수 있습니다 [5, 6].
+- [[SOLID]]
+  - 연결 이유: 확장성과 유지보수성이 높은 코드를 작성하기 위한 5가지 원칙 모음으로, React 환경에서도 컴포넌트를 분리하고 결합도를 낮추는 기반 기술로 작용합니다 [7, 8].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 아키텍처 수준에서 단일 책임 원칙(SRP)이나 개방/폐쇄 원칙(OCP)을 지키는 뼈대를 구축하면서도, YAGNI를 통해 불필요한 클래스나 인터페이스 확장을 어떻게 제어할 수 있는지 균형점을 학습할 수 있습니다 [8, 9].
+
+### Deeper Research Questions
+- YAGNI 원칙을 적용할 때, '미래를 대비한 유연한 아키텍처 설계'와 불필요한 '오버엔지니어링(Over-engineering)' 사이의 경계는 구체적으로 어떻게 정의하고 판단할 수 있는가?
+- 애자일(Agile) 환경에서 YAGNI 원칙이 잦은 요구사항 변경에 대한 시스템의 대처 능력을 본질적으로 어떻게 향상시키는가?
+- 미래의 확장성을 희생할 수 있다는 YAGNI의 단점(Trade-off)을 보완하면서도 초기 개발 속도를 유지하기 위한 아키텍처 패턴은 무엇인가?
+- React 컴포넌트 설계 시 YAGNI 원칙을 고수하여 단순하게 만들었다가, 추후 대규모 비즈니스 로직이 추가되어 전면적인 리팩토링이 불가피해지는 상황을 완화할 방법은 없는가?
+- "가장 단순한 해결책"을 요구하는 KISS 원칙과 "미래의 기능 배제"를 요구하는 YAGNI 원칙이 실무 코드 구현 중 서로 상충하거나 모순을 일으키는 사례는 무엇인가?
+
+### Practical Application Contexts
+- **Implementation:** React 등 프론트엔드 컴포넌트를 구현할 때, 당장 사용되지 않을 props 속성을 예상하여 선언해두거나 쓰이지 않을 헬퍼 함수를 미리 만들어두는 것을 금지함으로써 적용합니다 [5].
+- **System Design:** 소프트웨어 설계 시 현재의 비즈니스 요구사항(Business Needs)에 직결되지 않는 부가적인 시스템 레이어나 복잡한 디자인 패턴의 도입을 보류합니다.
+- **Operation / Maintenance:** 미래를 위해 남겨둔 미사용 코드(dead code)가 생기지 않으므로, 유지보수 시 개발자가 파악하고 테스트해야 할 코드의 양이 줄어들어 운영 효율성이 증가합니다 [1].
+- **Learning Path:** 클린 코드(Clean Code)의 기초를 다지고, 객체지향 및 함수형 프로그래밍의 핵심 원칙(SOLID, DRY, KISS)을 학습하는 과정에서 실용주의적 개발 마인드셋을 갖추기 위해 필수적으로 함께 학습됩니다 [7, 10].
+- **My Project Relevance:** 기획이 수시로 변경될 수 있는 스타트업 프로젝트나 MVP(Minimum Viable Product) 모델을 개발할 때, 개발 속도를 최적화하고 불필요한 기능 개발에 리소스를 낭비하지 않는 데 직접적으로 활용됩니다 [5].
+
+### Adjacent Topics
+- [[Agile Development]]
+  - 확장 방향: YAGNI 원칙이 왜 애자일의 짧은 스프린트 및 반복적 개발 주기와 궁합이 잘 맞는지, 프로젝트 관리 및 개발 라이프사이클 관점에서 이해를 확장할 수 있습니다.
+- [[Clean Code]]
+  - 확장 방향: YAGNI, DRY, KISS와 같은 원칙들이 궁극적으로 가독성 높고 유지보수하기 쉬운 코드베이스(Clean Code)를 어떻게 완성하는지 통합적인 관점으로 확장해 볼 수 있습니다 [2].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/agent harness engineering.md b/00_Raw/agent harness engineering.md
new file mode 100644
index 00000000..f886b495
--- /dev/null
+++ b/00_Raw/agent harness engineering.md	
@@ -0,0 +1,89 @@
+# [[agent harness engineering]]
+
+## 📌 Brief Summary
+에이전트 하네스 엔지니어링(Agent Harness Engineering)은 AI 에이전트가 대규모로 신뢰성 있게 작동할 수 있도록 실행 환경, 제약 조건 및 피드백 루프를 설계하는 규율이자 인프라 기술입니다 [1]. 이는 프롬프트와 컨텍스트 관리를 넘어 에이전트의 세션, 도구, 보안, 오류 복구, 수명주기 등을 제어하는 런타임 환경을 구축하는 것을 의미합니다 [2, 3]. "에이전트 = 모델 + 하네스"라는 공식으로 요약되며, 확률적인 언어 모델을 결정론적인 비즈니스 및 소프트웨어 환경에서 안전하게 실행시키는 핵심 역할을 합니다 [4-6].
+
+## 📖 Core Content
+
+*   **패러다임의 진화 (Evolution of Engineering Paradigms)**:
+    AI 엔지니어링은 모델에게 "무엇을 말할지"를 고민하는 **프롬프트 엔지니어링(Prompt Engineering)**에서, "어떤 정보를 보여줄지"를 고민하는 **컨텍스트 엔지니어링(Context Engineering)**을 거쳐 발전해 왔습니다 [2, 3, 7]. 현재의 **하네스 엔지니어링(Harness Engineering)**은 모델이 "어떤 세계(환경)를 통해 움직이고 제어될 것인지"를 설계하는 단계입니다 [3]. 즉, 단순히 프롬프트를 넘겨주는 것을 넘어 가드레일, 신호등, 비상 정지 시스템을 구축하여 에이전트의 행동을 통제하는 것입니다 [3].
+
+*   **하네스의 6대 핵심 구성 요소 (The Six Core Components)**:
+    완전한 형태의 에이전트 하네스는 다음과 같은 6가지 런타임 거버넌스 기능으로 구성됩니다 [8, 9].
+    1.  **실행 루프 (Execution Loop, E)**: 에이전트의 관찰-사고-행동 주기를 오케스트레이션하고 오류 복구와 종료 조건을 관리합니다.
+    2.  **도구 레지스트리 (Tool Registry, T)**: 에이전트가 외부 세계와 상호작용하는 모든 행동을 스키마를 통해 검증하고 라우팅합니다.
+    3.  **컨텍스트 관리자 (Context Manager, C)**: 모델의 컨텍스트 창에 들어가는 정보를 제어하며, 정보의 압축, 검색, 우선순위를 결정합니다.
+    4.  **상태 저장소 (State Store, S)**: 턴(Turn) 및 세션 전반에 걸쳐 작업 관련 상태를 영구적으로 유지하고 부분적인 실패 시 복구를 지원합니다.
+    5.  **수명주기 훅 (Lifecycle Hooks, L)**: 정책 집행, 인증, 로깅을 위해 호출 전후의 가로채기(Interception) 지점을 형성합니다.
+    6.  **평가 인터페이스 (Evaluation Interface, V)**: 벤치마크나 평가 파이프라인에서 사용할 수 있도록 실행 궤적, 중간 상태, 성공 신호를 표준화된 형식으로 캡처합니다.
+
+*   **제어 메커니즘과 안전 아키텍처 (Control Mechanisms & Safety)**:
+    하네스는 **피드포워드(가이드)**와 **피드백(센서)**이라는 사이버네틱 제어 메커니즘을 사용합니다 [10]. 규칙 파일(예: `AGENTS.md`)이나 아키텍처 제약 조건을 통해 에이전트의 솔루션 공간을 사전에 줄이고(피드포워드), 린터(Linter) 오류와 같은 구조화된 신호를 루프에 주입하여 스스로 궤도를 수정하도록 유도합니다(피드백) [1, 11, 12]. 또한 샌드박스나 마이크로 VM(MicroVM)을 활용하여 코드 실행 환경을 분리함으로써, 에이전트가 시스템의 민감한 데이터나 자원에 함부로 접근하지 못하도록 보안을 강화합니다 [13-16].
+
+*   **모델 능력과 인프라의 관계 (Model Capability vs. Infrastructure)**:
+    모델 자체의 역량만으로는 실제 배포 환경에서의 신뢰성을 보장할 수 없습니다 [17, 18]. 하네스의 설계 방식을 변경하는 것만으로도 모델의 수정 없이 코딩 벤치마크에서 최대 10배의 성능 향상을 이끌어낼 수 있음이 실증적으로 증명되었습니다 [19, 20]. 이는 장기 실행(Long-running) 작업일수록 에이전트의 성능 한계가 모델이 아닌 **인프라(하네스)에 의해 결정됨**을 시사합니다 [21-23].
+
+## ⚖️ Trade-offs & Caveats
+
+*   **기능성과 격리 간의 상충 관계 (Capability vs. Isolation)**:
+    에이전트가 복잡한 작업을 수행하도록 도구 권한과 외부 시스템 접근성을 높이면 필연적으로 보안 공격 표면(예: 간접 프롬프트 인젝션 등)이 증가합니다 [24, 25]. 반대로 강력한 보안 격리를 위해 마이크로 VM, 샌드박스, 네트워크 제한 등을 도입하면 실행 지연 시간(Latency)이 늘어나고 인프라 운영 복잡성이 크게 증가합니다 [24, 26].
+*   **과도한 제약의 위험 (Over-constraining)**:
+    결정론적인 안전을 확보하기 위해 하네스의 제약을 너무 빡빡하게 설정하면, 유효한 코드 리팩토링이나 정상적인 작업 패턴마저 차단되는 부작용이 발생합니다 [11]. 린트(Lint) 규칙이 잘못 구성되면 에이전트의 속도만 늦출 뿐 출력 품질을 향상시키지 못하므로 제약의 범위를 좁게 시작하여 점진적으로 확장해야 합니다 [11].
+*   **컨텍스트 비용과 검색 지연 (Context Cost vs. Retrieval Latency)**:
+    에이전트의 모든 상호작용 이력을 컨텍스트에 누적하면 토큰 비용이 2차 함수적으로 폭증하며, '컨텍스트 부패(Context Rot)' 현상이 발생해 모델의 추론 능력이 저하됩니다 [27-29]. 이를 막기 위해 정보를 요약하거나 외부 스토리지로 오프로딩(RAG 등)하면 정보 손실과 검색 대기 시간 증가가 발생하며, 에이전트가 올바른 쿼리를 작성하지 못할 경우 필수적인 세부 정보를 놓칠 위험이 있습니다 [30, 31].
+*   **다중 에이전트 조정 오버헤드 (Multi-Agent Coordination Overhead)**:
+    특화된 하위 에이전트(Sub-agent)를 생성하는 다중 에이전트 아키텍처는 단일 에이전트 워크플로우에 비해 토큰을 최대 15배 더 사용할 수 있습니다 [32, 33]. 또한 상태 일관성 관리, 메시지 라우팅, 컨텍스트 분리 등의 조정 비용이 추가되므로, 복잡한 병렬 작업이 아닌 경우 최적화된 단일 에이전트를 사용하는 것보다 오히려 비효율적일 수 있습니다 [33-35].
+*   **표준화 대 특수성 (Standardization vs. Specialization)**:
+    MCP나 A2A와 같은 프로토콜을 사용한 표준화는 생태계의 호환성을 높여주지만, 특정 모델이나 도구에 완벽히 최적화되지 않은 구조적 타협을 강제할 수 있습니다 [36]. 성급한 표준화는 비효율적인 모델-하네스 결합을 고착시킬 수 있는 반면, 표준화를 피하면 다중 에이전트 환경에서 시스템이 파편화되는 문제를 겪게 됩니다 [36].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [관계 유형 A: 아키텍처 및 기반 기술]
+- [[Model Context Protocol (MCP)]]
+  - 연결 이유: AI 에이전트가 외부 도구, 시스템, 데이터 소스와 통신하기 위한 개방형 표준 프로토콜로, 하네스의 도구 레지스트리(T 컴포넌트)를 구현하는 핵심 기술입니다 [37, 38].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 하네스가 에이전트와 도구를 결합할 때, 각 도구의 API 명세나 인증을 하드코딩하지 않고 어떻게 범용적이고 안전하게 확장할 수 있는지 이해할 수 있습니다 [39, 40].
+
+- [[Agent-to-Agent (A2A)]]
+  - 연결 이유: 다중 에이전트 오케스트레이션 환경에서 에이전트 간의 원격 통신과 위임(Delegation)을 처리하는 표준 프로토콜입니다 [41, 42].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 에이전트 실행 루프(E 컴포넌트)가 어떻게 분산된 외부 에이전트들과 작업, 상태, 평가 데이터를 주고받으며 협업하는지 파악할 수 있습니다 [41, 43].
+
+- [[Agent State Store]]
+  - 연결 이유: 단일 세션을 넘어 에이전트의 진행 상황, 체크포인트, 과거의 경험(기억)을 지속적으로 저장하는 하네스 인프라(S 컴포넌트)입니다 [8, 44].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 긴 지평(Long-horizon)을 갖는 작업에서 에이전트가 장애를 복구하고 영구적인 기억 장치를 통해 경험을 축적하는 메커니즘을 배울 수 있습니다 [45, 46].
+
+#### [관계 유형 B: 설계 철학 및 운영 방법론]
+- [[Context Engineering]]
+  - 연결 이유: 모델에 단순 프롬프트를 넘기는 것을 넘어, 파일 시스템, 도구 출력 등 거대한 정보를 압축하고, 필터링하며 배치하여 에이전트의 주의력을 통제하는 기술입니다 [47, 48].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 하네스의 컨텍스트 관리자(C 컴포넌트)가 토큰 예산과 정보 유실 사이에서 어떻게 균형을 잡는지 최적화 기법을 심도 있게 볼 수 있습니다 [27, 49].
+
+- [[Plan-Execute-Verify (PEV) Loop]]
+  - 연결 이유: 작업을 한 번에 모델에게 맡기지 않고, 계획 생성 → 계획 내에서의 도구 실행 → 외부 기준을 통한 검증으로 분리하여 실패를 막는 하네스의 핵심 실행 패턴입니다 [50, 51].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 확률적인 AI 모델을 어떻게 결정론적이고 안정적인 엔터프라이즈 워크플로우로 묶어낼 수 있는지 구체적인 통제 단계를 확인할 수 있습니다 [50, 51].
+
+### Deeper Research Questions
+
+- 에이전트 하네스의 6대 구성 요소(E, T, C, S, L, V) 간의 교차 결합(Cross-component coupling)이 시스템의 오작동 및 보안 취약성으로 이어지는 메커니즘은 무엇인가?
+- 대규모 컨텍스트 창을 지원하는 최신 모델에서도 여전히 하네스 기반의 맥락 압축 및 검색(Retrieval)이 필요한 이유는 무엇이며, 최적의 컨텍스트 교체 임계값은 어떻게 설정되는가?
+- 하네스의 도구 레지스트리에 부여된 접근 권한이 간접 프롬프트 인젝션(Indirect Prompt Injection)을 만나면 어떻게 권한 탈취로 이어지며, 이를 막기 위한 하네스 런타임의 최적 차단 로직은 무엇인가?
+- 인간의 승인을 요구하는 수명주기 훅(Lifecycle Hooks)이 남용될 경우 발생하는 '승인 피로도(Approval Fatigue)'를 회피하면서도 결정론적 안전을 유지할 수 있는 평가 모델 아키텍처는 어떻게 설계할 수 있는가?
+- 평가 파이프라인(Evaluation Harness) 자체가 모델의 성능 측정에 편향을 유발하는 '하네스-모델 결합(Harness-Model Coupling)' 문제를 계량화하고 통제하기 위한 실험 설계 방법론은 무엇인가?
+
+### Practical Application Contexts
+
+- **Implementation:** 코드를 자율적으로 실행하는 에이전트를 구축할 때, 도커(Docker) 컨테이너나 마이크로 VM을 이용해 운영체제 레벨의 샌드박스를 구축하고 시스템 호출을 차단하는 런타임 하네스를 구현합니다 [16, 52].
+- **System Design:** 소프트웨어 아키텍처를 구성할 때, LLM을 단순히 API 호출로 사용하는 것을 넘어 '제어 평면(Control Plane)' 역할을 하는 하네스 서버를 두고, 모델 추론 영역(Brain)과 도구 실행 영역(Hands)을 물리적으로 분리합니다 [53, 54].
+- **Operation / Maintenance:** 운영 환경에서는 AgentOps, Langfuse, OpenLLMetry 같은 관측 가능성(Observability) 도구를 하네스에 연동해, 수많은 턴과 세션에 걸친 에이전트의 결정 흐름, 지연 시간, 토큰 비용, 그리고 툴 실패의 근본 원인을 모니터링합니다 [55, 56].
+- **Learning Path:** AI 개발자로서 프롬프트의 텍스트를 다듬는 프롬프트 엔지니어링을 습득한 후, RAG를 통한 정보 주입 체계인 컨텍스트 엔지니어링을 거쳐, 궁극적으로 에이전트의 안전망과 실행 사이클 전반을 통제하는 하네스 엔지니어링으로 학습 범위를 확장하게 됩니다 [7, 57].
+- **My Project Relevance:** 자신의 코드 저장소를 기반으로 AI 코딩 어시스턴트를 도입할 때, 린트(Lint) 규칙과 타입 체커, CI 테스트 결과를 하네스의 하드 게이트(Hard gate)로 연결하여, AI가 짠 코드가 사람의 리뷰로 넘어오기 전에 아키텍처 기준에 맞게 자가 수정하도록 자동화 시스템을 구축할 수 있습니다 [1, 58].
+
+### Adjacent Topics
+
+- [[Agentic Software Engineering]]
+  - 확장 방향: 하네스 인프라 위에서 에이전트가 어떻게 기획, 코딩, 테스트, 리뷰의 소프트웨어 개발 전체 수명주기(SDLC)를 자율적으로 또는 사람과 협력하여 수행하는지 연구를 확장할 수 있습니다 [59, 60].
+- [[Agent-Computer Interfaces (ACI)]]
+  - 확장 방향: 하네스가 에이전트에게 제공하는 인터페이스(명령어, 오류 반환 형식, 상태 표현 등)의 설계가 모델의 추론 및 계획 품질에 미치는 직접적인 영향을 연구할 수 있습니다 [61].
+
+---
+*Last updated: 2026-05-01*
\ No newline at end of file
diff --git a/00_Raw/system_analysis_and_improvement_plan.md b/00_Raw/system_analysis_and_improvement_plan.md
deleted file mode 100644
index cf92d5ac..00000000
--- a/00_Raw/system_analysis_and_improvement_plan.md
+++ /dev/null
@@ -1,27 +0,0 @@
-# ConnectAI 기술 부채 및 아키텍처 개선 계획 (Python Core)
-
-## 📌 핵심 진단 요약
-현재 ConnectAI의 Python 기반 추론 엔진은 알고리즘 비효율성($O(N^2)$), 동기식 I/O 블로킹, 강한 결합도(Tight Coupling)로 인해 성능 확장이 제한된 상태임. 이를 프로덕션 수준으로 끌어올리기 위한 단계별 최적화가 필요함.
-
-## 🛠️ 최적화 전략 (Phase 2: Core Optimization)
-
-### 1. 알고리즘 효율화 (Performance P1)
-- **현상**: `InferenceEngine.py`의 `feature_match_brute_force` 함수가 중첩 루프로 인해 $O(N^2)$ 복잡도 가짐.
-- **해결**: **KD-Tree** 또는 행렬 분해 기법을 도입하여 $O(N \log N)$으로 최적화. 추론 지연 시간 5~10배 단축 목표.
-
-### 2. 비동기 I/O 전환 (Throughput P1)
-- **현상**: `DataLoader.py`의 `load_dataset_sync` 함수가 동기식으로 동작하여 I/O 대기 시 CPU 유휴 발생.
-- **해결**: `asyncio` 기반 비동기 I/O 또는 스레드 풀 기반 병렬 처리를 도입하여 처리량(Throughput) 개선.
-
-### 3. 모듈 디커플링 (Maintainability P2)
-- **현상**: `PreprocessingModule`과 `CoreModel` 간의 직접 의존성으로 인한 강한 결합.
-- **해결**: **관찰자 패턴(Observer Pattern)** 도입. `DataReadyEvent` 발행-구독 모델을 통해 모듈 간 독립성 및 테스트 용이성 확보.
-
-## 🚀 구현 가이드라인
-- **Step 1**: 알고리즘 최적화 (KD-Tree 구현 및 검증)
-- **Step 2**: 비동기 I/O 전환 (async/await 래핑 및 이벤트 루프 통합)
-- **Step 3**: 아키텍처 디커플링 (이벤트 시스템 구축 및 DIP 실현)
-
----
-*분석 일자: 2026-04-30*
-*우선순위: Step 1 (ROI 최상) > Step 2 > Step 3*
diff --git a/00_Raw/useEffect.md b/00_Raw/useEffect.md
new file mode 100644
index 00000000..62b77e7f
--- /dev/null
+++ b/00_Raw/useEffect.md
@@ -0,0 +1,58 @@
+# [[useEffect]]
+
+## 📌 Brief Summary
+`useEffect`는 리액트(React) 함수형 컴포넌트에서 사이드 이펙트(side effects)를 관리하고 수행하기 위해 사용되는 핵심 훅(Hook)입니다 [1, 2]. 이 훅을 효과적으로 사용하기 위해서는 실행 타이밍을 제어하는 의존성 배열(dependency array)과 리소스 해제를 위한 클린업(cleanup) 함수를 올바르게 관리해야 합니다 [2, 3]. 코드를 작성할 때 남용하거나 관리를 소홀히 하면 예기치 않은 리렌더링과 성능 저하, 심각한 메모리 누수를 유발할 수 있습니다 [3, 4].
+
+## 📖 Core Content
+- **사이드 이펙트 관리**: `useEffect`는 주로 함수형 컴포넌트 내에서 데이터 구독, 이벤트 리스너 등록 등의 외부 시스템과의 동기화 및 부수 효과를 처리하는 데 사용됩니다 [2]. 
+- **의존성 배열(Dependency Array)의 중요성**: `useEffect`가 언제 실행될지 결정하는 의존성 배열을 정확하게 설정해야 합니다. 배열이 잘못 제공되면 예기치 않은 동작, 컴포넌트의 불필요한 리렌더링, 혹은 꼭 필요한 업데이트가 누락되는 버그가 발생할 수 있습니다 [2]. 만약 JSX 내부나 렌더링 도중 선언된 익명 함수를 `useEffect`의 의존성으로 전달하면, 매 렌더링마다 함수 참조가 새로 생성되어 `useEffect`가 불필요하게 재실행되는 원인이 됩니다 [5].
+- **클린업(Cleanup) 패턴**: 이벤트 리스너나 구독처럼 종료 시 처리가 필요한 사이드 이펙트는 `useEffect` 내부에서 반드시 클린업 함수를 반환해야 합니다 [3]. 컴포넌트가 언마운트(unmount)될 때 이 클린업 함수가 리소스를 해제하지 않으면, 참조가 메모리에 계속 남아 점진적인 성능 저하를 유발하는 메모리 누수(Memory Leak)가 발생합니다 [3, 6].
+- **서버 컴포넌트(Server Components) 환경에서의 제한**: Next.js 13 이상에서 사용되는 리액트 서버 컴포넌트(RSC)에서는 상태나 라이프사이클을 가질 수 없으므로 `useEffect`를 사용할 수 없습니다 [7]. 서버 컴포넌트는 클라이언트 측 스크립트 없이 서버에서 데이터를 직접 페칭(fetching)할 수 있게 해주어, 전통적인 `useEffect` 기반 데이터 로딩 패턴을 상당 부분 대체합니다 [8].
+
+## ⚖️ Trade-offs & Caveats
+- **성능 오버헤드와 렌더링 악순환**: `useEffect`를 남용하여 너무 많은 로직을 처리하게 되면 잦은 컴포넌트 리렌더링이 발생하여 애플리케이션의 전반적인 성능과 사용자 경험이 크게 저하될 수 있습니다 [4].
+- **메모리 누수 제약**: 개발자의 부주의로 인해 클린업 함수가 누락되거나 의존성 배열 관리가 잘못되면, 컴포넌트가 화면에서 사라진 후에도 백그라운드 연산이 계속 진행되거나 DOM 참조가 메모리에 남아(Detached DOM nodes) 치명적인 메모리 누수 제약 상황을 초래합니다 [3, 4, 6].
+- **코드 복잡도 증가**: 레거시 리액트 코드베이스 리팩토링 시, 불필요한 `useEffect` 제거가 핵심 과제로 꼽힙니다 [9]. 상태(state) 도출이나 파생 데이터 생성에 `useEffect`를 오용하면 유지보수성이 떨어지며, 이를 해결하기 위해 로직을 걷어내고 `useMemo`나 `useCallback` 등으로 구조를 다시 설계해야 하는 부담이 생깁니다 [4, 9].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [최적화 및 대안 기술]
+- [[useMemo]]
+  - 연결 이유: `useEffect`를 남용하여 파생 데이터를 계산하는 대신, 계산 비용이 높은 값을 메모이제이션할 때 적합한 대안으로 권장됩니다 [4].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 불필요한 연산과 리렌더링을 방지하고 상태 파생 최적화를 구현하는 방법.
+
+- [[useCallback]]
+  - 연결 이유: `useEffect`의 의존성 배열에 들어가는 함수의 참조(Reference Identity)를 렌더링 간에 안정적으로 유지시키기 위해 사용됩니다 [4, 5].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 자바스크립트의 참조 동등성(Reference Equality)이 리액트 렌더링 사이클 및 이펙트 실행 빈도에 미치는 영향.
+
+#### [아키텍처 및 디버깅 도구]
+- [[React Server Components]]
+  - 연결 이유: 서버 컴포넌트 환경에서는 `useEffect`의 사용이 원천적으로 차단되며, 이를 통해 `useEffect`에 의존하던 클라이언트 사이드 데이터 페칭 구조를 서버로 전환할 수 있습니다 [7, 8].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 클라이언트 상태(Client State)와 서버 컴포넌트의 역할 분리 및 하이드레이션(Hydration) 최적화 방식.
+
+- [[Memory Leaks]]
+  - 연결 이유: `useEffect`에서 클린업을 누락하는 것이 자바스크립트 환경에서 발생하는 메모리 누수의 대표적인 원인 중 하나입니다 [3, 6].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: Chrome DevTools의 Heap Snapshot 등을 활용하여 분리된 DOM 노드 및 정리되지 않은 구독을 추적하고 디버깅하는 원리.
+
+### Deeper Research Questions
+- `useEffect`의 의존성 배열 내부에서 얕은 비교(Shallow Comparison)가 동작하는 방식은 객체나 배열 같은 참조 타입 데이터에 어떤 부작용을 일으키는가?
+- `useEffect`를 이용한 클라이언트 사이드 데이터 페칭을 TanStack Query (React Query)나 Server Components로 대체했을 때 얻을 수 있는 아키텍처적 이점과 성능 차이는 무엇인가?
+- 불필요한 `useEffect`를 식별하고 제거하기 위해 `why-did-you-render`나 React Profiler와 같은 도구를 어떻게 활용하여 성능 측정의 지표로 삼을 수 있는가?
+- 컴포넌트가 언마운트되는 시점에 `useEffect`의 클린업 함수가 실행되는 과정은 브라우저의 가비지 컬렉션(Garbage Collection)과 어떻게 상호작용하는가?
+- `useEffect` 훅 내부의 로직을 `useTransition`이나 `useDeferredValue` 등 동시성(Concurrent) 기능과 결합할 때 고려해야 할 동기화 문제는 무엇인가?
+
+### Practical Application Contexts
+- **Implementation:** 함수형 컴포넌트에서 이벤트 리스너(예: 스크롤, 리사이즈)를 붙이거나 외부 라이브러리를 마운트할 때 활용하며, 반환 함수를 통해 명시적인 클린업(removeEventListener 등)을 구현해야 합니다 [2, 3].
+- **System Design:** 애플리케이션의 렌더링 성능을 설계할 때, 자주 변경되는 상태의 사이드 이펙트는 컴포넌트 트리의 최하단으로 격리하거나 Context API 대신 Zustand와 같은 상태 관리자를 활용하여 리렌더링 범위를 제한해야 합니다 [10, 11].
+- **Operation / Maintenance:** 프로덕션 환경에서 시간이 지남에 따라 앱이 느려지거나 멈추는 현상이 발생할 경우, Chrome DevTools의 Memory 탭을 통해 `useEffect`의 구독 해제 누락 여부를 프로파일링하고 메모리 누수를 디버깅합니다 [6, 12].
+- **Learning Path:** 리액트를 처음 배우는 단계에서 훅의 규칙(Rules of Hooks)을 이해하고, 생명주기(Lifecycle) 메서드가 함수형의 `useEffect`로 어떻게 대체되는지, 그리고 의존성 배열 관리가 왜 중요한지를 파악하는 핵심 학습 경로입니다 [2, 13].
+- **My Project Relevance:** 레거시 리액트 프로젝트를 리팩토링하거나 클래스 기반 컴포넌트를 마이그레이션할 때, 불필요한 `useEffect` 체인을 제거하고 의존성 배열을 교정하여 코드 스멜(Code Smell)을 없애고 확장성을 높이는 실무 과제와 직결됩니다 [9].
+
+### Adjacent Topics
+- [[Rules of Hooks]]
+  - 확장 방향: `useEffect`를 포함한 모든 리액트 훅이 반복문, 조건문 내부가 아닌 컴포넌트의 최상위에서만 일관되게 호출되어야 하는 구조적 원리를 이해하는 데 도움을 줍니다 [13].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/대규모 React 애플리케이션 아키텍처 구성.md b/00_Raw/대규모 React 애플리케이션 아키텍처 구성.md
new file mode 100644
index 00000000..ac95b55f
--- /dev/null
+++ b/00_Raw/대규모 React 애플리케이션 아키텍처 구성.md	
@@ -0,0 +1,79 @@
+# [[대규모 React 애플리케이션 아키텍처 구성]]
+
+## 📌 Brief 소스 Summary
+대규모 React 애플리케이션 아키텍처 구성은 코드, 상태 관리, 비즈니스 로직이 UI 컴포넌트로 유출되는 것을 막고 예측 가능한 성장을 가능하게 하는 엄격한 설계 방법론을 의미합니다 [1, 2]. 프로젝트가 커짐에 따라 단순히 파일 유형별(컴포넌트, 훅 등)로 폴더를 나누는 방식 대신, 기능(Feature)이나 도메인 중심으로 코드를 조직하는 방식이 필수적입니다 [3, 4]. 성공적인 아키텍처는 단방향 의존성 규칙을 강제하는 Feature-Sliced Design(FSD)과 같은 패턴을 채택하고, SOLID 원칙에 입각한 클린 코드 작성, 그리고 확장 가능한 전역 상태 관리 전략을 결합하여 개발팀의 협업 효율성과 유지보수성을 극대화합니다 [5-7].
+
+## 📖 Core Content
+
+*   **기능(Feature) 기반 모듈화 및 Feature-Sliced Design (FSD):**
+    *   과거의 React 앱은 컴포넌트, 훅, 스타일 등 기술적 역할에 따라 폴더를 분리(Type-Based)했지만, 이는 앱이 확장될수록 비즈니스 로직이 파편화되는 문제를 낳았습니다 [3, 8]. 대규모 앱에서는 도메인 기능별로 코드를 구성하는 특징 기반(Feature-based) 폴더 구조를 사용해야 합니다 [4, 9].
+    *   이를 체계화한 방법론이 Feature-Sliced Design(FSD)입니다 [10]. FSD는 코드의 스코프와 책임에 따라 `app`, `pages`, `widgets`, `features`, `entities`, `shared`라는 고정된 레이어로 구성됩니다 [5].
+    *   가장 중요한 규칙은 단방향 의존성(Unidirectional dependencies)으로, 상위 레이어는 하위 레이어를 참조할 수 있지만 반대는 불가능하여 순환 참조를 방지합니다 [5, 11]. 또한 각 슬라이스는 `index.ts`를 통해서만 외부로 노출되는 Public API 규칙을 따라야 캡슐화가 보장됩니다 [7, 12].
+*   **컴포넌트 설계와 클린 코드 원칙:**
+    *   React의 함수형 컴포넌트에도 SOLID 원칙이 적용됩니다. 단일 책임 원칙(SRP)에 따라 하나의 컴포넌트는 한 가지 일만 해야 하며, 300줄이 넘어가는 컴포넌트는 더 작은 단위로 분리해야 합니다 [13, 14]. 
+    *   KISS 원칙에 따라 복잡성보다 단순함을 추구하되, DRY 원칙을 지키기 위해 중복되는 로직은 커스텀 훅으로 추출합니다 [15, 16]. 단, 너무 이른 추상화는 코드를 더 읽기 어렵게 만들 수 있으므로 패턴이 3번 이상 반복될 때 추상화하는 것이 좋습니다 [15].
+*   **확장 가능한 상태 관리 전략:**
+    *   상태는 로컬 UI 상태, 전역 애플리케이션 상태, 서버 캐시 상태, URL 상태로 엄격히 파편화하여 관리해야 합니다 [17, 18]. 모든 데이터를 Redux와 같은 단일 스토어에 넣는 과거 방식에서 벗어나, 서버 데이터는 TanStack Query를 통해 캐싱하고 UI 상태는 Zustand 등을 사용합니다 [17, 18].
+    *   React의 내장 Context API는 값이 바뀔 때마다 해당 컨텍스트를 구독하는 모든 컴포넌트가 리렌더링되는 문제(Re-render storm)가 있어 빈번하게 변하는 상태에는 적합하지 않습니다 [19, 20].
+    *   대규모 팀(10명 이상)이나 복잡한 비동기 작업이 많은 환경에서는 일관된 패턴을 강제하는 Redux(RTK)가 여전히 강력하며, 중소규모 팀에서는 보일러플레이트가 적고 셀렉터(Selector)를 통해 불필요한 렌더링을 막아주는 Zustand가 적합합니다 [6, 21, 22].
+*   **일관된 명명 규칙(Naming Conventions):**
+    *   운영체제(Windows, macOS, Linux) 간 대소문자 구분 차이로 인한 CI/CD 빌드 실패를 방지하기 위해 파일 및 폴더 이름은 주로 `kebab-case`를 사용합니다 [23-25].
+    *   React 컴포넌트는 `PascalCase`로 작성하며, 변수나 함수, 커스텀 훅은 `camelCase`를 사용합니다 [26, 27].
+*   **성능 최적화와 안정성:**
+    *   대규모 번들 사이즈를 줄이기 위해 Vite의 `manualChunks`를 이용한 벤더 코드 스플리팅과, `React.lazy` 및 Suspense를 활용한 라우트 기반 코드 스플리팅이 필수적입니다 [28-32].
+    *   전체 애플리케이션이 충돌하는 것을 방지하기 위해 Error Boundary를 위젯이나 기능 단위로 선별적으로 배치하여 안전한 Fallback UI를 제공해야 합니다 [33, 34].
+
+## ⚖️ Trade-offs & Caveats
+*   **FSD 등 엄격한 아키텍처 도입의 오버헤드:** Feature-Sliced Design은 구조적 안정성을 주지만 진입 장벽이 높습니다. 개발자는 특정 모듈이 'feature'에 속하는지 'widget'에 속하는지 분류하는 의미론적 고민에 많은 시간을 쓸 수 있습니다 [35]. 무작정 초기부터 쪼개기 시작하면 3개면 충분했을 슬라이스가 수백 개로 불어나는 과잉 엔지니어링이 발생할 수 있습니다 [36].
+*   **Barrel Files(`index.ts`)의 한계:** FSD에서 캡슐화를 위해 권장하는 Barrel 파일 패턴은 내부 리팩토링을 쉽게 만들지만, 번들링 과정에서 트리 쉐이킹(Tree-shaking) 성능을 떨어뜨리거나 순환 참조 디버깅을 어렵게 만드는 단점이 존재합니다 [35].
+*   **상태 관리 도구의 딜레마:** Context API는 서드파티 종속성이 없는('Zero cost') 장점이 있지만 성능 저하의 주범이 될 수 있습니다 [19, 37]. 반면 Zustand는 유연하고 가벼우나 명확한 컨벤션을 강제하지 않아 대규모 팀에서는 코드가 중구난방(Store soup)이 될 위험이 있습니다 [21, 38]. Redux는 디버깅(Time-travel)과 팀 컨벤션 통일에 탁월하지만 보일러플레이트로 인한 개발 속도 저하를 감수해야 합니다 [6, 39, 40].
+*   **메모이제이션의 비용:** `React.memo`, `useCallback`, `useMemo`를 사용한 렌더링 최적화는 공짜가 아닙니다. 이전 props와 새로운 props를 비교하는 과정 자체에 비용이 들며, 컴포넌트 렌더링 속도보다 비교 연산이 더 오래 걸리거나 얕은 비교(Shallow comparison)의 한계로 인해 오히려 성능이 악화되는 부작용이 발생할 수 있습니다 [41-43]. React Compiler가 이 과정을 자동화해 주지만, 블랙박스로 동작하여 성능 디버깅이 더 어려워지며 일부 라이브러리(불안정한 참조를 반환하는 훅 등)와의 호환성 문제가 생깁니다 [44, 45].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [아키텍처/기반 기술]
+- [[Feature-Sliced Design]]
+  - 연결 이유: 대규모 React 애플리케이션의 복잡성을 관리하기 위한 현대적인 프론트엔드 아키텍처 방법론입니다 [10, 46].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 모듈의 스코프를 나누는 방법, 단방향 의존성 규칙, 그리고 컴포넌트를 비즈니스 도메인 단위로 캡슐화하는 원리를 이해할 수 있습니다 [5, 11].
+- [[SOLID 원칙]]
+  - 연결 이유: OOP의 원칙이지만 React 함수형 프로그래밍에 맞게 변형 적용되어 컴포넌트의 책임과 분리 기준을 제시합니다 [7, 47].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 거대한 컴포넌트를 쪼개는 기준(SRP)과 불필요한 prop 전달을 피하는 방법(ISP) 등을 학습할 수 있습니다 [13, 48].
+
+#### [구현/활용 도구]
+- [[Zustand]]
+  - 연결 이유: Context API의 리렌더링 문제를 해결하면서도 Redux보다 낮은 도입 비용으로 전역 상태를 관리할 수 있는 도구입니다 [39, 49].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: Selector 패턴을 통해 컴포넌트가 구독하는 상태 슬라이스만 변경될 때 렌더링을 트리거하는 성능 최적화 메커니즘을 배울 수 있습니다 [18, 22].
+- [[TanStack Query]]
+  - 연결 이유: UI 앱 상태와 서버 데이터 상태를 분리하는 모던 프론트엔드 아키텍처의 핵심 도구입니다 [18, 50].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 데이터 캐싱, 중복 요청 제거, 무한 스크롤 및 낙관적 업데이트 등 비동기 서버 상태를 별도로 관리하는 전략을 이해할 수 있습니다 [18, 50].
+- [[Code Splitting]]
+  - 연결 이유: 거대한 JavaScript 번들로 인해 초기 로딩 속도가 느려지는 문제를 해결하는 핵심 성능 최적화 기법입니다 [29, 51].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: `React.lazy`와 Suspense를 통한 라우트별 로딩 처리 및 Vite의 `manualChunks`를 활용한 벤더 라이브러리 캐싱 전략을 알 수 있습니다 [30-32].
+
+### Deeper Research Questions
+
+- Feature-Sliced Design(FSD)에서 Feature와 Widget의 경계를 결정하는 명확한 기준은 무엇이며, 인증(Auth)과 같이 여러 도메인에 걸친 교차 절단 관심사(Cross-cutting concerns)는 어느 레이어에 배치해야 하는가?
+- React의 내장 Context API가 야기하는 불필요한 리렌더링 문제를 Zustand의 셀렉터(Selector) 패턴은 내부적으로 어떻게 감지하고 해결하는가?
+- React Compiler가 도입됨에 따라 기존의 수동 메모이제이션(`useMemo`, `useCallback`, `React.memo`)에 의존하던 성능 최적화 패러다임은 어떻게 변화하며, 레거시 프로젝트 리팩토링 시 어떤 제약 사항이 있는가?
+- 10명 이상의 대규모 개발팀에서 상태 관리 아키텍처(Zustand vs Redux)를 선택할 때, 애플리케이션의 비동기 처리 복잡도와 디버깅 요구사항은 어떠한 영향을 미치는가?
+- Vite 기반의 번들링 환경에서 `manualChunks`를 활용한 코드 분할 시, 초기 렌더링 성능(Core Web Vitals)에 미치는 구체적인 영향과 캐싱 전략은 무엇인가?
+
+### Practical Application Contexts
+
+- **Implementation:** 거대한 `components/` 폴더 대신 `features/auth/`, `features/checkout/`과 같이 폴더를 구성하고, 해당 기능에 필요한 UI 컴포넌트, API 호출 훅, 타입을 폴더 내부에 캡슐화하여 구현합니다.
+- **System Design:** 애플리케이션 계층을 `app`, `pages`, `features`, `entities`, `shared`로 나누고, 상위 계층만 하위 계층을 import 할 수 있도록 ESLint 규칙을 설정하여 순환 참조를 방지하는 시스템을 설계합니다.
+- **Operation / Maintenance:** 프로덕션 환경에서는 Error Boundary를 폼이나 서드파티 위젯 등에 씌워 특정 기능이 다운되어도 전체 화면이 백화되는 것을 막고, Sentry나 LogRocket과 연동하여 세션 리플레이 및 에러 로그를 수집합니다.
+- **Learning Path:** 소규모 프로젝트에서 React Context API로 시작하여 한계(리렌더링 폭탄)를 경험한 후, Zustand를 학습하고, 궁극적으로 복잡한 비즈니스 요건을 다룰 때 Redux와 구조적 패턴, 그리고 FSD를 도입하는 방향으로 아키텍처 학습을 진행합니다.
+- **My Project Relevance:** 코드베이스가 거대해져 컴포넌트와 훅을 찾기 어려워졌을 때, 기존의 기술 스택 중심 폴더를 기능(Feature) 도메인 구조로 리팩토링하고 `index.ts`를 활용하여 모듈 간 강결합을 끊어낼 수 있습니다.
+
+### Adjacent Topics
+
+- [[Micro-Frontends]]
+  - 확장 방향: 단일 페이지 애플리케이션(SPA)의 규모가 지나치게 커졌을 때, 도메인별로 완전히 독립된 팀 단위 저장소와 배포 파이프라인을 구축하는 엔터프라이즈급 확장 아키텍처로 연구를 진행할 수 있습니다.
+- [[React Compiler]]
+  - 확장 방향: 구조적 아키텍처를 넘어, 개발자가 수동으로 적용하던 렌더링 최적화 로직을 빌드 타임에 컴파일러가 어떻게 자동 캐싱(Memoization)하는지에 대한 동작 원리와 한계점을 탐구할 수 있습니다.
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/레거시 React 코드베이스 마이그레이션.md b/00_Raw/레거시 React 코드베이스 마이그레이션.md
new file mode 100644
index 00000000..42133bab
--- /dev/null
+++ b/00_Raw/레거시 React 코드베이스 마이그레이션.md	
@@ -0,0 +1,66 @@
+# [[레거시 React 코드베이스 마이그레이션]]
+
+## 📌 Brief Summary
+레거시 React 코드베이스 마이그레이션(리팩토링)은 오래된 React 애플리케이션의 아키텍처, 상태 관리, 컴포넌트 구조 등을 최신 표준과 베스트 프랙티스에 맞게 개선하는 과정입니다 [1, 2]. 이 과정은 단순히 구식 코드를 수정하는 것을 넘어, 유닛 테스트를 통한 안정성 확보, 클래스형 컴포넌트에서 함수형/훅(Hook)으로의 전환, 그리고 점진적인 아키텍처 개편을 포함합니다 [2, 3]. 궁극적인 목표는 시스템의 결합도를 낮추고 유지보수성 및 확장성을 높여 누적된 기술 부채를 해결하는 것입니다 [1, 4].
+
+## 📖 Core Content
+*   **마이그레이션 준비 및 기본 원칙**: 
+    리팩토링을 시작하기 전 가장 먼저 수행해야 할 작업은 기존 기능이 깨지지 않도록 보장하는 유닛 테스트(Unit Test)를 작성하는 것입니다 [3, 5, 6]. 애플리케이션이 매우 작다면 처음부터 새로 작성하는 것이 나을 수도 있으나 [7], 일반적으로는 전면 재작성(Rewrite)보다는 점진적으로 개선하는 "리팩토링(Refactor, do not rewrite)" 철학을 따르는 것이 권장됩니다 [1].
+*   **컴포넌트 및 언어 현대화**: 
+    자바스크립트(JS)로 작성된 코드라면 타입스크립트(TS)로 업데이트하여 정적 타이핑을 적용합니다 [2, 8]. 또한, 레거시 클래스 기반 컴포넌트는 함수형 컴포넌트와 훅(Hooks)으로 마이그레이션해야 하며, 라이프사이클에 묶여 있던 불필요한 `useEffect` 사용을 식별하고 제거해야 합니다 [2].
+*   **상태 관리(State Management) 리팩토링**: 
+    과거의 방대한 Redux 스토어나 비효율적인 Context API 사용을 목적에 맞게 분리해야 합니다 [2, 9, 10]. 서버 상태(API 데이터)는 TanStack Query와 같은 라이브러리로 분리하여 관리하고, 전역 클라이언트 상태는 Zustand나 Context로 분리하며, 지역 상태는 컴포넌트 내부로 국한시키는 작업이 필요합니다 [2]. 이 과정 역시 한 번에 변경하기보다는 단일 스토어 단위(예: 알림 기능부터 시작해 체크아웃 플로우로 이동)로 점진적 마이그레이션을 진행합니다 [1].
+*   **아키텍처 및 폴더 구조 개편**: 
+    기존에 파일 타입별(예: components, hooks)로 나뉘어 있던 구조를 비즈니스 도메인이나 기능별(Feature-based) 구조로 개편합니다 [11, 12]. 더 나아가 Feature-Sliced Design(FSD) 같은 계층적 아키텍처를 도입하여 각 모듈의 응집도를 높이고 모듈 간 의존성을 단방향으로 제한합니다 [13, 14].
+*   **클린 코드와 스타일링 일관성 확보**: 
+    방대한 컴포넌트 내부의 데이터 페칭이나 비즈니스 로직은 커스텀 훅(Custom Hooks)으로 추출하여 모듈화합니다 [15, 16]. 여러 가지 CSS 방식(인라인 스타일, 외부 CSS, sx 등)이 혼재되어 있다면 하나로 표준화하여 일관성을 맞추고, ESLint 등의 도구를 도입하여 코드 린팅을 강제합니다 [6, 17-19].
+
+## ⚖️ Trade-offs & Caveats
+*   **전면 재작성(Rewrite) vs 점진적 마이그레이션**: 전면 재작성은 새로운 설계로 깨끗하게 코드를 짤 수 있다는 장점이 있으나, 시간 비용이 크고 기존의 비즈니스 로직 누락이라는 심각한 리스크가 있습니다 [1, 7]. 반면 점진적 리팩토링은 비교적 안전하지만, 과도기 동안 레거시 상태 관리(예: Context API)와 새로운 상태 관리(예: Zustand)가 공존하게 되어 구조적 복잡성이 일시적으로 증가할 수 있습니다 [1].
+*   **타입스크립트(TypeScript) 도입의 한계**: JS 코드를 TS로 전환하는 것은 안정성을 크게 높이지만, 팀원의 숙련도에 따라 인지적 오버헤드와 복잡성을 유발할 수 있습니다. 따라서 경험이 부족한 팀이라면 무리하게 한 번에 적용하기보다 점진적 채택이 필요합니다 [8].
+*   **추상화의 부작용**: DRY(Don't Repeat Yourself) 원칙을 극단적으로 추구하여 공통 로직을 무리하게 추상화하면, 코드가 지나치게 복잡해져 KISS(Keep It Simple, Stupid) 원칙에 위배됩니다 [20]. 잘못 추상화된 코드는 오히려 향후 변경을 어렵게 만들 수 있으므로 패턴이 세 번 이상 반복될 때까지 기다렸다가 추상화하는 것이 좋습니다 [20, 21].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [아키텍처/기반 기술]
+- [[Feature-Sliced Design]]
+  - 연결 이유: 레거시 구조의 파편화된 코드들을 논리적으로 재배치하고 향후 확장이 가능한 폴더 구조로 개편할 때 활용되는 현대적인 프론트엔드 아키텍처론입니다 [13, 14].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 기능, 엔티티, 위젯 등으로 계층을 나누고 단방향 의존성 및 명시적 Public API를 설정하여 코드의 결합도를 낮추는 원리 [13, 14, 22].
+
+- [[점진적 마이그레이션 (Incremental Migration)]]
+  - 연결 이유: 대규모 레거시 시스템을 안전하게 리팩토링하기 위한 핵심 실행 전략입니다 [1].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 새로운 기술(예: Zustand)을 도입할 때 전체를 재작성하지 않고, 알림 기능 등 독립적이고 작은 스토어부터 시작해 점진적으로 전환하는 리스크 관리 방법 [1].
+
+#### [구현/활용 도구]
+- [[커스텀 훅 (Custom Hooks)]]
+  - 연결 이유: 비대해진 레거시 컴포넌트 내부에서 비즈니스 로직과 UI 렌더링 로직을 분리해내는 핵심적인 리팩토링 단위입니다 [15, 16].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 로직(예: `useFetch`, `useForm`)을 분리함으로써 개별 유닛 테스트가 용이해지고 컴포넌트의 책임을 단일화하는 원리 [15].
+
+- [[TanStack Query (React Query)]]
+  - 연결 이유: 기존 레거시 앱에서 Redux나 Context API로 억지로 관리하던 API 응답 데이터를 분리해내기 위한 서버 상태 관리 도구입니다 [2, 10, 23].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 클라이언트 상태와 서버 상태를 명확히 분리함으로써 보일러플레이트를 줄이고 데이터 동기화를 자동화하는 방식 [10, 23].
+
+### Deeper Research Questions
+- 레거시 Context API에서 Zustand 등 다른 상태 관리 라이브러리로 점진적으로 마이그레이션할 때, 두 상태 시스템 간의 데이터 동기화 이슈는 어떻게 방지할 수 있는가?
+- TypeScript가 전혀 적용되지 않은 방대한 JavaScript 코드베이스에 TS를 도입할 때 가장 리스크가 적고 효율적인 점진적 적용(incremental adoption) 전략은 무엇인가?
+- 리팩토링 과정에서 기존 기능을 유지하고 있음을 증명하기 위해, 유닛 테스트와 시각적 회귀 테스트(Visual Regression Testing) 중 어느 것을 먼저 도입하는 것이 효과적인가?
+- 비즈니스 로직이 뷰(View)에 강하게 결합된 레거시 컴포넌트를 커스텀 훅으로 추출할 때 발생하는 의존성(props, state) 얽힘 문제는 어떤 패턴으로 해결할 수 있는가?
+- Feature-Sliced Design(FSD) 아키텍처로 개편 시, 여러 기능(Feature)에서 공통으로 교차되는 관심사(Cross-cutting concerns, 예: 인증 로직)는 어느 계층에 어떻게 배치해야 결합도를 최소화할 수 있는가?
+
+### Practical Application Contexts
+- **Implementation:** 클래스 컴포넌트의 복잡한 라이프사이클 메서드를 분석하여 함수형 컴포넌트의 훅(`useState`, `useEffect`)으로 1:1 대응 변환하고, 렌더링 최적화 로직을 재구성하는 코딩 작업 [2].
+- **System Design:** 단순히 컴포넌트, 훅, 스타일 단위로 분리되어 있던 폴더 구조를 분석하여 비즈니스 도메인(Auth, Dashboard 등) 단위로 재설계 및 디렉터리 구조 개편 [11, 12].
+- **Operation / Maintenance:** ESLint 및 Prettier와 함께 Git 훅(Husky 등)을 구축하여, 향후 새로 작성되는 코드가 레거시 패턴(구식 라이브러리 사용, CSS 혼재)으로 되돌아가지 않도록 코드 컨벤션을 자동화하여 유지보수 [19, 24].
+- **Learning Path:** 소규모 장난감(toy) 앱에서 먼저 TypeScript와 Custom Hooks 분리를 연습한 뒤, 레거시 코드베이스의 작은 컴포넌트부터 유닛 테스트를 작성해가며 점진적으로 규모를 키우는 실무 학습 방향 [5, 25].
+- **My Project Relevance:** 유지보수 기간이 오래되어 기술 부채가 쌓인 React 프로젝트를 인수받았을 때, 시스템의 중단 없이 코드 품질과 성능을 최신 기준에 맞게 현대화(Modernization)해야 하는 실무 환경에 직접 적용.
+
+### Adjacent Topics
+- [[클린 코드 (Clean Code)와 SOLID 원칙]]
+  - 확장 방향: 리팩토링 시 컴포넌트의 단일 책임 원칙(SRP)과 개방-폐쇄 원칙(OCP)을 준수하여 가독성과 확장성을 높이는 일반적인 소프트웨어 공학 설계 패턴 탐구.
+- [[프론트엔드 테스팅 (Frontend Testing)]]
+  - 확장 방향: 마이그레이션 과정에서 기존 기능이 훼손되지 않도록 보장하기 위해 Storybook 기반 UI 테스트나 Jest, Cypress 등을 활용한 테스트 커버리지 확보 전략 조사.
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/웹 성능 최적화(Core Web Vitals) 개선 작업.md b/00_Raw/웹 성능 최적화(Core Web Vitals) 개선 작업.md
new file mode 100644
index 00000000..a40df2ec
--- /dev/null
+++ b/00_Raw/웹 성능 최적화(Core Web Vitals) 개선 작업.md	
@@ -0,0 +1,80 @@
+# [[웹 성능 최적화(Core Web Vitals) 개선 작업]]
+
+## 📌 Brief Summary
+웹 성능 최적화(Core Web Vitals) 개선 작업은 사용자에게 빠르고 안정적인 웹 경험을 제공하기 위해 애플리케이션의 체감 속도와 안정성을 향상시키는 과정입니다 [1-3]. 주로 최대 콘텐츠 풀 페인트(LCP), 다음 페인트에 대한 상호작용(INP), 누적 레이아웃 이동(CLS), 최초 입력 지연(FID)과 같은 표준 성능 지표를 측정하고 최적화합니다 [1-3]. 이를 달성하기 위해 자바스크립트 번들 크기 축소, 불필요한 렌더링 방지, 리소스 로딩 우선순위 지정 및 서버 측 렌더링 도입 등의 기술이 활용됩니다 [4-6].
+
+## 📖 Core Content
+* **핵심 성능 지표 (Core Web Vitals) 이해 및 모니터링:** 
+  성능 최적화는 측정에서 시작됩니다. 사용자 경험을 나타내는 핵심 지표로는 LCP(시각적 로딩 완료 시간), FID 및 INP(입력 반응성), CLS(시각적 안정성), FCP(최초 콘텐츠 풀 페인트), TBT(총 차단 시간) 등이 있습니다 [2, 3]. 이러한 지표들은 Lighthouse, Web Vitals JS, SigNoz, DebugBear 같은 실제 사용자 모니터링(RUM) 도구와 Chrome DevTools를 통해 지속적으로 추적해야 합니다 [2, 7-10].
+* **번들 크기 축소 및 코드 분할 (Code Splitting):** 
+  대규모 자바스크립트 페이로드는 LCP와 INP 지표를 악화시킵니다 [11, 12]. Vite의 `manualChunks`를 사용하여 React 코어와 같은 무거운 벤더 라이브러리를 캐싱 가능한 개별 파일로 분리해야 합니다 [13-15]. 또한, `React.lazy()`와 `Suspense`를 활용하여 라우트(Route) 또는 무거운 컴포넌트(차트 등)를 사용자가 필요로 할 때만 동적으로 로드(Lazy Loading)함으로써 초기 번들 크기를 20~70%까지 줄일 수 있습니다 [12, 15-18].
+* **렌더링 성능 최적화 (메모이제이션):** 
+  불필요한 리렌더링은 메인 스레드를 차단하여 애플리케이션을 느리게 만듭니다 [19]. 이를 방지하기 위해 `React.memo()`, `useCallback`, `useMemo`를 전략적으로 사용하여 참조 안정성을 확보하고 렌더링 비용을 줄여야 합니다 [20-22]. 최신 React 환경에서는 빌드 시점에 코드를 분석하여 자동으로 메모이제이션을 추가하는 'React Compiler'를 도입하면 수동 메모이제이션의 복잡성 없이 INP 지표를 크게 개선할 수 있습니다 [13, 23-25]. JSX 내에서 익명 함수 사용을 지양하는 것도 불필요한 리렌더링을 막는 방법입니다 [26, 27].
+* **리스트 가상화 (Virtualization):**
+  수천 개의 항목을 렌더링해야 하는 목록은 DOM 비대화를 유발하여 스크롤링 시 메인 스레드를 지연시킵니다(INP 저하) [28, 29]. `react-window`와 같은 라이브러리를 사용하여 뷰포트에 보이는 항목만 렌더링하는 '가상화(Windowing)' 기법을 적용해야 합니다 [29-31].
+* **동시성 렌더링 및 비동기 UI 제어 (Concurrent Features):**
+  React 18 이상에서는 `useTransition`을 사용해 무거운 상태 업데이트를 지연시키고 긴급한 사용자 상호작용(타이핑, 클릭 등)을 우선 처리할 수 있습니다 [32-34]. 또한, `useDeferredValue`를 사용하여 렌더링 비용이 높은 데이터의 반영을 지연시킴으로써 UI의 반응성을 부드럽게 유지할 수 있습니다 [35].
+* **Next.js React 서버 컴포넌트 (RSC) 활용:**
+  Next.js 환경에서는 상호작용이 필요 없는 정적 UI를 서버 컴포넌트로 분리하여 서버에서 렌더링해야 합니다 [20, 36, 37]. 이를 통해 클라이언트로 전송되는 자바스크립트 크기를 줄이고, 하이드레이션(Hydration) 시간을 단축하여 초기 페인트(FCP) 및 상호작용 도달 시간(TTI) 성능을 대폭 끌어올릴 수 있습니다 [37, 38].
+* **리소스 로딩 우선순위 및 이미지 최적화:**
+  중요한 렌더링 경로(Critical Rendering Path)를 최적화하기 위해 비동기적으로 스크립트를 로드(`async`, `defer`)해야 합니다 [5, 16]. 이미지는 WebP나 AVIF 같은 최신 압축 포맷을 사용하고, 스크롤 아래에 있는 이미지는 `loading="lazy"` 속성을 통해 지연 로딩하며, 핵심 이미지는 `fetchpriority`나 `preload`를 사용해 빠르게 로드해야 합니다 [8, 39, 40].
+
+## ⚖️ Trade-offs & Caveats
+* **메모이제이션의 오버헤드:** `React.memo()`, `useCallback`, `useMemo`는 이전 상태와 새로운 상태를 비교하는 과정을 수반합니다. 렌더링 비용이 매우 낮고 자주 업데이트되는 컴포넌트에 이를 남용할 경우, 메모이제이션 비교 비용이 실제 렌더링 비용보다 커져 오히려 성능을 저하시킬 수 있습니다 [41, 42].
+* **코드 분할(Code Splitting)의 한계:** 코드를 너무 작게 여러 개의 청크(Chunk)로 나누면, 브라우저가 수많은 네트워크 요청을 처리해야 하므로 또 다른 성능 병목이 발생할 수 있습니다. 벤더 라이브러리 캐싱과 초기 로드 속도 사이의 균형을 맞추는 정교한 `manualChunks` 관리가 필요합니다 [13-15, 43, 44].
+* **React Compiler의 디버깅 복잡성:** React Compiler는 코드를 자동으로 최적화해 주지만 블랙박스 형태로 동작하기 때문에, 의도치 않은 리렌더링이 발생했을 때 원인을 추적하고 디버깅하기가 훨씬 더 어려워질 수 있습니다 [45]. 또한 불안정한 참조를 반환하는 서드파티 라이브러리(`useMutation`, `useLocation` 등)와 함께 사용할 경우 호환성 문제가 생길 수 있습니다 [46, 47].
+* **서버 컴포넌트(Server Components)의 제약:** 클라이언트 측 JavaScript 페이로드를 줄이는 데 매우 효과적이지만, 상태(State), 생명주기 훅(`useEffect`), 브라우저 전용 API를 전혀 사용할 수 없습니다 [48]. 따라서 상호작용이 필요한 클라이언트 컴포넌트와 정적 서버 컴포넌트 간의 경계를 신중하게 설계해야 합니다 [48].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [구현/최적화 기법]
+- [[Code Splitting & Lazy Loading]]
+  - 연결 이유: 대용량의 자바스크립트 번들을 사용자가 필요로 하는 시점이나 라우트에 따라 분할하여 로드하는 핵심 기법입니다 [16, 18, 28].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 초기 페이지 로딩 시간 단축 원리와 Vite/Webpack의 번들링 구조, LCP 지표 향상 방법.
+- [[Virtualization (Windowing)]]
+  - 연결 이유: 대규모 데이터 리스트 렌더링 시 브라우저의 DOM 노드 생성 부담을 줄여줍니다 [29-31].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 메모리 소비 최소화 및 메인 스레드 차단 방지를 통한 INP(Interaction to Next Paint) 성능 개선 효과.
+- [[Memoization]]
+  - 연결 이유: React 애플리케이션 내의 불필요한 리렌더링 연산을 방지하여 런타임 성능을 유지하는 데 사용됩니다 [20, 21, 24].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 객체 참조의 안정성(Reference Equality)과 React의 가상 DOM 렌더링 사이클, React Compiler의 작동 원리.
+
+#### [아키텍처/기반 기술]
+- [[React Server Components]]
+  - 연결 이유: 클라이언트 측 JS 페이로드 크기를 원천적으로 줄여 하이드레이션 병목을 해결하는 현대 프론트엔드 최적화 아키텍처입니다 [36, 37].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 서버와 클라이언트 간의 데이터 페칭, 상호작용 분리 설계 및 TTI(Time to Interactive) 개선 과정.
+- [[Concurrent Rendering]]
+  - 연결 이유: `useTransition`, `useDeferredValue`를 사용하여 무거운 렌더링 작업을 지연시키고 중요한 사용자 인터랙션의 우선순위를 높일 수 있습니다 [32-34].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 브라우저 메인 스레드의 작업 큐(Queue) 관리와 애플리케이션의 체감 반응성 개선.
+
+#### [측정/모니터링 도구]
+- [[Real User Monitoring (RUM)]]
+  - 연결 이유: 합성 환경(Synthetic)이 아닌 실제 사용자의 디바이스와 네트워크 환경에서 발생하는 Core Web Vitals 지표를 수집하고 분석하기 위해 필수적입니다 [3, 8].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 데이터 기반 최적화 의사 결정 과정 및 프로덕션 환경에서의 성능 퇴행(Regression) 모니터링 방식.
+
+### Deeper Research Questions
+
+- React Compiler의 자동 메모이제이션은 기존 `useMemo`/`useCallback`을 활용한 수동 메모이제이션 방식과 비교하여 렌더링 최적화 로직의 세분화(Granularity) 측면에서 어떻게 다르게 동작하는가?
+- Next.js의 React 서버 컴포넌트(RSC)를 도입할 때, 전역 상태 관리(Global State Management) 라이브러리와 클라이언트의 고도화된 상호작용을 통합하는 과정에서 발생하는 아키텍처적 제약은 무엇인가?
+- Vite의 `manualChunks` 설정을 통해 동적 임포트를 구현할 때, 브라우저의 캐싱 전략과 연계하여 LCP 및 FCP를 극대화할 수 있는 청크 분할 단위의 최적 임계점은 어떻게 설정하는가?
+- Chrome DevTools의 Heap Snapshots 기능을 활용하여 분리된 DOM 노드(Detached DOM nodes)나 누수된 이벤트 리스너를 찾아내고, 이것이 장기적인 렌더링 성능에 미치는 영향을 해결하는 구체적인 프로세스는 무엇인가?
+- 상태 의존성이 얽혀 있는 복잡한 컴포넌트 트리에서 React Context API의 과도한 리렌더링 문제를 방지하기 위해 Zustand의 선택기(Selector) 패턴이 성능 최적화에 기여하는 원리는 무엇인가?
+
+### Practical Application Contexts
+
+- **Implementation:** React 애플리케이션의 라우팅 구조를 분석하여 `React.lazy()`와 `Suspense`를 통해 라우트별 코드 분할을 적용하고, 이미지 등 정적 리소스에 `loading="lazy"` 및 `fetchpriority` 속성을 도입하여 초기 번들 크기를 줄입니다.
+- **System Design:** 아키텍처 설계 단계부터 상호작용이 없는 정적 데이터 영역(예: 상품 목록, 아티클 본문 등)은 Next.js의 Server Components로 구성하고, 상호작용이 필수적인 부분(예: 장바구니 버튼, 필터)만 Client Components로 설계하여 자바스크립트 전송량을 최소화합니다.
+- **Operation / Maintenance:** 프로덕션 환경 배포 이후 SigNoz, DebugBear, Sentry 등의 모니터링 도구를 연동하여 실제 사용자들의 LCP, INP, CLS 데이터를 수집하고, 성능 예산(Performance Budgets)을 설정하여 성능 저하 여부를 지속해서 감시합니다.
+- **Learning Path:** 먼저 브라우저의 중요 렌더링 경로(Critical Rendering Path)를 이해한 후, React의 생명주기와 리렌더링 유발 원인을 학습하고, 마지막으로 동시성 렌더링(Concurrent Features)과 서버 사이드 최적화 기법을 숙지하는 순서로 지식을 확장합니다.
+- **My Project Relevance:** 과도하게 큰 메인 자바스크립트 청크로 인해 로딩이 느려지거나 사용자 인터랙션 시 버벅거림(Jank)이 발생하는 현재의 프로젝트에 즉각 적용하여 SEO 점수를 개선하고 사용자 이탈률을 방지하는 실질적인 문제 해결 지침으로 작용합니다.
+
+### Adjacent Topics
+
+- [[Memory Management & Leak Debugging]]
+  - 확장 방향: 자바스크립트 힙(Heap) 메모리와 가비지 컬렉션(GC)의 동작 원리를 파악하여, 분리된 DOM 노드나 클로저로 인해 발생하는 메모리 누수를 해결함으로써 장기적인 페이지 성능 저하를 방지하는 방법에 대한 연구 [49-51].
+- [[State Management Architecture]]
+  - 확장 방향: Context API가 초래하는 불필요한 전역 리렌더링의 한계를 파악하고, Zustand나 Jotai 등 필요한 상태 슬라이스만 구독(Subscribe)할 수 있는 가벼운 상태 관리 도구를 활용한 성능 보호 아키텍처 설계 [52-55].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/프론트엔드 리팩토링 및 코드 유지보수.md b/00_Raw/프론트엔드 리팩토링 및 코드 유지보수.md
new file mode 100644
index 00000000..5524db97
--- /dev/null
+++ b/00_Raw/프론트엔드 리팩토링 및 코드 유지보수.md	
@@ -0,0 +1,77 @@
+# [[프론트엔드 리팩토링 및 코드 유지보수]]
+
+## 📌 Brief 시 Summary
+프론트엔드 리팩토링 및 코드 유지보수는 애플리케이션의 기존 동작을 그대로 유지하면서 코드의 구조, 가독성, 확장성을 개선하는 지속적인 소프트웨어 공학 과정입니다 [1, 2]. 프로젝트가 성장함에 따라 얽혀있는 비즈니스 로직과 UI를 분리하고, 파일 유형이 아닌 도메인 또는 기능(Feature) 단위로 구조를 재편하여 아키텍처의 붕괴를 막는 것이 핵심입니다 [1, 3, 4]. 또한, SOLID나 DRY, KISS와 같은 설계 원칙을 적용하고, 자동화된 린팅(Linting)과 엄격한 Git 거버넌스를 통해 다수의 개발자가 협업하는 환경에서도 기술 부채를 최소화하고 안정적인 시스템을 유지하는 것을 목표로 합니다 [1, 5, 6].
+
+## 📖 Core Content
+*   **리팩토링의 준비와 테스트 의존성**
+    *   레거시나 다른 사람이 작성한 React 코드베이스를 리팩토링하기 전에는 반드시 유닛 테스트나 UI 테스트를 먼저 작성하여 기존 기능이 깨지지 않도록 보장해야 합니다 [2].
+    *   Storybook과 연동되는 시각적 회귀 테스트(Visual Regression Testing) 도구(예: Happo, Chromatic)를 활용하면, 리팩토링 과정에서 발생하는 의도치 않은 UI 레이아웃 변경이나 접근성 오류를 자동으로 식별할 수 있습니다 [7].
+    *   완전히 코드를 갈아엎는 재작성(Rewrite)보다는 한 번에 알림 기능이나 체크아웃 흐름 등 작은 스토어 단위로 기술을 교체하는 '점진적 마이그레이션(Incremental Migration)' 전략이 필수적입니다 [1].
+*   **아키텍처 및 폴더 구조의 현대화**
+    *   컴포넌트, 훅, 스타일 등을 단순히 기술적 파일 유형(Type-based)으로 묶는 폴더 구조는 프로젝트 규모가 커지면 유지보수를 극도로 어렵게 만듭니다 [1, 4].
+    *   2025년 기준 모범 사례는 코드를 기능(Feature) 단위로 묶는 것입니다. 특정 기능 내에 해당 기능만의 컴포넌트, API, 훅 등을 위치시켜 높은 응집도를 확보합니다 [1, 4].
+    *   더 나아가 **Feature-Sliced Design (FSD)** 같은 아키텍처론을 도입하여, 코드를 app, pages, widgets, features, entities, shared 계층으로 나누고, 상위 계층이 하위 계층에만 의존하게 하는 '단방향 의존성' 및 '단일 진입점(Public API)' 규칙을 강제하여 결합도를 낮출 수 있습니다 [1, 3].
+*   **코드 품질 및 설계 원칙(SOLID, DRY, KISS) 적용**
+    *   **단일 책임 원칙(SRP):** 300줄이 넘어가는 등 너무 많은 역할을 하는 대형 컴포넌트는 상태 관리, 데이터 페칭, 렌더링 역할을 분리하여 더 작고 집중된 컴포넌트로 리팩토링해야 합니다 [1, 6].
+    *   **로직의 추출과 재사용:** 반복되는 코드를 없애는 'DRY(Don't Repeat Yourself)' 원칙에 따라, 얽혀있는 복잡한 비즈니스 로직과 폼 처리 로직 등을 '커스텀 훅(Custom Hooks)'으로 분리해 리팩토링의 기본 단위로 삼습니다 [1, 6].
+    *   클래스형 컴포넌트 환경이라면 함수형 컴포넌트와 훅 기반으로 마이그레이션하고, 불필요한 `useEffect`를 제거하며, 타입스크립트(TypeScript)를 도입해 타입 안정성을 확보해야 합니다 [2]. 클라이언트 상태와 서버 상태를 분리해, 서버 데이터는 TanStack Query와 같은 전용 도구를 사용해 관리하는 것이 좋습니다 [1, 2].
+*   **유지보수를 위한 거버넌스와 표준화**
+    *   React 컴포넌트 파일 이름은 PascalCase, 일반 유틸리티나 훅은 camelCase, 폴더명은 운영체제 간 충돌을 막기 위해 kebab-case를 사용하는 등 일관된 네이밍 컨벤션을 확립해야 합니다 [1, 8].
+    *   팀 단위 유지보수를 위해 ESLint, Prettier, Husky를 조합하여 커밋이나 병합 전에 아키텍처 경계 위반(예: feature가 다른 feature를 임포트하는 행위)이나 코드 포맷팅을 자동으로 검사하고 수정해야 합니다 [1].
+    *   Git 브랜칭 시 짧은 생명주기를 가진 기능 브랜치(Feature Branch)를 운영하고, 'Conventional Commits' 규칙에 따라 의미 있는 커밋 메시지를 작성하며, 단일 책임에 맞는 작은 PR(Pull Request)을 생성하는 것이 핵심 유지보수 프랙티스입니다 [1, 5, 9].
+
+## ⚖️ Trade-offs & Caveats
+*   **추상화와 복잡성의 충돌 (DRY vs KISS):** 중복 코드를 줄이기 위해(DRY) 무리하게 재사용 가능한 추상화를 만들면, 오히려 코드를 이해하기 어려워져 KISS(Keep It Simple, Stupid) 원칙을 위배하게 됩니다. 소스 코드 패턴이 최소 3번 반복될 때까지 기다렸다가 추상화하는 것이 섣부른 최적화로 인한 부작용을 막는 방법입니다 [1, 6].
+*   **아키텍처 오버헤드:** Feature-Sliced Design(FSD)과 같이 엄격하게 분리된 계층 구조는 대규모 앱의 유지보수성에 탁월하지만, 소규모 프로젝트나 초보자에게는 폴더와 파일이 불필요하게 쪼개지고 개념적 오버헤드를 발생시켜 과도한 설계(Overkill)가 될 수 있습니다 [3, 4].
+*   **상태 관리 리팩토링의 반대 급부:** Context API에서 시작한 상태를 대규모 앱의 성능(리렌더링) 문제로 인해 Zustand나 Redux로 마이그레이션할 때 트레이드오프가 존재합니다. Zustand는 유연하지만 팀원마다 비동기 처리 패턴이 파편화될 위험이 있으며, Redux는 일관된 구조를 제공하지만 보일러플레이트(Boilerplate) 코드가 폭발적으로 증가하여 개발 속도를 저하시킬 수 있습니다 [10].
+*   **전면 재작성의 위험성:** 유지보수가 어려운 코드를 마주했을 때 전체 코드를 한 번에 재작성(Rewrite)하려는 시도는 실패할 확률이 매우 높습니다. 리팩토링은 비즈니스 기능 개발을 멈추지 않은 상태에서, 컴포넌트 및 스토어를 하나씩 '점진적(Incremental)'으로 수정해야만 리스크를 최소화할 수 있습니다 [1].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [관계 유형 A (아키텍처/기반 기술)]
+- [[Feature-Sliced Design (FSD)]]
+  - 연결 이유: 대규모 프론트엔드 프로젝트의 코드를 리팩토링할 때 기술 부채를 줄이기 위해 채택하는 최신 폴더 및 아키텍처 방법론입니다 [1, 3].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 앱을 레이어(app, pages, widgets, features, entities, shared)로 엄격히 나누고 단방향 의존성을 강제하여 코드 결합도를 낮추는 원리를 배울 수 있습니다.
+- [[SOLID 원칙]]
+  - 연결 이유: 리팩토링 시 컴포넌트와 모듈을 어떻게 나누고 구성할지 결정하는 가장 기초적인 소프트웨어 엔지니어링 철학입니다 [1, 6].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 단일 책임 원칙(SRP)을 통해 비대해진 컴포넌트를 분할하고, 개방-폐쇄 원칙(OCP)을 통해 기존 코드를 건드리지 않고 컴포넌트를 확장하는 방법을 이해할 수 있습니다.
+
+#### [관계 유형 B (구현/활용 도구)]
+- [[커스텀 훅 (Custom Hooks)]]
+  - 연결 이유: React 리팩토링에서 비즈니스 로직과 UI를 분리하고, DRY 원칙을 실현하는 가장 기본적인 단위이자 도구입니다 [1, 6].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 컴포넌트 내부에 산재한 상태 관리와 부수 효과(`useEffect`)를 어떻게 응집도 높은 독립적인 함수로 분리할 수 있는지 파악할 수 있습니다.
+- [[점진적 마이그레이션 (Incremental Migration)]]
+  - 연결 이유: 레거시 코드베이스를 개선할 때 시스템을 중단시키거나 위험한 '전체 재작성'을 피하기 위해 반드시 채택해야 하는 전략입니다 [1].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 알림이나 단순 상태 같은 작은 모듈부터 시작해 점진적으로 상태 관리 도구나 아키텍처를 교체해 나가는 구체적인 전환 절차를 이해할 수 있습니다.
+- [[시각적 회귀 테스트 (Visual Regression Testing)]]
+  - 연결 이유: 대규모 코드 구조를 변경하는 리팩토링 시, 기존 UI가 의도치 않게 깨지는 것을 방지하는 핵심 안전망입니다 [7].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: Storybook과 통합된 도구(예: Happo, Chromatic)를 통해 DOM 구조뿐만 아니라 실제 브라우저 렌더링 픽셀 차이를 감지하는 메커니즘을 배울 수 있습니다.
+
+### Deeper Research Questions
+
+- DRY 원칙과 KISS 원칙이 상충하는 상황에서, 프론트엔드 개발자가 리팩토링 시 추상화의 적절한 시점(예: Rule of Three)을 결정하는 구체적인 실무적 기준은 무엇인가?
+- 대규모 React 애플리케이션에서 Context API로 구축된 기존 상태 관리를 Zustand나 Redux로 점진적 마이그레이션(Incremental Migration)할 때 직면하는 기술적 장애물과 단계별 해결 전략은 무엇인가?
+- Feature-Sliced Design (FSD)을 도입하여 리팩토링할 때, 여러 기능(Feature)에서 공통으로 필요한 로직이 'Shared' 계층에 지나치게 비대해지는 문제를 어떻게 방지하고 조율할 수 있는가?
+- 레거시 React 코드베이스에 존재하는 다수의 불필요한 `useEffect`와 파편화된 서버 상태를 TanStack Query와 같은 도구로 리팩토링할 때, 기존 유닛 테스트 코드의 전략은 어떻게 수정되어야 하는가?
+- 다수의 프론트엔드 팀이 협업하는 환경에서 ESLint, Prettier, Husky를 활용해 FSD의 아키텍처 경계(단방향 의존성 등)와 네이밍 컨벤션을 자동화 및 강제하는 최적의 CI/CD 거버넌스 구성 방식은 무엇인가?
+
+### Practical Application Contexts
+
+- **Implementation:** 비대해진 React 컴포넌트를 마주했을 때 단일 책임 원칙(SRP)을 적용하여, UI 렌더링 로직은 그대로 두고 복잡한 상태 업데이트나 API 페칭 로직을 커스텀 훅으로 분리하는 리팩토링을 즉시 수행합니다 [1, 6].
+- **System Design:** 프로젝트 구조가 점점 혼란스러워지는 것을 막기 위해, 초기부터 파일 유형(components, hooks) 기반의 폴더 분류를 지양하고, Feature-Sliced Design(FSD)과 같은 도메인/기능 중심의 폴더 구조를 시스템의 뼈대로 설계합니다 [1, 3, 4].
+- **Operation / Maintenance:** 유지보수 과정에서 버그 픽스와 리팩토링 코드가 섞이지 않도록, 짧은 생명주기의 기능 브랜치를 사용하고 Conventional Commits를 도입하여 유지보수 이력(History)의 가독성을 높입니다 [5].
+- **Learning Path:** 리액트를 처음 배운 후, 단순히 코드를 작동하게 만드는 것을 넘어, 작성한 코드를 유닛 테스트(Unit Test)로 검증한 뒤 DRY, KISS, YAGNI 원칙에 따라 군더더기를 없애는 안전한 리팩토링 사이클을 훈련합니다 [2, 6].
+- **My Project Relevance:** 타인이 작성한 또는 오래된 레거시 코드를 인계받았을 때, 코드를 전면 재작성하지 않고 Storybook 등으로 시각적 테스트 안전망을 구축한 뒤 [7], 불필요한 상태 및 Effect를 점진적으로 정돈해 나가는 [2] 구체적인 가이드라인으로 활용할 수 있습니다.
+
+### Adjacent Topics
+
+- [[프론트엔드 성능 최적화 (Frontend Performance Optimization)]]
+  - 확장 방향: 리팩토링을 통해 코드의 가독성을 높이는 것을 넘어, 메모리 누수를 해결하거나(Chrome DevTools 활용), 불필요한 리렌더링 요소(React.memo, useCallback 오남용 등)를 찾아내어 애플리케이션의 런타임 성능을 개선하는 기법으로 학습을 확장합니다.
+- [[Git 브랜칭 및 협업 전략 (Git Branching & Workflow)]]
+  - 확장 방향: 리팩토링과 새로운 기능 개발이 동시에 일어나는 팀 환경에서, 코드 충돌을 최소화하고 리뷰 효율을 높이기 위한 Trunk-based Development, GitHub Flow 등 실무적 협업 워크플로우로 이해를 넓힙니다.
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/프론트엔드 클라우드 로깅 도구 도입 및 프로덕션 모니터링.md b/00_Raw/프론트엔드 클라우드 로깅 도구 도입 및 프로덕션 모니터링.md
new file mode 100644
index 00000000..a60b2510
--- /dev/null
+++ b/00_Raw/프론트엔드 클라우드 로깅 도구 도입 및 프로덕션 모니터링.md	
@@ -0,0 +1,69 @@
+# [[프론트엔드 클라우드 로깅 도구 도입 및 프로덕션 모니터링]]
+
+## 📌 Brief 정량 Summary
+프론트엔드 클라우드 로깅 및 프로덕션 모니터링은 실제 사용자의 브라우저 환경에서 발생하는 에러, 성능 문제, 사용자 상호작용을 실시간으로 추적하고 분석하는 과정입니다 [1], [2], [3]. 단순한 `console.log`로는 파악하기 힘든 다양한 디바이스와 네트워크 조건의 버그를 지능형 에러 그룹화, 세션 리플레이, 엔드투엔드 트레이싱 등의 기능으로 가시화합니다 [2], [4], [5]. Sentry, LogRocket, Datadog, SigNoz 등의 도구를 통해 프론트엔드 애플리케이션의 복원력을 높이고 장애를 신속하게 해결할 수 있습니다 [6], [7], [3].
+
+## 📖 Core Content
+*   **프론트엔드 로깅의 필요성 향상**
+    최신의 웹 애플리케이션은 방대한 환경(브라우저, 디바이스, 네트워크 등)에서 실행되므로, 단순한 `console.log`나 사용자의 스크린샷만으로는 프로덕션 환경의 에러 근본 원인을 파악하기 불가능에 가깝습니다 [1], [2].
+*   **주요 모니터링 도구 및 특징**
+    *   **Sentry:** 개발자 친화적인 에러 추적 도구로, 지능형 에러 그룹화(Intelligent error grouping)를 통해 중복 에러 노이즈를 줄여줍니다 [4], [3]. 에러 발생 전까지의 콘솔 로그, 네트워크 요청, 사용자 상호작용을 보여주는 '브레드크럼(Breadcrumb)'을 제공합니다 [4].
+    *   **LogRocket:** 세션 리플레이(Session Replay) 기능의 선구자로, DOM, Redux/Vuex 상태 변화, 네트워크 요청 및 성능 지표 등 사용자의 전체 세션을 녹화하듯 캡처하여 복잡한 디버깅에 탁월한 컨텍스트를 제공합니다 [8], [9].
+    *   **Datadog RUM:** 프론트엔드 에러를 백엔드 서비스, 데이터베이스, 서드파티 API까지 연결하여 추적할 수 있는 엔드투엔드(End-to-End) 분산 트레이싱을 제공하여, 복잡한 분산 시스템 디버깅에 강력합니다 [5].
+    *   **New Relic Browser:** 엔터프라이즈급 올인원 모니터링 플랫폼으로 프론트엔드, 백엔드 APM, 인프라 로깅을 한 곳에서 지원합니다 [10].
+    *   **Grafana Frontend Observability & SigNoz:** 벤더 종속성이 없는 OpenTelemetry 개방형 표준을 기반으로 합니다 [11], [12]. 특히 SigNoz는 프론트엔드 로그와 백엔드 트레이스를 연결하여 통합된 옵저버빌리티(Unified Observability)를 제공합니다 [12], [13].
+*   **에러 바운더리와의 결합을 통한 복원력 확보**
+    성공적인 프로덕션 모니터링은 사후 분석뿐만 아니라 런타임 실패에 대한 사전 방어와 결합됩니다. React의 Error Boundaries를 사용하여 단일 컴포넌트의 결함으로 전체 앱이 크래시되는 것을 막고, Sentry 등과 연동하여 에러를 즉각적으로 모니터링 도구에 보고할 수 있습니다 [14], [3], [15], [16].
+
+## ⚖️ Trade-offs & Caveats
+*   **성능 영향 (Performance Impact):** 프론트엔드 모니터링 도구의 SDK는 번들 사이즈를 증가시켜 로드 시간에 영향을 줍니다 [17], [18]. 일부 도구는 최대 120ms의 추가 로딩 시간을 발생시키므로, 매초가 중요한 e-커머스 사이트 등에서는 가벼운 도구 선택이 필수적입니다 [7].
+*   **개인정보 보호 문제 (Privacy Concerns):** LogRocket과 같이 사용자의 모든 화면과 상태를 기록하는 "전체 캡처(capture everything)" 방식은 민감한 데이터를 수집할 위험이 매우 큽니다 [9], [18]. 따라서 민감 정보를 마스킹하기 위한 보안/프라이버시 설정에 상당한 시간이 소요됩니다 [9], [19].
+*   **비용 및 스케일링 (Pricing Reality Check):** 다수의 SaaS 도구들은 트래픽 규모에 따라 비용이 기하급수적으로 증가합니다. 특히 Datadog은 로그 '수집(Ingest)'과 '색인(Index)'을 별도로 청구하는 '이중 요금제(two-part tariff)'를 사용하여, 비용 절감을 위해 일부 로그만 색인화하게 만들고 정작 중요할 때 디버깅 데이터를 찾지 못하게 하는 딜레마를 초래할 수 있습니다 [20], [21].
+*   **도입 및 설정 복잡성:** OpenTelemetry 기반 도구(Grafana, SigNoz)는 장기적인 유연성과 벤더 종속성 탈피의 장점이 있으나, Sentry 등 목적 기반 특화 도구에 비해 초기 학습 곡선이 가파르고 자체 호스팅 시 DevOps 전문 지식이 요구됩니다 [22], [23], [19].
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [관계 유형 A (아키텍처 및 원리)]
+- [[Session Replay]]
+  - 연결 이유: 단순한 에러 로그를 넘어 DOM, 상태 변경, 네트워크 요청 등 사용자의 전체 상호작용을 녹화하여 시각적으로 버그 발생 순간을 제공하는 핵심 모니터링 기술입니다 [24], [8], [9], [3].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 프론트엔드 로깅이 사용자의 UI/UX와 컴포넌트 생명주기(Lifecycle) 상의 데이터를 어떻게 캡처하고 활용하는지 이해할 수 있습니다 [24], [9].
+- [[End-to-End Tracing]]
+  - 연결 이유: 프론트엔드의 특정 에러가 단순 클라이언트 문제가 아닌 백엔드 API, 데이터베이스 등과 어떻게 연관되는지 식별해주는 기능입니다 [5], [25], [12].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: Datadog이나 SigNoz와 같은 풀스택 옵저버빌리티 도구가 시스템 전체의 성능 병목을 어떻게 진단하는지 파악할 수 있습니다 [5], [12].
+- [[OpenTelemetry]]
+  - 연결 이유: 특정 벤더에 종속되지 않고 애플리케이션의 텔레메트리(로그, 메트릭, 트레이스)를 표준화된 방식으로 수집하는 오픈 아키텍처입니다 [11], [12], [13].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 최신 프론트엔드 모니터링 생태계에서 유연성(Flexibility)을 유지하면서 확장성 있는 데이터 수집 파이프라인을 구축하는 원리를 이해할 수 있습니다 [11], [13].
+
+#### [관계 유형 B (오류 제어 및 성능 최적화 도구)]
+- [[Error Boundaries]]
+  - 연결 이유: 로깅 도구가 에러를 '수집'하는 역할이라면, Error Boundaries는 런타임 에러 발생 시 UI 전체의 크래시를 방지하고 fallback UI를 띄우는 '방어' 역할을 합니다 [14], [26], [15].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: Sentry 등과 결합하여 프로덕션에서 애플리케이션의 탄력성(Resilience)과 안정성을 어떻게 사용자에게 보장하는지 알 수 있습니다 [3], [15], [16].
+- [[JavaScript Memory Leaks]]
+  - 연결 이유: 로깅 도구나 성능 프로파일러(Chrome DevTools Memory Profiler 등)를 통해 추적해야 하는 대표적인 프론트엔드 성능 저하의 원인입니다 [27], [28], [29].
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 메모리 팽창, 분리된 DOM 노드(Detached DOM nodes)와 같은 문제가 사용자 환경에서 어떻게 성능 지연이나 브라우저 멈춤으로 이어지는지 이해할 수 있습니다 [28], [30], [31].
+
+### Deeper Research Questions
+
+- 프론트엔드 모니터링 도구의 SDK를 번들에 포함할 때 발생하는 성능 저하(번들 사이즈 증가 및 로딩 시간 지연)를 극복하기 위한 Code Splitting 및 지연 로딩 전략은 무엇인가?
+- Datadog과 같은 복잡한 '수집/색인 분리(two-part tariff)' 과금 모델 하에서, 급증하는 프론트엔드 로그 비용을 관리하면서도 필수 가시성을 유지하기 위한 최적의 로그 샘플링(Sampling) 기법은 어떻게 설계해야 하는가?
+- Session Replay 기능을 구현할 때, 전 세계적인 데이터 프라이버시 규제(예: GDPR)에 대응하기 위해 DOM 요소 내의 민감한 사용자 데이터를 프론트엔드단에서 어떻게 효율적으로 마스킹(Masking)하는가?
+- OpenTelemetry 표준을 프론트엔드에 적용하여 생성된 Trace ID는 백엔드의 분산 트레이스(Distributed Trace) 데이터와 네트워크 계층에서 어떻게 상호 연결 및 동기화되는가?
+- React Error Boundary 내부에서 처리할 수 없는 비동기 통신(Promise)이나 이벤트 핸들러 내부의 에러는 Sentry 등의 글로벌 로깅 도구로 어떻게 우회하여 포착(Catch)하는가?
+
+### Practical Application Contexts
+
+- **Implementation:** Next.js 등의 프론트엔드 프로젝트에 Sentry나 LogRocket SDK를 통합 초기화하고, React 트리에 Error Boundary 컴포넌트를 감싸 에러 캐치 시 모니터링 도구로 자동 전송되도록 구현합니다 [24], [9], [14], [16].
+- **System Design:** 단일 서비스가 아닌 마이크로서비스 아키텍처(MSA) 구조인 경우, 단순 에러 로깅(Sentry)보다는 SigNoz나 Datadog RUM을 채택해 프론트엔드 액션부터 백엔드 DB 쿼리까지 이어지는 엔드투엔드 트레이싱 아키텍처를 설계합니다 [5], [13].
+- **Operation / Maintenance:** 프로덕션 환경 운영 시 Sentry의 지능형 에러 그룹화를 통해 슬랙(Slack) 알람의 노이즈를 줄이고, 성능 이슈 리포트 접수 시 LogRocket의 세션 리플레이로 사용자 행동을 재현해 원인을 파악합니다 [4], [8], [3].
+- **Learning Path:** 처음엔 Chrome DevTools의 Console과 Memory 탭을 활용해 로컬 디버깅 및 메모리 누수 [32], [29] 원리를 학습하고, 이후 React의 Error Boundaries를 활용한 장애 격리 [26], 최종적으로 SaaS 기반 클라우드 로깅 도구 통합으로 나아갑니다.
+- **My Project Relevance:** 팀의 예산과 개발 여력에 따라 로깅 툴을 선택합니다. 초기 스타트업이나 소규모 팀은 Sentry의 넉넉한 무료 티어(월 5만 개 에러)를 채택하고, 비용 통제와 데이터 소유가 중요하다면 SigNoz 등 OpenTelemetry 자가 호스팅 옵션을 고려할 수 있습니다 [17], [12], [33].
+
+### Adjacent Topics
+
+- [[Core Web Vitals]]
+  - 확장 방향: 프론트엔드 모니터링 도구들이 단순 에러뿐만 아니라 사용자 경험 지표인 LCP, FID, CLS 등을 어떻게 측정하고 애플리케이션의 성능 최적화(Performance Optimization)로 연결하는지 학습할 수 있습니다 [34], [35], [36].
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/00_Raw/확장 가능한 React 아키텍처 및 폴더 구조 설계.md b/00_Raw/확장 가능한 React 아키텍처 및 폴더 구조 설계.md
new file mode 100644
index 00000000..358b60e0
--- /dev/null
+++ b/00_Raw/확장 가능한 React 아키텍처 및 폴더 구조 설계.md	
@@ -0,0 +1,73 @@
+# [[확장 가능한 React 아키텍처 및 폴더 구조 설계]]
+
+## 📌 Brief Summary
+확장 가능한 React 아키텍처 및 폴더 구조 설계란 애플리케이션이 성장함에 따라 발생하는 복잡성을 제어하고, 유지보수성과 팀 협업 효율을 높이기 위해 코드를 논리적이고 예측 가능하게 조직하는 방법입니다. 기존의 파일 유형별 분류를 넘어, 비즈니스 도메인을 중심으로 코드를 그룹화하는 '기능 기반(Feature-Based)' 구조와 단방향 의존성을 강제하는 'Feature-Sliced Design (FSD)' 같은 계층적 모델이 널리 사용됩니다. 이를 통해 컴포넌트 간의 강한 결합도를 낮추고, 각 기능의 독립적인 개발과 안전한 리팩토링을 보장할 수 있습니다.
+
+## 📖 Core 소스에 기반한 Core Content
+*   **폴더 구조의 진화와 하이브리드/기능 기반 접근**
+    초기 React 프로젝트는 `components`, `hooks`, `styles`와 같이 기술적 파일 유형에 따라 폴더를 나누는 방식이 흔했으나, 앱이 확장되면 관련된 기능 로직이 여러 폴더에 파편화되어 유지보수가 매우 어려워집니다. 2025년 기준 권장되는 방식은 기능(Feature)이나 비즈니스 도메인을 중심으로 조직하는 하이브리드 혹은 기능 기반 구조입니다. 예를 들어 `/features/auth` 폴더 내부에 해당 기능의 컴포넌트, 훅, API 로직, 타입 정의 등을 응집시켜 독립적인 모듈처럼 구성합니다. 공유되는 UI 컴포넌트나 유틸리티는 `/components`, `/utils` 등에 별도로 둡니다.
+*   **Feature-Sliced Design (FSD) 방법론**
+    FSD는 프론트엔드 프로젝트를 위한 명확하고 강제력 있는 계층형 아키텍처입니다. 코드를 범위와 책임에 따라 `app`(글로벌 설정), `pages`(라우팅), `widgets`(독립적 UI 블록), `features`(사용자 상호작용 및 비즈니스 로직), `entities`(핵심 비즈니스 모델), `shared`(재사용 가능한 유틸리티) 등 6가지 레이어로 나눕니다. 가장 중요한 규칙은 '단방향 의존성'으로, 상위 레이어는 하위 레이어를 참조할 수 있지만 하위 레이어는 상위 레이어를 참조할 수 없습니다. 또한 각 슬라이스는 `index.ts`를 통한 'Public API'만을 노출하여 내부 구현을 캡슐화합니다.
+*   **관심사 분리와 상태 및 성능 관리**
+    규모가 큰 시스템에서 비즈니스 로직과 UI를 명확히 분리하는 것은 필수입니다. 전역 상태 관리에 있어서, 빈번하게 변경되는 상태(예: 장바구니, 알림)를 다룰 때 React의 내장 Context API를 사용하면 구독 중인 모든 하위 컴포넌트가 불필요하게 리렌더링되는 성능 병목이 발생합니다. 이를 피하기 위해 Zustand나 Redux 같은 특화된 상태 관리 도구를 활용해 선택적 리렌더링(Selector Pattern)을 적용해야 합니다. 서버에서 가져오는 데이터 상태의 경우, TanStack Query와 같은 전용 라이브러리를 통해 클라이언트 상태와 엄격히 분리하여 `/features` 내부에 위치시킵니다.
+*   **명명 규칙(Naming Conventions)과 거버넌스**
+    파일 및 폴더 이름을 일관되게 관리하는 것은 협업 시 혼란을 방지합니다. React 컴포넌트 파일은 `PascalCase`(`UserProfile.tsx`)를 사용하지만, 일반 파일과 폴더명은 OS 호환성을 위해 `kebab-case`(`user-profile`)를 사용하는 것이 모범 사례로 꼽힙니다. 커스텀 훅과 변수는 `camelCase`(`useAuth`)를 사용합니다. 이러한 규칙과 의존성 규칙은 수동이 아닌 ESLint 등 린팅 도구를 통해 자동화하여 거버넌스를 유지합니다.
+*   **클린 코드와 소프트웨어 엔지니어링 원칙 (SOLID 등)**
+    React 코드에 단일 책임 원칙(SRP)을 적용하여 300줄이 넘어가는 다기능 컴포넌트를 작게 쪼개는 것이 권장됩니다. 반복되는 로직은 DRY 원칙을 통해 커스텀 훅으로 추출하되, 과도한 추상화가 오히려 코드의 직관성을 해치지 않도록 KISS 원칙을 준수해야 합니다. 또한, YAGNI 원칙에 따라 미래를 대비한 불필요한 확장 기능 구현을 피하여 코드 복잡도를 낮춰야 합니다.
+
+## ⚖️ Trade-offs & Caveats
+*   **기능 기반 구조(FSD 등)의 도입 오버헤드**
+    FSD나 기능 중심의 디렉토리 구조는 모듈성 측면에서 강력하지만, 소규모 프로젝트에서는 과도한 설정(Overkill)과 불필요한 계층 분리를 초래할 수 있습니다. 어떤 모듈이 "기능(Feature)"인지 "위젯(Widget)"인지 구별하는 등 경계를 나누기 모호한 교차 관심사(Cross-cutting concerns) 처리에서 팀 내 논쟁과 의미론적 오버헤드가 발생할 수 있습니다. 팀 전체가 아키텍처 규칙을 완벽히 이해하지 못하면, 결국 규칙을 우회하기 위해 `/shared` 디렉토리에 모든 코드를 덤프해버리는 혼란이 발생할 위험이 있습니다.
+*   **추상화의 딜레마 (DRY vs KISS)**
+    코드의 중복을 없애기 위해(DRY) 무조건적으로 커스텀 훅이나 고차 컴포넌트(HOC)로 로직을 추출하다 보면, 오히려 로직을 추적하기 어려워지고 이해하기 복잡해져서 "간결함을 유지하라(KISS)"는 원칙을 위반하게 됩니다. 전문가들은 추상화를 서두르지 말고 동일한 패턴이 최소 3번 이상 반복될 때 추출하는 것을 권장합니다.
+*   **상태 관리 도구 도입에 따른 복잡성 증가**
+    0KB의 내장 도구인 Context API는 작고 정적인 상태(테마 등) 관리에 간편하지만, 렌더링 성능 최적화가 불가능하다는 한계가 있습니다. 이를 해결하기 위해 Zustand나 Redux 같은 상태 관리 라이브러리를 프로젝트 폴더(`store/`)에 도입하면 성능 문제는 해결할 수 있으나, 외부 라이브러리에 대한 의존성이 생기며 상태 슬라이스의 모듈화, 선택자(Selector) 작성 등에서 팀의 개발 규율(학습 곡선 및 보일러플레이트)이 부가적으로 요구됩니다.
+
+## 🔗 Knowledge Connections
+
+### Related Concepts
+
+#### [관계 유형: 아키텍처 방법론]
+- [[Feature-Sliced Design (FSD)]]
+  - 연결 이유: 확장 가능한 프론트엔드를 구축하기 위해 고안된 구체적이고 최신화된 디렉토리 아키텍처 패러다임이기 때문입니다.
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 레이어(Layers), 슬라이스(Slices), 세그먼트(Segments)의 구분, 단방향 의존성 강제, Public API 캡슐화를 통한 도메인 분리 전략.
+
+#### [관계 유형: 소프트웨어 설계 및 최적화 원칙]
+- [[SOLID 및 Clean Code 원칙]]
+  - 연결 이유: 컴포넌트를 설계하고 리팩토링할 때 폴더와 파일의 책임을 나누는 기반 지침이 됩니다.
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 단일 책임 원칙(SRP)을 통한 대형 컴포넌트의 분해, DRY/KISS 원칙을 통한 적절한 훅 추상화의 균형점.
+
+- [[자동 메모이제이션 (React Compiler)]]
+  - 연결 이유: 잘 설계된 아키텍처 내에서도 렌더링 폭포를 막는 것은 필수적인데, 이를 시스템적으로 최적화하는 2025년 주요 기술입니다.
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 수동 메모이제이션(`useMemo`, `useCallback`)의 한계 및 코드 복잡성 문제, 컴포넌트가 React 규칙(Rules of React)을 엄격히 준수해야 하는 이유.
+
+#### [관계 유형: 상태 및 데이터 관리 도구]
+- [[Zustand 및 Redux]]
+  - 연결 이유: 전역 상태 관리는 리액트 아키텍처에서 `/store` 또는 각 도메인 기능 내의 핵심 레이어를 구성하며, 시스템 결합도를 결정짓는 요소이기 때문입니다.
+  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: Context API의 전체 리렌더링 문제 해결 방식, 컴포넌트 외부에서 상태를 관리하여 아키텍처 성능을 유지하는 구체적 방법.
+
+### Deeper Research Questions
+
+- 단일 프론트엔드 모노레포에서 FSD(Feature-Sliced Design)를 도입할 때, 기능 간 '공유 관심사(Cross-cutting concerns)'를 명확히 분리하고 레이어 역참조를 막기 위해 ESLint 규칙을 어떻게 구체적으로 세팅해야 하는가?
+- 상태 관리 도구(Context API, Zustand, Redux)의 선택이 프로젝트의 실제 폴더 트리 구성(예: 단일 `/store` 폴더 사용 vs `/features/auth` 내 슬라이스로 분산 배치)에 어떠한 영향을 미치며, 대규모 앱에서의 모범 사례는 무엇인가?
+- 확장성이 큰 애플리케이션에서 라우트 레벨의 코드 스플리팅(Code Splitting)과 `React.lazy`를 적용할 때, Vite의 `manualChunks`를 활용해 서드파티 라이브러리(Vendor)를 분리하는 빌드 최적화 설정 방법론은 무엇인가?
+- 컴포넌트의 책임을 분리(SRP)하기 위해 거대한 로직을 Custom Hooks로 추출할 때, 과도한 추상화(DRY)와 코드의 직관성(KISS) 간의 트레이드오프를 평가할 수 있는 구체적 코드 지표는 무엇인가?
+- 애플리케이션의 안정성을 확보하기 위해 React Error Boundaries를 설계할 때, 앱 전체를 단일로 감싸는 방식과 각 기능별(위젯/라우트 등)로 쪼개어 감싸는 방식이 아키텍처 구조 설계에 어떻게 반영되어야 하는가?
+
+### Practical Application Contexts
+
+- **Implementation:** React 컴포넌트명은 `PascalCase`로 짓고, 폴더와 파일명은 호환성을 위해 `kebab-case`로 명명합니다. 기능 로직은 `features` 폴더 내에 배치하거나 `hooks` 폴더에 분리하여 반복을 줄이고 코드 응집력을 높이도록 구현합니다.
+- **System Design:** 코드를 파일 유형(컴포넌트, 훅 등)이 아닌 비즈니스 흐름과 도메인(Auth, Dashboard 등)에 맞추어 설계해야 합니다. 상위 컴포넌트 계층은 하위 인프라/도메인 계층에만 접근할 수 있도록 의존성 흐름을 설계에 반영합니다.
+- **Operation / Maintenance:** 기능 기반으로 분할된 폴더 구조는 특정 기능(예: 결제 프로세스)에 버그가 발생하거나 유지보수가 필요할 때, 해당 도메인 폴더 하나만 집중 분석하면 되므로 변경에 따른 부작용(Side Effect) 추적 및 디버깅 운영이 훨씬 수월해집니다.
+- **Learning Path:** 리액트를 처음 배울 때는 Flat 구조나 `components`, `hooks`를 나누는 파일 유형 기반으로 시작하지만, 이후 불필요한 리렌더링이나 복잡성 문제에 직면하면 FSD 아키텍처나 Zustand 같은 전역 상태의 역할 범위를 제한하는 고도화된 아키텍처 설계로 발전시켜 나가는 경로가 효과적입니다.
+- **My Project Relevance:** 소스에 관련 정보가 부족합니다. (질문자의 개인 프로젝트와 관련된 명시적 맥락이 소스 데이터에 포함되어 있지 않습니다.)
+
+### Adjacent Topics
+
+- [[마이크로 프론트엔드 (Micro-Frontends)]]
+  - 확장 방향: 단일 리액트 앱의 폴더 구조 분리를 넘어서, 대형 엔터프라이즈 환경에서 여러 팀이 독립적으로 개발하고 배포할 수 있도록 프론트엔드 자체를 물리적으로 분할 및 런타임에 통합하는 설계 방법론으로 확장.
+- [[서버 상태 관리 (Server State Management)]]
+  - 확장 방향: 클라이언트 로컬 상태와 구별하여, API 데이터를 비동기적으로 관리하고 캐싱 및 재검증을 처리하는 TanStack Query(React Query) 기반의 계층 설계 및 데이터 패칭 최적화로 지식 확장.
+
+---
+*Last updated: 2026-04-30*
\ No newline at end of file
diff --git a/10_Wiki/Projects/ConnectAI/Core_Optimization_Plan.md b/10_Wiki/Projects/ConnectAI/Core_Optimization_Plan.md
new file mode 100644
index 00000000..07f1ff22
--- /dev/null
+++ b/10_Wiki/Projects/ConnectAI/Core_Optimization_Plan.md
@@ -0,0 +1,46 @@
+---
+id: a7f8e1c2-d3b4-4e5f-9a0b-1c2d3e4f5a6b
+category: "[[10_Wiki/Projects/ConnectAI]]"
+confidence_score: 0.90
+tags: [connectai, optimization, python, architecture, performance]
+last_reinforced: 2026-05-01
+github_commit: "initial-wikification"
+---
+
+# [[ConnectAI Core Optimization Plan (Python Core)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> ConnectAI의 성능 병목을 해결하기 위해 $O(N^2)$ 알고리즘을 $O(N \log N)$으로 고도화하고, 동기식 I/O를 비동기 파이프라인으로 전환하며, 옵저버 패턴을 통해 모듈 간 결합도를 제거하는 전면적인 코어 아키텍처 개편 계획이다.
+
+## 📖 구조화된 지식 (Synthesized Content)
+
+### 1. 알고리즘 효율화 (Performance Optimization)
+- **현상**: `InferenceEngine.py` 내 brute-force 특징 매칭 로직이 $O(N^2)$의 비효율성을 가짐.
+- **해결**: **KD-Tree** 또는 행렬 분해 기반 벡터 연산을 도입하여 $O(N \log N)$으로 개선. 추론 지연 시간 5~10배 단축을 목표로 함.
+
+### 2. 비동기 I/O 파이프라인 (Throughput Enhancement)
+- **현상**: 데이터 로딩(`DataLoader.py`) 과정이 동기식으로 동작하여 CPU 유휴 시간 발생 및 처리량 저하.
+- **해결**: `asyncio` 및 스레드 풀을 활용한 비동기/병렬 I/O 구조로 전환하여 데이터 수집 및 처리 속도 극대화.
+
+### 3. 모듈 디커플링 (Maintainability & Scalability)
+- **현상**: 전처리 모듈과 코어 모델 간의 직접적인 하드코딩 의존성으로 인해 유지보수 및 테스트가 난해함.
+- **해결**: **관찰자 패턴(Observer Pattern)** 및 이벤트 기반 아키텍처 도입. `DataReadyEvent` 발행-구독 모델을 통해 모듈 독립성 확보 및 DIP(의존 역전 원칙) 실현.
+
+## 🚀 구현 로드맵 (Execution Roadmap)
+- **Phase 1**: 핵심 알고리즘 최적화 및 벤치마킹 (KD-Tree 구현).
+- **Phase 2**: 비동기 I/O 래핑 및 전역 이벤트 루프 통합.
+- **Phase 3**: 이벤트 시스템 구축을 통한 모듈 간 인터페이스 표준화.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **복잡도 vs 성능**: KD-Tree 도입은 성능을 높이지만 데이터 업데이트 빈도가 극도로 높을 경우 트리 재구축 오버헤드가 발생할 수 있음.
+- **비동기 오버헤드**: 단순 연산 위주 작업에서는 `asyncio` 전환이 오히려 컨텍스트 스위칭 비용만 늘릴 수 있으므로 프로파일링 필수.
+
+## 🔗 지식 연결 (Graph)
+- **Parent**: [[10_Wiki/Projects/ConnectAI]]
+- **Related**: [[Observer Pattern]], [[KD-Tree]], [[Asynchronous I/O]]
+- **Raw Source**: [[00_Raw/system_analysis_and_improvement_plan]]
+
+## 💻 GitHub 동기화 자동화 워크플로우
+1. Stage: git add .
+2. Commit: `git commit -m "[P-Reinforce] Wikify ConnectAI Core Optimization Plan"`
+3. Push: `git push origin main`
diff --git a/10_Wiki/Topics/Development/Modern_React_Engineering_2025.md b/10_Wiki/Topics/Development/Modern_React_Engineering_2025.md
new file mode 100644
index 00000000..639bf010
--- /dev/null
+++ b/10_Wiki/Topics/Development/Modern_React_Engineering_2025.md
@@ -0,0 +1,50 @@
+---
+id: 5e8f4a2b-1c9d-4e8b-a2f3-7d9e1c6b4a2d
+category: "[[10_Wiki/Topics/Development]]"
+confidence_score: 0.95
+tags: [react, frontend, engineering, standard, 2025, performance, architecture]
+last_reinforced: 2026-05-01
+github_commit: "initial-wikification"
+---
+
+# [[Modern React & Frontend Engineering Standard (2025)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> 2025년의 프론트엔드 엔지니어링은 단순한 UI 개발을 넘어, FSD 아키텍처, 빌드 타임 자동화(React Compiler), 그리고 목적별로 파편화된 상태 관리 체계를 통해 확장성과 안정성을 극대화하는 정교한 분산 시스템 엔지니어링으로 진화했다.
+
+## 📖 구조화된 지식 (Synthesized Content)
+
+### 1. 확장 가능한 아키텍처: Feature-Sliced Design (FSD)
+- **계층적 구조화**: `app` -> `pages` -> `widgets` -> `features` -> `entities` -> `shared` 순의 레이어링을 통해 관심사를 분리한다.
+- **단방향 의존성**: 상위 레이어는 하위 레이어만 참조할 수 있도록 강제하여 순환 참조를 원천 차단하고 모듈 간 결합도를 낮춘다.
+- **Public API (index.ts)**: 각 슬라이스는 `index.ts`를 통해서만 외부와 소통하여 내부 구현을 캡슐화한다.
+
+### 2. 상태 관리의 전문화 및 파편화
+- **서버 상태**: TanStack Query (React Query)를 사용하여 캐싱, 동기화, 비동기 상태를 전담 관리한다.
+- **전역 애플리케이션 상태**: Zustand를 활용하여 Selector 기반의 세밀한 리렌더링 제어를 수행하며, Redux는 복잡도가 극도로 높은 대규모 협업 환경에서만 제한적으로 채택한다.
+- **로컬 및 UI 상태**: `useState`, `useReducer`, 또는 정적인 설정값의 경우 `Context API`를 적재적소에 배치한다.
+
+### 3. 성능 엔지니어링 (Build & Runtime)
+- **Vite & ESM**: 기존 번들러 대비 비약적으로 빠른 HMR과 개발 서버 속도를 보장한다.
+- **React Compiler**: 빌드 타임에 AST 분석을 통해 `useMemo`, `useCallback` 등을 자동으로 주입하여 수동 메모이제이션의 오버헤드를 제거한다.
+- **코드 스플리팅**: `React.lazy`와 Vite의 `manualChunks` 설정을 통해 라우트 단위로 번들을 쪼개어 초기 로딩 속도(LCP)를 개선한다.
+
+### 4. 운영 회복성 및 거버넌스
+- **Error Boundaries**: 특정 컴포넌트의 런타임 에러가 전체 앱 중단(White Screen)으로 번지지 않도록 구획별로 안전장치를 배치한다.
+- **Observability**: Sentry, LogRocket 등을 연동하여 실제 사용자의 세션 리플레이 및 에러 로그를 실시간 모니터링한다.
+- **엄격한 컨벤션**: `kebab-case`(파일명), `PascalCase`(컴포넌트), `camelCase`(훅/변수) 네이밍을 자동화 훅(Husky, ESLint)으로 강제한다.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **메모이제이션의 함정**: `React.memo`의 얕은 비교 비용이 실제 렌더링 비용보다 클 수 있으므로, React Profiler 측정 없는 무분별한 최적화는 지양해야 한다.
+- **FSD vs Flat Structure**: 소규모 프로젝트에서는 FSD가 오버엔지니어링이 될 수 있으며, 팀의 숙련도에 따라 `shared` 레이어 비대화 문제가 발생할 수 있다.
+- **Compiler 블랙박스**: 자동 최적화가 동작하지 않는 엣지 케이스(불안정한 참조 반환 등)에 대한 개발자의 수동 대응 패턴이 여전히 필요하다.
+
+## 🔗 지식 연결 (Graph)
+- **Parent**: [[10_Wiki/Topics/Development]]
+- **Related**: [[Feature-Sliced Design]], [[Zustand]], [[React Compiler]], [[Error Boundaries]]
+- **Raw Source**: [[00_Raw/2025 프론트엔드 엔지니어링 표준 확립]], [[00_Raw/대규모 React 애플리케이션 개발]], [[00_Raw/Modern React Application Development (2025)]]
+
+## 💻 GitHub 동기화 자동화 워크플로우
+1. Stage: git add .
+2. Commit: `git commit -m "[P-Reinforce] Wikify Modern React Engineering Standard 2025"`
+3. Push: `git push origin main`
diff --git a/10_Wiki/Topics_Biz/ConnectAI_Core_Optimization_Plan.md b/10_Wiki/Topics_Biz/ConnectAI_Core_Optimization_Plan.md
new file mode 100644
index 00000000..07f1ff22
--- /dev/null
+++ b/10_Wiki/Topics_Biz/ConnectAI_Core_Optimization_Plan.md
@@ -0,0 +1,46 @@
+---
+id: a7f8e1c2-d3b4-4e5f-9a0b-1c2d3e4f5a6b
+category: "[[10_Wiki/Projects/ConnectAI]]"
+confidence_score: 0.90
+tags: [connectai, optimization, python, architecture, performance]
+last_reinforced: 2026-05-01
+github_commit: "initial-wikification"
+---
+
+# [[ConnectAI Core Optimization Plan (Python Core)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> ConnectAI의 성능 병목을 해결하기 위해 $O(N^2)$ 알고리즘을 $O(N \log N)$으로 고도화하고, 동기식 I/O를 비동기 파이프라인으로 전환하며, 옵저버 패턴을 통해 모듈 간 결합도를 제거하는 전면적인 코어 아키텍처 개편 계획이다.
+
+## 📖 구조화된 지식 (Synthesized Content)
+
+### 1. 알고리즘 효율화 (Performance Optimization)
+- **현상**: `InferenceEngine.py` 내 brute-force 특징 매칭 로직이 $O(N^2)$의 비효율성을 가짐.
+- **해결**: **KD-Tree** 또는 행렬 분해 기반 벡터 연산을 도입하여 $O(N \log N)$으로 개선. 추론 지연 시간 5~10배 단축을 목표로 함.
+
+### 2. 비동기 I/O 파이프라인 (Throughput Enhancement)
+- **현상**: 데이터 로딩(`DataLoader.py`) 과정이 동기식으로 동작하여 CPU 유휴 시간 발생 및 처리량 저하.
+- **해결**: `asyncio` 및 스레드 풀을 활용한 비동기/병렬 I/O 구조로 전환하여 데이터 수집 및 처리 속도 극대화.
+
+### 3. 모듈 디커플링 (Maintainability & Scalability)
+- **현상**: 전처리 모듈과 코어 모델 간의 직접적인 하드코딩 의존성으로 인해 유지보수 및 테스트가 난해함.
+- **해결**: **관찰자 패턴(Observer Pattern)** 및 이벤트 기반 아키텍처 도입. `DataReadyEvent` 발행-구독 모델을 통해 모듈 독립성 확보 및 DIP(의존 역전 원칙) 실현.
+
+## 🚀 구현 로드맵 (Execution Roadmap)
+- **Phase 1**: 핵심 알고리즘 최적화 및 벤치마킹 (KD-Tree 구현).
+- **Phase 2**: 비동기 I/O 래핑 및 전역 이벤트 루프 통합.
+- **Phase 3**: 이벤트 시스템 구축을 통한 모듈 간 인터페이스 표준화.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **복잡도 vs 성능**: KD-Tree 도입은 성능을 높이지만 데이터 업데이트 빈도가 극도로 높을 경우 트리 재구축 오버헤드가 발생할 수 있음.
+- **비동기 오버헤드**: 단순 연산 위주 작업에서는 `asyncio` 전환이 오히려 컨텍스트 스위칭 비용만 늘릴 수 있으므로 프로파일링 필수.
+
+## 🔗 지식 연결 (Graph)
+- **Parent**: [[10_Wiki/Projects/ConnectAI]]
+- **Related**: [[Observer Pattern]], [[KD-Tree]], [[Asynchronous I/O]]
+- **Raw Source**: [[00_Raw/system_analysis_and_improvement_plan]]
+
+## 💻 GitHub 동기화 자동화 워크플로우
+1. Stage: git add .
+2. Commit: `git commit -m "[P-Reinforce] Wikify ConnectAI Core Optimization Plan"`
+3. Push: `git push origin main`
diff --git a/10_Wiki/Topics_Biz/Modern_React_Engineering_2025.md b/10_Wiki/Topics_Biz/Modern_React_Engineering_2025.md
new file mode 100644
index 00000000..639bf010
--- /dev/null
+++ b/10_Wiki/Topics_Biz/Modern_React_Engineering_2025.md
@@ -0,0 +1,50 @@
+---
+id: 5e8f4a2b-1c9d-4e8b-a2f3-7d9e1c6b4a2d
+category: "[[10_Wiki/Topics/Development]]"
+confidence_score: 0.95
+tags: [react, frontend, engineering, standard, 2025, performance, architecture]
+last_reinforced: 2026-05-01
+github_commit: "initial-wikification"
+---
+
+# [[Modern React & Frontend Engineering Standard (2025)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> 2025년의 프론트엔드 엔지니어링은 단순한 UI 개발을 넘어, FSD 아키텍처, 빌드 타임 자동화(React Compiler), 그리고 목적별로 파편화된 상태 관리 체계를 통해 확장성과 안정성을 극대화하는 정교한 분산 시스템 엔지니어링으로 진화했다.
+
+## 📖 구조화된 지식 (Synthesized Content)
+
+### 1. 확장 가능한 아키텍처: Feature-Sliced Design (FSD)
+- **계층적 구조화**: `app` -> `pages` -> `widgets` -> `features` -> `entities` -> `shared` 순의 레이어링을 통해 관심사를 분리한다.
+- **단방향 의존성**: 상위 레이어는 하위 레이어만 참조할 수 있도록 강제하여 순환 참조를 원천 차단하고 모듈 간 결합도를 낮춘다.
+- **Public API (index.ts)**: 각 슬라이스는 `index.ts`를 통해서만 외부와 소통하여 내부 구현을 캡슐화한다.
+
+### 2. 상태 관리의 전문화 및 파편화
+- **서버 상태**: TanStack Query (React Query)를 사용하여 캐싱, 동기화, 비동기 상태를 전담 관리한다.
+- **전역 애플리케이션 상태**: Zustand를 활용하여 Selector 기반의 세밀한 리렌더링 제어를 수행하며, Redux는 복잡도가 극도로 높은 대규모 협업 환경에서만 제한적으로 채택한다.
+- **로컬 및 UI 상태**: `useState`, `useReducer`, 또는 정적인 설정값의 경우 `Context API`를 적재적소에 배치한다.
+
+### 3. 성능 엔지니어링 (Build & Runtime)
+- **Vite & ESM**: 기존 번들러 대비 비약적으로 빠른 HMR과 개발 서버 속도를 보장한다.
+- **React Compiler**: 빌드 타임에 AST 분석을 통해 `useMemo`, `useCallback` 등을 자동으로 주입하여 수동 메모이제이션의 오버헤드를 제거한다.
+- **코드 스플리팅**: `React.lazy`와 Vite의 `manualChunks` 설정을 통해 라우트 단위로 번들을 쪼개어 초기 로딩 속도(LCP)를 개선한다.
+
+### 4. 운영 회복성 및 거버넌스
+- **Error Boundaries**: 특정 컴포넌트의 런타임 에러가 전체 앱 중단(White Screen)으로 번지지 않도록 구획별로 안전장치를 배치한다.
+- **Observability**: Sentry, LogRocket 등을 연동하여 실제 사용자의 세션 리플레이 및 에러 로그를 실시간 모니터링한다.
+- **엄격한 컨벤션**: `kebab-case`(파일명), `PascalCase`(컴포넌트), `camelCase`(훅/변수) 네이밍을 자동화 훅(Husky, ESLint)으로 강제한다.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **메모이제이션의 함정**: `React.memo`의 얕은 비교 비용이 실제 렌더링 비용보다 클 수 있으므로, React Profiler 측정 없는 무분별한 최적화는 지양해야 한다.
+- **FSD vs Flat Structure**: 소규모 프로젝트에서는 FSD가 오버엔지니어링이 될 수 있으며, 팀의 숙련도에 따라 `shared` 레이어 비대화 문제가 발생할 수 있다.
+- **Compiler 블랙박스**: 자동 최적화가 동작하지 않는 엣지 케이스(불안정한 참조 반환 등)에 대한 개발자의 수동 대응 패턴이 여전히 필요하다.
+
+## 🔗 지식 연결 (Graph)
+- **Parent**: [[10_Wiki/Topics/Development]]
+- **Related**: [[Feature-Sliced Design]], [[Zustand]], [[React Compiler]], [[Error Boundaries]]
+- **Raw Source**: [[00_Raw/2025 프론트엔드 엔지니어링 표준 확립]], [[00_Raw/대규모 React 애플리케이션 개발]], [[00_Raw/Modern React Application Development (2025)]]
+
+## 💻 GitHub 동기화 자동화 워크플로우
+1. Stage: git add .
+2. Commit: `git commit -m "[P-Reinforce] Wikify Modern React Engineering Standard 2025"`
+3. Push: `git push origin main`
diff --git a/10_Wiki/Topics_Blog/Modern_React_Engineering_2025.md b/10_Wiki/Topics_Blog/Modern_React_Engineering_2025.md
new file mode 100644
index 00000000..639bf010
--- /dev/null
+++ b/10_Wiki/Topics_Blog/Modern_React_Engineering_2025.md
@@ -0,0 +1,50 @@
+---
+id: 5e8f4a2b-1c9d-4e8b-a2f3-7d9e1c6b4a2d
+category: "[[10_Wiki/Topics/Development]]"
+confidence_score: 0.95
+tags: [react, frontend, engineering, standard, 2025, performance, architecture]
+last_reinforced: 2026-05-01
+github_commit: "initial-wikification"
+---
+
+# [[Modern React & Frontend Engineering Standard (2025)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> 2025년의 프론트엔드 엔지니어링은 단순한 UI 개발을 넘어, FSD 아키텍처, 빌드 타임 자동화(React Compiler), 그리고 목적별로 파편화된 상태 관리 체계를 통해 확장성과 안정성을 극대화하는 정교한 분산 시스템 엔지니어링으로 진화했다.
+
+## 📖 구조화된 지식 (Synthesized Content)
+
+### 1. 확장 가능한 아키텍처: Feature-Sliced Design (FSD)
+- **계층적 구조화**: `app` -> `pages` -> `widgets` -> `features` -> `entities` -> `shared` 순의 레이어링을 통해 관심사를 분리한다.
+- **단방향 의존성**: 상위 레이어는 하위 레이어만 참조할 수 있도록 강제하여 순환 참조를 원천 차단하고 모듈 간 결합도를 낮춘다.
+- **Public API (index.ts)**: 각 슬라이스는 `index.ts`를 통해서만 외부와 소통하여 내부 구현을 캡슐화한다.
+
+### 2. 상태 관리의 전문화 및 파편화
+- **서버 상태**: TanStack Query (React Query)를 사용하여 캐싱, 동기화, 비동기 상태를 전담 관리한다.
+- **전역 애플리케이션 상태**: Zustand를 활용하여 Selector 기반의 세밀한 리렌더링 제어를 수행하며, Redux는 복잡도가 극도로 높은 대규모 협업 환경에서만 제한적으로 채택한다.
+- **로컬 및 UI 상태**: `useState`, `useReducer`, 또는 정적인 설정값의 경우 `Context API`를 적재적소에 배치한다.
+
+### 3. 성능 엔지니어링 (Build & Runtime)
+- **Vite & ESM**: 기존 번들러 대비 비약적으로 빠른 HMR과 개발 서버 속도를 보장한다.
+- **React Compiler**: 빌드 타임에 AST 분석을 통해 `useMemo`, `useCallback` 등을 자동으로 주입하여 수동 메모이제이션의 오버헤드를 제거한다.
+- **코드 스플리팅**: `React.lazy`와 Vite의 `manualChunks` 설정을 통해 라우트 단위로 번들을 쪼개어 초기 로딩 속도(LCP)를 개선한다.
+
+### 4. 운영 회복성 및 거버넌스
+- **Error Boundaries**: 특정 컴포넌트의 런타임 에러가 전체 앱 중단(White Screen)으로 번지지 않도록 구획별로 안전장치를 배치한다.
+- **Observability**: Sentry, LogRocket 등을 연동하여 실제 사용자의 세션 리플레이 및 에러 로그를 실시간 모니터링한다.
+- **엄격한 컨벤션**: `kebab-case`(파일명), `PascalCase`(컴포넌트), `camelCase`(훅/변수) 네이밍을 자동화 훅(Husky, ESLint)으로 강제한다.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **메모이제이션의 함정**: `React.memo`의 얕은 비교 비용이 실제 렌더링 비용보다 클 수 있으므로, React Profiler 측정 없는 무분별한 최적화는 지양해야 한다.
+- **FSD vs Flat Structure**: 소규모 프로젝트에서는 FSD가 오버엔지니어링이 될 수 있으며, 팀의 숙련도에 따라 `shared` 레이어 비대화 문제가 발생할 수 있다.
+- **Compiler 블랙박스**: 자동 최적화가 동작하지 않는 엣지 케이스(불안정한 참조 반환 등)에 대한 개발자의 수동 대응 패턴이 여전히 필요하다.
+
+## 🔗 지식 연결 (Graph)
+- **Parent**: [[10_Wiki/Topics/Development]]
+- **Related**: [[Feature-Sliced Design]], [[Zustand]], [[React Compiler]], [[Error Boundaries]]
+- **Raw Source**: [[00_Raw/2025 프론트엔드 엔지니어링 표준 확립]], [[00_Raw/대규모 React 애플리케이션 개발]], [[00_Raw/Modern React Application Development (2025)]]
+
+## 💻 GitHub 동기화 자동화 워크플로우
+1. Stage: git add .
+2. Commit: `git commit -m "[P-Reinforce] Wikify Modern React Engineering Standard 2025"`
+3. Push: `git push origin main`
diff --git a/10_Wiki/Topics_GD/Modern_React_Engineering_2025.md b/10_Wiki/Topics_GD/Modern_React_Engineering_2025.md
new file mode 100644
index 00000000..639bf010
--- /dev/null
+++ b/10_Wiki/Topics_GD/Modern_React_Engineering_2025.md
@@ -0,0 +1,50 @@
+---
+id: 5e8f4a2b-1c9d-4e8b-a2f3-7d9e1c6b4a2d
+category: "[[10_Wiki/Topics/Development]]"
+confidence_score: 0.95
+tags: [react, frontend, engineering, standard, 2025, performance, architecture]
+last_reinforced: 2026-05-01
+github_commit: "initial-wikification"
+---
+
+# [[Modern React & Frontend Engineering Standard (2025)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> 2025년의 프론트엔드 엔지니어링은 단순한 UI 개발을 넘어, FSD 아키텍처, 빌드 타임 자동화(React Compiler), 그리고 목적별로 파편화된 상태 관리 체계를 통해 확장성과 안정성을 극대화하는 정교한 분산 시스템 엔지니어링으로 진화했다.
+
+## 📖 구조화된 지식 (Synthesized Content)
+
+### 1. 확장 가능한 아키텍처: Feature-Sliced Design (FSD)
+- **계층적 구조화**: `app` -> `pages` -> `widgets` -> `features` -> `entities` -> `shared` 순의 레이어링을 통해 관심사를 분리한다.
+- **단방향 의존성**: 상위 레이어는 하위 레이어만 참조할 수 있도록 강제하여 순환 참조를 원천 차단하고 모듈 간 결합도를 낮춘다.
+- **Public API (index.ts)**: 각 슬라이스는 `index.ts`를 통해서만 외부와 소통하여 내부 구현을 캡슐화한다.
+
+### 2. 상태 관리의 전문화 및 파편화
+- **서버 상태**: TanStack Query (React Query)를 사용하여 캐싱, 동기화, 비동기 상태를 전담 관리한다.
+- **전역 애플리케이션 상태**: Zustand를 활용하여 Selector 기반의 세밀한 리렌더링 제어를 수행하며, Redux는 복잡도가 극도로 높은 대규모 협업 환경에서만 제한적으로 채택한다.
+- **로컬 및 UI 상태**: `useState`, `useReducer`, 또는 정적인 설정값의 경우 `Context API`를 적재적소에 배치한다.
+
+### 3. 성능 엔지니어링 (Build & Runtime)
+- **Vite & ESM**: 기존 번들러 대비 비약적으로 빠른 HMR과 개발 서버 속도를 보장한다.
+- **React Compiler**: 빌드 타임에 AST 분석을 통해 `useMemo`, `useCallback` 등을 자동으로 주입하여 수동 메모이제이션의 오버헤드를 제거한다.
+- **코드 스플리팅**: `React.lazy`와 Vite의 `manualChunks` 설정을 통해 라우트 단위로 번들을 쪼개어 초기 로딩 속도(LCP)를 개선한다.
+
+### 4. 운영 회복성 및 거버넌스
+- **Error Boundaries**: 특정 컴포넌트의 런타임 에러가 전체 앱 중단(White Screen)으로 번지지 않도록 구획별로 안전장치를 배치한다.
+- **Observability**: Sentry, LogRocket 등을 연동하여 실제 사용자의 세션 리플레이 및 에러 로그를 실시간 모니터링한다.
+- **엄격한 컨벤션**: `kebab-case`(파일명), `PascalCase`(컴포넌트), `camelCase`(훅/변수) 네이밍을 자동화 훅(Husky, ESLint)으로 강제한다.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **메모이제이션의 함정**: `React.memo`의 얕은 비교 비용이 실제 렌더링 비용보다 클 수 있으므로, React Profiler 측정 없는 무분별한 최적화는 지양해야 한다.
+- **FSD vs Flat Structure**: 소규모 프로젝트에서는 FSD가 오버엔지니어링이 될 수 있으며, 팀의 숙련도에 따라 `shared` 레이어 비대화 문제가 발생할 수 있다.
+- **Compiler 블랙박스**: 자동 최적화가 동작하지 않는 엣지 케이스(불안정한 참조 반환 등)에 대한 개발자의 수동 대응 패턴이 여전히 필요하다.
+
+## 🔗 지식 연결 (Graph)
+- **Parent**: [[10_Wiki/Topics/Development]]
+- **Related**: [[Feature-Sliced Design]], [[Zustand]], [[React Compiler]], [[Error Boundaries]]
+- **Raw Source**: [[00_Raw/2025 프론트엔드 엔지니어링 표준 확립]], [[00_Raw/대규모 React 애플리케이션 개발]], [[00_Raw/Modern React Application Development (2025)]]
+
+## 💻 GitHub 동기화 자동화 워크플로우
+1. Stage: git add .
+2. Commit: `git commit -m "[P-Reinforce] Wikify Modern React Engineering Standard 2025"`
+3. Push: `git push origin main`