Claude로 평가 설계와 힐클라이밍 자동화하기

실제 사용 환경을 반영하는 평가를 설계하고 과적합을 점검하면서 성능과 비용을 개선하는 원칙을 설명합니다. claude-api 스킬의 build-eval과 hillclimb 명령이 이 원칙을 적용하는 절차와 사례를 소개합니다.

Sourceclaude.dev/blog/automating-eval-design-and-hillclimbing

평가를 설계하고 그 평가를 기준으로 힐클라이밍을 수행하면서 스스로를 속이지 않기 위한 원칙과, claude-api 스킬의 build-eval 및 hillclimb 명령이 이 원칙을 적용하는 방법을 소개합니다.

평가는 앱이나 스킬이 특정 작업을 얼마나 잘 수행하는지 알려줍니다. 하지만 평가를 설계하고, 스스로를 속이지 않으면서 평가 성능을 개선하기는 어렵습니다. 우리는 이 두 가지를 위한 지침을 claude-api 스킬에 추가했습니다.

이 스킬을 사용하면 /claude-api build-eval을 실행해 코드베이스 안에 평가를 구축할 수 있습니다. 이어서 /claude-api hillclimb을 실행하면 과적합을 감지하기 위해 별도로 남겨 둔 예제 집합을 활용하면서, 한 번에 하나씩 변경하여 애플리케이션을 개선할 수 있습니다.

이 글에서는 좋은 평가 설계와 힐클라이밍의 원칙을 먼저 살펴보고, claude-api 스킬을 사용하는 Claude Code가 이 원칙을 어떻게 적용하는지 설명합니다. 마지막으로 이 명령들을 활용한 몇 가지 사례를 소개합니다.

평가 설계

잘 설계된 평가에는 몇 가지 공통 요소가 있습니다(그림 1).

  1. 평가 작업은 실제 운영 환경을 반영합니다. 운영 환경, 즉 테스트하는 기능이나 애플리케이션이 사용될 환경에서 중요하게 여기는 작업을 표본으로 선정해야 합니다. 만들기 쉽거나 채점하기 쉽다는 이유로 작업을 고르는 경우도 있습니다. 하지만 작업 분포가 실제로 중요하게 여기는 대상을 대표하도록 해야 합니다.
  2. 더 강력한 모델과 더 많은 추론을 사용하면 성능이 향상됩니다. 일반적으로 더 유능한 모델과 더 높은 effort 수준은 평가에서 더 좋은 성능을 보여야 합니다. 그렇지 않다면 모호한 작업이나 잘못 보정된 채점기가 성능을 제한하는 경우가 많습니다.
  3. 최고 성능 수준에서도 달성 가능한 개선 여지가 남아 있습니다. 가장 유능한 모델을 가장 높은 effort로 실행하더라도 평가 점수가 100%보다 충분히 낮아야 합니다. 그렇지 않으면 변경 사항이 성능에 미치는 영향을 신뢰할 만하게 판단할 수 없습니다. 이 격차가 불가능하거나 모호한 작업 때문에 생겨서는 안 됩니다. 반복 실행 횟수와 관계없이 모든 평가 실행에서 실패하는 작업은 이러한 문제의 흔한 징후입니다. 좋은 작업이라면 해당 분야 전문가 두 사람이 같은 판정을 내려야 하며, 채점기가 확인하는 모든 사항이 작업에 명시되어 있어야 합니다.
  4. 실행 간 분산이 작습니다. 설계가 부실하고 모호한 작업이나 동일한 출력에 서로 다른 판정을 내리는 채점기 때문에 분산이 커지는 경우가 많습니다. 설정에도 분산의 원인이 숨어 있을 수 있습니다. 예를 들어 effort가 일관되게 적용되지 않을 수 있습니다. 환경도 평가 결과에 영향을 줄 수 있습니다. 이전 시행에서 남은 파일이나 Git 이력이 에이전트에게 정답을 제공할 수 있습니다.

