A2A 프로토콜이란 무엇인가? 에이전트 카드와 작업 설명

A2A는 에이전트를 네트워크 피어(network peers)로 전환합니다.

Page content

A2A 프로토콜(에이전트 투 에이전트 프로토콜)은 독립적인 AI 에이전트 시스템 간의 통신을 위한 개방형 표준입니다.

이 문장은 단순해 보이지만, 대부분의 AI 에이전트 데모에서 완전히 생략되는 중요한 의미를 내포하고 있습니다. 대부분의 데모는 여전히 단일 어시스턴트, 단일 런타임, 단일 도구 루프, 그리고 단일 소유주를 가정합니다. 즉, 에이전트가 검색을 수행하고 도구를 호출하며 코드를 작성하고 API를 쿼리하며, 아마도 MCP 서버를 사용하여 답변을 반환할 수 있다는 것입니다.

A2A Protocol — Agent Cards, Tasks, and Artifacts connecting independent AI agents

A2A는 서로 다른 팀, 프레임워크, 벤더, 언어, 또는 조직에 의해 구축된 에이전트들이 존재하는 다른 세상을 위해 설계되었습니다. 이는 하나의 에이전트가 다른 에이전트를 발견하고, 그 에이전트의 기능을 이해하며, 작업을 보내고, 메시지를 교환하고, 파일이나 구조화된 출력을 받으며, 작업 완료까지 추적해야 한다는 것을 가정합니다. 따라서 A2A는 또 다른 도구 호출 형식이 아니라, AI 에이전트들을 동등한 피어(peer)로서 상호운용 가능하게 만드는 진정한 시도입니다.

주요 개념은 다음과 같습니다:

  • 에이전트 카드(Agent Cards)
  • 에이전트와 클라이언트
  • 작업(Tasks)
  • 메시지(Messages)
  • 부분(Parts)
  • 아티팩트(Artifacts)
  • 작업 상태(Task states)
  • 스트리밍 및 비동기 업데이트

이 기사는 이러한 개념을 평범한 엔지니어링 용어로 설명하며, 실제 다중 에이전트 시스템에서 A2A가 어디에 위치하는지 이해할 수 있는 충분한 세부 정보를 제공합니다.

짧은 정의

A2A는 에이전트 간 통신을 위한 프로토콜입니다.

이 프로토콜을 통해 하나의 에이전트나 클라이언트는 공통 모델을 통해 다른 에이전트와 통신할 수 있습니다. 수신 에이전트는 자신의 기능을 설명하고, 작업을 수락하며, 해당 작업의 라이프사이클을 관리하고, 추가 입력을 요청하며, 진행 상황을 스트리밍하고, 구체적인 출력을 반환할 수 있습니다.

여기서의 핵심은 에이전트가 내부적으로 어떻게 사고하는지를 표준화하는 것이 아닙니다. 이는 에이전트들이 경계(boundary)에서 어떻게 대화하는지를 표준화하는 것입니다.

A2A 에이전트는 내부적으로 다음을 사용할 수 있습니다:

  • Python
  • Go
  • JavaScript
  • LangGraph
  • CrewAI
  • Semantic Kernel
  • 사용자 정의 코드
  • MCP 서버
  • 사설 API
  • 벡터 데이터베이스
  • 워크플로우 엔진

호출자(caller)는 이 중 어느 것도 알 필요가 없습니다. 호출자가 알아야 할 것은 다음과 같습니다:

  • 이 에이전트는 무엇을 할 수 있는가?
  • 어떻게 대화해야 하는가?
  • 어떤 입력을 받아들이는가?
  • 어떤 출력을 생성할 수 있는가?
  • 작업을 어떻게 추적하는가?
  • 결과를 어떻게 받는가?

이 여섯 가지 질문이 독립적으로 운영되는 에이전트들 사이에서 A2A가 확립하려는 프로토콜 경계를 정의합니다.

왜 A2A가 존재하는가

AI 시스템은 단일 어시스턴트에서 전문가 에이전트의 네트워크로 이동하고 있습니다.

한 회사는 다음과 같은 에이전트를 가질 수 있습니다:

  • 지원 에이전트
  • 청구 에이전트
  • 법적 검토 에이전트
  • DevOps 에이전트
  • 데이터 분석 에이전트
  • 연구 에이전트
  • 문서화 에이전트
  • 코드 검토 에이전트

각 에이전트는 고유한 도구, 권한, 도메인 지식, 프롬프트, 메모리, 검색 시스템, 및 감사 규칙을 가질 수 있습니다.

공유 프로토콜이 없으면 모든 통합은 맞춤형이 됩니다. 지원 에이전트는 청구 에이전트에 대한 맞춤 배선(bespoke wiring)이 필요하고, 청구 에이전트는 법적 에이전트에 대한 자체 배선이 필요하며, 연구 에이전트는 문서화 에이전트에 대한 또 다른 배선이 필요합니다. 에이전트 네트워크가 성장함에 따라 이러한 조합적 오버헤드는 잘 확장되지 않습니다.

A2A는 이러한 에이전트들에게 상호 작용할 수 있는 공통된 방법을 제공하여 N×M 통합 문제를 단일 공유 계약으로 줄입니다. 여기서 약속되는 것은 마법 같은 자율성이 아니라 상호운용성입니다.

A2A는 MCP가 아닙니다

A2A는 종종 MCP와 비교되지만, 이 둘은 다른 문제를 해결합니다.

