OpenAI Evals 전환 준비: 평가셋과 채점 기준을 Promptfoo로 옮기기

분류: 개발-AI · 기준일: 2026-10-05 KST

💡 AI 서비스는 모델을 한 번 연결했다고 끝나지 않아요. 프롬프트를 고쳤을 때 전에 잘하던 일을 계속 잘하는지 확인할 장치가 필요합니다. 이 역할을 하는 것이 평가셋과 채점 기준이에요. 그런데 평가를 돌리던 서비스가 바뀐다면, 결과 화면만 저장해 두는 것으로 충분할까요?

2026년 10월에는 OpenAI Evals를 사용 중인 프로젝트가 확인할 일정이 있습니다. 공식 공지에 따르면 기존 평가는 10월 31일 읽기 전용으로 바뀌고, Evals 대시보드와 API는 11월 30일 종료 예정이에요. 발표일은 6월 3일입니다. 이번 주에 새로 발표된 기능이 아니라, 전환 시점이 다가온 운영 과제로 골랐어요. 공식 종료 일정

STEP 1평가 결과와 평가 방법을 따로 챙겨요

먼저 지금 가지고 있는 것을 네 부분으로 나눠보세요. 첫째는 모델에 전달하는 프롬프트, 둘째는 테스트 입력과 기대 결과, 셋째는 사용하는 모델과 생성 설정, 넷째는 합격 여부를 정하는 기준입니다. 이 중 하나라도 빠지면 예전 결과를 보면서도 같은 시험을 다시 치르기 어려워집니다.

예를 들어 고객 문의를 “배송”, “환불”, “기타”로 나누는 기능이라면, 입력 문장만 보관해서는 부족해요. 분류 이름의 정확한 표기, 애매한 문의의 처리 방식, 아무 정보가 없을 때의 답변 규칙도 있어야 합니다. 점수 95점이라는 기록보다 어떤 사례에서 어떤 기준으로 실패했는지가 다음 수정에 더 도움이 될 때가 많아요.

OpenAI의 공식 이관 문서는 기존 평가를 Promptfoo 설정으로 수동 재구성하는 경로를 안내합니다. 테스트, 프롬프트, 모델, 채점 기준을 대응시키고 새 평가를 실행하는 방식이에요. 과거 실행이 자동으로 새로운 실행이 되거나 기존 화면 전체가 그대로 복제되는 것으로 이해하면 안 됩니다. 공식 이관 가이드

과거 결과를 보존하는 경로도 따로 확인하세요. 현재 Promptfoo CLI 문서에는 OpenAI 대시보드 JSONL 결과를 가져오는 기능이 있지만, 이것이 실행 가능한 평가 정의와 채점기를 자동으로 복원하지는 않는다고 명시돼 있어요. 대시보드 형식과 API output-items 응답도 같은 것으로 취급하면 안 됩니다. “결과를 가져왔다”와 “다시 평가할 수 있다”를 서로 다른 완료 항목으로 기록하세요.

평가 자료에는 실제 고객의 질문과 모델 답변이 들어 있을 수 있어요. 이동 전에 식별 가능한 정보와 비밀값을 확인하고, 업무상 필요한 접근자만 볼 수 있는 위치를 정합니다. API 키를 YAML에 직접 적지 말고 승인된 비밀 관리 방식으로 전달하세요. 설정 파일이 코드 저장소에 들어간다고 해서 테스트 원문까지 모두 공개해도 된다는 뜻은 아닙니다.

STEP 2가장 작은 평가 하나부터 다시 실행할 수 있게 만들어요

처음부터 전체 평가를 옮기기보다 입력과 정답이 분명한 기능 하나를 고르는 편이 좋아요. 아래에서는 문의 분류를 예로 사용합니다. 사용 중인 모델, 도구, 검색 문서까지 한 번에 교체하면 점수 변화가 이관 때문인지 모델 때문인지 알기 어려워집니다. 첫 비교에서는 가능한 한 원래 조건을 유지하세요.

Promptfoo 설정은 프롬프트, provider, 테스트 사례를 묶고, 필요하면 각 사례에 assertion을 붙이는 형태입니다. 모델 ID는 프로젝트에서 실제로 사용할 수 있는 값으로 정해야 해요. 특정 모델이 가장 좋다고 정해두지 말고 기존 평가 조건과 호환성을 먼저 확인합니다. 공식 설정 구조

다음은 설명용 최소 구성입니다. 모델 ID 자리는 바꿔야 하며 실행을 검증한 완성 설정은 아닙니다. 실제 입력이 외부 모델 제공자에게 전달되고 사용료가 발생할 수 있다는 점도 함께 확인하세요.

