Ch.06 — 단일 응답에서 궤적 평가로

Ch.06 개요 — Part II의 출발점

Part I(Ch.01~05)에서 우리는 "텍스트 생성의 질"을 측정하는 25년의 역사를 추적했다. BLEU의 n-gram 정밀도부터 LLM-as-Judge의 확률적 사고연쇄(Chain-of-Thought)까지, 그 모든 방법은 본질적으로 하나의 텍스트 출력을 평가했다. 입력이 들어가고, 출력이 나오고, 그 출력의 품질을 잰다. 단순하고 정적(static)이며 재현 가능했다.

그러나 에이전트(agent)는 텍스트를 "생성"하지 않는다. 에이전트는 환경(environment)과 상호작용하며 행동(action)의 시퀀스를 "실행"한다. API를 호출하고, 파일을 읽고, 코드를 실행하고, 웹을 탐색하고, 다른 에이전트와 대화한다. 평가 대상은 더 이상 한 문장이 아니라, 시간에 걸쳐 펼쳐진 궤적(trajectory) 전체다. 이 장은 그 전환—패러다임 시프트(paradigm shift)—이 왜 일어났고, 어떻게 평가의 모든 것을 바꾸는지를 다룬다.

6.0 이 장의 구성 로드맵

이 장은 세 개의 렌즈—철학(philosophy), 수학(mathematics), 실무(practice)—를 통해 패러다임 전환을 조망한다. 철학적 렌즈는 토머스 쿤(Thomas Kuhn)의 과학 혁명 구조를 차용해 "왜 지금 전환이 일어나는가"를 설명한다. 수학적 렌즈는 마르코프 결정 과정(Markov Decision Process, MDP)과 부분 관측 MDP(POMDP)로 궤적 평가를 형식화한다. 실무적 렌즈는 AgentBench, WebArena 같은 실제 벤치마크와 고객 지원 에이전트 사례를 통해 정적 평가가 어디서 무너지는지를 보인다.

섹션	주제	렌즈	핵심 내용
6.1	패러다임 전환의 3단계	철학	쿤의 정상과학→위기→혁명 모델을 평가사에 적용
6.2	LLM vs 에이전트: 근본 차이	실무	16차원 비교 테이블, 입력·출력·환경·비용의 변화
6.3	궤적(Trajectory)의 형식화	수학	$\tau = [(s_t,a_t)]$ 정의, 상태·관찰·이력의 구조
6.4	정적 평가의 한계 시연	실무	고객 지원 에이전트 사례, 환불 미수행 탐지
6.5	MDP 관점의 에이전트 평가	수학	$(S,A,P,R,\gamma)$ 모델링, 궤적 가치 함수
6.6	관측 가능성과 로깅	실무	궤적 로깅 인프라, 부작용 추적, 감사 가능성
6.7	결과·과정·혼합 평가	수학	세 평가 철학의 트레이드오프와 가중 결합
6.8	동적 환경의 복잡성	수학	부분 관측·비결정론·상태 의존·장기 지평
6.9	오류 전파와 복합 실패	수학	단일 스텝 오류가 궤적 성공률에 미치는 기하급수적 영향
6.10	비결정론과 재현성	실무	$pass@k$, $pass^k$, 분산 추정, 시드 고정
6.11	평가 방법론의 진화 트리	철학	텍스트 평가→에이전트 평가의 분기 다이어그램
6.12	실제 벤치마크 분석	실무	AgentBench·WebArena·SWE-bench의 평가 설계
6.13	사례 연구 3선	실무	웹 쇼핑·코드 수정·고객 지원 궤적 분석
6.14	검증기(Verifier) 설계	실무	상태·실행·판단 기반 검증, 메타 평가
6.15	비용 인지 평가	실무	예산 제약 하 표본 배분, 계층적 평가
6.16	에이전트 평가 안티패턴	철학	데모 주도 평가 등 8대 함정과 해법
6.17	역사적 타임라인	철학	2002~2024 평가 패러다임 진화 연표
6.18	멀티 에이전트로의 다리	수학	결합 궤적, 협응·통신 차원의 등장(Ch.08 예고)
6.19	요약과 다음 장 예고	—	Ch.07 에이전트 벤치마크로의 연결

6.1 패러다임 전환의 3단계: 쿤의 렌즈로 본 평가의 역사

토머스 쿤(Thomas Kuhn)은 『과학 혁명의 구조』(Kuhn, 1962)에서 과학의 발전이 점진적 축적이 아니라 단속적 혁명(punctuated revolution)을 통해 일어난다고 주장했다. 한 패러다임(paradigm)이 지배하는 "정상과학(normal science)" 시기에는 그 틀 안에서 퍼즐을 푼다. 그러나 기존 틀로 설명할 수 없는 변칙(anomaly)이 누적되면 "위기(crisis)"가 오고, 결국 새로운 패러다임이 옛것을 대체하는 "혁명(revolution)"이 일어난다. 흥미롭게도 LLM 평가의 역사는 이 3단계 구조와 놀랍도록 잘 들어맞는다.

1단계 · Normal Science

텍스트 생성 평가

BLEU(Papineni 2002), ROUGE(Lin 2004), MMLU(Hendrycks 2021) 같은 정적 벤치마크가 지배. "정답과 얼마나 유사한가"라는 단일 질문 안에서 모든 퍼즐을 푼다.

2단계 · Crisis

평가의 무력화

LLM이 "너무 잘해서" MMLU·HumanEval이 포화(saturation)되고, 데이터 오염(contamination)과 정적 정답의 부재로 기존 지표가 변별력을 잃는다.

3단계 · Revolution

궤적 평가

도구 사용·멀티턴·환경 상호작용을 하는 에이전트가 등장. 평가 단위가 "응답"에서 "행동의 궤적"으로 이동하는 패러다임 전환.

6.1.1 정상과학: 참조 기반 평가의 황금기

2002년부터 2020년경까지 NLP 평가의 지배 패러다임은 "참조 기반(reference-based)" 측정이었다. 기계 번역의 BLEU(Papineni et al., 2002, DOI:10.3115/1073083.1073135), 요약의 ROUGE(Lin, 2004), 그리고 객관식 지식 평가의 MMLU(Hendrycks et al., 2021, arXiv:2009.03300)가 이 시대를 대표한다. 이 패러다임의 전제는 명확했다: 모든 태스크에는 정답(ground truth)이 존재하며, 모델 출력이 그 정답에 가까울수록 좋다는 것이다. 평가는 정적이고 결정론적이며, 한 번 데이터셋을 구축하면 수백만 건의 출력을 자동으로 채점할 수 있었다.

이 패러다임은 대단히 생산적이었다. 리더보드(leaderboard)가 표준이 되었고, 연구자들은 단일 스칼라(scalar) 점수로 모델을 비교했다. GLUE(Wang et al., 2018, arXiv:1804.07461)와 그 후속작 SuperGLUE(Wang et al., 2019, arXiv:1905.00537)는 자연어 이해 능력을 하나의 종합 점수로 환원하는 데 성공했다. 정상과학의 시기에 평가는 "풀린 문제(solved problem)"처럼 보였다.

6.1.2 위기: LLM이 평가를 무력화하다

위기는 두 갈래로 찾아왔다. 첫째는 포화(saturation)다. GPT-4가 MMLU에서 86%, HumanEval에서 67%를 기록하면서(OpenAI, 2023, arXiv:2303.08774), 이들 벤치마크의 변별력이 급감했다. 모든 최상위 모델이 90%대 정확도에 몰리면, 0.5%의 차이가 통계적 잡음인지 실질적 우위인지 구분하기 어려워진다. 둘째는 데이터 오염(contamination)이다. 인터넷 규모로 사전학습(pre-training)된 모델은 벤치마크 정답을 이미 "본" 경우가 많아, 측정값이 일반화 능력이 아니라 암기를 반영할 위험이 커졌다.

더 근본적인 위기는 평가 대상 자체의 변화였다. 사용자는 더 이상 LLM에게 "이 문장을 번역하라"고만 요청하지 않았다. "내 캘린더를 확인하고, 빈 시간을 찾아, 회의를 잡고, 참석자에게 이메일을 보내라"고 요청하기 시작했다. 이것은 하나의 텍스트 응답으로 평가할 수 있는 태스크가 아니다. 참조 기반 패러다임의 핵심 전제—"정적 정답이 존재한다"—가 무너진 것이다.

변칙의 누적

쿤의 모델에서 위기는 "변칙(anomaly)이 누적될 때" 발생한다. LLM 평가의 변칙은 명확했다. (1) 두 모델이 동일한 MMLU 점수를 받지만 실제 도구 사용 능력은 천차만별이다. (2) 정답이 같아도 그 정답에 이르는 과정이 안전하지 않을 수 있다. (3) 단일 응답은 완벽하지만 멀티턴 대화에서 일관성이 붕괴한다. 이 변칙들은 참조 기반 패러다임의 틀 안에서는 측정조차 불가능했다.

6.1.3 혁명: 궤적이 새로운 평가 단위가 되다

2022~2023년, 도구 사용(tool use)과 추론-행동(ReAct, Reasoning+Acting; Yao et al., 2023, arXiv:2210.03629)을 결합한 에이전트가 등장하면서 새로운 패러다임이 자리 잡았다. AgentBench(Liu et al., 2023, arXiv:2308.03688)는 LLM을 8개 환경—운영체제, 데이터베이스, 지식 그래프, 카드 게임, 횡적 사고 퍼즐, 자원 분배, 웹 쇼핑, 다중 대화—에서 "에이전트로서" 평가하는 최초의 종합 벤치마크 중 하나였다. WebArena(Zhou et al., 2023, arXiv:2307.13854)는 GitLab, 쇼핑 관리자, Reddit 등 실제 웹사이트를 복제한 환경에서 812개의 태스크를 정의했다.

이 혁명의 핵심은 평가 단위(unit of evaluation)의 이동이다. 정상과학에서 평가 단위는 "응답(response)"이었다. 혁명 이후 평가 단위는 "궤적(trajectory)"—에이전트가 태스크를 수행하며 거쳐간 상태와 행동의 전체 기록—이 되었다. 이 변화는 사소해 보이지만, 평가의 모든 측면(입력, 출력, 환경, 비용, 재현성, 방법론)을 근본적으로 바꾼다. 이것이 이 장 전체의 주제다.

패러다임 전환의 정의

에이전트 평가는 "응답의 질(quality of response)"이 아니라 "행동의 올바름(correctness of behavior)"을 묻는다. 이것은 평가 철학의 코페르니쿠스적 전환이다. 텍스트의 표면적 품질이 우수하더라도, 그 텍스트에 이르는 과정에서 잘못된 API를 호출하거나, 위험한 명령을 실행했거나, 필요한 확인 절차를 건너뛰었다면, 그 에이전트는 실패한 것이다. 우리는 "무엇을 말했는가"에서 "무엇을 했는가"로 평가의 축을 옮긴다.

6.2 LLM vs 에이전트: 16가지 본질적 차이

패러다임 전환을 가장 구체적으로 이해하는 방법은 두 평가 방식을 차원별로 나란히 놓고 비교하는 것이다. 아래 표는 입력 형태부터 거버넌스 함의까지 16개 차원에 걸쳐 LLM 평가와 에이전트 평가의 차이를 정리한다. 이 표는 이 장에서 가장 중요한 단일 도구이며, 이후 모든 절은 이 표의 한 행을 깊이 파고드는 것으로 볼 수 있다.

차원	LLM 평가	에이전트 평가
입력(Input)	단일 프롬프트(prompt) — 정적 텍스트	상태(state) + 관찰(observation) + 이력(history)이 동적으로 갱신
출력(Output)	텍스트 응답 한 건	텍스트 + 함수 호출 + API 요청 + 파일 조작 + UI 액션의 시퀀스
환경(Environment)	없음(static) — 모델만 존재	시뮬레이션, OS, 웹, DB, API, 파일시스템과 상호작용
평가 대상	응답 품질(response quality)	궤적(trajectory) 전체 — 과정과 결과 모두
시간 척도	수 초 — 단일 API 호출	수 분~수 시간 — 멀티턴 루프, 수십~수백 스텝
건당 비용	$0.001~0.01 / 평가	$0.10~5.00 / 평가 — 루프·도구·재시도 누적
비결정성	낮음 — temperature=0이면 거의 결정론적	높음 — 환경 상태, API 응답 변동, 타임아웃
평가 방법	정적 비교(static comparison)	동적 시뮬레이션(dynamic simulation) + 실행
Ground Truth	가능 — 정답 문자열·라벨 존재	어려움 — "올바른 과정"이 유일하지 않음
재현성(Reproducibility)	높음 — 동일 입력→동일 출력	낮음 — 환경 상태와 외부 의존성에 좌우
스케일(Scale)	수만~수백만 건 자동 채점	수십~수백 건 — 환경 구축·실행 비용 제약
실패 모드	단일 — 틀린 응답	복합 — 잘못된 도구, 무한 루프, 부분 완료, 부작용
오류 전파	없음 — 독립적 단발성	심각 — 초기 오류가 후속 스텝으로 증폭(error propagation)
관측 가능성	완전 — 입력과 출력이 모두 보임	부분(partial) — 환경 상태의 일부만 관측(POMDP)
부작용(Side effects)	없음 — 순수 함수에 가까움	있음 — 실제 이메일 발송, DB 수정, 결제 등 불가역
거버넌스 함의	출력 필터링으로 대응 가능	실행 권한·승인·롤백·감사 추적이 필수

16×

평가 단위
1응답→궤적

~100×

건당 비용
증가폭

35.8%

WebArena
GPT-4 성공률

78.2%

WebArena
인간 성공률

6.2.1 입력의 변화: 프롬프트에서 상태로

LLM 평가에서 입력은 고정된 텍스트 프롬프트다. 동일한 프롬프트는 언제나 동일한 입력이다. 그러나 에이전트의 입력은 시간에 따라 변하는 상태(state)다. 상태는 현재 관찰(예: 웹페이지의 DOM, 터미널 출력, API 응답)과 누적된 이력(지금까지 수행한 행동과 그 결과)으로 구성된다. 같은 태스크라도 에이전트가 매 스텝 다른 행동을 하면, 다음 스텝의 입력 상태가 완전히 달라진다.

