MetaAgent 논문 정리

부제: FSM(유한상태기계)로 자동 설계하는 멀티 에이전트 시스템

• 논문명: MetaAgent: Automatically Constructing Multi-Agent Systems Based on Finite State Machines
• 저자: Yaolun Zhang, Xiaogeng Liu, Chaowei Xiao
• 발표: ICML 2025 / PMLR 267
• 원문 PDF: 2507.22606v1.pdf

---

한 줄 요약

MetaAgent는 멀티 에이전트 시스템을 “정해진 순서대로 흐르는 파이프라인”이 아니라, 상태(state)와 전이(transition)를 갖는 FSM으로 설계해 자동으로 생성하는 프레임워크다.

핵심은 도구 사용(tool use), 상태 내 반복 개선(null-transition), 이전 단계로 되돌아가는 traceback, 중복 상태 병합 최적화를 함께 묶어 실제 작업형 태스크에 더 강한 구조를 만든다는 점이다.

---

이 논문이 풀려는 문제

기존 멀티 에이전트 시스템은 크게 두 부류의 한계가 있다.

1) 사람 손으로 짠 시스템의 한계

• 특정 시나리오에 맞춰 설계되어 범용성이 낮다.
• 프롬프트, 역할, 흐름을 사람이 계속 다듬어야 한다.
• 새로운 도메인에 옮길 때 비용이 크다.

2) 기존 자동 설계 방법의 한계

• 케이스 단위로만 에이전트 구성을 만들고, 태스크 유형 전체를 커버하지 못하는 경우가 많다.
• 도구 사용이 약하거나 없다.
• 외부 데이터나 많은 반복 학습이 필요하다.
• 대부분 선형 파이프라인, 토론, 오케스트레이터 구조에 머물러 오류 수정용 되돌아가기(traceback)가 약하다.

이 논문은 “자동 설계”와 “실전형 협업 구조”를 동시에 만족시키는 프레임워크가 필요하다고 본다.

---

핵심 기여 4가지

1. 멀티 에이전트 시스템을 FSM으로 자동 설계

사용자는 “소프트웨어 개발용 멀티 에이전트 시스템을 만들어라”처럼 일반적인 태스크 설명만 준다.
그러면 MetaAgent는 그 태스크를 풀기 위한:

• 에이전트 집합
• 상태(state)
• 전이 조건(transition conditions)
• 최종 상태(final state)

를 자동으로 설계한다.

2. 각 상태에 Condition Verifier를 둔다

각 상태는 단순히 “에이전트가 한 번 일하고 끝”이 아니라,

• 어떤 에이전트가 일할지
• 무엇을 할지(instruction)
• 결과를 누가 받아 기억할지(listeners)
• 다음 상태로 넘어갈지 판단할 검증기(condition verifier)

를 함께 가진다.

즉, 에이전트 실행과 흐름 제어를 분리했다는 점이 중요하다.

3. Null-transition과 Traceback을 구조적으로 지원

이 논문의 실질적인 차별점은 여기다.

• Null-transition: 조건을 못 맞추면 같은 상태에 남아 다시 개선한다.
• Traceback: 이전 상태의 정보나 산출물이 문제라면, 이전 상태로 돌아가 수정한다.

이 때문에 MetaAgent는 선형 파이프라인보다 훨씬 실전적이다.
예를 들어 테스트 단계에서 버그가 나오면 개발 단계로 되돌아가 고칠 수 있다.

4. 중복 상태를 병합하는 최적화

초기 설계된 FSM은 상태 수가 많아질 수 있다.
논문은 Adaptor LLM을 사용해 두 상태를 병합할 수 있는지 판단한다. 판단 기준은 대략 다음과 같다.

• 역할이 충분히 다른가
• 상태 간 정보 전달이 정말 필요한가
• 도구나 행동이 겹치는가

즉, 너무 잘게 쪼개진 상태들을 합쳐서 더 짧고 튼튼한 시스템으로 다듬는 것이다.

---

MetaAgent를 이해하는 핵심 구조

FSM 관점에서 보면 하나의 상태는 다음 요소를 가진다.

