아키텍처 평가

학습 목표

아키텍처 평가가 무엇을·언제 하는지 설명할 수 있다.

ATAM(Architecture Tradeoff Analysis Method) 흐름과 산출물(민감점·트레이드오프·리스크)을 설명할 수 있다.

앞서 본 품질 시나리오를 평가 입력으로 쓰는 방법을 적용할 수 있다.

기술 부채를 측정·분류·상환 계획에 연결할 수 있다.

문제 상황

• "아키텍처 리뷰 한 번 하자" — 3시간 회의 후 액션 없음, 슬랙 스레드만
• PM "빠르게" vs SRE "안정" — 숫자 없이 감으로 싸움
• MSA 전환 전 부하 테스트 — Order API p99 2.4s — 누가 민감한지 목록 없음
• 레거시 공유 DB — "나중에" 3년, 이자만 누적
• C4·ADR은 있는데 품질 검증 연결 안 됨 — 문서 장식
• 장애 후 "구조적 원인" — 시나리오로 재현 안 됨

문서·결정 기록까지 갖췄다. 구조가 요구를 만족하는지 체계적으로 검증하는 편이다.

1. 아키텍처 평가란

아키텍처 평가 — 설계가 품질 속성·비즈니스 목표를 만족하는지 이해관계자와 함께 검토.

산출물	역할
C4	현재 구조 제시
품질 시나리오	검증 기준
ADR	결정·트레이드오프 기록
평가 결과	리스크·민감점·개선 우선순위

할 때	안 할 때
대규모 전환·신규 플랫폼	한 줄 버그 fix
분기 아키텍처 점검	전원 매일 ATAM
장애 구조 원인 분석	이미 합의된 팀 내부 convention

• 코드 리뷰 ≠ 아키텍처 평가 — 후자는 품질 속성·시나리오 중심
• Richards/Ford — 가벼운 워크숍도 시나리오만 있으면 가치 있음

2. ATAM 개요

ATAM — Software Architecture in Practice 의 대표 평가 방법. 트레이드오프·민감점·리스크를 명시한다.

단계	내용	산출물
1 Plan	이해관계자·비즈니스 드라이버·품질 속성 우선순위	시나리오 후보·유틸리티 트리 초안
2 Present	아키텍처 설명 (C4 Container 등)	공통 이해
3 Analyze	시나리오별 전술·민감점·리스크	sensitivity point·tradeoff 목록
4 Record	우선순위·액션·ADR	평가 리포트·백로그

• 전체 ATAM은 2~3일 워크숍 — 스타트업은 4단계 축소 버전 흔함
• 민감점(sensitivity point) — 품질에 큰 영향 주는 파라미터(타임아웃, pool size, replica 수)
• 트레이드오프 — 한 속성 개선이 다른 속성 희생

3. 품질 시나리오를 평가 입력으로

6요소 품질 시나리오

요소	의미	예
Source	자극 주체	10,000 동시 사용자
Stimulus	무슨 일	주문 API 호출
Artifact	대상	Order Service
Environment	조건	피크 시간, 정상 모드
Response	기대 동작	요청 처리 완료
Response measure	측정	p99 500ms 이하, error rate 0.1% 미만

평가에서는 우선순위 높은 속성부터 시나리오 세트를 고정한다.

단계	질문
시나리오	누가 무엇을 어떤 조건에서 기대하는가
구조 매핑	C4 어느 Container·경로가 관여하는가
민감점	어느 설정·의존이 measure를 좌우하는가
리스크	미달 시 비즈니스 손실·복구 비용
액션	ADR·백로그·실험

• Payment PG 동기 호출 — 앞서 Container 경로가 이 시나리오 민감점이 될 수 있음
• 시나리오 없으면 "느리다"만 반복

4. 평가 시나리오·결과 예제

쇼핑 플랫폼 분기 평가 입력·발견 예시.

{
  "evaluationId": "shop-platform-2026-q3",
  "architectureView": "C4 Container v3",
  "priorityAttributes": ["performance", "availability", "modifiability"],
  "scenarios": [
    {
      "id": "perf-order-peak",
      "source": "10k concurrent customers",
      "stimulus": "POST /orders during flash sale",
      "artifact": "Order API",
      "environment": "peak traffic, dependent services healthy",
      "response": "orders accepted without client timeout",
      "measure": "p99 latency <= 500ms, error rate < 0.1%"
    },
    {
      "id": "avail-payment-db-fail",
      "source": "operations on-call",
      "stimulus": "Payment DB primary instance unavailable",
      "artifact": "Payment API",
      "environment": "production, normal checkout load",
      "response": "checkout continues via failover or graceful degradation",
      "measure": "monthly availability >= 99.95%, MTTR <= 15m"
    },
    {
      "id": "mod-split-inventory",
      "source": "inventory squad",
      "stimulus": "add reservation rule without redeploying Order API",
      "artifact": "Order API, Inventory API boundary",
      "environment": "steady-state development",
      "response": "change isolated to Inventory service and contract tests pass",
      "measure": "lead time for inventory change < 2 days, zero Order API deploy"
    }
  ],
  "findings": [
    {
      "scenarioId": "perf-order-peak",
      "risk": "synchronous Payment PG call extends Order API latency tail",
      "sensitivityPoint": "Payment API timeout and thread pool size",
      "tradeoff": "sync PG vs async payment intent event",
      "action": "ADR-0004 evaluate async payment handoff"
    },
    {
      "scenarioId": "avail-payment-db-fail",
      "risk": "single-region DB without rehearsed failover",
      "sensitivityPoint": "RDS failover DNS TTL and connection pool recycle",
      "tradeoff": "active-passive cost vs multi-AZ always-on",
      "action": "quarterly failover drill + runbook"
    }
  ]
}

