품질 속성은 숫자다
성능·확장성·가용성을 SLI/SLO/SLA로 수치화해 설계를 강제하는 품질 속성 프레임
이 글의 결론
대규모 시스템에서 품질 속성은 “잘 동작한다”는 인상이 아니라, 설계를 강제하는 측정 지표로만 의미가 있다.
왜 품질 속성이 설계의 중심인가
기능이 ‘무엇을 만드는가’라면, 품질 속성은 ‘어떻게 망가질 수 있는가’를 규정한다.
왜
대규모 시스템은 기능이 아니라 품질 속성의 한계에서 실패한다. 성능 병목, 확장 실패, 가용성 저하 중 하나라도 수치로 고정되지 않으면, 설계는 낙관에 의존하게 된다.
무엇
- 성능(Performance): 요청 하나가 얼마나 빨리 처리되는가
- 확장성(Scalability): 부하 증가 시 성능 저하 없이 처리량을 늘릴 수 있는가
- 가용성(Availability): 시스템이 사용 가능한 상태로 존재하는 비율
- 내결함성(Fault Tolerance): 장애가 발생해도 기능을 유지하는 능력
- 고가용성(High Availability): 장애를 사용자가 거의 인지하지 못하도록 설계하는 전략
어떻게
품질 속성을 모두 SLI(측정) → SLO(목표) → SLA(계약) 구조로 번역한다.
기준 사례: 포럼 서비스
이 글 전체는 ‘포럼 서비스(게시글/댓글/조회)’ 하나의 사례를 재사용한다.
- 일일 활성 사용자: 50만
- 트래픽 피크: 평시 대비 5배
- 읽기:쓰기 = 20:1
성능·확장성·가용성 비교 표
이 셋을 섞어 말하는 순간, 설계 논의는 붕괴된다.
| 구분 | 정의 | 대표 지표 | 설계 영향 | 흔한 오해 |
|---|---|---|---|---|
| 성능 | 단일 요청 처리 특성 | p95 latency, TPS | 캐시, 쿼리 최적화 | “확장하면 해결” |
| 확장성 | 부하 증가 대응 능력 | throughput 증가 곡선 | 무상태화, 샤딩 | “서버 늘리면 됨” |
| 가용성 | 사용 가능 비율 | uptime %, error rate | 이중화, failover | “장애 없게 만들자” |
성능 (Performance)
성능은 ‘빠르다’가 아니라 ‘p95 200ms 이하’ 같은 문장이다.
정의
단일 요청이 완료되기까지 걸리는 시간과 처리량 특성.
직관
평균(latency avg)은 의미 없다. 느린 5%가 사용자 경험을 결정한다.
측정/지표
- p50 / p95 / p99 latency
- 요청당 CPU time
- DB query latency
설계 영향
- 포럼 조회 API의 p95가 300ms 초과 → 캐시 도입
- 비동기 처리로 write latency 격리
흔한 함정
- 평균 응답 시간만 보고 “충분히 빠르다” 판단
확장성 (Scalability)
확장성은 서버 개수가 아니라, 증가 곡선의 형태다.
정의
부하 증가 시 성능 저하 없이 처리량을 늘릴 수 있는 능력.
직관
2배 서버 → 2배 처리량이 나오지 않으면 확장성 문제다.
측정/지표
- QPS 증가 대비 latency 변화
- scale-out 시 선형성
설계 영향
- 포럼 읽기 트래픽 급증 → stateless API
- DB 샤딩 키를 게시글 ID로 고정
흔한 함정
- 오토스케일링 = 확장성이라고 착각
가용성·내결함성·고가용성
가용성은 결과, 내결함성은 수단, 고가용성은 전략이다.
가용성 정의
일정 기간 동안 시스템이 정상 사용 가능한 비율.
측정/지표
- 성공 요청 비율
- error rate
- uptime %
‘nines’ 직관과 다운타임
과장은 금물이다. 0.1%는 생각보다 크다.
| 가용성 | 월 다운타임 | 연 다운타임 |
|---|---|---|
| 99% | ~7.2시간 | ~3.65일 |
| 99.9% | ~43분 | ~8.7시간 |
| 99.99% | ~4.3분 | ~52분 |
설계 영향
- 포럼 글쓰기: 99.9%
- 조회 API: 99.99% (읽기 우선)
흔한 함정
- 모든 기능에 동일한 가용성 목표 설정
SLA / SLO / SLI
이 셋은 문서가 아니라 ‘의사결정 언어’다.
관계
- SLI: 실제 측정 지표
- SLO: 내부 목표
- SLA: 외부 계약
예시 1 (포럼 조회)
- SLI: p95 latency
- SLO: p95 < 200ms, 월 99.99%
- SLA: 월 99.9% 미만 시 크레딧 제공
예시 2 (글쓰기)
- SLI: 성공 요청 비율
- SLO: 99.9%
- SLA: 없음 (내부 기능)
트레이드오프 사례 4개
품질 속성은 항상 서로를 깎는다.
- 성능 vs 비용
- 캐시 히트율 ↑ → 메모리 비용 ↑
- 가용성 vs 일관성
- 장애 시 읽기 허용 → stale data 허용
- 확장성 vs 복잡도
- 샤딩 도입 → 운영 난이도 급증
- 내결함성 vs 운영 난이도
- 재시도·서킷브레이커 → 디버깅 난이도 ↑
면접 답변 템플릿
숫자 없는 답변은 즉시 탈락 신호다.
- “우리 시스템의 핵심 SLI는 p95 latency이고 SLO는 200ms / 99.99%이다. 이유는 읽기 중심 포럼이기 때문이다.”
- “이 요구사항 때문에 consistency를 eventual로 두고 availability를 높게 둔다.”
재학습 체크리스트 (12)
- 모든 품질 속성에 수치가 있는가
- 평균이 아닌 percentile을 쓰는가
- 기능별로 SLO를 분리했는가
- SLA와 SLO를 구분했는가
- 비용 증가를 명시했는가
- 트레이드오프를 말할 수 있는가
- 읽기/쓰기 목표를 분리했는가
- 장애 시 허용 범위를 정했는가
- 확장 곡선을 확인했는가
- 운영 복잡도를 인지했는가
- “빠르다”라는 말을 제거했는가
- 설계 선택을 숫자로 방어할 수 있는가
면접 3분 구술 스크립트
“이 시스템은 읽기 중심 포럼입니다.
핵심 품질 속성은 성능과 가용성입니다.
SLI는 p95 latency와 성공 요청 비율이며,
SLO는 조회 p95 200ms, 99.99%입니다.
이를 위해 캐시와 stateless API를 선택했고,
장애 시 consistency를 완화하는 대신 availability를 유지했습니다.”
한 줄 요약
품질 속성은 추상 개념이 아니라, 설계를 강제하는 숫자다.