• AWS가 승리한 이유는 성능이 아니라 「전 세계 개발자가 참여할 수 있는 표준 기반」을 만들었기 때문
• AI 시대에도 동일한 역학이 작용하고 있으며, 현재 MCP · A2A · Function Calling의 3가지 프로토콜이 표준을 다투고 있음
• 2026년 시점에서 MCP가 유력한 표준 후보로서 급속히 보급되고 있으나, 이 승인 또한 AWS와 동일한 「여백의 설계」에 있음

클라우드 서비스를 선택할 때, 많은 기업과 개발자는 AWS를 선택지에 넣습니다.

하지만, 왜 AWS일까요? 단순히 성능이 높아서, 혹은 가격이 저렴해서일까요?

실제로는 그것만으로는 설명할 수 없습니다. AWS가 전 세계에서 이용되는 가장 큰 이유는, 전 세계 개발자가 참여할 수 있는 「표준 기반 (Standard Infrastructure)」을 만들었다는 것에 있습니다.

그리고 이 「표준화의 역학 (Dynamics of Standardization)」은 지금 AI 세계에서 완전히 동일한 형태로 반복되고 있습니다. 본 기사에서는 AWS의 성공 요인을 분석한 후, AI 시대에 진행 중인 프로토콜 표준화 경쟁 (MCP vs A2A vs Function Calling)을 동일한 프레임워크로 풀어봅니다.

IT의 역사를 보면, 최고 성능의 기술이 승리한 것은 아닙니다.

승패를 가른 것은, 얼마나 많은 참가자가 생태계 (Ecosystem)에 가담했는가입니다. 표준이 되면 이용자가 늘어나고 → 대응 서비스가 늘어나고 → 다시 이용자가 늘어나는 네트워크 효과 (Network Effect)가 발생합니다.

AWS는 단순한 서버 대여 서비스가 아닙니다. 클라우드 시스템을 구축할 때의 「공통 부품」을 제공했습니다.

하지만 중요한 것은 서비스의 수가 아닙니다. 전 세계 개발자들이 「AWS로 만드는 방법」을 공유하게 되었다는 점입니다. Stack Overflow의 답변, Terraform의 모듈, CDK의 컨스트럭트 라이브러리 (Construct Library), Qiita의 기술 기사. 이 모든 것이 「AWS 위에서 구축하기 위한 공유 지식」으로서 축적되었습니다.

즉, AWS는 클라우드 개발의 공통 언어가 된 것입니다.

표준화에서 중요한 것은 모든 것을 완성하는 것이 아닙니다. 오히려 「타자가 참여할 수 있는 여지」를 남겨두는 것입니다.

Linux가 확산된 이유도 누구나 이용할 수 있고, 누구나 개선할 수 있는 환경이었기 때문입니다. AWS도 마찬가지로, AWS만으로 폐쇄된 세계를 만드는 것이 아니라 개발자 · 기업 · OSS 커뮤니티 · 파트너 기업이 참여할 수 있는 장을 만들었습니다.

이 「여백의 설계 (Design of Margin)」는 후술할 MCP의 성공 요인과 완전히 동일한 구조를 가지고 있습니다.

생성형 AI 시대에 들어서며 많은 사람은 「어떤 AI 모델이 가장 똑똑한가」에 주목하고 있습니다. 하지만 역사의 법칙에 따르면 성능만으로는 최종 승자를 결정할 수 없습니다.

중요한 것은, 누가 AI를 사회에 편입시키기 위한 표준 기반을 만드는가입니다.

2026년 현재, AI 연동의 표준을 둘러싸고 3가지 프로토콜이 경쟁하고 있습니다.

OpenAI가 2023년 6월 GPT-3.5-turbo에서 도입한, LLM이 외부 도구를 호출하게 하는 메커니즘입니다.

