feat: structure knowledge base with P-Reinforce categories and include Skybound wiki Batch 11.01-B

2026-04-21 10:25:01 +09:00
parent eb6049e195
commit e17155b555
37 changed files with 370 additions and 2 deletions
@@ -0,0 +1,26 @@
+---
+title: 효율적인 API 통신 패턴 (Axios & Interceptors)
+category: Software Architecture
+tags: [API, Axios, Interceptor, Error Handling, Network]
+created: 2026-04-20
+---
+
+# [[API_Communication_Patterns]] (API 통신 패턴)
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> 서버와의 대화는 항상 '정중하되 의심하며' 처리하라. 모든 요청은 중앙 통제소(Interceptor)를 거치고 모든 에러는 시나리오가 준비되어 있어야 한다.
+
+## 📖 구조화된 지식 (Synthesized Content)
+- **Service Layer (서비스 레이어) 추상화**:
+    - 컴포넌트 내에 `axios` 코드를 기생시키지 마라. `userService.js`, `productApi.js` 처럼 API별로 모듈화하여 컴포넌트는 오직 '함수 호출'만 알게 하라.
+- **Axios Interceptors (심사 통로)**:
+    - 모든 요청에 인증 토큰을 자동으로 붙이거나, 백엔드에서 내려오는 401 에러를 가로채서 자동으로 토큰을 갱신(Silent Refresh)하는 로직을 중앙 집권화한다.
+- **Error Scenario Planning**:
+    - 400(잘못된 요청), 403(권한 없음), 500(서버 죽음) 등 각 에러 코드별로 사용자가 경험할 UI 처리 방침을 미리 약속하라.
+
+## ⚠️ 모순 및 업데이트 (RL Update)
+- 모든 통신에 Axios가 정답은 아니다. 브라우저 네이티브인 `fetch`로도 충분한 경우가 많으며, 라이브러리 의존성을 낮추는 것이 가벼운 앱을 만드는 첫걸음일 수 있다.
+
+## 🔗 지식 연결 (Graph)
+- Related: [[System_Protocol_Standard]] , [[React_State_Management_Strategy]]
+- Foundation: [[Reliability_Safety_First]]
@@ -0,0 +1,28 @@
+---
+title: 컴포넌트 설계 패턴 (Atomic & Composition)
+category: Software Architecture
+tags: [Design Pattern, Atomic Design, Composition, Architecture]
+created: 2026-04-20
+---
+
+# [[Component_Design_Patterns]] (컴포넌트 설계 패턴)
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> 컴포넌트는 작을수록 강하고, 단순할수록 재사용성이 극대화된다. 복잡한 컴포넌트는 여러 개의 작고 순수한(Pure) 컴포넌트로 해체하라.
+
+## 📖 구조화된 지식 (Synthesized Content)
+- **Container-Presenter 패턴**:
+    - **Container**: 데이터(State, API)를 가져오고 관리하는 '머리'.
+    - **Presenter**: 오직 Props만 받아 화면을 그리는 '몸통'. 스타일과 UI 구조에만 집중하여 테스트 가능성을 높인다.
+- **Compound Components (복합 컴포넌트)**:
+    - `<Select><Option /></Select>` 처럼 부모와 자식이 상태를 공유하며 하나의 긴밀한 기능을 수행하는 패턴. 사용자가 UI 구조를 자유롭게 배치할 수 있게 유연성을 제공한다.
+- **Atomic Design (원자 중심 설계)**:
+    - Atom(버튼, 입력창) $\rightarrow$ Molecule(검색바) $\rightarrow$ Organism(헤더) $\rightarrow$ Template $\rightarrow$ Page. 
+    - 가장 하위의 Atom이 프로젝트 전반에서 동일한 디자인 언어인 '디자인 토큰'을 반영하게 한다.
+
+## ⚠️ 모순 및 업데이트 (RL Update)
+- 너무 과도한 컴포넌트 분할은 프로토타이핑 속도를 늦춘다. 처음에는 크게 짜고, 중복이 발생하거나 복잡도가 높아질 때 '사후적 리팩토링'을 통해 분리하는 것이 실무적으로 현명하다.
+
+## 🔗 지식 연결 (Graph)
+- Related: [[Project_Architecture_Guidelines]] , [[Styling_Governance]]
+- Design: [[Accessibility_Inclusivity]]
@@ -0,0 +1,25 @@
+---
+title: 시스템 아키텍처와 관심사 분리 (Separation of Concerns)
+category: Software Architecture
+tags: [Architecture, SoC, Modular Design, Design Pattern]
+created: 2026-04-20
+---
+
+# 시스템 아키텍처와 관심사 분리 (SoC)
+
+## 🎯 개요 (Overview)
+복잡한 소프트웨어 시스템을 역할별로 구분된 독립적인 모듈로 나누어, 유지보수성과 확장성을 극대화하는 설계 철학입니다.
+
+## 🚀 계층구조 예시 (Layering Example)
+1.  **Logic Engine**: 순수 비즈니스 로직 및 규칙 수행 (예: `gameWorker.js`)
+2.  **State Manager**: 데이터의 중앙 집중 처리 (예: `TetrisGame.jsx`)
+3.  **View Layer**: 사용자 인터페이스 표현 및 렌더링 (예: React Components)
+
+## 💡 레슨 런 (Lesson Learned)
+> [!IMPORTANT]
+> **"코드의 경계가 명확할 때 시스템은 비로소 건강해진다."**
+> 기능을 추가할 때 기존 코드를 수정하기보다 새로운 모듈을 덧붙일 수 있는 구조를 고민해야 합니다.
+
+## 🔗 연결된 지식
+- [[WebWorker_Performance]]
+- [[Single_Source_of_Truth]]
@@ -0,0 +1,24 @@
+---
+title: 상태 관리의 단일 진실 공급원 (Single Source of Truth)
+category: Software Architecture
+tags: [State Management, Data Consistency, Redux, Architecture]
+created: 2026-04-20
+---
+
+# 상태 관리의 단일 진실 공급원 (Single Source of Truth)
+
+## 🎯 개요 (Overview)
+시스템의 핵심 데이터를 중앙 집중식으로 관리하여, 데이터 불일치(Inconsistency) 현상을 원천 차단하고 예측 가능한 데이터 흐름을 확보하는 설계 원칙입니다.
+
+## 🚀 주요 원칙 (Key Principles)
+- **단일 지점 정의 (Defined at Single Point)**: 상태는 오직 한 곳에서만 정의되고 관리되어야 합니다.
+- **예측 가능성 (Predictability)**: 상태 변경은 정해진 규칙(Action/Setter)을 통해서만 발생하여 디버깅을 용이하게 합니다.
+
+## 💡 레슨 런 (Lesson Learned)
+> [!TIP]
+> **"상태는 오직 한 곳에서만 정의하고, 모든 로직은 그 상태를 읽고 쓰는 방식으로 동작해야 한다."**
+> 코드의 파편화를 막기 위해 데이터의 책임 범위(Responsibility)를 명확히 하는 것이 대규모 프로젝트 성공의 열쇠입니다.
+
+## 🔗 연결된 지식
+- [[Separation_of_Concerns]]
+- [[Domain-Driven Design (DDD)]]
@@ -0,0 +1,24 @@
+---
+title: 시스템 시뮬레이션 설계 원리
+category: Systemic Modeling & Fun
+tags: [Simulation, Physics Engine, Systemic Modeling, Ruleset]
+created: 2026-04-20
+---
+
+# 시스템 시뮬레이션 설계 원리
+
+## 🎯 개요 (Overview)
+현실 세계의 물리 법칙이나 비즈니스 규칙을 수학적으로 정의하고, 이를 절대적으로 우회할 수 없는 시스템 내의 법(Law)으로 구축하는 설계 기법입니다.
+
+## 🚀 핵심 메커니즘 (Mechanisms)
+- **규칙 강제 (Ruleset Enforcement)**: 모든 상태 변화는 사전에 정의된 물리 엔진 함수(`checkCollision` 등)를 거쳐야만 합니다.
+- **수학적 모델링**: 변화를 시각적 묘사가 아닌 데이터와 수식으로 먼저 증명합니다.
+
+## 💡 레슨 런 (Lesson Learned)
+> [!TIP]
+> **"모든 시뮬레이션은 수학적 규칙을 절대 우회할 수 없도록 강제해야 한다."**
+> 이를 통해 단순한 게임을 넘어 자율주행, 물리 엔진 등 고도의 결정론적 시스템 모델링이 가능해집니다.
+
+## 🔗 연결된 지식
+- [[WebWorker_Performance]]
+- [[Separation_of_Concerns]]