에이전트가 실패했을 때, 우리는 어디를 보고 있었나
ICML 2026. 능력치로 덮여온 에이전트 실패의 원인 분석에 관한 발표.
목차
이 글은 ICML 2026 워크숍에서 들은 oral 발표를 발표자 1인칭 시점으로 재구성한 것입니다.
요즘 에이전트들은 예전보다 훨씬 잘한다. 문제는 그 발전이 실패를 없애서가 아니라, 그냥 능력치로 밀어붙여서 이루어질 때가 많다는 데 있다. 실패의 원인을 제대로 짚고 고쳐서 좋아진 게 아니라, 모델이 세지니까 웬만한 문제는 그냥 뚫고 지나가버리는 식이다. 그런데 이렇게 되면 역설적으로 남아 있는 실패들은 점점 더 알아보기 어려워진다. 예전엔 눈에 띄던 실수가, 이제는 훨씬 미묘하고 조용한 형태로 숨어버린다. 나는 이 지점에서 이 작업을 시작했다.
실패는 사실 굉장히 유용한 신호다. 그 신호를 제대로 읽어낼 수만 있다면, 우리는 에이전트를 실제로 더 나아지게 만들 수 있다. 그런데 그러려면 먼저 실패의 원인을 정확히 짚어내는 일, 즉 failure attribution이 필요하다. 에이전트가 실행한 롤아웃 안에서 아주 초반의 어느 한 스텝을 찾아내야 한다. 그 스텝 하나만 고쳤으면 전체 실행이 성공으로 바뀌었을, 바로 그 지점 말이다.
who, when, what — 그리고 지금까지의 벤치마크가 놓친 것
이 문제를 나는 세 갈래로 나눠서 본다. 먼저 “누가”다. 멀티에이전트 시스템 안에서 어떤 에이전트가 실패를 일으켰는지를 찾는 일이다. 다음은 “언제”다. 정확히 어느 스텝에서 궤도를 벗어났는지를 짚는 일이다. 그리고 마지막이 “무엇”이다. 이게 어떤 종류의 실패인지, 실패 모드에 라벨을 붙이는 일이다.
그런데 지금까지 나와 있는 failure attribution 벤치마크들을 보면 규모가 아주 작고, 게다가 거의 다 텍스트 하나에만 갇혀 있었다. 그래서 나는 싱글 에이전트와 멀티 에이전트 프레임워크를 모두 아우르고, 텍스트뿐 아니라 이미지와 비디오까지 다루는 대규모 벤치마크를 만들기로 했다. 결과적으로 우리는 26개의 서로 다른 소스 벤치마크에서 뽑아낸 1만 2천 개 이상의 실패 트레이스를 모았다. 세 가지 모달리티를 가로지르고, 이 실패들을 아홉 개의 태스크 카테고리로 나눴다. QA, VQA, 비디오 이해, 비디오 생성, 텍스트 태스크 등을 포괄한다. 여기에 15개의 서로 다른 에이전트 프레임워크와 18가지 에러 타입까지 얹었다. 이 정도 스케일과 모달리티 커버리지를 가진 failure attribution 벤치마크는 이전에 없었다.
warm-start rollout — 에러를 “심는” 방법이 왜 중요한가
벤치마크를 만들면서 제일 신경 쓴 부분은 사실 데이터 자체보다 이 실패 사례들을 어떻게 만들어내느냐였다. 기존 벤치마크들이 하던 방식은 단순했다. 처음부터 롤아웃을 시작해서, 중간 어딘가에 원하는 지점에서 에러를 주입하는 식이다. 그런데 여기엔 함정이 있다. 에이전트의 행동은 원래 비결정적이다. 처음부터 롤아웃을 새로 시작하면, 에러를 주입하기도 전에 이미 이전과는 다른 방향으로 미세하게 드리프트가 생긴다. 그러니 같은 시점에 같은 에러를 주입한다고 해도, 그 순간의 맥락이나 트라젝토리 자체가 매번 조금씩 달라져 있는 것이다.
그래서 우리는 warm-start rollout이라는 방식을 썼다. 에러를 주입하기 전까지의 모든 스텝은 그대로 리플레이한다. 그러다 특정 지점에 도달하면, 별도의 모델이 그 스텝에 정확히 에러를 심는다. 그리고 그 이후부터 롤아웃을 이어간다. 이렇게 하면 판별이 명확해진다. 에러를 주입했을 때는 실패하고 주입하지 않았을 때는 성공한다면, 그 주입된 에러야말로 그 스텝에서의 결정적 원인이라고 확신할 수 있다. 맥락이 흔들리지 않은 채로 원인과 결과를 정확히 짝지을 수 있게 되는 셈이다.
22%라는 숫자, 그리고 모델이 진짜로 보고 있는 것
이렇게 만든 벤치마크로 여러 모델과 여러 에이전트 프레임워크를 평가해봤다. 결과는 이 문제가 아직 전혀 풀리지 않았다는 걸 보여준다. 어떤 에이전트가 잘못했는지, 어느 스텝에서 결정적 에러가 났는지는 모델들이 꽤 잘 짚어낸다. 그런데 그 실패가 정확히 어떤 유형인지 분류하는 문제로 가면 이야기가 완전히 달라진다. 가장 성능이 좋은 모델조차 22%밖에 맞히지 못했다.
모달리티별로 봐도 예상을 벗어나는 지점이 있었다. 보통은 텍스트가 제일 쉬운 태스크라고 생각하기 쉽다. 그런데 에러 분류로 들어가면 오히려 텍스트의 정확도가 제일 낮았다. 이미지나 비디오로 갈수록 그나마 나은 성능이 나왔다. 더 들여다보면, 모델들은 결국 표면적인 유사성만 보고 판단하고 있었다. 지각 오류나 추론 오류, 액션 오류처럼 신호가 뚜렷한 실패는 꽤 잘 잡아낸다. 하지만 플래닝 오류와 검증 오류처럼 서로 겉모습이 비슷한 경우엔 성능이 뚝 떨어진다. 근본 원인을 이해하는 게 아니라, 눈에 띄는 패턴만 흉내 내고 있다는 뜻이다. 스텝을 짚어내는 능력도 트레이스가 길어질수록 급격히 무너졌다. 94%에서 시작한 정확도가 50%, 심지어 그 아래로까지 떨어지는 경우도 있었다.
질의응답 시간에 누군가 물었다. 벤치마크를 확장할 때 어떤 종류의 실패를 주입할지 어떻게 결정하느냐고. 답은 이랬다. 먼저 모든 유형의 에러를 모아 테스트 세트를 구성한 다음, 실제 에이전트가 돌아간 성공 트레이스와 실패 트레이스를 비교해서 어떤 에러가 실제로 얼마나 자주 발생하는지를 파악한다. 그 분포를 그대로 따라서 에러를 샘플링하고, 그렇게 실제 실패 패턴을 최대한 모사하는 방식으로 각 모달리티에 맞는 에러를 주입한다. 인위적으로 그럴듯한 실패를 지어내는 게 아니라, 실제 세계에서 에이전트가 정말로 넘어지는 방식을 그대로 벤치마크 안으로 옮겨오려는 시도였다.
결국 내가 이 작업에서 확인한 건 하나다. 에이전트가 똑똑해질수록, 그 실패는 점점 더 조용해진다. 그리고 조용한 실패일수록, 그걸 짚어내는 능력이 있어야만 다음 단계로 나아갈 수 있다. 우리가 만든 벤치마크가 완벽한 답은 아니지만, 적어도 지금 모델들이 어디서 진짜로 이해하고 있고 어디서 그냥 패턴을 흉내 내고 있는지를 구분할 수 있는 도구 하나는 만든 셈이다.