참고 학습 목표
- A2A가 등장하게 된 배경(단일 에이전트의 한계)을 설명할 수 있다
- A2A와 MCP의 차이를 명확히 구분하고, 함께 사용하는 아키텍처를 설계할 수 있다
- Agent Card의 구조와 역할을 JSON 수준에서 이해한다
- Task 라이프사이클(submitted → working → completed)을 추적할 수 있다
- 실제 시나리오(여행 예약 등)에서 A2A 기반 에이전트 협업을 설계할 수 있다
A2A 등장 배경: 왜 에이전트 간 통신 표준이 필요한가?
단일 에이전트의 한계
하나의 AI Agent가 모든 작업을 처리하는 데에는 근본적인 한계가 있습니다.성공 비유: 한 사람이 회계, 법률, 마케팅, 개발을 모두 하면 전문성이 떨어집니다. 각 분야 전문가가 표준화된 업무 프로토콜 로 협업하는 것이 더 효율적입니다. A2A는 이 “업무 프로토콜”에 해당합니다.
기존 Multi-Agent의 문제
기존에는 여러 Agent를 협업시키려면 동일한 프레임워크 안에서만 가능했습니다. A2A는 이 제약을 없애고, 이기종 Agent 간 상호운용성 을 제공합니다.A2A를 이해하기 위한 배경 지식
REST API를 설계해 본 경험이 있다면 A2A의 구조를 빠르게 이해할 수 있습니다. 하지만 A2A는 기존 API 통신과 근본적으로 다른 철학을 가지고 있으므로, 그 차이를 먼저 짚고 넘어가겠습니다.분산 시스템의 기본 원리: CAP 정리와 Agent
분산 시스템을 설계할 때 빠지지 않는 이론이 CAP 정리 입니다. 어떤 분산 시스템도 다음 세 가지를 동시에 만족할 수 없다는 원칙입니다.
A2A 프로토콜은 이 중 AP(가용성 + 분할 내성) 를 우선합니다. 그 이유는 다음과 같습니다:
- Agent는 독립적으로 배포됩니다. 항공 Agent가 다운되어도 호텔 Agent는 계속 작동해야 합니다.
- 네트워크 분할은 현실입니다. 서로 다른 클라우드, 다른 VPC에 배포된 Agent 간 통신 장애는 일상적입니다.
- 일관성은 Task 단위로 보장합니다. 전체 시스템의 강한 일관성(Strong Consistency) 대신, 각 Task의 상태 전이가 올바르게 이루어지는 최종적 일관성(Eventual Consistency) 을 채택합니다.
참고 REST API 개발자를 위한 비유: 마이크로서비스에서 서비스 A가 다운되어도 서비스 B가 동작하는 것과 같은 원리입니다. A2A에서도 각 Agent는 독립적인 서비스이며, 한 Agent의 장애가 전체 시스템을 멈추지 않습니다.
RPC vs REST vs 이벤트 기반 vs A2A
기존 서비스 통신 방식과 A2A는 무엇이 근본적으로 다를까요?
핵심 차이는 Opacity(불투명성) 입니다:
- REST API를 호출할 때, 클라이언트는 엔드포인트가 어떤 DB를 쓰는지, 어떤 로직을 거치는지 어느 정도 예측할 수 있습니다.
- A2A에서 Task를 위임할 때, 클라이언트는 상대 Agent가 어떤 LLM을 쓰는지, 어떤 프롬프트를 사용하는지, 내부적으로 몇 단계를 거치는지 전혀 모릅니다. 알 필요도 없습니다.
주의 Delegation(위임) vs Invocation(호출): REST API는 “무엇을 어떻게 해라”를 지시하는 호출 입니다. A2A는 “이 일을 맡긴다”는 위임 입니다. 위임의 핵심은 “방법의 자율성”을 상대에게 부여하는 것입니다. 이 차이가 Agent 간 통신을 기존 API와 근본적으로 구별합니다.
A2A 핵심 설계 원칙
A2A vs MCP 비교
성공 한 마디 정리: MCP는 “Agent가 도구를 쓰는 방법”, A2A는 “Agent가 다른 Agent에게 일을 맡기는 방법”입니다.