feat: Wiki 지식 자산 업데이트 - UX Scenarios, Frontend, Game Design, Topics 추가 [2026-05-08]

10_Wiki/Topics/Architecture/Bottom-Up-Approach.md

@@ -1,13 +1,26 @@
 ---
-category: Unified
+id: wiki-2026-0508-bottom-up-approach
+title: Bottom Up Approach
+category: 10_Wiki/Topics
+status: needs_review
+canonical_id: self
+aliases: []
+duplicate_of: none
+source_trust_level: A
+confidence_score: 0.92
 tags: [auto-consolidated, technical-documentation]
-title: [[Bottom-Up-Approach|Bottom-Up-Approach]]
-last_updated: 2026-05-02
+raw_sources: []
+last_reinforced: 2026-05-08
+github_commit: pending
+inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
+tech_stack:
+  language: unspecified
+  framework: unspecified
 ---
 
 # [[Bottom-Up-Approach|Bottom-Up-Approach]]
 
-## 📌 Brief Summary
+## 📌 한 줄 통찰 (The Karpathy Summary)
 > "작은 성공의 조립: 거창한 전체 계획부터 세우지 않고, 가장 구체적이고 당장 실행 가능한 작은 부품들을 먼저 만들어 검증한 뒤 이들을 연결하여 점진적으로 거대한 시스템을 완성하는 실용주의적 전략."
 
 ---
@@ -18,7 +31,7 @@ last_updated: 2026-05-02
 
 상향식 탐색(Bottom-Up Approach)은 데이터가 최종적으로 도달하거나 영속화되는 지점(예: 데이터베이스 스토리지), 혹은 개발자가 변경해야 하는 구체적인 코드 위치에서 시작하여 이를 호출하는 상위 함수나 클래스를 역추적하며 코드베이스를 이해하는 전략이다 [1, 2]. 이 방식은 주로 버그 수정, 성능 최적화, 부수 효과(Side effect) 분석 시 핵심적으로 활용되며, 작업에 필요한 종속성(Dependent graph)에만 집중하여 불필요한 코드 파악에 드는 시간을 줄여준다 [1, 2].
 
-## 📖 Core Content
+## 📖 구조화된 지식 (Synthesized Content)
 상향식 접근법(Bottom-Up-Approach)은 기초적인 요소들에서 시작하여 점차 상위 수준의 종합적인 시스템으로 나아가는 방식입니다.
 
 1.  **특징**:
@@ -42,7 +55,7 @@ last_updated: 2026-05-02
 - **적용 시점과 장점**: 버그를 수정하거나, 성능을 최적화하고, 특정 수정 사항에 대한 부수 효과를 분석해야 할 때 가장 효과적이다 [2]. 본인이 작업하는 영역과 관련된 종속성만 파악하면 되므로, 개발자가 전혀 신경 쓸 필요 없는 시스템 상층부의 무관한 정보까지 학습해야 하는 인지적 과부하를 방지할 수 있다 [1]. 문서화되지 않은 소프트웨어를 다룰 때 변경이 필요한 특정 부분에만 집중하는 매우 실용적인 접근법이다 [3].
 - **하이브리드 전략 (Hybrid Strategy)**: 대규모 시스템을 완벽하게 그리기 위해 상향식 탐색은 단독으로 쓰이기보다 하향식 탐색(Top-down)과 혼합되어 사용된다 [4]. 하향식으로 비즈니스 의도와 전체 요청 흐름을 파악하고, 상향식으로 기술적인 한계를 확인하며 그 중간 지점에서 일관된 이해를 형성하는 과정이 필수적이다 [2, 4].
 
-## ⚖️ Trade-offs & Caveats
+## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
 - **과거 데이터와의 충돌**: 과거에는 완벽한 초기 설계(Top-down) 정책이 실패를 막는 유일한 길이라 믿었으나, 현대의 애자일 및 스타트업 정책은 빠른 실패와 학습이 가능한 '상향식 실행 정책'을 압도적으로 선호함(RL Update).
 - **정책 변화(RL Update)**: 지식 관리 정책(예: 이 Wiki)에서, 전체 카테고리부터 완벽히 짜는 대신 개별 지식 카드들을 먼저 풍성하게 주입하고 나중에 이들의 연결(Graph)을 통해 구조를 발견하는 '상향식 지식 생성 정책'이 채택됨 ([[Ps-Reinforce|Ps-Reinforce]] 핵심 철학).
 
@@ -54,7 +67,7 @@ last_updated: 2026-05-02
 
 상향식 탐색은 변경해야 하는 코드와 기술적 제약 사항을 명확하고 효율적으로 파악할 수 있게 해주지만, 코드베이스 전체의 아키텍처나 고수준의 비즈니스 의도(Intent)를 즉각적으로 이해하기는 어렵다는 명확한 한계가 있다 [1, 4]. 상향식만 고집할 경우 큰 그림을 놓치고 지엽적인 기술 구현이나 물리적 제약에만 시야가 매몰될 수 있다 [2, 4]. 따라서 상향식으로 코드의 종속성을 파악한 이후에는, 시스템 최상위 디렉토리의 목적이나 비즈니스 맥락을 알고 있는 팀원에게 설명을 요청하거나 하향식 탐색을 병행하여 좁은 이해의 폭을 넓히고 보완하는 작업이 필요하다 [1, 4].
 
-## 🔗 Knowledge Connections
+## 🔗 지식 연결 (Graph)
 - [[Big-Picture|Big-Picture]], [[Analysis|Analysis]], [[Emergence|Emergence]], [[Agile-Philosophy|Agile-Philosophy]], [[Rapid-Prototyping|Rapid-Prototyping]]
 - **Modern Tech/Tools**: Component-based UI (React), Microservices, Modular [[Hardware|Hardware]].
 ---
@@ -140,3 +153,52 @@ last_updated: 2026-05-02
 
 ---
 *Last updated: 2026-05-02*
+
+## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
+
+**언제 이 지식을 쓰는가:**
+- *(TODO)*
+
+**언제 쓰면 안 되는가:**
+- *(TODO)*
+
+## 🧪 검증 상태 (Validation)
+
+- **정보 상태:** needs_review
+- **출처 신뢰도:** A
+- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
+
+## 🧬 중복 검사 (Duplicate Check)
+
+- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
+- **처리 방식:** UPDATE (자동 정규화)
+- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
+
+## 🕓 변경 이력 (Changelog)
+
+| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
+|------|-----------|-----------|--------|
+| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
+
+## 💻 코드 패턴 (Code Patterns)
+
+**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
+
+```text
+# TODO
+```
+
+## 🤔 의사결정 기준 (Decision Criteria)
+
+**선택 A를 써야 할 때:**
+- *(TODO)*
+
+**선택 B를 써야 할 때:**
+- *(TODO)*
+
+**기본값:**
+> *(TODO)*
+
+## ❌ 안티패턴 (Anti-Patterns)
+
+- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*