A2A 프로토콜 도입 가이드: MCP와의 차이부터 v1.0 호환성까지

독립적으로 운영되는 다른 에이전트에 일을 맡겨야 한다면 A2A 프로토콜을 사용합니다. 툴이나 데이터에 접근해야 한다면 Model Context Protocol(MCP)이 적합합니다. A2A v1.0에서는 연동 규약이 달라졌습니다. 따라서 어떤 시스템 사이를 연결하려는지, 양쪽 엔드포인트가 어떤 버전을 지원하는지 함께 살펴야 합니다.

MCP와 A2A의 차이: 툴·데이터 접근과 작업 위임

MCP는 에이전트가 외부 기능에 접근하게 합니다. A2A는 다른 에이전트에 작업의 일부를 책임지고 수행하도록 요청하게 합니다. 하나의 시스템에서 둘을 함께 사용할 수 있습니다.

Model Context Protocol(MCP)은 AI 애플리케이션이 툴과 데이터 소스 등 외부 시스템에 연결하는 방식을 표준화합니다. Agent2Agent(A2A)는 독립적인 에이전트 사이의 통신을 표준화합니다. 공식 문서에서도 두 프로토콜을 상호 보완적인 관계로 설명합니다. MCP 소개, A2A와 MCP의 관계.

MCP 활용 예: 주문 정보 조회

배송 문의에 답하는 고객지원 에이전트를 생각해 보겠습니다. MCP 서버가 주문 조회 툴을 제공합니다. 에이전트는 주문 식별자를 전달하고 주문 데이터를 받아 고객에게 보낼 답변을 작성합니다.

비즈니스 측면의 이점은 주문 시스템과의 연결을 재사용할 수 있다는 점입니다. 레코드 하나를 조회하려고 별도의 에이전트까지 도입할 필요는 없습니다. 이런 툴 연결에 관한 판단은 MCP 서버 가이드에서 다룹니다.

A2A 프로토콜 활용 예: 공급업체 후보 선정 위임

적합한 공급업체 후보 목록이 필요한 구매 어시스턴트를 생각해 보겠습니다. 다른 업체가 운영하는 별도의 소싱 에이전트가 조사 워크플로를 맡습니다. 구매 어시스턴트는 요구사항을 보내고, 배송 조건을 확인하는 추가 질문에 답한 뒤, 구조화된 후보 목록을 받습니다.

구매 어시스턴트는 소싱 에이전트의 검색 방식이나 사용 모델, 내부 처리 순서를 알 필요가 없습니다. 필요한 것은 합의된 요청 방식과 쓸 수 있는 결과물입니다. A2A는 바로 이런 에이전트 사이의 연결을 지원하도록 설계되었습니다.

소싱 에이전트가 내부적으로 카탈로그 데이터를 가져올 때는 MCP를 사용할 수도 있습니다. 이 구조에서는 A2A가 작업 위임을 담당하고, MCP가 데이터 접근을 제공합니다.

판단 기준은 필요한 인터페이스입니다. MCP 툴도 내부에 복잡한 로직을 구현할 수 있습니다. 내부 동작이 얼마나 지능적으로 보이는지보다, 다른 시스템을 스킬을 탐색할 수 있고 작업 수명주기를 갖춘 에이전트로 공개해야 하는지를 기준으로 A2A를 선택합니다.

A2A 프로토콜이란 무엇입니까?

A2A는 서로 다른 업체나 프레임워크로 만든 에이전트가 공유하는 통신 규약입니다. 호출자는 상대 에이전트의 내부 메모리, 툴, 의사결정 로직에 접근하지 않고도 상호작용할 수 있습니다. 프로토콜 사이트는 이런 내부 요소가 외부에 드러나지 않는다는 뜻으로 ‘불투명하다(opaque)’고 표현합니다. A2A 개요.

