2026년 8월 17일에 A2A가 에이전틱 AI 재단(AAIF, Agentic AI Foundation)의 호스티드 프로젝트가 되었습니다. 상편에서는 공식 SDK로 A2A 서버를 직접 띄워 항목 12개로 확인하고, 같은 작업을 MCP와 순수 HTTP로도 만들어 비교했습니다. 결과부터 말씀드리면 A2A로 얻는 것은 진행 확인(task status)과 취소(cancellation)에 대한 규약이고 그 대신 응답 바이트와 지연 시간이 늘어납니다. 하지만 에이전트 카드가 선언한 인증은 SDK 기본 구성에서 검사되지 않았기 때문에 선언과 강제를 나누어 보셔야 합니다. 그리고 아직은 스펙 그대로 동작하는 것이 12개 중 5개로 많지 않았습니다. 하편에서는 A2A가 에이전틱 AI 재단의 프로젝트가 되었다는 것이 무엇을 뜻하는지부터 정리하고, A2A와 이어지는 다른 프로젝트들과 도입 전에 확인할 것 7가지를 차례로 보겠습니다.

중립 재단으로 관리 주체가 바뀐 A2A

관리 주체가 바뀌기까지는 두 단계를 거쳤습니다. 공개하고 두 달 뒤인 2025년 6월에 구글이 리눅스 재단으로 넘기겠다고 발표했고 올해 8월에 그 산하의 에이전틱 AI 재단이 관리를 넘겨받은 것입니다. 그리고 지금 재단 안에서 A2A가 놓인 성숙도 단계는 Growth인데 그 위에 Impact 단계가 하나 더 있습니다. 발표문에 따르면 공급망, 금융 그리고 모바일 플랫폼에서 이미 운영 환경에 쓰이고 있고 함께하는 조직도 150곳이 넘습니다.

그렇다면 관리 주체가 바뀌는 것으로 무엇이 달라질까요? 2가지로 나누어 볼 수 있습니다.

첫 번째는 한 회사의 결정에 따라 프로토콜의 앞날이 정해질 여지가 줄어든다는 것입니다. 특정 회사가 만든 규격은 그 회사가 전략을 바꾸면 유지와 개정이 함께 멈출 수 있는데 중립 재단이 관리하면 그 걱정을 덜 수 있습니다. 실제로 저장소 주소도 google/A2A에서 a2aproject/A2A로 바뀌었고 지금은 예전 주소로 가면 새 주소로 넘어갑니다.

두 번째는 에이전트를 만들 때 필요한 요소들이 한곳에 모였다는 것입니다. 도구를 호출하는 규격, 코딩 에이전트에게 프로젝트 규칙을 알려 주는 파일, 그 앞단에 두는 인프라 그리고 실제로 쓰는 에이전트 도구가 이미 재단에 있었고 여기에 에이전트끼리 일을 주고받는 규격이 더해진 것입니다. 에이전틱 AI 재단은 2025년 12월에 만들어졌고 A2A가 들어온 다음 날 Agent Router까지 승인되어 이 글을 작성하는 시점에는 프로젝트 6개를 관리하고 있습니다. 이를 성격에 따라 구분하여 표로 정리해 볼 수 있습니다.

A2A 도입 전 확인할 에이전틱 AI 재단 프로젝트 6개 비교표: 프로토콜 MCP(에이전트가 도구와 자원을 사용하는 방식)·A2A(에이전트가 다른 에이전트에게 일을 맡기는 방식), 파일 형식 AGENTS.md(코딩 에이전트에게 프로젝트 규칙을 알려 주는 파일), 인프라 agentgateway(에이전트·모델·도구 사이의 연결을 중계하는 게이트웨이)·Agent Router(애플리케이션을 모델과 MCP 도구에 연결하고 접근과 사용량을 관리하는 게이트웨이), 에이전트 Goose(확장이 가능한 오픈소스 AI 에이전트)