소형·중형·최상위 모델을 low, medium, high effort로 실행했을 때 시도당 행동 토큰 수에 따른 점수입니다. 번호가 붙은 표시는 네 가지 요소를 나타냅니다. 모델이 더 유능하고 effort가 높을수록 점수가 오르고, 최상위 곡선은 만점 아래에 있으며, 오차 막대의 폭은 좁게 유지됩니다.

그림 1. 좋은 평가의 네 가지 요소입니다.

적대적 샘플링

모델의 역량은 작업에 따라 불균일합니다. 현재 모델이 실패한다는 이유로 사례를 선택하면 특정 모델의 역량이 낮은 지점만 표본으로 추출하게 됩니다(그림 2). 그러면 평가는 애플리케이션이 수행하기에 본질적으로 어렵거나 가치 있는 작업보다 해당 모델 특유의 실패 패턴을 측정하게 될 수 있습니다.

작업 공간에 따른 역량을 보여주는 두 패널입니다. 현재 모델은 들쭉날쭉한 곡선으로, 다음 모델은 그 위의 더 매끄러운 곡선으로 표시됩니다. 왼쪽에서는 현재 모델이 실패하는 사례가 역량이 낮은 지점에만 모여 있습니다. 오른쪽에서는 사람이 어렵다고 판단한 사례가 높은 지점과 낮은 지점에 분산되어 있으며, 작동해서는 안 되는 사례도 몇 개 포함되어 있습니다.

그림 2. 적대적 샘플링을 보여줍니다.

사람이 어렵다고 판단한 사례를 선택하세요. 작업을 포함하기 전에 왜 어려운지 설명할 수 있는지 확인하는 것이 유용합니다. 실제 운영 트래픽, 버그 보고서, 지원 티켓에서 도출한 애플리케이션의 구체적인 실패 사례를 포함하세요. 다만 사용자 트래픽을 무조건 신뢰해서는 안 됩니다. 사용자는 잘 작동하리라 예상하는 것만 시도하기도 하므로, 사용자 트래픽만으로 구성한 작업 분포는 쉬운 작업에 치우칠 수 있습니다.

/CLAUDE-API BUILD-EVAL

claude-api 스킬의 build-eval 명령은 이 원칙을 안내형 워크플로로 구현합니다. Claude Code에서 /claude-api build-eval을 실행하면 Claude가 사용자에게 질문하고, 코드베이스 안에 평가를 구축하며, 정해진 지점에서 승인을 기다립니다.

예제 설계

Claude는 다음 순서로 입력을 표본 추출하여 평가를 구성하도록 돕습니다.

  1. 보관 정책과 민감한 데이터에 관해 질문한 뒤, 실제 운영 환경의 대화·실행 기록을 사용합니다.
  2. 버그 보고서와 지원 티켓을 사용합니다.
  3. 사용자가 직접 작성한 사례 5～10개를 사용합니다.
  4. 코드베이스를 바탕으로 합성한 사례를 사용합니다.

스킬은 실제 운영 트래픽을 우선하지만, 사용자가 제공하는 소수의 실제 예제를 기준으로 합성 데이터를 생성할 수도 있습니다. 스킬은 Claude에게 모든 입력을 보여주는 간단한 페이지를 만들고 사용자가 확인할 때까지 기다리도록 지시합니다. 아래는 스킬이 사용자에게 검토를 요청할 수 있는 이메일 라우터 애플리케이션의 입력 집합 예시입니다(그림 3).

입력 24개로 구성된 받은편지함 라우팅 평가의 검토 페이지입니다. 각 사례의 이메일 본문에 billing, easy, ambiguous 등의 태그가 붙어 있습니다. 옆에서는 Claude가 채팅으로 입력이 실제 사용 사례를 대표하는지 묻고, 사용자가 그렇다고 답합니다.

그림 3. 스킬이 생성한 입력 검토 예시입니다.

채점기 검증

입력을 정한 뒤 Claude는 애플리케이션 출력에 적합한 채점기 중 비용이 가장 적게 드는 방식을 제안합니다.