호출하는 쪽은 A2A 클라이언트, 요청을 받는 시스템은 A2A 서버이며 원격 에이전트라고도 합니다. 전문 기능을 외부에서 도입하는 창업자라면, 전문 에이전트의 구현을 다시 만드는 대신 서비스 간 인터페이스에 집중해 연동할 수 있다는 의미입니다.

A2A는 누가 개발했고, 누가 관리합니까?

공식 사이트는 개발 주체와 이관 경위를 명확히 밝힙니다. “A2A는 원래 Google이 개발했으며 Linux Foundation에 기증되었습니다.” 또한 기술운영위원회(Technical Steering Committee)가 프로젝트를 유지·관리한다고 설명합니다. 따라서 현재 프로젝트에는 최초 개발 주체를 넘어서는 거버넌스 구조가 있습니다. 거버넌스와 오픈 소스.

명세와 SDK 링크, 샘플은 a2aproject/A2A 저장소에서 확인할 수 있습니다. A2A 자체는 프로토콜이므로, 에이전트를 개발하고 운영할 소프트웨어는 별도로 선택해야 합니다.

A2A 프로토콜 명세에서 알아야 할 핵심 개념

대화, 진행 상황을 추적하는 작업, 그 작업의 결과물을 구분하는 것이 핵심입니다. 이 개념을 분리하면 프로토콜에 맞춰 시스템을 설계하기가 수월해집니다.

Agent Card: 에이전트의 기능과 연결 방법을 확인하는 문서

Agent Card는 에이전트의 식별 정보, 스킬, 지원 기능, 연결 정보, 인증 요구사항을 담은 JSON 메타데이터 문서입니다. 클라이언트는 이를 보고 해당 에이전트에 접속할지, 어떻게 접속할지 판단합니다. 핵심 개념.

소싱 사례라면 카드에 공급업체 조사 스킬이 명시될 수 있습니다. 이는 연동의 출발점이지, 최종 후보 목록이 구매 기준을 충족한다는 증거는 아닙니다.

문서에 명시된 표준 탐색 경로는 /.well-known/agent-card.json입니다. 직접 설정하거나 관리되는 레지스트리를 통해 카드를 가져올 수도 있습니다. A2A는 이런 레지스트리를 위한 표준 API를 정하지 않습니다. 에이전트 탐색.

태스크, 메시지, Part, 아티팩트는 어떻게 다릅니까?

**태스크(task)**는 식별자와 수명주기가 있고 상태를 유지하는 작업 단위입니다. **메시지(message)**는 한 차례의 의사소통입니다. Part에는 실제 텍스트, 파일 내용이나 참조, 구조화된 데이터가 들어갑니다. **아티팩트(artifact)**는 태스크를 수행하는 동안 생성되는 구체적인 결과물입니다. 핵심 개념.

공급업체 사례에서 “어느 지역으로 배송해야 합니까?”는 의사소통입니다. 진행 상황을 추적하는 소싱 업무는 태스크이고, 완성된 후보 목록은 아티팩트입니다. 구매 워크플로는 대화 기록에서 완성된 것처럼 보이는 내용을 찾는 대신, 후보 목록을 결과물로 받아 처리해야 합니다.

에이전트는 그 자체로 완결된 메시지를 반환할 수도, 태스크를 생성할 수도 있습니다. 서로 관련된 상호작용은 contextId로 묶습니다. 태스크가 종료 상태에 도달한 뒤 수정이 필요해지면 기존 태스크를 재시작하지 않고 새 태스크를 시작합니다. 태스크의 수명주기.

결과물을 받은 뒤 구매 담당자가 요구사항을 바꾸는 상황에서는 이 구분이 중요합니다. 최초 후보 목록을 식별할 수 있게 유지하고 수정은 새 작업으로 처리해야, 후속 사용자가 자신이 승인한 결과가 무엇인지 알 수 있습니다.

전송 방식: 같은 규약을 어떻게 주고받습니까?

