AI 오류 예산 배포 승인 루프

AI가 만든 기능을 배포할 때 가장 자주 생기는 문제는 코드가 틀렸다는 사실보다, 무엇을 기준으로 배포를 멈출지 미리 정하지 않았다는 사실입니다. 테스트가 모두 통과해도 사용자가 체감하는 오류율, 응답 지연, 결제 실패, 알림 누락, 접근 권한 오류가 갑자기 늘 수 있습니다. 반대로 작은 경고 하나 때문에 계속 배포를 막으면 팀은 AI 자동화를 신뢰하지 못하고 수동 확인으로 돌아갑니다. 그래서 VIBE 코딩에서는 배포 승인 기준을 감정이 아니라 오류 예산, 관측 지표, 롤백 조건으로 다루어야 합니다.

초보자는 오류 예산을 “서비스가 감당할 수 있는 실패의 한도”로 이해하면 됩니다. 예를 들어 30분 동안 새 기능의 5xx 비율이 1%를 넘지 않아야 한다, 결제 완료 전환이 이전 7일 평균보다 10% 이상 떨어지면 멈춘다, 특정 핵심 페이지의 p95 응답 시간이 2초를 넘으면 롤백한다 같은 숫자가 오류 예산입니다. 실무에서는 이 숫자에 기능 플래그, 카나리 배포, 로그 이벤트, 브라우저 스모크, 사용자 영향도 판단을 묶어 “AI 배포 승인 루프”로 만듭니다.

핵심 결론

AI 오류 예산 배포 승인 루프의 핵심은 “AI가 만든 변경을 자동으로 믿지 말고, 정해진 숫자 안에서만 점진적으로 믿는다”입니다. 코드 리뷰와 테스트는 출발점이고, 실제 승인은 운영 지표가 합니다. 배포 전에는 어떤 지표를 볼지 정하고, 배포 중에는 작은 사용자 집단에서 오류 예산을 소비하는지 확인하고, 배포 후에는 롤백 또는 확대 승인 기준을 적용합니다.

이 루프는 세 가지 산출물을 남깁니다. 첫째, AI 작업 지시서에 들어갈 배포 승인 계약입니다. 둘째, 릴리스별로 기록되는 관측 지표와 결정 로그입니다. 셋째, 다음 배포에서 재사용할 중단·승인 기준입니다. 이 세 가지가 없으면 “잘 된 것 같다”는 느낌이 배포 기준이 되고, 장애가 난 뒤에야 어떤 숫자를 봐야 했는지 떠올리게 됩니다.

좋은 오류 예산은 너무 넓지도 너무 좁지도 않습니다. “오류가 조금이라도 있으면 중단”은 현실적이지 않고, “큰 문제가 없으면 진행”은 모호합니다. VIBE 코딩에서는 기능 성격에 맞게 핵심 사용자 행동 1~3개, 서버 오류 1~2개, 성능 지표 1개, 사용자 문의나 알림 같은 정성 신호 1개를 고릅니다. 그리고 각 지표에 관찰 시간, 임계값, 책임 있는 행동을 붙입니다.

왜 중요한가

AI 변경은 빠르지만 사용자 영향은 느리게 드러난다

AI 에이전트는 한 번에 라우팅, 상태 관리, 데이터 저장, 스타일, 테스트를 모두 수정할 수 있습니다. 로컬에서는 자연스럽게 보이지만 실제 사용자는 오래된 브라우저 캐시, 느린 네트워크, 권한이 다른 계정, 예외적인 입력값, 모바일 화면, 외부 연동 지연을 동시에 만납니다. 이때 배포 직후 5분은 조용할 수 있고, 30분 뒤 특정 경로에서만 오류가 늘어날 수 있습니다.

오류 예산은 이 지연을 감안해 “언제까지 무엇을 볼 것인가”를 정합니다. AI가 만든 변경을 바로 전체 공개하지 않고 10%, 25%, 50%, 100%처럼 단계적으로 넓히면 실패를 작게 만들 수 있습니다. 숫자로 정한 지표가 정상 범위에 있으면 다음 단계로 승인하고, 벗어나면 기능 플래그를 끄거나 이전 버전으로 되돌립니다.

배포 승인 기준이 없으면 사람도 AI도 책임을 미룬다