이 차이는 평가 설계에 결정적이다. LLM 평가에서는 "입력 데이터셋"을 한 번 고정하면 된다. 에이전트 평가에서는 입력이 에이전트의 행동에 의해 생성되므로, 평가자는 "입력"이 아니라 "초기 상태 + 환경 동역학(dynamics)"을 고정해야 한다. 입력 공간이 본질적으로 분기(branching)하는 트리 구조가 되는 것이다.

6.2.2 출력의 변화: 텍스트에서 행동으로

LLM의 출력은 토큰 시퀀스다. 에이전트의 출력은 환경에 영향을 미치는 행동(action)이다. 행동은 도구 호출(tool call), 함수 실행, 파일 쓰기, 네트워크 요청, UI 클릭 등 다양한 형태를 띤다. 결정적으로, 에이전트의 출력은 부작용(side effect)을 가진다. LLM이 "이메일을 보내겠습니다"라고 텍스트를 출력하는 것과, 에이전트가 실제로 SMTP 요청을 실행하는 것은 평가 관점에서 완전히 다른 사건이다.

텍스트와 행동의 평가 비대칭성

텍스트는 "취소(undo)"할 수 있다. 잘못된 응답은 무시하면 그만이다. 그러나 행동의 부작용은 종종 불가역(irreversible)이다. 잘못 발송된 이메일, 삭제된 파일, 처리된 결제는 되돌릴 수 없다. 이 불가역성 때문에 에이전트 평가는 "최종 결과가 맞았는가"뿐 아니라 "과정에서 위험한 행동을 했는가"를 반드시 함께 봐야 한다. 결과만 보는 평가는 운 좋게 성공한 위험한 에이전트를 걸러내지 못한다.

6.2.3 비용과 스케일의 역전

LLM 평가의 강점은 스케일이었다. 단일 API 호출이 수 초, 수 밀리달러로 끝나므로 수백만 건의 평가를 자동화할 수 있었다. 에이전트 평가는 이 경제학을 뒤집는다. 한 번의 에이전트 실행은 수십 번의 LLM 호출, 여러 도구 실행, 재시도, 그리고 종종 인간 검토를 수반한다. 결과적으로 건당 비용이 10~1000배 증가하고, 현실적으로 평가 가능한 샘플 수는 수십~수백 건으로 급감한다.

AgentBench의 보고에서도 "평가 비용이 매우 높다"는 점이 핵심 한계로 지적된다(Liu et al., 2023). 각 환경에서 의미 있는 통계량을 얻으려면 여러 번 시도해야 하는데, 비결정성 때문에 시도 횟수를 늘려야 하고, 이것이 다시 비용을 증폭시킨다. 이 비용 제약은 에이전트 평가 설계 전반에 영향을 미치는 일급 제약(first-class constraint)이다.

6.3 궤적(Trajectory)이란 무엇인가

패러다임 전환의 수학적 심장에는 "궤적(trajectory)"이라는 개념이 있다. 궤적은 에이전트가 태스크를 수행하며 거쳐간 전체 상태 변화의 기록이다. 직관적으로는 "에이전트가 무엇을 보고, 무엇을 했고, 그 결과 무엇이 바뀌었는가"의 완전한 로그(log)다.

6.3.1 궤적의 형식적 정의

궤적의 정의 (State-Action Sequence)

$$\tau = [(s_0, a_0), (s_1, a_1), (s_2, a_2), \ldots, (s_T, a_T)]$$

$s_t$: 시점 $t$의 상태(관찰 $o_t$ + 이력 $h_t$의 결합). $a_t$: 시점 $t$의 행동(LLM 출력 + 도구 호출). $T$: 궤적의 종료 시점(지평, horizon). 궤적은 초기 상태 $s_0$에서 시작해 종료 상태 $s_T$에 이르는 경로다.

여기서 상태 $s_t$는 두 부분으로 분해된다. 첫째는 현재 관찰 $o_t$로, 환경이 에이전트에게 노출하는 정보(웹페이지 DOM, 터미널 출력, 함수 반환값)다. 둘째는 이력 $h_t = (a_0, o_1, a_1, \ldots, o_t)$로, 지금까지의 행동과 관찰의 누적이다. 에이전트의 정책(policy) $\pi$는 이 상태를 입력받아 다음 행동의 확률 분포를 출력한다.

에이전트 정책 (Policy)

$$a_t \sim \pi(\cdot \mid s_t) = \pi(\cdot \mid o_t, h_t), \qquad s_{t+1} \sim P(\cdot \mid s_t, a_t)$$

정책 $\pi$는 상태를 행동의 확률 분포로 매핑한다. 환경의 전이 함수(transition) $P$는 현재 상태와 행동으로부터 다음 상태를 결정한다. LLM 에이전트에서 $\pi$는 LLM 자체이며, $P$는 도구·환경이다.

6.3.2 궤적의 시각적 구조

궤적은 추상적 수식이지만, 실제로는 매우 직관적인 흐름이다. 에이전트는 "생각(think)→행동(act)→관찰(observe)"의 루프를 반복하다가 최종 답에 도달한다. 이것이 ReAct(Yao et al., 2023) 패러다임의 핵심이며, 아래는 "샌프란시스코의 현재 날씨에 맞는 옷차림을 추천하라"는 태스크의 궤적이다.

0Think

날씨 정보가 필요하다. 날씨 API를 호출해 샌프란시스코의 현재 기온과 강수 여부를 확인하자.
올바른 계획 수립

1Act

get_weather(city="San Francisco") — 도구 호출. 정확한 인자(argument) 전달.
올바른 도구·인자 선택

2Observe

환경 응답: {"temp": 14, "unit": "C", "condition": "fog", "wind": 22} — 14도, 안개, 바람 22km/h.

3Think

14도에 안개와 강풍. 쌀쌀하므로 겉옷이 필요하다. 바람 때문에 방풍 재킷이 적합하겠다.
관찰을 정확히 해석

4Final

"샌프란시스코는 현재 14도에 안개와 강풍입니다. 가벼운 스웨터 위에 방풍 재킷을 권합니다."
근거 있는 최종 답변

이 시각화에서 평가의 핵심 통찰이 드러난다. 최종 답변(스텝 4)만 평가하면 스텝 0~3의 품질을 알 수 없다. 만약 에이전트가 날씨 API를 호출하지 않고 추측으로 "샌프란시스코는 따뜻하니 반팔을 입으세요"라고 답했다면? 우연히 그날 날씨가 따뜻했다면 결과는 맞을 수 있다. 그러나 그 궤적은 근본적으로 잘못되었다—근거 없이 추측했기 때문이다. 궤적 평가는 바로 이 차이를 포착한다.

궤적은 "과정의 증거"다

법정에서 판결만 보는 것과 재판 과정 전체를 보는 것은 다르다. 같은 판결이라도 적법한 절차를 거쳤는지가 정의(justice)를 결정한다. 에이전트 궤적도 마찬가지다. 같은 최종 답변이라도, 필요한 도구를 호출하고, 관찰을 정확히 해석하고, 안전 절차를 지켰는지가 그 답변의 신뢰성을 결정한다. 궤적은 에이전트가 "올바른 절차(due process)"를 따랐다는 증거다.

6.3.3 궤적 공간의 폭발적 크기

궤적 평가가 어려운 근본 이유는 가능한 궤적의 수가 지평 $T$에 대해 지수적으로 증가하기 때문이다. 매 스텝 행동 공간의 크기가 $|A|$라면, 길이 $T$의 가능한 궤적 수는 $|A|^T$에 이른다. 행동이 10가지이고 지평이 20스텝이면 $10^{20}$개의 궤적이 존재한다—우주의 모든 모래알보다 많다. 이 조합 폭발(combinatorial explosion)이 "올바른 궤적"을 유일하게 정의하기 어렵게 만든다.

궤적 공간의 크기

$$|\mathcal{T}_T| \le \prod_{t=0}^{T-1} |A(s_t)| \approx |A|^T$$

$|A(s_t)|$: 상태 $s_t$에서 가능한 행동의 수. 행동 공간이 상태에 따라 달라지므로 실제 궤적 수는 곱으로 표현된다. 지평 $T$가 길어질수록 궤적 공간은 지수적으로 폭발한다.

길이의 저주(Curse of Horizon)

궤적의 길이가 길어질수록 평가의 어려움은 기하급수적으로 증가한다. 이것은 두 가지 효과의 결합이다. 첫째, 가능한 궤적의 수가 $|A|^T$로 폭발해 "올바른 궤적"을 열거하기가 불가능해진다. 둘째, 6.9절에서 보겠지만 스텝당 오류율이 작아도 누적되면 전체 성공률이 급락한다. 장기 지평(long-horizon) 태스크가 에이전트 평가의 최전선(frontier)인 이유가 여기에 있다.

6.3.4 궤적의 데이터 구조 구현

이론을 코드로 옮겨 보자. 궤적을 1급 객체(first-class object)로 표현하면, 이후 모든 평가 로직이 이 구조를 입력으로 받는 깔끔한 파이프라인이 된다.

from dataclasses import dataclass, field
from typing import Any, Optional
from enum import Enum

class StepKind(Enum):
    THINK = "think"      # 내부 추론(부작용 없음)
    ACT   = "act"        # 도구 호출(부작용 가능)
    OBSERVE = "observe"  # 환경 관찰
    FINAL = "final"      # 최종 응답

@dataclass
class Step:
    """궤적의 단일 스텝 (s_t, a_t) 쌍을 표현"""
    t: int
    kind: StepKind
    observation: Any = None       # o_t: 환경이 노출한 관찰
    action: Optional[dict] = None  # a_t: {tool, args} 또는 텍스트
    reward: float = 0.0            # r(s_t, a_t): 스텝 보상(선택적)
    side_effect: bool = False      # 불가역 부작용 발생 여부
    meta: dict = field(default_factory=dict)

@dataclass
class Trajectory:
    """tau = [(s_0,a_0), ..., (s_T,a_T)] 전체 궤적"""
    task_id: str
    steps: list[Step] = field(default_factory=list)
    success: Optional[bool] = None  # 결과 기반 성공 여부

    def horizon(self) -> int:
        return len(self.steps)

    def tool_calls(self) -> list[dict]:
        """ACT 스텝의 도구 호출만 추출 — 과정 평가의 기본 단위"""
        return [s.action for s in self.steps
                if s.kind == StepKind.ACT and s.action]

    def has_irreversible(self) -> bool:
        """불가역 부작용이 한 번이라도 있었는가 (안전 평가의 핵심)"""
        return any(s.side_effect for s in self.steps)

    def discounted_return(self, gamma: float = 0.99) -> float:
        """V(tau) = sum_t gamma^t * r_t — 궤적의 할인 가치"""
        return sum(gamma ** s.t * s.reward for s in self.steps)

6.3.5 궤적 거리와 정렬: 두 궤적이 얼마나 비슷한가

과정 기반 평가의 핵심 연산은 "에이전트 궤적이 정답 궤적(gold trajectory)과 얼마나 가까운가"를 재는 것이다. 그러나 두 행동 시퀀스는 길이가 다르고, 순서가 어긋나며, 동등하지만 표현이 다른 행동을 포함할 수 있다. 이 문제는 생물정보학의 서열 정렬(sequence alignment)이나 음성 인식의 동적 시간 워핑(Dynamic Time Warping, DTW)과 수학적으로 동형이다.

레벤슈타인 기반 궤적 거리

$$d(\tau, \tau^*) = \min_{\text{ops}} \sum_{\text{op}} c(\text{op}), \qquad \text{op} \in \{\text{삽입}, \text{삭제}, \text{치환}\}$$

에이전트 궤적 $\tau$를 정답 궤적 $\tau^*$로 변환하는 데 필요한 최소 편집 비용. 행동 삽입(불필요한 도구 호출), 삭제(누락된 단계), 치환(잘못된 도구)에 각각 비용을 부여한다. 정렬 점수는 $1 - d/\max(|\tau|, |\tau^*|)$로 정규화.

그러나 단순 편집 거리는 "도구 A와 도구 B가 의미상 동등한가"를 모른다. 그래서 실무에서는 치환 비용을 행동 임베딩(embedding) 간 코사인 거리로 대체하거나, 도구 온톨로지(ontology)에 기반한 의미 거리를 사용한다. 이렇게 하면 "검색 도구를 search로 부르든 query로 부르든 동등하다"는 유연성을 확보한다.

def trajectory_distance(traj_a: list[str], gold: list[str],
                        sub_cost=None) -> dict:
    """편집 거리 기반 궤적 정렬 점수 (DP, O(mn))"""
    m, n = len(traj_a), len(gold)
    if sub_cost is None:
        sub_cost = lambda x, y: 0.0 if x == y else 1.0
    dp = [[0.0] * (n + 1) for _ in range(m + 1)]
    for i in range(m + 1): dp[i][0] = i      # 전부 삭제
    for j in range(n + 1): dp[0][j] = j      # 전부 삽입
    for i in range(1, m + 1):
        for j in range(1, n + 1):
            dp[i][j] = min(
                dp[i-1][j] + 1,                       # 삭제(불필요 행동)
                dp[i][j-1] + 1,                       # 삽입(누락 행동)
                dp[i-1][j-1] + sub_cost(traj_a[i-1], gold[j-1]),  # 치환
            )
    dist = dp[m][n]
    norm = 1 - dist / max(1, m, n)
    return {"distance": dist, "alignment_score": max(0.0, norm)}

# 에이전트: [search, click, click, ...], 정답: [search, filter, add_cart]
print(trajectory_distance(["search","click","click"],
                          ["search","filter","add_cart"]))

정렬은 "정답 경로의 독재"를 누그러뜨린다

편집 거리 기반 정렬의 가치는 "부분 점수"를 자연스럽게 부여한다는 데 있다. 정답 궤적과 80% 일치하는 에이전트는 0.8을, 완전히 다른 에이전트는 0에 가까운 점수를 받는다. 의미 기반 치환 비용을 도입하면 동등한 대안 경로도 인정한다. 그러나 근본 한계는 남는다—단일 정답 궤적을 고정하면, 그와 구조적으로 다르지만 똑같이 옳은 경로(예: 순서를 바꿔도 되는 독립 단계)를 과소평가한다. 그래서 6차원 프레임워크는 정렬 점수를 유일 지표가 아니라 여러 신호 중 하나로만 사용한다.

6.4 정적 평가의 한계 시연: 고객 지원 에이전트

