본문으로 건너뛰기

Claude 에이전트 평가하기 (Evals)

고급

프롬프트를 손봤더니 더 좋아진 느낌이 듭니다 — 그런데 정말 그럴까요? **평가(evals, evaluations)**가 없으면 눈을 가린 채 비행하는 셈입니다. 모든 변경이 동전 던지기이고, 무언가 망가진 것을 테스트가 아니라 화난 사용자를 통해 알게 됩니다. 평가는 "감"을 신뢰하고, 방어하고, 시간에 따라 지켜볼 수 있는 숫자로 바꿔줍니다. 이것이 취미 수준의 프롬프트와 프로덕션급 Claude 작업을 가르는 가장 큰 단 하나의 차이입니다.

What you'll learn
  • "내가 보기엔 괜찮은데"가 테스트가 아닌 이유 — 그리고 대신 무엇을 측정해야 하는지
  • 상상한 실패가 아니라 실제(REAL) 실패로부터 (상향식으로) 골든 데이터셋 구축하기
  • 가능한 곳에서는 코드로 채점하고, 불가능한 곳에서는 LLM-as-judge로 채점하기
  • 프롬프트나 모델 변경이 조용히 회귀할 수 없도록 평가를 CI에 연결하기

사고방식: 추측하지 말고 측정하라​

당신을 구해줄 세 가지 규칙:

  • 상향식이 하향식을 이긴다. 실제 실패를 먼저 수집한 다음, 그것을 잡아내도록 지표를 설계하세요. 실제 고장에서 만든 평가는 실제 고장을 예측하지만, 화이트보드에서 발명한 평가는 대부분 당신의 상상력을 측정할 뿐입니다.
  • 다시 실행할 수 있는 숫자. 평가는 반복 가능합니다: 같은 입력 → 비교 가능한 점수. 그래야 프롬프트 v1과 v2, 또는 claude-haiku-4-5와 claude-sonnet-5를 정직하게 비교할 수 있습니다.
  • 실행 비용이 싸고, 자주 실행한다. 사람이 반나절 걸리는 일이라면 하지 않게 됩니다. 자동화하세요.

골든 데이터셋 구축하기 (상향식)​

골든 데이터셋은 모든 평가의 핵심입니다 — 정답이 알려진 기대값을 가진 입력들을 엄선한 모음입니다.

Guided walkthrough1 of 4
  1. 실제로 나쁜 출력에서 시작하세요: 프로덕션 트레이스, 버그 리포트, 지원 티켓. 이것들이 중요한 케이스입니다.

채점: 코드가 먼저, 판정자가 나중​

가장 싸고 믿을 수 있는 검사를 먼저 잡으세요.

  • 프로그래밍적(결정론적) 검사 — 답에 구조가 있는 곳이라면 어디서든 사용하세요: 정확/키워드 일치, "이 스키마에 유효한 JSON인가", "올바른 인자로 올바른 도구를 호출했는가", "N 토큰 미만 / X ms 미만". 빠르고, 공짜이며, 절대 불안정하지 않습니다.
  • LLM-as-judge — 코드로 다루기 어려운 모호한 차원(유용성, 어조, 출처에 대한 충실도)에 사용하세요. 판정자에게 감이 아니라 **루브릭(rubric)**을 주고, 신뢰하기 전에 사람이 매긴 레이블에 대해 보정하세요.

:::warning 판정자에게는 편향이 있다 LLM 판정자는 더 긴 답변 쪽으로(장황함 편향), 그리고 먼저 보여지는 선택지 쪽으로(위치 편향) 치우칩니다. 방어책: 엄격한 루브릭, 절대 점수 대신 쌍대(pairwise) 비교, 답변 순서 바꾸기, 그리고 사람이 레이블한 일부에 대해 판정자를 다시 확인하기. 판정자는 하나의 층일 뿐, 테스트 전체가 아닙니다. :::

LLM-as-judge 루브릭 (시작용)

You are a strict grader. You are given a QUESTION, a REFERENCE answer, and a MODEL answer.
Score the MODEL answer from 1-5 on (a) faithfulness to the reference and (b) helpfulness.
Output ONLY JSON, nothing else: {"score": <1-5>, "reason": "<one short sentence>"}

QUESTION: {{question}}
REFERENCE: {{reference}}
MODEL: {{model_answer}}

에이전트의 경우, *궤적(trajectory)*도 테스트하라​

에이전트는 옳은 최종 답에 도달하되 잘못된 방식으로 도달할 수 있습니다 — 루프에 빠지거나, 파괴적인 도구를 호출하거나, 예산을 태워버리면서요. 그러니 목적지뿐 아니라 경로를 평가하세요: 올바른 도구를, 합리적인 순서로, 루프 없이, 예산 안에서 호출했는가? 도구 호출 정확성과 궤적 검사는 최종 답만 보는 평가로는 결코 볼 수 없는 실패를 잡아냅니다.

CI에 연결하기​

여기서 평가가 진가를 발휘합니다: 회귀를 병합할 수 없게 만드세요.

Guided walkthrough1 of 3
  1. 가능한 곳은 프로그래밍적으로 채점하고, 나머지는 판정자로 실행하세요.
평가 어휘
Enter 또는 스페이스 키를 눌러 카드를 뒤집습니다. 좌우 화살표 키로 카드를 이동할 수 있습니다.용어가 표시되었습니다.
1 / 4

스스로 확인하기

0/3
  1. 평가를 채점할 때 가장 믿을 만한 첫 번째 선택은 무엇인가?
  2. 골든 데이터셋의 케이스는 주로 어디에서 와야 하는가?
  3. 에이전트(AGENT)의 경우, 최종 답 외에 무엇을 평가해야 하는가?
Key takeaways
  • 평가 없음 = 감으로 배포하기. 프롬프트나 에이전트를 신뢰하기 전에 하나 구축하세요.
  • 실제 실패로부터 골든 데이터셋을 만들고, 매주 새 회귀로 키우세요.
  • 코드 기반 검사가 먼저; 모호한 부분에는 (루브릭과 함께, 보정된) LLM-as-judge.
  • 에이전트의 경우, 출력만이 아니라 궤적을 채점하세요.
  • CI에서 실행하고 점수가 떨어지면 빌드를 실패시키세요 — 그것이 품질 회귀를 멈추는 방법입니다.

출처 및 더 읽을거리​

다음​