---
id: P-REINFORCE-WIKI-03071FFF
category: "10_Wiki/💡 Topics/02_Architecture_Principles"
confidence_score: 0.95
tags: ['비기능적-요구사항-(non-functional-requirements,-nfrs)', 'architecture-tradeoff-analysis-method-(atam)', 'architecture-decision-records-(adrs)', 'iso/iec-25010', 'microservices-architecture-pattern', 'architecture-principles']
last_reinforced: 2026-05-02
---

# [[비기능적 요구사항 (Non-functional Requirements, NFRs)]]

## 📌 Brief Summary
비기능적 요구사항(NFRs)은 소프트웨어 시스템이 특정 기능을 수행하는 '방식'과 관련된 품질 속성(Quality Attributes)을 정의하는 개념입니다 [1]. 여기에는 성능, 확장성, 보안, 유지보수성, 가용성 및 신뢰성 등이 포함되며, 종종 아키텍처적 특성(Architectural Characteristics)으로도 불립니다 [1, 2]. 이러한 비기능적 요구사항은 소프트웨어 아키텍처 설계와 패턴 선택을 주도하는 가장 핵심적인 기준점 역할을 합니다 [3, 4].

## 📖 Core Content
* **개념 및 품질 모델(Quality Models):**
  비기능적 요구사항은 결함 허용성(fault-tolerance), 하위 호환성, 확장성, 신뢰성, 유지보수성, 사용성 등 다양한 시스템 특성을 포괄합니다 [1]. ISO/IEC 25010:2011 표준에 따르면, 이러한 품질 속성은 시스템 작동 중 나타나는 **런타임 비기능적 요구사항**(신뢰성, 성능 효율성, 보안, 호환성 등)과 시스템의 개발 및 유지보수 주기와 관련된 **개발 타임 비기능적 요구사항**(유지보수성, 이식성)으로 분류할 수 있습니다 [5].
* **아키텍처 결정의 기준 (Drivers for Architectural Decisions):**
  소프트웨어 아키텍처는 본질적으로 애플리케이션의 기능 자체가 아니라, 비기능적 요구사항을 충족하기 위한 인프라와 구조를 설계하는 과정입니다 [3]. 예를 들어, 프로젝트의 맥락에 따라 "고가용성 > 성능", "빠른 출시 > 완벽한 확장성", "낮은 운영 비용 > 최대의 유연성" 등 핵심 비기능적 요구사항의 우선순위를 명확히 계량화하여 평가하는 것이 구조적 의사결정의 객관적 근거가 됩니다 [4, 6].
* **평가 및 검증 방법론:**
  특정 아키텍처 패턴이 우선순위화된 비기능적 요구사항을 충족하는지 검증하기 위해 평가 기준이 필요합니다 [7]. ISO 25010 품질 모델의 기능 적합성, 성능 효율성(시간 행동, 자원 효율성), 호환성 지표를 사용하여 아키텍처 구조의 비즈니스 목적 부합성을 측정합니다 [8, 9]. 이 과정에서 ATAM(Architecture Tradeoff Analysis Method)과 같은 구체적인 시나리오 기반 분석 방법을 활용하여 시스템 부하, 장애 상황 등에서 시스템이 어떻게 반응하는지 검증합니다 [10-12].

## ⚖️ Trade-offs & Caveats
* **불가피한 상충 관계 (Trade-offs):** "완벽한 아키텍처는 없다"는 원칙에 따라 비기능적 요구사항들 사이에는 항상 상충 관계가 존재합니다 [11, 13]. 특정 품질 속성을 극대화하면 종종 다른 속성의 희생이 따릅니다. 예를 들어, 극단적으로 높은 보안성(고강도 암호화)을 추구하면 성능(대기 시간 증가)이 떨어질 수 있습니다 [11].
* **비용과 유지보수성의 저하:** 개발 속도(Fast delivery / Time to Market)라는 요구사항을 최우선으로 할 경우 시스템을 쉽게 설계할 수는 있으나, 향후 코드 유지보수성(Maintainability)이 떨어지거나 높은 기술 부채(Technical Debt)가 발생할 위험이 커집니다 [2, 11].
* **구조적 복잡성에 따른 반대 급부:** 높은 확장성(Scalability)이나 유연성 등 특정 NFR을 충족하기 위해 마이크로서비스(MSA)나 이벤트 기반 아키텍처(EDA) 같은 분산 환경 패턴을 도입하면, 결과적으로 통신 지연(Network Latency), 데이터 일관성 보장의 어려움, 디버깅 및 테스팅의 난이도 증가 등 운영 복잡성이라는 새로운 단점이 유발됩니다 [14-16].
* **결정의 동적 변화와 문서화 필요성:** 시스템의 사용량이 증가하거나 비즈니스 맥락이 변함에 따라 초기 우선순위에 두었던 비기능적 요구사항도 달라지게 됩니다 [17]. 따라서 아키텍처 결정 사항과 그에 수반된 타협점을 아키텍처 결정 기록(ADRs)과 같은 수단을 통해 문서화하지 않으면, 향후 팀원이나 이해관계자가 시스템 진화 방향을 파악하거나 유지보수하는 데 큰 어려움을 겪게 됩니다 [18, 19].

## 🔗 Knowledge Connections

### Related Concepts

