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

10_Wiki/Topics/Architecture/Legacy System Migration.md

@@ -1,7 +1,27 @@
-## 📌 Brief Summary
+---
+id: wiki-2026-0508-legacy-system-migration
+title: Legacy System Migration
+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
+---
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
 레거시 시스템 마이그레이션은 낡은 아키텍처와 코드를 최신 기술 표준으로 전환하여 시스템의 유지보수성, 안정성, 성능을 개선하는 공정이다. 프론트엔드 환경에서는 전체 시스템을 한 번에 재작성하는 위험을 피하기 위해, 기능 개발과 병행 가능한 **점진적 마이그레이션(Incremental Migration)** 전략을 핵심으로 한다.
 
-## 📖 Core Content
+## 📖 구조화된 지식 (Synthesized Content)
 1. **점진적 마이그레이션 전략 (Refactor, Do Not Rewrite)**
    - 시스템 전체를 중단시키지 않고 기능 단위로 하나씩 새로운 스택으로 옮기는 방식을 취한다.
    - 예: Context API에서 Zustand로 전환 시, 단순한 전역 알림 기능부터 시작하여 점진적으로 복잡한 결제/상태 로직으로 범위를 확대한다.
@@ -15,12 +35,12 @@
 4. **안전망으로서의 테스트**
    - 마이그레이션 시작 전 기존 동작을 검증하는 테스트 코드를 우선 작성하여, 변경 과정에서 발생할 수 있는 기능 회귀(Regression)를 방지한다.
 
-## ⚖️ Trade-offs & Caveats
+## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
 - **과도기적 복잡성**: 점진적 마이그레이션 중에는 두 가지 이상의 기술 스택(예: Redux와 Zustand)이 공존하게 되어 번들 사이즈가 일시적으로 증가하고 데이터 동기화 로직이 복잡해질 수 있다.
 - **개발 속도 저하**: 새로운 기능 개발과 마이그레이션을 병행할 경우, 리팩토링 비용으로 인해 단기적인 제품 출시 속도가 느려질 수 있다.
 - **기술 부채의 잔존**: 부분적인 마이그레이션이 중단될 경우, 오히려 시스템이 더 파편화된 상태로 남게 될 위험이 있으므로 명확한 마이그레이션 로드맵이 필요하다.
 
-## 🔗 Knowledge Connections
+## 🔗 지식 연결 (Graph)
 ### Related Concepts (Auto-Linked)
 * [[Architecture]]
 * [[JavaScript]]
@@ -54,3 +74,52 @@
 - **Technical Debt Management**
 - **Clean Code & Refactoring Patterns**
 - **Strangler Fig Pattern in Software Architecture**
+
+## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*