Model Context Protocol(MCP) 표준 해부: JSON-RPC 2.0 기반 Tools·Resources·Prompts 3대 프리미티브와 프로세스 격리 통신 원리

Model Context Protocol(MCP)의 Host, Client, Server 3계층 연결망과 JSON-RPC 2.0 비동기 버스를 상징하는 추상 기하학 아트워크다. 중앙 코어로부터 분기되는 궤도 링과 3대 프리미티브(도구·리소스·프롬프트)의 독립 노드가 안전한 프로세스 격리 경계 내에서 초고속으로 상호작용하는 개방형 에이전트 생태계를 표현했다.

생성형 AI와 대규모 언어 모델(LLM)이 단순한 텍스트 생성을 넘어 사용자의 파일 시스템을 읽고, 데이터베이스를 조회하며, 빌드 도구나 웹 브라우저를 직접 조작하는 '자율형 에이전트(Autonomous Agents)'로 진화함에 따라 모델과 외부 시스템을 안전하고 효율적으로 연결하는 인터페이스 표준의 필요성이 급부상했다. 과거에는 OpenAI의 Function Calling, LangChain의 독자적인 Tool 인터페이스, 그리고 각 IDE나 챗봇 애플리케이션마다 제각기 다른 규격으로 도구 연동 코드를 작성해야 했다. 이로 인해 $N$ 개의 AI 애플리케이션과 $M$ 개의 데이터 소스를 연결하기 위해 $N \times M$ 개의 커스텀 어댑터를 개발하고 유지보수해야 하는 파편화 위기가 발생했다. Model Context Protocol Specification, Anthropic MCP Introduction

결론부터 말하면 Model Context Protocol(MCP)은 AI 어시스턴트와 외부 환경 간의 데이터 교환을 단일화한 JSON-RPC 2.0 기반의 개방형 표준 규격이며, Host-Client-Server의 3계층 분리와 3대 프리미티브(Tools, Resources, Prompts)를 통해 벤더 종속성을 제거하고 프로세스 경계 격리를 통한 강력한 보안 모델을 제공한다. MCP를 도입하면 개발자는 특정 모델이나 AI 클라이언트에 종속되지 않고 한 번 작성한 도구·데이터 서버를 Claude Desktop, Cursor, Antigravity, 오픈소스 에이전트 프레임워크 어디에서든 즉시 재사용할 수 있다. 또한 모든 외부 도구 실행과 데이터 조회가 별도의 독립 프로세스나 샌드박스에서 구동되므로 모델의 임의 코드 실행이나 시스템 권한 오남용을 호스트 단에서 완벽하게 통제할 수 있다.

이 글에서는 MCP의 탄생 배경과 Host-Client-Server 3계층 아키텍처의 동작 원리를 해부하고, 전송 계층(Stdio vs SSE)의 차이점 및 JSON-RPC 2.0 기반의 3대 핵심 프리미티브(Tools, Resources, Prompts)의 통신 규격을 상세히 분석한다. 또한 핸드셰이크부터 도구 실행, 에러 처리에 이르는 전 과정을 로컬 Python 스크립트로 직접 구현·검증한 5가지 시나리오를 살펴보고, 프로덕션 환경에서 안전한 MCP 서버를 구축하기 위한 실무 엔지니어링 체크리스트를 제시한다.

1. 도구 연동의 N x M 파편화 위기와 MCP 표준의 탄생 배경

전통적인 AI 어시스턴트 생태계에서 도구(Tool)와 컨텍스트 연동은 심각한 구조적 한계를 안고 있었다.

파편화된 독점 인터페이스: OpenAI, Google, Anthropic 등 주요 모델 벤더마다 함수 호출(Function Calling / Tool Use)의 스키마와 응답 처리 규격이 서로 달랐다.

애플리케이션 결합도(Tight Coupling): 특정 에디터(VS Code, JetBrains)나 CLI 도구에서 동작하는 플러그인은 다른 챗봇 인터페이스나 자동화 파이프라인에서 전혀 재활용할 수 없었다.

