단일 에이전트로 해결되지 않으면 작업을 여러 에이전트에게 나눠 맡기는 것이 요즘 흔한 대응입니다. 그런데 멀티 에이전트 실행 기록 1,642건을 분류한 연구에서, 가장 흔한 실패는 에이전트끼리 어긋나는 것이 아니었습니다. 같은 단계를 반복하는 것(15.7%)과 종료 조건을 판단하지 못하는 것(12.4%)이 1·3위였고, 에이전트 사이의 문제로 분류된 실패는 전체의 3분의 1이 채 되지 않았습니다.
멀티 에이전트 시스템은 하나의 작업을 여러 개의 에이전트가 역할을 나눠 처리하는 구조입니다. 기획자·구현자·검토자로 나누는 식입니다. 나누면 각자가 좁은 일에 집중하니 결과가 좋아질 것 같지만, 측정해 보면 그 기대만큼 나오지 않는 경우가 많습니다.
Cemri 등의 논문(arXiv:2503.13657)은 첫 문장부터 이렇게 시작합니다 — “멀티 에이전트 시스템에 대한 열의에도 불구하고, 널리 쓰이는 벤치마크에서의 성능 향상은 대체로 미미하다.” 논문은 그 이유를 밝히려고 실패를 분류했습니다.
반대 사례도 있습니다. Anthropic은 자사 리서치 시스템에서 “Claude Opus 4를 총괄로 두고 Claude Sonnet 4를 하위 에이전트로 쓴 멀티 에이전트 구성이 단일 Claude Opus 4보다 내부 리서치 평가에서 90.2% 더 나았다”고 공개했습니다. 다만 개발사가 자체 내부 평가에서 낸 수치이고, 같은 글에 그 대가도 함께 적혀 있습니다.
병렬로 쪼갤 수 있는 조사 작업에서 내부 평가 기준 90.2% 향상. 하위 에이전트가 각자 다른 갈래를 동시에 탐색합니다.
출처: Anthropic 공개 글(개발사 자체 평가).
같은 글에서 “에이전트는 채팅보다 약 4배, 멀티 에이전트는 채팅보다 약 15배 많은 토큰을 쓴다”고 밝혔습니다. 토큰은 모델이 글을 처리하고 요금을 매기는 기본 단위입니다.
함의: 작업 하나의 가치가 그 비용을 넘어야 성립합니다.
만드는 단계와 세는 단계가 다릅니다. 유형 체계는 사람이 만들었습니다 — 프레임워크 5종에서 모은 기록 150건을 전문가 6명이 분석했고, 세 차례의 일치도 조사에서 카파 0.88이 나왔습니다(회차마다 3명이 무작위 5건을 각자 분류). 카파는 우연히 같은 답이 나올 가능성을 걷어낸 뒤의 일치도이고, 0.8을 넘으면 대체로 높다고 봅니다. 반면 아래 비율을 낸 1,642건은 사람이 아니라 LLM 분류기(o1 기반)가 분류했습니다. 사람과의 일치도는 카파 0.77이고, 학습에 쓰이지 않은 다른 프레임워크에서는 0.79였습니다.
| 범주 | ID | 실패 유형 | 비중 |
|---|---|---|---|
| 설계 문제 FC1 · 합계 44.2% | FM-1.1 | 작업 명세를 지키지 않음 | 11.8% |
| FM-1.2 | 지정된 역할을 따르지 않음 | 1.5% | |
| FM-1.3 | 같은 단계를 반복함 | 15.7% | |
| FM-1.4 | 대화 기록을 잃어버림 | 2.8% | |
| FM-1.5 | 종료 조건을 판단하지 못함 | 12.4% | |
| 에이전트 간 어긋남 FC2 · 합계 32.35% | FM-2.1 | 에이전트 사이 대화 내용이 초기화됨 | 2.2% |
| FM-2.2 | 지시가 모호해도 확인 질문을 하지 않음 | 6.8% | |
| FM-2.3 | 작업이 원래 목표에서 벗어남 | 7.4% | |
| FM-2.4 | 필요한 정보를 다른 에이전트에게 전달하지 않음 | 0.85% | |
| FM-2.5 | 다른 에이전트의 입력을 무시함 | 1.9% | |
| FM-2.6 | 밝힌 계획과 다르게 실행함 | 13.2% | |
| 검증 실패 FC3 · 합계 23.5% | FM-3.1 | 끝나기 전에 멈춤 | 6.2% |
| FM-3.2 | 검증이 없거나 불완전함 | 8.2% | |
| FM-3.3 | 검증을 잘못 수행함 | 9.1% |
출처 · arXiv:2503.13657 본문 원문 확인(PDF 텍스트에서 14개 값 전부 대조). 유형별 비율은 논문에 그대로 있는 값이고, 범주 합계는 그 값들을 더한 것입니다(논문이 합계를 따로 적지는 않습니다). 반올림 때문에 합이 100.05%가 됩니다.
멀티 에이전트를 도입하면 “에이전트끼리 손발이 안 맞는 것”이 가장 큰 문제일 것 같습니다. 그런데 에이전트 사이의 어긋남으로 분류된 실패의 비중은 32.35%입니다. 나머지 67.7%는 설계 문제이거나 검증 실패입니다.
비중이 큰 네 유형을 보면 성격이 더 분명해집니다.
| 유형 | 비중 | 한 에이전트에서도 날 수 있는가 (이 글의 추론) |
|---|---|---|
| 같은 단계를 반복함 | 15.7% | 가능. 진행 상태를 스스로 못 읽는 문제로 보입니다 |
| 밝힌 계획과 다르게 실행함 | 13.2% | 가능. 추론과 도구 호출이 어긋나는 문제로 보입니다 |
| 종료 조건을 판단하지 못함 | 12.4% | 가능. 종료 조건이 없거나 모호한 문제로 보입니다 |
| 작업 명세를 지키지 않음 | 11.8% | 가능. 지시가 불충분한 문제로 보입니다 |
논문 자체도 “확인된 실패들은 더 정교한 해법을 요구한다”고 적으며, 프롬프트를 다듬는 것만으로는 해결하기 어려운 격차가 있다고 봤습니다.
두 자료를 합치면 판단 기준이 나옵니다. 아래는 이 글에서 정리한 기준이고, 논문이나 개발사 문서가 표 형태로 제시한 것은 아닙니다.
| 확인할 것 | 나눠도 좋은 쪽 | 나누지 않는 편이 나은 쪽 |
|---|---|---|
| 작업 구조 | 갈래가 서로 독립적이라 동시에 진행할 수 있음 | 앞 단계 결과가 다음 단계 입력이라 줄줄이 이어짐 |
| 맥락 크기 | 다뤄야 할 정보가 한 컨텍스트에 안 들어감 | 한 컨텍스트로 충분함 |
| 도구 복잡도 | 복잡한 도구를 여럿 다뤄야 함 | 도구가 적고 단순함 |
| 맥락 공유 | 각 갈래가 자기 맥락만 알아도 됨 | 모두가 같은 맥락을 계속 알고 있어야 함 |
| 비용 여력 | 결과 하나의 가치가 토큰 여러 배를 감당함 | 단가 민감. 채팅 대비 15배가 부담됨 |
| 지금의 실패 유형 | 탐색 범위가 좁아서 놓치는 것이 문제 | 반복·정지 조건·명세 위반이 문제 |
| 예시 | 여러 출처를 동시에 훑는 조사 | 대부분의 코딩 작업(개발사가 직접 언급) |
아래 비중은 어디를 먼저 볼지를 알려 줄 뿐, 무엇을 해야 하는지까지 정해 주지는 않습니다. 관측된 실패의 분포이지 점검 규칙이 아닙니다. 2번 이하는 그 분포를 보고 고른 일반적인 대응입니다.
| # | 할 일 | 확인 방법 |
|---|---|---|
| 1 | 최근 실패한 실행 20건을 꺼내 14가지 유형으로 분류한다 | 어느 범주에 몰리는지. 표를 그대로 체크리스트로 쓰면 됩니다 |
| 2 | 종료 조건을 명시적으로 적는다 | “무엇이 되면 끝”이 지시문에 문장으로 있는지. 관측된 실패의 12.4%가 정지 조건 유형이었습니다 |
| 3 | 진행 상태를 에이전트가 읽을 수 있게 남긴다 | 이미 한 단계를 다시 하지 않으려면 무엇을 했는지 스스로 확인할 수 있어야 합니다 |
| 4 | 하겠다고 밝힌 것과 실제로 실행한 것을 나란히 기록한다 | 밝힌 계획과 다르게 실행한 유형이 13.2%였습니다. 둘을 나란히 보지 않으면 애초에 눈에 띄지 않습니다 |
| 5 | 검증 단계를 따로 만든다 | 검증이 없거나 불완전한 경우 8.2%, 검증 자체가 틀린 경우 9.1%입니다 |
| 6 | 모호할 때 되묻게 한다 | 되묻지 않고 진행한 유형이 6.8%였습니다. 어떤 경우에 되물을지를 지시문에 적으세요 |
| 7 | 나누기 전후의 토큰을 같은 표에서 비교한다 | 채팅 대비 15배라는 개발사 집계가 우리 워크로드에서도 비슷한지 |
| 자료 | 이 글에서 쓴 내용 | 링크 |
|---|---|---|
| Cemri 외, Why Do Multi-Agent LLM Systems Fail? (arXiv:2503.13657) | 유형 14가지와 각 비율(1,642건, LLM 분류기), 사람이 만든 체계(5종·150건·전문가 6명·카파 0.88), 사람-LLM 일치도 0.77, “성능 향상은 대체로 미미하다”. 초록·본문·방법론 원문 확인 | arxiv.org/abs/2503.13657 |
| Anthropic — How we built our multi-agent research system | 내부 평가 90.2% 향상, 토큰 4배·15배, 맥락 공유가 필요한 영역과 코딩 작업에 대한 유보. 개발사 자체 집계 | anthropic.com/engineering/multi-agent-research-system |
수치는 위 두 자료에서 직접 확인했습니다. 널리 도는 42/37/21 범주 비율은 원문과 맞지 않아 쓰지 않았습니다. 멀티 에이전트 프레임워크는 빠르게 바뀌므로, 도입 판단 전에 쓰시는 도구의 최신 문서를 함께 보세요.