98. SAAM (Software Architecture Analysis Method) - 소프트웨어 아키텍처 평가법의 시초

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

본질: SAAM (Software Architecture Analysis Method)은 소프트웨어 아키텍처가 향후 요구사항 변경(시나리오)을 얼마나 쉽게 수용할 수 있는지를 평가하는 체계적 방법론이다.

가치: 추상적인 아키텍처의 품질을 '시나리오'라는 구체적인 테스트 케이스로 변환하여, 모듈 간의 결합도와 응집도를 정량적으로 측정하고 예측할 수 있게 해 준다.

판단 포인트: 여러 시나리오가 단일 컴포넌트의 수정을 집중적으로 요구(상호작용)한다면, 해당 컴포넌트가 과도한 책임을 지고 있어 향후 유지보수 병목이 될 위험이 크다고 판단해야 한다.

Ⅰ. 개요 및 필요성

SAAM (Software Architecture Analysis Method)은 1994년 카네기멜론 대학교 부설 SEI (Software Engineering Institute)에서 제안한 최초의 소프트웨어 아키텍처 평가 기법이다. 초기 소프트웨어 공학에서는 구축된 아키텍처가 "미래에 얼마나 수정하기 쉬울 것인가"를 검증할 객관적인 기준이나 절차가 부재했다.

아키텍처 설계가 잘못되면 기능 구현은 당장 가능하더라도, 작은 요구사항 변경 시 시스템 전체를 뜯어고쳐야 하는 재앙이 발생한다. SAAM은 이러한 리스크를 방지하기 위해, 다양한 이해관계자들이 모여 미래의 변경 상황을 가정하고, 그 변경이 현재 구조에 미치는 파급 효과를 미리 가늠해 보기 위해 도입되었다.

📢 섹션 요약 비유: SAAM은 건물 설계도만 보고 실시하는 모의 소방 훈련과 같다. 실제로 불(요구사항 변경)이 났을 때 사람들이 대피하기 쉬운 구조인지, 기둥 몇 개를 허물고 고쳐야 하는지 설계도 위에서 미리 검증하는 것이다.

Ⅱ. 아키텍처 및 핵심 원리

SAAM의 핵심 원리는 '시나리오 (Scenario)' 기반 평가다. 시스템에 요구될 수 있는 변경 작업을 시나리오로 작성하고, 이 시나리오들이 아키텍처의 어느 컴포넌트를 건드리는지 추적한다.

평가 과정은 시나리오를 아키텍처 수정 없이 수용 가능한 '직접(Direct)' 시나리오와, 수정을 수반해야 하는 '간접(Indirect)' 시나리오로 분류하는 것부터 시작된다.

┌─────────────────────────────────────────────────────────────┐
│             SAAM의 시나리오 상호작용 (Interaction) 분석          │
├─────────────────────────────────────────────────────────────┤
│   [시나리오 1] "결제 수단 추가" ──────▶  [컴포넌트 A] (수정 1)  │
│                                            ▲                │
│   [시나리오 2] "UI 테마 변경" ──(독립)─▶  [컴포넌트 B] (수정 2)  │
│                                            │                │
│   [시나리오 3] "보안 암호화 강화" ─────┘ (수정 3)            │
│                                                             │
│ * 컴포넌트 A에 서로 다른 성격의 간접 시나리오(1,3)가 집중됨      │
│ * 진단: 컴포넌트 A의 응집도가 낮고 역할이 혼재됨 (SRP 위배 의심)  │
└─────────────────────────────────────────────────────────────┘

가장 중요한 검증 단계는 시나리오 상호작용 (Scenario Interaction) 분석이다. 만약 기능 추가(시나리오 1)와 보안 패치(시나리오 3)라는 전혀 다른 목적의 변경이 동일한 컴포넌트를 뜯어고치게 만든다면, 그 컴포넌트는 단일 책임 원칙 (SRP, Single Responsibility Principle)을 위배하여 과도하게 얽혀 있는 설계(스파게티 코드)일 확률이 높다.

📢 섹션 요약 비유: SAAM 평가는 자동차 부품 테스트다. "라디오 채널 바꾸기"(직접 시나리오)는 버튼만 누르면 되지만, "에어컨 필터 교체"(간접 시나리오)를 위해 대시보드를 전부 뜯어야 한다면 설계가 잘못되었다고 잡아내는 과정이다.

Ⅲ. 비교 및 연결

SAAM은 아키텍처 평가의 선구자지만, 특정 품질 속성(주로 수정 용이성)에만 편향되어 있다는 한계가 있었다. 이를 극복하기 위해 후속 모델인 ATAM이 등장했다.

구분	SAAM	ATAM (Architecture Trade-off Analysis Method)
등장 시기	1994년 (초기 평가 모델)	1998년 (발전/종합 모델)
주요 목적	수정 용이성(Modifiability) 중심의 단일 품질 평가	다중 품질 속성 간의 상충 관계(Trade-off) 분석
핵심 기법	시나리오의 직접/간접 분류 및 상호작용 파악	민감도점(Sensitivity Point) 및 상충점 도출
적용 범위	시스템의 구조적 결합도, 유지보수성 진단	성능, 보안성, 가용성 등 전사적 아키텍처 품질 검증

