279. 아키텍처 품질 속성 (Quality Attributes) - 시나리오 기반 정의

핵심 인사이트 (3줄 요약)

본질: 아키텍처 품질 속성(Quality Attributes)은 시스템이 '무엇(기능)'을 하는가가 아니라 '얼마나 잘(How well)' 수행하는지를 나타내는 비기능적 요구사항(가용성, 성능, 보안성 등)의 척도다.

가치: "시스템이 빨라야 한다"는 식의 모호한 요구사항을 '자극원-자극-환경-대상-응답-응답 척도'라는 6가지 요소를 갖춘 구체적인 시나리오로 정의함으로써, 이해관계자 간의 합의를 이끌고 아키텍처 설계와 테스트의 명확한 기준(Testable)을 세운다.

융합: ATAM(Architecture Trade-off Analysis Method) 같은 아키텍처 평가 기법의 핵심 재료로 사용되며, 시스템 아키텍트가 성능(Performance)과 유지보수성(Modifiability) 사이의 트레이드오프(Trade-off)를 결정하는 객관적 나침반 역할을 한다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 품질 속성이란 소프트웨어 시스템의 성능, 신뢰성, 보안성, 가용성 등 시스템의 '행동 양식'을 결정짓는 특성이다. 시나리오 기반 정의는 이러한 품질 속성들을 측정 가능하고(Measurable) 관찰 가능한(Observable) 상황극(Scenario) 형태로 서술하는 방법론이다.
필요성: 고객이 "우리 쇼핑몰은 빨라야 하고, 절대 죽으면 안 됩니다"라고 요구했다고 치자. '빠르다'는 1초인가, 0.1초인가? '절대'는 99%인가, 99.999%인가? 이처럼 모호한 비기능 요구사항(NFR)을 그대로 두고 아키텍처를 설계하면, 나중에 고객은 "내가 생각한 빠름이 아니다"라며 불만을 제기하고 재작업이 발생한다. 따라서 숫자로 측정이 가능한 '시나리오' 형태의 합의서가 반드시 필요하다.
💡 비유: 자동차를 살 때 "튼튼한 차를 주세요"라고 말하는 것은 모호합니다. 대신 "시속 60km로 콘크리트 벽을(환경) 정면으로 들이받았을 때(자극), 범퍼가 부서지더라도(대상), 승객의 공간은 유지되어야 하며(응답), 탑승자의 부상 수치가 1도 이하여야 한다(응답 척도)"라고 구체적인 '충돌 테스트 시나리오'를 적어두는 것과 같습니다.
등장 배경 및 발전 과정:
1. 비기능 요구사항의 방치: 초기 소프트웨어 공학에서는 기능(Use Case) 구현에만 집중하고 성능이나 보안은 뒷전으로 미루어, 배포 후 시스템이 붕괴되는 일이 잦았다.
2. ISO/IEC 9126 및 25010 표준화: 소프트웨어 품질 특성을 6~8개(기능성, 신뢰성, 사용성 등)로 분류하고 표준화하려는 시도가 나타났다.
3. SEI(Software Engineering Institute)의 시나리오 접근법: 표준화된 단어만으로는 실무적 합의가 어렵다고 판단하여, 카네기 멜런 대학(SEI)을 중심으로 품질 속성을 6요소 기반의 '시나리오'로 명세하고 이를 바탕으로 아키텍처를 평가하는 ATAM 기법이 정립되었다.
📢 섹션 요약 비유: "맛있는 라면을 끓여라"가 아니라, "물 500ml가 100도가 되었을 때 면을 넣고 정확히 3분간 끓여, 염도가 1.5%인 라면을 내어라"라고 레시피를 구체화하는 작업입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

기능적 요구사항 vs 비기능적 요구사항 (품질 속성)

아키텍처 설계 시 이 둘의 차이를 명확히 아는 것이 출발점이다.

구분	기능적 요구사항 (Functional)	비기능적 요구사항 / 품질 속성 (Non-Functional)
정의	시스템이 무엇(What)을 해야 하는가?	시스템이 그것을 어떻게(How well) 해야 하는가?
예시	"사용자는 장바구니에 상품을 담을 수 있다."	"장바구니 담기 버튼을 누르면 0.5초 이내에 반응해야 한다."
만족 여부	Yes / No (기능이 동작하거나 안 하거나)	스펙트럼 (0.5초면 대만족, 1초면 불만족 등 수치화됨)
아키텍처 영향	주로 도메인 로직, DB 스키마 등에 영향	시스템 전체 아키텍처(서버 대수, 캐시 도입, 암호화)를 결정

