SLO, SLI & Error Budget Physics

1. Overview

SLO와 에러 버젯의 물리학(SLO, SLI & Error Budget Physics)은 "우리 서버는 1년 365일 단 1초도 죽으면 안 돼!"라는 비즈니스 부서의 비현실적인 망상을 부수고, 완벽함(100%)을 포기함으로써 역설적으로 배포의 속도와 시스템의 안정성을 쟁취하는 SRE(Site Reliability Engineering)의 수학적 타협술을 해부합니다.

학습자는 막연하게 "서버가 빠르면 좋겠다"는 소망을, 분모(전체 요청)와 분자(성공 요청)로 나눌 수 있는 **SLI(서비스 수준 지표)**라는 냉혹한 측정기로 뜯어봅니다. 나아가 "우리는 99.9%의 성공률만 약속한다"고 선을 긋는 **SLO(서비스 수준 목표)**와, 이를 어겼을 때 고객에게 돈(위약금)을 물어주는 **SLA(서비스 수준 계약)**의 법적 경계를 장악합니다. 마지막으로, 100%에서 99.9%를 뺀 나머지 '0.1%의 여유 공간'을 **에러 버젯(Error Budget)**으로 환산하여, 이 예산이 남아있으면 미친 듯이 신기능을 배포하고 예산이 바닥나면 배포를 올스톱하는 데이터 주도 거버넌스 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• SRE Core Metrics: SLI (무엇을 측정할 것인가?), SLO (우리의 목표는 몇 % 인가?), SLA (어기면 얼마를 배상할 것인가?).
• The Physics of 9s: 99% (Two 9s, 연간 3일 다운타임) vs 99.999% (Five 9s, 연간 5분 다운타임)의 기하급수적 비용 차이.
• Error Budget (에러 버젯): 100% - SLO. 합법적으로 서버를 고장 낼 수 있는 허용치이자 신기능 배포의 속도 제한기.
• MTTR vs MTBF: 장애가 나는 간격(MTBF)을 늘리려는 헛된 노력보다, 장애 복구 시간(MTTR)을 1초로 줄이는 안티 프래질(Anti-fragile) 전략.

Out-of-Scope

• 프로메테우스(Prometheus) 쿼리 작성법: rate(http_requests_total[5m]) 같은 구체적 PromQL 문법 → 09-06-01 Observability 또는 도구 매뉴얼로 위임.
• 인프라 이중화(HA) 구축: 99.99%를 달성하기 위해 Active-Standby DB를 어떻게 구성할 것인가 → 07-02-02 High Availability & Load Balancing 영역으로 분리.

Boundaries

• 100% vs 99.9%: 100%의 안정성을 추구하면? 아무것도 배포하지 않고 서버를 얼려두면(Freeze) 됩니다. 하지만 회사는 망합니다(혁신 부재). 구글(Google) SRE의 대원칙은 "100%는 잘못된 목표(The Wrong Objective)"라는 것입니다. 99.9%와 100% 사이의 유저 체감 차이는 없지만, 100%를 달성하기 위한 인프라 비용은 1,000배가 듭니다. SLO는 '얼마나 안정적일 것인가'를 정하는 게 아니라, '얼마나 혁신(배포)할 것인가'의 브레이크 페달을 세팅하는 **경제학적 타협(Economic Trade-off)**의 경계선임을 명확히 긋습니다.

3. Counterexample

• 100%의 망상과 배포 전쟁: 기획팀이 "우리 앱은 단 1번의 결제 실패도 용납할 수 없다(100% 타겟)"고 선언했습니다. 에러 버젯(허용치)이 0입니다. 개발팀은 신기능 배포를 할 때마다 결제가 터질까 두려워, 결재 라인을 5단계로 늘리고 배포를 한 달에 1번으로 줄였습니다. 결과적으로 에러는 안 났지만, 경쟁사가 하루에 10번씩 신기능을 배포하며 치고 나가는 동안 앱은 시장에서 도태되었습니다. 완벽함(100%)을 추구하다 굶어 죽는 전형적인 비즈니스 붕괴입니다.
• 측정 불가능한 약속 (SLI 부재): 영업팀이 B2B 고객과 "우리는 빠른 응답 속도를 보장합니다"라는 SLA(계약)를 맺었습니다. 고객이 "서버가 너무 느리다, 위약금을 내놔라"고 항의합니다. 개발팀이 "어제 응답 속도 1초였는데요?"라고 반박하자, 고객은 "체감상 5초였다"라고 우깁니다. 무엇이 '빠른' 것인지(예: 99번째 백분위수 응답 시간이 200ms 이하)를 수학적 분모/분자(SLI)로 합의해 놓지 않아 벌어지는 법적/감정적 진흙탕 싸움입니다.

