《Towards a Science of Scaling Agent Systems》 핵심만 남긴 정리

멀티에이전트는 언제 강하고 언제 약한가

한 줄 요약
이 논문은 “에이전트를 더 많이 붙이면 성능이 좋아진다”는 통념을 반박한다.
실제 성능은 에이전트 수보다 태스크 구조, coordination 방식, tool 사용량, single-agent baseline에 의해 결정된다.

이 논문이 답한 질문

최근 에이전트 시스템 논의는 종종 “SAS보다 MAS가 더 강하다”는 전제를 깔고 간다. 하지만 이 논문은 질문 자체를 바꾼다. 중요한 것은 멀티에이전트가 좋은가가 아니라, 어떤 문제에서 어떤 coordination 구조가 맞는가이다.

저자들은 이를 보기 위해 4개 agentic benchmark, 5개 아키텍처(SAS, Independent, Centralized, Decentralized, Hybrid), 3개 LLM family를 조합해 총 180개 통제 실험을 수행했다. 같은 도구, 같은 프롬프트 구조, 같은 토큰 예산을 유지해 아키텍처 자체의 효과를 최대한 분리했다.

또한 이 논문은 agentic task를 엄격하게 정의한다. 단발성 정답 맞히기 문제가 아니라, 외부 환경과의 지속적 상호작용, 부분 관측 상태에서의 정보 수집, 피드백에 따른 전략 수정이 필요한 과제만 진짜 agentic evaluation으로 본다.

숫자로 먼저 보는 핵심

• 180개 통제 실험으로 아키텍처 효과를 비교했다.
• 성능 예측 모델은 cross-validated R² = 0.524를 기록했다.
• held-out 설정에서 최적 architecture 선택 정확도 87%를 보였다.
• Finance Agent에서는 Centralized MAS가 +80.8% 개선됐다.
• BrowseComp-Plus에서는 Decentralized MAS가 +9.2%로 가장 좋았다.
• PlanCraft에서는 모든 MAS가 악화됐고, Independent MAS는 -70.1%까지 떨어졌다.
• single-agent baseline이 대략 45%를 넘으면 MAS 이익이 줄어드는 capability ceiling이 나타났다.
• 오류 증폭은 Independent 17.2배, Centralized 4.4배로 차이가 컸다.

---

핵심 포인트 6가지

1. 멀티에이전트는 기본값이 아니다

이 논문의 가장 중요한 메시지는 단순하다. 멀티에이전트는 자동으로 이득을 주지 않는다.
전체 평균으로 보면 MAS의 개선폭은 -3.5%였고, 성능 분산은 매우 컸다. 즉 “에이전트를 더 붙이면 대체로 낫다”는 식의 일반론은 성립하지 않는다. 이 논문은 멀티에이전트를 만능 해법이 아니라 조건부 설계 선택지로 다룬다.

2. 성능을 결정하는 것은 agent 수보다 task-architecture fit이다

같은 멀티에이전트라도 어떤 문제를 푸느냐에 따라 결과가 완전히 달라진다.

• Finance Agent처럼 병렬 분해가 가능한 분석형 과제에서는 Centralized MAS가 +80.8% 개선됐다.
• BrowseComp-Plus처럼 동적으로 웹을 탐색해야 하는 과제에서는 Decentralized MAS가 +9.2%로 가장 유리했다.
• PlanCraft처럼 순차 제약이 강한 planning task에서는 모든 MAS가 -39%~-70% 범위로 악화됐다.

즉, 중요한 질문은 “몇 명의 에이전트를 둘까?”가 아니라, 이 태스크가 병렬 분해 가능한가, 아니면 하나의 연속된 상태 추적이 더 중요한가이다.

3. tool이 많아질수록 coordination tax가 커진다

논문은 이를 tool-coordination trade-off라고 부른다. 도구가 많은 환경에서는 agent 간 메시지 교환, 역할 분담, 상태 동기화가 늘어나고, 그만큼 실제 추론에 쓸 토큰과 집중력이 줄어든다. 이 효과는 모델에서 β = -0.267로 나타난다.