• Assigned Agent: 현재 상태를 실제로 수행하는 에이전트
• Instruction: 이 상태에서 수행할 작업 지시
• Condition Verifier: 결과가 어떤 전이 조건을 만족하는지 판단
• Listeners: 현재 상태의 출력을 받아 기억할 에이전트들

실행 흐름은 다음처럼 생각하면 된다.

1. 현재 상태의 에이전트가 작업한다.
2. Condition Verifier가 결과를 본다.
3. 조건이 맞으면 다음 상태로 이동한다.
4. 조건이 안 맞으면 같은 상태에 머물며 수정한다.
5. 이전 단계 문제라면 traceback으로 되돌아간다.

---

Figure로 이해하는 MetaAgent

Figure 1. FSM이 실제로 어떻게 동작하는가

 

무엇을 보여주나?

• Pac-Man 게임 제작이라는 예시를 통해,
• 정보 수집 → 검증 → 다음 상태 전이 → 필요 시 이전 상태로 traceback
  의 흐름을 시각화한다.

여기서 봐야 할 포인트

• Information Collector가 검색 도구를 쓴다.
• Condition Verifier가 결과를 보고, 통과면 다음 상태로 넘긴다.
• 실패면 같은 상태에서 피드백을 받아 다시 시도한다.
• 다음 상태(Product Manager)에서 이전 정보가 부족하다고 판단하면 다시 앞 상태로 돌아간다.

해석

• 이 그림 한 장이 이 논문의 핵심을 거의 다 보여준다.
• MetaAgent는 “에이전트 수”보다 흐름 제어 방식에 더 큰 방점을 찍는다.

---

Figure 2. MetaAgent는 어떻게 시스템을 만든 뒤 다듬는가

 

무엇을 보여주나?

• 일반 태스크 설명을 입력으로 받아
• Designer가 에이전트와 상태를 만들고
• 그것을 FSM으로 연결한 뒤
• 마지막에 상태 병합 최적화를 수행하는 전체 생성 파이프라인이다.

포인트

• 입력은 구체적인 개별 문제(case)가 아니라 태스크 유형(task type) 이다.
• 그래서 “한 번 설계한 시스템을 같은 도메인의 다른 문제에도 재사용”하려는 방향성이 분명하다.
• 마지막 Optimizing the FSM 단계가 성능에 실제로 큰 영향을 준다.

해석

• 이 논문은 단순히 프롬프트를 잘 짜는 게 아니라,
  멀티 에이전트 시스템의 구조 자체를 생성하고 압축하는 문제로 접근한다.

---

Figure 3. 왜 FSM이 더 일반적인 구조라고 말하는가

무엇을 보여주나?
기존 멀티 에이전트 구조 3개와 FSM을 비교한다.

• Linear
• Decentralized Debate
• Coordinate with Orchestrator
• Finite State Machine

논문의 주장

• Linear 구조는 사실상 “되돌아가기 없는 FSM”
• Debate 구조는 “제한된 되돌아가기만 있는 FSM”
• Orchestrator 구조는 “검증기를 공유하는 FSM”
• 따라서 FSM이 더 일반적이고 유연한 상위 표현이라는 것이다.

왜 중요한가

• 자동 설계에서는 예외 처리, 되돌아가기, 조건 분기가 매우 중요하다.
• 선형 SOP만으로는 실제 태스크의 불확실성을 다루기 어렵다.

---

방법론을 쉽게 정리하면

MetaAgent의 아이디어는 다음 한 문장으로 정리할 수 있다.

“에이전트 협업을 대화 순서가 아니라 상태 전이 문제로 바꾸자.”

 

이 발상이 좋은 이유는 다음과 같다.

A. 협업의 실패 지점을 구조적으로 다룰 수 있다

기존에는 결과가 이상해도 어디서부터 잘못됐는지 추적하기 어렵다.
MetaAgent는 상태와 전이를 명시하므로:

• 현재 상태가 실패했는지
• 이전 상태 정보가 잘못됐는지
• 같은 상태에서 더 다듬으면 되는지

를 구분할 수 있다.