데이터 접근의 비대칭성: 모델에 정적 파일이나 DB 레코드 같은 '참조용 컨텍스트'를 제공하는 방식과 실제 상태를 변경하는 '실행형 도구'를 제공하는 방식이 통합되지 못하고 혼재되어 있었다.

보안 격리 부재: 도구 실행 코드가 AI 애플리케이션과 동일한 런타임 프로세스에서 구동될 경우, 오염된 프롬프트나 프롬프트 인젝션(Prompt Injection) 공격에 의해 호스트 전체의 권한이 탈취될 위험이 상존했다.

이러한 문제를 근본적으로 해결하기 위해 2024년 11월 Anthropic이 제정하고 이후 리눅스 재단(Linux Foundation)의 Agentic AI Foundation으로 이관된 개방형 표준이 바로 Model Context Protocol(MCP)이다. 웹 브라우저가 HTTP를 통해 어떤 웹 서버와도 통신하고, 개발 도구가 LSP(Language Server Protocol)를 통해 모든 프로그래밍 언어의 구문 분석기를 공통으로 활용하듯, MCP는 AI 에이전트와 도구 생태계를 잇는 '범용 프로토콜' 역할을 수행한다.

Model Context Protocol(MCP)의 Host 애플리케이션, 1:1 격리 Client 채널, 그리고 독립 프로세스로 동작하는 MCP Server 및 3대 프리미티브(Tools, Resources, Prompts)의 3계층 아키텍처 다이어그램이다. 로컬 Stdio 파이프와 원격 HTTP/SSE 전송 계층을 통해 안전하게 통신하는 구조를 도식화했다.

2. MCP 3계층 아키텍처와 전송 계층(Transport Layer)

MCP 아키텍처는 책임을 명확히 분리하기 위해 Host, Client, Server의 3단계 계층 구조를 엄격하게 준수한다.

1) Host (호스트 애플리케이션)

사용자가 직접 대면하는 최상위 AI 컨테이너 애플리케이션이다 (예: Claude Desktop, Antigravity, Cursor, 사용자 정의 CLI 등).

LLM 오케스트레이션 라이프사이클을 총괄하며, 사용자 보안 정책(도구 실행 전 사용자 승인 팝업 노출 등)을 최종적으로 통제한다.

호스트 내부에서 여러 개의 독립적인 MCP Client 인스턴스를 관리한다.

2) Client (클라이언트 인스턴스)

Host 프로세스 내부에서 특정 MCP Server와 1:1로 직접 연결되는 전용 프로토콜 어댑터다.

서버마다 개별 Client가 독립적으로 생성되므로, 특정 서버에서 크래시나 지연이 발생하더라도 다른 서버나 호스트 전체로 장애가 전파되지 않는다.

JSON-RPC 2.0 메시지의 직렬화 및 역직렬화, 세션 상태 유지, 프로토콜 핸드셰이크를 전담한다.

3) Server (MCP 서버)

특정 도구나 데이터 소스만을 전문적으로 외부에 노출하는 경량 독립 프로그램이다 (예: Git 서버, PostgreSQL 서버, 파일시스템 서버, Slack 연동 서버 등).

호스트 프로세스와 물리적으로 격리된 서브프로세스(Subprocess) 또는 원격 컨테이너 환경에서 구동된다.

3대 핵심 프리미티브인 Tools, Resources, Prompts를 표준 포맷으로 외부에 제공한다.

4) 전송 계층 (Transport Layer): Stdio vs SSE

MCP는 메시지 내용(Data Layer)과 물리적 전달 방식(Transport Layer)을 완벽히 분리했다.

Stdio (표준 입출력 파이프):

호스트가 MCP 서버 프로세스를 자식 프로세스로 직접 스폰(Spawn)하고 stdin과 stdout 파이프를 통해 개행 문자(\n)로 구분된 JSON 문자열을 주고받는 방식이다.

