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

10_Wiki/Topics/Architecture/소프트웨어 아키텍처 평가 (Software Architecture Evaluation).md

@@ -1,14 +1,26 @@
 ---
-id: P-REINFORCE-WIKI-D09FA4BC
-category: Unified
+id: wiki-2026-0508-소프트웨어-아키텍처-평가-software-architect
+title: 소프트웨어 아키텍처 평가 (Software Architecture Evaluation)
+category: 10_Wiki/Topics
+status: needs_review
+canonical_id: self
+aliases: [P-REINFORCE-WIKI-D09FA4BC]
+duplicate_of: none
+source_trust_level: A
 confidence_score: 0.95
-tags: ['소프트웨어-아키텍처-평가-(software-architecture-evaluation)', 'atam-(architecture-tradeoff-analysis-method)', 'iso-25010', 'adr-(architecture-decision-records)', 'utility-tree-(유틸리티-트리)', 'architecture-principles']
+tags: [소프트웨어-아키텍처-평가-(software-architecture-evaluation), atam-(architecture-tradeoff-analysis-method), iso-25010, adr-(architecture-decision-records), utility-tree-(유틸리티-트리), 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
 ---
 
 # [[소프트웨어 아키텍처 평가 (Software Architecture Evaluation)]]
 
-## 📌 Brief Summary
+## 📌 한 줄 통찰 (The Karpathy Summary)
 소프트웨어 아키텍처 평가는 제안된 설계안이나 기존 아키텍처가 시스템의 비즈니스 목표와 품질 요구사항을 얼마나 잘 충족하는지 체계적으로 결정하는 과정이다 [1]. 이 과정은 아키텍처 결정을 내리는 시점, 설계의 일부 또는 전체가 완료된 후, 심지어 시스템 구축 이후 등 다양한 수명주기 단계에서 수행될 수 있다 [1]. 평가는 단순한 직관이나 유행이 아닌 구체적인 시나리오와 품질 모델(예: ISO 25010)을 바탕으로 수행되며, 대표적인 기법인 ATAM을 통해 아키텍처의 타협점(Trade-off)과 위험 요소(Risks)를 식별한다 [1-3].
 
 ## 📖 Core 소스에 관련 정보가 부족합니다. Content
@@ -21,13 +33,12 @@ last_reinforced: 2026-05-02
 * **체계적인 아키텍처 의사결정 프로세스:** 
   성공적인 평가 및 결정은 다음의 체계적인 단계를 따른다. 첫째, 요구사항 및 문맥을 이해한다 [6]. 둘째, 품질 요구사항을 평가하고 가중치를 매긴다(우선순위화) [6]. 셋째, 결정 매트릭스와 ATAM 등을 사용하여 여러 아키텍처 컨셉을 기준에 따라 평가하고 트레이드오프를 분석한다 [6, 7]. 넷째, 프로토타이핑(Prototyping)이나 기술 증명(PoC)을 통해 핵심적인 기술 리스크(부하 성능 등)를 검증하고 최소화한다 [6, 8]. 마지막으로, 도출된 결정 사항과 타협의 근거를 ADR(Architecture Decision Records)을 통해 문서화하고, 시스템 환경이 변할 때마다 아키텍처를 정기적으로 재검토(Review)한다 [6, 9].
 
-## ⚖️ Trade-offs & Caveats
+## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
 * **불가피한 타협(Trade-offs):** "완벽한 아키텍처는 존재하지 않으며, 모든 결정은 타협이다"라는 원칙이 아키텍처 평가의 핵심이다 [4]. 예를 들어, 극도로 안전한 시스템(높은 암호화)을 채택하면 응답 시간(지연 시간) 등 성능 측면에서 손해를 볼 수 있으며, 시스템을 매우 빠르게 개발(Fast delivery)하는 쪽을 선택하면 향후 유지보수성이나 확장성을 양보해야 할 수 있다 [2, 4, 10].
 * **결정 지연 및 분석 마비(Analysis Paralysis) 주의:** 아키텍트가 잘못된 결정을 내릴 것을 두려워하여 평가와 결정을 미루는 것은 심각한 안티패턴(Anti-pattern)이다 [11]. 이는 분석 마비로 이어져 팀의 진행을 방해하므로, 충분한 정보가 모이는 "마지막 책임 순간(last responsible moment)"에는 타협을 감수하고 결정을 내려야 한다 [11].
 * **문서화 누락에 따른 위험:** 아키텍처 평가를 통해 결정된 사항들이 ADR 등으로 적절히 문서화되지 않으면, 시간이 지나 시스템 환경이 변하거나 새로운 팀원이 합류했을 때 왜 그러한 설계가 채택되었는지 알 수 없게 되어 동일한 논의를 반복하는 비효율이 발생한다 [3, 11].
 
-## 🔗 Knowledge Connections
-
+## 🔗 지식 연결 (Graph)
 ### Related Concepts
 
 #### [관계 유형 A (평가 방법론 및 표준)]
@@ -70,4 +81,61 @@ last_reinforced: 2026-05-02
   - 확장 방향: ADR과 같은 문서화가 누락되었거나 아키텍처 침식이 심각한 기존 레거시(Legacy) 시스템에서, 현재 구현된 코드베이스를 분석하여 소프트웨어 아키텍처를 재구성하고 재평가하는 방법론 연구.
 
 ---
-*Last updated: 2026-05-02*
+*Last updated: 2026-05-02*
+
+## 📖 구조화된 지식 (Synthesized Content)
+
+**추출된 패턴:**
+> *(TODO)*
+
+**세부 내용:**
+- *(TODO)*
+
+## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*