Claude는 몇 가지 사례를 채점한 뒤 사용자라면 다르게 채점했을 사례가 있는지 묻습니다(그림 4). 일반적으로 평가기를 신뢰하기 전에 채점된 실행 기록의 표본을 읽는 것이 중요합니다. 채점 오류는 평가가 잘못 설정되는 가장 흔한 원인 중 하나입니다.

채점기를 검증하면 스킬은 평가 집합의 규모인 사례 수 × 반복 수 × 모델 수와 대략적인 소요 시간을 알려줍니다. 이어서 기준 평가를 실행하고 신뢰구간과 함께 점수를 출력합니다. 결과물로는 사례, 채점기, 실행기, 사례별 JSON 한 줄과 전체 실행 기록, 그리고 각 사례의 점수와 실행 기록 링크를 나열한 간단한 페이지를 받습니다. 페이지에 표시된 내용 외에 차트 같은 것이 더 필요하다면 요청하면 됩니다. Claude는 기존 페이지 옆에 추가 페이지를 만듭니다. 이 추가 페이지는 기본적으로 로컬에서 열리며 네트워크에서 아무것도 불러오지 않는 정적 파일입니다.

받은편지함 라우팅 평가의 결과 페이지입니다. 사례 24개의 기준 평균 정답 점수는 0.681이며, 아래에는 각 반복 실행 링크가 포함된 사례별 점수 표가 있습니다. 반복 실행 링크를 열면 해당 사례의 원시 JSON 추적 기록이 옆에 표시됩니다.

그림 4. 각 입력에 대한 제안 점수를 포함한 결과 페이지의 구성 예시입니다.

진단 검사

앞서 설명한 기준 평가를 실행하는 동안 Claude는 여러 사항을 확인합니다.

힐클라이밍

이제 애플리케이션이 작업을 얼마나 잘 수행하는지 신뢰할 만하게 채점할 수 있으므로 개선을 시도할 수 있습니다. 힐클라이밍은 비용과 성능 사이의 절충에 영향을 주는 effort나 프롬프트 같은 매개변수를 조정하는 효과적인 방법입니다. 적용 대상을 선택할 때 참고할 일반적인 지침은 다음과 같습니다.

과적합

잘 설계된 평가도 실제 운영 환경에서 중요하게 여기는 작업 분포와 정확히 일치하는 경우는 드뭅니다. 따라서 평가에 대한 ‘과적합’은 흔한 문제이며, 실제 운영 트래픽보다 평가에서 더 좋은 성능을 내는 시스템으로 이어집니다.

평가가 하네스, 즉 프롬프트·도구·Claude를 호출하는 루프 등 모델 주변 코드에 ‘유출’되는 경로는 다양합니다. 예를 들어 OCR이 유용한 평가 작업이 있지만 실제 운영 작업에서는 OCR이 거의 유용하지 않다고 가정해 보겠습니다. 평가 하네스가 애플리케이션에 OCR 도구를 추가하면 실제 운영에는 영향이 없으면서 벤치마크 점수만 향상될 수 있습니다. 더 넓게 보면 힐클라이밍은 선택된 평가 예제의 특수한 예외 상황에 대응하는 기능을 하네스에 추가할 수 있습니다. 이런 추가 기능은 평가 점수는 높이지만 실제 운영 성능 향상으로 이어지지 않습니다(그림 5).

왼쪽 벤치마크의 특성이 오른쪽 하네스에 대응 기능을 추가하도록 만드는 모습입니다. OCR이 필요한 작업 구성은 OCR 도구를 추가하게 하고, /app 안의 작업은 “always cd /app, run pytest”를 추가하게 하며, 특이한 표현은 그에 맞춘 프롬프트를 만들게 하고, 읽어 본 실패 사례에는 각각 패치를 추가하게 합니다. 점선 화살표는 노골적인 유출을 나타냅니다. 정답이 있는 공개 저장소에서 하네스가 curl로 기준 풀이를 가져올 수 있습니다.

