멀티에이전트 팀의 연산 배분

멀티에이전트 설계에서 에이전트 수보다 먼저 정할 것은 추가 추론 연산을 쓸 단계와 모델입니다. ProgramBench의 같은 리더-워커 하네스에서 계획만 위임한 Sol 팀은 전 단계를 위임한 Sol 팀보다 추가 비용당 보상이 약 2.7배였습니다(3.8 대 1.4).

코딩 에이전트에 추론 연산을 더 쓰는 주된 방법은 더 오래 생각하게 하거나 여러 번 시도하게 하는 것이었습니다. 에이전트 팀은 한 번의 시도를 여러 에이전트가 나눠 맡는 세 번째 방법입니다. 단일 에이전트의 추론 시점 연산 확장은 Test-Time Compute Scaling에 있습니다.

2026년 10월에 나온 한 연구는 팀 설계를 연산 배분 문제로 정식화했습니다. 강한 모델로만 구성한 팀은 솔로 에이전트보다 보상이 높았지만 비용은 3~7배였고, 이득의 크기는 추가 연산을 쓴 단계와 모델에 따라 갈렸습니다.

이 결과에 과제 분해 가능성 연구와 실패 귀속 연구를 더하면 팀을 꾸리기 전에 확인할 조건 세 가지가 나옵니다. 과제를 나눌 수 있는지, 어느 단계를 위임할지, 실패를 추적할 수 있는지입니다.

추가 연산이 들어갈 단계

Samway 등(arXiv:2610.17471, 2026-10)은 리더가 워커에게 하위 과제를 위임하는 최소 하네스를 만들었습니다. 워커는 배정받은 하위 과제만 보고, 전체 과제 설명이나 다른 워커의 대화는 보지 않습니다. 리더 프롬프트로 위임을 계획(P), 구현(I), 검증(V) 중 한 단계로 제한하거나 세 단계 모두(PIV)에 허용해 단계별 효과를 분리했습니다.

벤치마크는 ProgramBench의 200개 과제입니다. 에이전트는 빈 작업공간과 블랙박스 참조 실행 파일, 동작 문서만 받고 호환 프로그램을 처음부터 만듭니다. 주 실험은 GPT-5.6 Sol·Terra·Luna(논문 표기) 세 등급을 medium reasoning effort로 쓰고, 결과는 3회 실행의 평균입니다.

효율은 솔로 대비 보상 증가를 솔로 대비 비용 증가로 나눈 η로 잽니다. 논문은 η를 추가 비용 100달러당 보상 포인트로 보고하며, 보상 1포인트는 보상값 0.01입니다.

원문은 이 비용을 '총 추론 비용'이라고만 적었습니다. 아래 표의 과제당 비용에 과제 수 200을 곱한 총비용으로 계산하면 보고된 η와 맞습니다(계획: 5.7포인트 ÷ 추가 148달러 × 100 ≈ 3.8). 이 기준은 계산으로 맞춘 추정입니다.

아래 표는 Sol 리더와 대기형(blocking) 스케줄의 결과입니다. 대기형은 리더가 워커의 작업이 끝날 때까지 기다리는 방식입니다.

보상은 논문 표 3의 3회 평균이고, 비용은 표 4의 과제당 평균 추론 비용입니다. Sol 워커에게 계획만 맡긴 팀은 전 단계를 맡긴 팀과 보상이 같고(0.634 대 0.631) 비용은 약 절반입니다. η는 계획이 3.8, 구현과 검증이 최대 2.4, 전 단계가 1.4입니다.

저자들은 이 차이를 과제 구조로 설명합니다. ProgramBench는 목표 프로그램을 블랙박스로만 주므로 인터페이스, 경계 조건, 출력을 탐침으로 알아내야 합니다. 계획 워커는 이 탐색을 병렬로 나누고, 리더는 그 보고를 받아 직접 구현하고 검증합니다.

flowchart LR
    L["리더<br/>과제 분해"] --> W1["계획 워커 1<br/>참조 실행 파일 탐침"]
    L --> W2["계획 워커 2<br/>참조 실행 파일 탐침"]
    L --> WN["계획 워커 N<br/>참조 실행 파일 탐침"]
    W1 --> R["리더<br/>보고 종합"]
    W2 --> R
    WN --> R
    R --> I["리더<br/>직접 구현"]
    I --> V["리더<br/>직접 검증"]

