AI 에이전트 평가, 결과만 보면 놓치는 이유: Trajectory Evaluation의 중요성

AI 에이전트는 왜 기존 방식으로 평가할 수 없을까?

생성형 AI가 발전하면서 프롬프트 하나에 대한 입력과 출력만 확인하는 방식은 더 이상 충분하지 않습니다. 특히 Autonomous AI Agent(자율형 AI 에이전트) 는 하나의 요청을 수행하는 과정에서 다양한 내부 작업을 수행하기 때문입니다.

하나의 질문을 처리하기 위해 AI 에이전트는 내부적으로 추론을 수행하고, 여러 API를 호출하며, 필요한 정보를 검색하고, 대화 상태를 갱신하는 등 수많은 단계를 거칩니다. 이러한 과정은 사용자에게는 보이지 않지만 최종 결과의 품질과 신뢰성을 결정하는 핵심 요소입니다.

이번 글에서는 AI 에이전트를 평가할 때 왜 최종 응답(Final Response) 만 확인해서는 안 되는지와 이를 해결하기 위한 Trajectory Evaluation 개념을 살펴보겠습니다.

반응형

---

최종 결과만 평가하는 방식의 한계

기존 소프트웨어 테스트는 대부분 결정론적(Deterministic) 입니다. 동일한 입력을 제공하면 항상 동일한 결과가 나오며, 테스트 역시 입력과 출력만 확인해도 충분한 경우가 많습니다.

초기의 생성형 AI 역시 비슷한 접근이 가능했습니다. 하나의 프롬프트를 입력하고 원하는 답변이 생성되는지만 확인하면 어느 정도 품질을 평가할 수 있었습니다.

하지만 자율형 AI 에이전트는 상황이 다릅니다.

사용자의 하나의 요청이 다음과 같은 여러 작업을 포함할 수 있습니다.

• 여러 단계의 추론(Reasoning)
• 외부 API 호출
• 검색(Retrieval)
• 도구(Tool) 사용
• 멀티턴 대화 상태 관리(State Mutation)

즉, 하나의 프롬프트가 내부적으로 수십 개의 실행 단계로 이어질 수 있습니다.

이러한 환경에서는 최종 답변이 맞다고 해서 실행 과정도 올바른 것은 아닙니다.

---

AI 에이전트 평가에서 가장 큰 함정

AI 에이전트를 개발할 때 가장 위험한 상황은 다음과 같습니다.

최종 답변은 정답이지만 실행 과정에서는 여러 문제가 발생하는 경우입니다.

예를 들어 다음과 같은 상황을 생각해 볼 수 있습니다.

• 실제로는 도구를 사용하지 않았는데 사용했다고 응답하는 경우
• 필요한 API 호출이 실패했지만 이를 숨기고 답변을 생성하는 경우
• 잘못된 검색 결과를 기반으로 우연히 맞는 답변을 생성하는 경우

겉으로 보기에는 문제가 없어 보일 수 있지만, 실제 서비스 환경에서는 이러한 오류가 반복적으로 발생하면 신뢰성이 크게 떨어질 수 있습니다.

따라서 AI 에이전트는 결과뿐 아니라 실행 과정 전체를 함께 평가해야 합니다.

---

Trajectory Evaluation이란?

Trajectory Evaluation은 AI 에이전트의 최종 결과만이 아니라 실행 과정 전체(Trajectory) 를 평가하는 방식입니다.

즉,

• 어떤 도구를 선택했는지
• 어떤 API를 호출했는지
• 호출 결과를 어떻게 처리했는지
• 중간 추론 과정에서 문제가 없었는지

등을 종합적으로 평가합니다.

이를 통해 최종 응답만으로는 발견하기 어려운 오류를 확인할 수 있습니다.

Trajectory Evaluation은 크게 두 가지 관점에서 평가가 이루어집니다.

---

1. Agent Task Success: 에이전트가 목표를 제대로 수행했는가

첫 번째 평가는 행동(Behavior) 과 목표 달성 여부(Goal Alignment) 입니다.

Hallucination

에이전트는 실제 수행한 작업만을 기반으로 답변해야 합니다.

다음과 같은 경우는 모두 문제가 됩니다.

• 사용할 수 있는 도구가 있는데 없다고 말하는 경우
• 수행하지 않은 API 호출을 했다고 설명하는 경우
• 실행하지 않은 작업을 완료했다고 응답하는 경우

이러한 현상은 일반적인 환각(Hallucination)의 한 형태입니다.

---

Instruction Following

에이전트는 주어진 지침을 정확하게 따라야 합니다.

