Review : Large Language Model-based Multi-Agent Collaboration

TL;DR

문제: 기존의 multi-agent 는 소규모에서는 효과적이지만, 구조 없는 확장은 coordination & context 비용으로 인해 성능이 붕괴된다. 접근: 효과적인 agent scaling 을 위해 DAG 기반 multi-agent collaboration network(MACNET) 을 설계했다. 관찰: agent 수 증가에 따라 성능은 logistic growth 형태로 증가했으며, 불규칙한 topology 가 규칙적인 구조보다 일관되게 우수했다. 한 줄 요약: 뉴런 수를 늘리면 성능이 좋아졌듯, 에이전트 수도 늘리면 성능이 좋아지지 않을까?

Introduction

LLM 기반 연구에서 multi-agent 협업이 단일 agent 보다 우수한 성능을 보인다는 점은 확인되었지만, 기존 연구에서는 agent scale 을 키우는 문제가 상대적으로 간과되었다. 일부 연구가 수십 개 수준을 다루긴 했으나, 대부분은 10 개 미만의 agent 를 사용했다. Neural network 에서 뉴런 수를 늘릴 때 성능이 증가하는 scaling law 가 관찰되었듯, agent 수에도 유사한 scaling law 가 적용될 수 있지 않을까라는 의문에서 연구가 시작되었다.

Research Question

어떻게 효과적인 agent scaling 을 할 수 있을까? 과연 agent scaling 은 성능을 향상시킬까?

하지만, 효과적인 agent 의 협업을 위해서는 단순히 agent 의 갯수를 늘려서 다수결 투표 (majority voting) 방식에 의존 할 수 없다. 효과적인 scaling 을 위해서는 scalable networking, cooperative interaction, and progressive decision-making 이 필요하다. 네트워크 확장이 용이하며, 상호 협력과 점진적인 의사결정을 할 수 있어야 한다.

Majority voting(다수결) 은 interaction 과 refinement 가 없고, agent 수가 증가할수록 정보 중복과 비용이 증가할 수밖에 없는 구조라 한계가 있다.

해당 연구에서는 이를 위해서 multi-agent collaboration network (MACNET) 을 제안하였다.

실험/접근 방법

flowchart TD
    Ai["Actor i"]
    Cij["Critic (i → j)"]
    Aj["Actor j"]

    Ai -->|artifact 제출| Cij
    Cij -->|수정 지시| Ai
    Ai -->|refined artifact| Cij
    Cij -->|승인된 artifact 전달| Aj

효과적인 agent scaling 을 위한 구조적 조건은 scalable networking, cooperative interaction, progressive decision making의 세 요소로 요약될 수 있다.

MACNET 은 이러한 조건을 만족시키기 위해, agent 간 상호작용의 순서와 정보 흐름을 구조적으로 제약하는 Directed Acyclic Graph(DAG) 기반의 협업 네트워크로 설계되었다. 여기서 DAG 는 단순한 구현 선택이 아니라, 대규모 agent 협업을 가능하게 하는 최소한의 구조적 제약으로 기능한다.

DAG 는 방향성을 가지면서 순환이 없는 그래프로, 정보의 backflow를 구조적으로 차단하고 task-specific 한 cycle breaking 을 불필요하게 만든다. 순환 구조 (A → B → C → A) 를 허용할 경우, agent 수가 증가함에 따라 상호작용 비용이 급격히 증가할 뿐만 아니라, 잘못된 중간 판단이나 hallucination 과 같은 local error 가 반복적으로 증폭·전파될 위험이 존재한다.

반면, DAG 구조에서는 상호작용이 위상적 순서에 따라 진행되므로, 의사결정이 단계적으로 축적되는 progressive decision making이 가능하며, 전체 협업 과정이 유한한 단계 내에서 종료됨이 구조적으로 보장된다. 그 결과, 각 agent 나 노드 수준에서 별도의 종료 조건을 설계할 필요가 없다.

그렇다면, 이러한 구조적 제약을 토대로 어떤 형태의 네트워크 (topology) 가 필요하며, 각 구성 요소가 어떤 역할로 어떻게 상호 작용할지 또한 대규모 협업에서 발생하는 context explosion 을 어떻게 제어할지를 알아보자