PIV 안내는 첫 소스 편집 이후에도 위임을 이어갔습니다. 그 결과 위임 호출은 계획 안내의 약 2.4배가 됐지만 보상은 늘지 않았습니다. 추가 연산이 코드를 쓰기 전에 가장 큰 값을 냈다는 것이 저자들의 결론입니다.

싼 워커를 둘 자리

워커를 단가가 낮은 Luna로 바꾸면 단계 간 차이가 더 커집니다. 논문의 토큰 단가 기준으로 Luna는 Sol의 입력 20분의 1, 출력 약 17분의 1입니다. Luna 계획 워커는 솔로와 거의 같은 비용으로 보상을 2.4포인트 올렸고, η는 51.0으로 Sol 계획 워커(3.8)의 약 13배였습니다.

Luna 구현 워커는 반대로 비용을 늘리면서 보상을 솔로보다 낮춰 η가 −12.0이었고, 검증에 둔 Luna 워커는 보상을 거의 바꾸지 못했습니다. 저자들은 싼 워커가 강한 리더에게 정보를 모아 줄 때는 효과가 있고, 리더가 통합할 코드를 만들 때는 효과가 없다고 해석합니다.

비동기(async) 스케줄은 워커가 일하는 동안 리더도 작업을 이어가는 방식입니다. 이 스케줄에서 Sol 리더와 Luna 계획 워커로 된 팀은 전부 Sol로 된 계획 팀이 Sol 솔로(PIV 안내) 대비 얻은 보상 이득의 47.5%를 얻었습니다. 이때 쓴 추가 비용은 전부 Sol로 된 계획 팀이 쓴 추가 비용의 13.9%였습니다.

보상의 상한은 리더가 정합니다. 워커를 Luna로 고정하고 리더를 Luna에서 Terra로 올리면 보상이 20.9%, Terra에서 Sol로 올리면 15.4% 더 오릅니다. Terra 리더에 Luna 워커를 붙인 팀은 Sol 솔로보다 10.3% 낮았습니다.

워커 수를 고정한 실험(Sol 리더, Luna 워커 2·4·8·16명, 단일 실행)에서도 같은 비대칭이 나옵니다. 계획 워커는 모든 크기에서 보상을 올려 솔로 대비 2명에서 3.2%, 16명에서 7.1% 높았습니다. 구현과 검증 워커는 4명까지 오른 뒤 멈췄고, 4명에서 16명으로 늘린 변화는 −1.5포인트와 −1.1포인트로 95% 신뢰구간이 0을 포함합니다.

저자들은 이 차이를 워커가 가져오는 정보량으로 설명합니다. 계획 워커는 팀 크기와 관계없이 각자 참조 실행 파일을 약 7회 실행하므로, 워커가 늘면 리더가 받는 정보도 늘어납니다. 구현 워커를 늘리면 고정된 계획이 더 잘게 나뉘어 워커당 배정문이 1.4k자에서 0.4k자로 줄고, Luna 워커의 소스 편집 비중은 54%에서 85%로 오릅니다.

Luna 계획 워커 16명을 둔 팀은 리더가 크기를 정하는 Sol 동질 팀과 보상 차이가 1.4포인트였고 비용은 70% 낮았습니다. 추가 연산을 계획 단계의 싼 워커에 몰아 준 결과입니다.

나눌 수 있는 과제와 나눌 수 없는 과제

계획 워커의 이득은 블랙박스 탐색을 독립적인 조각으로 나눌 수 있었던 데서 나왔습니다. Kim 등의 연구(arXiv:2512.08296, v3 2026-04)는 이 조건을 과제 단위에서 비교합니다. 6개 벤치마크, 5개 구조, 3개 LLM 계열의 260개 설정에서 도구, 프롬프트, 총 추론 토큰(시행당 평균 4,800개)을 맞췄습니다.

금융 분석 과제에서는 중앙 조정 구조가 단일 에이전트보다 상대 80.8% 높았습니다. 순차 계획 과제인 PlanCraft에서는 모든 멀티에이전트 구조가 하락했고, 독립 실행 구조의 하락이 70.0%로 가장 컸습니다.