장애가 난 뒤 흔히 나오는 말은 “테스트는 통과했는데요”입니다. 테스트는 중요하지만 운영 승인을 대신하지 않습니다. AI에게 “배포해도 되는지 확인해”라고만 지시하면 에이전트는 빌드 성공, 단위 테스트, 화면 표시 정도만 확인할 수 있습니다. 하지만 사업적으로 중요한 것은 가입 성공률, 질문 제출 성공률, 결제 전환, 검색 결과 품질, 고객 문의 증가 같은 사용자 결과입니다.

배포 승인 기준을 숫자로 만들면 사람과 AI가 같은 표를 봅니다. AI는 관측 로그를 수집하고, 사람은 숫자의 의미와 사용자 영향을 판단합니다. 둘 중 하나만으로는 부족합니다. 숫자가 기준 안이면 승인 근거가 남고, 기준 밖이면 감정 소모 없이 중단할 수 있습니다.

오류 예산은 속도를 늦추는 장치가 아니라 속도를 지키는 장치다

처음에는 임계값과 체크리스트가 번거롭게 느껴집니다. 그러나 몇 번 반복하면 오히려 배포가 빨라집니다. 매번 무엇을 볼지 토론하지 않아도 되고, 장애가 나도 “어디까지 되돌릴지”가 정해져 있습니다. AI 에이전트도 동일한 형식의 지시를 받아 배포 노트를 만들고, 스모크 경로를 확인하고, 지표 관찰 결과를 요약할 수 있습니다.

실제 작업 순서

1단계: 릴리스 단위를 작게 자른다

오류 예산 루프는 작은 변경에 가장 잘 작동합니다. AI에게 큰 기능 전체를 한 번에 완성시키면 어떤 지표가 어떤 변경 때문에 흔들렸는지 알기 어렵습니다. 먼저 릴리스를 사용자 행동 하나 또는 기술 위험 하나로 나눕니다. 예를 들어 “질문 작성 폼의 제출 안정성 개선”, “결제 완료 후 알림 재시도”, “대시보드 목록 가상 스크롤 적용”처럼 관찰 가능한 단위가 좋습니다.

작업 지시서에는 목표와 비목표를 함께 적습니다. 이번 릴리스가 바꾸는 경로, 바꾸지 않는 경로, 데이터 쓰기 여부, 외부 서비스 호출 여부, 사용자에게 즉시 보이는 변화 여부를 분리합니다. 이렇게 해야 오류 예산 지표도 작게 설계됩니다.

2단계: 사용자 결과 지표를 먼저 고른다

기술 지표만 보면 사용자가 겪는 문제를 놓칠 수 있습니다. 그래서 먼저 사용자 결과 지표를 고릅니다. 예를 들어 제출 성공률, 저장 완료율, 검색 결과 클릭률, 알림 수신 성공률, 결제 완료율, 재시도 후 성공률 같은 값입니다. 그 다음 서버 오류율, 응답 시간, 브라우저 콘솔 오류, 큐 적체, 외부 호출 실패율을 붙입니다.

각 지표에는 기준선을 둡니다. 기준선은 최근 7일 평균, 직전 배포 전 24시간, 또는 같은 요일·같은 시간대 평균처럼 비교 가능한 값이 좋습니다. 트래픽이 적은 서비스라면 비율만으로 판단하지 말고 건수 기준을 함께 둡니다. 예를 들어 “오류율 2% 초과이면서 실패 5건 이상”처럼 작은 표본의 흔들림을 줄입니다.

3단계: 오류 예산 표를 만든다

릴리스 문서에는 다음 항목을 넣습니다. 지표 이름, 기준선, 허용 범위, 관찰 시간, 중단 행동, 승인 행동입니다. 예를 들어 “질문 제출 성공률은 직전 7일 평균 대비 5%포인트 이상 하락하면 기능 플래그를 끈다”, “p95 응답 시간이 2초를 15분 이상 넘으면 카나리를 중단한다”, “브라우저 콘솔 오류가 새 경로에서 재현되면 확대 배포를 보류한다”처럼 씁니다.

