“More Agents Is All You Need”였는데, 정말 그랬을까
에이전트 연구 커뮤니티에서 “더 많으면 더 좋다”는 통념이 있다. 에이전트 수를 늘리면 병렬 탐색이 가능해지고, 검증이 겹치고, 오류가 상쇄된다고 믿었다. 이 주장을 뒷받침하는 스케일링 법칙과 ‘협업적 스케일링(collaborative scaling)‘이라는 개념이 등장했다.
그런데 동시에, 단일 강력 모델이 멀티에이전트 시스템과 맞먹거나 더 낫다는 반례도 꾸준히 보고되어 왔다. 문제는 이 비교들이 프롬프트·도구·컴퓨트 예산이 서로 달라서 깨끗한 비교가 아니었다는 점이다.
Nature Machine Intelligence에 게재된 이 논문은, 처음으로 통제된 조건 하에서 이 질문에 정량적으로 답한다.
실험 설계: 260개 구성의 통제 실험
연구진이 설계한 실험 프레임워크의 핵심은 **“아키텍처만 바꾸고 나머지는 모두 통제”**이다.
- 동일한 프롬프트, 동일한 도구 API, 동일한 컴퓨트 예산을 5가지 아키텍처에 적용
- 5개 아키텍처: 단일 에이전트(SAS), 독립형(independent), 중앙집중형(centralized), 분산형(decentralized), 하이브리드(hybrid)
- 3개 LLM 패밀리: OpenAI, Google, Anthropic — 각각 다른 역량 티어
- 6개 에이전틱 벤치마크: BrowseComp-Plus, Finance Agent, PlanCraft, WorkBench, SWE-bench Verified, Terminal-Bench

Fig. 1 | 3개 LLM 패밀리, 5개 아키텍처를 가로지른 평균 성능. 단일 에이전트(SAS)가 기준이 되며, 멀티에이전트 변형들은 각각 다른 스케일링 양상을 보인다.
총 260개의 구성을 실행했으며, 모든 시스템에 동일한 reasoning-token 예산(평균 약 4,800 토큰)을 할당했다. 멀티에이전트는 이 예산을 여러 에이전트에 분배하고, 단일 에이전트는 전체를 하나의 추론 궤적에 쓴다. 이 설계가 핵심이다: 계산량을 같게 하고 구조만 다르게 했다.
핵심 발견: 45% 능력 포화 임계점
논문의 가장 중요한 결론을 한 줄로 요약하면:
단일 에이전트 기준 성능이 약 45%를 넘으면, 에이전트를 추가하는 것은 성능을 올리지 않고 오히려 깎아먹는다.
이 임계점은 ‘능력 포화(capability saturation)‘로 명명되었다. 직관적이다: 단일 모델이 이미 충분히 잘하면, 여러 에이전트가 가져다주는 다양성의 이익보다 조정 오버헤드·정보 손실·오류 전파의 비용이 더 커진다.
검증 결과도 강력하다. SWE-bench Verified와 Terminal-Bench에서 이 규칙이 멀티에이전트 효과의 부호(+/-)를 94% 정확도로 예측했다.
벤치마크별 양상은 완전히 다르다