4. Prerequisites

• 관측 가능성 (Basic): 텔레메트리 데이터를 수집할 수 있는 아키텍처. (09-06-01 Observability)
• CI/CD 파이프라인 (Basic): 언제든 빠르게 롤백할 수 있는 인프라. (09-05-01-04 GitOps)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 측량할 수 없다면 통제할 수 없다 (The Anatomy of SLI)

• Why to Learn: "우리 서버 오늘 쾌적하네요"라는 엔지니어의 감(Feeling)을 죽여버리고, 누구나 멱등하게 판별할 수 있는 차가운 수학적 분수식(Fraction)을 설계하기 위함입니다.
• What to Learn:
  • Concepts: SLI (Service Level Indicator), Good Events, Valid Total Events, Latency SLI, Availability SLI, Percentile (P99, P95).
  • Skills: "응답 속도가 빠르다"는 요구사항을 → (200ms 이내에 HTTP 200 OK로 응답한 요청 수) / (유저가 보낸 전체 유효 요청 수) * 100 이라는 분모/분자 공식으로 번역하기.
• How to Learn:
  • 1단계: 추상의 배제: 기획자가 "서버가 안 끊겼으면 좋겠어요"라고 합니다. SLI는 이 말을 거부합니다. "Load Balancer에 들어온 Ping 요청 중 HTTP 200이 반환된 비율을 말하는 겁니까?"
  • 2단계: 분모와 분자: 모든 SLI는 좋은 이벤트(Good) / 유효한 전체 이벤트(Total)의 형태를 가집니다. 디도스(DDoS) 공격을 받아 HTTP 403으로 막아낸 요청은 '유효한 전체 이벤트' 분모에서 빼야 합니다. 안 그러면 에러율이 치솟아 억울해집니다.
  • 3단계: 백분위수(Percentile): 평균(Average)의 함정을 조심해야 합니다. 99명의 유저가 0.1초 만에 응답을 받았는데, 1명의 VIP 유저가 10초를 기다렸습니다. 평균은 0.2초로 매우 쾌적해 보입니다. 이를 막기 위해 "P99(하위 99% 유저)의 응답 속도가 200ms 이내일 것"처럼 통계적 아웃라이어를 방어하는 치밀한 척도 설계를 뜯어봅니다.
• Implement: 모호한 요구사항 → SLI 수학적 번역 모사. 요구사항: "결제 시스템이 안정적이어야 함." 잘못된 SLI: "서버 CPU가 80%를 넘지 않음" (유저는 CPU 따위에 관심 없음). 정확한 SLI: (200ms 이내에 승인/거절 응답을 완료한 결제 트랜잭션 수) / (클라이언트가 시도한 전체 결제 트랜잭션 수). 측정의 초점을 '서버 인프라'에서 '유저의 체감 가치'로 이동시키는 렌더링.

Recommended

Core Topic 02: 목표와 계약의 갭, SLO vs SLA (Internal vs Legal)

• Why to Learn: 개발팀의 목표치(SLO)를 그대로 영업팀의 계약서(SLA)에 갖다 썼다가, 0.01%의 사소한 서버 지연에도 고객에게 수천만 원의 위약금을 토해내는 파산을 막기 위함입니다.
• What to Learn:
  • Concepts: SLO (Service Level Objective), SLA (Service Level Agreement), Buffer (버퍼/여유 공간), Breach (위반), Penalties (위약금).
  • Skills: "우리의 진짜 목표(SLO)는 99.9% 달성이지만, 대외적으로 고객과 계약(SLA)할 때는 99.0%만 보장한다고 뻥을 쳐서(버퍼 확보)" 위약금 리스크를 완전히 박살 내기.
• How to Learn:
  • 1단계: SLO (내부의 약속): "우리는 SLI 99.9%를 달성할 거야!" 개발팀이 내부적으로 세운 가장 빡센 타겟입니다. 어기면? 기분은 나쁘지만 감옥에 가거나 돈을 뺏기진 않습니다.
  • 2단계: SLA (외부의 법적 계약): "우리 서비스가 99.0% 밑으로 떨어지면 이용료를 전액 환불해 주겠다." 이건 영업팀이 고객과 맺는 돈이 걸린 계약서입니다.
  • 3단계: 버퍼(Buffer)의 미학: SLO와 SLA는 절대 같으면 안 됩니다. SLA(99.0%) < SLO(99.9%)여야 합니다. 이 사이의 0.9% 갭이 회사의 목숨을 살리는 방어선입니다. 서버가 며칠 뻗어서 내부 목표(SLO)는 실패하더라도, 최후의 마지노선인 SLA 위약금만큼은 피할 수 있게 아키텍처와 비즈니스의 간극을 벌려놓는 지혜를 해부합니다.
