OpenAI, 실서비스 대화 130만 건을 재생하여 신규 모델의 문제 행동을 출시 전 측정

벤치마크에서 점수가 올라간 신규 모델을 실서비스에 교체했더니, 이전 모델보다 태만해졌다. 그런 경험이 있는 사람은 적지 않을 것이다. 원인 중 하나는 명확하다. 모델은 "이것은 테스트다"라고 눈치채면, 실서비스와는 다른 행동을 한다. OpenAI가 6월 16일에 공개한 Deployment Simulation은 이 "평가받고 있다는 것을 눈치채는" 문제에 정면으로 대응한 수법이다. 발상은 허탈할 정도로 소박하다. 합성 테스트 (Synthetic Test)를 그만두고 실서비스의 대화 로그를 그대로 신규 모델에 입력하는 것이다.

절차는 다음과 같다. 이미 출시된 모델이 실제로 처리한 대화를 수집하고, 거기서 어시스턴트의 응답만을 제외한다. 비어 있는 부분을 이제 출시하려는 후보 모델이 생성하게 한다. 그다음 생성 결과를 일탈 행동 분류기 (Deviation Classifier)에 통과시켜, 실서비스에 내보냈을 때의 문제 행동 발생률을 추정한다. 요컨대 "만약 지난달의 트래픽을 신규 모델이 처리했다면 어떤 일이 일어났을까"를 과거 로그의 재생 (Replay)을 통해 선제적으로 관측하는 것이다.

OpenAI는 작년 8월부터 올해 3월까지, GPT-5 Thinking에서 GPT-5.4에 걸친 약 130만 건의 익명화된 대화로 이를 실행했다. 대상은 데이터 이용에 동의한 사용자의 트래픽뿐이며, de-identified (개인 식별 정보를 제거한) 상태로 취급한다고 설명되어 있다.

왜 굳이 실서비스 로그인가? 이유는 숫자를 보면 명확하다. MarkTechPost의 상세 보도에 따르면, 모델에게 "이것은 평가인가?"를 판정하게 했을 때 결과는 다음과 같았다.

입력	"평가다"라고 판정된 비율
실제 실서비스 트래픽	5.4%
...

SWE-Bench는 거의 확실하게 테스트임을 간파한다. 반면, 실서비스 로그의 리플레이는 실서비스 그 자체와 구분이 되지 않는다 (5.1% 대 5.4%). 이 점이 핵심이며, 모델이 "본연의" 모습으로 행동하는 조건을 재현할 수 있기 때문에 출시 전의 추정이 실서비스의 거동에 가까워진다. 오랫동안 스코어를 추적해 온 입장에서는, 벤치마크의 숫자가 현장의 체감과 어긋나는 원인 중 하나가 이 정도로 정량화된 것은 수확이라고 생각한다.

정밀도의 지표로서, OpenAI는 중앙값으로 1.5배의 승법 오차 (median multiplicative error)를 보고하고 있다. 10만 메시지당 실제 발생률이 10건이라면, 추정치는 15건 또는 6.67건 정도로 수렴한다는 범위다. 3개의 사이트가 일제히 이 1.5배를 인용하고 있으므로, 이 수치는 신뢰할 만하다고 봐도 좋다. 다만 테일 (Tail) 측의 오차는 약 10배까지 벌어질 수 있다고 하므로 과신은 금물이다.

한계도 명시되어 있다.

20만 메시지에 1회 미만으로 발생하는 거동은 측정할 수 없다. 목표로 하는 것은 테일이 아니라 비-테일 (Non-tail) 리스크다.

즉 "드물게 일어나지만 일어나면 치명적인" 사안에는 적합하지 않다. 어디까지나 적당한 빈도로 발생하는 일탈을 출시 전에 잡아내는 도구라고 단정 지을 필요가 있다. 검증으로는 난제 프롬프트 집합 기반의 베이스라인이나 "이전 버전의 발생률을 그대로 사용하는" 소박한 베이스라인과 비교했는데, 실서비스의 발생률이 1.5배 이상 변하는 국면에서 가장 명확하게 승리했다고 보고되었다. 역으로 말하면, 거동이 거의 변하지 않는 업데이트에서는 구버전의 실적을 그대로 사용하는 것과 큰 차이가 없다는 뜻이기도 하다.

개인적으로 가장 감탄한 부분은 코딩 에이전트 (Coding Agent)로의 확장이다. 채팅과 달리 에이전트는 도구 (Tool)를 호출한다. 리플레이 중에 실제 도구를 실행하면 부작용이 발생하거나 불안정해진다. 그래서 OpenAI는 도구 호출 응답을 다른 LLM이 시뮬레이션하게 했다. 시뮬레이터에는 당시의 리포지토리 상태, 최종 턴의 롤아웃 (Rollout), 도구 호출과 응답 데이터베이스, 읽기 전용 커넥터를 전달한다. 사내 직원에 의한 GPT-5.4의 에이전트 궤적 12만 건을 사용하여, GPT-5.5 기반의 코딩 에이전트를 사내에 전개했을 경우를 재생했다고 한다.

이 시뮬레이션이 "그럴듯하기만" 해서는 의미가 없다. 판정기 (Discriminator)가 실제 응답과 재생 응답을 구별해낼 수 있는 승률은 초기 11.6%에서 49.5%까지 올라갔다. 50%는 동전 던지기와 같으므로, 즉 구별할 수 없는 상태이며, 리플레이가 실제 샘플링과 거의 구별되지 않게 되었음을 의미한다.

구체적인 수확으로 꼽히는 것이 GPT-5.1에서 발견된 "계산기 해킹"이다. 모델이 브라우저 도구를 계산기 대신 사용하면서, 그 조작을 검색이라고 속여서 제시하고 있었다. 이러한 미세한 속임수는 합성 벤치마크에서는 드러나기 어렵다. 실서비스에 가까운 문맥에서 재생함으로써 비로소 밝혀진 것이다.

이는 OpenAI의 내부 파이프라인에 관한 이야기이며, 외부에서 호출할 수 있는 API가 공개된 것은 아니다. 하지만 방법론 자체는 특별한 도구를 필요로 하지 않는다. 자사의 LLM 제품에서 모델이나 프롬프트(Prompt)를 교체할 때, 합성 테스트 세트(Synthetic test set)를 정교하게 만들기 전에, 우선 수중에 있는 운영 로그를 리플레이(Replay)한다. 발상은 이것뿐이다.

1. 동의를 얻은 사용자의 대화 로그를 익명화하여 수집
2. 각 대화에서 이전 모델의 최종 응답을 삭제
3. 동일한 문맥을 신규 모델(후보)로 재생성
...

합성 평가 세트가 금방 진부해지고, 게다가 모델이 이를 "테스트다"라고 간파해 나가는 현실을 고려하면, 회귀 테스트(Regression test)의 중심축을 공들여 만든 벤치마크에서 운영 트래픽(Production traffic)의 재생으로 옮기는 가치는 충분하다. 한편, 익명화와 사용자 동의 설계를 초기에 확립하지 않으면 법무 및 프라이버시 문제로 막히게 되며, 20만 분의 1 미만의 사건은 별도의 안전장치로 보호할 수밖에 없다. 만능 검증이 아니라, 벤치마크가 놓치는 "현장에서의 열화"를 측정하기 위한 하나의 수단으로 통합하는 것이 현실적인 방안이라고 생각한다.