A2A Protocol이란? AI Agent 간 협업을 위한 공통 언어

1. A2A Protocol이란?

A2A는 Agent2Agent Protocol의 약자로, 서로 독립적으로 구현된 AI Agent들이 표준화된 방법으로 통신하고 협업할 수 있도록 만든 개방형 프로토콜이다.

Agent마다 사용한 언어, 프레임워크, 모델, 실행 환경이 다르더라도 A2A 규칙을 지원하면 상대 Agent의 내부 구현을 알지 못한 채 메시지를 보내고 작업을 위임할 수 있다.

          REST API가 서비스와 서비스 간 통신 방식을 정리했다면,
          A2A는 Agent가 다른 Agent를 발견하고 협업하는 방식을
          표준화한다고 이해할 수 있다.
        

다만 A2A는 HTTP를 대체하는 새로운 네트워크 기술이라기보다, HTTP, JSON, 스트리밍과 같은 기존 웹 기술 위에서 Agent 간 상호작용 모델을 정의하는 프로토콜에 가깝다.

2. 왜 A2A가 필요할까?

초기의 LLM 애플리케이션은 하나의 모델이 API, 데이터베이스, 검색 도구를 직접 호출하는 구조가 많았다.

사용자 요청 전달

↓

단일 Agent 판단 및 도구 호출

↓

검색

데이터베이스

외부 API

하지만 업무가 복잡해지면서 하나의 Agent가 모든 책임을 갖는 방식에는 한계가 생겼다. 최근에는 각 Agent가 특정 전문 영역을 담당하고, 여러 Agent가 협력하여 하나의 목표를 수행하는 멀티 Agent 구조가 사용되고 있다.

사용자 요청

↓

Planner Agent 작업 분해 및 위임

↓

전문 Agent에게 작업 위임

Search Agent LangGraph

Data Agent CrewAI

Report Agent 직접 구현

서로 다른 프로그래밍 언어로 개발될 수 있다.
LangGraph, CrewAI, ADK 등 서로 다른 프레임워크를 사용할 수 있다.
각자 다른 API 요청과 응답 형식을 사용할 수 있다.
작업 상태와 오류를 표현하는 방식도 다를 수 있다.
다른 Agent가 어떤 일을 할 수 있는지 알기 어렵다.

if agent_type == "weather":
    call_weather_api()

elif agent_type == "search":
    call_search_api()

elif agent_type == "report":
    call_report_api()

Agent가 추가될 때마다 조건과 전용 API 연동이 늘어난다면 시스템은 빠르게 복잡해진다. A2A는 이러한 연결 방식을 공통 규칙으로 정리하려는 시도다.

3. 제1원칙으로 다시 보는 A2A

같은 프레임워크여야 한다

물리적인 제약이 아니다. 통신 규격만 일치하면 Agent 내부의 프레임워크는 서로 달라도 된다.

상대의 내부 로직을 알아야 한다

반드시 그렇지 않다. 외부에는 제공 가능한 능력과 입출력 규칙만 공개하면 된다.

작업은 즉시 응답해야 한다

보고서 생성이나 예약 처리처럼 오래 걸리는 작업도 있으므로 상태를 가진 비동기 작업 모델이 필요하다.

모든 Agent API를 미리 알아야 한다

Agent가 자신의 능력을 기계가 읽을 수 있는 형태로 공개하면, Client Agent가 적합한 협업 대상을 찾을 수 있다.

A2A의 본질
Agent의 내부 구현을 통일하는 것이 아니라, 서로 다른 Agent들이 협업하는 외부 경계의 규칙을 통일하는 것이다.

4. A2A의 기본 참여자

A2A Client

다른 Agent에게 메시지를 보내거나 작업을 요청하는 쪽이다. Planner 또는 Supervisor Agent가 Client 역할을 맡을 수 있다.

A2A Server

자신의 능력을 외부에 공개하고, Client가 전달한 요청을 처리하는 Remote Agent다.

5. A2A 핵심 개념

5.1 Agent Card

Agent Card는 Agent가 자신의 정보와 능력을 외부에 설명하기 위한 메타데이터 문서다.

{
  "name": "Weather Analysis Agent",
  "description": "지역별 현재 날씨와 예보를 분석합니다.",
  "url": "https://agent.example.com/a2a",
  "version": "1.0.0",
  "capabilities": {
    "streaming": true
  },
  "skills": [
    {
      "id": "weather-forecast",
      "name": "날씨 예보 조회",
      "description": "지역과 날짜를 기준으로 날씨를 조회합니다.",
      "tags": ["weather", "forecast"]
    }
  ]
}

5.2 Skill

Skill은 해당 Agent가 제공할 수 있는 구체적인 능력을 의미한다.

현재 날씨 조회
주간 예보 조회
강수 가능성 분석
날씨 기반 외출 추천

5.3 Message

Message는 Agent 간 대화의 기본 단위다. 텍스트뿐만 아니라 파일, 구조화된 데이터 등도 포함할 수 있다.

{
  "role": "user",
  "parts": [
    {
      "kind": "text",
      "text": "서울의 이번 주말 날씨를 분석해 줘."
    }
  ]
}

5.4 Task

Task는 상태를 가지고 추적할 필요가 있는 작업 단위다.

