비기능 요구사항 (Non-functional Requirements)

📌 Brief 시 Summary

비기능 요구사항(Non-functional Requirements)은 시스템이 무엇을 하는지(기능)가 아니라 시스템이 런타임 및 개발 단계에서 '얼마나 잘' 작동하는지를 정의하는 품질 속성(Quality Attributes)입니다 [1, 2]. 이는 아키텍처 특성(Architectural Characteristics), 추가 기능적 요구사항(Extra-functional Requirements), 행동 요구사항(Behavioral Requirements) 등으로도 불리며, 소프트웨어 아키텍트가 비즈니스 요구사항과 일치시켜야 하는 핵심 요소입니다 [1, 3]. 성공적인 아키텍처 결정을 위해서는 프로젝트의 성공에 중요한 비기능 요구사항을 도출하고 객관적으로 우선순위를 매기는 과정이 필수적입니다 [4].

📖 Core Content

비기능 요구사항의 정의 및 범주: 이해관계자의 관심사는 종종 비기능 요구사항으로 변환되며, 시스템의 아키텍처는 이러한 품질 속성과 밀접한 관련이 있습니다 [1]. ISO/IEC 25010:2011 표준에 따르면 비기능 요구사항은 크게 신뢰성, 운용성, 성능 효율성, 보안, 호환성과 같은 **런타임 요구사항(Runtime non-functional requirements)**과 유지보수성, 이식성(Transferability)과 같은 **개발 시간 요구사항(Development-time non-functional requirements)**으로 나뉩니다 [2].
아키텍처 결정과 품질 속성의 매핑: 소프트웨어 아키텍트는 비즈니스 요구사항을 아키텍처 특성(비기능 요구사항)과 일치시킬 책임이 있습니다 [3]. 예를 들어, 높은 고객 만족도를 위해서는 가용성, 내결함성, 보안성 및 성능이 요구되며, 제한된 예산과 시간은 구현 가능성과 단순성을 요구합니다 [3].
객관적 우선순위 산정: 프로젝트에서 모든 비기능 요구사항이 동일하게 중요할 수는 없으므로 우선순위를 정해야 합니다 [4]. 예를 들어 "고가용성 > 성능", "빠른 납품 > 완벽한 확장성"과 같이 정량적(1~5점 척도나 퍼센트)으로 가중치를 부여하고 그 이유를 정당화함으로써, 개인의 선호나 유행에 휩쓸리지 않고 보다 객관적인 아키텍처 결정을 내릴 수 있습니다 [4].
아키텍처 패턴의 평가: 선택된 아키텍처 패턴은 유행이 아니라 식별되고 우선순위가 매겨진 비기능 요구사항(확장성, 비용, 개발 노력, 진화 가능성 등)을 정량적으로 평가하여 비교 분석해야 합니다 [5]. 이때 ISO 25010과 같은 품질 모델을 통해 명확한 기준을 정의하고 의사결정 매트릭스를 활용할 수 있습니다 [5, 6].

⚖️ Trade-offs & Caveats

트레이드오프(Trade-off)의 필연성: 소프트웨어 아키텍처의 기본 법칙 중 하나는 "모든 것은 트레이드오프다(Everything is a trade-off)"라는 것입니다 [7]. 완벽한 아키텍처는 존재하지 않으며, 특정 비기능 요구사항을 우선시하면 필연적으로 다른 부분을 희생해야 합니다 [8].
속성 간의 충돌: ATAM(Architecture Tradeoff Analysis Method) 방법론을 통해 분석해 보면, 예를 들어 극도로 안전한 시스템(높은 암호화 적용)을 구축하면 대개 성능(지연 시간 증가)을 희생해야 하며, 시스템을 매우 빠르게 개발하면 향후 유지보수성이 떨어지는 등의 상호작용과 한계가 존재합니다 [8].
동기적 통신으로 인한 결합 문제: 아키텍처 컴포넌트 간에 동기적(Synchronous)으로 통신을 수행할 경우, 해당 컴포넌트들이 서로 얽히게 되어 동일한 아키텍처 특성(비기능 요구사항)을 공유해야만 하는 기술적 제약이 발생합니다 [7].

🔗 Knowledge Connections

[아키텍처 평가 및 표준]

ISO/IEC 25010
- 연결 이유: 비기능 요구사항(유지보수성, 신뢰성, 성능 효율성 등)을 정의하는 소프트웨어 품질 모델의 국제 표준입니다 [2, 6].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 아키텍처 비교 시 요구사항 평가를 위한 객관적이고 체계적인 평가 척도(기준)의 분류를 배울 수 있습니다.
ATAM (Architecture Tradeoff Analysis Method)
- 연결 이유: 특정 비기능 요구사항 간의 절충안(Trade-off)을 식별하고, 구체적인 시나리오를 바탕으로 아키텍처의 한계와 위험을 검증하는 평가 방법론입니다 [8-10].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 추상적인 품질 목표를 실제 시스템의 상황(예: 트래픽 급증 시의 응답성)에 맞게 검토하고 트레이드오프 지점을 도출하는 원리를 이해할 수 있습니다.

