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

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

Page content

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

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

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

A2A는 서로 다른 팀, 프레임워크, 벤더, 언어, 조직에 의해 구축된 에이전트들이 존재하는 다른 세계를 위해 설계되었습니다. A2A는 한 에이전트가 다른 에이전트를 발견하고, 그 에이전트가 무엇을 할 수 있는지 이해하고, 작업을 보내고, 메시지를 교환하며, 파일이나 구조화된 출력을 수신하고, 작업이 완료될 때까지 추적해야 할 수 있다는 것을 가정합니다. 이는 단순히 또 다른 도구 호출 형식이 아니라, AI 에이전트들이 동등한 존재로서 상호 운용될 수 있도록 하는 진정한 시도입니다.

핵심 개념은 다음과 같습니다:

  • 에이전트 카드(Agent Cards)
  • 에이전트와 클라이언트(Agents and clients)
  • 작업(Tasks)
  • 메시지(Messages)
  • 부분(Parts)
  • 산출물(Artifacts)
  • 작업 상태(Task states)
  • 스트리밍 및 비동기 업데이트(Streaming and asynchronous updates)

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

간략한 정의

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

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

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

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

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

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

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

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

왜 A2A가 존재하는가

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

한 회사에는 다음과 같은 에이전트들이 있을 수 있습니다:

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

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

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

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

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

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

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

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

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

에이전트 카드

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

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

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

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

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

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

에이전트 카드는 중요한데, 이는 에이전트들이 다른 모든 에이전트에 대한 하드코딩된 지식을 필요로 하지 않아야 하기 때문입니다.

클라이언트는 카드를 검사하고 다음을 결정할 수 있습니다:

  • 이 에이전트가 작업에 적합한가?
  • 필요한 콘텐츠 타입을 지원하나요?
  • 스트리밍을 지원하나요?
  • 인증이 필요한가요?
  • 어떤 스킬을 광고하나요?
  • 필요한 산출물 종류를 반환할 수 있나요?

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

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

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

에이전트 카드가 에이전트가 재무 분석을 수행할 수 있다고 하면, 클라이언트는 재무 분석 작업을 해당 에이전트에 위임하기 시작할 것입니다. 에이전트가 파일을 수락한다고 하면, 클라이언트는 파일을 보낼 것입니다. 에이전트가 스트리밍을 지원한다고 하면, 클라이언트는 진행 이벤트를 기대할 것입니다.

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

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

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

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

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

더 나아가 예상 입력 및 출력 모드를 포함하십시오.

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

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

에이전트 발견

에이전트 발견은 에이전트 카드를 찾는 프로세스입니다.

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

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

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

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

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

작업

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

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

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

하지만 많은 실제 에이전트 워크플로우는 즉시 이루어지지 않습니다.

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

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

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

작업 수명 주기

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

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

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

중요한 점은 작업이 단순한 응답 페이로드가 아니라는 것입니다. 작업은 언제든지 클라이언트가 쿼리할 수 있는 자체 상태를 가진 지속적인 작업 단위입니다. 클라이언트는 작업 상태를 사용하여 무슨 일이 일어나고 있는지 이해할 수 있습니다:

  • 에이전트가 작업을 수락했나요?
  • 아직 진행 중인가요?
  • 더 많은 입력이 필요한가요?
  • 성공적으로 완료했나요?
  • 실패했나요?
  • 취소되었나요?
  • 사용 가능한 산출물이 있나요?

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

예를 들어, 연구 에이전트는 작업을 즉시 반환할 수 있으며, 배경에서 작업을 계속하면서 진행 상황 이벤트를 스트리밍하거나 결과를 나중에 사용할 수 있게 만듭니다.

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

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

단순한 상호작용의 경우, 에이전트는 직접적인 Message를 반환할 수 있습니다. 복잡한 상호작용의 경우, Task를 반환할 수 있습니다. 모든 것이 작업 추적을 필요로 하는 것은 아니며, 짧은 상호작용을 전체 작업 워크플로우로 과도하게 엔지니어링하면 불필요한 오버헤드가 추가되므로 이 구별은 중요합니다.

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

이 단락을 요약해 줘.

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

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

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

작업이 더 적합합니다.