그림 5. 하네스 과적합의 흔한 원인입니다.

다음 세 가지가 도움이 됩니다.

아래에서 설명하듯 claude-api 스킬은 이 원칙을 대신 적용합니다.

/CLAUDE-API HILLCLIMB

claude-api 스킬의 hillclimb 명령은 이 원칙을 안내형 워크플로로 구현합니다. Claude Code에서 /claude-api hillclimb을 실행하면 Claude는 주어진 평가에서 성능을 개선하도록 반복 작업을 수행합니다. 사용자는 다음을 포함해 변경을 허용할 대상을 선택합니다.

시작하기 전에 Claude는 무엇을 최적화할지 묻습니다. 예를 들어 성능을 높일지, 성능을 유지하면서 비용을 줄일지 정합니다. 이어서 평가 집합을 무작위로 테스트 집합과 학습 집합으로 나눕니다. 비용이 목표라면 프롬프트 캐싱, 선택한 모델과 프롬프트의 호환성 점검, 모델 및 effort 설정 선택 등 몇 가지 일반적인 비용 요인을 검토합니다.

첫 번째 반복을 시작하기 전에 Claude는 평가 잡음, 즉 우연만으로 점수가 변동할 수 있는 폭이 사용자가 실제로 조치할 만한 최소 개선 폭보다 작은지 확인합니다. 그렇지 않다면 그 사실을 알리고 반복 횟수나 사례 수를 늘리도록 제안합니다.

각 반복에서 Claude는 이전 반복의 학습 실행 기록을 읽고, 하나의 변경을 패치로 제안합니다. 각 반복에서는 효과가 평가 잡음보다 크게 나타날 수 있는 변경을 목표로 합니다. 단순히 한 문장의 표현을 바꾸기보다 문제를 일으키는 섹션을 다시 쓰거나 빠진 규칙을 추가하는 식으로 실패 행동의 근본 원인을 수정합니다. 이어서 패치를 적용한 상태로 평가를 실행합니다. 이때 Claude는 다음을 확인합니다. train 집합은 개선되지만 test 집합은 그대로라면 과적합을 의심하고 패치를 되돌립니다. 성능이 퇴보해도 패치를 되돌립니다. 학습 집합과 테스트 집합이 모두 개선되면 패치를 유지합니다(그림 6).

힐클라이밍 루프입니다. 프롬프트 같은 수정 대상이 고정된 모델과 하네스에 입력되고, 별도로 보관한 테스트 집합과 학습 집합에서 채점됩니다. 분석기는 학습 실패만 읽고 반복마다 하나의 변경을 제안합니다. 학습과 테스트 점수가 모두 오르면 변경을 유지하고, 학습 점수만 오르거나 어느 한쪽 점수가 떨어지면 되돌립니다.

그림 6. 힐클라이머가 사용하는 절차입니다.

두세 번의 반복 동안 점수가 정체되면 Claude는 남은 학습 실패를 하나씩 읽고 원인별로 분류합니다. 단일 수정으로 얻을 수 있는 개선 폭이 평가 잡음을 넘지 못하는 경우에도 일찍 이 작업을 수행합니다. 측정하기에 너무 작은 변경에 반복 횟수를 소비하는 대신 반복 횟수나 사례 수를 늘리도록 제안합니다. 이 단계에서는 모호한 평가 사례, 하네스 오류, 실행 간 분산을 발견할 수 있습니다.

추가 힐클라이밍에는 실제로 유효한 실패 사례만 포함합니다.

힐클라이밍이 끝나면 Claude는 사용자 목표에 따라 테스트 집합에서 가장 좋은 결과를 낸 버전의 코드를 남깁니다. 기준 대비 테스트 결과를 신뢰구간과 함께 보고합니다(그림 7). 개선 폭이 잡음 범위 안이라면 이를 명시하고 병합하지 않도록 권합니다.

