AI 기능을 붙인 팀이 늘수록, 변경 실패의 원인은 모델 자체보다 검증 방식의 빈틈에서 더 자주 나옵니다. 벤치마크에서는 3점 좋아졌는데 실제 운영에서는 툴 호출이 더 자주 실패하거나, 프롬프트를 조금 바꿨더니 장문 설명은 좋아졌지만 고위험 작업에서 승인 경계를 넘겨버리는 식입니다. 그래서 최근에는 모델 점수표보다 실제 작업을 재생해 보는 검증 계층이 더 중요해지고 있습니다. 저는 이 흐름을 Synthetic Replay + Eval Gate로 보는 편이 가장 정확하다고 생각합니다.

핵심은 단순합니다. 새 모델, 새 프롬프트, 새 툴 스키마를 바로 production에 넣지 않고, 실제 업무에서 나온 작업 패킷을 먼저 재생합니다. 이 패킷에는 입력 텍스트만이 아니라 컨텍스트 조건, 허용된 툴, 기대 결과, 실패 분류, 비용 상한이 같이 붙습니다. 그 결과를 Deterministic Replay + Flight Recorder, Test Evidence Pipeline, Change Intelligence Control Plane, Policy Shadow Rollout과 연결하면, 변경 승인 기준이 “느낌상 괜찮아 보인다"에서 벗어나기 시작합니다.

이제 중요한 것은 평균 점수가 아니라 어떤 작업군에서 무엇이 더 좋아졌고 무엇이 더 위험해졌는가입니다. 개발 조직이 에이전트를 운영 체계 안으로 넣을수록, 이 질문은 선택이 아니라 필수가 됩니다.

이 글에서 얻는 것

  • Synthetic Replay가 왜 단순 프롬프트 회귀 테스트보다 한 단계 더 운영 친화적인지 설명할 수 있습니다.
  • Eval Gate를 설계할 때 어떤 지표를 최소 기준으로 삼아야 하는지 숫자 중심으로 가져갈 수 있습니다.
  • offline replay와 shadow traffic을 어떻게 역할 분담시키면 좋은지 정리할 수 있습니다.
  • 모델, 프롬프트, 툴, 정책 변경을 하나의 승인 구조로 묶는 실무 기준을 잡을 수 있습니다.

핵심 개념/이슈

1) 지금 병목은 모델 품질보다 “변경이 실제 업무를 망치지 않는지” 검증하는 능력이다

많은 팀이 아직도 AI 변경을 아래 둘 중 하나로 판단합니다.

  • 공개 벤치마크 점수
  • 내부 데모 몇 개에서의 체감 품질

문제는 이 둘이 실제 운영 실패를 잘 못 잡는다는 점입니다. 툴 호출 순서가 달라져 비용만 늘어날 수도 있고, JSON 형식은 맞는데 사람 승인 경계가 흐려질 수도 있고, 긴 문맥에서는 좋아졌지만 짧은 작업의 응답 지연이 급증할 수도 있습니다. 결국 운영에서는 “모델이 똑똑한가"보다 내 작업을 안정적으로 끝내는가가 더 중요합니다.

그래서 Synthetic Replay는 작업 단위로 봅니다. 예를 들어 아래처럼 쪼갭니다.

  • 코드 수정 제안
  • 운영 런북 요약
  • 외부 전송 초안 작성
  • 위험 작업 승격 판단
  • 툴 조합 호출이 필요한 다단계 작업

이 작업군별로 pass/fail 조건이 다르기 때문에, 평균 점수 하나로 배포 결정을 내리는 것은 점점 위험해집니다.

2) Replay packet은 프롬프트 텍스트가 아니라 “실행 문맥 묶음"이어야 한다