쉽게 말하면, 도구를 많이 써야 하는 복잡한 작업일수록 팀을 쪼개는 것이 오히려 비싸질 수 있다. “분업”의 이익보다 “조정”의 비용이 더 빨리 커지는 셈이다.

4. single-agent baseline이 높으면 MAS의 추가 이익은 빠르게 줄어든다

논문은 capability ceiling도 제시한다.
이미 single-agent baseline이 꽤 높은 문제라면, 추가 에이전트가 만들어내는 개선 여지가 크지 않다. 논문은 이 경계가 대략 45% 부근에서 나타난다고 보고하며, 관련 효과는 β = -0.404로 제시된다.

실무적으로는 명확하다. 단일 에이전트가 이미 꽤 잘하는 업무라면, 멀티에이전트는 “성능 향상 수단”보다 “비용 증가 장치”가 될 가능성이 높다.

5. topology는 단순한 연결 구조가 아니라 에러 제어 장치다

이 논문에서 topology는 미적인 설계 선택이 아니다. 오류가 어떻게 증폭되고 어떻게 차단되는지를 결정하는 운영 메커니즘이다.

• Independent는 병렬성은 높지만 교정 메커니즘이 약해 오류를 17.2배까지 증폭시켰다.
• Centralized는 오케스트레이터가 병목이 되지만, 대신 검증 지점이 생겨 4.4배 수준으로 오류를 억제했다.
• Hybrid는 유연해 보이지만, 경우에 따라 오히려 프로토콜 복잡성이 커질 수 있다.

결국 topology는 “누가 누구와 말하느냐”의 문제가 아니라, 누가 틀린 판단을 마지막 출력으로 흘려보내지 않게 막아주느냐의 문제다.

6. 에이전트 수는 많을수록 좋은 것이 아니다

이 논문은 optimal team size가 존재한다는 점도 보여준다. 초기에는 agent 수가 늘면서 이득이 생기지만, 어느 지점을 넘으면 coordination overhead가 parallelization 이익을 잡아먹는다.

Figure 5에서 Gemini-2.0 Flash는 7개 부근까지 늘릴 때 이득이 보이지만, Gemini-2.5 Pro는 더 이른 지점에서 포화 또는 하락을 보인다. 즉, 멀티에이전트 설계에서 중요한 것은 “최대한 많이 붙이기”가 아니라 어디까지 늘리는 것이 최적인지 찾는 것이다.

---

Figure로 보는 핵심 메시지

Figure 1. 모델이 강해져도 멀티에이전트 효과는 자동으로 생기지 않는다

 

이 그림은 모델 capability가 올라가더라도 MAS의 성능 향상이 자동으로 보장되지 않는다는 점을 보여준다. OpenAI와 Google 계열에서는 best MAS가 SAS보다 각각 +8.7%, +8.1% 개선됐지만, Anthropic 계열에서는 -4.6%로 악화됐다. 핵심은 더 좋은 모델 + 더 많은 agent가 아니라, 더 좋은 모델 + 맞는 coordination 구조라는 점이다.

출처: 원문 Figure 1

Figure 2. 태스크가 바뀌면 최적 아키텍처도 바뀐다

이 그림이 사실상 논문의 핵심 결론을 가장 선명하게 보여준다.

• Finance Agent: Centralized가 가장 강하다.
• BrowseComp-Plus: Decentralized가 상대적으로 낫다.
• PlanCraft: SAS가 가장 낫고, MAS는 전반적으로 크게 손해 본다.
• Workbench: Decentralized가 소폭 우세하지만, 이득은 제한적이다.

즉, 문제의 구조가 architecture를 결정한다.
병렬 정보 수집이 중요한가, 순차 상태 추적이 중요한가, 도구가 많은가, 이미 baseline이 높은가가 먼저다.

출처: 원문 Figure 2

Figure 3. 성능만 볼 것이 아니라 비용도 같이 봐야 한다

