MCP와 A2A가 한 지붕 아래로 들어왔습니다 — 구글 A2A, 에이전틱 AI 재단 합류

MCP와 A2A가 한 지붕 아래로 들어왔습니다 — 구글 A2A, 에이전틱 AI 재단 합류

AI 에이전트가 혼자 일하는 시대는 이미 지났습니다. 에이전트는 도구를 부르고, 파일을 읽고, 다른 에이전트에게 일을 넘깁니다. 그런데 서로 다른 회사가 만든 에이전트끼리 어떻게 말을 섞을까요. 여기에 필요한 것이 프로토콜, 즉 약속된 대화 규칙입니다.

지금까지 그 규칙은 두 갈래였습니다. 앤스로픽이 만든 MCP(Model Context Protocol)는 에이전트와 도구를 잇고, 구글이 만든 A2A(Agent2Agent)는 에이전트와 에이전트를 잇습니다. 서로 다른 회사가 각자 관리하던 표준이었어요.

그 둘이 한 지붕 아래로 들어왔습니다. 2026년 8월, A2A가 리눅스 재단 산하의 에이전틱 AI 재단(AAIF)에 정식 합류했습니다. MCP는 이미 그 안에 있었고요. 에이전트 경제의 배관 두 개가 같은 중립 거버넌스로 묶인 겁니다.

두 개의 굵은 청록 고리가 서로 맞물려 하나로 겹쳐지는 개념 이미지 — 두 프로토콜이 한 거버넌스로 묶이는 상황을 표현

MCP와 A2A가 한 지붕 아래로 들어왔습니다

이번 합류의 의미는 기술 변경이 아니라 소유 구조 변경입니다. A2A의 코드나 사양이 바뀐 게 아니에요.

바뀐 것은 누가 이 표준의 방향을 결정하느냐입니다. 구글 한 회사에서, 여러 회사가 참여하는 재단으로 넘어갔습니다.

무슨 일이 있었나

2026년 8월 중순, 구글의 A2A 프로토콜이 에이전틱 AI 재단에 공식 합류했다는 발표가 나왔습니다.

이로써 에이전트 도구 연결 표준인 MCP와 에이전트 간 통신 표준인 A2A가 같은 재단 아래 놓이게 됐습니다. 멀티 에이전트 시스템을 설계할 때 두 표준의 조율이 한결 수월해지는 구조예요.

커다란 청록 고리 한가운데에 어두운 큐브가 놓인 개념 이미지 — 재단이라는 테두리 안으로 들어온 프로토콜을 표현

에이전틱 AI 재단이라는 곳

에이전틱 AI 재단은 AI 에이전트 관련 오픈 표준을 관리하기 위해 만들어진 조직입니다. 영문 약자로 AAIF라고 부릅니다.

출범은 2025년 12월이었고, 앤스로픽·블록(Block)·오픈AI가 공동 설립에 참여했습니다. 경쟁 관계인 회사들이 표준 관리에는 함께 들어간 셈이에요.

리눅스 재단 산하 기금이에요

AAIF는 독립 법인이 아니라 리눅스 재단 산하의 지정 기금(directed fund) 형태로 운영됩니다.

리눅스 재단은 리눅스 커널뿐 아니라 쿠버네티스, 노드js 등 수많은 오픈소스 프로젝트의 중립 관리 기구 역할을 해 왔습니다. 특정 기업이 프로젝트를 좌우하지 못하게 하는 장치가 이미 갖춰진 조직이에요.

어두운 육각 판 위에 밝은 청록 육각형 일곱 개가 둥글게 박힌 개념 이미지 — 여러 회사가 함께 만든 재단 구조를 표현

앤스로픽과 블록과 오픈AI가 함께 만든 조직

공동 설립 명단이 흥미롭습니다. MCP를 만든 앤스로픽, 결제·핀테크 회사인 블록, 그리고 앤스로픽의 최대 경쟁사인 오픈AI가 나란히 있어요.

