AI 에이전트 프로토콜 전쟁: 경쟁사들이 하나의 재단에 모인 이유

HTTP가 없는 웹을 상상할 수 있을까요? 브라우저마다 다른 프로토콜을 쓰고, 서버마다 다른 방식으로 응답하는 세상 말입니다. 1990년대 초, 웹은 실제로 그런 혼란 속에 있었습니다. 그리고 지금, AI 에이전트 세계에서 똑같은 일이 벌어지고 있습니다.

Anthropic은 MCP를, Google은 A2A를, OpenAI는 AGENTS.md를 밀고 있습니다. CopilotKit은 AG-UI를 만들었고, IBM은 ACP를 내놓았다가 A2A에 합류했습니다. 에이전트 프로토콜이 난립하는 상황에서, 2025년 12월 놀라운 일이 벌어졌습니다. 서로 경쟁하던 기업들이 Linux Foundation 산하에 하나의 재단을 공동 설립한 것입니다.

이 글에서는 단순한 프로토콜 사용법이 아니라, 왜 이런 일이 벌어지고 있는지를 분석합니다. 웹 표준의 탄생부터 현재의 에이전트 프로토콜 전쟁까지, 역사적 맥락 속에서 이 변화의 의미를 함께 살펴보겠습니다.

프로토콜 전체 지도 — 누가 무엇을 만들었는가

AI 에이전트 생태계에는 여러 프로토콜이 존재합니다. 각각이 해결하려는 문제가 다르기 때문에, 전체 그림을 먼저 이해하는 것이 중요합니다.

MCP (Model Context Protocol) — Anthropic

MCP는 에이전트가 외부 도구와 데이터에 접근하는 방식 을 표준화합니다. "에이전트가 바깥 세상과 어떻게 소통하는가"라는 질문에 대한 답입니다.

2024년 11월에 공개된 이후 폭발적으로 성장했습니다. 2026년 3월 기준으로 월간 SDK 다운로드 9,700만 건을 넘겼고, 활성 서버는 10,000개를 돌파했습니다. Claude, ChatGPT, Cursor, Gemini, VS Code, Microsoft Copilot 등 주요 AI 클라이언트가 모두 MCP를 지원합니다.

MCP의 아키텍처는 3계층 구조입니다.

Host (AI 앱: Claude, Cursor 등)
  └── Client (연결 관리자)
        └── Server (도구 제공자: GitHub API, DB, 파일 시스템 등)

서버가 제공하는 것은 세 가지입니다.

• Tools (모델이 제어): 함수 호출, API 실행
• Resources (앱이 제어): 파일, 데이터베이스 등 컨텍스트 자원
• Prompts (사용자가 제어): 재사용 가능한 프롬프트 템플릿

MCP 서버를 하나 만들어두면, 어떤 AI 클라이언트에서든 같은 도구를 쓸 수 있습니다. USB 포트처럼 연결만 하면 되는 표준 인터페이스인 셈입니다.

A2A (Agent2Agent Protocol) — Google

MCP가 "에이전트와 도구의 연결"이라면, A2A는 "에이전트와 에이전트의 연결" 입니다. 서로 다른 프레임워크, 다른 벤더에서 만든 에이전트들이 어떻게 협력하는가의 문제를 해결합니다.

A2A의 핵심 개념은 세 가지입니다.

• Agent Card (/.well-known/agent.json): 에이전트의 능력과 정보를 JSON으로 공개하여 자동 탐색 가능
• Task 객체: 단순한 요청-응답이 아닌 태스크 생명주기(생성-진행-완료)로 비동기 협업
• Artifact: 작업 결과물을 구조화하여 반환

2025년 4월 발표 이후 Salesforce, SAP, LangChain, Atlassian 등 50개 이상의 기업이 파트너로 참여했습니다. IBM이 독자 개발한 ACP도 2025년 9월 A2A에 합류하면서, 에이전트 간 통신 프로토콜은 A2A로 수렴하는 흐름이 형성되었습니다.

AGENTS.md — OpenAI

AGENTS.md는 다른 프로토콜과 성격이 다릅니다. 리포지토리에 마크다운 파일 형태로 존재하며, AI 코딩 에이전트가 프로젝트의 맥락을 이해하도록 돕는 지침서 표준 입니다.

이미 60,000개 이상의 오픈소스 프로젝트가 채택했고, Cursor, Devin, GitHub Copilot, Gemini CLI 등이 이를 인식합니다. 실제 모습은 이렇습니다.

# AGENTS.md

## 프로젝트 개요
이 프로젝트는 Next.js 14 기반의 블로그 플랫폼입니다.

## 코딩 규칙
- TypeScript strict mode 사용
- 컴포넌트는 함수형으로 작성
- 테스트는 Vitest 사용

