에이전트 eval 함수 해부 글 짚어보기 (1) — eval의 구조와 용어 사전

들어가며: 프로덕션에서 터진 버그를 eval이 잡았어야 했다

에이전트를 만들어서 배포했다. 고객 문의에 답변하는 에이전트다. 테스트할 때는 괜찮았다. 몇 가지 시나리오를 직접 돌려보고, 답변 품질이 나쁘지 않아서 릴리스했다. 이틀 뒤 슬랙에 알림이 쏟아진다. 에이전트가 환불 정책을 잘못 안내했다. 30일 환불 기한을 "90일"이라고 답했다. 한 건이 아니라, 같은 유형의 질문에 반복적으로 틀린 답을 내고 있었다.

프롬프트를 고쳤다. 다시 배포했다. 사흘 뒤 또 터진다. 이번에는 배송 추적 도구를 호출하면서 주문번호를 잘못 파싱해서 다른 고객의 배송 정보를 보여줬다. 고치고, 배포하고, 또 터지고. 이 루프에 갇히면 에이전트 개발은 소방 작업이 된다.

Anthropic 엔지니어링 블로그의 Demystifying Evals for AI Agents는 이 문제에서 출발한다.

Good evaluations help teams ship AI agents more confidently, develop them
faster, and maintain quality as they evolve. Without them, teams get stuck
in reactive loops—catching issues only in production and relying on
anecdotal testing that leaves blind spots.

"reactive loops" — 정확히 위의 시나리오다. 프로덕션에서 이슈가 터져야 발견하고, 일화적 테스트(anecdotal testing)에 의존하면 사각지대가 남는다. eval은 이 루프를 끊는 도구다.

이 시리즈는 원문을 따라가며 해설하는 글이다. 원문은 Anthropic이 실전 배포 사례에서 배운 eval 설계법을 공유하는데, Building effective agents 후속편 성격이다. 이번 1편에서는 eval의 기본 구조와 8개 핵심 용어를 정리한다. 이 용어들이 이후 편에서 계속 쓰이므로, 여기서 정확히 잡아두는 것이 중요하다.

1. eval의 세 단계: single-turn에서 agent eval까지

가장 단순한 형태: single-turn evaluation

eval의 가장 단순한 형태는 이렇다.

At its simplest, an evaluation ("eval") is a test for an AI system: give
an AI an input, then apply grading logic to its output.

프롬프트 하나를 넣고, 응답 하나를 받고, 채점 로직을 적용한다. 단위 테스트와 구조가 같다. 입력, 출력, 검증. "수도가 뭐야?"라고 물으면 "서울"이라고 답해야 하고, 채점 로직이 정답 여부를 판정한다.

이 수준의 eval은 만들기 쉽다. 프롬프트-응답 쌍을 모아서 정답과 비교하면 된다. 기존 소프트웨어 테스트와 크게 다르지 않다.

복잡도의 첫 번째 점프: multi-turn evaluation

Single-turn evaluations—a prompt, a response, and grading logic—are
relatively straightforward and well-documented. Multi-turn evaluations
are increasingly common as AI capabilities advance.

대화가 여러 턴에 걸쳐 이어지면 평가가 달라진다. 한 턴의 응답이 다음 턴의 맥락이 되고, 이전 대화를 제대로 기억하는지, 맥락을 유지하는지까지 검증해야 한다. 채점 대상이 단일 응답에서 대화 전체로 확장된다.

"지난번에 말한 주문 건 확인해줘"라고 했을 때, 에이전트가 이전 대화에서 언급된 주문번호를 기억하고 있는지. 이건 단일 턴 eval로는 잡을 수 없다.

복잡도의 두 번째 점프: agent evaluation

Agent evaluations are even more complex. Agents use tools across many
turns, modifying state. Mistakes can propagate and compound.

에이전트 eval은 여기서 한 단계 더 뛴다. 에이전트는 도구를 사용한다. 데이터베이스를 조회하고, API를 호출하고, 파일을 수정한다. 각 도구 호출이 환경의 상태를 바꾸고, 바뀐 상태가 다음 결정에 영향을 준다. 실수가 전파되고 누적된다(propagate and compound).

