시작하게 된 계기: ACP를 찾아갔더니 사라져 있었습니다

저는 MCP, ACP, 그리고 A2A 사이의 차이점을 정리하고 싶었습니다. MCP는 끊임없이 들려오는 이름이었고, A2A는 이름 정도는 알고 있었습니다. ACP는 거의 알지 못했기에, 공식 리포지토리(github.com/i-am-bee/acp)를 열어보았습니다.

README 상단에서 저를 맞이한 내용은 다음과 같았습니다:

ACP는 이제 Linux Foundation 산하의 A2A의 일부가 되었습니다!

해당 리포지토리는 2025년 8월 27일에 아카이브(archived)되었으며 읽기 전용으로 설정되었습니다. 즉, 독립적인 프로토콜로서의 ACP는 끝난 것입니다. ACP는 A2A로 통합되었습니다.

2025년 상반기에 작성된 많은 설명글은 "MCP, ACP, A2A 중 올바른 것을 선택하라"는 내용을 중심으로 구성되어 있습니다. 하지만 2026년의 이 세 가지는 대등한 관계가 아닙니다. MCP와 A2A라는 두 개의 기둥이 존재하며, ACP는 그중 하나로 흘러 들어간 역사의 일부일 뿐입니다.

따라서 이 포스트에서는 먼저 "에이전트는 오직 두 방향으로만 뻗어 나간다"라는 지도를 그려볼 것입니다. 그다음 그 지도 위에 MCP와 A2A를 배치하고, 그 후에 ACP가 어디에 있었으며 어디로 갔는지 설명하겠습니다. 처음부터 끝까지 읽어보시면 이 느슨한 용어들이 하나의 그림으로 맞춰질 것입니다.

사전 지식은 거의 필요하지 않습니다. LLM이 API를 호출하는 것을 본 적이 있다면, 충분히 따라오실 수 있습니다.

전제 조건 1: 무엇이 실제로 무언가를 "AI 에이전트"로 만드는가

프로토콜을 다루기 전에, 용어들을 정렬해 보겠습니다. "LLM"과 "AI 에이전트 (AI agent)"는 혼용되어 사용되기도 하지만, 같은 것은 아닙니다.

LLM 그 자체는 텍스트를 입력받아 텍스트를 반환하는 함수에 가깝습니다. 똑똑하지만, 스스로는 아무것도 할 수 없습니다. 웹을 탐색하거나, 파일을 읽거나, 코드를 실행할 수 없습니다. 그저 당신이 묻는 것에 답할 뿐입니다.

**AI 에이전트 (AI agent)**는 해당 LLM을 두뇌로 사용하여 목표를 향해 작동합니다. 스스로 결정하고, 도구(tools)를 선택하며, 필요한 만큼 루프(loop)를 반복합니다. "다음 주 도쿄 여행을 위한 항공권을 예약해 줘"라고 말하면, 에이전트는 좌석을 검색하고, 가격을 비교하며, 예약 API를 호출합니다. 에이전트는 그 전체 루프를 스스로 구동합니다.

LLM on its own vs an AI agent

기억해야 할 핵심은 다음과 같습니다: 에이전트는 두뇌 (LLM)에 손과 발 (도구, tools)이 더해진 것입니다. 두뇌만으로는 아무것도 할 수 없습니다. 그 손과 발을 어떻게 연결하느냐에 따라 첫 번째 프로토콜이 등장하게 됩니다.

전제 조건 2: 에이전트는 오직 두 방향으로만 뻗어 나갑니다

에이전트가 "외부 세계"와 소통할 때, 실제로는 오직 두 가지 방향으로만 움직입니다. 이 두 방향이 이 포스트 전체의 지도가 됩니다.

1. 하향식, 도구를 사용하기 위해 (수직적 방향, vertical direction): 검색 엔진, 데이터베이스, 내부 API, 파일 시스템 등입니다. 에이전트가 자신의 손과 발로서 "사용하는" 것들입니다. 여기에는 마스터/서번트 (master/servant) 관계가 존재합니다.
2. 수평식, 다른 에이전트와 협업하기 위해 (수평적 방향, horizontal direction): 다른 팀이 만든 에이전트나 다른 회사의 에이전트입니다. 동등한 위치에서 "업무를 넘겨주는" 동료(peer)입니다.

The two directions an agent reaches out: vertical tools, horizontal agents

이 두 방향은 본질적으로 완전히 다릅니다.