표는 길 필요가 없습니다. 오히려 5개 이하의 핵심 지표가 좋습니다. 너무 많은 숫자를 보면 아무도 책임 있게 판단하지 못합니다. AI에게는 이 표를 기준으로 로그와 화면 스모크를 요약하게 하고, 사람은 중단 또는 승인 결정을 내립니다.

4단계: AI에게 배포 전 검증을 맡기되 원자료 노출을 막는다

AI에게 줄 지시는 구체적이어야 합니다. “배포 전 확인해줘”가 아니라 “이 릴리스의 오류 예산 표를 기준으로 테스트, 스모크, 관측 이벤트 이름, 롤백 조건을 확인하고 위험을 요약해줘”라고 씁니다. 이때 외부 서비스 인증값, 개인 식별 정보, 내부 연결 문자열, 원문 사용자 데이터는 출력하지 말라고 명시합니다.

AI는 체크리스트를 실행하고 사람이 보기 좋은 요약을 만들 수 있습니다. 하지만 승인 버튼을 누르는 권한까지 자동으로 주지는 않습니다. 특히 결제, 권한, 데이터 삭제, 대량 알림, 개인정보 처리 흐름은 사람 승인 단계를 유지해야 합니다.

5단계: 카나리와 기능 플래그로 사용자 범위를 제한한다

전체 공개 전에 작은 범위로 시작합니다. 내부 계정, 직원 계정, 특정 비율의 사용자, 특정 지역, 특정 기능 플래그 그룹처럼 제어 가능한 범위가 좋습니다. 카나리 단계에서는 오류 예산을 짧은 시간으로 봅니다. 예를 들어 10분 또는 30분 동안 핵심 지표가 정상인지 확인한 뒤 다음 단계로 넘어갑니다.

기능 플래그는 단순한 on/off가 아니라 롤백 수단입니다. 배포된 코드를 되돌리지 않아도 위험 기능만 끌 수 있어야 합니다. 단, 플래그가 너무 많으면 상태 조합이 폭발하므로 릴리스마다 어떤 플래그가 관련되는지 기록해야 합니다.

6단계: 배포 후 결정 로그를 남긴다

승인 또는 중단을 했다면 이유를 남깁니다. “정상”이 아니라 “질문 제출 성공률 98.7%, p95 740ms, 새 콘솔 오류 0건, 실패 2건으로 기준 내라서 50%에서 100%로 확대”처럼 써야 다음 사람이 이해합니다. 중단했다면 어떤 지표가 얼마만큼 벗어났고 어떤 조치를 했는지 남깁니다.

결정 로그는 다음 배포의 기준선이 됩니다. 매번 새로 판단하는 대신 과거 릴리스의 정상 범위와 실패 패턴을 축적하면 AI에게도 더 좋은 맥락을 줄 수 있습니다.

상황별 예시

예시 A: 질문 제출 폼을 AI가 리팩터링한 경우

상황은 단순해 보입니다. 입력 검증을 정리하고 제출 버튼 상태를 바꾸는 작업입니다. 하지만 실제 위험은 중복 제출, 모바일 키보드 상태, 느린 네트워크에서의 재시도, 성공 후 이동 누락입니다. 오류 예산은 제출 성공률, 중복 제출 건수, 평균 응답 시간, 브라우저 콘솔 오류, 공개 목록 반영 지연으로 잡습니다.

중단 기준은 명확합니다. 제출 성공률이 기준선보다 5%포인트 이상 떨어지거나, 같은 사용자가 같은 내용으로 2회 이상 중복 저장되는 사례가 확인되거나, 모바일에서 성공 후 이동이 재현성 있게 실패하면 확대를 멈춥니다. 승인 기준은 내부 계정과 10% 사용자에서 30분 동안 기준 내에 있고, 대표 브라우저에서 제출·성공·목록 반영이 확인되는 것입니다.

예시 B: 결제 후 알림 재시도 로직을 추가한 경우

결제와 알림은 사용자 신뢰에 직접 연결됩니다. AI가 재시도 큐를 만들었더라도 무한 재시도, 중복 알림, 결제 완료 표시 지연, 실패 원인 은닉이 생길 수 있습니다. 오류 예산은 결제 완료 후 알림 발송 성공률, 중복 알림 비율, 큐 적체 시간, 결제 완료 화면 표시 지연, 고객 문의 증가로 잡습니다.