고객 지원 에이전트가 환불을 처리한다고 해 보자. 에이전트는 (1) 주문 조회 도구를 호출하고, (2) 환불 정책을 확인하고, (3) 환불 처리 도구를 실행한다. 1단계에서 주문번호를 잘못 파싱하면, 2단계에서 다른 고객의 주문에 대한 환불 정책을 확인하고, 3단계에서 엉뚱한 주문을 환불 처리한다. 한 단계의 실수가 이후 모든 단계로 전파된다.

원문은 이 복잡성의 근본 원인을 이렇게 짚는다.

These same capabilities that make agents useful—autonomy, intelligence,
flexibility—also make them harder to evaluate.

에이전트를 유용하게 만드는 바로 그 특성들 -- 자율성, 지능, 유연성 -- 이 평가를 어렵게 만든다. 자율적으로 판단하니까 예측 불가능하고, 지능적으로 행동하니까 평가자도 똑똑해야 하고, 유연하게 대처하니까 정해진 정답이 없을 수 있다.

이 세 단계의 진화를 정리하면 이렇다.

단계	평가 대상	복잡성 원인
Single-turn	단일 응답	없음 (입력-출력 비교)
Multi-turn	대화 전체	맥락 유지, 턴 간 의존성
Agent	대화 + 도구 호출 + 환경 상태	상태 변경, 실수 전파, 비결정적 경로

원문에는 이 차이를 보여주는 다이어그램이 있다. 왼쪽의 단순한 eval은 프롬프트 → 응답 → 채점의 직선이다. 오른쪽의 복잡한 코딩 에이전트 eval은 여러 도구 호출, 분기, 상태 변경이 얽힌 그래프다. 직선과 그래프의 차이만큼 평가의 난이도가 다르다.

2. 용어 사전: 8개 핵심 개념

원문은 eval의 구성 요소를 8개 용어로 정의한다. 이 용어들은 이후 편에서 계속 등장하므로 하나씩 짚어둔다.

2-1. task (문제)

task (a.k.a problem or test case): a single test with defined inputs and
success criteria

task는 eval의 최소 단위다. 정의된 입력(inputs)과 성공 기준(success criteria)을 가진 하나의 테스트다. "고객이 30일 이내 주문에 대해 환불을 요청했을 때, 에이전트가 환불을 승인하는가"가 하나의 task다.

핵심은 success criteria가 task에 포함된다는 점이다. 입력만 정의하고 "잘 답하면 통과"라고 하면 task가 아니다. 무엇이 성공인지 명시적으로 정의되어 있어야 한다. 이 성공 기준이 모호하면 채점이 일관성을 잃는다. "친절하게 답변하는가"는 모호한 기준이고, "환불 승인 메시지를 포함하는가"는 명시적인 기준이다.

task의 별칭이 problem 또는 test case인 것도 눈여겨볼 만하다. 이 용어 선택은 eval이 본질적으로 "시험 문제"라는 것을 강조한다. 시험 문제에는 정답 기준이 있듯이, task에도 성공 기준이 있다.

2-2. trial (시행)

trial: each attempt at a task. Run multiple trials for consistent results

trial은 하나의 task에 대한 한 번의 시도다. 같은 task를 여러 번 실행하는 이유가 있다. AI 모델의 출력은 비결정적(non-deterministic)이다. 같은 프롬프트를 넣어도 매번 다른 응답이 나올 수 있다. 한 번 성공했다고 해서 그 task를 통과했다고 볼 수 없다. 다섯 번 돌려서 네 번 성공해야 통과라고 정의할 수도 있다.

소프트웨어 테스트와 비교하면 차이가 명확하다. 일반 단위 테스트는 한 번 돌리면 된다. 같은 입력에 항상 같은 출력이 나오니까. 하지만 AI eval에서는 같은 입력에 다른 출력이 나올 수 있으므로, 여러 trial을 돌려서 통계적으로 판단해야 한다. trial 수가 적으면 노이즈에 의한 거짓 양성/거짓 음성이 생긴다. 이 비결정성 문제는 4편에서 자세히 다룰 예정이다.

2-3. grader (채점기)

