SW 아키텍처 평가로 품질 목표와 설계 위험 검증하기
SW 아키텍처 평가의 목적과 시기별 접근, SAAM·ATAM·CBAM·ARID의 차이, 품질 속성 시나리오와 절충 관계를 실무 관점에서 정리합니다.
2026-08-15 · 최초 발행 2026-04-17
설계가 품질 요구를 감당할 수 있는지 확인하는 일
아키텍처는 시스템의 구조와 품질 특성을 좌우하는 설계 결과물이다. SW 아키텍처 평가는 제안된 구조가 비즈니스 목표와 가용성, 성능, 보안성, 유지보수성 같은 품질 요구를 충족할 수 있는지 설계 수준에서 분석하고 검증하는 과정이다.
이 활동은 설계 문서를 읽는 데 그치지 않는다. 특정 품질 속성을 달성하기 위해 채택한 설계 전략 또는 패턴인 아키텍처 접근법이 비기능적 요구사항에 어떤 영향을 주는지 검토하고, 아키텍처 결정의 적합성을 객관적으로 판단한다. 구현 전에 잠재 위험을 찾아 제거하고, 설계 구조가 요구사항을 얼마나 반영하는지 정량적 또는 정성적 지표로 판단하는 데 목적이 있다. 복잡한 마이크로서비스 아키텍처와 클라우드 환경에서는 설계 결함을 일찍 찾아 기술적 부채를 줄이는 수단으로도 쓰인다.
품질 속성 사이에는 상충 관계가 생길 수 있다. 평가는 이러한 관계를 드러내고 결정의 타당성을 검토하며, 아키텍처가 비즈니스 목표와 연결되는지 확인한다. 설계와 요구사항을 두고 개발 팀과 이해관계자가 같은 기준으로 대화하게 하는 역할도 맡는다.
구현 전에 얻는 검토 효과
아키텍처 결함은 구현 이후 발견될수록 수정 비용이 기하급수적으로 증가할 수 있다. 설계 단계에서 문제를 다루면 상대적으로 매우 적은 비용으로 해결할 수 있다.
평가 과정은 설계자가 자신의 결정과 근거를 다시 검토하도록 만든다. 이 과정에서 설계의 완성도가 높아질 수 있으며, 대규모 재작업으로 이어질 구조적 결함이나 성능 병목도 구현 전에 식별할 수 있다. 비즈니스 이해관계자의 요구가 실제 기술 구조에 적절히 반영됐는지 확인하는 기회이기도 하다.
평가 시점에 따라 달라지는 검증 대상
| 구분 | 설명 | 특징 |
|---|---|---|
| Early (구축 전) | 아키텍처 설계가 진행 중이거나 완료된 직후 수행 | 가장 큰 비용 절감 효과, 설계 방향성 수정 용이 |
| Discovery Review | 개발 초기 이른 시점에 수행하는 미니 평가 | 핵심적인 아키텍처 결정 사항에 대한 빠른 피드백 제공 |
| Late (구현 후) | 시스템이 이미 구현되어 운영 중이거나 구축 완료 후 수행 | 실제 구현체와 설계 간의 일치성 검증, 차기 시스템을 위한 학습 |
Early 평가는 설계 방향을 바꾸기 쉬운 시점에 수행한다. Discovery Review는 개발 초기에 핵심 결정에 대한 빠른 피드백을 얻기 위한 미니 평가다. Late 평가는 운영 중이거나 구축이 끝난 시스템을 대상으로 구현체와 설계의 일치 여부를 확인하고, 다음 시스템에 적용할 학습을 남긴다.
시나리오부터 수학 모델까지의 평가 접근
평가 방법론은 기술적 접근에 따라 네 가지 유형으로 나뉜다.
- 시나리오 기반(Scenario based)은 품질 속성을 구체적인 사용 사례나 시나리오로 표현하고, 아키텍처가 이를 어떻게 처리하는지 분석한다. 범용적으로 가장 널리 사용되는 방식이다.
- 시뮬레이션 기반(Simulation based)은 아키텍처 모델을 실행 가능한 코드로 변환하거나 전용 시뮬레이터로 성능과 부하 처리를 예측한다.
- 수학적 모델 기반(Mathematical model based)은 큐잉 이론이나 복잡도 모델 같은 수학적 공식을 사용해 성능이나 신뢰성을 정량적으로 분석한다.
- 경험 기반(Experience based)은 전문가 지식과 유사 프로젝트 사례를 바탕으로 체크리스트나 리뷰를 수행한다.
SAAM·ATAM·CBAM·ARID가 판단하는 것
SAAM(Software Architecture Analysis Method)은 최초로 체계화된 아키텍처 평가 방법론이다. 기능적 적합성과 수정 가능성에 초점을 두며, 시스템이 앞으로 얼마나 쉽게 변경될 수 있는지를 여러 시나리오로 분석한다. 시나리오 기반 평가 방식을 처음 도입했으며, 변경 요구사항이 발생했을 때 아키텍처가 얼마나 유연하게 대응할 수 있는지 검토한다.
ATAM(Architecture Trade-off Analysis Method)은 대표적인 시나리오 기반 평가 방법론이다. 시스템의 품질 요소를 종합적으로 다루면서, 한 품질을 높일 때 다른 품질이 저하될 수 있는 절충 관계(Trade-off)를 드러내는 데 맞춰져 있다. 민감도(Sensitivity)와 절충점(Trade-off)을 식별해 의사결정을 지원한다. 민감점(Sensitivity Point)은 특정 아키텍처 결정이 특정 품질 속성에 큰 영향을 주는 지점이며, 절충점(Tradeoff Point)은 여러 품질 속성에 영향을 주어 한쪽 개선이 다른 쪽 저하로 이어지는 지점이다.
CBAM(Cost Benefit Analysis Method)은 ATAM의 결과에 경제적 관점을 더한다. 기술적으로 우수한 설계인지뿐 아니라 비용 대비 효과가 가장 높은 설계안이 무엇인지 분석해, 한정된 리소스 안에서 비즈니스 가치를 극대화할 아키텍처 선택을 돕는다. 투입 비용 대비 효용(Utility)과 투자 대비 효과(ROI)를 산출해 경영진의 의사결정을 지원한다.
ARID(Active Reviews for Intermediate Designs)는 ATAM과 SAAM의 장점을 취하면서 ADR(Active Design Review) 방식을 혼합한 기법이다. 전체 아키텍처가 완성되기 전의 중간 설계에 집중하며, 설계가 실제로 구현 가능하고 개발자가 이해하기 쉬운지 검증한다. 특정 부분 또는 일부 기능을 대상으로 해당 설계가 실제 구현 단계에서 사용 가능한지(Usability), 다른 모듈과의 상호작용이 원활한지도 확인한다.
평가 기법을 선택으로 연결하는 흐름
평가 계획을 세운 뒤 시나리오의 우선순위를 정하고 설계를 설명한 다음, 아키텍처 접근법을 분석해 결과와 의사결정으로 연결한다. 수행 시점을 정한 뒤 사전 설계 평가에서는 ATAM과 ARID 같은 방법을 적용할 수 있다. ATAM의 분석 결과는 CBAM을 통해 비용과 경제성 판단으로 보강할 수 있으며, ARID의 중간 설계 검증 결과와 함께 최적 아키텍처 선택 및 위험 제거로 이어진다.
품질 속성 시나리오로 설계를 검토하는 방식
품질 속성 중심의 평가는 시나리오를 바탕으로 진행한다. 시나리오는 자극(Stimulus), 환경(Environment), 응답(Response)으로 구성되며, 이를 통해 아키텍처가 상황 변화에 얼마나 견고하게 대응하는지 확인한다.
컴포넌트 사이의 인터페이스와 데이터 흐름을 추적하면 병목 지점이나 단일 장애점(SPOF)을 식별할 수 있다. 이해관계자가 함께 참여하는 시나리오 워크스루에서는 트래픽 급증이나 데이터베이스 장애처럼 특정 상황을 가정하고, 아키텍처의 동작을 단계별로 검증한다. 과거의 모범 사례(Best Practices)와 카탈로그화된 설계 원칙을 활용한 체크리스트는 설계에서 빠진 요소를 점검하는 데 쓰인다.
평가 결과를 개발 과정에 남기려면
평가 방법론만 적용해서는 충분하지 않다. 비즈니스 목표가 기술적 품질 요구사항으로 명확히 정의돼야 하며, 아키텍트·프로젝트 관리자·고객 등 다양한 이해관계자가 시나리오 도출에 참여해야 객관성을 확보할 수 있다.
평가 중 확인된 리스크(Risk)와 비리스크(Non-Risk)는 문서화해 이후 개발 과정에서 참고할 수 있도록 관리한다. 이런 기록이 있어야 평가가 일회성 검토로 끝나지 않고 설계와 구현의 판단 근거로 남는다.
Sources
- Software Architecture in Practice (3rd Edition), SEI Series
- IEEE Std 1471: Recommended Practice for Architectural Description of Software-Intensive Systems
- SEI (Software Engineering Institute) Technical Reports on Architecture Evaluation Methods
- Bass, L., Clements, P., & Kazman, R. (2012). Software Architecture in Practice. Addison-Wesley Professional.
- Clements, P., Kazman, R., & Klein, M. (2002). Evaluating Software Architectures: Methods and Case Studies. Pearson Education.
- SEI (Software Engineering Institute) Architecture Tradeoff Analysis Method (ATAM) Documentation.