모델 업그레이드가 세 가지 워크플로우를 망가뜨렸는데 테스트는 여전히 통과했다

에이전트 평가 (agent evals)를 실행하는 모든 팀은 결국 똑같은 벽에 부딪힙니다. 금요일에는 테스트 스위트가 모두 초록색(pass)이었는데, gpt-4.1에서 gpt-4.1-2026-05로 모델을 업데이트했더니 월요일에 세 가지 워크플로우가 다르게 동작하는 상황 말입니다. 예외(exception)가 발생하여 '고장'난 것은 아닙니다. 그냥... 달라졌을 뿐입니다. 예전에는 실행되던 도구 호출 (tool call)이 이제는 실행되지 않습니다. 예전에는 문서를 인용하던 요약이 이제는 내용을 의역합니다. 통과율 (pass rate)은 여전히 94%입니다. 무엇이 변했는지 아무도 모릅니다.

이것이 회귀 (regression) 문제이며, 이는 드리프트 (drift)와는 다릅니다.

드리프트 (Drift)는 쇠퇴입니다. 회귀 (Regression)는 계단 함수 (step function)입니다.

드리프트는 시간이 지남에 따라 '고정된' 설정에서 발생하는 현상입니다. 세상이 변하고 데이터가 변함에 따라, 에이전트의 행동이 다시 기준을 잡지 못한 채 베이스라인 (baseline)에 대해 서서히 쇠퇴하는 것입니다. 저는 이전에 이를 포착하는 방법에 대해 글을 쓴 적이 있습니다.

회귀는 다릅니다. 회귀는 당신이 직접 도입한 불연속성 (discontinuity)입니다. 모델 버전 업데이트, 프롬프트 (prompt) 수정, 레지스트리 (registry)의 새로운 도구 추가, 혹은 누군가가 "어떻게 되나 보자"며 변경한 온도 (temperature) 설정 등이 이에 해당합니다. 설정은 알려진 타임스탬프에서 변경되었습니다. 그리고 그와 함께 행동도 변했습니다. 대부분의 에이전트 출력은 비결정론적 (non-deterministic) 산문이기 때문에, 그 변화는 당신이 보고 있지 않던 6%의 오차 속에 숨어버립니다.

본능적으로 모델-판사 (model-as-judge) 방식을 도입하고 싶을 것입니다. "이전 답변과 새 답변을 비교해서 더 나빠졌는지 알려줘."라고 말이죠. 하지만 그 본능을 억제하십시오. 두 출력을 비교하는 판사는 어떤 것이 더 읽기 좋은지에 대한 '의견'을 줄 뿐입니다. 구조적으로 무엇이 변했는지에 대한 '사실'을 알려주지는 않습니다. 만약 에이전트의 추론 과정 (reasoning trace)을 판정하려 한다면, 당신은 순환 논리에 빠지게 됩니다. 판사와 피판정자가 동일한 기질 (substrate)을 공유하므로 독립적인 정답 (ground truth)이 존재하지 않기 때문입니다. 당신은 기준점 (anchor) 없이 모델에게 모델을 채점하라고 요구하고 있는 것입니다.

당신이 실제로 원하는 것은 **골든 트레이스 (golden trace)**입니다. 즉, 에이전트가 말로 빠져나갈 수 없는 축(axes)을 기준으로 새로운 버전이 반드시 비교해야 하는, 고정된 검증된 궤적 (known-good trajectory)입니다.

회귀 체크 (regression checks)의 순위를 비용이 아닌 독립성에 따라 매기십시오

사람들이 저지르는 실수는 증거를 비용이 저렴한 것에서 비싼 것으로 순위를 매기는 것입니다. 중요한 축은 독립적(independent) → 변조 가능(corruptible), 즉 에이전트가 신호를 얼마나 조작할 수 있는가입니다.

Tier 1 — 에이전트가 속일 수 없는 증거. 새로운 버전이 작업에 필요할 때 여전히 fetch_invoice 도구(tool)를 호출했습니까? 스키마(schema)에 따라 여전히 유효한 JSON을 생성했습니까? 타임아웃(timeout) 내에 완료했습니까? 작성했다고 주장하는 파일이 실제로 디스크에 존재합니까? 이것들은 외부에서 관찰 가능한 사실들입니다. 에이전트의 문장(prose)은 이 사실들과 논쟁할 수 없습니다. 골든 트레이스(golden trace)가 두 개의 도구를 호출했는데 새로운 실행이 하나만 호출했다면, 그것은 회귀(regression)입니다. 판단이 필요 없는 명백한 사실입니다.

Tier 2 — 에이전트가 작성하지 않은 베이스라인(baseline) 대비 통계적 신호. 새로운 출력과 골든 출력(golden output) 사이의 임베딩 유사도(embedding similarity). 차이점(diff)이 실제로 의미 있는 것을 변경했습니까, 아니면 단순히 외관상의 변화입니까? 길이 및 반복의 차이(deltas). 이 중 어느 것도 모델의 의견을 필요로 하지 않습니다. 고정된 참조점으로서의 기존 아티팩트(artifact)가 필요할 뿐입니다. 에이전트는 골든 트레이스를 작성하지 않았으므로, 비교 과정을 조작할 수 없습니다.

