멀티에이전트 두 토폴로지 — 위: Main Session 이 spawn(task, selected_context) 으로 Sub Agent 를 띄우고 Result Summary·Artifact 를 부모에 병합한다. 아래: Session A(Claude)·B(codex)·C(Hermes) 가 각자 own loop/tools 를 가진 채 explicit Protocol / API / MCP 라는 공용 바를 통해서만 handoff 한다

이 그림은 “멀티에이전트”라는 한 단어에 뭉뚱그려 들어가 있는 서로 다른 두 구조를 위아래로 갈라 놓았다. 위는 부모가 자식을 소유하고, 아래는 아무도 아무를 소유하지 않는다. 둘은 잘하는 일도 다르고, 무엇보다 고장 나는 방식이 다르다.

위쪽 — 서브에이전트는 “부모가 소유한 도구”다

그림에서 가장 중요한 글자는 화살표 옆의 주석이다.

spawn(task, selected_context) — Tool which is owned by Main

서브에이전트는 동료가 아니라 부모의 도구다. 박스 안에 적힌 세 줄이 그걸 그대로 보여준다.

항목 값 누가 정하나
System Prompt “You are a ~~~” 부모(또는 정의 파일)
User Prompt “handoff” 부모
Context “Parent picked files” 부모가 골라서 넣는다

세 줄 모두 부모에서 내려온다. 자식은 자기가 무엇을 볼지 스스로 정하지 않는다. 그리고 돌아오는 것은 작업 전체가 아니라 Result Summary, Artifact — 요약과 산출물이고, 그것이 Main Session (Parent에 병합) 된다.

이 구조를 왜 쓰는지도 공식 문서에 그대로 적혀 있다. Anthropic 의 Claude Code 문서는 서브에이전트를 “부수 작업이 메인 대화를 검색 결과·로그·파일 내용으로 범람시킬 때” 쓰라고 하면서, 각 서브에이전트가 자기만의 컨텍스트 윈도우, 커스텀 시스템 프롬프트, 별도의 도구 접근 권한을 갖고 독립적으로 일한 뒤 결과만 돌려준다고 설명한다.1

즉 위쪽 구조의 본질은 병렬 처리가 아니라 컨텍스트 격리다. 부모의 대화창을 더럽히지 않으려고 더러운 일을 옆방에서 시키는 것이다. 문서가 드는 이득도 그 순서다 — 컨텍스트 보존, 도구 제한을 통한 제약 강제, 설정 재사용, 도메인 특화, 그리고 값싼 모델로 라우팅해 비용 통제.1

여기서 조용한 대가가 하나 있다. 컨텍스트를 부모가 고른다는 것은, 부모가 잘못 고르면 자식은 그 사실조차 모른다는 뜻이다. 자식은 “내가 못 본 파일이 있다”고 항의할 방법이 없다. 위쪽 구조의 정확도 상한은 결국 부모의 선별 능력이 결정한다.

아래쪽 — 세션은 각자 자기 루프를 가진다

아래 초록 박스 셋은 성격이 완전히 다르다. Session A (Claude), Session B (codex), Session C (Hermes) 는 각각 own loop / tools 를 갖고 있다. 누가 누구를 띄운 게 아니다. 각자 자기 판단으로 돌고, 자기 도구를 쓴다.

그래서 이들이 만나는 지점이 하나뿐이다 — 맨 아래 파란 바, explicit Protocol / API / MCP handled. 서로의 머릿속을 공유하지 않고, 명시적으로 정해둔 것만 주고받는다.

이 원칙을 가장 또렷하게 문서화한 것이 Linux Foundation 의 A2A(Agent2Agent) 명세다. A2A 는 설계 원칙에 Opaque Execution 을 명시한다 — 에이전트들은 “선언된 능력과 교환된 정보”에 근거해 협업하며, 서로의 내부 사고·계획·도구 구현을 공유할 필요가 없다.2 목표 역시 “서로의 내부 상태·메모리·도구에 접근하지 않고” 안전하게 정보를 교환하는 것이다.2

Claude Code 쪽도 같은 선을 긋는다. 세션 간 메시지 기능의 문서는 이렇게 못 박는다 — “메시지는 한 Claude 가 다른 Claude 에게 쓰는 텍스트 조각이며, 대화 기록이나 파일이 아니다.” 대화 전체를 옮기고 싶으면 메시지가 아니라 세션 재개(resume)를 쓰라고 한다.3

