14.3 신뢰성 공학 — 실패의 예산으로 변경 속도를 산다

"장애가 없어야 한다"는 목표는 수치가 없어서 어떤 판단도 만들지 못한다. 이 문서는 사용자가 겪는 것을 재는 SLI, 합의된 목표인 SLO, 그 차이인 에러 버짓으로 신뢰성을 운영 가능한 수치로 바꾸고, burn rate 경보로 소진을 감지하며, 장애 대응·포스트모템·점진적 배포를 통해 예산 소진 신호를 실제 행동에 연결하는 체계를 다룬다.

학습 목표

• 좋은 SLI의 조건을 설명하고 사용자 여정을 기준으로 SLI와 측정 지점을 선택한다.
• 실측과 사용자 기대를 근거로 SLO를 정하고 에러 버짓을 계산한다.
• 빠른·느린 burn rate 경보를 설계하고 각 경보가 요구하는 대응 강도를 구분한다.
• 장애 대응의 역할 분리와 비난 없는 포스트모템이 정보 흐름을 지키는 구조를 설명한다.
• 점진적 배포가 에러 버짓 소진을 제한하는 메커니즘을 수치로 판단한다.

배경: "다시는 장애 없게"가 만드는 악순환

챕터 0의 장애를 겪은 주문 확정 API팀으로 돌아가자. 경영진은 "재발 방지"를 지시했고 팀은 배포 승인 절차를 3단계로 늘렸다. 결과는 예측 가능한 경로를 따른다. 배포 주기가 주 단위로 늘어지고, 배포당 변경량이 커지고, 커진 배포는 실패 확률과 진단 비용을 함께 키워 더 큰 장애를 만든다. 장애가 나면 절차가 더 늘어난다.

이 악순환의 뿌리는 절차가 아니라 목표의 부재다. "장애 없게"는 100% 신뢰성이고, 인트로에서 본 것처럼 100%는 목표가 될 수 없다. 목표 수치가 없으면 세 가지 판단이 불가능해진다. 지금 신뢰성이 충분한지(더 투자해야 하는지 그만해도 되는지), 이 배포를 나가도 되는지, 새벽에 사람을 깨울 일인지. 세 판단 모두 "현재 상태가 목표에서 얼마나 떨어져 있는가"를 전제하는데 목표가 없기 때문이다.

Google SRE가 정립한 접근은 목표를 수치로 합의하고 목표와 100%의 차이를 쓸 수 있는 예산으로 운영하는 것이다. 예산이 남았으면 배포하고, 소진되면 멈춘다. 신뢰성과 변경 속도의 갈등이 조직 정치에서 산수로 바뀐다.

핵심 개념

SLI: 사용자가 겪는 것을 비율로 잰다

SLI(Service Level Indicator)는 서비스 수준의 실측값이다. 좋은 SLI의 형태는 하나로 수렴한다.

        좋은 이벤트 수
SLI = ──────────────── × 100%
        유효한 이벤트 수

이 형태가 중요한 이유는 두 가지다. 값이 0~100%로 정규화되어 목표(SLO)와 직접 비교되고, "좋은 이벤트"의 정의에 사용자 관점이 강제로 들어간다. 주문 확정 API라면 이렇게 쓴다.

• 가용성: 유효 요청 중 5xx가 아닌 응답의 비율
• 지연: 유효 요청 중 800ms 안에 응답한 요청의 비율
• 정합성: 확정 요청 중 정확히 하나의 주문을 생성한 요청의 비율

지연 SLI를 "p99 ≤ 800ms"가 아니라 "800ms 안에 응답한 비율 ≥ 99%"로 쓰는 것은 같은 말의 재표현이지만, 비율 형태는 다른 SLI와 같은 척도가 되어 에러 버짓 계산에 바로 들어간다는 운영상 이점이 있다.