이 그림은 멀티에이전트 논의에서 빠지기 쉬운 포인트를 짚는다. 좋은 아키텍처는 단순히 정확도가 높은 구조가 아니라, 비용 대비 성능이 납득되는 구조여야 한다.

OpenAI 계열에서는 Centralized/Hybrid가 비용을 더 쓰더라도 일정한 이득을 보이는 반면, Google 계열은 비교적 빨리 효율 plateau에 도달한다. Anthropic 계열은 편차가 더 크고 coordination overhead에 민감한 모습이 나타난다.
즉, 멀티에이전트 설계는 모델 capability뿐 아니라 경제성까지 같이 봐야 한다.

출처: 원문 Figure 3

Figure 5. 적정 agent 수는 모델과 구조에 따라 달라진다

이 그림은 “agent 수를 늘리면 계속 좋아진다”는 기대를 깨준다. Gemini-2.0 Flash에서는 7개 부근까지 이득이 보이지만 이후 꺾이고, Gemini-2.5 Pro에서는 더 이른 지점에서 포화 또는 하락이 나타난다.
즉, 최적 agent 수는 모델 능력과 coordination 방식에 따라 다르며, 일정 지점 이후에는 coordination overhead가 병렬화 이익을 넘어서게 된다.

출처: 원문 Figure 5

---

실무에서 바로 가져갈 포인트

• 분석형 리서치 업무처럼 병렬 분해가 가능한 과제라면, 우선 Centralized MAS를 검토할 만하다.
• 웹 탐색처럼 여러 경로를 동시에 시도하고 상호 검증해야 하는 과제라면, Decentralized MAS가 더 잘 맞을 수 있다.
• 순차 계획, 상태 의존적 실행, 짧고 엄격한 액션 체인이 중요한 과제라면, SAS를 기본값으로 두는 편이 안전하다.
• tool 수가 많거나 single-agent baseline이 이미 높은 업무라면, agent 수를 늘리기 전에 coordination cost부터 계산해야 한다.
• Independent MAS는 “가벼운 앙상블”처럼 보이지만, 교정 장치가 약해 오류 전파에 취약할 수 있다.
• Hybrid는 항상 상위 호환이 아니다. 구조를 섞을수록 좋아지는 것이 아니라, 프로토콜 복잡성이 먼저 폭증할 수 있다.

---

이 논문을 읽을 때 같이 봐야 할 한계

이 논문은 매우 잘 통제된 실험이지만, 어디까지나 4개 벤치마크와 고정된 토큰 예산 안에서 얻은 결과다. 따라서 모든 agent 시스템에 기계적으로 일반화할 수는 없다. 다만 저자들은 GPT-5.2에 대한 held-out 검증에서 MAE 0.071을 보고했고, 핵심 질적 발견 5개 중 4개가 유지된다고 설명한다. 그래서 이 논문의 가치는 “절대 법칙 제시”보다는, 멀티에이전트 설계를 감이 아니라 측정 가능한 변수로 보게 만들었다는 데 있다.

---

블로그용 마무리 문단

이 논문의 메시지는 명확하다. 멀티에이전트의 성패를 가르는 것은 agent 수 자체가 아니라, 태스크가 병렬 분해 가능한지, coordination overhead를 감당할 수 있는지, baseline이 이미 높은지, 오류를 누가 검증하는지다. 결국 좋은 agent system은 “더 큰 팀”에서 나오지 않는다. 더 맞는 구조에서 나온다. 앞으로 agent 설계의 출발점은 “몇 명을 둘까?”가 아니라, “이 문제는 정말 협업이 필요한가?”가 되어야 한다.

---

참고

• Yubin Kim et al., Towards a Science of Scaling Agent Systems, 2025.
• 본 문서의 수치와 그림은 사용자가 제공한 원문 PDF를 바탕으로 정리했다.
• 그림은 원문 Figure 1, Figure 2, Figure 3, Figure 5를 사용했다.