## 디렉토리 구조
- src/components/ — UI 컴포넌트
- src/lib/ — 유틸리티 함수
- src/app/ — Next.js App Router 페이지

런타임 프로토콜은 아니지만, 에이전트가 코드베이스를 이해하는 "첫 번째 인터페이스"라는 점에서 프로토콜 생태계의 중요한 한 축을 담당합니다.

AG-UI — CopilotKit

AG-UI는 에이전트 백엔드와 프론트엔드를 실시간으로 연결하는 이벤트 기반 프로토콜 입니다. 양방향 JSON 이벤트 스트림으로 메시지, 도구 호출, 상태 변화를 사용자 인터페이스에 전달합니다. Oracle과 Google이 채택했고, LangGraph, CrewAI 등 주요 에이전트 프레임워크를 지원합니다.

MCP vs A2A — 경쟁이 아닌 레고 블록

MCP와 A2A를 놓고 "어느 쪽이 이기는가"라고 묻는 것은 잘못된 질문입니다. 둘은 서로 다른 문제를 해결합니다.

실전에서 이 두 프로토콜은 함께 작동합니다. 신입 사원 온보딩이라는 복잡한 업무를 예로 들어보겠습니다.

사용자: "김철수 신입사원 온보딩 처리해줘"
     ↓
오케스트레이터 에이전트
     ├── A2A → HR 에이전트 (인사 처리)
     │         └── MCP → 인사 DB 도구 (사원 정보 등록)
     ├── A2A → IT 에이전트 (계정 생성)
     │         └── MCP → 계정 생성 API (이메일, Slack 등)
     └── A2A → 시설 에이전트 (좌석 배정)
               └── MCP → 좌석 배정 시스템 (빈 자리 탐색)

각 에이전트는 MCP로 자신의 도구를 호출 하고, A2A로 다른 에이전트와 결과를 교환 합니다. MCP는 수직 통합, A2A는 수평 통합을 담당하는 것입니다. 이 분리 덕분에 시스템을 더 쉽게 구성하고, 확장하고, 보호할 수 있습니다.

A2A의 Agent Card가 실제로 어떤 모습인지 살펴보겠습니다.

{
  "name": "HR Onboarding Agent",
  "description": "신입사원 온보딩 프로세스를 처리합니다",
  "url": "https://agents.company.com/hr-onboarding",
  "version": "1.0.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": false
  },
  "skills": [
    {
      "id": "employee-registration",
      "name": "사원 등록",
      "description": "인사 시스템에 신규 사원을 등록합니다"
    },
    {
      "id": "document-generation",
      "name": "문서 생성",
      "description": "근로계약서, 보안서약서 등을 생성합니다"
    }
  ]
}

이 Agent Card는 /.well-known/agent.json 경로에 공개됩니다. 다른 에이전트가 이 카드를 읽고, 해당 에이전트가 무엇을 할 수 있는지 자동으로 파악하는 구조입니다. 웹사이트의 robots.txt와 비슷한 개념이라고 생각하면 됩니다.

AAIF — 경쟁사들이 한 테이블에 앉은 이유

2025년 12월 9일, AI 업계에서 이례적인 일이 벌어졌습니다. Anthropic, OpenAI, Block이 공동으로 Linux Foundation 산하에 Agentic AI Foundation(AAIF) 을 설립한 것입니다. 각 사는 자신의 핵심 프로젝트를 기부했습니다.

2026년 2월 기준으로 97개 신규 멤버가 합류하여 총 146개사 가 참여하고 있습니다. Platinum 멤버 8개사는 AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, OpenAI입니다. Gold 멤버에는 JPMorgan Chase, Salesforce, SAP, IBM, Oracle 등 엔터프라이즈 거물들이 포진해 있습니다.

그런데 왜 경쟁사들이 이런 결정을 내렸을까요?

1. 파편화의 역사적 교훈

2000년대 분산 컴퓨팅 표준 전쟁을 기억하시나요? CORBA, DCOM, WS-* 등이 표준을 놓고 싸웠지만, 대부분 실패했습니다. 결국 단순한 REST와 JSON이 승리했습니다.

"벤더들이 자사 고유 통신 프로토콜을 밀면, 다리가 아닌 사일로를 만든다. 에이전트들이 서로 다른 방언을 쓰면 상호 연결이 불가능해진다." — InfoWorld

AAIF는 이 교훈이 반복되지 않도록 조기에 합의한 결과입니다.

2. 네트워크 효과의 수학

모든 에이전트가 같은 프로토콜을 사용하면, 생태계 전체의 가치가 기하급수적으로 증가합니다. 10개의 에이전트가 서로 다른 프로토콜을 쓰면 통합 비용이 O(n^2)로 폭발하지만, 표준 프로토콜이 있으면 O(n)으로 줄어듭니다.

