에이전트 eval 함수 해부 글 짚어보기 (5) — 0→1 로드맵과 운영

들어가며: "그래서 어떻게 시작하는가"

1편에서 eval의 구조와 8개 핵심 용어를 정리했다. 2편에서 eval이 왜 필요한지, 어떤 종류가 있는지를 다뤘다. 3편에서 grader의 유형과 설계 원칙을 해부했다. 4편에서 비결정성이라는 근본적 도전과 통계적 접근법을 살펴봤다.

구조를 알고, 이유를 알고, 도구를 알고, 측정법을 안다. 그런데 여전히 남는 질문이 있다. eval이 하나도 없는 상태에서, 어떻게 첫 번째 eval을 만들고, 그것을 실전에서 운영 가능한 시스템으로 키우는가?

원문의 마지막 파트인 "Going from zero to one"은 정확히 이 질문에 답한다. Step 0부터 Step 8까지의 로드맵을 제시하고, eval만으로는 부족한 이유를 Swiss Cheese Model로 설명한다. 이 편은 그 로드맵을 따라가며 각 단계의 사례와 함의를 풀어본다.

태스크 수집: Step 0 ~ 2

Step 0. 일찍 시작하라 — 20~50개면 충분하다

Teams delay because they think they need hundreds of tasks. In reality,
20-50 simple tasks from real failures is great start.

eval 도입을 미루는 팀의 가장 흔한 이유가 "태스크가 충분하지 않아서"다. 수백 개의 시나리오를 준비해야 할 것 같고, 그러려면 몇 주가 걸릴 것 같고, 지금은 기능 개발이 급하다. 원문은 이 인식을 정면으로 반박한다. 실제 실패 사례에서 뽑은 20~50개의 간단한 태스크면 훌륭한 시작이다.

왜 초기에는 적은 수로도 충분한가? 원문이 그 이유를 설명한다.

In early agent development, each change has clear noticeable impact →
large effect size → small sample sizes suffice.

초기 에이전트 개발에서는 변경 하나하나의 영향이 명확하게 드러난다. 효과 크기(effect size)가 크기 때문에 적은 표본으로도 충분하다. 프롬프트를 수정하면 10개 태스크 중 7개의 결과가 바뀐다. 도구 호출 로직을 고치면 15개 태스크 중 12개에 영향이 간다. 변화가 뚜렷하니까 적은 수의 태스크로도 개선 여부를 판단할 수 있다.

반대로 성숙한 에이전트에서는 이야기가 다르다.

More mature agents may need larger, more difficult evals.

에이전트가 성숙해지면 대부분의 쉬운 문제는 이미 풀린 상태다. 남은 것은 미묘한 엣지 케이스들이고, 이 경우 변경의 효과 크기가 작아진다. 작은 효과를 탐지하려면 더 많은 태스크, 더 어려운 태스크가 필요하다. 하지만 그것은 나중 일이다. 처음부터 완벽한 eval suite를 갖추려 하면 영원히 시작하지 못한다.

원문은 80/20 접근법을 권한다. 처음에는 전체 범위의 20%만 커버해도 80%의 가치를 얻을 수 있다. 그리고 결정적인 경고를 덧붙인다.

Evals get harder to build the longer you wait—early on, product
requirements naturally translate into test cases.

eval은 기다릴수록 만들기 어려워진다. 초기에는 제품 요구사항이 자연스럽게 테스트 케이스로 변환된다. "에이전트가 환불을 처리해야 한다"는 요구사항은 곧 "환불 요청 시 올바르게 처리하는가"라는 태스크다. 하지만 에이전트가 복잡해지고, 기능이 쌓이고, 엣지 케이스가 누적된 뒤에 eval을 만들려면, 무엇을 테스트해야 하는지부터 파악하는 데 시간이 걸린다. 기술 부채와 같은 구조다. 나중에 갚을수록 이자가 붙는다.

Step 1. 수동으로 하던 것부터 전환하라

Begin with manual checks you run during development. Behaviors you
verify before each release, common tasks users try.

첫 번째 태스크를 어디서 가져와야 하는지 모르겠다면, 이미 하고 있는 것에서 시작하라. 개발 중에 수동으로 확인하는 것들. 릴리스 전에 매번 검증하는 행동들. 사용자가 자주 시도하는 일반적인 태스크들. 이것들이 첫 번째 eval 태스크의 원천이다.

