SLO 에러버짓이 바닥났을 때, 가장 먼저 봐야 할 것은 무엇인가?

번다운 그래프의 급락 시점과 배포·설정 변경·트래픽 변화 시점을 겹쳐 보는 것이 출발점이다. Google SRE 정책에서는 단일 장애가 4주 에러버짓의 20% 이상을 소진하면 포스트모템이 의무이고, 전체 버짓이 소진되면 P0·보안 수정 외 모든 릴리스가 중단된다 출처. 이후 조사는 순간 오류율이 아니라 "지금 속도로 얼마나 빨리 버짓이 사라지는가", 즉 번레이트를 기준으로 진행한다.

  • 번다운 급락 시점 ↔ 배포·설정변경·트래픽 변화 대조가 모든 분석의 출발점
  • 번레이트는 오류율 한 점이 아니라 소진 속도로 봐야 조기경보가 가능
  • 체크아웃 API 사례에서는 사흘간 월간 버짓의 80%가 소진됐고, 배포부터 롤백까지 시간이 기록됨
  • 즉시 완화(롤백·확장·플래그 off)와 근본원인 분석은 반드시 분리해서 진행
  • 액션아이템은 담당자·기한·검증방법을 명시해야 재발방지로 이어진다

이번 분석에서는 가용성 SLO 기반 에러버짓 소진 사건을 번다운 그래프 판독부터 타임라인 복원, 가설 기각, 재발방지 조치까지의 과정으로 한정해서 뜯는다. SLI를 어떻게 설계하는지, SLO 수치를 조직 내부에서 어떻게 합의하는지는 다루지 않는다.

번다운 그래프에서 급락은 무엇과 맞춰봐야 하는가?

급락 시점의 좌표를 먼저 숫자로 고정한 뒤, 같은 시간대의 배포 로그·설정 변경 이력·트래픽 곡선을 나란히 놓고 본다. 가용성 SLO가 99.9%이고 평가 기간이 30일이면 허용 오류율은 0.1%, 시간으로 환산한 에러버짓은 약 43.2분이다. 이 값은 기간 × (1 − SLO)로 누구나 재현할 수 있다 출처.

번다운 급락 분석의 실무 절차는 devops-daily의 정리에서 구체화된다. 먼저 번다운이 꺾인 정확한 시각을 특정하고, 그 전후 30분~1시간 범위의 배포·설정 변경·트래픽 스파이크를 대조한다. 이 단계에서 "무엇이 바뀌었는가"를 먼저 확정해야 이후 가설 검증이 좁혀진다. 그 다음 단계로 오류를 엔드포인트, HTTP 상태 코드, 의존 서비스별로 분해한다 출처. 급락 시점만 짚고 분해를 생략하면 "무엇이 깨졌는지"는 알아도 "왜 깨졌는지"에 도달하지 못한다.

오류를 엔드포인트·상태코드·의존성으로 쪼개면 무엇이 드러나는가?

오류가 특정 상태 코드와 특정 의존 서비스에 몰려 있는지를 보면 원인 후보가 급격히 좁혀진다. 예를 들어 500번대 오류가 여러 엔드포인트에 고르게 퍼져 있다면 공용 인프라(커넥션 풀, 캐시, DNS) 문제일 가능성이 크고, 특정 엔드포인트에만 집중돼 있다면 해당 코드 경로나 그 경로가 호출하는 단일 의존성이 유력해진다.

체크아웃 API 사례에서는 오류가 데이터베이스 연결 한도 초과에 집중돼 있었다. 이 분해 결과 하나만으로 "일시적 외부 장애" 가설은 약해지고 "내부 리소스 한도 소진" 가설로 무게가 옮겨간다 출처. 분해 단계를 건너뛰고 번다운 급락 시점과 배포 시점의 일치만으로 결론을 내리면, 우연히 같은 시간대에 겹친 다른 변경을 원인으로 오인할 위험이 남는다. 엔드포인트·상태코드·의존성 3축 분해는 그 오인 가능성을 줄이는 최소한의 검증 절차다.

가설은 어떤 순서로 세우고 기각하는가?