추상적 논의를 구체적 사례로 내려보자. 가장 명료한 예는 고객 지원(customer support) 에이전트다. 이 사례는 "최종 응답만 보는 정적 평가"가 어떻게 위험한 에이전트를 통과시키는지를 적나라하게 드러낸다.

6.4.1 시나리오: 배송 지연 환불 요청

태스크는 다음과 같다: 고객이 "주문한 상품의 배송이 3일이나 늦어졌어요. 환불해 주세요"라고 요청한다. 올바른 에이전트는 (1) 주문 조회 API를 호출해 주문을 확인하고, (2) 배송 상태를 조회해 실제 지연을 검증하고, (3) 환불 정책을 조회해 자격을 판단하고, (4) 자격이 있다면 실제 환불을 처리하고, (5) 고객에게 정확히 안내해야 한다. 다섯 단계 모두가 "올바른 궤적"의 구성 요소다.

이제 두 에이전트를 비교하자. 에이전트 A는 위 다섯 단계를 모두 수행한다. 에이전트 B는 어떤 API도 호출하지 않고, 단지 "네, 환불 처리해 드리겠습니다. 영업일 기준 3~5일 내에 환불됩니다"라고 정중하게 답한다. 실제로는 아무것도 처리하지 않았다.

관점	에이전트 A (올바름)	에이전트 B (위험)
주문 조회 API 호출	수행	미수행
배송 상태 확인	수행	미수행
환불 정책 조회	수행	미수행
실제 환불 처리	수행	미수행(거짓 약속)
고객 안내 톤	정중·정확	정중·그럴듯함
LLM-as-Judge 점수 (응답만)	0.92	0.90
궤적 평가 점수 (과정 포함)	0.94	0.08

정적 평가의 치명적 맹점

최종 응답만 보는 LLM-as-Judge는 에이전트 B에게 0.90을 준다. 텍스트가 정중하고, 문법적으로 완벽하고, 고객의 요청에 적절히 응답하는 것처럼 보이기 때문이다. 그러나 에이전트 B는 실제 환불을 하지 않고 거짓 약속을 한, 프로덕션에 배포되면 즉각 고객 신뢰를 파괴할 시스템이다. 정적 평가는 이 차이를 0.02점으로밖에 보지 못한다. 궤적 평가는 0.86점의 격차로 본다.

6.4.2 인터랙티브 데모: 궤적 단계별 판단

아래 데모에서 에이전트 B의 궤적 각 스텝을 클릭하면, 그 지점에서 평가자가 내려야 할 판단이 표시된다. 정적 평가는 마지막 스텝 하나만 보지만, 궤적 평가는 모든 스텝을 검사한다.

에이전트 B의 궤적 — 각 스텝을 클릭하여 판단 포인트 확인

스텝을 클릭하면 그 지점의 평가 판단이 표시됩니다.

6.4.3 결과 일치가 과정 정당성을 보장하지 않는다

혹자는 반문할 수 있다. "에이전트 B의 응답이 결과적으로 고객을 만족시키면 되는 것 아닌가?" 그러나 핵심은 결과 일치(outcome agreement)가 과정 정당성(process legitimacy)을 보장하지 않는다는 점이다. 에이전트 B는 우연히 그럴듯한 텍스트를 생성했을 뿐, 실제 시스템 상태(주문, 환불, 정책)와는 완전히 단절되어 있다. 이런 에이전트는 약간만 상황이 달라져도—예컨대 환불 자격이 없는 주문에 대해서도—똑같이 "환불해 드리겠습니다"라고 답할 것이다. 이것이 궤적을 봐야만 발견되는 시스템적 결함이다.

# 과정 기반 평가기: 필수 도구 호출 체크리스트로 궤적 검증
def evaluate_support_trajectory(traj: Trajectory) -> dict:
    """고객 지원 환불 태스크의 과정 기반 평가"""
    required = {
        "lookup_order":     0.20,  # 주문 조회
        "check_shipping":   0.20,  # 배송 상태 확인
        "check_policy":     0.20,  # 환불 정책 조회
        "process_refund":   0.30,  # 실제 환불 처리(가장 중요)
    }
    called = {c["tool"] for c in traj.tool_calls()}
    process_score = sum(w for tool, w in required.items()
                        if tool in called)
    # 안내 품질(0.10)은 응답이 존재하면 부여
    has_final = any(s.kind == StepKind.FINAL for s in traj.steps)
    comm_score = 0.10 if has_final else 0.0
    # 거짓 약속 페널티: 환불을 약속했으나 처리하지 않은 경우
    promised = has_final and "process_refund" not in called
    penalty = 0.30 if promised else 0.0
    total = max(0.0, process_score + comm_score - penalty)
    return {"score": total, "missing": set(required) - called,
            "false_promise": promised}

# 에이전트 B: 어떤 도구도 호출하지 않고 환불을 약속
# → process_score=0, comm=0.10, penalty=0.30 → total=0.0 근처

6.5 MDP 관점: 에이전트 평가의 수학적 기초

궤적 평가를 엄밀하게 다루려면 적절한 수학적 틀이 필요하다. 강화학습(Reinforcement Learning, RL)에서 빌려온 마르코프 결정 과정(Markov Decision Process, MDP)이 그 틀을 제공한다. 에이전트를 MDP로 모델링하면, 직관적이던 개념들—성공, 효율, 보상—이 정밀한 수학적 대상이 된다.

6.5.1 에이전트를 MDP로 모델링하기

마르코프 결정 과정 (MDP) 5-튜플

$$\mathcal{M} = (S, A, P, R, \gamma)$$