에이전트를 배포하기 전에 "환불 시나리오 한번 돌려볼까"라며 직접 테스트하고 있다면, 그 시나리오가 첫 번째 태스크다. "주문 조회가 되는지 확인해야지"라며 매번 수동으로 돌리고 있다면, 그것도 태스크다. 수동 테스트를 자동화하는 것이 가장 낮은 진입 장벽이다. 이미 무엇을 검증해야 하는지 알고 있으니까.

프로덕션에 이미 배포된 상태라면 원천이 하나 더 있다.

If in production: look at bug tracker and support queue. Converting
user-reported failures into test cases ensures suite reflects actual
usage. Prioritize by user impact.

버그 트래커와 고객 지원 큐를 보라. 사용자가 리포트한 실패를 태스크로 변환하면, eval suite가 실제 사용 패턴을 반영하게 된다. 사용자 영향이 큰 것부터 우선순위를 매기면 된다.

이것은 소프트웨어 테스트에서 "버그가 발견되면 재현 테스트를 먼저 작성하라"는 원칙과 동일하다. 실제로 터진 버그는 다시 터질 가능성이 높다. 그 버그를 태스크로 만들어두면 회귀(regression)를 잡는 안전망이 된다.

Step 2. 모호하지 않은 태스크를 작성하라

태스크를 모았으면, 그 태스크가 명확한지 검증해야 한다. 원문이 제시하는 리트머스 테스트가 있다.

Good task: two domain experts independently reach same pass/fail
verdict. Could they pass the task themselves? If not, needs refinement.

좋은 태스크의 기준: 두 명의 도메인 전문가가 독립적으로 같은 합격/불합격 판정에 도달하는가. 전문가 스스로가 그 태스크를 통과할 수 있는가. 둘 중 하나라도 안 된다면 태스크를 다듬어야 한다.

"고객 문의에 잘 답하라"는 모호한 태스크다. "잘"의 기준이 사람마다 다르기 때문이다. "고객이 30일 이내 주문에 대해 환불을 요청하면, 환불을 승인하고 확인 메시지를 보내라"는 명확한 태스크다. 두 전문가가 동일한 판정을 내릴 수 있다.

Ambiguity in specs becomes noise in metrics.

명세의 모호함은 메트릭의 노이즈가 된다. 태스크가 모호하면 grader의 판정이 일관되지 않고, 결과적으로 eval 점수가 불안정해진다. 점수가 올랐는지 내렸는지가 실제 개선 때문인지, 아니면 모호한 채점 때문인지 구분할 수 없게 된다. 이 문제는 LLM 기반 grader에서 특히 심각하다.

Same applies to model-based grader criteria: vague rubrics → inconsistent
judgments.

LLM judge에게 "답변이 친절한가?"라고 물으면 매번 다른 판정이 나온다. "인사로 시작하는가, 사과 표현이 포함되어 있는가, 해결 방안을 제시하는가"라고 구체적으로 물어야 일관된 결과가 나온다.

원문은 Terminal-Bench 감사 사례로 모호한 태스크의 위험을 보여준다.

Terminal-Bench audit example: task asks to write script but doesn't
specify filepath → tests assume particular filepath → agent fails
through no fault of its own.

Terminal-Bench라는 벤치마크를 감사했더니, 태스크가 "스크립트를 작성하라"고만 요구하고 파일 경로를 명시하지 않았다. 그런데 채점 로직은 특정 파일 경로에 스크립트가 있는지를 확인했다. 에이전트가 스크립트를 완벽하게 작성했어도, 다른 경로에 저장했으면 실패 처리된다. 에이전트의 잘못이 아니라 태스크의 잘못이다.

0% pass@100 is usually signal of broken task, not incapable agent.

pass@100이 0% — 즉 100번 시도해서 한 번도 통과하지 못하는 경우 — 는 대개 에이전트가 무능한 것이 아니라 태스크가 깨진 것이다. 100번 다 실패한다면, 에이전트의 능력 문제라기보다는 태스크 자체에 구조적 결함이 있을 가능성이 높다.

이 문제를 방지하는 장치가 reference solution이다.

Create reference solution: known working output that passes all graders.

reference solution은 모든 grader를 통과하는 것으로 확인된 정답 출력이다. 태스크를 만들 때 reference solution을 함께 작성하면, grader가 최소한 올바른 답을 통과시키는지 검증할 수 있다. reference solution이 grader를 통과하지 못하면, grader에 버그가 있다는 뜻이다. 이것은 일종의 "테스트의 테스트"다.

문제 세트 설계: Step 3

Step 3. 양방향 테스트를 만들어라

태스크를 모으고 명확하게 작성했다면, 다음은 태스크 세트의 균형이다.