가장 쉬운 가설부터 세우고, 데이터가 불일치하는 순간 바로 다음 가설로 넘어가는 순서가 효율적이다. 체크아웃 API 사례를 예로 들면, 초기 가설은 "일시적 네트워크 문제로 인한 외부 장애"였다. 하지만 배포 시각과 번다운 급락 시점이 정확히 일치했고, 오류가 DB 연결 한도 초과에 집중돼 있었다는 분해 결과가 나오면서 이 가설은 기각된다.

다음 가설은 "배포에서 커넥션 풀 상한이 제거됐고, 평일보다 높은 주말 배치 동시성이 DB 연결 한도를 소진했다"였다. 이 가설은 변경 전후의 커넥션 풀 설정값과 주말 배치의 동시성 조건을 실제로 재현해서 검증됐다 출처. 여기서 남는 교훈은, 장애 원인을 "배포 담당자의 실수"로 단순화하지 않고 변경·트래픽 패턴·의존성·검증 공백 네 가지의 결합으로 기술한다는 점이다. 평상시 트래픽에서 통과한 변경이 주말 배치나 스파이크, 재시도 폭증 조건에서는 다르게 반응할 수 있으므로, 대표 부하 하나만으로 변경의 안전성을 판단하지 않는다.

체크아웃 API 사례는 실제로 어떤 숫자를 남겼는가?

하나의 사례 기준으로, 2025년 4월 10~12일 사흘 동안 월간 에러버짓의 80%가 소진됐다. 금요일 16:58에 v2.3.2가 배포됐고, 주말 배치 작업이 시작된 뒤 커넥션 풀이 제한 없이 늘어나기 시작했다. 토요일 02:15에 10배 번레이트 경보가 발생했지만, 실제 소진 사실이 확인된 건 월요일 09:00이었고 15분 뒤인 09:15에 v2.3.1로 롤백됐다 출처. 배포부터 확인까지 약 64시간, 경보부터 확인까지 약 55시간이 걸렸다는 점이 이 타임라인에서 드러나는 가장 중요한 숫자다.

관측 설계 사례로는 Next.js BFF·Node 서비스·BullMQ 워커에 OpenTelemetry를 적용하고 Grafana Cloud의 Tempo·Loki를 trace_id로 연계한 HR SaaS 구성이 있다. 이 구성에서 초기 99.99% SLO는 경보가 지나치게 자주 울려 99.5%로 재조정됐고, 주간 에러버짓 리뷰와 Slack 번레이트 경보가 도입된 뒤 주간 페이지 수가 41건에서 9건으로, P1 MTTR이 4시간에서 22분으로 줄었다고 보고됐다 출처. 유사하게 OpenTelemetry·Grafana·Prometheus 기반 SLO를 도입한 다른 환경에서는 경보량이 78%, 평균 탐지 시간이 47분에서 3분으로 줄었다는 보고가 있다 출처. 다만 두 사례 모두 트래픽 규모, 서비스 버전, 하드웨어, 부하 생성 조건이 공개되지 않아 독립 재현 가능한 벤치마크가 아니라 해당 페이지의 자체 보고 사례로 분류해야 한다. 2026년 기준으로도 이 수치를 표준값처럼 인용하는 것은 적절하지 않다.

경보를 촘촘히 켜면 무엇을 잃는가?

더 낮은 SLO 여유(더 빡빡한 임계값)는 실제 저하를 더 일찍 잡아내지만, 동시에 경보 피로를 키운다. 앞서 본 HR SaaS 사례가 보여주는 트레이드오프가 정확히 이것이다. 99.99% SLO는 이론적으로는 더 안전해 보이지만, 실제로는 사소한 변동에도 경보가 터져 주간 페이지가 41건까지 쌓였다. 반대로 SLO를 99.5%로 낮추자 경보는 9건으로 줄었지만, 그만큼 임계값과 실제 사용자 영향 사이의 여유가 늘어난 셈이다 출처.

에러버짓 소진에 따른 릴리스 동결도 같은 구조의 트레이드오프를 가진다. Google SRE 정책처럼 버짓 소진 시 P0·보안 수정 외 변경을 전부 막으면 신뢰성은 보호되지만, 그 기간 동안 정상적인 기능 변경과 개선 작업은 전부 지연된다 출처. 느린 번레이트 경보를 확인만 하고 넘기지 않도록 런북을 바꾸는 조치 역시 같은 맥락이다. 조사 의무를 늘리면 조기 발견 확률은 올라가지만, 온콜 인력의 조사 부담도 함께 늘어난다.

