The agent evaluation revolution - Google Cloud Tech

How to evaluate agents in practice - Google Cloud Tech

구글 클라우드 테크의 위 영상을 참고하여 정리한 게시글이다.

AI 에이전트의 평가는 왜 다른가?

AI 에이전트를 구축한 뒤 몇 개의 프롬프트에 응답을 잘 하는 것 만으로는 부족하다.
사용자가 복잡한 현실 문제, 여러 단계가 얽힌 요청에 제대로 응답하는지 알기 위해서는 단순한 Pass/Fail의 전통적인 테스트 방식은 불가능하다.

확률론과 결정론

구분	전통 소프트웨어	AI 에이전트
동작 방식	결정론적 (같은 입력 → 같은 출력)	확률론적·자율적
테스트 방식	Unit/Integration test로 충분	실행마다 경로가 달라질 수 있음
실패 유형	명확한 pass/fail	잘못된 도구 선택, 컨텍스트 유실, 타임아웃 등 다양

전통적인 소프트웨어는 결정론적이다. 같은 인풋에 같은 응답이 나온다. 많는 경우 유닛 테스트만으로 충분하다.

하지만 AI 에이전트는 이보다 자율적이고 확률론적이다. 같은 문제를 유효하게 해결하기 위해 다양한 방식을 선택할 수 있다. 그러면서 문제는 해결했지만 과정 중에 엉뚱한 도구들을 호출하거나, 가짜 응답을 생성하는 예상하지 못한 방식으로 문제를 달성할 수 있다. 최종 답변만을 확인하는 것 만으로는 이러한 과정을 온전히 평가할 수 없다.

에이전트 평가의 의미

AI 에이전트는 전체의 오케스트레이션 레이어(소위 에이전트의 두뇌)를 평가한다.
즉 AI 에이전트에 대한 평가는 시스템 수준의 테스트(System-level testing)로 진행된다.
계획, 도구, 메모리 등을 포함한 전체 시스템이 제대로 작동했는지를 파악해야 한다.

체크리스트

체크 항목	확인할 내용
① 최종 출력	작업 완료 여부, 작업 성공률, 단계별 진행도, 출력 품질(일관성/정확성/명확성), 안전성(편향, 프롬프트 인젝션 방어)
② 계획 및 추론	복잡한 목표를 논리적으로 분해했는가, 각 단계를 합리적으로 정당화하는가, 멀티턴 동안 일관성 유지하는가
③ 도구 사용	올바른 도구 선택, 정확한 파라미터 전달, 출력 처리, 불필요한 호출 회피(레이턴시·비용 관리)
④ 메모리 및 컨텍스트	중요한 정보 기억 여부, 과거 정보 정확히 검색, 장기 컨텍스트·상충 정보 처리 (RAG의 경우 precision/recall 확인)

최종 출력

시스템 레벨에서 가장 먼저 점검할 것은 최종 결과이다.

1. 작업 성공률 : 실제로 일을 끝마쳤는가
2. 출력 품질 : 단계별 진행 상황, 일관성, 정확성, 명확성
3. 안전성 : 편향, 프롬프트 인젝션 방어

계획 및 추론

모델이 목잡한 목표를 논리적으로 세분화 하는지,

긴 멀티턴 동안 일관적이고 합리적인 사고를 이어나가는지

도구 호출

1. 도구를 효과적으로 호출하는가
2. 올바른 도구를 호출하는가
3. 정확한 매개변수로 출력을 처리하는가
4. 불필요한 호출로 지연 시간과 비용이 늘고 있진 않은가

메모리와 컨텍스트

1. 중요한 정보를 기억하고 있는가
2. 과거 정보를 Retrieve(검색)하고, 모순된 정보들을 잘 다루는가

이때 AI 에이전트의 응답이 어떤 레이어에서 잘못되는지를 파악하는 것이 중요하다.

• 컨텍스트 정밀도 (Context Precision): 실제 질문에 필요한 핵심 정보만 포함되어 있는지, 노이즈가 너무 많아 AI 에이전트들의 정확성이 떨어지는 것은 아닌지