그림이 뭉뚱그린 지점 하나

파란 바에 Protocol / API / MCP 가 나란히 적혀 있는데, 여기는 조심할 필요가 있다. MCP 는 원래 에이전트-에이전트 축의 규격이 아니다. MCP 명세는 스스로를 host–client–server 구조로 정의하며, 호스트가 여러 클라이언트를 만들고 각 클라이언트가 서버 하나와 1:1 로 붙는다. 설계 원칙에는 “서버는 대화 전체를 읽을 수 없어야 하고 다른 서버를 들여다볼 수도 없어야 한다”가 들어 있다.4

즉 MCP 는 에이전트가 도구·컨텍스트에 닿는 축이고, A2A 는 에이전트끼리 닿는 축이다. 그림처럼 한 바에 모아 그리면 “세션 간 협업 = MCP” 로 읽히기 쉬운데, 실제로는 MCP 서버를 공유 게시판처럼 쓰는 것은 관례일 뿐 규격이 보장하는 협업 모델이 아니다.

갈림길은 하나다 — 누가 컨텍스트를 소유하는가

두 구조를 가르는 축은 병렬성도, 에이전트 수도 아니다.

  위쪽 (서브에이전트) 아래쪽 (세션 협업)
소유권 부모가 자식을 소유 아무도 소유하지 않음
컨텍스트 부모가 골라서 준다 각자 스스로 만든다
통신 생성 시 1회 + 종료 시 요약 1회 살아 있는 동안 계속, 프로토콜로만
결과 부모에 병합 각자 자기 결론을 유지
종료 부모가 끝내면 같이 끝 서로 무관하게 살고 죽음
주 실패 모드 부모가 컨텍스트를 잘못 고름 / 병합 지점 병목 공유 자원 경합, 교착, 중복 작업

공식 문서도 이 갈래를 그대로 안내한다. 서브에이전트 문서는 “서브에이전트는 하나의 세션 안에서 동작한다”고 명시하고, 서로 메시지를 주고받는 독립 세션이 필요하면 cross-session messaging 을, Claude 가 띄우고 감독하는 팀이 필요하면 agent teams 를 보라고 갈라준다.1 에이전트 팀 문서는 선택 기준을 한 문장으로 준다 — “작업자들이 서로 통신해야 하는가” 로 고르라는 것이다.5

아래쪽 구조를 실제로 굴려 보면 — 내가 겪은 것

여기부터는 공식 문서가 아니라 내 환경에서의 관측이다(재현 조건이 특수하므로 일반화하지 않는다).

나는 텔레그램에 붙은 Claude Code 세션 4개(bot1~bot4)를 동시에 돌리고 있다. 그림 아래쪽 구조 그대로다 — 서로 부모-자식이 아니고, 각자 자기 루프를 돌며, 같은 저장소를 본다.

2026년 8월 20일, 그 넷이 한 저장소의 같은 브랜치(develop)에 각자 판단으로 push 했다. 결과는 이랬다.

  • git push 가 non-fast-forward 로 거절됨 — 다른 세션이 먼저 올린 커밋 위에 얹으려 해서. rebase 후 재시도로 해결.
  • CI 워크플로에 cancel-in-progress 가 걸려 있어서, 새 push 가 앞선 run 을 취소했다. 연속 4개 run 이 cancelled 로 끝났다. 15~28분 걸리는 CI 보다 네 세션의 push 간격이 더 짧았기 때문이다.
  • 그 결과 나는 내가 만든 수정이 동작하는지 확인할 수 없었다. 취소된 run 은 증명도 반증도 못 한다.

여기서 배운 것은 그림의 파란 바가 왜 explicit 인가다. 네 세션이 “같은 저장소를 본다”는 것은 프로토콜이 아니다. 공유 자원은 채널이 아니다. 파일을 같이 본다고 협업이 되는 게 아니라, 누가 언제 무엇을 잡는지 를 명시적으로 정해야 협업이 된다. A2A 가 능력 발견(discovery)과 태스크 수명주기를 규격 안에 넣어 둔 이유가 이것이다.2

반대로 위쪽 구조에서는 이 사고가 원천적으로 안 난다. 부모가 자식을 띄우고 결과를 받아 병합하므로, 경합할 지점이 병합 한 곳으로 모인다. 대신 그 한 곳이 병목이 되고, 자식이 많아질수록 부모의 컨텍스트가 요약으로 채워진다. 에이전트 팀 문서가 “조율 오버헤드가 있고 단일 세션보다 토큰을 훨씬 많이 쓴다“고 경고하는 것도 같은 맥락이다.5

