요약 버전: 스웜 (Swarm) 내에서는 여러 전문화된 에이전트들이 중앙 오케스트레이터 (Orchestrator) 없이 서로 직접 대화하고, 발견한 내용을 공유하며, 함께 솔루션을 정교화합니다. Google은 이를 Cloud Architecture Center 가이드에서 가장 강력하면서도 가장 비용이 많이 드는 멀티 에이전트 패턴 (Multi-agent pattern)으로 명명했습니다. 문제가 진정으로 토론을 통해 이득을 얻을 수 있는 경우에만 이 패턴을 사용하십시오.

스웜 패턴 (Swarm pattern)이란 무엇인가?

스웜 패턴은 협력적인 전방위 (All-to-all) 통신 방식을 사용하며, 여기서 여러 전문화된 에이전트들이 복잡한 문제에 대한 솔루션을 반복적으로 정교화하기 위해 함께 작동합니다 (Google Cloud). 핵심적인 특징은 각 에이전트가 다른 모든 에이전트와 통신할 수 있으며, 발견한 내용을 공유하고, 제안을 비판하며, 서로의 작업 내용을 바탕으로 발전시켜 나갈 수 있다는 점입니다.

이것이 스웜을 코디네이터 패턴 (Coordinator pattern)과 구분 짓는 요소입니다. 스웜은 일반적으로 프로세스를 궤도에 유지시키는 중앙 감독관 (Central supervisor)이 없습니다. 디스패처 에이전트 (Dispatcher agent)가 초기 요청을 라우팅하고 통신을 촉진하지만, 코디네이터가 하는 방식처럼 워크플로 (Workflow)를 오케스트레이션 (Orchestrate)하지는 않습니다 (Google Cloud).

Diagram: three peer agents, researcher, engineer, and finance, pass work around a shared task, converging on consensus.

실제 작동 방식

디스패처 (Dispatcher)가 요청을 해석하고 어떤 에이전트가 시작해야 할지 결정합니다. 그 이후부터는 어떤 에이전트든 다음 단계에 더 적합하다고 판단되는 다른 에이전트에게 작업을 넘기거나, 디스패처를 통해 사용자에게 최종 답변을 반환할 수 있습니다 (Google Cloud).

프로세스를 중단할 오케스트레이터 (Orchestrator)가 없기 때문에, 명시적인 종료 조건 (exit condition)을 정의해야 합니다. Google은 이것이 종종 최대 반복 횟수, 시간 제한, 또는 합의 (consensus) 도달과 같은 특정 목표의 달성임을 명확히 하고 있습니다 (Google Cloud). 종료 조건이 없다면, 스웜 (swarm)은 자연스럽게 끝날 지점을 찾지 못합니다.

사용 시점

토론과 반복적인 개선 (iterative refinement)을 통해 이득을 얻을 수 있는 모호하거나 매우 복잡한 문제에 스웜을 사용하십시오 (Google Cloud). Google의 예시는 제품 설계입니다. 시장 조사 에이전트 (market researcher agent), 엔지니어링 에이전트 (engineering agent), 그리고 재무 모델링 에이전트 (financial modeling agent)가 아이디어를 공유하고, 기능과 비용 사이의 트레이드오프 (trade-offs)를 토론하며, 상충하는 요구 사항들 사이에서 균형을 맞춘 사양 (specification)으로 수렴합니다.

그 가치는 여러 전문가의 관점을 합성 (synthesis)하는 데 있습니다. 정답이 여러 전문가가 서로에게 진정으로 반응하는 것에 달려 있을 때, 스웜은 단일 에이전트나 경직된 파이프라인 (pipeline)이 만들어낼 수 없는 결과를 생성할 수 있습니다.

사용하지 말아야 할 시점

더 단순한 패턴이 적합할 때는 스웜을 사용하지 마십시오. 작업에 알려진 구조가 있다면, 순차적 파이프라인 (sequential pipeline)이나 코디네이터 (coordinator)가 비용이 더 저렴하고 제어하기 훨씬 쉽습니다. 예측 가능한 지연 시간 (latency)이나 비용이 필요할 때도 사용하지 마십시오. 동적이고 모든 에이전트 간의 통신 (all-to-all conversation)은 이 두 가지를 보장하지 않기 때문입니다. 또한, 확실한 종료 조건을 정의할 수 없을 때도 사용하지 마십시오. 중단 규칙이 없는 끝없는 토론은 비용 폭주 (runaway cost)의 원인이 됩니다.

