18개월 동안 네 개의 새로운 프로토콜 약어가 등장했지만, 대부분의 엔지니어들은 여전히 이들이 서로 어떻게 연관되는지 설명하지 못합니다. 이것은 지식의 공백이 아니라, 문서화의 실패입니다.

저는 지난 한 달 동안 정확히 똑같은 대화를 세 번 나누었습니다. 매번 똑똑한 엔지니어가 이렇게 묻습니다: "잠깐만요, 우리가 A2A를 사용한다면 여전히 MCP가 필요한가요?" 대답은 '예'입니다, 언제나 '예'입니다. 그리고 이 질문이 계속해서 나온다는 사실은 이 분야가 얼마나 형편없이 설명되고 있는지를 말해줍니다.

MCP, A2A, A2UI, 그리고 AG-UI는 서로 경쟁하는 표준이 아닙니다. 이들은 동일한 문제를 해결하지 않습니다. 심지어 아키텍처(Architecture)의 동일한 계층에서 작동하지도 않습니다. 혼잡하고 혼란스러운 표준 지형처럼 보이는 것은 사실 계층화된 상호운용성 스택(Interoperability Stack)의 시작이며, 이는 에이전틱 시스템(Agentic Systems)을 위한 TCP/IP의 순간입니다.

이 글은 그 지도를 그립니다. 과장도 없고, 승자 독식의 서사도 없습니다. 오직 아키텍처(Architecture)뿐입니다.

요약 (TL;DR) — 네 줄 요약

시간이 없으신가요? 전체 내용을 표로 정리했습니다:

그 어떤 것도 REST API를 대체하지 않습니다. 네 가지 모두 동일한 시스템 내에서 동시에 실행될 수 있으며, 종종 그래야만 합니다.

graph LR
    User([User])
    FE[Frontend App]
...

이 글의 나머지 부분에서는 각 계층이 왜 존재하는지, 그것이 없으면 무엇이 잘못되는지, 그리고 여전히 남아있는 간극은 무엇인지에 대해 심도 있게 설명합니다.

문제점: 프로토콜 피로도는 실재한다

2023년에 AI 애플리케이션을 구축한다는 것은 모델을 선택하고, 프롬프트 (Prompt)를 작성하고, REST API를 연결하는 것을 의미했습니다. 다루어야 할 범위가 관리 가능한 수준이었습니다. 대부분의 팀은 전체 시스템을 머릿속에 담을 수 있었습니다.

2026년 중반에 이르면, 프로덕션 AI 시스템은 도구 레지스트리 (Tool Registries), 멀티 에이전트 조정 (Multi-agent Coordination), 스트리밍 이벤트 버스 (Streaming Event Buses), 그리고 선언적 UI 생성 (Declarative UI Generation)을 포함하게 됩니다. 이 지형을 탐색하는 팀들은 합리적인 질문을 던지고 있습니다:

• A2A가 MCP를 대체하나요? 둘 다 "에이전트 프로토콜 (agent protocols)"이라고 불리는데 말이죠.
• AG-UI와 A2UI의 차이점은 무엇인가요? 둘 다 사용자 인터페이스 (user interfaces)를 언급하고 있습니다.
• 이 중 어떤 것이 REST API를 대체하나요?
• 우리는 실제로 지금 당장 무엇을 채택해야 할까요?

이러한 혼란은 이해할 수 있습니다. 이 프로토콜들은 서로 다른 조직에서, 서로 다른 시기에, 진정으로 서로 다른 문제들을 해결하기 위해 등장했습니다. 누구도 앉아서 이 스택을 위에서 아래로 설계하지 않았습니다. 이는 바텀업 (bottom-up) 방식으로 나타나고 있으며, 즉 일관된 그림을 조각들을 모아 조립해야 한다는 것을 의미합니다.

그 그림은 다음과 같습니다.

핵심 4요소: 각 프로토콜이 실제로 하는 일

MCP (Model Context Protocol) — AI 툴링의 "USB-C"