별도의 네트워크 포트 개방이나 방화벽 설정, 인증 토큰 교환 없이 로컬 환경에서 가장 안전하고 오버헤드가 적어 데스크톱 어시스턴트에서 기본으로 채택된다.

HTTP with SSE (Server-Sent Events):

서버가 원격 클라우드나 중앙 인프라에 상주할 때 사용된다.

클라이언트는 HTTP POST 요청으로 명령을 전송하고, 서버는 지속적인 SSE 스트림을 통해 실시간 응답과 알림(Notifications)을 비동기로 클라이언트에 푸시한다.

MCP 클라이언트와 서버 간의 초기 핸드셰이크(initialize -> notifications/initialized), 역량 검색(list), 런타임 도구 실행(call) 및 표준 에러 처리 생명주기를 나타낸 시퀀스 다이어그램이다.

3. JSON-RPC 2.0 기반 3대 핵심 프리미티브와 생명주기

MCP는 모든 요청과 응답을 경량 표준인 JSON-RPC 2.0 규격으로 처리한다. 서버가 제공할 수 있는 역량(Capabilities)은 크게 3가지 핵심 프리미티브로 분류된다.

1) Tools (실행형 액션 — 모델 제어)

모델이 능동적으로 판단하여 호출하는 실행 함수다.

tools/list 요청을 통해 서버가 지원하는 모든 도구의 이름, 설명, 그리고 JSON Schema 규격의 입력 매개변수 명세(inputSchema)를 호스트에 전달한다.

모델이 도구 사용을 결정하면 호스트는 tools/call 메서드와 함께 인자(arguments)를 서버로 전송하고, 서버는 실행 결과를 구조화된 콘텐츠 배열(content: [{type: "text", text: "..."}])로 반환한다.

2) Resources (정적/동적 컨텍스트 데이터 — 애플리케이션 제어)

파일 내용, 데이터베이스 스키마, 시스템 환경설정 등 모델에 '읽기 전용 컨텍스트'를 주입하기 위한 데이터 프리미티브다.

고유한 URI 체계(예: file:///workspace/src/app.py, postgres://db/users/schema)를 통해 식별된다.

클라이언트는 resources/list로 탐색하고 resources/read를 호출하여 텍스트 또는 Base64 바이너리 데이터를 안전하게 가져온다.

도구와 달리 시스템 상태를 변경하지 않는 순수 읽기 작업이므로 보안 승인 절차를 최소화할 수 있다.

3) Prompts (재사용 가능한 상호작용 템플릿 — 사용자 제어)

복잡한 다단계 워크플로나 프롬프트 엔지니어링 모범 사례를 템플릿화하여 제공하는 프리미티브다.

prompts/list를 통해 인자 정의와 함께 템플릿 목록을 조회하고, prompts/get에 파라미터를 넘겨 렌더링된 메시지 배열(System, User, Assistant 메시지)을 획득한다.

4) 초기 핸드셰이크와 엄격한 상태 전이

MCP 통신은 반드시 규정된 3단계 핸드셰이크를 거쳐야 한다.

Initialize: 클라이언트가 지원하는 프로토콜 버전(protocolVersion)과 역량을 전송한다.

Initialize Response: 서버가 자신의 버전, 식별자, 제공 가능한 프리미티브 역량(capabilities)을 응답한다.

Initialized Notification: 클라이언트가 준비 완료 알림(notifications/initialized)을 전송함으로써 세션이 활성화된다. 초기화가 끝나기 전에 도구나 리소스를 호출하면 서버는 표준 에러 코드 -32002 (Server not initialized)를 반환하며 작업을 거부한다.

4. 기존 플러그인 방식 vs MCP 표준 아키텍처 비교

전통적인 AI 도구 연동 방식과 MCP 표준 아키텍처를 기능 및 운영 관점에서 비교하면 다음과 같다.