이 경우 승인 기준은 더 보수적이어야 합니다. 10% 카나리에서 충분한 결제 표본이 쌓일 때까지 기다리고, 중복 알림이 1건이라도 확인되면 확대를 보류합니다. 사용자가 돈을 냈는데 상태가 모호하면 기술 지표가 좋아도 사용자 영향은 큽니다.

예시 C: 관리자성 일괄 작업 화면을 개선한 경우

대량 작업 화면은 작은 UI 오류가 큰 데이터 변경으로 이어질 수 있습니다. AI가 체크박스, 필터, 일괄 실행 버튼, 확인 모달을 개선했다면 오류 예산은 실행 대상 수의 정확도, 취소 가능성, 권한 없는 실행 시도, 실행 후 감사 로그, 되돌리기 경로로 잡습니다.

중단 기준은 권한이 다른 계정에서 버튼이 보이거나, 필터 결과와 실행 대상 수가 다르거나, 확인 모달 없이 일괄 실행이 가능하거나, 실행 결과를 추적할 이벤트가 없을 때입니다. 이 경우 성능보다 권한과 되돌리기 가능성이 더 중요합니다.

실수와 주의점

평균만 보고 p95와 최악 경로를 놓친다

평균 응답 시간은 좋아 보여도 일부 사용자가 매우 느린 응답을 겪을 수 있습니다. AI가 캐시나 데이터 로딩을 바꾸면 첫 방문, 모바일, 권한이 많은 계정, 데이터가 많은 계정에서만 느려질 수 있습니다. p95, p99, 특정 경로별 지표를 함께 봐야 합니다.

오류율만 보고 사용자 행동 실패를 놓친다

서버가 200을 반환해도 사용자가 원하는 결과가 저장되지 않을 수 있습니다. 폼 제출 후 성공 메시지가 떴지만 목록에 반영되지 않는 경우, 결제 완료 후 알림이 안 가는 경우, 검색 결과가 빈 목록으로 고정되는 경우가 그렇습니다. 사용자 결과 지표를 반드시 넣어야 합니다.

카나리 없이 전체 공개한다

작은 서비스라도 전체 공개는 위험합니다. 특히 AI가 데이터 흐름, 권한, 상태 전이를 함께 바꿨다면 카나리를 생략하지 마세요. 트래픽이 적다면 내부 계정이나 테스트 고객 그룹이라도 좋습니다. 중요한 것은 실패 범위를 제한하는 것입니다.

중단 기준을 회의 중에 만든다

장애가 의심되는 순간에는 모두가 긴장합니다. 그때 기준을 새로 만들면 낙관론과 비관론이 충돌합니다. 중단 기준은 배포 전에 작성되어야 합니다. 숫자와 행동이 이미 정해져 있으면 토론 시간을 줄이고 사용자를 보호할 수 있습니다.

AI에게 승인 권한까지 넘긴다

AI는 지표를 모으고 비교하고 요약하는 데 강합니다. 하지만 사업 영향, 고객 신뢰, 법적 위험, 브랜드 리스크는 사람이 최종 판단해야 합니다. 자동 확대는 낮은 위험 기능에 한정하고, 결제·권한·개인정보·삭제·대량 알림은 사람 승인 단계를 유지합니다.

AI에게 줄 지시 예시

다음 문장을 그대로 복사해 시작점으로 쓸 수 있습니다. 실제 프로젝트에서는 경로명과 지표명을 바꿔 사용하세요.

이번 변경은 질문 제출 흐름의 안정성 개선이다. 목표는 중복 제출을 막고 느린 네트워크에서도 성공 후 이동을 안정화하는 것이다. 비목표는 목록 디자인 변경과 권한 정책 변경이다. 배포 전 오류 예산 표를 만들어라. 사용자 결과 지표는 제출 성공률, 중복 저장 건수, 성공 후 목록 반영 시간이다. 기술 지표는 서버 오류율, p95 응답 시간, 브라우저 콘솔 오류다. 각 지표에 기준선, 허용 범위, 관찰 시간, 중단 행동, 승인 행동을 붙여라. 원문 사용자 데이터나 외부 서비스 인증값은 출력하지 말고 안전한 집계값만 사용하라.

