Cursor에 MCP Server 세 개를 붙여 두었는데, 동료가 Claude Desktop으로 옮기면 설정을 처음부터 다시 작성해야 합니다. CRM 팀은 GPT, Claude, Gemini 각각에 맞는 어댑터를 따로 유지보수합니다. 이것이 AI 도구 통합의 N×M 딜레마입니다. 2024년 이전 AI 생태계는 인터넷 초창기처럼 프로토콜이 제각각이었습니다. MCP는 AI 영역의 USB-C에 해당합니다. 모델과 외부 도구·데이터 사이의 통신을 하나의 개방 표준으로 묶습니다. 본 글은 개발자와 아키텍트를 위해 ① MCP의 역사적 위치, ② Host / Client / Server 3계층과 JSON-RPC 전송, ③ REST API와의 핵심 차이, ④ 2026년 4대 벤더와 생태계 데이터, ⑤ NUKCLOUD 클라우드 Mac에서 MCP Server를 배포하는 6단계 Runbook을 정리합니다. Cursor Agent Skills 가이드, GitHub Copilot Agent Runbook, AI 코딩 어시스턴트 비교와 함께 읽으면 Skill과 MCP의 역할 분담까지 한눈에 파악할 수 있습니다.
00인터넷 혼돈에서 AI 혼돈으로: 통합 프로토콜이 필요한 이유
1970년대 ARPAnet, Ethernet, 패킷 무선망은 서로 다른 규칙으로 동작했습니다. 네트워크를 넘을 때마다 맞춤형 변환 계층이 필요했고, 비용과 오류가 누적되었습니다. TCP/IP가 공통 통신 규칙을 정의한 뒤, HTTP가 그 위에서 웹의 기반을 만들었습니다.
2024년 이전 AI 생태계도 같은 혼돈 상태였습니다. ChatGPT Plugins, OpenAI Function Calling, Claude Tool Use, IDE 플러그인, LangChain·CrewAI 같은 Agent 프레임워크마다 데이터 접근 방식이 달랐습니다. 모델 공급사를 바꾸면 통합 로직을 처음부터 다시 짜야 하는 경우가 많았습니다. MCP는 Agent 시대에 HTTP와 같은 역할을 맡으려 합니다. 브라우저를 발명하는 것이 아니라, 브라우저 생태계가 존재할 수 있는 인프라를 제공하는 것입니다.
痛点AI 도구 통합의 N×M 딜레마
현대 LLM은 학습 데이터 시점 제한, 실시간 정보 부재, 직접 실행 불가 같은 한계를 갖습니다. Tool Use·Function Calling으로 AI에 「손발」을 연결하는 것이 능력 확장의 주류 경로입니다. 그러나 현실은 다음과 같습니다.
- N개 모델 × M개 도구 = N×M개 맞춤 통합: 기업 CRM은 Claude, GPT, Gemini 각각에 별도 어댑터를 유지해야 합니다.
- IDE 접근 방식 파편화: 파일 시스템, 데이터베이스, API 접근 경로가 Cursor, Zed, Continue마다 다릅니다.
- 프레임워크 간 재사용 불가: LangChain, CrewAI 등 오케스트레이션 프레임워크의 도구 정의를 다른 프레임워크로 옮기기 어렵습니다.
- 벤더 종속: 통합 자산이 특정 LLM 벤더에 묶여 마이그레이션 비용이 큽니다.
USB 표준화 이전 Mini-USB, Micro-USB, Lightning이 공존하던 상황과 같습니다. MCP는 AI 도구 통합 영역의 USB-C를 지향합니다. 상대가 누구인지 몰라도 연결만 하면 통신할 수 있게 만드는 것입니다.
01MCP란 무엇인가: 아키텍처와 전송 계층
Model Context Protocol(모델 컨텍스트 프로토콜)은 Anthropic이 2024년 11월 공개한 오픈 표준입니다. AI 모델(클라이언트)과 외부 도구·데이터(서버) 사이 통신 규칙을 정의합니다. 핵심은 「AI가 어떤 도구를 발견하고, 어떻게 호출하는가」를 표준화하는 것입니다.
3계층 역할 모델:
- Host(호스트): Claude Desktop, Cursor, VS Code 등 사용자 인터페이스를 제공합니다.
- MCP Client(클라이언트): Host 내부에서 각 Server와 1:1 세션을 유지합니다.
- MCP Server(서버): Tools, Resources, Prompts를 노출하고 데이터베이스, API, 파일 시스템 등 외부 시스템과 연결합니다.
| 전송 방식 | 적합 시나리오 | 특징 |
|---|---|---|
| STDIO | 로컬 자식 프로세스 | 의존성 없음, 빠른 기동, 격리성 우수 |
| HTTP + SSE | 원격·클라우드 서비스 | 네트워크 호출, 수평 확장 지원 |
전송 계층은 JSON-RPC 2.0을 기반으로 합니다. 주요 메서드는 tools/list(런타임 도구 발견), tools/call(실행), resources/read(읽기 전용 데이터 조회)입니다. Server는 Client에 능동적으로 메시지를 푸시할 수 있어, 전통 REST의 단방향 요청-응답과 구분됩니다.
{
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"name": "query_database",
"arguments": { "sql": "SELECT * FROM users LIMIT 10" }
},
"id": 1
}02MCP vs REST API: 아키텍처 수준 비교
| 차원 | 전통 REST API | MCP |
|---|---|---|
| 도구 발견 | 문서를 읽고 하드코딩 | 런타임 tools/list 동적 조회 |
| 세션 상태 | 무상태, 요청마다 독립 | 상태ful 세션, 다단계 워크플로 지원 |
| 자기 기술 | API가 AI에게 역량을 설명하지 않음 | JSON Schema로 파라미터·부작용 기술 |
| 통신 방향 | 단방향 요청-응답 | 양방향, Server 역방향 푸시 가능 |
| 통합 비용 | N×M 맞춤 개발 | Server 한 번 작성, 다중 클라이언트 재사용 |
인용 가능 데이터 1: 기업 AI 통합에 MCP를 도입한 뒤 개발 비용이 약 38–55% 감소했다는 업계 조사 구간이 보고됩니다.
인용 가능 데이터 2: 2026년 기준 MCP 생태계에는 10,000개 이상의 Server가 등록되어 있으며, Server 하나가 추가될 때마다 호환 Client 전체에서 즉시 사용 가능합니다.
인용 가능 데이터 3: 표준화된 인터페이스는 AI 통합 분야 신규 진입 장벽을 약 62% 낮추고, 전통 SI의 맞춤 개발 수요를 약 43% 줄인다는 추정치가 있습니다.
032026 생태계: 4대 벤더와 AAIF 거버넌스
MCP는 AI Agent 폭발 시점과 맞물려 성장했습니다. 주요 타임라인은 다음과 같습니다.
- 2024년 11월: Anthropic이 MCP 규격을 오픈소스로 공개하고 Claude 플래그십에 선통합합니다.
- 2025년: Cursor, Zed, Continue 등 IDE가 네이티브 MCP를 지원합니다.
- 2026년 Q1: OpenAI가 MCP 채택을 발표합니다(1월).
- 2026년 Q2: Google DeepMind CEO가 Gemini MCP 지원을 선언합니다(2월). Microsoft도 지원을 완료합니다.
- 2026년 Q2: 거버넌스가 Linux Foundation 산하 Agentic AI Foundation(AAIF)으로 이관됩니다.
한 회사의 사실상 표준에서 업계 공공 인프라로 넘어선 전환입니다. IETF가 인터넷 프로토콜을 관리하는 것과 유사합니다. 네트워크 효과가 형성되고 있습니다. MCP Client가 하나 늘면 기존 도구 전체가 즉시 활용 가능해지며, HTTP가 웹 생태계를 키운 것과 같은 양의 피드백 루프입니다.
한계와 보완: MCP는 아직 완성형이 아닙니다. OAuth 2.0/2.1 기업급 인증은 2026 로드맵에 남아 있고, DNS에 해당하는 통합 Server 레지스트리는 부재합니다. SSE 전송은 session affinity가 필요해 무상태 HTTP만큼 수평 확장이 자연스럽지 않습니다. Google의 A2A(Agent-to-Agent) 프로토콜은 Agent 간 수평 통신을 정의합니다. MCP는 수직 통합(모델↔도구), A2A는 수평 오케스트레이션(Agent↔Agent)을 담당하며, 둘은 Agent 인터넷 프로토콜 스택을 함께 구성합니다.
046단계 Runbook: 클라우드 Mac에서 MCP Server 배포
아래 Runbook은 전용 Apple Silicon 노드에서 MCP Server를 7×24 운영하고, Cursor·Claude Code 등 Client가 STDIO 또는 HTTP+SSE로 원격 접속하도록 돕습니다.
-
01
도구 요구사항과 Client 목록 정리: 팀이 쓰는 Host(Cursor / Claude Desktop / VS Code + Continue)와 연결할 외부 시스템(데이터베이스, GitHub, 내부 API)을 나열합니다. 각 Client의 MCP 설정 형식(
mcp.json또는 IDE 설정 패널)을 확인합니다. -
02
콘솔에서 클라우드 Mac 프로비저닝: NUKCLOUD 콘솔에 로그인해 16 GB+ 메모리 스펙(다중 MCP Server 병렬 시 32 GB 권장)을 선택합니다. 요금 페이지에서 시간 과금으로 시험할 수 있습니다.
-
03
Node.js / Python 런타임 설치: SSH 로그인 후 MCP Server 구현 언어에 맞게
node@20또는python@3.12를 설치합니다.npx또는uvx로 커뮤니티 Server를 빠르게 띄워 연결성을 검증합니다. -
04
MCP Server 배포 및 전송 계층 설정: 로컬 전용 도구는 STDIO(
command+args)로 실행합니다. 여러 Client가 공유해야 하면 HTTP+SSE로 포트를 노출하고, API Key·DB 자격 증명을 Server 계층에서 중앙 관리해 Client 설정에 분산하지 않습니다. -
05
Client 연결 및
tools/list검증: Cursor.cursor/mcp.json또는 Claude Desktop 설정에서 클라우드 Server를 가리킵니다. 기동 후tools/list가 예상 도구 목록을 반환하는지 확인하고,tools/call스모크 테스트로 지연 기준선을 기록합니다. -
06
launchd상시 운영과 월간 임대 고정:~/Library/LaunchAgents/com.team.mcp-server.plist로 Server 프로세스를 7×24 유지합니다. 파일럿 통과 후 주문 페이지에서 스펙을 고정합니다. 권한·감사는 Server 계층에서 일원화하고, AI Client마다 DB 자격 증명을 흩뿌리지 않습니다.
공유 VPS나 로컬 노트북에서 MCP Server를 돌릴 때 덮개 닫기로 STDIO 세션이 끊기고, 대역폭 지터로 SSE 연결이 끊기며, 여러 개발자가 같은 프로세스 포트를 두고 충돌하는 일이 흔합니다. Claude Code Agent Teams나 Cursor Background Agents가 장시간 도구를 호출해야 한다면 NUKCLOUD 다중 리전 베어메탈 Mac / 클라우드 Mac 노드가 전용 테넌트 경계와 스펙 탄력성 면에서 MCP 워크플로와 더 잘 맞습니다. 시간 과금으로 Server 스택을 시험한 뒤 월간 임대로 고정할 수 있습니다. MCP Server를 팀 공용 인프라로 두면 Client를 바꿔도 통합 자산을 그대로 재사용할 수 있어, N×M 딜레마를 운영 단계에서 실질적으로 줄일 수 있습니다.