[A2A 알아보기 1편] A2A 프로토콜: 프레임워크가 서로 달라도 에이전트들끼리 서로 작업을 위임하게 하는 표준 규격

9bow · 9월 11, 2026, 11:00오전

A2A 프로토콜 소개

A2A(Agent2Agent) 프로토콜은 서로 다른 프레임워크와 회사가 만든 AI 에이전트가 상대의 내부 상태와 도구를 들여다보지 않고도 작업을 맡기고 결과를 주고받게 하는 개방형 통신 규격입니다. 지금 에이전트를 만드는 팀은 LangGraph, CrewAI, Semantic Kernel, Google ADK(Agent Development Kit) 중 하나를 고르거나 직접 만든 루프를 씁니다. 이 선택은 팀마다 다르고, 그래서 A팀의 에이전트가 B팀의 에이전트에게 일을 넘기려면 둘 사이에만 통하는 연동 코드를 매번 새로 써야 합니다. 연동 대상이 늘어날수록 이 코드는 조합의 수만큼 늘어납니다.

A2A는 그 연동 지점을 프레임워크 밖의 공통 규격으로 옮깁니다. 각 에이전트는 자신이 무엇을 할 수 있는지를 적은 JSON 문서 하나를 공개하고, 상대는 그 문서만 읽고 표준 방식으로 요청을 보냅니다. 요청을 받은 쪽이 LangGraph로 만들어졌는지 Java로 짜였는지는 보내는 쪽이 알 필요가 없고, 알 수도 없습니다. 프로토콜이 명시적으로 내건 설계 원칙 중 하나가 불투명한 실행(Opaque Execution) 으로, 에이전트는 공개한 능력과 주고받은 정보만으로 협력하고 내부 계획이나 도구 구현은 공유하지 않습니다.

A2A는 Google이 처음 개발해 Linux Foundation에 기부했고, 지금은 AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP, ServiceNow의 대표들로 구성된 기술 운영 위원회(Technical Steering Committee)가 관리합니다. 명세는 2025년의 0.1.0에서 시작해 0.2 계열과 0.3.0을 거쳐 2026년 3월 1.0.0에 이르렀고, 저장소의 최신 릴리즈는 명세 본문의 오류를 고친 v1.0.1입니다. 공식 SDK는 Python, JavaScript, Java, C#/.NET, Go, Rust용으로 제공됩니다. 본 게시물에서는 1.0 명세를 기준으로 A2A의 데이터 모델과 동작, 그리고 0.3에서 넘어올 때 깨지는 부분을 정리합니다.

A2A 프로토콜과 MCP의 역할 분담

A2A를 처음 접할 때 가장 먼저 생기는 질문은 MCP(Model Context Protocol) ( 다음 MCP 스펙 릴리즈(2026-07-28)의 주요 내용: Stateless 전환 및 공식 확장 도입 예정)와 무엇이 다른가입니다. A2A 프로젝트는 이 둘을 경쟁 관계가 아니라 서로를 보완하는 관계로 설명하며, 각자가 푸는 문제가 다르다는 점을 근거로 듭니다. MCP는 에이전트 하나가 도구, API, 데이터에 접근하는 방법을 표준화하고, A2A는 그렇게 무장한 에이전트들이 서로를 찾고 작업을 위임하고 결과를 나누는 방법을 표준화합니다:

프로젝트가 "A2A가 아닌 것" 을 따로 명시해 둔 목록도 오해를 줄이는 데 도움이 됩니다. A2A는 LangGraph나 CrewAI 같은 에이전트 개발 키트가 아니고, 에이전트가 자기 하위 에이전트를 부르거나 도구를 호출하는 방법을 정하지도 않습니다. 그 자리는 각 프레임워크의 기본 기능이나 MCP의 몫입니다. Slack이나 Discord 같은 대화형 메시징 앱도 아니며, 자율 에이전트 사이의 기계 대 기계 통신을 위한 규격입니다.

한국어권에서 A2A가 처음 소개된 것은 2025년 Google의 공개 시점이었고, 그때의 내용은 PyTorchKR의 A2A 공개 소식 글에 정리되어 있습니다. 그 글이 다룬 0.x 시절과 지금의 1.0 사이에는 거버넌스와 데이터 모델 양쪽에서 적지 않은 변화가 있었고, 아래 절들이 그 차이를 다룹니다.

A2A 프로토콜의 3계층 구조

