Google Cloud 멀티 에이전트 — A2A와 MCP로 만드는 5가지 통합 패턴
에이전트 간 통신을 위한 A2A와 외부 도구 연결을 위한 MCP가 Google Cloud에서 어떻게 통합되는지, 5가지 패턴으로 정리한다.
AI 에이전트 하나로 모든 걸 처리하는 시대는 끝나가고 있다. 각자 전문 영역을 가진 에이전트들이 협력하는 멀티 에이전트 시스템이 현실적인 대안으로 떠오르고 있다. 그런데 에이전트들이 어떻게 서로 통신하고, 어떻게 외부 시스템에 연결할까?
Google Cloud가 이 문제에 대한 답으로 A2A와 MCP를 제시했다.
두 프로토콜의 역할 분리
많은 사람들이 A2A와 MCP를 혼동한다. 이름도 비슷하고 둘 다 "에이전트 연결"처럼 들린다.
A2A(Agent-to-Agent): 에이전트들이 서로 협력하고 작업을 위임할 때 사용하는 프로토콜
MCP(Model Context Protocol): 에이전트가 외부 도구와 데이터에 접근할 때 사용하는 프로토콜
비유하면 A2A는 팀원들 사이의 커뮤니케이션이고, MCP는 팀원이 외부 시스템(데이터베이스, API, 파일 등)에 접근하는 방법이다.
[💡 잠깐! 이 용어는?] A2A(Agent-to-Agent): Google이 제안한 에이전트 간 표준 통신 프로토콜. Agent Card로 기능을 공개하고, Task 단위로 작업을 위임한다.
[💡 잠깐! 이 용어는?] MCP(Model Context Protocol): Anthropic이 제안한 AI 모델과 외부 도구 연결 표준. REST API, 데이터베이스, 파일 시스템 등을 LLM이 사용할 수 있게 추상화한다.
5가지 통합 패턴
패턴 1: 에이전트 발견과 등록
멀티 에이전트 시스템에서 첫 번째 문제는 "어떤 에이전트가 있는지 어떻게 아냐"는 것이다.
A2A는 Agent Card라는 개념을 통해 이 문제를 해결한다.
{
"name": "code-review-agent",
"version": "1.0.0",
"capabilities": [
"python-review",
"security-analysis",
"performance-check"
],
"endpoint": "https://agents.example.com/code-reviewer",
"auth": {
"type": "oauth2",
"scopes": ["review:read", "review:write"]
}
}각 에이전트는 자신의 Agent Card를 Agent Registry에 등록한다. 다른 에이전트는 레지스트리를 조회해서 필요한 기능을 가진 에이전트를 찾는다. AWS의 서비스 디스커버리나 쿠버네티스의 Service 리소스와 같은 개념이다.
패턴 2: 크로스팀 위임
한 팀의 오케스트레이터 에이전트가 다른 팀의 전문 에이전트에게 작업을 위임하는 패턴이다.
[오케스트레이터]
├── 한국어 팀 [번역 에이전트]
├── 일본어 팀 [번역 에이전트]
└── 영어 팀 [번역 에이전트]
각 팀은 자신의 에이전트를 독립적으로 배포하고 업데이트한다. 오케스트레이터는 어떤 기술 스택을 쓰는지 알 필요가 없다. A2A가 표준 인터페이스를 제공하기 때문이다.
이 패턴의 핵심 장점은 배포 독립성이다. 번역 팀이 새 버전의 에이전트를 배포해도 오케스트레이터 코드를 건드릴 필요가 없다.
패턴 3: MCP 도구 연결
에이전트가 REST API, 데이터베이스, 레거시 시스템에 접근할 때 사용하는 패턴이다.
from google.cloud.agents import AgentBuilder
agent = AgentBuilder.create(
name="data-analyst",
model="gemini-2.5-pro"
)
# MCP 서버로 외부 도구 연결
agent.add_mcp_server("bigquery", endpoint="mcp://bigquery.example.com")
agent.add_mcp_server("salesforce", endpoint="mcp://salesforce.example.com")
agent.add_mcp_server("slack", endpoint="mcp://slack.example.com")Google Cloud는 60개 이상의 사전 구축 MCP 서버를 제공한다. BigQuery, Cloud SQL, Salesforce, Slack 등 주요 서비스들을 플러그인 형태로 연결할 수 있다.
비유하면 에이전트는 USB 허브이고, 각 MCP 서버는 USB 기기다. 표준 인터페이스(USB) 덕분에 어떤 기기든 꽂으면 쓸 수 있다.
패턴 4: 조직 간 협업
다른 조직의 에이전트를 활용해야 할 때를 위한 패턴이다.
[우리 회사 오케스트레이터]
├── 내부: 고객 데이터 에이전트
├── 파트너: 물류 회사 배송 에이전트
└── 외부: 결제 플랫폼 에이전트
Agent Gallery에서 파트너 에이전트를 검색하고, 계약된 범위 내에서 사용할 수 있다. 각 조직은 자신의 거버넌스와 데이터 정책을 독립적으로 유지한다.
| 측면 | 단일 조직 | 조직 간 협업 |
|---|---|---|
| 배포 | 한 팀이 관리 | 각자 독립 관리 |
| 데이터 접근 | 전체 공유 | 계약된 범위만 |
| 업데이트 | 중앙화 | 분산화 |
| 거버넌스 | 단일 정책 | 조직별 정책 |
패턴 5: 이벤트 기반 에이전트 메시
실시간 데이터 변화에 자동으로 반응하는 에이전트 네트워크다.
from google.cloud.agents import EventTrigger, AgentMesh
mesh = AgentMesh()
# BigQuery 데이터 변화 감지
@mesh.trigger(EventTrigger.bigquery_update("sales_data"))
async def handle_sales_update(event):
# 자동으로 적절한 에이전트에게 라우팅
if event.anomaly_detected:
await mesh.route_to("anomaly-investigator", event)
elif event.threshold_exceeded("revenue"):
await mesh.route_to("report-generator", event)Pub/Sub로 이벤트를 구독하고, 조건에 따라 자동으로 적절한 전문 에이전트에게 라우팅된다. 사람이 개입하지 않아도 데이터 변화에 자동으로 반응하는 에이전트 시스템이 만들어진다.
A2A vs MCP 선택 기준
언제 A2A를 쓰고 언제 MCP를 쓰는지 헷갈린다면 이렇게 판단한다.
| 질문 | 답변 | 프로토콜 |
|---|---|---|
| 다른 에이전트에게 작업을 위임해야 하나? | Yes | A2A |
| 외부 API나 DB에 접근해야 하나? | Yes | MCP |
| 에이전트들이 결과를 공유해야 하나? | Yes | A2A |
| 파일을 읽거나 코드를 실행해야 하나? | Yes | MCP |
대부분의 실제 시스템에서는 둘을 함께 사용한다. 에이전트들이 A2A로 협력하면서, 각 에이전트는 MCP로 자신의 도구에 접근하는 구조다.
현재 상태와 주의사항
A2A는 Google이 2025년에 발표한 비교적 새로운 프로토콜이다. MCP보다 역사가 짧고, 구현체와 레퍼런스가 아직 충분하지 않다.
- A2A: Google이 주도, 에이전트 간 통신에 특화, 아직 생태계 형성 중
- MCP: Anthropic이 주도, 에이전트-도구 연결에 특화, 상대적으로 생태계 성숙
두 프로토콜이 경쟁 관계가 아니라 보완 관계라는 점은 명확하다. Google도 MCP를 지원하고, Anthropic도 에이전트 간 통신을 위한 표준화에 관심을 보이고 있다.
마무리
- A2A는 에이전트 간 통신, MCP는 에이전트-도구 연결이다
- 5가지 패턴은 점진적으로 적용 가능하다 — 단순한 1번부터 시작해서 필요에 따라 확장
- 배포 독립성과 조직 간 협업이 멀티 에이전트의 핵심 장점이다
- A2A는 아직 생태계가 형성 중이라 도입 시 주의가 필요하다
멀티 에이전트 시스템의 복잡성은 개별 에이전트 개발보다 에이전트 간 인터페이스 설계에서 온다. A2A와 MCP는 이 인터페이스를 표준화하려는 시도다.
참고:
같은 카테고리 · AI
비슷한 주제의 최신 글
태그가 겹치는 글
공통 태그가 많을수록 위에 보인다