3. 엔터프라이즈 신뢰 확보

기업들은 표준이 확정되기 전까지 대규모 투자를 꺼립니다. 중립적 거버넌스 아래 표준이 관리되면, 벤더 락인 우려 없이 도입할 수 있습니다. AAIF의 Platinum 멤버에 JPMorgan Chase, Bloomberg 같은 금융 기업이 포함된 것은 우연이 아닙니다.

4. "표준 레이어에서 협력, 애플리케이션 레이어에서 경쟁"

이것이 핵심 전략입니다. HTTP를 모든 브라우저가 공유하지만 브라우저 자체는 치열하게 경쟁하듯, 프로토콜은 공유하되 그 위의 AI 제품과 서비스에서 경쟁하는 것입니다. Anthropic이 MCP를 기부해도 Claude의 경쟁력은 MCP 위에서 구축됩니다. 프로토콜 자체가 아니라 그 위의 경험이 차별화 포인트가 됩니다.

W3C의 탄생을 다시 보다 — 역사는 반복되는가

1994년, 웹이 폭발적으로 성장하면서 심각한 문제가 발생했습니다. 같은 HTML 문서가 브라우저마다 다르게 보이는 것이었습니다. Microsoft의 IE와 Netscape가 각자의 HTML 확장을 밀면서, 개발자들은 "IE용 페이지"와 "Netscape용 페이지"를 따로 만들어야 했습니다.

Tim Berners-Lee는 MIT, CERN과 함께 W3C를 설립하고, 경쟁사들을 한자리에 모아 HTML, CSS, HTTP 표준을 만들어냈습니다. 그 결과가 우리가 오늘날 사용하는 웹입니다.

유사성이 놀라울 정도입니다. 하지만 역사에서 배워야 할 경고 도 있습니다.

WHATWG vs W3C — 분열의 교훈

2004년, Mozilla, Apple, Opera는 W3C의 느린 표준화 속도에 불만을 품고 WHATWG를 결성했습니다. 수년간 두 조직이 각각의 HTML 표준을 밀면서 혼란이 지속되었고, 2019년에야 단일 HTML 표준에 합의했습니다.

AAIF는 이런 분열을 처음부터 방지하려는 시도입니다. 프로젝트별 기술적 자율권은 유지하되, 거버넌스는 하나로 통합한 것이 핵심입니다.

SOAP vs REST — 복잡성의 패배

2000년대 WS-* 스펙 군단(SOAP, WSDL, UDDI 등)은 엔터프라이즈 통합의 "완벽한 표준"을 목표로 했지만, 복잡성에 짓눌려 실패했습니다. 단순한 REST와 JSON이 승리한 것입니다.

MCP의 Streamable HTTP와 A2A의 JSON-RPC 설계는 이 교훈을 명확히 반영합니다. 복잡한 바이너리 프로토콜 대신, HTTP와 JSON이라는 웹 개발자에게 익숙한 기반 위에 구축되었습니다.

정부도 움직인다 — NIST AI Agent Standards Initiative

프로토콜 표준화가 민간에서만 진행되는 것은 아닙니다. 2026년 2월 17일, 미국 NIST(국립표준기술연구소)가 AI Agent Standards Initiative 를 발표했습니다.

세 가지 축으로 구성됩니다.

1. 업계 주도 에이전트 표준 개발 및 국제 표준 기구에서의 미국 리더십 촉진
2. 커뮤니티 주도 오픈소스 프로토콜 개발 및 유지 지원
3. AI 에이전트 보안 및 신원(identity) 분야 연구 추진

여기서 주목할 점은 선례입니다. NIST AI Risk Management Framework(2023)는 자발적 가이드라인으로 시작했지만, 18개월 내에 행정명령, 주법, 연방 조달 요건에 반영되었습니다. AI Agent Standards Initiative도 같은 궤적을 따를 가능성이 높습니다. 즉, 지금의 "권고"가 미래의 "규제"가 될 수 있다 는 의미입니다.

회의론과 논쟁점 — 낙관만 할 수 없는 이유

생태계가 아름답게 정리될 것이라는 낙관적 전망만 있는 것은 아닙니다.

경계의 모호성

"이론상 공존할 수 있지만, 실제로는 줄다리기가 벌어질 것이다. 개발자는 그렇게 많은 생태계에 에너지를 투자할 수 없다." — Solomon Hykes, Dagger CEO

도구는 점점 에이전트처럼 행동하고, 에이전트는 도구에 크게 의존합니다. MCP와 A2A의 경계가 이론만큼 깔끔하지 않을 수 있습니다. MCP 서버가 충분히 복잡해지면 사실상 에이전트와 다를 바 없고, 그때 A2A와의 경계는 흐려집니다.

표준 과잉(Standards Fatigue)