“A graph will orchestrate agent interactions, akin to social networks where information propagates through directed edges. Intuitively, the acyclic nature prevents information backflow, eliminating the need for additional designs like task-specific cycle-breaking, thereby enhancing generalizability and adaptability across contexts.” (Qian et al., 2025, p. 3)

네트워크 (Topology) 구성은 어떻게 되어야 할까

이 모양이 어떻게 생겼을까

이 논문에서는 2 depth 의 구조를 제공한다. chain, tree, graph 이다.

Chain:
- linear structure (Waterfall Model 유사)
Tree:
- Star (wider), Tree (deeper)
Graph:
- Mesh (fully-connected), Layer (Multi-Layer Perceptron shaped), Random (irregular)

Interactive Reasoning: 어떻게 Agent 간에 상호 작용을 하는가

MACNET 에서 노드 (node) 와 엣지 (edge) 는 모두 LLM 기반 agent 로 구현된다. 노드 (Actor, $a_{i}$ ) 는 입력된 artifact 를 받아 수정된 artifact 를 생성하며, 현재 artifact 의 버전과 해당 시점의 결정 결과를 유지한다. 엣지 (Critic, $a_{ij}$ ) 는 노드 $v_{i} \to v_{j}$ 에 대응하는 중재자 (agent) 로, artifact 를 직접 생성하지 않고 수정 방향과 적용 기준에 대한 directional instruction만 제공한다.

Topological Order 를 따르라

Agent 간 상호작용은 DAG 의 topological ordering에 의해 구조적으로 제한된다. 즉, 각 방향 엣지 $v_{i} \to v_{j}$ 에 대해 아래 수식을 만족한다. $I (a_{i}) < I (a_{ij}) < I (a_{j})$ 위의 순서가 강제되며, 이는 Actor → Critic → 다음 Actor의 의사결정 흐름을 의미한다. 이 순서 제약 하에서 병렬 실행은 허용되지만, 의존성은 위배되지 않는다.

DAG 의 node 와 edge 는 multi-turn 대화를 통해 아래 과정을 반복한다. 먼저 $a_{i} \leftrightarrow a_{ij}$ 구간에서 Critic 이 피드백을 제공하고 Actor 가 artifact 를 정제 (refine) 한다. 이후 $a_{ij} \leftrightarrow a_{j}$ 구간에서 정제된 artifact 가 Critic 을 통해 다음 Actor 에게 전달되어 추가 개선이 이루어진다.

Dataflow 는 Node 와 Edge 기반으로 동작한다

MACNET 에서 dataflow 는 artifact 가 네트워크 내에서 전달되는 경로를 의미하며, artifact 는 연결된 노드들의 topology 에 따라 전달된다.

고려 사항 : Memory Control

Agent scaling 의 위험성은 제약 없는 정보 교환이 context explosion 을 일으킨다는 점이다. 예를 들어 memory control 없이 n 개의 agent 가 각각 n 개의 memory 를 주고받는 구조라면 비용은 $O (n^{2})$ 로 증가한다. 본 논문은 short-term/long-term memory 설계를 통해 대화 히스토리를 버리고 최종 artifact 중심으로 유지함으로써 복잡도를 완화한다.

Memory Control (Context Explosion)

무제한 정보 교환은 컨텍스트 폭발을 유발할 수 있음. 본 논문은 short-term/long-term memory 로 대화 히스토리를 버리고 최종 artifact 중심으로 유지해 복잡도를 완화.

Short-term memory:
- 각 interaction 내 working memory
- task, role prompt, current artifact
Long-term memory:
- 최종 결과물이 될 artifact 만 유지

Short-term memory 는 각 interaction 에서의 working memory 로서 task, role prompt, current artifact 를 포함한다. Long-term memory 는 최종 결과물이 될 artifact 만 유지한다. 즉, n 개의 agent 가 short-term memory 를 로컬하게 사용하되 long-term 에는 최종 artifact 만 남겨 대화 history 를 버림으로써 저장/전달 복잡도를 $O (n)$ 로 낮춘다.

결과, 관찰값

Performance 비교

MACNET-Chain 이 대부분의 metric 에서 baseline 을 능가

MACNET-Random 이 평균 Quality 에서 최고 성능 (0.6522)

