A2A 도입 전 확인할 7가지와 SDK 점검 결과

A2A(에이전트 간 작업을 맡기고 진행 상태를 확인하는 규약)는 2026년 8월 17일 에이전틱 AI 재단(AAIF)의 호스티드 프로젝트가 됐습니다. 앞선 실험에서는 공식 SDK로 만든 서버의 동작을 12개 항목으로 점검하고 MCP 및 순수 HTTP와 비교했습니다. A2A는 작업 진행 상태 확인과 취소 규약을 제공하지만 응답 바이트와 지연 시간이 늘었고, 12개 항목 중 스펙대로 동작한 것은 5개였습니다. SDK 기본 구성은 에이전트 카드에 선언된 인증을 검사하지 않았습니다.

A2A 관리권은 공개 두 달 뒤인 2025년 6월 구글이 리눅스 재단에 넘기겠다고 발표했고, 2026년 8월 재단 산하 AAIF가 맡았습니다. 글 작성 시 재단은 A2A를 Growth 단계로 분류했고 그 위에는 Impact 단계가 있습니다. 재단 발표에 따르면 A2A는 공급망·금융·모바일 플랫폼의 운영 환경에서 사용되고 있으며 참여 조직은 150곳이 넘습니다. 중립 재단으로 관리 주체가 바뀌면 한 회사의 전략 변경에 따라 규격의 유지·개정이 멈출 위험을 줄일 수 있다고 글은 설명합니다. 저장소 주소도 google/A2A에서 a2aproject/A2A로 바뀌었습니다.

AAIF는 2025년 12월 만들어졌으며, A2A가 합류한 다음 날 Agent Router도 승인돼 글 작성 시점에 6개 프로젝트를 관리했습니다. 도구 호출 규격, 프로젝트 규칙 파일, 인프라, 에이전트 도구가 있던 재단에 에이전트 간 작업 전달 규격이 더해졌습니다. 작성자는 규격 문서는 여러 조직이 따를 때 표준이 될 수 있지만, 이를 쓰는 제품은 표준의 실제 사용 여부를 보여 준다고 구분합니다. 클로드 코드 v2.1.277부터는 CLAUDE.md가 없을 때 AGENTS.md를 읽으며, 설정하면 두 파일을 모두 읽습니다. 다만 재단의 거버넌스와 중립성은 개별 SDK가 스펙을 따르는지 보증하지 않습니다.

A2A는 상대 에이전트를 찾아 작업을 맡기고 진행 상황을 확인하거나 취소하는 규약이며, 인증 확인·요청 중계와 기록·작업 에이전트의 도구 호출은 다른 프로젝트가 보완합니다. A2A로 일을 받은 에이전트가 MCP로 도구를 호출할 수 있으며, 내부에서 어떤 도구를 썼는지는 작업을 맡긴 쪽에 보이지 않습니다. 쿠버네티스 서비스에 appProtocol: agentgateway.dev/a2a를 지정하면 agentgateway가 A2A 트래픽을 처리하고, 에이전트 카드 주소를 게이트웨이 주소로 바꾸며 호출 메서드와 결과, JSON-RPC 오류 코드를 액세스 로그에 남깁니다. 지원하지 않는 메서드도 HTTP 200 응답 안에 JSON-RPC 오류를 담을 수 있어 상태 코드만 보는 모니터링은 성공으로 셀 수 있지만, 게이트웨이 로그에는 오류가 기록됩니다.

두 버전을 함께 제공하는 서버는 카드에 v0.3과 v1.0 주소를 모두 적을 수 있습니다. 그러나 agentgateway는 v1.0 주소만 게이트웨이 주소로 바꾸고 v0.3 주소는 백엔드 주소로 남겨, v0.3 클라이언트가 게이트웨이를 우회해 백엔드에 직접 요청하는 사례가 확인됐습니다. 또 agentgateway v1.5.0에는 A2A 요청의 인가 기능이 없습니다. 인증은 호출자의 신원을 확인하고 인가는 호출자가 특정 메서드나 스킬을 쓸 수 있는지 판단합니다. MCP에는 도구 이름과 인자에 규칙을 적용하는 장치가 있지만 A2A에는 아직 없어 관측만 가능하며, 인증과 인가는 앱이나 다른 계층에서 맡아야 합니다.

