안녕하세요, 미니지식공간입니다. A2A 프로토콜(Agent2Agent)이 2026년 8월 17일 AAIF(Agentic AI Foundation, 리눅스 재단 산하 에이전트 표준 재단)의 호스티드 프로젝트가 되면서, MCP(Model Context Protocol)와 같은 거버넌스 아래 놓였다. 이 글은 이관 사실관계를 정리한 뒤, A2A 스펙에서 실제로 코드에 닿는 부분 — 에이전트 카드, 발견 경로, 바인딩과 오퍼레이션 — 을 공식 문서 기준으로 본다.
TL;DR
- 2026-08-17 AAIF 공식 블로그가 A2A 합류를 발표했고, 같은 날 Axios가 단독 보도했다. 신규 기증이 아니라 리눅스 재단 내부의 소속 이동이다.
- A2A는 에이전트↔에이전트, MCP는 에이전트↔도구를 맡는다. 같은 재단이지만 프로젝트와 기술 운영위원회는 분리 유지된다.
- 코드 관점의 진입점은 에이전트 카드다. 표준 경로는
/.well-known/agent-card.json이고, 최신 릴리스는 A2A 1.0.0이다.
1. 이관 사실관계
| 항목 | 내용 | 출처·시점 |
|---|---|---|
| 발표 주체 | Agentic AI Foundation (Linux Foundation) | AAIF 블로그 2026-08-17 |
| 발표 형태 | A2A가 AAIF 호스티드 프로젝트로 합류 | AAIF 블로그 2026-08-17 |
| 최초 공개 | 구글이 A2A 공개 | 2025년 4월 |
| 리눅스 재단 기증 | 창립 조직 AWS·Cisco·Google·Microsoft·Salesforce·SAP·ServiceNow | 2025년 6월 |
| 프로토콜 병합 | IBM Agent Communication Protocol이 A2A로 병합 | 2025년 8월 |
| 첫 안정 스펙 | A2A v1.0 — 다중 프로토콜 바인딩, 버전 협상, 멀티테넌시, 서명된 에이전트 카드 | 2026년 3월 |
| 지지 조직 | 150곳 이상 (재단 자사 발표) | AAIF 블로그 2026-08-17 |
| AAIF 규모 | 2025년 12월 출범 시 40곳 미만 → 250곳 이상 (재단 자사 발표) | Axios 2026-08-17 |
표현이 갈리는 지점이 하나 있다. Axios는 "리눅스 재단의 넓은 포트폴리오에서 에이전틱 AI 전담 재단으로 이동"이라고 썼고, Techstrong.ai(2026-08-18)는 "구글이 A2A를 AAIF에 기여했다"고 썼다. A2A는 2025년 6월부터 이미 리눅스 재단 프로젝트였으므로 전자가 정확한 서술이다. 이관에 따른 저장소·TSC 구성 세부 변화는 공개되지 않았다(확인 필요).
2. 스택에서 A2A가 앉는 자리
AAIF는 자기 프로젝트를 층으로 나눠 설명한다. 이 구분이 곧 "어느 문제에 어느 규약을 쓰는가"의 지도다.
| 계층 | 프로젝트 | 역할 |
|---|---|---|
| 지시·맥락 | AGENTS.md | 프로젝트의 관례·기대·운영 지침을 에이전트에 전달 |
| 에이전트 런타임 | goose | 추론·계획·능력 호출이 일어나는 실행 환경 |
| 에이전트↔도구 | MCP | 도구·데이터소스·앱·서비스 연결 표준화 |
| 트래픽 중재·제어 | agentgateway | 라우팅·정책·관측을 경계에서 처리 |
| 에이전트↔에이전트 | A2A | 독립 에이전트의 발견·통신·위임·결과 교환 |
A2A 공식 문서는 왜 에이전트를 MCP 도구로 감싸면 안 되는지도 명시한다. 도구는 대체로 상태가 없고 정해진 기능을 수행하는 반면, 에이전트는 다중 턴으로 협상하고 되묻고 위임한다. 에이전트를 툴로 래핑하면 이 능력이 잘려 나간다는 것이 문서의 설명이다.
3. 에이전트 카드: 코드가 닿는 첫 지점
A2A에서 상대 에이전트를 쓰려면 먼저 에이전트 카드를 읽는다. 카드는 JSON 문서이며 신원(name, description, provider), 서비스 엔드포인트(url), 능력(streaming, pushNotifications 등), 인증 스킴, 그리고 AgentSkill 목록을 담는다.
아래는 A2A 공식 파이썬 퀵스타트(helloworld 예제)의 스킬 정의 원문이다.
# Defines the abilities or functions that agent can perform.
skill = AgentSkill(
id='echo_bot',
name='Echo Bot',
description='An example agent that acknowledges client request and responds with a "Hello World" message.',
input_modes=['text/plain'],
output_modes=['text/plain'],
tags=['a2a', 'echo-example'],
examples=['hi', 'how are you'],
)같은 예제의 에이전트 카드 정의는 다음과 같다. supported_interfaces가 v1.0에서 눈여겨볼 필드로, 서비스에 닿을 수 있는 엔드포인트와 프로토콜 바인딩을 우선순위 있는 목록으로 선언한다.
# Define a public-facing agent card that allows clients to discover your agent's capabilities.
public_agent_card = AgentCard(
# Basic identity information of A2A server
name='Hello World Agent', # Identity
description='Just a hello world agent',
version='0.0.1',
# Default Media Types for the agent's interactions
default_input_modes=['text/plain'], # Supported media types
default_output_modes=['text/plain'],
# Supported A2A features (like streaming or extended config)
capabilities=AgentCapabilities(streaming=True, extended_agent_card=True),
# Ordered list of endpoints and protocols where the service can be reached
supported_interfaces=[
AgentInterface(
protocol_binding='JSONRPC',
url='http://127.0.0.1:9999',
protocol_version='1.0',
)
],
# The list of AgentSkill objects that this agent offers
skills=[skill],
# Optional attributes (omitted here for simplicity):
# icon_url -> A URL to an icon representing the agent
)위 두 블록은 a2a-protocol.org 공식 퀵스타트 문서의 원문이다.
카드를 찾는 세 가지 방법
공식 문서는 발견 전략을 세 가지로 정리한다.
- Well-Known URI — 표준 경로
https://{agent-server-domain}/.well-known/agent-card.json에 카드를 올린다. RFC 8615를 따른다. 공개 에이전트나 특정 도메인 안에서의 광범위한 발견에 권장된다. - 큐레이티드 레지스트리 — 중앙 레지스트리에 카드를 등록하고 스킬·태그 등으로 질의한다. 단, 현재 A2A 스펙은 레지스트리 API를 규정하지 않는다고 문서가 명시한다.
- 직접 구성 — 설정 파일·환경변수·하드코딩. 정적인 관계에는 간단하지만 동적 발견에는 부적합하다.
문서에 기술된 경로·메서드를 그대로 정리하면 1번 조회는 다음 형태다(조건부 요청 헤더는 문서의 캐싱 지침을 반영했다).
# 1) 최초 조회
curl -sS https://smart-thermostat.example.com/.well-known/agent-card.json
# 2) 재조회 시에는 저장해 둔 ETag로 조건부 요청
curl -sS -H 'If-None-Match: "<stored-etag>"' \
https://smart-thermostat.example.com/.well-known/agent-card.json서버 쪽 지침도 명확하다. 카드 엔드포인트는 Cache-Control에 적절한 max-age를 넣고, 카드의 version 필드나 콘텐츠 해시에서 파생한 ETag를 함께 내려 클라이언트가 조건부 요청을 쓸 수 있게 하라고 문서는 권고한다. 카드에 민감한 정보가 있으면 인증된 확장 에이전트 카드를 쓰고, mTLS·IP 제한·OAuth 2.0 같은 접근 제어를 엔드포인트에 걸라는 권고도 함께 있다. 정적 비밀값을 카드에 박는 대신 대역 외 동적 자격증명을 쓰라는 문장도 명시돼 있다.
4. 바인딩과 오퍼레이션
A2A는 정본 데이터 모델을 프로토콜 버퍼로 정의하고, 모든 바인딩이 기능적으로 동등한 표현을 제공해야 한다(MUST)고 규정한다. 스펙이 정의하는 바인딩은 세 가지다.
| 바인딩 | 스펙 위치 |
|---|---|
| JSON-RPC | Section 9: JSON-RPC Protocol Binding |
| gRPC | Section 10: gRPC Protocol Binding |
| HTTP+JSON/REST | Section 11: HTTP+JSON/REST Protocol Binding |
추상 오퍼레이션은 11종이다. 바인딩별 메서드 이름은 이 목록에 매핑된다.
- Send Message / Send Streaming Message
- Get Task / List Tasks / Cancel Task / Subscribe to Task
- Create·Get·List·Delete Push Notification Config
- Get Extended Agent Card
요청 흐름은 문서의 시퀀스 다이어그램대로 네 단계다. ① GET /.well-known/agent-card로 카드 수신 → ② 카드의 securitySchemes 파싱, openIdConnect이면 authorizationUrl·tokenUrl 기준으로 토큰 발급 → ③ 카드의 url로 sendMessage 호출, 서버가 태스크를 만들고 Task 응답 반환 → ④ 스트리밍이 필요하면 sendMessageStream으로 Task(Submitted) → TaskStatusUpdateEvent(Working) → TaskArtifactUpdateEvent → TaskStatusUpdateEvent(Completed)를 SSE로 수신한다.
현재 최신 릴리스 버전은 1.0.0이며, 프로토콜 버전은 Major.Minor(예: 1.0)로 식별한다. 공식 SDK는 파이썬·Go·자바·자바스크립트·.NET·러스트가 저장소로 공개돼 있다.
5. 반론: 상호운용이 신뢰를 주지는 않는다
Techstrong.ai(2026-08-18) 보도에서 Seekr의 리드 AI 솔루션 아키텍트 마헤시 샨무가순다람은 이번 흐름에 유보를 달았다. 요지는 세 문장으로 정리된다. 개방형 규약은 상호운용을 넓히지만 그만큼 기존의 신뢰 격차도 함께 넓힌다. A2A 체인에서 각 에이전트는 앞 에이전트의 출력을 "검증할 주장"이 아니라 "100% 신뢰할 입력"으로 다루기 쉽다. 그 가정이 박히면 연쇄 실패가 팀의 예상보다 구조적으로 나빠진다.
이 지적은 A2A의 설계 원칙 중 하나인 불투명 실행(opaque execution)과 맞물린다. 문서는 에이전트가 내부 논리·메모리·독자 도구를 노출하지 않고 선언된 능력과 교환된 맥락만으로 협업한다고 설명한다. 지식재산과 보안에는 유리하지만, 받은 결과의 근거를 되짚기는 어려워진다. 근거·신뢰도·추적 정보를 핸드오프의 기본 단위로 만들지 여부는 프로토콜이 아니라 애플리케이션 층의 선택이다.
6. 도입 전 체크리스트
- 상대가 도구인지 에이전트인지 먼저 판정한다. 상태 없는 기능 호출이면 MCP, 다중 턴 위임이면 A2A다.
- 카드 노출 범위를 정한다. 공개 카드에는 최소 정보만 두고, 민감한 스킬·내부 URL은 인증된 확장 카드로 분리한다.
- 카드 캐싱을 설계한다. 서버는
Cache-Control·ETag, 클라이언트는If-None-Match조건부 요청. - 바인딩을 고른다. 세 바인딩은 기능적으로 동등해야 하지만, 팀의 관측·게이트웨이 스택이 어느 쪽을 잘 다루는지가 실제 선택 기준이 된다.
- 장기 실행 작업 경로를 정한다. 스트리밍(SSE)으로 받을지, 푸시 알림 설정을 쓸지, 폴링으로 Get Task를 칠지.
- 핸드오프 검증 규칙을 문서화한다. 어떤 결과를 그대로 신뢰하고 어떤 결과를 재검증할지 코드가 아니라 정책으로 먼저 정한다.
자주 묻는 질문
Q. MCP를 이미 쓰고 있는데 A2A도 붙여야 하나?
용도가 다르므로 자동으로 필요해지지는 않는다. 사내 단일 에이전트가 도구만 호출한다면 MCP로 충분하다. 다른 팀·다른 회사가 운영하는 에이전트에 작업을 넘길 일이 생길 때 A2A가 의미를 갖는다.
Q. 이번 AAIF 합류로 A2A 스펙이 바뀌나?
발표된 내용은 거버넌스 소속 변경이며 스펙의 파괴적 변경은 공지되지 않았다. 최신 릴리스는 1.0.0이다. 다만 저장소 위치나 회의 체계는 바뀔 수 있으니 공식 채널을 확인하는 편이 안전하다.
Q. 에이전트 카드는 꼭 /.well-known에 둬야 하나?
아니다. well-known URI는 세 가지 발견 전략 중 하나이며, 레지스트리나 직접 구성도 스펙이 인정한다. 다만 레지스트리 API는 현 스펙에 표준이 없으므로 이식성은 well-known 쪽이 낫다.
마무리
이번 소식의 실질은 기능이 아니라 소유권이다. 도구 연결(MCP)과 에이전트 연결(A2A)이 같은 중립 거버넌스에 놓였다는 사실은 멀티 벤더 에이전트 구성을 검토하는 팀의 위험 계산을 바꾼다. 그러나 규약이 보장하는 것은 전달이지 진위가 아니다. 체인이 길어질수록 검증은 프로토콜 밖에서 팀이 직접 설계해야 한다. 관련해서 MCP 2026-07-28 스펙 정리와 Agent Plugins 1.0.0 스펙 정리도 함께 보면 스택 전체 그림이 잡힌다.
출처
- AAIF, "A2A joins AAIF's open agentic stack" (2026-08-17)
- Axios, "Exclusive: Google-backed agentic A2A protocol gets a new home" (2026-08-17)
- Techstrong.ai, "Google Moves A2A Under Agentic AI Foundation" (2026-08-18)
- A2A 공식 문서 — Agent Discovery
- A2A 공식 퀵스타트 — Agent Skills & Agent Card (코드 스니펫 출처)
본 글은 공개 자료를 바탕으로 정리했으며, 세부 내용·수치는 원 출처·공식 문서와 대조 확인을 권장합니다.