#### [관계 유형 A: 아키텍처/평가 방법론]
- [[Architecture Tradeoff Analysis Method (ATAM)]]
  - 연결 이유: 비기능적 요구사항 간의 상충 관계(Trade-offs)를 체계적으로 분석하기 위해 고안된 소프트웨어 공학 평가 프레임워크입니다 [10, 11].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 추상적인 '성능'이나 '가용성' 요구사항을 구체적인 시스템 부하 시나리오로 변환하여, 숨겨진 아키텍처 위험과 상호작용을 찾아내는 방식을 이해할 수 있습니다.

#### [관계 유형 A: 아키텍처/문서화 표준]
- [[Architecture Decision Records (ADRs)]]
  - 연결 이유: 비기능적 요구사항을 충족시키기 위해 내린 아키텍처적 선택, 타협점 및 향후 리스크를 지속적으로 추적하고 문서화하는 표준 방식입니다 [18, 19].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 조직 내에서 아키텍처 결정의 배경(왜 이 패턴을 버리고 다른 패턴을 선택했는지)을 어떻게 소통하고 장기적으로 보존하는지 이해할 수 있습니다.

#### [관계 유형 A: 아키텍처/품질 표준]
- [[ISO/IEC 25010]]
  - 연결 이유: 소프트웨어 아키텍처가 달성해야 할 품질 속성(NFRs)을 기능 적합성, 성능 효율성, 호환성, 상호작용 능력 등으로 체계화한 국제 표준입니다 [5, 8].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 요구사항 수집 및 아키텍처 평가 시 측정 가능한 품질 지표(Metrics)를 어떻게 설정하고 평가 기준으로 삼는지 파악할 수 있습니다.

#### [관계 유형 B: 패턴과 구조적 해결책]
- [[Microservices Architecture Pattern]]
  - 연결 이유: 높은 확장성(Scalability), 독립적 배포성(Deployability), 가용성(Availability)이라는 특정한 비기능적 요구사항을 극대화하기 위해 자주 채택되는 분산 아키텍처 패턴입니다 [20, 21].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: NFR을 극대화하려는 선택이 운영 비용(Operational Complexity)이나 복잡한 데이터 관리라는 새로운 기술적 한계를 어떻게 유발하는지 실사례로 배울 수 있습니다.

### Deeper Research Questions
- 성능(Performance)과 데이터 일관성(Consistency)과 같은 상충하는 비기능적 요구사항(NFR)을 동시에 만족해야 할 때, 아키텍트들은 어떤 전략으로 적절한 타협점(Trade-offs)을 설정하는가?
- ISO/IEC 25010에 명시된 개발 타임 비기능적 요구사항(예: 유지보수성)과 런타임 비기능적 요구사항(예: 성능 효율성) 간의 충돌은 프로젝트 초기 설계 시 어떻게 우선순위가 결정되는가?
- 마이크로서비스 아키텍처(MSA) 또는 서버리스(Serverless)와 같은 분산형 아키텍처 패턴을 도입할 때 발생하는 보안(Security) 요구사항의 변화는 모놀리식 아키텍처와 어떻게 다른가?
- ATAM(Architecture Tradeoff Analysis Method)을 통해 도출한 위험 요소(Risk)를 애자일 개발 방법론 환경에서 어떻게 반복적으로 검증하고 아키텍처를 진화시킬 수 있는가?
- 비기능적 요구사항이 시간이 지남에 따라 변동할 때, 아키텍처 결정 기록(ADR) 문서는 변경 관리에 어떤 구체적이고 실질적인 도움을 주는가?

### Practical Application Contexts
- **Implementation:** 개발자는 코드를 작성하거나 인프라를 구성할 때 응답 시간(시간 행동), 처리량, 자원 활용도와 같은 성능 효율성 요구사항을 만족하도록 코딩 및 배포 가이드라인을 준수합니다.
- **System Design:** 프로젝트 시작 시 비즈니스 이해관계자와 함께 주요 NFR의 가중치(예: "보안성 > 속도")를 평가행렬에 넣고, 이에 부합하는 최적의 아키텍처 패턴(예: 계층형 vs 이벤트 기반)을 결정합니다.
- **Operation / Maintenance:** 가용성 및 결함 허용성에 대한 NFR이 실제 시스템에서 지켜지고 있는지 확인하기 위해 로그 통합 및 분산 트레이싱을 통한 런타임 상태 관측(Observability) 체계를 운영합니다.
- **Learning Path:** 시스템 설계 면접(System Design Interview)이나 설계 역량 강화를 위해 다양한 아키텍처 패턴을 배우고, 각각이 확장성, 장애 허용성 등 어떤 NFR 특화 솔루션인지 학습합니다.
- **My Project Relevance:** 현재 진행 중인 소프트웨어 기획 단계에서 팀 규모, 예상 트래픽 부하, 예산, 규제 준수 등을 기반으로 프로젝트의 가장 핵심적인 NFR을 정의하고, 구조적 복잡성과 유연성 사이의 올바른 타협안을 제시하는 기초 자료로 사용됩니다.

### Adjacent Topics
- [[Conway's Law]]
  - 확장 방향: 아키텍처 구조와 비기능적 품질 속성(특히 모듈성과 유지보수성)이 팀의 의사소통 구조와 어떻게 상호 영향을 주고받는지 조직적 관점에서 탐구합니다.
- [[Technical Debt]]
  - 확장 방향: 일정을 맞추기 위해 섣불리 내린 아키텍처 타협이나 나쁜 설계가 장기적으로 유지보수성(Maintainability)이라는 비기능적 품질에 어떠한 비용으로 되돌아오는지 연구합니다.

---
*Last updated: 2026-05-02*