01. Trajectory vs Outcome 평가

1. 정의

에이전트 평가에서 가장 먼저 마주치는 갈림길이다.

Outcome (결과) 평가: 에이전트가 최종적으로 무엇을 산출했는가만 본다. 입력→출력의 함수로 취급.
Trajectory (경로) 평가: 에이전트가 어떤 순서로 어떻게 그 결과에 도달했는가를 본다. 추론 단계, 툴 호출, 중간 결정까지 포함.

비유하자면 outcome은 시험 답안지 채점, trajectory는 풀이과정 채점이다. 둘 다 가능하고 둘 다 의미가 다르다.

2. 핵심 메커니즘

2.1 Outcome 평가가 측정하는 것

가장 단순한 형태: f(input) == expected_output ? (exact match) 또는 유사도(BLEU, ROUGE, embedding cosine), 또는 LLM-as-judge로 자유형 답을 채점.

에이전트 도메인에서는 흔히 세계 상태(world state) 의 변화를 본다. 예: τ-bench는 대화 종료 시점의 DB 상태를 정답 상태와 비교. “고객이 환불받았어야 하는데 DB에 환불 레코드가 있나?” — 대화 내용은 안 본다.

2.2 Trajectory 평가가 측정하는 것

에이전트의 한 실행은 보통 다음과 같은 시퀀스다.

사용자 발화
→ 에이전트 추론 (think)
→ 툴 호출 1 (action a₁)
→ 툴 결과 (observation o₁)
→ 에이전트 추론
→ 툴 호출 2 (a₂)
→ ...
→ 최종 응답

이 (a₁, o₁, a₂, o₂, …, response) 시퀀스 전체가 trajectory다. Trajectory 평가는 이 시퀀스의 각 지점을 채점한다.

대표적인 trajectory 메트릭(Vertex AI 명명법):

trajectory_exact_match: 에이전트가 밟은 step 시퀀스가 정답 시퀀스와 완전히 동일한가. 가장 엄격.
trajectory_precision: 에이전트가 밟은 step 중 정답 시퀀스에 포함된 것의 비율. “쓸데없는 짓을 안 했나”
trajectory_recall: 정답 시퀀스의 step 중 에이전트가 실제로 밟은 것의 비율. “필요한 일을 다 했나”
trajectory_in_order_match: 순서가 맞는지 보지만 중간에 다른 step이 끼어도 OK

2.3 정답 trajectory가 없을 때

대부분의 현실 태스크는 “정답 풀이과정”이 유일하지 않다. 이때 두 가지 우회로:

속성 기반 채점: “툴 X를 적어도 한 번 호출했는가?”, “DB 쓰기 전에 검증 함수를 거쳤는가?” 같은 속성으로 분해. 정답 시퀀스 대신 정답 속성 집합.
LLM-as-judge로 trajectory 채점: 판정 모델에게 “이 풀이과정은 합리적인가?”를 물음. 5장(τ-bench)·2장(LLM-as-Judge) 참고.

3. 강점과 약점

축	Outcome	Trajectory
비용	저 (한 번만 비교)	고 (각 step마다)
디버깅 가치	낮음 — 어디서 틀렸는지 모름	높음 — 실패 지점 특정 가능
Reward Hacking 취약성	중 — 결과만 맞히면 OK라 우회 가능	낮음 — 과정도 봐서 우회 어려움
정답 라벨 비용	낮음 (최종 결과만 라벨)	매우 높음 (각 step 라벨링)
자유도 허용	높음 — 어떤 길이든 OK	낮음 — 정답 경로에 가까워야

Outcome의 함정 — Reward Hacking: “환불 처리”를 측정하기 위해 DB에 환불 레코드 1건이 있나로만 본다면, 에이전트가 그냥 빈 환불 레코드를 하나 박아넣고 끝낼 수 있다. 결과는 맞는데 의도는 어긋남. 13장(벤치마크 함정)에서 자세히.

Trajectory의 함정 — 과적합: 정답 trajectory를 너무 엄격히 잡으면, 더 짧고 좋은 풀이를 발견한 에이전트가 틀린 것으로 채점된다. 사실 그게 더 잘한 건데. 그래서 trajectory_recall 만 쓰거나, “필수 step의 부분집합”으로 라벨링하는 절충안이 흔하다.

