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

10_Wiki/Topics/Architecture/Object-Oriented-Programming.md

@@ -1,13 +1,26 @@
 ---
-category: Unified
+id: wiki-2026-0508-object-oriented-programming
+title: Object Oriented Programming
+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: Object-Oriented Programming (OOP, 객체 지향 프로그래밍)
-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
 ---
 
 # Object-Oriented Programming (OOP, 객체 지향 프로그래밍)
 
-## 📌 Brief Summary
+## 📌 한 줄 통찰 (The Karpathy Summary)
 > "데이터와 행위를 하나의 '객체'라는 유기체로 묶고, 이들의 소통과 연합으로 거대하고 견고한 소프트웨어 제국을 건설하라" — 프로그램을 단순히 명령어의 나열이 아닌 독립된 단위인 '객체'들의 집합으로 파악하여 유연성과 재사용성을 극대화하는 프로그래밍 패러다임.
 
 ---
@@ -18,7 +31,7 @@ last_updated: 2026-05-02
 
 객체 지향 프로그래밍(OOP)은 애플리케이션의 데이터와 비즈니스 로직을 객체와 클래스 중심으로 구성하여 코드의 이해도, 유연성, 유지보수성을 높이는 프로그래밍 패러다임이다 [1-3]. 대규모 소프트웨어 시스템에서 OOP 코드베이스를 읽는 행위는 분산된 클래스 계층 구조와 메서드 호출 네트워크를 이리저리 이동하며 추적하는 과정을 수반한다 [3]. 따라서 효과적인 코드베이스 해독을 위해서는 SOLID 원칙이나 디자인 패턴과 같은 OOP 기반의 설계 규칙을 이해하는 것이 필수적이다 [2, 4].
 
-## 📖 Core Content
+## 📖 구조화된 지식 (Synthesized Content)
 - **추출된 패턴:** "Modular Autonomy and Interface-based Contract" — 내부의 구현 상세는 감추고(Encapsulation), 공통 기능은 물려받으며(Inheritance), 동일한 메시지에도 각자 다르게 반응(Polymorphism)하게 함으로써 코드 간의 결합도를 낮추고 변화에 강한 구조를 만드는 패턴.
 - **4대 핵심 원칙:**
     - **Encapsulation (캡슐화):** 데이터와 함수를 하나로 묶고 외부 접근을 제한하여 무결성 보호.
@@ -48,7 +61,7 @@ last_updated: 2026-05-02
 * **객체 지향 남용 (Object-Orientation Abusers)**
   코드베이스를 분석할 때 주의 깊게 살펴야 하는 부분 중 하나는 OOP의 특성을 잘못 활용해 발생한 '코드 냄새(Code Smells)'이다. 'Switch문 남용(Switch Statements)', '임시 필드(Temporary Field)', '거부된 유산(Refused Bequest)'과 같은 객체 지향 남용 사례들은 코드의 확장성을 저해하고 탐색을 어렵게 만든다 [12, 13].
 
-## ⚖️ Trade-offs & Caveats
+## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
 - **과거 데이터와의 충돌:** 상속이 만능이라는 믿음에서 벗어나, 과도한 상속 깊이가 코드를 더 복잡하게 만드는 문제를 해결하기 위해 '상속보다는 합성(Composition over Inheritance)'을 지향하는 실무적 지침이 정립됨.
 - **정책 변화:** Antigravity 프로젝트의 모든 에이전트 스킬과 데이터 핸들러는 SOLID 원칙을 준수하는 OOP 아키텍처로 설계되어 있어, 새로운 기능 추가 시 기존 코드의 수정 없이 확장이 가능함.
 
@@ -63,7 +76,7 @@ last_updated: 2026-05-02
 * **도구 의존성 증가:** 수천 개의 클래스로 이루어진 복잡한 네트워크를 수동으로 추적하는 것은 불가능에 가깝기 때문에, IDE의 기호 탐색, 참조 찾기 기능이나 LSP(Language Server Protocol), 정적 분석 도구 등에 대한 의존도가 극도로 높아진다 [3, 15, 16].
 * **추상화로 인한 런타임 파악의 어려움:** 인터페이스와 다형성(Polymorphism)을 통한 추상화는 정적 코드만으로는 실제 런타임에 어떤 객체의 메서드가 호출되는지 파악하기 어렵게 만든다. 이 때문에 동적인 동작 특성을 파악하려면 중단점(Breakpoints)이나 디버거를 통한 실행 추적이 강제될 수 있다 [12, 17, 18].
 
-## 🔗 Knowledge Connections
+## 🔗 지식 연결 (Graph)
 - [[Iterative-Development-Models|Iterative-Development-Models]], [[Microservices-Architecture|Microservices-Architecture]],[[_system|system]]-Design-for-AI-Scale, Design-Patterns-in-AI
 - **Raw Source:** 10_Wiki/Topics/AI/Object-Oriented-Programming.md
 
@@ -152,4 +165,47 @@ last_updated: 2026-05-02
 ## 🧪 검증 상태 (Validation)
 - **정보 상태**: 검증 완료 (Verified)
 - **출처 신뢰도**: A
-- **검토 이유**: 현대 소프트웨어 개발의 주류 패러다임인 OOP의 핵심 원리를 정립하고, 대규모 시스템의 지속 가능한 설계를 위한 기반 지식 통합.
+- **검토 이유**: 현대 소프트웨어 개발의 주류 패러다임인 OOP의 핵심 원리를 정립하고, 대규모 시스템의 지속 가능한 설계를 위한 기반 지식 통합.
+
+## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
+
+**언제 이 지식을 쓰는가:**
+- *(TODO)*
+
+**언제 쓰면 안 되는가:**
+- *(TODO)*
+
+## 🧬 중복 검사 (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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*