Home / Strands 멀티에이전트 운영 / Strands 멀티에이전트 통신
Note

Strands 멀티에이전트 통신

3계층 통신, 패턴별 데이터 흐름, A2A Protocol

⏱ 35분 115 / 189

멀티에이전트 통신

3계층 통신, 패턴별 데이터 흐름, A2A Protocol

멀티에이전트를 프로덕션에서 운영한다

에이전트 간 통신·에러 복원·안전 보장 — 운영의 3축

운영 개요

통신 · 에러 · 안전 — 프로덕션 3축

PART 1 · 운영 개요

멀티에이전트 운영 3축

프로덕션에서 멀티에이전트를 지탱하는 세 가지 핵심 축

  1. 1
    통신 (Communication)

    에이전트 간 메시지 전달·공유 상태·프로토콜 표준화. Shared Context부터 A2A Protocol까지 계층별 통신 전략이 필요합니다.

  2. 2
    에러 복원 (Resilience)

    타임아웃·환각·핸드오프 유실 등 분산 환경 고유의 실패 모드에 대응. Circuit Breaker와 Supervisor Escalation으로 장애를 격리합니다.

  3. 3
    안전 보장 (Safety)

    에이전트별 권한 제어·입출력 검증·행동 제한. Cedar 정책과 Bedrock Guardrails로 자율 행동의 범위를 선언적으로 제한합니다.

takeaway

축마다 전용 패턴과 AWS 서비스가 매핑됩니다 — 하나라도 비면 프로덕션에서 드러납니다.

PART 1 · 운영 개요

축별 핵심 과제

메시지 유실·장애 전파·권한 초과 — 축마다 다른 실패 양상과 대응 패턴

핵심 과제실패 시 결과대응 패턴
통신메시지 유실·순서 역전·스키마 불일치에이전트 간 상태 불일치 → 잘못된 의사결정A2A Protocol · Dead Letter Queue
에러타임아웃 연쇄·핸드오프 유실·무한 루프단일 에이전트 장애가 전체 시스템으로 전파Circuit Breaker · Supervisor Escalation
안전권한 초과·프롬프트 인젝션·출력 오염비인가 행동 실행 → 데이터 유출·규정 위반Cedar Policy · Bedrock Guardrails
takeaway

실패 시 결과의 공통 패턴은 전파입니다 — 상태 불일치·장애·비인가 행동이 시스템 전체로 번지기 전에 축별 대응 패턴으로 격리합니다.

PART 1 · 운영 개요

프로토타입 vs 프로덕션

단일 에이전트 PoC에서는 보이지 않던 문제의 프로덕션 폭발 지점

프로토타입

단일 에이전트 PoC

  • 단일 호출 — 1회 호출로 끝
  • 단일 장애 — 실패해도 그 호출뿐
  • 단일 권한 — 도구·데이터 접근 범위 하나
  • 로컬 테스트 — print 디버깅으로 충분

PoC 단계에서는 문제가 드러나지 않습니다 — 호출이 짧고, 장애가 고립되고, 권한이 하나뿐이기 때문입니다.

프로덕션

분산 멀티에이전트 운영

  • 장기 실행 — 수십 분 실행, 헬스체크·하트비트 필요
  • 장애 전파 — Circuit Breaker로 failure domain 격리
  • 권한 충돌 — Cedar 정책으로 에이전트별 최소 권한
  • 분산 관측 — OpenTelemetry + X-Ray, correlation ID로 추적

네트워크 단절·모델 스로틀링·연쇄 장애·비인가 도구 호출이 복합적으로 발생 — end-to-end 가시성까지 요구됩니다.

takeaway

네 폭발 지점의 공통 원인은 분산입니다 — 단일이던 호출·장애·권한·관측이 여러 에이전트로 쪼개지는 순간 운영 문제가 시작됩니다.

에이전트 간 통신

3계층 모델 · A2A Protocol · 메커니즘 비교

PART 2 · 에이전트 간 통신

통신 3계층 모델

결합도와 확장성에 따라 계층을 선택하는 통신 아키텍처

L3: A2A Protocol

이기종 에이전트 프레임워크 간 표준 통신. HTTP + JSON-RPC 기반으로 Agent Card 교환 후 Task 단위로 비동기 협업합니다. Linux Foundation 오픈 표준 (Google 개발·기증).

L2: Message Passing

에이전트 간 비동기 메시지 큐. SQS·SNS·EventBridge를 통해 느슨하게 결합된 이벤트 기반 통신. 순서 보장이 필요하면 FIFO 큐 사용.

L1: Shared Context

동일 프로세스 내 메모리 공유. Strands의 agent.state(AgentState)나 Swarm의 shared_context를 통해 에이전트 간 상태를 직접 공유. 가장 빠르지만 단일 프로세스 한정.

PART 2 · 에이전트 간 통신

A2A Protocol 통합

A2AServer가 Strands 에이전트를 JSON-RPC over HTTP로 노출 — Agent Card 자동 게시와 Task 단위 협업 수신

핵심 포인트

A2AServer
Strands 에이전트를 JSON-RPC over HTTP의 A2A 서버로 노출
agent_factory=
요청 컨텍스트별로 에이전트를 새로 생성하는 팩토리 장착
name / description
Agent Card 자동 생성의 원천 — /.well-known/agent-card.json 경로로 게시
serve()
host·port로 서버 시작 — Task 단위 비동기 협업 수신

코드

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

# 요청 컨텍스트별로 에이전트를 생성하는 팩토리
def create_research_agent(context_id):
    return Agent(
        name="research-agent",
        description="기술 문서를 검색하고 요약합니다",
        model="us.anthropic.claude-sonnet-4-6",
        system_prompt="기술 리서치 전문 에이전트",
        tools=[web_search, summarize],
    )

# Agent Card는 name/description에서 자동 생성·게시된다
server = A2AServer(agent_factory=create_research_agent,
                   host="0.0.0.0", port=8080)
server.serve()
PART 2 · 에이전트 간 통신

통신 메커니즘 비교

지연 허용도·결합도·확장성 기준으로 메커니즘 선택

메커니즘지연결합도확장성적합한 경우
Shared Context매우 낮음 (같은 프로세스)강결합단일 프로세스부모-자식 에이전트, 동일 Lambda 내
Message Passing (SQS)수십 ms느슨무제한 스케일비동기 작업 분배, 이벤트 기반
A2A Protocol수백 ms표준 인터페이스크로스 프레임워크이기종 에이전트, 조직 간 협업
Direct Invocation수십 ms중간Lambda 동시성 한도동기 핸드오프, 즉시 응답 필요
takeaway

빠를수록 강결합, 느슨할수록 느립니다 — 같은 프로세스면 Shared Context, 비동기 분배면 SQS, 이기종 협업이면 A2A를 사용합니다.

멀티에이전트는 만드는 것보다 운영이 어렵습니다.

통신 · 에러 · 안전장치 — 세 축을 잡아야 프로덕션에서 살아남습니다