예산이 0.1건 남았을 때 배포할까

한 줄 요약

오류 예산은 대시보드 장식이 아니라 검증된 관측과 합의된 정책으로 변경 여부를 결정하는 입력입니다. 데이터가 없는데도 오류가 0건이라는 이유로 배포를 승인하면, 안전한 판단이 아니라 증거가 없는 판단입니다.

왜 이게 필요했나

가상의 플랫폼 팀이 30일간 발급 가용성 99.9%, 빠른 성공 비율 99%를 목표로 정했습니다. 이번 창에는 유효 시도 10000건, 가용 성공 9995건, 빠른 성공 9850건이 있습니다. 가용성만 보면 99.95%로 목표를 넘지만, 빠른 성공은 98.5%로 부족합니다. 팀이 가용성 한 칸만 보고 새 기능을 배포하면 이미 나쁜 지연 경험을 더 악화시킬 수 있습니다.

이 단원의 수치는 정책 판단을 배우기 위한 예시입니다. 모든 플랫폼의 적정 목표라는 뜻이 아닙니다. 너무 느슨한 목표도, 사용자가 구별하지 못하는 극단적인 목표도 비용과 우선순위를 왜곡할 수 있습니다. 어떤 사용자 경험을 지키려는지부터 설명할 수 있어야 합니다.

어떻게 동작하나

요청 기반 예산의 네 숫자

같은 관측 창에서 N은 유효 시도 수, G는 좋은 시도 수, T는 목표 비율입니다. 허용 실패량은 N × (1 − T), 실제 실패량은 N − G, 남은 예산은 허용 실패량에서 실제 실패량을 뺀 값입니다. 소비 비율은 실제 실패량을 허용 실패량으로 나눕니다. 실습은 sli·consumed를 소수 6자리로 표시하지만 예산 경계 비교를 위해 허용 실패량을 정수로 반올림하지 않습니다.

N=10000, T=0.999면 허용 실패는 10건입니다. 실패가 5건이면 5건이 남고 절반을 소비했습니다. 실패가 10건이면 잔여가 정확히 0입니다. 실패가 20건이면 잔여 -10, 소비 비율 2로 초과 사용을 보여 줍니다. 화면을 예쁘게 보이게 하려고 음수를 0으로 잘라 버리면 초과량을 잃습니다.

N=100일 때 같은 목표를 적용하면 허용 실패량은 0.1건입니다. 실제 실패 사건이 0.1건 있다는 뜻이 아니라 비율 목표가 허용하는 산술량입니다. 실패 1건이면 이 작은 창의 예산을 10배 사용합니다. 0.1을 먼저 0으로 반올림하면 분모가 0이 되어 정책 해석까지 틀어집니다. 적은 표본의 민감성과 대표 관측 창을 함께 설명해야 합니다.

예산 고갈과 변경 정책은 합의한다

[Google SRE 오류 예산 정책 예시](https://sre.google/workbook/error-budget-policy/)는 예산 상태를 변경 우선순위와 연결하고 책임·예외를 문서화하는 참고 자료입니다. 이번 실습의 단순 정책은 잔여 예산이 0 이하이면 일반 기능 변경을 freeze, 남아 있으면 ship입니다. freeze를 “모든 작업 금지”로 읽지 마세요. 장애 복구나 긴급 보안 수정에는 별도 판단·검토 절차가 필요합니다. 여기의 함수는 실제 배포 시스템을 호출하지 않고 학습용 결론만 반환합니다.

관측 공백이 있거나 유효 시도가 0건이면 investigate입니다. 이 경우 성공률·예산 숫자를 null로 남겨 계산할 근거가 없음을 드러냅니다. 창에서 요청이 정말 없었는지, 수집기가 멈췄는지, 라우팅이 바뀌었는지 다음 조사를 해야 합니다. 입력 covered는 관측 범위에 관한 증거를 요약한 플래그이며, 코드가 true로 써 줬다고 실제 관측 완전성이 증명되지는 않습니다.

서로 다른 창의 숫자를 섞지 않는다

이번 실습의 steady·slow·gap은 같은 서비스의 연속 세 날짜가 아니라 독립적인 30일 관측 창의 가상 사례입니다. 각 창 안에서 분모와 분자를 맞춥니다. 어제의 분모에 오늘의 실패량을 나누거나, 30일 전체 예산과 5분간 실패 건수를 곧바로 같은 소비율이라고 부르지 않습니다. 짧은 기간의 소비 속도를 이용한 알림 설계는 별도 시간 구간과 비율 정의가 필요합니다.

가용성과 지연 판단을 합칠 때는 investigate가 우선이고, 그다음 freeze, 마지막 ship입니다. 한 지표의 근거가 없는데 다른 지표가 좋다는 이유로 승인하지 않기 위해서입니다. 우선순위는 이번 과제의 계약이며 더 복잡한 서비스 정책에는 서비스 중요도·의존성·변경 위험도도 들어갈 수 있습니다.

현장에서 만나는 모습

steady는 가용 성공 9995/10000, 빠른 성공 9950/10000이고 관측이 완전하므로 두 예산이 모두 남습니다. slow는 같은 가용성이라도 빠른 성공이 9850건뿐이라 freeze입니다. gap은 수집된 숫자가 100%여도 covered=False라 investigate입니다. 세 사례를 하나의 상태 문자열로만 제출하지 않고 각 SLI·허용량·잔여량·소비 비율을 함께 남겨 다음 사람이 판단 근거를 다시 계산하게 합니다.

이런 판단은 도구 설치 이상의 직무 역량입니다. 2026-09-11 확인한 [Supabase SRE 공고](https://jobs.ashbyhq.com/supabase/ed6cedb1-b9bf-4609-ac5c-c75c33b31bf3/)는 사용자 경험에 근거한 SLI/SLO, 오류 예산 정책, 운영 준비성 검토를 연결합니다. 이 실습은 그중 작은 계산·검증 루프를 다루며, 대규모 운영 경험이나 채용 요건 전체를 충족시켰다는 의미는 아닙니다.

다음 실습에서 할 것

먼저 HTTP 실패를 분모에서 빠뜨리지 않도록 분류하고 실제 요청으로 검증합니다. 이후 집계·예산·보고서를 구현하며 정상 사례와 반례를 함께 만듭니다. 마지막 단계는 다섯 가지 잘못된 구현을 여러분의 사례가 구별하는지 검사합니다. 기대값을 잘못 적어 실패하게 만드는 것이 아니라 올바른 구현은 통과시키고 잘못된 구현만 거절해야 합니다.