핵심 인사이트

  1. Error Budget(오류 예산)은 SLO에서 허용되는 오류의 총량 — "99.9% SLO = 0.1% 오류 허용 = 월 43.2분 다운타임"으로 표현되며, 오류 예산 소진 속도가 기능 개발 속도를 조절하는 SRE의 핵심 메커니즘이다.
  2. Error Budget 정책(Error Budget Policy)이 없으면 이론에 불과 — SRE팀이 오류 예산이 소진될 때 "기능 개발을 멈추고 안정성에 집중한다"는 명시적 규칙이 존재해야 개발팀과의 협력이 실질적으로 작동한다.
  3. SLO는 사용자 경험과 직결된 지표를 측정해야 한다 — 시스템 CPU 사용률 같은 내부 지표가 아닌, 요청 성공률·응답 시간·에러율처럼 사용자가 직접 느끼는 "골든 시그널(Golden Signal)"을 SLI로 정의해야 의미 있는 SLO가 된다.

Ⅰ. SLI·SLO·SLA·Error Budget

계층 구조:

SLI (Service Level Indicator):
  측정 가능한 서비스 특성
  예: "이번 달 요청 성공률 = 99.95%"

SLO (Service Level Objective):
  내부 목표 (계약 아님)
  예: "요청 성공률 SLO = 99.9%"
  
  → 현재 99.95% > 99.9% → SLO 준수 ✅

SLA (Service Level Agreement):
  고객과의 외부 계약
  예: "가용성 99.9% 보장 (SLA)"
  
  SLO > SLA 설정: 완충 지대
  (SLO 위반 → 경고, SLA 위반 → 계약 페널티)

Error Budget:
  SLO에서 허용되는 오류 총량
  
  Error Budget = 1 - SLO
  
  예: SLO = 99.9%
  Error Budget = 0.1%
  
  월 기준 (30일 × 24시간 × 60분 = 43,200분):
  허용 다운타임 = 43,200분 × 0.1% = 43.2분
  
  소진 추적:
  이번 달 다운타임 = 30분
  남은 예산 = 43.2 - 30 = 13.2분 (70.4% 소진)

Error Budget 소진율:
  빠른 소진 → 릴리스 속도 감소
  느린 소진 → 더 빠른 릴리스 가능
  
  소진율 100% → SLO 위반

📢 섹션 요약 비유: Error Budget은 월 용돈 — 99.9% SLO = 한 달 43.2분 용돈. 장애마다 용돈이 줄어요. 다 쓰면(SLO 위반) 다음 달까지 조심해야(릴리스 중단)!


Ⅱ. Error Budget Policy

Error Budget Policy (오류 예산 정책):

목적:
  오류 예산 소진 수준에 따른 행동 지침
  개발팀 ↔ SRE팀 갈등 해결 메커니즘

정책 구성 예:

오류 예산 소진율 0~50%:
  → 정상 릴리스 계속
  → 기능 개발 속도 유지

오류 예산 소진율 50~75%:
  → 릴리스 검토 강화
  → 고위험 변경 차단
  → 신규 기능 대신 안정성 작업 일부 투입

오류 예산 소진율 75~100%:
  → 릴리스 속도 50% 감소
  → 안정성 이슈 우선 해결
  → 피처 플래그(Feature Flag) 활용 점진적 배포

오류 예산 완전 소진 (100%):
  → 기능 개발 중단 (릴리스 프리즈)
  → 모든 리소스 안정성에 투입
  → 포스트모텀 + 개선 계획 필수
  → 다음 달 SLO 검토

정책 합의 주체:
  개발팀 + SRE팀 + 제품 관리자
  공식 문서화 (Policy Document)
  경영진 승인

핵심 효과:
  개발팀: "왜 빨리 배포 못 해요?"
  SRE팀: "오류 예산 90% 소진했잖아요"
  → 주관적 갈등 → 객관적 데이터 기반 대화

📢 섹션 요약 비유: Error Budget Policy는 지출 규칙 — 용돈(예산) 50% 쓰면 사치품(고위험 릴리스) 금지, 75% 쓰면 필수품만, 다 쓰면 소비 완전 중단. 명확한 규칙!


Ⅲ. 골든 시그널 기반 SLI

Google SRE 골든 시그널 (4 Golden Signals):

1. 지연 시간 (Latency):
  요청 처리 시간
  중요: 성공 응답 vs 실패 응답 지연 구분
  
  SLI 예: P99 응답시간 < 200ms
  
  실패 응답 지연도 포함해야:
  타임아웃 = 5초 응답 = 나쁜 SLI에 포함

2. 트래픽 (Traffic):
  시스템 부하 측정
  HTTP RPS, 초당 트랜잭션
  
  SLI 예: RPS (성능 용량 SLI)
  트래픽 급증 탐지 → 자동 스케일링 트리거

3. 에러 (Errors):
  요청 실패율
  
  SLI 예: 에러율 < 0.1%
  
  명시적 실패: HTTP 500
  암묵적 실패: HTTP 200이지만 잘못된 응답

4. 포화도 (Saturation):
  시스템 리소스 얼마나 차 있나
  CPU: 80%, 메모리: 85%, 디스크: 90%
  
  SLI 예: 큐 깊이 < 100개
  성능 저하 예측 지표

SLI 작성 원칙:
  1. 사용자 중심: 사용자가 직접 경험하는 것
  2. 측정 가능: 명확한 수치
  3. 달성 가능: 기술적으로 가능한 목표
  4. 관련성: 서비스 신뢰성과 직결

나쁜 SLI 예:
  CPU 사용률 < 70% (사용자 경험과 직접 무관)
  
