Claude의 답변이 좋아졌는지 확인하는 법: 평가 문제 만들기부터 개선까지

Claude에게 주는 지시를 고쳤더니 답변이 좋아 보입니다. 하지만 방금 확인한 문제에만 잘 답하게 된 것인지, 다른 요청에서도 나아진 것인지 어떻게 구분할까요? 몇 개만 돌려 보고 “느낌상 좋아졌다"고 판단하기 쉽습니다. 이 글은 대표 문제와 채점 기준을 만들고, 수정에 쓰지 않은 문제로도 효과를 확인하는 방법을 설명합니다.

한눈에 보기

• 평가 세트는 실제 업무를 닮은 문제와 채점 기준의 묶음입니다. 좋은 평가라면 성능 차이를 구분할 수 있고, 반복 실행해도 점수가 크게 흔들리지 않아야 합니다.
• Claude Code에서 사용하는 claude-api 스킬의 /claude-api build-eval 은 사용자에게 질문하며 평가를 만듭니다. /claude-api hillclimb 은 한 번에 하나씩 수정하고 점수 변화를 확인합니다.
• 개선에 참고하는 학습용 문제와 확인용 시험 문제를 나눕니다. 그래야 특정 문제에만 맞춘 수정인 과적합을 알아차릴 수 있습니다.

원문 소개

Lance Martin이 2026년 9월 28일에 claude.dev 블로그에 올린 플레이북입니다. LLM 앱이나 스킬을 운영하면서 변경의 효과를 확인할 방법이 필요한 분께 맞습니다.

좋은 평가의 조건과 build-eval

평가(eval)는 앱이나 스킬이 특정 과제를 얼마나 잘 해내는지 재는 시험입니다. 예를 들어 고객지원 앱이라면 실제 문의를 문제로 삼고, 올바른 처리 결정을 내렸는지 채점할 수 있습니다. 문제 묶음이 평가 세트이고 결과를 판정하는 코드나 모델이 채점기입니다. 원문이 꼽는 좋은 평가의 조건은 네 가지입니다.

1. 실제 업무를 닮아야 합니다. 만들거나 채점하기 쉬운 문제만 모으면 실제 요청의 종류와 비율을 반영하지 못합니다.
2. 성능 차이를 구분해야 합니다. 더 강한 모델이나 더 높은 effort, 즉 계산 자원을 더 쓰는 설정에서 보통 점수가 올라야 합니다. 그렇지 않다면 문제 설명이나 채점 기준이 모호한지 살펴봅니다.
3. 개선할 여지가 있어야 합니다. 가장 강한 설정도 만점에서 한참 아래여야 한다는 조건입니다. 이 여유를 headroom이라고 합니다. 다만 반복해도 누구나 틀리는 문제라면 불가능하거나 모호한 과제인지 확인해야 합니다.
4. 다시 실행해도 비슷하게 나와야 합니다. effort 설정이 일관되지 않거나, 이전 실행이 남긴 파일과 git 기록에 정답이 노출되면 비교가 흐트러집니다. 같은 조건에서 다시 실행할 수 있어야 수정 효과를 판단할 수 있습니다.

지금 모델이 틀린 사례만 고르면 그 모델의 약점에 치우친 시험이 될 수 있습니다. 원문은 사람이 어려운 이유를 설명할 수 있는 사례와 실제 서비스의 운영 기록, 버그 리포트, 문의 건인 티켓에서 나온 실패를 쓰라고 권합니다.

/claude-api build-eval 을 실행하면 Claude가 사용자에게 질문하며 프로젝트 안에 평가를 만듭니다. 문제는 운영 기록, 버그 리포트와 티켓, 직접 쓴 5-10개, 코드에서 생성한 합성 사례 순으로 모읍니다. 만든 사례를 전부 보여 주고 실제 평가에 쓸 만한지 확인받습니다.

채점 방식은 가장 비용이 적게 드는 방법부터 제안합니다. 숫자나 정해진 값이 정답이면 코드로 비교합니다. 여러 표현이 가능한 답변이면 다른 모델이 기준에 맞춰 심사합니다. 몇 건을 채점해 보여 주며 사람이 다르게 판정할 사례는 없는지 확인합니다.

