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

10_Wiki/Topics/Architecture/지식 증발 (Knowledge Vaporization).md

@@ -1,29 +1,40 @@
 ---
-id: P-REINFORCE-WIKI-9818F780
-category: Unified
+id: wiki-2026-0508-지식-증발-knowledge-vaporization
+title: 지식 증발 (Knowledge Vaporization)
+category: 10_Wiki/Topics
+status: needs_review
+canonical_id: self
+aliases: [P-REINFORCE-WIKI-9818F780]
+duplicate_of: none
+source_trust_level: A
 confidence_score: 0.95
-tags: ['지식-증발-(knowledge-vaporization)', 'software-architecture-erosion-(소프트웨어-아키텍처-침식)', 'architecture-decision-records-(adr)', 'knowledge-management-(지식-관리)', 'technical-debt-(기술-부채)', 'architecture-principles']
+tags: [지식-증발-(knowledge-vaporization), software-architecture-erosion-(소프트웨어-아키텍처-침식), architecture-decision-records-(adr), knowledge-management-(지식-관리), technical-debt-(기술-부채), architecture-principles]
+raw_sources: []
 last_reinforced: 2026-05-02
+github_commit: pending
+inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
+tech_stack:
+  language: unspecified
+  framework: unspecified
 ---
 
 # [[지식 증발 (Knowledge Vaporization)]]
 
-## 📌 Brief Summary
+## 📌 한 줄 통찰 (The Karpathy Summary)
 지식 증발(Knowledge Vaporization)은 시간이 지남에 따라 소프트웨어 아키텍처의 설계 배경, 논리 및 결정에 대한 지식이 이해관계자들의 기억에서 사라지거나 상실되는 현상입니다 [1, 2]. 이는 아키텍처 위반 및 기술 부채의 축적과 더불어 소프트웨어 아키텍처 침식(Architecture Erosion)을 유발하는 주요 원인으로 지목됩니다 [1].
 
-## 📖 Core Content
+## 📖 구조화된 지식 (Synthesized Content)
 *   **아키텍처 침식의 주요 원인:** 지식 증발은 시간이 지남에 따라 의도된 아키텍처와 실제로 구현된 아키텍처 간의 격차가 벌어지는 현상인 '소프트웨어 아키텍처 침식'을 일으키는 핵심 원인 중 하나입니다 [1].
 *   **암묵적 지식의 한계와 지식 격차:** 소프트웨어 아키텍처 지식은 흔히 암묵적(tacit)이며 주요 이해관계자들의 머릿속에만 머무르는 경향이 있습니다 [3]. 이로 인해 시간이 흐를수록 어떠한 기술적 배경에서 아키텍처 결정이 내려졌는지 그 이유와 배경이 잊혀지기 쉽습니다 [2]. 
 *   **설계 추론의 실패 유발:** 아키텍처 설계 문제는 매우 복잡하고 상호 의존적이기 때문에, 지식 증발로 발생한 설계 논리(Design reasoning)에 대한 지식 격차는 궁극적으로 잘못된 소프트웨어 아키텍처 설계로 이어지게 됩니다 [3].
 *   **해결 및 방어 체계:** 지식 증발을 방지하기 위해서는 지식 관리(Knowledge Management) 및 의사소통 활동이 필수적입니다 [3]. 결정의 맥락, 정당성, 기각된 대안, 장기적 위험과 결과 등을 아키텍처 결정 기록(ADR, Architecture Decision Records)으로 문서화하여 변경 이력을 지속적으로 관리하는 체계가 필요합니다 [2, 4].
 
-## ⚖️ Trade-offs & Caveats
+## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
 소스에 관련 정보가 부족합니다. (지식 증발 현상에 대응하는 기술적 최적화 방법이 가지는 구체적인 부작용이나 구조적인 반대 급부에 대해서는 소스에 상세히 서술되어 있지 않습니다.)
 
 다만 제한적으로 확인되는 맥락에 따르면, 지식 증발을 막기 위해 ADR과 같은 문서를 위키 등 접근 가능한 저장소에 지속적으로 관리해야 합니다 [4]. 이러한 아키텍처 지식의 관리 및 문서화가 누락되거나 이해되지 않으면, 문제 해결 없이 동일한 논의만 반복되는 상황이 발생하여 개발 팀의 진행을 방해할 수 있는 위험(Anti-pattern)이 존재합니다 [4]. 
 
-## 🔗 Knowledge Connections
-
+## 🔗 지식 연결 (Graph)
 ### Related Concepts
 
 #### [관계 유형 A: 아키텍처/기반 기술]
@@ -60,4 +71,53 @@ last_reinforced: 2026-05-02
   - 확장 방향: 시스템 설계가 그 시스템을 설계하는 조직의 소통 구조를 모방한다는 법칙으로, 조직 내 소통의 부재나 지식 증발이 최종 시스템 아키텍처에 어떤 형태적 제약을 가하는지 연결 지어 탐구할 수 있습니다 [7].
 
 ---
-*Last updated: 2026-05-02*
+*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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*