B. 도구 사용과 검증을 같은 루프 안에 묶을 수 있다

에이전트가 검색이나 코드 실행을 하고,
그 결과를 Condition Verifier가 읽고,
그에 따라 반복/전이/되돌아가기를 선택한다.

즉, 툴 피드백이 시스템 흐름을 직접 바꾸는 구조가 된다.

C. 자동 설계가 “케이스 전용”에서 “태스크 전용”으로 올라간다

SPP나 AutoAgents 같은 방식은 개별 문제마다 새 구성을 짜는 느낌이 강하다.
MetaAgent는 “이 도메인의 문제를 해결하는 공통 FSM”을 먼저 만든다.

---

실험 결과에서 꼭 봐야 할 숫자

1) 텍스트 기반 태스크

방법	Writing	GPQA
Direct	0.76	0.46
CoT	0.74	0.44
CoT-SC	0.74	0.49
llm-debate	0.73	0.54
Self-Refine	0.76	0.55
SPP	0.79	0.45
MetaAgent	0.86	0.60

해석

• Writing은 0.86으로 가장 높다.
• GPQA도 0.60으로 최고 성능이다.
• 단순 프롬프트 기법이나 자동 케이스 설계 방식보다 안정적으로 강하다.

---

2) ML Bench 성능

방법	평균 점수
AutoGen	0.77
Open Interpreter	0.49
TaskWeaver	0.35
MetaGPT	0.45
Data Interpreter	0.86
SPP	0.16
AutoAgents	0.00
MetaAgent	0.83

해석

• 자동 설계 방식 중에서는 MetaAgent가 가장 강하다.
• 사람이 ML용으로 잘 설계한 Data Interpreter(0.86)와 비교해도 상당히 근접한다.
• 즉, “자동 생성인데도 특정 도메인 최적화 시스템에 거의 근접”했다는 점이 중요하다.

---

3) 소프트웨어 개발 태스크

방법	평균 점수
MetaGPT	0.35
AutoAgents	0.20
SPP	0.15
MetaAgent	0.85

해석

• 여기서 MetaAgent의 강점이 특히 크게 드러난다.
• 논문은 Requirement Designer / Code Developer / Tester 같은 역할 구성을 자동 생성했다고 설명한다.
• 테스트 단계에서 버그를 찾고 개발 단계로 되돌리는 구조가 실제로 유효했다는 뜻이다.

---

4) 비용 분석

방법	Software 총 토큰	ML Bench 총 토큰
MetaGPT	60,237	65,355
AutoAgents	52,180	62,585
MetaAgent	47,752	46,289

해석

• MetaAgent는 설계 비용이 아예 없는 건 아니지만,
• 전체적으로는 실전 태스크에서 낮은 총비용 + 높은 성능을 동시에 보여준다.

---

5) Ablation이 말해주는 진짜 핵심

설정	ML Bench	Software	Writing	GPQA
MetaAgent (w/o tool-using)	-	-	0.79	0.52
MetaAgent (w/o optimization)	0.61	0.65	0.65	0.56
MetaAgent (w/o traceback)	0.72	0.35	0.77	0.58
MetaAgent	0.83	0.85	0.86	0.60

이 표에서 읽어야 할 핵심

• Optimization 제거: 전반적으로 크게 떨어진다.
  → 중복 상태 병합이 단순한 후처리가 아니라 성능 핵심이라는 뜻.
• Traceback 제거: 특히 소프트웨어 태스크에서 치명적이다.
  → 버그 수정형 태스크에서는 되돌아가기 능력이 매우 중요하다는 뜻.
• Tool-using 제거: 지식형 텍스트 태스크 성능이 감소한다.
  → 외부 정보 접근이 실제로 도움이 된다.

---

핵심 포인트 5개

포인트 1. 이 논문은 “에이전트 수”보다 “흐름 제어 구조”를 이야기한다

멀티 에이전트 연구는 종종 역할 분담 그 자체에 집중한다.
하지만 MetaAgent는 상태, 전이, 검증, 반복, traceback의 구조가 더 중요하다고 본다.