그런 다음 수정 전 점수인 기준선을 측정합니다. 같은 결과에 채점기가 같은 판정을 내리는지, 시간 제한으로 실행이 중단되는 타임아웃이나 길이 제한으로 잘린 답변이 있는지도 점검합니다. 실행 환경의 문제를 모델의 실력 차이로 오해하지 않기 위한 과정입니다.

사용자가 확인하는 지점은 두 번입니다. 입력을 모은 직후와 채점 샘플을 본 직후입니다.

hillclimb: 한 번에 하나씩, 시험용 세트로 검증

힐클라이밍(hillclimbing)은 조금 수정하고 점수를 재 본 뒤, 좋아진 수정을 남기며 반복하는 방식입니다. 한 번에 많은 것을 바꾸면 무엇이 효과를 냈는지 알기 어려워 하나씩 고칩니다.

주의할 점은 과적합입니다. 평가 문제의 답에만 맞춘 규칙을 넣으면 그 문제에서는 점수가 오르지만 다른 요청에는 도움이 안 될 수 있습니다. 모델을 둘러싼 프롬프트, 도구, 반복 실행 코드를 하네스라고 합니다. 여기에도 특정 문제에만 통하는 수정이 들어갈 수 있습니다.

/claude-api hillclimb 은 평가 세트를 무작위로 학습용과 시험용으로 나눕니다. 여기서 학습용은 모델 자체를 재학습시키는 데이터라는 뜻이 아닙니다. Claude가 실패 기록을 읽고 프롬프트나 코드를 고칠 때 참고하는 문제들입니다. 시험용은 그 수정이 다른 문제에도 도움이 되는지 확인하는 데 씁니다.

매 라운드에는 학습 기록을 읽고 패치, 즉 수정안을 하나 제안합니다. 적용한 뒤 두 세트를 다시 평가해서 학습과 시험 점수가 모두 오르면 남깁니다. 학습만 오르거나 점수가 내려가면 되돌립니다.

점수가 두세 라운드 정체되면 남은 실패를 원인별로 분류합니다. 모호한 문제나 하네스 오류 때문에 실패한 것인지 확인하는 단계입니다. 끝나면 시험 점수가 가장 좋았던 버전으로 코드를 둡니다. 점수 상승이 실행마다 생기는 오차인 잡음 안에 있으면, 개선을 확인하지 못했다고 알리고 코드를 합치지 말라고 권합니다.

그림 1. 왼쪽부터 수정할 대상, 고정된 모델·실행 환경, 시험용·학습용 평가, 수정 유지 여부입니다. 아래 분석기는 학습용 실패만 읽습니다. 두 점수가 모두 오르면 유지하고, 학습만 오르거나 어느 점수든 내려가면 되돌립니다. 출처: 원문 .

학습 점수만 오르고 시험 점수가 제자리면 과적합을 의심해 패치를 되돌립니다. 정체가 이어질 때는 새 패치를 만들지 않고, 남은 실패에서 평가 쪽 문제를 걸러 낸 뒤 다음 라운드로 넘어갑니다.

사례 두 가지

고객지원 벤치마크는 티켓 44건을 학습용 30건과 시험용 14건으로 나눴습니다. 결정 정확도는 문의에 올바른 처리 결정을 내린 비율입니다. 학습용 티켓의 변화는 아래와 같습니다.

마지막으로 시험 티켓 14건에서도 확인했습니다. 최종 설정은 90.5%로 원래 설정의 78.6%를 앞섰고, 비용은 원래의 약 5분의 1이었습니다. 개선에 참고한 문제 외에서도 점수가 올랐다는 점을 함께 봐야 합니다.

그림 2. 가로축은 티켓당 비용, 세로축은 학습용 티켓의 정확도입니다. 왼쪽으로 갈수록 저렴하고 위로 갈수록 정확합니다. 축과 설명만 한글화했습니다. 출처: 원문 .