Google 자체의 비교 표는 이 특성을 명확하게 지적합니다: 에이전트 간의 동적이고 모든 에이전트 간의 통신으로 인한 높은 지연 시간과 운영 비용 (Google Cloud). 이것이 감수해야 할 대가입니다.

알려진 문제점

스웜 (Swarm)은 구현하기에 가장 복잡하고 비용이 많이 드는 멀티 에이전트 패턴입니다 (Google Cloud). 두 가지 문제가 이를 유발합니다.

첫째, 수렴 (convergence)이 보장되지 않습니다. 어떤 에이전트도 오케스트레이션 (orchestrate)을 위해 모델을 사용하지 않기 때문에, 이 패턴은 비생산적인 루프에 빠지거나 해결책으로 수렴하는 데 실패할 수 있습니다 (Google Cloud). 에이전트들이 합의에 도달하지 못한 채 서로 겉도는 대화만 할 수 있습니다.

둘째, 통신 자체를 관리하기가 어렵습니다. 에이전트 간의 통신을 제어하고, 반복적인 워크플로 (workflow)를 관리하며, 에이전트 간의 다회차 대화 (multi-turn conversation)에서 발생하는 상당한 비용과 지연 시간 (latency)을 처리하기 위해 정교한 로직을 설계해야 합니다 (Google Cloud). 이 패턴은 멀티 에이전트 설계가 가장 자주 취약해지는 지점이므로, 많은 팀이 이를 기본값(default)보다는 최후의 수단으로 남겨둡니다.

시작하기 전에 알아야 할 세 가지

1. 종료 조건 (exit condition)을 먼저 정의하세요. 오케스트레이터 (orchestrator)가 없으므로, 반복 횟수 제한, 시간 제한 또는 합의 목표 (consensus goal)만이 실행을 종료할 수 있는 유일한 수단입니다.
2. 카탈로그에서 가장 높은 비용을 예상하세요. 전체 대 전체 (all-to-all) 방식의 대화는 모델 호출 (model calls)을 배가시킵니다. 이에 따라 예산을 책정하세요.
3. 먼저 코디네이터 (coordinator)를 시도해 보세요. 중앙 에이전트가 경로를 지정하고 결합할 수 있다면, 아마도 스웜이 필요하지 않을 것입니다. 토론 자체가 목적일 때만 스웜을 사용하세요.

FAQ

스웜은 코디네이터와 어떻게 다른가요?
코디네이터는 모델을 사용하여 작업을 오케스트레이션하고 경로를 지정합니다. 스웜은 오케스트레이터가 없습니다. 동료(peers)들이 전체 대 전체 (all-to-all)로 통신하고 서로에게 업무를 넘기며, 디스패처 (dispatcher)는 이를 촉진하는 역할만 수행합니다.

스웜은 왜 그렇게 비용이 많이 드나요?
동적인 전체 대 전체 (all-to-all) 통신은 다회차 대화 (multi-turn conversation) 전반에 걸쳐 많은 모델 호출을 의미하며, 이는 여기서 다루는 다른 어떤 패턴보다 지연 시간과 비용을 모두 높입니다.

스웜 (Swarm)이 무한 루프에 빠지는 것을 어떻게 방지하나요?
명시적인 종료 조건(exit condition)을 정의하세요: 최대 반복 횟수, 시간 제한, 또는 합의(consensus) 도달 등이 있습니다. 종료 조건이 없으면 수렴(converge)하지 않을 수 있습니다.

스웜은 Anthropic의 패턴이기도 한가요?
아니요. Google은 이를 자사의 Cloud Architecture Center 가이드에 명시하고 있습니다. Anthropic은 Building Effective Agents에서 스웜을 나열하지 않았습니다.

출처

• Google Cloud Architecture Center, Choose a design pattern for your agentic AI system: https://docs.cloud.google.com/architecture/choose-design-pattern-agentic-ai-system
• Google Developers Blog, Developer's guide to multi-agent patterns in ADK: https://developers.googleblog.com/developers-guide-to-multi-agent-patterns-in-adk/
• Google Agent Development Kit docs: https://google.github.io/adk-docs/