싱글 vs 멀티 에이전트 — 같은 자료, 반대 결론

Anthropic은 멀티 에이전트가 90.2% 향상을 만든다고 보고하고, Cognition은 'Don't Build'를 권한다. 두 진영의 1차 자료를 정면 비교해 single vs multi 의사결정 기준을 정리.

“AI 에이전트가 답이다”라는 말이 한 해 안에 두 번 정반대 방향으로 권고된 경우는 드물다. 2025년 한 해 동안 Anthropic은 멀티 에이전트 시스템이 단일 에이전트보다 내부 평가에서 90.2% 더 나은 성과를 냈다고 발표했고 (Anthropic, 2025-06), 같은 해 Cognition Labs는 “Don’t Build Multi-Agents”라는 제목의 글을 공개했다 (Cognition, 2025).

같은 1차 자료군 — Anthropic의 자체 운영 사례, OpenAI의 가이드, ReAct 계열 논문 — 을 인용하는 두 글이 정반대의 권고로 끝난다. 어느 쪽이 틀린 것이 아니라, 풀려는 문제가 다르다는 점이 핵심이다. 이 글은 두 진영의 1차 자료를 정면으로 놓고 비교한 뒤, single vs multi-agent 의사결정 기준을 정리한다.

”에이전트”라는 단어가 가리키는 것이 너무 많다

비교에 들어가기 전에 정의부터 좁힐 필요가 있다. 2024년부터 2025년까지 “agentic AI” 검색 트래픽이 600% 이상 증가하면서 (US News, 2025), 이 단어는 LLM 호출 루프부터 자율 시스템까지 너무 다양한 것을 가리키게 됐다. 같은 단어로 다른 시스템을 부르면 “멀티가 좋다 / 단일이 좋다”라는 토론 자체가 어긋난다.

Anthropic의 “Building Effective Agents” (2024-12) 가이드는 이 모호함을 다음과 같이 정리한다.

Workflow: “LLMs and tools are orchestrated through predefined code paths.” — 사전 정의된 코드 경로에서 LLM과 도구가 순차 실행됨
Agent: “systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.” — LLM이 자신의 절차와 도구 사용을 동적으로 결정함
Multi-Agent System (MAS): 다수의 LLM(또는 같은 LLM의 여러 인스턴스)이 분산된 의사결정과 위임 구조로 협업하는 시스템

세 시스템의 차이는 단지 “에이전트가 몇 개냐”가 아니라 누가 다음 행동을 결정하는가에 있다. Workflow는 코드가 결정하고, Single Agent는 LLM 하나가 결정하며, MAS는 다수 LLM이 위임·조율을 통해 결정한다.

차원	Workflow (Chain)	Single Agent	Multi-Agent System
다음 행동 결정자	사전 정의된 코드	단일 LLM	다수 LLM (위임·조율)
단계 수	고정	가변 (open-ended)	가변 + 위임 깊이
디버깅 난도	낮음	중간	높음 (non-deterministic)
토큰 비용 (chat 대비, Anthropic 측정)	1-2x	약 4x	약 15x
대표 예	Prompt chaining, Routing	ReAct loop, Claude Code	Anthropic Research System, AutoGen
적합 용도	잘 정의된 절차	open-ended 단일 작업	병렬 탐색, 도메인 분리

이 정의를 합의한 뒤에야 “Anthropic은 왜 멀티를 권하는가”와 “Cognition은 왜 멀티를 만들지 말라고 하는가”가 같은 평면에서 비교 가능해진다.

Anthropic의 90.2% — 멀티 에이전트가 답이라는 주장

2025년 6월 Anthropic은 자사 Research 기능의 백엔드 아키텍처를 공개했다 (“How we built our multi-agent research system”, Anthropic Engineering, 2025-06). 핵심 결과 한 줄이 이 글에서 가장 많이 인용되는 수치다.

“A multi-agent system with Claude Opus 4 as the lead agent and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2% on our internal research eval.” (Anthropic)

