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로 구성됩니다. 하지만 종료 일정이 있는 만큼, 단순 사용법보다 마이그레이션 가능한 평가 체계를 만드는 게 더 중요합니다.
LLM 기능을 처음 만들 때는 프롬프트 하나로 충분해 보입니다. 샘플 몇 개를 넣어보고 결과가 괜찮으면 배포합니다. 문제는 배포 후에 생깁니다.
이런 문제는 눈으로 몇 개 보는 방식으로 잡기 어렵습니다. eval은 “대표 입력 세트와 판정 기준”을 만들어 변경 전후를 비교하는 장치입니다. 코드 테스트와 비슷하지만, 정답이 명확한 경우와 주관 평가가 섞인다는 점이 다릅니다.
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 같은 정보가 포함됩니다.
이 구조 자체는 간단합니다. 중요한 건 “평가 데이터를 어떻게 만들고, 어떤 기준으로 실패를 정의하느냐”입니다.
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를 같이 저장하면 나중에 실패 분석이 쉬워집니다.
평가 기준은 처음부터 복잡하게 만들 필요가 없습니다. 분류 작업이면 exact match가 좋습니다. 추출 작업이면 필수 필드 일치율을 봅니다. 요약이나 답변 품질처럼 주관성이 있는 작업은 rubric 기반 평가가 필요하지만, 이때도 기준을 작게 나눠야 합니다.
예를 들어 고객 문의 요약을 평가한다면 하나의 “좋음/나쁨” 점수보다 다음처럼 나눕니다.
이렇게 나누면 실패 원인이 보입니다. 단일 점수는 개선 방향을 숨깁니다.
LLM eval은 매 요청마다 돌리는 것이 아니라 변경 시점에 돌리는 게 일반적입니다. 다음 이벤트에서 실행하면 좋습니다.
초기에는 전체 eval을 매번 돌리지 않아도 됩니다. smoke eval과 full eval을 나누세요.
Smoke eval은 20~30개 핵심 샘플로 빠르게 돌립니다. PR마다 실행할 수 있습니다. Full eval은 200개 이상 샘플로 nightly나 배포 전 실행합니다. 비용이 부담되면 모델 후보별 비교는 Batch API나 비동기 큐로 처리합니다.
결과 기준도 명확해야 합니다.
숫자는 제품별로 다르지만, 기준이 없으면 eval 결과가 보고서로만 남습니다.
종료 일정이 있는 플랫폼을 쓰고 있다면 아래 항목을 먼저 정리하세요.
이 목록이 있으면 OpenAI Datasets, 자체 runner, 다른 vendor 평가 도구로 옮기는 일이 쉬워집니다. 반대로 이 정보가 UI에 흩어져 있으면 종료 직전에 급하게 옮기느라 평가 신뢰도가 깨집니다.
LLM 평가에서 자주 보는 실수는 네 가지입니다.
첫째, 성공 사례만 eval에 넣습니다. 데모에서 잘 된 샘플은 평가 가치가 낮습니다. 실패했거나 애매했던 샘플을 모아야 회귀를 잡습니다.
둘째, 평가 데이터와 학습 데이터를 섞습니다. fine-tuning이나 prompt few-shot에 쓴 예시는 eval holdout과 분리해야 합니다.
셋째, 모델 출력만 보고 비용과 지연시간을 안 봅니다. 실서비스에서는 품질, 비용, latency가 같이 기준입니다.
넷째, 사람이 고친 결과를 eval에 반영하지 않습니다. 운영 중 상담원이나 관리자가 수정한 데이터는 좋은 eval 후보입니다. 단, 개인정보 제거와 라벨 검수는 필요합니다.
OpenAI Evals 종료 일정 전에 할 일을 정리하면 다음과 같습니다.
결론은 간단합니다. eval은 LLM 제품의 테스트 코드입니다. OpenAI Evals platform이 종료된다고 평가가 덜 중요해지는 게 아닙니다. 오히려 지금이 평가 데이터를 제품 자산으로 분리할 타이밍입니다. 플랫폼에 묶인 eval을 파일과 프로세스로 꺼내면, 모델이 바뀌어도 프롬프트가 바뀌어도 품질을 숫자로 관리할 수 있습니다.
