A2A(Agent2Agent) 프로토콜

1. 개요

정의: A2A(Agent2Agent)는 서로 다른 벤더·프레임워크로 구현된 자율 AI 에이전트들이 상대의 내부 구현을 노출하지 않고도 서로를 발견하고 작업을 위임·협업할 수 있도록 표준화한 개방형 애플리케이션 계층 프로토콜로, 에이전트 메타데이터(Agent Card) 기반의 발견과 Task·Message·Artifact라는 공통 객체 모델 위에서 동작하는 "에이전트를 위한 상호운용 표준"이다.

생성형 AI가 단순한 질의응답을 넘어 여러 전문 에이전트가 협력해 복합 업무를 수행하는 멀티에이전트(Multi-Agent) 체제로 진화하면서, 가장 큰 난제는 모델의 추론 능력이 아니라 이질적인 에이전트들을 어떻게 안전하게 연결할 것인가로 옮겨갔다. 기업 현실에서는 CRM 분석 에이전트는 A사 프레임워크(LangGraph)로, 일정 조율 에이전트는 B사 솔루션으로, 사내 결재 에이전트는 자체 개발로 구축되는 식으로 벤더·런타임·언어가 제각각이다. 이들을 협업시키려면 에이전트 쌍마다 전용 어댑터를 만들어야 했고, 이는 과거 시스템 통합에서 겪었던 N×N 포인트 투 포인트 통합 지옥을 에이전트 세계에서 재현했다.

A2A는 이 문제를 에이전트 간 통신의 공통 규약을 세워 해결한다. 에이전트가 자신을 서술하는 표준 명함(Agent Card)을 공개하면, 다른 에이전트가 이를 읽어 "무엇을 할 수 있는지"를 파악하고 표준 메시지로 작업을 위임한다. 핵심 철학은 불투명성(Opacity)으로, 작업을 위임받은 원격 에이전트는 자신의 내부 추론·프롬프트·사용 도구를 공개하지 않고 오직 작업 상태와 결과물만 교환한다. 이로써 지식재산을 보호하면서도 협업이 가능해져, 에이전트가 서로를 교체 가능한 "서비스"처럼 소비하는 에이전트 간 웹(Web of Agents)의 기반이 된다.

A2A는 2025년 4월 Google이 50여 개 파트너와 함께 공개했고, 2025년 6월 Linux Foundation에 기증되어 특정 벤더에 종속되지 않는 중립 거버넌스로 이관되었다. 등장 배경은 명확하다. 과거 웹 서비스가 SOAP·REST로, 마이크로서비스가 gRPC로 표준화되었듯, 에이전트 생태계도 상호운용 표준 없이는 사일로로 파편화된다는 위기의식이다. A2A의 특징은 첫째 기존 웹 표준 재사용(HTTP·JSON-RPC 2.0·SSE·OpenAPI 인증 스킴)으로 도입 장벽을 낮추고, 둘째 엔터프라이즈급 보안·인증을 1급 요소로 설계하며, 셋째 장기 실행·비동기 작업(며칠 걸리는 작업도 추적 가능)을 네이티브로 지원하고, 넷째 텍스트·이미지·오디오·구조화 데이터를 아우르는 모달리티 중립성을 갖춘다는 점이다.

2. A2A 전체 구조와 핵심 개념

A2A는 작업을 요청하는 클라이언트 에이전트(Client Agent)와 그 요청을 수행하는 원격 에이전트(Remote Agent, A2A Server) 간의 상호작용으로 동작한다. 한 에이전트는 상황에 따라 클라이언트가 되기도 하고 서버가 되기도 한다. 전체 흐름은 "① 발견 → ② 협상 → ③ 작업 수행·추적 → ④ 결과 수신"의 생애주기를 가진다.

graph TB
    subgraph User["사용자 / 오케스트레이터"]
        O["클라이언트 에이전트<br/>(Client Agent)"]
    end
    subgraph RemoteA["원격 에이전트 A (A2A Server)"]
        CardA["Agent Card<br/>(.well-known 공개)"]
        LogicA["내부 추론·도구<br/>(불투명·비공개)"]
    end
    subgraph RemoteB["원격 에이전트 B (A2A Server)"]
        CardB["Agent Card"]
        LogicB["내부 로직"]
    end
    O -->|"1.발견: Agent Card 조회"| CardA
    O -->|"2.작업 위임: Task 생성"| LogicA
    LogicA -->|"3.상태·결과: Task/Artifact"| O
    O -.->|"병렬 위임"| CardB
    O -.-> LogicB
    LogicA -->|"하위 위임"| CardB