Synthetic Replay가 의미 있으려면 입력 텍스트만 저장해서는 부족합니다. 실제 운영에서 결과를 바꾸는 것은 보통 아래 정보들입니다.

  • 시스템/개발자 지침과 현재 정책 버전
  • 허용된 툴 목록과 스키마 버전
  • 첨부 문서, 요약 메모, 최근 대화 맥락
  • 작업 위험도와 기대 결과 형식
  • latency budget, cost budget, escalation 조건

즉 replay packet은 사실상 작업 계약서에 가깝습니다. 이 구조는 Context Contract Registry와 잘 맞습니다. 입력 계약이 정리돼 있어야 같은 작업을 다음 주, 다음 모델, 다음 런타임에서도 비슷한 조건으로 재생할 수 있기 때문입니다.

실무적으로는 최소 아래 필드를 두는 편이 좋습니다.

  • task_class
  • risk_level
  • input_bundle_ref
  • allowed_tools
  • expected_outcome
  • must_not_do
  • latency_budget_ms
  • cost_budget_usd
  • review_label

이 정도만 있어도 “응답이 괜찮아 보였다"를 넘어서, 실제 운영 기준으로 합격 여부를 비교할 수 있습니다.

3) 좋은 Eval Gate는 pass rate만 보지 않고 high-risk miss와 cost-per-success를 같이 본다

에이전트 변경 검증에서 흔한 함정은 통과율 하나만 보는 것입니다. 하지만 pass rate가 3% 올랐어도 비용이 두 배가 되거나, 고위험 작업에서 한 번 더 잘못된 허용을 내보냈다면 운영적으로는 나빠진 변경일 수 있습니다.

그래서 최소한 아래 지표를 같이 보는 편이 좋습니다.

  • task_pass_rate: 작업 완료 기준 통과율
  • high_risk_miss_rate: 막았어야 할 고위험 실패를 놓친 비율
  • tool_success_rate: 필요한 툴 체인을 끝까지 성공시킨 비율
  • cost_per_success: 성공 1건당 평균 비용
  • p95_latency: 작업 완료 기준 지연시간
  • rollback_readiness: 되돌리기 또는 shadow 복귀 준비 시간

권장 출발 기준은 아래 정도가 현실적입니다.

  • 일반 작업군 pass rate는 기존 대비 하락 금지, 가능하면 +2% 이상 개선
  • high-risk miss rate는 1% 미만
  • tool success rate는 95% 이상
  • p95 latency 증가는 기존 대비 15% 이내
  • cost-per-success 증가는 20% 이내, 단 high-risk miss 개선이 크면 예외 검토 가능
  • rollback 또는 이전 버전 복귀 준비 시간은 15분 이내

핵심은 더 좋아진 면만 보지 않고, 무엇을 대가로 얻은 개선인지를 같이 보는 것입니다.

4) Offline replay와 shadow traffic은 경쟁재가 아니라 역할이 다르다

Offline replay의 장점은 빠르고 반복 가능하다는 것입니다. 같은 작업 묶음을 여러 모델, 여러 프롬프트, 여러 정책 버전으로 짧은 시간 안에 비교할 수 있습니다. 회귀 검증과 후보 압축에 아주 강합니다. 반면 한계도 분명합니다. 실제 운영의 분포 변화, 신규 예외, 최신 문맥 구조는 완전히 재현되지 않을 수 있습니다.

반대로 shadow traffic은 현실 적합성이 높습니다. 실제 사용자 작업이나 실제 운영 입력을 기반으로 새 정책이 어떤 판정을 내릴지 볼 수 있습니다. 하지만 느리고, 수집 비용이 크며, 즉시 반복 실험에는 불리합니다.

그래서 잘하는 팀은 보통 이렇게 나눕니다.

  1. Offline replay로 후보 3개를 1개로 줄임
  2. Shadow traffic으로 실제 분포에서 missed high-risk와 friction 확인
  3. 기준 충족 시 partial rollout 진행

이 흐름은 Policy Shadow Rollout과 자연스럽게 이어집니다. replay가 빠른 회귀 검증이라면, shadow는 현실 적합성 검증입니다. 둘 중 하나만으로는 부족합니다.

