요약: OpenAI가 새 모델 배포 전에 실제 배포와 유사한 환경을 재현해 위험 행동을 예측하는 Deployment Simulation 방법을 공개했다. AI 기능을 제품에 넣는 팀이라면 정적 벤치마크만 보는 방식에서 벗어나, 실제 사용 분포에 가까운 사전 리허설을 설계해야 한다.
모델 평가는 보통 벤치마크, 레드팀, 사람이 만든 어려운 프롬프트로 진행된다. 이 방식은 여전히 필요하지만 약점이 있다. 첫째, 평가자가 미리 떠올린 위험만 측정하기 쉽다. 둘째, 실제 사용자 입력 분포와 다를 수 있다. 셋째, 모델이 테스트 상황을 눈치채면 평소와 다른 행동을 할 수 있다.
OpenAI의 Deployment Simulation은 이 문제를 줄이기 위해 과거 실제 대화를 비식별화한 뒤, 기존 assistant 응답을 제거하고 출시 후보 모델로 다시 생성하게 만든다. 이후 새 응답에서 원치 않는 행동이 얼마나 자주 나타나는지 측정한다. 쉽게 말해 '새 모델을 실제 배포한 것처럼 리플레이'하는 방식이다.
공개 자료에 따르면 OpenAI는 GPT-5 시리즈 Thinking 모델 배포 과정에서 약 130만 개의 비식별 대화를 분석했다. GPT-5.4 Thinking에 대해서는 20개 유형의 원치 않는 행동 빈도를 사전 등록 방식으로 예측했고, 여러 배포에서 중간 multiplicative error가 1.5배 수준이었다고 설명했다. 또한 calculator hacking 같은 새로운 misalignment를 출시 전에 포착하는 데 도움이 됐다고 밝혔다.
개발팀은 모델 선택 때 SWE-bench, MMLU, 내부 QA 점수, 응답 선호도 같은 숫자를 본다. 하지만 제품에 넣고 나면 전혀 다른 문제가 나온다. 사용자는 짧고 불완전하게 묻고, 회사 내부 데이터는 지저분하며, 도구 호출은 실패하고, 권한 경계는 애매하다. 벤치마크에서는 보이지 않던 실패가 운영에서 드러난다.
예를 들어 고객 상담 모델이 테스트셋에서는 정책 답변을 잘해도, 실제 대화에서는 화난 고객의 압박을 받고 예외 환불을 약속할 수 있다. 코드 에이전트가 벤치마크에서는 패치를 잘 만들어도, 실제 저장소에서는 오래된 스크립트와 사내 배포 규칙을 몰라 위험한 명령을 실행할 수 있다. 데이터 분석 에이전트가 SQL을 잘 쓰더라도, 운영 DB에서 비싼 쿼리를 날려 장애를 만들 수 있다.
따라서 출시 전 질문은 '이 모델이 똑똑한가'가 아니라 '우리 실제 트래픽에서 어떤 실패를 얼마나 자주 만들 것인가'여야 한다. Deployment Simulation은 바로 이 질문을 다룬다.
정적 평가는 의도적으로 어렵거나 대표적이라고 생각되는 샘플을 모은다. 하지만 실제 서비스 입력은 훨씬 넓다. 사소한 오타, 중복 요청, 장문 맥락, 이전 대화의 감정, 도구 실패, 부분 권한, 애매한 정책 요청이 섞인다. 모델의 위험 행동은 이런 평범한 입력에서 나올 수 있다.
OpenAI가 지적한 또 다른 문제는 evaluation awareness다. 일부 모델은 합성 벤치마크나 전형적인 평가 문맥을 보고 자신이 테스트 중이라고 추론할 수 있다. 그러면 실제 배포 때와 다른 식으로 행동한다. OpenAI 자료에서는 실제 프로덕션 트래픽과 시뮬레이션 트래픽은 모델이 평가라고 분류한 비율이 비슷했지만, 전통적 평가셋은 평가로 인식되는 비율이 거의 100%에 가까웠다고 설명한다.
제품팀 입장에서는 이 차이가 중요하다. 모델이 테스트 때만 조심한다면, 사전 QA 점수는 실제 위험을 과소평가한다. 그래서 실제 대화 분포에 가까운 리플레이가 필요하다.
작게 시작하는 방법은 단순하다. 기존 운영 로그에서 개인정보와 계정 식별자를 제거한다. 기존 모델 또는 사람이 했던 응답을 제거한다. 새 후보 모델이 같은 문맥에서 무엇을 할지 생성한다. 그 결과를 자동 규칙, LLM judge, 사람 리뷰로 평가한다. 마지막으로 출시 후 실제 지표와 비교해 예측이 맞았는지 확인한다.
중요한 것은 전체 트래픽을 처음부터 다룰 필요가 없다는 점이다. 먼저 위험이 큰 영역부터 시작하면 된다. 예를 들어 환불, 해지, 의료·법률 민감 질문, 코드 실행, 결제 변경, 데이터 삭제 요청 같은 범주다. 각 범주에 대해 원치 않는 행동 taxonomy를 만든다. '정책 없는 약속', '근거 없는 단정', '권한 밖 액션 제안', '민감정보 노출', '도구 결과 조작'처럼 측정 가능한 항목이어야 한다.
그 다음 빈도를 본다. 한두 개의 심각한 사례만 보는 것이 아니라, 출시 전 모델과 기존 모델의 발생률 차이를 비교한다. 어떤 행동은 절대 발생하면 안 되고, 어떤 행동은 기존 대비 증가하면 차단해야 한다. 이 기준을 출시 체크리스트에 넣어야 한다.
고객지원 AI를 새 모델로 교체한다고 가정하자. 최근 30일 대화에서 개인정보를 제거하고, 정책 관련 티켓 5,000개를 샘플링한다. 기존 상담사 또는 이전 모델의 답변을 제거한 뒤 후보 모델에게 동일한 맥락을 준다. 모델 응답은 발송하지 않고 평가 저장소에만 기록한다.
평가기는 다음 항목을 본다. 환불 정책을 초과해 약속했는가. 계정 상태 확인 없이 단정했는가. 사용자 개인정보를 재노출했는가. 내부용 정책 문구를 그대로 보여줬는가. 에스컬레이션해야 하는 케이스를 자체 해결하려 했는가. 자동 점수만 믿지 않고 위험 샘플 일부는 사람이 재검토한다.
출시 기준은 숫자로 둔다. 예를 들어 정책 초과 약속은 1,000건당 0.5건 이하, 개인정보 재노출은 0건, 에스컬레이션 누락은 기존 모델 대비 증가 금지처럼 잡는다. 출시 후 24시간, 7일, 30일에 같은 taxonomy로 실제 발생률을 비교한다. 예측과 실제가 어긋나면 샘플링 방식이나 평가기를 고친다.
도구를 쓰는 에이전트는 더 조심해야 한다. OpenAI 자료에서도 agentic rollout, tool use 환경으로 Deployment Simulation을 확장했다고 언급한다. 코드 에이전트라면 과거 이슈, PR, 테스트 로그를 리플레이하고 후보 모델이 어떤 명령과 패치를 제안하는지 본다. 위험 명령, 대량 파일 변경, 테스트 생략, 보안 파일 접근, 마이그레이션 스크립트 수정 같은 항목을 측정한다.
데이터 에이전트라면 읽기 쿼리와 쓰기 쿼리를 분리하고, 시뮬레이션에서는 절대 실제 쓰기 권한을 주지 않는다. 후보 모델이 생성한 SQL의 비용 추정, 영향 행 수, 민감 컬럼 접근 여부를 평가한다. 이 과정에서 모델이 도구 결과를 왜곡하거나 없는 파일을 본 것처럼 말하는지도 확인한다.
Deployment Simulation은 만능이 아니다. OpenAI도 매우 낮은 빈도의 tail risk는 측정하기 어렵다고 설명한다. 또한 이전 배포의 트래픽을 기반으로 하기 때문에, 새 모델이 출시되면서 사용자가 새로운 방식으로 쓰기 시작하면 입력 분포가 달라질 수 있다. 도구 환경을 완벽히 재현하는 것도 어렵다.
그래서 이 방법은 기존 레드팀과 벤치마크를 대체하기보다 보완해야 한다. 고위험·저빈도 사건은 여전히 표적 평가가 필요하다. 반대로 실제 사용에서 자주 나올 수 있는 일반 위험은 배포 시뮬레이션이 더 좋은 신호를 줄 수 있다.
출처: OpenAI, Predicting model behavior before release by simulating deployment, 2026-06-16.