비교 항목	1. 벤더별 Function Calling / 커스텀 플러그인	2. 언어 모델 프레임워크 (LangChain / LlamaIndex Tool)	3. Model Context Protocol (MCP) 표준
표준화 수준	벤더 독점 규격 (OpenAI, Gemini 등 상이)	특정 라이브러리/프레임워크 내부 추상화	오픈 거버넌스 개방형 통신 프로토콜 (Linux Foundation)
프로세스 격리성	미지원 (동일 프로세스 내 인메모리 실행)	라이브러리 런타임 종속	Stdio/SSE 기반 서브프로세스 완전 격리
상호 운용성	타사 클라이언트 재사용 불가	해당 프레임워크 사용자 간에만 공유	Claude Desktop, Cursor, Antigravity 등 모든 호스트 호환
컨텍스트/도구 분리	함수 호출 하나로 모든 작업 혼용	Tool 인터페이스 중심	Tools(실행), Resources(데이터), Prompts(템플릿) 명확 분리
프로토콜 기반	REST API / JSON 페이로드 제각각	언어별 객체 인스턴스 바인딩	JSON-RPC 2.0 (양방향 비동기 통신 규격)
지원 전송 계층	HTTP/HTTPS 단일	로컬 함수 직접 호출	Stdio (로컬 무오버헤드) & SSE (원격 스트리밍)

5. 로컬 Python으로 검증하는 MCP 프로토콜 시뮬레이션

프로덕션 MCP 서버의 내부 아키텍처와 JSON-RPC 2.0 통신 규격을 완벽히 재현한 로컬 Python 검증 스크립트(test_mcp_protocol_simulation.py)를 작성하여 실행했다.

직접 실행해 확인한 5가지 검증 시나리오

로컬 터미널 환경에서 위 검증 스크립트를 직접 실행하여 5가지 시나리오가 모두 정상 통과(All 5 MCP protocol verification checks passed successfully!)함을 확인했다.

초기 핸드셰이크 및 역량(Capabilities) 협상 (Case 1): 클라이언트가 initialize를 요청했을 때 서버 식별 정보와 3대 프리미티브 역량이 정상 반환되고, 단방향 알림인 notifications/initialized를 수신한 직후 서버의 내부 상태가 활성화(INITIALIZED)됨을 확인했다.

Tools 프리미티브 스키마 조회 및 도구 호출 검증 (Case 2): tools/list로 등록된 도구의 파라미터 제약조건을 확인하고, tools/call 요청을 통해 SQL 쿼리 실행 도구가 정형화된 콘텐츠 배열(content)과 에러 플래그(isError: false)를 정확히 반환함을 검증했다.

Resources 프리미티브 읽기 및 URI 체계 검증 (Case 3): resources/list로 config://system/env 리소스를 조회하고, resources/read를 통해 호스트 환경 설정 JSON 데이터가 올바른 MIME 타입(application/json)으로 전달됨을 확인했다.

Prompts 프리미티브 템플릿 인자 바인딩 검증 (Case 4): prompts/get 호출 시 language: "Rust" 인자가 템플릿 내에 안전하게 보간되어 사용자 역할(user role)의 메시지 객체로 변환됨을 확인했다.

표준 에러 코드 및 보안 경계 제어 검증 (Case 5): 필수 매개변수 누락 시 -32602 (Invalid params), 미등록 도구/메서드 요청 시 -32601 (Method not found), 존재하지 않는 리소스 요청 시 -32001 에러가 표준 규격에 맞게 반환되어 프로세스 경계 내에서 오류가 안전하게 격리됨을 입증했다.

6. 프로덕션 MCP 서버 개발 및 보안 운영 체크리스트

Stdio 전송 시 표준 출력(stdout) 순수성 보장:

Stdio 모드로 동작하는 MCP 서버 코드 내에서 디버깅 목적으로 print()나 console.log()를 호출하면 stdout 파이프에 비정형 문자열이 섞여 클라이언트의 JSON-RPC 파서가 -32700 (Parse error)를 일으키며 즉시 크래시된다.