일반 시나리오 (General) vs 구체적 시나리오 (Concrete)

시나리오 기반 정의법은 크게 두 가지 형태의 시나리오를 사용한다.

  ┌─────────────────────────────────────────────────────────────┐
  │                 일반 시나리오와 구체적 시나리오의 관계                │
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │  [일반 시나리오 (General Scenario)]                         │
  │   - 특정 품질 속성(예: 가용성)이 무엇을 의미하는지 범용적으로 정의. │
  │   - "어떤 시스템이든 결함이 발생하면 정해진 시간 내에 복구되어야 한다."│
  │                                                             │
  │         ▼ (시스템의 실제 환경을 반영하여 구체화)                  │
  │                                                             │
  │  [구체적 시나리오 (Concrete Scenario)]                      │
  │   - 개발 중인 특정 시스템의 상황에 맞게 6가지 요소로 정확히 작성.   │
  │   - "쇼핑몰 결제 서버에 정전이 발생하면(자극), 백업 서버가 3초 이내에│
  │      활성화되어(응답) 사용자의 결제 요청이 실패하지 않아야 한다."   │
  │                                                             │
  │  ※ 아키텍트와 고객이 합의하고 검증하는 대상은 바로 '구체적 시나리오'다. │
  └─────────────────────────────────────────────────────────────┘

품질 속성의 분류 (시스템/비즈니스/아키텍처 속성)

품질 속성은 시스템의 런타임 행동뿐만 아니라, 비즈니스 목적이나 아키텍처 자체의 구조적 특징도 포함한다.

런타임 품질 속성: 실행 중에 관찰되는 속성. (성능, 가용성, 보안성, 사용성)
개발 타임 품질 속성: 시스템의 구조와 코드와 관련된 속성. (변경 용이성, 이식성, 재사용성, 테스트 용이성)
비즈니스 품질 속성: 회사의 예산 및 일정과 관련된 속성. (출시 시간-Time to market, 구축 비용, 수명)

아키텍트는 이 수많은 속성들 사이에서 우선순위(Priority)를 정하고 타협(Trade-off)을 이끌어내야 한다. 예를 들어 **'최고의 보안성(데이터 암호화 10번)'**을 달성하려다 보면 필연적으로 **'성능(응답 시간 지연)'**이 떨어진다. 이 균형점을 찾는 것이 설계의 핵심이다.

📢 섹션 요약 비유: 일반 시나리오가 "사람은 아프면 병원에 가야 한다"는 사전적 정의라면, 구체적 시나리오는 "김철수가 감기(자극)에 걸리면 즉시 이비인후과에 가서 주사를 맞고(응답) 다음 날 회사에 출근해야 한다(척도)"라는 족집게 처방전입니다.

Ⅲ. 융합 비교 및 다각도 분석

1. 품질 속성 시나리오 vs 유스케이스(Use Case)

둘 다 요구사항을 추출하는 기법이지만 초점이 완전히 다르다.

비교 항목	유스케이스 (Use Case)	품질 속성 시나리오 (QA Scenario)
초점	사용자와 시스템 간의 기능적 상호작용	특정 상황(부하, 해킹 등)에서의 비기능적 반응
형식	액터(Actor)가 특정 목표를 위해 행동하는 순서	자극원, 자극, 환경 등 6요소로 구성된 단일 문장
주요 역할자	기획자, 비즈니스 분석가 (BA)	소프트웨어 아키텍트 (SA)
테스트 방법	기능 인수 테스트, 단위 테스트	부하 테스트, 침투 테스트, 재난 복구 테스트

과목 융합 관점

소프트웨어 공학 (SE): 품질 속성 시나리오는 **ATAM(Architecture Trade-off Analysis Method)**의 가장 중요한 첫 단계 입력물이다. 이 시나리오들이 없으면 아키텍처가 요구사항을 만족하는지 평가할 기준 자체가 없어진다.
클라우드 / IT 인프라: 클라우드 SLA(Service Level Agreement)는 품질 속성 시나리오의 상용화된 계약서다. "가용성 99.99% 미달 시 요금을 환불한다"는 SLA는 바로 가용성이라는 품질 속성에 대한 구체적 응답 척도(Measure)다.
📢 섹션 요약 비유: 유스케이스가 자동차의 '기어 변속, 핸들 조향' 등 운전자가 차를 모는 방법론이라면, 품질 속성 시나리오는 '시속 200km에서 급브레이크를 밟았을 때 차가 밀리지 않는가'라는 자동차의 한계 성능 테스트와 같습니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

