A2A는 에이전트가 상호 운용할 수 있도록 공통 언어와 표준화된 핸드셰이크 절차를 정의한다. 목표는 기존 표준을 재발명하는 것이 아니라, 에이전트가 개별 작업을 수행하는 방식과 협업 과정 사이의 구조적 간극을 해소하는 데 있다.
스타트업 ai리절츠(aiRESULTS) 최고경영자 매트 하산은 A2A를 “게임 체인저”라고 평가했다. 하산은 “이 프로토콜은 ‘단일 에이전트가 작업을 수행할 수 있는가?’에서 ‘특화된 에이전트가 팀을 구성해 복잡한 비즈니스 워크플로를 어떻게 협업할 수 있는가?’로 논점을 전환한다”고 분석했다.
이 이니셔티브는 2025년 4월, 구글이 오픈소스 사양을 공개하면서 시작됐다. 폭발적으로 증가하는 자율형 에이전트 생태계 전반에서 상호 운용성을 촉진하고, 다양한 플랫폼 기반 에이전트를 연결하기 위한 목적이었다. 초기 에이전트가 서로 통신하기 어렵게 만들었던 취약한 통합 구조를 피하도록 개발자를 지원하는 것이 목표였다.
하산은 “A2A는 이론적으로는 에이전트 간 보편적 통신 표준이고, 실질적으로는 복잡한 업체 중립 멀티 에이전트 시스템을 기업 환경에서 구현하기 위한 아키텍처 설계도”라고 강조했다.
발견, 메시징, 작업 위임의 공통 기반을 제공함으로써 A2A는 별도의 커스텀 미들웨어 없이도 다른 개발사·플랫폼의 에이전트가 다단계 워크플로를 공동으로 처리하도록 지원한다. 이러한 상호 운용성이 프로토콜의 핵심이며, 기업은 하나의 모놀리식 초대형 에이전트를 구축하는 대신, 특화된 에이전트를 조합해 바로 협업 가능한 네트워크를 구성할 수 있다.
A2A의 동작 방식
A2A는 에이전트 간 통신 규칙과 표준화된 능력 공유 방식을 정의한다.
하산은 “A2A 기술의 핵심은 작업 위임을 형식화한 ‘태스크 객체(Task Object)’”라고 설명했다. 기존 인공지능 에이전트를 A2A 기반으로 확장할 때, 개발자는 에이전트의 특화 기능을 공용 메타데이터 파일인 에이전트 카드로 구성한다. 이 메타데이터는 해당 에이전트의 기능을 설명하며, 이를 바탕으로 클라이언트 에이전트가 원격 에이전트를 발견하고 구조화된 태스크 요청을 보낸 뒤 안전하게 상태를 모니터링할 수 있다. 원격 에이전트가 랭체인(LangChain) 기반이든, 파이썬 기반 커스텀 프레임워크든, 업체 특화 SDK 기반이든 이러한 동작은 동일하게 수행된다.
A2A의 네 가지 핵심 데이터 구조
A2A는 워크플로 단계에 따라 네 가지 기본 객체를 정의한다.
A2A는 통신을 네 가지 주요 객체 유형으로 구성하며, 각 객체는 워크플로의 고유한 단계를 나타낸다.
- - 에이전트 카드. agent.json 형태의 소규모 JSON 파일이며, 에이전트의 정체성, 기능, 인증 방식, 선택적 디지털 서명을 포함한다. 다른 에이전트는 이 카드를 읽어 협업 가능 여부를 확인하고 신뢰를 평가한다.
- - 태스크(Task). 고유 task_id, 입력 페이로드, 우선순위·만료·모달리티 요구사항 같은 메타데이터를 포함한 구조화된 작업 요청이다. 태스크는 수행해야 할 작업을 정의하며, 이후 모든 통신의 기준점이 된다.
- - 메시지(Message). 태스크 진행 상태와 중간 정보를 전달하는 스트림이다. 메시지는 진행률 표시, 추가 입력 요청, 문맥 정보를 포함하며 일반적으로 SSE 또는 gRPC 기반 스트림으로 전송된다.
- - 아티팩트(Artifact). 완료된 태스크 결과물이다. 아티팩트는 텍스트, 파일, 구조화된 데이터를 포함할 수 있으며, 트랜잭션을 종료하고 후속 태스크로 연결할 수도 있다.
일반적인 처리 과정에서, 요청 에이전트는 먼저 상대 에이전트의 기능과 지원 프로토콜을 확인하기 위해 에이전트 카드를 조회한다. 요청 에이전트는 클라이언트, 조회 대상 에이전트는 서버로 불리지만, 이 역할은 고정되지 않는다. 동일한 상호작용 중에도 두 에이전트가 역할을 교차 변경할 수 있다.
클라이언트 에이전트는 createTask 요청을 전달하며, 서버 에이전트는 task_id를 반환해 요청을 승인한다. 태스크가 실행되는 동안, 서버는 상태를 나타내거나 추가 정보를 요청하는 메시지 객체를 스트리밍한다. 작업이 완료되거나 실패하면, 서버는 하나 이상의 아티팩트 객체와 완료 코드를 전송한다.
모든 단계가 동일한 스키마를 준수하므로, A2A 지원 에이전트는 커스텀 어댑터 없이도 동일한 대화 구조에 참여할 수 있다. 예를 들어, 대규모 언어 모델 기반 플래닝 에이전트가 데이터 수집 태스크를 파이썬 마이크로서비스에 위임하고, 그 마이크로서비스가 다시 휴먼 인 더 루프 에이전트에게 출력을 검증하도록 위임하는 구조도 가능하다. 이 모든 과정은 A2A 메시지로 이루어진다.
A2A의 설계 원칙
A2A는 웹 표준에서 검증된 개념을 자율형 시스템에 적용한다.
A2A는 수십 년 간의 인터넷 엔지니어링 경험을 기반으로 설계되었으며, HTTP, REST, OAuth 등의 표준에서 차용한 원칙을 자율형 시스템에 적용한다.
- - 상호 운용성. A2A는 특정 프레임워크에 종속되지 않는다. 랭체인, 오픈데빈(OpenDevin), 커스텀 SDK 등 어떤 언어나 프레임워크로 개발된 에이전트라도 동일한 메시지 스키마를 사용해 통신할 수 있다. 구현과 상호작용을 분리함으로써 멀티 에이전트 생태계가 가능해진다.
- - 투명성. 각 에이전트는 구조화된 에이전트 카드를 통해 기능과 한계를 공개한다. 다른 에이전트는 소스 코드를 보지 않고도 협업 가능성을 평가할 수 있다.
- - 보안. 인증, 권한 부여, 메시지 무결성은 사양의 핵심 요소다. A2A는 다양한 인증 방식과 서명된 에이전트 카드를 지원해 자동화된 신뢰 결정을 가능하게 한다. 모든 태스크와 메시지는 추적 가능하며, 에이전트 활동은 감사를 위한 기록으로 남는다.
- - 모듈성·조합성. 프로토콜은 각 에이전트를 입력·출력이 명확한 불투명 서비스(opaque service)로 취급한다. 에이전트는 서로의 기능을 재사용해 긴 워크플로를 구성할 수 있으며, 이는 API와 마이크로서비스 아키텍처의 조합성과 유사하다.
- - 확장성·복원력. A2A는 비동기·분산 환경을 전제로 한다. 에이전트는 장기 실행 태스크를 처리하고, 중간 결과를 스트리밍하며, 네트워크 장애에서 복구할 수 있다. 또한 런타임 동작을 강제하지 않기 때문에 로컬 환경에서 두 개의 에이전트가 협업하는 상황부터, 수백 개의 클라우드 기반 에이전트가 도메인 간 협력하는 구조까지 자연스럽게 확장된다.
이러한 원칙 조합은 프레임워크·모델·통신 기술이 발전하더라도 지속적으로 진화하는 분산 지능의 공통 언어로 A2A를 자리매김하게 한다.
A2A는 안전한가
A2A 보안은 프로토콜 무결성과 에이전트 간 신뢰에 기반한다.
A2A 보안은 두 가지 층위에서 동작한다. 프로토콜 자체의 무결성과, 에이전트 간 신뢰 메커니즘이다. 사양에는 웹 규모 API를 보호하는 것과 동일한 보호 장치—인증, 권한 부여, 암호화—가 포함되어 있으며, 자율형 시스템이 상호 신뢰성을 평가하고 반응할 수 있도록 설계된 추가 기능도 제공한다.
에이전트 카드는 에이전트의 정체성, 기능, 지원하는 인증 방식을 설명한다. 이 카드는 디지털 서명을 포함할 수 있어, 클라이언트 에이전트가 서버 에이전트를 생성한 기업을 검증한 후 통신을 시작하도록 돕는다.
통신이 시작되면 태스크와 메시지는 HTTPS, gRPC, 웹소켓(WebSocket) 같은 안전한 채널을 통해 교환되며, 모든 페이로드는 전송 중 암호화된다. 또한 프로토콜은 명확한 응답 코드와 이벤트 로그를 정의해 기업의 옵저버빌리티 도구와 통합 가능한 감사 기록을 제공한다.
하산은 “장애가 발생한 에이전트는 오류 코드나 실패 알림을 요청자로 반환하며, 요청자는 즉시 더 신뢰할 수 있는 다른 에이전트로 전환할 수 있다”고 설명했다.
하산은 이러한 기반이 향후 고도화된 동작을 가능하게 한다고 분석했다. “특정 에이전트나 에이전트 네트워크는 자체 추적 시스템을 구축해 신뢰 점수를 관리하고, 해당 정보를 공유하거나 신뢰 등급을 발행할 수 있다. 반복된 실패는 점수 하락으로 이어지고, 결국 다른 에이전트가 해당 에이전트에게 작업을 요청하지 않게 된다.”
이러한 자가 규제 구조는 중앙 관리자가 모든 참여 에이전트를 검증할 수 없는 대규모 멀티 에이전트 시스템에서 필수다. A2A의 신뢰 모델은 성능이 낮거나 악의적 에이전트를 자동으로 격리하고, 안정적으로 동작하는 에이전트는 상호작용을 통해 신뢰도를 높인다.
다만 A2A의 개방형 특성은 사이버보안과 동일한 고민을 남긴다. 외부 에이전트 인증 방식, 스키마 해석 차이, 잘못된 메시지로 인한 민감정보 노출 위험, 정체성 위조, 모델 환각, 버전 불일치 등은 기업의 거버넌스 체계로 관리해야 할 잠재적 리스크다.
대다수 실제 배포 환경에서는 프로토콜 수준의 통제와 운영 정책을 결합해 보안을 확보한다. 서명된 에이전트 카드 요구, API 키 또는 OAuth 토큰 중앙 관리, 에이전트 신뢰도를 기록하는 레퓨테이션 데이터베이스 운영 등이 그 예다. 장기적으로 이러한 관행은 웹의 인증서 발급 기관 구조(CA)와 유사한 표준화된 신뢰 레지스트리로 발전할 가능성이 있다.
A2A의 실제 사례
A2A는 이미 다양한 기업과 플랫폼에서 초기 적용이 이루어지고 있다.
구글이 A2A 프로토콜을 공개했을 당시, 아틀라시안, 박스, 페이팔, SAP, 주요 컨설팅 기업 등 50개 이상 파트너가 지원을 발표했다. 마이크로소프트 또한 애저 AI 파운드리와 코파일럿 스튜디오 플랫폼에서 A2A 지원을 공식적으로 발표했다.
구글은 실제 적용 사례도 공개했다. 예를 들어, 박스 AI 에이전트(Box AI Agents)는 A2A 규격을 준수하는 엔드포인트를 통해 여러 플랫폼의 에이전트와 협업한다. 또 다른 사례로, 트윌리오(Twilio)는 A2A 확장을 사용해 지연(latency) 정보를 브로드캐스트하고, 해당 정보를 기반으로 에이전트 간 지능형 라우팅을 수행하며, 느린 에이전트만 남았을 때 단계적 축소 동작을 지원한다. 이러한 사례는 아직 완전한 대규모 상용 배포는 아니지만, 파일럿 단계를 넘어 엔터프라이즈 환경에서 실질적 채택이 진행 중임을 보여준다.
기대되는 미래는 A2A가 또 다른 ‘AI 과대광고용 프로토콜’이 아니라, 멀티 에이전트 생태계의 기반 통신 계층으로 자리잡는 것이다. 지금 에이전트 카드를 발행하고, 태스크를 정의하며, 결과 스트리밍을 실험하는 기업은, 향후 업체 중립 에이전트가 자동화 파이프라인의 핵심 구성 요소가 될 때 경쟁 우위를 확보할 가능성이 크다. 도입 초기 단계이긴 하지만, 지금의 로드맵은 고립된 에이전트가 공통 언어로 상호 대화하는 세계로 향하고 있다.
dl-itworldkorea@foundryco.com
Josh Fruhlinger editor@itworld.co.kr
저작권자 Foundry & ITWorld, 무단 전재 및 재배포 금지
이 기사의 카테고리는 언론사의 분류를 따릅니다.
언론사는 한 기사를 두 개 이상의 카테고리로 분류할 수 있습니다.
