SLO 기반 자율 운영, 에러 버짓으로 판단하기

알림이 모자랐던 게 아니라 판단 기준이 없었다

대부분의 운영 조직은 이미 많은 것을 자동화했다. 오토스케일링, 헬스 체크에 따른 재시작, CI/CD가 일상적으로 돌아간다. 그런데도 새벽 3시에 사람이 깬다. 자동화는 "CPU가 80%를 넘으면 노드를 늘린다" 같은 규칙은 실행하지만, "지금 사용자가 실제로 불편을 겪고 있는가"는 판단하지 못한다는 점이 주요 원인 중 하나다.

그래서 두 가지 실패가 되풀이된다.

• 과잉 반응: CPU는 90%인데 응답 시간은 정상이다. 그래도 알림이 울리고, 사람이 깨서 확인한 뒤 다시 잠든다. 이런 일이 쌓이면 진짜 알림에도 둔감해진다.
• 과소 반응: 리소스 지표는 모두 정상인데 특정 API의 5xx 비율이 조금씩 오른다. 리소스 임계치만 보는 모니터링은 이를 놓치고, 고객 문의가 먼저 들어온다.

SLO 기반 자율 운영은 판단 기준을 바꾼다. 리소스 상태가 아니라 사용자가 체감하는 신뢰성을 기준으로 삼는다. 그 기준에서 얼마나 빠르게 벗어나는지, 즉 에러 버짓 소진 속도(burn rate)를 보고 시스템이 어느 수준까지 대응할지 스스로 결정하게 한다. 사람은 매번 상황을 판별하고 버튼을 누르는 대신 정책을 설계하고 예외를 처리하며 결과를 감사하는 역할로 올라간다.

SLI, SLO, 에러 버짓: 기계가 읽을 수 있는 허용 실패량

개념	정의	예시
SLI	사용자 경험을 나타내는 측정값. 흔히 좋은 이벤트 / 전체 유효 이벤트로 계산	결제 API 요청 중 성공적으로 처리된 비율, 또는 300ms 안에 응답한 비율
SLO	정해진 기간 동안 SLI가 달성해야 하는 목표	30일 롤링 윈도우에서 가용성 99.9%
에러 버짓	1 - SLO. 기간 안에 허용되는 나쁜 이벤트의 총량	99.9% 요청 기반 SLO라면 전체 유효 요청의 0.1%
Burn rate	에러 버짓을 소진하는 속도. 1이면 현재 속도가 기간 내내 이어질 때 예산을 정확히 모두 사용	14.4면 30일 예산을 약 2.1일 만에 소진

burn rate = 관측된 나쁜 이벤트 비율 / (1 - SLO)

99.9%를 시간으로 단순 환산하면 30일 중 약 43분이다. 다만 요청 기반 SLO의 에러 버짓은 원칙적으로 '실패한 요청 수'로 계산하므로, 43분은 모든 요청이 고르게 발생하고 해당 시간에 전면 장애가 났다고 가정한 근사치다.

가용성과 지연시간은 가능한 한 별도의 SLI로 관리하는 편이 좋다. 둘을 하나의 "300ms 안에 성공한 요청"으로 합치면 계산은 간단하지만, 장애 원인이 오류인지 지연인지 구분하기 어려워질 수 있다.

자율 운영에서 에러 버짓은 목표치라기보다 위험 예산으로 사용한다. 중요한 이유는 세 가지다.

1. 공통된 판단 틀: CPU, 지연시간, 오류율처럼 단위가 다른 신호를 "사용자가 허용한 실패량에 영향을 주는가"라는 하나의 질문으로 해석할 수 있다.
2. 사용자 중심: 인프라에 문제가 있어도 사용자가 체감하지 않으면 버짓에 직접 영향을 주지 않는다. 반대로 인프라가 정상처럼 보여도 사용자 요청이 실패하면 버짓이 줄어든다.
3. 미리 합의한 위험 한도: 개발, 운영, 제품 조직이 "이만큼의 실패 위험을 허용한다"는 정책에 합의하면, 시스템이 그 범위 안에서 행동할 조직적 근거가 생긴다.