전송 방식 또는 프로토콜 바인딩은 연결을 통해 각 연산을 주고받는 방법을 정의합니다. 명세에는 JSON-RPC, gRPC, HTTP+JSON/REST 바인딩이 정의되어 있습니다. Agent Card의 인터페이스 정보는 엔드포인트, 바인딩, 프로토콜 버전을 명시합니다. A2A 명세.

폴링, 스트리밍, 푸시 알림은 태스크 업데이트를 전달받는 방식으로, 바인딩과는 별개의 선택입니다. 구매 대시보드에는 폴링으로 충분할 수 있지만, 상호작용이 중요한 화면에서는 점진적인 업데이트가 필요할 수 있습니다. 해당 기능을 전제로 인터페이스를 설계하기 전에 실제 엔드포인트의 지원 여부를 확인해야 합니다.

A2A v1.0에서는 무엇이 달라졌습니까?

기존 연동은 호환성을 검토해야 합니다. 버전 문자열만 바꿔서는 충분하지 않습니다. 아래는 공식 변경 안내 페이지가 v0.3.0과 v1.0을 비교해 설명한 내용입니다.

• 공통 정의: a2a.proto가 프로토콜을 정의하는 기준이 되며, 프로토콜 바인딩별 정식 명세가 제공됩니다.
• 전송 데이터 형식 변경: 통합된 Part가 개별 콘텐츠 유형을 대체합니다. kind 구분자 대신 멤버 이름을 사용하고, 열거형 값은 SCREAMING_SNAKE_CASE를 따릅니다.
• Agent Card 재구성: supportedInterfaces에 연결 세부 정보를 묶고, 인터페이스마다 프로토콜 버전을 선언합니다.
• 연산 변경: message/send는 SendMessage로 바뀝니다. ListTasks는 필터와 커서 기반 페이지네이션을 지원하는 목록 조회를 추가합니다.
• 기업 환경 관련 변경: 테넌트 필드, Agent Card 서명 검증 규칙, 변경된 OAuth 흐름을 연동 설계에 반영해야 합니다.

이 변경 사항은 2026년 10월 12일 프로젝트의 v1.0 변경 안내 페이지를 기준으로 확인했습니다.

기존 커넥터를 점검할 때는 직렬화된 요청, 응답 파싱, 카드 탐색, 사용 중인 연산을 함께 검토해야 합니다. 연결이 된다는 사실만으로 모든 상호작용이 여전히 올바르게 동작한다고 판단할 수는 없습니다.

어떤 프레임워크와 플랫폼이 A2A를 지원합니까?

A2A 구현을 문서화한 제품은 있지만, 지원 버전과 기능 범위는 서로 다릅니다. 워크플로에 필요한 동작을 기준으로 선택해야 합니다. 아래 지원 현황과 제약은 2026년 10월 12일 각 개발사의 공개 문서로 확인했으며, 제품에 로그인해 직접 테스트하지는 않았습니다.

Google Agent Development Kit

에이전트 개발 프레임워크인 Google Agent Development Kit(ADK)는 에이전트를 공개하고 Agent Card를 생성하는 to_a2a를 문서화하고 있습니다. Python A2A 연동은 **실험 단계(Experimental)**로 표시되어 있습니다. 문서상 a2a-sdk 0.3.x와 1.x.x를 지원하며, 새로 연동할 때는 1.x.x를 사용하도록 안내합니다. ADK 에이전트 공개 가이드.

ADK는 원격 에이전트를 호출하는 RemoteA2aAgent도 문서화하고 있습니다. 따라서 ADK로 개발하는 경우 작업을 위임하는 쪽과 받는 쪽 모두 공식 문서에서 구현의 출발점을 찾을 수 있습니다. 래퍼가 편리하더라도 배포 여부를 결정할 때는 실험 단계라는 점을 고려해야 합니다. ADK 원격 에이전트 호출 가이드.

LangSmith Agent Server를 통한 LangGraph 연동

