A2A Extensions는 9월 9일에 무엇을 공개했나? AI Agent 확장과 JSON 프로토콜 (2026)

읽기 전 요약

항목	설명
공식 게시	2025-09-09 Google Developers Blog《A2A Extensions: Empowering Custom Agent Functionality》
핵심 산출물	URI로 식별하는 선택적 프로토콜 확장: 새 데이터, 새 제약, 새 RPC, 새 상태 기계
JSON 위치	Agent Card의 capabilities.extensions[]
협상 방식	HTTP 헤더 A2A-Extensions. 기본은 비활성
2026 포지션	A2A는 Agent 상호운용을, Extensions는 도메인 커스텀을 맡는다. MCP나 Function Calling을 대체하지 않는다

9월 9일에 무엇을 공개했나?

A2A(Agent2Agent)는 이미 Agent가 서로를 발견하고, 작업을 보내고, 결과를 스트리밍으로 돌려주는 방식을 규정한다. 그러나 코어 프로토콜은 범용이어야 한다——「음성 지연 브로드캐스트」「엔드투엔드 추적」「제로 트러스트 핸드셰이크」같은 수직 능력을 내장할 수는 없다. 2025년 9월 9일, Google 엔지니어가 공식 블로그에서 내놓은 답이 Extensions다.

그날 공개된 것은 어떤 새 RPC 하나가 아니라, 한 세트의개방 확장 메커니즘이다:

• 누구나 확장을 정의·게시·구현할 수 있고, 고유 URI로 식별한다(버전 번호를 넣는 것을 권장. 예: https://example.com/ext/my-extension/v1).
• Agent는 Agent Card(능력을 기술하는 JSON)에서 자신이 지원하는 확장을 선언한다.
• Client는 단일 요청에서 HTTP 헤더로필요할 때만 활성화한다. 선언하지 않은 클라이언트는 코어 프로토콜을 그대로 쓰며 깨지지 않는다.
• 공식은 동시에 Hello World를 제시했다: Message / Artifact의 metadata에 타임스탬프를 찍는다.

2026년에는 규격이 A2A Extensions 특집에 쓰여 있고, 거버넌스 프레임워크도 등장했다(공식 확장은 https://a2a-protocol.org/extensions/ 접두사를 쓴다). 아래에서는 JSON 프로토콜로 메커니즘을 분해한다.

A2A 프로토콜과 Agent Card JSON

Agent Card는 Agent의 「기계가 읽을 수 있는 명함」으로 이해하면 된다: 이름, 설명, 진입 URL, 입출력 MIME, 스킬 목록, 그리고 capabilities. Extensions는 capabilities에 매달리고, 별도 파일을 만들지 않는다.

확장이 붙은 Agent Card는 대략 다음과 같다(구조는 공식 예시, 필드명은 현행 규격을 따른다):

{
  "name": "Magic 8-ball",
  "description": "An agent that can tell your future... maybe.",
  "version": "0.1.0",
  "url": "https://example.com/agents/eightball",
  "capabilities": {
    "streaming": true,
    "extensions": [
      {
        "uri": "https://example.com/ext/konami-code/v1",
        "description": "Provide cheat codes to unlock new fortunes",
        "required": false,
        "params": {
          "hints": [
            "When your sims need extra cash fast"
          ]
        }
      }
    ]
  },
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/plain"],
  "skills": [
    {
      "id": "fortune",
      "name": "Fortune teller",
      "description": "Seek advice from the mystical magic 8-ball",
      "tags": ["mystical"]
    }
  ]
}

이 JSON을 디버깅할 때는 JSONSort 포맷으로 괄호와 쉼표를 먼저 확인하고, Schema와 대조해 extensions[]에 빠진 필드가 있는지 본다. Agent Card는 네트워크에 공개되므로 params에 비밀 키를 넣지 말 것.

확장 메커니즘: 선언, 기본 꺼짐, 요청마다 활성화

Extensions의 설계 목표는 A2A를 확장하되 코어 표준을 찢지 않는 것이다. 규격은 몇 가지 경계를 분명히 한다:

1. 기본은 비활성. 확장을 모르는 클라이언트도 코어 메서드를 호출해 베이스라인 경험을 얻는다.
2. Client가 능동적으로 opt-in한다. HTTP 요청에 A2A-Extensions를 붙이고, 값은 쉼표로 구분한 URI 목록이다.
3. Agent는 지원하지 않는 URI를 무시하고, 응답 헤더에 실제로 활성화된 확장을 에코한다.
4. required: true는 하드 의존이다. 클라이언트가 활성화하지 않거나 지키지 않으면 Agent는 요청을 거절해야 한다. 데이터 표시형 확장에는 required를 달지 말 것.

확장은 다른 확장에 의존할 수 있다(필수 또는 선택). 규격은 확장 설명서에 의존성을 쓰라고 요구하며, 활성화 시 Client가 의존 URI도 함께 붙인다. 버전 번호는 URI에 넣는다: 파괴적 변경은 반드시 새 URI로 바꾸고, Agent는몰래 다른 버전으로 후퇴해서는 안 된다.

AgentExtension JSON 필드 해설

규격은 코어 타입 검증을 확장이 깨지 않도록 넘지 말아야 할 선도 그었다: 프로토콜이 이미 정의한 데이터 구조에 필수 필드를 더하거나 빼지 말 것. 커스텀 속성은 기존 metadata map에 넣는다. 열거에 새 값을 넣지 말 것. 추가 의미 역시 metadata에 쓴다. 이 두 조항이 JSON이 어떤 모양이어야 하는지를 바로 결정한다.

요청 협상: HTTP 헤더 + JSON-RPC 메시지

활성화는 「연결하면 영구히 켜짐」이 아니라 매 HTTP 요청에서 일어난다. 전형적인 요청(공식 Hello World 스타일):

POST /agents/eightball HTTP/1.1
Host: example.com
Content-Type: application/json
A2A-Extensions: https://example.com/ext/konami-code/v1

{
  "jsonrpc": "2.0",
  "method": "SendMessage",
  "id": "1",
  "params": {
    "message": {
      "messageId": "1",
      "role": "ROLE_USER",
      "parts": [{"text": "Oh magic 8-ball, will it rain today?"}]
    },
    "metadata": {
      "https://example.com/ext/konami-code/v1/code": "motherlode"
    }
  }
}

대응 응답은 활성화에 성공한 확장을 에코해야 한다:

HTTP/1.1 200 OK
Content-Type: application/json
A2A-Extensions: https://example.com/ext/konami-code/v1

{
  "jsonrpc": "2.0",
  "id": "1",
  "result": {
    "message": {
      "messageId": "2",
      "role": "ROLE_AGENT",
      "parts": [{"text": "That's a bingo!"}]
    }
  }
}

주의: params.metadata의 키는확장 URI에 경로 접미사를 더한 것이지, 아무 짧은 필드명이 아니다. 이렇게 하면 여러 확장이 같은 JSON-RPC에 데이터를 넣어도 이름이 충돌하지 않는다. 「확장이 안 먹힌다」를 조사할 때는 먼저 요청 헤더에 URI가 있는지 보고, 이어서 요청/응답 JSON을 diff한다——JSON Diff는 활성화 전후 metadata 비교에 잘 맞는다.

네 가지 확장: 데이터, Profile, 메서드, 상태 기계

규격은 「확장이 무엇을 할 수 있는지」를 의도적으로 넓게 썼지만, 2026년에 내다볼 수 있는 용법은 네 가지로 접을 수 있다:

• 데이터형（Data-only）: Agent Card에 구조화 정보만 더 노출하고, 요청-응답 흐름은 바꾸지 않는다. 예: GDPR 준수 필드 선언. 이런 종류는 required: true를 달지 말 것.
• Profile 형: 코어 메시지에 더 엄한 구조나 상태 제약을 겹친다. A2A에 profile을 한 겹 씌우는 셈이다. 예: 모든 parts가 어떤 Schema를 따르는 DataPart여야 함; 또는 TaskStatus.state === "working"일 때 metadata["generating-image"]로 하위 상태를 나타낸다.
• 메서드형（Extended Skills）: 코어 집합 밖의 RPC를 추가한다. 예: task-history 확장이 tasks/search를 더해, Agent에 「이력 작업을 검색할 수 있는」 스킬을 하나 늘린다.
• 상태 기계형: 작업 상태 기계에 상태나 전이를 더한다. 선을 밟기 가장 쉬운 종류이므로, 새 의미는 반드시 metadata에 두고 코어 열거를 고치지 말 것.

공개 당일 이름이 오른 현장 사례

Google 블로그는 추상 메커니즘만 이야기하지 않고, 당시 이미 쓰이던 확장을 나열해 JSON이 무엇을 실어야 하는지 대조하기 쉽게 했다.

Traceability（추적 가능성）: 코어 메시지는 ResponseTrace——주 프로토콜과 독립된 구조화 로그로, Agent가 취한 단계를 기록한다. 각 Step은 ToolInvocation(도구/API 호출)이거나 AgentInvocation(다른 Agent를 다시 호출)이다. 단계는 중첩될 수 있다: 하류 Agent도 이 확장을 지원하면 그 trace가 상류 단계에 매달려 엔드투엔드 호출 트리를 만든다. 다중 Agent 협업을 평가하고 오류를 찾는 데 필수지만, A2A 코어에 넣을 필요는 없다.

Twilio Latency Extension: 음성 Agent(ConversationRelay)는 지연을 브로드캐스트해 가장 알맞은 하류 모델을 고르거나 우아하게 강등한다. 지연은 Agent Card의 코어 필드가 아니다. Twilio가 확장으로 메운 것은 「도메인 데이터가 코어 프로토콜을 오염시켜서는 안 된다」는 전형이다.

Identity Machines: 확장으로 Agent 간 제로 트러스트 핸드셰이크를 한다. 작업 위임 전에 목적, 예산, 능력, 모델, PII 상태 등 커스텀 조건을 정책 게이트로 검사한다. 여기서 JSON이 실는 것은 정책 컨텍스트이지 채팅 텍스트가 아니다.

블로그는 Ethereum의 ERC-8004 방향도 언급한다: 온체인 신원/평판/검증 레지스트리로 조직 간 Agent에 신뢰 층을 깐다. A2A Extension 형태로 게시된다는 보장은 없지만, 같은 문제——코어 프로토콜은 「어떻게 말하는가」를 풀고, 확장과 외부 표준은 「왜 신뢰하는가」를 푼다——를 보여 준다.

MCP, Function Calling과는 어떤 관계인가?

세 가지 모두 JSON을 내놓지만 계층이 다르다. 2026년에 서로를 대체해서는 안 된다:

흔한 아키텍처는 층을 나눈다: MCP Server가 도구를 제공 → 호스트가 도구를 모델의 Function Calling으로 매핑 → 여러 Agent 사이는 A2A로 작업을 보내고, Extensions로 추적·지연·신원 등 교차 Agent 데이터를 실는다. 앞 두 층의 JSON 비교는 이전 글 MCP Tool Schema vs Function Calling을 보라.

JSON Schema로 확장 데이터를 제약하기

확장 규격은 최소한 다음을 써야 한다: URI 목록, params의 schema, Client/Agent 사이 추가 데이터 구조, 새 요청-응답 흐름. 현장에 내릴 때는:

• AgentExtension.params와 metadata 키마다 JSON Schema를 유지한다.
• CI에서 예시 payload로 검증한다. Agent Card는 공개 API 계약으로 다룬다.
• 확장 관련 입력은 모두 신뢰할 수 없는 데이터로 보고, 먼저 parse한 뒤 validate한다.

JSON Schema 작성법은 본 사이트의 JSON Schema 완전 튜토리얼을 참고하라. 로컬 포맷, 문법 검사, 다중 버전 Diff는 JSONSort면 충분하다. 정책이나 신원 정보가 든 Card를 제3자 사이트에 올릴 필요는 없다.

흔한 오해

• Extension을 「아무 필드나 더하기」로 생각한다. 코어 구조는 바꾸지 않는다. 새 데이터는 metadata로.
• 데이터형 확장에 required를 단다. 수많은 클라이언트를 쓸데없이 거절한다.
• URI에 버전을 넣지 않는다. 파괴적 변경의 탈출구가 없고 협상도 꼬인다.
• 버전이 안 맞을 때 옛 구현으로 후퇴한다. 규격은 그 활성화 요청을 무시하라고 하지, 몰래 호환하라고 하지 않는다.
• 새 RPC가 기존 인가를 우회한다. 확장 메서드는 코어 메서드와 같은 인증·인가를 타야 한다.
• MCP 도구 목록과 한 덩어리로 본다. MCP는 「어떤 도구가 있는가」를 풀고, A2A Extension은 「두 Agent가 도메인 규칙으로 어떻게 말하는가」를 푼다.

자주 묻는 질문（FAQ）

A2A Extensions는 2026년 9월 9일에 공개됐나?

공식 블로그 날짜는 2025년 9월 9일이다. 2026년 독자도 이 날짜로 「무엇을 공개했나」를 검색한다. 메커니즘 자체는 현행 A2A 규격에 쓰여 있고, 거버넌스와 예시 확장(Traceability, Timestamp, Secure Passport 등)이 이어지고 있다.

확장을 구현해야 A2A를 쓸 수 있나?

아니다. 확장은 기본이 꺼져 있다. 상대 Agent Card가 어떤 확장을 required로 표시했을 때만, 규격대로 활성화하고 지켜야 한다.

확장 JSON은 메시지 본문과 HTTP 헤더 어디에 두나?

활성화 목록은 A2A-Extensions 헤더. 확장이 나르는 업무 데이터는 JSON-RPC params.metadata(또는 규격이 지정한 다른 위치). 헤더가 협상을, JSON이 페이로드를 담당한다.

Agent Card와 확장 metadata는 어떻게 디버깅하나?

로컬에서 JSONSort로 Card를 포맷하고, Schema를 검증하고, 두 버전의 extensions 배열을 diff한다. 신원이나 정책이 든 JSON을 온라인 도구에 붙여 넣지 말 것.

결론

9월 9일에 공개된 것은 또 하나의 벤더 사유 API가 아니라 A2A의 개방 확장 층이다: URI로 능력에 이름을 붙이고, Agent Card JSON으로 선언하며, A2A-Extensions로 요청마다 활성화하고, metadata로 도메인 데이터를 싣는다. 2026년 다중 Agent 시스템을 만들 때: 코어 대화는 A2A, 도구 공급은 MCP, 모델 의도는 Function Calling, 수직 요구는 Extensions——넷이 각 층을 맡고, JSON Schema를 파라미터와 확장 데이터의 단일 사실 원천으로 삼는다.

더 읽을거리

• Google: A2A Extensions 공개 블로그 2025-09-09 원문과 사례
• A2A Extensions 규격 특집 선언, 활성화, 거버넌스와 제한
• MCP Tool Schema vs Function Calling 도구 층 JSON 비교
• JSONSort 로컬 JSON 도구상자 포맷, 문법 검증, Diff

업데이트 로그: 2026-08-28 초고 게시