논문은 Finance-Agent와 PlanCraft의 차이를 고정 예산 안의 토큰 사용으로 설명합니다. 분해 가능한 과제에서는 각 에이전트가 국소 추론을 마치고 남은 예산으로 부분 결과를 주고받습니다. 순차 의존이 강한 과제에서는 제약 확인과 상태 추적에 예산 대부분이 쓰이고, 이어지는 메시지 교환이 추론 품질을 떨어뜨립니다.

두 과제의 도메인 복잡도 점수는 Finance-Agent 0.41, PlanCraft 0.42로 비슷했습니다. 논문은 결과를 가른 요인으로 복잡도보다 과제 분해 가능성을 꼽습니다.

코딩 과제인 SWE-bench Verified(20문제 부분집합)에서는 모든 멀티에이전트 구조가 단일 에이전트보다 낮았습니다(−2.1%~−14.9%). 논문은 이 과제를 도메인 복잡도가 낮은(0.255) 분해 가능한 과제로 분류하고, 하락을 능력 포화로 설명합니다. 대부분의 모델이 단일 에이전트로 이미 약 45%를 넘어 조정으로 더할 여지가 작다는 해석입니다.

조정 오버헤드와 구조별 오류 증폭 수치는 멀티에이전트 시스템 평가와 오케스트레이션 토폴로지에 있습니다.

사고 토큰 예산을 같게 묶은 비교도 같은 방향입니다. Tran과 Kiela(arXiv:2604.02460, 2026-04)는 다중 홉 질의응답(FRAMES, MuSiQue)을 4개 모델로 풀었습니다.

이 연구는 단일 에이전트와 다섯 가지 멀티에이전트 구조를 같은 예산에서 비교했습니다. 예산 1,000토큰의 평균 정확도는 단일 에이전트 0.418, 순차 멀티에이전트 0.379였습니다. 단일 에이전트는 100토큰을 제외한 모든 예산에서 최고이거나 최고와 통계적으로 구별되지 않았습니다.

저자들은 데이터 처리 부등식으로 이를 설명합니다. 다른 에이전트가 받는 메시지는 원래 컨텍스트에서 만든 것이므로 정답에 관한 정보를 늘릴 수 없다는 논리입니다. 이 논증은 컨텍스트를 완전히 활용한다는 가정에 기대며, 저자들도 컨텍스트 활용이 떨어지면 멀티에이전트가 경쟁력을 가질 수 있다고 봅니다.

세 결과를 나란히 놓으면 추가 에이전트가 이득을 내는 조건이 하나로 모입니다. 워커가 리더의 컨텍스트에 없는 정보를 새로 가져올 때 이득이 나고, 이미 있는 정보를 나눠 처리할 때는 조정 비용만 늡니다. 이는 판단입니다.

실패를 되짚을 수 있는가

연산을 잘 배분한 팀도 실패할 수 있고, 그때는 원인을 찾아야 합니다. 실패 귀속(failure attribution)은 실패한 실행 기록에서 책임 에이전트와 결정적 단계를 찾는 문제입니다. 결정적 단계는 그 단계를 고치면 최종 출력이 기대 출력으로 바뀌는 가장 이른 단계입니다.

공통 벤치마크인 Who&When은 127개 멀티에이전트 시스템의 실패 로그 184건에 책임 에이전트와 결정적 단계 라벨을 사람이 단 데이터입니다. 알고리즘 생성 로그(CaptainAgent 팀)는 최대 10단계로 짧습니다. 수작업 로그(Magentic-One)는 평균 LLM 호출이 28.8회로 더 깁니다(TraceElephant 집계).

원 논문의 기준선 수치는 멀티에이전트 도입의 신뢰성 판정에 있습니다. 2026년에 나온 방법들은 책임 에이전트를 70%대까지 맞히지만, 결정적 단계의 정확도는 그보다 크게 낮습니다.

단위는 %이고, 정답 제공은 귀속기에 과제의 정답을 함께 주었는지를 뜻합니다. FALAT(arXiv:2606.00765, 2026-05)은 같은 백본으로 비교한 설정에서 책임 에이전트 정확도가 최고 73.0%였습니다. CHIEF(arXiv:2602.23701, 2026-02)는 정답을 준 조건에서 77.59%를 보고했습니다.

