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

10_Wiki/Topics/Architecture/Rule of Three (3의 법칙).md

@@ -1,21 +1,40 @@
+---
+id: wiki-2026-0508-rule-of-three-3의-법칙
+title: Rule of Three (3의 법칙)
+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
+---
+
 # [[Rule of Three (3의 법칙)]]
 
-## 📌 Brief Summary
+## 📌 한 줄 통찰 (The Karpathy Summary)
 **Rule of Three (3의 법칙)**은 소프트웨어 프로그래밍에서 유사한 코드 조각을 언제 리팩토링하여 중복을 피할지 결정하기 위한 경험 법칙(Rule of thumb)입니다 [1]. 마틴 파울러(Martin Fowler)의 저서를 통해 대중화되었으며 돈 로버츠(Don Roberts)가 제안한 "세 번 스트라이크면 리팩토링하라(Three strikes and you refactor)"는 개념으로 요약됩니다 [1, 2]. 즉, 처음이나 두 번째로 비슷한 코드를 작성할 때는 중복을 허용하되, 세 번째로 동일한 코드가 나타날 때는 새로운 프로시저나 메서드로 추출(Extract)하여 추상화해야 한다는 원칙입니다 [1, 3].
 
-## 📖 Core Content
+## 📖 구조화된 지식 (Synthesized Content)
 - **개념의 기원 및 정의**: 3의 법칙은 개발자가 리팩토링을 수행해야 하는 최적의 타이밍을 결정하는 지침입니다. 코드를 처음 작성할 때는 그냥 목적에 맞게 구현하고, 두 번째로 비슷한 작업을 할 때는 중복이 신경 쓰이더라도 그대로 진행하며, 세 번째로 동일한 형태의 작업이 반복될 때 비로소 리팩토링을 수행하라는 것입니다 [2].
 - **성급한 추상화(Premature Refactoring) 방지**: 리팩토링을 시도하는 많은 개발자가 범하는 실수는 코드를 무조건 작게 분할하여 추상화하려는 것입니다. 30줄짜리 코드를 가독성을 높인다는 명목하에 여러 클래스로 잘게 쪼개면, 코드를 읽을 때마다 함수 본문을 추적해야 하므로 오히려 유지보수를 어렵게 만듭니다 [4-6]. 3의 법칙은 사례가 3개 이상 모일 때까지 기다림으로써 공통점과 차이점을 더 명확히 파악하고 올바른 추상화를 찾을 수 있도록 돕습니다 [3].
 - **중복 허용 원칙 (WET - Write Everything Twice)**: 3의 법칙은 때로는 코드 중복을 그대로 두는 것이 더 나은 선택일 수 있음을 시사합니다 [7]. 두 번의 중복 코드만 있을 경우, 이를 리팩토링하고 잘못된 설계를 도입하는 비용이 단순히 중복을 유지보수하는 비용보다 더 클 수 있습니다 [8]. 하지만 세 번째 복사본이 나타나면 유지보수 비용이 리팩토링 비용을 초과하게 되므로 이때 개입합니다 [8]. 
 - **잘못된 추상화보다 저렴한 중복**: 개발자 샌디 메츠(Sandi Metz)는 "중복이 잘못된 추상화보다 훨씬 저렴하다(Duplication is far cheaper than the wrong abstraction)"라고 강조했습니다 [9]. 두 코드가 우연히 비슷해 보일 뿐, 서로 다른 개념을 나타내는 경우라면 중복을 유지하는 것이 낫습니다 [9].
 
-## ⚖️ Trade-offs & Caveats
+## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
 - **잘못된 추상화의 부작용**: 코드를 조기에 추상화할 경우, 새로운 요구사항이 생겼을 때 유연하게 대처하지 못하는 부작용이 발생합니다. 잘못된 추상화를 억지로 새로운 유즈케이스에 맞추기 위해 불리언 매개변수나 if 문 등을 추가하게 되며, 이는 코드를 끔찍하게 꼬이게 만듭니다 [7, 10]. 
 - **원칙의 도그마화 경계**: 3의 법칙은 어디까지나 경험에 기반한 가이드라인일 뿐 절대적인 규칙은 아닙니다 [1, 7]. 3번의 중복이 발생했다고 해서 기계적으로 추상화해야 하는 것은 아닙니다. 만약 추출하려는 추상화 개념에 명확한 이름을 붙일 수 없다면, 이는 아직 올바른 추상화를 찾지 못했다는 뜻이므로 억지로 리팩토링하지 말고 더 많은 중복 사례가 나타날 때까지 기다리는 것이 좋습니다 [7].
 - **코드 재사용과 유지보수의 역설**: 짧은 코드가 항상 가독성이 높은 것은 아닙니다 [11]. 단지 읽기 좋다는 이유만으로 한 번만 쓰일 헬퍼 함수를 무분별하게 만들어내면, 코드를 이해하기 위한 인지적 컨텍스트 스위칭 비용이 증가하여 유지보수를 저해하는 트레이드오프가 존재합니다 [6].
 
-## 🔗 Knowledge Connections
-
+## 🔗 지식 연결 (Graph)
 ### Related Concepts
 
 #### [관계 유형 A: 설계 철학 및 원칙]
@@ -55,4 +74,53 @@
   - 확장 방향: 3의 법칙을 지키지 않아 방치된 중복 코드로 인해 발생하는 유지보수 부채와, 반대로 너무 이른 추상화로 인해 발생하는 아키텍처 부채 중 어떤 부채가 이자가 더 비싼지 비교 연구해 볼 수 있습니다.
 
 ---
-*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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*