A2A 명세는 서로 다른 세 층으로 나뉘어 있고, 이 구분이 프로토콜을 읽는 순서를 정해 줍니다:

1계층인 정본 데이터 모델(Canonical Data Model) 은 Task, Message, AgentCard, Part, Artifact, Extension 같은 핵심 구조체를 정의합니다. 이 계층은 프로토콜 중립이며, Protocol Buffer 메시지로 표현됩니다. 명세가 "spec/a2a.proto 파일이 모든 프로토콜 데이터 객체와 요청/응답 메시지의 유일한 정본 정의" 라고 밝히고 있어, SDK의 언어별 타입과 JSON 스키마는 이 proto에서 다시 생성해야 하고 손으로 고쳐서는 안 됩니다. 문서 사이트의 정의 페이지가 제공하는 JSON Schema도 proto에서 자동 생성된 비정본 산출물입니다.

2계층인 추상 오퍼레이션(Abstract Operations) 은 구현이 지원해야 하는 동작을 전송 방식과 무관하게 서술합니다. 메시지 전송, 스트리밍 메시지 전송, 태스크 조회, 태스크 목록 조회, 태스크 취소, 태스크 구독, 푸시 알림 설정의 생성/조회/목록/삭제, 확장 에이전트 카드 조회까지 11가지입니다.

3계층인 프로토콜 바인딩(Protocol Binding) 은 위 오퍼레이션을 JSON-RPC, gRPC, HTTP+JSON/REST 같은 구체적인 전송 방식에 대응시킵니다. 같은 동작이 바인딩마다 어떤 이름과 경로를 갖는지는 명세 §5.3의 대응표가 정리하고 있으며, 주요 항목은 다음과 같습니다:

기능	JSON-RPC 메서드	gRPC 메서드	REST 엔드포인트
메시지 전송	`SendMessage`	`SendMessage`	`POST /message:send`
스트리밍 메시지 전송	`SendStreamingMessage`	`SendStreamingMessage`	`POST /message:stream`
태스크 조회	`GetTask`	`GetTask`	`GET /tasks/{id}`
태스크 목록 조회	`ListTasks`	`ListTasks`	`GET /tasks`
태스크 취소	`CancelTask`	`CancelTask`	`POST /tasks/{id}:cancel`
태스크 구독	`SubscribeToTask`	`SubscribeToTask`	`POST /tasks/{id}:subscribe`
확장 에이전트 카드 조회	`GetExtendedAgentCard`	`GetExtendedAgentCard`	`GET /extendedAgentCard`

바인딩이 여러 개라는 사실이 클라이언트에게 부담이 되지 않는 이유는 명세 §5.1이 기능적 동등성을 요구하기 때문입니다. 한 에이전트가 여러 바인딩을 지원한다면 모든 바인딩이 같은 오퍼레이션과 기능을 제공해야 하고, 같은 요청에 의미상 같은 결과를 돌려주어야 하며, 오류를 일관되게 대응시키고, 에이전트 카드에 선언한 같은 인증 방식을 지원해야 합니다. 클라이언트는 자신이 다룰 수 있는 바인딩을 고르기만 하면 되고, 무엇을 골랐는지에 따라 할 수 있는 일이 달라지지 않습니다.

이 계층 분리 덕분에 새 전송 방식을 추가해도 데이터 모델은 그대로 둘 수 있습니다. 명세 §12는 사설 바인딩을 만들 때 지켜야 할 조건까지 규정해 두었고, 실제로 a2aproject 조직에는 SLIMRPC 바인딩을 다루는 experimental-cpb-slimrpc 같은 실험 저장소가 있습니다.

A2A 프로토콜의 에이전트 카드

에이전트 카드(Agent Card)는 A2A 서버가 공개하는 JSON 문서로, 클라이언트가 상대 에이전트를 찾고 연결 방식을 결정하는 근거가 됩니다. A2A 서버는 이 문서를 반드시 제공해야 하며, 클라이언트는 잘 알려진 경로인 https://{도메인}/.well-known/agent-card.json에서 받거나, 별도의 목록 서비스를 조회하거나, 미리 설정된 주소를 쓰는 세 가지 방법으로 얻습니다.

