Error Budget: 장애를 허용하는 예산의 개념과 계산

전편에서 SLO를 100%가 아닌 값으로 정했습니다. 그 순간 흥미로운 것이 생깁니다. 목표가 99.9%라면 0.1%만큼은 실패해도 된다는 뜻이고, 이 “실패해도 되는 몫"에 이름을 붙인 것이 Error Budget(오류 예산)입니다. 예산이라는 이름은 비유가 아닙니다. 실제로 잔액이 있고, 소비되고, 바닥나면 지출이 통제됩니다.

예산의 크기: 계산은 뺄셈과 곱셈뿐 #

Error Budget = 1 − SLO입니다. 이것을 측정 구간에 곱하면 손에 잡히는 크기가 나옵니다.

두 가지 환산을 다 만들어 두는 것이 실용적입니다. 시간 환산은 “이번 장애 37분짜리로 이번 달 예산의 86%를 썼다"처럼 인시던트의 무게를 즉시 말해 주고, 요청 수 환산은 완전 정지가 아닌 부분 장애(오류율 5%가 두 시간)를 계산할 수 있게 해 줍니다. 부분 장애의 소비량은 “오류율 × 지속 시간"이므로, 5% 오류율 2시간은 100% 정지 6분과 같은 지출입니다.

예산이 바꾸는 것 ①: 갈등이 규칙이 됩니다 #

Error Budget의 첫 번째 쓸모는 1편에서 예고한 것, 개발 속도와 안정성의 갈등을 회의가 아니라 규칙으로 바꾸는 것입니다.

• 예산이 남아 있으면 배포하고, 실험하고, 위험을 감수합니다. 신뢰성이 목표를 넘고 있다는 뜻이므로, 남는 신뢰성은 속도로 바꿔 쓰는 것이 합리적입니다.
• 예산이 소진되면 사전에 합의한 정책이 발동합니다. 전형적으로는 기능 배포 동결(핫픽스, 신뢰성 개선만 허용), 신뢰성 작업의 우선순위 격상입니다.

핵심은 정책을 예산이 남아 있을 때 미리 합의해 두는 것입니다. 소진된 뒤에 “동결이냐 아니냐"를 논의하면 결국 힘의 문제로 돌아갑니다. 문서로 굳혀 둔 정책이 있으면, 동결은 누군가의 판단이 아니라 잔액 조회의 결과가 됩니다. 그리고 이 규칙은 개발팀을 벌주는 장치가 아닙니다. 예산이 넉넉할 때 “더 과감하게 배포해도 된다"는 허가를 주는, 양방향 장치로 운영해야 제도가 삽니다.

예산이 바꾸는 것 ②: 알림이 소진 속도 기반이 됩니다 #

전통적 알림은 임계값입니다(“오류율 1% 초과 시 호출”). 이 방식은 두 가지로 어긋납니다. 짧은 스파이크에 사람을 깨우고(예산으로 보면 티끌), 임계값 바로 아래에서 며칠씩 이어지는 출혈은 놓칩니다.

Error Budget은 이것을 번 레이트(burn rate, 소진 속도) 알림으로 바꿉니다. 번 레이트 1은 “이 속도면 구간 종료와 함께 예산이 정확히 0"이라는 속도입니다. 번 레이트 14.4는 30일 예산을 이틀에 태우는 속도입니다. 실무 표준은 두 단계입니다.

• 빠른 소진(예: 1시간 창에서 번 레이트 14 이상): 즉시 호출합니다. 지금 크게 새고 있습니다.
• 느린 소진(예: 6시간 창에서 번 레이트 3 이상): 티켓을 만들어 근무 시간에 대응합니다. 이대로 두면 예산이 며칠 안에 마릅니다.

이 구조의 장점은 알림의 의미가 자명해진다는 것입니다. “오류율 1%“는 심각한지 아닌지 해석이 필요하지만, “이 속도면 이틀 뒤 예산 소진"은 그 자체가 판단입니다.

운영에서 만나는 현실 문제 #

• 의존성이 태우는 예산: 클라우드나 외부 API의 장애도 우리 SLI에는 우리 실패로 찍힙니다. 원칙적으로 맞는 처리입니다. 사용자는 원인을 구분하지 않기 때문입니다. 의존성 장애가 예산을 반복해서 태운다면, 그것은 “우리 잘못이 아니다"가 아니라 재시도, 폴백, 멀티 리전 같은 방어가 필요하다는 신호로 읽습니다.
• 계획 정비(점검 창): 사용자에게 영향이 있는 계획 작업도 예산에서 차감합니다. 예산이 넉넉할 때 정비를 배치하는 식으로, 정비 일정 결정에도 같은 잔액을 씁니다.
• 구간 방식: 달력 기준 30일(매월 리셋)은 이해가 쉽고, 롤링 30일은 월초 리셋 직후 예산이 갑자기 넉넉해지는 왜곡이 없습니다. 시작은 달력 기준이 쉽고, 성숙하면 롤링으로 옮기는 팀이 많습니다.
• 너무 안 쓰는 것도 신호입니다: 예산이 매달 대부분 남는다면 목표가 실제 능력보다 느슨하다는 뜻이고, 그만큼 배포를 보수적으로 하고 있을 가능성이 있습니다. 예산은 다 쓰라고 있는 것입니다.

시작하는 법: 작게, 한 서비스부터 #

도입 절차는 SLO만 있으면 간단합니다. 핵심 서비스 하나의 SLO에서 예산을 환산해 대시보드에 잔액과 번 레이트를 올리고, 두 단계 번 레이트 알림을 걸고, 소진 시 정책 한 페이지를 관련 팀과 합의합니다. 첫 달의 목표는 규칙의 완벽함이 아니라 “잔액을 보는 습관"입니다. 인시던트가 예산 언어로 회고되기 시작하면(다음 편에서 다룹니다) 제도가 자리 잡은 것입니다.

정리 #

• Error Budget = 1 − SLO. 시간과 요청 수 양쪽으로 환산해 두면 인시던트의 무게와 부분 장애의 지출을 즉시 말할 수 있습니다.
• 예산이 남으면 속도에 쓰고, 소진되면 사전 합의한 정책(배포 동결, 신뢰성 우선)이 발동합니다. 정책은 반드시 소진 전에 합의합니다.
• 알림은 임계값이 아니라 번 레이트로 겁니다. 빠른 소진은 호출, 느린 소진은 티켓이라는 두 단계가 표준입니다.
• 의존성 장애도 예산에서 차감합니다. 반복되면 면책 사유가 아니라 방어 설계가 필요하다는 신호입니다.
• 매달 남아도는 예산은 목표가 느슨하다는 신호입니다. 예산은 쓰라고 있는 것입니다.

다음 편은 예산을 실제로 태우는 순간의 이야기, 인시던트 핸들링입니다.