반면 CPU 사용률, 큐 길이, 인스턴스 수는 SLI가 아니다. 사용자는 CPU를 겪지 않는다. CPU 90%여도 응답이 빠르면 사용자에게는 아무 일도 없고, CPU 30%여도 락 대기로 응답이 9초면 장애다. 내부 지표는 원인 진단에 필수지만, "서비스가 충분히 좋은가"의 판정 기준은 사용자가 관찰하는 결과여야 한다.

측정 지점이 SLI의 의미를 결정한다. 같은 "가용성"도 서버 로그로 재면 서버에 도달하지 못한 실패(DNS, LB 설정 오류, 네트워크 단절)가 빠지고, 로드 밸런서 로그로 재면 클라이언트 앱의 실패가 빠진다. 사용자에 가까운 지점일수록 충실하지만 수집이 비싸고 잡음(사용자 단말·ISP 문제)이 섞인다. 어디서 재는지와 무엇이 측정 범위 밖인지를 SLI 정의에 명시하는 것까지가 SLI 설계다.

SLI는 적어야 한다. 사용자 여정(주문 확정, 주문 조회) 하나당 2~3개면 충분하고, 그 이상은 판단을 돕는 것이 아니라 "어떤 지표는 항상 나쁘다" 상태를 만들어 판단을 마비시킨다.

SLO와 에러 버짓: 목표가 예산을 만든다

SLO(Service Level Objective)는 SLI의 목표값과 측정 윈도우다. "30일 이동 윈도우에서 주문 확정 요청의 99.9%가 성공하고 800ms 안에 응답한다"처럼 쓴다. 목표 수치는 두 방향에서 좁힌다. 위로는 사용자가 실제로 필요로 하는 수준(그 이상은 체감되지 않는 투자), 아래로는 현재 실측(먼저 실측을 확인하지 않은 목표는 선언 직후부터 위반 상태로 시작할 수 있다). 처음에는 실측 기반의 달성 가능한 목표로 시작해 사용자 기대와의 격차를 점진적으로 좁히는 편이, 이상적 수치를 선언하고 무시되는 것보다 낫다.

SLO가 정해지면 에러 버짓(error budget)은 자동으로 따라온다. 에러 버짓 = 1 − SLO. 월 3,000만 요청에 SLO 99.9%라면 한 달에 30,000개의 요청은 실패해도 목표 위반이 아니다. 이 30,000개가 예산이고, 예산의 쓰임은 세 가지다. 예상 못한 장애가 소진하고, 위험한 변경(배포, 마이그레이션, 부하 실험)이 소진하고, 계획된 유지보수가 소진한다.

예산이 실제로 작동하려면 소진 시 행동이 사전에 합의되어 있어야 한다. 이것이 에러 버짓 정책(error budget policy)이다.

에러 버짓 정책 예시 (주문 확정 API, 30일 윈도우)
- 잔여 버짓 > 50%: 정상 배포. 실험적 변경 허용.
- 잔여 버짓 ≤ 50%: 배포는 카나리 단계를 2배로 늘려 진행.
- 잔여 버짓 ≤ 10%: 신뢰성 개선 외 기능 배포 동결.
- 버짓 소진: 기능 작업 중단, 소진 원인 상환 작업이 최우선.
  동결 해제는 잔여 버짓 회복 또는 경영 승인으로만.

정책의 핵심은 마지막 줄이다. 배포 동결을 풀 권한을 명시해 두지 않으면, 마감 압박이 오는 순간 정책은 조용히 무시되고 예산은 대시보드 장식이 된다. 에러 버짓은 개발팀과 운영·경영 사이의 계약이며, 계약은 위반 시 조항이 있어야 계약이다.

burn rate: 소진 속도로 경보를 설계한다

"SLO를 위반했다"는 경보는 너무 늦고, "오류가 1건 발생했다"는 경보는 너무 이르다. 필요한 것은 이 속도로 계속되면 예산이 언제 바닥나는가이고, 이를 정규화한 값이 burn rate다.

              실제 오류율
burn rate = ────────────────      (1.0 = 윈도우 종료 시점에 정확히 예산 소진)
             1 − SLO