카드에서 필수인 항목은 name, description, version, supportedInterfaces, capabilities, defaultInputModes, defaultOutputModes, skills입니다. 이 가운데 skills는 에이전트가 잘하는 일을 하나씩 기술한 목록이고, 각 항목은 식별자와 이름, 설명, 태그, 예시 프롬프트, 그리고 그 기능에만 적용되는 입출력 미디어 타입을 가질 수 있습니다.

연결 방식은 supportedInterfaces 배열이 정합니다. 배열의 각 항목은 접속 주소(url), 프로토콜 바인딩(protocolBinding, 공식 값은 JSONRPC, GRPC, HTTP+JSON), 그리고 그 주소가 제공하는 프로토콜 버전(protocolVersion)을 담습니다. 순서에 의미가 있어서 앞쪽 항목이 선호하는 인터페이스이고, 클라이언트는 자신이 지원하는 것 중 가장 앞에 있는 항목을 골라야 합니다. 여러 에이전트를 하나의 엔드포인트 뒤에 두는 경우를 위해 불투명한 라우팅 식별자인 tenant 필드도 있으며, 이 값이 설정되어 있으면 클라이언트는 모든 요청에 같은 값을 넣어야 합니다.

선택 기능은 capabilities 안에 모여 있습니다. 스트리밍 지원 여부(streaming), 푸시 알림 지원 여부(pushNotifications), 인증 후 확장 카드 제공 여부(extendedAgentCard), 그리고 지원하는 확장 목록(extensions)입니다. 클라이언트가 카드에 선언되지 않은 기능을 쓰려고 하면 서버는 해당하는 오류를 돌려주어야 하므로, 오퍼레이션을 호출하기 전에 카드를 먼저 확인하는 것이 정석입니다. 카드는 RFC 7515의 JSON Web Signature로 서명할 수도 있어서, 위변조 여부와 발급자를 검증하려는 경우에 쓸 수 있습니다.

A2A 프로토콜의 태스크와 아티팩트

A2A에서 작업의 단위는 태스크(Task)입니다. 태스크는 서버가 생성한 고유 식별자를 가지며, 현재 상태(status), 결과물 목록(artifacts), 오간 메시지 기록(history)을 함께 담습니다. 상태 값은 아홉 가지가 정의되어 있고, 그중 네 가지가 더 이상 진행되지 않는 종료 상태입니다:

상태	의미
`TASK_STATE_SUBMITTED`	태스크가 접수되어 확인된 상태
`TASK_STATE_WORKING`	에이전트가 처리 중인 상태
`TASK_STATE_INPUT_REQUIRED`	진행에 추가 입력이 필요해 중단된 상태
`TASK_STATE_AUTH_REQUIRED`	진행에 인증이 필요해 중단된 상태
`TASK_STATE_COMPLETED`	성공적으로 끝난 종료 상태
`TASK_STATE_FAILED`	오류로 끝난 종료 상태
`TASK_STATE_CANCELED`	완료 전에 취소된 종료 상태
`TASK_STATE_REJECTED`	에이전트가 수행하지 않기로 한 종료 상태
`TASK_STATE_UNSPECIFIED`	상태를 알 수 없는 경우

메시지(Message)와 아티팩트(Artifact)는 이름이 비슷하지만 맡은 역할이 다릅니다. 메시지는 클라이언트와 에이전트가 주고받는 대화의 한 턴이고, 아티팩트는 태스크가 만들어 낸 결과물입니다. 명세는 결과를 메시지로 전달하지 말고 아티팩트로 돌려주라고 권고하는데, 태스크 기록에 모든 메시지가 보존된다는 보장이 없기 때문입니다. 클라이언트가 스트림에서 끊겼다가 다시 붙으면 중간 상태 메시지를 놓칠 수 있으므로, 명세는 메시지를 신뢰할 수 있는 전달 수단으로 여기지 말라고 명시합니다.

메시지와 아티팩트의 내용은 파트(Part)라는 단위로 채워집니다. 파트는 text, raw(바이트, JSON에서는 base64 문자열), url, data(임의의 구조화된 JSON) 중 정확히 하나만 가져야 하며, 파일 이름과 미디어 타입을 함께 붙일 수 있습니다. 텍스트뿐 아니라 파일과 구조화된 데이터를 같은 틀로 실어 나르는 것이 이 구조의 목적입니다.

