A2A의 주요 개념¶
Agent2Agent(A2A) 프로토콜은 에이전트가 상호 작용하는 방식을 정의하는 핵심 개념 집합을 기반으로 구축됩니다. 이러한 개념을 이해하는 것은 A2A 호환 시스템을 개발하거나 통합하는 데 매우 중요합니다.
핵심 행위자¶
- 사용자: 에이전트 지원이 필요한 요청이나 목표를 시작하는 최종 사용자(사람 또는 자동화된 서비스)입니다.
- A2A 클라이언트 (클라이언트 에이전트): 사용자를 대신하여 원격 에이전트에게 작업이나 정보를 요청하는 애플리케이션, 서비스 또는 다른 AI 에이전트입니다. 클라이언트는 A2A 프로토콜을 사용하여 통신을 시작합니다.
- A2A 서버 (원격 에이전트): A2A 프로토콜을 구현하는 HTTP 엔드포인트를 노출하는 AI 에이전트 또는 에이전트 시스템입니다. 클라이언트로부터 요청을 받고, 작업을 처리하며, 결과나 상태 업데이트를 반환합니다. 원격 에이전트는 클라이언트 관점에서 "불투명한(opaque)" 시스템으로 작동하므로, 클라이언트는 내부 작동 방식, 메모리 또는 도구를 알 필요가 없습니다.
기본적인 통신 요소¶
-
에이전트 카드 (Agent Card):
- A2A 서버를 설명하는 JSON 메타데이터 문서로, 일반적으로 잘 알려진 URL(예:
/.well-known/agent.json
)에서 찾을 수 있습니다. - 에이전트의 ID(이름, 설명), 서비스 엔드포인트 URL, 버전, 지원되는 A2A 기능(스트리밍 또는 푸시 알림 등), 제공하는 특정 기술, 기본 입출력 양식 및 인증 요구 사항을 자세히 설명합니다.
- 클라이언트는 에이전트 카드를 사용하여 에이전트를 발견하고 안전하고 효과적으로 상호 작용하는 방법을 이해합니다.
- 자세한 내용은 프로토콜 사양: 에이전트 카드를 참조하십시오.
- A2A 서버를 설명하는 JSON 메타데이터 문서로, 일반적으로 잘 알려진 URL(예:
-
작업 (Task):
- 클라이언트가 에이전트에게 메시지를 보내면, 에이전트는 요청을 이행하기 위해 상태를 가진 작업(예: "보고서 생성", "항공편 예약", "질문에 답변")을 완료해야 한다고 판단할 수 있습니다.
- 각 작업은 에이전트가 정의한 고유 ID를 가지며 정의된 라이프사이클(예:
submitted
,working
,input-required
,completed
,failed
)을 통해 진행됩니다. - 작업은 상태를 가지며 클라이언트와 서버 간의 여러 차례의 교환(메시지)을 포함할 수 있습니다.
- 자세한 내용은 프로토콜 사양: 작업 객체를 참조하십시오.
-
메시지 (Message):
- 클라이언트와 에이전트 간의 단일 회차 또는 통신 단위를 나타냅니다.
- 메시지에는
role
(클라이언트가 보낸 메시지의 경우"user"
, 서버가 보낸 메시지의 경우"agent"
)이 있으며 실제 내용을 전달하는 하나 이상의Part
객체를 포함합니다. 메시지 객체의messageId
부분은 메시지 발신자가 설정한 각 메시지에 대한 고유 식별자입니다. - 반드시 공식적인
Artifacts
가 아닌 지침, 컨텍스트, 질문, 답변 또는 상태 업데이트를 전달하는 데 사용됩니다. - 자세한 내용은 프로토콜 사양: 메시지 객체를 참조하십시오.
-
부분 (Part):
Message
또는Artifact
내의 기본적인 내용 단위입니다. 각 부분은 특정type
을 가지며 다음과 같은 다양한 종류의 데이터를 전달할 수 있습니다.TextPart
: 일반 텍스트 내용을 포함합니다.FilePart
: 파일을 나타내며, 인라인 base64 인코딩 바이트로 전송하거나 URI를 통해 참조할 수 있습니다. 파일 이름 및 미디어 유형과 같은 메타데이터를 포함합니다.DataPart
: 양식, 매개변수 또는 기계가 읽을 수 있는 모든 정보에 유용한 구조화된 JSON 데이터를 전달합니다.
- 자세한 내용은 프로토콜 사양: Part Union 타입을 참조하십시오.
-
아티팩트 (Artifact):
- 작업 처리 중에 원격 에이전트가 생성한 유형의 출력 또는 결과를 나타냅니다.
- 예로는 생성된 문서, 이미지, 스프레드시트, 구조화된 데이터 결과 또는 작업의 직접적인 결과인 기타 독립적인 정보 조각이 있습니다.
- 아티팩트는 하나 이상의
Part
객체로 구성되며 점진적으로 스트리밍될 수 있습니다. - 자세한 내용은 프로토콜 사양: 아티팩트 객체를 참조하십시오.
상호 작용 메커니즘¶
-
요청/응답 (폴링):
- 클라이언트는 요청(예:
message/send
RPC 메서드 사용)을 보내고 서버로부터 응답을 받습니다. - 상호 작용에 상태를 가진 장기 실행 작업이 필요한 경우, 서버는 처음에
working
상태로 응답할 수 있습니다. 그러면 클라이언트는 작업이 최종 상태(예:completed
,failed
)에 도달할 때까지 주기적으로tasks/get
을 호출하여 업데이트를 폴링합니다.
- 클라이언트는 요청(예:
-
스트리밍 (서버 전송 이벤트 - SSE):
- 점진적으로 결과를 생성하거나 실시간 진행률 업데이트를 제공하는 작업용입니다.
- 클라이언트는
message/stream
을 사용하여 서버와 상호 작용을 시작합니다. - 서버는 열린 상태로 유지되는 HTTP 연결로 응답하며, 이를 통해 서버 전송 이벤트(SSE) 스트림을 보냅니다.
- 이러한 이벤트는
Task
,Message
, 또는TaskStatusUpdateEvent
(상태 변경용) 또는TaskArtifactUpdateEvent
(새롭거나 업데이트된 아티팩트 청크용)일 수 있습니다. - 이를 위해서는 서버가 에이전트 카드에
streaming
기능을 알려야 합니다. - 스트리밍 및 비동기 작업에 대해 자세히 알아보십시오.
-
푸시 알림:
- 매우 긴 실행 시간이 소요되는 작업이나 지속적인 연결(SSE와 같은) 유지가 비실용적인 시나리오를 위한 것입니다.
- 클라이언트는 작업 시작 시(또는
tasks/pushNotificationConfig/set
호출을 통해) 웹훅 URL을 제공할 수 있습니다. - 작업 상태가 중요하게 변경되면(예: 완료, 실패 또는 입력 필요), 서버는 이 클라이언트 제공 웹훅으로 비동기 알림(HTTP POST 요청)을 보낼 수 있습니다.
- 이를 위해서는 서버가 에이전트 카드에
pushNotifications
기능을 알려야 합니다. - 스트리밍 및 비동기 작업에 대해 자세히 알아보십시오.
기타 중요 개념¶
- 컨텍스트 (
contextId
): 여러 관련Task
객체를 논리적으로 그룹화하는 데 사용할 수 있는 서버 생성 식별자로, 일련의 상호 작용에 걸쳐 컨텍스트를 제공합니다. - 전송 및 형식: A2A 통신은 HTTP(S)를 통해 이루어집니다. JSON-RPC 2.0은 모든 요청 및 응답에 대한 페이로드 형식으로 사용됩니다.
- 인증 및 권한 부여: A2A는 표준 웹 보안 관행에 의존합니다. 인증 요구 사항은 에이전트 카드에 선언되며, 자격 증명(예: OAuth 토큰, API 키)은 일반적으로 A2A 프로토콜 메시지 자체와 별도로 HTTP 헤더를 통해 전달됩니다.
- 엔터프라이즈급 기능에 대해 자세히 알아보십시오.
- 에이전트 발견: 클라이언트가 사용 가능한 A2A 서버 및 해당 기능에 대해 알아보기 위해 에이전트 카드를 찾는 프로세스입니다.
- 에이전트 발견에 대해 자세히 알아보십시오.
- 확장: A2A를 사용하면 에이전트가 AgentCard의 일부로 사용자 지정 프로토콜 확장을 선언할 수 있습니다.
- 자세한 문서는 곧 제공될 예정입니다.
이러한 핵심 구성 요소와 메커니즘을 이해함으로써 개발자는 상호 운용 가능하고 협력적인 AI 에이전트 시스템을 구축하기 위해 A2A를 효과적으로 설계, 구현 및 활용할 수 있습니다.