가. Agent Card(에이전트 명함) — Agent Card는 A2A 서버가 공개하는 JSON 형식의 메타데이터 문서로, 통상 /.well-known/agent-card.json 경로에 게시된다. 여기에는 에이전트의 이름·버전·설명, 서비스 엔드포인트 URL, 보유 스킬(skills) 목록, 지원 입출력 모달리티, 요구하는 인증 방식(OAuth 2.0·API Key 등), 스트리밍·푸시 지원 여부 같은 능력(capability) 정보가 담긴다.

명함에 선언되는 스킬(skill)은 에이전트가 수행 가능한 능력을 자연어 설명과 함께 구조화한 항목으로, 클라이언트(또는 오케스트레이터 LLM)가 "이 요청을 어느 에이전트에게 보낼지"를 의미 기반으로 라우팅하는 근거가 된다. 즉 Agent Card는 기계가 읽는 API 명세인 동시에, LLM이 추론으로 적합한 협업자를 고르도록 돕는 의미론적 디렉터리 역할을 겸한다.

Agent Card는 단순한 소개가 아니라 상호운용의 출발점이라는 데 본질이 있다. 클라이언트 에이전트는 사람이 식당 간판과 메뉴판을 보고 들어갈지 정하듯, 명함을 읽어 "이 에이전트가 내 작업을 처리할 수 있는지, 어떤 인증이 필요한지"를 런타임에 동적으로 판단한다. 이는 서비스 디렉터리(UDDI)나 OpenAPI 명세가 했던 역할을 에이전트 세계로 옮긴 것으로, 사전에 하드코딩된 연동 없이도 느슨한 결합(loose coupling)과 동적 발견을 가능하게 한다. 예컨대 여행 예약 오케스트레이터가 신규 항공사 에이전트의 명함만 등록하면, 코드 변경 없이 그 에이전트를 협업 후보로 편입할 수 있다.

나. Task(작업) — Task는 A2A가 추적하는 작업의 기본 단위로, 고유 ID를 가지며 submitted → working → input-required → completed/failed/canceled 같은 명시적 상태 기계(state machine)를 따른다. 하나의 Task는 여러 차례의 메시지 교환에 걸쳐 수명을 유지하므로, 몇 초 만에 끝나는 조회부터 며칠이 걸리는 심사·승인까지 동일한 모델로 다룰 수 있다.

Task를 상태를 갖는(stateful) 1급 객체로 승격한 것이 A2A 설계의 핵심 결정이다. 전통적 REST 호출은 요청-응답으로 끝나지만, 에이전트 협업은 본질적으로 장기 실행·비동기이기 때문이다. "경쟁사 재무제표를 분석해 보고서를 작성하라"는 위임은 수 시간이 걸릴 수 있고, 중간에 추가 정보(input-required)를 요구하거나 진행률을 보고해야 한다. Task 상태 기계는 이러한 중단·재개·추적을 표준화해, 클라이언트가 폴링 대신 SSE(Server-Sent Events) 스트리밍이나 푸시 알림(Push Notification)으로 상태 변화를 수신하도록 한다.

다. Message와 Part(메시지와 파트) — Message는 클라이언트와 에이전트가 주고받는 개별 발화(turn)이며, 그 안의 콘텐츠는 Part 단위로 담긴다. Part는 TextPart(텍스트), FilePart(파일·바이너리), DataPart(JSON 등 구조화 데이터)로 구분되어, 하나의 메시지가 여러 모달리티를 혼합해 전달할 수 있다.

또한 Message에는 역할(role) 구분이 있어 사용자 발화와 에이전트 응답을 구별하며, 여러 Part를 하나의 메시지에 묶어 "설명 텍스트 + 첨부 파일 + 구조화 파라미터"를 한 번에 전달할 수 있다. 이는 사람이 이메일에 본문과 첨부를 함께 보내는 것과 유사하다.

Part 추상화가 중요한 이유는 모달리티 협상을 가능하게 하기 때문이다. 어떤 에이전트는 텍스트만, 어떤 에이전트는 이미지·오디오까지 처리하므로, 송신 측은 수신 에이전트의 Agent Card에 선언된 지원 모달리티에 맞춰 Part를 구성한다. 이는 콘텐츠 형식을 하드코딩하지 않고 능력 기반으로 협상하는 설계로, 멀티모달 에이전트 간 협업의 유연성을 확보한다.