대표적인 실패 사례는 다음과 같습니다.

• 금지된 작업을 수행하는 경우
• 필요하지 않은 허가를 반복적으로 요청하는 경우
• 작업을 끝까지 수행하지 않고 중간에서 종료하는 경우

즉, 사용자의 요구사항을 얼마나 정확하게 수행했는지를 평가합니다.

---

Tool Output Handling

도구를 호출하는 것만으로는 충분하지 않습니다.

API가 반환한 결과를 정확하게 해석하고 활용해야 합니다.

예를 들어,

• 정상적인 응답을 오류로 처리하거나
• 필요한 데이터를 누락하거나
• 반환값을 잘못 파싱하는 경우

에는 최종 결과 역시 신뢰하기 어렵습니다.

---

2. Tool Use Quality: 도구를 얼마나 정확하게 사용했는가

두 번째 평가는 도구 사용 자체의 품질 입니다.

AI 에이전트는 다양한 Tool을 호출하기 때문에 도구 사용 정확성이 매우 중요합니다.

---

Parameter Errors

가장 흔한 오류는 잘못된 파라미터 전달입니다.

예를 들면 다음과 같습니다.

• 숫자 50 대신 문자열 "50" 전달
• 매개변수 순서 변경
• 서로 다른 필드 값을 잘못 매핑

이러한 작은 실수도 API 실패의 원인이 됩니다.

---

Selection & Syntax

적절한 도구를 선택했는지도 중요한 평가 대상입니다.

예를 들어,

• 검색 도구를 사용해야 하는데 계산기를 호출하거나
• JSON 형식을 잘못 작성하거나
• 필수 필드를 누락하는 경우

에는 정상적인 실행이 어렵습니다.

---

Tool Hallucination

실제로 존재하지 않는 도구를 호출하는 것도 대표적인 문제입니다.

예를 들어,

• 존재하지 않는 함수 이름 사용
• 정의되지 않은 파라미터 생성
• 지원하지 않는 API를 호출하는 경우

이러한 오류는 에이전트가 실행 자체를 실패하게 만드는 원인이 됩니다.

---

Trajectory Evaluation이 필요한 이유

최종 응답만 확인하는 평가는 다음과 같은 문제를 발견하기 어렵습니다.

• 실행 과정에서 발생한 오류
• 잘못된 Tool 선택
• API 호출 실패
• 추론 과정의 비효율성
• 잘못된 상태(State) 관리

반면 Trajectory Evaluation은 실행 로그 전체를 분석하기 때문에 이러한 문제를 조기에 발견하고 개선할 수 있습니다.

특히 복잡한 AI 에이전트를 운영할수록 실행 과정에 대한 평가는 필수적인 요소가 됩니다.

---

간단한 예시

동일한 질문에 대해 두 개의 AI 에이전트가 다음과 같이 응답했다고 가정해 보겠습니다.

에이전트 A

• 올바른 Tool 선택
• 정상적인 API 호출
• 응답 파싱 성공
• 최종 답변 생성

에이전트 B

• 잘못된 Tool 선택
• API 호출 실패
• 실패를 숨긴 채 추론
• 우연히 동일한 최종 답변 생성

최종 응답만 비교하면 두 에이전트 모두 성공한 것처럼 보입니다.

하지만 Trajectory Evaluation을 적용하면 에이전트 B는 실행 과정에서 여러 문제가 있었음을 확인할 수 있습니다.

이처럼 실행 과정까지 평가해야 AI 에이전트의 실제 품질을 정확하게 측정할 수 있습니다.

---

728x90

AI 에이전트는 단순히 하나의 답변을 생성하는 시스템이 아니라, 여러 단계의 추론과 도구 활용을 통해 문제를 해결하는 실행 시스템입니다.

따라서 최종 결과만 확인하는 평가는 에이전트의 실제 성능과 안정성을 충분히 반영하지 못합니다.

Trajectory Evaluation은 실행 과정 전체를 평가하여 행동의 적절성, 목표 달성 여부, 도구 사용 품질까지 종합적으로 검증하는 방법입니다.

앞으로 AI 에이전트가 더욱 복잡한 업무를 수행하게 될수록 "무엇을 답했는가"보다 "어떻게 답에 도달했는가"를 평가하는 방식 이 더욱 중요해질 것입니다.

다음 단계에서는 이러한 Trajectory Evaluation을 자동화하는 5단계 평가 플라이휠(5-stage Eval Flywheel) 과 Evolutionary Prompt Engineering 을 활용해 AI 에이전트를 지속적으로 개선하는 방법을 살펴보겠습니다.

300x250