멀티 에이전트 토폴로지는 여러 LLM 에이전트를 어떤 모양으로 연결해 일을 나누고 결과를 모을지 정하는 구조다. 네트워크에서 토폴로지가 노드가 연결된 모양(스타형·링형·메시형)을 가리키듯, 여기서는 에이전트끼리 연결된 모양을 가리킨다. 각 에이전트 안에서는 똑같이 에이전트 루프가 돌고, 토폴로지는 그 루프들을 서로 어떻게 잇느냐의 문제다.
네 가지 모양
단일 [에이전트] ─ 도구들
수퍼바이저 [오케스트레이터] → 워커 A · 워커 B · 워커 C → 오케스트레이터가 취합
파이프라인 [수집] → [검증] → [요약]
스웜 [A] ⇄ [B] ⇄ [C] (서로 제어를 넘김)- 단일 에이전트: 에이전트 하나가 도구를 쓰며 루프를 돈다. 대부분의 일은 여기서 끝난다
- 수퍼바이저(스타형): 중앙 에이전트가 일을 쪼개 워커 에이전트에게 맡기고 결과를 합친다. Anthropic은 이를 오케스트레이터-워커(Orchestrator-Workers)라 부르는데, 하위 작업을 미리 정해 두지 않고 입력을 보고 그때 나눈다는 점이 단순 병렬 실행과 다르다. 워커는 각자 따로 컨텍스트를 쓰므로 시끄러운 탐색을 중앙에서 떼어 낼 수 있다(하네스 엔지니어링의 서브에이전트). 반대로 모든 일이 중앙을 거치니 중앙이 병목이 될 수 있다. 워커 자리에 하위 에이전트 팀을 두면 계층형(Hierarchical Teams)이 된다
- 파이프라인(직렬): 앞 단계의 출력이 다음 단계의 입력이 된다. Anthropic의 프롬프트 체이닝(Prompt Chaining)과 같은 모양이다. 순서가 고정된 일에 맞고, 단계마다 무엇이 들어오고 나가는지 분명하다
- 스웜(메시형): 중앙 없이 각 에이전트가 자기 전문 분야에 맞춰 다른 에이전트에게 제어를 넘긴다(핸드오프, Handoff). LangGraph Swarm은 마지막으로 활성화된 에이전트를 기억해 다음 대화를 그 에이전트에서 이어 간다. 흐름이 미리 정해져 있지 않아서, 결과가 이상하면 어느 에이전트에서 틀어졌는지 넘긴 기록을 따라가야 한다
에이전트들이 메시지 기록을 어떻게 나누는지도 구조를 가른다. 기록 하나를 함께 쓰면 서로의 중간 과정이 다 보이지만 필요 없는 내용까지 쌓인다. LangGraph의 수퍼바이저 예처럼 각자 기록을 따로 두고 최종 결과만 넘기면 컨텍스트는 가벼워지지만 맥락을 넘기는 방법을 따로 설계해야 한다.
단일로 시작하고, 병목이 보일 때 나눈다
Anthropic은 가장 단순한 해법을 찾고 필요할 때만 복잡도를 늘리라고 권한다. 에이전트를 늘리면 비용이 빠르게 커지기 때문이다. Anthropic의 리서치 시스템 사례에서 에이전트는 채팅보다 토큰을 약 4배, 멀티 에이전트 시스템은 약 15배 썼다(2025 기준).
- 잘 맞는 일: 서로 독립적인 방향이 많아 나눠서 동시에 조사할 수 있는 일, 한 컨텍스트에 다 들어가지 않는 정보, 다뤄야 할 도구가 많은 일. 같은 사례에서 Claude Opus 4가 이끌고 Sonnet 4 서브에이전트가 일하는 구조가 단일 Opus 4보다 내부 리서치 평가에서 90.2% 앞섰다
- 안 맞는 일: 모든 에이전트가 같은 맥락을 공유해야 하는 일, 에이전트끼리 의존이 많은 일. 대부분의 코딩 작업은 조사보다 병렬로 나눌 부분이 적어 여기에 가깝다
그래서 실무에서는 단일 에이전트로 시작한다. 컨텍스트가 넘치거나 독립적인 하위 작업이 분명히 보이는 병목이 생기면 그때 수퍼바이저나 파이프라인으로 나눈다. 만든 결과를 따로 검사하는 둘짜리 구조는 생성과 평가 분리, 토큰이 새는 지점은 LLM 사용 습관에서 다룬다. 정해진 자료 조각을 한 번 찾아 넣는 RAG (검색 증강 생성)와 달리, 수퍼바이저형 리서치 에이전트는 찾은 결과를 보고 다음 검색을 정한다.
출처: Building effective agents Anthropic · How we built our multi-agent research system Anthropic(2025) · Multi-agent LangChain 문서 · LangGraph: Multi-Agent Workflows LangChain 블로그(2024) · langgraph-swarm-py LangChain