한줄 요약: 소프트웨어 회사의 역할 분담(PM→Architect→Engineer→QA)과 표준 산출물(PRD→설계→코드→테스트)을 LLM 에이전트에 적용하여, 기존 멀티에이전트 대비 코드 생성 품질을 크게 향상시켰다.
| 항목 | 내용 |
|---|---|
| 저자 | Sirui Hong, Mingchen Zhuge, Jonathan Chen, Xiawu Zheng, Yuheng Cheng, Ceyao Zhang, Jinlin Wang, Zili Wang, Steven Ka Shing Yau, Zijuan Lin, Liyang Zhou, Chenyu Ran, Lingfeng Xiao, Chenglin Wu, Jürgen Schmidhuber |
| 소속 | DeepWisdom, KAUST |
| 발표 | ICLR 2024 (Oral) |
| 링크 | arxiv.org/abs/2308.00352 |
| 키워드 | Multi-Agent, Software Engineering, Role-Playing, SOP |
1. 문제 정의
기존 멀티에이전트 시스템(ChatDev, CAMEL 등)의 문제:
- 무구조적 대화: 에이전트 간 자유 형식 채팅 → 핵심에서 벗어나는 논의, 반복, 환각 누적
- 역할 모호성: "개발자"와 "테스터"가 명확한 산출물 없이 대화 → 책임 불분명
- 오류 전파: 앞 단계의 잘못된 결정이 검증 없이 다음 단계로 전달
핵심 관찰:
실제 소프트웨어 회사는 자유 대화가 아니라 SOP(표준 운영 절차)로 동작한다:
PM → PRD(요구사항 문서)
Architect → 시스템 설계 문서
Engineer → 코드
QA → 테스트 케이스
→ 이 구조를 멀티에이전트에 적용하면?2. 제안 방법
역할 기반 에이전트 설계
5가지 역할 (실제 소프트웨어 팀 반영):
Product Manager:
입력: 사용자 요구사항 (자연어)
출력: PRD (Product Requirement Document)
→ 기능 목록, 사용자 스토리, 제약 조건 정의
Architect:
입력: PRD
출력: 시스템 설계 (클래스 다이어그램, API 명세, 데이터 구조)
→ 기술적 구조와 인터페이스 정의
Project Manager:
입력: 시스템 설계
출력: 태스크 분해 + 의존성 그래프
→ 구현 순서와 파일 목록 정의
Engineer:
입력: 태스크 + 설계 문서
출력: 코드 파일들
→ 설계에 맞춰 구현
QA Engineer:
입력: 코드 + PRD
출력: 테스트 케이스 + 버그 리포트
→ 요구사항 대비 검증구조화된 커뮤니케이션 (SOP)
기존 멀티에이전트:
Agent A ↔ Agent B ↔ Agent C (자유 대화)
→ 정보 손실, 토픽 드리프트, 환각 증폭
MetaGPT:
PM → [PRD 문서] → Architect → [설계 문서] → Engineer → [코드] → QA
→ 정형화된 산출물(artifact)로 소통
→ 각 에이전트는 이전 산출물을 입력으로 받음
→ 자유 대화 대신 문서 기반 소통Publish-Subscribe 메시지 공유
각 에이전트가 모든 메시지를 받으면:
→ 컨텍스트 오버플로우, 불필요한 정보 노이즈
MetaGPT의 구독 메커니즘:
Engineer가 구독하는 메시지: [시스템 설계, 태스크 분해]
QA가 구독하는 메시지: [PRD, 코드]
→ 각 역할이 필요한 정보만 수신
→ 토큰 사용량 감소 + 관련 정보에만 집중실행 가능한 피드백 루프
Engineer가 코드 생성 후:
1. 자동 실행 (컴파일/런타임 체크)
2. 에러 발생 시 → 에러 메시지 + 코드를 다시 Engineer에게
3. Engineer가 수정
4. 최대 N회 반복
→ "생성 → 실행 → 피드백 → 수정" 루프
→ 실행 불가능한 코드 제출 방지3. 실험 결과
3.1 소프트웨어 생성 벤치마크 (SoftwareDev)
7개 소프트웨어 프로젝트 (게임, 웹앱, 유틸리티):
| 프레임워크 | 실행 가능률 | 평균 코드 품질 (1-5) | 비용 ($) |
|---|---|---|---|
| ChatDev | 57.1% | 2.4 | 0.34 |
| MetaGPT | 85.7% | 3.6 | 1.09 |
| AutoGPT | 14.3% | 1.2 | 2.87 |
→ 실행 가능률이 ChatDev 대비 ~30%p 향상, 비용은 ChatDev보다 높지만 AutoGPT의 1/3
3.2 HumanEval 코드 생성
| 방법 | Pass@1 |
|---|---|
| GPT-4 (직접) | 67.0% |
| ChatDev (GPT-3.5) | 61.8% |
| MetaGPT (GPT-3.5) | 62.8% |
| MetaGPT (GPT-4) | 85.9% |
→ GPT-3.5 기반에서도 ChatDev를 초과, GPT-4와 결합 시 높은 성능
3.3 생성된 코드의 복잡도
| 프레임워크 | 평균 파일 수 | 평균 코드 줄 수 | 구조화 정도 |
|---|---|---|---|
| ChatDev | 3.2 | 128 | 단일 파일 위주 |
| MetaGPT | 8.7 | 472 | 다중 파일, 모듈화 |
→ MetaGPT가 더 현실적이고 구조화된 소프트웨어 생성
3.4 어블레이션
| 변형 | 실행 가능률 |
|---|---|
| MetaGPT (full) | 85.7% |
| − SOP 제거 (자유 대화) | 42.9% |
| − 실행 피드백 제거 | 57.1% |
| − 역할 구분 제거 | 28.6% |
→ 역할 구분과 SOP가 가장 핵심적 요소
4. 한계점
- 비용 증가: SOP의 여러 단계를 거치므로 단일 에이전트 대비 3-5배 API 비용 → 간단한 태스크에는 과잉
- SOP 설계의 수작업: 소프트웨어 개발용 SOP는 저자가 직접 설계 — 새로운 도메인(연구, 마케팅)에 적용하려면 도메인별 SOP 재설계 필요
- 대규모 프로젝트 미검증: 실험은 수백 줄 규모의 프로젝트 — 수천-수만 줄의 실제 소프트웨어에서의 효과 미지수
- 에이전트 간 이견 해소 부족: SOP가 일방향(PM→Architect→Engineer)이므로, Architect가 PM의 요구에 이의를 제기하는 메커니즘 약함
- LLM 능력에 의존: GPT-3.5 기반에서는 복잡한 설계 문서 생성 품질이 불안정
- 동적 역할 조정 불가: 프로젝트 특성에 따라 역할이 추가/축소되어야 하지만, 고정된 5역할 구조
5. 의의와 영향
- "구조가 자유를 이긴다"를 멀티에이전트에서 실증 — SOP + 역할 분담이 자유 대화보다 우월
- 소프트웨어 공학의 방법론(Waterfall, Agile의 산출물 개념)을 AI 에이전트에 이식한 학제간 연구
- ChatDev, CAMEL과 함께 멀티에이전트 코드 생성의 3대 프레임워크
- 후속 연구(AgentVerse, DyLAN, STORM)에서 "구조화된 워크플로우" 패턴의 직접적 영향
- GitHub 12K+ stars → 오픈소스 커뮤니티에서 활발히 사용
6. 💬 리뷰어 코멘트
MetaGPT의 가장 큰 교훈은 "LLM 에이전트도 프로세스 관리가 필요하다"는 것이다. 사람으로 구성된 팀도 자유 토론만으로는 소프트웨어를 만들지 못한다. 요구사항 → 설계 → 구현 → 테스트라는 구조화된 프로세스가 있어야 한다. LLM 에이전트도 마찬가지다.
흥미로운 것은 산출물(artifact)이 커뮤니케이션의 핵심이라는 설계 철학이다. 에이전트 간 대화 대신 문서를 주고받는 것은, 정보 손실을 방지하고 각 단계의 출력 품질을 검증 가능하게 만든다. 이는 현실 소프트웨어 개발에서 코드 리뷰와 설계 문서가 존재하는 이유와 정확히 같다.
한계로는 일방향 워터폴 구조가 반복적 수정(iteration)에 약하다는 점이 있다. 실제 개발에서는 "구현하다 보니 설계를 바꿔야 한다"는 상황이 빈번한데, MetaGPT의 SOP는 이를 충분히 지원하지 못한다.
관련 논문: ChatDev, CAMEL, AutoGen, AgentVerse, SWE-Agent