SAAM이 "이거 고치기 편한가?"만 물었다면, ATAM은 "고치기 편하게 만들면 보안이나 속도는 안 떨어지는가?"까지 확장하여 시스템의 전체 균형을 연결하여 평가한다.

📢 섹션 요약 비유: SAAM이 자동차의 '정비 편의성'만 체크하는 정비사라면, ATAM은 정비 편의성은 물론이고 '승차감', '연비', '최고 속도'까지 서로 간의 밸런스를 모두 점검하는 수석 엔지니어다.

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

현대 대규모 프로젝트에서 SAAM을 단독으로 사용하는 경우는 드물지만, 그 핵심 논리인 '변경 영향도 분석'은 감리 및 유지보수 실무에 여전히 유효하다.

판단 가이드라인

레거시 전환 (Modernization) 시: 기존 모놀리식 시스템을 MSA(Microservices Architecture)로 쪼갤 때, 과거 장애 보고서나 추가 요구사항들을 SAAM의 시나리오로 치환하여 적용해 본다. 가장 상호작용이 심한(수정이 빈번했던) 덩어리가 최우선 분리 대상이다.
설계 단계 감리: 아키텍트가 제출한 설계 산출물 검토 시, 이해관계자들을 모아 가상의 비즈니스 변경 시나리오 3~5개를 던져본다. 특정 공통 모듈에 수정이 몰린다면 병목 컴포넌트이므로 설계를 리팩터링 하도록 권고해야 한다.
한계 인식: SAAM은 기능적 수정 용이성 판단에는 탁월하지만, 동시 접속자 수 10만 명 돌파와 같은 '비기능적 성능 시나리오'를 평가하기에는 지표가 부족하므로 반드시 ATAM 등과 병행해야 한다.

📢 섹션 요약 비유: 기술사가 SAAM을 쓰는 것은 젠가 게임의 블록을 찔러보는 것과 같다. 요구사항이라는 손가락으로 이리저리 찔러보았을 때, 블록 하나만 빼도 전체가 흔들린다면 그 부분의 구조적 결함을 실무적으로 지적하는 것이다.

Ⅴ. 기대효과 및 결론

SAAM은 주관적이었던 아키텍처 설계를 '시나리오'라는 정량적 도구로 테스트할 수 있게 만든 최초의 이정표다. 변경의 파급 효과를 미리 계산함으로써 유지보수 비용을 획기적으로 절감하고, 설계 초기에 잠재적 구조 결함을 잡아낼 수 있게 되었다.

비록 오늘날에는 ATAM이나 경제성까지 고려한 CBAM(Cost Benefit Analysis Method) 등 더 복잡한 방법론에 표준의 자리를 넘겨주었지만, **"시나리오를 통해 아키텍처의 약점을 미리 들춰낸다"**는 철학은 모든 현대 소프트웨어 공학의 뿌리로 굳건히 남아있다.

📢 섹션 요약 비유: SAAM은 인류 최초의 나침반과 같다. 지금은 GPS(ATAM, CBAM)가 그 자리를 대신하지만, 나침반이 세워둔 '방향을 미리 측정한다'는 원리가 없었다면 현대의 정밀한 항법 장치도 존재할 수 없었다.

📌 관련 개념 맵

개념	연결 포인트
품질 속성 시나리오 (Quality Attribute Scenario)	아키텍처 평가에 사용되는 자극(Stimulus), 환경, 응답 측정의 기본 단위
ATAM (Architecture Trade-off Analysis Method)	SAAM의 한계를 넘어 다중 품질 속성의 상충관계를 분석하는 후속 기법
단일 책임 원칙 (SRP, Single Responsibility Principle)	SAAM의 시나리오 상호작용 검증 시 가장 먼저 평가되는 객체지향 핵심 원칙
CBAM (Cost Benefit Analysis Method)	아키텍처 결정에 따른 기술적 이점과 경제적 비용을 함께 분석하는 기법

📈 관련 키워드 및 발전 흐름도

소프트웨어 설계의 주관성 · 평가 기준 부재
    │
    ▼
SAAM (Software Architecture Analysis Method)
(수정 용이성 중심, 최초의 시나리오 기반 평가)
    │
    ▼
ATAM (Architecture Trade-off Analysis Method)
(다중 품질 속성 간의 상충 관계 및 민감도 분석)
    │
    ▼
CBAM (Cost Benefit Analysis Method)
(비즈니스 가치와 경제성 평가 통합)

이 흐름도는 단일 품질(유지보수성) 진단에서 출발해, 종합 기술 평가를 거쳐, 경제적 비즈니스 가치 평가로 확장되는 아키텍처 평가 방법론의 진화를 보여준다.

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

내가 만든 레고 성이 있는데, 나중에 "창문을 성문으로 바꾸자!"라는 계획(시나리오)이 생겼다고 상상해 봐요.
SAAM은 이 계획을 진짜로 하기 전에 "레고 블록을 몇 개나 부수고 다시 조립해야 할까?"를 미리 계산해 보는 검사법이에요.
계산해 봤더니 맨 밑바닥 블록 하나 때문에 성 전체를 다 부숴야 한다면, 처음부터 레고를 잘못 조립했다는 걸 깨닫게 해준답니다!