[SE100 #026] 품질 속성 시나리오와 ATAM
소프트웨어 공학 100 주제 시리즈의 26번째 글이다. (카테고리: 설계와 아키텍처)
한 줄 요약
“빨라야 한다”, “확장 가능해야 한다” 같은 품질 요구는 그대로는 검증할 수 없다. 품질 속성 시나리오는 이를 자극·환경·응답·응답 측정값으로 구체화하고, SEI 의 ATAM(Architecture Tradeoff Analysis Method)은 그런 시나리오를 이해관계자와 함께 뽑아 우선순위를 매긴 뒤, 아키텍처의 위험·민감점·트레이드오프 지점을 찾아낸다.
왜 필요한가
요구사항 문서의 비기능 요구는 흔히 이렇게 생겼다.
- 시스템은 고성능이어야 한다.
- 시스템은 유지보수하기 쉬워야 한다.
- 시스템은 가용성이 높아야 한다.
이 문장들은 거짓이 될 수 없다. 어떤 아키텍처를 가져와도 “충분히 고성능” 이라고 주장할 수 있으니 설계를 평가하는 기준이 되지 못한다. 더 큰 문제는 품질 속성들이 서로 충돌한다는 점이다. 캐시를 넣으면 성능은 오르지만 일관성이 약해진다. 암호화를 넣으면 보안은 오르지만 지연이 는다. 마이크로서비스로 나누면 독립 배포성은 오르지만 장애 지점이 는다. 이런 충돌을 개발 막바지에, 혹은 운영 중에 발견하면 되돌리기가 가장 비싸다.
ATAM 기술 보고서는 이 점을 짚는다. 아키텍처 결정은 여러 품질 속성에 동시에 영향을 주므로, 한 속성만 분석하면 다른 속성에 대한 영향을 놓친다. 평가는 처음부터 다속성이어야 한다.
핵심 개념
원전
Rick Kazman, Mark Klein, Paul Clements, ATAM: Method for Architecture Evaluation, CMU/SEI-2000-TR-004, 2000년 8월. 카네기멜런대 소프트웨어공학연구소(SEI)가 공개한 기술 보고서이며, 보고서 PDF를 직접 읽을 수 있다. 이하 ATAM 의 정의와 절차는 이 보고서를 따른다.
품질 속성 특성화: 자극 → 결정 → 응답
보고서는 각 품질 속성을 세 범주로 특성화한다.
| 범주 | 뜻 | 성능의 예 | 변경 용이성의 예 |
|---|---|---|---|
| 외부 자극(stimuli) | 아키텍처가 반응하거나 바뀌게 만드는 사건 | 메시지, 인터럽트, 키 입력 | 소프트웨어 변경 요청 |
| 아키텍처 결정 | 응답에 직접 영향을 주는 컴포넌트·커넥터와 그 속성 | 프로세서·네트워크 중재, 프로세스·스레드 구조, 우선순위 | 캡슐화, 간접화 메커니즘 |
| 응답(responses) | 측정·관찰 가능한 양 | 지연, 처리량 | 영향받는 컴포넌트·커넥터·인터페이스 수, 변경 노력 |
품질 속성 시나리오
보고서는 잘 형성된 시나리오의 조건을 이렇게 말한다. 자극이 무엇인지, 환경 조건이 무엇인지, 응답의 측정 가능한·관찰 가능한 표현이 무엇인지가 분명해야 한다. 예로 든 시나리오들은 다음과 같다.
- 원격 사용자가 피크 시간에 웹으로 DB 보고서를 요청하면 5초 안에 받는다. (성능)
- 캐시 시스템의 프로세서가 고장 나면 1초 안에 다른 프로세서로 넘어간다. (신뢰성)
- 새 메시지 유형을 1인주(person-week) 미만의 작업으로 추가한다. (변경 용이성)
Bass, Clements, Kazman 의 교재 Software Architecture in Practice 는 이를 여섯 부분 형식으로 정리한다.
출처(Source) ── 자극(Stimulus) ──▶ [ 대상(Artifact) / 환경(Environment) ] ──▶ 응답(Response)
│
응답 측정(Response Measure)
| 부분 | 결제 API 예 |
|---|---|
| 출처 | 외부 가맹점 시스템 |
| 자극 | 결제 승인 요청 |
| 대상 | 결제 API 와 승인 DB |
| 환경 | 평상시 부하의 3배인 연말 피크, DB 레플리카 1대 장애 상태 |
| 응답 | 요청을 처리하고 결과를 반환 |
| 응답 측정 | p99 지연 800 ms 이하, 오류율 0.1% 이하 |
“고성능이어야 한다” 와 비교하면 차이가 분명하다. 이 시나리오는 틀릴 수 있다. 그래서 설계를 평가하는 기준이 된다. (표의 수치는 설명용 예다.)
ATAM 의 시나리오 세 종류
| 종류 | 목적 | 보고서의 예 |
|---|---|---|
| 유스케이스 시나리오 | 완성된 시스템의 전형적 사용. 정보 수집용 | 피크 시간 보고서 요청 5초 내 응답 |
| 성장(growth) 시나리오 | 예상되는 변경 | 추적 대상 수가 두 배가 돼도 화면 지연 200 ms 유지 |
| 탐색(exploratory) 시나리오 | 시스템을 한계까지 미는 극단적 변경. 암묵적 가정 노출 | 기반 플랫폼을 완전히 다른 OS 로 교체 |
유틸리티 트리
유틸리티 트리는 비즈니스 목표를 품질 속성 요구로 하향식으로 옮기는 도구다. 루트는 “유틸리티”(시스템의 전반적 좋음), 그 아래 품질 속성, 세부 요인, 잎에는 구체적 시나리오가 온다. 아래는 결제 시스템을 가정한 설명용 예다.
유틸리티
├── 성능
│ ├── 데이터 지연 ── (M,L) 주문 조회 API 평균 응답 50 ms 이하
│ └── 처리량 ── (H,M) 연말 피크에도 결제 승인 처리량 유지
├── 가용성
│ └── 장애 조치 ── (H,H) 결제 노드 1대 장애 시 30초 내 자동 전환
└── 변경 용이성
└── 새 결제 수단 ── (H,L) 새 간편결제 추가 2인주 이내
잎마다 두 축으로 우선순위를 매긴다. 첫째 시스템 성공에 대한 중요도, 둘째 달성에 대한 인지된 위험(난이도). 보고서는 0~1 척도보다 High/Medium/Low 상대 등급을 선호한다고 밝히는데, 이해관계자가 그보다 세밀한 구분을 안정적으로 하지 못하기 때문이다. (H,H) 잎이 분석의 최우선 대상이다. 보고서는 유틸리티 트리를 정제하는 과정에서, 처음에는 보안과 변경 용이성만 핵심이라 여겼던 이해관계자들이 성능과 가용성도 중요하다는 것을 발견한 사례를 소개한다.
위험, 비위험, 민감점, 트레이드오프 지점
ATAM 의 산출물은 “통과/불합격” 이 아니라 아래 네 가지 목록이다.
| 산출물 | 보고서의 정의 | 예 |
|---|---|---|
| 위험(risk) | 아직 내려지지 않은 중요한 결정, 또는 내려졌지만 결과가 충분히 이해되지 않은 결정 | OS 이식 레이어를 두기로 했지만 무엇을 넣을지 모름 |
| 비위험(non-risk) | 흔히 암묵적인 가정에 기대는 좋은 결정. 명시적으로 기록 | 결제 데이터는 단일 리전 DB 로 충분 — 트래픽 가정이 유지되는 한 |
| 민감점(sensitivity point) | 측정 가능한 품질 응답과 높은 상관을 갖는 아키텍처 파라미터 | 특정 통신 채널의 처리량이 전체 처리량을 좌우 |
| 트레이드오프 지점(tradeoff point) | 한 파라미터가 둘 이상의 민감점이고, 바꾸면 품질 속성들이 서로 다르게 영향을 받는 곳 | 채널 속도를 올리면 처리량은 오르지만 신뢰성은 떨어짐 |
트레이드오프 지점이 가장 값진 발견이다. 거기가 바로 “한쪽을 얻으려면 다른 쪽을 내줘야 하는” 결정이며, 그 결정은 ADR(SE100 #025)로 남길 대상이다.
아홉 단계와 두 단계(phase)
| 묶음 | 단계 |
|---|---|
| 발표 | 1. ATAM 소개 2. 비즈니스 동인 발표(프로젝트 관리자) 3. 아키텍처 발표(아키텍트) |
| 조사·분석 | 4. 아키텍처 접근법 식별 5. 품질 속성 유틸리티 트리 생성 6. 접근법 분석 — 위험·민감점·트레이드오프 식별 |
| 테스트 | 7. 시나리오 브레인스토밍과 우선순위 투표(이해관계자 전체) 8. 접근법 재분석 — 상위 시나리오를 테스트 케이스로 |
| 보고 | 9. 결과 발표 |
보고서는 이를 두 phase 로 수행한다고 설명한다. Phase 1 은 아키텍처 중심으로, 평가팀 일부(대개 1~3명)가 아키텍트와 만나 1~6단계를 축소 수행하며 정보를 모은다. Phase 2 는 이해관계자 중심으로, 더 넓은 이해관계자가 참여해 관점을 끌어내고 1단계 결과를 검증한다. 유틸리티 트리(하향식, 아키텍트·핵심 이해관계자)와 브레인스토밍(상향식, 전체 이해관계자)이 서로를 보완한다.
실무 적용: 반나절 미니 ATAM
정식 ATAM 은 외부 평가팀과 며칠이 필요하다. 팀 내부에서는 다음처럼 축소해도 효과가 크다.
- 비즈니스 동인 15분: 제품 책임자가 “올해 이 시스템이 실패하면 왜일까” 를 말한다.
- 아키텍처 30분: C4 컨테이너 다이어그램 한 장으로 설명(SE100 #024).
- 유틸리티 트리 60분: 품질 속성별로 시나리오를 여섯 부분 형식으로 쓰고 (중요도, 위험)을 H/M/L 로 매긴다.
- 분석 90분: (H,H)·(H,M) 시나리오마다 아키텍처를 따라가며 질문한다. “이 응답 측정값을 무엇이 결정하는가(민감점)? 그걸 바꾸면 무엇이 나빠지는가(트레이드오프)? 아직 정하지 않은 것은(위험)?”
- 정리 30분: 아래 표를 채우고, 위험마다 담당자와 대응(프로토타입, 부하 테스트, ADR)을 붙인다.
| ID | 시나리오 | 관련 결정 | 분류 | 근거 | 대응 |
|----|----------|-----------|------|------|------|
| R1 | 피크 3배 시 p99 800ms | 동기 PG 호출 | 위험 | PG 지연 분포 미측정 | 부하 테스트(담당: A) |
| T1 | 노드 장애 30초 전환 | 세션 고정 LB | 트레이드오프 | 전환 빠름 vs 세션 유실 | ADR-0012 작성 |
| N1 | 새 결제 수단 2인주 | 결제 포트 인터페이스 | 비위험 | 수단 추가가 어댑터 1개로 끝남 | — |
흔한 오해와 함정
- “ATAM 은 아키텍처를 채점한다.” 산출물은 점수가 아니라 위험·민감점·트레이드오프 목록이다. 목적은 어디에 설계·분석·프로토타입 노력을 쏟을지 아는 것이다.
- “품질 요구 = 형용사.” “확장 가능해야 한다” 는 시나리오가 아니다. 자극, 환경, 측정 가능한 응답이 없으면 평가할 수 없다.
- “모든 시나리오를 다 분석한다.” 유틸리티 트리의 핵심은 우선순위다. (H,H) 부터 본다.
- “아키텍트끼리 하면 된다.” Phase 2 와 7단계는 이해관계자 전체를 위한 것이다. 운영자·테스터·유지보수자의 시나리오가 아키텍트의 사각지대를 드러낸다.
- “비위험은 기록할 필요 없다.” 보고서는 비위험도 명시적으로 기록하라고 한다. 비위험은 대개 암묵적 가정에 기대고 있어서, 그 가정이 깨지면 위험이 된다.
확인 문제
- ATAM 보고서가 말하는 잘 형성된 시나리오의 세 가지 조건은?
- 민감점과 트레이드오프 지점의 차이는?
- 유틸리티 트리의 잎에 매기는 두 가지 우선순위 축은?
- 성장 시나리오와 탐색 시나리오의 차이를 예와 함께 설명하라.
- “시스템은 고가용성이어야 한다” 를 여섯 부분 시나리오로 다시 써 보라.
풀이
- 자극이 무엇인지, 환경 조건이 무엇인지, 응답의 측정·관찰 가능한 표현이 무엇인지가 분명해야 한다.
- 민감점은 하나의 품질 응답과 높은 상관을 갖는 파라미터다. 트레이드오프 지점은 그런 파라미터가 둘 이상의 민감점이어서, 바꾸면 여러 품질 속성이 서로 다른 방향으로 영향을 받는 곳이다.
- 시스템 성공에 대한 중요도, 그리고 달성의 인지된 위험(난이도).
- 성장 시나리오는 예상되는 전형적 변경(예: 처리 대상 수가 두 배로 늘어도 지연 유지)이고, 탐색 시나리오는 시스템을 한계까지 미는 극단적 변경(예: 기반 플랫폼 전체 교체)으로 암묵적 가정을 드러내는 것이 목적이다.
- 예: 출처 — 인프라, 자극 — 주문 API 노드 1대의 프로세스 크래시, 대상 — 주문 API, 환경 — 평상시 부하, 응답 — 남은 노드로 트래픽 전환 및 크래시 노드 재시작, 응답 측정 — 30초 이내 전환, 그 사이 실패 요청 비율 1% 이하.
더 읽을거리 (References)
- Rick Kazman, Mark Klein, Paul Clements, ATAM: Method for Architecture Evaluation, CMU/SEI-2000-TR-004, 2000 (PDF)
- Len Bass, Paul Clements, Rick Kazman, Software Architecture in Practice, 4th ed., Addison-Wesley, 2021 (서지 정보)
- ISO/IEC/IEEE 42010 공식 사이트, Home — 아키텍처 평가 프레임워크 ISO/IEC/IEEE 42030 공지 포함
- CS300: 요구사항 분석