SLA·SLO·SLI를 숫자로 읽는 법: 에러 버짓으로 ‘개발 속도 vs 안정성’ 균형 잡기

현장에서는 "약속"과 "측정"이 섞여서 사고가 난다

서비스가 느려지거나 장애가 나면 가장 먼저 나오는 질문은 "지금 정상인가"와 "언제까지 복구할 수 있나"다.

이때 SLA·SLO·SLI를 말로만 알고 있으면, 팀마다 기준이 달라 같은 상황을 다르게 해석하게 된다.

숫자로 합의되지 않은 상태에서는 기능 개발은 과속하고, 안정화는 과잉 방어로 흐르기 쉽다.

실무에서 자주 보이는 문제 장면은 다음과 같다.

• 고객사에는 "가용성 99.9%"라고 말했지만, 내부 목표와 측정 방식이 서로 다르다.
• "응답이 느리다"라는 이슈에 대해 지연시간 기준(p95/p99) 없이 평균만 보고 결론을 내린다.
• 장애가 잦아지자 배포를 멈췄지만, 언제 다시 속도를 올릴지 판단 기준이 없다.

흔한 오해는 "SLA가 곧 내부 운영 목표"라는 생각이다.

SLA는 대외 약속의 성격이 강하고, 내부 의사결정은 SLO와 에러 버짓으로 굴리는 편이 충돌이 적다.

SLA·SLO·SLI 관계도(약속·목표·측정의 연결)

용어 3개를 한 장으로 정리하면 숫자가 읽히기 시작한다

SLA·SLO·SLI는 서로 다른 역할을 가진다.

이 셋이 분리되지 않으면, "측정은 했는데 의사결정이 안 되는 상태"가 반복된다.

구분	의미	누가 주로 쓰나	예시(가용성 기준)
SLI	서비스 상태를 측정하는 지표다.	개발/운영/관측 도구	성공 요청 비율(2xx/3xx), 에러율(5xx)
SLO	SLI에 대해 달성하고 싶은 내부 목표치다.	팀 내부 합의	"월 가용성 99.9% 유지"
SLA	대외적으로 보상/계약이 걸린 약속이다.	고객/비즈니스/계약	"월 가용성 99.5% 미만 시 크레딧 제공"

SLO

정의: 서비스가 "어느 정도까지는 흔들려도 된다"를 숫자로 고정한 내부 목표다.

핵심 특징: 측정 가능한 SLI를 전제로 하고, 일정 기간(예: 28일, 30일) 창에서 평가한다.

주의점: 목표를 너무 타이트하게 잡으면 배포가 멈추고, 너무 느슨하면 고객 체감이 나빠진다.

SLO는 "지표를 보는 방식"도 함께 정해야 한다.

예를 들어 지연시간을 평균으로 볼지, p95/p99로 볼지에 따라 같은 그래프에서도 결론이 달라진다.

에러 버짓은 ‘남은 실패 허용치’를 돈처럼 쓰게 만든다

에러 버짓(error budget)

정의: SLO를 기준으로 허용되는 실패량을 수치로 환산한 잔액이다.

핵심 특징: 잔액이 남아 있으면 기능 개발과 실험을 진행할 여지가 생기고, 잔액이 바닥나면 안정화가 우선이 된다.

주의점: 계산식은 단순해도, "무엇을 실패로 볼지" 정의가 흐리면 버짓이 의미를 잃는다.

가장 흔한 형태의 계산은 가용성 SLO에서 출발한다.

예를 들어 월 SLO가 99.9%라면 허용 실패율은 0.1%다.

월 허용 실패 시간(분) = 월 전체 시간(분) × (1 - SLO)

예: 30일 기준
월 전체 시간 = 30 × 24 × 60 = 43,200분
SLO 99.9% → 허용 실패율 0.1% → 43,200 × 0.001 = 43.2분

지연시간 SLO에서도 같은 사고방식이 적용된다.

예를 들어 "요청의 99%는 300ms 이내" 같은 목표라면, 초과한 요청이 버짓을 깎는 방식으로 본다.

에러 버짓 기반 의사결정 흐름(잔액→배포 속도 조절)

숫자를 운영에 붙이는 절차: 대시보드에서 ‘판단’까지 연결한다

SLA·SLO·SLI는 문서로 끝내면 효과가 약하다.

관측 화면과 배포 의사결정에 연결될 때부터 팀의 행동이 바뀐다.

아래 절차는 특정 툴에 종속되지 않게 "경로/체크 포인트" 형태로 정리한 것이다.