MCP(모델 컨텍스트 프로토콜)는 주로 AI 앱이나 에이전트를 도구, 리소스, 프롬프트에 연결하는 데 관한 반면, A2A는 주로 에이전트를 다른 에이전트에 연결하는 데 관한 것입니다.

유용한 정신 모델은 다음과 같습니다:

MCP: 에이전트에서 도구로
A2A: 에이전트에서 에이전트로

예를 들어, 에이전트는 MCP를 사용하여 다음에 접근할 수 있습니다:

  • GitHub
  • 파일시스템
  • 데이터베이스
  • Slack
  • 문서 검색 시스템
  • 클라우드 API

이러한 MCP 서버를 구축하는 실용적인 가이드는 Go와 Python에 제공됩니다.

동일한 에이전트는 A2A를 사용하여 작업을 다음에 위임할 수 있습니다:

  • 보안 검토 에이전트
  • 연구 에이전트
  • 계획 에이전트
  • 규정 준수 에이전트
  • 코딩 에이전트

이 두 프로토콜은 함께 작동할 수 있으며, 실제로 종종 함께 사용됩니다. 깨끗한 아키텍처는 종종 다음과 같습니다:

에이전트 경계 외부: A2A
에이전트 경계 내부: MCP

이는 다른 에이전트들이 A2A를 사용하여 당신의 에이전트와 통신한다는 의미이며, 당신의 에이전트는 내부적으로 도구에 접근하기 위해 MCP를 사용합니다. 이는 내부의 변화에 관계없이 외부 인터페이스를 안정적으로 유지하는 관심사의 분리입니다. 두 프로토콜이 어떻게 아키텍처 책임을 나누고 실제로 둘 다 필요한 시기에 대한 자세한 비교는 A2A vs MCP: Do AI Agents Really Need Both Protocols?을 참조하십시오.

A2A의 핵심 역할

A2A는 기능을 노출하는 에이전트와 이를 사용하려는 클라이언트라는 두 당사자를 중심으로 구축된 간단한 역할 모델을 사용합니다.

클라이언트는 다음과 같을 수 있습니다:

  • 다른 에이전트
  • 오케스트레이터(Orchestrator)
  • 어시스턴트 애플리케이션
  • 워크플로우 시스템
  • 게이트웨이
  • 테스트 하네스
  • 인간 대상 앱

에이전트는 다음과 같을 수 있습니다:

  • 전문가 AI 서비스
  • 도메인 어시스턴트
  • 워크플로우 소유 에이전트
  • 원격 벤더 에이전트
  • 내부 엔터프라이즈 에이전트

중요한 점은 에이전트가 단순한 함수가 아니라는 것입니다. 에이전트는 특정 기능을 소유하고 이를 에이전트 인터페이스를 통해 노출합니다.

에이전트 카드(Agent Cards)

에이전트 카드는 A2A에서 가장 중요한 개념 중 하나입니다.

에이전트 카드는 에이전트를 설명합니다. 이는 에이전트가 무엇인지, 무엇을 할 수 있는지, 어떻게 통신해야 하는지, 그리고 어떤 제약이 적용되는지를 클라이언트에 알려주는 발견 문서(discovery document)입니다.

에이전트 카드를 다음과 같은 것들의 혼합으로 생각할 수 있습니다:

  • 서비스 메타데이터
  • 기능 선언
  • API 발견 문서
  • 에이전트 프로필
  • 계약 표면(contract surface)

일반적인 에이전트 카드는 다음과 같은 것들을 설명할 수 있습니다:

  • 에이전트 이름
  • 설명
  • 서비스 엔드포인트
  • 지원되는 프로토콜 기능
  • 지원되는 입력 및 출력 모드
  • 사용 가능한 스킬
  • 인증 요구사항
  • 제공자 정보
  • 버전 정보
  • 문서 링크
  • 선택적 메타데이터

에이전트 카드는 중요합니다. 에이전트들은 다른 모든 에이전트에 대한 하드코딩된 지식을 가질 필요가 없어야 하기 때문입니다.

클라이언트는 카드를 검사하여 다음과 같은 결정을 내릴 수 있습니다:

  • 이것이 작업에 적합한 에이전트인가?
  • 필요한 콘텐츠 유형을 지원하는가?
  • 스트리밍을 지원하는가?
  • 인증이 필요한가?
  • 어떤 스킬을 광고하는가?
  • 필요한 유형의 아티팩트를 반환할 수 있는가?

실용적인 시스템에서 에이전트 카드는 에이전트 레지스트리, 개발자 포털, 내부 에이전트 카탈로그의 기초가 됩니다. 이는 클라이언트가 통합에 커밋하기 전에 사용 가능한 것을 조회할 수 있는 서비스 디렉토리의 기계 판독형 equivalent입니다.

에이전트 카드는 기능 경계입니다

에이전트 카드는 마케팅 텍스트로 취급해서는 안 됩니다. 이는 다른 시스템이 런타임에 의존하는 기능 경계(capability boundary)입니다.

에이전트 카드에서 당신의 에이전트가 재무 분석을 수행할 수 있다고 하면, 클라이언트들은 재무 분석 작업을 그 에이전트에 위임하기 시작할 것입니다. 에이전트가 파일을 받는다고 하면, 클라이언트들은 파일을 보낼 것입니다. 에이전트가 스트리밍을 지원한다고 하면, 클라이언트들은 진행 이벤트(progress events)를 기대할 것입니다.