실용적인 규칙은 간단합니다: 단순하고 즉각적인 상호작용에는 직접적인 Message를 사용하고, 장기 실행, 상태가 있는, 감사 가능하거나 산출물을 생성하는 작업에는 Task를 사용하십시오.

메시지

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

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

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

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

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

메시지에는 다음이 포함될 수 있습니다:

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

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

부분(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를 반환할 때, 이들은 산출물입니다 — 작업의 작업을 검사 가능, 재사용 가능, 조합 가능하게 만드는 구체적인 출력. 한 에이전트의 산출물은 구조 손실 없이 다른 에이전트의 입력이 됩니다.

메시지와 산출물 비교

간단하게 생각하는 방법:

메시지는 대화입니다.
산출물은 출력입니다.

메시지는 에이전트들이 조율하는 데 도움이 되고, 산출물은 작업이 실제로 생성한 것입니다.

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

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

이 분리는 작업 조율과 납품물을 혼합하는 것을 피하므로 로깅, 감사, 다운스트림 소비자에게 출력 전달을 훨씬 더 쉽게 만듭니다.

실용적인 예

주요 어시스턴트가 문서화 에이전트의 도움이 필요하다고 가정해 봅시다.

사용자가 요청합니다:

새 청구서 웹훅 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 시스템은 세 가지 모드 주변에 설계되어야 합니다: 단순한 작업을 위한 즉각적인 응답, 대화형 장기 실행 작업을 위한 스트리밍, 단일 연결보다 오래 지속될 수 있는 내구성 있는 배경 작업을 위한 비동기.

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

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

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

A2A와 다중 모드 에이전트

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

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

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

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

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

부분과 미디어 타입은 A2A가 에이전트 경계를 넘어 더 풍부한 콘텐츠를 보존하는 방법입니다. 그리고 이는 다중 에이전트 체인의 모든 홉에서 경계에서의 정보 손실이 누적되기 때문에, 프로토콜이 처음에 보이는 것보다 더 중요한 장소 중 하나입니다.

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 추론, 메모리, 라우팅, 도구화, 가시성이 프로덕션 어시스턴트 내에서 어떻게 함께 맞물리는지에 대한 교차 단면도(map)는 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 보안은 진지한 관심을 deserving합니다.

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

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

  • 어떤 에이전트가 이 에이전트를 발견할 수 있는가?
  • 어떤 에이전트가 그에게 작업을 보낼 수 있는가?
  • 어떤 인증이 필요한가?
  • 호출자에 어떤 권한이 첨부되어 있는가?
  • 한 에이전트가 다른 에이전트에 사용자 권한을 위임할 수 있는가?
  • 메시지에 어떤 데이터가 포함될 수 있는가?
  • 어떤 산출물이 반환될 수 있는가?
  • 작업은 어떻게 감사되는가?
  • 수신 에이전트가 도구 또는 다른 에이전트를 호출할 수 있는가?
  • 비밀은 어떻게 보호되는가?

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

보안은 에이전트 네트워크가 구축된 후 추가되어서는 안 됩니다. 네트워크가 처음부터 형성되어야 합니다. 라이브 에이전트 토폴로지를 가로질러 인증 및 권한 경계를 리트로피팅하는 것이 설계하는 것보다 훨씬 더 어렵기 때문입니다.

가시성 고려사항

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

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

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

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

예를 들어:

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

그 끝-to-end 추적이 없으면, 다중 에이전트 시스템은 프로덕션에서 신뢰하기 매우 어려워집니다 — 시스템이 주어진 출력을 생성한 이유를 확신 있게 답할 수 없으며, 더 나아가 무엇이 잘못되었는지 식별할 수 없습니다. 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가 해결하는 도구 통합 문제와 진정으로 다른 문제입니다.

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

제 의견: 작은 프로젝트로 A2A로 시작하지 마십시오. 유용한 에이전트, 좋은 도구, 명확한 아키텍처로 시작하십시오 — AI Systems cluster는 더 넓은 컨텍스트가 원한다면 연결된 세트로서 셀프 호스트 어시스턴트, MCP 서버, 에이전트 메모리를 다룹니다. 하지만 당신의 “도구"가 자체 작업 수명 주기를 가진 또 다른 자율 전문가처럼 보이기 시작하면, 그것은 아마도 더 이상 도구만은 아닐 것입니다 — 그리고 그때가 바로 A2A가 흥미로워지는 때입니다.

출처

구독하기

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