아키텍처 평가

[ 아키텍처 평가 ]

아키텍처 평가는

설계한 아키텍처(또는 디자인 패턴)가

기능 요구사항과 비기능(품질) 요구사항을

실제로 만족할 수 있는지 점검하는 과정이다.

 

구현 전에 구조적 문제를 미리 발견하고,

시스템을 더 잘 이해하고,

근거를 남겨 문서화하는 데 목적이 있다.

 

특히 규모가 커질수록 아키텍처의 선택은

성능, 유지보수성, 보안, 가용성 같은

품질 속성에 큰 영향을 준다.

 

그래서 코드가 쌓인 뒤에

뒤늦게 구조를 뜯어고치기보다,

시나리오와 품질 속성을 기준으로

설계를 평가하는 편이 비용이 훨씬 작다.

---

아키텍처 평가에서 보는 것들

아키텍처 평가에서는 보통 아래를 확인한다.

• 기능 요구사항을 지원하는
  흐름이 구조적으로 가능한가
• 품질 요구사항의 목표가 무엇이고,
  (성능/보안/가용성/유지보수성/사용성 등)
  어디에서 흔들릴 수 있는가
• 변경(새 기능 추가, 환경 변경, 리팩토링)이
  들어왔을 때 구조가 버틸 수 있는가
• 타협점(trade-off)과 리스크가 어디에 숨어 있는가

---

대표 방법 2가지: SAAM, ATAM

아키텍처 평가 기법은 여러 가지가 있지만,

실무/교재에서 자주 등장하는 대표 축은

다음 두 가지다.

• SAAM
  시나리오 기반 평가로 시나리오를
  실행할 수 있는지와 변경 비용을 중심으로 점검
• ATAM
  시나리오 기반이면서도 여러 품질 속성 간의
  trade-off와 리스크 발굴을 중심으로 점검

아래부터는 각 방법을 흐름도와 표로 정리한다.

---

1. SAAM

1-1) 핵심 아이디어

SAAM(Software Architecture Analysis Method)은

이해관계자가 제시하는 시나리오를 기준으로

아키텍처를 평가한다.

 

시나리오는 사용자/관리자/고객 등과

시스템이 상호작용하는 상황을

짧게 서술한 것이다.

 

SAAM의 핵심은 두 가지다.

• 아키텍처가 시나리오를 실행할 수 있는지 판단
• 실행이 어렵다면 어떤 변경이 필요하고
  비용이 얼마나 드는지 추정

1-2) SAAM 진행 흐름도

[이해관계자 시나리오 수집]
          |
          v
[시나리오 우선순위 결정]
          |
          v
[아키텍처 구성요소/상호작용 매핑]
          |
          v
[시나리오 수행 가능 여부 평가]
     |               |
     | 가능          | 불가/취약
     v               v
[문서화]     [변경 필요사항 도출 + 변경비용 추정]
          |
          v
[결과 정리/공유]

 

1-3) 시나리오 유형

SAAM에서는 시나리오를 보통

직접/간접 시나리오로 나눠서 본다.

구분	의미	평가 관점 예시
직접 시나리오	시스템 변경이 필요 없는 시나리오	일반 유스케이스 지원, 인터페이스가 제공하는 보통 기능, 스트레스/장기간 사용 시 데이터 붕괴 여부, 통신 무결성 등
간접 시나리오	시스템 변경이 필요한 시나리오	새 기능 추가/기능 삭제, 새 하드웨어/OS/IO 환경 적응, 모듈화/최적화/재사용을 위한 재구조화 수용 가능성 등

 

1-4) SAAM 산출물

• 시나리오 목록 + 우선순위
• 시나리오-아키텍처 매핑
  (어떤 구성요소가 어떤 상호작용을 담당하는지)
• 변경 필요사항 목록
• 변경 비용 추정치(대략이라도)

---

2. ATAM

2-1) SAAM과의 차이

ATAM(Architecture Trade-off Analysis Method)은

시나리오를 쓰지만, 초점이 조금 다르다.

• 여러 품질 속성에 집중한다
  (성능/보안/가용성/유지보수성 등)