결정적 단계 정확도는 짧은 로그에서도 최고 52.00%였고, 표의 방법들은 긴 수작업 로그에서 30% 안팎입니다. 반복 재실행을 쓰는 FAMAS의 보고값은 수작업 로그에서 41.38%입니다(정답 제공 조건, CHIEF 표 1).

평가 조건도 수치를 크게 바꿉니다. CHIEF 논문은 수작업 로그 단계 정확도를 29.31%로 보고했지만, FALAT이 백본 이름이 같은 DeepSeek V3.2로 CHIEF를 재실행한 값은 10.3%였습니다. FALAT의 수작업 로그 단계 정확도는 정확 일치에서 22.229.1%이고, ±5단계를 허용하면 43.153.4%로 오릅니다.

기록에 무엇을 남기는지도 귀속 정확도를 바꿉니다. TraceElephant(arXiv:2604.22708, 2026-04)는 세 시스템에서 실패 트레이스 220건을 모았고, 세 시스템 중 하나는 단일 에이전트 스캐폴드입니다. 각 단계의 입력 컨텍스트, 메타데이터, 도구 로그까지 기록했습니다.

두 귀속 기법에 정답을 준 조건에서, 입력 컨텍스트와 메타데이터를 빼고 출력(도구 로그 포함)만 남기면 단계 정확도가 0.160.17이었습니다. 전체 트레이스에서는 0.280.30이었습니다.

이 결과는 위임 구조의 기록 설계로 이어집니다. ProgramBench 하네스의 워커는 배정받은 하위 과제만 보므로, 워커의 판단을 평가하려면 리더가 보낸 배정문이 입력 컨텍스트로 남아 있어야 합니다. 구현을 싼 워커 여러 명에게 나누면 결정적 단계가 들어 있을 수 있는 궤적 수도 함께 늘어납니다.

이 연결은 판단입니다. 리더-워커 코딩 팀에서 귀속 정확도를 직접 잰 연구는 확인하지 못했습니다. 운영 환경에서 실행 기록의 범위를 정하는 방법은 기업별 코딩 에이전트 하네스 운영에 있습니다.

이 주장이 성립하지 않는 조건

최선의 위임 단계는 과제마다 다릅니다. 스켈레톤과 단위 테스트가 주어지는 Commit0-Lite(파이썬 라이브러리 16개, 설정당 1회 실행)에서는 구현 안내가 10개 설정 중 8개에서 가장 효과적이었습니다. 계획은 한 번도 명확한 최선이 아니었습니다.

다만 Commit0-Lite는 과제 수가 적고 Sol이 16개 중 12개 과제에서 만점을 받을 만큼 포화에 가까워, 원문도 이 차이를 방향성 결과로만 봅니다. 계획 우위는 명세를 탐색해야 하는 ProgramBench에서 관찰됐습니다.

리더 모델이 위임하지 않으면 배분 자체가 일어나지 않습니다. 최소 안내(minimal)는 위임 시점과 방법을 리더에게 맡기는 프롬프트입니다. Claude Opus 4.7 리더는 최소 안내에서 과제당 워커를 0.3명만 띄웠고, 팀은 솔로와 구별되지 않았습니다(+0.001 ± 0.022).

PIV 안내를 받은 Opus 4.7 팀은 보상이 0.0430.063 올랐고, 비용은 솔로의 1.72.0배였습니다. Claude Haiku 4.5 팀은 위임을 했지만 모든 설정에서 솔로 이하(−0.041~−0.004)였고 비용은 약 두 배였습니다. 두 Claude 결과와 워커 수 고정 실험은 단일 실행입니다.

GPT-5.6 결과의 200과제 평균은 실행 간 표준편차가 최대 0.014로 작지만, 과제 하나의 보상은 실행 간 평균 0.057~0.113 차이가 납니다. 팀의 이득은 대체로 쉬운 과제에서 가장 크고 어려운 과제에서 줄었으며, 구현 안내만 쉬운 과제에서 가장 나빴습니다.

워커 상한을 올리거나 메시지 도구를 주는 조작은 이득을 내지 못했습니다. 워커 상한을 5명에서 20명으로 올리면 보상 변화는 −1.6~+1.6포인트였고, 비용은 10개 중 7개 설정에서 5~17% 올랐습니다.

