아키텍처 품질 속성

학습 목표

주요 아키텍처 품질 속성(quality attribute) 을 정의하고 구분할 수 있다.

이해관계자 concern을 품질 속성·측정 지표로 번역할 수 있다.

품질 시나리오(quality scenario) 로 요구를 구체화할 수 있다.

품질 속성 간 트레이드오프가 구조 선택을 좌우함을 설명할 수 있다.

문제 상황

• "성능 좋게", "안정적으로", "나중에 바꾸기 쉽게"
  • 요구는 많은데 무엇을 얼마나 만족할지 숫자가 없다
• p99 200ms인지 2s인지에 따라 캐시·DB 샤딩·동기 호출 설계가 전혀 달라진다
  • 같은 "빠르게"인데 아키텍처 결정이 갈린다
• 가용성 99.9%와 99.99%는 장애 허용 시간이 10배 차이
  • 멀티 AZ, health check, circuit breaker 여부가 갈린다
• 테스트하기 어려운 구조는 리팩터링도 느려진다
  • 품질 속성을 나중에 끼워 넣기 어렵다

이해관계자 concern을 봤다. 이번 편은 concern을 설계·평가 가능한 품질 속성으로 내리고, 시나리오로 고정한다.

1. 품질 속성이란

품질 속성 — 시스템이 기능 외에 얼마나 잘 동작하는지를 나타내는 비기능 요구의 설계 관점.

• 기능: "주문을 생성한다"
• 품질: "주문 API p99 latency 300ms 이하", "월 가용성 99.95%"

아키텍처 스타일·컴포넌트·커넥터 선택은 대부분 품질 속성을 만족하기 위한 수단이다.

범주	대표 속성	한 줄 정의
운영(Operational)	성능, 가용성, 확장성	런타임에 사용자·운영이 체감하는 특성
개발(Development)	유지보수성, 테스트 용이성	변경·검증 비용
보안(Security)	기밀성, 무결성, 인증	데이터·접근 보호
조직·배포	배포 용이성, 관측성	릴리스·장애 대응 (운영 concern과 겹침)

• Richards/Ford는 구조에 영향을 주는 속성에 집중한다
  • UI 색상 같은 건 아키텍처 범위 밖

2. 핵심 품질 속성

성능 (Performance)

• 처리량(throughput), 지연(latency), 자원 사용률
• 측정: RPS, p50/p95/p99, CPU·메모리
• 전술 예: 캐시, 비동기, 읽기 복제, CDN, connection pool

가용성 (Availability)

• 요청이 실패하지 않고 처리될 확률·시간 비율
• 측정: uptime %, MTBF, MTTR, error rate
• 전술 예: redundancy, health check, graceful degradation, 다중 AZ

확장성 (Scalability)

• 부하 증가에 선형에 가깝게 용량을 늘릴 수 있는가
• Scale up(큰 머신) vs Scale out(인스턴스 추가)
• 전술 예: stateless 서비스, 샤딩, 파티셔닝, 메시지 큐로 부하 분산

보안 (Security)

• 기밀성, 무결성, 인증·인가, 감사
• 아키텍처: zero trust, 네트워크 분리, 암호화 전송·저장, 최소 권한
• Network 시리즈의 TLS·애플리케이션 계층과 연결

유지보수성 (Modifiability / Maintainability)

• 기능·요구 변경을 얼마나 싸고 안전하게 반영하는가
• 측정: 변경 범위(모듈 수), 배포 빈도, 결함 유입률
• 전술 예: 경계 분리, 의존성 역전, 플러그인 구조

테스트 용이성 (Testability)

• 결함을 얼마나 빨리·자동으로 찾을 수 있는가
• mock·stub 가능한 경계, 결정론적 동작, 작은 배포 단위
• 테스트 어려운 구조는 가용성·유지보수성도 함께 악화된다

3. 품질 시나리오

모호한 요구를 검증 가능한 문장으로 바꾼다. Software Architecture in Practice 의 6요소 형식이 널리 쓰인다.

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

예시 (가용성)

운영팀이(Stimulus source) 프로덕션에서(environment) 결제 DB 인스턴스 1대가 다운되면(stimulus), Payment Service는(artifact) 결제 요청을 계속 처리한다(response). 월 가용성 99.95% 이상, MTTR 15분 이하(response measure).

• 시나리오가 없으면 "고가용성"은 누구나 다른 그림을 그린다
• ADR·아키텍처 평가(이후 편)의 입력이 된다

4. Concern에서 품질 속성으로

앞 편 concern을 이번 편 언어로 옮기면 논의가 짧아진다.

Concern	품질 속성	아키텍처 전술 예
"느리다"	성능	캐시, read replica, 비동기 이벤트
"배포할 때마다 장애"	가용성, 배포 용이성	blue-green, canary, feature flag
"트래픽 급증 대비"	확장성	HPA, stateless, queue
"규제·개인정보"	보안	암호화, 감사 로그, 네트워크 분리
"레거시 손대기 무서움"	유지보수성, 테스트 용이성	경계 분리, 계약 테스트

5. 트레이드오프

품질 속성은 동시에 극대화하기 어렵다. 구조는 우선순위를 반영한다.

긴장	한쪽	다른 쪽	흔한 선택
성능 vs 보안	암호화·검증 오버헤드	낮은 지연	TLS, HSM, 단계적 검증
일관성 vs 가용성	강한 트랜잭션	분산 가용	saga, eventual consistency
속도 vs 유지보수성	빠른 하드코딩	깨끗한 경계	MVP 후 strangler
테스트 vs 출시 속도	높은 커버리지	짧은 사이클	계약·스모크 우선

• 아키텍트는 "다 잘됨"이 아니라 순위와 측정을 문서화한다
• 품질 시나리오 + ADR이 그 기록이다

6. 정리

• 품질 속성은 기능과 별도로 구조를 결정하는 축이다
• 성능·가용성·확장성·보안·유지보수성·테스트 용이성이 일상적으로 다루는 핵심이다
• 품질 시나리오로 측정 가능하게 쓰면 이해관계자 concern과 연결된다
• 트레이드오프를 숨기지 않는 것이 아키텍처의 정직함이다

다음에 다룰 것

• 레이어드 아키텍처
• Presentation / Business / Persistence, 장단점

---

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