SLO 99.9%에서 오류율이 0.1%면 burn rate 1.0으로, 30일 뒤 예산이 정확히 0이 된다. 오류율 1.44%면 burn rate 14.4로, 그대로 두면 50시간 만에 한 달 예산이 사라진다. Google SRE Workbook이 권장하는 경보 설계는 소진 속도별로 대응 강도를 다르게 묶는다(30일 윈도우 기준).

burn rate	측정 윈도우	이 상태가 윈도우만큼 지속되면	대응
14.4	1시간	30일 예산의 2% 소진	즉시 호출(page)
6	6시간	30일 예산의 5% 소진	즉시 호출(page)
1	3일	30일 예산의 10% 소진	티켓(다음 근무일 처리)

이 표의 논리를 풀면 이렇다. 예산의 2%를 한 시간에 태우는 사건은 사람이 자다가도 일어나야 하는 속도다. 반대로 burn rate 1은 "목표를 정확히 다 쓰는 속도"이므로 급하지 않지만, 3일간 지속됐다면 우연이 아니라 지속적 저하이므로 근무 시간에 조사해야 한다. 빠른 소진은 사건(incident)이고 느린 소진은 부채(debt)다. 전자는 즉시 완화가, 후자는 원인 상환 계획이 대응이다.

실무에서는 각 경보에 짧은 보조 윈도우(긴 윈도우의 1/12, 예: 1시간 경보에 5분)를 함께 걸어 "지금도 소진 중인가"를 확인한다. 긴 윈도우 하나만 쓰면 사건이 이미 끝났는데도 평균이 임계를 넘은 채로 남아 경보가 계속 울리고, 이런 잔향이 반복되면 팀은 경보를 무시하게 된다. 경보의 비용은 오탐 자체가 아니라 경보 채널의 신뢰 하락이며, 사람이 확인해서 "할 일 없음"으로 끝나는 경보는 설계 실패로 취급해 제거하거나 티켓으로 강등해야 한다.

장애 대응: 판단 구조를 미리 정한다

burn rate 경보가 사람을 깨웠다면 그때부터는 장애 대응(incident response)이다. 장애 중의 판단은 평시와 두 가지가 다르다. 정보가 불완전하고, 조사와 완화가 자원을 두고 경쟁한다. 이를 다루는 구조가 역할 분리다.

• 지휘(incident commander): 우선순위와 자원 배분을 결정한다. 직접 조사하지 않는다.
• 작업(operations): 실제 조사와 완화를 수행한다.
• 소통(communications): 이해관계자에게 상태를 알리고, 작업자에게 오는 질문을 차단한다.

소규모 팀이 세 역할을 세 사람으로 채울 필요는 없지만, 역할의 분리 자체는 규모와 무관하게 유효하다. 조사에 몰입한 사람은 "이 조사를 계속할 가치가 있는가"를 판단하기 가장 나쁜 위치에 있고, 상태를 묻는 메시지에 답하느라 조사가 끊기는 것은 가장 흔한 대응 지연 원인이기 때문이다.

우선순위도 미리 정한다. 완화가 원인 규명에 앞선다. 롤백, 기능 플래그 비활성화, 트래픽 전환처럼 원인을 몰라도 피해를 멈추는 수단을 먼저 쓴다. 챕터 0의 사례에서 "SDK 재시도를 플래그로 끈다"가 "왜 느려졌는지 규명"보다 먼저인 것과 같은 논리다. 원인은 시스템이 안정된 뒤 보존된 증거(로그, 메트릭, 타임라인)로 조사한다.

포스트모템: 비난이 없어야 정보가 남는다

장애가 끝나면 에러 버짓은 이미 소진됐다. 남은 가치는 정보다. 포스트모템(postmortem)은 그 정보를 재발 방지로 바꾸는 문서이고, 표준 구성은 타임라인(감지→완화→해소), 사용자 영향(SLI로 정량화), 원인 분석, 그리고 소유자와 기한이 있는 액션 아이템이다.