description: 문의 분류 평가 이관 예시
prompts:
  - '문의 내용을 배송, 환불, 기타 중 하나로만 분류하세요. 문의: {{input}}'
providers:
  - 'openai:YOUR_SUPPORTED_MODEL_ID'
tests:
  - description: 배송 문의
    vars:
      input: '택배가 어디쯤 왔나요?'
    assert:
      - type: equals
        value: 배송
  - description: 환불 문의
    vars:
      input: '주문을 취소하고 돈을 돌려받고 싶어요.'
    assert:
      - type: equals
        value: 환불

이 두 문장을 잘 맞힌다고 운영 준비가 끝난 것은 아니에요. 먼저 연결이 되는지 확인할 아주 작은 시작점입니다. 이후 실제 기능에서 중요했던 사례를 넣으세요. 배송과 환불을 동시에 묻는 문의, 오타가 많은 문장, 빈 입력, 정보가 부족한 문장처럼 실패 구간을 설명할 수 있는 사례가 필요해요.

애매한 사례는 개발자가 먼저 정책을 정해야 합니다. “배송이 늦어서 환불하고 싶어요”를 배송으로 볼지 환불로 볼지 정답이 없는 상태라면, 도구를 바꿔도 평가가 흔들립니다. 분류 우선순위나 복수 분류 허용 여부를 결정하고 그 정책을 프롬프트와 기대값에 똑같이 반영하세요.

사례마다 고유 ID를 붙이고, 왜 추가했는지 한 줄 메모를 남기는 것도 유용합니다. 실패한 로그를 평가셋에 넣었다면 원래 오류와 연결해 두세요. 나중에 담당자가 바뀌어도 단순히 점수를 올리기 위해 어려운 사례를 삭제하는 실수를 줄일 수 있습니다.

STEP 3채점기가 같은 의미의 점수를 내는지 확인해요

정답이 “배송” 한 단어인 분류는 정확 일치 검사로 시작할 수 있어요. JSON 응답이라면 파싱 가능 여부, 필수 필드, 허용된 값 등 형식 검사를 먼저 둡니다. 이런 부분까지 다른 AI에게 통째로 판단시키면 단순한 오류가 설명 좋은 답변에 가려질 수 있어요. 검사 유형과 지표

반대로 상담 요약처럼 표현이 여러 가지일 수 있는 작업을 문자열 하나와 비교하면, 의미가 맞는 답변도 실패할 수 있습니다. 이때는 금지할 사실 추가, 반드시 포함할 핵심 정보, 문서에 없는 내용을 모른다고 표현하는 기준을 나눠보세요. 모델 기반 채점은 이처럼 의미 판단이 필요한 부분에 사용하고, 사람이 동의하는 기준인지 별도로 검토합니다.

예를 들어 “원문에 없는 주문 금액을 추가하면 실패”, “환불 요청이라는 핵심 의도를 누락하면 실패”는 상대적으로 확인하기 쉬운 규칙이에요. “좋은 답변이면 5점”은 검토자마다 해석이 다를 수 있습니다. 통과 사례와 실패 사례를 각각 몇 개 정해두고, 채점기가 의도대로 구분하는지 먼저 시험해 보세요.

이관 과정에서 정규화도 주의가 필요합니다. 앞뒤 공백을 없애는 처리는 도움이 될 수 있지만, 코드·식별자·법적 문구처럼 정확한 표현이 중요한 작업에서는 의미를 바꿀 수 있어요. 비교 전에 어떤 문자를 바꾸는지 기록하고 기존 평가에도 같은 처리가 있었는지 확인합니다.

점수의 척도 역시 맞춰야 해요. 기존 도구의 1~5점과 새 도구의 0~1 점수를 숫자만 바꿔 대응시키면 같은 합격 기준이 되지 않을 수 있어요. 특히 유사도 점수나 AI 채점은 새 구현에서 결과가 달라질 수 있으므로, 예전 통과선을 그대로 복사하기 전에 대표 답변에 대한 판정이 일치하는지 확인합니다.

STEP 4같은 입력으로 나란히 돌리고, 달라진 사례를 읽어요

설정 파일을 만들었다면 문법과 구성을 먼저 확인하고 작은 평가를 실행하세요. 다음 명령은 공식 CLI 흐름을 바탕으로 한 예시입니다. 설치된 버전과 provider 설정을 확인한 뒤 사용하며, 여기서는 실제 API 호출을 실행한 것은 아닙니다.

promptfoo validate config -c promptfooconfig.yaml
promptfoo eval -c promptfooconfig.yaml --no-cache --max-concurrency 2 -o results.json
promptfoo view