시나리오 — 모호한 성능 요구사항으로 인한 프로젝트 분쟁: 공공기관 포털 사이트 구축 프로젝트. 고객의 요구사항 명세서(RFP)에 "시스템은 다수의 사용자가 접속해도 지연 없이 응답해야 한다"라고만 적혀 있었다. 배포 후 고객은 "클릭했는데 3초나 걸린다, 너무 느리다"며 인수를 거부했다. 반면 개발팀은 "동시 접속자 1만 명 상황에서 3초면 훌륭한 것 아니냐"며 맞선다.
- 아키텍트의 해결책: 프로젝트 초기에 구체적 시나리오를 작성하지 않은 아키텍트의 직무 유기다. 요구사항 분석 단계에서 "평상시(환경) 외부 일반 사용자(자극원)가 메인 페이지 조회를 요청하면(자극), 웹 서버(대상)는 이를 처리하고(응답), 95%의 요청이 1초 이내에 완료되어야 한다(응답 척도)"라고 시나리오를 도출하고 고객의 서명을 받아 부하 테스트(JMeter 등)의 기준으로 삼았어야 한다.
시나리오 — 유지보수성(Modifiability)과 성능(Performance)의 트레이드오프: 핀테크 스타트업. 개발팀은 결제 모듈의 유지보수성을 높이기 위해 코드의 결합도를 낮추고자 수많은 인터페이스와 의존성 주입(DI), 그리고 분산 마이크로서비스(MSA)를 도입했다. 결과적으로 코드는 깔끔해졌으나, 결제 1건당 네트워크 홉(Hop)이 5번이나 발생해 **성능(응답 속도)**이 2초를 넘어가는 참사가 발생했다.
- 아키텍트의 해결책: 아키텍처 전술은 공짜가 아니다. 모듈화(Modifiability 전술)는 함수/네트워크 호출 오버헤드를 늘려 성능(Performance)을 필연적으로 저하시킨다. 아키텍트는 비즈니스 우선순위를 명확히 확인하고, 성능 시나리오(0.5초 이내 결제 완료)가 1순위라면 과도한 추상화나 MSA 통신을 걷어내고 내부 메서드 호출이나 캐싱 구조로 트레이드오프 결단을 내려야 한다.

도입 체크리스트

기술적: 시나리오의 '응답 척도(Measure)'가 실제로 현재의 테스트 도구(APM, JMeter, Chaos Mesh 등)를 통해 정량적으로 검증 및 측정 가능한가? "코드가 예뻐야 한다" 같은 주관적 척도는 무효다.
경영적: 도출된 수십 개의 시나리오들에 대해 이해관계자(고객, 개발자, 운영자)들이 참여하여 '비즈니스 중요도'와 '구현 난이도'를 바탕으로 H/M/L 우선순위 매트릭스(Utility Tree)를 작성하였는가?

안티패턴

구체성 없는 시나리오 나열 (Vague Scenarios): "해커가 침입하면 시스템은 방어해야 한다" 수준의 시나리오는 쓰레기다. 어떤 자극(DDos인지 SQL 인젝션인지), 어느 정도의 척도(5분 내 탐지, 데이터 유출 0건)인지 숫자가 들어가지 않은 시나리오는 아키텍처 평가에 아무런 도움이 되지 않는다.
📢 섹션 요약 비유: 복싱 선수가 훈련할 때 "그냥 안 맞고 잘 때린다"라고 목표를 정하면 안 됩니다. "1라운드 3분 동안(환경), 상대가 잽을 날리면(자극), 0.1초 만에 위빙으로 피하고(응답), 카운터 펀치를 90% 확률로 적중시킨다(척도)"처럼 구체적이어야 정확한 훈련(아키텍처 설계)이 가능합니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	모호한 비기능 요구사항 (AS-IS)	시나리오 기반 정의 (TO-BE)	개선 효과
정량	배포 후 아키텍처 재설계에 따른 공수 3개월	설계 단계에서 병목 예방 및 검증	후반부 구조 변경에 따른 비용(Rework Cost) 80% 절감
정량	성능/부하 테스트 기준 부재로 인한 검증 지연	구체적 응답 척도 기반의 자동화 테스트 구현	품질 검증 및 인수 테스트(UAT) 시간 단축
정성	개발자와 고객 간의 "느리다/빠르다" 주관적 분쟁	명확한 수치 합의로 커뮤니케이션 오해 소멸	아키텍처 의사결정의 객관적 논리 및 합리성 확보

