Strands Agents의 5가지 멀티 에이전트 패턴: 어떤 것을 언제 사용할 것인가

항공권을 검색하는 에이전트가 있습니다. 또 다른 에이전트는 날씨를 확인합니다. 또 다른 에이전트는 기업 정책을 준수합니다. 이들을 어떻게 함께 작동하게 만들 수 있을까요?

Strands Agents는 여러 에이전트를 조정하기 위한 5가지 패턴을 제공합니다. 각 패턴은 서로 다른 문제를 해결합니다. 핵심적인 차이점은 실행 순서를 누가 결정하는가입니다. 모델이 결정할 수도 있고, 에이전트 자체가 결정할 수도 있으며, 코드 내에서 사용자가 결정할 수도 있습니다.

이 포스트에서는 코드를 통해 각 패턴을 살펴보고, 비교 표를 통해 차이점을 보여주며, 적절한 패턴을 선택할 수 있는 의사결정 프레임워크를 제공합니다.

모든 예제는 Strands Agents (2026년 6월)를 사용합니다. 전체 코드는 github.com/ricardoceci/curso-strands-agentcore-2026/tree/main/clase-3에서 확인할 수 있습니다.

실행 예제: 기업용 여행 에이전트 (Corporate Travel Agent)

모든 예제는 동일한 사례를 사용합니다: 항공권 검색, 날씨 조회, 추천 생성을 조정하는 기업용 여행 에이전트입니다. 세 가지 기능, 세 명의 전문화된 에이전트가 존재합니다.

from strands import Agent, tool

@tool
...

패턴 1: 도구로서의 에이전트 (Agents as Tools)

오케스트레이터 에이전트 (Orchestrator agent)가 다른 에이전트들을 마치 도구 (Tools)인 것처럼 사용합니다. 오케스트레이터는 언제 누구에게 업무를 위임할지를 결정합니다.

작동 방식

메인 에이전트의 tools 배열에 서브 에이전트 (Sub-agent)를 직접 전달합니다. SDK는 이를 자동으로 도구로 변환합니다. 오케스트레이터의 모델이 해당 기능이 필요하다고 판단하면 서브 에이전트를 호출합니다. 모든 과정은 동일한 Python 프로세스 내에서 실행됩니다.

더 세밀한 제어를 원한다면 .as_tool()을 사용하여 도구의 이름과 설명을 커스텀하거나, @tool 데코레이터를 사용하여 호출 전체를 래핑(Wrap)할 수 있습니다.