여기서 표준이 될 수 있는 것은 위의 3개입니다. 규격을 정하는 문서이기 때문에 여러 회사가 같은 규격을 따르면 그것이 곧 표준이 됩니다. 실제로 그렇게 되어 가는 사례가 최근에 하나 나왔는데, 클로드 코드(Claude Code)가 v2.1.277부터 AGENTS.md를 직접 읽기 시작했습니다. CLAUDE.md가 여전히 기본이지만 그 파일이 없으면 AGENTS.md를 읽으며 설정에서 둘 다 읽게 할 수도 있습니다. 그에 반해 아래 3개는 그 규격을 쓰는 제품이라서 표준 자체라기보다는 표준이 실제로 쓰이는지를 보여 주는 쪽입니다. 이 가운데 MCP와 AGENTS.md는 제가 이 지면에 쓴 MCP 2026-07-28 스펙 총정리와 우리 팀의 CLAUDE.md, AGENTS.md로 바꿔도 될까에서 다뤘으니, 이번 글은 남은 A2A를 중심에 두고 MCP와의 관계부터 게이트웨이와 에이전트까지 차례로 보겠습니다.

여기서 한 가지 나누어 보셔야 할 것이 있습니다. 에이전틱 AI 재단의 프로젝트가 되었다는 것과 스펙에 적힌 대로 동작한다는 것은 다른 이야기입니다. 에이전틱 AI 재단이 담당하는 것은 거버넌스와 중립성이지 개별 SDK가 스펙을 지키는지까지 보증하지는 않기 때문입니다. 상편에서 공식 SDK로 만든 서버가 스펙대로 동작하는지 직접 확인한 것도 그래서입니다.

A2A와 다른 프로젝트들의 연관 관계

상편에서는 A2A 자체에 대해서 확인해 보았습니다. 그런데 A2A는 상대 에이전트를 찾아서 일을 맡기고 진행을 확인하고 취소하는 규약까지만 정합니다. 에이전트 사이의 통신을 실제로 운영하려면 카드에 선언한 인증을 누군가 검사해야 하고 오가는 요청을 중계하고 기록하는 장치도 있어야 하며 일을 받은 에이전트가 도구를 호출하는 규격도 필요합니다. 이러한 것들은 A2A 밖의 다른 프로젝트가 담당하는데 각각이 A2A와 어떻게 연결되는지를 하나씩 보겠습니다.

도구를 호출하는 쪽에는 MCP가 있습니다.

상편에서 상대에 따라 골라 쓴다고 말씀드렸는데, 한 서비스가 둘을 함께 제공할 수도 있습니다. A2A로 일을 받은 에이전트가 그 일을 처리하려고 MCP로 도구를 호출하는 구성이 스펙 부록에도 나오는데, 이때 안쪽에서 무엇을 쓰는지는 일을 맡긴 쪽에 보이지 않습니다.

앞단에는 agentgateway가 있습니다.

쿠버네티스 서비스에 설정값 하나(appProtocol: agentgateway.dev/a2a)를 지정하면 게이트웨이가 그 트래픽을 A2A로 처리하는데, 이때 에이전트 카드의 주소를 자기 주소로 바꿔서 내보내고 액세스 로그에 어떤 메서드를 호출했고 결과가 무엇이며 JSON-RPC 오류 코드가 몇 번인지를 남깁니다. 지원하지 않는 메서드를 호출하면 HTTP는 200으로 오고 그 안에 JSON-RPC 오류가 실리기 때문에 상태 코드만 보는 모니터링은 이를 성공으로 집계하게 되는데, 그 대신 게이트웨이 로그가 오류를 기록해 줍니다. 다만 카드를 바꿔 내보내는 동작에는 확인할 점이 있습니다. 두 버전을 함께 서비스하는 서버는 카드에 v0.3 주소와 v1.0 주소를 둘 다 적어 내보내는데, agentgateway는 v1.0 주소만 자기 주소로 바꾸고 v0.3 주소는 백엔드의 직접 주소로 남겨 둡니다. 이 때문에 v0.3 클라이언트가 게이트웨이를 거치지 않고 백엔드로 바로 요청을 보내는 경우를 확인했습니다.

하지만 agentgateway는 A2A 요청의 인가를 판단하지 않습니다.

호출자가 누구인지 확인하는 것이 인증(authentication)이라면 그 호출자가 어떤 메서드나 스킬을 호출해도 되는지 판단하는 것은 인가(authorization)입니다. 이 가운데 인가 쪽을 보면 agentgateway v1.5.0에는 해당 기능이 없습니다. MCP 쪽에서는 도구 이름과 인자에 규칙을 강제하는데 A2A 쪽에는 같은 장치가 아직 마련되지 않아서 관측은 하고 강제는 하지 않습니다. 그래서 상편에서 확인한 인증 검사가 없는 문제는 agentgateway를 앞에 둔다고 해서 해결되지 않고 인증과 인가 모두 앱이나 다른 계층이 담당해야 합니다.

이 규격들을 직접 사용하는 에이전트로는 Goose가 있습니다.

