OpenAI Evals 전환 대응: 2026년 종료 일정 전에 평가 체계 정리하기

LLM 애플리케이션을 운영한다면 “프롬프트가 좋아 보인다”는 말만으로는 부족합니다. 모델을 바꾸거나 프롬프트를 수정할 때 기존 품질이 유지되는지 확인해야 합니다. 그래서 eval, 즉 평가 체계가 필요합니다. 그런데 OpenAI 문서에는 중요한 일정이 명시돼 있습니다. 기존 Evals platform은 전환 기간을 거쳐 2026년 10월 31일 read-only가 되고, 2026년 11월 30일 종료될 예정입니다. 새로 평가 체계를 만들거나 기존 eval을 운영 중이라면 지금 구조를 정리해야 합니다.

이 글은 “OpenAI Evals를 계속 써도 되는가”, “Datasets로 넘어가야 하는가”, “LLM 서비스에서 평가 데이터를 어떻게 설계해야 하는가”에 대한 실무 가이드입니다. 공식 문서 기준 Evals API는 task description, test input, testing criteria, run, result analysis로 구성됩니다. 하지만 종료 일정이 있는 만큼, 단순 사용법보다 마이그레이션 가능한 평가 체계를 만드는 게 더 중요합니다.

eval이 필요한 순간은 언제인가

LLM 기능을 처음 만들 때는 프롬프트 하나로 충분해 보입니다. 샘플 몇 개를 넣어보고 결과가 괜찮으면 배포합니다. 문제는 배포 후에 생깁니다.

• 모델 버전을 올렸더니 말투가 바뀐다.
• 프롬프트에 한 줄 추가했더니 분류 정확도가 떨어진다.
• 안전 정책 응답이 늘어 conversion이 줄어든다.
• JSON 필드 누락이 특정 입력에서만 발생한다.
• 한국어와 영어 입력의 품질 차이가 커진다.
• 긴 문서에서는 잘 되지만 짧은 문장에서는 오분류가 늘어난다.

이런 문제는 눈으로 몇 개 보는 방식으로 잡기 어렵습니다. eval은 “대표 입력 세트와 판정 기준”을 만들어 변경 전후를 비교하는 장치입니다. 코드 테스트와 비슷하지만, 정답이 명확한 경우와 주관 평가가 섞인다는 점이 다릅니다.

OpenAI Evals API의 기본 구조

OpenAI 문서의 예시는 IT support ticket을 Hardware, Software, Other로 분류하는 작업입니다. eval을 만들 때 핵심 재료는 두 가지입니다.

첫째, data_source_config입니다. 평가 데이터가 어떤 필드를 갖는지 정의합니다. 예를 들어 ticket_text, correct_label이 있습니다.

둘째, testing_criteria입니다. 모델 출력이 맞는지 판단하는 기준입니다. 예시에서는 string_check로 모델 출력이 human label과 같은지 확인합니다.

그 다음 JSONL 파일로 테스트 데이터를 업로드하고, eval run을 생성합니다. run은 각 샘플에 대해 모델을 호출하고, criteria별 pass/fail을 계산합니다. 결과에는 total, passed, failed, errored, model usage 같은 정보가 포함됩니다.

이 구조 자체는 간단합니다. 중요한 건 “평가 데이터를 어떻게 만들고, 어떤 기준으로 실패를 정의하느냐”입니다.

2026년 종료 일정이 의미하는 것

OpenAI는 Evals platform이 read-only 전환 후 종료될 예정이라고 안내하고, 새로 평가를 시작하는 사용자에게 Datasets를 고려하라고 말합니다. 따라서 지금 해야 할 일은 두 가지입니다.

첫째, 기존 eval을 export 가능한 형태로 정리해야 합니다. 플랫폼 UI 안에만 있는 평가 데이터는 위험합니다. JSONL, CSV, Git 저장소, 내부 DB 중 하나로 원본을 보관해야 합니다.

둘째, 평가 로직을 특정 플랫폼에 과하게 묶지 않아야 합니다. OpenAI Evals API를 쓰더라도 데이터 스키마, 정답 라벨, grader 기준, 모델 호출 prompt는 별도 파일로 관리하는 게 좋습니다. 그래야 Datasets나 사내 평가 runner로 옮길 수 있습니다.

평가 체계의 소유권은 플랫폼이 아니라 제품팀에 있어야 합니다. 플랫폼은 실행 도구입니다.

평가 데이터셋을 설계하는 법

좋은 eval은 많은 데이터보다 대표성이 중요합니다. 처음부터 5,000개를 만들 필요는 없습니다. 오히려 50~200개의 잘 고른 샘플이 프롬프트 회귀를 더 빨리 잡습니다.

데이터셋은 최소한 다음 그룹을 포함해야 합니다.

• 정상 입력: 가장 흔한 사용자 요청.
• 경계 입력: 짧거나 애매한 요청.
• 긴 입력: 문서, 로그, 대화 전체.
• 악성 또는 정책 위반 입력: 거절해야 하는 요청.
• 다국어 입력: 한국어, 영어, 혼합 문장.
• 형식 깨짐 입력: 오타, 줄바꿈, 누락 필드.
• 비즈니스 중요 입력: 결제, 인증, 보안, 의료, 법률 등.

각 샘플에는 정답만 넣지 말고 왜 중요한지도 남기는 게 좋습니다. 예를 들어 case_type, risk_level, source, expected_behavior를 같이 저장하면 나중에 실패 분석이 쉬워집니다.