Test both cases where behavior SHOULD occur and where it SHOULDN'T.
One-sided evals create one-sided optimization.

행동이 발생해야 하는 경우와 발생하지 않아야 하는 경우를 모두 테스트하라. 한쪽만 테스트하면 한쪽으로 치우친 최적화가 된다.

이것은 분류 문제에서 precision과 recall의 균형과 같은 원리다. recall만 최적화하면 모든 것을 양성으로 분류하고, precision만 최적화하면 아무것도 양성으로 분류하지 않는다. eval도 마찬가지다.

Example: only testing if agent searches when it should → agent searches
for everything.

에이전트가 "검색해야 할 때 검색하는가"만 테스트하면, 에이전트는 모든 질문에 검색을 시도하도록 최적화된다. 검색하면 점수가 올라가고, 안 해도 깎이지 않으니까. 결과적으로 "Apple을 누가 창업했는가?" 같은, 모델이 이미 알고 있는 질문에도 불필요하게 검색을 돌리는 에이전트가 된다.

원문이 Claude.ai의 웹 검색 eval을 구체적으로 설명한다.

Claude.ai web search eval: queries where model should search (weather)
AND queries where it should answer from knowledge ("who founded Apple?").
Balancing undertriggering vs overtriggering took many rounds of refinement.

Claude.ai의 웹 검색 eval은 두 가지 유형의 쿼리를 포함한다. 검색해야 하는 쿼리(날씨 정보)와 자체 지식으로 답해야 하는 쿼리("Apple을 누가 창업했는가?"). undertriggering(검색해야 할 때 안 하는 것)과 overtriggering(안 해도 될 때 하는 것)의 균형을 잡는 데 여러 라운드의 개선이 필요했다.

이 사례가 보여주는 교훈은 양방향 테스트가 단순히 "긍정/부정 케이스를 반반 넣자"가 아니라는 점이다. 검색 트리거의 경계선을 찾는 것이 핵심이다. "서울 오늘 날씨"는 명확히 검색해야 하고, "Apple 창업자"는 명확히 안 해도 된다. 하지만 "최신 iPhone 가격"은? "지난주 삼성 주가"는? 경계선 근처의 케이스가 eval을 정교하게 만든다. 그리고 이 경계선은 한 번에 정해지지 않는다. 여러 라운드의 반복이 필요하다.

eval harness와 grader 설계: Step 4 ~ 5

Step 4. 안정적인 환경에서 실행하라

태스크와 문제 세트가 준비되었다면, 이제 이것을 실행할 인프라가 필요하다. 1편에서 evaluation harness라는 용어를 정의했다. Step 4는 이 harness가 갖춰야 할 핵심 속성을 다룬다.

Agent in eval must function roughly same as production agent. Each trial
should be "isolated"—start from clean environment.

두 가지 원칙이 있다. 첫째, eval 환경의 에이전트는 프로덕션 에이전트와 거의 동일하게 동작해야 한다. eval에서는 잘 되는데 프로덕션에서 안 되면 eval의 의미가 없다. 둘째, 각 trial은 격리되어야 한다. 깨끗한 환경에서 시작해야 한다.

trial 격리가 왜 중요한지, 원문이 두 가지 방향에서 설명한다.

Shared state between runs (leftover files, cached data, resource
exhaustion) causes correlated failures. Shared state can also
artificially inflate performance.

공유 상태는 성능을 실제보다 낮게 만들 수도 있고 높게 만들 수도 있다. 이전 trial에서 남은 파일, 캐시된 데이터, 자원 고갈이 다음 trial에 영향을 미치면 연관된 실패(correlated failures)가 발생한다. 하나의 환경 문제가 여러 trial을 동시에 망치면, trial들이 독립적이지 않게 되고, 점수의 의미가 사라진다.

반대로, 공유 상태가 성능을 부풀릴 수도 있다. 원문이 놀라운 사례를 소개한다.

Example: Claude gaining unfair advantage by examining git history from
previous trials.

Claude가 이전 trial의 git history를 검사해서 부당한 이점을 얻은 경우다. trial A에서 에이전트가 코딩 문제를 풀면서 git commit을 남겼다. trial B에서 비슷한 문제를 풀 때, 에이전트가 git log를 확인해서 trial A의 풀이를 참고했다. trial B의 점수는 올라갔지만, 이것은 에이전트의 실력이 아니라 환경 오염의 결과다. 프로덕션에서는 이전 trial의 git history가 없으므로, 이 점수는 프로덕션 성능을 과대평가한다.