나쁜 에이전트 카드는 나쁜 시스템을 만듭니다. 라우팅 결정과 기능 가정은 전체 에이전트 네트워크를 통해 연쇄적으로 퍼지기 때문입니다. 유용한 에이전트 카드는 다음과 같아야 합니다:

  • 구체적임
  • 정확함
  • 안정적임
  • 버전 관리됨
  • 보안에 대한 인식이 있음
  • 한계에 대해 솔직함

“비즈니스 작업을 수행함"과 같은 모호한 스킬은 도움이 되지 않습니다.

더 나은 스킬은 다음과 같습니다:

SaaS 송장 데이터를 분석하고 월별 지출 요약을 생성합니다.

더 나아가서 예상되는 입력 및 출력 모드도 포함하십시오.

입력: CSV 또는 JSON 송장 기록.
출력: Markdown 요약 및 구조화된 JSON 합계.

에이전트 카드가 더 정확할수록, 다른 에이전트들이 작업을 올바르게 라우팅하기가 더 쉬워집니다.

에이전트 발견(Agent Discovery)

에이전트 발견은 에이전트 카드를 찾는 과정입니다.

간단한 배포에서는 발견이 정적일 수 있습니다. 클라이언트는 이미 특정 에이전트의 URL을 알고 있습니다.

더 큰 배포에서는 다음과 같은 것이 포함될 수 있습니다:

  • 레지스트리
  • 개발자 포털
  • 내부 카탈로그
  • DNS 기반 발견
  • 구성 관리
  • 환경별 라우팅
  • 테넌트 인식 게이트웨이

중요한 설계 선택은 발견이 공개적인지, 사적인지, 또는 권한 기반인지 여부입니다.

모든 에이전트가 모든 사람에게 발견될 수 있는 것은 아닙니다. 내부 급여 에이전트는 모든 호출자에게 동일한 에이전트 카드를 노출해서는 안 되며, 파트너 에이전트는 파트너에게 안전한 스킬만 볼 수 있습니다. 에이전트 발견은 단순한 편의 기능이 아닙니다. 이는 보안 및 거버넌스 모델의 일부이며, 가시성 범위를 지정하는 것은 1차적인 설계 결정입니다.

작업(Tasks)

작업(Task)은 에이전트에 의해 수행 중인 작업을 나타냅니다.

여기서 A2A는 단순한 요청-응답 API보다 더 흥미로워집니다.

일부 에이전트 상호작용은 빠릅니다. 클라이언트가 메시지를 보내고, 에이전트가 직접적인 응답을 반환합니다.

그러나 많은 실제 에이전트 워크플로우는 즉시 완료되지 않습니다.

작업은 다음을 포함할 수 있습니다:

  • 여러 소스 검색
  • 명확화 요청
  • 도구 호출
  • 작업 위임
  • 승인 대기
  • 보고서 생성
  • 파일 생성
  • 진행 상황 스트리밍
  • 재시도 처리
  • 여러 아티팩트 반환

A2A는 이러한 작업을 작업(Task)으로 모델링합니다. 작업에 정체성과 라이프사이클을 부여하는 것은 장기 실행 에이전트 작업이 추적, 검사, 그리고 잠재적으로 취소 또는 재시도되어야 하기 때문에 중요합니다.

작업 라이프사이클(Task Lifecycle)

작업은 다양한 상태로 이동할 수 있습니다.

정확한 상태 모델은 프로토콜 버전 및 구현에 따라 다르지만, 기본 아이디어는 직관적입니다:

  • 제출됨(submitted)
  • 처리 중(working)
  • 입력 필요(input required)
  • 완료됨(completed)
  • 실패함(failed)
  • 취소됨(canceled)
  • 거부됨(rejected)

중요한 점은 작업이 단순한 응답 페이로드가 아니라는 것입니다. 이는 클라이언트가 언제든지 쿼리할 수 있는 자체 상태를 가진 지속적인 작업 단위입니다. 클라이언트는 작업 상태를 사용하여 현재 상황을 파악할 수 있습니다:

  • 에이전트가 작업을 수락했는가?
  • 아직 작업 중인가?
  • 추가 입력이 필요한가?
  • 성공적으로 완료했는가?
  • 실패했는가?
  • 취소되었는가?
  • 사용 가능한 아티팩트가 있는가?

이는 몇 초, 몇 분, 또는 더 오래 걸리는 워크플로우에 특히 유용합니다.

예를 들어, 연구 에이전트는 즉시 작업을 반환한 다음, 백그라운드에서 작업을 계속하면서 진행 상황 이벤트를 스트리밍하거나 결과를 나중에 사용할 수 있게 할 수 있습니다.

상태 없는 메시지 또는 상태 있는 작업

A2A는 단순하고 복잡한 상호작용 모두를 지원합니다.

단순한 상호작용의 경우, 에이전트는 직접적인 메시지(Message)를 반환할 수 있으며, 복잡한 상호작용의 경우 작업(Task)을 반환할 수 있습니다. 이 구별은 모든 것이 작업 추적을 필요로 하는 것이 아니며, 짧은 상호작용을 전체 작업 워크플로우로 과대설계하면 불필요한 오버헤드가 추가되기 때문에 중요합니다.

클라이언트가 다음과 같이 요청하면:

이 단락을 요약해 줘.

직접적인 응답이면 충분할 수 있습니다.

클라이언트가 다음과 같이 요청하면:

상위 5개 오픈소스 벡터 데이터베이스를 연구하고, 비교하며, 마이그레이션 권장 사항을 작성해 줘.

작업이 더 적합합니다.

실용적인 규칙은 간단합니다: 단순하고 즉각적인 상호작용에는 직접적인 메시지를 사용하고, 장기 실행, 상태 유지, 감사 가능, 또는 아티팩트를 생성하는 작업에는 작업을 사용하십시오.