앞의 둘이 규격과 그 규격으로 오가는 요청을 중계하는 인프라였다면, 그 규격으로 실제 일을 주고받는 것은 사람이 직접 쓰는 에이전트입니다. 성격이 그 둘과 다르다는 점은 밝혀 두는 것이 좋겠습니다. 규격은 여러 곳이 같은 문서를 따르면 표준이 되지만 에이전트는 각 파운데이션 모델(foundation model)을 기반으로 동작하는 경우가 많아서 1개로 규격화하기 쉽지 않은 부분이 있습니다. 그리고 opencode를 비롯한 비슷한 도구가 계속 나오면서 경쟁이 치열해지고 있어서 어느 쪽이 자리를 잡을지는 아직 말씀드리기 어렵습니다. 그래도 이 자리를 함께 보는 이유는 규격이 문서로만 있는지 아니면 실제로 쓰이고 있는지를 그 규격을 쓰는 도구에서 확인할 수 있기 때문입니다.

Goose는 2025년 12월에 MCP, AGENTS.md와 함께 에이전틱 AI 재단 창립 기부 3종에 포함되었고 2026년 4월 7일에는 저장소가 블록(Block)의 조직에서 재단 조직(aaif-goose/goose)으로 옮겨 갔습니다. 기업이 만들어 키운 에이전트가 중립 재단으로 관리 주체를 옮긴 사례입니다. 이 글을 작성하는 시점에 별이 54,500개를 넘었고 최신 버전은 2026년 9월 17일에 나온 v1.51.0이며 MCP로 연결할 수 있는 확장이 70가지가 넘고 컨텍스트 파일도 AGENTS.md를 먼저 읽습니다. 두 표준을 현업에서 쓰는 도구가 이미 있다는 뜻입니다.

그러면 A2A는 어떨까요? 아직 그렇게 쓰는 도구가 보이지 않습니다. Goose 같은 에이전트에서 다른 조직의 에이전트를 카드로 찾아 일을 맡기는 구성을 기본으로 제공하기 시작하면, 그때부터 A2A는 규격 문서가 아니라 현업에서 쓰는 규약이 됩니다. 지금 관심을 두고 어떻게 변화하는지 계속 살펴봐야 할 부분 중에 하나가 이 지점이라고 생각합니다.

지금 확인할 것과 앞으로 지켜볼 것

A2A를 도입하실 생각이라면 확인하시면 좋을 내용을 먼저 정리해 보겠습니다.

에이전트 카드에 인증 방식을 적어 두어도 SDK 기본 구성은 그것을 검사하지 않으니 인증은 앱이나 앞단에서 직접 거셔야 합니다.
확장 에이전트 카드는 스펙상 인증된 요청에만 주는 카드지만 SDK 기본 구성은 신원을 확인하지 않습니다. 따라서 주소만 알면 누구나 받아 갈 수 있으니 공개해도 되는 내용만 담으시기 바랍니다.
A2A-Version 헤더는 반드시 붙이셔야 합니다. 빠뜨리면 오류 없이 v0.3으로 처리됩니다.
에이전트 카드의 인터페이스 목록을 그대로 믿지 마시고 실제로 호출해서 확인해 보시는 것이 좋습니다.
완료된 태스크를 취소하면 스펙이 정한 코드(-32002)가 아니라 서버 내부 오류를 뜻하는 코드(-32603)가 옵니다. 그러니 취소 결과를 오류 코드로 처리한다면 이 코드를 서버 장애로 오해해 재시도하지 않도록 따로 처리하셔야 합니다.
푸시 알림을 쓰시려면 알림 설정을 담아 둘 곳과 푸시를 보내는 부분을 직접 만들어 연결하셔야 하며 연결한 뒤에도 보내기에 실패하면 서버 로그에만 남으니 그쪽을 함께 보셔야 합니다.
태스크 저장소는 기본값이 파드 메모리라 재시작하면 상태가 사라지니 재시작해도 남는 저장소로 바꾸셔야 합니다.

그리고 지금은 도입하지 않더라도 관심을 두고 계신다면 지표 3가지를 보시면 좋겠습니다. 앞에서 직접 만들어야 한다고 말씀드린 것들을 언제부터 안 만들어도 되는지 알려 주는 지표라, 이것들이 변경되면 그때 도입 여부를 다시 고려해 보아야 합니다.