Fig. 2 | 벤치마크별 멀티에이전트 성능 편차. Finance Agent에서는 최대 +80.8% 향상, PlanCraft에서는 최대 -70.0% 하락. 같은 아키텍처도 도메인에 따라 결과가 완전히 달라진다.
| 벤치마크 | 최고 MAS 효과 | 최악 MAS 효과 | 해석 |
|---|---|---|---|
| Finance Agent | +80.8% (centralized) | +57% (independent) | 분해 가능한 분석 작업에서 협업이 빛난다 |
| BrowseComp-Plus | +9.2% (decentralized) | -35% (independent) | 동적 웹 탐색은 조정 비용이 크다 |
| WorkBench | +6.0% (decentralized) | -11% | 도구가 단순하면 조정 이득이 미미 |
| Terminal-Bench | +6.0% (independent) | -20% (centralized) | 도구가 2개뿐이라 중재가 의미 없다 |
| SWE-bench Verified | -1.3% (hybrid) | -12.8% (independent) | 단일 에이전트 베이스라인이 이미 높다 |
| PlanCraft | -39.1% (hybrid) | -70.0% (independent) | 순차 계획 작업에서 협업은 재앙 |
핵심 통찰: 복잡도가 아니라 ‘작업 분해 가능성(task decomposability)‘이 결정한다. PlanCraft처럼 순차적 의존성이 강한 작업은 에이전트를 나눌수록 조정 메시지가 쌓이고 토큰이 낭비된다. 반면 Finance Agent처럼 수익·비용·시장 요인이 독립적으로 분석 가능하면 병렬 에이전트가 시너지를 낸다.
왜 실패하는가: 오류 증폭과 조정 세금
논문은 단순히 “때로는 안 된다”가 아니라 왜 안 되는지를 실행 궤적(trace) 수준에서 분해한다.
1. 오류 증폭 계수 (Error Amplification)
아키텍처별 트레이스 수준 오류 증폭 계수(A_e^trace)를 측정했다:
| 아키텍처 | 오류 증폭 계수 |
|---|---|
| SAS (단일) | 1.0 (기준) |
| Centralized | 4.4× |
| Hybrid | 5.1× |
| Decentralized | 7.8× |
| Independent | 17.2× |
독립형이 가장 나쁘다. 검증 메커니즘이 없기 때문에 오류가 그대로 누적된다. 중앙집중형이 그나마 낫지만, 여전히 단일 에이전트의 4.4배 오류율을 감수해야 한다.
2. 조정 오버헤드
에이전트 수가 늘어날수록 추론 턴(turn) 수가 멱법칙(power law)으로 증가한다:
- SAS 기준 7.2턴
- 에이전트 6명 → 약 69턴 예측 (9.5배)
- 에이전트 10명 → 약 157턴 예측 (21.8배)
이 오버헤드는 단순히 ‘더 많이 계산한다’가 아니다. 에이전트 간 메시지가 쌓이면서 토큰 예산이 추론이 아닌 조정 통신에 소모된다.
3. 정보 파편화 (Information Fragmentation)
단일 에이전트는 모든 추론 단계가 하나의 메모리 스트림에 공유된다. 멀티에이전트는 글로벌 컨텍스트를 에이전트 간 메시지로 압축해야 하는데, 이 압축이 손실이 심하다. PlanCraft에서 이 효과가 극명하다: 레시피 검색→재고 확인→제작이라는 3단계가 순차적인데, 에이전트 3명에게 나누면 2명은 불필요한 중복 작업을 하고 조정 메시지만 양산한다.
예측 모델: R² = 0.373으로 아키텍처 선택
이 260개 구성의 데이터로 선형 회귀 예측 모델을 만들었다. 4가지 예측 변수 카테고리:
- 기본 모델 역량 (intelligence index I)
- 시스템 구성 (에이전트 수 n_a)
- 작업 속성 (도구 수 T, 단일 에이전트 베이스라인 P_SA)
- 실측 조정 메트릭 (효율성 E_c, 오버헤드 O%, 오류 증폭 A_e, 메시지 밀도 c, 중복도 R)