grader 기준을 단순하게 시작하기

평가 기준은 처음부터 복잡하게 만들 필요가 없습니다. 분류 작업이면 exact match가 좋습니다. 추출 작업이면 필수 필드 일치율을 봅니다. 요약이나 답변 품질처럼 주관성이 있는 작업은 rubric 기반 평가가 필요하지만, 이때도 기준을 작게 나눠야 합니다.

예를 들어 고객 문의 요약을 평가한다면 하나의 “좋음/나쁨” 점수보다 다음처럼 나눕니다.

• 핵심 요청을 포함했는가.
• 금액, 날짜, 상품명 같은 사실을 틀리지 않았는가.
• 상담원이 다음 액션을 알 수 있는가.
• 개인정보를 불필요하게 노출하지 않았는가.
• 3문장 이하로 제한을 지켰는가.

이렇게 나누면 실패 원인이 보입니다. 단일 점수는 개선 방향을 숨깁니다.

eval을 CI와 배포 과정에 넣는 방법

LLM eval은 매 요청마다 돌리는 것이 아니라 변경 시점에 돌리는 게 일반적입니다. 다음 이벤트에서 실행하면 좋습니다.

• 프롬프트 변경 PR.
• 모델 버전 변경.
• retrieval chunking 전략 변경.
• system instruction 변경.
• structured output schema 변경.
• safety policy 또는 guardrail 변경.

초기에는 전체 eval을 매번 돌리지 않아도 됩니다. smoke eval과 full eval을 나누세요.

Smoke eval은 20~30개 핵심 샘플로 빠르게 돌립니다. PR마다 실행할 수 있습니다. Full eval은 200개 이상 샘플로 nightly나 배포 전 실행합니다. 비용이 부담되면 모델 후보별 비교는 Batch API나 비동기 큐로 처리합니다.

결과 기준도 명확해야 합니다.

• 핵심 케이스 실패 0개.
• 전체 pass rate 95% 이상.
• high risk 그룹은 98% 이상.
• JSON 파싱 실패 0개.
• 평균 비용이 이전 버전 대비 20% 이상 증가하면 리뷰.

숫자는 제품별로 다르지만, 기준이 없으면 eval 결과가 보고서로만 남습니다.

기존 Evals에서 Datasets로 옮길 때 정리할 항목

종료 일정이 있는 플랫폼을 쓰고 있다면 아래 항목을 먼저 정리하세요.

1. eval 이름과 목적.
2. 입력 스키마.
3. 샘플 데이터 원본.
4. 정답 라벨 또는 기대 출력.
5. grader 기준.
6. 사용 모델과 파라미터.
7. 프롬프트 템플릿.
8. 최근 3개월 run 결과.
9. 실패 샘플 목록.
10. 제품 배포와 연결된 gate 기준.

이 목록이 있으면 OpenAI Datasets, 자체 runner, 다른 vendor 평가 도구로 옮기는 일이 쉬워집니다. 반대로 이 정보가 UI에 흩어져 있으면 종료 직전에 급하게 옮기느라 평가 신뢰도가 깨집니다.

운영팀이 자주 하는 실수

LLM 평가에서 자주 보는 실수는 네 가지입니다.

첫째, 성공 사례만 eval에 넣습니다. 데모에서 잘 된 샘플은 평가 가치가 낮습니다. 실패했거나 애매했던 샘플을 모아야 회귀를 잡습니다.

둘째, 평가 데이터와 학습 데이터를 섞습니다. fine-tuning이나 prompt few-shot에 쓴 예시는 eval holdout과 분리해야 합니다.

셋째, 모델 출력만 보고 비용과 지연시간을 안 봅니다. 실서비스에서는 품질, 비용, latency가 같이 기준입니다.

넷째, 사람이 고친 결과를 eval에 반영하지 않습니다. 운영 중 상담원이나 관리자가 수정한 데이터는 좋은 eval 후보입니다. 단, 개인정보 제거와 라벨 검수는 필요합니다.

전환 대응 체크리스트

OpenAI Evals 종료 일정 전에 할 일을 정리하면 다음과 같습니다.

1. 기존 eval 데이터와 criteria를 JSONL 또는 Git 저장소로 export한다.
2. 새 eval은 플랫폼 UI가 아니라 파일 기반 원본을 먼저 만든다.
3. OpenAI Datasets 또는 자체 runner로 옮길 수 있게 스키마를 단순화한다.
4. smoke eval과 full eval을 분리한다.
5. 모델 변경, 프롬프트 변경, schema 변경 시 eval을 CI에 연결한다.
6. pass rate뿐 아니라 비용, latency, 파싱 실패율을 기록한다.
7. 실패 샘플을 매주 검토해 데이터셋에 추가한다.
8. 종료일인 2026년 10월 31일 read-only, 11월 30일 shutdown 일정을 팀 캘린더에 넣는다.

결론은 간단합니다. eval은 LLM 제품의 테스트 코드입니다. OpenAI Evals platform이 종료된다고 평가가 덜 중요해지는 게 아닙니다. 오히려 지금이 평가 데이터를 제품 자산으로 분리할 타이밍입니다. 플랫폼에 묶인 eval을 파일과 프로세스로 꺼내면, 모델이 바뀌어도 프롬프트가 바뀌어도 품질을 숫자로 관리할 수 있습니다.