구현 후에는 단위 테스트, 통합 테스트, 대표 브라우저 스모크, 모바일 폭 화면 스모크를 실행했다는 증거를 남겨라. 배포는 내부 계정, 10%, 50%, 100% 순서로 확대한다고 가정하고 각 단계에서 어떤 숫자를 확인해야 하는지 써라. 중단 기준에 걸리면 기능 플래그를 끄는 순서와 사용자 공지 필요 여부를 제안하라.

이 지시는 AI에게 해야 할 일과 하지 말아야 할 일을 동시에 알려줍니다. 특히 “원문 사용자 데이터나 외부 서비스 인증값은 출력하지 말라”는 문장은 디버깅 편의를 위해 위험한 값을 노출하는 습관을 막는 안전장치입니다.

검증 체크리스트

• 릴리스 목표와 비목표가 한 문단으로 분리되어 있는가?
• 핵심 사용자 결과 지표가 최소 1개 이상 들어갔는가?
• 서버 오류, 성능, 브라우저 콘솔, 외부 연동 실패 중 이번 변경에 맞는 기술 지표를 골랐는가?
• 각 지표에 기준선, 허용 범위, 관찰 시간, 중단 행동, 승인 행동이 있는가?
• 표본이 적을 때 비율만 보지 않고 최소 건수 조건을 함께 두었는가?
• 기능 플래그나 카나리처럼 실패 범위를 줄이는 수단이 있는가?
• 롤백 또는 플래그 off가 실제로 실행 가능한지 배포 전에 확인했는가?
• 사용자에게 보이는 성공 메시지와 실제 저장·반영 결과가 일치하는지 확인했는가?
• 브라우저 콘솔에 사용자 원문 데이터나 긴 내부 식별자가 남지 않는지 확인했는가?
• AI 요약이 원자료를 그대로 출력하지 않고 안전한 집계와 판단 근거만 남기는가?

중단 기준과 승인 기준

중단 기준

다음 조건 중 하나라도 만족하면 확대 배포를 멈춥니다. 핵심 사용자 결과 지표가 기준선보다 약속한 폭 이상 하락한다. 서버 오류율이나 p95 응답 시간이 관찰 시간 동안 임계값을 넘는다. 새 브라우저 콘솔 오류가 대표 경로에서 재현된다. 기능 플래그 off나 이전 버전 전환이 즉시 실행되지 않는다. 결제·권한·데이터 삭제·대량 알림처럼 되돌리기 어려운 경로에서 예외가 1건이라도 확인된다.

중단은 실패가 아니라 안전한 운영입니다. 중단 후에는 원인 후보, 사용자 영향 범위, 임시 완화, 재배포 조건을 기록합니다. AI에게는 “해결책을 바로 넣어라”보다 “증거를 기준으로 원인 후보를 3개 이하로 좁히고, 되돌릴 수 있는 작은 수정안을 제안하라”고 지시하는 편이 안전합니다.

승인 기준

승인은 모든 숫자가 완벽하다는 뜻이 아닙니다. 정한 관찰 시간 동안 핵심 지표가 허용 범위 안에 있고, 사용자 결과가 확인되며, 롤백 수단이 살아 있고, 새 공개 오류나 보안 노출이 없다는 뜻입니다. 승인 결정에는 지표 값과 관찰 시간을 함께 남깁니다. “문제 없음”보다 “10% 카나리 30분, 제출 성공률 99.1%, 중복 저장 0건, p95 680ms, 새 콘솔 오류 0건, 플래그 off 경로 확인”이 훨씬 좋은 기록입니다.

다음 단계

처음 도입한다면 가장 위험한 릴리스 하나만 고르세요. 결제, 권한, 질문 제출, 파일 업로드, 알림, 대량 작업처럼 사용자 영향이 큰 흐름이 좋습니다. 그 릴리스에 오류 예산 표를 붙이고, 배포 후 실제 숫자를 기록합니다. 다음에는 같은 형식으로 다른 릴리스에 적용합니다.

팀 단위로 확장할 때는 오류 예산 템플릿을 코드 리뷰와 배포 체크리스트에 연결합니다. AI에게 기능 구현만 시키지 말고 “배포 승인 표까지 작성하라”고 요구하세요. 시간이 지나면 팀은 배포를 덜 무서워하게 됩니다. 실패를 막을 수 있어서가 아니라, 실패를 작게 만들고 빠르게 되돌릴 수 있다는 확신이 생기기 때문입니다.

