69.3k 스타, ICLR 2025 oral, “First AI Software Company”. MetaGPT는 멀티에이전트 프레임워크의 기준점이다. 근데 이 글은 코드 예제나 설치법을 설명하지 않는다. 왜 MetaGPT가 그렇게 설계되었는지, 그 철학적 선택을 추적하는 글이다.

문제: 체인으로 연결된 환각

2023년 초, LLM 기반 멀티에이전트 시스템은 대부분 “A가 말하면 B가 답한다”는 단순 채팅 체인이었다. 논리적 일관성은 체인의 길이에 반비례했다. 캐스케이딩 환각 — 앞 에이전트의 작은 오류가 뒤로 갈수록 증폭되는 패턴 — 이 복잡한 작업을 가로막았다.

MetaGPT 팀이 보기에, 이 문제의 근본 원인은 “에이전트에게 역할만 주고 일하는 방법은 알아서 정하라”는 접근이었다. 도메인 전문성의 부재가 캐스케이딩 환각을 부르는 거다.

코어 철학: Code = SOP(Team)

MetaGPT의 가장 중요한 문장을 꼽으라면 이것이다: Code = SOP(Team). 소프트웨어 회사의 표준 운영 절차(SOP)를 그대로 에이전트 팀에 이식했다. 프롬프트 체인에 SOP를 인코딩해서 워크플로를 표준화하고, 각 에이전트가 인간과 같은 도메인 전문성을 갖게 했다.

이 철학은 두 가지 통찰에서 나온다:

  • 인간 조직은 이미 최적화되어 있다: 수십 년간 소프트웨어 회사가 발전시킨 역할 분담과 SOP는 LLM 에이전트에도 적용 가능한 패턴이다
  • 구조가 자유보다 낫다: 완전한 자유를 주는 것보다 정해진 역할과 검증 단계가 더 일관된 결과를 만든다

무엇을 배울 수 있는가

이 글에서 다루는 것:

  • Assembly Line 패러다임 — 다양한 역할을 에이전트에 할당하고 조립 라인처럼 작업을 분해하는 방식
  • SOP-driven Workflow — 표준화된 절차가 일관성을 높이는 메커니즘
  • Meta Programming의 의미 — 프로그램으로 프로그램을 생성한다는 개념이 멀티에이전트 시스템에서 어떻게 구현되는지
  • Drewgent와의 연결점 — 내가 운영하는 에이전트 시스템과 MetaGPT의 설계 선택이 만나는 지점

왜 SOP인가

Chat-based 멀티에이전트 시스템이 가진 근본적인 문제는 검증 부재다. Agent A가 “이 API가 좋을 것 같아”라고 말하면 Agent B가 “좋아, 그걸로 가자”고 답한다. A의 틀린 가정이 B를 거쳐 C로 전파되고, 최종 출력은 완성된 것처럼 보이지만 내부는 모순투성이다.

MetaGPT는 SOP를 도입해서 이 문제를 해결한다. 각 단계마다 검증 게이트가 있다. Product Manager가 요구사항을 쓰면, Architect가 검증한다. Architect 디자인이 나오면, Project Manager가 작업을 분할한다. 각 단계는 이전 단계의 출력을 검증하는 역할도 겸한다.

이게 “채팅”과 “프로세스”의 차이다. 채팅은 자유롭지만 검증이 없다. 프로세스는 덜 자유롭지만 오류를 잡는다.

조립 라인: 대규모 해체

“Create a 2048 game” — 한 줄의 요구사항을 MetaGPT에 넣으면, 여섯 개의 역할이 협력해서 완전한 레포지토리를 생성한다:

  • Boss: 요구사항 진입점. 하나의 목표를 팀에 전달한다
  • Product Manager: 요구사항을 User Story와 경쟁 분석 문서로 변환한다
  • Architect: 데이터 구조, API 설계, 기술 선택을 결정한다
  • Project Manager: 작업을 분할하고 배정한다
  • Engineer: 실제 코드를 작성한다
  • QA Engineer: 결과물을 검증한다

이 구조를 Mermaid로 그리면 이렇다:

flowchart LR
  Boss --> PM[Product Manager]
  PM --> Architect
  Architect --> PMgr[Project Manager]
  PMgr --> Engineer1
  PMgr --> Engineer2
  PMgr --> Engineer3
  Engineer1 --> QA
  Engineer2 --> QA
  Engineer3 --> QA
  QA --> Output[(Generated Repo)]

  style Boss fill:#7b5f3d,color:#fff
  style PM fill:#4a90d9,color:#fff
  style Architect fill:#4a90d9,color:#fff
  style PMgr fill:#4a90d9,color:#fff
  style QA fill:#50c878,color:#fff

메타 프로그래밍: LLM으로 LLM을 제어하다

MetaGPT의 “Meta”는 단순한 이름이 아니다. 메타 프로그래밍 — 프로그램이 프로그램을 생성하는 패러다임 — 이 프레임워크의 핵심이다.

전통적인 메타 프로그래밍이 코드로 코드를 생성한다면, MetaGPT는 자연어 명세로 소프트웨어를 생성한다. LLM 그 자체가 메타 계층의 실행 엔진이고, SOP는 그 엔진이 따라야 할 컴파일 규칙이다.

이 관점에서 보면 멀티에이전트 시스템은 단순한 “여러 AI가 대화하는 것”이 아니라 분산 메타 컴파일러다. 각 에이전트는 컴파일 패스 하나를 담당하고, SOP는 그 패스들의 실행 순서를 정의한다.

핵심 설계 결정

MetaGPT의 설계에서 주목할 만한 결정과 그 트레이드오프:

결정 이유 트레이드오프
SOP를 프롬프트에 인코딩 에이전트 행동의 일관성 확보 프롬프트가 길어지고 유연성이 감소
고정된 역할 할당 도메인 전문성 극대화 새로운 역할 추가 시 프레임워크 수정 필요
순차적 조립 라인 단계적 검증으로 오류 차단 병렬 처리보다 느림
단일 입력 → 전체 산출물 사용자 경험 단순화 중간 개입이 어려움
Python 베이스 + CLI 개발자 접근성 극대화 비개발자 사용성 제한

Drewgent와의 대화

이 프레임워크를 보면서 Drewgent와 비교하지 않을 수 없었다. 몇 가지 흥미로운 접점:

  • SOP vs Domain Router: MetaGPT가 SOP를 프롬프트에 하드코딩했다면, 나는 Domain Router 플러그인으로 에이전트의 컨텍스트를 분류해서 주입한다. 같은 목표(일관성)에 다른 접근.
  • 고정 역할 vs Pillar Writers: MetaGPT는 6개 역할을 고정했다. 나도 비슷하게 4개 Pillar Writer(engineer/researcher/philosopher/creative)를 할당한다. 역할 분담이 효과적이라는 공통된 발견.
  • 조립 라인 vs Orchestrator: MetaGPT의 순차적 조립 라인을 my content pipeline의 orchestrator + parallel spawn이 더 유연한 방식으로 구현하고 있다. 병렬성과 검증의 균형.

가장 큰 차이점은 MetaGPT가 “AI가 소프트웨어 회사를 대체한다”는 비전에서 출발한 반면, 나는 “인간 개발자를 돕는 AI”에 초점을 맞췄다는 점이다. 같은 기술이 다른 철학으로 이어질 수 있다는 게 재미있다.

철학의 현재와 미래

MetaGPT의 설계 철학이 중요한 이유는 이것이 하나의 레퍼런스 아키텍처이기 때문이다. 앞으로 나올 멀티에이전트 프레임워크들은 MetaGPT의 결정 중 일부를 계승하고 일부를 거부할 것이다.

이미 2025년에는 Agent Teaming, AutoGen, CrewAI 등이 다른 접근을 시도하고 있다. “단일 시스템 프롬프트에 모든 걸 담는다”는 접근은 줄어들고, 역할 분담과 프로세스 기반 설계는 늘어나는 추세다.

MetaGPT가 증명한 것은 이것이다: 소프트웨어 공학의 모범 사례는 AI 에이전트 세계에서도 여전히 유효하다. SOP, 역할 분담, 단계적 검증 — 인간 개발자를 위해 발전된 이 패턴들은 AI가 코드를 쓰는 세상에서도 사라지지 않는다. 모양이 바뀔 뿐.

—

읽어줘서 고맙다. 다음 글에서는 Agent Teaming이나 AFlow 논문을 파보려고 한다. 궁금한 거 있으면 코멘트 남겨줘.