포인트 2. FSM은 선형 파이프라인의 상위 개념으로 제시된다

논문은 기존 구조를 부정하기보다,

• linear
• debate
• orchestrator
  모두를 FSM의 특수한 경우로 해석한다.

즉, FSM을 공통 언어로 삼아 멀티 에이전트 구조를 일반화하려는 시도다.

포인트 3. “태스크 레벨 설계”라는 관점이 인상적이다

개별 문제마다 프롬프트를 새로 짜는 것이 아니라
“이 도메인 전체를 위한 협업 기계”를 만든다.

포인트 4. 실전 태스크에서는 traceback이 진짜 중요하다

특히 소프트웨어 개발처럼 이전 단계 산출물이 후속 단계 품질을 좌우하는 문제에서는
되돌아가기 없는 구조가 쉽게 무너진다.

포인트 5. 자동 설계라고 해서 공짜는 아니지만, 비용 대비 성능이 좋다

MetaAgent는 설계 단계를 거치지만,
실행까지 포함한 총비용 기준으로도 꽤 경쟁력이 있다.

---

논문이 갖는 의미

이 논문이 흥미로운 이유는, 멀티 에이전트를 단순한 “역할극”이나 “다중 응답 생성”으로 보지 않고
프로세스 제어 문제로 재해석했다는 점이다.

실무적으로 보면 다음에 가깝다.

• PM이 요구사항을 정리하고
• 개발자가 구현하고
• QA가 테스트하고
• 문제가 있으면 다시 앞 단계로 되돌아간다

즉, MetaAgent는 LLM 멀티 에이전트를 소프트웨어 워크플로우에 가까운 제어 시스템으로 만든다.

---

한계와 비판적으로 볼 지점

1. 기반 모델 의존성이 크다

논문에서도 GPT-4o 기반일 때 성능이 가장 좋고,
특히 Executor 모델 품질이 낮아지면 성능이 크게 하락한다고 보고한다.

2. 설계 품질도 결국 LLM 품질에 좌우된다

FSM을 자동 생성한다 해도,

• 어떤 상태를 만들지
• 어떤 조건으로 전이할지
• 어떤 역할을 합칠지

이 모든 것이 디자이너 LLM 판단에 의존한다.

3. 더 큰 실서비스 환경에서의 복잡도는 남아 있다

상태 수가 많아질수록 관리가 어려워질 수 있고,
전이 조건이 복잡해지면 디버깅 난이도도 올라갈 수 있다.

4. 벤치마크 다양성은 아직 더 필요하다

결과는 인상적이지만,

• 더 다양한 도메인
• 장기 실행 태스크
• 실패 비용이 큰 환경
  에서 얼마나 안정적인지는 추가 검증이 필요하다.

---

결론 문단

MetaAgent는 멀티 에이전트 시스템을 유한상태기계(FSM)로 설계해 자동 생성하는 프레임워크다. 이 논문의 핵심은 역할 분담 자체보다, 상태 전이와 검증, 반복 개선, 그리고 이전 단계로의 traceback을 포함한 제어 구조를 설계 대상으로 삼았다는 점이다. 특히 도구 사용과 condition verifier를 결합해, 결과에 따라 같은 상태에서 다시 다듬거나 이전 상태로 되돌아가는 흐름을 만들었다는 점이 실전형 태스크에 강하게 작동한다.

실험에서도 MetaAgent는 텍스트 기반 문제뿐 아니라 ML Bench와 소프트웨어 개발 태스크에서 강한 성능을 보였다. 특히 자동 설계 계열 중 가장 높은 수준의 성능을 내면서도, 비용 측면에서도 경쟁력이 있었다. 결국 이 논문은 “멀티 에이전트를 어떻게 많이 두느냐”보다 “어떤 상태 기계로 제어하느냐”가 더 중요할 수 있음을 보여준다.

---

아주 짧은 결론

MetaAgent의 본질은 ‘멀티 에이전트 자동 설계’보다도, ‘에이전트 협업을 FSM으로 제어하자’는 제안에 있다.
그리고 그 제안은 실제 벤치마크에서 꽤 설득력 있게 작동한다.