정의: MCP는 Anthropic에 의해 개발되었으며 2024년 말에 오픈 소스로 공개되었습니다. 이는 AI 모델이 도구 (tools)를 발견하고 호출하며, 데이터 소스에 접근하고, 로컬 또는 엔터프라이즈 리소스와 통합하는 방식을 표준화합니다. 아키텍처는 클라이언트-서버 (client-server) 구조입니다. MCP 호스트 (사용자의 AI 애플리케이션)가 stdio, SSE 또는 HTTP를 통한 JSON-RPC를 사용하여 표준화된 인터페이스를 통해 MCP 서버 (도구 제공자)에 연결됩니다.

비유: USB-C. USB-C 이전에는 모든 주변 기기에 각기 다른 케이블이 필요했습니다. USB-C 이후에는 규격을 준수하는 모든 장치가 규격을 준수하는 모든 호스트에 연결됩니다. MCP는 AI 도구에 대해 동일한 역할을 수행합니다. 규격을 준수하는 모든 도구 제공자는 규격을 준수하는 모든 AI 애플리케이션에 연결될 수 있으며, 매번 페어링을 위한 맞춤형 글루 코드 (glue code)가 필요하지 않습니다.

실제 사례: 로컬 파일 시스템을 읽는 Claude Desktop. 내부 지식 베이스를 쿼리하는 Cursor. CRM, 코드 저장소, 티켓팅 시스템에서 정보를 가져오는 엔터프라이즈 AI 어시스턴트 — 이 모든 것이 동일한 프로토콜을 통해 이루어지며, 그 중 어느 것도 맞춤형 커넥터 (bespoke connector)를 필요로 하지 않습니다. 하나의 Postgres MCP 서버를 구축하면 어디에서나 작동합니다.

혼동하기 쉬운 점: MCP는 에이전트를 _도구 (tool)_에 연결하는 것에 관한 것입니다. 도구는 호출되었을 때 응답할 뿐, 목표나 에이전시 (agency)를 가지고 있지 않습니다. 이 차이는 매우 중요한데, 다음 프로토콜인 A2A는 완전히 다른 종류의 관계를 위한 것이기 때문입니다.

MCP는 여기 언급된 네 가지 중 가장 성숙한 단계에 있습니다. 사양(spec)이 안정적이고, TypeScript 및 Python SDK가 견고하며, 서버 생태계도 상당히 성장했습니다. 오늘날 AI 도구 통합(tool integration)을 구축하고 있다면, 바로 여기서 시작해야 합니다.

graph LR
    Host[AI Application\nMCP Host]
    Host <-->|MCP| S1[MCP Server\nFilesystem]
...

A2A (Agent-to-Agent) — AI를 위한 B2B 네트워크

정의: A2A는 Google에 의해 발표되었으며, 여러 클라우드 및 엔터프라이즈 파트너들이 참여했습니다. 이는 서로 다른 프레임워크(framework)를 기반으로 구축되고 서로 다른 인프라(infrastructure)에서 실행되는 자율 에이전트(autonomous agents)들이 서로를 발견하고, 작업을 위임하며, 장기적인 작업(long-running work)에 대해 협업할 수 있도록 합니다. 에이전트들은 기계가 읽을 수 있는 역량 프로필인 "에이전트 카드(Agent Card)"를 게시합니다. 통신은 HTTP 기반의 JSON-RPC를 통해 이루어지며, 상태 업데이트 스트리밍을 위해 SSE(Server-Sent Events)를 사용합니다.

실제 사례: 여행 계획 에이전트가 게시된 에이전트 카드를 통해 항공권 예약 에이전트를 발견합니다. 그리고 티켓 검색 및 구매를 장기 작업으로 위임합니다. 예약 에이전트는 요금 조회 및 결제를 진행하는 동안 구조화된 상태 업데이트를 전송합니다. 공유된 코드베이스(codebase)도 없고, 중간에 개입하는 인간 조정자(human coordinator)도 없습니다.