자율 운영과 자동화의 차이

자동화는 정해진 조건에 정해진 행동을 수행한다. 자율 운영은 목표인 SLO를 지키는 방향으로 허용된 행동을 선택하고, 결과를 검증해 다음 행동을 바꾼다. 핵심 차이는 결과를 다시 관측하는 폐루프(closed loop)가 있느냐에 있다.

단계	이름	하는 일	사람의 역할
L0	수동	대시보드를 보고 사람이 판단하고 실행	판단과 실행 전부
L1	임계치 알림	알림을 받고 사람이 런북 실행	판단과 실행
L2	SLO 알림	burn rate 기반으로 호출 노이즈 감소	판단과 실행
L3	조건부 자율	사전 승인된 대응을 시스템이 실행하고 결과 검증	정책 승인, 예외 처리, 사후 검토
L4	목표 기반 자율	허용된 여러 대응 중 SLO 회복 가능성이 높은 행동을 선택하고 결과를 정책 개선에 반영	정책 설계와 감사

위 단계 구분은 이 글에서 설명을 위해 나눈 분류이며 표준이 아니다. 많은 조직에서 우선 목표로 삼을 만한 단계는 L3다. L4는 스케일링이나 트래픽 가중치 조정처럼 상태 공간과 안전 경계를 비교적 명확히 정의할 수 있는 영역부터 제한적으로 시도할 수 있다.

아키텍처: 관측, 판단, 행동, 검증

[관측] --> [판단] --> [행동] --> [검증]
  ^                                |
  +--------------------------------+
     회복 확인 -> 다시 관측으로
     회복 실패, 부작용, 불확실성 -> 중단, 원복, 에스컬레이션

구성 요소별 요건은 다음과 같다.

• 관측: SLI는 사용자와 가까운 지점에서 측정한다. 로드밸런서 로그, APM 트랜잭션, RUM, 합성 모니터링이 주요 소스다. 서버 내부 지표는 SLI의 대체물이 아니라 원인 분석과 선행 신호로 사용한다.
• 판단: 정책은 코드로 관리한다(policy as code). 예를 들어 "버짓 잔량이 X% 이하이고, 긴 윈도우와 짧은 윈도우에서 burn rate가 각각 Y 이상이면 행동 A를 허용한다" 같은 규칙을 버전 관리하고 리뷰한다.
• 행동: 초기 자율 행동은 원복 가능하고, 멱등성이 있으며, 폭발 반경이 작은 것이어야 한다. 롤백, 제한된 트래픽 가중치 조정, 기능 플래그 비활성화, 상한이 있는 스케일 아웃부터 시작한다.
• 검증: 행동 뒤 일정 시간 안에 burn rate가 낮아졌는지뿐 아니라 지연, 오류율, 포화도 등 보호 지표가 악화되지 않았는지도 확인한다. 회복하지 않거나 부작용이 생기면 가능한 경우 원복하고 사람에게 에스컬레이션한다.
• 변경 이벤트 연동: 배포, 설정 변경, 기능 플래그 조정 이력을 관측 데이터와 연결한다. 판단 엔진이 최근 변경을 알면 원인 후보를 좁히고 롤백 여부를 더 안전하게 결정할 수 있다.

검증 단계가 없으면 자율 운영이 아니라 무인 자동화에 가깝다.

에러 버짓을 정책으로 만들기

Multi-window, multi-burn-rate 판단

Google SRE Workbook의 Alerting on SLOs 장에서 소개한 다중 윈도우, 다중 burn rate 방식을 판단 엔진의 입력으로 활용할 수 있다. 다음 표의 윈도우와 burn rate는 이 장이 제시한 99.9% SLO, 30일 기준의 권장 시작값이며, 자율 행동은 이를 운영 정책으로 확장한 예시다.