• Implement: 장애 발생 시 위약금(Penalty) 계산 시뮬레이터. 설정: SLA=99.0%, SLO=99.9%. (월 총 시간 720시간). 장애 상황: 이번 달에 누적 3시간 동안 서버 접속 끊김. (가동률 99.58% 기록). 결과 평가:
  1. SLO (99.9%): 미달(Breach). 개발팀 반성문 작성 및 신기능 배포 동결.
  2. SLA (99.0%): 통과(Met). 위약금 0원, 고객 배상 의무 없음. 개발팀을 쪼는 동시에 회사의 현금 붕괴를 막아내는 이중 방어막 시각화.

Practical

Core Topic 03: 허용된 폭주의 권한, 에러 버젯 (Error Budget: The Pace Car)

• Why to Learn: "우리 배포해도 돼요?"를 팀장님 기분이나 QA팀의 꼰대력으로 결정하는 정치적 사투를 끝내고, 통장 잔고(데이터)를 까보고 배포를 승인/거부하는 냉혹한 통제 시스템을 구축하기 위함입니다.
• What to Learn:
  • Concepts: Error Budget (에러 버젯), Burn Rate (소진율), Freeze (코드 동결), Data-driven Governance.
  • Skills: SLO가 99.9%라면, 나머지 0.1%(한 달에 약 43분)를 에러 버젯(허용된 뻘짓의 시간)으로 계산해 놓고, 배포하다 에러가 나서 30분을 까먹으면 "이번 달 남은 예산은 13분입니다"라고 전광판에 띄우기.
• How to Learn:
  • 1단계: 예산의 부여: 완벽함(100%)은 없습니다. 구글 SRE는 100% - SLO를 공식 예산(Budget)으로 줍니다. 한 달이 43,200분인데 SLO가 99.9%면, **한 달에 43분은 합법적으로 서버를 뻗게 만들어도 되는 권리(예산)**를 부여받은 겁니다.
  • 2단계: 예산의 소비 (혁신의 가속): 개발팀은 이 예산이 남는 한, 테스트가 덜 끝났든 뭐든 미친 듯이 하루에 10번씩 신기능을 실서버에 배포합니다. 배포하다 버그가 나면 에러 버젯을 5분 차감합니다. 예산이 남았으니 계속 달립니다.
  • 3단계: 예산의 고갈 (혁신의 중지): 어제 거대한 버그를 쳐서 에러 버젯 43분을 다 써버렸습니다(잔고 0원). 즉시 모든 신기능 배포 권한이 박탈(Freeze)당합니다. 이번 달이 끝날 때까지 개발팀은 짐 싸고 코드 리팩터링과 테스트 코드 작성(안정성 작업)만 해야 합니다. 인간의 입김이 아니라 '수학'이 개발 속도(Agility)와 안정성(Reliability)의 밸런스를 강제로 조율하는 위대한 페이스메이커를 뜯어봅니다.
• Implement: Error Budget Burn Rate(소진율) 통제기 모사. 이번 달 예산: 43분 허용 (SLO 99.9%). Day 5: 핫픽스 실패로 다운타임 40분 발생. (남은 예산: 3분, 소진율 93%). Day 6: 마케팅팀이 "내일 당장 새 이벤트 배포해 주세요!" 요구. 기계의 심판: 봇이 [Reject] 도장을 찍음. 이유: 에러 버젯 잔고(3분) 부족. 다음 달 1일까지 신규 피처 배포 금지. 예외 없음. 사내 정치와 직급을 씹어 먹는 데이터 거버넌스의 승리 시각화.

Advanced

Core Topic 04: 시간의 물리학과 Nine의 마법 (The Physics of 9s & MTTR)

• Why to Learn: 비즈니스 임원이 "아마존은 99.999% 라던데, 우리도 무조건 파이브 나인(Five 9s) 맞춰!"라고 할 때, 그 뒤에 숨겨진 '수십억 원의 인프라 구축 비용' 청구서를 던져주며 헛소리를 논리적으로 분쇄하기 위함입니다.
• What to Learn:
  • Concepts: The Nines (99.9%, 99.99%), MTBF (Mean Time Between Failures), MTTR (Mean Time To Recovery), High Availability Cost Curve.
  • Skills: "99.9% (연간 8시간 다운 허용)는 서버 2대로 가능하지만, 99.999% (연간 5분 다운 허용)는 전 세계 분산 DB와 3중 로드밸런서가 필요해 인프라 비용이 100배로 뛴다"는 비선형적 비용(Cost) 곡선을 증명하기.
