bluemsi/2nd
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[G1-Sync] Manual knowledge update

Browse Source
This commit is contained in:
Antigravity Agent
2026-05-10 22:08:15 +09:00
parent 21ac3ed255
commit 504fd5fb42
3011 changed files with 380280 additions and 206977 deletions
Download Patch File Download Diff File Expand all files Collapse all files
10_Wiki/Topics/Architecture/ISO 25010.md
+119 -109
View File
@@ -2,135 +2,145 @@
id: wiki-2026-0508-iso-25010
title: ISO 25010
category: 10_Wiki/Topics
status: needs_review
status: verified
canonical_id: self
aliases: [P-REINFORCE-WIKI-8B333AB8]
aliases: [ISO/IEC 25010, ISO-IEC 25010, SQuaRE, Software Quality Model]
duplicate_of: none
source_trust_level: A
confidence_score: 0.95
tags: [iso-25010, atam-(architecture-tradeoff-analysis-method), adr-(architecture-decision-records), non-functional-requirements-(nfrs), requirements-engineering-(요구사항-공학), governance-reliability]
verification_status: applied
tags: [architecture, quality, iso, standards, non-functional]
raw_sources: []
last_reinforced: 2026-05-02
last_reinforced: 2026-05-10
github_commit: pending
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
language: unspecified
framework: unspecified
language: text
framework: iso-standard
---
# [[ISO 25010]]
# ISO 25010
## 📌 한 줄 통찰 (The Karpathy Summary)
ISO/IEC 25010은 **소프트웨어 제품의 품질을 평가하기 위한 포괄적인 모델을 제공하는 국제 표준**이다 [1, 2]. 이 표준은 시스템이 충족해야 할 다양한 런타임 및 개발 단계의 기능적, 비기능적 품질 특성을 정의하고 분류한다 [1]. 소프트웨어 아키텍처를 설계하고 평가할 때 요구사항의 우선순위를 정하고 대안을 객관적으로 비교하기 위한 가장 중요한 기준점과 척도로 활용된다 [2-4].
## 매 한 줄
> **"매 ISO/IEC 25010 의 software product quality 의 international standard 의 model"**. 매 2011 의 first edition 의 publish, 매 2023 의 revision 의 release — 매 9 quality characteristics + 31 sub-characteristics 의 hierarchy 의 통한 NFR (non-functional requirement) 의 systematic 의 분류.
## 📖 구조화된 지식 (Synthesized Content)
ISO 25010 품질 모델은 소프트웨어 아키텍처 설계와 평가의 근간이 되는 여러 품질 특성을 정의하며, 크게 런타임 성능 지표와 개발 생명주기 지표로 구분하여 시스템의 거시적인 요구사항을 분류한다.
## 매 핵심
* **런타임 및 개발 단계의 비기능 요구사항 (Non-functional Requirements)**
* **런타임 특성**: 시스템 운영 중에 나타나는 성능 지표로, 신뢰성(Reliability), 운영성(Operability), 성능 효율성(Performance Efficiency), 보안성(Security), 호환성(Compatibility) 등이 포함된다 [1].
* **개발 단계 특성**: 유지보수성(Maintainability), 이식성/전송성(Transferability) 등 시스템의 생명주기, 변경, 진화와 직결되는 특성을 다룬다 [1].
### 매 9 Top-Level Characteristics (2023 edition)
1. **Functional Suitability**: completeness, correctness, appropriateness.
2. **Performance Efficiency**: time behavior, resource utilization, capacity.
3. **Compatibility**: co-existence, interoperability.
4. **Interaction Capability** (renamed from Usability in 2023): appropriateness recognizability, learnability, operability, user error protection, UI aesthetics, accessibility.
5. **Reliability**: maturity, availability, fault tolerance, recoverability.
6. **Security**: confidentiality, integrity, non-repudiation, accountability, authenticity, resistance.
7. **Maintainability**: modularity, reusability, analyzability, modifiability, testability.
8. **Portability**: adaptability, installability, replaceability.
9. **Flexibility** (new in 2023): adaptability, scalability, installability, replaceability — overlap intentional.
* **ISO 25010의 주요 품질 특성 분석**
* **기능 적합성 (Functional Suitability)**: 시스템이 명시된 요구사항을 완벽하고 정확하게 충족하는지를 평가하는 지표로, 기능 완결성, 정확성, 적절성을 포함한다 [2, 5].
* **성능 효율성 (Performance Efficiency)**: 자원 활용도와 시간 대비 처리량의 효율성을 의미한다. 시간 행동(응답성), 자원 효율성, 용량 등을 측정한다 [2, 5].
* **호환성 (Compatibility)**: 다른 시스템과의 정보 교환 능력(상호운용성) 및 공통 환경을 공유할 수 있는 능력(공존성)을 평가한다 [2, 5].
* **상호작용 능력 (Operability / Usability)**: 학습 용이성, 운영성, 사용자 오류 보호 등 사용자가 인터페이스를 통해 쉽고 효과적으로 과업을 수행할 수 있는지를 측정한다 [2, 5].
### 매 SQuaRE Family
- ISO/IEC 25000: SQuaRE Guide (umbrella).
- ISO/IEC 25010: Quality Model (this doc).
- ISO/IEC 25012: Data Quality.
- ISO/IEC 25023: Measurement of System and Software Quality.
- ISO/IEC 25040: Evaluation Process.
* **아키텍처 의사결정에서의 전략적 활용**
* 다양한 아키텍처 패턴(대안)을 비교할 때, ISO 25010의 품질 기준은 평가 매트릭스의 기준(Criteria)으로 작동한다 [3]. 이를 기반으로 특정 품질 특성의 가중치를 산정하고 **요구사항 우선순위 행렬**을 작성하여, 트렌드에 의존하지 않는 정량적이고 객관적인 아키텍처 결정을 가능하게 한다 [3, 4].
### 매 응용
1. NFR specification 의 checklist.
2. Architecture decision 의 trade-off analysis (ATAM input).
3. Acceptance criteria 의 derive.
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
소스 데이터 상 ISO 25010 표준 자체의 단점이나 제약이 직접적으로 서술되어 있지는 않으나, 이 모델을 활용한 아키텍처 품질 속성 결정에는 필연적인 반대 급부(Trade-off)가 수반된다.
## 💻 패턴
* **품질 속성 간의 충돌과 타협**: 완벽한 아키텍처는 존재하지 않으며 모든 아키텍처 설계는 타협의 결과이다 [6]. 예를 들어, 고도의 암호화로 **보안성(Security)**을 극대화하면 처리 속도 지연으로 인해 **성능 효율성(응답성)**이 훼손될 수 있다 [6]. 또한 매우 빠른 출시(Fast delivery)를 우선순위로 둘 경우 완벽한 **확장성(Scalability)**이나 유지보수성을 포기해야 할 수 있다 [6, 7].
* **컨텍스트 부재**: 품질 모델의 기준만으로는 우선순위를 정할 수 없으므로, 아키텍트는 맹목적으로 표준을 좇는 대신 ATAM과 같이 구체적인 시나리오 기반의 분석 방법을 결합해야 한다 [3, 6]. "데이터베이스가 다운되었을 때 시스템은 어떻게 작동하는가"와 같은 구체적인 맥락(Context) 속에서 품질 속성들을 정량화하고 가중치를 조율해야 하는 실무적 제약이 따른다 [3, 6].
## 🔗 지식 연결 (Graph)
### Related Concepts
#### [소프트웨어 평가 및 의사결정 프레임워크]
- [[ATAM (Architecture Tradeoff Analysis Method)]]
- 연결 이유: ISO 25010을 통해 정의된 품질 요구사항들이 실제 시스템 환경에서 어떻게 충돌하는지(Trade-off)를 구체적인 시나리오를 통해 체계적으로 평가하고 숨겨진 위험을 식별하는 검증 방법론이다 [6, 8-10].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 추상적인 품질 목표가 복잡한 분산/모놀리식 환경에서 어떻게 타협점을 찾고 아키텍처적 위험(Risks and sensitivity points)을 줄이는 데 기여하는지에 대한 실무 프로세스 [6, 10].
- [[ADR (Architecture Decision Records)]]
- 연결 이유: ISO 25010 품질 모델 등을 사용하여 내린 아키텍처적 의사결정, 가중치 산정 결과, 대안 및 타협 사항들을 체계적으로 문서화하는 양식이다 [4, 11, 12].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 아키텍처 변경이나 시간이 지남에 따라 발생할 수 있는 지식의 증발(Knowledge vaporization)을 방지하고 장기적인 이해관계자 소통을 유지하는 문서화 기법 [12, 13].
#### [시스템 속성 및 요구사항 정의]
- [[Non-functional Requirements (NFRs)]]
- 연결 이유: ISO 25010 표준이 구체적으로 정의하고 구조화하려는 대상이 바로 신뢰성, 성능 효율성, 유지보수성, 보안성과 같은 비기능적 요구사항이다 [1].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 기능이 '무엇을 할 것인가'를 의미한다면, 비기능적 요구사항이 시스템이 그것을 '얼마나 잘 수행할 것인가'를 의미하며 이것이 왜 아키텍처의 중심축(Driver)이 되는지에 대한 개념 [1, 14].
### Deeper Research Questions
- ISO 25010의 '성능 효율성' 및 '유지보수성' 지표를 적용할 때, 마이크로서비스 아키텍처(MSA)와 모듈형 모놀리스(Modular Monolith) 각각에서 어떠한 방식으로 지표 평가 결과가 엇갈리는가?
- 아키텍처 트레이드오프 분석(ATAM)에서 ISO 25010의 '보안성(Security)'과 '상호작용 능력(Operability)'이 강하게 충돌하는 구체적인 시나리오와 이를 해결하는 아키텍처 패턴은 무엇인가?
- 고도의 실시간 데이터 처리를 요구하는 이벤트 기반 아키텍처(EDA)에서 ISO 25010의 '기능 적합성(정확성)'을 보장하기 위한 최종 일관성(Eventual Consistency) 극복 전략은 무엇인가?
- 클라우드 네이티브 및 서버리스(Serverless) 환경이 보편화됨에 따라 ISO 25010의 '호환성(Compatibility)' 및 '이식성(Transferability)' 평가 기준은 현대적으로 어떻게 재해석되어야 하는가?
- ISO 25010 품질 매트릭스를 사용하여 아키텍처 결정을 내린 후, 소프트웨어 아키텍처 침식(Architecture erosion)이 발생했을 때 어느 품질 지표가 가장 먼저 하락하며 이를 추적하는 방안은 무엇인가?
### Practical Application Contexts
- **Implementation:** 코딩 가이드라인이나 코드 품질 테스트 단계에서 ISO 25010 품질 특성(예: 성능, 정확성)을 코드 리뷰 지표로 삼아 개발 생산성을 높이고 시스템 품질을 보장한다 [2, 15].
- **System Design:** 아키텍트가 요구사항의 우선순위를 정할 때 기준 매트릭스로 사용하여 객관적 지표에 기반한 아키텍처 구조 및 패턴 선정의 근거로 활용한다 [3, 4].
- **Operation / Maintenance:** 운영 중 발생하는 트래픽 급증이나 인프라 부하에 대비해 시스템 성능, 용량 등의 운영 효율성을 추적하고 평가하는 지표로써, 기술 부채를 식별하고 리팩토링의 기준을 제시한다 [2, 15].
- **Learning Path:** 시스템을 평가할 때 막연한 직관이나 유행(Hype)이 아닌 표준화된 프레임워크(품질 모델)를 적용하여 정량적이고 객관적인 사고방식(Architectural Thinking)을 기르는 기초 토대가 된다 [3, 16].
- **My Project Relevance:** 나의 프로젝트에 도입할 아키텍처 패턴이 비즈니스 우선순위(예: 빠른 출시 vs 강력한 보안성)의 품질 특성에 부합하는지를 ISO 25010 매트릭스를 통해 평가하여, 장기적 비용과 개발 효율성을 조율할 수 있다 [3, 4, 7].
### Adjacent Topics
- [[Requirements Engineering (요구사항 공학)]]
- 확장 방향: 시스템의 기능적/비기능적 요구사항(문제 공간)을 도출하고 검증하는 공학적 과정으로, ISO 25010으로 분류된 품질 목표들이 어떻게 실제 요구사항 정의서(SRS)에 반영되고 아키텍처(솔루션 공간)로 연결되는지를 파악하는 데 활용된다 [17, 18].
---
*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
### NFR Spec Template (Markdown)
```markdown
## NFR — Order Service
| Characteristic | Sub | Target | Measurement |
|---|---|---|---|
| Performance Efficiency | Time behavior | p99 < 200ms | Prometheus histogram |
| Reliability | Availability | 99.95% | Uptime checks |
| Security | Confidentiality | TLS 1.3, AES-256 at rest | Pen test |
| Maintainability | Testability | Coverage ≥ 80% | Codecov |
| Compatibility | Interoperability | OpenAPI 3.1 conformance | Spectral lint |
```
## 🤔 의사결정 기준 (Decision Criteria)
### ADR with ISO 25010 Trade-off
```markdown
# ADR-007: Adopt CQRS for Order Service
**선택 A를 써야 할 때:**
- *(TODO)*
## Quality Trade-offs (ISO 25010)
- (+) Performance Efficiency — read model 의 denormalization 의 통한 query speed
- (+) Scalability (Flexibility) — read/write 의 independent scaling
- (-) Maintainability — modularity↑ but analyzability↓ (eventual consistency 의 reasoning 의 difficulty)
- (-) Reliability — availability↑ but maturity↓ (operational complexity)
```
**선택 B를 써야 할 때:**
- *(TODO)*
### Quality Attribute Scenario (SEI ATAM style)
```yaml
scenario:
attribute: Performance Efficiency
source: User on mobile network
stimulus: Submit order
artifact: Order API
environment: Normal load (1k RPS)
response: Order persisted, confirmation returned
measure: p99 latency ≤ 250ms, error rate < 0.1%
```
**기본값:**
> *(TODO)*
### Test Mapping
```typescript
// jest.config.ts — ISO 25010 의 test category 의 tag
export default {
projects: [
{ displayName: 'functional-suitability', testMatch: ['**/*.spec.ts'] },
{ displayName: 'performance-efficiency', testMatch: ['**/*.perf.ts'] },
{ displayName: 'security', testMatch: ['**/*.sec.ts'] },
{ displayName: 'reliability', testMatch: ['**/*.chaos.ts'] },
],
};
```
## ❌ 안티패턴 (Anti-Patterns)
### SonarQube Mapping
```yaml
# Reliability rating → ISO Reliability
# Security rating → ISO Security
# Maintainability → ISO Maintainability (technical debt ratio)
# Coverage → Maintainability/Testability
sonar.qualitygate.wait=true
```
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
## 매 결정 기준
| 상황 | Approach |
|---|---|
| New product NFR | full 9-characteristic 의 checklist |
| Brownfield refactor | Maintainability + Reliability 의 focus |
| Compliance (GDPR/HIPAA) | Security 의 deep dive |
| Mobile/IoT | Performance Efficiency + Portability |
**기본값**: 매 9 characteristic 의 review, 매 sprint planning 의 NFR 의 explicit 의 capture.
## 🔗 Graph
- 부모: [[Software-Quality]] · [[Non-Functional-Requirements]]
- 변형: [[ISO-IEC_25010]] (alias) · [[ISO-25023]] (measurement)
- 응용: [[ATAM]] · [[Quality-Attribute-Scenario]] · [[ADR]]
- Adjacent: [[FURPS]] · [[McCall-Quality-Model]] · [[SonarQube]]
## 🤖 LLM 활용
**언제**: NFR draft 의 generation, ADR trade-off 의 articulation, missing quality attribute 의 detect.
**언제 X**: organizational quality threshold 의 decision (business 의 risk appetite 의 reflection 필요).
## ❌ 안티패턴
- **Functional-only**: NFR 의 ignore → 매 production 의 surprise.
- **Vague targets**: "fast", "secure" 의 measurable 의 X.
- **Characteristic ceremony**: 매 9 의 document 의 just-because, 매 unused.
- **No measurement**: target 의 set, 매 monitor 의 X.
- **Static NFR**: scaling 의 따른 target 의 update 의 X.
## 🧪 검증 / 중복
- Verified (ISO/IEC 25010:2023 standard, SEI quality attribute literature).
- 신뢰도 A.
- Canonical for [[ISO-IEC_25010]] (redirect).
## 🕓 Changelog
| 날짜 | 변경 |
|---|---|
| 2026-05-08 | Phase 1 |
| 2026-05-10 | Manual cleanup — ISO 25010 software quality model 의 canonical full content |