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

10_Wiki/Topics/Architecture/시스템 아키텍처 시각화 (System Architecture Visualization).md

@@ -1,25 +1,28 @@
 ---
-id: P-REINFORCE-WIKI-FC85131D
-title: "시스템 아키텍처 시각화 (System Architecture Visualization)"
-category: Unified
-status: draft
-canonical_id: ""
-aliases: []
-duplicate_of: ""
+id: wiki-2026-0508-시스템-아키텍처-시각화-system-architecture
+title: 시스템 아키텍처 시각화 (System Architecture Visualization)
+category: 10_Wiki/Topics
+status: needs_review
+canonical_id: self
+aliases: [P-REINFORCE-WIKI-FC85131D]
+duplicate_of: none
 source_trust_level: A
 confidence_score: 0.95
-tags: ['System Architecture Visualization']
-raw_sources: ["Datacollector_MAC/out_wiki/시스템 아키텍처 시각화 (System Architecture Visualization).md"]
+tags: [System Architecture Visualization]
+raw_sources: [Datacollector_MAC/out_wiki/시스템 아키텍처 시각화 (System Architecture Visualization).md]
 last_reinforced: 2026-05-02
-github_commit: ""
+github_commit: pending
+tech_stack:
+  language: unspecified
+  framework: unspecified
 ---
 
 # [[시스템 아키텍처 시각화 (System Architecture Visualization)]]
 
-## 📌 Brief Summary
+## 📌 한 줄 통찰 (The Karpathy Summary)
 시스템 아키텍처 시각화는 소프트웨어 시스템의 핵심 구성 요소, 상호 연결 및 통신 채널을 시각적으로 보여주는 청사진 역할을 합니다 [1-3]. 이는 기술 및 비기술 이해관계자 간의 의사소통 격차를 해소하고, 시스템 설계를 명확히 하여 올바른 의사결정을 돕는 살아있는 문서(Living documentation) 기능을 합니다 [4-6]. 특히 방대하고 복잡한 코드베이스에서 구조와 의존성을 도식화함으로써 신규 개발자의 온보딩(onboarding)을 가속화하고, 아키텍처의 부패나 기술적 부채를 방지하는 핵심 수단으로 작용합니다 [7-9].
 
-## 📖 Core Content
+## 📖 구조화된 지식 (Synthesized Content)
 *   **다이어그램의 주요 유형과 활용 목적**
     *   **컨텍스트 다이어그램 (Context Diagram):** 시스템을 블랙박스로 취급하여 대상 시스템과 상호작용하는 사용자 및 외부 시스템(서드파티 API 등) 간의 경계를 표시합니다. 주로 비기술 직군(PM, 기획자 등)과의 소통에 유용합니다 [7, 10, 11].
     *   **컨테이너 다이어그램 (Container Diagram):** 애플리케이션, 데이터베이스, 메시지 큐 등 배포 가능한 주요 기술 블록과 이들 간의 통신 방식을 보여주어 개발자의 전반적인 기술 개요 파악에 도움을 줍니다 [12, 13].
@@ -37,13 +40,12 @@ github_commit: ""
     *   **명확한 목적과 일관성:** 하나의 다이어그램은 하나의 질문에만 답하도록 분리해야 하며, 색상, 도형, 선 모양에 일관된 규칙을 적용하고 범례(Legend)를 반드시 포함해야 합니다 [5, 27].
     *   **비즈니스 언어로의 번역:** 기술적 도구나 아키텍처(예: '쿠버네티스 컨테이너 오케스트레이션')를 나열하는 것에 그치지 않고, 이것이 사용자에게 어떤 가치(예: '일일 사용자 10배 증가 시에도 지연 없음')를 주는지 명확하게 설명해야 합니다 [28, 29].
 
-## ⚖️ Trade-offs & Caveats
+## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
 *   **아키텍처 드리프트 (Architectural Drift) 위험:** 현대의 애자일 개발 및 클라우드 마이그레이션 환경에서는 시스템이 빠르게 진화합니다. 다이어그램을 수동으로 업데이트하는 것은 번거롭기 때문에 쉽게 방치될 수 있으며, 실제 코드 구현과 일치하지 않는 '오래된(stale)' 다이어그램은 오히려 혼란을 초래하여 다이어그램이 없는 것보다 더 큰 해를 끼칠 수 있습니다 [30-33].
 *   **정보 과부하 (The God Diagram):** 단일 다이어그램 안에 시스템의 모든 클래스, 메서드, 데이터베이스 테이블 및 프레임워크를 억지로 욱여넣으려고 하면 가독성이 완전히 상실된 '선과 상자의 수프(Boxes and Lines Soup)' 상태가 됩니다. 시각적 계층화 없이 과도한 기술 디테일('Technology Worship')을 묘사하는 것은 지양해야 합니다 [34-36].
 *   **정적 도구의 유지보수 제약:** PowerPoint나 단순 화이트보드와 같이 정적 이미지만 생성하는 도구를 사용할 경우, 서비스 이름이 변경되거나 구조가 바뀌었을 때 관련된 모든 문서와 이미지를 수동으로 찾아 업데이트해야 하는 치명적인 비효율과 불일치 문제가 발생합니다 [37].
 
-## 🔗 Knowledge Connections
-
+## 🔗 지식 연결 (Graph)
 ### Related Concepts
 
 #### [아키텍처/기반 기술]
@@ -93,3 +95,40 @@ github_commit: ""
 - **기존 유사 문서:** None
 - **처리 방식:** CREATE
 - **처리 이유:** 신규 지식 체계 도입
+
+## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
+
+**언제 이 지식을 쓰는가:**
+- *(TODO)*
+
+**언제 쓰면 안 되는가:**
+- *(TODO)*
+
+## 🕓 변경 이력 (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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*