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

  • 최초의 아키텍처 평가법: SAAM은 카네기멜론 대학교(SEI)에서 개발한 최초의 소프트웨어 아키텍처 평가 방법론으로, 아키텍처 평가의 기초적인 틀을 확립했습니다.
  • 수정 용이성 집중: 다양한 품질 속성 중에서도 특히 **수정 용이성(Modifiability)**에 초점을 맞추어, 시스템 변경에 따른 파급 효과를 분석합니다.
  • ATAM의 전신: SAAM의 한계(단일 품질 속성 한정)를 극복하기 위해 다중 품질 속성 간의 상충 관계(Trade-off)를 평가하는 ATAM으로 발전하였습니다.

Ⅰ. 개요 (Context & Background)

SAAM(Software Architecture Analysis Method)은 1994년 SEI(Software Engineering Institute)에 의해 제안된 평가 방법론입니다. 당시에는 소프트웨어 아키텍처를 정량적, 체계적으로 평가하는 표준이 없었습니다. SAAM은 시스템이 미래의 변경 요구사항(시나리오)을 얼마나 쉽게 수용할 수 있는지를 평가하기 위해 고안되었습니다.

핵심 목적은 이해관계자들이 모여 다양한 변경 시나리오를 도출하고, 해당 시나리오들이 현재 아키텍처에 미치는 영향도를 분석하여 잠재적 리스크를 식별하는 것입니다.

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

SAAM은 '시나리오(Scenario)' 기반의 평가 기법을 사용합니다. 특정 기능 추가, 환경 변화 등의 시나리오를 시스템 아키텍처에 투영하여, 몇 개의 컴포넌트가 수정되어야 하는지를 측정합니다.

+-------------------------------------------------------------+
|               SAAM Evaluation Process (SAAM 평가 프로세스)    |
+-------------------------------------------------------------+
|  1. 시나리오 도출        (Develop Scenarios)                |
|           ↓                                                 |
|  2. 아키텍처 설명        (Describe Architecture)            |
|           ↓                                                 |
|  3. 시나리오 분류        (Classify Scenarios)               |
|     (직접 지원 vs 간접 지원/수정 필요)                      |
|           ↓                                                 |
|  4. 시나리오 평가        (Evaluate Indirect Scenarios)      |
|     (수정해야 할 컴포넌트 및 비용 산정)                     |
|           ↓                                                 |
|  5. 시나리오 상호작용 평가 (Assess Scenario Interactions)   |
|     (동일 컴포넌트에 대한 복수 시나리오 충돌 분석)          |
|           ↓                                                 |
|  6. 전체 평가 및 종합    (Create Overall Evaluation)        |
+-------------------------------------------------------------+
  1. 시나리오 도출 (Develop Scenarios): 이해관계자들이 아키텍처가 직면할 미래의 변경 요구사항을 시나리오 형태로 작성합니다.
  2. 시나리오 분류 (Classify Scenarios):
    • Direct Scenario: 아키텍처 수정 없이 바로 수용 가능한 시나리오.
    • Indirect Scenario: 아키텍처의 특정 모듈이나 구조를 수정해야 수용할 수 있는 시나리오.
  3. 평가 및 상호작용 (Interaction Analysis): 여러 개의 Indirect Scenario가 하나의 컴포넌트 수정을 요구한다면, 해당 컴포넌트는 지나치게 많은 책임(응집도 저하)을 가지고 있을 가능성이 높습니다. (이를 'Scenario Interaction'이라 합니다.)

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

비교 항목SAAM (Software Architecture Analysis Method)ATAM (Architecture Trade-off Analysis Method)
목적단일 아키텍처의 수정 용이성(Modifiability) 중심 평가다중 품질 속성 간의 상충 관계(Trade-off) 평가
등장 시기1994년 (초기 모델)1998년 (발전 모델)
평가 대상주로 변경에 따른 파급 효과 (응집도, 결합도)성능, 가용성, 보안성, 수정 용이성 등 종합 품질 속성
분석 도구시나리오 직접/간접 분류 및 상호작용 평가민감도점(Sensitivity Point), 상충점(Trade-off Point) 도출
활용도아키텍처 평가의 기초 개념 이해에 활용현대 대규모 프로젝트의 표준 아키텍처 평가로 활용

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

  • 정보시스템 감리: 시스템 구축 전 설계 단계 감리 시, 아키텍처가 향후 유지보수와 기능 확장에 유연한지 점검할 때 SAAM의 시나리오 상호작용 분석 기법을 약식으로 적용할 수 있습니다. 특정 컴포넌트에 시나리오(변경 요청)가 집중된다면, SRP(단일 책임 원칙) 위배를 의심해야 합니다.
  • 레거시 시스템 분석: 오래된 모놀리식 시스템을 차세대(MSA 등)로 전환할 때, 현재 아키텍처의 문제점을 파악하기 위해 SAAM 방식의 변경 영향도 분석이 유효합니다.

Ⅴ. 기대효과 및 결론 (Future & Standard)

SAAM은 아키텍처 평가에 '시나리오'라는 강력하고 정량화 가능한 도구를 최초로 도입했다는 데 역사적 의의가 있습니다. 비록 현재의 복잡한 시스템에서는 다중 품질 속성을 다루는 ATAM이나 경제성을 고려한 CBAM에 자리를 내주었지만, 아키텍처의 유지보수성(수정 용이성)을 검증하는 가장 직관적인 논리적 근간으로 남아있습니다.

📌 관련 개념 맵 (Knowledge Graph)

  • 상위 개념: 아키텍처 평가 (Architecture Evaluation)
  • 파생 개념: ATAM (Architecture Trade-off Analysis Method), CBAM, 시나리오 (Quality Attribute Scenario)
  • 설계 원칙 연관: 단일 책임 원칙 (SRP), 응집도 및 결합도 (Cohesion & Coupling)

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

  1. 레고로 만든 성이 있는데, 앞으로 "창문을 더 크게 만들자", "지붕을 바꾸자" 같은 계획(시나리오)을 미리 세워봐요.
  2. SAAM은 이런 계획들을 실행할 때, "레고 블록을 몇 개나 빼고 다시 꽂아야 하는지(수정 용이성)" 계산해보는 방법이에요.
  3. 만약 똑같은 기둥 하나를 계속 빼고 꽂아야 한다면, 그 기둥이 너무 많은 일을 하고 있다는 걸 발견할 수 있죠!