• 컨텍스트 재현율 (Context Recall): 필요한 정보를 모두 가져왔는지, 결정적인 내용이 누락되어 재현률이 떨어지고 AI 환각이 발생하진 않는지

• ① 도구의 문제 (Tool Issue) : 도구 설정이 잘못되어 AI 에이전트가 사용하기 어렵거나, 잘못된 값을 반환하게 되는 경우

• ② 추론의 공백 (Reasoning Gap): AI가 인과관계, 선후관계를 잘못 파악하거나 논리적인 단계를 건너 뛰는 경우

• ③ 메모리 실패 (Memory Failure): 대화가 길어질 때에 과거 맥락을 잃어버리면서 정확성이 떨어지는 경우

 

멀티 에이전트 평가 예시

다음의 워크 플로우를 가진 멀티 에이전트 시스템이 있다고 하자

1. 에이전트 A : 가장 앞단에서 고객과 소통하고 다른 에이전트에 정보를 넘겨준다
2. 에이전트 B : 환불 및 교환에 특화된 에이전트이다. 이와 관련된 도구들을 지니고 있다.

이와 같은 멀티 에이전트를 평가할 때 다음과 같은 테스트는 정확하게 멀티 에이전트 시스템을 평가할 수 없다.

케이스	개별 평가 결과	실제 상황
A만 단독으로 "환불 성공률" 평가	0% 성공 (A는 환불을 안 하니까)	A는 성공 — A의 임무는 환불이 아니라 정보 인계였음
A가 잘못된 주문 ID를 B에게 전달, B는 정상 처리	B 단독으론 성공처럼 보임	전체 시스템은 실패 — 잘못된 정보가 전달됐기 때문

1. 에이전트 A가 환불에 성공하는지 확인한다 : 에이전트 A는 환불 도구가 없기 때문에 테스트가 통과되지 않는다.
2. 환불이 성공하는지 확인한다 : 에이전트 A가 잘못된 주문 Id를 넘겨줬는데, 에이전트 B가 임의로 환불에 성공하는 경우가 발생한다면? 테스트는 통과했지만 시스템은 실패한다.

즉 멀티 에이전트 평가에서는 아래의 요소를 모두 확인해야 시스템의 성공을 파악할 수 있다.

1. 전체 네트워크가 목표를 달성했는가
2. 공유 컨텍스트가 안전하게 전달됐는가
3. 전체 시스템이 비용·레이턴시 측면에서 효율적인가

테스트 피라미드

단계	테스트 유형	주요 목적	비용·속도
Tier 1	컴포넌트 수준 단위 테스트	도구와 매개변수의 정확성 확인	빠르고 저렴함
Tier 2	궤적 통합 테스트	계획, 추론, 전체 실행 흐름 확인	중간
Tier 3	멀티 에이전트 E2E/인간 검토	도움성, 안전성, 사용자 경험 확인	느리고 비쌈

 컴포넌트 수준의 단위 테스트는 실용적이다.

인간 검토는 비용이 비싸지만, 실제 인간 검토를 진행해야 에이전트의 완성을 평가할 수 있다.

세 단계는 서로 대체되지 않고 보완적이다.

 

컴포넌트 수준 테스트

에이전트를 구성하는 가장 작은 요소를 독립적으로 검증하는 단계다.

주로 다음 항목을 테스트한다.

• 올바른 도구를 선택했는가

• 필요한 매개변수를 빠짐없이 전달했는가

• 매개변수 값이 정확한가

• JSON 구조가 올바른가

• 도구 호출 결과 형식이 유효한가

• 잘못된 입력을 적절히 처리하는가

예를 들어 사용자가 다음과 같이 요청했다고 가정한다.

해리포터 책을 찾아줘.

에이전트가 search_local_library 도구를 선택해야 한다면 Tier 1에서는 다음을 확인한다.

선택한 도구: search_local_library
전달한 매개변수: title="Harry Potter"