1. 경로: 모니터링 대시보드 → 서비스 선택 → "가용성/에러율/지연시간" 패널 확인
2. 체크 포인트: SLI 후보를 1~2개로 좁힌다(예: 5xx 비율, p95 지연시간).
3. 경로: SLI 정의 문서(위키/런북) → "성공/실패" 조건 명시
4. 체크 포인트: 무엇을 실패로 볼지 고정한다(예: 5xx만 실패로 볼지, 타임아웃도 포함할지).
5. 경로: SLO 설정 페이지 또는 운영 문서 → 기간 창 선택(예: 28일/30일)
6. 체크 포인트: 목표치를 정한다(예: 가용성 99.9%, 지연시간 p95 300ms).
7. 경로: 에러 버짓 계산표 → "허용 실패 시간/허용 실패 요청 수" 산출
8. 체크 포인트: 월 단위 잔액을 숫자로 공개한다(예: 이번 달 허용 실패 43.2분).
9. 경로: 배포 정책(릴리즈 체크리스트) → 버짓 잔액에 따른 규칙 작성
10. 체크 포인트: 잔액이 특정 구간 이하로 내려가면 배포 속도를 낮추는 조건을 적는다.

이 과정에서 자주 생기는 착각은 "SLO를 높이면 품질이 자동으로 올라간다"는 생각이다.

목표를 올리기 전에, 실패 정의와 관측 누락(로그/메트릭 공백)이 먼저 정리되어야 숫자가 안정적으로 나온다.

빠른 YES/NO 판단 체크리스트는 다음과 같다.

• YES: SLI가 한 문장으로 정의되어 있고, 성공/실패가 계산 가능하다.
• YES: SLO의 기간 창이 고정되어 있고, 대시보드에서 같은 창으로 볼 수 있다.
• YES: 에러 버짓이 "몇 분/몇 건"처럼 잔액으로 표시된다.
• NO: SLA 수치만 있고 내부 목표(SLO)가 없다.
• NO: 평균 지연시간만 보고 목표를 정한다.
• NO: 버짓이 0이어도 배포 정책이 변하지 않는다.

실전 예시 1개: 버짓 잔액으로 배포를 늦추는 순간

문제: 월 초부터 간헐적 타임아웃이 누적되어 가용성 SLO 99.9%의 에러 버짓이 빠르게 줄어든다.

왜 발생: 외부 API 지연이 증가했고, 재시도 로직이 중복 요청을 만들면서 내부 큐 적체가 심해졌다.

어떤 선택이 적합: 잔액이 특정 임계치 이하로 내려가면 기능 배포를 줄이고, 완화/복구 작업(타임아웃 조정, 재시도 제한, 큐 처리량 개선)을 우선한다.

잘못 쓰면 어떤 문제: 잔액이 마이너스로 가는 동안에도 배포를 지속하면, 작은 변경이 큰 장애로 이어질 확률이 올라간다.

확인/해결: 대시보드에서 에러율과 지연시간을 함께 보고, 배포 기록과 겹치는지 확인한 뒤, 에러 버짓 규칙에 따라 배포를 제한하고 안정화 작업을 진행한다.

관측 문구 예:
- 5xx 비율: 0.18% (목표 0.10% 초과)
- 에러 버짓 잔액: 43.2분 중 31.0분 소진
- 결론: 잔액 30% 이하 진입 → 기능 배포 주기 축소, 안정화 우선

결론

SLA는 외부 약속, SLO는 내부 목표, SLI는 측정 지표로 역할이 갈린다.

에러 버짓은 목표를 "잔액"으로 바꿔 배포 속도와 안정성의 균형을 판단 가능하게 만든다.

대시보드의 관측과 배포 규칙이 연결되면 숫자가 문서가 아니라 행동이 된다.

연계 주제 제안: 지연시간 SLO를 p95/p99로 설계하는 방법, 알림 임계값을 오탐/미탐 관점에서 조정하는 방법이 다음 단계로 이어지기 좋다.

FAQ

SLA가 있는데 SLO를 또 정해야 하나?

SLA는 대외 약속이라 내부 운영의 세밀한 판단 기준으로 쓰기에는 무겁거나 느슨한 경우가 있다.

SLO는 팀이 스스로 조정할 수 있는 목표이므로, 에러 버짓과 함께 쓰면 운영 의사결정이 빨라진다.

SLI는 몇 개가 적당한가?

처음에는 1~2개가 적당하다(예: 가용성, 지연시간).

너무 많으면 목표가 분산되고, 실패 정의가 흔들려 버짓이 의미를 잃기 쉽다.

에러 버짓이 0이면 무조건 배포를 멈춰야 하나?

무조건 정지보다는 "배포 종류"를 나누는 방식이 현실적이다.

잔액이 없을 때는 기능 배포를 줄이고, 리스크가 낮은 수정(모니터링 보강, 롤백 준비, 성능 개선)을 우선하는 규칙이 잘 맞는다.