MCP, A2A, AG-UI, A2UI, ACP, UCP... 프로토콜이 너무 많습니다. 개발자 입장에서는 어디에 시간을 투자해야 할지 판단하기 어렵습니다. ACP가 A2A에 합병된 것은 통합 방향의 첫 신호이지만, 여전히 정리가 더 필요합니다.

보안 문제

MCP 서버가 급속히 확산되면서 보안 검증이 미흡한 서버가 다수 존재합니다. 누구나 MCP 서버를 만들어 공개할 수 있다는 것은 강점이자 약점입니다. 엔터프라이즈 환경에서의 대규모 도입을 위해서는 보안 표준의 성숙이 필수적입니다.

2026 MCP 로드맵에서 감사 추적, SSO, 게이트웨이 를 엔터프라이즈 우선순위로 명시한 것은 이 문제를 인식하고 있다는 증거입니다.

타임라인으로 보는 흐름 — 18개월의 급변

핵심 사건만 추려서 보면, 이 생태계가 얼마나 빠르게 움직이고 있는지 실감할 수 있습니다.

18개월 만에 프로토콜 공개부터 재단 설립, 정부 차원의 표준화 움직임까지 진행되었습니다. 웹 표준이 수십 년에 걸쳐 형성된 것과 비교하면 압도적인 속도입니다.

개발자에게 미치는 실제 영향

이 모든 변화가 우리 개발자에게 어떤 의미를 가질까요? 시간축별로 정리해보겠습니다.

지금 당장 할 수 있는 것

MCP 서버 개발 은 이미 실전입니다. 자신이 만든 API나 도구를 MCP 서버로 감싸면, Claude, ChatGPT, Cursor 등 모든 주요 AI 클라이언트에서 사용할 수 있습니다. MCP 서버의 기본 구조는 이렇습니다.

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({
  name: "my-service",
  version: "1.0.0",
});

// 도구 정의
server.tool(
  "get-user-info",
  "사용자 정보를 조회합니다",
  { userId: z.string().describe("사용자 ID") },
  async ({ userId }) => {
    const user = await fetchUser(userId);
    return {
      content: [{ type: "text", text: JSON.stringify(user) }],
    };
  }
);

// 서버 시작
const transport = new StdioServerTransport();
await server.connect(transport);

AGENTS.md 작성 도 바로 시작할 수 있습니다. 프로젝트 루트에 파일 하나만 추가하면 Codex, Copilot, Gemini CLI 등이 프로젝트를 더 정확하게 이해합니다.

2026년 후반에 주목할 것

A2A 기반 멀티에이전트 시스템 이 본격화됩니다. 서로 다른 벤더의 에이전트를 조합하여 엔터프라이즈 워크플로우를 구축하는 사례가 등장할 것입니다. A2A의 Agent Card 기반 자동 탐색이 성숙하면, 에이전트 마켓플레이스의 가능성도 열립니다.

중장기 전망

NIST 기준이 업계 표준으로 굳어지면, 프로토콜 준수가 곧 컴플라이언스 가 됩니다. 규제 대응 차원에서도 표준 프로토콜 채택은 선택이 아닌 필수가 될 가능성이 높습니다. 그리고 궁극적으로 MCP+A2A가 HTTP처럼 에이전트를 연결하는 인프라가 되면, 우리는 "에이전트 인터넷"이라는 새로운 계층을 목격하게 될 것입니다.

마무리 — 이것은 기술 선택이 아니라 생태계 참여의 문제

프로토콜 전쟁의 승자는 없습니다. 표준이 승리합니다.

1990년대 IE와 Netscape가 싸운 결과, 승리한 것은 어느 한쪽 브라우저가 아니라 HTML/CSS/HTTP라는 표준이었습니다. 지금 벌어지고 있는 AI 에이전트 프로토콜 경쟁도 같은 결론을 향해 가고 있습니다. AAIF의 설립, ACP의 A2A 합류, NIST의 움직임 — 모두 "하나의 표준"을 향한 수렴의 신호입니다.

개발자로서 우리가 할 일은 명확합니다. 특정 프로토콜의 "승리"에 베팅하는 것이 아니라, 표준 생태계에 참여하는 것 입니다. MCP 서버를 만들어보고, AGENTS.md를 작성하고, A2A의 발전을 지켜보면서 준비하는 것입니다.

HTTP가 탄생하는 순간을 목격한 1994년의 개발자들은 그 의미를 실시간으로 체감하지 못했을 것입니다. 하지만 우리는 지금 그와 같은 순간을 인식하면서 지나가고 있습니다. 2026년 4월 뉴욕에서 열리는 MCP Dev Summit의 95개 이상의 세션은, 이 생태계가 얼마나 빠르게 구체화되고 있는지를 보여주는 또 하나의 증거입니다.

지금 이 순간이 바로 참여를 시작할 때입니다.