AI Agent의 평가
오늘은 AI 에이전트 평가에 대해 깊이 있게 공부해봤다. W&B(Weights & Biases) 자료를 기반으로 에이전트 평가에 대한 내용 정리해 본다.
AI 에이전트 평가의 평가 방법
에이전트를 만들고 나면 원하는 성능이 나올 때까지 끊임없이 평가하고 개선해야 한다. 단순히 LLM(Large Language Model)만 평가할 때는 입출력만 보면 됐지만, 에이전트는 LLM과 여러 도구들이 결합된 복합적인 시스템이라 상황이 다르다. 전체 시스템뿐만 아니라 각 구성 요소도 꼼꼼히 평가해야 한다. 특히 에이전트는 라우터에 따라 도구 사용이 동적으로 바뀌기 때문에, 이런 경로 변화까지도 함께 고려해야 한다는 점이 흥미로웠다. 아직 평가 방법이 계속 발전 중이라지만, W&B 백서에서는 2025년 2월 기준 실무 관행을 토대로 방향성을 제시하고 있었다.
에이전트 시스템 평가의 관점
효과적인 에이전트 시스템을 개발하고 운영하려면 여러 시점에서 평가하는 게 필수적이다. 단순히 최종 결과만 보는 게 아니라, 처리 단계별 동작이나 선택 프로세스까지 포괄적인 평가가 필요하다는 점을 다시 한번 깨달았다. W&B는 세 가지 중요한 접근 방식을 요약해 설명했는데, 각각의 특징을 정리해 봤다.
1. 시스템 전체 평가
이미지 출처: Googld ADK Docs - Evaluate
이 방식은 입력에 대한 최종 출력이 기대하는 품질을 충족하는지 검증한다. 태스크 달성도를 직접 측정할 수 있다는 점이 가장 큰 특징이다. 시스템이 설정된 제약(레이턴시, 비용 등)을 만족하면서 적절한 출력을 생성하는지 평가하는 것이다.
다만, 내부에서 어떤 처리가 일어났는지 파악하기 어려워서 문제가 생겼을 때 원인 분석이 어렵다는 단점이 있다. 이를 보완하기 위해 단계별 평가를 병행해서 내부 과정을 시각화하고 효율적으로 개선할 수 있다고 한다. 시간과 비용이 많이 드는 방식이라, 빠른 개선을 위해서는 평가 시점을 전략적으로 잘 선택하는 게 중요하다고 느꼈다.
2. 각 스텝/서브모듈별 평가
시스템의 각 단계에서 발생하는 의사결정, 출력, 처리 시간, 비용 등을 개별적으로 검증하는 방식이다. 문제 발생 위치를 정확하게 식별할 수 있다는 게 큰 장점이다. 일단 평가 체계를 구축하면 이후 반복적인 검증을 빠르게 할 수 있다고 한다.
하지만 각 단계에 맞는 평가 기준과 데이터셋을 준비해야 하고, 현실적으로 모든 단계를 평가하기는 어렵다고 한다. 특히 앞 단계의 맥락을 반영한 평가 데이터 설계는 정말 복잡할 것 같다.
3. 단계/도구 선택 트레이스 평가
이미지 출처: Markovate - AI Agent Evaluation
태스크 수행 과정에서 각 단계의 흐름과 도구 선택 경로를 평가하는 방식이다. 시스템이 예상된 절차에 따라 작동하는지 검증하는 것이 목표다. 예를 들어, 입력에 대한 이상적인 도구 선택 경로를 미리 정의하고 실제 수행 결과와 비교하는 방식이다. 이를 통해 불필요한 도구 호출이나 과도한 처리 단계를 식별하고 시스템을 최적화할 수 있다. 처리 시간과 비용에 영향을 주는 병목 요인을 파악하는 데도 유용하다고 한다.
가장 어려울 것 같다고 생각한 부분은, 정답 경로가 하나로 고정되지 않고 여러 유효한 경로가 존재할 수 있어서 평가 기준 설정이 어렵다는 점이었다. 실제로 에이전트를 사용하는 경우는 단순한 rule-based 시스템이 아니라 복잡한 의사결정이 필요한 시스템이 많으니, 모든 경로를 포괄적으로 분석하려고 하면 평가 프로세스가 너무 복잡해질 수 있겠다는 생각이 들었다.
평가 지표
평가 지표는 크게 정확도(Accuracy), 시스템(System), 에러(Error), 실행 경로(Execution Path) 네 가지 카테고리로 나뉜다고 한다. 각각의 특징과 용도를 자세히 살펴봤다.
정확도
시스템 출력의 정확성을 측정하는 가장 기본적인 지표다. 정답이 명확하면 자동화된 벤치마크 평가를 사용하고, 정답이 명확하지 않을 때는 분류기나 LLM을 이용하거나 사람이 직접 평가한다고 한다. LLM 단독 평가와 본질적으로 다르지 않다고 하니, 이 부분은 비교적 익숙했다. 또한, 범용적인 벤치마크 외에도 금융 분야의 FLICK, 의료 분야의 MED-QA, 프로그래밍 분야의 SWE-bench처럼 분야별로 특화된 벤치마크를 통한 평가도 언급하고 있었다. 구성하고자 하는 에이전트 시스템의 활용 분야에 알맞는 벤치마크가 무엇인지 파악하는 것 또한 중요할 것으로 생각된다.
시스템
효율성과 사용자 경험을 측정하는 지표로, 주로 레이턴시, 비용, 토큰 소비량 등을 포함한다. 레이턴시는 사용자 반응 속도에 직접 영향을 미치고, 비용은 성능 대비 경제성을, 토큰 소비량은 레이턴시와 비용 모두에 영향을 준다. 동일한 정확도를 유지하면서 토큰 사용량이 적다면 더 효율적인 시스템으로 볼 수 있다는 점이 중요했다.
레이턴시가 길거나 비용이 과도한 경우 어느 단계에서 병목이 발생하는지 파악하는 것이 중요하다고 하는데, 얼마 전에 공부했던 Observability의 중요성이 여기서 또 언급되니 다시 한번 그 중요성을 실감했다.
에러
태스크나 도구의 실행이 정상적으로 완료되었는지 측정하는 지표다. 처리 실패가 심각한 영향을 미칠 수 있는 환경에서는 에러 핸들링 구조가 중요하다고 한다. 또한, 태스크가 완료된 것처럼 보여도 핵심적인 확인 절차가 누락된 경우가 있을 수 있어서, 각 단계에서 필요한 확인이 제대로 수행되었는지 점검하고 실행 내역이 명확하게 기록되는 구조를 마련해야 한다고 강조했다. 최근 검색을 통한 정보 정리 에이전트를 테스트하면서, 검색을 수행하지 않고 모델이 학습된 시점의 정보를 기반으로 마치 검색한 것처럼 출력하는 현상을 경험했었는데, 이 내용을 보니 더욱 깊이 공감할 수 있었다.
실행 경로
에이전트 시스템에서는 도구 선택 및 실행 흐름 자체도 중요한 평가 항목이다. 다음 세 가지 측면에서 평가를 수행한다고 한다.
- 프로토콜 준수: 태스크 복잡도에 따라 적절한 분석 절차가 선택되고 있는지 확인하는 것이다. 간단한 태스크에 상세한 분석 프로토콜을 적용하면 불필요한 레이턴시와 비용이 발생할 수 있으니, 태스크 성격에 맞춰 분석의 깊이를 동적으로 조절하는 구조가 필요하다는 점을 알 수 있었다.
- 태스크별 단계 수: 불필요한 처리의 최소화, 효율적인 실행 여부를 평가하는 것이다. 예를 들어 Reflection 패턴에서 반복 스텝 수가 과도한 경우, 출력 변화가 미미해지는 시점을 감지해서 이후 과정을 생략하는 방법으로 처리 비용을 줄일 수 있다고 한다.
- 휴먼 피드백의 실행 횟수 및 타이밍: 필요 시점에서 휴먼 피드백이 적절히 이루어지고 있는지 검토하는 것이다. 사람이 직접 확인하는 절차가 적절히 실행됨을 보장하여 시스템의 신뢰성을 확보하는 데 기여한다.
개발 단계와 운영 단계에서의 평가
개발 단계에서의 평가와 운영 환경에서의 평가는 수집하는 지표 자체에는 큰 차이가 없다고 한다. 운영 환경에서도 정확도, 시스템, 에러, 실행 경로 등을 계속 추적하며 개선하는 것이 중요하다고 강조했다.
다만, 운영 환경에서는 자동화된 정확도 평가를 실시간으로 수행하기 어려운 경우가 많아서, 운영 중에 수집되는 실제 휴먼 피드백이 중요한 지표가 된다고 한다. 이런 피드백은 시스템의 실제 활용 맥락을 반영하며 평가 및 개선 과정에서 유용한 정보로 활용된다는 점이 인상 깊었다.
또한, 생성형 AI 애플리케이션의 특성상 사용자가 자유롭게 텍스트를 입력할 수 있으므로, 시스템이 개발자의 예상과 다른 방식으로 사용될 가능성이 존재한다는 점도 고려해야 한다. 따라서 실제 사용자 행동을 분석하고 이해하는 것이 중요하며, 사용자 입력 데이터를 기반으로 질문 유형, 질문 대상, 또는 시스템이 응답하지 못한 사례 등을 분석하고 이를 통해 시스템의 실용성을 높이기 위한 인사이트를 도출해야 한다고 한다.
평가 체계 구축의 흐름
마지막으로, 실제 AI 에이전트 시스템의 평가 체계를 어떻게 구축해 나갈 수 있는지 그 흐름을 설명해 줬다. 효과적인 평가 체계 구축을 위해서는 단계적인 접근이 중요하며, 네 가지 주요 단계를 중심으로 설명하고 있었다.
스텝 1: Observability 플랫폼 도입
개발 초기에는 직관적인 결과 확인(“Vibe Check”)만으로도 어느 정도 시스템 상태를 파악할 수 있지만, 운영 단계에 접어들면 지속적인 개선을 위한 체계적인 평가 구조가 필요하다고 한다. 이를 위해 먼저 실행 과정을 기록하고 시각화하는 기능을 제공하는 플랫폼을 도입하여 기반을 마련하라고 조언했다. 역시 Observability의 중요성은 아무리 강조해도 지나치지 않는 것 같다. 자료 제공사인 W&B가 관련 플랫폼을 판매하고 있는 만큼 해당 플랫폼의 도입에 중점을 두고 설명하고 있으나, 최초 시스템 설계에서 부터 Observability를 고려한다면 꼭 플랫폼을 도입해야할지는 의문이다.
스텝 2: 기본 테스트 케이스 정비
에이전트의 핵심 기능을 기준으로 기본적인 테스트 케이스를 준비해야 한다. 이를 통해 개선 효과를 일정한 기준으로 비교할 수 있다는 장점이 있다. 초기에는 최소한의 기능 검증이 가능한 간단한 케이스부터 시작하고, 점차 범위와 복잡도를 확대해 나가라고 한다. 완성도 높은 테스트 세트가 반복 가능한 평가를 가능하게 한다는 점을 명심해야겠다.
스텝 3: Playground에서의 검증
모든 단계를 동일한 밀도로 평가하는 것은 현실적으로 어렵기 때문에, Playground와 같은 소규모 테스트 환경에서 개별 스텝을 실험적으로 검증하고, 집중적인 평가가 필요한 지점을 식별하라고 한다. 이 과정을 통해 평가 체계의 전체 구조가 점차 명확해질 수 있다고 하니, 효율적인 평가를 위해 꼭 필요한 단계라고 생각했다.
스텝 4: 본격적인 평가 체계 구축
최종 단계에서는 다양한 입력 예시, 성공·실패 사례, 복잡한 문의 등을 포함한 평가 데이터셋을 정비한다. 이러한 세트를 활용하면, 에이전트의 변경이 실제 성능 향상으로 이어졌는지 정량적으로 검증할 수 있다고 한다. 이를 통해 보다 안정적인 개선 사이클을 구현할 수 있을 것이다.
평가 체계가 마련된 이후에는 적절한 모델 선택, 프롬프트 튜닝, AI 에이전트 구조 재설계 등을 통해 시스템을 계속 개선해 나갈 수 있다. 예를 들어 tabelog 개발 블로그에 따르면, 메뉴 문자 인식 성능 평가에서 가로쓰기에는 GPT-4o가, 세로쓰기에서는 Claude 모델이 더 높은 정확도를 보인다고 한다. 이처럼 태스크를 세분화하고 체계적인 평가를 통해 성능 차이를 식별함으로써, 모델 조합이나 전략을 최적화할 수 있다는 점이 정말 흥미로웠다.
오늘 공부를 통해 AI 에이전트 평가가 얼마나 복잡하고 다층적인 과정인지 다시 한번 깨달았다. 단순히 잘 작동하는지 여부를 넘어, 내부 작동 방식과 효율성, 그리고 사용자 경험까지 고려한 Holistic 한 평가가 필수적이라는 점을 명심해야겠다. 이 내용을 바탕으로 실제 에이전트 프로젝트에 어떻게 적용할 수 있을지 고민해 봐야겠다.