여러 태스크와 메시지를 하나의 대화로 묶을 때는 contextId를 씁니다. 태스크 식별자는 서버가 생성하는 반면 contextId는 클라이언트가 제시할 수도 있는데, 서버가 받아들일 수 없으면 오류로 거부해야 하고 임의로 새 값을 만들어서는 안 됩니다. 명세는 서버가 만든 contextId를 클라이언트가 불투명한 식별자로 다루기를 권합니다.

A2A 프로토콜이 태스크 진행 상황을 전달하는 세 가지 방법

오래 걸리는 작업을 다루는 것이 A2A의 설계 전제이므로, 진행 상황을 전달하는 경로도 세 가지가 준비되어 있습니다:

방식	동작	적합한 상황
폴링(Polling)	클라이언트가 주기적으로 태스크 조회를 호출	간단한 연동, 드문 갱신, 방화벽 제약이 큰 클라이언트
스트리밍(Streaming)	이벤트가 발생하는 대로 실시간 전달	대화형 애플리케이션, 실시간 대시보드, 진행률 표시
푸시 알림(Push Notification)	서버가 클라이언트 웹훅으로 HTTP POST 전송	서버 대 서버 연동, 아주 긴 작업, 이벤트 기반 구조

스트리밍은 에이전트 카드의 capabilities.streaming이, 푸시 알림은 capabilities.pushNotifications가 참일 때만 쓸 수 있습니다. 스트리밍으로 전달되는 이벤트는 상태 변화를 알리는 TaskStatusUpdateEvent와 결과물을 실어 나르는 TaskArtifactUpdateEvent 두 종류이며, 명세는 모든 구현이 이벤트를 생성된 순서 그대로 전달해야 하고 전송 과정에서 순서를 바꿔서는 안 된다고 규정합니다. 하나의 태스크에 여러 스트림이 동시에 붙을 수도 있는데, 이때 모든 스트림은 같은 이벤트를 같은 순서로 받아야 하고 한 스트림을 닫아도 나머지는 영향을 받지 않아야 합니다. 네트워크가 끊긴 클라이언트가 새 스트림으로 다시 붙는 상황이 이 규정 덕분에 성립합니다.

한편 푸시 알림은 바인딩과 무관하게 동작한다는 점이 특징입니다. 에이전트가 gRPC로 서비스하고 있더라도 웹훅 호출은 평범한 HTTP와 HTTP 바인딩에 정의된 JSON 페이로드를 씁니다.

A2A 프로토콜 0.3에서 1.0으로 넘어갈 때 깨지는 것

1.0은 이전 버전과 호환되지 않는 변경을 포함하고 있어서, 0.3 시절의 예제 코드나 블로그 글을 그대로 따라 하면 동작하지 않습니다. 명세 부록 A가 이 변경을 정리해 두었고, 실무에서 가장 자주 걸리는 것은 두 가지입니다.

첫째, 다형 객체를 구분하던 kind 필드가 사라졌습니다. 0.3.x에서는 파트와 스트리밍 이벤트가 kind라는 판별자 필드를 안에 넣어 자기 타입을 밝혔는데, 1.0에서는 JSON 멤버 이름 자체가 판별자 역할을 합니다. 텍스트 파트는 {"kind": "text", "text": "..."} 에서 {"text": "..."} 로 바뀌었고, 파일 파트는 중첩된 file 객체 대신 raw 또는 url과 filename, mediaType을 나란히 두는 형태가 되었습니다. 스트리밍 이벤트도 마찬가지여서 {"kind": "status-update", ...} 는 {"statusUpdate": {...}} 로 감싸집니다. Protocol Buffers의 oneof 의미론에 맞추기 위한 변경이라고 명세는 설명합니다.

둘째, 확장 카드 지원 여부를 나타내는 필드가 자리를 옮겼습니다. 최상위에 있던 supportsExtendedAgentCard가 제거되고 capabilities.extendedAgentCard로 들어갔습니다. 스트리밍과 푸시 알림처럼 특정 오퍼레이션을 열어 주는 선택 기능은 모두 capabilities 안에 있으므로 그쪽이 맞다는 판단입니다.

버전 협상 방식도 알아 둘 필요가 있습니다. 클라이언트는 요청마다 A2A-Version 헤더를 보내야 하며, 값은 1.0처럼 주(Major)와 부(Minor) 버전까지만 씁니다. 패치 번호는 호환성에 영향을 주지 않으므로 요청과 응답, 에이전트 카드에 넣지 않습니다. 헤더가 비어 있으면 서버는 0.3으로 해석해야 하고, 지원하지 않는 버전이면 VersionNotSupportedError를 돌려주어야 합니다. 헤더 대신 요청 파라미터로 버전을 보내는 것도 허용됩니다. 하나의 에이전트가 같은 전송 방식에 대해 서로 다른 버전의 인터페이스를 동시에 열어 둘 수도 있습니다.

