개념
배포 순간에 초록이었다는 것으로 충분한가
앞 레슨에서 관측성을 배웠다. 로그·메트릭·대시보드로 실패를 추적하는 법이다. 이번에는 그 지표들을 품질 목표로 승격시키는 이야기다.
문제 상황부터 보자.
릴리즈 회귀 테스트 통과율 98%, 품질 게이트 전부 초록. 배포했다. 그런데 그 주에 고객센터 문의가 늘었다. 확인해보니 결제 화면이 특정 시간대에 8초씩 걸리고 있었다. 테스트는 전부 통과했는데.
이건 테스트가 잘못된 게 아니다. 테스트가 답하는 질문과 사용자가 겪는 경험이 다른 질문 이기 때문이다.
| 답하는 질문 | 측정 시점 | |
|---|---|---|
| 테스트 통과율 | 이 기능이 명세대로 동작하는가 | 배포 전, 통제된 환경 |
| SLI/SLO | 사용자가 실제로 어떤 경험을 하고 있는가 | 배포 후, 실제 트래픽 |
모듈 6(레슨 5)에서 배운 품질 지표는 대부분 앞줄에 있다. 결함 밀도, 커버리지, 실패율. 전부 우리가 만든 것에 대한 지표 다. 뒷줄 — 사용자가 겪는 것에 대한 지표 — 를 다루는 것이 이 레슨이다.
SLI·SLO·SLA 세 단어 구분하기
용어부터 정리한다. 자주 섞여 쓰이지만 층이 다르다.
| 용어 | 정체 | 예 |
|---|---|---|
| SLI(Service Level Indicator) | 측정하는 값 | 결제 요청 중 3초 안에 성공한 비율 |
| SLO(Service Level Objective) | 그 값의 목표 | 30일 기준 99.5% 이상 |
| SLA(Service Level Agreement) | 고객과의 계약(위반 시 보상) | 99.0% 미만이면 요금 감면 |
관계는 단순하다 — SLI를 재고, SLO를 목표로 삼고, SLA는 그보다 느슨하게 잡는다. SLA를 SLO와 같게 두면 목표를 살짝 못 미치는 순간 계약 위반이 된다. 그래서 SLO를 SLA보다 빡빡하게 잡아 여유를 둔다.
대부분의 조직에서 QA가 실제로 다루는 것은 SLI와 SLO 다.
좋은 SLI를 고르는 법
여기가 이 레슨에서 가장 실무적인 부분이다. 나쁜 SLI를 고르면 숫자는 멀쩡한데 사용자는 불편한 상황이 계속 생긴다.
원칙 1 — 서버가 아니라 사용자 관점에서 고른다.
| 나쁜 SLI | 왜 나쁜가 | 더 나은 SLI |
|---|---|---|
| CPU 사용률 | 사용자는 CPU를 안 쓴다 | 요청 성공률 |
| 서버 가동률 | 서버는 살아 있는데 응답이 느릴 수 있다 | 3초 내 응답 비율 |
| 평균 응답시간 | 평균은 소수의 극단을 감춘다 | p95·p99 응답시간 |
| 전체 에러율 | 중요한 기능과 아닌 것이 섞인다 | 핵심 여정별 성공률 |
평균 대신 백분위(p95, p99)를 쓰는 이유 를 짚어두자. 평균 응답시간 200ms는 훌륭해 보이지만, 5%의 사용자가 8초를 기다리고 있어도 평균은 크게 흔들리지 않는다. 그리고 그 5%는 대개 데이터가 많은 헤비 유저 다.
원칙 2 — 핵심 사용자 여정(critical user journey) 단위로 잡는다.
전체 API 성공률 하나보다, 사용자가 실제로 하는 일 단위가 낫다.
서비스 전체 성공률 99.7% ← 괜찮아 보인다
│
├─ 로그인 99.9%
├─ 상품 검색 99.8%
├─ 장바구니 99.9%
└─ 결제 완료 97.2% ← 여기가 문제다전체 숫자에서는 결제의 문제가 다른 여정에 희석돼 보이지 않는다. 모듈 4에서 배운 리스크 기반 사고 를 지표에 적용하는 것이다 — 사업에 치명적인 여정부터 따로 잰다.
원칙 3 — 어디서 재는지 정한다.
같은 지표도 측정 위치에 따라 값이 다르다.
| 측정 위치 | 잡히는 것 | 안 잡히는 것 |
|---|---|---|
| 서버 로그 | 서버가 처리한 요청 | 서버에 도달 못 한 요청, 클라이언트 렌더링 |
| 로드밸런서 | 도달한 모든 요청 | 클라이언트 측 문제 |
| 클라이언트(RUM) | 사용자가 실제 겪은 것 | 앱을 켜지도 못한 경우 |
| 합성 모니터링 | 일정한 조건의 정기 점검 | 실사용자의 다양성 |
서버 로그만 보면 "서버까지 오지 못한 실패"가 통째로 안 보인다. 모듈 16(레슨 4)에서 배운 Core Web Vitals가 클라이언트 측 SLI의 대표적 예다. 이상적으로는 서버와 클라이언트 양쪽을 함께 본다.
에러 버짓 — SLO가 의사결정을 바꾸는 지점
SLO를 정하면 자동으로 따라오는 개념이 있다. 에러 버짓(error budget) 이다.
SLO 99.5% → 허용되는 실패 0.5% = 에러 버짓
30일 기준으로 환산하면
30일 × 24시간 × 60분 = 43,200분
43,200분 × 0.5% ≈ 216분 (약 3시간 36분)
→ 이번 달에 "3시간 36분어치" 실패가 허용된다이 개념이 강력한 이유는 품질 논쟁을 자원 배분 논쟁으로 바꾸기 때문이다.
| 에러 버짓 상태 | 조직의 행동 |
|---|---|
| 많이 남았다 | 새 기능을 더 과감하게 배포해도 된다 |
| 거의 다 썼다 | 배포 속도를 줄이고 안정화에 투입 |
| 초과했다 | 기능 개발을 멈추고 신뢰성 작업만 |
이게 왜 QA에게 중요한가? 지금까지 "더 테스트해야 합니다"와 "일정이 급합니다"는 끝나지 않는 논쟁 이었다. 근거가 양쪽 다 주관이기 때문이다. 에러 버짓은 그 논쟁에 공통의 숫자 를 준다.
"이번 달 에러 버짓의 78%를 이미 썼습니다. 이 기능을 지금 내보내면 남은 버짓으로는 2주를 못 버팁니다."
모듈 4(레슨 5)에서 배운 Go/No-Go 의사결정이 여기서 한 단계 정교해진다. 릴리즈 판단의 근거가 "테스트 결과"만이 아니라 "지금 운영 품질에 여유가 있는가" 로 확장되는 것이다.
SLO를 정하는 절차
숫자를 어디서 가져올 것인가. 모듈 25(레슨 3)에서 배운 '목표치의 출처' 문제가 여기서 반복된다. 실무적인 순서는 이렇다.
① 현재 값을 먼저 잰다 4주 이상, 실제 데이터로
↓
② 사용자가 체감하는 경계를 찾는다
"몇 초부터 이탈이 늘어나는가"
↓
③ 현재 값과 경계 사이에서 목표를 정한다
현재 99.2% → 목표 99.5% (달성 가능하되 노력이 필요한 수준)
↓
④ 한 분기 돌려보고 조정한다①을 건너뛰고 목표부터 정하는 것이 가장 흔한 실수다. 현재 99.2%인 서비스에 갑자기 99.99%를 목표로 걸면, 첫 달에 버짓을 다 쓰고 그 뒤로는 아무도 그 숫자를 보지 않는다. 지키지 못하는 목표는 없는 목표보다 나쁘다.
100%를 목표로 잡지 않는 것 도 중요하다. 100%는 달성 불가능하고, 시도하는 비용이 급격히 오르며, 무엇보다 에러 버짓이 0이 되어 아무것도 배포할 수 없게 된다. SLO의 목적은 완벽이 아니라 합의된 불완전함 이다.
QA는 SLO에서 무엇을 하는가
SLO는 흔히 SRE나 인프라 팀의 것으로 여겨진다. 그런데 QA가 기여할 자리가 분명히 있다.
1) 어떤 여정이 핵심인지 정하는 일. 제품 전체에서 무엇이 치명적인지 아는 사람은 대개 QA다. 모듈 4의 리스크 분석이 그대로 SLI 선정 근거가 된다.
2) SLI 정의의 애매함을 걷어내는 일. "결제 성공률"이라고만 하면 분모와 분자가 사람마다 다르다. 사용자가 취소한 것은? 카드사 한도 초과는? 요구사항을 검증 가능하게 만드는 훈련(모듈 2) 이 여기서 그대로 쓰인다.
3) 릴리즈 판단에 버짓을 끌어들이는 일. Go/No-Go 회의에서 테스트 결과와 함께 에러 버짓 잔량을 말하는 것.
4) SLO 위반을 결함처럼 다루는 일. SLO를 넘겼는데 아무 일도 일어나지 않으면 그 SLO는 장식이다. 위반 시 무엇을 하는지 — 티켓을 만드는지, 회고를 하는지 — 를 프로세스로 만드는 것은 QA가 잘하는 일이다.
안티패턴
1) 서버 지표만으로 SLO를 만든다. 사용자는 CPU를 안 쓴다.
2) SLI가 너무 많다. 지표 30개짜리 SLO는 아무도 못 본다. 핵심 여정 3~5개 로 시작한다.
3) 위반해도 아무 일이 없다. 버짓을 다 써도 배포 속도가 그대로면 에러 버짓은 숫자놀이가 된다.
4) 목표를 근거 없이 정한다. "99.9%가 멋있어서" 정한 목표는 첫 달에 무너진다. 현재 값 측정이 먼저다.
5) 평균만 본다. p95·p99를 함께 보지 않으면 소수의 심각한 경험이 통째로 감춰진다.
6) 테스트 지표를 SLI로 쓴다. 커버리지나 통과율은 SLI가 아니다. 사용자가 겪는 것이 아니기 때문이다. 둘은 서로를 대체하지 않고 보완 한다.
실무에서 왜 필요한가
QA의 시야가 릴리즈 순간에 멈춰 있으면, 배포 후에 벌어지는 일에 대해 할 말이 없어진다. 그런데 사용자가 겪는 품질의 대부분은 배포 후에 발생한다. SLI·SLO를 아는 QA는 품질에 대한 발언권이 릴리즈 이후로 확장된다.
실무적으로 가장 큰 이득은 논쟁의 성격이 바뀌는 것 이다. "품질이 중요하다"와 "일정이 급하다"의 감정적 대립이, 에러 버짓이라는 공통 숫자 위에서 "지금 여유가 얼마나 있는가"라는 계산 문제로 바뀐다. 그 계산은 양쪽 다 반박하기 어렵다.
그리고 이 개념은 채용에서도 신호가 된다. SRE 문화를 도입한 조직에서 QA를 뽑을 때, 테스트 결과와 운영 지표를 함께 말할 수 있는 사람 은 드물다. "회귀 통과율 98%였고, 배포 후 결제 여정 SLI가 99.1%에서 98.7%로 떨어져 원인을 추적했습니다"라고 말할 수 있으면 층이 다르다.