설정을 바꾼 경로가 1~4번 점으로 표시돼 있습니다. 2번에서 3번으로 갈 때 정확도는 거의 같고 비용만 줄었고 4번에서는 프롬프트를 고쳐 정확도가 뛰었습니다. 이 차트는 학습용 티켓의 결과이므로, 위의 시험 티켓 14건 결과도 함께 확인해야 합니다.

claude-api 스킬 자체의 평가는 66%에서 시작해 약 88%까지 올랐습니다. 스킬은 Claude가 특정 작업을 수행할 때 참고하는 지침 묶음입니다. 먼저 빠진 기능 여덟 개를 채워 74%로 올렸고, 데이터 형식을 설명하는 타입 표를 고쳐 77%에 도달했습니다.

점수가 정체한 뒤 실패를 분류하자 모델이 옛 API 형태로 코드를 쓰는 문제가 드러났습니다. 옛 형태를 현재 형태로 바꾸는 안내 표를 넣자 80%가 됐습니다. 이후 오류가 있는 평가 과제와 채점 로직을 고치고 스킬도 더 손봐 약 88%에 닿았습니다. 이 마지막 상승에는 시험 문제와 채점의 수정도 포함되므로, 전부 스킬 성능 향상으로만 읽으면 안 됩니다.

앞의 두 단계는 스킬 내용을 채우고 바로잡는 수정이었습니다. 점수가 멈춘 뒤 실패를 모아 읽자 모델이 옛 형태로 쓴다는 원인이 보였습니다. 마지막 구간은 과제와 채점 로직 수정에 스킬 수정을 더해 올랐습니다.

인사이트

여기부터는 원문이 아닌 이 블로그의 해석입니다.

1. 점수가 오르지 않으면 프롬프트나 모델 설정을 더 바꾸기 전에 평가 문제와 채점 기준부터 확인할 필요가 있습니다. 질문이 모호하거나 채점 코드가 틀리면 좋은 답을 내도 낮은 점수를 받을 수 있습니다. 원문의 스킬 사례에서도 과제와 채점 로직을 고쳤습니다. 이렇게 평가를 바로잡아 오른 점수는 모델이나 프롬프트가 좋아져서 오른 점수와 구분해야 합니다.

2. 평가는 정확도를 높이는 데만 쓰는 도구가 아닙니다. 이미 점수가 높다면 비슷한 정확도를 유지하면서 비용을 줄일 수 있는지 확인하는 데도 쓸 수 있습니다. 모델을 교체할 때도 같은 문제로 답변의 품질과 비용을 비교하면 판단하기 쉬워집니다.

3. 사례가 적어도 수정에 참고할 문제와 수정 결과를 확인할 문제는 나누는 편이 좋겠습니다. 프롬프트를 고칠 때 본 문제에서만 점수가 오르면 새로운 요청에도 효과가 있다고 보기 어렵습니다. 원문에서도 별도로 남겨 둔 시험용 14건은 학습용 문제와 다른 점수를 보였습니다. 적은 사례로 확인한 결과인 만큼 더 넓은 업무에서도 같은 효과가 날지는 추가로 확인해야 합니다.

먼저 평가가 제대로 작동하는지 확인한 뒤 모델이나 프롬프트를 바꾸면, 점수가 달라진 이유를 구분하기 쉬워집니다.

바로 해볼 것

• 운영 중인 프롬프트 하나를 고르고 실제 요청 기록에서 평가에 쓸 사례를 뽑습니다. 각 사례에 어떤 결과가 나와야 맞는 답인지 적어 둡니다.
• 몇 건을 채점한 뒤 질문, 모델의 답변, 채점 결과를 직접 읽어봅니다. 내가 맞다고 판단한 답을 채점기가 틀렸다고 하거나 그 반대인 사례가 있는지 확인합니다.
• 사례를 두 묶음으로 나눕니다. 학습용은 실패한 이유를 읽고 프롬프트를 고치는 데 쓰고, 시험용은 수정할 때 참고하지 않은 사례에서도 효과가 있는지 확인하는 데 씁니다. 수정 전후의 두 점수를 따로 기록합니다.

원문: Automating eval design and hillclimbing with Claude