한눈에 보기
- 실전과 닮은 시험을 먼저 만든다
- 만드는 모델과 채점하는 모델을 분리한다
- 탐색용 점수와 실전 점수를 나눠 본다
AI를 실제 업무에 연결하기 전에는 실전과 닮은 사례와 합격 기준으로 먼저 시험해야 합니다. eval은 AI의 업무 수행을 재는 평가이고, 만드는 AI와 채점하는 AI를 분리하면 느낌이 아니라 반복 가능한 기록으로 품질을 비교할 수 있습니다.
좋은 eval은 무엇을 갖춰야 하나요?
원문은 좋은 평가에 네 가지 조건이 필요하다고 설명합니다. 실제 업무를 닮아야 하고, 더 강한 모델이나 더 많은 생각을 쓸수록 점수가 올라갈 여지가 있어야 합니다. 최상위 모델도 만점을 받기 어려워야 변별력이 생기며, 같은 조건에서 결과가 지나치게 흔들리지 않아야 합니다.
정답과 규칙이 분명한 항목은 프로그램으로 채점할 수 있습니다. 답이 열려 있는 문항은 기준표를 별도 채점 모델에 주고 평가하게 할 수 있습니다. 이때 시험을 보는 AI와 채점하는 AI는 분리해야 하며, 채점 기준과 모델 버전도 기록해야 전후 비교가 가능합니다.
점수는 왜 두 묶음으로 보나요?
한 번에 모든 사례를 고치려 하지 않고, 평가 결과를 보며 프롬프트와 라우팅을 한 가지씩 개선하는 과정을 hillclimbing이라고 합니다. 원문 사례는 전체 44건 중 탐색에 사용한 30건과, 탐색(튜닝) 과정에서 한 번도 보지 않은 14건(held-out)으로 나눴습니다. 탐색용 점수는 74.4%에서 98.9%로 올랐고, held-out 점수도 78.6%에서 90.5%로 올랐습니다.
탐색용 점수만 보면 문제를 외운 것처럼 좋아 보일 수 있습니다. 비용이 약 5분의 1로 내려간 이유도 함께 봐야 합니다. 시작은 Opus 4.8의 기본 high effort였고, 마지막은 Sonnet 5의 low effort였으며, 프롬프트와 라우팅 규칙도 개선됐습니다. 즉 모델 선택과 지시 설계를 같이 조정한 결과입니다.
학원 업무에는 어떻게 시작할까요?
상담 문의를 실제 사례에서 골라 답변의 합격 기준을 적고, 모의 상담 대화로 미리 시험해 보는 방식부터 시작할 수 있습니다. 워크북 검수라면 문항 연결, 사실 오류, 형식 누락을 각각 검사 항목으로 만들고, 사람이 최종 판단할 항목과 자동으로 확인할 항목을 나눕니다. 평가 결과가 낮은 이유를 기록하면 다음 개선의 방향도 분명해집니다.
원문에서 소개한 /claude-api build-eval과 /claude-api hillclimb 같은 흐름은 평가 사례를 만들고 개선을 반복하는 예입니다. 도구를 그대로 도입하기보다, 먼저 업무 사례·합격 기준·채점 방법·보류 조건 네 가지를 문서로 고정하는 것이 우선입니다.
eval을 설계하고 개선할 때 볼 것
- 실제 상담·수업 자료에서 대표 사례와 어려운 사례를 함께 골라 평가 묶음을 만듭니다.
- 정답형 검사는 규칙이나 프로그램으로, 열린 답변은 기준표 기반 채점으로 나눕니다.
- 시험을 보는 AI와 채점하는 AI를 분리하고, 채점 조건을 기록합니다.
- 튜닝에 쓰는 사례와 탐색 과정에서 보지 않는 사례를 분리합니다.
- 한 번에 하나의 프롬프트·라우팅·모델 변경만 적용해 점수 변화를 비교합니다.
- 점수뿐 아니라 실패 유형과 사람의 재검토 시간을 함께 기록합니다.
자주 묻는 질문
eval 사례는 몇 건이어야 하나요?
정해진 숫자부터 채우기보다 실제 업무의 변형과 위험을 골고루 포함하는 것이 먼저입니다. 사례가 적다면 결론을 확정하지 말고, 새로 생긴 실패를 평가 묶음에 추가하면서 범위를 넓히세요.
채점 모델은 시험 모델과 달라야 하나요?
중요한 평가에서는 분리하는 편이 좋습니다. 같은 모델이 만들고 스스로 합격을 선언하면 자기 결과를 후하게 볼 수 있으므로, 별도 채점 모델과 고정된 기준표를 사용하세요.
전후 점수가 올랐으면 바로 실전에 넣어도 되나요?
튜닝에 사용하지 않은 사례에서도 좋아졌는지 확인해야 합니다. 같은 채점 모델과 기준을 유지하고, 점수 외에 실제 검토 시간과 위험한 실패가 줄었는지도 함께 보세요.
hillclimbing은 모델만 바꾸는 과정인가요?
아닙니다. 프롬프트, 라우팅, effort, 모델 선택을 한 가지씩 바꾸며 평가를 높이는 과정입니다. 여러 변경을 동시에 적용하면 무엇이 개선을 만들었는지 알기 어렵습니다.
출처
- Automating eval design and hillclimbing with Claude — Lance Martin (claude.dev, 2026-09-28) — https://claude.dev/blog/automating-eval-design-and-hillclimbing/
이 글은 claude.dev 원문을 학원 운영 관점에서 요약·해설한 글이며 번역이 아닙니다.