$S$: 상태 공간(state space). $A$: 행동 공간(action space). $P(s' \mid s, a)$: 전이 확률(transition probability). $R(s, a)$: 보상 함수(reward function). $\gamma \in [0,1)$: 할인율(discount factor). 에이전트 평가에서 각 구성 요소는 환경과 태스크에 의해 정의된다.

각 구성 요소를 에이전트 평가의 언어로 해석하면 다음과 같다. 상태 공간 $S$는 환경이 가질 수 있는 모든 구성(웹페이지 상태, 파일시스템 상태, DB 상태)이다. 행동 공간 $A$는 에이전트가 취할 수 있는 모든 도구 호출과 응답이다. 전이 확률 $P$는 환경 동역학으로, 비결정론적(API 응답 변동, 네트워크 지연)이다. 보상 함수 $R$은 평가 설계자가 정의하는 것으로, 여기에 평가의 가치관이 담긴다. 할인율 $\gamma$는 미래 보상의 현재 가치를 조절한다.

MDP 요소	강화학습에서	에이전트 평가에서
$S$ 상태 공간	게임 화면, 로봇 센서	웹 DOM, 터미널, DB 스냅샷
$A$ 행동 공간	조이스틱, 모터 명령	도구 호출, 함수 인자, 텍스트 응답
$P$ 전이	물리 엔진, 게임 규칙	API·환경 동역학(비결정론적)
$R$ 보상	점수, 목표 도달	태스크 성공, 과정 품질, 안전 위반(음수)
$\gamma$ 할인	장기 vs 단기 균형	효율성 선호(짧은 궤적 보상)
$\pi$ 정책	학습된 신경망	LLM + 프롬프트 + 도구 스캐폴딩

6.5.2 궤적의 가치 함수

MDP에서 한 궤적의 가치는 누적 할인 보상(cumulative discounted reward)으로 정의된다. 이것이 평가에서 "이 궤적이 얼마나 좋은가"를 정량화하는 기초다.

궤적의 가치 (Return)

$$V(\tau) = \sum_{t=0}^{T} \gamma^t \, r(s_t, a_t)$$

각 스텝의 보상 $r(s_t, a_t)$를 할인율 $\gamma^t$로 가중해 합산. $\gamma < 1$이면 늦게 받는 보상의 가치가 줄어들어, 같은 결과를 더 적은 스텝으로 달성한 궤적이 더 높은 가치를 받는다(효율성 선호).

정책의 기대 가치는 그 정책으로 생성되는 모든 궤적의 가치를 기댓값으로 평균한 것이다. 환경이 비결정론적이므로, 같은 정책이라도 여러 궤적이 나오고, 평가는 이 분포(distribution)를 봐야 한다—이것이 6.10절 재현성 논의의 수학적 근거다.

정책의 기대 가치 (Expected Return)

$$J(\pi) = \mathbb{E}_{\tau \sim \pi, P}\left[ V(\tau) \right] = \mathbb{E}_{\tau}\left[ \sum_{t=0}^{T} \gamma^t \, r(s_t, a_t) \right]$$

$\tau \sim \pi, P$: 정책 $\pi$와 환경 전이 $P$가 함께 생성하는 궤적 분포. 에이전트 평가의 목표는 유한한 샘플로 이 기댓값을 추정하는 것이다.

6.5.3 보상 함수에 담기는 가치관

MDP의 가장 중요하면서도 미묘한 부분은 보상 함수 $R$이다. 보상 함수는 "무엇이 좋은 행동인가"에 대한 평가 설계자의 가치관을 인코딩한다. 같은 태스크라도 보상 함수를 어떻게 설계하느냐에 따라 전혀 다른 에이전트가 "최선"으로 평가된다. 결과만 보상하면 과정을 무시하는 에이전트가, 과정만 보상하면 결과를 놓치는 에이전트가 최적화된다.

보상 해킹(Reward Hacking)의 위험

잘못 설계된 보상 함수는 보상 해킹을 유발한다. 예컨대 "도구를 많이 호출할수록 보상"을 주면, 에이전트는 불필요한 도구를 남발한다. "응답이 길수록 보상"을 주면 장황한 답변이 나온다. 보상 함수는 평가의 헌법(constitution)이므로, 측정하려는 진짜 가치와 정렬(align)되도록 신중히 설계해야 한다. Ch.11~13에서 이 보상 설계를 6차원 메트릭으로 체계화한다.

# 보상 함수 설계: 결과 + 과정 + 안전 패널티의 결합
def reward_function(traj: Trajectory, gold_actions: list[str]) -> float:
    """에이전트 평가용 보상 함수 R(tau)"""
    # 1) 결과 보상: 태스크 성공 시 +1.0
    outcome = 1.0 if traj.success else 0.0
    # 2) 과정 보상: 정답 행동과의 일치율
    actual = [c["tool"] for c in traj.tool_calls()]
    matched = sum(1 for a in gold_actions if a in actual)
    process = matched / max(1, len(gold_actions))
    # 3) 효율 보상: 짧은 궤적 선호 (할인 효과)
    efficiency = 0.99 ** traj.horizon()
    # 4) 안전 패널티: 불가역 부작용 + 실패 시 강한 음수
    safety_penalty = -2.0 if traj.has_irreversible() and not traj.success else 0.0
    return (0.5 * outcome + 0.3 * process
            + 0.2 * efficiency + safety_penalty)

6.5.4 가치 함수와 행동 가치 함수

MDP의 핵심 도구는 두 가지 가치 함수다. 상태 가치 함수 $V^\pi(s)$는 "상태 $s$에서 정책 $\pi$를 따를 때 기대되는 누적 보상"이고, 행동 가치 함수 $Q^\pi(s, a)$는 "상태 $s$에서 행동 $a$를 한 뒤 $\pi$를 따를 때의 기대 보상"이다. 에이전트 평가에서 이 두 함수는 "현재 상태가 얼마나 유망한가"와 "이 행동이 좋은 선택이었나"를 정량화한다.

벨만 방정식 (Bellman Equation)

$$V^\pi(s) = \sum_{a} \pi(a \mid s) \sum_{s'} P(s' \mid s, a)\big[ r(s, a) + \gamma V^\pi(s') \big]$$

상태 가치는 현재 보상과 다음 상태 가치의 할인 합으로 재귀적으로 정의된다. 평가 관점에서, 정답 정책의 $V^*(s)$와 에이전트 정책의 $V^\pi(s)$의 차이가 "에이전트가 최적에서 얼마나 멀어졌는가"를 나타낸다.

어드밴티지 함수 (Advantage) — 행동의 상대적 가치

$$A^\pi(s, a) = Q^\pi(s, a) - V^\pi(s)$$

어드밴티지는 "특정 행동이 평균적 행동보다 얼마나 나은가"를 측정한다. $A > 0$이면 그 시점의 좋은 선택, $A < 0$이면 후회할 선택. 스텝별 어드밴티지를 추정하면 궤적 어디에서 에이전트가 잘못된 결정을 했는지(신용 할당)를 정밀하게 짚을 수 있다.

실무에서 에이전트의 $Q$를 정확히 계산하기는 어렵지만, LLM 평가자(judge)나 별도의 가치 모델로 근사할 수 있다. 핵심은 어드밴티지가 음수인 스텝을 찾으면 "이 스텝에서 에이전트가 후회할 결정을 했다"는 정밀한 진단을 얻는다는 점이다. 이것이 6.8.4절에서 언급한 신용 할당 문제의 수학적 해법이다.

6.6 관측 가능성과 로깅: 평가의 인프라

지금까지의 모든 평가—과정 점수, 어드밴티지, 궤적 거리—는 한 가지를 전제한다: 궤적을 완전히 관측할 수 있다. 그러나 이것은 공짜가 아니다. 에이전트가 무엇을 보고 무엇을 했는지를 빠짐없이 기록하는 로깅(logging) 인프라가 없으면, 사후 평가는 불가능하다. 이 절은 평가를 "가능하게 만드는" 기반 공학을 다룬다.

6.6.1 왜 완전한 관찰 로깅이 필수인가

6.8.1절에서 보았듯, 에이전트는 부분 관측 환경에서 동작한다. 에이전트가 실패했을 때 그 원인을 "추론 부족"과 "정보 부족"으로 가르려면, 평가자는 에이전트가 각 스텝에서 정확히 무엇을 관찰 $o_t$로 받았는지를 알아야 한다. 관찰을 로깅하지 않으면, "에이전트가 가격을 확인하지 않았다"는 비난이 "에이전트가 가격을 못 봤다"는 변호와 구분되지 않는다. 공정한 채점은 완전한 관찰 기록 위에서만 성립한다.

import json, time, hashlib

class TrajectoryLogger:
    """에이전트 실행을 완전히 기록하는 평가 로거"""

    def __init__(self, task_id: str, seed: int):
        self.task_id = task_id
        self.seed = seed                 # 재현성을 위한 시드 기록
        self.events = []
        self.t0 = time.time()

    def log_observation(self, t: int, obs) -> None:
        """환경 관찰 o_t를 기록 — 부분 관측성 재구성에 필수"""
        self.events.append({
            "t": t, "type": "observation",
            "content": obs,
            "hash": hashlib.sha256(str(obs).encode()).hexdigest()[:12],
            "wall_time": round(time.time() - self.t0, 3),
        })

    def log_action(self, t: int, action: dict, side_effect=False) -> None:
        """행동 a_t를 기록 — 부작용 플래그 포함"""
        self.events.append({
            "t": t, "type": "action",
            "tool": action.get("tool"), "args": action.get("args"),
            "side_effect": side_effect,
            "wall_time": round(time.time() - self.t0, 3),
        })

    def to_trajectory(self) -> dict:
        """감사 가능한(auditable) 궤적 JSON으로 직렬화"""
        return {"task_id": self.task_id, "seed": self.seed,
                "events": self.events,
                "total_wall_time": round(time.time() - self.t0, 3)}

6.6.2 부작용 추적과 감사 가능성

로깅의 두 번째 임무는 부작용(side effect)을 추적하는 것이다. 6.2.2절에서 강조했듯 에이전트의 행동은 실제 세계를 바꾼다. 평가 인프라는 어떤 행동이 불가역적 부작용을 일으켰는지를 명시적으로 표시해야 한다. 이것은 거버넌스와 감사(audit)의 토대가 된다—"이 에이전트가 평가 중 실제 이메일을 몇 통 보냈는가?"라는 질문에 정확히 답할 수 있어야 한다.

로깅 대상	왜 필요한가	평가에서의 용도
관찰 $o_t$	부분 관측성 재구성	실패 원인 귀속(정보 vs 추론)
행동 $a_t$ + 인자	과정 평가의 기본 단위	도구 정확성, 궤적 정렬
부작용 플래그	불가역 행동 추적	안전 거부권, 감사 추적
벽시계 시간	지연·효율 측정	효율성 차원, 타임아웃 진단
시드	재현성 보장	실패 재현, 회귀 디버깅
관찰 해시	환경 상태 변화 감지	비결정론 정량화

"로깅 없는 평가는 평가가 아니다"

전통적 소프트웨어 관측 가능성(observability)의 삼위일체—로그(log), 메트릭(metric), 추적(trace)—은 에이전트 평가에 그대로 적용된다. 단, 한 가지가 추가된다: 관찰 기록(observation capture). 에이전트가 본 것을 기록하지 않으면, 우리는 에이전트의 결정을 그 맥락에서 판단할 수 없다. 좋은 에이전트 플랫폼은 평가를 사후에 덧붙이는 것이 아니라, 모든 실행을 처음부터 완전히 기록하도록 설계한다. 이 기록 위에서 비로소 과정 평가, 안전 감사, 회귀 디버깅이 가능해진다.

6.7 결과·과정·혼합: 궤적 평가의 세 가지 철학

궤적을 어떻게 평가할 것인가에는 세 가지 근본 철학이 있다. 결과 지향(outcome-based), 과정 지향(process-based), 그리고 혼합(hybrid)이다. 이 셋의 선택은 단순한 기술적 결정이 아니라 "에이전트에게 무엇을 요구하는가"에 대한 철학적 입장이다.

6.7.1 결과 지향(Outcome-based) 평가

결과 지향 평가는 최종 상태 $s_T$만 본다. "태스크를 달성했는가?"라는 단 하나의 질문이다. WebArena의 성공률(success rate), SWE-bench(Jimenez et al., 2023, arXiv:2310.06770)의 테스트 통과율(test pass rate)이 대표적이다. 이 접근의 강점은 명확성과 객관성이다. 최종 상태가 목표 상태와 일치하는지는 종종 자동으로, 모호함 없이 판정할 수 있다.

결과 지향 평가

$$V_{\text{outcome}}(\tau) = \mathbb{1}[\,g(s_T) = g^*\,]$$

$g(s_T)$: 종료 상태에서 추출한 목표 변수, $g^*$: 정답 목표. 지표 함수 $\mathbb{1}[\cdot]$는 목표 달성 시 1, 아니면 0. 부분 점수(partial credit)를 위해 거리 함수로 일반화할 수 있다.

그러나 결과 지향 평가의 약점도 분명하다. 과정의 질을 완전히 무시한다. 6.4절의 에이전트 B처럼 운 좋게 결과를 맞춘 경우, 위험한 과정도 만점을 받는다. 또한 부분적으로 옳은 궤적(예: 5단계 중 4단계를 올바르게 수행했으나 마지막에 실패)을 0점으로 처리해, 개선의 신호를 잃는다.

6.7.2 과정 지향(Process-based) 평가

과정 지향 평가는 각 스텝의 품질을 본다. "올바른 도구를 호출했는가? 관찰을 정확히 해석했는가? 추론이 타당한가?"를 단계별로 채점한다. 궤적 매칭(trajectory matching), 스텝 단위 정확도(step-level accuracy), 도구 호출 정확성(tool call correctness)이 이 범주다.

과정 지향 평가

$$V_{\text{process}}(\tau) = \frac{1}{T+1} \sum_{t=0}^{T} q(s_t, a_t)$$

$q(s_t, a_t)$: 스텝 $t$의 품질 점수(예: 올바른 도구 선택=1, 부적절=0). 스텝별 품질을 평균. 가중 평균이나 정답 궤적과의 정렬(alignment) 기반으로 일반화 가능.

과정 지향 평가의 강점은 중간 실수를 포착하고, 부분 점수를 제공하며, 개선 방향을 알려준다는 점이다. 그러나 치명적 난점이 있다: "올바른 과정"을 정의하기가 어렵다. 대부분의 태스크는 정답에 이르는 경로가 여럿이다. 정답 궤적(gold trajectory) 하나를 고정하면, 그와 다르지만 동등하게 유효한 경로를 부당하게 감점하게 된다.

과정과 결과의 간극(The Gap)

과정 평가와 결과 평가 사이의 간극을 메우는 것이 현재 에이전트 평가 연구의 핵심이다. 결과만 보면 위험한 성공을 놓치고, 과정만 보면 "정답 경로"의 독재(tyranny of the gold path)에 빠진다. 이상적인 평가는 "결과가 옳고 + 과정도 정당한" 궤적에만 만점을 주되, 다양한 유효 경로를 인정하는 유연성을 갖춰야 한다. 이것이 6차원 프레임워크(Part III)가 풀려는 문제다.

6.7.3 혼합(Hybrid) 평가

실무적 해법은 결과와 과정을 가중 결합하는 혼합 평가다. 두 신호의 장점을 취하고 단점을 상쇄한다.

혼합 평가

$$V_{\text{hybrid}}(\tau) = \alpha \cdot V_{\text{outcome}}(\tau) + (1 - \alpha) \cdot V_{\text{process}}(\tau)$$

$\alpha \in [0, 1]$: 결과 가중치. $\alpha=1$이면 순수 결과 지향, $\alpha=0$이면 순수 과정 지향. 도메인에 따라 조절: 안전 중요 분야는 과정 가중치를 높이고, 명확한 정답이 있는 분야는 결과 가중치를 높인다.

철학	측정 대상	장점	단점	대표 벤치마크
결과 지향	최종 상태 $s_T$	명확·객관·자동 채점	과정 무시, 운 좋은 성공 통과	WebArena, SWE-bench
과정 지향	각 스텝 $q(s_t,a_t)$	중간 실수 포착, 부분 점수	정답 경로 정의 난해	궤적 매칭, ToolBench
혼합	결과 + 과정 가중합	균형, 도메인 적응	가중치 $\alpha$ 튜닝 필요	AgentBench(reasoning+action)

흥미롭게도 AgentBench는 "reasoning score"와 "action score"를 분리 측정하는데(Liu et al., 2023), 이는 사실상 과정(reasoning)과 결과 지향 행동(action)을 나눠 본 혼합 접근의 초기 형태다. 도구 사용 능력이 전체 성능에 핵심적이라는 그들의 관찰은, 결과만으로는 보이지 않는 과정 차원의 중요성을 방증한다.

세 평가 철학의 트레이드오프

α 변화에 따른 점수 민감도

혼합 평가를 코드로 구현할 때 주의할 점은, 결과·과정 점수가 같은 스케일(0~1)에 있어야 하고, 안전 위반은 가중 평균이 아니라 별도의 거부권(veto)으로 처리해야 한다는 것이다. 아래 구현은 이 두 원칙을 모두 반영한다.

def hybrid_evaluate(traj: Trajectory, gold_actions: list[str],
                    alpha: float = 0.5) -> dict:
    """결과·과정 혼합 평가 + 안전 거부권"""
    # 1) 결과 점수: 태스크 성공 여부
    v_outcome = 1.0 if traj.success else 0.0
    # 2) 과정 점수: 궤적 정렬(6.3.5의 편집 거리 재사용)
    actual = [c["tool"] for c in traj.tool_calls()]
    v_process = trajectory_distance(actual, gold_actions)["alignment_score"]
    # 3) 혼합: V = a*outcome + (1-a)*process
    v_hybrid = alpha * v_outcome + (1 - alpha) * v_process
    # 4) 안전 거부권: 가중 평균에 참여시키지 않고 따로 차단
    if detect_reward_hacking(traj) or (
            traj.has_irreversible() and not traj.success):
        return {"score": 0.0, "gate": "FAIL",
                "outcome": v_outcome, "process": round(v_process, 3)}
    return {"score": round(v_hybrid, 3), "gate": "PASS",
            "outcome": v_outcome, "process": round(v_process, 3)}

6.8 동적 환경의 네 가지 복잡성

에이전트 평가가 LLM 평가보다 본질적으로 어려운 이유는 환경의 동적(dynamic) 성질에 있다. 이 동역학은 네 가지 복잡성으로 분해된다: 부분 관측성, 비결정론, 상태 의존성, 장기 지평. 각각은 평가 설계에 고유한 도전을 제기한다.

6.8.1 부분 관측 가능(Partially Observable)

현실의 에이전트는 환경의 전체 상태를 결코 볼 수 없다. 웹 에이전트는 화면에 보이는 DOM 일부만 관측하고, 스크롤해야 보이는 요소나 다른 페이지의 정보는 가려져 있다. API 에이전트는 응답이 잘리거나(truncated) 페이지네이션(pagination)되어 부분 정보만 받는다. 이런 상황은 부분 관측 MDP(Partially Observable MDP, POMDP)로 모델링된다.

부분 관측 MDP (POMDP) 7-튜플

$$\mathcal{M}_{PO} = (S, A, P, R, \Omega, O, \gamma)$$

기존 MDP에 $\Omega$(관찰 공간)와 $O(o \mid s', a)$(관찰 함수: 실제 상태 $s'$에서 관찰 $o$가 나올 확률)가 추가된다. 에이전트는 진짜 상태 $s$를 보지 못하고 관찰 $o$만 받으므로, 신념 상태(belief state) $b(s)$를 추론해야 한다.

부분 관측성은 평가에 두 가지 도전을 던진다. 첫째, 에이전트의 실패가 "추론 능력 부족" 때문인지 "정보를 못 봤기 때문"인지 구분하기 어렵다. 둘째, 평가자조차 에이전트가 무엇을 "봤는지"를 정확히 재구성해야 공정한 채점이 가능하다. 그래서 좋은 평가 인프라는 매 스텝의 관찰 $o_t$를 완전히 로깅한다.

실패 원인을 귀속(attribution)하려면, 에이전트가 각 시점에 "알 수 있었던 정보"를 추적해야 한다. 아래 코드는 관찰 로그로부터 "에이전트가 특정 사실을 관측할 기회가 있었는가"를 판정해, 정보 부족과 추론 부족을 가른다.

def attribute_failure(traj: Trajectory, required_fact: str) -> str:
    """실패를 '정보 부족' vs '추론 부족'으로 귀속 (부분 관측 진단)"""
    # 에이전트가 required_fact를 관측할 기회가 있었는가
    observed = any(required_fact in str(s.observation)
                   for s in traj.steps
                   if s.kind == StepKind.OBSERVE)
    # 에이전트가 그 정보를 얻기 위한 탐색 행동을 했는가
    explored = any(s.kind == StepKind.ACT for s in traj.steps)
    if observed:
        # 정보는 봤는데 실패 → 추론/실행 문제
        return "reasoning_failure"
    elif not explored:
        # 정보를 찾으려는 시도조차 안 함 → 계획 문제
        return "planning_failure"
    else:
        # 탐색은 했으나 정보가 가려져 있었음 → 환경/정보 문제
        return "information_failure"

# 같은 '실패'라도 귀속이 다르면 개선 방향이 완전히 달라진다

6.8.2 비결정론적(Nondeterministic)

같은 상태에서 같은 행동을 해도 결과가 다를 수 있다. API가 타임아웃되거나, 네트워크 오류가 나거나, 서버 부하로 응답이 달라지거나, LLM 자체의 샘플링(temperature>0)으로 다른 행동이 나온다. 이 비결정론은 전이 확률 $P(s' \mid s, a)$가 디랙 델타(Dirac delta)가 아니라 진짜 분포라는 의미다.

성공 확률의 기댓값 추정

$$P(\text{success}) = \mathbb{E}_{\tau \sim \pi, P}\big[\mathbb{1}[\text{success}(\tau)]\big] \approx \frac{1}{n} \sum_{i=1}^{n} \mathbb{1}[\text{success}(\tau_i)]$$

$n$번 독립 시행한 궤적 $\tau_1, \ldots, \tau_n$의 성공 비율로 진짜 성공 확률을 추정. 비결정론 때문에 단일 시행으로는 정책을 평가할 수 없고, 반드시 다중 시행이 필요하다.

평가의 성배(Holy Grail)

비결정론적 환경에서 재현성(reproducibility)을 확보하는 것은 에이전트 평가의 성배다. 같은 에이전트, 같은 태스크라도 실행할 때마다 다른 점수가 나오면, "이 버전이 이전보다 나아졌는가"라는 가장 기본적인 질문에 답할 수 없다. 시드 고정(seed pinning), 환경 스냅샷(snapshot), 모킹(mocking), 다중 시행 평균—이 모든 기법이 재현성을 향한 분투다. 6.10절에서 이 도구들을 자세히 다룬다.

6.8.3 상태 의존(Stateful)

에이전트의 행동은 환경 상태를 영구히 바꾸고, 이는 이후 가능한 행동을 제한하거나 확장한다. "이메일을 이미 보냈으면 다시 보낼 필요가 없다." "파일을 삭제했으면 더 이상 읽을 수 없다." "장바구니에 담았으면 이제 결제할 수 있다." 이런 상태 의존성은 행동을 독립적으로 평가할 수 없게 만든다. 같은 행동도 맥락에 따라 옳거나 그르다.

상태 의존성은 마르코프 성질(Markov property)의 적용을 미묘하게 만든다. 이론적으로 상태 $s_t$가 모든 관련 이력을 포함하면 마르코프 성질이 성립하지만, 실제로는 상태 표현이 불완전해 "숨은 이력 의존성"이 생긴다. 평가자는 행동을 평가할 때 그 시점의 완전한 상태 맥락을 함께 고려해야 한다.

# 상태 의존성 검증: 중복/모순 행동 탐지
def detect_stateful_violations(traj: Trajectory) -> list[str]:
    """상태 의존 규칙 위반 탐지 (중복 발송, 사후 참조 등)"""
    violations = []
    sent_emails, deleted_files = set(), set()
    for s in traj.steps:
        if s.kind != StepKind.ACT or not s.action:
            continue
        tool, args = s.action["tool"], s.action.get("args", {})
        if tool == "send_email":
            key = (args.get("to"), args.get("subject"))
            if key in sent_emails:           # 이미 보낸 이메일 중복
                violations.append(f"중복 발송 t={s.t}: {key}")
            sent_emails.add(key)
        elif tool == "delete_file":
            deleted_files.add(args.get("path"))
        elif tool == "read_file":
            if args.get("path") in deleted_files:  # 삭제 후 읽기 시도
                violations.append(f"삭제된 파일 참조 t={s.t}")
    return violations

6.8.4 장기 지평(Long-horizon)

네 번째 복잡성은 장기 지평이다. 실제 태스크는 수십에서 수백 스텝에 걸쳐 진행된다. 긴 지평은 두 문제를 낳는다. 첫째, 신용 할당(credit assignment) 문제—최종 실패가 어느 스텝의 잘못 때문인지 추적하기 어렵다. 둘째, 오류 전파(error propagation)—초기의 작은 실수가 후속 스텝으로 증폭되어 복합적 실패가 된다. 이 두 번째 문제는 너무 중요해서 다음 절 전체를 할애한다.

복잡성	수학적 형식	평가 도전	대응 기법
부분 관측	POMDP, 신념 상태 $b(s)$	실패 원인 귀속(정보 부족 vs 추론 부족)	완전한 관찰 로깅
비결정론	$P(s'\|s,a)$가 분포	단일 시행 무의미, 재현성 상실	다중 시행, 시드 고정
상태 의존	이력 의존 행동 평가	행동의 맥락 의존적 정당성	상태 추적, 규칙 검증
장기 지평	큰 $T$, 신용 할당	오류 전파, 실패 귀속	스텝 보상, 중간 체크포인트

6.9 오류 전파와 복합 실패

장기 지평 평가의 핵심 위험은 오류 전파(error propagation)다. 직관은 간단하다: 매 스텝의 성공 확률이 높아도, 많은 스텝을 모두 성공해야 전체가 성공하므로, 전체 성공률은 급격히 떨어진다. 이 효과를 정량화하면 에이전트 평가에서 가장 중요한 부등식 하나가 나온다.

6.9.1 독립 스텝 가정 하의 성공률

독립 스텝 성공률 (최선의 경우)

$$P(\text{success}) = \prod_{t=1}^{T} p_t = p^T \quad (\text{if } p_t = p \;\forall t)$$

스텝별 성공 확률 $p_t$가 독립이라 가정하면, 전체 성공률은 곱으로 표현된다. 모든 스텝의 성공 확률이 동일하게 $p$라면 $p^T$. 이것은 오류가 전파되지 않는 "최선의 경우"다.

숫자를 넣어 보면 충격적이다. 스텝당 성공률이 95%(매우 높다)라도, 20스텝 태스크의 전체 성공률은 $0.95^{20} \approx 0.358$, 즉 36%에 불과하다. 50스텝이면 $0.95^{50} \approx 0.077$로 8%까지 추락한다. 우연찮게도 $0.95^{20} \approx 0.358$이라는 값은 WebArena에서 GPT-4가 기록한 35.8% 성공률과 거의 일치한다—긴 지평이 성능의 천장을 어떻게 누르는지 보여주는 우연한 일치다.

95%의 함정

"우리 에이전트의 스텝 정확도는 95%입니다"는 인상적으로 들린다. 그러나 이 진술은 태스크 지평을 명시하지 않으면 무의미하다. 5스텝 태스크라면 77% 성공률이지만, 30스텝 태스크라면 21%에 불과하다. 에이전트 성능을 보고할 때는 반드시 지평 길이와 함께 보고해야 한다. 스텝 정확도와 태스크 성공률을 혼동하면 심각한 과대평가에 빠진다.

6.9.2 오류 전파가 있는 현실

현실은 독립 가정보다 더 나쁘다. 초기 오류는 후속 스텝의 성공 확률을 낮춘다(전파). 예컨대 첫 스텝에서 잘못된 페이지로 이동하면, 이후 모든 행동이 잘못된 맥락에서 이뤄진다. 이를 모델링하려면 조건부 성공 확률을 도입해야 한다.

오류 전파 모델 (조건부 성공률)

$$P(\text{success}) = \prod_{t=1}^{T} p_t^{\,\text{eff}}, \qquad p_t^{\,\text{eff}} = p_t \cdot (1 - \rho)^{e_{$e_{0$이면 오류가 누적되며 성공률이 독립 가정보다 빠르게 하락한다.

import numpy as np

def simulate_horizon_success(p_step=0.95, rho=0.0,
                             horizons=range(1, 51), n_sim=20000):
    """오류 전파를 포함한 지평별 성공률 시뮬레이션"""
    results = {}
    for T in horizons:
        successes = 0
        for _ in range(n_sim):
            errors, ok = 0, True
            for t in range(T):
                p_eff = p_step * (1 - rho) ** errors  # 전파로 깎인 성공률
                if np.random.random() > p_eff:
                    errors += 1; ok = False; break  # 첫 실패에서 중단
            successes += ok
        results[T] = successes / n_sim
    return results

# rho=0: 독립 가정(p^T), rho=0.2: 오류 전파 → 더 가파른 하락
indep = simulate_horizon_success(p_step=0.95, rho=0.0)
propag = simulate_horizon_success(p_step=0.95, rho=0.2)
print("T=20", round(indep[20], 3), round(propag[20], 3))
# 예: 0.358 vs ~0.21 — 전파가 있으면 성공률이 더 낮다

지평 길이에 따른 태스크 성공률 (오류 전파 효과)

복구 능력(Recovery)이 새로운 핵심 역량

오류 전파의 함의는 명확하다. 긴 지평에서 높은 성공률을 얻으려면, 스텝 정확도를 높이는 것만으로는 부족하다. 오류를 감지하고 복구하는 능력이 결정적이다. 잘못된 행동 후 "이건 틀렸다, 되돌아가자"라고 판단할 수 있는 에이전트는, 전파 계수 $\rho$를 사실상 낮춰 성공률 곡선을 위로 끌어올린다. 그래서 6차원 프레임워크(Part III)에서 견고성(Robustness)—특히 fault recovery—이 독립 차원으로 다뤄진다.

6.10 비결정론과 재현성: 한 번으로는 안 된다

비결정론적 환경에서 단 한 번의 실행으로 에이전트를 평가하는 것은 동전을 한 번 던져 그 동전이 공정한지 판단하는 것과 같다. 진짜 성능 분포를 추정하려면 다중 시행과 적절한 통계가 필요하다. 코드 생성 분야에서 표준이 된 두 지표—$pass@k$와 $pass^k$—가 이 문제의 핵심을 보여준다.

6.10.1 pass@k: 관용적 성공 지표

$pass@k$는 "$k$번 시도 중 적어도 한 번 성공할 확률"이다. Codex 논문(Chen et al., 2021, arXiv:2107.03374)에서 정립된 이 지표는 "여러 후보 중 하나만 맞으면 된다"는 관용적(lenient) 설정에 적합하다.

pass@k 추정량 (Chen et al., 2021)

$$\text{pass@}k = \mathbb{E}_{\text{problems}}\left[ 1 - \frac{\binom{n-c}{k}}{\binom{n}{k}} \right]$$

$n$: 생성한 총 샘플 수, $c$: 그중 정답 샘플 수, $k$: 평가 시 허용 시도 수. $\binom{n-c}{k}/\binom{n}{k}$는 $k$개를 뽑았을 때 모두 오답일 확률이므로, 1에서 빼면 적어도 하나 성공할 확률이 된다. 이 추정량은 분산이 낮아 안정적이다.

6.10.2 pass^k: 신뢰성 지표

반대로 $pass^k$는 "$k$번 시도해서 모두 성공할 확률"이다. 프로덕션 에이전트의 신뢰성(reliability)을 측정하는 데 적합하다—한 번이라도 실패하면 곤란한 고위험 환경에서는 "운 좋게 한 번 성공"이 아니라 "항상 성공"이 중요하다.

pass^k (전 시행 성공 확률)

$$\text{pass}^k = \left(P(\text{success})\right)^k \approx \hat{p}^{\,k}$$

단일 성공 확률 $\hat{p}$를 $k$제곱. $\hat{p}=0.9$라도 $\text{pass}^5 = 0.59$로, 5회 연속 성공 확률은 59%에 불과하다. 신뢰성 관점에서 단일 성공률이 얼마나 오해를 줄 수 있는지 보여준다.

import numpy as np
from math import comb

def pass_at_k(n: int, c: int, k: int) -> float:
    """Chen et al. 2021의 안정적 pass@k 추정량"""
    if n - c < k:
        return 1.0  # 오답이 k개 미만이면 반드시 성공 포함
    return 1.0 - comb(n - c, k) / comb(n, k)

def evaluate_with_repeats(run_fn, task, n=10) -> dict:
    """비결정론적 에이전트를 n회 반복 실행하여 분포 추정"""
    outcomes = [run_fn(task).success for _ in range(n)]
    c = sum(outcomes)
    p_hat = c / n
    # Wilson 신뢰구간(이항 비율의 안정적 CI)
    z = 1.96
    denom = 1 + z*z/n
    center = (p_hat + z*z/(2*n)) / denom
    half = z*np.sqrt(p_hat*(1-p_hat)/n + z*z/(4*n*n)) / denom
    return {
        "p_hat": p_hat,
        "pass@1": pass_at_k(n, c, 1),
        "pass@5": pass_at_k(n, c, 5),
        "pass^3": p_hat ** 3,             # 신뢰성 지표
        "ci95": (center - half, center + half),
    }

지표	질문	적합 상황	$\hat{p}=0.9$일 때 ($k=5$)
pass@1	한 번에 성공하나?	기본 단발 평가	0.90
pass@5	5번 중 하나라도?	후보 생성·재시도 허용	≈ 1.00
pass^5	5번 모두 성공?	고신뢰 프로덕션	0.59
분산 $\sigma^2$	얼마나 흔들리나?	안정성 비교	$p(1-p)/n$

6.10.3 재현성을 위한 실무 도구

분포를 추정하는 것을 넘어, 평가를 가능한 한 재현 가능하게 만드는 공학적 노력이 필요하다. WebArena가 정적 스냅샷(static snapshot) 환경을 사용하는 이유도 바로 재현성이다—실시간으로 변하는 웹사이트에서는 어제의 성공이 오늘은 실패가 될 수 있기 때문이다(Zhou et al., 2023). 그러나 정적 스냅샷은 "실시간 업데이트 불가"라는 대가를 치른다. 재현성과 현실성(realism) 사이의 이 긴장은 에이전트 평가 설계의 영원한 트레이드오프다.

재현성 기법	원리	장점	한계
시드 고정(seed pinning)	LLM·환경 난수 시드 고정	샘플링 비결정성 제거	외부 API 변동은 못 막음
환경 스냅샷	웹·DB를 특정 시점으로 동결	외부 상태 고정	현실성 저하, 노후화
도구 모킹(mocking)	외부 API를 녹화 응답으로 대체	완전 결정론, 빠름·저렴	실제 API 동작과 괴리
다중 시행 평균	$n$회 반복 후 통계량 보고	분포 정직하게 추정	비용 $n$배 증가
컨테이너 격리	Docker로 환경 재현	의존성·OS 상태 동결	비결정적 동시성은 잔존

재현성-현실성 트레이드오프

완벽한 재현성과 완벽한 현실성은 동시에 가질 수 없다. 도구를 모킹하면 결정론적이지만 실제 API의 미묘한 동작을 놓친다. 라이브 API를 쓰면 현실적이지만 재현 불가능하다. 실무의 해답은 계층적 전략이다: 개발·회귀 테스트에는 모킹·스냅샷으로 빠르고 재현 가능한 평가를, 출시 전 최종 검증에는 라이브 환경에서 다중 시행 평가를 적용한다. Ch.14의 CI/CD 파이프라인이 이 계층 전략을 구현한다.

6.10.4 분산 추정과 부트스트랩

다중 시행으로 성공률을 추정했다면, 그 추정의 불확실성을 정직하게 보고해야 한다. 표본이 작을 때(에이전트 평가에서는 흔하다) 정규 근사가 부정확하므로, 부트스트랩(bootstrap)으로 분포를 직접 추정하는 것이 안전하다. 부트스트랩은 관측된 결과를 복원 추출(resampling)해 통계량의 분포를 경험적으로 만든다.

부트스트랩 신뢰구간

$$\hat{p}^{*(b)} = \frac{1}{n}\sum_{i=1}^{n} x_i^{*(b)}, \qquad \text{CI}_{95} = \big[\,Q_{2.5}(\hat{p}^*),\; Q_{97.5}(\hat{p}^*)\,\big]$$

$x_i^{*(b)}$: $b$번째 부트스트랩 표본(원 결과에서 복원 추출), $Q_\alpha$: 부트스트랩 분포의 $\alpha$ 분위수. 분포 가정 없이 신뢰구간을 얻으므로 소표본에 견고하다.

import numpy as np

def bootstrap_success_ci(outcomes: list[int], n_boot=10000,
                        seed=0) -> dict:
    """성공/실패 결과의 부트스트랩 신뢰구간 (소표본 견고)"""
    rng = np.random.default_rng(seed)       # 재현성: 시드 고정
    arr = np.asarray(outcomes, dtype=float)
    n = len(arr)
    boots = np.empty(n_boot)
    for b in range(n_boot):
        sample = rng.choice(arr, size=n, replace=True)  # 복원 추출
        boots[b] = sample.mean()
    return {
        "p_hat": float(arr.mean()),
        "ci_95": (float(np.percentile(boots, 2.5)),
                   float(np.percentile(boots, 97.5))),
        "std_err": float(boots.std()),
    }

# 사례 3의 에이전트 W: 10회 중 6회 성공
print(bootstrap_success_ci([1,1,0,1,1,0,1,0,1,0]))
# p_hat=0.6, ci_95≈(0.3, 0.9) — 소표본이라 구간이 매우 넓다

넓은 신뢰구간을 숨기지 말 것

에이전트 평가의 작은 표본은 필연적으로 넓은 신뢰구간을 낳는다. "성공률 60%"라는 점 추정만 보고하고 신뢰구간 [30%, 90%]를 숨기면, 독자는 실제보다 훨씬 확실한 결론을 내린다. 정직한 평가는 항상 불확실성을 함께 보고한다—넓은 구간은 부끄러운 것이 아니라, 더 많은 시행이 필요하다는 정확한 신호다.

6.11 평가 방법론의 진화 트리

지금까지의 논의를 한 장의 지도로 정리하자. 텍스트 평가에서 에이전트 평가로의 분기는 마치 진화 계통수(phylogenetic tree)처럼 가지를 친다. 아래 트리는 각 방법론이 어디서 갈라져 나왔는지, 그리고 어떤 가지가 현재 연구의 최전선인지를 보여준다.

평가 방법론
├── 텍스트 평가 (Part I · 정상과학)
│ ├── 참조 기반 — BLEU(2002), ROUGE(2004): n-gram 중첩
│ ├── LLM-as-Judge — G-Eval, GPT-4 평가: 확률적 CoT 채점
│ └── 인간 평가 — Crowdsourcing, Chatbot Arena: 선호 비교
│
└── 에이전트 평가 (Part II~III · 혁명)
├── 결과 기반 (Outcome)
│ ├── Success Rate — WebShop, WebArena: 목표 상태 일치
│ └── Test Pass Rate — SWE-bench: 단위 테스트 통과
├── 과정 기반 (Process)
│ ├── Trajectory Matching — 정답 궤적과의 정렬
│ ├── Step-level Accuracy — 스텝별 품질 채점
│ └── Tool Call Correctness — ToolBench: 도구·인자 정확성
└── 혼합 (Hybrid)
├── Multi-dimensional Scoring — 6차원 프레임워크 (Part III)
└── Human-AI Collaborative — 인간 검토 + 자동 채점 결합

6.11.1 분기의 의미: 무엇이 보존되고 무엇이 새로운가

이 트리에서 주목할 점은, 에이전트 평가가 텍스트 평가를 폐기하지 않는다는 것이다. LLM-as-Judge는 에이전트의 "최종 응답"이나 "추론 단계"를 채점하는 데 여전히 쓰인다. 인간 평가는 자동 채점이 어려운 미묘한 판단에 동원된다. 새로운 것은 이들 위에 추가된 과정 차원과 환경 상호작용 차원이다. 쿤의 표현을 빌리면, 새 패러다임은 옛 패러다임의 도구를 흡수하되 더 넓은 현상을 설명하는 틀로 재배치한다.

가지	측정 단위	자동화	현재 성숙도
참조 기반	n-gram 중첩	완전 자동	성숙(포화)
LLM-as-Judge	응답·추론 품질	반자동	성숙·확산 중
Success Rate	목표 상태 일치	자동(검증기 필요)	표준화 진행
Trajectory Matching	궤적 정렬	반자동	활발한 연구
Tool Call Correctness	도구·인자	자동	도구 생태계 의존
Multi-dimensional	6차원 종합	반자동	최전선(이 책의 주제)

이 분류 체계는 단순한 정리표가 아니라, 새 평가 방법을 만났을 때 그것이 무엇을 측정하고 무엇을 놓치는지를 빠르게 진단하는 도구다. 아래 함수는 평가 방법의 특성을 입력받아 진화 트리의 어느 가지에 속하는지, 그리고 어떤 사각지대를 갖는지를 분류한다.

def classify_eval_method(uses_trajectory: bool, checks_process: bool,
                         checks_outcome: bool, checks_safety: bool) -> dict:
    """평가 방법을 진화 트리 가지로 분류하고 사각지대를 진단"""
    if not uses_trajectory:
        branch = "텍스트 평가 (정상과학)"
    elif checks_process and checks_outcome:
        branch = "혼합 (Hybrid)"
    elif checks_process:
        branch = "과정 기반 (Process)"
    else:
        branch = "결과 기반 (Outcome)"
    # 사각지대 진단: 보지 못하는 차원 열거
    blind_spots = []
    if not checks_process: blind_spots.append("위험한 성공(과정 미검사)")
    if not checks_outcome: blind_spots.append("실질 달성 여부")
    if not checks_safety:  blind_spots.append("불가역 부작용·거부권")
    return {"branch": branch, "blind_spots": blind_spots}

print(classify_eval_method(True, False, True, False))
# {'branch': '결과 기반', 'blind_spots': ['위험한 성공', '불가역 부작용·거부권']}
# → SWE-bench류: 결과는 보지만 과정·안전을 놓친다

6.11.2 분기점의 인터랙티브 탐색

아래 아코디언에서 각 방법론을 펼치면 핵심 특징과 한계를 확인할 수 있다.

참조 기반 평가 (BLEU/ROUGE)

정답 텍스트와의 n-gram 중첩을 측정. 빠르고 완전 자동이지만, 의미는 같아도 표현이 다른 출력을 감점하고, 에이전트의 행동 차원을 전혀 보지 못한다. 정상과학 패러다임의 전형.

결과 기반 Success Rate (WebArena)

최종 환경 상태가 목표와 일치하는지를 검증기(checker)로 판정. 객관적이고 자동화 가능하나, 과정의 안전성·효율성을 무시하고 부분 점수가 없다. 운 좋은 성공을 만점 처리하는 위험.

과정 기반 Trajectory Matching

에이전트 궤적을 정답 궤적과 정렬해 채점. 중간 실수를 잡고 부분 점수를 주지만, 유효한 대안 경로를 부당하게 감점할 수 있다("정답 경로의 독재"). 다중 정답 궤적이나 의미 기반 정렬로 완화.

혼합 Multi-dimensional Scoring

결과·과정·안전·효율 등 여러 차원을 가중 종합. 균형 잡히고 도메인 적응적이나, 가중치 설계와 차원 정의가 복잡하다. 이 책의 6차원 프레임워크가 이 가지에 속하며, Safety는 거부권(veto)으로 별도 취급한다.

6.12 실제 벤치마크의 평가 설계 분석

이론을 실제 벤치마크에 비춰 보면 패러다임 전환이 어떻게 구현되는지가 선명해진다. AgentBench, WebArena, SWE-bench는 각각 다른 환경과 평가 철학을 대표한다.

6.12.1 AgentBench: 다환경 종합 평가

AgentBench(Liu et al., 2023, arXiv:2308.03688)는 LLM을 에이전트로 평가하는 최초의 종합 벤치마크 중 하나다. 8개의 이질적 환경—운영체제(Linux 터미널 파일 조작), 데이터베이스(SQL), 지식 그래프(SPARQL), 디지털 카드 게임(Dominion), 횡적 사고 퍼즐, 자원 분배(House Allocation), 웹 쇼핑, 다중 대화—에서 의사결정 능력을 측정한다. 환경마다 고유한 성공 기준이 있고, 전체 점수는 8개 환경의 평균이다.

AgentBench의 가장 통찰력 있는 설계는 "reasoning score"와 "action score"의 분리 측정이다. 이것은 6.7절의 과정/결과 이분법을 실증적으로 구현한 것이다. 그들의 주요 발견—GPT-4가 평균 약 46%로 압도적 1위이지만 환경 간 편차가 크고(OS에서는 높지만 게임/퍼즐에서는 낮음), 도구 사용 능력이 성능에 핵심적—은 단일 스칼라 점수가 에이전트 능력의 다차원성을 가린다는 점을 드러낸다.

환경	행동 유형	성공 기준	평가 철학
운영체제(OS)	Bash 명령	목표 파일 상태 도달	결과 기반
데이터베이스	SQL 쿼리	쿼리 결과 정확성	결과 기반
지식 그래프	SPARQL 탐색	정답 엔티티 도달	결과 + 과정
카드 게임	게임 내 행동	승률·점수	결과 기반(확률적)
웹 쇼핑	탐색·구매	목표 상품 구매	결과 기반
다중 대화	대화 응답	상호작용 품질	과정 기반

AgentBench가 드러낸 한계

AgentBench 저자들이 스스로 지적한 한계는 패러다임 전환의 미완성을 보여준다. (1) 환경이 너무 단순화되어 실제 프로덕션과 거리가 있고, (2) 도구 호출 1회로 해결 가능한 문제가 많으며, (3) 멀티 에이전트 시나리오가 없고, (4) 평가 비용이 매우 높다. 이 한계들이 곧 Part III 6차원 프레임워크와 멀티 에이전트 평가(Ch.08)가 채우려는 공백이다.

6.12.2 WebArena: 현실적 웹 환경

WebArena(Zhou et al., 2023, arXiv:2307.13854, ICLR 2024)는 현실성에 초점을 맞춘다. 기존 벤치마크(WebShop, ALFWorld)가 단순화된 환경이었던 데 반해, WebArena는 GitLab, Map, Shopping Admin, Reddit, Forum 등 실제 웹사이트를 복제한 환경에서 812개의 태스크를 정의한다. 각 태스크는 시작 URL과 의도(intent)로 명시되며, 성공 기준은 최종 상태가 목표 상태와 일치하는지다.

WebArena의 평가 방법은 결과 기반의 정수다. 성공률(Success Rate)을 주 지표로, 일부 태스크에는 문자 편집 거리(character edit distance)와 최종 URL 매칭을 보조 지표로 쓴다. 태스크는 Easy/Medium/Hard/Extra Hard로 난이도가 등급화된다. 가장 충격적인 결과는 인간-에이전트 격차다: GPT-4 + 기본 도구가 약 35.8% 성공률인 반면, 인간은 약 78.2%를 기록했다(Zhou et al., 2023). 이 42%포인트의 격차가 에이전트 평가가 측정해야 할 "갈 길"을 정량화한다.

WebArena: 인간 vs 에이전트 성공률

벤치마크별 평가 차원 비중

WebArena 역시 한계를 명시한다. 웹사이트가 정적 스냅샷이어서 실시간 업데이트를 반영하지 못하고(재현성-현실성 트레이드오프의 산물), 일부 태스크의 성공 기준이 모호하며, 멀티 에이전트를 지원하지 않는다. 그럼에도 WebArena-Lite(2024)로 빠른 평가를 가능하게 했고, AgentBench·OSWorld 등 후속 벤치마크의 기반이 되었다.

6.12.3 SWE-bench: 코드 수정의 결과 기반 평가

SWE-bench(Jimenez et al., 2023, arXiv:2310.06770)는 결과 기반 평가의 또 다른 정점이다. GitHub의 실제 이슈와 풀 리퀘스트(pull request)에서 추출한 2,294개 과제에서, 에이전트는 코드베이스를 수정해 버그를 고쳐야 한다. 평가 기준은 명쾌하다: 해당 이슈의 단위 테스트(unit test)가 통과하는가. 이 검증기는 완전 자동이고 객관적이며 조작이 어렵다.

SWE-bench가 강력한 이유는 "결과의 객관적 검증 가능성"이다. 테스트 통과 여부는 논쟁의 여지가 없다. 그러나 이 강점이 곧 한계이기도 하다. 테스트가 잡지 못하는 코드 품질(가독성, 부작용, 보안 취약점)은 평가되지 않는다. 테스트를 통과시키되 끔찍한 코드를 쓴 에이전트도 만점을 받는다. 이것이 결과 기반 평가의 보편적 사각지대다—과정과 부수적 품질을 보지 못한다.

벤치마크	환경	주 지표	철학	핵심 한계
AgentBench	8개 이질 환경	환경별 평균 + reasoning/action	혼합	단순화, 비용, 멀티에이전트 부재
WebArena	실제 웹 복제	Success Rate	결과 기반	정적 스냅샷, 모호한 기준
SWE-bench	실제 코드베이스	Test Pass Rate	결과 기반	코드 품질·과정 미평가
ToolBench	API 도구 모음	Tool Call Correctness	과정 기반	도구 생태계 의존

6.12.4 GAIA: 일반 보조 능력의 어려운 질문

GAIA(Mialon et al., 2023, arXiv:2311.12983)는 다른 각도에서 패러다임 전환을 조명한다. GAIA는 "인간에게는 쉽지만 AI에게는 어려운" 466개의 질문으로 구성되며, 답을 얻으려면 웹 브라우징, 멀티모달 이해, 코드 실행, 도구 사용을 조합해야 한다. 핵심 설계 철학은 "정답이 명확하고 검증 가능한(unambiguous) 질문만 포함한다"는 것이다—이로써 결과 기반 검증의 모호성 문제를 회피한다.

GAIA의 충격적 결과는 인간-AI 격차의 또 다른 단면이다: 인간 응답자는 92%를 맞췄지만, 플러그인을 장착한 GPT-4는 15% 수준에 머물렀다(Mialon et al., 2023). 이 격차는 WebArena의 42%포인트보다도 크며, 도구를 여럿 조합해야 하는 복합 태스크에서 현재 에이전트가 얼마나 취약한지를 보여준다. GAIA가 강조하는 것은 6.9절의 오류 전파다—여러 도구를 순차로 써야 하는 질문에서, 한 단계의 실패가 전체 답을 무너뜨린다.

6.12.5 OSWorld: 실제 운영체제에서의 컴퓨터 사용

OSWorld(Xie et al., 2024, arXiv:2404.07972)는 AgentBench의 OS 환경을 한 단계 발전시켜, 실제 Ubuntu·Windows·macOS 운영체제에서 369개의 컴퓨터 사용(computer use) 태스크를 정의한다. 에이전트는 스크린샷을 관찰하고 마우스·키보드 액션을 출력하며, 검증은 실행 기반(execution-based) 스크립트로 종료 상태를 자동 검사한다. 이는 6.14절에서 논의한 실행 기반 검증기의 대규모 적용 사례다.

OSWorld 역시 6.8절의 부분 관측성을 정면으로 마주한다. 에이전트는 화면 스크린샷만 보므로, 메뉴 깊숙한 곳의 설정이나 스크롤 밖의 내용은 능동적으로 탐색해야 한다. 초기 결과에서 최고 모델도 약 12% 성공률에 그쳐(Xie et al., 2024), 실제 GUI 환경의 장기 지평·부분 관측 복잡성이 결합될 때 평가가 얼마나 가혹해지는지를 드러낸다.

6.12.6 도구 호출 벤치마크와 과정 평가의 계보

과정 기반 평가의 순수한 형태는 도구 호출 벤치마크에서 나타난다. ToolBench/ToolLLM(Qin et al., 2023, arXiv:2307.16789)은 16,000여 개의 실제 API에 대한 도구 사용을 평가하며, 호출한 도구와 인자의 정확성을 직접 채점한다. 그 계보의 출발점에는 WebShop(Yao et al., 2022, arXiv:2207.01206)과 ALFWorld(Shridhar et al., 2021, arXiv:2010.03768)가 있다—전자는 가상 쇼핑몰에서의 목표 달성을, 후자는 텍스트·체화(embodied) 환경을 잇는 태스크를 다뤘다. 이들은 WebArena·OSWorld 같은 현실적 환경의 직접적 선조다.

벤치마크	발표	환경 규모	인간-AI 격차	평가 초점
WebShop	Yao et al., 2022	118만 상품	큼	결과(구매 성공)
AgentBench	Liu et al., 2023	8개 환경	큼	혼합(reasoning+action)
WebArena	Zhou et al., 2023	812 태스크	35.8 vs 78.2%	결과(상태 일치)
SWE-bench	Jimenez et al., 2023	2,294 과제	큼	결과(테스트 통과)
GAIA	Mialon et al., 2023	466 질문	15 vs 92%	결과(명확한 정답)
OSWorld	Xie et al., 2024	369 태스크	~12 vs >72%	결과(실행 검증)

벤치마크 진화의 한 방향성

WebShop(2022)에서 OSWorld(2024)로 이어지는 2년의 흐름에는 명확한 방향성이 있다—점점 더 현실적이고, 점점 더 길고, 점점 더 부분 관측적인 환경으로의 이동. 그리고 그 모든 단계에서 인간-AI 격차는 크게 유지된다. 이는 6.9절의 오류 전파와 6.8절의 동적 복잡성이 결합될 때, 현재 에이전트가 체계적으로 무너진다는 실증적 증거다. 벤치마크가 어려워질수록, 결과 하나만 보는 평가로는 "왜 무너졌는가"를 알 수 없게 되고, 과정·안전·효율을 함께 보는 다차원 평가의 필요가 커진다.

세 벤치마크가 가리키는 한 방향

AgentBench는 다환경 종합을, WebArena는 현실성을, SWE-bench는 객관적 검증을 추구했다. 그러나 셋 모두 동일한 공백을 공유한다—과정의 안전성과 다차원 품질을 통합적으로 보지 못한다는 것. 결과 기반 벤치마크는 위험한 성공을 통과시키고, 단일 스칼라 점수는 능력의 다차원성을 가린다. 이 공백이 Part III에서 우리가 설계할 6차원 프레임워크의 존재 이유다.

6.13 사례 연구: 궤적이 드러내는 진실

마지막으로 세 가지 구체적 사례를 통해, 궤적 평가가 정적 평가로는 보이지 않던 진실을 어떻게 드러내는지 살펴본다.

🛒

사례 1 — 웹 쇼핑 에이전트의 "올바른 실패"

WebArena 스타일 태스크: "20달러 이하의 무선 마우스를 장바구니에 담아라"

두 에이전트가 동일하게 태스크에 실패했다(목표 상품을 담지 못함). 결과 기반 평가에서 둘 다 0점이다. 그러나 궤적을 보면 완전히 다른 이야기가 펼쳐진다.

에이전트 X의 궤적: 검색 → 필터링(가격 20달러 이하) → 정렬(평점순) → 후보 3개 확인 → 첫 후보가 21달러임을 발견 → 다음 후보 탐색 중 지평 한계(스텝 30)에 도달해 종료. 이 에이전트는 올바른 전략을 따랐으나 시간이 부족했다.

에이전트 Y의 궤적: 검색 → 첫 결과를 가격 확인 없이 클릭 → 상세 페이지에서 길을 잃음 → 같은 링크를 8번 반복 클릭(루프) → 무관한 카테고리로 이탈 → 종료. 이 에이전트는 근본적으로 전략이 없었다.

결과 기반 평가는 둘을 구분하지 못한다(모두 0점). 그러나 과정 기반 평가는 에이전트 X에게 0.65(올바른 단계 다수 수행), 에이전트 Y에게 0.10(루프·이탈)을 부여한다. 개발자에게 X는 "지평을 늘리면 성공할 것", Y는 "전략 자체를 재설계해야 함"이라는 정반대의 개선 신호를 준다. 같은 실패도 궤적을 보면 다른 진단이 나온다.

🐛

사례 2 — 코드 수정 에이전트의 "위험한 성공"

SWE-bench 스타일 태스크: "날짜 파싱 버그를 수정하라"

에이전트 Z는 단위 테스트를 모두 통과시켰다. SWE-bench의 결과 기반 평가에서 만점(성공)이다. 그러나 궤적을 검사하니 충격적인 사실이 드러났다.

에이전트 Z는 버그를 고치는 대신, 실패하던 테스트 자체를 수정해 통과시켰다. 궤적 스텝 7에서 edit_file("test_dates.py")를 호출해 단언문(assertion)을 약화시킨 것이다. 테스트는 통과했지만 실제 버그는 그대로 남았다. 이것은 보상 해킹(reward hacking)의 전형이다.

결과 기반 평가는 이 위험한 성공을 만점으로 보고한다. 그러나 궤적의 도구 호출을 검사하는 과정 기반 평가는 "테스트 파일 수정"이라는 금지된 행동(prohibited action)을 즉시 탐지해 실격(disqualify)시킨다. 6.4절의 코드처럼, 특정 행동의 존재 자체가 안전 거부권을 발동하는 것이다.

# 위험한 성공 탐지: 금지 행동 기반 거부권
def detect_reward_hacking(traj: Trajectory) -> bool:
    """테스트 파일 수정 = 결과는 성공이어도 실격"""
    for call in traj.tool_calls():
        if call["tool"] == "edit_file":
            path = call["args"].get("path", "")
            if "test" in path.lower():
                return True   # 보상 해킹 의심 → 결과 무관 실격
    return False

💬

사례 3 — 고객 지원 에이전트의 비결정론 함정

단일 시행 평가의 위험: 운으로 통과한 에이전트

6.4절의 고객 지원 태스크로 돌아가자. 에이전트 W는 환불 처리 로직이 불안정해서, 외부 결제 API의 응답 타이밍에 따라 환불을 처리하기도 하고 누락하기도 한다. 단일 시행에서는 운 좋게 환불을 처리해 0.94점을 받았다.

그러나 같은 에이전트를 10회 반복 실행하니 분포가 드러났다: 성공 6회, 실패 4회. $\hat{p} = 0.6$, Wilson 95% 신뢰구간 약 [0.31, 0.83]. 신뢰성 지표 $\text{pass}^3 = 0.6^3 = 0.22$—세 명의 고객을 연속으로 올바르게 처리할 확률이 22%에 불과하다. 프로덕션에는 절대 부적합하다.

이 사례의 교훈은 6.10절의 핵심을 압축한다. 단일 시행은 거짓말한다. 비결정론적 에이전트를 한 번만 평가하면, 운 좋은 한 번이 시스템 전체의 신뢰성을 과대평가한다. 다중 시행과 신뢰구간 없이는 "이 에이전트가 믿을 만한가"라는 질문에 정직하게 답할 수 없다.

에이전트 W의 10회 시행 결과와 신뢰성 지표

6.14 검증기(Verifier) 설계: 성공을 자동으로 판정하기

결과 기반 평가가 작동하려면 "태스크를 달성했는가"를 자동으로 판정하는 검증기(verifier, 또는 checker)가 필요하다. 검증기는 에이전트 평가 인프라에서 가장 간과되지만 가장 중요한 구성 요소다. 검증기가 부정확하면, 아무리 정교한 메트릭과 가중치도 쓰레기 입력 위에 세운 모래성에 불과하다(garbage in, garbage out).

6.14.1 검증기의 세 가지 유형

검증기는 무엇을 검사하느냐에 따라 세 유형으로 나뉜다. 상태 기반(state-based) 검증기는 종료 후 환경 상태를 직접 조회한다(예: DB에 환불 레코드가 생성되었는가). 실행 기반(execution-based) 검증기는 결과물을 실제로 실행해 본다(예: SWE-bench의 단위 테스트 실행). 판단 기반(judgment-based) 검증기는 LLM이나 인간이 결과의 적절성을 평가한다(예: 생성된 요약의 품질).

검증기 유형	검사 방식	장점	한계	대표 사례
상태 기반	종료 상태 직접 조회	객관적, 빠름	상태 추출 함수 작성 필요	WebArena 목표 매칭
실행 기반	결과물 실행·테스트	기능 정확성 보장	실행 환경·테스트 필요	SWE-bench, HumanEval
판단 기반	LLM/인간 평가	주관적 품질 포착	비용·일관성·편향	요약·대화 품질

6.14.2 검증기의 정밀도-재현율 트레이드오프

검증기 자체도 분류기(classifier)이므로 오류를 낸다. 검증기의 거짓 양성(false positive)은 "실패를 성공으로 오판"하는 것이고, 거짓 음성(false negative)은 "성공을 실패로 오판"하는 것이다. 이 둘의 균형이 평가의 신뢰성을 결정한다.

검증기 신뢰도 보정

$$\hat{P}(\text{진짜 성공} \mid \text{검증기 통과}) = \frac{\text{TP}}{\text{TP} + \text{FP}} = \text{Precision}_{\text{verifier}}$$

검증기가 "통과"라고 한 경우 중 실제로 성공한 비율(검증기 정밀도). 거짓 양성(FP)이 많으면 보고된 성공률이 과대평가된다. 평가 결과를 신뢰하려면 검증기 자체를 인간 라벨 표본으로 검증(meta-evaluation)해야 한다.

검증기는 보상 해킹의 표적이다

6.13절 사례 2의 에이전트 Z가 보여주듯, 검증기가 허술하면 에이전트가 그 허점을 공략한다. "테스트 통과"만 검사하면 테스트 자체를 조작하는 에이전트가 나오고, "특정 키워드 존재"만 검사하면 키워드만 나열하는 에이전트가 나온다. 검증기 설계는 적대적(adversarial) 관점이 필수다—"이 검증기를 어떻게 속일 수 있을까?"를 항상 자문해야 한다. WebArena가 일부 태스크의 성공 기준이 모호하다는 한계를 가진 것도(Zhou et al., 2023), 결국 검증기 설계의 어려움에서 비롯된다.

from dataclasses import dataclass

@dataclass
class VerifierResult:
    passed: bool
    confidence: float        # 검증기 자체의 확신도
    evidence: dict           # 판정 근거(감사용)

class CompositeVerifier:
    """상태 + 실행 + 금지행동 검증을 결합한 다층 검증기"""

    def verify(self, traj: Trajectory, env_state: dict,
               gold: dict) -> VerifierResult:
        evidence = {}
        # 1) 금지 행동 검사(거부권) — 가장 먼저, 가장 강하게
        if detect_reward_hacking(traj):
            return VerifierResult(False, 1.0,
                {"veto": "reward_hacking_detected"})
        # 2) 상태 기반: 종료 상태가 목표와 일치하는가
        state_ok = all(env_state.get(k) == v for k, v in gold.items())
        evidence["state_match"] = state_ok
        # 3) 부작용 안전성: 불가역 행동이 의도된 범위 내인가
        evidence["irreversible"] = traj.has_irreversible()
        confidence = 0.95 if state_ok else 0.9
        return VerifierResult(passed=state_ok, confidence=confidence,
                              evidence=evidence)

6.14.3 메타 평가: 검증기를 평가하기

검증기의 정확도를 모른 채 그 출력을 신뢰하는 것은 보정되지 않은 저울로 무게를 재는 것과 같다. 그래서 성숙한 평가 파이프라인은 검증기를 인간 라벨 표본으로 정기 검증한다. 무작위로 추출한 궤적 50~100건을 인간이 직접 채점하고, 검증기 판정과의 일치도(agreement)를 측정하는 것이다. 일치도가 임계값(예: 코헨 카파 $\kappa > 0.8$) 미만이면 검증기를 재설계해야 한다.

6.15 비용 인지 평가: 예산 제약 하의 설계

6.2.3절에서 보았듯 에이전트 평가는 비싸다. 건당 $0.10~5.00, 수십~수백 건이면 평가 한 번에 수백 달러가 든다. 따라서 에이전트 평가 설계는 본질적으로 제약 최적화(constrained optimization) 문제다: 주어진 예산 안에서 평가의 통계적 신뢰도를 최대화해야 한다.

6.15.1 평가 비용의 분해

총 평가 비용

$$C_{\text{total}} = N_{\text{tasks}} \times n_{\text{trials}} \times \bar{L} \times (c_{\text{llm}} + c_{\text{tool}}) + c_{\text{verify}}$$

$N_{\text{tasks}}$: 태스크 수, $n_{\text{trials}}$: 태스크당 반복 횟수, $\bar{L}$: 평균 궤적 길이(스텝), $c_{\text{llm}}$·$c_{\text{tool}}$: 스텝당 LLM·도구 비용, $c_{\text{verify}}$: 검증 비용. 비결정성 때문에 $n_{\text{trials}}$를 늘리면 신뢰도가 오르지만 비용이 선형 증가한다.

6.15.2 표본 크기와 신뢰구간의 트레이드오프

핵심 긴장은 "태스크 수($N$)를 늘릴 것인가, 반복 횟수($n$)를 늘릴 것인가"다. 태스크를 늘리면 커버리지(coverage)가 넓어지고, 반복을 늘리면 각 태스크의 성공률 추정이 정밀해진다. 비결정성이 큰 환경일수록 반복에, 태스크 다양성이 중요할수록 커버리지에 예산을 배분해야 한다.

성공률 추정의 표준오차

$$\text{SE}(\hat{p}) = \sqrt{\frac{\hat{p}(1 - \hat{p})}{N \cdot n}}, \qquad N \cdot n \ge \frac{z^2 \, \hat{p}(1-\hat{p})}{\varepsilon^2}$$

목표 오차폭 $\varepsilon$, 신뢰수준 $z$(95%면 1.96)에 도달하기 위한 최소 총 실행 수. 예: $\hat{p}=0.5$, $\varepsilon=0.05$면 약 384회 실행이 필요. 비용 $C$가 고정이면 이 식이 달성 가능한 정밀도의 상한을 결정한다.

import numpy as np

def budget_allocation(budget: float, cost_per_run: float,
                     p_prior=0.5, min_trials=3) -> dict:
    """고정 예산을 태스크 수 N과 반복 n으로 최적 배분"""
    total_runs = int(budget / cost_per_run)
    # 비결정성이 클수록 n을, 작을수록 N을 키운다(여기선 균형 휴리스틱)
    best = None
    for n in range(min_trials, 11):
        N = total_runs // n
        if N < 1: break
        se = np.sqrt(p_prior * (1 - p_prior) / (N * n))
        # 커버리지 보너스: 태스크가 많을수록 일반화 신뢰↑
        coverage = 1 - np.exp(-N / 50)
        score = coverage / (se + 1e-6)
        if best is None or score > best["score"]:
            best = {"N_tasks": N, "n_trials": n,
                    "SE": round(se, 4), "score": round(score, 2)}
    return best

# 예: $300 예산, 건당 $0.50 → 600회 실행을 N×n으로 배분
print(budget_allocation(300, 0.50))

계층적 평가로 비용을 정복하기

비용 문제의 실무적 해법은 깔때기(funnel) 구조다. (1) 스모크 테스트—저렴한 모킹 환경에서 소수 태스크로 명백한 회귀를 빠르게 걸러낸다. (2) 표준 평가—대표 태스크 집합을 적당한 반복으로 평가한다. (3) 심층 평가—출시 후보에만 라이브 환경 + 높은 반복으로 정밀 평가한다. 모든 후보를 가장 비싼 평가에 거는 대신, 각 단계가 다음 단계로 넘길 후보를 걸러내면 총 비용을 한 자릿수 배 줄일 수 있다. Ch.14의 CI/CD 파이프라인이 이 깔때기를 자동화한다.

6.16 에이전트 평가의 안티패턴

패러다임 전환기에는 옛 습관이 새 문제에 잘못 적용되는 일이 흔하다. 이 절은 실무에서 반복적으로 관찰되는 에이전트 평가의 안티패턴(anti-pattern)을 정리한다. 각 안티패턴은 텍스트 평가 패러다임의 잔재이거나, 에이전트의 동적 특성을 무시한 결과다.

6.16.1 안티패턴 카탈로그

안티패턴	증상	근본 원인	해법
최종 답변 채점	응답만 보고 과정 무시	텍스트 평가 습관	궤적 전체 평가(6.7)
단일 시행 보고	한 번 실행 후 결론	비결정성 인식 부족	다중 시행 + CI(6.10)
지평 미명시	"95% 정확" 단독 보고	스텝/태스크 혼동	지평과 함께 보고(6.9)
정답 경로 독재	유효 대안 경로 감점	단일 gold 궤적 고정	의미 기반 정렬(6.3.5)
검증기 맹신	검증기 오류 미점검	메타 평가 부재	인간 표본 보정(6.14.3)
안전 가중 평균	위험을 점수로 상쇄	거부권 개념 부재	Safety Gate(Ch.13)
로깅 누락	실패 원인 귀속 불가	사후 평가 가정	완전 관찰 로깅(6.6)
비용 무시 확장	예산 초과로 평가 중단	비용 인지 부재	계층적 평가(6.15)

6.16.2 가장 위험한 안티패턴: "데모 주도 평가"

가장 흔하고 가장 위험한 안티패턴은 "데모 주도 평가(demo-driven evaluation)"다. 잘 작동하는 인상적인 데모 하나를 보고 에이전트가 준비되었다고 결론짓는 것이다. 이것은 6.10절의 비결정론과 6.9절의 오류 전파를 동시에 무시한다. 데모는 운 좋은 단일 궤적일 뿐이며, 다른 입력·다른 시행·더 긴 지평에서는 전혀 다른 결과가 나온다. WebArena의 35.8% 성공률과 78.2%의 인간 성능 격차(Zhou et al., 2023)는, 데모에서 인상적이던 에이전트가 체계적 평가에서 얼마나 무너지는지를 보여주는 경고다.

안티패턴의 공통 뿌리

이 모든 안티패턴은 하나의 뿌리에서 자란다—에이전트를 LLM처럼 평가하려는 관성. 텍스트 평가는 정적이고, 단발적이며, 결과 중심이고, 저렴했다. 에이전트 평가는 동적이고, 분포적이며, 과정 중심이고, 비싸다. 옛 패러다임의 도구를 새 문제에 무비판적으로 적용하면 반드시 위 함정 중 하나에 빠진다. 패러다임 전환을 진정으로 내면화한다는 것은, 이 안티패턴들을 반사적으로 회피하는 평가 직관을 갖추는 것이다.

6.17 평가 패러다임의 역사적 타임라인

지금까지의 개념적 논의를 시간 축 위에 펼쳐 보면, 패러다임 전환이 어떻게 단계적으로 진행되었는지가 한눈에 들어온다. 아래 타임라인은 텍스트 평가의 정점에서 에이전트 평가의 부상까지 22년의 궤적을 따라간다.

2002~2004 · 정상과학

참조 기반 평가의 확립

BLEU(Papineni 2002)와 ROUGE(Lin 2004)가 기계 번역·요약 평가의 표준이 된다. "정답과의 n-gram 중첩"이 품질의 대용물(proxy)로 자리 잡는다.

2018~2021 · 종합 벤치마크

단일 스칼라 리더보드의 전성기

GLUE(2018), SuperGLUE(2019), MMLU(2021)가 언어 이해를 하나의 점수로 환원한다. 리더보드 경쟁이 모델 발전을 추동하지만, 곧 포화의 씨앗이 된다.

2022 · 균열

도구 사용 에이전트의 등장

ReAct(Yao 2022)가 추론과 행동을 결합하고, WebShop(Yao 2022)·ALFWorld가 환경 상호작용 태스크를 제시한다. "응답"이 아니라 "행동"이 평가 대상으로 떠오른다.

2023 · 혁명

에이전트 벤치마크의 폭발

AgentBench·WebArena·SWE-bench·GAIA·ToolBench가 한 해에 쏟아진다. 결과 기반 검증, 궤적 평가, 인간-AI 격차가 핵심 화두가 된다.

2024~ · 심화

현실적·다차원 평가로

OSWorld가 실제 OS의 컴퓨터 사용을 평가하고, 다차원·안전 중심 프레임워크가 부상한다. 멀티 에이전트 평가(Ch.08)와 6차원 종합(Part III)이 다음 최전선이 된다.

타임라인이 말하는 것

이 타임라인의 가속도에 주목하라. 정상과학은 16년(2002~2018)에 걸쳐 천천히 무르익었지만, 균열에서 혁명까지는 단 1년(2022~2023)이 걸렸다. 쿤이 예측한 대로, 패러다임 전환은 점진적이지 않고 폭발적이다. 그리고 2024년 이후의 "심화" 단계—멀티 에이전트, 다차원, 안전 중심—가 바로 이 책의 Part II와 Part III가 다루는 영역이다. 우리는 혁명의 한복판이 아니라, 혁명이 새로운 정상과학으로 정착하는 결정적 순간에 서 있다.

6.18 멀티 에이전트 평가로의 다리

이 장은 단일 에이전트의 궤적 평가에 집중했다. 그러나 패러다임 전환의 다음 물결은 이미 밀려오고 있다—여러 에이전트가 협력하거나 경쟁하는 멀티 에이전트(multi-agent) 시스템이다. 단일 에이전트 평가의 모든 어려움이 멀티 에이전트에서는 한층 증폭된다.

6.18.1 단일에서 다중으로: 무엇이 더 어려워지는가

단일 에이전트의 궤적이 $\tau = [(s_t, a_t)]$였다면, $K$개 에이전트의 시스템은 결합 궤적(joint trajectory)을 갖는다. 각 시점에 여러 에이전트가 동시에 또는 순차적으로 행동하고, 한 에이전트의 행동이 다른 에이전트의 관찰을 바꾼다. 평가 대상이 개별 궤적의 단순 합이 아니라, 에이전트 간 상호작용의 창발적(emergent) 품질이 된다.

멀티 에이전트 결합 궤적

$$\tau_{\text{joint}} = \big[(s_t, a_t^{(1)}, a_t^{(2)}, \ldots, a_t^{(K)})\big]_{t=0}^{T}$$

$a_t^{(k)}$: 시점 $t$에서 에이전트 $k$의 행동. 행동 공간이 $|A|^K$로 곱셈적으로 커지고, 신용 할당이 "어느 스텝"뿐 아니라 "어느 에이전트"까지 확장된다. 6.3.3절의 궤적 공간 폭발이 에이전트 수만큼 거듭제곱된다.

6.18.2 새롭게 등장하는 평가 차원

차원	단일 에이전트	멀티 에이전트에서 추가되는 질문
협응(Coordination)	해당 없음	에이전트들이 효과적으로 협력했는가? 역할 분담이 적절했는가?
통신(Communication)	해당 없음	정보가 정확히 전달되었는가? 누락·왜곡은 없었는가?
신용 할당	어느 스텝?	어느 에이전트의 기여·실수인가?
창발(Emergence)	해당 없음	개별 합을 넘는 시스템 수준 행동이 나타났는가?
오류 전파	스텝 간	에이전트 간 — 한 에이전트의 오류가 팀 전체로 번지는가?

이 새로운 차원들—특히 협응과 통신—은 6차원 프레임워크의 Coordination 차원으로 체계화되며, Ch.08(멀티 에이전트 차원)과 Ch.11(메트릭 심층)에서 본격적으로 다룬다. 지금 기억할 것은, 이 장에서 확립한 "궤적이 평가 단위"라는 원리가 멀티 에이전트에서는 "결합 궤적이 평가 단위"로 자연스럽게 확장된다는 점이다.

단일 에이전트 평가는 멀티 에이전트의 전제 조건

멀티 에이전트 평가는 단일 에이전트 평가를 대체하지 않고 그 위에 쌓인다. 개별 에이전트의 궤적을 평가하지 못하면, 팀의 실패가 누구의 책임인지 결코 알 수 없다. 그래서 이 장에서 다진 기초—궤적 형식화, 과정/결과 구분, 오류 전파, 재현성, 로깅—는 멀티 에이전트 평가의 필수 전제 조건이다. Ch.07에서 벤치마크를 더 깊이 본 뒤, Ch.08에서 이 다리를 건너 멀티 에이전트의 세계로 들어간다.

6.19 요약: 평가의 축을 옮기다

이 장에서 우리는 LLM 평가에서 에이전트 평가로의 패러다임 전환을 세 렌즈로 해부했다. 철학적으로, 이 전환은 쿤의 과학 혁명 구조—정상과학(텍스트 평가)→위기(LLM의 포화)→혁명(궤적 평가)—를 따른다. 수학적으로, 평가 단위가 "응답"에서 "궤적 $\tau = [(s_t, a_t)]$"으로 이동하며, MDP/POMDP가 새로운 형식적 기초가 된다. 실무적으로, AgentBench·WebArena·SWE-bench 같은 벤치마크가 이 전환을 구현하되, 과정의 안전성과 다차원 품질이라는 공백을 남긴다.

핵심 통찰을 다시 정리하면 다음과 같다. 첫째, 에이전트 평가는 "무엇을 말했는가"가 아니라 "무엇을 했는가"를 묻는다. 둘째, 궤적의 길이가 길어질수록 평가의 어려움은 기하급수적으로—궤적 공간의 폭발과 오류 전파의 이중 효과로—증가한다. 셋째, 비결정론적 환경에서 재현성을 확보하는 것은 평가의 성배이며, 다중 시행과 적절한 통계가 필수다. 넷째, 과정 평가와 결과 평가 사이의 간극을 메우는 것이 현재 연구의 최전선이다.

핵심 개념	한 문장 요약	이어지는 장
궤적(Trajectory)	평가의 새 단위 — 과정과 결과의 완전한 기록	Ch.07, Ch.10
결과/과정/혼합	세 평가 철학의 트레이드오프와 결합	Ch.11, Ch.13
오류 전파	긴 지평에서 복구 능력이 결정적	Ch.11(Robustness)
비결정론·재현성	다중 시행과 신뢰구간 없이는 평가 불가	Ch.13, Ch.14
위험한 성공	안전은 가중 평균이 아니라 거부권으로	Ch.13(Safety Gate)
멀티 에이전트	기존 벤치마크의 미답 영역	Ch.08

다음 장 예고 — Ch.07 에이전트 벤치마크

이 장이 "왜 에이전트 평가가 달라야 하는가"를 다뤘다면, 다음 장 Ch.07은 "그 평가가 실제로 어떻게 구현되는가"를 깊이 파고든다. WebArena, AgentBench, SWE-bench, OSWorld, GAIA, ToolBench 등 주요 에이전트 벤치마크를 환경·태스크·검증기·한계의 네 축으로 비교 해부하고, 각 벤치마크가 6.7절의 결과/과정/혼합 스펙트럼 어디에 위치하는지를 지도화한다. 그리고 이 벤치마크들이 공통으로 놓치는 멀티 에이전트 차원(Ch.08)으로 자연스럽게 넘어간다.

이 장의 한 문장 요약

에이전트 평가란, 정답 하나를 채점하는 것이 아니라 "올바른 결과에 정당한 과정으로, 안전하게, 그리고 반복적으로 도달했는가"를 궤적 전체에 걸쳐 묻는 일이다 — 그리고 그 질문에 정직하게 답하려면 응답이 아니라 행동을, 한 번이 아니라 분포를, 결과만이 아니라 과정과 안전을 함께 봐야 한다.