에이전트 사례인 Goose는 2025년 12월 MCP, AGENTS.md와 함께 AAIF 창립 기부 프로젝트 3개 중 하나가 됐고, 2026년 4월 7일 Block 조직에서 aaif-goose/goose로 저장소를 옮겼습니다. 글 작성 시 별은 54,500개를 넘었고, 최신 버전은 2026년 9월 17일 출시된 v1.51.0입니다. MCP로 연결하는 확장은 70가지가 넘고 컨텍스트 파일로 AGENTS.md를 먼저 읽습니다. 작성자는 다른 조직의 에이전트를 카드로 찾아 작업을 맡기는 기능을 Goose 같은 에이전트가 기본 제공하면 A2A가 실무 규약으로 쓰인다고 설명합니다. 당시에는 그런 도구가 아직 보이지 않았습니다.

도입 전 점검 사항은 7가지입니다. 첫째, 에이전트 카드에 인증 방식이 적혀 있어도 SDK 기본 구성은 검사하지 않으므로 앱이나 앞단에서 인증을 걸어야 합니다. 둘째, 확장 에이전트 카드는 스펙상 인증된 요청에만 제공하지만 SDK 기본 구성은 신원을 확인하지 않아 주소를 아는 누구나 가져갈 수 있으므로 공개 가능한 정보만 담아야 합니다. 셋째, A2A-Version 헤더를 빼면 오류 없이 v0.3으로 처리됩니다. 넷째, 카드의 인터페이스 목록을 그대로 믿지 말고 실제 호출로 확인해야 합니다. 다섯째, 완료된 작업을 취소하면 스펙의 코드 -32002 대신 서버 내부 오류 코드 -32603이 올 수 있어, 이를 서버 장애로 오인해 재시도하지 않도록 별도 처리해야 합니다. 여섯째, 푸시 알림은 설정 저장과 전송 기능을 직접 연결해야 하며 전송 실패는 서버 로그에만 남으므로 로그도 확인해야 합니다. 일곱째, 태스크 저장소의 기본값은 파드 메모리여서 재시작하면 상태가 사라지므로 영속 저장소로 바꿔야 합니다.

앞으로 살펴볼 지표는 3가지입니다. 공식 SDK가 인증 검사와 푸시 전송을 기본 제공하는지, 게이트웨이가 A2A에서도 호출자별 권한을 검사하는지, A2A가 AAIF의 Growth에서 Impact 단계로 올라가는지입니다. AAIF는 2026년 9월 1일 신생 프로젝트용 Sandbox 단계를 만들고 단계별 기준을 정리했습니다. 글은 Impact 승격이 채택·커뮤니티·재단 관여의 증가를 뜻한다고 설명합니다.

A2A는 작업 진행 확인과 처리 중 취소가 필요한 경우 유용하며, 상대 에이전트가 바뀌어도 같은 클라이언트를 쓸 수 있게 합니다. 오래 걸리지 않고 중간 상태 확인이나 관리가 필요 없는 호출에는 MCP로 충분하다고 글은 설명합니다. MCP는 지난 7월 개정으로 요청을 각각 독립적으로 처리하는 구조가 됐습니다. 반면 작업 도중 되묻거나 거절할 수 있는 에이전트와 통신할 때 A2A 규약의 의미가 생깁니다. 대신 A2A는 응답 바이트가 늘고 호출당 1.2~2.1ms가 더 걸렸으며, 12개 점검 항목 중 스펙대로 동작한 것은 5개였습니다. 2026년 9월 기준 규격은 v1.0으로 고정됐지만, 스펙을 강제하는 기능은 사용하는 쪽에서 직접 갖춰야 한다고 글은 지적합니다. 9월 갱신 로드맵에는 v1.1 준비가 적혔고, 태스크 타임라인 개선과 양방향 스트리밍이 포함돼 이번 점검 내용도 이후 다시 확인할 필요가 있다고 밝혔습니다. 측정 스크립트·매니페스트·판정표와 게이트웨이 측정은 공개 저장소에 정리돼 있습니다. 작성자는 AAIF 앰버서더이며, A2A와 agentgateway가 재단 프로젝트인 점을 밝히고 스펙과 맞지 않는 부분도 직접 확인했다고 설명합니다.