그리고 이름이 바뀐 요청과 응답 타입들은 별도로 정리되어 있고, 명세는 이 옛 이름들이 0.5.0 이전에는 제거되지 않는다고 밝히고 있습니다:

옛 이름	현재 이름
`MessageSendParams`	`SendMessageRequest`
`SendMessageSuccessResponse`	`SendMessageResponse`
`SendStreamingMessageSuccessResponse`	`StreamResponse`
`SetTaskPushNotificationConfigRequest`	`CreateTaskPushNotificationConfigRequest`
`ListTaskPushNotificationConfigSuccessResponse`	`ListTaskPushNotificationConfigsResponse`
`GetAuthenticatedExtendedCardRequest`	`GetExtendedAgentCardRequest`

JSON 직렬화 규칙도 함께 기억해 두면 좋습니다. proto의 snake_case 필드는 JSON에서 모두 camelCase로 바뀌고(context_id는 contextId), 열거형 값은 ProtoJSON 규칙에 따라 proto에 정의된 이름 그대로, 즉 TASK_STATE_INPUT_REQUIRED나 ROLE_USER 같은 대문자 형태로 직렬화됩니다.

A2A 프로토콜의 확장 기능

핵심 명세를 건드리지 않고 기능을 덧붙이는 통로가 확장(Extension)입니다. 에이전트는 capabilities.extensions에 확장을 선언하고, 각 확장은 자신을 식별하는 URI와 설명, 그리고 필수 여부를 나타내는 required 플래그를 가집니다. 클라이언트는 HTTP 헤더나 gRPC 메타데이터처럼 바인딩별 수단으로 사용할 확장을 밝히고, 확장이 필요로 하는 값은 메시지와 아티팩트의 metadata에 확장 URI를 키로 삼아 넣습니다. 위치 정보나 인용 출처처럼 핵심 프로토콜에 넣기에는 특수한 데이터가 이 자리에 들어갑니다.

확장 URI에는 버전을 포함하는 것이 권고 사항이고, 호환되지 않는 변경에는 새 URI를 만들어야 합니다. 클라이언트가 요청한 확장을 에이전트가 지원하지 않으면 에이전트는 그 확장을 무시하고 진행하되, 카드에 required: true로 선언된 확장이라면 오류를 돌려주어야 합니다. 이때 이전 버전으로 자동 대체해서는 안 된다는 조항도 함께 있습니다.

a2aproject 조직 아래에서 관리되는 확장과 사설 바인딩에는 2단계 승격 절차가 적용됩니다. 누구나 독립적으로 확장을 만들어 배포할 수 있지만, 조직 안으로 들어오려면 먼저 메인테이너의 후원을 받아 experimental-ext-{이름} 저장소에서 시작해야 하고, 공식 단계로 올라가려면 Apache 2.0 라이선스와 최소 하나의 참조 구현을 갖춰야 합니다. 공식 확장은 https://a2a-protocol.org/extensions/ 아래의 URI를, 사설 바인딩은 https://a2a-protocol.org/bindings/ 아래의 URI를 식별자로 받습니다.

A2A 프로토콜의 인증과 작업 중 인가

A2A는 에이전트를 평범한 엔터프라이즈 애플리케이션으로 취급하고 검증된 웹 보안 관행에 기댑니다. 신원 정보는 프로토콜 계층에서 다루고 A2A의 의미론 안에는 두지 않는다는 것이 방침이어서, 로그인이나 토큰 교환을 위한 A2A 메시지 같은 것은 따로 없습니다. 운영 배포는 암호화된 통신을 써야 하고, HTTP 기반 바인딩은 HTTPS를, gRPC는 TLS를 씁니다.

