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

10_Wiki/Topics/Other/아키텍처_드리프트_Architectural_Drift.md

@@ -1,17 +1,29 @@
 ---
-category: Unified
+id: wiki-2026-0508-아키텍처-드리프트-architectural-drift
+title: 아키텍처 드리프트 Architectural Drift
+category: 10_Wiki/Topics
+status: needs_review
+canonical_id: self
+aliases: []
+duplicate_of: none
+source_trust_level: A
+confidence_score: 0.92
 tags: [auto-wikified, technical-documentation]
-title: 아키텍처 드리프트 (Architectural Drift)
-description: "아키텍처 드리프트(Architectural Drift)는 소프트웨어가 진화하고 업데이트되며 새로운 기능이 추가됨에 따라, 시스템의 실제 구현 구조가 원래 설계되었던 초기 아키텍처에서 점차 멀어지는 현상을 의미합니다 [1]."
-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
 ---
 
 # 아키텍처 드리프트 (Architectural Drift)
 
-## 📌 Brief Summary
+## 📌 한 줄 통찰 (The Karpathy Summary)
 아키텍처 드리프트(Architectural Drift)는 소프트웨어가 진화하고 업데이트되며 새로운 기능이 추가됨에 따라, 시스템의 실제 구현 구조가 원래 설계되었던 초기 아키텍처에서 점차 멀어지는 현상을 의미합니다 [1]. 이는 아키텍처 다이어그램 등 설계 문서에 대한 수동 업데이트가 많은 시간을 소모하고 우선순위에서 밀려 방치될 때 주로 발생합니다 [2]. 결과적으로 설계 문서는 정적인 유물로 남고 실제 소프트웨어는 점점 더 동적이고 복잡해지는 단절(Disconnect)을 초래하며, 시스템 이해와 유지보수를 어렵게 만듭니다 [1, 2].
 
-## 📖 Core Content
+## 📖 구조화된 지식 (Synthesized Content)
 *   **발생 원인 및 환경:** 
     현대의 소프트웨어 개발은 애자일 환경과 클라우드 마이그레이션 등을 통해 빠르게 변화합니다 [3]. 소프트웨어가 새로운 요구사항에 맞춰 기능 업데이트를 반복하는 동안, 아키텍처의 중심적인 뼈대는 서서히 진화하지만 개별 컴포넌트의 동작과 상호작용은 끊임없이 변화합니다 [4]. 특히 모놀리식 구조에서 마이크로서비스로 전환하여 개발 속도가 비약적으로 빨라질 때, 아키텍처를 지속적으로 캡처하고 모니터링하지 않으면 아키텍처 드리프트가 급격히 가속화됩니다 [2].
 *   **부정적 파급 효과:**
@@ -19,14 +31,13 @@ last_updated: 2026-05-02
 *   **해결 및 방지 접근법:**
     과거와 같은 정적이고 이론적인 문서화 방식에서 벗어나 실시간으로 변화를 감지할 수 있는 동적이고 살아있는 도구(Dynamic, living tools)의 도입이 요구됩니다 [7]. '코드로서의 아키텍처(Architecture as code)' 기능을 갖춘 자동화 솔루션을 활용하여 라이브 애플리케이션의 실제 런타임 흐름을 C4 모델 등의 참조 다이어그램과 지속적으로 정렬시키고, 아키텍처의 변형을 실시간으로 감지(Detecting architectural drift)하여 의도된 설계와 일치시키는 과정이 필수적입니다 [8, 9].
 
-## ⚖️ Trade-offs & Caveats
+## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
 *   **다이어그램 최신화의 수동 오버헤드 vs 문서의 신뢰성:** 
     아키텍처 다이어그램은 복잡한 시스템 구조를 소통하는 훌륭한 도구이지만, 수동으로 지속적인 최신화를 유지하는 데는 막대한 시간과 노력이 소모됩니다 [2]. 다이어그램을 최신 상태로 유지하지 않으면 잘못된 정보를 제공하게 되어 오히려 시스템 독해와 파악에 큰 해악을 끼칩니다 [5, 10]. 따라서 관리 리소스를 들이는 것과 자동화 도구 도입 사이에서 트레이드오프가 발생합니다.
 *   **자동화 도구(역공학) 의존의 한계:** 
     과거 초기 UML 모델링 도구(예: IBM Rhapsody)들은 코드 생성 및 왕복 엔지니어링(Round-tripping)을 통해 코드와 모델의 동기화를 시도했으나, 개발자들이 자동 생성된 코드의 품질에 만족하지 않고 자신만의 선호 프레임워크로 코드를 작성하면서 결국 도구가 외면받고 다이어그램이 무의미해진 실패 사례가 존재합니다 [11]. 또한 다중 언어와 프레임워크가 섞인 분산 애플리케이션에서 단순히 코드를 역공학(Reverse-engineering)하여 다이어그램을 생성하는 것은 해석하기 지나치게 복잡한 결과물을 낼 위험이 있습니다 [12]. 자동화 툴은 실효성 있는 높은 수준의 추상화를 제공하지 않으면 활용도가 떨어집니다.
 
-## 🔗 Knowledge Connections
-
+## 🔗 지식 연결 (Graph)
 ### Related Concepts
 
 #### [관계 유형 A (아키텍처/기반 기술)]
@@ -69,4 +80,53 @@ last_updated: 2026-05-02
   - 확장 방향: 정적인 소스 코드를 읽는 것만으로는 완전히 파악할 수 없는 객체의 수명 주기나 의존성을 로그, 중단점(Breakpoints), OpenTelemetry 등을 활용해 추적함으로써 설계와 실제의 간극을 파악하는 방법론으로 확장됩니다 [16, 20-22].
 
 ---
-*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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*