쉬운 설명
하나의 AI 에이전트는 스스로 계획을 세우고 도구를 부르며 작업을 끝낼 수 있습니다. 그런데 현실의 일은 에이전트 하나로 끝나지 않는 경우가 많습니다. 어떤 팀은 계약서를 잘 읽는 에이전트를 만들고, 다른 팀은 규정 준수를 잘 따지는 에이전트를 만듭니다. 일을 마치려면 앞쪽 에이전트가 작업의 일부를 뒤쪽 에이전트에게 넘겨야 합니다. A2A는 그 인수인계를 가능하게 하는 공통 규칙입니다.
이런 프로토콜이 없던 시절에는 에이전트 둘을 잇는다는 게 짝마다 연결 코드를 새로 짜는 일이었습니다. A 에이전트가 B 에이전트의 API 형식을 정확히 알아야 했고, 어느 한쪽이 바뀌면 그 코드가 깨졌습니다. A2A는 이걸 하나의 약속된 형식으로 바꿉니다. 에이전트는 자신이 무엇을 할 수 있는지 짧게 설명한 정보(흔히 Agent Card라고 부릅니다)를 알리고, 다른 에이전트는 그걸 읽어 작업을 보내고 같은 통로로 결과를 받습니다. 새 에이전트를 합류시킬 때 기존 에이전트들을 다시 짜지 않아도 됩니다.
A2A는 MCP와 나란히 놓고 보면 이해가 쉽습니다. 둘은 같은 그림의 다른 절반을 맡습니다. MCP는 한 에이전트를 자기 도구와 데이터(데이터베이스, 캘린더, 파일 시스템)로 아래쪽으로 잇습니다. A2A는 한 에이전트를 다른 에이전트로 옆으로 잇습니다. 에이전트가 자기 도구를 쓸 때는 MCP를, 더 잘 맞는 동료에게 하위 작업을 넘길 때는 A2A를 쓰는 식입니다. 둘은 경쟁이 아니라 보완 관계입니다.
A2A는 프로토콜이지 모델이 아니고, 내려받는 앱도 아닙니다. 그 자체로 어떤 에이전트를 더 똑똑하게 만들거나 더 믿을 만하게 만들지 않습니다. 에이전트가 자신을 알리고, 작업을 보내고, 진행 상황을 전하고, 답을 돌려주는 방식을 표준화할 뿐입니다. 상대 에이전트가 믿을 만한지, 그리고 그 에이전트가 행동해도 되는지는 별개의 문제이고, 여전히 인증과 권한, 사람의 점검이 필요합니다.
비유로 보면
부서마다 전문가가 따로 있는 회사를 떠올려 보세요. 한 사무실 안에서 직원이 자기 책상의 도구를 꺼내 쓰는 모습이 MCP 쪽 그림입니다. A2A는 한 부서 직원이 다른 부서의 전문가에게 전화를 걸어 "이 작업을 맡길게요, 끝나면 결과를 보내 주세요"라고 부탁하는 예절에 가깝습니다. 전화선과 공통의 요청 방식이 있어야, 서로의 내부 서류함을 들여다보지 않고도 처음 보는 사이가 협업할 수 있습니다.
어디에서 만나나
A2A는 일이 에이전트 하나, 팀 하나를 넘어 여러 곳으로 나뉘는 자리에 등장합니다. Google은 커머스, 데이터 스트리밍, DevOps, 통신처럼 요청이 여러 전문 에이전트를 차례로 거치는 예를 들었습니다. 작업을 단계마다 가장 잘 맞는 에이전트에게 보내는 오케스트레이션과 워크플로 시스템에서도 쓰이고, 서로 다른 회사가 만든 에이전트들이 함께 맞물려 돌아가야 하는 생태계에서도 중요합니다.
작은 예시
Google은 서로 다른 언어로 만든 에이전트들이 A2A로 함께 일하는 사례를 소개했습니다. 예를 들어 Python으로 만든 에이전트와 Go로 만든 에이전트가 계약서가 규정에 맞는지 함께 점검하는 식입니다. 두 에이전트를 같은 언어나 프레임워크로 다시 짤 필요 없이, 공통 프로토콜로 작업과 결과를 주고받으며 협업합니다.
자주 하는 오해
한 줄 정리
MCP는 한 에이전트에게 도구와 데이터로 닿는 손을 주고, A2A는 여러 에이전트가 서로 일을 넘기고 인수인계하는 길을 줍니다. 에이전트 사이의 협업을 위한 배관인 셈이고, 시스템이 에이전트 하나를 넘어 커질수록 쓸모가 커집니다. 다만 신뢰와 권한이라는 어려운 질문은 사라지지 않고, 그 인수인계를 어떻게 설계하느냐의 문제로 옮겨 갑니다.
자주 묻는 질문
둘은 잇는 대상이 다릅니다. MCP는 한 에이전트를 자기 도구와 데이터(데이터베이스, 파일 시스템, 캘린더)에 하나의 공통 인터페이스로 이어, 에이전트가 세상에 손을 대게 합니다. A2A는 한 에이전트를 다른 에이전트에 이어, 둘 사이에서 작업을 위임하거나 넘기게 합니다. 간단히 말하면 MCP는 에이전트에서 도구로 내려가는 세로 방향이고, A2A는 에이전트에서 에이전트로 가는 가로 방향입니다. 한 에이전트가 둘을 동시에 쓸 수도 있습니다. 자기 도구에 닿을 때는 MCP, 동료에게 도움을 청할 때는 A2A를 씁니다. 둘은 경쟁이 아니라 보완하는 프로토콜입니다.
둘 다 아닙니다. A2A는 프로토콜, 즉 한 에이전트가 다른 에이전트를 찾아 작업을 보내고 결과를 받는 방식을 정해 둔 규칙입니다. 스스로 생각하거나 답을 만들지 않고, 내려받는 제품도 아닙니다. 실제로 만들거나 돌리는 것은 A2A를 말할 줄 아는 에이전트들과, 각 에이전트가 자신이 무엇을 할 수 있는지 알리는 짧은 설명입니다. 각 에이전트 안의 모델은 그대로이고, A2A는 그들이 서로 대화할 때 쓰는 공통 형식일 뿐입니다. HTTP나 API 표준처럼, 독립된 두 프로그램이 합의한 배관이라고 보면 됩니다. 그 자체가 하나의 애플리케이션은 아닙니다.
두 에이전트가 작업을 주고받을 수 있다는 사실이, 그래도 되는지를 말해 주지는 않습니다. A2A는 요청을 실어 나를 뿐, 보낸 쪽이 그 요청을 할 자격이 있는지나 받은 쪽이 따라야 하는지를 정하지 않습니다. 그래서 신원과 권한은 그 주위에 따로 설계해야 합니다. 연결된 에이전트 하나하나를 외부 서비스처럼 다루세요. 인증으로 그게 정말 누구인지 확인하고, 권한 설정으로 무엇을 요청할 수 있는지 정하며, 결제나 외부 발송처럼 되돌릴 수 없는 동작 앞에는 사람이 승인하는 단계를 둡니다. 위임받은 작업이 슬그머니 자기 범위를 넓히지 않는지, 한 에이전트가 다른 에이전트에게 넘기는 내용 안에 숨어든 지시(프롬프트 인젝션의 사촌격)가 없는지도 살펴야 합니다. 설정 시점의 질문은 MCP 때와 같습니다. 이 에이전트는 남에게 무엇을 요청할 수 있고, 남은 이 에이전트에게 무엇을 요청할 수 있으며, 일이 경계를 넘을 때 책임은 누구에게 있는가.