라. Artifact(산출물) — Artifact는 Task가 생산한 최종 결과물(보고서 파일, 생성된 이미지, 구조화 데이터 등)로, 대화용 메시지와 분리해 관리된다. 즉 "진행 과정의 대화"(Message)와 "확정된 결과"(Artifact)를 구분함으로써, 클라이언트는 중간 잡담과 무관하게 인도 가능한 산출물만 명확히 수거한다.

이 분리는 멱등성·재사용 측면에서 실무적 함의가 크다. 동일 Task의 Artifact는 식별자로 참조·캐싱·버전 관리할 수 있어, 협업 결과를 감사(audit)하거나 후속 에이전트의 입력으로 재투입하기 용이하다. 예컨대 "시장 조사 에이전트"가 생산한 분석 보고서 Artifact를 "슬라이드 생성 에이전트"의 입력으로 그대로 넘기면, 중간 대화 로그를 다시 파싱할 필요 없이 확정 산출물만 전달되어 에이전트 파이프라인의 결합도가 낮아진다. 이는 데이터 엔지니어링의 "불변 데이터셋(immutable dataset)" 패턴을 에이전트 협업에 적용한 것과 같다.

A2A의 핵심 객체를 표로 정리하면 다음과 같다. 다만 표는 요약일 뿐이며, 각 객체가 왜 분리되었는지는 위 문단의 설명이 본질이다.

개념	역할	특징	비유
Agent Card	에이전트 능력·엔드포인트·인증 공개	동적 발견, `.well-known` 게시	명함·메뉴판
Task	작업 추적 단위(상태 기계)	장기·비동기, 중단·재개	작업 지시서
Message/Part	개별 발화와 멀티모달 콘텐츠	텍스트·파일·데이터 혼합	대화 한 턴
Artifact	최종 산출물	메시지와 분리, 재사용	완성품·납품물

3. 통신 절차와 전송 계층

A2A의 전형적 협업은 아래 순서를 따른다. 특히 발견과 위임이 런타임에 동적으로 일어난다는 점이 사전 연동 방식과의 결정적 차이다.

sequenceDiagram
    participant C as 클라이언트 에이전트
    participant S as 원격 에이전트(A2A Server)
    C->>S: 1. GET /.well-known/agent-card.json (발견)
    S-->>C: Agent Card (스킬·인증·엔드포인트)
    C->>S: 2. 인증 (OAuth2/API Key)
    C->>S: 3. message/send (Task 생성·작업 위임)
    S-->>C: Task(status=working, id)
    loop 스트리밍 진행
        S-->>C: 4. SSE: status-update (진행률/부분결과)
    end
    S-->>C: 5. input-required (추가정보 요청)
    C->>S: 6. message/send (추가 입력)
    S-->>C: 7. Task(status=completed) + Artifact

가. 발견(Discovery) — 클라이언트는 알려진 URL 또는 레지스트리에서 Agent Card를 조회해 상대의 능력과 인증 요건을 파악한다. 능력에 부합하지 않으면 다른 에이전트를 찾는다. 발견이 런타임에 일어난다는 점은 확장성 측면에서 결정적인데, 신규 에이전트를 추가할 때 기존 에이전트의 코드를 고치지 않고 명함만 등록하면 되므로 O(N²)의 연동 부담이 O(N)으로 줄어든다. 대규모 조직에서는 사내 에이전트 카탈로그(레지스트리)를 두어 명함을 중앙 관리하고 접근 정책을 적용하는 것이 일반적 패턴이다.

나. 인증·인가 — A2A는 자체 인증을 새로 만들지 않고 OpenAPI가 쓰는 표준 인증 스킴(OAuth 2.0, OpenID Connect, API Key, mTLS 등)을 재사용한다. 기업의 기존 IAM·게이트웨이 인프라에 자연스럽게 얹힌다는 점이 엔터프라이즈 채택의 핵심 유인이다. 바퀴를 다시 발명하지 않는 이 설계 덕분에, 보안팀은 기존에 검증된 토큰 발급·검증 체계를 그대로 재사용하면서 에이전트 협업에만 범위를 좁힌 scoped token을 발급할 수 있다.

다. 작업 위임과 추적 — 클라이언트는 message/send(또는 스트리밍용 message/stream)로 Task를 생성한다. 짧은 작업은 동기 응답으로, 긴 작업은 SSE 스트리밍으로 진행 상황을, 클라이언트가 오프라인일 수 있는 초장기 작업은 푸시 알림(webhook)으로 완료를 통지받는다.