같은 글이 비용에 대해서는 다음과 같이 명시한다.

Agents (single) = chat의 약 4x 토큰
Multi-agent = chat의 약 15x 토큰
“Token usage alone explains 80% of performance variance.” — 토큰 사용량 하나가 성능 분산의 80%를 설명

90.2% 향상이라는 수치만 떼어 보면 “멀티로 가야 한다”는 결론이 자연스럽지만, 같은 글이 즉시 비용 트레이드오프를 못 박는다. 토큰 예산이 15배 늘어도 감당 가능한 task에서만 이 향상이 의미를 가진다는 뜻이다.

8가지 프롬프트 엔지니어링 원칙

Anthropic이 운영하면서 정리한 8가지 원칙은 멀티 에이전트 시스템 설계의 일종의 체크리스트로 읽을 수 있다 (Anthropic, 2025-06).

Mental modeling — 사용자의 의도 모델을 lead agent가 먼저 형성한 뒤 위임
Delegation teaching — 위임 방법을 subagent에게 명시적으로 가르침 (역할·범위·중지 조건)
Effort scaling — task 난이도에 호출 수를 맞춤. simple = 1 agent / 3-10 tool calls, complex = 10+ subagents
Tool design criticality — 도구 인터페이스가 결과 품질을 결정. 도구 자체가 잘못 설계되면 어떤 프롬프트 튜닝도 무력
Self-improvement — agent가 자기 출력물을 평가·재시도
Search strategy — broad → narrow. 처음에는 폭넓게 탐색, 이후 좁혀 들어감
Extended thinking — 복잡한 추론에는 reasoning budget 확장
Parallelization — subagents 3-5개 병렬 + 도구 호출 3개 이상 병렬 → research time을 최대 90% 단축

이 중에서 가장 운영적으로 강한 권고는 3번(Effort scaling)과 8번(Parallelization)이다. 단순 쿼리에 멀티를 던지는 것이 가장 흔한 안티패턴이라는 자기 보고가 뒤따른다.

자기 보고된 실패 모드

같은 글이 자사 운영에서 관찰한 실패 모드 4개를 명시한다 (Anthropic).

단순 쿼리에 50개 이상의 subagent를 spawn한 경우
존재하지 않는 정보를 끝없이 web search한 경우
모호한 task description으로 subagent들이 동일 작업을 중복 수행
권위 있는 출처 대신 SEO 어뷰징 사이트(content farm)를 우선 선택

이 네 가지는 모두 멀티 에이전트 구조에서 lead agent의 위임 설계가 부실할 때 나타난다. 단일 에이전트라면 발생하지 않거나 발생해도 1배 비용에 그칠 문제가, 멀티에서는 15배 비용 곱하기 발생 빈도로 폭증한다.

Anthropic의 운영 트레이드오프

자기 발표문이 인정한 운영 비용은 다음과 같다.

트레이드오프	설명
비용 폭증	chat 대비 15x 토큰. 토큰 단가 그대로 운영비로 전이
Sync bottleneck	lead agent가 모든 subagent의 결과를 동기적으로 기다림
Rainbow deployment	사소한 변경이 cascade로 행동 전체를 바꿈 → 점진 배포 필수
비결정성 디버깅	같은 입력에 다른 출력. “full production tracing”과 “high-level observability of decision patterns”가 필수
장애 cascade	”Minor failures cascade into large behavioral changes; requires durable execution and error recovery without expensive restarts.”

Anthropic 자신의 결론은 “멀티가 답이다”가 아니라 “research-style open-ended task에는 멀티가 답이지만, 그 외에는 가장 단순한 솔루션부터 출발하라”이다. 같은 회사의 “Building Effective Agents” 가이드는 이 권고를 더 강하게 명시한다.

“Find the simplest solution possible, and only increase complexity when needed… Many applications benefit most from optimizing single LLM calls with retrieval and in-context examples.” (Anthropic)

90.2%와 “start simple”이 같은 회사의 두 글에 동시에 등장한다. 모순이 아니라, task profile에 따라 답이 다르다는 신호다.