grader: logic that scores some aspect of the agent's performance. A task
can have multiple graders, each containing multiple assertions (checks)

grader는 에이전트의 수행을 채점하는 로직이다. 하나의 task에 여러 grader가 붙을 수 있고, 각 grader 안에 여러 assertion(체크)이 들어갈 수 있다.

환불 처리 task를 예로 들면 이렇다.

정확성 grader: 올바른 주문을 환불 처리했는가? 환불 금액이 맞는가?
정책 준수 grader: 30일 환불 기한을 확인했는가? 환불 사유를 기록했는가?
커뮤니케이션 grader: 고객에게 환불 완료 메시지를 보냈는가? 메시지에 예상 처리 기간이 포함되어 있는가?

grader가 하나뿐이면 다차원적인 평가가 불가능하다. 환불 금액은 맞았지만 고객 안내가 누락된 경우, 단일 grader로는 이 미묘한 차이를 잡을 수 없다. 여러 grader가 각각 다른 측면을 채점하면, 에이전트가 어디서 강하고 어디서 약한지 분리해서 볼 수 있다.

assertion이라는 용어도 중요하다. 소프트웨어 테스트에서 assertEqual, assertTrue 같은 검증문과 동일한 개념이다. grader는 assertion들의 묶음이다. "환불 금액이 50,000원인가" (assertion 1), "환불 상태가 COMPLETED인가" (assertion 2) — 이런 체크들이 모여서 하나의 grader를 구성한다.

2-4. transcript (기록)

transcript (trace/trajectory): complete record of a trial—outputs, tool
calls, reasoning, intermediate results. For the Anthropic API, this is
the full messages array

transcript는 trial의 완전한 기록이다. 에이전트가 뭘 출력했는지, 어떤 도구를 호출했는지, 중간 결과가 뭐였는지 전부 담긴다. Anthropic API 기준으로는 messages 배열 전체가 transcript다.

별칭이 trace 또는 trajectory인 것이 의미 있다. trace는 "추적 기록", trajectory는 "궤적"이다. 에이전트가 목적지까지 어떤 경로를 거쳤는지를 보여주는 것이다. 결과만 보면 "환불 처리 완료"라고 나오지만, transcript를 보면 에이전트가 주문 조회를 세 번 시도했다가 두 번 실패하고, 결국 다른 API를 써서 조회에 성공한 뒤 환불을 처리한 전체 과정이 드러난다.

이 transcript가 다음 용어인 outcome과 대비될 때 진짜 중요해진다.

2-5. outcome (결과)

outcome: final state in the environment at the end of the trial.

outcome은 trial이 끝난 뒤 환경의 최종 상태다. transcript가 "과정"이라면 outcome은 "결과"다.

원문이 이 차이를 flight-booking 예시로 설명한다.

For example, a flight-booking agent might say "Your flight has been booked"
(transcript) but the outcome is whether a reservation actually exists in
the environment's SQL database.

에이전트가 "항공편이 예약되었습니다"라고 말하는 것은 transcript에 기록된 내용이다. 하지만 실제로 SQL 데이터베이스에 예약 레코드가 존재하는지는 outcome이다. 이 둘은 다를 수 있다. 에이전트가 "예약 완료"라고 답했지만 실제로는 API 호출이 실패해서 예약이 안 되었을 수 있다. transcript만 보면 성공이지만, outcome을 확인하면 실패다.

이 구분이 에이전트 eval에서 핵심적인 이유가 있다. 에이전트가 도구를 사용하고 환경 상태를 바꾸기 때문이다. 챗봇은 답변만 하므로 transcript만 검증하면 된다. 하지만 에이전트는 실제 환경에 영향을 미치므로, 환경의 최종 상태(outcome)를 반드시 검증해야 한다.

정리하면 이렇다.

	transcript	outcome
무엇인가	과정 기록 (대화, 도구 호출, 중간 결과)	환경의 최종 상태
검증 대상	에이전트가 뭘 말하고 뭘 했는가	실제로 뭐가 바뀌었는가
flight-booking 예시	"항공편이 예약되었습니다"	DB에 예약 레코드 존재 여부
검증 실패 케이스	에이전트가 정답을 말했지만 실행이 안 됨	실행은 됐지만 에이전트가 틀린 안내를 함