특정 task 에 특정 topology 가 더 적합: chain → software development, tree → creative writing

Topology 분석을 어떻게 할 것인가?

Density Perspective : 얼마나 많이 연결 되었는가

높은 interaction density 가 평균적으로 좋은 성능을 보임 (mesh > tree > chain)
- 작업 특성에 따라서 편차가 존재한다고 추정이 된다.
  - Chain structure 가 softwareengineering 에서는 성능이 잘나온다. 그 이유는 software engineering 의 경우 linear process 를 따르기 때문이다.
  - 높은 창의성을 요구하는 다양한 직업에 있어서는 다양한 에이전트 간의 연결이 더 유리 할 수 있다.
  - 하지만, Density 가 항상 최적의 퍼포먼스를 보이는 것이 아님을 시사

높은 interaction density 가 평균적으로 좋은 성능을 보였다 (mesh > tree > chain). 다만 작업 특성에 따라 편차가 존재하는데, 예를 들어 software engineering 에서는 linear process 를 따르는 경향이 있어 chain 구조가 더 잘 작동할 수 있다. 반면 높은 창의성을 요구하는 작업에서는 다양한 agent 간 연결이 더 유리할 수 있다. 또한 density 가 항상 최적의 성능을 보장하지는 않는다는 점도 시사된다.

Shape Perspective : 그래프 패턴이 어떻게 구성이 되었나

Irregular topology(random) 가 regular topology 를 outperform 하는 것이 관찰되었다. 이는 지나치게 밀집된 상호작용이 agent 들에게 정보 부하를 주어 효과적인 reflection 과 refinement 를 저해했기 때문으로 해석된다. 또한 small-world properties 가 성능 향상에 기여했는데, 경로가 짧을수록 정보 전달 및 정제가 수월해지기 때문이다. 참고로 random topology 는 mesh 대비 약 52% 의 시간 절감도 보고되었다.

Direction Perspective

Divergent topology 가 convergent topology 보다 우수했으며, 발산 구조에서는 더 다양한 의견을 고려할 수 있어 성능이 좋아지는 것으로 해석된다. 또한 artifact propagation 역시 divergent structure 에서 더 smooth 하게 진행되었다.

그래서… Agent 에서 Scaling Law 가 성립이 되었는가

Logistic 하게 에이전트가 늘어날수록 성능이 증가하는 것이 관측이 되었다.

하지만, agent 의 수가 늘어나서 지능이 좋아졌다는 것보다 Task 를 풀 때 다양한 측면을 agent 들이 상호작용에서 고려하게 됨으로써 성능이 증가하는 것으로 여겨진다.

결론

MACNET 이 효과적으로 작동하며 collaborative scaling law 가 존재함을 확인했다. 다만 MACNET 을 구성할 때 어떤 topology 와 어느 정도의 agent scaling 이 최적인지는 task 시나리오에 따라 달라질 수 있다. 한계로는 scaling law 를 관찰하긴 했지만, 어떤 구조가 어떤 시나리오에서 최적인지까지는 밝히지 못했다는 점이 있다.

정리하면, MACNET 은 평균적으로 모든 baseline 을 압도했고 1000+ agent collaboration 을 효과적으로 지원했다. 또한 성능이 logistic growth pattern 으로 향상되는 collaborative scaling law 를 발견했으며 (용어는 본 논문에서 처음 정의), agent 수를 스케일링할 때는 불규칙 (irregular) topology 가 규칙적 (regular) topology 보다 평균적으로 더 높은 성능을 보였다 (Regular: Chain, Star, Tree, Layer / Irregular: Random, Mesh). 마지막으로 agent collaboration 은 training-time scaling 의 대안으로 inference-time procedural thinking 을 제공하여, Training 이 아닌 Inference 단계에서 성능 향상을 가능하게 하는 “shortcut” 역할을 할 수 있다.

Questions

Critic 마다 정말 다른 역할이 부여되는가?

Review 를 하면서 Critic 의 역할에 대한 질문을 받았다. 논문을 읽으면 각 Critic 은 edge 에 배치되어 두 노드 사이를 중재하는 역할을 한다고만 나와 있다. 그렇다면 모든 Critic 이 동일한 ” 감독자 ” 역할만 수행하는 것일까, 아니면 각 Critic 마다 전문화된 다른 역할을 가지는 것일까?