LangGraph 배포용 서빙 계층인 LangSmith Agent Server는 /a2a/{assistant_id}에 A2A 엔드포인트를 제공합니다. 문서에는 v1.0 JSON-RPC 바인딩을 사용하고 v0.3 메서드 이름도 허용한다고 명시되어 있습니다. 그래프 상태에는 messages 필드가 필요합니다. LangSmith A2A 문서.

같은 페이지에는 제약도 나와 있습니다. gRPC와 HTTP+JSON은 구현되어 있지 않으며, SubscribeToTask와 푸시 알림 설정도 아직 지원하지 않습니다. 메시지 스트리밍을 지원한다고 해서 모든 구독·알림 연산을 제공하는 것은 아닙니다. 백그라운드 작업의 처리 방식을 정하기 전에 연산별 지원 범위를 확인해야 하는 구체적인 이유입니다.

CrewAI와 CrewAI AMP

에이전트를 조율하는 프레임워크인 CrewAI는 원격 작업 위임을 위한 A2AClientConfig와 에이전트 공개를 위한 A2AServerConfig를 문서화하고 있습니다. 하나의 에이전트가 두 역할을 모두 수행하도록 설정할 수 있습니다. CrewAI 작업 위임 문서.

배포 플랫폼인 CrewAI AMP는 A2A 서버 에이전트를 **초기 릴리스(early release)**로 표시하고, 프로토콜 버전 0.2와 0.3을 명시합니다. 또한 오픈 소스 구현의 메모리 내 상태 저장 대신 영속적인 분산 스토리지를 사용한다고 설명합니다. CrewAI에 A2A 지원이 있다는 사실만으로 AMP 엔드포인트도 v1.0을 지원한다고 가정해서는 안 됩니다. AMP의 A2A 지원.

Microsoft Foundry Agent Service

관리형 에이전트 플랫폼인 Microsoft Foundry Agent Service는 프로토콜 1.0용 a2a 툴 유형을 정식 출시(GA) 기능으로 문서화하고 있습니다. 이전 a2a_preview 툴 유형은 0.3을 지원하며 여전히 프리뷰 단계입니다. Microsoft는 새 연동에 정식 출시된 유형을 사용하도록 권장합니다. Foundry A2A 문서.

해당 페이지는 Foundry 에이전트를 대상으로 연결할 때 텍스트만 지원하며 스트리밍 응답은 지원하지 않는다고도 명시합니다. 멀티미디어 결과물을 스트리밍으로 받아야 하는 워크플로라면 이 제약을 고려해야 합니다. 프로토콜이 허용하는 콘텐츠 유형을 모든 호스팅 플랫폼이 구현한다고 볼 수는 없습니다.

프레임워크 자체를 고르는 데는 AI 에이전트 프레임워크 비교를 참고하면 됩니다. 여기서 정리한 연동 정보는 더 구체적인 질문, 즉 에이전트를 서비스하는 시스템이 어떤 A2A 인터페이스를 문서화하고 있는지에 답합니다.

개발자·운영자·구매 담당자는 무엇을 따져야 합니까?

추가 서비스를 운영할 가치가 있다면, A2A를 통해 재사용하기 쉬운 연동 구조를 얻을 수 있습니다. 다만 의사결정을 맡은 역할에 따라 살펴야 할 사항은 다릅니다.

개발자: 전송 방식을 추가하기 전에 무엇을 위임할지 정의해야 합니다. “출처와 선정 근거를 포함한 후보 목록을 만들어 주세요”는 서비스에 맡기는 일입니다. “이 데이터베이스를 조회해 주세요”는 툴에 맡기는 일입니다. 두 요청이 결국 모델 호출로 이어지더라도 이 구분은 유지해야 합니다.

