OpenAI Evals 읽기 전용 전환: 11월 30일 종료 전에 평가 자산 옮기기

평가 자산을 관리형 플랫폼에서 이식 가능한 구성으로 옮기는 과정을 표현한 생성형 개념 이미지다. 실제 제품 화면이 아니다.

OpenAI Evals로 회귀 테스트를 운영한다면 지금 확인할 것은 새 모델의 점수보다 평가 자산을 다시 실행할 수 있는지다. 공식 일정상 기존 eval은 2026년 10월 31일부터 읽기 전용이며, Evals 대시보드와 API는 11월 30일 종료 예정이다. 프롬프트·테스트 입력·채점 기준을 보존하고, 새 실행 환경에서 판정이 유지되는지 확인해야 한다.

이 글은 2026년 11월 2일 공식 문서 기준이다. 종료 발표 자체는 6월 3일에 나왔다. 이번에 달라진 점은 읽기 전용 전환일이 지났다는 것이다. 개별 계정의 실제 접근 상태를 시험한 결과는 아니다. OpenAI 공식 종료 일정

1. 무엇을 옮겨야 하나

OpenAI의 공식 이전 가이드는 Promptfoo를 권장하며, 기존 평가를 수동으로 재구성하는 절차를 설명한다. 별도의 Evals 내보내기 기능을 전제로 하지 않는다. 자동 변환이나 과거 실행 이력의 자동 이전이 보장된다고 이해하면 안 된다. 공식 이전 가이드

실무에서는 다음 항목을 하나의 평가 명세로 묶어 두는 편이 좋다. 아래는 이 글의 운영 제안이다.

입력: 테스트 ID, 입력 문장, 참고 문맥, 기대 답변.

실행 조건: 프롬프트 원문과 버전, 모델 식별자, 사용한 매개변수, 도구와 외부 데이터의 버전.

판정 조건: grader의 지침, 기준 답변, 임계값, 실패 처리 방식.

비교 기록: 접근 가능한 기존 출력과 점수, 실패 사례, 실행 시점.

민감한 실제 사용자 입력을 그대로 저장소에 넣지 않는다. 비식별 샘플을 만들고 원본 보관 위치의 접근 권한을 분리한다. API 키는 평가 파일에 복사하지 않는다.

특히 평균 점수만 남기면 이전 검증이 어려워진다. 어떤 사례가 왜 통과했는지 알아야 새 채점기가 다른 이유로 통과시키는 문제를 찾을 수 있다.

2. 가장 작은 평가부터 재구성한다

아래는 의도 분류기를 위한 새 예제다. 기존 Evals 파일을 자동 변환한 결과가 아니다. 테스트 입력과 기대 출력을 한 곳에서 읽을 수 있도록 작게 구성했다.

Promptfoo는 프롬프트, provider, 테스트, assertion을 구성 파일에 연결한다. 예제의 모델은 공식 구성 문서에 등장하는 식별자이며, 실제 이전에서는 기존 평가와 비교하려는 모델 및 계정의 지원 범위에 맞춰야 한다. 평가 환경을 옮기면서 모델까지 바꾸면 점수 차이의 원인을 분리하기 어렵다. Promptfoo 구성 문서

equals는 기대 문자열과 출력이 일치하는지 검사한다. 실제 서비스가 공백을 정리한 뒤 결과를 소비한다면 평가에서도 같은 전처리 정책을 명시해야 한다. 출력 형식 검사와 의미적 품질 검사를 섞어 놓지 않는 것이 좋다. Assertion 문서

3. 구성 검사와 모델 실행을 분리한다

Promptfoo가 설치된 환경에서 먼저 구성을 검사한다.

다음 명령은 모델을 호출해 새 평가를 실행한다. 사용할 provider의 기존 인증 설정과 예상 비용을 확인한 뒤 실행한다.

공식 가이드가 제시하는 실행 흐름이다. --no-cache 실행은 과거 OpenAI Evals 실행을 복원하는 작업이 아니라 새 결과를 만드는 작업이다. 이 글을 작성하면서 위 명령이나 유료 모델 호출을 실행하지 않았다. YAML은 공식 문서 형식에 맞춘 설명용 예제이며 실제 계정에서의 통과 결과를 주장하지 않는다. 공식 실행·검증 절차

4. 이전 성공은 통과율 하나로 판단하지 않는다

다음 순서로 확인하면 문제의 위치를 좁히기 쉽다. 이는 운영상 검증 제안이다.

테스트 수와 ID를 비교해 누락·중복을 찾는다.

같은 입력에 실제로 전달된 프롬프트와 도구 응답을 비교한다.

정답·명백한 오답·경계 사례를 넣어 채점 기준을 검사한다.

출력 형식 실패와 의미적 오답을 따로 집계한다.

새 기준선을 승인한 뒤 CI의 차단 조건을 적용한다.

LLM이 채점하는 평가라면 judge 모델과 지침도 평가 대상이다. OpenAI 가이드는 유사도 점수가 시스템 간 동일하지 않을 수 있으며, 재구성한 grader를 회귀 판단에 쓰기 전에 검증하라고 명시한다. 이전 전후의 숫자가 같다는 이유만으로 동등한 평가라고 결론 내리지 않는다. 이전 검증 주의사항

5. 종료 범위를 넓혀 해석하지 않는다

이번 일정은 OpenAI Evals 제품에 관한 것이다. 공식 문서는 eval 워크플로의 grader가 전환 범위에 포함된다고 설명하면서 fine-tuning 워크플로는 별도로 구분한다. 모든 모델 API나 모든 평가 방식이 함께 종료된다는 뜻은 아니다. 종료 범위

남은 기간에 할 일은 거대한 평가 체계를 새로 만드는 것이 아니다. 중요한 실패 사례부터 재실행 가능한 파일로 옮기고, 채점 의미가 유지되는지 확인하는 것이다. 서비스의 배포 판단에 쓰이는 평가라면 구성 파일 검증, 소규모 새 실행, 판정 검토를 각각 별도 완료 조건으로 두는 편이 안전하다.