한 줄 요약
이 논문은 멀티 에이전트 시스템을 자동으로 설계하는 MASS를 제안합니다.
핵심은 단순합니다.
- 에이전트를 많이 붙이는 것만으로는 충분하지 않습니다.
- 각 에이전트의 프롬프트가 먼저 좋아야 합니다.
- 그다음, 어떤 에이전트를 어떤 구조로 연결할지 찾아야 합니다.
- 마지막으로, 전체 워크플로우 안에서 프롬프트를 다시 맞춰야 합니다.
Crop 포인트: MASS는 프롬프트 탐색과 토폴로지 탐색을 분리하지 않고, 두 설계 축을 함께 다룬다.
문제의식: 멀티 에이전트는 강력하지만 설계가 어렵다
LLM 에이전트 하나로도 많은 작업을 처리할 수 있습니다.
하지만 복잡한 작업에서는 여러 에이전트를 함께 쓰는 방식이 자주 더 좋습니다.
예를 들면 다음과 같습니다.
- 여러 답안을 만든 뒤 투표하기
- 한 에이전트가 답하고 다른 에이전트가 검토하기
- 여러 에이전트가 토론하기
- 코드 실행기나 검색 도구를 붙이기
- 긴 문서를 요약한 뒤 답변하기
문제는 설계 비용입니다.
멀티 에이전트 시스템에서는 결정할 것이 많습니다.
- 각 에이전트에게 어떤 역할을 줄 것인가
- 어떤 지시문과 예시를 넣을 것인가
- 에이전트를 병렬로 둘 것인가
- 순차적으로 반성하게 할 것인가
- 토론 구조를 넣을 것인가
- 도구 사용을 어디에 붙일 것인가
수동 설계는 금방 한계에 부딪힙니다.
논문은 이 문제를 프롬프트 설계와 토폴로지 설계의 결합 문제로 봅니다.
핵심 질문
저자들이 던지는 질문은 세 가지입니다.
- 에이전트를 늘리기 전에, 개별 에이전트의 프롬프트를 먼저 최적화해야 하는가?
- 모든 토폴로지가 실제로 성능 향상에 도움이 되는가?
- 프롬프트와 토폴로지를 함께 최적화하면 더 좋은 멀티 에이전트 시스템을 찾을 수 있는가?
결론은 명확합니다.
좋은 멀티 에이전트 시스템은 “많은 에이전트”가 아니라 “잘 준비된 에이전트와 적절한 연결 구조”에서 나온다.
인사이트 1: 프롬프트 최적화가 먼저다
논문은 먼저 단일 에이전트의 프롬프트를 최적화하는 것이 얼마나 중요한지 확인합니다.
비교 대상은 일반적인 멀티 에이전트 확장 방식입니다.
- 여러 답안을 만들고 일관된 답을 고르는 방식
- 답을 만들고 스스로 반성하는 방식
- 여러 에이전트가 토론하는 방식
결과는 흥미롭습니다.
프롬프트가 잘 다듬어진 에이전트는 단순히 에이전트 수를 늘리는 방식보다 토큰 대비 성능이 좋았습니다.
또한 최적화된 프롬프트 위에 병렬 샘플링을 얹으면 성능이 더 잘 올라갔습니다.
Crop 포인트: 프롬프트를 먼저 개선한 경로가 더 적은 낭비로 높은 정확도에 도달한다.
이 결과가 주는 메시지는 분명합니다.
좋지 않은 프롬프트를 가진 에이전트를 여러 개 연결하면 오류도 함께 증폭된다.
따라서 MASS는 토폴로지를 찾기 전에 각 블록의 프롬프트를 먼저 최적화합니다.
MASS의 전체 구조
MASS는 멀티 에이전트 설계를 세 단계로 나눕니다.
1단계: 블록 수준 프롬프트 최적화
먼저 가장 작은 단위의 에이전트 블록을 최적화합니다.
예를 들면 다음과 같습니다.
- 예측자
- 반성자
- 토론자
- 요약자
- 집계자
- 코드 실행 피드백을 쓰는 에이전트
이 단계의 목적은 간단합니다.
각 역할을 맡은 에이전트가 최소한 제 기능을 하도록 만드는 것입니다.
2단계: 워크플로우 토폴로지 최적화
다음으로 어떤 블록을 조합할지 찾습니다.
중요한 점은 모든 구조를 똑같이 탐색하지 않는다는 것입니다.
검증 성능을 실제로 끌어올린 블록은 더 자주 선택합니다.
반대로 성능을 떨어뜨린 블록은 탐색에서 덜 쓰입니다.
즉, MASS는 전체 공간을 무작정 뒤지지 않습니다.
영향력이 큰 구조를 중심으로 탐색 공간을 줄입니다.
3단계: 워크플로우 수준 프롬프트 최적화
마지막으로 선택된 전체 구조 안에서 프롬프트를 다시 조정합니다.
개별 에이전트가 잘 작동하더라도, 시스템 안에서는 역할이 달라집니다.
앞선 에이전트의 출력이 뒤의 에이전트 입력이 되기 때문입니다.
그래서 최종 단계에서는 전체 흐름에 맞춰 프롬프트를 다시 맞춥니다.
Crop 포인트: MASS는 로컬 프롬프트 최적화에서 출발해, 구조 탐색을 거쳐, 전체 워크플로우에 맞춘 프롬프트 재조정으로 끝난다.
인사이트 2: 모든 토폴로지가 도움이 되지는 않는다
멀티 에이전트 시스템에서는 흔히 더 복잡한 구조가 더 좋을 것이라고 생각하기 쉽습니다.
논문 결과는 그렇지 않습니다.
HotpotQA에서는 토론 구조가 도움이 되었지만, 다른 구조는 성능을 거의 올리지 못하거나 떨어뜨렸습니다.
LiveCodeBench에서는 코드 실행기처럼 작업 특화 도구가 큰 도움이 되었습니다.
즉, 토폴로지는 작업에 따라 달라집니다.
Crop 포인트: 작업마다 도움이 되는 블록이 다르며, 일부 블록은 오히려 성능을 낮춘다.
이 결과는 MASS의 탐색 방식과 연결됩니다.
MASS는 검증 성능을 기준으로 블록의 영향력을 측정합니다.
그 후 성능에 긍정적인 블록을 중심으로 후보 구조를 만듭니다.
실험 결과: MASS는 수동 설계와 자동 설계를 모두 앞섰다
논문은 다양한 작업에서 MASS를 평가합니다.
작업군은 크게 세 가지입니다.
- 수학 및 이산 추론
- 멀티홉·긴 문맥 이해
- 코드 생성 및 코드 실행 기반 예측
비교 대상도 넓습니다.
- Chain-of-Thought
- Self-Consistency
- Self-Refine
- Multi-Agent Debate
- ADAS
- AFlow
주요 결과는 다음과 같습니다.
- Gemini 1.5 Pro 기준, MASS 평균 성능은 78.79였습니다.
- 같은 설정에서 Multi-Agent Debate는 70.26이었습니다.
- ADAS는 69.72였습니다.
- Gemini 1.5 Flash에서도 MASS는 평균 74.30을 기록했습니다.
핵심은 단순한 승패가 아닙니다.
MASS가 강한 이유는 특정 구조 하나를 고정하지 않기 때문입니다.
작업에 맞는 프롬프트와 구조를 함께 찾습니다.
단계별 효과: 세 단계가 모두 필요하다
MASS의 성능 향상은 한 번에 생기지 않습니다.
단계별로 누적됩니다.
- 기본 에이전트에서 출발합니다.
- 단일 에이전트 프롬프트 최적화가 성능을 올립니다.
- 블록 수준 최적화가 더 큰 폭으로 성능을 올립니다.
- 토폴로지 최적화가 추가 개선을 만듭니다.
- 최종 워크플로우 프롬프트 최적화가 마지막 성능을 끌어올립니다.
논문은 이 흐름을 통해 다음을 보여줍니다.
프롬프트만 최적화해도 부족하고, 토폴로지만 찾는 것도 부족하다.
둘을 순서 있게 결합해야 합니다.
Crop 포인트: 성능은 단일 최적화가 아니라, 블록 프롬프트·구조 탐색·전체 프롬프트 최적화가 쌓이며 오른다.
최적화 과정: MASS는 안정적으로 좋아진다
ADAS와 AFlow 같은 자동 설계 방법은 새 구조를 반복적으로 제안합니다.
하지만 프롬프트 최적화가 명시적으로 들어가지 않으면 탐색이 불안정해질 수 있습니다.
MASS는 다르게 움직입니다.
먼저 프롬프트가 좋은 블록을 만듭니다.
그다음 구조를 찾습니다.
마지막으로 전체 구조에 다시 맞춥니다.
이 단계적 접근 덕분에 검증 성능이 비교적 안정적으로 상승합니다.
Crop 포인트: MASS의 궤적은 프롬프트 개선, 블록 선택, 전체 조정이 이어지며 점진적으로 상승한다.
MASS가 찾은 구조는 항상 복잡하지 않다
MATH 예시에서 MASS는 처음에는 토론 구조를 강하게 활용합니다.
하지만 이후에는 더 많은 병렬 예측자를 두고 집계하는 구조가 더 낫다는 것을 찾습니다.
마지막에는 그 구조에 맞는 프롬프트를 다시 최적화합니다.
여기서 중요한 점은 다음입니다.
가장 복잡한 구조가 항상 가장 좋은 구조는 아니다.
수학 문제에서는 다양한 풀이 후보를 만들고 좋은 답을 고르는 방식이 강할 수 있습니다.
반면 사실 검증이 중요한 멀티홉 질문에서는 토론과 검토가 더 유리할 수 있습니다.
Crop 포인트: MATH에서는 토론보다 병렬 탐색과 집계가 더 강한 최종 구조로 선택된다.
작업별로 유리한 패턴이 다르다
논문은 MASS가 찾은 최적 토폴로지를 시각화합니다.
전체적으로 다음 패턴이 보입니다.
- 수학과 DROP: 병렬 탐색과 집계가 강합니다.
- HotpotQA, MuSiQue, 2WikiMultiHopQA: 토론 구조가 자주 등장합니다.
- MBPP, HumanEval, LiveCodeBench: 실행기와 반성 구조가 중요합니다.
이는 직관적입니다.
수학 문제는 여러 풀이 경로를 탐색하는 것이 유리합니다.
멀티홉 질문은 서로 다른 근거를 맞춰 보는 과정이 중요합니다.
코딩 작업은 실행 결과와 오류 피드백이 강한 신호가 됩니다.
Crop 포인트: 최적 구조는 작업군에 따라 달라지며, 하나의 고정된 멀티 에이전트 설계가 모든 문제를 해결하지 않는다.
비용 관점: 성능만이 아니라 토큰 효율도 중요하다
멀티 에이전트 시스템은 성능을 올릴 수 있지만 비용이 증가합니다.
에이전트가 늘면 호출 수와 토큰 수가 늘어납니다.
그래서 중요한 질문은 이것입니다.
같은 비용 안에서 얼마나 좋은 성능을 내는가?
논문은 MASS가 더 나은 비용-성능 지점을 만든다고 보고합니다.
MASS는 여러 후보 구조를 찾기 때문에, 사용자는 가장 높은 성능만 고를 필요가 없습니다.
비용이 낮으면서 충분히 좋은 구조도 선택할 수 있습니다.
Crop 포인트: MASS 후보들은 높은 정확도 영역을 형성하며, 비용 대비 성능이 좋은 선택지를 제공한다.
실무적으로 얻을 수 있는 설계 원칙
이 논문에서 바로 가져올 수 있는 원칙은 다음과 같습니다.
1. 에이전트를 늘리기 전에 프롬프트를 먼저 다듬어라
나쁜 프롬프트는 여러 에이전트 구조 안에서 더 큰 문제를 만듭니다.
먼저 각 역할의 지시문과 예시를 안정화해야 합니다.
2. 토폴로지는 작업별로 달라야 한다
수학, 멀티홉 QA, 코딩은 서로 다른 구조를 요구합니다.
하나의 만능 멀티 에이전트 템플릿을 기대하기 어렵습니다.
3. 성능을 올리는 블록만 중심으로 탐색하라
모든 블록을 다 탐색하면 비용이 커집니다.
더 나쁜 경우, 성능을 낮추는 블록이 최종 구조에 섞일 수 있습니다.
4. 최종 구조가 정해진 뒤 프롬프트를 다시 맞춰라
개별 에이전트의 프롬프트와 전체 시스템 안의 프롬프트는 다릅니다.
후자는 다른 에이전트의 출력에 맞춰야 합니다.
5. 코딩 작업에는 실행 피드백을 적극적으로 써라
코드 생성에서는 실행 결과가 강력한 검증 신호입니다.
실행기와 반성자를 결합하면 오류 수정 능력이 좋아질 수 있습니다.
한계와 앞으로의 방향
MASS는 강력하지만 완성된 해법은 아닙니다.
논문도 몇 가지 한계를 인정합니다.
- 탐색 공간은 대표적인 블록을 포함하지만, 가능한 모든 구조를 담지는 않습니다.
- 토론 구조는 완전 연결 방식이라 통신이 중복될 수 있습니다.
- 더 고급 탐색 알고리즘을 쓰면 샘플 효율이 좋아질 수 있습니다.
- 프롬프트 최적화도 오류 로그나 텍스트 피드백을 더 잘 활용할 여지가 있습니다.
- 검증 데이터가 부실하면 잘못된 구조를 선택할 수 있습니다.
특히 실무에서는 비용 제한이 중요합니다.
따라서 MASS 같은 접근은 단순히 최고 성능 구조를 찾는 데서 끝나면 안 됩니다.
성능, 비용, 지연시간을 함께 고려해야 합니다.
핵심 정리
MASS의 메시지는 명확합니다.
멀티 에이전트 시스템의 성능은 에이전트 수가 아니라 설계 품질에서 나온다.
좋은 설계는 세 가지를 포함합니다.
- 역할에 맞게 최적화된 프롬프트
- 작업에 맞는 연결 구조
- 전체 흐름에 맞춘 재조정
이 논문은 멀티 에이전트 설계를 경험적 시행착오에서 구조화된 최적화 문제로 옮깁니다.
그래서 실무적으로도 의미가 큽니다.
새로운 작업에 멀티 에이전트를 적용할 때, 바로 복잡한 시스템을 만들기보다 다음 순서를 따르는 것이 좋습니다.
- 단일 에이전트와 핵심 역할 프롬프트를 먼저 안정화한다.
- 후보 블록을 작게 정의한다.
- 검증 성능으로 도움이 되는 블록을 고른다.
- 구조를 찾는다.
- 전체 구조 안에서 프롬프트를 다시 조정한다.
이것이 논문이 제안하는 가장 실용적인 멀티 에이전트 설계 방식입니다.
Source
- Han Zhou, Xingchen Wan, Ruoxi Sun, Hamid Palangi, Shariq Iqbal, Ivan Vulić, Anna Korhonen, Sercan Ö. Arık. Multi-Agent Design: Optimizing Agents with Better Prompts and Topologies. ICLR 2026.
- arXiv: https://arxiv.org/abs/2502.02533
- OpenReview: https://openreview.net/forum?id=I05H9RUzHB