운영자: 작업을 넘긴 뒤 누가 책임질지 정해야 합니다. 구매 사례에서는 소싱 에이전트가 추가 정보를 요청하거나, 응답을 멈추거나, 수락 기준에 맞지 않는 후보 목록을 반환했을 때 어떻게 처리할지 누군가 결정해야 합니다. 메시지 형식을 공유한다고 이런 책임까지 정해지는 것은 아닙니다.

구매 담당자와 창업자: 지원 프로토콜 버전, 바인딩, 연산, 콘텐츠 유형, 배포 상태를 확인해야 합니다. 이 정보를 워크플로 요구사항과 나란히 놓고 비교합니다. 세부 정보가 빠진 호환성 설명만으로 연동을 추진하기로 결정하기에는 부족합니다.

A2A 도입 예산은 어떻게 계산합니까?

A2A에는 월별 비용을 일괄 계산할 수 있는 단일 배포 구성이 없습니다. 외부에서 호스팅하는 전문 에이전트를 쓰는 경우와 직접 서비스를 운영하는 경우는 비용 항목이 다릅니다. 프로토콜 문서도 모든 플랫폼에 적용되는 공통 가격을 제시하지 않습니다.

동일한 예산 기간을 기준으로 다음 식을 적용합니다.

연동의 순편익 = 절감한 커넥터 비용 − 마이그레이션 비용 − 추가 인프라 비용 − 지속적인 운영 비용.

운영 비용에는 모델 사용량, 호스팅, 태스크 저장소, 모니터링, 장애 대응 책임에 드는 비용을 포함합니다. 각 항목에는 실제로 부담하는 비용을 넣어야 합니다. 새 연동 지점을 유지하는 비용을 감당할 만큼 반복적인 통합 작업을 줄일 수 있을 때 A2A를 도입할 가치가 있습니다.

A2A에 대한 기대 중 과장된 부분은 무엇입니까?

공통 프로토콜만으로 낯선 에이전트를 신뢰할 수 있게 되거나 분산 작업의 신뢰성이 자동으로 보장되지는 않습니다. 표준화의 효용은 있지만, 애플리케이션 차원의 결정은 여전히 직접 내려야 합니다.

Agent Card는 서비스가 제공하는 기능을 알립니다. 운영 주체를 신뢰할지, 결과물을 받아들일지는 별도로 판단해야 합니다. A2A의 기업 환경 가이드는 실제 동작에 대한 권한을 포함해 인증과 인가를 강제할 책임이 구현에 있다고 설명합니다. 기업 환경 구현 가이드.

소싱 워크플로에서는 조사 권한을 허용하더라도 구매 권한까지 묵시적으로 부여해서는 안 됩니다. 추천을 반환하는 행위와 주문을 실행하는 행위는 애플리케이션에서 별도 권한으로 관리해야 합니다.

반환된 아티팩트, 해당 태스크의 상태, 자체 수락 기록을 각각 별도의 관리 대상으로 다뤄야 합니다. 위임한 워크플로가 구매 주문을 생성하도록 허용하기 전에, 애플리케이션이 업무 동작의 중복을 어떻게 감지하고 결과가 불확실한 상황에서 어떻게 복구할지 정해야 합니다.

모든 내부 하위 에이전트 호출에 A2A를 추가하는 것도 과도한 적용입니다. 프로젝트가 정한 범위에서도 에이전트 내부의 하위 에이전트 호출이나 툴 호출 방식을 규정하는 일은 명시적으로 제외합니다. 구성 요소가 같은 애플리케이션 규약 아래 있다면, 프레임워크가 기본 제공하는 구성 방식으로 이미 충분할 수 있습니다. A2A의 범위.

A2A와 MCP 중 무엇이 필요합니까? 둘 다 써야 합니까?

현재 제품에서 실제로 연결해야 하는 대상부터 살펴야 합니다.

에이전트가 재사용 가능한 툴 인터페이스를 통해 업무 시스템, 파일, API에 접근해야 한다면 MCP를 선택합니다. 직접 기능을 공개해야 한다면 Python MCP 서버 구축 가이드를 따릅니다. 여러 연결의 접근 권한을 통제하는 것이 과제가 되면 MCP 게이트웨이 해설에서 해당 계층을 살펴볼 수 있습니다.