미래 전망

Infrastructure as Code (IaC)와의 결합: 품질 속성 시나리오는 단순한 문서를 넘어 시스템 모니터링 툴(Datadog, Prometheus)의 알람(Alert) 규칙으로 1:1 변환되고 있다. "응답 시간이 1초를 초과하면(시나리오 실패) 오토스케일링으로 서버를 늘려라"와 같이 아키텍처 스스로 시나리오를 만족시키기 위해 진화하는 자가 치유(Self-healing) 인프라로 발전 중이다.
카오스 엔지니어링 (Chaos Engineering): 가용성이나 보안성 시나리오를 종이 위에서 평가하는 것을 넘어, Netflix의 Chaos Monkey처럼 운영 환경에 일부러 장애(자극)를 발생시켜 시스템이 시나리오에 명시된 응답 척도(복구 시간)를 실제로 지키는지 런타임에 지속 검증하는 훈련으로 고도화되고 있다.

참고 표준

ISO/IEC 25010: 소프트웨어 및 시스템 품질 모델 (기능적합성, 성능 효율성, 호환성, 사용성, 신뢰성, 보안성, 유지보수성, 이식성)
SEI ATAM: 카네기 멜런 대학의 아키텍처 트레이드오프 분석 방법론 (품질 속성 시나리오를 핵심 입력으로 사용)

아키텍처 품질 속성은 시스템의 뼈대(Skeleton)를 결정짓는 중력과 같다. 중력을 무시하고 건물을 지으면 반드시 무너지듯, 성능이나 보안 같은 비기능 요구사항을 시나리오라는 수치화된 계약서로 못 박지 않은 아키텍처는 오픈과 동시에 모래성처럼 허물어진다. 기술사는 기능(Feature) 구현에만 매몰된 개발자들의 시선을 끌어올려, 시스템이 어떤 극단적 자극(해킹, 트래픽 폭주) 환경 속에서도 살아남을 수 있도록 시나리오 기반의 혹독한 검증 틀을 짜는 마스터 플래너가 되어야 한다.

📢 섹션 요약 비유: 튼튼한 다리를 짓기 위해 설계도(기능)만 그리는 것이 아니라, "진도 7의 지진(자극)이 1분간 왔을 때(환경) 다리가 무너지지 않고 버틴다(척도)"는 극한의 시나리오를 먼저 세우고 그에 맞춰 철근(아키텍처)의 두께를 결정하는 위대한 엔지니어링의 출발점입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
6가지 시나리오 요소	시나리오를 구성하는 필수 원자재(자극원, 자극, 환경, 대상, 응답, 응답 척도). 280번 토픽에서 상세히 다룸.
ATAM (Architecture Trade-off Analysis Method)	아키텍처가 품질 속성 시나리오들을 얼마나 잘 만족시키는지 평가하고, 속성 간의 충돌(Trade-off)을 조율하는 평가 기법.
SLA (Service Level Agreement)	서비스 제공자와 고객 간에 맺는 서비스 수준 협약서. 품질 속성 시나리오의 '응답 척도'가 법적 계약 형태로 발전한 것.
비기능적 요구사항 (NFR)	품질 속성과 동의어로 쓰이며, 기능이 아닌 시스템의 성능, 가용성, 보안성 등을 지칭하는 요구공학 용어.
카오스 엔지니어링 (Chaos Engineering)	도출된 결함/장애 시나리오를 실제 라이브 서버에 주입하여 시스템의 복원력을 실전 테스트하는 최신 데브옵스 기법.

👶 어린이를 위한 3줄 비유 설명

장난감 자동차를 만들 때 "그냥 좋은 차 만들어줘"라고 하면 어떤 게 좋은 건지 알 수가 없어요.
그래서 "아무리 세게 던져도(자극) 절대 부서지지 않고(응답), 10미터 이상 굴러가야 해(척도)"라고 아주 구체적인 상황을 그림 그리듯 적어둬야 해요.
이렇게 시스템이 얼마나 빠르고 튼튼해야 하는지 정확한 목표 상황을 꼼꼼하게 적어두는 것을 **'품질 속성 시나리오'**라고 한답니다!