오늘날 대부분의 AI 시스템은 단일 에이전트입니다. 하나의 모델, 하나의 프롬프트 루프, 하나의 도구 세트. 이 방식은 작업이 단일 에이전트가 처리하기에 너무 크거나, 내 에이전트가 처리할 수 없는 단계를 다른 팀에서 구축한 에이전트가 처리해야 할 때까지는 잘 작동합니다. 하지만 그럴 때마다 벽에 부딪힙니다. 두 개의 독립적인 에이전트가 서로를 찾고, 작업을 주고받고, 결과를 보고하는 표준적인 방법이 없기 때문입니다. Agent2Agent (A2A)는 이러한 벽을 허물기 위해 만들어진 프로토콜입니다.
이 가이드는 A2A가 무엇인지, 어떤 문제를 해결하는지, 내부적으로 어떻게 작동하는지, 그리고 MCP와 어떻게 다른지 설명합니다. 이 글을 읽은 후 A2A 에이전트를 테스트하고 싶다면, Apidog A2A 디버거 가이드에서 이 게시물이 끝나는 지점부터 이어집니다.
Agent2Agent (A2A)란 무엇인가요?
Agent2Agent (A2A)는 AI 에이전트 간의 통신을 위한 개방형 프로토콜입니다. 이는 한 에이전트가 자신의 역량을 광고하는 방법, 다른 에이전트가 여기에 연결하는 방법, 두 에이전트가 메시지와 파일을 교환하는 방법, 그리고 작업 상태가 호출자에게 다시 전달되는 방법을 정의합니다.
핵심 단어는 간의입니다. A2A는 하나의 에이전트에게 더 많은 도구를 제공하는 것이 아닙니다. 이는 종종 다른 팀이 다른 프레임워크로 구축한 개별 에이전트들이 서로의 내부를 알 필요 없이 함께 작동하도록 하는 것입니다.
에이전트 트래픽을 위한 HTTP라고 생각해보세요. HTTP는 브라우저가 서버가 어떤 언어로 실행되는지 신경 쓰지 않고 모든 웹 서버와 통신할 수 있게 합니다. A2A는 LangGraph 에이전트가 CrewAI 에이전트가 어떻게 구축되었는지 신경 쓰지 않고 서로 통신할 수 있도록 합니다. 양측은 '봉투'에 동의하며, 어느 쪽도 자신의 구현 세부 정보를 노출하지 않습니다.
Google은 2025년에 A2A를 도입했으며, 이후 벤더 중립적인 프로젝트로 Linux Foundation에 이관했습니다. 사양은 A2A GitHub 리포지토리에 공개되어 있으며, 참조 구현은 A2A 프로젝트 사이트에서 확인할 수 있습니다.
A2A가 해결하는 문제
A2A 이전에는 두 에이전트를 연결하는 것은 글루 코드를 작성하는 것을 의미했습니다. 모든 페어링은 맞춤형이었습니다. 만약 당신의 에이전트가 파트너 팀의 연구 에이전트를 호출해야 한다면, 누군가는 특별한 클라이언트를 작성하고, 페이로드 형태를 선택하고, 인증 체계를 고안하고, 이 모든 것을 수동으로 유지보수해야 했습니다. 다음 페어링은 다시 처음부터 시작되었습니다.
이러한 접근 방식은 빠르게 한계에 부딪힙니다:
- 탐색 불가. 작업을 보내기 전에 에이전트가 "무엇을 할 수 있나요?"라고 물어볼 표준적인 방법이 없었습니다.
- 공유되는 작업 모델 없음. 한 에이전트는 일반 문자열을 반환하고, 다른 에이전트는 맞춤형 JSON 블롭을 반환하며, 세 번째 에이전트는 토큰을 스트리밍했습니다. 호출자는 각각을 특별하게 처리해야 했습니다.
- 공통 인증 없음. 모든 통합은 자격 증명과 헤더를 다시 발명했습니다.
- 상호 운용성 없음. AutoGen으로 구축된 에이전트는 동일한 작업을 수행하더라도 LangGraph로 구축된 에이전트를 대체할 수 없었습니다.
A2A는 OpenAPI가 REST 통합을 해결한 방식과 동일하게 이 문제를 해결합니다. 즉, 하나의 합의된 계약을 통해 모든 규격 준수 에이전트가 다른 모든 규격 준수 에이전트와 통신할 수 있게 합니다.
A2A 작동 방식
A2A에는 네 가지 핵심 개념이 있습니다. 이 개념들을 이해하면 전체 프로토콜을 머릿속에 담을 수 있습니다.
에이전트 카드
에이전트 카드는 에이전트가 자신을 설명하기 위해 발행하는 JSON 문서입니다. 이는 탐색의 진입점입니다. 에이전트의 이름, 설명, 역량, 선언된 기술, 지원되는 입력 및 출력 유형, 인증 요구 사항, 그리고 프로토콜 버전을 나열합니다.
관례적으로 이 카드는 잘 알려진 경로, 종종 https://your-agent.example.com/.well-known/agent.json에 위치합니다. 호출 에이전트는 먼저 해당 URL을 가져와 카드를 읽고, 단일 메시지를 보내기 전에 정확히 무엇을 요청할 수 있는지 알게 됩니다.
작업 (Tasks)
작업(Task)은 A2A에서 작업의 단위입니다. 한 에이전트가 다른 에이전트에게 무언가를 하도록 요청하면, 그 요청은 고유한 ID를 가진 작업이 되고, 상태는 submitted(제출됨), working(작업 중), input-required(입력 필요), completed(완료됨)와 같은 상태를 거쳐 진행됩니다. 호출자는 작업을 폴링하거나 업데이트를 구독할 수 있습니다. 이 공유 작업 모델은 A2A 에이전트를 교체 가능하게 만듭니다. 호출자는 누가 작업을 수행하든 상관없이 동일한 방식으로 상태를 처리합니다.
메시지 및 아티팩트
메시지는 에이전트 간의 실제 내용을 전달합니다. 메시지는 텍스트 부분, 파일 부분, 구조화된 데이터 또는 이들의 조합으로 구성됩니다. 수신 에이전트는 자신의 기술에 필요한 부분을 읽습니다.
에이전트가 작업을 마치면 아티팩트, 즉 작업의 구조화된 출력을 반환합니다. 아티팩트는 생성된 문서, 데이터 테이블, 요약 또는 파일 참조일 수 있습니다. 아티팩트 또한 부분들로 구성되므로, 양방향으로 형식이 일관되게 유지됩니다.
스트리밍 및 업데이트
오래 실행되는 작업은 차단될 필요가 없습니다. A2A는 서버 전송 이벤트를 지원하여, 작업이 진행됨에 따라 에이전트가 부분 결과와 상태 변경을 스트리밍할 수 있습니다. 연구 에이전트는 최종 보고서를 발행하기 전에 "3개의 출처를 찾았습니다"와 같은 메시지를 보낼 수 있습니다. 호출자는 스피너를 응시하는 대신 진행 상황을 표시합니다.
종합적으로 볼 때, 일반적인 A2A 교환은 다음과 같습니다:
- 에이전트 A는 에이전트 B의 에이전트 카드를 가져와 해당 기술을 읽습니다.
- 에이전트 A는 작업을 생성하는 메시지를 보냅니다.
- 에이전트 B는 작업을 수행하고 상태 업데이트를 스트리밍합니다.
- 에이전트 B는 작업이
completed상태에 도달하면 아티팩트를 반환합니다. - 에이전트 A는 아티팩트를 사용하여 다음 단계로 진행합니다.
전체 대화는 HTTP를 통한 JSON입니다. 특별한 것은 없습니다.
A2A 대 MCP
A2A와 모델 컨텍스트 프로토콜(MCP)은 둘 다 에이전트와 관련되어 있고 개방형 프로토콜이기 때문에 자주 혼동됩니다. 하지만 이들은 서로 다른 문제를 해결합니다.
| A2A | MCP | |
|---|---|---|
| 연결 대상 | 에이전트 간 | 에이전트와 도구 및 데이터 |
| 답변하는 질문 | "다른 에이전트가 이 단계를 대신 처리할 수 있나요?" | "이 에이전트가 어떤 도구와 리소스에 접근할 수 있나요?" |
| 일반적인 사용 | 팀 간 다중 에이전트 워크플로우 | 단일 에이전트가 데이터베이스, 파일 시스템 또는 API를 호출 |
| 교환 단위 | 작업, 메시지, 아티팩트 | 도구 호출, 리소스, 프롬프트 |
MCP는 에이전트가 외부 시스템에 접근하는 방식입니다. A2A는 에이전트가 다른 에이전트에게 접근하는 방식입니다. 실제 운영 시스템에서는 종종 둘 다 사용됩니다. 에이전트가 MCP를 사용하여 데이터베이스를 쿼리하고, A2A를 사용하여 하위 작업을 전문 에이전트에게 전달합니다. MCP 서버 대 A2A 분석은 이 결정에 대해 심층적으로 다루며, Apidog의 MCP 클라이언트 디버거는 MCP 측면을 실질적으로 보여줍니다.
현실 세계에서의 다중 에이전트 협업
A2A는 에이전트를 협업하게 만드는 한 가지 방법이지만 유일한 방법은 아닙니다. 일부 시스템은 대신 직접 오케스트레이션을 사용하여 한 에이전트가 작업을 계획하고 명시적으로 다른 에이전트에게 위임합니다.
명확한 오픈 소스 예시로는 OpenAI Codex와 Claude Code 간의 실시간 워크플로우를 조정하는 기술인 Codex-Claude-Collab이 있습니다. Codex는 작업을 계획하고, 구현을 Claude Code에 위임한 다음, 사용자에게 응답하기 전에 변경 사항을 검토하고 결과를 확인합니다. 이는 두 개의 다른 코딩 에이전트 간의 긴밀한 계획자-구축자 루프입니다.
이러한 패턴은 하드와이어링된 오케스트레이션입니다. 한쪽은 다른 쪽이 누구인지 정확히 알고 있습니다. A2A는 동일한 아이디어를 일반화합니다. Codex가 Claude Code를 특별히 호출한다는 것을 아는 대신, A2A 호출자는 에이전트 카드를 읽고 어떤 규격 준수 에이전트와도 작업합니다. 양쪽 끝을 모두 제어할 수 있을 때는 오케스트레이션이 훌륭합니다. 에이전트가 독립적이거나, 다른 팀에 의해 소유되거나, 교체 가능해야 할 때는 A2A가 필요합니다. 대부분의 성숙한 시스템은 팀 내에서는 오케스트레이션을, 팀 경계를 넘어서는 A2A를 모두 사용하게 됩니다.
A2A 에이전트 테스트 방법
A2A 에이전트를 구축하거나 사용하게 되면 트래픽을 볼 필요가 있습니다. 콘솔 로그는 구조화된 필드를 숨기고, 맞춤형 테스트 스크립트는 오래되면 쓸모없어집니다. 시각적 A2A 디버거가 제 역할을 하는 곳이 바로 여기입니다.
Apidog는 표준 클라이언트에 A2A 디버거를 제공합니다. 에이전트 카드 URL을 붙여넣고 연결을 클릭하면, Apidog가 카드를 읽고 에이전트의 이름, 역량, 기술을 보여줍니다. 테스트 메시지를 보내고, 파일을 첨부하고, 메타데이터를 추가하며, 응답을 세 가지 뷰(읽기 쉬운 미리보기, 원시 콘텐츠, 전체 JSON-RPC 페이로드)로 읽을 수 있습니다. 이는 curl 없이도 Bearer Token, Basic Auth, API 키 헤더를 처리합니다.
핵심은 격리입니다. 에이전트가 오작동할 때, 전송이 잘못되었는지 에이전트의 로직이 잘못되었는지 알고 싶을 것입니다. 정확한 와이어 페이로드를 보면 몇 초 안에 답을 얻을 수 있습니다. Apidog A2A 디버거 가이드는 완전한 연결-전송-읽기 루프를 안내하며, API를 호출하는 AI 에이전트 테스트의 더 넓은 원칙은 먼저 와이어를 확인하는 동일한 원칙을 적용합니다.
A2A 시작하기
A2A 에이전트를 구축하거나 연결하고 싶다면, 다음의 간단한 경로를 따르세요:
- A2A 사양을 읽고 필요한 에이전트 카드 필드와 작업 수명 주기를 파악하세요.
- 참조 샘플 에이전트 중 하나를 로컬에서 실행하세요. 대부분 몇 분 안에 시작되어 작동하는 에이전트 카드를 노출합니다.
- 샘플의 에이전트 카드 URL에 A2A 디버거를 연결하고 "안녕하세요" 메시지를 보내세요. 왕복 통신을 확인할 수 있는지 확인하세요.
- 자신만의 에이전트를 구축하고, 유효한 에이전트 카드를 노출하고, 워크플로우에 연결하기 전에 같은 방식으로 테스트하세요.
- 일반 텍스트 경로가 작동하면 인증, 파일 첨부, 스트리밍을 추가하세요.
A2A는 아직 초기 단계이지만, 벤더 중립적인 재단과 늘어나는 프레임워크 통합 목록의 지원을 받고 있습니다. 에이전트 트래픽을 일급 프로토콜로 취급하면 나중에 맞춤형 글루 코드를 다시 작성하는 수고를 덜 수 있습니다. AI 에이전트가 새로운 API 소비자라는 게시물은 더 자세한 설명을 제공하며, AI 에이전트용 API 설계는 소비자가 사람 대신 에이전트일 때 무엇이 달라지는지 다룹니다.
자주 묻는 질문
A2A는 Google에서 만들었나요?
Google은 2025년에 A2A를 도입한 후, 벤더 중립적인 공개 프로젝트로 Linux Foundation에 기증했습니다. 사양은 공개적으로 개발되고 있으며, 어떤 벤더든지 이를 구현할 수 있습니다.
에이전트가 하나뿐이라면 A2A가 필요한가요?
아니요. A2A는 에이전트 간 통신을 해결합니다. 도구 세트를 가진 단일 에이전트는 A2A가 아닌 MCP가 필요합니다. 두 번째 에이전트가 등장하면 A2A를 사용하게 됩니다.
어떤 프레임워크가 A2A를 지원하나요?
A2A는 설계상 프레임워크에 구애받지 않습니다. 유효한 에이전트 카드를 발행하고 프로토콜을 따르는 모든 에이전트는 참여할 수 있으므로, LangGraph, CrewAI, AutoGen 및 사용자 정의 에이전트 모두 작동합니다. 에이전트의 내부 프레임워크는 호출자에게 보이지 않습니다.
A2A는 MCP와 같은가요?
아니요. MCP는 하나의 에이전트를 도구 및 데이터 소스에 연결합니다. A2A는 에이전트들을 서로 연결합니다. 이들은 상호 보완적이며, 많은 시스템에서 동시에 둘 다 실행합니다.
A2A 통합은 어떻게 디버깅하나요?
Apidog A2A 디버거와 같은 시각적 A2A 디버거를 사용하세요. 에이전트 카드 URL을 붙여넣고, 테스트 메시지를 보내고, 원시 요청과 응답을 검사하여 전송 버그와 에이전트 로직 버그를 구별할 수 있습니다.
A2A는 장기 실행 작업을 지원하나요?
네. 작업 모델은 명시적인 상태를 가지고 있으며, 프로토콜은 부분 결과 및 진행 상황 업데이트 스트리밍을 위한 서버 전송 이벤트를 지원하므로, 장기 실행 작업이 호출자를 차단하지 않습니다.