여러 개발자의 에이전트를 조합하는 MDA가 단일 개발자 시스템을 앞선다

무엇인가

이 논문은 에이전트 시스템의 확장 축을 "한 개발자 안에서의 모델·도구 확장"에서 "여러 개발자 사이의 조합"으로 옮길 수 있는지 묻는다. 현재 에이전트 시스템은 단일 개발자가 모든 에이전트를 설계·배포하고 오케스트레이션까지 통제하는 SDA(single-developer agentic system) 형태가 지배적이다. 저자들은 이를 여러 개의 경쟁하는 인터넷에 비유한다. 각자 자기 인터넷을 만들면 보안과 유지보수는 좋아질 수 있지만 이미 존재하는 구성요소를 매번 다시 만들어야 하고, 사용자는 열등한 선택지 사이를 오가야 한다. 마찬가지로 SDA는 오케스트레이션, 웹 검색, 문서 파싱 같은 기반 능력을 매번 새로 구현해야 하며, 프런티어 성능의 상한은 결국 가장 큰 단일 개발자의 자원으로 결정된다. 논문은 여러 개발자가 각자 만든 에이전트를 하나의 시스템이 조합하는 MDA(multi-developer agentic system)를 새로운 스케일링 축으로 제안한다.

어떻게 동작하나

형식화는 이렇다. 개발자 집단 P={d_i}의 각 개발자는 예산 b_i로 하나의 에이전트 시스템 a_i: X→Y를 배포하고, 이들이 모여 전역 에이전트 풀 A를 이룬다. 조정 메커니즘 Ω는 풀 A와 요청 x를 받아 응답을 돌려준다. SDA는 Ω^SDA(A,x)=a_i(x)로 자기 시스템만 쓴다. 라우티드 SDA(rSDA)는 라우터가 σ_SDA(A,x)로 시스템 하나를 골라 요청 전체를 맡기므로, 모든 개발자가 참여하되 선택된 시스템은 다른 시스템과 상호작용하지 않는다. 논문이 구현한 δ-MDA는 요청을 δ로 하위 과제 (x_1,…,x_k(x))로 분해하고, 각 하위 과제를 라우터 σ가 풀 안의 서로 다른 시스템에 보낸 뒤, γ가 그 응답들을 모아 최종 답을 만든다. 여러 라운드를 반복할 수 있다. 핵심 차이는 SDA와 rSDA에서는 개발자가 자기 시스템의 평균적 능력으로 평가받는 반면, δ-MDA에서는 특정 하위 과제에서의 최고 능력만 쓰인다는 점이다. 대신 분해·통신·합성 오버헤드가 붙는다.

무엇과 다른가

실험은 실제 개발자 생태계를 메타 에이전트 파이프라인으로 모사한다. 스펙 에이전트가 JSON 명세 Z_i를 생성하고(개발자 전문성 차이를 반영하며 길이가 제한된다), 메타 에이전트가 도구·의존성·시스템 메시지를 만들어 ReAct 에이전트로 컴파일한 뒤 테스트 질의와 트레이스를 보며 반복 개선한다. 이 개선 라운드 수가 개발자 예산 b_i다. 세 개의 풀을 만든다. 전문가 풀 A_S는 k>1인 전문가 개발자, 일반주의자 풀 A_G는 k=1, 멀티에이전트 풀 A_MAS는 한 개발자가 중앙 오케스트레이터 아래 여러 전문가를 묶은 SDA다. 세 풀의 전역 예산 합 B=Σb_i는 동일하게 맞춘다. 이질성은 메타 에이전트용 LLM(gpt-5.2, claude-opus-4.5, gemini-3-pro-preview)과 배포 에이전트의 성능·비용 등급(H/M/L)으로 반영한다. 라우터 σ는 에이전트 설명문과 배포 중 쌓인 경험 버퍼를 함께 쓰는 자기개선 LLM 에이전트이며, 업데이트 에이전트가 전역 순위와 "A는 강하지만 B는 약하다" 같은 상황별 순위를 만든다. 평가는 GAIA(웹 검색·멀티모달·다양한 파일 형식)와 SealQA(웹 검색 중심 QA)에서 정확도와 API 비용으로 한다. GAIA에서는 일반주의자 9명(A_G, A_MAS)과 k=6인 전문가 54명(A_S)을, SealQA에서는 2≤k≤8(평균 3.8)인 전문가 42명과 일반주의자 11명을 인스턴스화한다.

