멀티 에이전트 오케스트레이션 시대: AWS 스트랜즈 1.0과 A2A 프로토콜이 바꾸는 것들

AWS가 지난 5월 오픈소스 에이전트 SDK ‘스트랜즈 에이전트(Strands Agents)’ 파이썬 버전 1.0을 정식 출시하면서, AWS 공식 오픈소스 블로그를 통해 A2A(Agent-to-Agent) 프로토콜 네이티브 지원을 함께 발표했습니다. 공식 문서가 지금 권장하는 예시는 이렇습니다.

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

def create_agent(context_id: str) -> Agent:
    return Agent(
        name="Calculator Agent",
        description="A calculator agent.",
        callback_handler=None
    )

a2a_server = A2AServer(agent_factory=create_agent)
a2a_server.serve()

초기엔 A2AServer(agent=agent)처럼 만들어둔 에이전트 인스턴스 하나를 그대로 넘기는 방식도 쓰였지만, 공식 문서는 지금 이 방식을 쓰지 말라고 명시하고 있습니다. 대화(컨텍스트)마다 같은 인스턴스를 돌려쓰다 보니, 요청이 몰리면 순서대로 밀리는 문제가 있었기 때문입니다.

대신 agent_factory에 대화마다 새 에이전트를 만들어주는 함수를 넘기면, 동시에 여러 대화가 들어와도 서로 다른 인스턴스로 처리됩니다. 함수 정의가 하나 늘었을 뿐, 핵심은 여전히 ‘만들어둔 에이전트를 A2AServer로 감싸고 serve()를 부르는’ 몇 줄짜리 작업이라는 점은 같습니다. 반대로 다른 플랫폼의 A2A 에이전트를 내 워크플로우 안으로 불러오는 것도 비슷한 수준의 짧은 클라이언트 코드로 처리됩니다.

단순한 SDK 업데이트처럼 보이지만, 이 소식은 최근 몇 달간 이어져 온 더 큰 흐름 위에 있습니다. 챗GPT·클로드·제미나이처럼 ‘에이전트 하나가 알아서 처리하는’ 방식에서, 여러 에이전트를 팀처럼 조율해서 쓰는 ‘멀티 에이전트 오케스트레이션’으로 무게 중심이 옮겨가고 있다는 신호입니다.

스트랜즈 에이전트의 실제 쓰임새를 보면 이 흐름이 단순한 발표성 이벤트가 아니라는 점이 좀 더 분명해집니다. 리서치 사이트 Ry Walker Research의 분석에 따르면 2026년 6월 기준 스트랜즈 에이전트 파이썬 패키지는 월 1670만 건 다운로드를 기록한 반면, 깃허브 스타는 6100개 남짓으로 다운로드 대비 스타 수가 유독 낮습니다. 커뮤니티에서 화제가 돼서 퍼졌다기보다 아마존 Q 디벨로퍼(Amazon Q Developer)·AWS 글루(Glue)·VPC 리처빌리티 애널라이저 등 AWS 자체 제품 안에 이미 들어가 돌아가고 있기 때문으로 풀이됩니다. 즉 이번 A2A 지원은 ‘AWS가 새로 미는 실험적 기능’이 아니라, 이미 AWS 서비스 곳곳에서 조용히 돌아가던 기반 SDK에 업계 표준 통신 규격 하나가 얹힌 것에 가깝습니다.

배경: 왜 ‘혼자 일하는 에이전트’로는 한계가 왔나

여러 전문성이 필요한 업무일수록 드러나는 한계

지금까지 이 블로그에서 다룬 챗GPT 에이전트 모드, 제미나이 에이전트, 클로드 Agent Skills는 모두 ‘에이전트 하나가 리서치부터 실행까지 처리한다’는 전제로 설계돼 있습니다. 간단한 작업에는 충분하지만, 예산 승인·계약서 검토·다단계 리서치처럼 여러 전문성이 섞인 업무로 갈수록 에이전트 하나에 모든 역할을 맡기는 방식은 판단 정확도가 떨어지고 맥락(컨텍스트)이 뒤섞이는 문제를 드러냈습니다.

