A2A와 MCP 차이: 도구 연결과 에이전트 간 위임은 무엇이 다를까

두 도자기 작업 트레이 사이에 걸쳐 놓인 봉투. 이해를 돕기 위한 AI 생성 개념 이미지입니다.

MCP를 알게 된 뒤 A2A를 보면 비슷한 연결 규약처럼 느껴집니다. 둘 중 하나가 다른 하나를 대체한다고 생각하기보다, 연결 상대에게 무엇을 맡길지부터 보면 차이가 분명해집니다.

외부 기능 호출인지, 상태를 가진 일을 다른 에이전트에 맡기는지부터 구분하세요.

“조회해줘”와 “조사해서 결과를 보내줘”의 차이

가상의 도서 추천 서비스를 생각해 보겠습니다. 도서 검색 기능에 제목과 저자를 보내 목록을 받는 일은 기능 호출에 가깝습니다. 다른 서비스의 추천 에이전트에게 독자의 조건을 맡기고, 추가 질문을 주고받으며 추천 보고서를 기다리는 일은 작업 위임에 가깝습니다.

A2A의 공식 비교 문서는 MCP를 도구·자료 연결, A2A를 독립적인 에이전트 간 협업의 규약으로 설명합니다. 다만 “MCP는 무조건 짧고 상태가 없다”처럼 절대적인 구분으로 외우지는 마세요. 핵심은 호출 시간보다 상대 시스템과 협업하는 계약입니다.

A2A에서는 작업과 대화와 결과물을 나눕니다

공식 핵심 개념에 나오는 Agent Card는 상대의 기능·접점·인증 요구 등을 설명하는 메타데이터입니다. Task는 식별자와 생애주기를 가진 작업이고, Message는 대화 한 차례이며, Artifact는 작업에서 만들어진 결과물입니다.

도서 추천 사례에 적용하면 다음과 같습니다. 이 표는 실제 API 응답이 아닌 개념 대응입니다.

구성 요소	가상 서비스에서의 의미
Agent Card	어떤 추천 업무를 받고 어떻게 인증하는지
Task	이번 독자를 위한 추천 조사 한 건
Message	“입문서만 원하시나요?”라는 추가 질문
Artifact	추천 이유와 출처를 담은 최종 문서

“처리 중입니다”라는 메시지를 받았다고 추천 문서가 도착한 것은 아닙니다. 받는 쪽에서는 작업 상태와 결과물을 각각 처리해야 합니다. 반대로 바로 답할 수 있는 요청은 항상 긴 Task로 만들 필요가 없다는 것도 공식 개념 설명에 포함됩니다.

MCP와 비교할 때는 응답의 단위도 기록합니다.

확인 지점	MCP 도구 호출	A2A 에이전트 협업
상대가 설명하는 것	도구·자료·입력 스키마	Agent Card의 identity·endpoint·skill·인증 요구
요청 결과	구조화된 도구 결과	즉시 Message 또는 추적할 Task
오래 걸리는 작업	호출 시간과 호스트 정책을 별도 설계	Task ID·상태 조회·스트리밍·push 알림 검토
결과물	도구 반환값	Artifact와 그 안의 Part·출처·파일 참조
전송 경계	MCP transport와 JSON-RPC	A2A HTTP(S)와 JSON-RPC payload

A2A의 Message와 Artifact는 텍스트만 담는다고 가정하지 않습니다. 공식 개념 문서는 Part에 텍스트, URL·inline bytes 파일, 구조화 데이터를 담을 수 있다고 설명합니다. 따라서 “보고서가 왔다”는 로그보다 어떤 Part와 MIME type, 원격 파일 URL을 받았는지까지 결과 계약에 넣어야 합니다.

내부 도구까지 공개할 필요는 없습니다

추천 에이전트가 내부적으로 어떤 모델을 쓰고 어떤 검색 도구를 호출하는지는 A2A를 호출한 쪽에서 보이지 않을 수 있습니다. 그래서 서로 다른 구현을 연결하기에는 유용하지만, 상대의 판단 과정을 자동으로 감사할 수 있다는 뜻은 아닙니다.

필요한 출처나 결과 형식은 별도로 합의해야 합니다. 예컨대 “책 제목만”이 아니라 “책 제목, 추천 조건, 공개 소개 페이지”를 결과 계약으로 정할 수 있습니다. 응답에 URL이 있다는 것과 그 페이지가 추천 이유를 실제로 뒷받침하는지도 별개입니다.

같은 시스템 안에서 둘을 함께 쓸 수 있습니다

외부 추천 에이전트에는 A2A로 일을 맡기고, 그 에이전트가 내부 도서 검색 기능에는 MCP로 접근하는 구성이 가능합니다. 도구 연결과 협업을 각각 맞추는 것이지, 규약 두 개를 붙였기 때문에 품질이 좋아지는 것은 아닙니다.

단일 앱에서 함수 하나를 부르면 끝나는 일이라면 A2A 도입 필요부터 따져볼 만합니다. 외부 에이전트의 상태 추적, 추가 입력, 비동기 결과 전달이 실제 요구사항일 때 협업 규약을 검토하세요. Agent Card에 인증 방법이 적혔다는 사실만으로 접근 권한이 주어지지는 않습니다.

요청을 어떤 규약으로 보낼지 결정하는 질문

현장에서 “A2A를 쓸까, MCP를 쓸까”를 바로 묻기보다 먼저 요청의 책임 범위를 적는 편이 낫습니다.