힐클라이밍 이후 받은편지함 라우팅 결과 페이지에서 세 가지 변형의 학습·테스트 점수를 비교합니다. 각 큐를 정의하고 동률 해소 규칙을 추가한 v1은 두 집합에서 모두 0.875로 최고 결과를 기록했습니다. 풀이 예제 두 개를 추가한 v2는 학습 점수만 오르고 테스트 점수는 그대로여서 되돌렸습니다.

그림 7. 힐클라이밍 후 생성되는 보고서의 구성 예시입니다.

사례

비용 절감을 위한 힐클라이밍

우리는 비용을 줄이고 성능을 높이기 위해 내부 고객 지원 벤치마크에서 /claude-api hillclimb을 실행했습니다. 벤치마크에는 티켓 44개가 있었으며, 30개는 탐색에 사용하고 14개는 별도로 남겨 두었습니다. 처음에는 Opus 4.8을 기본 effort 설정인 high로 실행했으며, 탐색용 티켓의 의사결정 정확도는 74.4%, 티켓당 토큰 비용은 4.6센트였습니다.

힐클라이밍은 먼저 프롬프트를 점검하여 의무적인 도구 호출 절차, 작업 메모 단계, 서로 모순되는 규칙을 제거했습니다. 이어서 Opus 5.5를 low effort로 시도했습니다. 정확도는 87.8%로 기준을 넘어섰고 비용은 티켓당 1.9센트로 줄어 초기 비용의 절반 미만이 되었습니다.

절감액 일부는 Opus 5.5의 가격 덕분입니다. 입력·출력 토큰 비용은 Opus 4.8보다 20% 낮고, 캐시 읽기 비용은 60% 낮습니다. Opus 5.5가 기준을 충족했으므로, 힐클라이밍은 한 단계 낮은 등급의 더 저렴한 모델도 기준을 충족할 수 있는지 확인했습니다. low effort의 Sonnet 5는 비슷한 정확도인 88.9%를 기록했으며, 비용은 약 절반인 티켓당 1센트였습니다(그림 8).

학습 집합의 의사결정 정확도와 티켓당 비용을 표시하여 채택된 경로를 보여줍니다. high effort의 Opus 4.8 기준 결과는 정확도 74.4%, 비용 4센트 초과였고, 이후 low effort의 Opus 5.5, 약 1센트의 low effort Sonnet 5를 거쳐, 프롬프트를 개선한 Sonnet 5에서는 정확도가 100%에 가까워졌습니다.

그림 8. 비용에 초점을 맞춘 힐클라이밍입니다.

마지막으로 Claude는 라우팅 규칙과 환불 한도에 대한 상호 참조를 추가하여 프롬프트를 개선했고, Sonnet 5는 거의 같은 비용으로 98.9%를 달성했습니다. 탐색 과정에서 전혀 보지 못한 티켓 14개에서 최종 설정은 90.5%를 기록했습니다. 원래 설정의 78.6%보다 높으면서 비용은 약 5분의 1이었습니다.

성능 개선을 위한 힐클라이밍

또 다른 사례는 claude-api 스킬입니다. 이 스킬은 우리 API 사용법과 Claude 활용을 위한 일반적인 지침을 제공하며, 이 글에서 설명한 하위 명령도 포함합니다. 우리는 스킬이 우리 API를 사용하는 코드를 올바르게 구현하는지 확인하고자 문서에서 도출한 평가 집합을 만들었습니다.

이 평가에서 스킬의 초기 점수는 66%였습니다. 힐클라이머가 문서와 SDK에 접근할 수 있도록 하여 Claude가 오류를 식별하고 스스로 수정하게 했습니다(그림 9). Claude는 스킬에 기능 여덟 가지에 대한 설명이 빠져 있음을 발견했습니다.

스킬에 해당 섹션을 추가하자 성능이 74%로 향상되었습니다. 이어서 C#과 Java 타입 표의 오류를 발견했고, 이를 수정하여 성능을 77%로 높였습니다.

