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

10_Wiki/Topics/Architecture/Polymorphism (다형성).md

@@ -1,9 +1,29 @@
+---
+id: wiki-2026-0508-polymorphism-다형성
+title: Polymorphism (다형성)
+category: 10_Wiki/Topics
+status: needs_review
+canonical_id: self
+aliases: []
+duplicate_of: none
+source_trust_level: A
+confidence_score: 0.92
+tags: [uncategorized]
+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
+---
+
 # [[Polymorphism (다형성)]]
 
-## 📌 Brief Summary
+## 📌 한 줄 통찰 (The Karpathy Summary)
 다형성(Polymorphism)은 객체 지향 프로그래밍에서 객체가 자신의 타입에 따라 적절한 동작을 스스로 수행하게 하는 메커니즘이다 [1, 2]. 리팩토링 원칙에서 다형성은 주로 길고 복잡한 조건문(switch 또는 if-else)을 하위 클래스의 재정의된 메서드로 대체하여 코드의 중복을 제거하고 명확성을 높이는 데 사용된다 [1, 3, 4]. 이를 통해 새로운 타입이나 조건이 추가될 때 기존 코드를 수정할 필요 없이 새로운 클래스를 추가하기만 하면 되는 유연성을 제공하여 아키텍처의 변경을 관리하기 쉽게 만든다 [3, 5, 6].
 
-## 📖 Core Content
+## 📖 구조화된 지식 (Synthesized Content)
 * **조건부 로직의 단순화 및 유연성 확보:** 
   절차지향적 코드에서 흔히 나타나는 긴 분기문(Switch 구문 등)은 중복을 유발하고, 새로운 조건이 추가될 때마다 관련된 모든 조건문을 찾아 수정해야 하므로 유지보수를 매우 어렵게 만든다 [3, 7]. 다형성을 활용하면 명시적인 조건문을 다형성 메시지로 변경하여 분기 로직을 인코딩할 수 있으며, 객체에게 타입을 묻고 행동을 결정하는 대신 단순히 행동을 호출(invoke)하여 객체 스스로 올바른 동작을 수행하도록 만들 수 있다 [2, 4, 5].
 
@@ -16,14 +36,13 @@
 * **Null 객체 패턴(Introduce Null Object)을 통한 다형성 적용:**
   Null 값을 확인하는 반복적인 조건문 역시 다형성을 통해 우아하게 해결할 수 있다 [2]. Null 값을 나타내는 특수 하위 클래스(Null Object)를 생성하고 해당 타입의 기본 동작을 재정의함으로써, 명시적인 null 체크 로직 없이도 다형성 호출을 통해 객체가 적절한 행동을 위임받아 수행하게 된다 [2, 12].
 
-## ⚖️ Trade-offs & Caveats
+## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
 * **과도한 엔지니어링(Overkill) 위험:** 
   단일 메서드에만 영향을 미치는 소수의 조건만 존재하며 향후 조건이 변경되거나 확장될 것으로 예상되지 않는 경우, 상속과 다형성을 도입하는 것은 오히려 불필요한 복잡성을 초래할 수 있다 [13]. 이 경우에는 다형성 대신 '매개변수를 명시적 메서드로 바꾸기(Replace Parameter with Explicit Methods)' 같은 단순한 기법이 더 적합할 수 있다 [13].
 * **객체 생명주기에 따른 상속 적용 제약:**
   하위 클래스를 활용해 다형성을 구현할 때 주의해야 할 가장 큰 제약은 '객체는 생성된 이후 자신의 클래스를 런타임에 변경할 수 없다'는 점이다 [14]. 객체의 타입 코드나 상태가 수명 주기 동안 변경되어야 하거나, 해당 클래스가 이미 다른 이유로 하위 클래스화되어 있다면 단순 상속을 사용할 수 없다 [9, 15]. 이러한 제약 상황에서는 상속 대신 '상태 패턴(State Pattern)'이나 '전략 패턴(Strategy Pattern)'을 결합하여 간접 참조(indirection) 계층을 추가하는 구조적 타협이 필요하다 [14-16].
 
-## 🔗 Knowledge Connections
-
+## 🔗 지식 연결 (Graph)
 ### Related Concepts
 
 #### [아키텍처 및 기반 원칙]
@@ -71,4 +90,53 @@
   - 확장 방향: 다형성이 필요한 상황을 식별할 수 있는 다양한 징후들(예: 반복되는 조건문, 기능 욕심, 데이터 뭉치 등)을 어떻게 민감하게 포착하고 평가할 것인지에 대한 통찰로 확장이 가능하다.
 
 ---
-*Last updated: 2026-05-03*
+*Last updated: 2026-05-03*
+
+## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*