평가 주도 에이전트 개발(Eval-Driven Agent Development)

Anthropic의 가이드는 이렇게 말합니다. "단순한 프롬프트로 시작하고, 포괄적 평가로 최적화하며, 필요한 경우에만 멀티 단계 에이전트 시스템을 추가하라." 평가(Evaluation)는 마지막 단계가 아닙니다. Phase 14의 모든 선택을 이끄는 바깥쪽 루프(Outer Loop)입니다.

유형: Learn + Build 언어: Python (stdlib) 선수 학습: Phase 14 전체 소요 시간: 약 60분

학습 목표

세 가지 평가 계층(Evaluation Layers)을 말하고, 각각 무엇에 쓰이는지 설명합니다. 정적 벤치마크(Static Benchmarks), 커스텀 오프라인 평가(Custom Offline Evals), 온라인 프로덕션 평가(Online Production Evals)입니다.
평가자-최적화자(Evaluator-Optimizer)의 촘촘한 루프를 설명합니다.
2026년 모범 사례를 설명합니다. 평가는 코드 옆에 두고, 지속적 통합(CI)에서 실행되며, 풀 리퀘스트(PR)를 막는 게이트(Gate)가 됩니다.
Phase 14의 모든 강의(lesson)를 그것이 생성하는 평가 케이스(Eval Case)에 연결합니다.

문제

에이전트는 데모를 통과합니다. 하지만 데모로는 예측할 수 없는 방식으로 프로덕션에서 실패합니다. 벤치마크는 "이 모델이 폭넓게 능력을 갖추었는가?"에는 답해주지만, "이 에이전트가 우리 제품에 올바른 패치를 내놓고 있는가?"에는 답해주지 못합니다. 답은 세 계층의 평가를 지속적으로 실행하고, 모든 가드레일(Guardrail)과 학습된 규칙을 평가 케이스에 대응시키는 것입니다.

개념

세 가지 평가 계층

정적 벤치마크(Static Benchmarks) — 코드에는 SWE-bench Verified(19강), 브라우징과 데스크톱에는 WebArena/OSWorld(20강), 범용 에이전트에는 GAIA(19강), 도구 사용에는 BFCL V4(6강)를 사용합니다. 모델 간 비교와 회귀 게이팅(Regression Gating)에 사용합니다. 오염(Contamination)은 실재하는 문제입니다. SWE-bench+는 32.67%의 풀이 유출(Solution Leakage)을 발견했습니다. 항상 Verified와 +-audited 점수를 함께 보고해야 합니다.
커스텀 오프라인 평가(Custom Offline Evals) — 제품의 형태에 맞춘 평가입니다.
- 심판으로서의 LLM(LLM-as-judge; Langfuse, Phoenix, Opik — 24강).
- 실행 기반 평가(Execution-based). 패치를 실제로 실행하고 테스트를 확인합니다.
- 궤적 기반 평가(Trajectory-based). 행동 순서를 정답 궤적(Gold)과 비교합니다. OSWorld-Human은 최상위 에이전트가 정답 대비 1.4-2.7배 더 많은 단계를 사용한다는 점을 보여줍니다.
온라인 평가(Online Evals) — 프로덕션 평가입니다.
- 세션 리플레이(Session Replays; Langfuse).
- 가드레일이 유발한 알림(16강, 21강).
- 단계별 비용과 지연 시간 추적(23강 OpenTelemetry; OTel 스팬).

평가자-최적화자(Evaluator-Optimizer; Anthropic)

촘촘한 루프는 다음과 같습니다.

제안자(Proposer)가 출력을 생성합니다.
평가자(Evaluator)가 판단합니다.
평가자가 통과시킬 때까지 다듬습니다.

이는 자기 개선(Self-Refine; 5강)을 일반화한 형태입니다. 신뢰성이 중요한 어떤 에이전트 흐름도 평가자-최적화자(Evaluator-Optimizer) 패턴으로 감쌀 수 있습니다.

2026년 모범 사례

평가는 코드 옆에 둡니다.
모든 풀 리퀘스트(PR)에서 지속적 통합(CI)으로 실행합니다.
평가 점수로 병합(merge)을 막습니다. 예를 들어 "main 대비 5% 초과 회귀 없음" 같은 규칙을 둡니다.
모든 가드레일은 평가 케이스로 대응됩니다.
모든 학습된 규칙(Reflexion, pro-workflow learn-rule)은 실패 케이스로 대응됩니다.

Phase 14를 하나로 묶기

Phase 14의 모든 강의는 평가 케이스를 만들어냅니다.