Cognition의 반론 — Don’t Build Multi-Agents

Anthropic의 발표 이후 같은 해 Cognition Labs (Devin을 만든 회사)가 정면으로 반박하는 글을 공개했다 (“Don’t Build Multi-Agents”, Cognition, 2025). 제목 그대로 멀티 에이전트를 만들지 말라는 권고이며, 권고의 근거는 두 가지 원칙으로 압축된다.

“Share context, and share full agent traces, not just individual messages.”

“Actions carry implicit decisions, and conflicting decisions carry bad results.” (Cognition)

첫 원칙은 메시지 단위가 아니라 전체 trace를 공유해야 한다는 것이고, 둘째 원칙은 모든 행동에는 암묵적 가정이 들어 있어 가정이 충돌하면 결과가 망가진다는 것이다. 이 두 원칙을 위반하면 멀티 에이전트는 깨진다는 게 Cognition의 입장이다.

Flappy Bird 사례

Cognition이 든 가장 짧고 명확한 사례가 Flappy Bird 클론 빌드다.

사용자가 “Flappy Bird를 만들어 달라”고 요청했다고 가정하자. lead agent가 두 subagent에게 작업을 나눠 위임한다.

Subagent 1: 배경(background) 생성 → Mario 스타일 파이프 풍경을 그림
Subagent 2: 새 캐릭터 생성 → Mario와 어울리지 않는 픽셀 스타일 새

각 subagent는 자기 작업만 보고 자기만의 스타일 가정을 한다. lead agent가 두 결과물을 합쳐도 두 가정이 충돌해 일관성이 깨진다. 통합 단계는 두 miscommunication을 동시에 떠안는다.

이 사례의 교훈은 단순하다. 각 subagent가 내린 “암묵적 결정”이 다른 subagent의 결정과 충돌할 가능성이 높은 task에서는 멀티 구조 자체가 문제를 만든다. Flappy Bird처럼 단일 일관성이 필요한 산출물(코드베이스, 게임, 디자인 시스템)에서 특히 두드러진다.

Cognition의 권고

원칙과 사례를 받아 Cognition이 제안하는 대안은 single-threaded linear agent다.

컨텍스트가 단일 thread에서 연속적으로 흐르는 single agent를 우선
컨텍스트가 너무 길어지면 dedicated LLM이 history를 “key details, events, and decisions”로 압축
다만 “this approach is hard to get right” — 압축 LLM 자체의 정확도가 또 다른 challenge

Cognition은 이 글의 결론에서 “멀티가 절대 안 된다”고 말하지 않는다. “현재 시점에서는 멀티의 trade-off를 감당하기 어렵고, single을 잘 만드는 것도 충분히 어렵다”는 입장에 가깝다.

두 진영의 차이는 무엇인가

같은 1차 자료군 — Anthropic Building Effective Agents, OpenAI Practical Guide, ReAct 계열 논문 — 을 인용하면서 정반대의 결론을 내리는 이유는 풀려는 task profile이 다르기 때문이다.

차원	Anthropic Research System	Cognition Devin
대표 task	open-ended web research, broad exploration	long-running coding, codebase 일관성 변경
Sub-task 간 가정 충돌	낮음 (각 subagent가 다른 source를 탐색)	높음 (각 subagent가 같은 codebase의 다른 부분을 변경)
병렬 탐색 가치	매우 높음 (research time -90%)	낮음 (병렬 변경이 conflict 생성)
결과 통합	lead agent가 source 종합	코드베이스 일관성 검증
권고	Multi-agent	Single-threaded

요약하면 두 권고 모두 task profile 위에서 옳다.

“멀티 에이전트가 좋은가?”라는 질문 자체가 잘못되었다는 게 두 글을 함께 읽은 후의 결론이다. 올바른 질문은 “내가 풀려는 task profile에서 멀티가 가치를 만드는가, conflict를 만드는가”이다.

의사결정 — Single이 적합한가, Multi가 적합한가