좋은 SLI 예:
  요청 성공률 > 99.9%
  P99 응답시간 < 300ms
  에러율 < 0.1%

📢 섹션 요약 비유: 골든 시그널은 신체 활력 징후 — 지연(맥박), 트래픽(호흡), 에러(체온), 포화도(혈압). 네 가지 정상이면 서비스 건강!


Ⅳ. SLO 설정 방법

SLO 설정 과정:

1단계: SLI 정의
  어떤 지표가 사용자 경험을 대표하는가?
  
  결제 서비스:
  SLI-1: 결제 요청 성공률
  SLI-2: 결제 P99 응답시간
  SLI-3: 결제 에러율

2단계: 기준선 파악
  과거 데이터 분석 (최소 4주)
  
  현재 성공률: 99.93%
  P99 응답시간: 280ms
  에러율: 0.07%

3단계: SLO 설정
  기준선 기반 + 비즈니스 요구사항 고려
  
  원칙:
  SLO = 기준선 - 완충 (5~20%)
  너무 엄격: 지속 불가
  너무 느슨: 의미 없음
  
  SLO-1: 성공률 ≥ 99.9% (기준 99.93%)
  SLO-2: P99 ≤ 300ms (기준 280ms)
  SLO-3: 에러율 ≤ 0.1% (기준 0.07%)

4단계: 측정 구현
  Prometheus + Grafana:
  
  # 성공률 쿼리
  sum(rate(http_requests_total{status=~"2.."}[5m]))
  /
  sum(rate(http_requests_total[5m]))
  
  Datadog, Google Cloud Monitoring 내장 SLO

5단계: Error Budget 추적
  주간 SLO 리뷰 미팅
  Error Budget Burn Rate 알림
  
  Burn Rate > 1: 예산 소진 중
  Burn Rate > 3: 심각 경보 (1시간 내 SLO 위반 예상)

📢 섹션 요약 비유: SLO 설정은 시험 목표 점수 — 평소 93점이면 SLO를 90점으로(여유 있게). 너무 높게 잡으면(97점) 항상 스트레스. 적당한 목표로 지속 가능하게!


Ⅴ. 실무 시나리오 — 전자상거래 SRE

전자상거래 플랫폼 Error Budget 관리:

서비스: 상품 검색 + 주문 처리
SLO: 성공률 99.95%, P99 < 500ms

월초 Error Budget:
  성공률 Budget = 0.05% × 43,200분 = 21.6분
  P99 Budget = 별도 추적

1주차:
  배포 3회 → 장애 없음
  성공률: 99.97%
  Budget 소진: 5.4분 (25% 소진)
  → 정상 범위

2주차:
  대형 기능 배포 → DB 쿼리 오류 30분
  성공률: 99.92% (SLO 위반!)
  Budget 완전 소진 + 초과

Error Budget Policy 발동:
  Budget 소진 100% → 릴리스 프리즈 선언
  
  3주차:
  기능 개발 중단
  원인 분석:
  → DB 인덱스 미생성 쿼리 → 전체 테이블 스캔
  → 트래픽 증가 시 타임아웃
  
  해결:
  인덱스 추가, 쿼리 최적화, DB 읽기 복제 추가
  
  4주차:
  성능 테스트 + 점진적 배포
  Budget 회복 (월 초기화)

포스트모텀:
  원인: 신규 기능 배포 전 성능 테스트 누락
  대책:
  1. 배포 전 부하 테스트 의무화
  2. DB 쿼리 플랜 검토 체크리스트
  3. 점진적 배포 (Canary: 1% → 10% → 100%)

결과:
  이후 3개월: SLO 위반 0건
  Error Budget 소진율 평균 30%
  (기능 개발 충분히 진행하면서 안정성 유지)

📢 섹션 요약 비유: 전자상거래 SRE — 2주차 장애로 용돈(Budget) 바닥. 릴리스 프리즈(쇼핑 중단) + 원인 제거(DB 최적화). 이후 3개월 용돈 30%만 써서 안정+개발 균형!


📌 관련 개념 맵

Error Budget & SLO
+-- 지표 체계
|   +-- SLI (측정)
|   +-- SLO (목표)
|   +-- SLA (계약)
|   +-- Error Budget
+-- 골든 시그널
|   +-- 지연, 트래픽, 에러, 포화도
+-- 정책
|   +-- Error Budget Policy
|   +-- 릴리스 프리즈
+-- 도구
    +-- Prometheus + Grafana
    +-- Datadog SLO
    +-- Google Cloud Monitoring

📈 관련 키워드 및 발전 흐름도

[Google SRE 개념 (2003~)]
내부 SRE 팀 운영
Error Budget 실험
      |
      v
[Google SRE 책 (2016)]
SLI/SLO/Error Budget 공개
업계 표준화
      |
      v
[Prometheus + Grafana (2016~)]
오픈소스 SLO 측정
클라우드 네이티브 SRE
      |
      v
[SLO 도구 상용화 (2018~)]
Nobl9, Datadog SLO
OpenSLO 표준화
      |
      v
[현재: AI 기반 SLO]
ML 기반 이상 탐지
번 레이트 예측

👶 어린이를 위한 3줄 비유 설명

  1. Error Budget은 월 용돈 — 99.9% SLO = 한 달 43분 용돈. 장애마다 용돈 줄어요. 다 쓰면 새 기능 개발 중단!
  2. Error Budget Policy는 지출 규칙 — 용돈 75% 쓰면 사치품(고위험 배포) 금지, 다 쓰면 완전 중단. 팀이 미리 약속한 규칙!
  3. 골든 시그널은 건강 진단 — 지연(맥박), 트래픽(호흡), 에러(체온), 포화도(혈압). 네 가지 정상 = 서비스 건강!