강의	만들어지는 평가 케이스
01 Agent Loop	예산 소진, 무한 루프 가드
02 ReWOO	도구가 실패했을 때 계획자(Planner)가 올바르게 재계획
03 Reflexion	학습된 반성(Reflection)이 재시도에 적용됨
05 Self-Refine/CRITIC	심판(Judge)이 다듬어진 출력을 통과시킴
06 Tool Use	인자 변환이 동작하고 알 수 없는 도구가 거부됨
07-10 Memory	검색 인용(Citation)이 출처와 일치하고, 오래된 사실은 무효화됨
12 Workflow Patterns	각 패턴이 올바른 출력을 생성함
13 LangGraph	재개(Resume)가 상태를 정확히 재현함
14 AutoGen Actors	데드 레터 큐(Dead Letter Queue; DLQ)가 충돌한 처리기(Handler)를 잡음
16 OpenAI Agents SDK	올바른 입력에서 가드레일(Guardrail)이 발동함
17 Claude Agent SDK	하위 에이전트(Subagent) 결과가 오케스트레이터(Orchestrator)로 돌아옴
19-20 Benchmarks	SWE-bench Verified 점수, WebArena 성공률, OSWorld 효율
21 Computer Use	단계별 안전 장치가 주입된 DOM을 잡음
23 OTel	스팬(Span)이 필수 속성을 내보냄
26 Failure Modes	감지기가 알려진 실패를 태깅함
27 Prompt Injection	PVE가 오염된 검색 결과를 거부함
28 Orchestration	감독자(Supervisor)가 올바른 전문가로 라우팅함
29 Runtime Shapes	DLQ가 N% 실패를 처리함

평가 모음에 이 케이스들이 모두 있으면 Phase 14를 덮은 것입니다.

평가 주도 개발이 실패하는 지점

기준선 부재. 마지막으로 좋았던 상태(Last-Known-Good)가 없는 평가는 읽어낼 수 없습니다. 기준선(Baseline)을 저장해야 합니다.
근거 없는 LLM 심판(Judge). 심판도 환각(Hallucinate)합니다. CRITIC 패턴(5강)처럼 심판은 외부 도구에 근거(Grounding)를 두어야 합니다.
평가에 과적합. 평가 점수만 올리도록 최적화하면 프로덕션 유용성과 멀어집니다. 케이스를 주기적으로 교체해야 합니다.
불안정한 평가(Flaky Evals). 비결정적 케이스는 거짓 알림을 만듭니다. 시드(Seed)를 고정하고 상태를 스냅샷(Snapshot)해야 합니다.

만들어보기

code/main.py는 표준 라이브러리(stdlib)만 사용하는 평가 하네스(Harness)입니다.

범주(benchmark, custom, online)를 가진 케이스 레지스트리(Registry)입니다.
테스트 대상이 되는 스크립트 기반 에이전트입니다.
평가자-최적화자 루프입니다. 제안하고, 판단하고, 통과하거나 최대 라운드에 닿을 때까지 다듬습니다.
지속적 통합 게이트(CI Gate)입니다. 집계 통과율과 기준선 대비 회귀를 확인합니다.

실행 방법은 다음과 같습니다.

python3 code/main.py

출력은 케이스별 통과와 실패, 회귀 플래그, CI 게이트 판정을 보여줍니다.

사용해보기

평가 케이스를 에이전트 코드와 같은 저장소에 작성합니다.
모든 풀 리퀘스트(PR)에서 지속적 통합(CI)으로 실행합니다.
회귀가 발생하면 빌드를 실패시킵니다.
시간에 따른 통과율을 추적합니다.
모든 프로덕션 실패를 새 평가 케이스로 연결합니다.

산출물 만들기

outputs/skill-eval-suite.md는 CI 게이트와 회귀 추적을 갖춘 세 계층 평가 모음(Eval Suite)을 에이전트 제품에 맞춰 구성합니다.

연습문제

프로덕션 실패 하나를 고르세요. 이를 재현하는 평가 케이스를 작성합니다. 지금 에이전트는 이를 통과하나요?
세 가지 차원(사실성, 톤, 범위)에 대한 도메인 LLM 심판(Judge) 루브릭(Rubric)을 만드세요. 50개 세션을 채점합니다.
평가 모음을 CI에 연결하세요. 5% 이상 회귀하면 빌드를 실패시킵니다.
궤적 효율(Trajectory Efficiency) 지표를 추가하세요. 에이전트가 정답 궤적 대비 몇 단계를 사용했나요?
Phase 14의 모든 강의를 평가 모음의 케이스에 대응시키세요. 빠진 것이 있나요? 그것이 메워야 할 공백(Gap)입니다.

핵심 용어

용어	흔한 설명	실제 의미
정적 벤치마크(Static Benchmark)	"기성 평가"	SWE-bench, GAIA, AgentBench, WebArena, OSWorld입니다.
커스텀 오프라인 평가(Custom Offline Eval)	"도메인 평가"	제품 형태에 맞춘 LLM 심판, 실행, 궤적 평가입니다.
온라인 평가(Online Eval)	"프로덕션 평가"	세션 리플레이, 가드레일 알림, 비용과 지연 시간 추적입니다.
평가자-최적화자(Evaluator-Optimizer)	"제안-판단-다듬기"	심판이 통과시킬 때까지 반복합니다.
CI 게이트(CI Gate)	"병합 차단기(Merge Blocker)"	평가 회귀가 있으면 빌드를 실패시킵니다.
기준선(Baseline)	"마지막으로 좋았던 상태"	회귀를 감지하기 위한 참조 점수입니다.
궤적 효율(Trajectory Efficiency)	"정답 대비 단계 수"	에이전트 단계 수를 사람 전문가의 최소 단계 수로 나눈 값입니다.

더 읽을거리

Anthropic, Building Effective Agents — "단순하게 시작하고, 평가로 최적화하라"
OpenAI, SWE-bench Verified — 선별된 벤치마크
Berkeley Function Calling Leaderboard — 도구 사용 벤치마크
Langfuse docs — 실제 평가와 세션 리플레이