Agent2Agent 프로토콜: 서로 다른 AI 에이전트의 협업 규격

핵심 판단: A2A는 MCP와 경쟁하는 단일 규격이라기보다, 도구 연결보다 높은 계층에서 에이전트가 능력과 작업 상태를 교환하는 문제를 다뤘다.

MCP가 에이전트와 도구·데이터 소스의 연결을 표준화했다면 Agent2Agent는 서로 다른 조직이나 프레임워크의 에이전트가 작업을 맡기고 상태를 주고받는 상황에 초점을 맞췄다. 두 프로토콜을 이름만 보고 하나를 선택할 대상으로 보면 설계 계층을 놓친다. 어떤 신뢰 경계를 가로지르는지가 더 중요한 구분이다.

발표를 한눈에 보기

• 발표 주체: Google Cloud
• 공식 발표일: 2025-04-09
• 대상: Agent2Agent protocol
• 발표 당시 상태: 오픈 프로토콜 사양과 파트너 생태계 공개
• 이 글의 질문: 에이전트 간 협업은 도구 호출과 무엇이 다르고, MCP와 어떻게 함께 배치할 수 있는가?

50개 이상 파트너와 명세·예제 코드를 공개하고 기업 인증과 장기 작업 상태 교환을 다뤘다.

기술 구조: 무엇이 실제로 달라졌나

Agent Card로 능력을 선언하고 HTTP·SSE·JSON-RPC 위에서 메시지, 산출물, 작업 수명주기를 표준화한다.

A2A의 에이전트는 자신의 능력과 접근 정보를 Agent Card로 설명하고, 클라이언트 에이전트는 작업을 생성해 상태와 결과물을 교환한다. 긴 작업, 스트리밍 업데이트, 사람이 개입해야 하는 흐름을 작업 단위로 표현하려는 것이 핵심이다.

도구 호출은 보통 비교적 짧고 구조화된 함수 실행이다. 에이전트 위임은 상대가 내부 계획과 여러 도구를 사용할 수 있으며 완료까지 시간이 길다. 따라서 호출 스키마 외에도 작업 수명주기, 취소, 신원, 결과 출처, 책임 경계를 다뤄야 한다.

작동 흐름: Agent Card 탐색 → 상대의 신원·능력·정책 확인 → 작업 생성 → 진행 상태와 메시지 교환 → 결과물 수신 → 검증·승인 또는 재작업

이 구조에서 개발자가 가져갈 설계 원칙은 다음과 같다:

• MCP는 에이전트-도구 연결, A2A는 에이전트-에이전트 위임이라는 기본 계층을 먼저 구분한다.
• 상대 에이전트의 자기소개를 신뢰하지 말고 조직 신원, 권한, 계약된 결과 형식을 별도로 검증한다.
• 장기 작업에는 취소, 만료, 중복 제출, 부분 결과, 사람 승인 상태를 명시한다.

발표가 바꾼 것과 바꾸지 않은 것

도구 연결 MCP에 이어 에이전트 간 상호운용성이 별도의 표준화 문제로 부상했다.

A2A는 에이전트 생태계의 상호운용성을 모델 API 호환성보다 넓은 문제로 만들었다. 서로 다른 벤더의 에이전트가 업무를 위임하려면 능력 발견과 작업 상태라는 공통 언어가 필요하다. 조직 경계를 넘는 자동화에서는 이 표준 계층이 감사와 교체 가능성에 특히 중요하다.

다만 다음 문제까지 해결됐다고 확대 해석해서는 안 된다:

• 메시지 형식 호환성이 상대 에이전트의 품질이나 선의를 보장하지 않는다.
• 여러 에이전트가 참여하면 오류의 책임 주체와 데이터 보존 위치가 불명확해질 수 있다.
• 업무 의미와 권한 체계는 프로토콜만으로 표준화되지 않으며 도메인 계약이 필요하다.

직접 평가한다면 이렇게 본다

발표사의 종합 점수 하나를 재현하는 것보다, 실제 제품의 입력과 실패 비용에 맞춘 평가가 더 유용하다. 이 주제라면 다음 순서로 확인한다:

• 상대 에이전트가 능력을 과장하거나 지원하지 않는 결과 형식을 반환하는 경우를 시험한다.
• 진행 중 연결 단절, 중복 작업 생성, 늦은 결과, 취소 경쟁 상태를 주입한다.
• 위임 전후로 데이터가 어느 조직과 지역에 저장되는지 감사 로그에서 추적한다.
• 직접 도구 호출, 내부 단일 에이전트, 외부 A2A 위임의 비용과 완료 시간을 비교한다.

에이전트 간 신뢰는 프로토콜 연결 성공으로 성립하지 않는다. 인증된 신원, 최소 공개 데이터, 결과 검증, 계약된 실패 처리가 함께 있어야 한다.

내 판단

A2A와 MCP는 함께 쓸 수 있다. 에이전트는 A2A로 다른 에이전트에게 작업을 맡기고 각 에이전트는 MCP로 자신의 도구를 사용할 수 있다. 다만 계층이 늘수록 추적과 책임은 어려워진다. 실제로 조직 경계를 넘는 위임이 있을 때만 A2A의 복잡성을 도입하는 것이 좋다.

초기 명세의 공급자 구현 편차와 인증·신뢰·책임 소재는 실제 도입에서 추가 설계가 필요했다.

검증 범위

이 글은 공식 발표와 공개된 기술 자료를 바탕으로 구조와 제품 영향을 분석했다. 직접 벤치마크나 장기 운영 검증은 수행하지 않았으며, 발표사가 제시한 수치는 해당 기관의 평가 조건에 한정해 해석했다. 업데이트 시점은 2026년 7월 18일이다.

함께 읽을 글