이것이 왜 단순한 "더 화려한 API 호출"이 아닌가: 양측 모두 자율적입니다. 양측 모두 내부 상태(internal state), 목표(goals), 그리고 각자의 제약 조건(constraints)을 가지고 있습니다. A2A는 단순히 "이 함수를 호출하고 응답을 받는다"는 수준이 아니라, 신뢰 경계(trust boundaries)를 넘어선 진정한 에이전트 간 협업(agent-to-agent coordination)을 위해 설계되었습니다.

A2A는 클라우드 및 엔터프라이즈 커뮤니티 전반에서 실질적인 주목을 받고 있습니다. 여러 주요 플랫폼들이 A2A 호환 에이전트를 발표했습니다. 2026년 중반 기준으로 광범위한 프로덕션 도입은 아직 초기 단계이지만, 지금부터 평가를 시작하기에 충분할 만큼 방향성은 명확합니다.

sequenceDiagram
    participant OA as Your Agent
    participant AC as Agent Card Registry
...

A2UI (Agent-to-User Interface) — 선언적 메뉴

정의: A2UI는 실행 가능한 코드를 전송하지 않고 에이전트가 사용자 인터페이스(User Interface, UI)에 대해 어떻게 통신할 것인가라는 구체적인 문제를 다룹니다. 에이전트가 임의의 HTML이나 JavaScript를 생성하여 주입하는 대신, A2UI 방식의 에이전트는 구조화된 UI 의도(UI intent)를 선언합니다. 예를 들어, "사용자가 날짜 범위를 선택해야 합니다" 또는 "승인을 위해 이 세 가지 옵션을 제시하십시오"와 같이 선언하면, 호스트 애플리케이션이 자체 컴포넌트를 사용하여 이를 렌더링합니다.

비유: 레스토랑 메뉴와 같습니다. 메뉴는 표준화된 형식으로 무엇을 이용할 수 있는지 설명합니다. 준비와 전달은 주방, 직원, 디자인 언어가 담당합니다. 메뉴에는 레시피가 포함되어 있지 않습니다. 즉, 이용 가능한 것과 그것이 만들어지는 방식을 분리합니다.

실제 사례: 비용 승인 워크플로(Workflow)를 처리하는 에이전트는 구조화된 양식 명세(Form spec)를 선언합니다. 호스트 애플리케이션은 조직의 디자인 시스템, 접근성 설정, 권한 모델을 그대로 유지한 채 이를 네이티브 UI로 렌더링합니다. 에이전트는 의도를 설명하고, 애플리케이션은 렌더링을 처리합니다.

솔직한 주의사항: 공식적인 프로토콜 명세로서의 A2UI는 네 가지 중 가장 초기 단계에 있습니다. 개념은 타당합니다. 에이전트가 임의의 프론트엔드 코드를 주입하여 문제를 겪은 팀들이 독립적으로 정확히 이 패턴에 도달하는 것을 목격했으며, 여러 프레임워크가 이 지점으로 수렴하고 있습니다. 하지만 단일한 권위 있는 표준은 아직 형성 중입니다. 현재 이를 구현하는 팀들은 일반적으로 자신들만의 스키마 컨벤션(Schema convention)을 바탕으로 작업하고 있습니다.

graph TD
    AR[Agent Runtime]
    Spec[UI Intent Declaration
schema and options]
...

AG-UI (Agent-User Interaction) — 실시간 이벤트 스트림

정의: AG-UI는 주로 CopilotKit 팀이 주도하고 있는 신흥 오픈 프로토콜로, 백엔드 에이전트 런타임(Agent runtime)과 프론트엔드 간의 실시간 이벤트 전송을 표준화합니다. 이는 토큰 스트리밍(Token streaming), 도구 호출(Tool invocation), 상태 전환(Status transition), 인간 참여형(Human-in-the-loop) 일시 중지 및 재개와 같은 구조화된 이벤트 어휘(Vocabulary)를 정의합니다.

비유: 상호작용이 가능한 피드(feed)가 포함된 라이브 방송과 같습니다. 정적인 페이지 로드(page load)가 아니라, 프론트엔드(frontend)가 도착하는 대로 처리하고 렌더링하는 연속적인 이벤트 스트림(stream of events)입니다. AG-UI는 불투명한 백엔드(backend) 프로세스를 관찰 가능하고 상호작용 가능한 경험으로 바꾸는 역할을 합니다.