비난 없음(blameless)이 이 과정의 전제 조건인 이유는 도덕이 아니라 정보 이론적 필요다. "누가 잘못했나"를 묻는 조직에서 사람들은 자기에게 불리한 정보를 내지 않는다. 타임라인에서 "내가 경보를 보고도 오탐이라 판단해 30분간 무시했다"는 진술이 사라지면, "경보 오탐률이 높아 진짜 신호가 무시되는 구조"라는 진짜 원인도 함께 사라진다. 다음 장애 때 같은 30분이 반복된다.

그래서 분석의 질문을 바꾼다. "왜 그 사람이 실수했나"가 아니라 "왜 시스템은 그 실수 하나로 사용자 피해까지 도달했나" 다. 사람의 실수는 확률적으로 반드시 발생하는 입력이고, 방어 계층(리뷰, 테스트, 카나리, 자동 롤백, 경보)이 그 입력을 흡수하도록 설계하는 것이 시스템의 책임이다. 잘못된 설정을 배포한 사람이 아니라, 설정 오류가 검증 없이 전체 리전에 도달할 수 있었던 배포 경로가 분석 대상이다. 액션 아이템도 "담당자 교육"이 아니라 방어 계층의 추가·수리로 나와야 하며, "더 조심한다"는 액션 아이템은 아무것도 바꾸지 않겠다는 선언과 같다.

점진적 배포: 예산으로 계산하는 폭발 반경

변경은 장애의 지배적 원인이므로, 에러 버짓을 지키는 가장 효과적인 메커니즘은 변경의 폭발 반경(blast radius)을 제한하는 것이다. 점진적 배포가 예산을 지키는 효과는 수치로 계산된다.

주문 확정 API(SLO 99.9%, 30일 윈도우)에 치명적 결함이 있는 버전을 배포한다고 하자. 결함은 노출된 트래픽을 100% 실패시킨다.

• 전체 배포: 오류율 100%, burn rate 1000. 예산 전체가 43분 만에 소진된다. 사람이 대응하기 전에 한 달 예산이 사라진다.
• 1% 카나리: 전체 오류율 1%, burn rate 10. 1시간 안에 감지·롤백하면 소진은 예산의 약 1.4%다. 같은 결함이 예산의 1.4%로 관측되고 차단된 것이다.

이 계산이 보여주는 것은 카나리가 "조심스러운 느낌"이 아니라 예산 소진의 상한을 노출 비율로 통제하는 장치라는 점이다. 카나리 단계(1% → 10% → 50% → 100%)와 각 단계의 관찰 시간은 "이 단계에서 최악의 결함이 소진할 예산"으로 설계하고, 관찰 대상은 내부 지표가 아니라 SLI다. 카나리 집단의 SLI가 기존 집단보다 유의하게 나쁘면 자동 롤백까지 연결해야, 감지에서 완화까지의 시간이 사람의 반응 속도에 묶이지 않는다.

기능 플래그는 배포(코드 전달)와 릴리스(기능 노출)를 분리해 같은 원리를 기능 단위로 적용한다. 챕터 0 사례의 "SDK 재시도를 플래그로 끈다"가 가능했던 것은 이 분리가 있었기 때문이고, 롤백 없이 초 단위로 폭발 반경을 0으로 만드는 수단이 된다. 파이프라인 구축과 배포 전략의 구현은 챕터 15에서 다루며, 여기서의 요점은 판단 기준이다. 배포 방식은 취향이 아니라 에러 버짓 정책의 집행 수단으로 선택한다.

실무 관점

SLO와 SLA를 혼동하면 목표가 방어선이 된다

SLA(Service Level Agreement)는 위반 시 보상이 따르는 대외 계약이고, SLO는 내부 운영 목표다. 둘을 같은 수치로 두면 SLO 위반이 곧 계약 위반이 되어, 팀은 목표를 사수해야 할 방어선으로 취급하고 예산을 쓰는 결정(위험한 변경)을 하지 못하게 된다. 내부 SLO는 SLA보다 엄격하게 두어 SLA 위반 전에 내부 경보와 동결이 먼저 작동하는 완충을 만든다.

