2026년 8월 17일, Google이 만든 A2A(Agent2Agent) 프로토콜이 Linux Foundation 산하 **Agentic AI Foundation(AAIF)**의 호스팅 프로젝트가 됐습니다. AAIF는 2025년 12월 Anthropic의 MCP, Block의 goose, OpenAI의 AGENTS.md를 앵커 프로젝트로 출범한 재단입니다.

한 줄로 요약하면 이렇습니다. 에이전트가 도구를 부르는 규약(MCP)과 에이전트가 서로를 부르는 규약(A2A)이 같은 중립 재단 아래로 들어왔습니다.

벤더 발표는 대개 그날 하루짜리 뉴스로 끝납니다. 이 건은 조금 다릅니다. 우리가 고객사 에이전트 플랫폼을 설계할 때 매번 미뤄뒀던 질문 — "이 에이전트를 나중에 다른 팀 에이전트와 어떻게 붙일 것인가" — 의 답이 사내 컨벤션에서 산업 표준으로 넘어가는 지점이기 때문입니다.

요약: 무슨 일이 있었나

시점	사건
2025-04-09	Google이 A2A 발표 (50+ 파트너)
2025-12-09	Linux Foundation, AAIF 출범 — MCP · goose · AGENTS.md 앵커
2026-08-17	A2A가 AAIF 호스팅 프로젝트로 편입
현재	AAIF 회원사 250곳 이상 (출범 시 40곳 미만)

A2A는 현재 스펙 v1.0, Apache-2.0 라이선스이며 AWS · Cisco · Google · IBM Research · Microsoft · Salesforce · SAP · ServiceNow 대표로 구성된 Technical Steering Committee가 관리합니다. AAIF의 Platinum 회원사는 AWS · Anthropic · Block · Bloomberg · Cloudflare · Google · Microsoft · OpenAI입니다.

즉 모델 제공사, 하이퍼스케일러, SaaS 벤더가 같은 테이블에 앉은 상태로 두 프로토콜이 굴러가게 됐습니다.

기존과의 차이: 두 개의 축

MCP와 A2A는 경쟁 관계가 아닙니다. 축이 다릅니다.

MCP는 수직축입니다. 에이전트 하나가 자기 도구를 부르는 방식을 표준화합니다. 도구의 스키마, 인자, 반환값이 그대로 노출됩니다. 신뢰 경계 안쪽이라 가능한 설계입니다.

A2A는 수평축입니다. 에이전트가 다른 에이전트를 발견하고(Agent Card), 작업을 위임하고(Task), 결과물을 주고받되(Artifact) 내부 상태 · 메모리 · 도구 목록은 노출하지 않습니다. 상대가 LangGraph인지 Bedrock Agent인지 사내 Python 스크립트인지 몰라도 됩니다.

이 구분이 실무에서 왜 중요한지는 코드보다 조직도에서 드러납니다. 부서 A의 에이전트에게 부서 B의 도구를 MCP로 직접 물리면, 부서 B의 API 스키마 변경이 부서 A의 프롬프트를 깨뜨립니다. 우리가 여러 프로젝트에서 반복해서 본 실패 패턴입니다. A2A는 그 사이에 계약(Task) 을 끼워 넣습니다.

	MCP	A2A
연결 대상	에이전트 ↔ 도구 · 데이터	에이전트 ↔ 에이전트
노출하는 것	도구 스키마, 호출 결과	능력 선언(Agent Card), 작업 상태
감추는 것	(거의 없음)	내부 도구 · 메모리 · 모델 선택
실패의 전파	스키마 변경 → 프롬프트 파손	Task 상태로 격리
적합한 경계	팀 내부	팀 · 조직 · 벤더 간

SHIFTONE 관점에서의 시사점

1. "표준을 채택할까"에서 "어느 축에 둘까"로 질문이 바뀐다

작년까지 고객사 논의의 절반은 "MCP를 써야 하나요, 자체 툴 스펙을 유지할까요"였습니다. 이제 그 논쟁은 실효가 없습니다. 관리형 서비스들이 이미 MCP를 전제로 나오고 있기 때문입니다. 예를 들어 AWS는 Bedrock AgentCore Gateway의 내장 커넥터 타겟을 MCP로 노출하고, 2026년 8월 Web Search 도구에 도메인 · 발행일 필터를 추가하면서 유럽(아일랜드) · 아시아태평양(도쿄) 리전으로 확장했습니다.

실질적인 질문은 이제 이겁니다. 이 기능을 MCP 서버로 낼 것인가, A2A 에이전트로 낼 것인가. 판단 기준은 하나로 정리됩니다 — 호출자가 내 내부 구현을 알아야 하면 MCP, 몰라도 되면 A2A.

2. AgentOps의 관측 지점이 프로토콜 경계로 이동한다

에이전트가 하나일 때는 애플리케이션 로그로 충분했습니다. A2A로 에이전트가 서로를 부르기 시작하면 추적해야 할 것이 늘어납니다.

어느 에이전트가 어느 Task를 누구에게 위임했는가
Task가 어느 상태에서 멈췄는가 (submitted / working / failed)
위임 체인의 총 토큰 · 비용을 누구 앞으로 달 것인가
실패했을 때 재시도 책임은 위임자인가 수임자인가

마지막 항목이 특히 까다롭습니다. HTTP의 5xx 재시도 관례처럼 합의된 규범이 아직 없습니다. 저희는 당분간 위임자가 타임아웃과 재시도를 전부 소유하는 쪽으로 잡고 있습니다. 수임 에이전트가 자체 재시도까지 하면 중복 실행과 비용 폭증이 동시에 옵니다.

3. 인증 · 권한은 여전히 각자 숙제다

표준이 한 지붕에 모였다고 인가 모델까지 통일된 것은 아닙니다. "부서 A의 에이전트가 부서 B의 에이전트에게 위임할 때, 원래 사용자의 권한은 어디까지 따라가는가"는 프로토콜이 아니라 조직이 답해야 하는 질문입니다. 위임 체인이 길어질수록 사용자 권한이 아니라 서비스 계정 권한으로 실행되는 구간이 생기는데, 여기가 감사에서 가장 먼저 걸립니다.

다음 액션

이번 주 저희가 내부적으로 잡은 체크리스트입니다.

경계 인벤토리 — 현재 운영 중인 에이전트별로 "이 호출이 조직 경계를 넘는가"를 표시. 넘는 것만 A2A 후보.
Agent Card 초안 — 후보로 뽑힌 에이전트의 능력 선언을 먼저 문서로 작성. 구현보다 계약이 먼저입니다.
위임 추적 필드 추가 — 기존 추적 로그에 delegation_id · parent_agent · task_state를 넣어 두기. A2A 도입 전에 넣어야 나중에 비교군이 생깁니다.
재시도 정책 명문화 — 위임자 소유 원칙을 런북에 박아 두기.
분기 리뷰 — A2A v1.0 확장(extension) 프로세스와 AAIF 거버넌스 변경을 분기마다 확인.

표준이 재단으로 가는 일은 대체로 조용하게 지나갑니다. 하지만 이 조용한 변화가 2~3년 뒤 "왜 우리 에이전트는 서로 말을 못 하나"를 결정합니다. 지금 필요한 건 전면 재작성이 아니라, 경계를 표시해 두는 일입니다.

MCP 옆에 A2A가 앉았다 — 에이전트 상호운용 표준이 한 지붕으로 모인 뒤 무엇이 달라지나