실제 사례: 실제로 무슨 일이 일어나고 있는지 확인할 수 있는 고객 지원 코파일럿(copilot):

• 에이전트(agent)가 글을 쓸 때 스트리밍되는 응답 토큰(Response tokens)
• 도구(tool)가 실행될 때 나타나는 "지식 베이스 검색 중..."
• 인라인(inline)으로 표시되는 도구 파라미터(parameters) 및 결과
• 에이전트에게 권한이 필요할 때 승인 프롬프트(prompt)와 함께 나타나는 일시 중지 상태
• 인간이 승인하면 재개되는 실행

핵심 통찰: 당신은 아무 일도 일어나고 있지 않은지 의문이 드는 스피너(spinner)를 멍하니 바라보고 있지 않게 됩니다. 에이전트가 단계별로 작업하는 것을 지켜보며, 어느 시점에서든 개입할 수 있습니다. 이것이 바로 AG-UI가 가능하게 하는 것이며, 이벤트 시퀀스(sequence of events)로 나타나면 다음과 같습니다:

이것이 없다면 에이전트는 블랙박스(black boxes)입니다. 사용자는 스피너를 바라보며 행운을 빌 뿐입니다. 데모(demo)용으로는 괜찮을지 몰라도, 프로덕션(production) 환경에서는 적절하지 않습니다.

지금 이것이 중요한 이유: 투명성(Transparency)과 인간 참여형(human-in-the-loop)은 마지막에 덧붙이는 기능이 아닙니다. 실제 거버넌스(governance)가 작동하는 모든 엔터프라이즈(enterprise) 맥락에서 이는 점점 더 필수적인 요구사항이 되고 있습니다. AG-UI는 각 팀이 처음부터 직접 구축할 필요 없이 이 두 가지를 모두 가능하게 하는 이벤트 스트림(event stream)을 제공합니다.

A2UI와 마찬가지로, AG-UI는 MCP보다 표준화 라이프사이클(standardisation lifecycle)의 초기 단계에 있습니다. 이 사양(spec)은 공식적인 표준화 프로세스보다는 커뮤니티 채택을 통해 안정화되고 있습니다.

sequenceDiagram
    participant UI as What You See
    participant AR as Agent
...

프로토콜 요약 (Protocol Summary)

이들이 결합되는 방식: 계층형 아키텍처 (How They Fit Together: A Layered Architecture)

이 프로토콜들이 서로 중복되는 것처럼 보이는 이유는 각각을 고립된 상태로 설명하기 때문입니다. 이들을 스택(stack)에 나란히 배치하면 그림이 명확해집니다:

+----------------------------------+
| 사용자 경험 계층 (User Experience Layer) |
| A2UI + AG-UI |
| ... |
+----------------------------------+

도구 및 컨텍스트 계층 (Tool & Context Layer, MCP): 이곳은 에이전트가 능력을 얻는 곳입니다. 파일을 읽거나, 데이터베이스를 쿼리하거나, API를 호출합니다. MCP는 멀티 에이전트 조정(multi-agent coordination)이나 사용자 인터페이스(user interfaces)에는 관심이 없습니다. MCP는 단 하나의 질문에 답합니다: 에이전트가 실제로 무엇을 보고 무엇을 할 수 있는가?

에이전트 조정 계층 (Agent Coordination Layer, A2A): 능력, 권한 또는 도메인 측면에서 단일 에이전트가 처리할 수 있는 범위를 초과하는 작업이 발생할 때, A2A가 위임(delegation)을 처리합니다. A2A는 에이전트 사이에서 작동하며, MCP는 에이전트와 도구 사이에서 작동합니다. 서로 다른 관계이며, 서로 다른 프로토콜입니다.

사용자 경험 계층 (User Experience Layer, A2UI + AG-UI): A2UI는 사용자가 무엇을 보고 상호작용해야 하는지(what)를 설명합니다. AG-UI는 그것이 어떻게 전달되는지(how)를 처리합니다. 즉, 에이전트의 동작을 불투명한 상태가 아닌 관찰 가능한 상태로 만드는 실시간의 점진적인 이벤트 흐름(live, incremental event flow)을 담당합니다. 동일한 계층에 있는 상호 보완적인 문제입니다.