심각도	긴 윈도우	짧은 윈도우	Burn rate	의미	대응 예시
긴급	1시간	5분	14.4	1시간 동안 30일 버짓의 약 2% 소진	안전 조건 충족 시 자동 완화 또는 롤백, 즉시 호출
높음	6시간	30분	6	6시간 동안 30일 버짓의 약 5% 소진	자동 완화 시도, 결과 검증, 필요 시 호출
보통	3일	6시간	1	3일 동안 30일 버짓의 약 10% 소진	티켓 생성, 업무 시간에 원인 제거

긴 윈도우는 의미 있는 규모의 버짓이 소진됐는지를, 짧은 윈도우는 그 소진이 지금도 계속되는지를 확인한다. 두 조건을 모두 만족할 때만 행동하게 하면, 장애가 회복된 뒤에도 긴 윈도우에 남은 과거 오류 때문에 알림이나 자동 행동이 계속되는 일을 막을 수 있다.

참고로 Workbook 원문은 긴급과 높음 구간을 모두 호출(page), 보통 구간을 티켓으로 분류한다. 표의 자동 완화는 이를 자율 운영에 맞게 확장한 예시다. 다만 위 수치는 출발점이지 모든 서비스에 그대로 적용할 정답은 아니다. 트래픽 규모, 이벤트 발생 패턴, 탐지 지연, 자동 행동의 위험도에 따라 백테스트와 운영 결과를 바탕으로 조정해야 한다.

배포 게이트

예를 들어 다음과 같이 에러 버짓 잔량을 배포 정책에 연결할 수 있다. 아래 구간 값은 설명용 예시이며 권장값이 아니다. 실제로는 서비스의 SLO 수준, 과거 소진 패턴, 배포 빈도와 변경 위험도를 보고 정한다. Google의 오류 예산 정책 예시도 잔량 구간이 아니라 직전 4주 동안 버짓을 초과했는지를 동결 조건으로 삼는다.

• 50% 초과: 표준 배포 절차 적용
• 25~50%: 카나리 관측 시간을 늘리고 자동 분석 기준 강화
• 25% 미만: 신규 기능 배포 동결, 신뢰성 개선과 승인된 핫픽스만 허용
• 소진: 원칙적으로 배포 동결, 예외 승인과 회고 필수

이 정책을 CD 파이프라인이 직접 읽게 하면 매번 회의로 배포 여부를 정하지 않아도 된다. 단, 긴급 보안 패치처럼 배포하지 않는 위험이 더 큰 경우를 위해 책임자, 만료 시간, 감사 기록이 명확한 예외 절차를 함께 둬야 한다.

자동 롤백과 카나리 분석

카나리 버전의 SLI를 베이스라인과 비교하고, 카나리의 burn rate가 통계적으로나 운영적으로 의미 있게 높을 때 배포를 중단하거나 롤백한다. 절대 임계치만 보는 것보다 같은 시간대의 베이스라인과 비교하면 공통 장애나 자연 변동에 따른 오탐을 줄일 수 있다.

자동 롤백 전에는 최소 표본 수, 관측 시간, 베이스라인 건전성, 데이터 지연을 확인해야 한다. 데이터베이스 스키마처럼 완전한 원복이 어려운 변경은 자동 롤백 대상에서 제외하거나 별도 안전 절차를 둔다.

SLO를 반영한 스케일링

지연시간 SLI와 burn rate를 스케일링 정책에 반영하면 사용자 경험과 용량 결정을 연결할 수 있다. 다만 burn rate는 이미 발생한 나쁜 이벤트를 집계하므로 이것만으로 스케일링하면 대응이 늦을 수 있다. 큐 길이, 동시 요청 수, 포화도 같은 선행 지표로 빠르게 반응하고, SLO 신호로 확장 폭과 유지, 축소 여부를 조정하는 방식이 안전하다.

예를 들어 CPU가 높더라도 지연 SLO와 포화 신호가 안정적이면 불필요한 확장을 억제할 수 있다. 반대로 CPU에 여유가 있어도 큐와 지연이 함께 악화되면 병목을 조사하면서 사전 승인된 범위 안에서 확장할 수 있다.

우선순위와 부하 차단