메시지(Messages)

메시지는 클라이언트와 에이전트 간에 교환되는 통신 단위입니다.

메시지는 하나 이상의 부분(Parts)을 포함할 수 있습니다.

메시지는 다음을 나타낼 수 있습니다:

  • 사용자 요청
  • 에이전트 응답
  • 명확화 질문
  • 추가 입력
  • 작업 관련 통신
  • 진행 상황 컨텍스트
  • 구조화된 지시사항

메시지는 단순히 문자열이 아닙니다. 에이전트 통신은 종종 평문보다 훨씬 더 많은 것을 전달해야 하며, 메시지 구조는 이를 수용하도록 설계되었습니다.

메시지는 다음을 포함할 수 있습니다:

  • 텍스트
  • 파일
  • 구조화된 JSON
  • 이미지
  • 참조
  • 메타데이터

메시지는 봉투(envelope)이며, 부분은 그 안에 있는 실제 타입화된 콘텐츠입니다.

부분(Parts)

부분(Part)은 메시지 또는 아티팩트 내부의 콘텐츠 조각입니다.

이것이 A2A가 다중 모드 및 구조화된 통신을 지원하는 방법입니다.

부분은 다음과 같은 다양한 콘텐츠 유형을 포함할 수 있습니다:

  • 텍스트
  • 파일 데이터
  • 구조화된 데이터
  • 참조에 의한 바이너리 콘텐츠
  • JSON 유사 데이터

부분은 다음과 같은 메타데이터도 포함할 수 있습니다:

  • 미디어 타입
  • 파일명
  • 추가 컨텍스트

미디어 타입은 수신 에이전트가 콘텐츠를 어떻게 해석해야 하는지 알려주기 때문에 중요합니다.

예를 들어:

text/plain
application/json
text/markdown
image/png
application/pdf
text/csv

이는 A2A의 과소평가된 부분 중 하나입니다. 에이전트 통신은 모든 것을 평문으로 축소해서는 안 됩니다. 하위 에이전트가 스프레드시트, 이미지, JSON 페이로드, 로그 파일, 또는 PDF가 필요하다면, 프로토콜은 이를 단락으로 왜곡하는 대신 콘텐츠로서 보존해야 합니다. 좋은 에이전트 시스템은 각 부분이 자연스러운 미디어 타입을 최종 소비자까지 전달함으로써 이러한 불필요한 텍스트 병목 현상을 피합니다.

아티팩트(Artifacts)

아티팩트는 에이전트가 작업 처리 중에 생성하는 구체적인 출력물입니다.

이는 일반적인 메시지와 다릅니다. 메시지는 에이전트 간의 통신인 반면, 아티팩트는 작업이 생성한 구체적인 결과물입니다.

아티팩트의 예는 다음과 같습니다:

  • Markdown 보고서
  • JSON 분석 결과
  • CSV 내보내기
  • 생성된 이미지
  • PDF 문서
  • 코드 패치
  • 테스트 결과 파일
  • 배포 계획
  • 다이어그램
  • 데이터 추출물

이 구별은 실용적입니다. 연구 에이전트가 “답을 찾았습니다"라고 말할 때, 그것은 메시지입니다. market-analysis.md, sources.json, 그리고 risk-summary.csv를 반환할 때, 그것은 아티팩트입니다 — 작업의 작업이 검사 가능, 재사용 가능, 조합 가능하게 만드는 구체적인 출력물입니다. 하나의 에이전트의 아티팩트는 구조 손실 없이 다른 에이전트의 입력이 됩니다.

메시지 vs 아티팩트

간단하게 생각하면 다음과 같습니다:

메시지는 대화입니다.
아티팩트는 출력물입니다.

메시지는 에이전트들이 조정하는 데 도움이 되며, 아티팩트는 작업이 실제로 생성한 것입니다.

예를 들어, 소프트웨어 개발 워크플로우에서:

  • 클라이언트는 버그 수정을 요청하는 메시지를 보냅니다.
  • 코딩 에이전트는 명확화 질문과 함께 메시지를 보냅니다.
  • 코딩 에이전트는 작업을 수행합니다.
  • 에이전트는 패치 파일, 테스트 출력, 설명과 같은 아티팩트를 반환합니다.

이 분리는 작업 조정과 결과물을 혼합하는 것을 피하여 로깅, 감사, 그리고 하위 소비자에게 출력을 전달하기 훨씬 easier하게 만듭니다.

실용적인 예제

주요 어시스턴트가 문서화 에이전트의 도움이 필요하다고 상상해 보십시오.

사용자가 다음과 같이 요청합니다:

새 결제 웹훅 API에 대한 개발자 문서를 작성해 줘.

주요 어시스턴트는 에이전트 레지스트리를 확인하여 문서화 에이전트를 찾습니다.

문서화 에이전트의 에이전트 카드는 다음과 할 수 있다고 말합니다:

  • API 문서 작성
  • OpenAPI 스펙 수락
  • Markdown 스타일 가이드 수락
  • Markdown 문서 생성
  • Python 및 JavaScript 예제 생성
  • 장기 실행 작업 지원
  • 아티팩트 반환

주요 어시스턴트는 다음과 함께 메시지를 보냅니다:

  • 간단한 지시사항
  • OpenAPI 파일
  • 스타일 가이드
  • 대상 독자에 대한 메타데이터

문서화 에이전트는 작업을 생성합니다.

작업은 처리 중 상태로 진입합니다.