둘 다 검증해야 완전한 eval이다. transcript만 검증하면 "말만 잘하는" 에이전트를 통과시키고, outcome만 검증하면 과정에서의 문제(불필요한 도구 호출, 고객 정보 노출 등)를 놓친다.

2-6. evaluation harness (평가 인프라)

evaluation harness: infrastructure that runs evals end-to-end—provides
instructions and tools, runs tasks concurrently, records steps, grades
outputs, aggregates results

evaluation harness는 eval 전체를 끝까지 실행하는 인프라다. 지시와 도구를 제공하고, task를 동시에 실행하고, 각 단계를 기록하고, 출력을 채점하고, 결과를 집계한다.

이것을 소프트웨어 테스트 프레임워크와 비교하면 이해가 쉽다. JUnit이나 pytest가 테스트를 발견하고, 실행하고, 결과를 리포팅하는 것처럼, evaluation harness는 eval task를 발견하고, 에이전트에게 실행시키고, grader로 채점하고, 결과를 리포팅한다.

원문이 열거한 역할을 하나씩 보면:

provides instructions and tools: 에이전트에게 시스템 프롬프트와 사용 가능한 도구를 세팅해준다
runs tasks concurrently: task를 병렬로 실행한다. eval suite가 수백 개의 task를 포함할 수 있으므로 동시 실행이 필수다
records steps: 각 trial의 transcript를 기록한다
grades outputs: grader를 실행해서 채점한다
aggregates results: 개별 task 결과를 집계해서 전체 점수, 카테고리별 통과율 등을 산출한다

evaluation harness가 없으면 이 모든 것을 수작업으로 해야 한다. 프롬프트를 수동으로 넣고, 응답을 눈으로 확인하고, 스프레드시트에 기록한다. 도입 시나리오의 "몇 가지 시나리오를 직접 돌려보고" 릴리스한 것이 정확히 harness 없이 eval을 한 경우다.

2-7. agent harness (에이전트 스캐폴드)

agent harness (scaffold): system that enables a model to act as an
agent—processes inputs, orchestrates tool calls, returns results.

agent harness는 모델이 에이전트로 행동할 수 있게 해주는 시스템이다. 입력을 처리하고, 도구 호출을 오케스트레이션하고, 결과를 반환한다.

evaluation harness와 이름이 비슷해서 혼동하기 쉽다. 구분이 중요하다.

evaluation harness: eval을 실행하는 인프라. 테스트 프레임워크에 해당한다.
agent harness: 에이전트를 실행하는 인프라. 테스트 대상(System Under Test)에 해당한다.

evaluation harness가 agent harness 위에서 동작한다. evaluation harness가 task를 agent harness에 넘기면, agent harness가 모델을 에이전트로 동작시켜서 task를 수행하고, 결과를 evaluation harness에 돌려준다. evaluation harness가 그 결과를 채점한다.

원문이 구체적인 예시를 든다.

For example, Claude Code is a flexible agent harness built for software
engineering tasks, and we've used the open-source Agent SDK to build
long-running agent harnesses.

Claude Code가 agent harness다. 모델(Claude)이 소프트웨어 엔지니어링 에이전트로 동작할 수 있게 해주는 시스템이다. 도구 호출, 파일 시스템 접근, 터미널 명령 실행 등을 오케스트레이션한다. Agent SDK로 만든 장기 실행 에이전트도 agent harness다.

에이전트 자체와 agent harness를 구분하는 것도 중요하다. 모델(Claude)은 에이전트가 아니다. 모델이 agent harness(Claude Code, 또는 Agent SDK로 만든 시스템) 안에서 동작할 때 에이전트가 된다. harness가 도구를 제공하고, 루프를 돌리고, 상태를 관리하기 때문이다.

2-8. evaluation suite (평가 모음)

evaluation suite: collection of tasks designed to measure specific
capabilities or behaviors. Tasks in a suite share a broad goal (e.g.,
customer support: refunds, cancellations, escalations)