claude-api 스킬 평가의 힐클라이밍 반복별 통과율입니다. 기준 66.1%에서 24번째 반복의 87.9%까지 상승합니다. 음영으로 표시한 단계는 누락된 섹션과 타입 표 추가, 스킬이 Claude에게 코드 작성을 지시하는 방식 수정, 채점기 수정과 추가 스킬 편집을 나타냅니다.

그림 9. 성능에 초점을 맞춘 힐클라이밍입니다.

두 번의 반복 동안 점수가 정체되자 Claude는 남은 실패를 분석하고 근본 원인별로 분류했습니다. 일반적인 반복에서는 가장 흔한 실패를 수정하기 위해 한 번 편집합니다. 이 단계에서는 편집하지 않고 남은 모든 실패를 원인별로 분류하기만 합니다. 이 성찰 단계는 몇 가지 면에서 유용했습니다.

시작하기

이 하위 명령은 claude-api 스킬을 통해 Claude Code에서 직접 사용할 수 있습니다.

특정 문제를 위한 평가 집합을 생성하려면 /claude-api build-eval을 실행하세요. 실행 추적 기록 같은 예제에 접근할 수 있도록 제공하여 방향을 제시할 수 있습니다. Claude는 이 글의 지침을 적용해 예제와 채점기를 설계하고, 사용자가 예제와 채점기를 승인하도록 합니다.

이미 평가가 있고 성능을 높이거나 성능을 유지하면서 비용을 줄이는 등의 목표에 따라 Claude가 개선하기를 원한다면 /claude-api hillclimb을 실행하세요. Claude는 이 글의 지침을 적용해 힐클라이밍 중 과적합을 확인합니다. 또한 첫 번째 반복을 시작하기 전과 점수가 정체될 때마다, 올바르게 보이는 답변을 오답으로 처리하는 채점기나 하네스 오류처럼 평가 자체의 버그도 확인합니다.

스킬 개발을 맡은 Misha Khalman에게 특별히 감사드립니다. 검토, 기여, 제품 지원을 해주신 Misha Khalman, Michael Segner, Matt Bell, Matt Thanabalan에게도 감사드립니다.

Deep Dive

2026-09-29

평가 데이터는 모델 학습 자료보다 시험 문제에 가깝다

처음에는 데이터 세팅이 무엇을 준비하라는 뜻인지 불분명했다. 이메일 분류 예시에서 입력, 기대 부서, 해당 사례를 포함한 이유를 한 건으로 구성하자 평가 데이터셋의 역할이 명확해졌다. 실제 서비스에 들어올 요청을 모으고 같은 문제로 변경 전후를 비교하는 것이다.

채점기도 자동으로 믿을 수 있는 것은 아니다. 사람이 입력·실제 답변·판정 이유를 함께 읽어 몇 건의 채점에 동의하는지 확인한다. 환불 가능 여부를 확인하겠다는 적절한 답변을 ‘즉시 환불하지 않았다’는 이유로 실패 처리한다면 답변보다 채점 기준을 먼저 고쳐야 한다. 사람의 역할은 모든 답을 계속 수작업으로 채점하는 것보다 자동 평가가 따를 기준을 정하고 검증하는 데 있다.

학습·테스트 분리는 외운 코스와 처음 가는 도로의 차이다

학습 집합과 테스트 집합을 나누는 이유는 운전 연습의 비유로 이해했다. 매일 같은 코스에서 ‘편의점이 보이면 차선을 바꾼다’고 외우면 그 코스는 잘 운전할 수 있다. 다른 도로에서도 표지판과 교통 상황을 보고 판단할 수 있는지는 별도 확인이 필요하다.

프롬프트에 ‘두 번이라는 표현이 있으면 결제 부서로 보낸다’고 추가하면 ‘결제가 두 번 됐어요’는 맞힐 수 있다. 그러나 ‘로그인을 두 번 시도했는데 안 돼요’까지 결제로 분류할 수 있고, ‘같은 금액이 중복으로 빠져나갔어요’는 놓칠 수 있다. 이미 본 표현에 맞춘 수정과 새로운 사례에도 통하는 규칙을 구분하기 위해 데이터를 나눈다.