논문의 Equation 2 를 보면 각 agent 가 “professional roles” 를 가진다고 명시되어 있으며, Section 3.1 의 ablation study 에서 agents’ profiles 를 제거했을 때 평균 3.67% 의 성능 하락이 관찰되었다. 이는 각 agent 의 전문화된 역할이 실제로 성능에 기여함을 시사한다. 더 구체적으로, Section 3.4 의 Figure 8 을 보면 ChatDev 구현에서 54 개의 서로 다른 aspects 를 검토하는 것으로 나타났다 (Syntax Errors, Runtime Errors, Logic Errors, Security Vulnerabilities, Performance Issues 등). 만약 모든 Critic 이 동일한 역할을 수행한다면 이렇게 다양한 측면을 검토할 수 없을 것이다.

실제 GitHub ChatDev MACNET 브랜치 의 구현을 확인해보니, 각 Phase 마다 서로 다른 Critic 클래스가 정의되어 있었다. 예를 들어, phase.py 에서 DemandAnalysis Phase 는 CEO 가 Critic 역할을, CPO 가 Actor 역할을 수행하며, Coding Phase 에서는 CTO 가 Critic 으로, Programmer 가 Actor 로 배치된다. CodeReviewComment Phase 에서는 Code Reviewer 가 Critic 이 되고, TestModification Phase 에서는 Test Engineer 가 Critic 역할을 맡는다. 즉, 개발 프로세스의 각 단계마다 해당 단계에 전문화된 역할이 Critic 으로 배치되는 구조다.

더 흥미로운 점은 SRDD_Profile 시스템의 존재다. ChatDev 구현에는 ./SRDD_Profile/{category}/{1-99}.txt 형태로 40 개 카테고리 × 100 개 프로필 = 4,000 개의 서로 다른 role prompt 가 준비되어 있다. 예를 들어 Development/1.txt 는 알고리즘 전문가, Development/10.txt 는 모바일 개발 전문가, Entertainment/15.txt 는 AI/ML 전문가, Finance/22.txt 는 배포/위험 관리 전문가 등 각 프로필마다 고유한 전문성과 스킬셋이 정의되어 있다. 그리고 graph.py:400-439 의 agent_deployment(self, _type) 메서드를 보면 다음과 같은 코드가 있다:

profile_num = random.randint(1, 99)
with open(f"./SRDD_Profile/{_type}/{profile_num}.txt", "r", encoding="utf-8") as f:
    self.nodes[node.id].system_message = f.read()

즉, 각 노드가 생성될 때마다 1-99 범위에서 무작위로 프로필을 선택하여 서로 다른 전문성을 부여하는 것이다.

그렇다면 왜 논문에서는 이러한 role 차별화를 명시적으로 기술하지 않았을까? 세 가지 이유를 추측할 수 있다. 첫째, 논문의 핵심 기여는 “DAG 기반 협업 구조 ” 와 “agent scaling law” 이며, role assignment 는 구현 세부사항으로 간주되었을 가능성이 있다. 둘째, ChatDev 라는 특정 application domain(소프트웨어 개발) 의 구현 예시이기 때문에, 범용적인 MACNET 프레임워크를 설명하는 논문에서는 domain-specific 한 role system 을 깊이 다루지 않았을 수 있다. 셋째, 4,000 개의 프로필과 무작위 할당 메커니즘은 실험 재현성과 공정성 측면에서 논란의 여지가 있어 의도적으로 간략히 언급했을 가능성도 있다.

결론적으로, 각 Critic 마다 다른 역할이 부여된다는 강력한 증거가 4 가지 수준에서 확인된다: (1) 논문의 ablation study 에서 profiles 제거 시 3.67% 성능 하락, (2) 54 개의 서로 다른 검토 aspects, (3) phase 별로 전문화된 Critic 클래스 (CEO, CTO, Code Reviewer, Test Engineer 등), (4) 4,000 개의 SRDD_Profile 시스템과 무작위 할당 메커니즘. 따라서 MACNET 에서 각 Critic 은 동일한 감독자가 아니라, 각자의 전문 영역을 가진 domain expert 로 기능한다고 볼 수 있다.