원인 기반 경보를 증상 기반 경보로 교체한다

"CPU > 80%", "디스크 > 90%", "재시작 발생" 같은 원인 후보 기반 경보는 사용자 피해 없이도 울리고(오탐), 예상 못한 원인에는 침묵한다(누락). SLI 기반 burn rate 경보는 원인이 무엇이든 사용자 피해가 있을 때만 울린다. 원인 지표들은 경보가 아니라 대시보드와 진단 쿼리로 옮긴다. 경보 목록을 검토해 "이 경보가 울렸을 때 사용자 피해가 없다면 왜 사람을 부르는가"에 답하지 못하는 항목을 제거하는 것이, 경보 추가보다 신뢰성 운영을 더 개선하는 경우가 많다.

포스트모템의 액션 아이템이 완료되는지가 문화의 실측이다

포스트모템 문서가 쌓이는데 같은 유형의 장애가 반복된다면, 액션 아이템이 백로그에서 기능 작업에 밀려 죽고 있을 가능성이 높다. 액션 아이템에 소유자·기한을 붙이고 완료율을 추적하는 것, 그리고 에러 버짓 정책에 "버짓 소진 시 미완료 포스트모템 액션이 최우선"을 명시하는 것이 문서를 의례에서 투자로 되돌린다. 포스트모템 회의에서 "잘된 것"(감지가 빨랐다, 롤백이 동작했다)을 기록하는 것도 형식이 아니다. 어떤 방어 계층이 실제로 작동했는지의 증거이며, 다음 투자에서 지킬 것의 목록이다.

낮은 트래픽에서는 비율 SLI가 불안정하다

시간당 요청이 수백 건인 서비스에서 요청 5개의 실패는 오류율을 크게 흔들어 burn rate 경보를 오탐으로 만든다. 윈도우를 늘리거나(감지 지연과 트레이드오프), 이벤트 수 기반 조건을 병행하거나("실패 N건 이상 그리고 burn rate 임계 초과"), 사용자 수가 적은 내부 서비스라면 SLO 자체를 더 관대하게 두는 것이 맞다. SLI·SLO 체계는 통계가 성립할 트래픽을 전제하며, 그 전제가 깨지는 규모에서는 기법을 기계적으로 이식하지 않는다.

더 깊이: 의존성이 SLO의 상한을 정한다

주문 확정 API가 재고 서비스와 결제 서비스를 직렬로 호출하고 각각의 가용성이 99.9%라면, 두 의존성만으로 성공률의 기대 상한은 0.999 × 0.999 ≈ 99.8%다. 자체 결함이 하나도 없어도 99.9% SLO를 지킬 수 없다. 이 계산은 SLO 설정 전에 의존성 그래프를 따라 내려가며 해야 하는 산수이고, 결과가 목표에 못 미치면 선택지는 세 가지다. 목표를 현실로 내리거나, 의존성의 SLO 상향을 협상하거나, 아키텍처로 의존을 우회한다(캐시된 재고로 낙관적 확정, 결제의 비동기화 등 — 이 대안들의 정합성 비용은 챕터 10의 주제다).

역방향의 함의도 있다. 당신의 서비스가 다른 팀의 의존성이라면, 당신의 SLO는 그들의 SLO 산수에 들어가는 입력이다. 실측보다 관대한 SLO를 공표하면 소비자들은 그 수치로 설계하고, 당신이 SLO를 지켜도 그들의 여유가 사라진다. 반대로 실제보다 훨씬 높은 신뢰성을 오래 제공하면 소비자들은 공표 수치가 아니라 체감 신뢰성에 맞춰 설계하게 되고(재시도 없는 호출, 타임아웃 없는 대기), 당신이 SLO 범위 안에서 정당하게 실패해도 그들이 깨진다. 공표한 SLO와 제공하는 신뢰성을 의도적으로 일치시키는 것 — 필요하다면 계획된 장애 주입으로라도 — 이 의존성 계약을 건강하게 유지한다.

정리