5) 평가 결과는 “증거 묶음"으로 남아야 배포 승인에 쓸 수 있다

Synthetic Replay가 진짜 운영 도구가 되려면 결과가 표 몇 개로 끝나면 안 됩니다. 어떤 변경이 어떤 packet에서 실패했고, 그 실패가 단순 formatting 문제인지, tool sequencing 문제인지, 정책 위반인지, latency budget 초과인지까지 묶여야 합니다. 이때 중요한 것이 Execution Receipt와 Test Evidence Pipeline입니다.

실무에서는 아래 묶음이 있으면 강합니다.

  • 변경 ID와 관련 모델/프롬프트/툴 버전
  • replay packet 샘플과 작업군 분포
  • pass/fail scorecard
  • high-risk miss 사례 3~5개
  • 비용/지연 변화
  • rollback 경로와 owner

이 묶음이 있어야 배포 회의에서 “왜 이 변경을 올리는지"를 짧게 설명할 수 있습니다. 결국 Eval Gate는 평가 시스템이 아니라 승인 인터페이스이기도 합니다.

6) 운영 리뷰는 주간 1장짜리 gate scorecard로 닫히는 편이 좋다

데이터가 많아질수록 회의가 길어지고 책임은 흐려지기 쉽습니다. 한 팀은 pass rate만 보여 주고, 다른 팀은 latency만 강조하고, 정책 담당자는 miss rate만 들고 오는 식입니다. 이렇게 되면 승인 속도는 느려지고, 실패한 변경의 원인도 흐려집니다.

그래서 저는 주간 리뷰를 아래 6줄짜리 scorecard로 닫는 편이 가장 실전적이라고 봅니다.

  • 변경 ID와 대상 작업군
  • pass rate, tool success rate
  • high-risk miss rate, false escalation rate
  • p95 latency, cost-per-success
  • shadow 결과와 reviewer override 비율
  • rollback readiness, owner sign-off

이 6줄이 한 화면에 있으면 “품질은 올랐지만 비용이 너무 비싼 변경”, “평균은 좋아졌지만 고위험 실패를 늘린 변경”, “지표는 좋은데 rollback 준비가 안 된 변경"을 바로 분리할 수 있습니다. 결국 좋은 Eval Gate는 더 많은 표를 만드는 일이 아니라, 승인과 보류를 빠르게 나누는 기준선을 만드는 일입니다.

실무 적용

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

실무 우선순위는 보통 아래 순서가 안전합니다.

1순위, 고위험 작업군 replay packet 표준화

  • 외부 전송, 코드 수정, 권한 변경, 배포 관련 작업부터 시작
  • 전체 작업의 100%를 다루기보다 위험도가 큰 상위 20% 작업군부터 표준화

2순위, gate 기준선 문서화

  • pass rate 하락 금지
  • high-risk miss rate 1% 미만
  • p95 latency 증가 15% 이내
  • cost-per-success 증가 20% 이내
  • rollback readiness 15분 이내

3순위, offline과 shadow 분리 운영

  • offline replay는 후보 압축
  • shadow는 현실 검증
  • 둘의 점수가 엇갈리면 shadow 결과를 더 보수적으로 해석

4순위, 승인 단위를 change set으로 묶기

  • 모델 교체, 프롬프트 수정, 툴 스키마 수정, 정책 수정이 함께 들어가면 개별 최적화보다 change set 단위로 승인

2) 4주 도입 순서

1주차: 상위 고위험 작업 30~50개를 replay packet으로 정리
처음부터 500개를 모으려 하지 않는 편이 낫습니다. 분포가 좋은 샘플보다 운영상 아픈 샘플이 먼저입니다.

2주차: 기본 scorecard와 실패 taxonomy 정의
format fail, tool fail, policy miss, latency fail, cost fail 정도만 나눠도 의사결정 속도가 빨라집니다.