여기서 학습은 모델의 가중치를 바꾸는 학습을 뜻하지 않는다. 개선하는 에이전트가 실패 기록을 참고해 프롬프트나 설정을 수정한다는 뜻이다. 테스트 입력은 평가 실행에는 사용되지만, 변경을 제안하는 에이전트에게는 상세 내용을 보여주지 않는다. 또한 같은 테스트 점수로 반복해서 변경을 고르면 그 점수에 간접적으로 맞춰질 수 있으므로, 엄격한 최종 확인에는 마지막까지 사용하지 않는 사례가 도움이 된다.

두 집합을 고정하되 데이터셋은 버전별로 갱신한다

‘학습 집합은 계속 바뀌고 테스트에는 특수한 사례만 추가하는가?’라는 의문을 해소했다. 한 번의 개선 작업에서는 두 집합과 채점 기준을 함께 고정한다. 바뀌어야 하는 것은 비교할 프롬프트나 설정이다. 문제까지 바꾸면 점수가 오른 원인을 구분할 수 없다.

테스트 집합도 흔한 요청과 어려운 요청을 포함해 실제 사용 상황을 대표해야 한다. 현재 모델이 틀리는 문제나 특수한 예외만 모으면 실제 성능을 해석하기 어렵다. 새 요청 유형, 중요한 실제 실패, 정책 변경은 다음 평가 버전에 반영한다. 기대 정답이 잘못됐거나 사라진 기능의 사례는 수정·제외할 수 있지만, 계속 틀린다는 이유만으로 사례를 빼서는 안 된다.

평가 구성이 바뀌었다면 기준 버전과 후보 버전을 모두 새 평가에서 실행한다. 문제 구성이 다른 두 점수만 비교해서 개선이라고 주장하지 않는다.

사례를 모으는 것과 매번 전부 실행하는 것은 다르다

데이터셋을 갱신한다는 설명이 무제한 누적을 뜻하는 것은 아니다. 수집한 사례는 보관하더라도, 매번 실행하는 평가에는 대표성과 비용을 고려해 사례를 선택할 수 있다. 비슷한 사례는 중복을 줄이고 중요한 과거 실패는 재발 확인에 사용한다. 서비스 범위가 넓어지거나 작은 성능 차이를 판단해야 한다면 규모를 늘린다.

수정에 이미 사용한 사례는 재발 확인에는 유용하지만 보지 못한 요청에 대한 성능 증거는 아니다. 사례의 출처뿐 아니라 수정에 노출되었는지도 관리해야 한다. 동일 사례를 반복하면 응답의 변동은 확인할 수 있지만 새로운 유형의 요청을 추가하는 효과까지 대신하지는 못한다.

평가 도구는 기존 기능을 반복 실행하고 채점하는 구조다

평가 도구가 별도의 큰 제품이어야 한다는 생각도 풀렸다. 기본 구성은 사례 데이터, 채점기, 실행기, 사례별 기록과 보고서다. 실행기가 기존 기능에 입력을 전달하고 결과를 채점하면 된다. build-eval은 이 반복 가능한 평가를 만들고, hillclimb은 변경을 적용한 뒤 재평가하여 선택한 버전과 그 근거를 남긴다.

분류 외에 대화에도 적용할 수 있다. 이전 대화를 주고 다음 답변을 평가하거나, 여러 차례 대화한 뒤 목적을 달성했는지 확인한다. 예약 대화라면 ‘예약했다’는 문장뿐 아니라 날짜·시간·인원, 사용자 동의, 도구 호출과 실제 예약 상태를 확인해야 한다.

Key Insight

프롬프트 개선을 믿으려면 대표적인 문제와 검증된 채점 기준을 고정하고, 수정에 참고한 사례와 별도로 남겨 둔 사례의 결과를 비교해야 한다. 평가 데이터는 무조건 늘리기보다 버전별로 관리하며, 이미 보고 고친 문제의 성공을 새로운 상황에 대한 실력으로 착각하지 않는다.

References