이 문제를 해결하는 접근이 멀티 에이전트 오케스트레이션입니다. 리서치 담당, 실행 담당, 검토 담당처럼 역할을 나눈 여러 에이전트가 각자 좁은 범위의 일만 맡고, 이를 조율하는 ‘오케스트레이터’ 에이전트가 전체 흐름을 관리하는 구조입니다.

프레임워크마다 달랐던 ‘에이전트 간 대화 방식’

문제는 이 구조를 실제로 만들려면 프레임워크마다 에이전트 간 통신 방식이 제각각이었다는 점입니다. A사 프레임워크로 만든 에이전트와 B사 프레임워크로 만든 에이전트를 연결하려면 매번 별도의 연동 코드를 짜야 했습니다. A2A 프로토콜은 바로 이 문제, 즉 ‘서로 다른 플랫폼에서 만든 에이전트끼리 어떻게 대화하게 할 것인가’를 표준화하려는 시도입니다.

A2A 프로토콜, 1년 새 표준으로 성장

2025년 4월 구글이 처음 공개한 A2A는 처음엔 지지 기관이 50여 곳 수준이었습니다. 그런데 2026년 4월 발표된 1주년 집계를 보면 참여 기관이 150개 이상으로 3배가량 늘었습니다.

구글·마이크로소프트·AWS·세일즈포스·SAP·서비스나우·워크데이 등 클라우드·SaaS 업계 주요 기업 대부분이 이름을 올린 상태입니다. SDK 지원 언어도 출시 초기엔 파이썬뿐이었지만 지금은 파이썬·자바스크립트·자바·Go·.NET 5개 언어로 늘었습니다.

이 확산에는 클라우드 인프라 차원의 뒷받침도 있습니다. 에이전트 프로토콜 동향을 추적하는 agentndx.ai의 2026년 4월 집계에 따르면 A2A 프로젝트의 깃허브 스타는 2만 2000개를 넘었고, 구글 버텍스 AI(Vertex AI)·마이크로소프트 애저 AI 파운드리(Azure AI Foundry)·AWS 베드락(Bedrock) 등 3대 클라우드의 관리형 에이전트 서비스에도 A2A 지원이 들어간 것으로 알려져 있습니다. 다만 같은 자료는 ‘공급망·금융서비스·보험·IT운영 분야에서 프로덕션 배포 사례가 있다’고만 언급할 뿐 구체적 기업명은 공개하지 않고 있어, 표준 자체는 자리를 잡았지만 사례 공개는 아직 제한적인 초기 확산 국면으로 보는 게 정확합니다.

왜 중요한가: 프레임워크들이 ‘공통 언어’로 수렴하고 있다

마이크로소프트: AutoGen과 시맨틱 커널을 한 지붕 아래로

이 흐름에서 가장 눈에 띄는 변화는 마이크로소프트입니다. 그동안 별도 제품으로 존재하던 AutoGen(멀티 에이전트 오케스트레이션 담당)과 시맨틱 커널(Semantic Kernel, 엔터프라이즈 통합·텔레메트리 담당)을 하나로 합쳐 Microsoft Agent Framework 1.0을 지난 4월 정식 출시했습니다. 마이크로소프트는 이 발표에서 MCP와 A2A 두 표준을 “나중에 덧붙인 기능이 아니라 처음부터 내장된 기능”이라고 강조했습니다.

랭그래프와 크루AI, A2A 지원 수준은 다르다

랭그래프(LangGraph)와 크루AI(CrewAI)도 A2A를 지원한다고 알려져 있지만, 실제 지원 수준에는 분명한 차이가 있습니다. 크루AI는 다른 A2A 에이전트를 호출하는 클라이언트 기능까지 내장돼 있어, 대상 에이전트를 자동으로 찾아내고 재시도·시간초과·인증 처리까지 프레임워크가 알아서 해줍니다.

