에이전트 설계 ⑥ — 멀티에이전트: 읽기는 병렬, 쓰기는 단일

2025년 최대의 설계 논쟁이었고, 2026년엔 사실상 종결됐다. 양쪽의 근거와 종합, 그리고 실패 통계까지.

찬성: Anthropic의 리서치 시스템

오케스트레이터-워커 구조(Opus 리드 + Sonnet 워커 병렬)가 단일 에이전트 대비 내부 리서치 평가 +90.2%, 병렬 도구 호출로 시간 최대 90% 단축. 대신 토큰은 일반 챗의 ~15배 — 성능 분산의 80%를 토큰 소비가 설명한다. 적합 과제: "S&P 500 IT 기업 이사회 전원 조사" 같은 breadth-first 병렬 탐색.

반대: Cognition의 "Don't Build Multi-Agents"

Devin 팀의 2원칙: ① 컨텍스트는 개별 메시지가 아니라 전체 트레이스를 공유해야 하고, ② 모든 행동에는 암묵적 결정이 담겨 병렬 작업의 결정들이 충돌한다. Flappy Bird 예제 — 서브에이전트 둘이 서로 다른 스타일 가정을 해서 합칠 수 없는 결과물. 코딩의 정답은 단일 스레드 + 히스토리 압축.

종합 — 이제는 합의

LangChain의 정리가 정확하다: 읽기 중심(리서치·탐색)은 병렬화되고, 쓰기 중심(코딩·문서 작성)은 안 된다. Anthropic 시스템조차 읽기는 병렬, 최종 보고서 작성은 단일 에이전트로 수렴시킨다. 진짜 쟁점은 아키텍처가 아니라 각 에이전트에게 충분한 컨텍스트를 전달하는가("반도체 부족 조사해줘" 같은 모호한 위임이 중복·오해의 근원). 실무 규칙: 핸드오프 시 전체 트레이스 전달(OpenAI Agents SDK handoff의 기본값이 이것), 최종 쓰기·결정은 반드시 한 에이전트로.

실패는 어디서 오나 — MAST 통계

Berkeley의 MAST(ICML 2025, 1,600+ 트레이스 전문가 주석): 14개 실패 모드 중 명세·설계 문제 41.8% + 검증·종료 문제 21.3% + 에이전트 간 불일치 36.9% — 즉 실패의 대부분이 모델 성능이 아니라 오케스트레이션 설계 결함이다. 모델을 업그레이드하기 전에 명세 프롬프트와 검증 단계부터 고쳐라. 같은 맥락: MASS 연구(ICLR 2026)는 토폴로지 튜닝보다 개별 에이전트 프롬프트 최적화가 먼저이고 효과도 크다고 보고. CrewAI조차 공식 문서에서 프로덕션엔 자율 크루가 아닌 결정론적 Flow로 구속하라고 권한다.

생태계 표지판

Swarm→OpenAI Agents SDK(handoffs), AutoGen→AG2/Microsoft Agent Framework로 계보 정리. 조직 경계를 넘는 에이전트 간 통신은 A2A 프로토콜(Linux Foundation, v1.0)이 표준이 됐다 — B2B 에이전트 서비스라면 Agent Card 공개를 전제로 설계. 살아남은 역할 기반 아이디어는 페르소나가 아니라 구조화된 아티팩트로 통신하기(MetaGPT의 교훈). 관리형으로는 AWS Bedrock 멀티에이전트가 계층 3단계 제한을 두는 것 자체가 실무 상한선의 방증이다.

한 줄 요약: 에이전트 수를 늘리기 전에, 지금 있는 에이전트 하나에게 컨텍스트를 제대로 주고 있는지부터 확인하라.

— 에이전트 설계 시리즈 ⑥ / 다음 글: 안전과 가드레일 — 인젝션은 막는 게 아니라 무해하게 만드는 것