A2A(에이전트 간 작업을 맡기고 진행 상태를 확인하는 규약)는 2026년 8월 17일 에이전틱 AI 재단(AAIF)의 호스티드 프로젝트가 됐습니다. 앞선 실험에서는 공식 SDK로 만든 서버의 동작을 12개 항목으로 점검하고 MCP 및 순수 HTTP와 비교했습니다. A2A는 작업 진행 상태 확인과 취소 규약을 제공하지만 응답 바이트와 지연 시간이 늘었고, 12개 항목 중 스펙대로 동작한 것은 5개였습니다. SDK 기본 구성은 에이전트 카드에 선언된 인증을 검사하지 않았습니다.

A2A 관리권은 공개 두 달 뒤인 2025년 6월 구글이 리눅스 재단에 넘기겠다고 발표했고, 2026년 8월 재단 산하 AAIF가 맡았습니다. 글 작성 시 재단은 A2A를 Growth 단계로 분류했고 그 위에는 Impact 단계가 있습니다. 재단 발표에 따르면 A2A는 공급망·금융·모바일 플랫폼의 운영 환경에서 사용되고 있으며 참여 조직은 150곳이 넘습니다. 중립 재단으로 관리 주체가 바뀌면 한 회사의 전략 변경에 따라 규격의 유지·개정이 멈출 위험을 줄일 수 있다고 글은 설명합니다. 저장소 주소도 google/A2A에서 a2aproject/A2A로 바뀌었습니다.

AAIF는 2025년 12월 만들어졌으며, A2A가 합류한 다음 날 Agent Router도 승인돼 글 작성 시점에 6개 프로젝트를 관리했습니다. 도구 호출 규격, 프로젝트 규칙 파일, 인프라, 에이전트 도구가 있던 재단에 에이전트 간 작업 전달 규격이 더해졌습니다. 작성자는 규격 문서는 여러 조직이 따를 때 표준이 될 수 있지만, 이를 쓰는 제품은 표준의 실제 사용 여부를 보여 준다고 구분합니다. 클로드 코드 v2.1.277부터는 CLAUDE.md가 없을 때 AGENTS.md를 읽으며, 설정하면 두 파일을 모두 읽습니다. 다만 재단의 거버넌스와 중립성은 개별 SDK가 스펙을 따르는지 보증하지 않습니다.

A2A는 상대 에이전트를 찾아 작업을 맡기고 진행 상황을 확인하거나 취소하는 규약이며, 인증 확인·요청 중계와 기록·작업 에이전트의 도구 호출은 다른 프로젝트가 보완합니다. A2A로 일을 받은 에이전트가 MCP로 도구를 호출할 수 있으며, 내부에서 어떤 도구를 썼는지는 작업을 맡긴 쪽에 보이지 않습니다. 쿠버네티스 서비스에 appProtocol: agentgateway.dev/a2a를 지정하면 agentgateway가 A2A 트래픽을 처리하고, 에이전트 카드 주소를 게이트웨이 주소로 바꾸며 호출 메서드와 결과, JSON-RPC 오류 코드를 액세스 로그에 남깁니다. 지원하지 않는 메서드도 HTTP 200 응답 안에 JSON-RPC 오류를 담을 수 있어 상태 코드만 보는 모니터링은 성공으로 셀 수 있지만, 게이트웨이 로그에는 오류가 기록됩니다.

두 버전을 함께 제공하는 서버는 카드에 v0.3과 v1.0 주소를 모두 적을 수 있습니다. 그러나 agentgateway는 v1.0 주소만 게이트웨이 주소로 바꾸고 v0.3 주소는 백엔드 주소로 남겨, v0.3 클라이언트가 게이트웨이를 우회해 백엔드에 직접 요청하는 사례가 확인됐습니다. 또 agentgateway v1.5.0에는 A2A 요청의 인가 기능이 없습니다. 인증은 호출자의 신원을 확인하고 인가는 호출자가 특정 메서드나 스킬을 쓸 수 있는지 판단합니다. MCP에는 도구 이름과 인자에 규칙을 적용하는 장치가 있지만 A2A에는 아직 없어 관측만 가능하며, 인증과 인가는 앱이나 다른 계층에서 맡아야 합니다.