evaluation suite는 특정 역량이나 행동을 측정하기 위해 설계된 task 모음이다. suite 안의 task들은 넓은 목표를 공유한다.

원문의 예시가 이를 잘 보여준다. 고객 지원 evaluation suite에는 환불, 취소, 에스컬레이션 관련 task들이 포함된다. 개별 task는 구체적인 시나리오("30일 이내 주문 환불 요청")를 다루지만, suite 전체는 "고객 지원 에이전트가 주요 업무를 처리할 수 있는가"라는 넓은 질문에 답한다.

suite 단위로 task를 묶는 이유가 있다. 에이전트가 환불은 잘 처리하지만 에스컬레이션에 실패한다면, 그것은 전체 점수 80%로 표현되는 것보다 "환불 100%, 에스컬레이션 40%"로 표현되는 것이 유용하다. suite가 이 세분화를 가능하게 한다. 어디가 강하고 어디가 약한지 카테고리별로 보여준다.

3. 좋은 eval은 정적이지 않다 — Opus 4.5의 일화

용어를 정리했으니, 원문이 전하는 중요한 경고 하나를 짚고 넘어간다.

원문에는 Opus 4.5가 tau2-bench 문제를 푸는 일화가 등장한다. tau2-bench는 에이전트 평가 벤치마크로, 실제 업무 시나리오를 시뮬레이션한다. 그 중 항공편 예약 문제가 있었다.

For example, Opus 4.5 recently solved a tau2-bench problem about booking
a flight by discovering a loophole in the airline policy. It found a way
to re-book the flight that was technically within the rules but wasn't
the expected path. The evaluation "failed" because the gold-standard
answer followed the standard procedure, but the model actually found a
better solution for the user.

상황을 정리하면 이렇다. 항공사 정책에 허점(loophole)이 있었다. Opus 4.5는 그 허점을 발견해서, 기술적으로는 규정 내에 있는 방법으로 항공편을 재예약했다. 고객에게는 더 좋은 결과였다. 하지만 eval의 정답(gold-standard answer)은 표준 절차를 따르는 것이었다. Opus 4.5의 해법은 정답과 달랐으므로 eval은 "실패"로 처리했다.

이 일화가 보여주는 것은 두 가지다.

첫째, frontier 모델은 eval 설계자가 예상하지 못한 해법을 찾을 수 있다. 정적인 정답 비교로는 이런 "더 나은 해법"을 실패로 처리하게 된다. grader가 "정답 경로를 따랐는가"만 검증하면, 정답보다 나은 경로를 틀렸다고 판정한다.

둘째, eval은 한 번 만들고 끝나는 것이 아니다. 모델이 진화하면 eval도 진화해야 한다. 오늘의 정답이 내일은 차선책이 될 수 있다. 좋은 eval은 "이 경로를 따랐는가"보다 "고객 문제가 해결되었는가"를 검증하는 쪽으로 설계되어야 한다. 경로가 아닌 결과를 검증하는 것 -- 이것이 앞서 정리한 outcome 검증의 중요성과 연결된다.

마무리: 이 용어들이 이후 편에서 어떻게 쓰이는가

1편에서 정리한 8개 용어는 이 시리즈 전체의 기반이다. 이후 편에서 이 용어들이 어떻게 쓰이는지 간략히 예고한다.

2편 (왜 eval이 필요한가): task 설계의 원칙을 다룬다. 어떤 시나리오를 task로 만들어야 하는지, success criteria를 어떻게 정의해야 하는지. evaluation suite를 어떤 기준으로 구성하는지.
3편 (grader 유형): grader를 깊이 파고든다. 코드 기반 grader, LLM 기반 grader, 사람 평가자 등 유형별 특성과 트레이드오프. assertion을 어떻게 설계해야 하는지.
4편 (비결정성): trial이 왜 여러 번 필요한지를 본격적으로 다룬다. AI 모델의 비결정적 출력이 eval 결과에 미치는 영향과 대처법. transcript 분석으로 실패 원인을 추적하는 방법.
5편 (eval 로드맵): evaluation harness를 실전에서 어떻게 구축하는지. agent harness와의 통합. eval을 CI/CD에 넣는 방법.

다음 편에서 다시 만나자.