--no-cache는 저장된 캐시를 읽고 쓰지 않도록 하는 옵션입니다. 이관 검증에서 새 응답이 필요할 때 유용하지만, 호출량과 비용은 늘 수 있어요. 반복 실행은 예산 안에서 필요한 만큼 계획하고, 동일 입력의 응답이 달라지는지 보려면 캐시와 반복 설정을 함께 확인합니다. 동시 호출 수를 낮추는 것도 서비스 제한을 확인하는 동안 도움이 됩니다. CLI 옵션

비교할 때는 전체 통과율만 보지 말고 사례별로 결과를 나눠보세요. “둘 다 통과”, “기존만 통과”, “새 평가만 통과”, “둘 다 실패”의 네 묶음이면 시작하기 충분합니다. 이관 직후에는 가운데 두 묶음을 먼저 읽으면 어디서 의미가 바뀌었는지 찾기 쉬워요.

예를 들어 기존만 통과한 사례가 모두 줄바꿈이 포함된 답변이라면 전처리 차이를 의심할 수 있어요. 새 평가만 통과한 사례가 필수 정보가 빠진 답변이라면 채점 기준을 느슨하게 옮겼을 가능성을 확인합니다. 이런 경우는 모델 품질이 좋아졌다거나 나빠졌다고 결론 내리기 전에 평가 구현부터 비교해야 합니다.

모델 자체의 변동도 고려해야 해요. 같은 조건에서 한 번 더 실행했을 때 판정이 자주 뒤집히는 사례라면, 한 번의 성공으로 안정적이라고 말하기 어렵습니다. 대표 사례를 반복 관찰하고 사람이 판정한 예시와 비교해 보세요. 반복 횟수와 허용 가능한 변동 폭은 기능의 위험도와 비용을 보고 정해야 합니다. 평가 설계 모범 사례

비용과 속도도 별도 기록으로 남깁니다. 이관 전보다 호출을 더 많이 하거나 AI 채점기를 추가했다면 통과율이 같아도 운영 부담은 달라질 수 있어요. 입력 건수, 생성 호출 수, 채점 호출 수, 실패·재시도 수를 함께 적어두면 다음 실행의 예산을 잡기 쉽습니다. 이 글은 특정 금액이나 처리속도를 보장하지 않습니다.

STEP 5돌아가는 파일을 만들었다면, 유지할 방법도 정해요

다음 단계는 평가 설정을 애플리케이션 변경과 함께 검토하는 것입니다. 프롬프트나 검색 처리를 바꾼 PR에서 관련 평가도 돌리면, 예전에 통과하던 기능이 깨지는지 확인할 수 있어요. CI에 연결할 때는 외부 기여 PR에 비밀값을 노출하지 않고, API 호출 예산과 결과물 보존 범위를 명확히 하세요. Promptfoo CI/CD 안내

처음부터 모든 변경을 자동 차단할 필요는 없습니다. 점수의 신뢰도가 검증될 때까지 결과를 보고하는 단계로 운영하고, 충분히 합의된 필수 검사부터 차단 조건으로 옮기는 방법을 고려해 보세요. 실패가 발생하면 누가 어떤 사례를 읽을지 정해져 있어야 빨간 표시가 의미를 가집니다.

AI에게 설정 변환을 맡길 때도 이 구분을 알려주세요. “이 평가를 변환해줘”라고만 요청하면 빈칸을 알아서 채우거나 기존 채점기의 의미를 단순화할 수 있어요. 먼저 누락 항목을 표시하고, 원래 기준과 대응표를 만들고, 실행 전에 검토할 수 있게 부탁하는 편이 안전합니다.

기존 평가의 입력과 기대값, 프롬프트, 모델 설정, 채점 기준을 읽어줘.
Promptfoo 설정으로 대응시키되 없는 정보는 추정하지 말고 표시해줘.
실패해야 할 예시와 통과해야 할 예시를 함께 제안해줘.
고객 데이터와 비밀값을 새 서비스에 전송하지 말고,
실제 API 실행 없이 설정 초안과 비교 계획부터 보여줘.

평가를 옮긴다는 것은 설정 파일 한 개를 만드는 작업보다 넓어요. 서비스가 잘 동작한다는 판단 근거를 계속 사용할 수 있도록 정리하는 과정입니다. 이번 주에는 평가 하나를 골라 다시 실행 가능한 상태로 만들고, 예전 실패 사례를 제대로 잡아내는지부터 확인해 보세요. 작은 범위에서 기준을 맞춘 뒤 확장하면 종료 일정에 쫓겨 중요한 검사까지 놓치는 일을 줄일 수 있습니다.