두 진영의 1차 자료를 합쳐 의사결정 기준을 4차원으로 정리할 수 있다.

---
config:
  look: handDrawn
  theme: neutral
---
flowchart TD
    A[Task 정의] --> B{절차가 사전 정의되어 있는가?}
    B -->|예| C[Workflow / Chain]
    B -->|아니오| D{Sub-task 간 가정 충돌 가능성?}
    D -->|높음| E[Single Agent]
    D -->|낮음| F{병렬 탐색이 가치를 만드는가?}
    F -->|아니오| E
    F -->|예| H["Multi-Agent System<br/>+ 모델 매핑 전략"]

4가지 결정 차원

차원 1 — 절차 사전 정의: 단계가 코드로 정의 가능하면 Workflow가 가장 단순하고 안전하다. 디버깅도 가능하다. 동적 의사결정이 필요한 순간부터 Agent로 넘어간다.
차원 2 — Sub-task 간 가정 충돌: 한 subagent의 결정이 다른 subagent의 결정과 충돌할 수 있는 task(코딩, 디자인, 단일 산출물)는 single이 안전하다. 충돌 가능성이 낮은 task(병렬 web research, 도메인 분리)는 multi가 가치를 만든다.
차원 3 — 병렬 탐색의 가치: 병렬화로 시간을 90% 단축할 수 있는 task인가, 순차 처리가 자연스러운 task인가. Anthropic의 research time -90% 수치는 병렬 탐색 가치가 큰 task의 상한선이다.
차원 4 — 모델 매핑 전략: lead와 subagent에 다른 모델을 매핑(예: lead=Opus, subagents=Sonnet)할 수 있는 task인가. 매핑이 가능하면 멀티의 raw token 폭증이 비용 폭증과 직결되지 않는다. 매핑이 어렵고 모든 호출이 SOTA 모델이어야 한다면, single이 비용 측면에서 더 안전하다.

비용 — Raw Token이 아니라 모델 매핑이 좌우한다

Anthropic이 보고한 “chat 대비 15x 토큰”이라는 수치는 모든 호출이 같은 모델일 때 성립한다. 실제 운영은 다르다. 같은 발표문에서 Anthropic은 자사 Multi-Agent Research System의 모델 매핑을 다음과 같이 명시한다.

Lead agent = Claude Opus 4
Subagents = Claude Sonnet 4

Lead가 의사결정·종합을 맡고, subagent는 high-volume implementation work를 맡는다. Sonnet은 Opus의 일부 가격(2026년 5월 기준 input 단가 약 5분의 1)이라, 같은 task를 single agent + Opus로 모두 처리하는 것보다 비용이 낮아질 수 있다. Production AI Gateway 패턴(Haiku → Sonnet → Opus cascade)을 적용한 사례들은 LLM 비용 40-70% 절감을 보고했다.

반대 방향의 hidden cost가 더 위험하다. Single agent를 SOTA 모델 하나로 굴리는 흔한 디폴트 — 예컨대 Claude Opus 4.7로 모든 subtask를 처리하는 패턴 — 는 simple subtask에까지 가장 비싼 모델을 쓰는 구조다. 비용 비교는 raw token이 아니라 (모델 단가) × (호출 수)로 가야 한다.

따라서 의사결정에서 “15x 토큰을 감당 가능한가”는 잘못된 질문이다. 올바른 질문은 두 가지다.

lead와 subagent에 서로 다른 모델을 매핑할 수 있는 task인가?
Single agent로 처리할 때 SOTA 모델이 정말 모든 subtask에 필요한가?

매핑이 가능하고 simple subtask 비중이 높다면, multi-agent + 모델 매핑이 single + SOTA보다 cheaper할 수 있다. 비용은 절대값이 아니라 매핑 가능성에 달려 있다.

5가지 케이스 적용

