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

10_Wiki/Topics/Architecture/비기능 요구사항 (Non-functional Requirements).md

@@ -1,17 +1,29 @@
 ---
-id: P-REINFORCE-WIKI-D66AEA8E
-category: Unified
+id: wiki-2026-0508-비기능-요구사항-non-functional-requirem
+title: 비기능 요구사항 (Non functional Requirements)
+category: 10_Wiki/Topics
+status: needs_review
+canonical_id: self
+aliases: [P-REINFORCE-WIKI-D66AEA8E]
+duplicate_of: none
+source_trust_level: A
 confidence_score: 0.95
-tags: ['비기능-요구사항-(non-functional-requirements)', 'iso/iec-25010', 'atam-(architecture-tradeoff-analysis-method)', '확장성-(scalability)', '내결함성-(fault-tolerance)', 'architecture-principles']
+tags: [비기능-요구사항-(non-functional-requirements), iso/iec-25010, atam-(architecture-tradeoff-analysis-method), 확장성-(scalability), 내결함성-(fault-tolerance), 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
 ---
 
 # [[비기능 요구사항 (Non-functional Requirements)]]
 
-## 📌 Brief Summary
+## 📌 한 줄 통찰 (The Karpathy Summary)
 비기능 요구사항(Non-functional Requirements)은 시스템이 무엇을 하는지(기능)가 아니라 시스템이 런타임 및 개발 단계에서 '얼마나 잘' 작동하는지를 정의하는 품질 속성(Quality Attributes)입니다 [1, 2]. 이는 아키텍처 특성(Architectural Characteristics), 추가 기능적 요구사항(Extra-functional Requirements), 행동 요구사항(Behavioral Requirements) 등으로도 불리며, 소프트웨어 아키텍트가 비즈니스 요구사항과 일치시켜야 하는 핵심 요소입니다 [1, 3]. 성공적인 아키텍처 결정을 위해서는 프로젝트의 성공에 중요한 비기능 요구사항을 도출하고 객관적으로 우선순위를 매기는 과정이 필수적입니다 [4].
 
-## 📖 Core Content
+## 📖 구조화된 지식 (Synthesized Content)
 - **비기능 요구사항의 정의 및 범주:** 
   이해관계자의 관심사는 종종 비기능 요구사항으로 변환되며, 시스템의 아키텍처는 이러한 품질 속성과 밀접한 관련이 있습니다 [1]. ISO/IEC 25010:2011 표준에 따르면 비기능 요구사항은 크게 신뢰성, 운용성, 성능 효율성, 보안, 호환성과 같은 **런타임 요구사항(Runtime non-functional requirements)**과 유지보수성, 이식성(Transferability)과 같은 **개발 시간 요구사항(Development-time non-functional requirements)**으로 나뉩니다 [2]. 
 - **아키텍처 결정과 품질 속성의 매핑:** 
@@ -21,7 +33,7 @@ last_reinforced: 2026-05-02
 - **아키텍처 패턴의 평가:**
   선택된 아키텍처 패턴은 유행이 아니라 식별되고 우선순위가 매겨진 비기능 요구사항(확장성, 비용, 개발 노력, 진화 가능성 등)을 정량적으로 평가하여 비교 분석해야 합니다 [5]. 이때 ISO 25010과 같은 품질 모델을 통해 명확한 기준을 정의하고 의사결정 매트릭스를 활용할 수 있습니다 [5, 6].
 
-## ⚖️ Trade-offs & Caveats
+## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
 - **트레이드오프(Trade-off)의 필연성:**
   소프트웨어 아키텍처의 기본 법칙 중 하나는 "모든 것은 트레이드오프다(Everything is a trade-off)"라는 것입니다 [7]. 완벽한 아키텍처는 존재하지 않으며, 특정 비기능 요구사항을 우선시하면 필연적으로 다른 부분을 희생해야 합니다 [8].
 - **속성 간의 충돌:**
@@ -29,8 +41,7 @@ last_reinforced: 2026-05-02
 - **동기적 통신으로 인한 결합 문제:**
   아키텍처 컴포넌트 간에 동기적(Synchronous)으로 통신을 수행할 경우, 해당 컴포넌트들이 서로 얽히게 되어 동일한 아키텍처 특성(비기능 요구사항)을 공유해야만 하는 기술적 제약이 발생합니다 [7].
 
-## 🔗 Knowledge Connections
-
+## 🔗 지식 연결 (Graph)
 ### Related Concepts
 
 #### [아키텍처 평가 및 표준]
@@ -75,4 +86,53 @@ last_reinforced: 2026-05-02
   - 확장 방향: 개발 조직의 커뮤니케이션 구조(인지적 한계)가 시스템의 비기능적 설계와 아키텍처 구조에 미치는 영향을 탐구할 수 있습니다.
 
 ---
-*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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*