If multiple trials fail due to same environment limitation (like CPU
memory), trials not independent → unreliable results.

여러 trial이 같은 환경 제한(예: CPU 메모리 부족) 때문에 실패하면, trial들은 독립적이지 않고 결과는 신뢰할 수 없다. "10개 중 3개만 통과"라는 결과가 나왔는데, 실패한 7개가 모두 메모리 부족 때문이라면, 에이전트의 통과율은 30%가 아니라 사실상 100%에 가깝다. 환경 문제를 에이전트 능력의 문제로 오해하게 된다.

실전에서 trial 격리를 구현하는 방법은 여러 가지다. Docker 컨테이너로 각 trial을 실행하거나, 가상 머신을 trial마다 새로 프로비저닝하거나, 최소한 작업 디렉토리를 trial마다 초기화하는 방식이 있다. 비용과 격리 수준 사이의 트레이드오프가 있지만, 핵심은 이전 trial의 흔적이 다음 trial에 영향을 미치지 않아야 한다는 것이다.

Step 5. grader를 신중하게 설계하라

harness가 준비되었다면, 그 안에서 동작할 grader를 설계해야 한다. 3편에서 grader의 유형을 자세히 다뤘는데, Step 5는 설계 원칙에 초점을 맞춘다.

Choose deterministic graders where possible, LLM graders where
necessary, human graders judiciously.

가능하면 결정론적 grader, 필요하면 LLM grader, 신중하게 인간 grader를 선택하라. 이 우선순위가 중요하다. 결정론적 grader(코드 기반, 정규식 매칭, 값 비교)는 빠르고 일관되며 비용이 없다. LLM grader는 유연하지만 비결정적이고 비용이 든다. 인간 grader는 가장 정확하지만 가장 느리고 비싸다.

결과를 채점하라, 경로를 채점하지 말라

grader 설계에서 가장 흔한 실수를 원문이 짚는다.

Common instinct to check agents followed specific steps (sequence of
tool calls)—too rigid, brittle. Agents regularly find valid approaches
eval designers didn't anticipate.

에이전트가 특정 단계(도구 호출 순서)를 따랐는지 확인하려는 것이 흔한 본능이다. 하지만 이것은 너무 경직되고 깨지기 쉽다. 에이전트는 eval 설계자가 예상하지 못한 유효한 접근법을 자주 찾는다.

1편에서 다뤘던 Opus 4.5의 tau2-bench 사례가 정확히 이것이다. 항공사 정책의 허점을 발견해서 고객에게 더 좋은 결과를 만들었지만, "표준 경로를 따르지 않았다"는 이유로 실패 처리되었다. 경로를 채점하면 이런 일이 반복된다.

"Grade what the agent produced, not the path it took."

에이전트가 생산한 것을 채점하라, 에이전트가 거친 경로를 채점하지 말라. 이것이 grader 설계의 핵심 원칙이다. "주문 조회 API를 호출한 뒤 환불 API를 호출했는가"가 아니라, "올바른 주문이 환불 처리되었는가"를 검증해야 한다.

부분 점수를 설계하라

Build in partial credit—agent that identifies problem and verifies
customer but fails refund is better than immediate failure.

부분 점수를 설계하라. 문제를 식별하고 고객을 확인했지만 환불에 실패한 에이전트는, 즉시 실패하는 에이전트보다 낫다. 이진(pass/fail) 채점만 있으면 "거의 성공"과 "완전 실패"를 구분할 수 없다.

에이전트 개발에서 부분 점수가 특히 중요한 이유가 있다. 에이전트의 태스크는 대개 여러 단계로 구성된다. 환불 처리를 예로 들면: (1) 고객 인증, (2) 주문 조회, (3) 환불 정책 확인, (4) 환불 실행, (5) 확인 메시지 전송. 이 중 4단계까지 성공하고 5단계에서 실패한 에이전트와, 1단계에서부터 실패한 에이전트는 완전히 다른 수준의 문제를 가지고 있다. 이진 채점에서는 둘 다 0점이다. 부분 점수에서는 80%와 0%다. 어디에서 실패하는지를 보여주므로, 어디를 고쳐야 하는지도 알 수 있다.

LLM judge의 보정

LLM grader를 사용해야 하는 경우, 원문이 몇 가지 실천 지침을 제시한다.

LLM-as-judge: calibrate with human experts, give LLM a way out
("Unknown"), structured rubrics, grade each dimension with isolated LLM
judge.