에이전트 사례인 Goose는 2025년 12월 MCP, AGENTS.md와 함께 AAIF 창립 기부 프로젝트 3개 중 하나가 됐고, 2026년 4월 7일 Block 조직에서 aaif-goose/goose로 저장소를 옮겼습니다. 글 작성 시 별은 54,500개를 넘었고, 최신 버전은 2026년 9월 17일 출시된 v1.51.0입니다. MCP로 연결하는 확장은 70가지가 넘고 컨텍스트 파일로 AGENTS.md를 먼저 읽습니다. 작성자는 다른 조직의 에이전트를 카드로 찾아 작업을 맡기는 기능을 Goose 같은 에이전트가 기본 제공하면 A2A가 실무 규약으로 쓰인다고 설명합니다. 당시에는 그런 도구가 아직 보이지 않았습니다.

도입 전 점검 사항은 7가지입니다. 첫째, 에이전트 카드에 인증 방식이 적혀 있어도 SDK 기본 구성은 검사하지 않으므로 앱이나 앞단에서 인증을 걸어야 합니다. 둘째, 확장 에이전트 카드는 스펙상 인증된 요청에만 제공하지만 SDK 기본 구성은 신원을 확인하지 않아 주소를 아는 누구나 가져갈 수 있으므로 공개 가능한 정보만 담아야 합니다. 셋째, A2A-Version 헤더를 빼면 오류 없이 v0.3으로 처리됩니다. 넷째, 카드의 인터페이스 목록을 그대로 믿지 말고 실제 호출로 확인해야 합니다. 다섯째, 완료된 작업을 취소하면 스펙의 코드 -32002 대신 서버 내부 오류 코드 -32603이 올 수 있어, 이를 서버 장애로 오인해 재시도하지 않도록 별도 처리해야 합니다. 여섯째, 푸시 알림은 설정 저장과 전송 기능을 직접 연결해야 하며 전송 실패는 서버 로그에만 남으므로 로그도 확인해야 합니다. 일곱째, 태스크 저장소의 기본값은 파드 메모리여서 재시작하면 상태가 사라지므로 영속 저장소로 바꿔야 합니다.

앞으로 살펴볼 지표는 3가지입니다. 공식 SDK가 인증 검사와 푸시 전송을 기본 제공하는지, 게이트웨이가 A2A에서도 호출자별 권한을 검사하는지, A2A가 AAIF의 Growth에서 Impact 단계로 올라가는지입니다. AAIF는 2026년 9월 1일 신생 프로젝트용 Sandbox 단계를 만들고 단계별 기준을 정리했습니다. 글은 Impact 승격이 채택·커뮤니티·재단 관여의 증가를 뜻한다고 설명합니다.

A2A는 작업 진행 확인과 처리 중 취소가 필요한 경우 유용하며, 상대 에이전트가 바뀌어도 같은 클라이언트를 쓸 수 있게 합니다. 오래 걸리지 않고 중간 상태 확인이나 관리가 필요 없는 호출에는 MCP로 충분하다고 글은 설명합니다. MCP는 지난 7월 개정으로 요청을 각각 독립적으로 처리하는 구조가 됐습니다. 반면 작업 도중 되묻거나 거절할 수 있는 에이전트와 통신할 때 A2A 규약의 의미가 생깁니다. 대신 A2A는 응답 바이트가 늘고 호출당 1.2~2.1ms가 더 걸렸으며, 12개 점검 항목 중 스펙대로 동작한 것은 5개였습니다. 2026년 9월 기준 규격은 v1.0으로 고정됐지만, 스펙을 강제하는 기능은 사용하는 쪽에서 직접 갖춰야 한다고 글은 지적합니다. 9월 갱신 로드맵에는 v1.1 준비가 적혔고, 태스크 타임라인 개선과 양방향 스트리밍이 포함돼 이번 점검 내용도 이후 다시 확인할 필요가 있다고 밝혔습니다. 측정 스크립트·매니페스트·판정표와 게이트웨이 측정은 공개 저장소에 정리돼 있습니다. 작성자는 AAIF 앰버서더이며, A2A와 agentgateway가 재단 프로젝트인 점을 밝히고 스펙과 맞지 않는 부분도 직접 확인했다고 설명합니다.