• 수직적 (도구): 상대방은 단순한 함수 (function)입니다. 입력을 전달하면 출력을 받습니다. 상대는 생각하지 않습니다. 지시받은 대로 수행할 뿐입니다.
• 수평적 (에이전트): 상대방 또한 두뇌를 가지고 있습니다. 당신은 "수행하고자 하는 것" (의도, intent)을 넘겨주며, 상대는 스스로 그 방법을 찾아냅니다. 때로는 여러 번의 왕복 과정 (round trips)이 필요할 수도 있습니다.

이 수직적(vertical) = MCP, 수평적(horizontal) = A2A 구분은 2026년 현재 사물을 분류하는 표준적인 방식입니다. 이는 누군가의 개인적인 견해가 아닙니다. A2A 사양(spec) 자체에 "A2A 및 MCP" 섹션이 존재하며, 여기서 MCP는 에이전트가 도구(tool)를 사용하는 방식이고, A2A는 에이전트들이 동료(peers)로서 협업하는 방식이라고 정의하며, 이 둘을 경쟁자가 아닌 상호 보완적인 관계로 규정하고 있습니다.

그럼 이제 두 가지를 하나씩 살펴보겠습니다.

MCP: 수직 방향(에이전트 ↔ 도구)을 위한 표준

MCP가 해결한 문제: N×M 배선 지옥 (wiring hell)

MCP (Model Context Protocol)는 Anthropic이 2024년 11월에 발표한 공개 프로토콜입니다. 한 문장으로 요약하자면, LLM에게 도구를 제공하는 표준화된 방식입니다.

왜 굳이 표준화를 해야 할까요? 표준이 없는 세상을 상상해 보세요. N 종류의 LLM (Claude, GPT, Gemini, ...)이 있고, 연결하려는 M 종류의 도구 (Slack, GitHub, Postgres, ...)가 있다고 가정해 봅시다. 표준이 없다면, 모든 쌍에 대해 커스텀 커넥터(custom connector)를 작성해야 합니다. 즉, N×M개의 배선이 필요하게 됩니다.

MCP는 중간에 하나의 **공통 소켓 (common socket)**을 배치합니다. 도구 측은 "MCP 서버 (MCP server)"를 한 번만 구축하면 모든 LLM이 이를 사용할 수 있습니다. LLM 측은 "MCP 클라이언트 (MCP client)"를 한 번만 구현하면 모든 도구에 접근할 수 있습니다. 배선은 N+M으로 줄어듭니다.

MCP collapses N x M wiring into one common socket

USB가 등장하기 전에는 모든 장치마다 고유한 케이블이 필요했습니다. USB는 소켓을 표준화했습니다. MCP는 "LLM과 그 도구들 사이의 USB"입니다.

MCP의 내부 구성: 세 가지 역할과 프리미티브 (primitives)

MCP는 JSON-RPC 2.0 (JSON 형식으로 요청과 응답을 교환하기 위한 단순한 규약) 위에서 작동하며, 진행 과정에서 세션 상태 (session state)를 유지합니다. 여기에는 세 가지 역할이 있습니다.

서버는 주로 세 가지 요소(프리미티브 (primitives)라고 불림)를 노출합니다. 이 요소들을 명확히 파악하면 MCP의 형태가 선명해집니다.

• 도구 (Tools): LLM이 호출할 수 있는 "함수 (functions)"입니다. 예를 들어 create_issue(title, body)와 같이 인자를 전달하면, 무언가를 수행하고 결과를 반환합니다. LLM은 이를 능동적으로 호출합니다.
• 리소스 (Resources): LLM이 읽을 수 있도록 허용하는 "데이터 (data)"입니다. 파일 내용, DB 레코드, 로그 등이 해당하며, URI로 식별됩니다.
• 프롬프트 (Prompts): 미리 준비된 "지침 템플릿 (instruction templates)"입니다. 사용자는 그중 하나를 선택하여 사용합니다.

연결하는 방법(전송 (transport))에는 두 가지가 있습니다. 서버를 로컬 프로세스로 실행하고 표준 입출력 (standard in/out)을 통해 통신하는 stdio, 그리고 HTTP를 통해 연결하는 Streamable HTTP입니다. 로컬 도구는 전자를 사용하고, 원격 서비스는 후자를 사용합니다.

MCP의 현재 위치 (2026년)

MCP는 정체되어 있지 않았습니다. 사양 (spec)은 자주 업데이트되며, 2026년 기준 최신 버전은 **2025-11-25 개정판 (revision)**입니다. 변경 사항의 추세와 방향을 읽어보면 명확해집니다.