버짓이 빠르게 줄어들 때는 중요도가 낮은 트래픽부터 제한하거나 저하 모드(degraded mode)로 전환해 핵심 사용자 여정의 SLO를 지킨다. 배치 작업을 지연하고, 추천 결과를 캐시된 값으로 대체하고, 비필수 분석 이벤트를 샘플링하는 식이다.

이를 위해서는 사용자 여정별 중요도, 의존성, 차단 순서, 복구 조건을 미리 정의해야 한다. 부하 차단 자체가 새로운 장애가 되지 않도록 테넌트별, 리전별 상한과 공정성도 함께 검토한다.

AI 에이전트 시대의 자율 운영

LLM 기반 운영 에이전트가 등장하면서 판단 단계의 범위가 넓어지고 있다. 에이전트는 트레이스, 로그, 변경 이력을 묶어 원인 가설을 세우고 대응 후보를 제안하는 데 유용하다. 다만 SLO가 없으면 무엇을 최적화해야 하는지, 어느 정도 위험을 감수할 수 있는지 판단할 기준이 없다. SLO와 에러 버짓은 에이전트가 따라야 할 목표와 행동 경계가 된다.

에이전트를 운영에 투입할 때는 권한을 단계적으로 나눈다.

권한 등급	예시 행동	실행 조건
읽기	지표, 로그, 트레이스 조회, 원인 가설과 대응안 작성	승인된 데이터 범위에서 상시 허용하되 민감정보 마스킹, 접근 통제, 조회 감사 적용
저위험 쓰기	상한이 있는 스케일 아웃, 사전 지정 기능 플래그 비활성화	정책 범위 안에서 자동 실행, 즉시 검증과 사후 보고
중위험 쓰기	애플리케이션 롤백, 제한된 트래픽 가중치 변경	burn rate 조건, 사전 승인 런북, 변경 호환성 확인 충족
고위험 쓰기	DB 스키마와 데이터 변경, 데이터 삭제, 리전 페일오버	반드시 사람 승인, 별도 실행 주체와 이중 확인 권장

핵심 가드레일은 다음과 같다.

• 행동 근거 기록: "1시간과 5분 윈도우에서 burn rate 14.4 초과, 직전 배포 v2.3.1과 시간적 상관, 승인된 런북에 따라 롤백"처럼 입력 신호, 정책 버전, 선택 이유, 실행 결과를 남긴다.
• 폭발 반경 제한: 한 번에 영향을 주는 서비스, 리전, 테넌트 범위, 트래픽 변경 폭, 시간당 행동 횟수에 상한을 둔다.
• 반복 루프 차단: 같은 행동을 반복해도 회복되지 않으면 정해진 횟수에서 멈추고 사람을 호출한다. 실행 중인 다른 자동화와의 충돌을 막는 잠금이나 조정 장치도 필요하다.
• 권한과 실행 주체 분리: 에이전트가 임의 명령을 만드는 대신, 좁게 정의된 도구와 사전 승인된 런북만 호출하게 한다. 자격 증명은 최소 권한과 짧은 수명으로 발급한다.
• 불확실할 때 중단: 데이터 누락, 관측 지연, 상충하는 신호가 있으면 추측으로 쓰기 작업을 실행하지 않고 사람에게 에스컬레이션한다.

도입 로드맵

1단계: SLO 정의(2~4주)

아래 단계별 기간은 대략적인 예시이며 조직 규모와 관측 체계의 성숙도에 따라 크게 달라진다.

• 로그인, 검색, 결제 등 핵심 사용자 여정 중 하나로 시작해 3~5개까지 확장
• 여정별 가용성과 지연 SLI 정의, 사용자와 가까운 지점에서 측정
• 과거 데이터와 사업 요구를 바탕으로 현실적인 SLO 설정
• 유효 이벤트, 제외 조건, 데이터 지연, 저트래픽 처리 방식 문서화
• 개발, 운영, 제품 조직이 에러 버짓 정책과 예외 절차에 합의

2단계: SLO 알림 전환(1~2개월)