인간 전문가로 보정: LLM judge의 판정을 인간 전문가의 판정과 비교해서, LLM이 일관되게 틀리는 패턴을 찾는다.
"Unknown" 옵션 제공: LLM에게 판정을 강제하지 말고, "판단할 수 없음" 옵션을 줘라. 확실하지 않은 경우 틀린 판정보다 판단 유보가 낫다.
구조화된 루브릭: 모호한 지시("답변이 좋은가?") 대신 구체적인 채점 기준을 제공하라.
차원별 분리된 LLM judge: 여러 측면을 한 번에 채점하지 말고, 각 차원(정확성, 완결성, 톤 등)을 별도의 LLM 호출로 채점하라. 한 호출에서 여러 기준을 채점하면 기준 간 간섭이 발생한다.

CORE-Bench 사례: 42%에서 95%로

원문에서 가장 인상적인 사례 중 하나가 CORE-Bench다.

CORE-Bench example: Opus 4.5 initially scored 42%, researcher found:
rigid grading ("96.12" vs "96.124991…"), ambiguous specs, stochastic
tasks. After fixes, jumped to 95%.

CORE-Bench에서 Opus 4.5의 초기 점수는 42%였다. 연구자가 실패 사례를 분석해보니, 에이전트의 문제가 아니라 eval의 문제였다.

경직된 채점: 정답이 "96.12"인데 에이전트가 "96.124991..."을 출력하면 오답 처리. 반올림 차이를 틀린 답으로 판정한 것이다.
모호한 명세: 태스크의 요구사항이 불명확해서 에이전트가 합리적인 해석을 했음에도 틀린 것으로 처리됨.
확률적 태스크: 태스크 자체에 무작위성이 있어서 매번 다른 결과가 나옴. 정답이 하나로 정해질 수 없는 문제를 고정된 정답으로 채점한 것.

이 문제들을 수정한 뒤 점수가 95%로 뛰었다. 42%와 95%의 차이는 에이전트의 능력이 아니라 eval의 품질이었다. 이것이 Step 2에서 강조한 "모호하지 않은 태스크"와 Step 5의 "결과 채점 원칙"이 실전에서 얼마나 중요한지를 보여주는 사례다.

METR 사례: 지시를 따른 모델을 처벌하는 eval

METR example: misconfigured tasks asked to optimize TO stated score
threshold, but grading required EXCEEDING it. Penalized models following
instructions.

METR 벤치마크의 사례는 다른 유형의 grader 결함이다. 태스크가 "점수 임계값까지 최적화하라"(TO)고 지시했는데, grader는 "임계값을 초과"(EXCEEDING)해야 통과로 판정했다. 지시를 정확히 따른 모델이 처벌받은 것이다.

태스크의 지시와 grader의 기준이 불일치한 전형적인 케이스다. "90점까지 올려라"라고 지시받은 에이전트가 정확히 90점을 달성했는데, grader가 "90점 초과"를 요구해서 불합격. 에이전트가 지시를 어기고 91점을 달성했다면 합격. 지시를 잘 따르는 모델이 불이익을 받는 역설적 상황이다.

이런 문제를 방지하려면, reference solution을 만들어서 grader를 먼저 검증하는 Step 2의 원칙으로 돌아간다. 태스크의 지시를 정확히 따르는 reference solution이 grader를 통과하는지 확인하면, 이런 불일치를 사전에 발견할 수 있다.

우회 방지

Make graders resistant to bypasses/hacks—passing should require actually
solving the problem.

grader를 우회(bypass)에 저항적으로 만들어라. 통과하려면 실제로 문제를 풀어야 하도록 설계해야 한다. 에이전트가 결과를 위조하거나, 채점 기준의 허점을 이용해서 실제로 문제를 풀지 않고 통과하는 경우를 방지해야 한다.

예를 들어, 코딩 태스크의 grader가 "특정 문자열이 stdout에 출력되는가"만 확인한다면, 에이전트는 echo "expected output"만 실행해도 통과할 수 있다. grader가 "제출된 코드가 여러 입력에 대해 올바른 출력을 내는가"를 확인해야 실제 문제 풀이를 요구할 수 있다.

장기 운영: Step 6 ~ 8

Step 6. transcript를 읽어라

Step 0~5까지는 eval을 구축하는 단계였다. Step 6부터는 운영 단계다. 그리고 운영의 첫 번째 원칙이 의외로 단순하다.

Won't know if graders work unless you read transcripts and grades from
many trials.

많은 trial의 transcript와 채점 결과를 직접 읽지 않으면, grader가 제대로 동작하는지 알 수 없다. 자동화의 역설이다. eval을 자동화했지만, 자동화가 올바르게 작동하는지는 사람이 확인해야 한다.