전송 계층에서 A2A v1.0 규격은 데이터 모델을 Protocol Buffers로 규범적으로 정의하고, 세 가지 바인딩(JSON-RPC 2.0, gRPC, HTTP+JSON/REST)을 제공한다. 이는 성능이 중요한 내부망은 gRPC로, 범용 상호운용은 JSON-RPC/REST로 선택하도록 하는 전송 유연성 설계다. Protocol Buffers를 단일 진실 원천(single source of truth)으로 삼으면, 서로 다른 언어로 구현된 에이전트들이 동일한 스키마에서 생성된 코드를 쓰므로 필드 불일치로 인한 통합 오류가 구조적으로 줄어든다.

실제 적용 사례를 보면, Google은 A2A 발표 당시 Salesforce·SAP·ServiceNow·PayPal 등 50여 개 기업과 함께 공개해 엔터프라이즈 업무 에이전트 간 협업 시나리오(예: 채용 과정에서 지원자 선별 에이전트가 일정 조율·배경 조회 에이전트에 작업을 위임)를 제시했다. 이처럼 A2A는 특정 모델이 아니라 기업 업무 자동화의 연결 조직(connective tissue)을 지향한다.

4. A2A와 MCP의 관계 — 경쟁이 아닌 보완

A2A를 이해할 때 가장 흔한 오해는 MCP(Model Context Protocol)와의 경쟁 관계 설정이다. 실제로 둘은 서로 다른 계층을 표준화하는 보완재다. MCP가 "하나의 에이전트가 자신의 도구·데이터에 어떻게 연결하는가"(수직적·에이전트-투-도구)를 표준화한다면, A2A는 "서로 다른 에이전트들이 어떻게 협업하는가"(수평적·에이전트-투-에이전트)를 표준화한다. 업계의 축약 표현대로 "도구에는 MCP, 에이전트에는 A2A"다.

graph TB
    subgraph AgentX["에이전트 X"]
        LX["추론 코어"]
        LX -->|"MCP"| T1["도구/DB/API"]
    end
    subgraph AgentY["에이전트 Y"]
        LY["추론 코어"]
        LY -->|"MCP"| T2["도구/파일"]
    end
    LX <-->|"A2A (협업·위임)"| LY

양자의 투명성 모델도 대비된다. MCP의 도구 호출은 호출자가 인자·결과를 투명하게 보는 반면, A2A는 원격 에이전트의 내부를 불투명하게 감춘다. 이는 협업 상대의 지식재산과 보안 경계를 지키기 위한 의도적 설계다. 실제 프로덕션 아키텍처는 두 표준을 함께 쓴다. 예를 들어 한 조직의 "출장 정산 에이전트"는 MCP로 자신의 영수증 OCR 도구·회계 DB에 접속하고, 동시에 A2A로 외부 "항공권 조회 에이전트"·"환율 에이전트"에 협업을 위임한다. 아래 비교는 차이가 생기는 근본 이유를 중심으로 정리한 것이다.

구분	A2A	MCP
표준화 대상	에이전트↔에이전트 협업(수평)	에이전트↔도구·데이터 연결(수직)
핵심 객체	Agent Card·Task·Artifact	Tool·Resource·Prompt
투명성	불투명(내부 비공개)	투명(인자·결과 공개)
상호작용	동적 발견·장기 작업·위임	세션 내 도구 호출
주도·거버넌스	Google→Linux Foundation	Anthropic→개방

5. 심화 — 표준화 동향과 보안 과제

A2A는 공개 1년 만에 빠르게 생태계를 넓혔다. 2025년 6월 Linux Foundation 기증으로 중립 거버넌스를 확보했고, 2025년 8월에는 IBM의 ACP(Agent Communication Protocol)가 A2A로 통합되며 경쟁 표준이 수렴했다. 2025년 12월 Linux Foundation은 에이전트 표준을 모으는 AAIF(Agentic AI Foundation)를 출범시켰고 A2A가 그 호스팅 프로젝트로 합류했다. v0.3.0(2025년 중반)을 거쳐 v1.0 안정 규격이 2026년 전후로 발표되며 Protocol Buffers 기반 데이터 모델과 3종 바인딩을 확정했다. 다만 1.0 공표 시점은 자료마다 차이가 있어, 정확한 버전·일자는 공식 규격(a2a-protocol.org)으로 확인할 필요가 있다.

