2026년 A2A 대 MCP: 에이전트가 도구를 호출하는 대신 다른 에이전트와 소통해야 하는 경우

거의 모든 2026년 에이전트 설계 논의에서 두 가지 프로토콜, 즉 MCP와 A2A가 등장합니다. 이들은 종종 경쟁자로 제시되지만, 이것이 첫 번째 실수입니다. MCP와 Agent2Agent는 서로 다른 계층에서 서로 다른 문제를 해결하며, 실제 운영 시스템은 이 둘 모두를 필요로 하는 경우가 많습니다. 유용한 질문은 어느 하나를 표준화할지 여부가 아니라, 주어진 통합이 실제로 어떤 방향을 가리키는지—당신이 호출하는 도구 쪽인지, 아니면 위임하는 동료(peer) 쪽인지를 결정하는 것입니다.

단 하나의 테스트 질문

연결된 반대편 시스템에 대해 한 가지를 물어보세요. 그것이 목표를 가지고 자체 결정을 내리는지, 아니면 역량을 노출하고 호출되기를 기다리는지를 말입니다?

• 만약 그것이 역량(카탈로그 검색, 쿼리 실행, 파일 읽기, 송장 생성 등)이라면, 그것은 **도구(tool)**입니다. 호출하는 에이전트가 결정권자 역할을 유지합니다. 이것이 MCP의 영역입니다.
• 만약 그것이 목표를 받아들이고, 여러 단계를 계획할 수 있으며, 명확화 질문을 할 수도 있고, 나중에 보고할 수도 있는 자율적인 작업자(autonomous worker)라면, 그것은 **동료 에이전트(peer agent)**입니다. 이것이 A2A의 영역입니다.

결제 API가 도구로 래핑된 경우, 지시를 받으면 주문을 환불합니다. 반면, A2A용으로 래핑된 청구 에이전트는 '지난 분기 실패한 갱신 건 처리'와 같은 메시지를 받고 필요한 환불, 재시도 및 이메일의 수를 결정할 수 있습니다. 오직 후자만이 에이전트가 될 자격이 있습니다.

각 프로토콜이 실제로 정의하는 것

발견이 핵심 단서입니다

두 프로토콜은 여러분이 그것들을 찾는 방식에서 경계를 드러냅니다.

MCP 서버는 사용자가 설정하는 것입니다. 에이전트에게 서버 명령어 또는 URL과 자격 증명을 제공하며, 임의의 클라이언트가 이를 발견할 것이라는 가정은 없습니다.

반면, A2A 에이전트는 잘 알려진 경로(well-known path)에 Agent Card를 게시하여 다른 에이전트들이 사적인 소개 없이도 이를 찾고 이해할 수 있게 합니다:

curl https://billing-agent.example.com/.well-known/agent-card.json

이 카드는 에이전트의 이름과 목록화된 기술(skills), 그리고 지원하는 인터페이스 바인딩을 광고합니다. 하나의 카드만으로 동일한 에이전트에 대한 JSON-RPC, REST (HTTP+JSON), gRPC 엔드포인트를 노출할 수 있습니다:

{
  "name": "Billing Agent",
  "description": "갱신, 환불 및 청구서 분쟁 처리"
... 
}

클라이언트는 이 공개된 문서 하나를 가져와 기술과 바인딩을 읽고, 어떻게 대화할지 선택합니다. MCP에는 호출자가 이미 서버를 알고 있다고 가정하기 때문에 이에 상응하는 공개적인 "도구 이력서(tool resume)"가 없습니다.

작업은 상태적이지만 도구 호출은 그렇지 않다

최소한의 A2A 1.0 JSON-RPC 메시지는 다음과 같습니다:

{
  "jsonrpc": "2.0",
  "id": "a17c2e10-7b6e-4f9a-9d3a-2b8c4e6f1a00",
... 
}

버전 관리는 알지 못할 수 없는 것

A2A 1.0과 이전의 0.3 라인은 와이어 호환성(wire compatible)이 없습니다. 메서드 이름이 변경되었고(SendMessage 대 message/send), 메시지 부분이 모양을 바꿨습니다 (1.0은 역할(role)로 ROLE_USER를 사용하는 { "text": "..." }를 사용하고; 0.3은 user와 함께 { "kind": "text", "text": "..." }를 사용합니다). 또한 전송 방식의 이야기가 다릅니다: 0.3은 JSON-RPC인 반면, 1.0은 REST와 네이티브 gRPC 바인딩을 추가했습니다. 클라이언트는 가정한 것이 아니라 카드의 protocolVersion을 읽고 그 방언(dialect)으로 대화해야 합니다. MCP도 자체적인 버전 진화가 있지만, 에이전트 간의 표면(surface)은 발견 과정에서 버전을 명시적으로 제공하기 때문에 불일치가 더 크게 드러납니다.

결합되는 지점

성숙한 패턴은 선택이 아니라 스택입니다:

• 전문 A2A 에이전트가 위임된 목표를 받습니다.
• 내부적으로, 해당 에이전트는 작업을 수행하기 위해 MCP 도구와 일반 HTTP API를 사용합니다.
• 그것은 A2A를 통해 요청한 에이전트에게 작업 상태를 보고합니다.

이러한 토폴로지에서 A2A는 자율 단위 간의 팀 간 프로토콜이며, MCP는 에이전트가 기능을 사용하기 위해 사용하는 팀 내부 프로토콜입니다. A2A를 통해 상태 비저장(stateless) 조회만 강제하면 절대 진행되지 않을 작업 상태 기계(task state machine)를 얻게 됩니다. 목표 소유자(goal-owning)이며 다단계 워커(multi-step worker)를 MCP에 넣는 것은 호출자에게 워커 경계 뒤에 있어야 할 오케스트레이션 책임을 남깁니다.

실용적인 결정 체크리스트

MCP를 사용해야 하는 경우: 상대방이 자체 목표가 없는 알려진 기능일 때, 작업이 단일 호출 또는 직접 스트림일 때, 그리고 당신의 에이전트가 오케스트레이터로 남아 있어야 할 때.

A2A를 사용해야 하는 경우: 상대방이 자체 계획 및 기술을 가진 별개의 에이전트일 때, 작업이 여러 단계 또는 시간을 걸쳐 진행될 때, 공개적인 검색(public discovery)과 기능 재개(capability resume)가 필요할 때, 또는 작업 상태, 스트리밍 업데이트, 취소(cancellation)를 일급 개념으로 필요로 할 때.

둘 다 사용해야 하는 경우: 자율 에이전트들이 협업해야 하지만 각각 여전히 아래에 있는 도구들을 사용하는 경우.

과도하게 에이전트를 만들려는 유혹은 현실적입니다. 모든 내부 API를 Agent Card로 감싸면 목표를 소유하지 않는 피어(peers) 네트워크가 생성되는데, 이는 대체한 도구들보다 디버깅하기 더 어렵습니다. 도구부터 시작하고, 실제 위임 가능한 목표가 존재할 때만 무언가를 에이전트로 승격시키세요.

두 프로토콜을 한곳에서 나란히 보고 싶다면, Powerduck 작업 공간을 사용하면 동일한 로컬 API 사양에 대해 MCP 엔드포인트와 A2A 에이전트 모두를 설계하고 디버깅할 수 있습니다 (Agent Card 검색, 시그니처 검증, JSON-RPC, REST, gRPC 바인딩 포함). 온라인 데모에서는 사양 기반 루프(spec-driven loop)를 보여주며, 도구에서 에이전트로의 프레이밍은 AI 에이전트를 위한 API 설계에서 다루고 있습니다.