질문	기능 호출에 가까움	에이전트 위임에 가까움
요청 한 번의 결과가 명확한가	파일 읽기, 검색, DB 조회	조사 보고서, 여러 단계 예약 처리
상대가 추가 질문을 할 필요가 있는가	보통 적음	조건 확인을 위해 필요할 수 있음
처리 상태를 나중에 다시 조회해야 하는가	단순 호출 결과로 충분할 수 있음	Task 식별자와 상태가 중요
결과가 단일 응답인가	도구 반환값	하나 이상의 Artifact가 될 수 있음
상대의 내부 구현을 알아야 하는가	도구 스키마를 알아야 함	능력과 결과 계약만 공유할 수 있음

예를 들어 “고객 번호 42의 최근 주문을 조회해줘”는 입력과 출력이 정해진 도구 호출로 만들기 쉽습니다. “고객 42의 배송 지연 원인을 조사하고, 물류 담당자에게 확인한 뒤 보고서를 만들어줘”는 중간 상태와 추가 메시지, 최종 산출물을 구분할 이유가 있습니다. 문장이 길어서 A2A인 것이 아니라 상대 에이전트가 작업의 일부 책임과 생애주기를 맡는다는 점이 다릅니다.

Task 생애주기를 놓치면 생기는 오류

가상의 조사 작업을 A2A로 보낸 뒤 HTTP 응답을 받았다고 즉시 성공 처리하면 아직 진행 중인 Task를 끝난 것으로 오해할 수 있습니다. 반대로 Message에 질문이 왔는데 오류로 처리하면 필요한 사용자 입력을 놓칩니다.

호출하는 쪽은 적어도 다음 상태를 구분할 필요가 있습니다.

1. 요청이 접수됐는가.
2. 상대가 추가 입력을 기다리는가.
3. 작업이 진행 중인가.
4. 완료됐고 Artifact를 받을 수 있는가.
5. 실패·취소됐으며 재시도 가능한가.

실제 상태 이름과 필드는 사용 중인 명세 버전을 따라야 합니다. 위 목록은 구현 코드를 대신하는 것이 아니라, Task를 단순 함수 반환값으로 축소하지 않기 위한 처리 항목입니다.

최종 Artifact도 파일이 존재한다는 이유만으로 수락하지 않습니다. 요청한 형식인지, 누락된 범위는 무엇인지, 원자료나 출처로 돌아갈 수 있는지 확인합니다. 작업이 완료 상태여도 결과 계약을 만족하지 못할 수 있습니다.

실패를 조사할 때는 “A2A 연결 실패” 한 줄로 기록하지 않습니다.

증상	먼저 확인할 것	잘못된 결론
Agent Card를 읽었지만 호출할 skill이 없음	skill 입력·출력·인증 요구와 내 요청의 일치	상대 에이전트가 기능이 없다고 단정하지 않기
HTTP 인증은 성공했지만 Task가 거부됨	권한 scope, 입력 Part, 정책상 허용 범위	인증 성공이 작업 승인을 뜻한다고 보지 않기
Task가 오래 working 상태임	polling·SSE·push 지원, 재시도·timeout 정책	서버가 멈췄다고 즉시 중복 작업을 만들지 않기
completed인데 Artifact가 비어 있음	결과 계약, artifact·part·MIME type, 원자료 링크	상태만 보고 업무 성공으로 처리하지 않기
스트림이 끊김	마지막 event·Task ID, 재연결·중복 수신 방지	같은 작업을 무조건 새로 제출하지 않기

이 표는 현재 공개 개념을 운영 진단 순서로 재구성한 것입니다. 실제 상태 이름, 이벤트 형식, 재개 방법은 연동하는 A2A 명세·SDK 버전에 맞춰 확인해야 합니다.

Agent Card는 광고 문구가 아니라 연결 계약의 입구입니다

Agent Card에서 능력 이름만 보고 상대를 고르면 “리서치 가능” 같은 넓은 표현에 의존하게 됩니다. 연결 전에는 다음을 좁혀 적습니다.

• 어떤 입력 형식과 크기를 받는가.
• 인증은 어떤 주체와 권한으로 하는가.
• 비동기 Task와 즉시 응답 중 무엇을 지원하는가.
• 어떤 Artifact를 반환하며 실패는 어떻게 표현하는가.
• 민감한 자료를 보낼 수 있는가, 보존 정책은 무엇인가.

상대 에이전트가 내부에서 MCP 도구를 쓴다고 해도 호출자는 그 도구 목록 전체를 알 필요가 없을 수 있습니다. 대신 “공개 자료만 사용”, “결제 실행 금지”, “보고서에 출처 포함”처럼 결과와 행동의 경계를 계약에 넣어야 합니다. 내부가 불투명하다는 것은 책임이 사라진다는 뜻이 아닙니다.

함께 사용할 때의 한 가지 구조

사용자
  └─ 일정 조정 에이전트
      ├─ A2A → 외부 여행 조사 에이전트
      │          └─ MCP → 공개 교통편 검색 도구
      └─ MCP → 내 캘린더 읽기 도구

이 구조에서 여행 조사 결과를 받는 것과 캘린더에 일정을 쓰는 것은 다른 권한입니다. 외부 에이전트가 “일정도 등록했다”고 답해도 실제 캘린더 쓰기 권한이 없었다면 완료로 취급하면 안 됩니다. 반대로 캘린더 도구를 연결했다고 외부 에이전트에게 그 권한을 전달할 필요도 없습니다. A2A와 MCP를 함께 쓰는 설계에서는 자격 증명과 승인 경계를 층별로 분리해야 합니다.

버전을 맞추기 전에는 개념 비교까지만

이 글은 2026년 9월 7일 공개 문서의 역할 구분을 설명합니다. 구체적인 메시지 필드와 전송 방식은 구현할 SDK 및 명세 버전에 맞춰 확인해야 합니다. 특정 에이전트 두 개를 연결해 호환성을 검증하지는 않았습니다.