• 2025-06-18 개정판: 보안이 중심이 되었습니다. MCP 서버를 OAuth 2.0 "리소스 서버 (resource server)"로 공식 분류하고, 토큰을 특정 서버에 바인딩합니다. 또한 구조화된 출력 (structuredContent)과 유도 (elicitation) (대화 중간에 사용자에게 추가 입력을 요청하는 기능)를 추가했습니다.
• 2025-11-25 개정판: 권한 부여 (authorization) 기능이 더욱 강화되었습니다 (OpenID Connect Discovery 지원 등). 또한 장시간 실행되는 작업을 추적하기 위한 태스크 (tasks) (실험적 기능)를 추가했습니다.

MCP는 "단순히 도구를 연결하는 것"으로 시작했으나, 점차 "누가 이 도구를 사용할 수 있는가" (인증 (authn) 및 인가 (authz)) 쪽으로 무게 중심을 옮겨왔습니다. 도구에 내부 DB와 결제 API가 포함되기 시작하면, 이는 자연스러운 발전 과정입니다.

A2A: 수평적 방향(agent ↔ agent)을 위한 표준

MCP가 한계에 부딪히는 지점

MCP는 도구(tools)를 연결합니다. 하지만 상대방이 도구가 아니라 또 다른 에이전트(agent)라면 어떻게 될까요?

예를 들어, 귀사의 여행 예약 에이전트가 파트너사의 "항공권 예약 에이전트"에게 업무를 넘기고자 한다고 가정해 봅시다. 이때 상대방은 다음과 같은 특성을 갖습니다:

• 자체적인 두뇌(LLM)를 가지고 있습니다. 즉, 귀사의 명령을 일대일로 실행하는 도구가 아닙니다.
• "다음 주 오사카행 항공권을 3만 엔 미만, 좌석 확보 조건으로 예약해 줘"와 같은 **의도 (intent)**가 주어지면, 어떤 예약 API를 어떻게 호출할지 스스로 결정합니다.
• 단 한 번의 왕복(round trip)으로 끝나지 않습니다. "그날은 만석입니다. 앞뒤 3일 이내로 조정해 볼까요?"와 같이 되묻기도 합니다 (멀티턴 교환 (multi-turn exchange)).

MCP의 "함수 한 번 호출 (call a function once)" 모델로는 이를 표현할 수 없습니다. 바로 이 지점에서 A2A (Agent2Agent)가 등장합니다.

A2A의 탄생 배경

A2A는 Google이 2025년 4월에 발표한 프로토콜입니다. 그 이후의 전개는 매우 빨랐습니다.

• 2025년 6월 23일, Linux Foundation 산하의 공식 프로젝트가 되었습니다 (100개 이상의 기업이 참여). 이는 특정 벤더의 소유물이 아닌 중립적인 표준이 되었음을 의미합니다.
• 2026년 3월 12일, v1.0.0 버전에 도달하며 안정적인 릴리스를 마쳤습니다.

A2A의 목표는 서로 다른 벤더와 프레임워크로 구축된 **불투명한 에이전트 (opaque agents)**들이 서로의 내부 상태나 도구에 접근하지 않고도 협업할 수 있도록 하는 것입니다. 소스 코드를 import 할 수 없고, 다른 곳에서 실행되며, 타인이 소유한 에이전트라 할지라도 여전히 업무를 맡길 수 있게 됩니다.

A2A의 내부 구성: 에이전트 카드(Agent Card)와 태스크(Task)

A2A에서 가장 먼저 파악해야 할 것은 에이전트 카드 (Agent Card) (에이전트의 명함)입니다. 각 에이전트는 이를 /.well-known/agent-card.json 경로에 JSON 형식으로 게시하며, 다음 내용을 포함합니다:

• 무엇을 할 수 있는지 (기술 및 역량 (skills and capabilities))
• 어디로 연결해야 하는지 (엔드포인트 (endpoint))
• 호출을 위해 어떤 인증 (auth)이 필요한지 (Bearer 토큰? mTLS?)

호출자는 먼저 이 카드를 읽습니다. 런타임(runtime)에 "이 대상이 무엇을 할 수 있고 어떻게 인증해야 하는지"를 학습한 다음, 실제 요청을 보냅니다. 상대방의 API 규약 (API contract)에 맞춰 미리 구축해 둘 필요가 없습니다.

작업의 단위는 Task입니다. Task는 고유 ID를 가지며 상태(state)를 거칩니다 (submitted → working → input-required → completed 등). 아무리 느린 작업이라도 그 상태를 추적하면서 진행 상황을 확인할 수 있습니다.

A2A flow: read the Agent Card, then run a stateful task

이