표준은 혼자 쥐고 있으면 아무도 안 쓴다는 판단이 깔려 있습니다. 경쟁사가 채택해야 표준이 되고, 표준이 돼야 생태계가 큽니다.

250개가 넘는 회원사

AAIF는 현재 250곳이 넘는 회원사를 두고 있습니다. 구글, 마이크로소프트, 아마존, 앤스로픽, 오픈AI, 블룸버그, 쇼피파이, 블록 등이 이름을 올렸어요.

AI 모델을 만드는 회사와 그 모델을 쓰는 회사가 함께 들어와 있다는 점이 눈에 띕니다.

커다란 어두운 삼각형 안쪽에 작은 청록 삼각형이 들어앉은 개념 이미지 — 리눅스 재단 산하 지정 기금이라는 위치를 표현

여덟 달 만에 40곳에서 250곳으로

성장 속도가 이 흐름을 말해 줍니다. 2025년 12월 출범 당시 회원사는 40곳이 채 되지 않았습니다.

여덟 달 만에 250곳을 넘겼어요. 에이전트 상호운용 문제가 얼마나 급한 실무 과제로 인식되고 있는지를 보여 주는 수치입니다.

A2A는 무엇을 하는 프로토콜인가

A2A는 서로 다른 벤더가 만든 에이전트끼리 대화하고 일을 나누는 규칙입니다. 2025년 4월 구글이 50곳이 넘는 파트너와 함께 공개했어요.

핵심은 발견과 위임입니다. 에이전트가 다른 에이전트를 찾아내고, 그 에이전트가 무엇을 할 수 있는지 확인한 뒤, 작업을 넘길 수 있게 합니다.

삼각형으로 배치된 청록 큐브 세 개가 가느다란 선으로 서로 이어진 개념 이미지 — 공동 설립에 참여한 세 회사를 표현

에이전트 카드라는 개념

A2A에는 에이전트 카드(agent card)라는 장치가 있습니다. 에이전트가 자기 능력과 접속 방법을 기술해 두는 명세예요.

다른 에이전트는 이 명세를 읽고 무엇을 맡길 수 있는지 판단합니다. 사람이 명함을 보고 누구에게 무슨 일을 부탁할지 정하는 것과 비슷한 구조입니다.

MCP는 도구를 잇고 A2A는 동료를 잇습니다

두 표준의 역할은 명확히 갈립니다. MCP는 에이전트와 도구·데이터를 잇는 세로 방향이에요. 파일 시스템, 데이터베이스, 외부 API에 닿는 통로입니다.

A2A는 에이전트와 에이전트를 잇는 가로 방향입니다. 같은 층위에 있는 상대에게 일을 넘기는 통로예요.

어두운 큐브 하나를 수많은 작은 청록 큐브가 에워싸고 있는 개념 이미지 — 250곳이 넘는 회원사가 모인 구조를 표현

두 프로토콜이 겹치지 않는 이유

역할이 다르기 때문에 둘은 경쟁 관계가 아닙니다. 오히려 함께 있어야 완성됩니다.

에이전트가 도구만 쓸 수 있으면 혼자 일하는 데서 끝나고, 다른 에이전트만 부를 수 있으면 실제 작업을 수행하지 못해요. 두 방향이 다 필요합니다.

구글이 통제권을 넘긴 순서

구글은 A2A를 단번에 넘기지 않았습니다. 단계를 밟았어요.

먼저 공개하고, 그다음 리눅스 재단에 기증하고, 이번에 AAIF라는 구체적 관리 조직 안으로 들어갔습니다. 통제권을 조금씩 내려놓는 과정이었습니다.

흐린 청록 큐브 몇 개로 시작한 줄이 훨씬 길고 밝은 큐브 행렬로 이어지는 개념 이미지 — 40곳에서 250곳으로 늘어난 성장을 표현

2025년 4월 공개, 6월 리눅스 재단 기증

시간순으로 보면 이렇습니다. 2025년 4월 50곳 이상의 파트너와 함께 A2A 공개, 같은 해 6월 리눅스 재단에 기증.

