실패를 분류하는 것만으로는 부족하다 — 에이전트마다 다른 택소노미가 필요한 이유
ICML 2026. MAST 이후, 에이전트별 실패 택소노미와 그 활용법을 다룬 발표.
목차
이 글은 ICML 2026 워크숍에서 들은 oral 발표를 발표자 1인칭 시점으로 재구성한 것입니다.
2025년은 멀티에이전트 시스템에 대한 기대가 최고조에 달했던 해였다. 동시에 그만큼 실패 사례도 쏟아졌다. 나는 그 실패들을 정리하고 싶었다. 그래서 만든 게 MAST였다.
MAST, 그리고 그 이후에 남은 질문
MAST는 멀티에이전트 시스템에서 반복적으로 나타나는 14가지 실패 모드를 정리한 택소노미다. 에이전트끼리 소통이 끊기는 경우, 언제 멈춰야 할지 몰라 계속 도는 경우, 원래 주어진 태스크 명세에서 슬금슬금 이탈하는 경우 같은 것들을 유형화했다. NeurIPS 2025에 이 작업을 냈고, 예상보다 훨씬 큰 반응을 얻었다. DeepMind나 Apple 같은 곳과 함께 논의를 이어가기도 했고, IBM은 자사 SWE 에이전트를 대상으로 모델별 실패 모드를 분석하는 데 MAST를 그대로 가져다 썼다.
그런데 2026년이 되니 상황이 달라졌다. 멀티에이전트 시스템이 더 이상 실험실의 프로토타입이 아니라 실제로 잘 작동하는, 일상적으로 쓰는 도구가 됐다. 그러면서 자연스럽게 질문이 바뀌었다. “MAST를 넘어서려면 무엇이 필요한가?”
이 질문에 답하려고 기존 접근법들을 다시 들여다봤는데, 셋 다 한계가 뚜렷했다. 태스크 성공률만 보는 방식은 그 안에 숨어 있는 유용한 정보를 전략적으로 버리는 셈이었다. 트레이스에 전문가가 일일이 주석을 다는 방식은 구조를 잃어버리는 데다 비용이 지나치게 높았다. 그리고 정작 MAST 자체도 새로운 실패 모드를 스스로 발견해내지는 못했다. 우리가 만든 택소노미가 고정된 렌즈가 되어버린 것이다.
ATLAS — 시스템마다 다른 택소노미를 자동으로 만들다
그래서 다음 작업으로 ATLAS(Adaptive Taxonomy Learning for Agentic Systems)를 제안했다. 목표는 단순하다. 하나의 만능 택소노미를 만드는 대신, 각 에이전트 시스템과 세팅에 맞춤화된 택소노미를 자동으로 구축하는 것이다.
작동 방식은 이렇다. 먼저 트레이스를 모으고, 여기서 초기 택소노미를 생성한다. 그다음이 핵심인데, 멀티에이전트 시스템이 스스로 이 초안을 검토하는 일종의 “inter-annotator agreement” 단계를 거친다. 이 단계에서 두 가지를 동시에 노린다. 하나는 높은 커버리지, 즉 전체 실패 모드를 최대한 빠짐없이 포괄하는 것이고, 다른 하나는 각 실패 모드가 서로 겹치지 않고 내적으로 명확해서 그걸 보자마자 어떤 개선 액션을 취해야 할지 바로 알 수 있게 만드는 것이다.
여기서 재미있는 설계 선택이 하나 있다. 카테고리의 큰 구조는 고정해두고, 카테고리 안의 세부 항목만 적응적으로 채워 넣는다. 큰 구조는 세 갈래다. 시스템 레벨 실패는 조기 종료나 컨텍스트 손실처럼 시스템 설계 자체의 오류에서 나온다. LLM 특화 실패는 코딩 에이전트나 논문 작성 에이전트처럼 특정 LLM 활용 방식에서 주입되는 변수와 관련이 있다. 도메인 특화 실패는 말 그대로 도메인마다 다르다. 크리티컬한 코딩 태스크와 창작 글쓰기 태스크는 완전히 다른 방식으로 실패한다. 입력으로는 에이전트 지시문과 도메인 정보가 포함된 트레이스를 받고, 이렇게 만들어진 택소노미를 신규 트레이스를 진단하는 데 다시 활용한다.
실제로 여러 벤치마크에 이 방식을 적용해봤더니, 도메인과 벤치마크마다 놀랄 만큼 다른, 그리고 꽤 긴 실패 모드 목록이 나왔다. 물론 공통적으로 반복되는 실패도 있다. 컨텍스트 소진, 조기 종료, 잘못된 상태 관리로 인한 컨텍스트 손실 같은 것들은 어디서나 등장했다. 하지만 도메인 특화 실패는 정말 그 도메인이 아니면 안 보이는 것들이었다. 예를 들어 LeetCode의 동적 프로그래밍 문제에서만 나타나는 특유의 실패 패턴이 있었고, 물리 관련 태스크에서는 물리 법칙 자체를 위반하는 실패 모드가 따로 잡혔다. 고정된 택소노미 하나로는 절대 잡아낼 수 없었을 것들이다.
ATLAS를 실제로 어디에 쓰는가
이렇게 만든 ATLAS를 활용하는 방법을 세 가지로 정리했다.
첫째, 진화 알고리즘으로 멀티에이전트 시스템의 설계 자체를 개선하는 데 쓴다. AlphaEvolve, 버클리의 OpenEvolve, Weco AI, DSPy 계열의 GEPA 같은 선행 연구들이 이미 이 방향을 다루고 있다. 우리가 다르게 한 지점은, 트레이스를 그대로 옵티마이저에 던져주는 대신 ATLAS로 분석한 결과를 넘겨주는 것이다. 그러면 옵티마이저가 훨씬 더 공정하고 상세한 근거를 가지고 판단할 수 있다. 실제로 비교해보니 MAST를 쓰거나 순수 트레이스만 주는 방식보다 ATLAS를 넣었을 때가 확연히 더 좋은 성능을 냈다.
둘째, 코딩 에이전트 시스템 안에서 택소노미 설계를 위한 외부 툴로 쓴다. SWE 에이전트가 실행되는 과정에서 실패 모드를 계속 수집(harvest)해서, 시간이 지날수록 택소노미 자체가 더 정교해지도록 만드는 방식이다.
셋째는 컨텍스트 안에 스킬로 심어 넣거나, 더 나은 LLM judge 에이전트를 만드는 데 쓰는 것이다. 이 부분은 발표 뒷부분에서 더 구체적으로 다뤘다.
스킬로서의 택소노미 — 언제, 어떻게 주입하는가
이 스킬 기반 접근이 실제로 효과가 있다는 걸 확인했고, 이 연구에 참여한 몇몇은 벌써 자기 회사의 일상 플랫폼에 이 방식을 적용하기 시작했다.
메커니즘은 이렇다. 에이전트가 서브태스크를 하나 완료하거나 미리 정해둔 특정 체크포인트에 도달할 때마다, 그 시점에 맞는 택소노미를 검색(retrieve)해서 컨텍스트에 주입한다. 이때 기존에 갖고 있던 택소노미가 여전히 유효하면 그대로 재사용하고, 더 이상 맞지 않으면 분석 과정을 다시 돌려서 새로 만든다. 매번 처음부터 다시 만드는 게 아니라, 필요할 때만 갱신하는 방식이다.
구체적인 사례가 인상 깊었다. 하나는 데이터베이스 쿼리를 확장하는 태스크였고, 다른 하나는 DeepMind의 AlphaEvolve 사례였다. 단위 정사각형 안에 원 26개를 최대한 빽빽하게 채워 넣는 문제인데, AlphaEvolve가 이 문제를 풀면서 특정 문제 클래스를 스스로 도출해냈다. 그리고 그렇게 도출된 스킬(택소노미)을 Claude에게 쥐여줬더니 성능이 크게 뛰었다. 택소노미가 단순히 실패를 사후에 분류하는 도구를 넘어서, 더 나은 시스템을 만드는 재료로도 쓰일 수 있다는 걸 보여주는 사례였다.
세 벤치마크, 그리고 가장 놀라웠던 발견
이 방식을 검증하기 위해 Terminal-Bench, PortCode를 포함한 세 가지 벤치마크에 걸쳐 실험을 설계했다. Terminal-Bench에서 PortCode로 이어지는 태스크를 태스크당 다섯 번씩 반복 수행했고, 목적은 여러 솔루션 후보 중 가장 좋은 것을 골라 해당 유형에서 최상의 결과를 뽑아내는 것이었다. 결과적으로 API로 생성한 택소노미를 컨텍스트 안에 포함시켰을 때, 다중 에이전트 운용 방식 자체가 개선됐다.
이 실험을 통해 택소노미가 유용해지는 방식을 두 가지 카테고리로 나눠 정리할 수 있었다. 하나는 어휘 유도(vocabulary derivation)다. 대상 시스템 자체의 실행 흔적에서 어휘를 이끌어내는 방식인데, 세션마다 놓치기 쉽지만 사실 중요한 케이스들을 포착해준다. 다른 하나는 점근적 개선(asymptotic improvement)이다. 택소노미를 갖고 있다는 사실 자체가, 시스템을 개선하는 여러 방식—다양한 솔루션, 다양한 참가자—에 걸쳐 일관되게 도움이 됐다. 특정 솔루션 하나에만 통하는 게 아니라 일반화된다는 뜻이다.
나는 이 일관성이야말로 이번 연구에서 가장 놀라웠던 발견이라고 생각한다. 실패를 잘 분류하는 것 자체는 목적이 아니다. 그 분류가 시스템마다, 도메인마다, 심지어 시간이 지나면서도 계속 맞게 갱신될 수 있어야 진짜 쓸모가 생긴다. MAST가 우리에게 실패를 보는 눈을 처음 줬다면, ATLAS는 그 눈이 마주하는 대상이 바뀔 때마다 스스로 초점을 다시 맞추는 법을 가르쳐준 셈이다.