어떻게 쓰나

GAIA에서 A_S 개별 SDA의 정확도 중앙값은 21%, 최고는 35%다. 이들을 δ-MDA로 묶으면 최고 A_S SDA보다 35%p 높은 70%를 넘긴다. A_MAS에서 다음으로 좋은 개별 SDA는 67%인데 비용이 29달러로 δ-MDA의 두 배가 넘는다. 라우터를 학습시키지 않고 에이전트 설명문만 쓰면 61.0%로 9.1%p 떨어진다. 일반주의자 SDA가 전문가 각자의 개발 예산의 몇 배를 들여 만들어졌음에도 MDA는 그 중앙값보다 12%p, 최고보다 3%p 높다. 상보적 에이전트 하나를 MDA에 추가하면 그 에이전트의 단독 정확도가 19%에 불과해도 MDA 정확도가 40%에서 53%로 오른다. 반면 SealQA처럼 과제 범위가 웹 검색 하나로 좁으면 MDA가 더 높은 비용에도 SDA 베이스라인보다 나쁠 수 있다.

전제와 한계

이론 모델은 인센티브 구조를 겨냥한다. 라우티드 SDA 아래에서는 모든 개발자가 일반주의자 풀 A_G로 가는 것이 유일한 보수 최대화 내시 균형이다(명제 1). 작은 개발자도 롱테일 능력을 밀기보다 축소된 열등한 일반주의자를 배포하는 편이 낫다는 뜻이다. δ-MDA 아래에서는 각 개발자가 단일 기술에 특화하는 내시 균형이 존재한다(명제 2). 보조정리 3은 어떤 풀에서도 δ-MDA의 후생이 라우티드 SDA 이상이며 등호는 풀이 A_G일 때만 성립한다고 말한다. 라우티드 SDA가 개발자 간 다양성을 낭비한다는 직관이다. 명제 4는 (rSDA, A_G)와 (δ-MDA, A_S)가 둘 다 결합 균형이지만 후자가 후생에서 엄격히 우월하다고 한다. 즉 현재의 (rSDA, A_G) 구성이 열등한데도 유지될 수 있는 닭과 달걀 문제가 있다. 명제 5는 개발자가 후생 기여가 아니라 트래픽 점유율을 최대화하면 어떤 조정 메커니즘에서도 일반주의 균형이 나온다고 지적한다.

개발자에게 주는 실무적 의미는 평가 기준이 바뀐다는 것이다. 에이전트를 단독 성능으로만 재면 실제 배포에서의 기여를 놓친다. GAIA에서 19%짜리 에이전트가 공유 시스템에 13%p를 더했다. 또 동일한 미드티어 전문가들이 MDA에서는 호출의 56%를 받았지만 경쟁 SDA로는 33%에 그쳤고, 같은 실험에서 MDA가 전체 정확도를 8%p 끌어올렸다. 좁은 도메인 데이터·서비스·통합을 가진 조직이 범용 어시스턴트를 직접 만드는 대신 특화 에이전트를 내놓고 보상과 통제권을 유지하는 경로가 열린다는 뜻이다. 실무에서는 라우팅·분해·합성 오버헤드를 비용에 반드시 포함해 측정해야 하고, 에이전트 설명문이 실제 능력과 어긋날 때(라우터 미학습 시 9.1%p 하락)를 전제로 경험 기반 라우팅을 설계해야 한다.

저자들이 밝힌 한계도 분명하다. MDA의 조정 오버헤드가 이론적 이득을 상쇄할 수 있고 실용성은 과제에 달려 있으며, 모든 환경에서 MDA가 SDA보다 우월할 가능성은 낮다. 규모가 커졌을 때의 라우팅과 분해·합성 구현, 협업 에이전트 간 가치 분배, 공유 MDA 인프라 비용을 누가 부담할지는 미해결 문제다. 참여자를 전부 신뢰할 수 없는 환경에서 보안·프라이버시·책임성 문제는 증폭되며, 악의적이거나 성능이 나쁜 시스템 하나가 하류에 치명적 결과를 내지 않도록 하는 장치가 필요하다. δ-MDA는 여러 구현 중 하나의 예비적 단계이고, 이론·경험 모델이 실제 개발자 집단의 복잡한 역학을 완벽히 담지는 못한다. 진짜 검증은 실제 배포에서 이뤄져야 한다는 것이 저자들의 결론이다.