SRE 실무 #2 에러 버짓 운영: 정책 문서와 번 레이트

5 분 소요

에러 버짓의 개념과 계산에서 버짓이 무엇이고 어떻게 계산하는지 다뤘습니다. 이번 편은 그 버짓을 조직의 의사결정 도구로 작동시키는 방법입니다. 버짓은 대시보드에 띄워 놓는 숫자가 아니라, “이 숫자가 이렇게 되면 우리는 이렇게 한다"는 사전 합의와 붙어 있을 때만 힘을 갖습니다.

에러 버짓 정책: 장애 전에 합의하는 문서 #

에러 버짓 정책(error budget policy)은 버짓 상태에 따른 행동을 미리 정해 둔 문서입니다. 핵심은 타이밍입니다. 버짓이 남아 있을 때, 이해관계가 걸리지 않은 상태에서 합의합니다. 버짓이 바닥난 뒤에 “그래서 배포를 멈출 거냐"를 논쟁하면, 그 논쟁은 항상 힘 있는 쪽이 이깁니다.

정책 문서의 뼈대는 단계별 행동표입니다. 예를 들면 이렇습니다.

버짓 잔량 (28일 창)행동
50% 이상정상 운영. 실험적 배포, 카오스 테스트 허용
50% 미만위험한 변경 보류, 배포 전 리뷰 강화
25% 미만신뢰성 작업을 스프린트 최우선으로 승격
0% (소진)피처 배포 동결. 신뢰성 개선 변경만 배포 가능

숫자와 행동은 조직마다 다르게 정하면 됩니다. 중요한 것은 세 가지입니다.

  1. 행동이 구체적이어야 합니다. “주의한다"는 정책이 아닙니다. “긴급 수정과 신뢰성 개선 외의 배포를 중단한다"가 정책입니다.
  2. 경영진의 서명이 필요합니다. 피처 동결은 제품 조직의 로드맵을 멈추는 결정입니다. 엔지니어링 내부 문서로는 실행되지 않고, 제품 책임자와 경영진이 미리 서명해야 실제 상황에서 지켜집니다.
  3. 예외 절차도 문서에 넣습니다. “동결 중에도 배포해야 한다면 누가 승인하는가"를 정해 두면, 예외가 정책을 무너뜨리는 대신 정책 안에서 처리됩니다.

번 레이트: 버짓이 줄어드는 속도 #

버짓 잔량만 보는 운영에는 구멍이 있습니다. 잔량 80%라는 숫자는 “지난 3주가 평온했다"와 “방금 시작된 장애가 시간당 10%씩 태우는 중"을 구분하지 못합니다. 그래서 속도를 봅니다.

번 레이트(burn rate)는 버짓을 소모하는 속도의 배수입니다. 기준은 1배 = 창이 끝나는 시점에 버짓이 정확히 0이 되는 속도입니다.

  • SLO 99.9%, 창 28일이면 허용 에러율은 0.1%입니다.
  • 실제 에러율이 0.1%면 번 레이트 1배. 28일 뒤 버짓이 정확히 소진됩니다.
  • 에러율 1%면 번 레이트 10배. 버짓이 2.8일 만에 바닥납니다.
  • 에러율 0.05%면 0.5배. 버짓의 절반만 쓰고 창이 끝납니다.

계산은 단순합니다. 번 레이트 = 실제 에러율 / (1 - SLO). 이 숫자 하나로 “지금 이 문제를 새벽에 깨워서 잡아야 하는가"를 판단할 수 있게 됩니다.

빠른 소진과 느린 소진은 다른 문제입니다 #

번 레이트 관점에서 버짓을 위협하는 상황은 두 종류이고, 대응도 다릅니다.

  • 빠른 소진(fast burn): 배포 사고, 인프라 장애처럼 짧은 시간에 버짓을 크게 태우는 경우입니다. 몇 시간 안에 사람이 개입해야 하므로 즉시 호출(페이지) 대상입니다.
  • 느린 소진(slow burn): 에러율이 SLO 근처를 살짝 넘는 상태가 며칠씩 이어지는 경우입니다. 오늘 밤 깨울 일은 아니지만 방치하면 창 후반에 버짓이 바닥납니다. 업무 시간에 처리할 티켓 대상입니다.

이 구분을 경보 시스템에 그대로 옮긴 것이 다중 창 번 레이트 경보이고, 다음 편(경보 설계)의 중심 주제입니다. 여기서는 원칙만 기억하면 됩니다. 같은 “버짓 위협"이라도 속도에 따라 호출과 티켓으로 갈라서 대응합니다.

릴리스 판단에 버짓을 연결하기 #

정책과 번 레이트가 갖춰지면, 버짓을 배포 파이프라인의 입력으로 쓸 수 있습니다.

  • 배포 게이트: 버짓 잔량이 임계값 아래면 파이프라인이 비긴급 배포를 자동으로 보류합니다. 사람이 정책을 기억할 필요가 없어집니다.
  • 점진 배포와 결합: 카나리 단계에서 번 레이트가 튀면 자동 롤백합니다. 버짓을 “배포가 안전한지"의 판정 기준으로 쓰는 것입니다.
  • 위험 예산 배분: 대형 마이그레이션처럼 위험한 작업은 “버짓의 20%까지 써도 된다"는 식으로 사전에 배분하면, 위험한 작업을 무작정 미루는 대신 계획적으로 수행할 수 있습니다.

이 지점이 에러 버짓의 진짜 가치입니다. 버짓은 개발 속도와 신뢰성의 싸움을 없애는 도구입니다. 버짓이 남아 있으면 빠르게 배포할 권리가 있고, 소진되면 속도를 늦출 의무가 있습니다. 양쪽 모두 감정이 아니라 숫자로 정당화됩니다.

흔한 실패 패턴 #

  • 정책 없는 버짓: 대시보드에 버짓은 있는데 소진돼도 아무 일도 일어나지 않는 경우입니다. 두 번쯤 반복되면 아무도 버짓을 보지 않게 됩니다.
  • 동결의 형해화: 피처 동결을 선언했는데 “이건 중요해서"라는 예외가 줄을 잇는 경우입니다. 예외 승인 절차를 정책에 넣고, 예외 횟수 자체를 기록해야 합니다.
  • SLO가 틀린 경우: 버짓이 만성적으로 소진된다면 팀이 게으른 것이 아니라 SLO가 현재 시스템 능력보다 높게 잡혔다는 신호일 수 있습니다. 이때의 올바른 대응은 SLO 하향 조정 또는 신뢰성 투자 확대이지, 경보 무시가 아닙니다.

정리 #

  • 에러 버짓 정책은 버짓 상태별 행동을 장애 전에 합의해 둔 문서입니다. 행동은 구체적으로, 경영진 서명과 예외 절차까지 포함합니다.
  • 번 레이트는 버짓 소모 속도의 배수입니다. 실제 에러율 / (1 - SLO)로 계산하고, 1배가 창 종료 시 정확히 소진되는 기준선입니다.
  • 빠른 소진은 페이지, 느린 소진은 티켓. 같은 위협도 속도로 대응을 가릅니다.
  • 버짓은 배포 게이트, 카나리 롤백, 위험 예산 배분으로 릴리스 판단에 연결될 때 힘을 발휘합니다.
  • 버짓이 만성 소진이면 SLO 자체를 의심합니다. 다음 편은 이 번 레이트를 경보로 구현하는 법입니다.
X