반면 랭그래프는 내가 만든 에이전트를 A2A 서버로 노출하는 기능은 갖추고 있지만, 다른 A2A 에이전트를 호출하는 클라이언트 쪽은 내장돼 있지 않아 개발자가 직접 HTTP 요청 코드를 짜야 합니다. 같은 ‘A2A 지원’이라는 표현을 쓰더라도 실제 완성도는 프레임워크마다 다르다는 뜻이니, 도구를 고를 때는 이 차이를 확인하는 게 좋습니다.

MCP와 A2A, 두 표준의 조합이 만드는 변화

즉 지금 벌어지고 있는 일은 하나의 회사가 표준을 독점하는 방식이 아니라, 경쟁 관계인 프레임워크들이 완성도의 차이는 있을지언정 최소한 ‘에이전트끼리 대화하는 방법’만큼은 공통 규격을 쓰기로 합의해가는 과정에 가깝습니다. 여기에 도구 연동을 표준화하는 MCP(Model Context Protocol)까지 더해지면서, ‘MCP로 도구를 연결하고 A2A로 에이전트를 연결한다’는 조합이 에이전트 아키텍처를 설계할 때 기본 전제로 자리잡는 분위기입니다.

실무적으로 이게 왜 중요할까요. 특정 프레임워크나 특정 AI 기업의 생태계에 통째로 종속될 위험이 줄어든다는 뜻입니다. 예를 들어 리서치는 무료 AI 에이전트 툴 중 하나로 처리하고, 실행은 다른 플랫폼의 에이전트에 맡기는 조합이 표준 프로토콜 위에서 점점 더 자연스러워지고 있습니다.

실무 시사점: 지금 시작한다면 ‘2~3개 에이전트’부터

오케스트레이터 하나 + 워커 2~3개: 판단 기준

이 흐름을 개인이나 소규모 팀이 오늘 당장 복잡하게 따라갈 필요는 없습니다. 실제로 먼저 따져볼 기준은 ‘이 업무가 병렬로 나눌 수 있는가, 순서대로 진행해야 하는가’입니다. 여러 후보안을 동시에 검토하거나 여러 채널에 동시에 콘텐츠를 배포하는 것처럼 병렬로 쪼갤 수 있는 작업은 에이전트를 나눌수록 효과가 커집니다.

반대로 ‘리서치 → 초안 작성 → 검토’처럼 앞 단계 결과가 다음 단계 입력이 되는 순차적 업무는 에이전트를 무작정 늘린다고 품질이 비례해서 좋아지지 않습니다. 오히려 에이전트 사이에서 정보가 누락되거나 살짝 다르게 해석되면서 결과가 원본 지시에서 멀어지는 경우가 생깁니다. 그래서 처음엔 오케스트레이터 1개와 워커 2~3개로 병목이 되는 한 가지 워크플로우만 먼저 완성해보는 쪽이 안전합니다.

n8n으로 오케스트레이터 역할 만들어보기

구체적인 그림을 그려보면 이렇습니다. n8n에서 Webhook 트리거로 요청을 받고, Switch 노드로 ‘리서치가 필요한 요청인지, 바로 실행하면 되는 요청인지’ 작업 유형을 먼저 분기합니다.

각 분기 끝에 HTTP Request 노드를 두고 리서치용 에이전트(예: 챗GPT·클로드의 API)와 실행용 에이전트(예: A2A로 노출된 스트랜즈 에이전트나 다른 워크플로우)를 각각 호출한 뒤, Merge 노드에서 두 결과를 합쳐 사람이 검토할 수 있는 형태로 정리합니다. n8n 자체가 오케스트레이터, 두 HTTP Request 노드가 호출하는 대상이 워커에 해당하는 셈입니다.

n8n과 메이크(Make)·다이파이(Dify)·코즈(Coze) 같은 노코드 자동화·에이전트 빌더 도구들도 이런 조합을 만드는 실질적인 출발점이 될 수 있습니다.

1인 개발자·소규모 자동화 프로젝트엔 지금 A2A가 필요할까