# 날씨를 위한 전문 서브 에이전트
weather_agent = Agent(
    tools=[get_weather],
...

사용 시점

명확하게 구별되는 기능을 가진 몇 개의 서브 에이전트가 있고, 메인 모델이 각 에이전트를 언제 호출할지 결정하기를 원할 때 사용합니다. 이는 가장 직접적인 패턴이며, 가장 적은 조정 (Coordination)을 필요로 합니다.

사용하지 말아야 할 때

에이전트들이 (오케스트레이터뿐만 아니라) 서로 통신해야 하거나 실행 순서가 중요한 경우입니다. 그런 경우에는 Graph 또는 Swarm이 더 효과적입니다.

패턴 2: Swarm

핸드오프 (Handoffs, 제어권 이전)를 통해 자율적으로 협력하는 에이전트 그룹입니다. 각 에이전트는 언제 다른 에이전트에게 작업을 넘길지 스스로 결정합니다.

작동 방식

Strands는 Swarm 내의 각 에이전트에 협력 도구를 제공합니다. 제어권을 이전하기 위한 핸드오프 도구와 모든 에이전트가 읽을 수 있는 공유 컨텍스트 (Shared Context)가 그것입니다. 에이전트들은 실행 순서를 스스로 결정합니다.

from strands.multiagent import Swarm

flight_agent = Agent(
...

사용해야 할 때

문제가 서로 다른 전문가들이 더 잘 처리할 수 있는 부분들로 나뉘며, 작업에 따라 순서가 달라질 수 있을 때 사용합니다. Swarm은 어떤 에이전트가 먼저 행동해야 할지 사전에 알 수 없는 문제에 가장 적합합니다.

사용하지 말아야 할 때

예측 가능하고 반복 가능한 실행 흐름이 필요한 경우입니다. Swarm은 런타임 (Runtime)에 순서를 결정합니다. 동일한 프롬프트에 대한 두 번의 실행이 서로 다른 경로를 따를 수 있습니다.

패턴 3: Graph

각 노드 (Node)가 에이전트이고 엣지 (Edge)가 실행 흐름을 정의하는 유향 그래프 (Directed Graph)입니다. 사용자가 구조를 정의하면 프레임워크가 순서대로 실행합니다.

작동 방식

GraphBuilder는 노드 (에이전트)와 엣지 (연결)를 정의할 수 있는 API를 제공합니다. 프레임워크는 한 노드의 출력을 다음 노드의 입력으로 전달합니다. 이는 비순환 그래프 (Acyclic Graphs, 파이프라인)와 순환 그래프 (Cyclic Graphs, 개선 루프)를 모두 지원하므로, 에이전트 간의 검토 반복 (Review Iterations)을 구현할 수 있는 유연성을 제공합니다.

from strands.multiagent import GraphBuilder

graph = (
...

사용해야 할 때

워크플로 (Workflow)가 변경되어서는 안 되는 엄격한 순서를 가질 때 사용합니다. 예를 들어: 항상 먼저 항공권을 검색하고, 그다음 날씨를 확인한 뒤, 마지막으로 추천을 생성하는 경우입니다. 파이프라인이 매번 동일하다면 Graph가 올바른 패턴입니다.

사용하지 말아야 할 때

실행 순서에 유연성이 필요한 경우입니다. 또한 깊이 (Depth) 수준이 많은 Graph는 각 노드가 이전 노드를 기다려야 하기 때문에 지연 시간 (Latency)을 증가시킵니다.

패턴 4: Workflow

명시적인 의존성(Dependencies)과 자동 병렬 실행(Automatic parallel execution)을 갖춘 작업 그래프 (Task graph)입니다. 각 작업은 특정 시스템 프롬프트 (System prompt)를 가진 에이전트에게 할당됩니다.

작동 방식

에이전트를 노드로 사용하는 Graph와 달리, Workflow는 **작업 (Tasks)**을 중심으로 작동합니다. 각 작업은 ID, 설명, 의존성 및 우선순위를 가집니다. 프레임워크는 실행 순서를 결정하고, 가능한 부분을 병렬화하며, 작업 간에 결과를 전달합니다.

from strands import Agent
from strands_tools import workflow

...

이 예시에서 search_flights와 check_weather는 병렬로 실행됩니다 (두 작업 사이에 의존성이 없음). generate_report는 두 작업이 모두 완료될 때까지 기다립니다.

사용 시점

병렬로 실행 가능한 단계들을 포함하는 반복 가능한 프로세스가 있는 경우에 사용합니다. Workflow는 명시적인 의존성, 결정론적 실행 (Deterministic execution), 작업 간의 결과 흐름을 갖는다는 점에서 전통적인 데이터 파이프라인 (Data pipeline)과 가장 유사한 패턴입니다.

사용하지 말아야 할 때

에이전트가 다음에 무엇을 할지 스스로 결정해야 하는 경우에는 사용하지 마십시오. Workflow는 자율성 없이 정의된 내용을 정확하게 실행합니다.

패턴 5: A2A (Agent-to-Agent)

에이전트들이 HTTP를 통해 통신할 수 있도록 하는 개방형 프로토콜 (Google이 생성하였으며, 현재 Linux Foundation 소속)입니다. 에이전트들은 서로 다른 프레임워크나 서로 다른 서버에서 작성될 수 있습니다.

작동 방식

에이전트는 에이전트 카드 (Agent Card, /.well-known/agent-card.json에 위치한 JSON 메타데이터)를 가진 A2A 서버로 노출됩니다. 다른 에이전트는 이를 클라이언트 (Client)로서 소비합니다. 통신은 HTTP/JSON을 통해 이루어집니다.

서버 (Server):

from strands import Agent
from strands.multiagent.a2a import A2AServer
import uvicorn
...

클라이언트 (Client):

from strands import Agent
from strands.agent.a2a_agent import A2AAgent

...

사용 시점

에이전트들이 서로 다른 서버에 존재하거나, 서로 다른 프레임워크 (Strands, LangGraph, CrewAI)로 작성되었거나, 서로 다른 팀 또는 조직에 속해 있는 경우에 사용합니다. A2A는 로컬 프로세스 경계 (Local process boundary)를 넘나드는 유일한 패턴입니다.

사용하지 말아야 할 때

모든 에이전트가 동일한 프로세스 내에서 실행되는 경우입니다. A2A는 네트워크 지연 시간(호출당 50-1000ms, 커뮤니티 벤치마크 참조)을 추가합니다. 로컬 통신(Local communication)의 경우, 다른 패턴들이 수십 배 더 빠릅니다.

5가지 멀티 에이전트 패턴 비교

측면	Agents as Tools	Swarm	Graph	Workflow	A2A
순서를 결정하는 주체	오케스트레이터 (Orchestrator) 모델	에이전트 (핸드오프 (handoffs))	사용자 (엣지 (edges))	사용자 (의존성 (dependencies))	해당 없음 (프로토콜)
...

의사결정 프레임워크 (Decision Framework)

패턴을 선택할 때는 다음 질문들을 따르십시오:

에이전트들이 동일한 프로세스 내에 있습니까?
아니라면: A2A (네트워크를 가로지르는 유일한 패턴).

실행 순서가 중요합니까?
중요하다면, 항상 동일한 순서입니까?: Graph (고정된 구조).
중요하다면, 병렬 작업이 포함됩니까?: Workflow (의존성 + 병렬성).

에이전트가 누가 행동할지를 스스로 결정해야 합니까?
그렇다면: Swarm (자율적인 핸드오프 (autonomous handoffs)).

오케스트레이터에서 전문가에게 직접 위임하는 방식입니까?
그렇다면: Agents as Tools (가장 직접적인 방식).

어느 것도 완벽하게 맞지 않습니까?
패턴들은 서로 조합될 수 있습니다. Graph는 노드(node)로서 Swarm을 가질 수 있습니다. 도구(tools)를 가진 에이전트는 원격 A2AAgent를 포함할 수 있습니다. Strands는 제약 없이 패턴을 혼합할 수 있게 해줍니다.

자주 묻는 질문 (FAQ)

Swarm은 내부적으로 A2A를 사용합니까?

아니요. Swarm은 동일한 프로세스 내에서 Python 함수 호출을 사용합니다. 혼동이 생기는 이유는 두 방식 모두 "에이전트 간의 통신"을 포함하기 때문이지만, Swarm은 로컬(마이크로초 단위)이고 A2A는 원격(HTTP)입니다.

Graph는 조건부 실행을 지원합니까?

네. 엣지(Edges)는 런타임(runtime)에 평가되는 조건을 가질 수 있습니다. 이를 통해 결정 트리(decision trees)처럼 동작하는 그래프를 만들 수 있습니다. 즉, 노드의 출력에 따라 흐름이 한 경로 또는 다른 경로를 따르게 됩니다.

패턴을 결합할 수 있습니까?

네, 그리고 이것은 Strands의 강점 중 하나입니다. Swarm (군집)은 Graph (그래프) 내부의 노드로 존재할 수 있습니다. Graph는 원격 A2AAgent를 노드로 사용할 수 있습니다. 도구 (Tools)를 가진 에이전트는 다른 에이전트를 도구로 포함할 수 있습니다. 구성 (Composition)에는 제한이 없습니다.

어떤 것이 가장 토큰 효율적입니까?

Agents as Tools (도구로서의 에이전트)와 Graph (그래프)는 조정 (Coordination) 과정이 결정론적 (Deterministic)이기 때문에 더 적은 토큰을 소비합니다. Swarm (군집)은 에이전트가 누구에게 업무를 넘길지 추론해야 하므로 더 많은 토큰을 소비할 수 있습니다. A2A는 HTTP 프로토콜 오버헤드 (Overhead)를 추가합니다.

Workflow (워크플로우)가 Graph (그래프)를 대체합니까?

아니요. Workflow는 Strands 도구 (strands-agents-tools에서 제공)인 반면, Graph는 네이티브 SDK 오케스트레이터 (Orchestrator)입니다. Workflow는 태스크 (Tasks) 단위로 작동하고, Graph는 에이전트 (Agents) 단위로 작동합니다. 각 노드가 자체 시스템 프롬프트 (System Prompt)와 도구를 가진 완전한 에이전트여야 한다면 Graph를 사용하십시오. 의존성 (Dependencies)이 있는 태스크 파이프라인 (Task Pipeline)이 필요하다면 Workflow를 사용하십시오.

결론

이 5가지 패턴은 서로 경쟁하는 관계가 아닙니다. 각 패턴은 서로 다른 조정 (Coordination) 요구 사항을 해결합니다. 핵심은 귀하의 사례에 가장 직접적으로 작동하는 방식(아마도 Agents as Tools)으로 시작하여, 필요할 때 더 복잡한 패턴으로 확장해 나가는 것입니다.

Corporate Travel Agent 사례를 통해 이러한 패턴이 실제로 구현된 모습을 보고 싶다면, 전체 코드는 강의 리포지토리 (Repository)에 있습니다:

github.com/ricardoceci/curso-strands-agentcore-2026

리소스

• Strands Multi-Agent Documentation
• Multi-Agent Collaboration Patterns with Strands and Amazon Nova (AWS Blog)
• Strands Agents Website
• A2A Protocol (Linux Foundation)
• A2A Protocol Support in AgentCore Runtime (AWS Blog)