핵심은 단순합니다. 변경 전에는 품질 개선폭만 보지 않고, 변경 후 문제가 생겼을 때 감지, 차단, 안전 복귀, backlog 처리까지 걸리는 시간을 미리 숫자로 정합니다. 이 흐름은 Synthetic Replay + Eval Gate, Policy Shadow Rollout, Change Intelligence Control Plane, Execution Receipt과 자연스럽게 연결됩니다. 결국 AI 운영이 성숙할수록 배포는 더 빨라지지만, 되돌리기는 더 의도적으로 설계됩니다.

이 글에서 얻는 것

• Rollback Budget이 단순 버전 롤백이 아니라 운영 복구 시간 예산이라는 점을 설명할 수 있습니다.
• 모델, 프롬프트, 툴, 정책 변경을 같은 rollback scorecard에서 보는 기준을 잡을 수 있습니다.
• detect-to-disable, drain, replay, human fallback 시간을 어떤 숫자로 관리해야 하는지 감을 잡을 수 있습니다.
• partial rollout과 shadow가 왜 rollback budget의 일부인지 실무적으로 이해할 수 있습니다.

핵심 개념/이슈

1) AI 변경은 “배포 성공"과 “운영 안전"이 자주 갈라진다

일반 애플리케이션 배포는 health check와 error rate만으로도 꽤 많은 문제를 잡을 수 있습니다. 하지만 AI 변경은 더 미묘합니다. 출력 형식은 멀쩡해 보여도 승인 누락이 늘거나, 툴 호출 순서가 바뀌어 비용이 급증하거나, 사람 검토로 가야 할 작업이 자동 경로로 흘러갈 수 있습니다. 즉 release dashboard가 초록색이어도 운영은 이미 틀어질 수 있습니다.

그래서 좋은 팀은 배포 전 질문을 이렇게 바꿉니다.

• 문제를 몇 분 안에 감지할 수 있는가
• 감지 후 몇 분 안에 차단할 수 있는가
• 이미 시작된 작업을 어느 상태까지 안전하게 정리할 수 있는가
• 잘못 누적된 backlog를 얼마나 빨리 복구할 수 있는가

이 질문이 바로 rollback budget의 시작점입니다.

2) Rollback Budget은 4개의 시간 예산으로 보는 편이 실전적이다

현장에서 가장 유용한 구분은 아래 네 가지입니다.

• detect_to_disable: 이상 징후 탐지부터 해당 변경 비활성화까지의 시간
• inflight_drain_time: 이미 시작된 작업을 취소, 보류, 사람 검토로 넘기는 데 걸리는 시간
• replay_backlog_recovery: 잘못 처리되었거나 보류된 작업을 정상 경로로 다시 흘리는 시간
• human_fallback_ready: 자동 경로를 끄고 사람 검토 체계로 전환하는 시간

이 네 개를 같이 봐야 하는 이유는, 모델 스위치만 되돌린다고 운영이 자동 복구되지 않기 때문입니다. 예를 들어 detect-to-disable은 3분인데, 검토 큐 전환에 40분이 걸리면 실제 서비스 위험은 여전히 큽니다. 반대로 disable이 10분 걸려도 inflight 정리와 사람 fallback이 5분 안에 끝나면 운영 영향은 작을 수 있습니다.

3) 변경 유형별 budget이 달라야 한다

모든 변경에 같은 롤백 기준을 두면 현실성이 떨어집니다. 저는 보통 아래처럼 나누는 편이 맞다고 봅니다.

• 모델 교체: detect-to-disable 10분 이내, inflight drain 15분 이내
• 프롬프트 템플릿 수정: detect-to-disable 15분 이내, replay backlog 30분 이내
• 툴 스키마 변경: detect-to-disable 5분 이내, incompatible call rate 즉시 알림
• 권한/정책 변경: detect-to-disable 5분 이내, human fallback 10분 이내
• 저위험 문구 수정: 일 단위 검토로도 충분할 수 있음

핵심은 risk가 클수록 “얼마나 빨리 내릴 수 있는가” 기준이 더 짧아져야 한다는 점입니다. 특히 외부 전송, 승인, 코드 수정, 배포 트리거처럼 blast radius가 큰 작업군은 rollback budget을 느슨하게 두면 안 됩니다.

4) Replay와 Shadow는 rollback을 대신하지 않고 더 빠르게 만든다

Synthetic Replay + Eval Gate 가 사전 검증이라면, Policy Shadow Rollout은 현실 분포 확인입니다. 그런데 둘 다 잘해도 실제 운영에서는 놓친 edge case가 나옵니다. 그래서 replay와 shadow는 rollback budget의 경쟁재가 아니라, budget을 줄여 주는 전방 안전장치입니다.

