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

10_Wiki/Topics/Architecture/리팩토링 원칙.md

@@ -1,10 +1,29 @@
+---
+id: wiki-2026-0508-리팩토링-원칙
+title: 리팩토링 원칙
+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
+---
+
 # [[리팩토링 원칙]]
 
-## 📌 Brief Summary
+## 📌 한 줄 통찰 (The Karpathy Summary)
 리팩토링(Refactoring)은 소프트웨어의 외부적 동작(관측 가능한 동작)을 변경하지 않으면서 내부 구조를 개선하여 코드를 더 이해하기 쉽고 수정하기 경제적으로 만드는 체계적이고 훈련된 과정입니다 [1-4]. 이는 단순히 코드를 예쁘게 꾸미는 것이 아니라, 기술 부채를 체계적으로 상환하고 소프트웨어의 생애 주기 동안 아키텍처의 부패를 방지하기 위한 핵심 전략입니다 [5-7]. 올바른 리팩토링은 향후 새로운 기능 추가와 버그 수정을 가속화하며, 전체적인 개발 및 유지보수 비용(ROI)을 낮추는 경제적 필수 활동입니다 [8-10].
 
-## 📖 Core Content
-
+## 📖 구조화된 지식 (Synthesized Content)
 *   **두 개의 모자 (Two Hats) 원칙**
     소프트웨어 개발 시 '기능 추가'와 '리팩토링'의 활동은 명확히 분리되어야 합니다 [11-13]. '기능 추가' 모자를 썼을 때는 기존 코드를 재구성하지 않고 새로운 동작을 추가하는 데만 집중하며, '리팩토링' 모자를 썼을 때는 기능을 추가하지 않고 오직 코드 구조 개선에만 전념해야 디버깅 효율이 급감하는 것을 막을 수 있습니다 [13-15].
 *   **경제성 중심의 판단 (Economic Justification)**
@@ -16,16 +35,14 @@
 *   **코드 스멜 (Code Smells) 인식**
     리팩토링이 필요한 시점을 알려주는 구체적인 신호로, 긴 함수(Long Method), 중복 코드(Duplicate Code), 데이터 뭉치(Data Clumps), 기능 욕심(Feature Envy) 등이 있습니다 [32-34]. 이러한 스멜을 인지하고 해당 문제에 맞는 적절한 리팩토링 카탈로그 기법(예: 함수 추출하기, 메서드 이동 등)을 선별해 적용해야 합니다 [34-36].
 
-## ⚖️ Trade-offs & Caveats
-
+## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
 *   **레거시 코드의 딜레마 (Legacy Code Dilemma)**: 리팩토링을 안전하게 수행하려면 테스트가 필요하지만, 테스트가 없는 얽힌 레거시 코드에 테스트를 추가하려면 코드를 리팩토링하여 의존성을 분리해야 하는 모순이 발생합니다. 이 경우 '접점(Seam)'을 찾아 소스코드를 최소한으로 건드리면서 우회적으로 테스트를 덮어씌워야 하는 극도의 주의가 요구됩니다 [37-40].
 *   **버그 유입의 위험성**: 리팩토링은 코드베이스의 구조를 재배치하므로, 단위 테스트라는 안전망이 부족하거나 한 번에 너무 큰 규모로 변경을 시도할 경우 기존 기능 파괴나 새로운 회귀 버그(Regression bug)를 유발할 수 있는 중대한 위험(Risky Change)이 따릅니다 [31, 41-43].
 *   **단기적 속도 저하 및 오버헤드 인식**: 리팩토링을 진행하는 동안에는 일시적으로 기능 추가 속도가 저하될 수 있으며, 개발 시간을 소모하게 됩니다. 때문에 일정이 매우 촉박하거나 마감 시한이 코앞인 경우 리팩토링을 유보해야 할 수 있습니다 [9, 23, 44, 45].
 *   **재작성(Rewrite)과의 경계**: 시스템이 심각하게 부패하여 결함이 넘치고 도저히 안정화할 수 없는 최악의 경우에는, 리팩토링을 시도하는 것보다 처음부터 새롭게 재작성(Rewrite from scratch)하는 것이 오히려 경제적일 수 있습니다 [46, 47].
 *   **지나친 공학적 완벽주의의 함정**: 단순히 클린 코드를 위한 미학적 이유나, 존재하지도 않는 미래의 확장을 위해 과도하게 리팩토링(추측성 일반화 등)을 수행하면 시스템을 불필요하게 복잡하게 만들 수 있습니다 [48, 49].
 
-## 🔗 Knowledge Connections
-
+## 🔗 지식 연결 (Graph)
 ### Related Concepts
 
 #### [관계 유형 A: 개발 및 검증 방법론 (Development & Testing Methodologies)]
@@ -73,4 +90,53 @@
   - 확장 방향: 리팩토링이 가장 활발히 요구되고 그 가치를 발휘하는 개발 환경인 애자일, eXtreme Programming(XP) 문화, 그리고 지속적 통합(CI/CD) 파이프라인과의 강력한 연관성을 탐구합니다.
 
 ---
-*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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*