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

10_Wiki/Topics/Architecture/Red-Green Refactoring.md

@@ -1,6 +1,26 @@
+---
+id: wiki-2026-0508-red-green-refactoring
+title: Red Green Refactoring
+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
+---
+
 # [[Red-Green Refactoring]]
 
-## 📌 Brief Summary
+## 📌 한 줄 통찰 (The Karpathy Summary)
 Red-Green Refactoring은 애자일 소프트웨어 개발에서 가장 널리 사용되는 코드 리팩토링 기법으로, 테스트 주도 개발(TDD) 워크플로우에 깊이 뿌리를 두고 있습니다 [1, 2]. 실패하는 테스트를 먼저 작성하는 'Red' 단계, 최소한의 코드로 테스트를 통과시키는 'Green' 단계, 그리고 코드를 개선하는 'Refactor' 단계의 세 가지 반복적인 주기로 구성됩니다 [3-5]. 기능 추가와 구조 개선을 엄격히 분리하여, 기존 동작을 훼손하지 않으면서도 시스템의 유연성과 유지보수성을 지속적으로 높이는 데 목적이 있습니다 [3, 5].
 
 ## 📖 Core 소스
@@ -12,13 +32,12 @@ Red-Green Refactoring은 "테스트 우선(test-first)" 접근법을 따르며,
 
 이 기술은 본질적으로 새로운 기능을 시스템에 추가하는 첫 번째 파트(Red, Green)와 그 기능을 수행하는 코드를 개선하는 두 번째 파트(Refactor)로 나뉩니다 [3]. 가장 중요한 원칙은 워크플로우 중에 이 두 가지 작업(기능 추가와 리팩토링)을 동시에 수행해서는 안 된다는 것입니다 [3].
 
-## ⚖️ Trade-offs & Caveats
+## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
 *   **Green 단계에서의 품질 저하 감수:** Green 단계에서는 고품질의 완벽한 코드를 작성하는 것보다 빠른 시간 내에 테스트를 통과하는 '속도'를 우선시합니다 [5]. 이는 기능 구현을 빠르게 달성하는 대신 의도적으로 엉성한 코드를 임시로 남기게 되며, 후속 Refactor 단계를 거치지 않으면 기술 부채로 전락할 위험이 있습니다.
 *   **기능 추가와 리팩토링의 동시 수행 금지:** 워크플로우를 진행할 때 새로운 기능 추가(코드 작성)와 리팩토링을 절대 동시에 진행해서는 안 됩니다 [3]. 이 엄격한 분리를 따르지 않으면 디버깅이 어려워지고, 테스트의 신뢰성이 떨어지는 부작용이 발생합니다 [3, 6].
 *   **초기 테스트 작성의 한계:** 코드를 작성하기 전에 실패하는 테스트를 먼저 구현해야 하므로(Red 단계), 테스트를 작성하는 데 추가적인 시간적 제약과 노력이 요구됩니다 [3, 5]. 테스트 인프라가 부족한 상황에서는 리팩토링에 앞서 테스트부터 구축해야 하므로 적용이 어려울 수 있습니다 [7].
 
-## 🔗 Knowledge Connections
-
+## 🔗 지식 연결 (Graph)
 ### Related Concepts
 
 #### [방법론/개발 프로세스]
@@ -58,4 +77,61 @@ Red-Green Refactoring은 "테스트 우선(test-first)" 접근법을 따르며,
   - 확장 방향: Red-Green 리팩토링의 성공을 좌우하는 테스트 피라미드, 단위 테스트(Unit Test) 작성법 및 레거시 코드에 테스트 하네스를 구축하는 방법론으로 이해를 확장합니다 [4, 14, 15].
 
 ---
-*Last updated: 2026-05-03*
+*Last updated: 2026-05-03*
+
+## 📖 구조화된 지식 (Synthesized Content)
+
+**추출된 패턴:**
+> *(TODO)*
+
+**세부 내용:**
+- *(TODO)*
+
+## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*