그리고 2026년 8월 AAIF 합류입니다. 1년 반에 걸친 이양 과정이었어요.

이번에 달라진 것은 호스팅입니다

그래서 이번 발표를 정확히 읽으면 이렇습니다. A2A는 이미 2025년에 리눅스 재단으로 갔으므로, 이번 조치는 지배 구조의 근본적 전환이라기보다 어느 조직이 실제로 관리하느냐를 명확히 한 것입니다.

다만 실무적으로는 의미가 큽니다. MCP와 같은 재단 안에 있으면 두 표준의 로드맵을 함께 논의할 자리가 생기니까요.

어두운 블록 두 개 사이를 굵고 밝은 청록 막대 하나가 잇는 개념 이미지 — 에이전트끼리 일을 주고받는 통신을 표현

기술운영위원회에 앉은 회사들

A2A는 기술운영위원회(TSC)가 관리합니다. 여기에는 AWS, 시스코, 구글, IBM 리서치, 마이크로소프트, 세일즈포스, SAP, 서비스나우의 대표가 참여합니다.

클라우드 사업자, 네트워크 장비 회사, 엔터프라이즈 소프트웨어 회사가 섞여 있어요. 어느 한 진영이 다수를 차지하지 않는 구성입니다.

중립 거버넌스가 왜 중요한가

표준의 관리 주체가 중립적이어야 하는 이유는 신뢰 때문입니다. 경쟁사가 만든 규격을 채택하려면, 그 회사가 어느 날 규격을 자기에게 유리하게 바꾸지 않으리라는 확신이 필요해요.

재단이 그 확신을 제도로 대신합니다. 사양 변경에 여러 회사의 동의가 필요하게 만들어 두는 방식으로요.

안쪽이 텅 빈 채 청록 테두리만 선명하게 빛나는 어두운 사각 패널 — 에이전트가 자기 능력을 적어 두는 명세를 표현

표준이 한 회사 것일 때 생기는 일

기술 역사에는 사례가 많습니다. 한 회사가 만든 규격이 널리 쓰이다가, 그 회사의 사업 방향이 바뀌면서 규격도 함께 흔들리는 일이요.

쓰던 쪽은 선택지가 없습니다. 이미 그 규격 위에 시스템을 얹어 두었으니까요. 이걸 벤더 종속이라고 부릅니다.

개발자에게 실제로 달라지는 것

당장 코드를 고칠 일은 없습니다. 사양이 바뀐 게 아니니까요.

달라지는 것은 예측 가능성입니다. 로드맵이 공개 논의를 거치게 되고, 사양 변경 이력이 재단 절차를 통해 남습니다. 장기 프로젝트의 기반으로 삼기가 한결 편해져요.

청록 큐브 두 개가 가느다란 빛줄기로 이어져 앞뒤로 늘어선 개념 이미지 — 도구 연결과 에이전트 연결이라는 두 방향을 표현

에이전트를 만드는 사람의 관점

여러 에이전트를 엮는 시스템을 설계한다면 지금이 표준을 정리하기 좋은 시점입니다.

도구 연결은 MCP로, 에이전트 간 위임은 A2A로 나누는 구도가 사실상 굳어졌어요. 자체 규격을 만들어 쓰던 부분이 있다면 어느 쪽으로 옮길지 판단해 볼 만합니다.

벤더 종속을 피하는 설계

표준을 쓴다고 종속이 자동으로 사라지지는 않습니다. 특정 구현체에 깊이 기대면 결과는 비슷해요.

실무적으로는 사양이 정의한 범위 안에서만 쓰고, 특정 구현체의 확장 기능은 경계를 그어 두는 편이 안전합니다. 나중에 갈아 끼울 자리를 남겨 두는 것이죠.

짙은 어둠 속에서 청록 직선 두 개가 정확히 한 점에서 교차하는 개념 이미지 — 역할이 다른 두 표준이 만나는 지점을 표현

남아 있는 과제