필드	용도
priorityAttributes	평가 초점 — 전부 동시 X
findings	ATAM 3단계 산출 — 액션까지
action	ADR·티켓 링크

• 부하 테스트·게임데이 결과를 findings에 추가
• 앞서 내고장성·캐시·outbox 전술이 시나리오 통과에 기여하는지 매핑

5. 가벼운 평가 vs 정식 ATAM

	Lightweight (2~4h)	Full ATAM (2~3d)
참석	핵심 아키텍트·리드	다수 이해관계자
시나리오	3~5 개	유틸리티 트리 전체
구조	C4 Container 1장	여러 뷰·배포
산출	리스크 top 5·ADR	공식 리포트·서명

실무 팁
분기마다 lightweight	drift 조기
전환 전만 full	비용 정당화
동일 시나리오 재사용	회귀 평가

6. 민감점·리스크·트레이드오프

용어	정의	예
Sensitivity point	속성에 영향 큰 설계 요소	Kafka linger.ms, PG timeout
Risk	시나리오 미달 가능성·영향	outbox relay lag → 재고 지연
Tradeoff	한 선택의 이득·손해	strong consistency vs availability
Non-risk	우려했으나 구조상 괜찮음	기록해 재논의 방지

시나리오: Payment DB failover
민감점: connection pool max, DNS TTL
리스크: pool 고갈로 cascade timeout
트레이드오프: multi-AZ 비용 vs MTTR
액션: pool recycle on health flip + drill

• 민감점은 부하 테스트·카오스로 수치 확인
• 앞서 circuit breaker·bulkhead가 리스크 완화 전술

7. 기술 부채 관리

기술 부채 — 단기 편의·미완 설계로 미래 변경 비용이 커진 상태.

분면	impact / cost	전략
Pay now	높음 / 낮음	즉시 상환 — 알림·계약 테스트
Plan	높음 / 높음	로드맵·ADR·단계 분해
Opportunistic	낮음 / 낮음	해당 영역 수정 시 함께
Accept	낮음 / 높음	명시적 수용·모니터

부채 유형	예
의도적	MVP 일정 — ADR에 상환 계획
비의도적	문서 없는 경계 침범
환경	구 런타임·EOL 라이브러리

debt register (예)
- shared order DB read by analytics  | impact high | cost high | plan: CDC ADR-0002
- missing outbox dashboard           | impact high | cost low  | pay now sprint 12
- legacy admin JSP                   | impact low  | cost high | accept until rewrite

• 부채 등록 — 평가·회고마다 갱신
• 상환 없이 추가 기능만 — 이자 가속

8. 평가와 문서·ADR 연동

docs/
  c4/02-containers.md
  evaluation/
    2026-q3-scenarios.json
    2026-q3-findings.md
  adr/
    0004-async-payment-handoff.md

연결
평가 → ADR	트레이드오프 결정 기록
평가 → C4	구조 변경 반영
평가 → 백로그	민감점 튜닝·드릴
ADR Supersede	평가로 가정 깨짐 시

• Part 6 마무리 — 문서(C4)·결정(ADR)·검증(평가) 삼각형
• Living — 분기 평가 후 시나리오·findings 커밋

9. 실무 체크리스트

질문	좋은 답
누가 주도?	아키텍트 + 품질 속성 오너
입력?	우선순위 속성 + 3~7 시나리오
출력?	민감점·리스크·액션 top N
주기?	분기 light + 전환 전 full
부채?	register + quadrant 분류
회귀?	동일 measure로 재평가

안티패턴	대안
체크리스트만 틱	시나리오 기반
한 번 평가 끝	분기 회귀
리스크 구두만	findings JSON·md
부채 숨김	register 공개
정답 찾기	트레이드오프 문서화

10. 정리

• 아키텍처 평가 — 품질 시나리오로 구조 검증
• ATAM — 민감점·리스크·트레이드오프 체계 도출
• 가벼운 워크숍도 시나리오·C4만으로 실용
• 기술 부채 — 영향·비용으로 상환 우선순위
• C4·ADR·평가 연동 — Part 6 완료, Part 7 운영으로

다음에 다룰 것

• ADR 실전
• 라이프사이클·팀 합의·저장소 운영

---

해당 내용은 Software Architecture in Practice, 4/E (Bass, Clements, Kazman) 및 Fundamentals of Software Architecture (Mark Richards, Neal Ford) 의 내용을 기반으로 합니다.