• 신뢰성 목표가 수치가 아니면 투자 중단점, 배포 가부, 호출 여부 어떤 판단도 만들 수 없다. SLI는 사용자가 겪는 결과를 좋은 이벤트/유효 이벤트 비율로 재고, 측정 지점과 측정 범위 밖을 명시해야 완성된다.
• SLO는 실측에서 출발해 사용자 기대로 좁혀 가는 합의이고, 에러 버짓(1−SLO)은 장애와 위험한 변경이 함께 쓰는 예산이다. 소진 시 행동(동결, 상환 우선)이 사전에 합의되어야 예산이 작동한다.
• burn rate는 예산 소진 속도의 정규화다. 빠른 소진(14.4×/1h)은 즉시 호출, 지속적 저소진(1×/3d)은 티켓으로 대응 강도를 나누고, 사람이 확인해서 할 일이 없는 경보는 설계 실패로 제거한다.
• 장애 중에는 완화가 규명에 앞서고 지휘·작업·소통을 분리한다. 포스트모템은 "왜 실수했나"가 아니라 "왜 방어 계층이 실수를 흡수하지 못했나"를 물어야 재발 방지 정보가 보존된다.
• 점진적 배포는 예산 소진 상한을 노출 비율로 통제하는 장치다. 전체 배포의 치명 결함은 43분에 월 예산을 소진하지만 1% 카나리는 같은 결함을 예산 1.4%로 차단한다. 배포 방식은 에러 버짓 정책의 집행 수단이다.

확인 문제

1. 팀이 SLI로 "5분 평균 CPU 사용률 70% 이하 유지 비율"을 제안했다. 이 지표가 SLI로 부적합한 이유를 두 가지 관점에서 설명하고, 같은 서비스(주문 조회 API)에 적합한 SLI를 측정 지점과 함께 제안하라.
2. SLO 99.9%(30일)인 서비스에서 오류율 0.5%가 40분째 지속 중이다. burn rate를 계산하고, 이 상태가 어느 경보(즉시 호출/티켓)에 해당하는지, 그리고 이 시점까지 소진된 예산이 대략 얼마인지 판단하라.
3. 포스트모템 초안에 "근본 원인: 담당자가 배포 전 체크리스트의 설정 검증 단계를 누락함. 액션 아이템: 전 팀원 체크리스트 재교육"이라고 적혀 있다. 이 분석의 구조적 문제를 지적하고 분석과 액션 아이템을 다시 써라.
4. 잔여 에러 버짓이 5%인 상태에서 마케팅이 "내일 대규모 프로모션에 맞춘 신기능 배포"를 요구한다. 에러 버짓 정책상 동결 구간이다. 이 상황에서 "무조건 배포 불가"보다 나은 대응 구조를 설계하라.

정답과 해설