Fig. 3 | Gemini-2.0 Flash와 2.5 Pro에서 에이전트 수를 1~9로 변화시키며 측정한 성능. Flash는 7명에서 최적점을 찍고 하락하지만, Pro는 더 일찍 성능이 포화된다.
교차 검증 결과 R² = 0.373 (task-grounded ACI를 쓰면 0.413). 절대적 예측력은 완벽과 거리가 멀지만, **같은 도메인 내에서 최적 아키텍처를 고르는 정확도는 87%**에 달한다. 무작위 선택(20%)이나 역량만으로 선택(54%)보다 훨씬 낫다.
유일하게 강건한 예측 변수
정 통계 검정(클러스터 로버스트 + Holm–Bonferroni 보정)을 통과한 변수는 단일 에이전트 베이스라인 하나뿐이다:
- P_robust = 0.004 (클러스터 로버스트)
- P_Holm = 0.018 (다중 비교 보정)
즉, “이 작업을 단일 에이전트가 얼마나 잘 풀 수 있는가”가 멀티에이전트 필요성의 가장 강력한 예측 변수라는 뜻이다.
아키텍처 선택 실무 가이드
논문의 의사결정 모델을 실무적으로 풀면:
| 상황 | 추천 아키텍처 | 근거 |
|---|---|---|
| 단일 에이전트 베이스라인 > 45% | SAS | 능력 포화. 조정은 순비용 |
| 분해 가능한 분석 작업 (T 중간, P_SA 낮음) | Centralized MAS | 병렬 분석 + 중앙 통합이 유효 |
| 도구가 많은 환경 (T ≥ 8) | Decentralized MAS | 병렬화 이득 > 오버헤드 |
| 순차적 계획 작업 | SAS | 조정 오버헤드가 압도적 |
| 도구가 2~3개인 단순 환경 | SAS | 중재 구조가 의미 없음 |
모델 패밀리별 차이
재미있게도, 벤더마다 멀티에이전트에서의 강점이 다르다:
- Anthropic: Finance Agent에서 centralized +127.5% (가장 안정적). WorkBench에서 decentralized +10.8%로 최고 효율
- Google: Finance Agent에서 centralized +164.3% (최대 폭발). 계층적 메시지 교환에 상대적 우위
- OpenAI: Finance Agent에서 centralized +69.9%. 높은 베이스라인(0.465)이 조정 이득의 여지를 제한
하지만 어떤 패밀리도 모든 벤치마크에서 일관되게 최고인 경우는 없었다. 벤더 선택이 도메인 특화된 조정 패턴에 영향을 미치지만, 근본적인 한계(45% 임계점, 순차 작업에서의 조정 비용)는 공통적이다.
비용 문제: 토큰 기반 조정의 근본적 한계
논문은 현재의 멀티에이전트 조정이 자연어 토큰 직렬화에 의존한다는 근본적 한계를 지적한다. 에이전트가 자신의 추론을 텍스트로 인코딩하고 다른 에이전트가 이를 읽고 해석하는 구조에서는, 통신 비용에 명백한 하한선이 존재한다.
미래 방향으로 제시되는 대안:
- 잠재 공간 추론(latent-space reasoning): 에이전트가 토큰이 아닌 표현 벡터를 직접 공유
- 활성화 공유(activation sharing): 모델 간 직접적인 표현 전송
- 희소 통신(sparse communication): 필요할 때만 메시지 교환
- 조기 종료(early exit): 합의에 도달하면 즉시 중단
- 蒸류된 조정자(distilled coordinator): 가벼운 모델로 중재
한계와 외삽의 위험
논문은 정직하게 한계를 명시한다:
- 6개 벤치마크만: 더 다양한 환경(로봇, 멀티모달, 장기 시간 의존성)에서 검증 필요
- G=6 클러스터: 통계적 검정력의 한계로 인해 여러 예측 변수가 방향성은 일관되지만 유의수준을 통과하지 못함
- 테스트된 모델 범위 내에서만: 더 강력한 미래 모델에서 이 패턴이 어떻게 변할지 미지수
- 토큰 기반 조정만 테스트: 다른 통신 패러다임에서는 결과가 다를 수 있음
왜 이 논문이 중요한가
이 연구의 가장 큰 기여는 “멀티에이전트가 좋다/나쁘다”의 논쟁에 종지부를 찍고, **“어떤 조건에서, 얼마나, 왜”**를 정량화했다는 점이다.
에이전트 시스템을 설계하는 실무자에게 이 논문은 명확한 행동 지침을 준다:
- 먼저 단일 에이전트로 베이스라인을 잡아라
- 베이스라인이 45%를 넘으면 멀티에이전트를 의심해라
- 작업이 자연스럽게 분해되는지 확인해라
- 도구가 많고 단일 에이전트가 처리하기 벅찰 때만 멀티에이전트를 도입해라
“More agents is all you need”는 좋은 슬로건이었지만, **“모델이 충분히 똑똑하면 에이전트를 추가할 필요가 없어진다”**가 더 정확한 진실에 가깝다.
더 실습해보고 싶은 분들께
에이전트 아키텍처 설계와 하네스 구축을 직접 실험해보고 싶다면, 다음 두 자료를 추천한다:
- 『이게 되네? 오픈클로 미친 활용법 50제』 — 에이전트 하네스를 실제로 구성하고 활용하는 50가지 패턴
- 「모두를 위한 루프 엔지니어링」 — 에이전트 루프 설계와 최적화의 실전 가이드
참고문헌: Kim, Y., Gu, K., Park, C. et al. “Capable language models can outgrow the benefits of collaboration.” Nature Machine Intelligence (2026). DOI: 10.1038/s42256-026-01268-y