• replay가 좋으면 detect 시간이 짧아집니다.
• shadow가 좋으면 full rollout 전에 disable할 수 있습니다.
• execution receipt가 있으면 어떤 작업을 replay해야 할지 빨리 좁힐 수 있습니다.
• escalation ladder가 있으면 자동 경로를 끄고 사람/상위 모델로 빨리 우회할 수 있습니다.

즉 rollback budget은 복구 계획 문서가 아니라, 검증 체계와 연결된 운영 인터페이스입니다.

5) 좋은 팀은 승인 기준표와 rollback 기준표를 한 장에 둔다

운영 회의에서 자주 생기는 실수는 품질 점수표와 복구 준비도를 따로 보는 것입니다. 그러면 개선폭만 보고 변경을 올린 뒤, 되돌리기 준비는 막상 사고가 난 다음에 확인하게 됩니다. 이 구조는 거의 항상 느립니다.

그래서 더 실전적인 방식은 한 장짜리 scorecard로 닫는 것입니다.

• 작업군별 pass rate
• high-risk miss rate
• tool success rate
• detect-to-disable
• inflight drain time
• replay backlog recovery
• human fallback ready
• rollback owner

이 8줄이 한 화면에 있으면 “품질은 좋아졌지만 되돌리기 준비가 안 된 변경"을 바로 보류할 수 있습니다. 저는 이게 AI 운영 팀이 일반 소프트웨어 팀과 점점 더 달라지는 지점이라고 봅니다. 배포 승인보다 복구 가능성의 수치화가 먼저라는 점입니다.

실무 적용

1) 의사결정 기준(숫자·조건·우선순위)

실무 우선순위는 아래 순서가 무난합니다.

1순위, 고위험 작업군 rollback budget 명문화

• 외부 전송, 승인, 코드 수정, 툴 실행 작업부터 시작
• detect-to-disable 510분, human fallback 1015분을 기본선으로 둠

2순위, 변경 단위를 change set으로 묶기

• 모델, 프롬프트, 툴, 정책이 함께 바뀌면 개별이 아니라 묶어서 rollback owner 지정

3순위, partial rollout 기본화

• 5% → 20% → 50% → 100% 단계로 올리고, 각 단계마다 rollback timer를 따로 둠

4순위, replay와 receipt 연결

• 잘못된 변경으로 영향받은 작업을 30분 안에 재처리 후보로 분류할 수 있어야 함

2) 운영 테이블 예시

이 표의 핵심은 “롤백 가능"이라는 말 대신 몇 분 안에 무엇을 복구해야 하는지를 고정하는 데 있습니다.

3) 운영 예시: 승인보다 rollback budget이 먼저인 상황

조금 더 현실적인 예로, 어떤 팀이 외부 전송 승인 경로에 새 모델과 프롬프트 보정을 함께 올린다고 가정해 보겠습니다. 오프라인 평가에서는 승인 설명이 더 자연스럽고 reviewer 만족도도 높았습니다. 그런데 실제 운영에 올리자 20분 안에 두 가지 신호가 동시에 생깁니다. 승인 대기열은 줄었지만, 사람이 봤어야 할 borderline 케이스가 자동 승인으로 통과하기 시작하고, 반대로 애매한 건은 사람 검토 큐로 과하게 몰리면서 on-call 담당자가 급격히 바빠집니다.

이때 배포 승인 문서만 잘 써 둔 팀은 대응이 느립니다. “정말 문제인가"를 다시 토론하고, 어떤 스위치를 내릴지 찾고, 이미 진행 중인 작업을 어디까지 멈출지 따로 정해야 하기 때문입니다. 반대로 rollback budget이 선행된 팀은 배포 런북, Feature Flag 운영, SLO/Error Budget처럼 기존 운영 장치를 그대로 가져와 빠르게 움직입니다.

실무에서는 아래처럼 한 장짜리 판단표가 있으면 강합니다.

• 2분 안에 이상 징후 감지: 승인 누락률, reviewer override 비율, 대기열 길이 중 2개 이상 악화 시 경보
• 5분 안에 자동 승인 경로 비활성화: 정책 플래그를 내려 새 경로 유입 차단
• 10분 안에 inflight 분기 정리: 이미 진행 중인 건은 사람 검토 큐로 우회하거나 보류 상태로 전환
• 30분 안에 replay 후보 확보: execution receipt 기준으로 잘못 처리된 작업군만 다시 모아 재검토

