MCP vs A2A — 도구에 꽂는 연결과 에이전트끼리의 대화

MCP가 “에이전트에 도구를 꽂는 법”을 표준화하자 자연스럽게 다음 질문이 나왔다. 에이전트가 다른 에이전트와 협업하려면? 이 자리를 노리는 프로토콜이 A2A(Agent2Agent)다. Google이 2025년에 공개했고 이후 Linux Foundation으로 이관되어 중립 표준을 지향하고 있다. 둘은 경쟁 규격처럼 소개되곤 하지만, 실제로는 연결의 방향이 다르다. MCP는 에이전트에서 아래로 내려가는 연결이고, A2A는 에이전트끼리 옆으로 이어지는 연결이다.

MCP — 상대는 함수다

MCP에서 서버가 노출하는 도구는 입력 스키마와 출력이 정해진 함수에 가깝다. 클라이언트가 tools/call로 인자를 보내면 서버는 결과를 돌려주고, 호출 한 번은 거기서 끝난다. 상대가 어떻게 구현됐는지는 몰라도 되지만, 무엇을 받고 무엇을 주는지는 스키마로 완전히 공개되어 있다. 판단은 도구를 부르는 쪽 LLM이 하고, 서버는 시키는 일을 수행한다.

A2A — 상대는 또 하나의 행위자다

A2A가 상정하는 상대는 함수가 아니라 자기 판단으로 움직이는 에이전트다. 여기서는 요청 하나가 즉답으로 끝나지 않는다. 몇 분, 며칠씩 걸리는 작업을 맡길 수 있어야 하고, 중간에 “정보가 더 필요하다”며 상대가 되물을 수도 있다. 그래서 A2A의 중심 단위는 함수 호출이 아니라 Task다. Task는 제출됨·작업 중·입력 대기·완료 같은 상태를 가지는 생명주기로 관리되고, 결과물은 Artifact로 돌아온다.

상대 에이전트를 찾는 방법도 다르다. A2A 에이전트는 자신이 무엇을 할 수 있는지를 담은 Agent Card라는 JSON 문서를 공개하고, 다른 에이전트는 이를 읽고 협업 상대를 고른다. 구조를 단순화하면 이런 모양이다.

{
  "name": "translation-agent",
  "description": "문서를 받아 지정한 언어로 번역한다",
  "url": "https://agents.example.com/translate",
  "skills": [
    {
      "id": "translate-doc",
      "name": "문서 번역",
      "description": "마크다운 문서를 번역하고 서식을 보존한다"
    }
  ]
}

MCP의 도구 목록과 닮아 보이지만 결정적 차이가 있다. 도구 스키마는 “이 인자를 넣으면 이 결과가 나온다”는 계약이고, Agent Card는 “나는 이런 일을 할 줄 안다”는 소개다. 어떻게 해낼지, 내부에서 어떤 모델과 도구를 쓸지는 드러내지 않는다. 상대는 불투명한 블랙박스로 남고, 대화는 자연어 메시지로 오간다.

나란히 놓고 보면

	MCP	A2A
연결 방향	에이전트 → 도구·데이터	에이전트 ↔ 에이전트
상대의 정체	스키마가 공개된 함수	내부가 불투명한 행위자
호출 단위	도구 호출 한 번	생명주기를 가진 Task
소통 방식	구조화된 인자·결과	메시지 교환(자연어 포함)
발견 방법	서버 접속 후 tools/list	공개된 Agent Card

언제 무엇이 필요한가

판단 기준은 상대에게 무엇을 기대하느냐다. 결과가 결정적이고 즉시 돌아와야 하는 일 — 파일 읽기, DB 조회, 이 블로그의 글 발행처럼 — 은 MCP 도구로 만드는 편이 맞다. 반대로 상대가 스스로 계획을 세우고 여러 단계를 거쳐야 하는 일 — 조사를 맡기고 보고서를 받는 식의 위임 — 은 A2A가 겨냥하는 영역이다.

그래서 한 에이전트가 두 프로토콜을 동시에 쓰는 그림이 자연스럽다. 자기 손발이 되는 도구는 MCP로 꽂고, 동료 에이전트와는 A2A로 대화하는 식이다. Google도 A2A를 MCP의 대체가 아니라 보완으로 소개했다. 다만 MCP가 이미 클라이언트 생태계에 넓게 자리 잡은 것과 달리, A2A는 아직 표준이 자리를 잡아가는 단계라 실제로 마주칠 일은 상대적으로 적다. 지금 시점에 기억할 것은 하나다 — 도구를 꽂을 거면 MCP, 에이전트에게 일을 맡길 거면 A2A.