At Anthropic: invested in tooling for viewing eval transcripts, regularly
read them.

Anthropic은 eval transcript를 보기 위한 도구에 투자했고, 정기적으로 transcript를 읽는다. 이것은 대기업이라서가 아니라, transcript를 읽지 않으면 eval의 문제를 발견할 수 없기 때문이다.

transcript를 읽으면 두 가지를 판별할 수 있다.

When task fails: transcript tells if agent made genuine mistake or
graders rejected valid solution. Failures should seem fair.

태스크가 실패했을 때, transcript를 보면 에이전트가 실제로 실수한 것인지, grader가 유효한 해법을 거부한 것인지 알 수 있다. 실패가 "공정해 보여야" 한다. CORE-Bench의 42% 점수를 transcript 없이 받아들였다면, Opus 4.5의 실제 능력을 심각하게 과소평가했을 것이다.

When scores don't climb: confidence needed that it's agent performance,
not eval.

점수가 오르지 않을 때도 transcript가 필요하다. 점수 정체가 에이전트의 성능 한계인지, eval의 문제인지 확신이 필요하다. 에이전트를 개선했는데 점수가 안 오른다면, 두 가지 가능성이 있다: (1) 개선이 실제로 효과가 없다, (2) eval이 개선을 감지하지 못한다. transcript를 읽으면 어느 쪽인지 판단할 수 있다.

Reading transcripts is critical skill for agent development.

원문은 이것을 "기술(skill)"이라고 표현한다. transcript를 읽는 것은 단순한 작업이 아니라 에이전트 개발의 핵심 역량이다. 에이전트가 어디서 헤매는지, 어떤 패턴으로 실패하는지, 도구 호출을 어떤 순서로 하는지를 관찰하면, 점수만 보는 것과는 질적으로 다른 인사이트를 얻는다.

Step 7. 역량 eval의 포화를 모니터링하라

Eval at 100% tracks regressions but provides no signal for improvement.

eval 점수가 100%에 도달하면 회귀를 추적할 수는 있지만, 개선의 신호를 제공하지 못한다. 모든 태스크를 통과하면 "더 잘했다"를 측정할 방법이 없다.

Eval saturation: agent passes all solvable tasks.

eval 포화(saturation)란 에이전트가 풀 수 있는 모든 태스크를 통과한 상태를 말한다.

SWE-Bench Verified: started at 30%, nearing saturation at over 80%.

SWE-Bench Verified가 이 현상을 보여주는 대표적인 사례다. 초기에는 30% 수준이었던 벤치마크가 현재 80%를 넘기며 포화에 접근하고 있다. 포화에 가까워지면 무슨 일이 벌어지는가?

As evals approach saturation, progress slows—only most difficult tasks
remain. Large capability improvements appear as small score increases.

포화에 접근하면 진보가 느려진다. 가장 어려운 태스크만 남기 때문이다. 큰 역량 향상이 작은 점수 증가로 나타난다. 에이전트의 추론 능력을 크게 개선했는데, SWE-Bench 점수가 85%에서 87%로만 올랐다면, 실제 개선은 상당하지만 수치로는 미미해 보인다. 남은 15%가 모두 극도로 어려운 문제이기 때문이다.

원문이 Qodo의 사례를 소개한다.

Qodo example: initially unimpressed by Opus 4.5 because one-shot coding
evals didn't capture gains on longer complex tasks. Developed new agentic
eval framework.

Qodo라는 회사가 Opus 4.5를 처음 평가했을 때 인상적이지 않았다. 기존의 one-shot 코딩 eval(한 번에 코드를 생성하는 평가)에서 큰 차이가 없었기 때문이다. 하지만 실제 사용에서는 더 긴, 더 복잡한 태스크에서 상당한 개선이 있었다. 기존 eval이 포화 상태여서 개선을 감지하지 못한 것이다. Qodo는 새로운 에이전틱 eval 프레임워크를 개발해서 이 문제를 해결했다.

이 사례의 교훈이 있다.

Rule: do not take eval scores at face value until someone digs into
details and reads transcripts.

누군가가 세부 사항을 파고들고 transcript를 읽기 전까지, eval 점수를 액면 그대로 받아들이지 말라. 점수가 낮으면 eval에 문제가 있을 수 있고, 점수가 높으면 eval이 포화 상태일 수 있다. 어느 경우든 transcript를 읽어야 진짜 상황을 알 수 있다.

Step 8. eval suite를 장기적으로 건강하게 유지하라