문서화 에이전트는 다음과 같은 메시지를 보낼 수 있습니다:

엔드포인트 설명을 추출하고 있습니다.

그런 다음:

인증 예제에 대한 명확화가 필요합니다.

주요 어시스턴트는 누락된 입력을 제공합니다.

작업이 계속됩니다.

마침내, 문서화 에이전트는 아티팩트를 반환합니다:

billing-webhooks.md
billing-webhook-examples-python.md
billing-webhook-examples-javascript.md

이것이 바로 A2A 모델의 작동 방식입니다: 단순히 “이 함수를 호출하라"가 아니라 “이 작업을 다른 에이전트에 위임하고, 필요에 따라 통신하며, 완료까지 결과를 추적하라"는 것입니다.

왜 실제 시스템에서 작업이 중요한가

작업은 A2A를 심각한 워크플로우에 적합하게 만드는 것입니다.

일반 HTTP API 호출은 종종 에이전트 작업에 비해 너무 얇습니다. 에이전트 작업은 불확실성, 여러 단계, 중간 결과, 그리고 후속 질문을 포함할 수 있습니다.

작업은 다음을 첨부할 수 있는 장소를 제공합니다:

  • 상태
  • 기록
  • 메시지
  • 아티팩트
  • 오류
  • 메타데이터
  • 진행 상황
  • 취소
  • 감사 정보

이는 다음과 같은 경우에 유용합니다:

  • 연구 워크플로우
  • 코드 생성
  • 데이터 분석
  • 규정 준수 검토
  • 문서 생산
  • 사건 조사
  • 다단계 계획
  • 인간 승인 워크플로우

작업 모델이 없으면, 개발자들은 일반적으로 사용자 정의 작업 ID, 큐, 상태 엔드포인트, 웹훅 콜백으로 이 로직을 자체적으로 다시 구축합니다. A2A는 이러한 패턴의 에이전트 특정 버전을 표준화하여 매번 새로운 에이전트 통합을 위해 재발명하지 않도록 시도합니다.

스트리밍 및 비동기 작업

A2A는 에이전트 작업이 스트리밍 또는 비동기적일 수 있다는 아이디어를 지원합니다.

스트리밍은 클라이언트가 실시간 업데이트를 원할 때 유용합니다.

예를 들어:

  • 진행 이벤트
  • 부분적 결과
  • 중간 상태
  • 생성된 텍스트
  • 단계 업데이트

비동기 워크플로우는 작업에 오랜 시간이 걸리거나 클라이언트가 열린 연결을 유지할 수 없을 때 유용합니다.

예를 들어:

  • 백그라운드 연구
  • 대규모 문서 생성
  • 다중 에이전트 검토
  • 데이터 처리
  • 인간 승인
  • 배치 분석

실무에서, 견고한 A2A 시스템은 세 가지 모드 주변에 설계되어야 합니다: 단순 작업을 위한 즉각적인 응답, 상호작용적인 장기 실행 작업을 위한 스트리밍, 그리고 단일 연결보다 오래 지속될 수 있는 내구성 있는 백그라운드 작업을 위한 비동기. SSE, 푸시 웹훅, 재구독, input_required를 통한 HITL, 오류 처리, 및 프로덕션 체크리스트에 대해서는 A2A Streaming and Async Tasks for Long-Running Agent Workflows를 참조하십시오.

에이전트 카드 및 스트리밍 지원

에이전트 카드는 에이전트가 스트리밍을 지원하는지 광고할 수 있습니다.

이는 클라이언트가 모든 에이전트가 스트리밍을 지원한다고 가정할 수 없기 때문에 중요합니다. 일부 에이전트는 단순한 요청-응답만 지원할 수 있고, 일부는 작업 폴링을 지원하며, 다른 일부는 푸시 알림 또는 서버 전송 이벤트를 지원합니다. 좋은 클라이언트는 상호작용 패턴을 선택하기 전에 에이전트 카드를 검사하며, 이것이 바로 에이전트 카드가 단순한 문서가 아니라 런타임 행동을 직접 형성하는 이유입니다.

A2A 및 다중 모드 에이전트

A2A는 평문보다 더 많은 것을 지원하도록 설계되었습니다.

이는 실제 에이전트 시스템이 점점 더 혼합된 입력과 출력을 처리하기 때문에 중요합니다:

  • 텍스트
  • 이미지
  • 오디오
  • 비디오
  • PDF
  • 스프레드시트
  • 구조화된 JSON
  • 로그
  • 코드
  • 다이어그램

모든 에이전트 경계가 모든 것을 텍스트로 변환하면 중요한 정보가 손실될 수 있습니다.

예를 들어, 시각적 문제 해결 에이전트는 약한 텍스트 설명이 아닌 이미지로 이미지를 받아야 합니다. 재무 에이전트는 복사된 단락이 아닌 구조화된 스프레드시트 데이터를 받아야 합니다. 코드 검토 에이전트는 모호한 요약이 아닌 소스 파일 또는 diff를 받아야 합니다.

부분 및 미디어 타입은 A2A가 에이전트 경계 너머로 더 풍부한 콘텐츠를 보존하는 방법이며, 이는 프로토콜이 처음에 보이는 것보다 더 중요한 곳 중 하나입니다. 왜냐하면 경계에서의 정보 손실은 다중 에이전트 체인에서 모든 홉(hop)에서 누적되기 때문입니다.

A2A는 에이전트 프레임워크가 아닙니다

A2A는 에이전트를 어떻게 구축해야 하는지 알려주지 않습니다.