클라이언트가 인증을 거치는 순서는 세 단계입니다. 에이전트 카드의 securitySchemes 필드에서 서버가 요구하는 인증 방식을 확인하고, 그 방식에 맞는 자격 증명을 A2A 바깥의 별도 절차로 얻은 뒤, 바인딩에 맞는 헤더나 메타데이터에 실어 모든 요청마다 보냅니다. 서버 쪽 의무는 더 무겁습니다. 들어오는 모든 요청을 인증해야 하고 모든 오퍼레이션에 인가 검사를 해야 하며, 특히 태스크 목록 조회와 태스크 조회는 인증된 호출자에게 보이는 것만 돌려주어야 합니다. 명세는 클라이언트가 필터를 지정하지 않았더라도 결과를 인가 범위로 좁혀야 하고, 인가 검사가 자원의 존재 여부를 흘릴 수 있는 조회보다 먼저 일어나야 한다고 규정합니다.

A2A에만 있는 장치는 작업 도중에 권한이 필요해지는 경우를 다루는 방식입니다. 에이전트가 외부 API를 부르기 위한 토큰이 필요하거나 되돌릴 수 없는 작업 전에 사람의 승인이 필요할 때, 태스크를 TASK_STATE_AUTH_REQUIRED 상태로 바꾸고 무엇이 필요한지 설명하는 메시지를 붙여 클라이언트에게 책임을 넘길 수 있습니다. 클라이언트가 그 자체로 또 다른 A2A 에이전트라면 자기 태스크도 같은 상태로 바꿔 자신의 클라이언트에게 다시 넘길 수 있어서, 인가 요청이 에이전트 사슬을 따라 거슬러 올라가는 모양이 됩니다.

이 상태에는 명세가 따로 명시해 둔 단서가 둘 있습니다. 하나는 상태 전이 자체를 인가로 여겨서는 안 된다는 것으로, 무엇이 허용되었는지의 범위와 의미는 프로토콜이 정의하지 않고 구현이나 자격 증명 발급자, 확장이 정해야 합니다. 다른 하나는 그렇게 얻은 자격 증명이 같은 태스크의 이후 메시지까지 인가한다고 가정해서는 안 된다는 것으로, 구현이 그렇게 동작한다고 명시적으로 정의한 경우에만 예외입니다. 자격 증명이 대역 외로 전달되면 에이전트가 곧바로 처리를 재개할 수 있어 클라이언트가 그 시점을 모를 수 있으므로, 명세는 태스크 구독이나 웹훅 등록, 폴링 중 하나로 갱신을 놓치지 않게 하라고 권합니다.

A2A 프로토콜은 누구에게 맞는가

여러 팀이 서로 다른 프레임워크로 에이전트를 만들고 있고 그 사이를 잇는 연동 코드가 이미 부담이 된 조직이라면, A2A는 그 부담을 표준 규격으로 옮길 수 있는 선택지입니다. 인증과 권한, 오류 처리, 오래 걸리는 작업의 상태 전달처럼 직접 설계하면 시간이 드는 부분이 명세에 정리되어 있고, 공식 SDK가 여섯 개 언어로 나와 있어 언어가 갈리는 조직에도 적용할 수 있습니다.

반대로 한 팀이 하나의 프레임워크 안에서 에이전트와 하위 에이전트를 구성하고 있다면 A2A를 도입할 이유가 거의 없습니다. 프로토콜 자신이 하위 에이전트 호출과 도구 호출은 A2A의 영역이 아니라고 분명히 해 두었기 때문에, 그 경우에는 프레임워크의 기본 기능이나 MCP를 쓰는 것이 맞습니다. 외부에 공개할 에이전트가 아직 없고 도구 연결만 필요한 단계에서도 마찬가지입니다.

한 가지 더 고려할 점은 시점입니다. 1.0은 0.3과 호환되지 않는 데이터 모델 변경을 담고 있어서, 지금 인터넷에 있는 A2A 예제 중 상당수가 0.3 기준입니다. 새로 시작하는 팀은 1.0 명세와 그에 맞춘 SDK 버전을 기준으로 잡고, 0.3으로 이미 운영 중인 팀은 에이전트 카드의 protocolVersion 선언과 A2A-Version 헤더 처리부터 점검하는 것이 순서입니다.

A2A 프로토콜의 라이선스

A2A 프로토콜은 Apache License 2.0으로 공개되어 있어 개인 및 상업적 목적으로 자유롭게 사용할 수 있습니다. 공식 SDK 저장소들도 같은 라이선스를 따릅니다.

A2A 프로토콜 공식 홈페이지

A2A 프로토콜 명세 문서

A2A 프로토콜 GitHub 저장소

더 읽어보기

이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일로 보내드립니다! 텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로도 새 글 알림을 받으실 수 있습니다.

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~