이 분석법은 언제 쓰고 언제 과한가?

SLI·SLO가 이미 정의돼 있고 번다운·번레이트 경보 인프라가 깔려 있는 서비스에는 이 분석법이 그대로 적용된다. 반대로 SLO 자체가 아직 합의되지 않았거나 트래픽 이력이 충분히 쌓이지 않은 초기 서비스에는 번다운 급락을 판독할 기준선이 없어, 먼저 SLI 정의와 기준 트래픽 수집이 선행돼야 한다.

즉시 완화와 근본원인 분석의 분리 원칙도 경계가 있다. 장애 도중에는 롤백·용량 확장·기능 플래그 비활성화처럼 고객 영향을 줄이는 조치를 먼저 수행하고, 근본 원인 분석은 안정화 이후로 미루는 것이 기본이다 출처. 다만 원인이 명백하고(예: 특정 배포 직후 급락) 롤백이 즉시 가능한 경우라면 분리 절차를 거치느라 시간을 끌 필요는 없다. 또한 평상시 대표 부하 테스트를 통과한 변경이라도 주말 배치나 스파이크, 재시도 폭증 조건까지 재현해보지 않았다면 "검증 완료"로 간주하지 않는 편이 안전하다.

핵심 정리

  • 번다운 급락 시점과 배포·설정변경·트래픽 변화를 대조하는 것이 분석의 출발점이고, 이후 엔드포인트·상태코드·의존성 3축으로 오류를 분해한다
  • 단일 장애가 4주 에러버짓의 20% 이상을 소진하면 포스트모템이 의무이며, 전체 소진 시 P0·보안 수정 외 릴리스가 중단된다
  • 체크아웃 API 사례(자체 보고)에서는 사흘간 월간 버짓 80%가 소진됐고, 배포(금 16:58)부터 확인(월 09:00), 롤백(월 09:15)까지의 타임라인이 기록됐다
  • SLO를 지나치게 높이면(예: 99.99%) 경보 피로가 커지고, 낮추면 임계값 여유가 늘어나는 트레이드오프가 있다 — 숫자는 사용자 여정 기준으로 정기 재검토한다
  • 액션아이템에는 담당자·기한·검증방법을 명시하고 실제 완료 여부를 추적해야 재발방지로 이어진다

자주 묻는 질문

번레이트 경보와 단순 임계값 경보는 뭐가 다른가?

번레이트는 오류율 한 점이 아니라 "현재 속도로 버짓이 얼마나 빨리 소진되는가"를 본다. 체크아웃 API 사례처럼 10배 번레이트 경보는 느린 소진도 조기에 알리지만, 확인만 하고 넘기면 의미가 없어 반드시 조사하도록 런북에 명시해야 한다는 교훈이 남았다.

포스트모템은 어느 수준의 장애에서 의무화되나?

단일 장애가 4주 에러버짓의 20% 이상을 소진하면 포스트모템이 의무이고, 근본 원인을 다루는 P0 액션 아이템을 포함해야 한다. 이 기준 이하의 작은 소진은 조직 정책에 따라 선택적으로 분석한다.

SLO 수치는 얼마나 자주 재검토해야 하나?

고정된 주기는 없지만, HR SaaS 사례처럼 경보가 과도하면 재조정하고 이후 주간 에러버짓 리뷰 같은 정기 점검을 둔다. SLO는 사용자 여정과 실제 관측 가능성을 기준으로 정하고, 무조건 높은 값으로 고정하지 않는다.

릴리스 동결은 버짓이 회복될 때까지 얼마나 걸리나?

구체적인 고정 기간은 공개돼 있지 않고, 롤링 평가 기간(예: 30일) 동안 버짓이 다시 쌓일 때까지 유지하는 것이 기본 구조다. 그 사이 허용되는 변경은 P0 장애 대응과 보안 수정으로 한정된다.

더 알아보기

장애 사후분석: 타임라인·근본원인·재발 방지의 방법론 — 이 주제의 종합 가이드