• multi-window, multi-burn-rate 알림 도입
• 기존 리소스 임계치 알림은 원칙적으로 원인 분석용 대시보드나 티켓으로 전환하되, 임박한 장애나 복구 불가능한 손상을 예고하는 신호는 호출에 유지
• 호출 건수, 실제 조치가 필요했던 비율, 탐지와 복구 시간 추적
• 과거 장애를 재생해 임계치와 윈도우 백테스트

3단계: 조건부 자율(분기 단위)

• 변경 이벤트를 관측 데이터와 연결
• 버짓 기반 배포 게이트 적용
• 카나리 자동 분석과 안전한 자동 롤백 도입
• 행동, 검증, 원복 또는 에스컬레이션 루프 구현
• 모든 정책 결정과 실행 결과를 감사 로그에 기록

4단계: 목표 기반 자율

• SLO를 반영한 스케일링과 부하 차단 도입
• AI 에이전트를 읽기 전용에서 저위험 쓰기 순으로 단계적 투입
• 섀도 모드와 제한된 서비스에서 충분히 검증한 뒤 범위 확대
• 분기별로 자율 행동 성공률, 오탐률, 원복률, 사람이 개입한 비율을 검토해 정책 조정

흔한 함정과 안티패턴

• SLO를 너무 많이 만든다: 서비스마다 수십 개를 만들면 우선순위가 사라진다. 핵심 사용자 여정부터 시작하고, 의사결정에 쓰이지 않는 SLO는 정리한다.
• 서버 내부 지표를 SLI로 삼는다: "CPU 사용률 SLO"는 사용자 신뢰성을 직접 나타내지 않는다. CPU는 진단과 선행 신호로 사용한다.
• 무조건 100%를 목표로 한다: 100%가 실제 사업 요구가 아니라면 에러 버짓이 사라지고 변경과 실험의 기준도 잃는다. 필요한 신뢰성과 그 비용을 함께 결정해야 한다.
• 검증 없이 자동 행동한다: 롤백했는데 원인이 다른 곳이면 상황이 더 나빠질 수 있다. 행동 후 목표 지표와 보호 지표의 회복 확인은 필수다.
• 버짓 정책에 강제력이 없다: 버짓이 바닥날 때마다 근거 없이 예외를 허용하면 정책에 대한 신뢰가 무너진다. 예외에는 책임자, 사유, 만료 시간, 감사 기록이 있어야 한다.
• 저트래픽 서비스에 비율 SLI를 그대로 적용한다: 요청 수가 적으면 한 건의 실패로 burn rate가 크게 출렁인다. 더 긴 윈도우, 최소 이벤트 수, 합성 모니터링, 기간 내 장애 발생 건수나 장애 시간 기반 목표를 검토한다.
• 모든 실패를 서비스 책임으로 계산한다: 잘못된 요청이나 명시적으로 제외하기로 합의한 이벤트까지 분모에 넣으면 SLI가 왜곡된다. 유효 이벤트와 제외 조건을 명확히 정의한다.
• 사람을 완전히 빼려고 한다: 목적은 사람을 없애는 것이 아니라 사람의 주의를 정말 판단이 필요한 예외와 정책 개선에 집중시키는 것이다.

마무리

자율 운영의 본질은 더 똑똑한 자동화가 아니라 합의된 판단 기준이다. SLO는 "사용자에게 어느 정도로 신뢰할 수 있어야 하는가"를 숫자로 바꾸고, 에러 버짓은 그 숫자를 시스템이 사용할 수 있는 위험 예산으로 바꾼다. 이 기준이 있으면 롤백, 스케일링, 배포 동결, AI 에이전트의 행동을 같은 질문으로 정리할 수 있다.

이 행동이 에러 버짓 소진을 멈추면서도 새로운 위험을 허용 범위 안에 두는가?

출발점은 거창하지 않아도 된다. 핵심 사용자 여정 하나에 SLO를 정하고, burn rate 기반 알림으로 전환한 뒤, 가장 안전하고 되돌리기 쉬운 행동 하나를 폐루프로 자동화하는 데서 시작하면 된다.