4. 대안과의 비교

Outcome ⊂ Trajectory?

오해하기 쉬운데, 둘은 다른 질문을 푸는 도구다.

“에이전트가 비즈니스 목표를 달성하는가?” → Outcome
“에이전트의 행동이 책임 있는가/일관된가/안전한가?” → Trajectory

엔터프라이즈에서 trajectory 평가가 갑자기 중요해진 이유: 컴플라이언스. “고객 데이터를 조회하기 전에 권한 체크 step을 거쳤는가” 같은 건 outcome에는 안 보인다. 결과(고객에게 답변)는 동일해도, 권한 체크 없이 답한 에이전트는 법적 문제다.

Tiered 권장안 (Galileo)

“Outcome 메트릭을 상시 모니터링·1차 검증에, trajectory 평가를 실패 사례 디버깅·고위험 결정 검증에.”

→ 100% 트래픽에 outcome, 1–5% 샘플 또는 알람 트리거 케이스에 trajectory.

5. 우리 실험에의 적용

본 실험 설계 §6의 7개 지표 중 개입 횟수가 사실상 거친 trajectory 메트릭이다(“에이전트가 혼자 못 해서 사용자가 끼어든 횟수”). 하지만 어디서 끼어들었는지, 왜 끼어들었는지는 안 잡힌다.

이미 우리는 hook으로 PreToolUse/PostToolUse를 logs/history-${EXPERIMENT_TOOL}.jsonl 에 기록하므로, trajectory 데이터는 공짜로 쌓이고 있다. 이걸 분석 스크립트 한 장으로 다음을 뽑을 수 있다:

T1(공지 작성)에 사용된 툴 목록 (Discord MCP, Slack MCP, Gmail … 또는 그냥 Bash echo 등)
툴 호출 순서 (Hermes는 곧장 Discord MCP, OpenClaw는 먼저 skill 검색 후 Discord skill?)
평균 툴 호출 횟수 (적을수록 효율적이라고 단정 못 함 — 4장에서 다룸)

H3(“OpenClaw 통합 강점”) 검증의 핵심이 trajectory다. OpenClaw가 Discord/Slack/Gmail을 어떤 순서로 어떤 인자로 호출하는지가 통합 강점의 실체다. Outcome(“공지가 발송되었나”) 만 보면 두 도구 차이가 안 보인다 — 둘 다 Y 일 수 있으니까.

적용 권장 (이번 시리즈 후에 의사결정):

trajectory 분석 스크립트 추가 — scripts/parse-trajectory.py 같은 한 장.
§6에 두 메트릭 추가:
- tool_calls_count (per task) — outcome 보조
- unique_tools_used (per task) — 통합 폭 측정
실패한 태스크는 trajectory 전체를 정성 검토 (5건/주 정도).

6. 더 읽을거리

Vertex AI Agent Eval — Google Cloud 공식 문서 — trajectory_exact_match·precision·recall 메트릭 명명법의 1차 출처
Galileo, “Agent Evaluation Framework 2026: Metrics, Rubrics & Benchmarks” — outcome 상시 + trajectory 선택 적용의 tiered 권장안 출처
LangSmith Evaluation 공식 페이지 — full trajectory 캡처와 step 단위 평가자 작성 가이드

다음 장 미리보기

LLM에게 “이 trajectory가 합리적인가?”를 물어볼 수 있다고 했다. 그런데 LLM 판정 모델은 얼마나 믿을 수 있나? Position bias, length bias, agreeableness bias, 50%+ 오차, 인간 일치율 64–68%… 이 모든 걸 알고도 우리는 LLM-as-judge를 어떤 조건에서 도입할 수 있을까. 02장.

이 장에서 확실히 알아야 하는 것

Outcome / Trajectory의 정의를 한 줄로 말할 수 있다.
trajectory_precision / trajectory_recall 의 차이를 예시로 설명할 수 있다.
정답 trajectory가 없을 때의 두 가지 우회로(속성 기반 / LLM judge)를 알고 있다.
Reward Hacking이 outcome 평가의 어떤 약점인지 1문장으로 말할 수 있다.
본 실험의 hook 로그가 사실상 무료 trajectory 데이터라는 것을 인지하고 있다.