평가 항목	기대 결과
도구 선택	지역 도서관 검색 도구
매개변수 이름	title
매개변수 값	Harry Potter
요청 형식	유효한 JSON
오류 처리	잘못된 입력 시 명확한 오류 반환

빠르고 자동화하기 쉽기 때문에 CI/CD 파이프라인에 포함하기 좋다.

모델이나 프롬프트를 변경할 때 기존 기능이 깨지는 회귀 오류도 조기에 발견할 수 있다.

 

궤적 테스트

• 궤적이란?

  궤적은 에이전트가 하나의 작업을 해결하기 위해 거친 전체 여정을 의미한다.

  일반적으로 다음 요소가 포함된다.

  • 호출한 도구의 순서

  • 각 도구에 전달한 매개변수

  • 중간 처리 단계

  • 오류 발생 후 대응 방식

  • 기억한 이전 정보

  • 최종 답변

궤적 테스트에서는 아래의 항목을 평가한다.

• 에이전트가 작업을 논리적인 단계로 나눴는가

• 도구를 올바른 순서로 호출했는가

• 이전 도구의 결과를 다음 단계에 반영했는가

• 실패한 도구를 반복 호출하지 않았는가

• 오류 발생 시 다른 경로로 전환했는가

• 사용자 요청을 끝까지 기억했는가

• 최종 목표를 실제로 달성했는가

책을 찾아 주문하는 북파인더 에이전트를 가정해 보자.

이 에이전트는 다음 세 가지 도구를 사용한다.

• 지역 도서관 검색

• 지역 서점 검색

• 온라인 주문

사용자 요청은 다음과 같다.

해리포터 책을 주문해줘.

원하는 실행 흐름은 다음과 같다.

지역 도서관 검색
→ 지역 서점 검색
→ 온라인 주문
→ 주문 결과 안내

단, 도서관이나 서점에서 책을 찾았다면 온라인 주문까지 진행할 필요는 없다.

따라서 실제 평가에서는 하나의 고정된 도구 호출 목록만 보는 것이 아니라, 각 조건에 맞는 유효한 경로를 정의해야 한다.

순서	작업	조건
1	지역 도서관 검색	항상 실행
2	지역 서점 검색	도서관에 없는 경우
3	온라인 주문	도서관과 서점에 모두 없는 경우
4	결과 안내	처리 완료 후 실행

 

만일 아래와 같은 순서로 실행된다면 최종적으로 책을 주문했더라도 올바른 궤적이라 할 수 없다.

온라인 주문
→ 지역 도서관 검색
→ 지역 서점 검색

지역에서 책을 구할 수 있는지 확인하지 않고 바로 온라인 주문을 실행했기 때문에 비용이나 배송 시간 측면에서 비효율적이다.

 

Tool Trajectory Average Score

Google Agent Development Kit 등에서는 실제 도구 호출 순서가 예상한 궤적과 얼마나 비슷한지 측정한다.

점수 범위는 0에서 1이다.

점수	의미
1.0	예상 궤적과 완전히 일치
0.8	대부분의 실행 순서가 일치
0.5	일부 핵심 단계만 일치
0.0	예상 궤적과 전혀 다름

하지만 실제 도구호출 순서가 기대값과 완벽하게 일치하는 경우는 없기에 적정 수준의 점수를 기준하는 것이 중요하다.

 

인간 검토

최종 단계에서는 아래와 같은 부분을 테스트해야 한다.

• 답변이 실제로 도움이 되는가

• 사용자의 의도를 제대로 이해했는가

• 지나치게 장황하거나 불친절하지 않은가

• 위험한 행동을 임의로 실행하지 않았는가

• 상식적으로 자연스러운 판단을 했는가

• 사용자에게 필요한 설명을 제공했는가

• 개인정보와 민감 정보를 안전하게 처리했는가

가령 아래와 같은 평가표를 작성해볼 수 있다.

항목	점수 범위
정확성	1~5
도움성	1~5
명확성	1~5
안전성	1~5
자연스러움	1~5
전체 만족도	1~5

 

하지만 비용이 크므로 출시 전 최종 단계에서 시행하는 것이 좋다.