핵심은 롤백을 “버전 되돌리기"가 아니라 사용자 영향 확산을 끊는 일련의 운영 동작으로 다루는 것입니다. 이 관점이 잡혀야 Synthetic Replay + Eval Gate가 사전 검증으로, Policy Shadow Rollout이 사전 노출 완충장치로, rollback budget이 사후 복구 기준으로 깔끔하게 역할 분담됩니다.

4) 4주 도입 순서

1주차: 고위험 변경 3종에 budget 설정
숫자가 완벽할 필요는 없습니다. 우선 detect, disable, fallback 시간을 처음으로 적는 것이 중요합니다.

2주차: execution receipt와 rollback owner 연결
누가 끄고, 누가 replay를 열고, 누가 사람 검토로 넘기는지 책임선을 명확히 둡니다.

3주차: shadow와 partial rollout에 timer 부착
변경을 올릴 때마다 “이 단계에서 몇 분 안에 내릴 수 있는가"를 같이 확인합니다.

4주차: rollback drill 1회 수행
실제 장애가 없어도 수동으로 disable, drain, replay, fallback을 연습합니다. 이 훈련이 없으면 budget은 문서에만 남습니다.

트레이드오프/주의점

첫째, rollback budget을 너무 공격적으로 잡으면 변경 속도가 과도하게 느려질 수 있습니다. 그래서 작업군 위험도별로 강도를 다르게 두는 편이 맞습니다.

둘째, disable은 빨라도 inflight 정리가 느리면 체감 피해는 줄지 않습니다. 차단 시간만 보고 안심하면 안 됩니다.

셋째, replay backlog를 과소평가하면 복구가 사람 작업 폭증으로 이어집니다. receipt와 replay packet이 없으면 budget이 실전에서 무너집니다.

넷째, owner가 없는 rollback plan은 거의 작동하지 않습니다. 변경마다 누가 내리고 누가 검토 큐를 여는지 지정돼 있어야 합니다.

다섯째, shadow를 오래 끌기만 하고 partial rollout을 안 하면 budget이 실제로 검증되지 않습니다. 복구 시간은 문서가 아니라 반복 훈련으로만 줄어듭니다.

체크리스트 또는 연습

체크리스트

• 변경 유형별 rollback budget이 숫자로 문서화되어 있다.
• detect-to-disable, inflight drain, replay 복구, human fallback 시간을 함께 본다.
• 고위험 변경은 partial rollout과 shadow를 기본으로 사용한다.
• execution receipt 또는 동등한 실행 증거가 남는다.
• rollback owner와 fallback owner가 구분되어 있다.
• 월 1회 이상 rollback drill을 수행한다.

미니 런북 템플릿

실제로는 체크리스트만으로 부족합니다. 장애 때 바로 붙여 넣어 쓸 수 있는 미니 런북 템플릿이 있어야 합니다.

1. Trigger: 어떤 지표가 몇 분 동안 악화되면 rollback budget을 발동하는가
2. Kill Switch: 어떤 feature flag, model route, policy version을 먼저 내리는가
3. Drain Rule: inflight 작업을 취소, 보류, 사람 검토 중 어디로 보낼 것인가
4. Replay Scope: 어떤 receipt 조건으로 재처리 대상을 추릴 것인가
5. Owner: disable, handoff, replay를 각각 누가 맡는가
6. Stop Condition: 어떤 지표가 정상화되면 부분 재개를 검토할 것인가

이 템플릿을 문서만으로 끝내지 말고, 최근 변경 1건에 실제로 채워 보세요. 많은 팀이 rollback budget을 말로는 이해해도, 막상 누가 어떤 버튼을 언제 누르는지가 비어 있어서 대응 속도가 느립니다.

연습 과제

1. 최근 모델 또는 프롬프트 변경 하나를 골라, “지금 문제를 발견하면 몇 분 안에 어디까지 되돌릴 수 있는가"를 detect, disable, drain, replay로 나눠 적어 보세요.
2. 외부 전송 또는 승인 작업군 하나를 골라, human fallback 준비 시간이 15분을 넘는 이유를 찾아보세요. 보통 큐 전환, 소유자 부재, receipt 부재가 병목입니다.
3. 현재 shadow 중인 변경이 있다면, full rollout 기준표 옆에 rollback budget 4개 항목을 같이 붙여 보세요. 승인 판단이 훨씬 보수적이고 선명해질 가능성이 큽니다.

관련 글

• Synthetic Replay + Eval Gate
• Policy Shadow Rollout
• Escalation Policy Ladder
• Change Intelligence Control Plane
• Execution Receipt
• 배포 런북 설계
• Feature Flag 운영 전략
• SLO/SLI/Error Budget 운영