Eval suite is living artifact, needs ongoing attention and clear
ownership.

eval suite는 살아 있는 산출물이다. 지속적인 관심과 명확한 소유권이 필요하다. 한 번 만들고 방치하면, 제품은 변하는데 eval은 제자리에 머물러서 실제 사용 패턴과 괴리가 생긴다.

Anthropic: dedicated evals teams own core infrastructure, domain
experts/product teams contribute tasks and run evaluations.

Anthropic의 조직 구조를 보면, 전담 eval 팀이 핵심 인프라를 소유하고, 도메인 전문가와 제품 팀이 태스크를 기여하고 eval을 실행한다. eval은 한 팀만의 책임이 아니다. 인프라(harness, grader 프레임워크)는 전문 팀이 관리하고, 태스크(실제 테스트 시나리오)는 제품을 가장 잘 아는 팀이 작성한다.

Owning and iterating on evals should be as routine as maintaining unit
tests.

eval을 소유하고 반복 개선하는 것은 단위 테스트를 유지보수하는 것만큼 일상적이어야 한다. 단위 테스트를 한 번 작성하고 영영 손대지 않는 팀은 없다. 기능이 추가되면 테스트가 추가되고, 요구사항이 바뀌면 테스트가 수정된다. eval도 마찬가지다.

원문은 eval이 제품 요구사항을 정제하는 도구이기도 하다고 강조한다.

Teams can waste weeks on AI features that "work" in early testing but
fail unstated expectations. Defining eval tasks is one of best ways to
stress-test product requirements.

팀이 초기 테스트에서 "작동하는" AI 기능에 몇 주를 낭비할 수 있다. 명시되지 않은 기대를 충족하지 못하기 때문이다. eval 태스크를 정의하는 것은 제품 요구사항을 스트레스 테스트하는 가장 좋은 방법 중 하나다.

"에이전트가 환불을 처리해야 한다"는 요구사항이 있다면, eval 태스크를 만들려고 할 때 비로소 질문이 구체화된다. 부분 환불도 되어야 하는가? 30일이 지난 주문은? 프로모션 할인이 적용된 주문은? 이런 질문들이 eval 태스크를 작성하는 과정에서 자연스럽게 떠오른다. eval이 요구사항의 빈틈을 드러내는 것이다.

Eval-driven development: build evals before agents can fulfill them.

이것이 eval-driven development다. 에이전트가 충족할 수 있기 전에 eval을 먼저 만든다. TDD(Test-Driven Development)의 AI 버전이다. 테스트를 먼저 작성하고, 그 테스트를 통과하도록 코드를 작성하는 것처럼, eval을 먼저 정의하고, 그 eval을 통과하도록 에이전트를 개발한다.

PM, CSM, salespeople can contribute eval tasks as PRs—actively enable
them.

마지막으로, eval 태스크 기여를 개발팀 바깥으로 확장하라. PM, CSM(Customer Success Manager), 영업 담당자가 eval 태스크를 PR로 기여할 수 있게 적극적으로 지원하라. 고객을 가장 자주 만나는 사람들이 가장 현실적인 태스크를 만들 수 있다. 영업 담당자가 "이 시나리오에서 고객이 불만을 제기했다"라고 리포트하면, 그것이 곧 eval 태스크가 된다. 기여 경로를 열어두는 것이 eval suite의 현실 반영도를 높이는 핵심이다.

Swiss Cheese Model: eval만으로는 부족하다

로드맵 8단계를 모두 밟았다고 해서 끝이 아니다. 원문은 eval이 평가 방법의 전부가 아님을 분명히 한다.

No single evaluation layer catches every issue. Multiple methods
combined → failures that slip through one layer caught by another.

어떤 단일 평가 레이어도 모든 이슈를 잡지 못한다. 여러 방법을 결합하면, 한 레이어를 빠져나간 실패가 다른 레이어에서 잡힌다. 이것이 Swiss Cheese Model이다.

스위스 치즈는 구멍이 있다. 한 장으로는 빛이 통과할 수 있다. 하지만 여러 장을 겹치면, 한 장의 구멍이 다른 장의 막힌 부분과 겹쳐서 빛이 통과하지 못한다. 각 평가 방법이 치즈 한 장이다. 구멍(놓치는 이슈)이 있지만, 여러 장을 겹치면 전체적으로 견고해진다.

원문은 6가지 평가 방법을 비교한다.