케이스	권고	근거
일관된 codebase 변경 (Devin)	Single	Cognition 사례. Sub-task 가정 충돌 높음
Web research, broad exploration	Multi	Anthropic 사례. 병렬 탐색 가치 큼
회계 전표 처리 (정해진 SOP)	Workflow	절차 사전 정의. Agent 불필요
단일 도메인 RAG 챗봇	Single	단일 task, 도메인 분리 불필요
CRM + 결제 + 분석 통합 워크플로	Multi	도메인·권한 분리. 각 도메인이 다른 가정으로 작동

Anthropic이 인정한 운영 룰: Effort Scaling

의사결정 트리 다음으로 적용할 룰은 Anthropic의 effort scaling이다. 같은 multi-agent 구조 안에서도 task 난이도에 호출 수를 맞춰야 한다.

Simple task: 1 agent / 3-10 tool calls
Medium task: lead agent + 2-3 subagents
Complex task: lead agent + 10+ subagents

이 룰을 무시하고 “멀티니까 모든 task에 10+ subagents”로 가는 게 Anthropic이 자기 보고한 첫 번째 실패 모드다 — 단순 쿼리에 50+ subagent를 spawn한 경우.

두 진영이 동의하는 한 가지

권고는 정반대지만 한 지점에서는 두 진영이 동의한다. start simple.

Anthropic Building Effective Agents: “find the simplest solution possible, and only increase complexity when needed.”
OpenAI Practical Guide (관련 자료): “maximize a single agent’s capabilities first… use orchestration patterns that match your complexity level, starting with a single agent.”
Cognition Don’t Build Multi-Agents: “Single-threaded linear agents where the context is continuous.”

세 글이 다른 결론을 말하지만, 출발점은 같다. 단일 에이전트로 풀 수 있는 task에 멀티를 쓰지 말 것. 멀티가 필요한 시점은 (a) 병렬 탐색의 가치가 명확하고, (b) sub-task 간 가정 충돌이 낮으며, (c) 15x 비용을 감당 가능한 task에 한정된다.

이 세 조건이 모두 충족될 때만 멀티 에이전트는 90.2%를 만들고, 한 조건이라도 빠지면 같은 멀티 구조가 conflict와 비용 폭증을 만든다.

다음 영역

이 글은 single vs multi 의사결정에 한정했다. 같은 결정 단계와 인접한 큰 영역 두 가지는 별도 주제로 남는다.

Multi-Agent Workflow 패턴과 예시 — Supervisor / Sequential / Hierarchical / Swarm / Map-Reduce / Group Chat 등 토폴로지·코디네이션 조합. 본 글의 비교가 dynamic delegation 사례(Anthropic Research)에 집중했다면, 이 영역은 사전 정의된 흐름 안에서 여러 에이전트를 배치하는 hybrid 구조 전반이다.
멀티 에이전트를 어떻게 평가하는가 — 비결정적 시스템의 evaluation 방법론. LLM-as-judge, human eval, benchmark의 한계 (UC Berkeley CRDI는 2026-04에 SWE-bench·GAIA·AgentBench 등이 reward hacking에 취약하다고 보고)

이 두 영역은 각각이 별도의 큰 글이며, 본 글의 의사결정 단계를 통과한 팀에게만 의미가 있다. 이번 글의 범위는 그 결정 자체에 한정한다.

Sources

How we built our multi-agent research system (Anthropic Engineering, 2025-06) — 90.2% 성능 향상, 15x 토큰, 8가지 원칙, 자기 보고된 실패 모드
Building effective agents (Anthropic Engineering, 2024-12) — Workflow vs Agent 정의, “start simple” 권고, 6가지 패턴
Don’t Build Multi-Agents (Cognition Labs, 2025) — 두 원칙(share context, conflicting decisions), Flappy Bird 사례, single-threaded 권고
A Practical Guide to Building Agents (OpenAI, 2025) — single agent first, when to split
What does ‘agentic’ AI mean? (US News, 2025-11) — agentic 검색 트래픽 600% 증가
How We Broke Top AI Agent Benchmarks (UC Berkeley CRDI, 2026-04-12) — 벤치마크 reward hacking 경고