A2A는 다음을 정의하지 않습니다:

  • 추론 전략
  • 계획 알고리즘
  • 메모리 시스템
  • 벡터 데이터베이스
  • 프롬프트 템플릿
  • 모델 제공자
  • 도구 프레임워크
  • 오케스트레이션 런타임
  • 평가 방법

이는 결함이 아닌 기능입니다. A2A는 서로 다른 에이전트 구현이 동일한 내부 아키텍처를 공유하지 않고도 통신할 수 있게 하는 경계 프로토콜입니다 — HTTP가 웹 애플리케이션을 어떻게 구축해야 하는지 알려주지 않고 시스템이 어떻게 통신하는지만 정의하는 것과 마찬가지로. A2A도同樣하게 이해되어야 합니다.

A2A는 API의 대체제가 아닙니다

A2A는 또한 모든 API를 대체하지 않습니다.

안정적인 요청-응답 계약을 가진 결정론적 서비스를 가지고 있다면, 일반적인 API가 더 나을 수 있습니다.

예를 들어:

  • 화폐 변환
  • 주소 검증
  • 송장 조회
  • 이미지 크기 조정
  • 검색 엔드포인트
  • 기능 플래그 조회
  • 내부 CRUD 서비스

이것들은 AI 시스템에 의해 호출된다는 이유만으로 자동으로 에이전트가 되는 것이 아닙니다. 원격 시스템이 실제로 에이전트처럼 행동할 때 A2A가 의미가 있습니다:

  • 작업을 소유함
  • 추가 입력을 요청할 수 있음
  • 내부적으로 도구를 사용할 수 있음
  • 시간이 걸릴 수 있음
  • 아티팩트를 생성할 수 있음
  • 발견할 가치가 있는 기능이 있음
  • 더 큰 워크플로우에서 피어로 작동할 수 있음

A2A를 단지 유행이기 때문에 사용하지 마십시오 — 추상이 실제로 문제에 적합할 때 사용하십시오.

AI 시스템 아키텍처에서 A2A의 위치

A2A는 독립적으로 배포 가능한 에이전트들 사이의 경계에서 가장 잘 맞습니다.

유용한 아키텍처는 다음과 같을 수 있습니다:

사용자
  |
  v
주요 어시스턴트
  |
  |-- A2A --> 연구 에이전트
  |-- A2A --> 코딩 에이전트
  |-- A2A --> 규정 준수 에이전트
  |-- A2A --> 문서화 에이전트

각 전문가 에이전트는 내부적으로 도구를 사용할 수 있습니다:

연구 에이전트
  |
  |-- MCP --> 웹 검색
  |-- MCP --> 문서 저장소
  |-- MCP --> 벡터 데이터베이스

이것은 다음과 같은 별도의 레이어를 제공합니다:

사용자 인터페이스 레이어
에이전트 조정 레이어
도구 통합 레이어
데이터 및 실행 레이어

A2A는 에이전트 조정 레이어에 있으며, MCP는 종종 도구 통합 레이어에 있고, 일반적인 API, 큐, 데이터베이스, 및 스토리지 시스템은 그 아래에 있습니다 — 각 레이어는 자체 추상화와 자체 실패 모드를 가집니다. LLM 추론, 메모리, 라우팅, 도구 사용, 및 관찰성이 프로덕션 어시스턴트 내부에서 어떻게 맞물리는지에 대한 횡단면 맵에 대해서는 AI Assistant Architecture: LLM, Memory, Tools, Routing, Observability를 참조하십시오.

아키텍처 패턴: 오케스트레이터 및 전문가

가장 일반적인 A2A 패턴은 아마도 오케스트레이터 플러스 전문가일 것입니다.

이 패턴에서, 하나의 주요 에이전트가 사용자 요청을 받고 작업의 일부를 전문가 에이전트에 위임합니다.

예제:

주요 어시스턴트
  |
  |-- A2A --> 법적 에이전트
  |-- A2A --> 재무 에이전트
  |-- A2A --> 연구 에이전트
  |-- A2A --> 작성 에이전트

이 패턴은 이해하기 쉽습니다: 오케스트레이터는 전체 워크플로우를 소유하고, 전문가 에이전트는 도메인 특정 작업을 소유합니다. 단점은 오케스트레이터가 병목 현상이 될 수 있으며, 효과적으로 위임하기 위해 견고한 라우팅 전략이 필요하다는 것입니다. — 기반 모델 선택 및 오케스트레이션 트레이드오프는 Multi-Model System Design: When One Model Isn’t Enough에서 다루어집니다. 그럼에도 불구하고, 대부분의 팀에게는 더 복잡한 토폴로지를 탐색하기 전에 도달할 수 있는 최고의 첫 번째 다중 에이전트 아키텍처입니다.

아키텍처 패턴: 피어 에이전트

피어 투 피어 패턴에서, 에이전트들은 서로 더 직접적으로 통신할 수 있습니다.

예를 들어:

연구 에이전트 --> 데이터 에이전트 --> 차트 에이전트 --> 작성 에이전트

이는 강력할 수 있지만, 통제하기가 더 어렵습니다.

다음에 대한 강력한 규칙이 필요합니다:

  • 누가 누구를 호출할 수 있는지
  • 어떤 컨텍스트가 공유될 수 있는지
  • 루프가 어떻게 방지되는지
  • 최종 출력이 누구의 소유인지
  • 비용이 어떻게 통제되는지
  • 위임이 어떻게 감사되는지