독립적으로 운영되는 다른 에이전트가 의미 있는 업무를 맡고, 그 인터페이스를 탐색하고 지시를 주고받으며 작업 진행 상황을 추적하는 공통 방식이 필요하다면 A2A를 선택합니다. 이미 그런 연동 요구가 있고 양쪽 엔드포인트가 호환되는 기능을 문서화하고 있다면 지금 도입을 진행할 수 있습니다.

에이전트가 전문 에이전트에 작업을 위임하고, 그 전문 에이전트도 툴과 데이터를 필요로 한다면 둘 다 선택합니다. 소싱 사례가 여기에 해당합니다. 조사 작업의 위임에는 A2A를, 에이전트 내부의 카탈로그 접근에는 MCP를 사용합니다.

외부 전문 에이전트가 아직 구상에만 있다면 A2A 도입은 기다려도 됩니다. 현재 툴만으로 충분히 동작하는 에이전트가 새로운 에이전트 간 프로토콜의 등장 때문에 영향을 받지는 않습니다. 모든 내부 함수 호출에 이 두 표준 중 하나를 적용할 필요도 없습니다. 실제 연동 문제를 해결하는 연결 규약을 채택해야 합니다.

다음 개발 단계에서는 무엇부터 해야 합니까?

주변 기술 스택을 마이그레이션하기 전에, 범위가 좁고 구체적인 업무 결과에 대해 작업 위임 규약을 작성합니다. 구매 어시스턴트라면 공급업체 후보 목록부터 시작하고, 구매 실행은 초기 범위에서 제외합니다.

1. 1

   수락할 수 있는 아티팩트의 기준을 정합니다

   후보 목록에 반드시 들어가야 할 정보, 수락할 수 없는 조건, 수락된 결과를 기록할 애플리케이션을 명시합니다. 원격 에이전트의 책임 범위를 한정해야 합니다.

2. 2

   문서에 명시된 인터페이스가 맞는지 확인합니다

   클라이언트와 서버의 프로토콜 버전, 바인딩, 인증 요구사항, 필요한 연산을 기록합니다. 워크플로에 스트리밍이나 푸시 전달이 필요한지, 양쪽 엔드포인트가 이를 지원하는지 확인합니다.

3. 3

   완료되지 못한 상황의 처리 방식을 설계합니다

   추가 확인, 타임아웃, 거절, 재시도 후에도 결과를 확신할 수 없는 응답을 누가 처리할지 정합니다. 작업이 진행 중일 때 사용자에게 무엇을 보여 줄지, 수정된 아티팩트가 이전 결과물을 어떻게 대체할지도 정의합니다.

이 규약은 A2A 도입의 구체적인 판단 근거가 됩니다. 작성 과정에서 전문 에이전트라고 생각했던 대상이 단지 레코드를 조회하는 역할에 그친다는 사실이 드러난다면, 툴 연결부터 구현합니다.

A2A 도입 전에 자주 묻는 질문

MCP 없이 A2A만 사용할 수 있습니까?

가능합니다. A2A는 원격 에이전트가 자체 툴과 데이터에 접근하는 방식을 정하지 않습니다. 툴 연결도 표준화해야 할 때 MCP가 유용합니다. 두 프로토콜을 함께 사용하는 방법.

두 에이전트가 같은 프레임워크를 사용해야 합니까?

아닙니다. 서로 다른 프레임워크 사이의 상호 운용성은 A2A의 핵심 목적입니다. 맞아야 하는 것은 에이전트의 내부 구현이 아니라 외부에 공개된 인터페이스와 상호작용에 필요한 기능입니다. A2A 개요.

실제로 쓸모 있는 에이전트 시스템을 만드는 실전 가이드를 받아보려면 뉴스레터를 구독하세요.