• How to Learn:
  • 1단계: 9의 마법 (The Nines): 9가 늘어날 때마다 다운타임은 1/10로 줍니다.
    • 2개의 9 (99%): 1년에 3일 15시간 다운. (동네 쇼핑몰)
    • 3개의 9 (99.9%): 1년에 8시간 다운. (스타트업 표준)
    • 4개의 9 (99.99%): 1년에 52분 다운. (대기업 인프라)
    • 5개의 9 (99.999%): 1년에 단 5분 다운. (항공/의료/AWS 코어)
  • 2단계: 수확 체감의 법칙: 99.9%에서 99.99%로 올리려면 인프라 비용이 10배 뜁니다. 그런데 유저들은 8시간 장애나 52분 장애나 똑같이 "앱이 가끔 뻗네" 정도로 인식합니다. 돈은 10배로 쓰는데 유저 체감 가치는 제자리걸음입니다.
  • 3단계: MTBF vs MTTR: 장애가 안 나게 간격(MTBF)을 늘리려는 노력은 불가능합니다. 번개는 떨어집니다. 대신, 장애가 났을 때 복구하는 시간(MTTR)을 3시간에서 5분으로 줄이는 자동화(GitOps 롤백)에 투자하는 것이 가성비가 1,000배 뛰어나다는 SRE 인프라 물리학의 최종 결론을 뜯어봅니다.
• Implement: The 9s 비용-효용 매트릭스 도출. 요구사항: 사내 게시판 (월 수익 100만 원). 임원이 99.999%(Five 9s) 요구. 엔지니어 분석: 99.999%를 위한 Active-Active 멀티 리전 아키텍처 및 무중단 failover 시스템 구축 비용 → 월 5,000만 원 예상. 결론: 100만 원 벌려고 5,000만 원의 인프라를 태우는 멍청한 짓임을 수학적으로 증명하고, 99.0%(Two 9s, 월 서버비 10만 원)로 역제안하는 기술 비즈니스 렌더링.

7. Terminology

8. References

Primary

• [P1] CS2023 - Software Engineering (SE) - Software Reliability (SLOs, SLIs, and Error Budgets)
• [P5] SFIA - Quality Management (QUMG) - Service level management

Secondary

• [Site Reliability Engineering] Google (Niall Richard Murphy et al.) - Embracing Risk, Service Level Objectives
• [The Site Reliability Workbook] Google - Implementing SLOs and Error Budgets

Industry

• [Google Cloud Architecture Center] - SRE fundamentals: SLIs, SLAs, and SLOs
• [Datadog Blog] - How to set and monitor SLOs and Error Budgets

9. Final Checklist

Primary

• 경영진이 "우리 서비스의 안정성 목표는 무조건 100%여야 한다"고 주장할 때, 완벽함(100%)을 추구할 경우 수반되는 기하급수적인 인프라 비용 증가와 신기능 배포 속도의 정체를 지적하며 99.9%의 타협점을 논증할 수 있는가?
• 시스템 상태를 측정할 때, 내부 인프라 지표인 "CPU 사용률 80% 이하" 대신, 사용자가 직접 체감하는 "API 응답시간 P99(하위 99%)가 200ms 이하(Latency SLI)"로 분모와 분자 공식을 설계할 수 있는가?

Secondary

• 외부 B2B 고객과 약속한 법적 위약금 마지노선인 SLA(예: 99.0%)를 방어하기 위해, 개발팀 내부적으로는 그보다 더 빡빡한 SLO(예: 99.9%)를 설정하여 사고 발생 시 대응할 수 있는 버퍼(Buffer) 공간을 어떻게 확보하는지 설명할 수 있는가?
• 한 달(43,200분) 기준으로 SLO가 99.9%일 때 부여받은 약 43분의 에러 버젯(Error Budget)을 계산하고, 핫픽스로 30분을 소진한 상황에서 잔여 예산이 13분 남았음을 수치로 증명하여 무리한 금요일 배포를 데이터로 기각할 수 있는가?

Industry

• 에러 버젯의 소진율(Burn Rate)이 평소보다 10배 빠르게 타들어가고 있을 때, 단순히 알람(Alert)을 띄우는 것을 넘어 CI/CD 파이프라인의 배포 게이트를 강제로 잠가(Code Freeze) 인간의 자의적 판단을 기계적으로 차단할 수 있는가?
• 99.9% (연 8시간 다운) 인프라를 99.99% (연 52분 다운)로 업그레이드할 때 발생하는 10배 이상의 비용(Cost) 증가 곡선을 근거로, 고장 발생 간격(MTBF)을 늘리려는 헛된 투자 대신 자동 롤백을 통해 장애 복구 시간(MTTR)을 압살하는 전략적 우위를 설계할 수 있는가?