피어 에이전트 네트워크는 우아하게 들리지만, 빠르게 혼란스러워질 수 있습니다 — 그래프의 모든 가장자리에 대한 강력한 거버넌스 규칙과 명확한 소유권을 가지고 있을 때만 사용하십시오.

아키텍처 패턴: A2A 게이트웨이

더 프로덕션 친화적인 패턴은 A2A 게이트웨이입니다.

모든 에이전트가 직접 다른 에이전트를 호출하는 대신, 트래픽이 게이트웨이를 통해 흐릅니다.

게이트웨이는 다음을 처리할 수 있습니다:

  • 인증
  • 권한 부여
  • 라우팅
  • 테넌트 매핑
  • 로깅
  • 속도 제한
  • 정책 확인
  • 프로토콜 버전 처리
  • 관찰성
  • 감사 추적

이는 게이트웨이가 에이전트 통신의 제어 평면이 되는 엔터프라이즈 환경에서 특히 유용합니다 — 각 에이전트 전반에 재구현하는 대신 한 곳에서 정책을 강제합니다. 작은 시스템에서는 과할 수 있지만, 여러 팀과 벤더가 있는 큰 시스템에서는 예상보다 더 일찍 필요해질 수 있습니다.

보안 고려사항

A2A 보안은 심각한 주의를 기울여야 합니다.

에이전트 간 통신은 민감한 컨텍스트를 경계 너머로 이동할 수 있습니다. 또한 자체 도구와 권한을 가질 수 있는 시스템에 작업을 위임할 수 있습니다.

핵심 보안 질문은 다음과 같습니다:

  • 어떤 에이전트가 이 에이전트를 발견하도록 허용되는가?
  • 어떤 에이전트가 작업 보내기를 허용되는가?
  • 어떤 인증이 필요한가?
  • 호출자에 어떤 권한이 첨부되는가?
  • 하나의 에이전트가 다른 에이전트에 사용자 권한을 위임할 수 있는가?
  • 메시지에 어떤 데이터가 포함될 수 있는가?
  • 어떤 아티팩트가 반환될 수 있는가?
  • 작업이 어떻게 감사되는가?
  • 수신 에이전트가 도구 또는 다른 에이전트를 호출할 수 있는가?
  • 비밀이 어떻게 보호되는가?

에이전트 카드는 정적 비밀을 포함해서는 안 되며, 민감한 에이전트 카드는 공개적으로 게시되는 대신 인증 뒤에 보호되어야 합니다. 다른 클라이언트는 종종 동일한 에이전트의 다른 뷰가 필요합니다 — 내부 호출자는 외부 파트너보다 더 많은 스킬을 볼 수 있으며, 공개 클라이언트는 제한된 안전한 기능 세트만 볼 수 있습니다.

보안은 에이전트 네트워크가 구축된 후에 추가되어서는 안 됩니다. 네트워크를 처음부터 형성해야 합니다. 왜냐하면 라이브 에이전트 토폴로지 전반에 인증 및 권한 경계를 리트로핏하는 것은 설계하는 것보다 훨씬 더 어려우기 때문입니다. 전체 처리 — 위협 모델, 정체성 레이어, 게이트웨이 제어 평면, 위임 범위, 및 감사 추적 — 에 대해서는 A2A and MCP Agent Security: Identity, Delegation, and Audit Trails를 참조하십시오.

관찰성 고려사항

A2A 시스템은 강력한 관찰성이 필요합니다.

작업이 에이전트 경계를 교차할 때, 단일 시스템이 전체 그림을 보유하지 않기 때문에 디버깅이 훨씬 더 어려워집니다. 다음을 알아야 합니다:

  • 어떤 에이전트가 작업을 생성했는지
  • 어떤 에이전트가 이를 수락했는지
  • 어떤 메시지가 교환되었는지
  • 어떤 상태 변경이 발생했는지
  • 어떤 아티팩트가 생성되었는지
  • 어떤 오류가 발생했는지
  • 각 단계에 얼마나 걸렸는지
  • 내부적으로 어떤 도구가 사용되었는지
  • 다른 에이전트가 호출되었는지
  • 위험한 행동을 누가 승인했는지

유용한 추적은 전체 체인을 통해 작업을 따라야 합니다.

예를 들어:

사용자 요청
  -> 주요 어시스턴트 작업
  -> 연구 에이전트 작업
  -> 문서 검색 도구 호출
  -> 요약 아티팩트
  -> 최종 응답

이 엔드 투 엔드 추적이 없으면, 다중 에이전트 시스템은 프로덕션에서 신뢰하기가 매우 어려워집니다 — 시스템이 주어진 출력을 생성한 이유를 확실히 답할 수 없으며, 하물며 무엇이 잘못되었는지 식별할 수 없습니다. Observability for LLM Systems: Metrics, Traces, Logs, and Testing in Production은 이 문제의 계측 및 도구 측면을 깊이 있게 다룹니다.

일반적인 실수

실수 1: 모든 도구를 에이전트라고 부르기

모든 도구가 에이전트는 아닙니다.

계산기는 도구입니다. 파일 리더는 도구입니다. 데이터베이스 쿼리 엔드포인트는 도구입니다.

작업을 소유하지 않고, 입력을 요청하지 않으며, 아티팩트를 생성하지 않고, 독립적인 피어로 동작하지 않으면, 아마도 A2A가 필요하지 않을 것입니다.

실수 2: 에이전트 카드를 너무 모호하게 만들기

에이전트 카드는 다음과 같이 말해서는 안 됩니다:

이 에이전트는 비즈니스 작업을 지원합니다.