기존 인프라 (Existing Infrastructure): 데이터베이스, REST API, GraphQL 서비스 등 이 중 어느 것도 사라지지 않습니다. MCP 서버는 종종 기존 API를 래핑(wrap)합니다. A2A 에이전트는 종종 기존 서비스의 전면(front)에 위치합니다. 새로운 프로토콜은 에이전트의 동작을 규정할 뿐, 하단의 인프라를 대체하지 않습니다.

네 가지 프로토콜이 모두 작동하는 시스템은 다음과 같은 모습입니다:

graph TB
    User([사용자]) --> FE[프론트엔드 애플리케이션]

...

각 엣지(edge)는 프로토콜 경계입니다. 프론트엔드는 데이터베이스에 직접 닿지 않습니다. 에이전트 런타임(agent runtime)은 가공되지 않은 HTML을 생성하지 않습니다. 예약 에이전트는 오케스트레이션(orchestrating) 에이전트와 코드를 공유하지 않습니다. 프로토콜은 이 이음새(seams)를 관리하며, 이러한 분리가 시스템을 유지 관리 가능하고, 교체 가능하며, 안전하게 확장할 수 있도록 만듭니다.

세 가지 흔한 오해

오해 #1: "A2A가 MCP를 대체한다"

아닙니다. 그들은 서로 다른 계층에서 서로 다른 문제를 해결하고 있을 뿐입니다. 결론은 명확합니다.

MCP는 에이전트 ↔ 도구 (Agent ↔ Tool) 관계입니다. 에이전트는 무언가를 하고 싶어 하며(파일 읽기, 데이터베이스 쿼리 등), 도구는 이에 응답합니다. 이는 종속적인 관계입니다. 도구는 스스로의 목표를 가지고 있지 않습니다.

A2A는 **에이전트 ↔ 에이전트 (Agent ↔ Agent)**입니다. 양측 모두 자율적입니다. 양측 모두 상태(state), 목표(goals), 그리고 내부적인 복잡성(internal complexity)을 가집니다. A2A 상호작용은 몇 시간에 걸쳐 지속될 수 있으며, 역량 협상(capability negotiation)을 포함하고, 실제적인 결과가 따르는 위임된 작업 소유권(delegated task ownership)을 포함할 수 있습니다.

데이터베이스는 목표를 가지고 있지 않습니다. 예약 에이전트(booking agent)는 목표를 가지고 있습니다. 이들은 진정으로 다른 프로토콜을 필요로 합니다. MCP 도구를 A2A를 준수하는 에이전트로 감쌀 수 있을까요? 기술적으로는 가능합니다. 하지만 그렇게 해야 할까요? 도구가 진정으로 자율적인 행동(autonomous behaviour)을 필요로 하지 않는 한, 그렇게 해서는 안 됩니다. 자율적 행동이 필요 없는 곳에 도입하는 것은 이유 없는 조정 오버헤드(coordination overhead)만 추가할 뿐입니다.

오해 #2: "AG-UI와 A2UI는 같은 것이다"

두 가지는 다르며, 이 둘을 혼동하면 이후 단계에서 실제적인 설계 문제로 이어집니다.

A2UI는 구조(structure)를 정의합니다 — 사용자가 무엇을 보아야 하는가? 양식(form), 날짜 선택기(date picker), 승인 대화 상자(approval dialog) 등입니다. 렌더링 코드(rendering code)가 아닌 선언적 의도(declarative intent)입니다.

AG-UI는 전송(transport)을 정의합니다 — 에이전트의 실시간 활동이 어떻게 프론트엔드에 도달하는가? 스트리밍되는 토큰(streamed tokens), 도구 이벤트(tool events), 상태 전이(status transitions), 일시 중지/재개 상태(pause/resume states) 등입니다. 즉, 이벤트 버스(event bus)입니다.