AgentBench: 에이전트로서의 LLM 평가 — 금융 AI 신뢰성을 위한 교훈
Beancount 쓰기(write-back) 에이전트가 안정적으로 수행해야 할 작업이 무엇인지 자문해 본다면, 그 답은 단순히 "텍스트 생성"이 아닙니다. 그것은 "구조화된 환경에서 궤도를 벗어나지 않고 일련의 작업을 수행하는 것"입니다. AgentBench (Liu 등, 칭화대, ICLR 2024)는 이러한 능력을 대규모로 측정하려는 최초의 진지한 시도 중 하나이며, 2023년의 스냅샷 데이터는 여전히 추출할 가치가 있는 교훈을 담고 있습니다.
논문 소개
칭화대학교의 Xiao Liu와 21명의 공동 저자가 발표한 AgentBench는 LLM을 수동적인 텍스트 생성기가 아닌 인터랙티브 에이전트로 스트레스 테스트하기 위해 설계된 8개의 환경을 정의합니다. 5개의 환경은 독창적으로 설계되었습니다: OS (bash 상호작용), 데이터베이스 (SQL 생성 및 오류 복구), 지식 그래프 (도구 기반 구조화된 쿼리), 디지털 카드 게임 (멀티턴 전략 경쟁), 수평적 사고 퍼즐 (연역적 대화). 나머지 3개는 기존 데이터셋에서 가져왔습니다: ALFWorld의 가사 관리, WebShop의 웹 쇼핑, Mind2Web의 웹 브라우징. 이 논문은 상용 API 모델과 최대 70B 규모의 오픈소스 모델을 포함한 27개 모델을 평가했습니다. 약 4,000개의 개발 세트와 13,000개의 테스트 세트 생성을 통해 환경별 성공률과 종합 점수를 보고합니다.
핵심 아이디어
- GPT-4가 종합 점수 4.01로 선두를 달리고 있습니다. Claude-2는 2.49점, GPT-3.5-turbo는 2.32점을 기록했습니다. 제출 당시 가장 강력한 오픈소스 모델이었던 CodeLlama-34B는 0.96점에 그쳤습니다. API 기반 모델의 전체 평균은 2.24점인 반면, 오픈소스 모델은 0.42점이었습니다.
- GPT-4는 OS에서 42.4%, 데이터베이스에서 32.0%, 가사 관리에서 78.0%를 기록했습니다. 이러한 격차는 어떤 환경이 지시 이행(instruction-following)에 보상을 주는지, 아니면 구조화된 추론에 보상을 주는지 보여줍니다.
- "작업 한도 초과(Task Limit Exceeded)"가 지배적인 실패 모드입니다. 지식 그래프 실패의 67.9%가 작업을 해결하기 전에 단계 예산을 초과했습니다. 이는 지식의 결핍이 아니라 장기적 추론(long-horizon reasoning)의 실패입니다.
- 형식 준수 오류(Format compliance errors)는 데이터베이스 작업 실패의 53.3%를 차지합니다. 에이전트가 구문상 틀린 SQL을 생성하거나, 평가자가 파싱할 수 없는 산문 형태로 쿼리를 감싸는 경우입니다.
- 유효하지 않은 작업 선택(Invalid action selection)은 가사 관리 실패의 64.1%를 유발합니다. 에이전트가 현재 상태에서 사용할 수 없는 작업을 명명하는 경우입니다.
- 코드 데이터 학습은 "작업 전반에 걸쳐 상반된 영향"을 미칩니다. 절차 준수 환경에서는 도움이 되지만, 대화 비중이 높은 환경에서는 일반적인 추론 능력을 저해할 수 있습니다.
유효한 점과 그렇지 않은 점
다중 환경, 멀티턴, 인터랙티브 평가라는 핵심 설계 선택은 옳았으며 여전히 과소평가되고 있습니다. 대부분의 LLM 벤치마크는 여전히 단일 턴 생성 품질을 측정하지만, AgentBench는 에이전트가 작업이 완료되거나 예산이 소진될 때까지 계속해서 의사결정을 내려야 한다는 점을 정확히 짚어냈습니다.
하지만 이 스냅샷은 현재 시점에서 보면 다소 오래된 데이터입니다. 2023년 중반에는 GPT-4(4.01)와 최우수 오픈소스 모델(0.96) 사이의 격차가 위협적으로 보였으나, 2025년 현재 그 격차는 상당 부분 좁혀졌습니다. Llama 3.1 70B나 Qwen 2.5 72B 같은 모델들은 2년 전만 해도 참신한 장애물이었던 지시 이행 및 형식 준수 기준을 이제 가볍게 통과합니다. 이 논문을 "오픈소스는 에이전트 작업을 수행할 수 없다"는 근거로 읽는 것은 실수일 것입니다. 대신 "형식 준수와 장기적 일관성이 여전히 어려운 문제"라는 증거로 읽는 것은 유효합니다.
또한 광범위함과 깊이 사이의 긴장도 존재합니다. 8개의 환경이 포괄적으로 보일 수 있지만, 각 환경은 상대적으로 얕습니다. WebArena(Zhou 등, 2024)는 812개의 장기적 템플릿 작업을 통해 웹 브라우징만을 전문적으로 다루며, OSWorld(Xie 등, 2024)는 우분투와 윈도우에서 369개의 실제 데스크톱 작업을 벤치마킹합니다. AgentBench는 환경 전반에 걸친 신호를 줄 수 있지만, 특정 환경을 식별한 후에는 도메인별 벤치마크를 대체하기 어렵습니다.
표 4의 실패 모드 분류체계는 아마도 가장 오래 남을 기여일 것입니다. 저자들은 실패를 작업 한도 초과, 형식 오류, 유효하지 않은 작업 등으로 세분화했습니다. 이는 단순한 구현 버그가 아니라, 멀티턴 압박 속에서 LLM이 상태를 유지하고, 가용 작업을 추적하며, 파싱 가능한 출력을 생성하는 방식의 구조적 약점입니다. 진지한 에이전트 시스템이라면 반드시 이 문제를 해결해야 합니다.
금융 AI에 이것이 중요한 이유
세 가지 주요 실패 모드는 Beancount 쓰기 에이전트에서 발생할 수 있는 문제들과 거의 직접적으로 일치합니다.
**작업 한도 초과(Task Limit Exceeded)**는 장부 대조(ledger reconciliation)의 실패 모드입니다. 여러 계정의 결산(period close)을 대조하려면 기초 잔액 확인, 차변과 대변의 매칭, 불일치 식별 및 수정 제안이 필요하며, 이 체인은 10~20단계까지 쉽게 이어질 수 있습니다. 체인 중간에 컨텍스트나 단계 예산에 도달하여 포기하는 에이전트는 단순히 실패하는 것이 아니라, 장부를 부분적으로 수정된 상태로 남겨둘 위험이 있습니다.
**형식 오류(Format Error)**는 트랜잭션 입력의 실패 모드입니다. Beancount는 엄격한 문법을 가지고 있습니다. 잘못된 형식의 포스팅(통화 누락, 잘못된 들여쓰기, 유효하지 않은 플래그)은 파일을 손상시키는 파싱 오류를 발생시킵니다. Beancount 출력 주변에 산문을 생성하거나, 잘못된 형식으로 그럴듯한 구문을 만드는 에이전트는 무용지물입니다. 이는 CRITIC 논문의 핵심 문제가 더 엄격한 도메인에 적용된 사례입니다.
**유효하지 않은 작업(Invalid Action)**은 쓰기 안전성(write-back safety)의 문제입니다. 실제 장부에서 작동하는 Beancount 에이전트는 트랜잭션 추가, 플래그 수정, 포스팅 이동과 같은 제한된 안전 작업 세트만을 가져야 합니다. 이 세트를 벗어난 작업(예: 여전히 포지션이 남아 있는 계정 삭제)을 환각(hallucination)하는 것은 감사를 하기 전까지는 포착하기 어려운 정확성 실패입니다.
"코드 학습이 상반된 영향을 미친다"는 발견도 관련이 있습니다. Beancount 쓰기는 지식 추출보다는 코드 생성에 가깝기 때문에 코드에 사전 학습된 모델이 자연스럽게 적합할 것입니다. 하지만 코드 학습이 멀티턴 상황에서 대화 추적 능력을 저해한다면, 배포 전에 AgentBench와 같은 하이브리드 평가를 통해 이러한 트레이드오프를 확인하는 것이 필수적입니다.
다음 읽을거리
- WebArena (Zhou 등, 2024; arXiv:2307.13854) — 실제 브라우저 환경에서의 812개 웹 브라우징 작업. AgentBench의 웹 계층을 깊이 있게 발전시킨 후속 연구.
- OSWorld (Xie 등, 2024; NeurIPS 2024) — 파일 시스템과 GUI 작업을 포함한 전체 데스크톱 환경 벤치마크. AgentBench의 OS 계층을 직접적으로 계승한 심층 벤치마크.
- TAU-bench (Yao 등, 2024) — 실제 도구 사용과 사용자 시뮬레이션을 통해 리테일 및 항공사 API 환경에서 에이전트를 평가. Beancount 장부를 환경으로 사용하는 설정과 가장 유사한 공개 벤치마크.