보안 측면에서 A2A는 새로운 공격 표면을 연다는 점이 활발히 연구되고 있다. 첫째, Agent Card 신뢰 문제로, 명함의 능력·신원이 위변조되면 악성 에이전트가 정당한 협업자를 사칭할 수 있어 서명·검증과 레지스트리 신뢰 체계가 요구된다. 둘째, 위임 연쇄(delegation chain)에서 권한이 과도하게 전파되는 혼동된 대리자(confused deputy) 위험으로, 각 위임 단계에 최소권한·범위 토큰(scoped token)을 적용해야 한다. 셋째, 불투명성 자체가 양날의 검이어서 악성 에이전트의 거동을 외부에서 감시하기 어렵다. 학계의 A2A 보안 분석(A2ABreak 등)은 인증·인가 우회, 작업 하이재킹, 프롬프트 인젝션 전파 등을 체계적 위협으로 지적한다. 따라서 실무 적용 시 제로 트러스트 원칙, 에이전트별 신원(SPIFFE 류의 워크로드 아이덴티티), 전 구간 감사 로깅을 병행해야 한다.

6. 고려사항 및 시사점

기술사 관점에서 A2A 도입은 단순 기술 선택이 아니라 에이전트 아키텍처·거버넌스·보안을 아우르는 전략 과제이며, 다음을 함께 고려해야 한다.

적용 전략(점진 도입): 전사 멀티에이전트를 한 번에 세우기보다, 내부적으로는 MCP로 도구 계층을 먼저 표준화한 뒤 조직·벤더 경계를 넘는 협업에만 A2A를 선택적으로 적용하는 2단계 접근이 현실적이다. Agent Card 레지스트리와 명함 서명 체계를 거버넌스의 선결 과제로 둔다.
트레이드오프(불투명성 vs 관측가능성): A2A의 불투명성은 지식재산 보호와 느슨한 결합을 주지만, 디버깅·감사·책임 추적을 어렵게 한다. 작업 ID 기반의 분산 추적(OpenTelemetry 연계)과 Artifact 버전 관리로 관측가능성을 보완해야 한다.
보안·규제(책임 소재): 자율 에이전트가 외부 에이전트에 위임해 발생한 결과의 법적·계약적 책임 귀속이 모호하다. 위임 범위를 토큰·정책으로 제한하고, 금융·의료 등 규제 산업에서는 사람의 승인(human-in-the-loop) 체크포인트를 Task 상태 기계에 명시적으로 설계한다.
표준 성숙도 리스크: A2A는 아직 급속히 진화 중(버전 변동·거버넌스 이관)이므로, 특정 버전에 강결합하지 말고 버전 협상·하위호환을 전제로 어댑터 계층을 두어 전환 비용을 흡수한다.
연계 기술·전망: A2A는 MCP(도구), LangGraph·AutoGen 등 오케스트레이션 프레임워크, 제로 트러스트·IAM과 결합될 때 가치가 극대화된다. 장기적으로는 에이전트가 서비스처럼 거래·발견되는 에이전트 경제(Agent Economy)·에이전트 간 웹의 하부 프로토콜로 자리 잡을 전망이며, 기업은 지금부터 에이전트 신원·명함·위임 정책의 거버넌스 체계를 선제적으로 준비해야 한다.

참고자료

A2A Protocol 공식 사이트 — https://a2a-protocol.org/
Wikipedia, "Agent2Agent" — https://en.wikipedia.org/wiki/Agent2Agent
Tyk, "A2A protocol: Architecture and technical specification" — https://tyk.io/learning-center/a2a-protocol-architecture-and-technical-specification/
Google Open Source Blog, "A year of open collaboration: Celebrating the anniversary of A2A" — https://opensource.googleblog.com/2026/04/a-year-of-open-collaboration-celebrating-the-anniversary-of-a2a.html
Palma.ai, "Agent2Agent (A2A) and MCP: What the Handover Means" — https://palma.ai/blog/A2A-linux-foundation-donation-comparison
A2ABreak: Systematic Security Analysis of the A2A Protocol (arXiv:2609.10871) — https://arxiv.org/pdf/2609.10871

한 줄 요약: A2A는 이질적 AI 에이전트들이 Agent Card 기반 동적 발견과 Task·Message·Artifact 공통 모델로 내부를 감춘 채 작업을 위임·협업하게 하는 개방형 상호운용 프로토콜로, "도구에는 MCP, 에이전트에는 A2A"처럼 MCP와 보완 관계를 이루며, 성공적 도입은 명함 신뢰·위임 권한·관측가능성 등 보안·거버넌스 설계에 달려 있다.