{
  "id": "task-20260710-001",
  "contextId": "weather-context-001",
  "status": {
    "state": "working"
  },
  "artifacts": []
}

5.5 Task Status

상태 예시	의미
`submitted`	작업이 제출된 상태
`working`	Agent가 작업을 수행 중인 상태
`input-required`	추가 정보가 필요한 상태
`auth-required`	추가 인증이 필요한 상태
`completed`	작업이 완료된 상태
`failed`	작업 처리에 실패한 상태
`canceled`	작업이 취소된 상태

5.6 Artifact

Artifact는 Task를 처리하면서 Agent가 생성한 결과물이다.

{
  "artifactId": "artifact-weather-report",
  "name": "주말 날씨 분석 보고서",
  "parts": [
    {
      "kind": "text",
      "text": "토요일은 흐리고 일요일 오후에는 비가 예상됩니다."
    }
  ]
}

Message는 Agent 간 대화나 요청을 표현하고, Artifact는 Task 수행으로 생성된 결과물을 표현한다.

6. 전체 동작 흐름

사용자 요청 수신 “이번 주말 야외 활동이 가능한지 알려줘.”

Agent 검색 및 능력 확인 Planner가 Agent Card를 읽어 Weather Skill을 확인한다.

Message 전송 지역과 날짜가 포함된 요청 메시지를 전달한다.

Task 생성 Weather Agent가 상태 추적이 필요한 작업으로 판단한다.

진행 상태 전달 submitted, working 등의 상태를 Client에 전달한다.

Artifact 생성 주말 날씨와 외출 추천이 포함된 결과물을 생성한다.

최종 응답 구성 Planner가 결과를 사용자에게 이해하기 쉬운 형태로 전달한다.

7. 일반 REST API와 무엇이 다를까?

구분	일반 REST API	A2A Protocol
주요 대상	서비스와 서비스	Agent와 Agent
요청 성격	정의된 기능 호출	목표 또는 작업 위임
능력 탐색	API 문서를 사람이 확인	Agent Card와 Skill을 기계가 확인
작업 모델	요청과 응답 중심	상태를 가진 장기 실행 Task 지원
결과 표현	서비스별 응답 DTO	Message와 Artifact

8. MCP와 A2A의 차이

MCP

Agent 또는 LLM 애플리케이션이 외부의 Tool, 데이터, 리소스를 사용하는 방식을 표준화한다.

Agent ↔ Tool

A2A

독립적인 Agent들이 서로를 발견하고, 메시지와 작업을 주고받는 방식을 표준화한다.

Agent ↔ Agent

Planner Agent

↓

A2A

↓

Weather Agent

↓

MCP

↓

Weather API / DB

          MCP와 A2A는 경쟁 관계라기보다 서로 다른 경계를 담당하는
          상호 보완적인 프로토콜이다.
        

9. LangGraph 구조에 적용하면

Supervisor Agent LangGraph

↓

A2A

Search Agent LangGraph

Weather Agent Google ADK

Report Agent CrewAI

구분 기준
같은 프로세스 안에서 State와 실행 흐름을 공유한다면 LangGraph Node에 가깝다. 독립적으로 배포되고 자체 판단과 도구를 가진 실행 주체라면 A2A Agent로 분리하는 방안을 고려할 수 있다.

10. 모든 Node를 Agent로 분리해야 할까?

독립적인 목표와 책임 범위를 가진다.
자체 모델, 메모리 또는 Tool을 사용한다.
다른 서비스에서도 재사용할 필요가 있다.
독립적인 배포와 확장이 필요하다.
처리 시간이 길어 상태 추적이 필요하다.
다른 조직이나 외부 업체가 운영한다.

모든 기능을 Agent로 분리하면 네트워크 지연, 인증과 권한 관리, 장애 지점, 관측성, 비용 및 디버깅 난도가 함께 증가한다.

11. 실무 적용 시 고려할 점

보안과 신뢰

인증, 인가, 암호화, 네트워크 접근 정책을 함께 설계해야 한다.

Task 멱등성

동일한 요청이 재전송되어도 결제나 예약이 중복 실행되지 않도록 해야 한다.

Timeout과 취소

Timeout, Task 취소, 재시도, 보상 트랜잭션 정책이 필요하다.

관측성

Task ID와 Context ID를 기준으로 로그, 메트릭, Trace를 연결해야 한다.

권한 범위

작업별 최소 권한과 사용자 승인을 적용해야 한다.

12. 정리

A2A의 핵심은 협업 경계의 표준화다.

A2A Protocol은 서로 다른 환경에서 동작하는 AI Agent가 상대방의 내부 구현을 알지 못하더라도 능력을 확인하고, 메시지를 교환하며, 상태를 가진 작업과 결과물을 주고받을 수 있도록 한다.

Agent Card는 Agent의 능력을 설명하고, Message는 대화를 전달하며, Task는 상태를 가진 작업을 관리하고, Artifact는 작업 결과물을 표현한다.

MCP가 Agent와 Tool 사이의 연결을 담당한다면, A2A는 Agent와 Agent 사이의 연결을 담당한다.

          REST API가 서비스의 기능을 호출하는 규칙이라면,
          A2A는 자율적인 Agent에게 목표를 맡기고 협업하는 규칙이다.
        