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

10_Wiki/Topics/Architecture/Refactoring Techniques (리팩토링 기법).md

@@ -1,6 +1,26 @@
+---
+id: wiki-2026-0508-refactoring-techniques-리팩토링-기법
+title: Refactoring Techniques (리팩토링 기법)
+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
+---
+
 # [[Refactoring Techniques (리팩토링 기법)]]
 
-## 📌 Brief Summary
+## 📌 한 줄 통찰 (The Karpathy Summary)
 리팩토링 기법(Refactoring Techniques)은 소프트웨어의 외부적인 동작을 변경하지 않으면서 내부 구조를 개선하여 코드를 더 이해하기 쉽고 수정하기 경제적으로 만드는 일련의 체계적인 코드 변환 방법이다[1-3]. 이 기법들은 코드 스멜(Code Smell)과 기술 부채를 해결하기 위해 설계되었으며, 메서드 추출, 클래스 이동, 조건부 로직 단순화 등 매우 작고 안전한 마이크로 리팩토링(Micro-refactoring) 단위로 수행된다[4, 5]. 자동화된 테스트를 기반으로 점진적으로 수행되는 리팩토링은 소프트웨어 아키텍처의 부패를 방지하고 유지보수성 및 확장성을 크게 향상시킨다[3, 6].
 
 ## 📖 Core 대Content
@@ -13,7 +33,7 @@
 *   **메서드 호출 단순화 (Simplifying Method Calls):** 클래스 간 상호작용 인터페이스를 단순화하여 버그 발생 위험을 줄인다[34]. 과도하게 긴 매개변수 목록을 줄이기 위해 관련된 매개변수들을 묶어 '매개변수 객체 도입(Introduce Parameter Object)'을 사용하거나, 객체를 통째로 넘기는 '객체 통째로 넘기기(Preserve Whole Object)'를 활용한다[35-37]. 또한, 부수 효과(Side Effect)가 있는 수정 함수와 상태를 반환하는 질의 함수를 분리(Separate Query from Modifier)하여 안전성을 확보한다[17, 38].
 *   **일반화 처리 (Dealing with Generalization):** 상속 계층 구조를 최적화한다[39]. 형제 클래스 간 중복되는 메서드나 필드는 '메서드 올리기(Pull Up Method)'나 '필드 올리기(Pull Up Field)'를 통해 슈퍼클래스로 이동시켜 중복을 제거한다[10, 40, 41]. 특정 서브클래스에서만 의미 있는 기능은 '메서드 내리기(Push Down Method)'를 통해 하위로 이동시킨다[32, 42].
 
-## ⚖️ Trade-offs & Caveats
+## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
 리팩토링 기법 적용 시 다음과 같은 부작용과 제약 사항을 주의해야 한다.
 
 *   **버그 도입의 위험 및 테스트 의존성:** 아무리 의미를 보존하는 마이크로 리팩토링이라도 오작동을 유발할 수 있다. 따라서 기존 동작을 검증할 수 있는 포괄적이고 빠른 자동화된 테스트 스위트(Unit Tests 등)가 필수적이다[43-45]. 자동화된 테스트가 결여된 거대한 레거시 코드 시스템에서 맹목적인 리팩토링을 수행하는 것은 극도로 위험하다[46, 47].
@@ -22,8 +42,7 @@
 *   **과도한 엔지니어링 및 단기적 성능 저하:** 단순히 미래의 변경을 예측하고 불필요한 유연성이나 아키텍처 계층을 추가하는 '과도한 엔지니어링(Over-engineering)'의 위험이 있다[54, 55]. 또한, 임시 변수를 제거하고 질의(Query) 함수로 변경하는 기법 등은 단기적으로 동일한 계산을 여러 번 수행하게 만들어 약간의 성능(Runtime) 저하를 유발할 수 있다[56, 57].
 *   **AI 도구의 역설:** 최근 AI 코딩 도구(LLM)를 리팩토링에 활용할 때, 숙련된 개발자는 AI가 생성한 복잡한 코드를 검증하고 교정하는 데 오히려 더 많은 시간을 소비하여 생산성이 약 19% 하락할 수 있는 '생산성 역설' 문제가 제기되었다[58, 59].
 
-## 🔗 Knowledge Connections
-
+## 🔗 지식 연결 (Graph)
 ### Related Concepts
 
 #### [소프트웨어 품질 및 평가 지표]
@@ -69,4 +88,61 @@
   - 확장 방향: 리팩토링은 잦고 작은 코드 변경을 수반하므로, 변경된 코드가 시스템을 망가뜨리지 않았음을 즉각적으로 피드백해주는 빠르고 강력한 CI/CD 파이프라인의 구축 및 자동화 테스트 통합 전략으로 이어진다.
 
 ---
-*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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*