에이전트 간 메시지 도구는 실행 중인 모든 에이전트에게 메시지를 보낼 수 있게 합니다. Sol 팀(PIV 안내)에서는 메시지의 84%가 리더에게 갔고 보상은 변화가 없었습니다. Luna 팀은 4.4~7.1포인트 떨어졌습니다.

η는 추가 비용이 분모이므로, 추가 비용이 작은 Luna 구성에서는 작은 보상 차이로도 값이 크게 나옵니다. 51.0 같은 값은 보상 증가폭과 함께 읽어야 한다는 것이 판단입니다. Kim 등의 예측 모델은 교차검증 R²가 0.373(과제 기반 능력 지표를 쓰면 0.413)이어서 성능 분산의 절반 이상을 설명하지 못합니다.

실패 귀속 수치는 대부분 GAIA와 AssistantBench 같은 웹 조사 과제의 로그에서 나왔습니다. TraceElephant의 유일한 코딩 로그는 SWE-Agent의 SWE-bench 실패 기록 44건이며, 단일 에이전트 기록입니다. 이 로그의 단계 정확도는 29.6%(Static Agentic 기법, 정답 제공)로 웹 과제 시스템(30.6%, 30.8%)과 비슷했습니다.

리더-워커 코딩 팀의 실패 로그에서도 단계 귀속이 비슷하게 어렵다고 보는 것은 추정입니다. 세 갈래의 연구 중 어느 것도 연산 배분과 실패 추적 가능성을 한 실험에서 함께 재지 않았습니다.

팀을 꾸리기 전에 확인할 것

세 조건을 실제 확인 항목으로 풀면 아래 다섯 질문이 됩니다. 질문에 답하기 전에 같은 과제, 같은 도구, 같은 총예산으로 단일 에이전트 기준선을 먼저 만들어야 합니다. 기준선이 없으면 팀의 이득과 비용을 잴 수 없습니다.

Who&When(웹 과제 로그) 기준으로 자동 귀속의 결정적 단계 정확도는 짧은 로그에서도 50% 안팎입니다. 그래서 자동 귀속 결과는 사람이 확인할 구간을 좁히는 데 쓰는 편이 맞습니다. 이 처방과 표의 처방은 앞 절의 근거에서 끌어낸 판단입니다.

참고 자료

• Scaling Inference-Time Compute with Teams of Coding Agents, arXiv:2610.17471 (2026-10)
• Towards a Science of Scaling Agent Systems, arXiv:2512.08296 (2025-12, v3 2026-04)
• Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets, arXiv:2604.02460 (2026-04)
• FALAT: Tracing Failures in LLM Agent Trajectories via Dependency-Guided Search, arXiv:2606.00765 (2026-05)
• From Flat Logs to Causal Graphs: Hierarchical Failure Attribution for LLM-based Multi-Agent Systems, arXiv:2602.23701 (2026-02)
• Seeing the Whole Elephant: A Benchmark for Failure Attribution in LLM-based Multi-Agent Systems, arXiv:2604.22708 (2026-04)

모든 수치는 2026-10 기준으로 각 원문에서 대조했습니다.

정리

멀티에이전트 팀의 이득은 에이전트 수보다 추가 추론 연산의 배분에 따라 갈립니다. ProgramBench의 Sol 동질 팀에서 계획만 위임한 팀은 전 단계를 위임한 팀과 같은 보상을 약 절반의 비용으로 얻었습니다. 싼 모델은 계획 워커로 쓸 때만 보상을 뚜렷하게 올렸습니다. 금융 분석과 순차 계획의 대비는 이 이득이 과제를 독립적인 조각으로 나눌 수 있을 때 생긴다는 점을 보여줍니다.

한계도 분명합니다. 최선의 위임 단계는 과제와 리더 모델에 따라 바뀌고, 자동 실패 귀속은 Who&When(웹 과제 로그) 기준으로 결정적 단계를 짧은 로그에서도 절반 정도까지만 맞힙니다. 팀을 꾸리기 전에 단일 에이전트 기준선, 새 정보를 만드는 단계, 입력까지 남기는 실행 기록을 먼저 갖추는 것이 순서입니다.