운영 루프를 팀에 정착시키는 방법

릴리스 노트가 아니라 승인 기록으로 남긴다

많은 팀이 배포 후 “무엇을 배포했다”만 기록합니다. 오류 예산 루프에서는 “무엇을 보고 승인했는가”가 더 중요합니다. 릴리스 노트에는 변경 요약, 영향 경로, 카나리 범위, 기준선, 실제 관찰값, 결정, 남은 위험을 한 화면에 남깁니다. 이렇게 하면 다음 장애 때 “그때 왜 통과시켰는지”를 추측하지 않아도 됩니다.

승인 기록은 AI에게도 좋은 학습 맥락이 됩니다. 다음 작업에서 에이전트에게 과거 승인 기록을 요약하게 하면, 팀이 어떤 지표를 중요하게 보는지 더 잘 반영합니다. 단, 원문 사용자 데이터나 내부 연결 정보는 기록에 넣지 않고 집계와 판단 근거만 남깁니다.

낮은 위험과 높은 위험을 분리한다

모든 배포에 같은 무게의 절차를 적용하면 루프가 오래가지 못합니다. 문구 수정, 카드 간격 조정, 내부 도움말 개선처럼 낮은 위험 변경은 짧은 스모크와 기본 지표로 충분할 수 있습니다. 반면 결제, 권한, 데이터 삭제, 개인정보, 대량 알림, 검색 랭킹, 외부 연동 재시도처럼 영향이 큰 변경은 사람 승인과 긴 관찰 시간이 필요합니다.

AI에게도 위험 등급을 먼저 분류하게 하세요. “이번 변경을 낮음, 중간, 높음으로 분류하고 이유와 필요한 승인 단계를 제안하라”고 지시하면 과도한 절차와 과소한 검증을 동시에 줄일 수 있습니다. 위험 등급이 높다고 해서 배포하지 말자는 뜻은 아닙니다. 더 작은 범위와 더 명확한 중단 기준으로 배포하자는 뜻입니다.

실패한 배포를 템플릿 개선으로 연결한다

중단이나 롤백이 발생하면 그 자체를 실패로 끝내지 말고 템플릿을 고칩니다. 놓친 지표가 있었는지, 기준선이 잘못됐는지, 관찰 시간이 짧았는지, 기능 플래그가 실제로 꺼지지 않았는지 확인합니다. 그리고 다음 AI 작업 지시서에 그 교훈을 한 줄로 추가합니다. 예를 들어 “모바일 느린 네트워크에서 성공 후 이동을 별도 스모크로 확인” 같은 문장이 반복 장애를 줄입니다.

이 방식은 AI 코딩의 강점과 잘 맞습니다. 사람은 실패에서 규칙을 뽑고, AI는 그 규칙을 다음 체크리스트와 테스트에 반영합니다. 시간이 지나면 배포 루프는 길어지는 것이 아니라 더 정확해집니다. 중요하지 않은 확인은 줄고, 실제로 사고를 막는 확인만 남습니다.

숫자가 없을 때는 대체 신호부터 시작한다

초기 서비스는 지표 체계가 완성되어 있지 않을 수 있습니다. 이때도 오류 예산 루프를 포기할 필요는 없습니다. 먼저 대표 경로 스모크, 브라우저 콘솔 오류, 핵심 제출 성공 여부, 관리자성 대시보드의 집계 수치, 사용자 문의 채널의 이상 신호처럼 손에 잡히는 대체 신호를 씁니다. 그리고 다음 작업의 목표를 “관측 이벤트 추가”로 잡아 숫자 기반 루프로 옮겨갑니다.

중요한 것은 완벽한 관측성 도구가 아니라 결정 가능한 기준입니다. 오늘은 수동 스모크와 작은 표로 시작하고, 다음 주에는 이벤트와 대시보드를 붙이고, 그 다음에는 카나리 자동 요약을 붙이면 됩니다. VIBE 코딩에서 좋은 자동화는 한 번에 완성되는 것이 아니라, 반복 배포를 견디며 점점 단단해집니다.