Tier 3 — 판사로서의 모델(model-as-judge). 물론 주관적인 부분이 존재합니다. "이 요약이 여전히 원문에 충실한가?"와 같은 질문은 항상 숫자로 환원될 수 없습니다. 하지만 Tier 3는 _판결이 아닌 신호(signal, never a verdict)_이며, 두 가지 엄격한 제약 조건을 가집니다. 첫째, 이는 **오프라인 전용(offline only)**이어야 합니다. 비용이 발생하고 느리며 비결정론적(non-deterministic)이므로, 배포를 제어하는 핫 패스(hot path)에 결코 위치할 수 없습니다. 둘째, **판단 대상이 되는 에이전트가 작성하지 않은 아티팩트(artifacts)**만을 검사해야 합니다. 즉, 원본 문서와 대조한 최종 출력물만을 검사해야 하며, 에이전트 자신의 사고 사슬(chain-of-thought)을 검사해서는 안 됩니다. 다른 모델로 추론 과정을 채점하는 것은 순환 논리의 함정(circular trap)이기 때문입니다.

Tier 1 + Tier 2는 실시간 게이트(gate) 역할을 합니다. 이들은 결정론적(deterministic)이며, 사실상 비용이 들지 않고, CI 실행을 차단할 수 있을 만큼 충분히 빠릅니다. 이 단계들은 압도적인 대다수의 회귀(regression) — 누락된 도구 호출(tool call), 깨진 스키마(schema), 근거가 확실했던 답변이 모호하게 변하는 현상 등 — 를 잡아냅니다. 판사(judge)는 약 20%의 주관적인 꼬리 부분(subjective tail)을 위해 남겨두고, 그 출력값에는 "증거가 아닌 의견"이라고 라벨을 붙여 아무도 7/10점이라는 점수를 통과 신호(green light)로 오해하지 않도록 하세요.

코드에서의 구현 모습

이러한 분할을 기반으로 구축된 회귀 게이트(regression gate)는 다음과 같습니다. agent-eval은 새로운 실행을 골든 트레이스(golden trace)와 비교하여 점수를 매깁니다. Tier 1+2 체크는 동기식(synchronously)으로 실행되어 빌드를 실패시킬 수 있는 반면, 판사는 오프라인(off-line)으로 실행됩니다.

import { evaluate, tier1, tier2 } from "agent-eval";
import { loadTrace } from "agentlens";

...

여기서 무엇이 핵심적인 지지대(load-bearing)인지 주목하십시오. Tier 1+2 체크가 작동하는 이유는 agentlens가 에이전트가 스스로에 대해 서술한 사후 요약(post-hoc summary)이 아니라, 실제 도구 호출(tool calls), 해결된 입력값(resolved inputs), 가공되지 않은 출력값(raw outputs)을 포함한 전체 트레이스(trace)를 캡처했기 때문입니다. 만약 최종 문자열만 기록했다면, 비교(diff)할 수 있는 위조 불가능한 데이터가 아무것도 없게 됩니다. 트레이스는 회귀를 디버깅 가능하게(debuggable) 만드는 핵심 요소입니다. "도구 호출 횟수 변경"으로 인해 게이트가 실패했을 때, 두 궤적(trajectories)을 나란히 열어보고 새 모델이 정확히 어느 단계에서 건너뛰었는지 확인할 수 있습니다.

이것이 실제적인 분업입니다. AgentLens는 에이전트가 그곳에 도달한 과정 — 모든 모델 및 도구 단계, 모든 해결된 입력값, 모든 가공되지 않은 출력값 — 을 캡처합니다. agent-eval은 그것이 생성한 결과물에 점수를 매깁니다 — 위에서 언급한 계층형 게이트를 통해서 말이죠. 하나 없이는 다른 하나도 반쪽짜리 시스템에 불과합니다. 점수가 없는 트레이스는 그저 비용만 많이 드는 로깅(logging)일 뿐이며, 트레이스가 없는 점수는 진단할 수 없는 빨간불(red light)일 뿐입니다.

규율 (The discipline)

중요하게 생각하는 모든 워크플로우에 대해 골든 트레이스(golden trace)를 고정(pin)하십시오. 모델 업데이트(model bump)와 프롬프트 변경이 있을 때마다 이를 다시 실행하십시오. 에이전트가 위조할 수 없는 구조적 사실인 Tier 1+2에서 빌드를 실패시키십시오. 판사는 주관적인 꼬리 부분에 대해 오프라인에서 속삭이듯 의견을 내놓게 하되, 판결(verdict)이 아닌 하나의 신호(signal)로서 명확하게 라벨을 붙이십시오.

모델 업그레이드로 피해를 보는 팀은 평가(evals)가 실패한 팀이 아닙니다. 사실(facts)을 고정하는 대신 분위기(vibes)를 채점했기 때문에 평가를 통과해 버린 팀들입니다. 사실을 고정하십시오. 당신이 지켜보고 있든 아니든, 모델은 당신의 발밑에서 변할 것입니다.