방법	장점	단점
자동화된 eval	빠른 반복, 재현 가능, 사용자 영향 없음, 커밋마다 실행 가능, 규모 있는 테스트	초기 투자 필요, 지속적 유지보수 필요, 실사용과 불일치 시 거짓 확신
프로덕션 모니터링	실제 사용자 행동, 합성 eval이 놓치는 이슈 포착, 실제 데이터(ground truth)	사후 대응적, 노이즈 많음, 계측 필요, 채점 기준 부재
A/B 테스트	실제 사용자 결과, 교란 변수 통제, 체계적	느림(수일~수주), 배포된 변경만 테스트, "왜"에 대한 신호 부족
사용자 피드백	예상치 못한 문제 발견, 실제 사례, 목표와 상관관계	드문 빈도, 자기 선택적, 심각한 경우로 편향, 자동화 불가
수동 transcript 리뷰	직관 형성, 미묘한 이슈 포착, 품질 기준 보정	시간 집약적, 규모 확장 불가, 일관성 부족, 리뷰어 피로
체계적 인간 연구	황금 표준, 주관적 태스크 처리 가능, 모델 기반 grader 개선	비용 높음, 느림, 평가자 간 불일치, 전문가 필요

각 방법의 적용 시점이 다르다.

자동화된 eval: 출시 전 + CI/CD, 첫 번째 방어선
프로덕션 모니터링: 출시 후, 분포 드리프트와 예상치 못한 실패 감지
A/B 테스트: 충분한 트래픽이 있는 유의미한 변경 검증
사용자 피드백 + transcript 리뷰: 지속적, 다른 방법의 빈틈 채움
체계적 인간 연구: LLM grader 보정, 주관적 출력 평가

Most effective teams combine: automated evals for fast iteration,
production monitoring for ground truth, periodic human review for
calibration.

가장 효과적인 팀은 이것들을 조합한다. 빠른 반복을 위한 자동화된 eval, 실제 데이터를 위한 프로덕션 모니터링, 보정을 위한 주기적 인간 리뷰.

자동화된 eval만으로는 실제 사용 패턴의 변화를 감지할 수 없다. 프로덕션 모니터링만으로는 사후 대응적이다. 인간 리뷰만으로는 규모 확장이 안 된다. 세 가지를 겹치면, 각각의 구멍을 다른 것이 메운다.

이것은 소프트웨어 엔지니어링의 테스트 피라미드와 유사한 구조다. 단위 테스트(빠르고 많음), 통합 테스트(중간), E2E 테스트(느리고 적음), 수동 QA가 겹겹이 쌓여서 전체 품질을 담보한다. AI 에이전트에서는 자동화된 eval이 단위 테스트에, 프로덕션 모니터링이 로깅/모니터링에, 인간 리뷰가 수동 QA에 대응한다.

시리즈 마무리: 5편을 한 줄로 되돌아보며

이 시리즈에서 다룬 내용을 한 줄씩 요약한다.

1편 (구조와 용어 사전): eval은 task, trial, grader, transcript, outcome, evaluation harness, agent harness, evaluation suite의 8개 구성 요소로 이루어진다.
2편 (왜 eval이 필요한가): eval 없이는 reactive loop에 갇히고, capability eval과 quality eval이라는 두 축으로 에이전트의 다른 측면을 측정한다.
3편 (grader 유형): 코드 기반 grader, LLM 기반 grader, 인간 grader 각각에 트레이드오프가 있고, 경로가 아닌 결과를 채점하는 것이 원칙이다.
4편 (비결정성과 통계): AI의 비결정적 출력은 eval 결과에 노이즈를 만들고, 이를 다루려면 여러 trial과 통계적 추론이 필요하다.
5편 (로드맵과 운영): 20~50개 태스크로 일찍 시작하고, 양방향 테스트를 설계하고, 환경을 격리하고, transcript를 읽고, Swiss Cheese Model로 다층 방어를 구축한다.

원문의 결론이 이 시리즈 전체를 관통하는 메시지를 요약한다.

Start early, read transcripts, iterate continuously.

일찍 시작하라. transcript를 읽어라. 계속 반복하라.

eval은 완성되는 것이 아니라 계속 진화하는 것이다. 에이전트가 변하면 eval도 변해야 하고, eval이 변하면 에이전트도 변한다. 이 피드백 루프가 AI 에이전트의 신뢰성을 만든다. 프롬프트를 고치고 기도하는 대신, eval을 만들고 측정하고 개선하는 것. 그것이 원문이 전달하려는 핵심이다.

원문 전체는 여기서 읽을 수 있다: Demystifying Evals for AI Agents — Anthropic Engineering Blog