첫 번째는 공식 SDK가 인증 검사와 푸시 보내기를 기본으로 제공하게 되는지입니다. 지금은 앱이 직접 만들어야 하는 부분이라 SDK가 이것까지 담당하게 되면 도입 부담이 크게 줄어듭니다.

두 번째는 게이트웨이가 A2A에서도 누가 무엇을 호출할 수 있는지 검사해 주는지입니다. MCP 쪽에는 이미 정책 장치가 있어서 그 기능을 어디에 넣을지는 보이는 상태입니다. 이것이 생기면 인증과 인가를 앱마다 만들지 않고 앞단에서 한 번에 걸 수 있습니다.

세 번째는 에이전틱 AI 재단 안에서 A2A가 Growth에서 Impact로 올라가는지입니다. 에이전틱 AI 재단은 2026년 9월 1일에 신생 프로젝트를 받는 Sandbox 단계를 새로 만들면서 단계별 기준을 정리했고 그 기준으로 보면 다음 단계로 올라간다는 것은 채택, 커뮤니티 그리고 재단 관여가 함께 커졌다는 뜻입니다. 다른 조직의 에이전트를 여럿 연결할 계획이라면 연결할 곳이 그만큼 늘었다고 보셔도 됩니다.

마치며

정리하자면, A2A가 제공하는 것은 다른 에이전트에게 맡긴 일이 지금 어디까지 됐는지 확인하는 방법과 그 일을 처리 도중에 취소하는 방법입니다. 이 둘이 스펙에 정해져 있어서 상대 에이전트가 바뀌어도 쓰던 클라이언트를 그대로 쓸 수 있습니다. 호출한 일이 오래 걸리지 않고 중간에 상태를 확인하거나 관리할 필요도 없다면 MCP로 충분합니다. 특히 MCP는 지난 7월 개정으로 요청 하나하나를 독립적으로 처리하는 구조가 되어서 API 서버처럼 여러 요청을 나눠 받기에 적합합니다. 그런데 시간을 들여 일하다가 중간에 되묻거나 거절하기도 하는 에이전트가 상대라면 그때부터 이 규약이 의미를 가지게 됩니다. 대신 응답 바이트가 늘고 호출당 1.2~2.1ms가 더 걸립니다. 그리고 아직은 스펙 그대로 동작하는 것이 12개 중 5개로 많지 않았습니다. 그중에서도 에이전트 카드에 적힌 것과 서버가 하는 일은 따로 보셔야 하고 그 일을 게이트웨이가 대신 해 주지도 않습니다.

에이전틱 AI를 구성하는 표준은 현재(2026년 9월) 이런 상태입니다. 규격은 v1.0으로 고정되어 읽을 만해졌지만 그 규격을 강제하는 부분은 아직 쓰는 쪽에서 직접 갖춰야 합니다. 그래서 지금은 문서를 믿기보다 직접 실행해서 확인해 보시는 편이 좋습니다. 측정에 사용한 스크립트, 매니페스트 그리고 항목별 판정 표는 공개 저장소에 정리해 두었으니 직접 돌려 보고 싶으신 분들은 참고하시기 바랍니다. 게이트웨이 쪽 측정은 같은 저장소의 다른 연구에 있습니다. 덧붙여 A2A 쪽은 9월에 갱신한 로드맵에서 v1.1을 준비한다고 적었는데 태스크 타임라인을 다듬는 것과 양방향 스트리밍이 그 안에 있으니 이번에 확인한 내용도 그때 다시 봐야 합니다.

게이트웨이는 이 글에서 다 다루지 못했습니다. 같은 재단의 두 게이트웨이인 agentgateway와 Agent Router를 비교하고 게이트웨이를 한 번 더 거치는 비용까지 잰 이야기는 「에이전틱 AI 세계에서 게이트웨이는 어떤 의미를 가질까요?」에서 이어서 보실 수 있습니다.

이 지면에 쓴 앞의 두 글, MCP 2026-07-28 스펙 총정리와 우리 팀의 CLAUDE.md, AGENTS.md로 바꿔도 될까와 함께 읽으시면 에이전틱 AI 재단의 프로젝트 6개를 모두 이어서 보시게 됩니다. 끝으로 한 가지를 더 말씀드리겠습니다. 저는 에이전틱 AI 재단의 앰버서더로 활동하고 있고 이 글에서 다룬 A2A와 agentgateway는 그 재단의 프로젝트입니다. 그렇다 보니 좋은 점만 적기보다 스펙대로 되지 않는 부분까지 직접 확인해서 적었습니다.