3주차: 새 모델 또는 프롬프트 변경 1건에 gate 적용
한 번에 여러 변경을 섞지 말고, 비교 가능한 change set부터 적용합니다.

4주차: shadow traffic 연결과 partial rollout 훈련
offline 결과가 좋은 후보만 shadow로 올리고, 15분 이내 rollback 훈련을 같이 해 봅니다.

3) 운영 테이블 예시

작업군최소 replay 수핵심 지표보수 기준
외부 전송 초안30+policy miss, reviewer overridemiss 1% 미만
코드 수정 제안50+tool success, diff validitysuccess 95% 이상
운영 런북 요약30+factual pass, latencylatency 증가 15% 이내
위험 작업 승격20+false escalation, missed escalation두 지표 모두 3% 미만

이 표의 핵심은 모든 작업군을 같은 pass rate로 재단하지 않는 것입니다. 작업군마다 실패 비용이 다르기 때문입니다.

4) change approval 흐름 예시

  1. 변경 제안 생성
  2. replay packet 50개 내외로 offline 비교
  3. scorecard 통과 시 shadow traffic 적용
  4. shadow에서 high-risk miss와 friction 확인
  5. partial rollout
  6. 1주 안정 후 full rollout

이 흐름이 자리 잡으면 “AI 변경은 늘 불안하다"는 감각이 꽤 줄어듭니다. 이유는 단순합니다. 더 똑똑해져서가 아니라, 변경을 다루는 방법이 소프트웨어 배포에 가까워지기 때문입니다.

트레이드오프/주의점

첫째, replay packet 품질이 낮으면 gate도 왜곡됩니다. 입력 계약이 엉성하면 좋은 모델도 나쁘게 보이고, 나쁜 변경도 통과할 수 있습니다.

둘째, offline replay만 믿으면 실제 분포 변화를 놓칠 수 있습니다. 운영 입력은 늘 움직이기 때문에 shadow가 꼭 필요합니다.

셋째, gate를 너무 엄격하게 잡으면 배포 속도가 과도하게 느려질 수 있습니다. 그래서 작업군별 위험도에 따라 강도를 다르게 두는 편이 맞습니다.

넷째, 평가자가 한 모델 또는 한 judge에 과도하게 의존하면 편향이 생길 수 있습니다. 최소한 고위험 작업은 사람 리뷰나 다중 기준을 섞는 것이 안전합니다.

다섯째, rollback readiness가 없는 gate는 반쪽입니다. 잘못 통과한 변경을 빨리 내릴 수 있어야 진짜 운영 도구가 됩니다.

체크리스트 또는 연습

체크리스트

  • 고위험 작업군에 대한 replay packet 스키마가 있다.
  • pass rate 외에 high-risk miss, tool success, cost-per-success를 같이 본다.
  • offline replay와 shadow traffic의 역할이 문서화되어 있다.
  • 변경 ID 기준으로 모델, 프롬프트, 툴, 정책 버전을 함께 기록한다.
  • 15분 이내 rollback 또는 shadow 복귀가 가능하다.
  • 주간 gate scorecard를 owner가 검토하고 sign-off 한다.

연습 과제

  1. 최근 진행한 AI 변경 하나를 골라, 벤치마크 점수 대신 작업군별 pass rate / high-risk miss / latency / cost로 다시 평가해 보세요. 어떤 면이 가려져 있었는지 바로 보일 가능성이 큽니다.
  2. 외부 전송 또는 코드 수정처럼 실패 비용이 큰 작업군 20개를 골라 replay packet 초안을 만들어 보세요. 입력 텍스트만으로는 재현되지 않는 필드가 금방 드러납니다.
  3. 현재 운영 중인 shadow 정책 하나를 골라, offline replay 결과와 shadow 결과가 어긋난 사례를 3개만 모아 보세요. 어떤 신호를 gate에 추가해야 할지 감이 잡힙니다.

관련 글