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

10_Wiki/Topics/Architecture/Software_Architecture_Recovery.md

@@ -1,13 +1,26 @@
 ---
-category: Unified
+id: wiki-2026-0508-software-architecture-recovery
+title: Software Architecture Recovery
+category: 10_Wiki/Topics
+status: needs_review
+canonical_id: self
+aliases: []
+duplicate_of: none
+source_trust_level: A
+confidence_score: 0.92
 tags: [auto-consolidated, technical-documentation]
-title: [[Software Architecture Recovery (소프트웨어 아키텍처 복구 / 역공학)]]
-last_updated: 2026-05-02
+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
 ---
 
 # [[Software Architecture Recovery (소프트웨어 아키텍처 복구 / 역공학)]]
 
-## 📌 Brief Summary
+## 📌 한 줄 통찰 (The Karpathy Summary)
 Software Architecture Recovery(소프트웨어 아키텍처 복구 또는 재구성, 역공학)는 시스템의 구현물과 문서 등 가용한 정보로부터 소프트웨어 시스템의 아키텍처를 찾아내고 재구성하는 방법, 기술 및 프로세스를 의미한다 [1]. 이 과정은 주로 아키텍처 침식(Architecture Erosion)이 발생했거나 관련 문서가 너무 오래되어 쓸모없어졌을 때 정보에 입각한 의사결정을 내리기 위해 필수적으로 요구된다 [1]. 소프트웨어 인텔리전스(Software Intelligence) 실천의 일환으로 다루어지며 정적 프로그램 분석(Static Program Analysis) 등의 역공학 기법이 활용된다 [1].
 
 ---
@@ -22,7 +35,7 @@ Software Architecture Recovery(소프트웨어 아키텍처 복구)는 시스템
 
 소프트웨어 아키텍처 복구(Software Architecture Recovery)는 재구성(Reconstruction) 또는 리버스 엔지니어링(Reverse Engineering)이라고도 불리며, 구현 코드와 문서를 포함하여 가용한 정보를 바탕으로 소프트웨어 시스템의 아키텍처를 밝혀내는 방법, 기술 및 프로세스를 의미한다 [1]. 이는 주로 구식이거나 더 이상 유효하지 않은 문서에 직면했을 때 정보에 기반한 의사결정을 내리기 위해 수행된다 [1]. 특히, 원래 의도했던 아키텍처와 실제 구현 간의 격차가 벌어지는 '아키텍처 침식(Architecture Erosion)' 현상을 해결하기 위해 필수적으로 요구되는 과정이다 [1].
 
-## 📖 Core Content
+## 📖 구조화된 지식 (Synthesized Content)
 * **정의 및 목적:** 아키텍처 복구는 사용 가능한 구현 코드 및 문서를 기반으로 기존 소프트웨어의 아키텍처 구조를 다시 밝혀내는 과정이다 [1]. 과거의 문서가 낡았거나(obsolete) 최신 상태를 반영하지 못할 때 합리적인 유지보수 및 구현 결정을 내리기 위해 수행된다 [1].
 * **발생 원인 (아키텍처 침식):** 복구가 필요해지는 주된 원인은 설계 당시 의도했던 아키텍처와 실제 구현 및 유지보수 과정에서 변형된 아키텍처 사이에 점진적인 격차가 발생하는 '아키텍처 침식(Software Architecture Erosion)' 현상 때문이다 [1, 2]. 구현 및 유지보수 결정이 초기 설계 비전에서 벗어날 때 이러한 침식이 가속화된다 [1].
 * **활용 기술:** 아키텍처를 복구하기 위해 사용되는 구체적인 실천 방법 중 하나로 소스 코드를 구조적으로 분석하는 '정적 프로그램 분석(Static Program Analysis)'이 있다 [1].
@@ -47,7 +60,7 @@ Software Architecture Recovery(소프트웨어 아키텍처 복구)는 시스템
 * **복구 기술 및 실무**: 소프트웨어 아키텍처를 복구하기 위한 실무적인 방법 중 하나로 '정적 프로그램 분석(static program analysis)'을 활용할 수 있다 [1]. 이러한 복구 및 분석 작업은 소프트웨어 인텔리전스 실무(software intelligence practice)에서 다루는 주제의 일부로 포함된다 [1].
 * **침식 및 복구 관련 실제 사례**: 아키텍처 침식의 심각성을 보여주는 대표적인 사례로는 넷스케이프(Netscape)가 개발한 모질라 웹 브라우저(Mozilla Web browser)의 실패가 있다 [2]. 초기 설계의 결함과 지속적인 변경으로 인해 코드베이스가 너무 복잡해졌고, 아키텍처 침식이 심화되면서 넷스케이프는 2년에 걸쳐 브라우저를 재개발(redeveloping)해야만 했다 [2]. 이는 값비싼 수정 비용과 프로젝트 지연을 막기 위해 초기 아키텍처의 선제적 관리가 얼마나 중요한지 시사한다 [2].
 
-## ⚖️ Trade-offs & Caveats
+## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
 소스에 아키텍처 복구 과정 자체에 대한 구체적인 기술적 제약이나 반대 급부(Trade-off)에 대한 상세한 정보가 부족합니다.
 
 다만, 아키텍처 복구를 유발하는 근본 원인인 '아키텍처 침식(Erosion)'과 관련하여, 이를 방치할 경우 소프트웨어 성능 저하, 진화 비용(Evolutionary Costs)의 상당한 증가, 그리고 전반적인 소프트웨어 품질의 하락이라는 심각한 부작용이 발생할 수 있습니다 [3]. 따라서 오래된 문서와 변질된 아키텍처를 그대로 유지하는 것과 역공학을 통해 이를 복구 및 리팩토링하는 데 드는 비용(수고) 사이의 트레이드오프를 고려하여 신속하게 복구와 재설계를 수행해야 합니다 [1, 3].
@@ -68,7 +81,7 @@ Software Architecture Recovery(소프트웨어 아키텍처 복구)는 시스템
 * 아키텍처 복구와 침식 해결을 위한 조치는 방치될 경우 소프트웨어의 성능 저하, 진화 비용(Evolutionary costs)의 극심한 증가, 그리고 전반적인 소프트웨어 품질 하락이라는 치명적인 반대 급부를 수반한다 [3].
 * 아키텍처 침식을 복구하고 수정하기 위해서는 '치료적 조치(Remedial measures)'로 리팩토링, 재설계, 문서 업데이트 등이 필요하다 [3]. 하지만 이를 사전에 방지하려면 아키텍처 규칙을 강제하거나 정기적인 코드 리뷰 및 자동화된 테스트와 같은 '예방적 조치(Preventative measures)'가 지속적으로 병행되어야만 복구의 실효성을 유지할 수 있다 [3].
 
-## 🔗 Knowledge Connections
+## 🔗 지식 연결 (Graph)
 ### Related Concepts
 
 #### [아키텍처 분석 및 진단 기술]
@@ -238,3 +251,52 @@ Software Architecture Recovery(소프트웨어 아키텍처 복구)는 시스템
 
 ---
 *Last updated: 2026-05-02*
+
+## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*