# Function Calling의 기본 구조
tools = [
{
...

특징: 심플하고 낮은 레이턴시 (Low Latency). OpenAI의 API 내에 닫힌 구조.

한계: 벤더 락인 (Vendor Lock-in). OpenAI 이외의 모델에서 동일한 도구 정의를 재사용할 수 없음. M개의 모델 × N개의 도구로 인해 M×N의 개별 구현이 필요함 (M×N 문제).

Anthropic이 2024년 11월에 공개하고, 2025년 12월에 Linux Foundation 산하의 Agentic AI Foundation (AAIF)에 기증된 오픈 프로토콜입니다.

┌─────────────┐ JSON-RPC 2.0 ┌─────────────┐
│ MCP Host │◄────────────────────►│ MCP Server │
│ (Claude, │ stdio / HTTP │ (GitHub, │
...

특징: 벤더 중립 (Vendor Neutral). 한 번 작성한 MCP 서버는 Claude, ChatGPT, Cursor, VS Code 등 모든 MCP 대응 클라이언트에서 이용할 수 있음. M×N 문제를 M+N으로 축소함.

규모 (2026년 7월 시점): Anthropic의 공식 발표(2025년 12월)에 따르면, 월간 9,700만 건 이상의 SDK 다운로드(Python + TypeScript)를 기록했습니다. GitHub Search API의 공개 데이터에 따르면, 15,900개 이상의 리포지토리가 mcp-server 토픽을 보유하고 있습니다(2026년 5월 시점). AAIF 참여 조직은 146개사(JPMorgan Chase, American Express, Autodesk, Red Hat, Huawei 등)입니다.

Google이 2025년 4월 Cloud Next에서 발표한 에이전트 간 통신 프로토콜입니다.

특징: MCP가 '모델 ↔ 도구 (Model ↔ Tool)'의 수직적 연결을 담당하는 반면, A2A는 '에이전트 ↔ 에이전트 (Agent ↔ Agent)'의 수평적 연계를 담당합니다. Agent Card를 통한 능력 공개, 작업 위임, 비동기 처리를 지원합니다.

MCP와의 관계: 경쟁 관계가 아닌 보완 관계입니다. Google 스스로 "MCP는 정비사가 진단 기기를 사용하는 방법이고, A2A는 고객이 정비 공장과 대화하는 방법이다"라고 설명했습니다.

MCP의 급속한 보급은 AWS의 성공과 동일한 표준화 메커니즘으로 설명할 수 있습니다. AWS는 상용 클라우드 서비스(인프라 표준)이고, MCP는 AI 도구 연결 프로토콜(통신 표준)로서 대상은 다릅니다. 하지만 "참여자를 늘리는 구조의 설계"라는 점에서는 동일한 역학이 작용하고 있습니다.

AWS가 파트너나 OSS(Open Source Software) 커뮤니티에 참여할 여지를 남겨두었듯이, MCP는 사양을 오픈하여 누구나 MCP 서버를 만들 수 있도록 했습니다. 그 결과, GitHub 상에 15,900개 이상의 MCP 서버 리포지토리가 생겨났으며, 각 서버는 즉시 모든 MCP 대응 클라이언트에서 이용할 수 있게 되었습니다.

AWS에서 서비스가 늘어날수록 이용자가 늘어났듯이, MCP에서도 서버가 늘어날수록 클라이언트 측의 대응 가치가 올라가며, 클라이언트가 늘어날수록 서버를 만드는 인센티브가 강해집니다.

MCP 서버가 늘어난다
↓
MCP 대응 클라이언트의 가치가 올라간다
...

AWS의 표준화에 서드파티(Third-party)가 올라탄 것처럼, MCP에는 OpenAI(최대의 경쟁자)가 2025년 3월에 대응을 표명했습니다. 이에 대해 한 분석가는 "1998년 Apple이 iMac에서 USB만을 채택한 순간과 유사하다. 에코시스템의 중심에 있는 플레이어가 채택함으로써 표준 후보로서의 지위가 크게 강화되었다"라고 분석했습니다.

AWS는 Amazon 단독 서비스이지만, MCP는 여기서 한 걸음 더 나아가 2025년 12월 Linux Foundation 산하의 AAIF에 기증되었습니다. Anthropic, OpenAI, Block, AWS, Google, Microsoft가 공동으로 운영하는 중립적인 거버넌스 체제를 취하고 있습니다.

MCP가 표준이 되어가는 이유를 구현 수준에서 확인해 보겠습니다. 다음은 TypeScript로 작성한 최소한의 MCP 서버 구조입니다.

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

이 서버를 한 번 작성해 두면 Claude, ChatGPT, Cursor, VS Code Copilot 및 기타 모든 MCP 대응 클라이언트에서 호출할 수 있습니다. Function Calling처럼 클라이언트마다 도구 정의를 다시 작성할 필요가 없습니다.

이것이 M×N 문제를 M+N으로 축소한다는 의미입니다.

【Function Calling】 【MCP】
Client A ─┬─ Tool 1 Client A ─┐
├─ Tool 2 Client B ─┤─ MCP Server (Tool)
...

실제 프로덕션 시스템(Production System)에서 세 가지 프로토콜은 경쟁 관계가 아니라 서로 다른 레이어를 담당합니다.

┌───────────────────────────────────────┐
│ A2A (에이전트 간 연계) │
│ 연구 Agent ←→ 집필 Agent ←→ 검증 Agent │
...

권장되는 접근 방식은, 우선 MCP로 도구 연결을 표준화하고, 멀티 에이전트 (Multi-agent)의 필요성이 생기면 A2A를 추가하며, 엄격한 실행 계약이 필요한 부분에 Function Calling (함수 호출)을 사용하는 레이어드 설계 (Layered Design)입니다.

지금까지의 분석을 통해 표준화의 역학에 관한 다음과 같은 법칙이 보입니다.

최고 성능의 기술이 반드시 승리하는 것은 아니다 (VHS vs Beta, Windows vs Mac) -
참여의 여백을 남긴 쪽이 승리한다 (Linux, AWS, MCP) -
네트워크 효과 (Network Effect)가 시작되면 역전은 극히 어렵다 (MCP 월간 9,700만 회 다운로드) -
중립적 거버넌스 (Neutral Governance)가 신뢰를 만든다 (Linux Foundation, AAIF)

일본의 AI 전략을 생각할 때, '세계 최대의 AI 모델을 만드는 것'만이 선택지는 아닙니다.

일본에는 제조업 현장 데이터, 의료 지식, 농업 기술, 방재 노하우 등 세계적으로 가치 있는 도메인 지식 (Domain Knowledge)이 있습니다. 이것들을 MCP 서버로서 표준 프로토콜 위에 공개하면, 전 세계의 AI 클라이언트 (Client)로부터 즉시 액세스할 수 있게 됩니다.

예를 들어 다음과 같은 특화형 MCP 서버를 생각할 수 있습니다.

제조 품질 AI: 일본 제조업이 축적한 품질 관리 노하우를 MCP 서버화하여, 전 세계 제조업 AI 에이전트가 이용할 수 있도록 함 -
방재 AI: 지진·쓰나미·태풍에 관한 세계 최고 수준의 지견을 MCP 서버화하여, 각국의 방재 시스템과 연계함 -
농업 AI: 기상·토양·재배 데이터의 해석을 MCP 서버로서 제공함

모델의 규모로 경쟁하는 것이 아니라, 도메인 지식을 세계 표준 프로토콜 위에서 제공한다는 전략입니다. '여백'을 사용하는 쪽에 머무는 것이 아니라, '여백 속에서 필수적인 부품이 된다'는 발상입니다.

AWS가 세계에서 선택받은 이유는 최고 성능의 기술이었기 때문이 아닙니다. 전 세계 개발자가 참여할 수 있는 표준 기반을 만들었기 때문입니다.

2026년 현재, AI 연계의 세계에서도 완전히 동일한 표준화 메커니즘이 작동하고 있습니다. MCP가 Anthropic의 공식 발표에서 월간 9,700만 다운로드에 도달하고, OpenAI·Google·Microsoft·AWS가 동일한 프로토콜을 채택한 구도는, 과거 AWS가 클라우드의 표준 언어가 되었던 과정과 겹칩니다.

표준을 제패하는 자가 다음 시대를 만듭니다. 이 법칙은 VHS, Windows, Linux, AWS를 거쳐, 지금 AI 프로토콜의 세계에서 다시 검증되고 있습니다.

일본이 지향해야 할 것은 AI 모델의 거대화 경쟁만이 아닙니다. 중요한 것은 전 세계의 AI가 이용하는 '지식·데이터·전문 능력의 접속 규격'을 만드는 쪽에 설 수 있느냐입니다. 인터넷 시대에 TCP/IP를 거머쥔 자가 통신 기반을 만들었고, 클라우드 시대에 AWS가 개발 기반을 만들었습니다. AI 시대에는 지식과 능력을 연결하는 표준을 누가 만드는가가 새로운 경쟁 축이 될 것입니다.

• Model Context Protocol 사양
• Anthropic MCP 공식 발표
• Agentic AI Foundation (Linux Foundation)
• MCP vs A2A vs Function Calling 비교 (Zilliz)
• MCP Adoption Statistics 2026