여기서 자연스럽게 드는 질문이 있습니다. 자동화 도구 하나로 혼자 운영하는 프로젝트에도 A2A가 지금 당장 필요할까요. 결론부터 말하면 우선순위는 아닙니다. 프로토콜을 비교하는 여러 자료가 공통적으로 지적하는 지점은 ‘MCP는 몇 분 안에 연결해서 쓸 수 있는 반면, A2A는 구조적으로 더 복잡하다’는 것이고, 서로 다른 회사의 에이전트를 A2A로 실제 연결해 쓰는 프로덕션 사례도 앞서 본 것처럼 아직 대기업 밖에서는 흔치 않은 것으로 알려져 있습니다. n8n만 봐도 도구 연동 표준인 MCP는 이미 정식 노드로 내장돼 있지만, A2A는 n8n-nodes-agent2agent 같은 커뮤니티 제작 노드 패키지를 별도로 설치해야 쓸 수 있는 수준에 머물러 있습니다. 즉 앞서 소개한 n8n 예시처럼 HTTP Request 노드로 직접 연동하는 방식이, 지금으로선 표준 프로토콜을 그대로 쓰는 것보다 더 실용적인 선택인 경우가 많습니다.

그렇다고 이 흐름을 몰라도 되는 건 아닙니다. 표준이 자리를 잡고 나면 다음 순서는 거의 항상 ‘매일 쓰는 노코드 도구에 버튼 하나로 들어오는 것’이기 때문입니다. MCP도 처음엔 앤트로픽이 만든 낯선 프로토콜이었지만, 업계 집계로는 2026년 3월 기준 누적 다운로드 9700만 건을 넘기고 앤트로픽·오픈AI·구글·마이크로소프트가 모두 지원할 만큼 빠르게 일상 도구의 기본 옵션 중 하나가 됐습니다. A2A가 같은 경로를 밟는다면, n8n이나 메이크(Make) 같은 도구에 ‘A2A로 다른 에이전트 호출’이 정식 노드로 들어오는 시점도 머지않아 올 수 있습니다. 그때 이 글에서 다룬 ‘MCP는 도구 연결, A2A는 에이전트 연결’이라는 구분만 미리 알아두면, 새 노드가 등장했을 때 무엇을 위한 기능인지 바로 판단하고 지금 짜둔 워크플로우 중 어디를 교체하면 좋을지 빠르게 감을 잡을 수 있습니다.

에이전트가 늘어날수록 커지는 권한·감사 로그 부담

다만 에이전트 수가 늘어날수록 신경 써야 할 지점도 함께 늘어납니다. 에이전트끼리 서로 어떤 권한으로 무엇을 주고받았는지 기록이 남지 않으면, 문제가 생겼을 때 원인을 추적하기 어렵습니다.

이 블로그에서 앞서 다룬 AI 에이전트 보안 체크리스트와 AI 에이전트 감사 로그·권한 관리 체크리스트의 원칙(권한 최소화, 감사 로그 확인)은 에이전트가 한 개일 때보다 여러 개가 서로 통신하는 지금 같은 구조에서 오히려 더 중요해집니다.

핵심을 정리하면 이렇습니다. 첫째, AWS 스트랜즈 에이전트 SDK 1.0이 코드 몇 줄 수준의 A2A 지원을 내놓으면서 멀티 에이전트 오케스트레이션이 실제로 손댈 수 있는 단계에 들어섰습니다. 둘째, A2A는 1년 만에 참여 기관이 3배로 늘었고 마이크로소프트·크루AI처럼 완성도 높은 지원을 갖춘 프레임워크와 랭그래프처럼 아직 서버 쪽만 지원하는 프레임워크가 섞여 있어 도구를 고를 때 이 차이를 확인해야 합니다. 셋째, 처음부터 여러 에이전트를 늘어놓기보다 오케스트레이터 1개와 워커 2~3개로 병목 하나를 먼저 풀어보고, 늘어나는 만큼 권한·감사 로그 관리도 함께 챙기는 것이 실무에서 가장 안전한 출발점입니다.

---