• 품질 속성 간 타협점(trade-off)을 찾아낸다
• 민감점(sensitivity point), trade-off point,
  리스크를 체계적으로 발굴한다

2-2) ATAM 진행 흐름도

[업무 배경/요구사항 공유]
          |
          v
[아키텍처 소개]
          |
          v
[품질 목표 도출 + 민감한 부분 식별]
          |
          v
[품질 속성 우선순위 + 시나리오 작성]
   (유틸리티 트리로 정리)
          |
          v
[시나리오 기반 분석/평가]
          |
          v
[trade-off / 민감점 / 리스크 도출]
          |
          v
[결과 정리 및 공유]

 

2-3) 유틸리티 트리(utility tree)란

ATAM에서 중요한 작업은 ‘어떤 품질 속성이 중요한지’와

‘그 품질을 시험할 시나리오’를 정리하는 것이다.

이 정리 방식이 유틸리티 트리다.

품질 특성	시나리오 사례
유지보수성	연동하는 시스템의 상태 확인 기능 추가, 모바일 단말기 접속 기능 추가, 수강 신청 프로세스 변경, 커리큘럼 변경 및 추가
성능	수강 과목 검색 기능 속도 향상, 수강 신청 기능 처리량 향상
가용성	데이터베이스 용량 초과로 로그 기록 불가, 데이터베이스 갱신 오류로 데이터 사용 문제
보안성	사용자 ID별 DB 접근 제어, 다른 시스템에서 접근할 때 제어하는 기능
사용용이성	신규 사용자 시스템 적응 단축, 수강 신청 오류 처리 기능의 도움말 보완

 

2-4) ATAM 산출물

• 품질 속성 우선순위(무엇을 제일 중요하게 볼지)
• 유틸리티 트리(품질 속성 ↔ 시나리오)
• 민감점/타협점(trade-off point) 목록
• 리스크와 완화 아이디어

---

3. SAAM vs ATAM 비교 표

항목	SAAM	ATAM
중심 질문	‘이 시나리오가 구조적으로 가능한가?’ ‘안 되면 바꾸려면 뭐가 필요하고 비용은?’	‘품질 목표를 만족하는가?’ ‘품질 속성 간 trade-off는?’ ‘리스크는 어디에?’
시나리오 역할	기능 수행 가능 여부 + 변경 비용 추정	품질 속성 검증 도구 (유틸리티 트리로 우선순위화)
강점	단순하고 시작하기 쉬움, 변경 관점 평가에 유리	품질 속성 중심 분석이 강함, 리스크/타협점 도출에 유리
결과물 느낌	변경 항목과 비용 추정이 또렷함	품질 목표/우선순위/리스크가 또렷함
추천 상황	초기 구조 점검, 변경이 잦은 제품에서 ‘변경 비용’이 중요한 경우	성능/보안/가용성 등 품질 요구가 까다롭고 trade-off 판단이 필요한 경우

---

[ 마무리 ]

적용 팁

• 시나리오는 ‘구체적으로’ 쓴다
  ‘빠르게 조회’ 같은 표현보다
  ‘검색 결과 2초 이내’, ‘동시 사용자 3,000명’처럼
  측정 가능한 문장으로 바꾸면 평가가 쉬워진다.
• 시나리오 우선순위는 반드시 정한다
  모든 시나리오를 같은 무게로 보면 결론이 흐려진다.
  사용자 영향도/비용/리스크 기준으로 상위부터 본다.
• 아키텍처-시나리오 매핑을 표로 남긴다
  ‘어떤 컴포넌트가 어떤 책임을 가지는지’가
  기록으로 남아야, 나중에 변경 논의가 빨라진다.

체크리스트

• 품질 속성 목표가 문장으로 정리돼 있는가
  (성능/보안/가용성/유지보수성/사용성 등)
• 이해관계자 시나리오가 수집됐는가
  (사용자/운영/개발/보안 등)
• 시나리오 우선순위가 정해졌는가
• 시나리오-구성요소 매핑이 가능한 형태로 남아 있는가
• 변경 필요사항과 변경 비용(대략)이
  기록됐는가(SAAM 관점)
• 민감점/타협점/리스크와 대응 방향이
  정리됐는가(ATAM 관점)