그래서 무엇을 고르나

문서와 경험을 합치면 판단 기준은 단순해진다.

위쪽(서브에이전트)을 고르는 경우 — 작업이 부모의 목표에 종속돼 있고, 결과가 요약 한 덩어리로 압축돼도 손실이 없을 때. 탐색·조사·리뷰처럼 “많이 읽고 조금 남기는” 일이 전형이다. 도구를 제한해 제약을 강제하고 싶을 때도 여기다.1

아래쪽(세션 협업)을 고르는 경우 — 작업자들이 서로 결론을 주고받아야 하고, 각자 오래 살아야 하며, 서로 다른 벤더/런타임일 때. 그림이 Claude·codex·Hermes 를 나란히 그린 것이 정확히 이 경우다. A2A 가 “서로 다른 프레임워크·언어·벤더로 만들어진 에이전트들”을 전제로 출발하는 것과 같다.2

그리고 아래쪽을 고른다면 채널을 먼저 만들고 시작해야 한다. 나처럼 채널 없이 넷을 풀어두면, 협업이 아니라 경합을 하게 된다.

이 그림이 말하지 않는 것

마지막으로 한계를 정직하게 적어 둔다.

  1. 위쪽의 병합 비용이 안 보인다. Result Summary, Artifact 는 화살표 하나로 그려져 있지만, 실제로는 요약 품질이 전체 정확도를 좌우한다. 자식이 본 것 중 무엇을 버릴지가 그림에는 없다.
  2. 아래쪽에 중재자가 없다. 셋이 동시에 같은 파일을 고치겠다고 하면 누가 양보하는지 그림은 답하지 않는다. 실제 시스템에서는 락·리스·순번 같은 것이 파란 바 안에 들어가야 한다.
  3. 두 구조는 배타적이지 않다. 아래쪽 세션 하나가 위쪽 구조를 품는 게 오히려 흔하다 — 세션 A 가 자기 안에서 서브에이전트를 여럿 띄우고, 그 결과만 세션 B 에 프로토콜로 넘긴다. 그림을 “둘 중 하나를 고르는 문제”로 읽으면 오히려 손해다.

References

본문 중 “내가 겪은 것” 절의 수치(연속 4개 run 취소, non-fast-forward 거절)는 2026-08-20 내 개인 환경에서의 관측이며 벤더 문서가 뒷받침하는 값이 아니다. 조율 없이 병렬 세션을 돌릴 때 무엇이 깨지는지의 사례로만 읽어 주기 바란다.

  1. Anthropic, Create custom subagents (Claude Code Docs). https://docs.claude.com/en/docs/claude-code/sub-agents — 서브에이전트의 독립 컨텍스트 윈도우·커스텀 시스템 프롬프트·도구 접근 제한, “결과만 반환”, “하나의 세션 안에서 동작”, 사용 이득 5가지. ↩ ↩2 ↩3 ↩4

  2. The Linux Foundation, Agent2Agent (A2A) Protocol Specification v1.0.0. https://a2a-protocol.org/latest/specification/ — 독립적·불투명한 에이전트 시스템 간 상호운용, Opaque Execution 원칙, 능력 발견·태스크 수명주기, JSON-RPC 2.0/HTTP/SSE 기반. ↩ ↩2 ↩3 ↩4

  3. Anthropic, Message your other Claude Code sessions (Claude Code Docs). https://docs.claude.com/en/docs/claude-code/cross-session-messaging — “메시지는 텍스트 조각이며 대화 기록이나 파일이 아니다”, ListAgents/SendMessage, 병렬 워크트리 조율 사례. ↩

  4. Model Context Protocol, Architecture (Specification 2025-06-18). https://modelcontextprotocol.io/specification/2025-06-18/architecture — host–client–server 구조, 클라이언트-서버 1:1, “서버는 대화 전체를 읽을 수 없고 다른 서버를 볼 수 없다”. ↩

  5. Anthropic, Orchestrate teams of Claude Code sessions (Claude Code Docs). https://docs.claude.com/en/docs/claude-code/agent-teams — 실험적 기능(CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS), 서브에이전트와의 선택 기준(“작업자들이 서로 통신해야 하는가”), 조율 오버헤드·토큰 비용 경고. ↩ ↩2