[핵심 아키텍처 품질 속성]

확장성 (Scalability)
- 연결 이유: 시스템의 사용자 수나 데이터 처리량이 증가할 때 이에 대응할 수 있는 능력을 의미하는 대표적인 비기능 요구사항입니다 [3, 11].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 수평적/수직적 성장을 지원하는 아키텍처 패턴의 구조적 이점과 시스템 성능 유지를 위한 설계 방식을 이해할 수 있습니다.
내결함성 (Fault Tolerance)
- 연결 이유: 컴포넌트의 실패 상황에서도 전체 시스템이 다운되지 않고 지속적으로 기능할 수 있는 능력을 요구하는 비기능 요구사항입니다 [1, 3].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 분산 시스템(예: P2P, 마이크로서비스)에서 어떻게 단일 장애점(SPOF)을 제거하여 신뢰성을 확보하는지 파악할 수 있습니다.

Deeper Research Questions

ISO/IEC 25010 표준에 정의된 '유지보수성'이나 '이식성'과 같은 개발 시간 비기능 요구사항은 초기 소프트웨어 설계에서 어떻게 정량적으로 측정되고 평가되는가?
보안성(Security)과 성능(Performance)이 상충할 때, ATAM 방법론의 시나리오 기반 접근은 두 비기능 요구사항 사이의 절충안을 도출하는 데 구체적으로 어떻게 적용되는가?
아키텍처 컴포넌트 간의 동기적(Synchronous) 통신이 동일한 비기능 요구사항을 강제하게 되는 원리는 무엇이며, 이를 피하기 위해 비동기 통신 모델(EDA 등)은 어떻게 활용되는가?
스타트업의 MVP 개발 상황(빠른 시장 출시)과 금융권의 인프라 구축(고가용성 및 보안) 상황에서 비기능 요구사항의 우선순위는 어떻게 변화하며, 이는 어떤 아키텍처 패턴 선택으로 직결되는가?
비기능 요구사항의 변화(예: 예상치 못한 트래픽 급증)에 대응하기 위해 시스템 아키텍처를 사후에 모듈형이나 분산형으로 마이그레이션할 때 발생하는 주요 기술 부채(Technical Debt)는 무엇인가?

Practical Application Contexts

Implementation: 비즈니스 이해관계자의 요구사항을 인터뷰하여, 명확한 척도를 지닌 비기능 요구사항(예: "초당 1000건의 트래픽에서 1초 이내 응답")으로 번역하고 구체화하는 활동에 적용됩니다 [10].
System Design: 도출된 비기능 요구사항에 우선순위를 부여하고(예: 빠른 납품 > 완벽한 확장성), 이를 기준으로 여러 아키텍처 패턴(모놀리식, 마이크로서비스 등)을 의사결정 매트릭스에 대입하여 아키텍처를 선정하는 과정에 활용됩니다 [4, 5].
Operation / Maintenance: 운영 과정에서 사용자 수 증가나 새로운 규제 적용 등 프로젝트 컨텍스트가 변경되었을 때, 기존 시스템의 비기능 요구사항 충족 여부를 정기적으로 재검토하고 시스템을 조정하는 지표로 사용됩니다 [12].
Learning Path: 소프트웨어 아키텍트로 성장하기 위해 ISO/IEC 25010 품질 모델을 학습하고, 이론적인 아키텍처 패턴들이 각 품질 속성에 어떠한 영향을 미치는지 ATAM 방법론을 통해 케이스 스터디를 진행해 볼 수 있습니다 [2, 5, 8].
My Project Relevance: 현재 내가 진행하는 프로젝트의 성공을 결정짓는 핵심 비기능 특성을 선별하고, 어째서 특정 기술 스택이나 아키텍처를 선택/포기했는지 그 논리적 트레이드오프 과정을 ADR(Architecture Decision Record)에 명확히 기록하는 데 적용됩니다 [13].

Adjacent Topics

소프트웨어 아키텍처 (Software Architecture)
- 확장 방향: 비기능 요구사항을 충족하기 위한 고수준의 구조적 프레임워크 설계와 전략적 방향성을 연구할 수 있습니다.
Architecture Decision Records (ADR)
- 확장 방향: 결정된 비기능 요구사항과 트레이드오프, 그리고 채택된 아키텍처의 논리를 문서화하고 이력을 추적하는 방법을 학습할 수 있습니다.
Conway's Law
- 확장 방향: 개발 조직의 커뮤니케이션 구조(인지적 한계)가 시스템의 비기능적 설계와 아키텍처 구조에 미치는 영향을 탐구할 수 있습니다.

Last updated: 2026-05-02

9.5 KiB Raw Blame History