거버넌스가 정리됐다고 문제가 다 풀린 것은 아닙니다. 에이전트 신원 확인, 권한 위임, 오래 도는 작업의 상태 관리 같은 굵직한 주제가 남아 있어요.

MCP 쪽에서도 에이전트 신원, 점진적 발견, HTTP 전송, 장기 실행 작업 원시 기능이 로드맵의 중심 주제로 논의되고 있습니다.

표준이 많다고 상호운용이 되는 건 아니에요

실무에서 자주 겪는 함정이 있습니다. 양쪽 다 같은 표준을 지원한다고 적혀 있는데 막상 안 붙는 경우요.

선택적 기능을 서로 다르게 구현했거나, 인증 방식이 어긋나거나, 버전이 다른 경우가 대부분입니다. 표준은 출발점이지 도착점이 아닙니다.

어두운 사각 구조물 안쪽에 밝은 청록 큐브가 자리 잡은 개념 이미지 — 중립 거버넌스 안에 놓인 표준을 표현

SVIL 작업 흐름에서 본 MCP

SVIL 연구소에서도 MCP는 이미 일상 도구입니다. 로컬 AI 워크스테이션 제어, 고스트 블로그 발행, 아웃라인 문서 기록이 전부 MCP 서버를 통해 붙어 있어요.

직접 써 보면 표준의 가치가 어디서 나오는지 체감됩니다. 서버를 하나 만들어 두면 여러 클라이언트가 같은 방식으로 붙거든요. 이 이점이 에이전트 간 통신으로 확장되는 것이 A2A가 노리는 지점입니다.

우리가 지켜볼 지점 세 가지

첫째, 두 표준의 접점 정리입니다. 같은 재단 안에 들어왔으니 역할 경계와 연동 방식에 대한 공식 문서가 나올지 지켜볼 만합니다.

둘째, 신원과 권한 문제의 진척입니다. 에이전트가 다른 에이전트를 대신해 행동할 때의 인증은 아직 미완인 영역이에요.

셋째, 실제 상호운용 사례입니다. 서로 다른 회사의 에이전트가 A2A로 실제 협업하는 사례가 나오는지가 표준의 진짜 시험대입니다.

서로 멀리 떨어져 떠 있는 똑같은 크기의 청록 육각기둥 세 개 — 앞으로 지켜볼 세 가지 관전 지점을 표현

핵심 정리

2026년 8월, 구글의 A2A 프로토콜이 리눅스 재단 산하 에이전틱 AI 재단(AAIF)에 정식 합류했습니다. 앤스로픽의 MCP와 같은 거버넌스 아래 놓이게 됐습니다.

AAIF는 2025년 12월 앤스로픽·블록·오픈AI가 공동 설립했고, 회원사가 40곳 미만에서 250곳 이상으로 늘었습니다. 구글·마이크로소프트·아마존 등이 참여합니다.

MCP는 에이전트와 도구를, A2A는 에이전트와 에이전트를 잇습니다. 역할이 달라 경쟁이 아니라 보완 관계입니다.

사양 자체가 바뀐 것은 아니라 당장 코드를 고칠 일은 없습니다. 달라지는 것은 표준의 예측 가능성이고, 신원·권한·장기 작업 관리는 여전히 과제로 남아 있습니다.

참고하실 만한 것

에이전트 관련 작업을 하고 계시다면 지금 쓰는 연결 방식이 어느 표준 위에 있는지 한 번 정리해 두시면 좋습니다. 자체 규격으로 붙여 둔 부분이 나중에 가장 비싼 자리가 되거든요.

SVIL은 MCP 서버를 직접 만들어 로컬 워크스테이션과 발행 파이프라인을 연결해 쓰고 있습니다. 표준을 따르면 클라이언트를 바꿔도 서버를 다시 만들지 않아도 된다는 점이 실질적인 이득이었어요.

두 표준의 접점 문서나 신원 관련 진척이 나오면 다시 정리해 전해 드리겠습니다.

출처


협업문의 : kuroicode@gmail.com
블로그 : https://blog.svil.dev/
홈페이지 : https://svil.dev/