1. 첫째, 사용자 관점이 없다. CPU 70%는 사용자가 겪는 어떤 결과와도 직접 대응하지 않는다. CPU가 90%여도 응답이 빠르면 사용자 피해가 없고, 30%여도 락·의존성 대기로 느리면 장애다. 원인 후보 지표를 판정 기준으로 쓰면 오탐과 누락이 함께 생긴다. 둘째, 목표가 되는 순간 왜곡된다(14.2의 Goodhart). 인스턴스를 과잉 증설하면 사용자 경험 개선 없이 SLI가 "달성"된다. 적합한 대안: "유효 요청 중 200ms 안에 2xx로 응답한 비율"(지연+가용성)을 로드 밸런서 로그에서 측정한다. LB 측정은 서버 장애·미도달을 포함하되 클라이언트 측 실패는 범위 밖임을 정의에 명시한다. CPU는 대시보드의 진단 지표로 옮긴다.
2. burn rate = 0.5% / 0.1% = 5. 이 속도가 6시간 지속되면 예산의 5 × 6/720 ≈ 4.2%가 소진된다. 표의 "6배/6시간" 즉시 호출 경보에 근접한 속도이므로 즉시 호출 대상이다(다만 경보 발화는 각 윈도우의 측정치 기준이므로, 40분 시점에는 1시간 윈도우 경보(임계 14.4)에는 못 미치고 6시간 윈도우가 채워지며 발화하게 된다 — 짧은 보조 윈도우를 병행하는 이유다). 지금까지 소진: 40분은 720시간의 약 0.093%이고 burn rate 5를 곱하면 약 0.46%, 즉 30일 예산의 약 0.5%다. 소진량 자체는 아직 작지만 속도가 문제이며, 방치하면 6일 안에 월 예산이 사라진다.
3. 이 분석은 "사람의 실수"에서 멈췄다. 사람의 누락은 확률적으로 반드시 발생하는 입력이므로 근본 원인이 될 수 없고, "재교육"은 그 확률을 유의미하게 바꾸지 못하는 액션이다. 진짜 질문은 "체크리스트 한 단계의 누락이 어떻게 검증 없이 사용자 피해까지 도달했나"다. 다시 쓰면 — 원인: (a) 설정 검증이 사람의 기억에 의존하는 수동 단계였다. (b) 잘못된 설정이 카나리 없이 전체에 적용되는 배포 경로가 존재했다. (c) 설정 오류로 인한 SLI 저하를 감지해 자동 롤백하는 장치가 없었다. 액션 아이템: 설정 검증을 배포 파이프라인의 자동 게이트로 전환(소유자·기한), 설정 변경도 코드 배포와 같은 카나리 경로를 강제, 카나리 SLI 저하 시 자동 롤백 연결. 재교육은 이 방어 계층들이 갖춰지기 전의 임시 완충으로만 의미가 있다.
4. "불가"로 끝나면 정책은 마감 압박에 밀려 조용히 무시되고, 그 순간 에러 버짓 체계 전체의 신뢰가 죽는다. 나은 구조는 정책에 이미 예외 경로를 설계해 두는 것이다. (1) 결정의 승격: 동결 해제는 팀이 아니라 예산의 이해관계자(경영)가 위험을 명시적으로 인수하는 결정으로 만든다. "배포하면 잔여 예산 5%로 프로모션 트래픽을 받는다. 장애 시 SLA 보상과 프로모션 실패 위험은 이 결정이 인수한다"를 문서로 남긴다. (2) 위험 축소 조건부 승인: 배포하되 폭발 반경을 통제한다 — 기능 플래그 뒤에 배포해 프로모션 직전 1%부터 점진 노출, SLI 저하 시 플래그로 즉시 차단, 자동 롤백 조건을 평소보다 민감하게 설정. (3) 사후 정산: 배포로 예산을 초과 소진하면 프로모션 종료 후 신뢰성 상환 작업을 최우선으로 한다는 조건을 함께 합의한다. 정책의 목적은 배포를 막는 것이 아니라 위험 인수를 명시적·가역적으로 만드는 것이다.

참고 자료

• Marc Alvidrez, Embracing Risk (Google SRE Book) — 에러 버짓의 원 정의와 신뢰성 대 변경 속도의 균형 논리를 확인한다.
• Chris Jones 외, Service Level Objectives (Google SRE Book) — SLI·SLO·SLA의 구분과 목표 설정 원칙의 기준 문서다.
• Steven Thurgood 외, Implementing SLOs (Google SRE Workbook) — 좋은 이벤트/유효 이벤트 비율 형태, 사용자 여정 기반 SLI 선택, 측정 지점의 트레이드오프를 확인한다.
• Steven Thurgood 외, Alerting on SLOs (Google SRE Workbook) — burn rate 경보의 임계값(14.4/6/1)과 다중 윈도우 설계의 유도 과정을 확인한다.
• John Lunney, Sue Lueder, Postmortem Culture: Learning from Failure (Google SRE Book) — 비난 없는 포스트모템의 근거와 문서 구성, 액션 아이템 운영을 확인한다.
• Andrew Stribblehill, Managing Incidents (Google SRE Book) — 지휘·작업·소통의 역할 분리와 장애 중 판단 구조의 출처다.