A2A Agent Card 검수, 접속 주소가 여러 개면 어느 곳에 보낼까

2026년 11월 기준, A2A Agent Card에서 전송 방식과 버전이 맞는 첫 항목을 고릅니다. 맞는 항목이 없으면 호출을 보류합니다.

재고 조회 에이전트에 검토를 맡기려는 가상 상황입니다. 카드에는 HTTP+JSON 주소가 먼저 있고, 그 아래에 JSONRPC 구버전과 새 버전 주소가 나옵니다. 요청을 보내는 쪽이 JSONRPC 바인딩에서 A2A 1.0만 지원한다면, 카드가 정상적으로 열렸다는 사실에 더해 실제 어느 주소와 버전으로 호출했는지 확인해야 합니다.

카드에 주소가 여러 개면 어떤 항목을 고르나요?#

클라이언트가 지원하는 전송 방식과 버전의 조합을 먼저 적습니다. 그 조건에 맞는 항목이 여럿이면 카드의 앞쪽 항목을 고릅니다. 요청에는 선택한 항목의 주소와 버전, tenant가 있으면 그 값을 함께 사용합니다.

A2A의 AgentInterface는 접속 주소인 url, 전송 바인딩인 protocolBinding, A2A 버전인 protocolVersion, 선택 항목인 tenant를 담습니다. 명세는 카드 순서에서 처음 지원하는 전송 방식을 선택해 해당 주소를 쓰도록 합니다. 이 글의 가상 인수 조건은 JSONRPC 바인딩에서 A2A 1.0만 허용하므로 0.3 항목도 제외합니다. A2A 공식 명세의 인터페이스 선언과 선택 규칙

tenant는 같은 접속 주소 뒤에서 에이전트나 테넌트로 요청을 라우팅하는 식별자입니다. 고른 항목에 값이 있으면 그 값을 요청에 그대로 반영하고, 항목에 없으면 tenant 필드를 생략합니다. 서버는 요청자의 인증과 업무 권한을 별도로 검증해야 합니다. AgentInterface의 필드 정의

실제 요청에서 무엇을 대조하나요?#

선택한 항목과 첫 요청에서 관측한 주소·바인딩·버전·tenant를 나란히 기록합니다. 같은 항목에서 나온 값이 요청에 모두 반영되면 인터페이스 선택 검수를 통과합니다. 인증과 업무 성공 여부는 이후 단계에서 각각 확인합니다.

아래는 가상 Agent Card의 supportedInterfaces 발췌입니다. 클라이언트가 JSONRPC 바인딩과 A2A 1.0 조합만 지원하면 세 번째 항목이 선택됩니다. 주소는 rpc-v1입니다. JSON-RPC 2.0 요청의 HTTP 헤더 A2A-Version에는 1.0을, SendMessage의 params.tenant에는 stock-review를 넣습니다. JSONRPC 바인딩의 서비스 파라미터와 요청 형식

{
  "supportedInterfaces": [
    {
      "url": "https://agent.example.invalid/rest",
      "protocolBinding": "HTTP+JSON",
      "protocolVersion": "1.0"
    },
    {
      "url": "https://agent.example.invalid/rpc-legacy",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "0.3"
    },
    {
      "url": "https://agent.example.invalid/rpc-v1",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0",
      "tenant": "stock-review"
    }
  ]
}

요청의 A2A-Version은 문서 릴리스 번호와 구분합니다. 패치 번호는 버전 협상에서 제외합니다. HTTP의 A2A-Version 헤더는 주 버전과 부 버전 형식이므로 이 예시에서는 1.0을 사용합니다. 명세에 따르면 서버는 빈 버전 값을 0.3으로 해석하고, 인터페이스가 지원하지 않는 버전은 VersionNotSupportedError로 돌려줍니다. 1.0이 필수인 연동에서는 빈 값이나 구버전 재시도로 오류를 숨기지 않도록 검수합니다. A2A 공식 명세의 버전 규칙

어떤 연동에 이 검수가 필요한가요?#

서로 다른 서비스의 에이전트에 업무를 보내는 연동이라면 카드의 선언과 요청을 대조합니다. 한 에이전트가 정해진 내부 도구를 호출하는 데 그치면, 기존 도구 연결과 권한 검수로 범위를 정할 수 있습니다. 카드 선택 검수 뒤에는 같은 호출에서 실제 인증과 권한, 업무 응답을 따로 확인합니다.

검수 기록에는 카드 확인 시점, 선택한 항목, 전송 전 요청에서 관측한 값, 실패 시 보류 사유를 남깁니다. 민감한 헤더와 실제 고객 데이터는 증적에 필요한 범위부터 정한 뒤 가립니다. 팀이 이미 쓰는 MCP 서버 구축 검수, 온톨로지 MCP의 읽기와 실행 경계, MCP SSE 응답 복원 검수는 도구 호출과 응답 단계의 판단 기준입니다.

근거와 확인일#

A2A 커뮤니티는 2026년 3월 12일 v1.0을 발표했습니다. 공식 v1.0.1 릴리스 기록은 변경 이력을 5월 26일자로 표시하고 GitHub 공개일은 5월 28일입니다. 이 글은 2026년 11월 7일 확인한 v1.0.1 명세의 인터페이스 선택과 버전 규칙에 맞춰 가상 표본을 구성했습니다. v1.0 발표 원문 · v1.0.1 릴리스

알파카랩스는 출처와 권한을 지키는 AI·MCP 조회와 운영 인수 조건을 협의하는 범위를 공개하고 있습니다. 2026년 11월 7일 확인한 자사 서비스 설명입니다. 온톨로지 구축·컨설팅 서비스

A2A Agent Card 검수 FAQ#

A2A 연결 인수표 초안 협의#

첫 범위 협의에서 가상 또는 비식별 카드와 지원 조합을 바탕으로 선택 항목·요청 증거·호출 보류 조건을 초안으로 정리합니다. 소요 시간은 자료와 검수 범위를 확인한 뒤 협의합니다.