이는 작업을 지능적으로 라우팅하려는 에이전트에게는 쓸모없습니다. 좋은 카드는 에이전트가 실제로 무엇을 하는지, 무엇을 받아들이는지, 무엇을 반환하는지, 그리고 어떤 제약이 적용되는지를 말해야 합니다.

실수 3: 작업 상태 무시하기

A2A를 사용하지만 모든 상호작용을 요청-응답처럼 취급한다면, 많은 가치를 놓치고 있습니다.

작업 모델은 일반 API보다 A2A를 사용해야 하는 주요 이유 중 하나입니다 — 이를 건너뛰면 매번 통합에서 동일한 라이프사이클 추적 로직을 재구축해야 합니다.

실수 4: 모든 것을 텍스트로 반환하기

A2A는 구조화되고 다중 모드 콘텐츠를 지원합니다. 이를 사용하십시오.

출력이 보고서라면, 보고서 아티팩트를 반환하십시오.

출력이 JSON이라면, 구조화된 데이터를 반환하십시오.

출력이 파일이라면, 파일을 반환하십시오.

평문이 올바른 출력인 경우를 제외하고는 모든 것을 평문으로 평평하게 만들지 마십시오.

실수 5: 권한 모델 없음

권한 경계가 없는 에이전트 네트워크는 위험합니다.

모든 에이전트가 모든 유형의 데이터로 다른 모든 에이전트를 호출할 수 있게 해서는 안 됩니다 — 인증, 권한 부여, 및 감사 추적을 사용하여 에이전트 네트워크 전반에 최소 권한 원칙을 강제하십시오.

언제 A2A를 사용해야 하는가?

실제 에이전트 경계가 있을 때 A2A를 사용하십시오.

좋은 이유는 다음과 같습니다:

  • 에이전트가 다른 팀에 의해 소유됨
  • 에이전트가 별도의 서비스로 배포됨
  • 에이전트가 다른 프레임워크로 구축됨
  • 에이전트가 서로를 발견해야 함
  • 에이전트가 작업을 위임해야 함
  • 작업이 장기 실행될 수 있음
  • 결과에 아티팩트가 포함될 수 있음
  • 클라이언트가 내부 도구를 알 필요가 없음
  • 에이전트 기능 메타데이터가 중요함

약한 이유는 다음과 같습니다:

  • 현대적으로 들리기 때문
  • 하나의 함수를 호출하고 싶음
  • 단일 에이전트 앱이 있음
  • 일반 API가 작동함
  • MCP가 이미 도구 통합 문제를 해결함

A2A는 시스템이 실제로 다중 에이전트일 때 강력합니다. 시스템이 그렇지 않을 때는 불필요한 의식이며, 그 의식의 비용 — 추가된 개념, 인프라, 디버깅 표면, 및 보안 요구사항 — 은 실제적입니다.

최소 정신 모델

만약 하나만 기억한다면, 이것을 기억하십시오:

에이전트 카드: 에이전트가 할 수 있는 것.
메시지: 에이전트들이 서로에게 말하는 것.
부분: 메시지 또는 아티팩트 내부의 타입화된 콘텐츠.
작업: 에이전트가 소유한 작업.
아티팩트: 작업이 생성한 출력물.

이것이 A2A의 핵심입니다 — 나머지는 대부분 이 다섯 가지 개념을 실제 프로덕션 시스템에서 사용할 수 있도록 신뢰할 수 있고, 관찰 가능하며, 충분히 안전하게 만드는 것입니다.

최종 생각

A2A는 또 다른 AI 약어가 아닙니다. 이는 고립된 어시스턴트에서 상호운용 가능한 에이전트 시스템으로의 더 큰 전환의 일부입니다. 이 전환은 모든 곳에서 동시에 일어나지 않을 것이며, 많은 애플리케이션은 MCP와 일반 API가 완전히 충분한 좋은 도구 접근을 가진 단일 에이전트 시스템으로 남아 있을 것입니다.

그러나 에이전트가 별도로 배포되는 피어가 되면, 더 강력한 경계가 필요합니다: 발견, 작업 소유, 텍스트보다 더 많은 것을 전달하는 메시지, 일급 출력물로서의 아티팩트, 그리고 에이전트 경계를 가로지르는 보안, 상태, 및 관찰성. A2A가 점유하려는 공간이며, 이는 MCP가 해결하는 도구 통합 문제와 genuinely 다른 문제입니다.

2026년에 A2A가 실제로 프로덕션 견인력을 얻고 있는 곳 — 채택 계층, 보안 우려, 엔터프라이즈 사용 사례, 및 결정 프레임워크 포함 — 에 대한 실용적인 견해에 대해서는 Google A2A Protocol in 2026: Adoption, Hype, and Reality를 참조하십시오.

제 의견: 작은 프로젝트에서는 A2A로 시작하지 마십시오. 유용한 에이전트, 좋은 도구, 그리고 명확한 아키텍처로 시작하십시오 — AI Systems cluster는 자체 호스팅 어시스턴트, MCP 서버, 및 에이전트 메모리를 연결된 집합으로 다루며, 더 넓은 컨텍스트가 원한다면 이를 참조하십시오. 그러나 당신의 “도구"가 자체 작업 라이프사이클을 가진 다른 자율적인 전문가처럼 보이기 시작하면, 그것은 아마도 더 이상 단순한 도구가 아닙니다 — 그리고 그때 A2A가 흥미로워집니다.

출처

구독하기

시스템, 인프라, AI 엔지니어링에 관한 새 글을 받아보세요.