Model Context Protocol(MCP) 아키텍처 해부: Host-Client-Server 구조부터 Stdio·Streamable HTTP 전송과 보안 경계까지

AI 애플리케이션(Host)과 다양한 외부 도구·데이터 소스(Server)를 표준 프로토콜로 상호 연결하는 Model Context Protocol(MCP)의 3계층 아키텍처를 상징하는 추상 기하학 아트워크다. 중앙의 다면체 코어와 3개의 동심 궤도 링, 네온 펄스 빔 및 3대 프리미티브(Tools, Resources, Prompts) 위성 노드가 결합된 데이터 버스 토폴로지를 표현했다.

대규모 언어 모델(LLM)이 단순한 텍스트 완성(Completion)을 넘어 스스로 계획을 수립하고, 터미널 명령을 실행하며, 원격 데이터베이스와 내부 문서를 조회하는 자율형 AI 에이전트(Agentic AI)로 빠르게 진화하고 있다. 그러나 지금까지 에이전트 생태계의 가장 큰 병목은 '외부 환경 연동의 극단적인 파편화'였다. 각 프레임워크(LangChain, LlamaIndex, Semantic Kernel, 독자 Agent Runner)마다 도구를 정의하고 호출하는 인터페이스가 제각각이었고, 데이터베이스나 SaaS 도구 하나를 추가하려면 각 프레임워크 전용 플러그인을 $M \times N$ 조합으로 중복 개발해야 했다. Anthropic — Introducing the Model Context Protocol, Model Context Protocol Specification

결론부터 말하면 Model Context Protocol(MCP)은 웹의 HTTP나 개발 도구의 언어 서버 프로토콜(LSP)처럼 AI 모델과 외부 데이터·액션을 분리하는 '개방형 범용 프로토콜 표준'이며, JSON-RPC 2.0 기반의 3대 프리미티브(Tools, Resources, Prompts)와 전송 계층 추상화(Stdio vs Streamable HTTP)를 통해 도구 연동 복잡도를 $O(M \times N)$ 에서 $O(M + N)$ 으로 종식시킨다. 표준 프로토콜을 구현한 MCP 서버 하나만 배포하면 Claude Desktop, Antigravity, Cursor, 사내 커스텀 에이전트 등 모든 MCP 호스트 클라이언트에서 즉시 안전하게 해당 도구와 리소스를 활용할 수 있다.

이 글에서는 MCP의 3계층 아키텍처(Host-Client-Server)의 역할 분담과 3대 프리미티브(Tools, Resources, Prompts)의 내부 구조를 해부한다. 또한 프로세스 기반 Stdio 트랜스포트와 최신 원격 Streamable HTTP 트랜스포트의 동작 원리, stdout 오염 방지 규칙을 살펴보고, 로컬 Python 시뮬레이션 스크립트로 5대 라이프사이클 시나리오를 직접 검증한 결과와 실무 프로덕션 연동 체크리스트를 정리한다.

MCP 3계층 아키텍처(Host 컨테이너, 1:1 클라이언트 인스턴스, 전송 계층 경계, MCP 서버)와 Stdio 서브프로세스 및 차세대 Streamable HTTP 트랜스포트의 연결 구조를 나타낸 시스템 다이어그램이다.

1. MCP 3계층 시스템 아키텍처: Host, Client, Server의 명확한 경계

MCP는 단일 모놀리식 라이브러리가 아니라 상호 결합도를 최소화한 3계층 분선 구조로 설계되어 있다.

1) MCP Host (컨테이너 & 사용자 오케스트레이터)

주요 역할: 사용자와 직접 맞닿아 있는 최상위 AI 애플리케이션 환경이다. Claude Desktop, Google Antigravity, Cursor, Zed, 자체 구축한 AI Agent 플랫폼 등이 Host에 해당한다.

컨텍스트 통합 및 권한 제어: 여러 MCP 서버로부터 수집된 도구 목록과 컨텍스트 리소스를 취합하여 LLM의 컨텍스트 윈도우에 주입한다. 모델이 도구를 호출하려고 할 때 사용자에게 실행 승인을 묻는 보안 게이트키퍼(Security Gatekeeper) 역할도 Host가 전담한다.

2) MCP Client (1:1 프로토콜 어댑터)

주요 역할: Host 프로세스 내부에서 구동되며, 각 MCP Server마다 1:1로 매핑되는 전용 커넥터 인스턴스다.

프로토콜 수명주기 관리: 대상 서버 프로세스를 자식 프로세스로 스폰(Spawn)하거나 원격 HTTP 엔드포인트와 세션을 수립하고, 초기화 핸드셰이크(initialize), 기능 목록 동기화, JSON-RPC 2.0 직렬화/역직렬화를 처리한다.

3) MCP Server (독립적 기능 제공자)

주요 역할: 특정 기능이나 데이터 소스에 특화된 가볍고 독립적인 프로세스 또는 마이크로서비스다.

경계 분리: LLM의 모델 가중치나 프롬프트 엔진에 대해 전혀 알 필요가 없다. 오직 JSON-RPC 2.0 표준 규격에 따라 자신이 제공할 수 있는 도구, 리소스, 프롬프트를 외부에 선언하고, 호출 요청이 들어왔을 때 비즈니스 로직을 수행한 후 표준화된 결과 봉투(CallToolResult)에 담아 반환한다.

2. 프로토콜을 지탱하는 3대 핵심 프리미티브: Tools, Resources, Prompts

MCP 사양은 AI 모델과 시스템 간의 상호작용 형태를 목적에 따라 3가지 프리미티브로 엄격히 구분한다.

1) Tools (모델 제어 액션)

동작 특성: REST의 POST와 같이 시스템의 상태를 변경하거나 외부 연산을 능동적으로 트리거하는 실행형 기능이다.

JSON Schema 기반 엄격성: 각 도구는 이름(name), 설명(description), 입력 매개변수 스키마(inputSchema)를 제공해야 한다. 모델은 이 스키마를 바탕으로 인자를 추론하며, 서버는 인자가 스키마 규약에 부합하는지 핸들러 실행 전에 엄격히 검증한다.

실행 결과 캡슐화: 실행 성공 시 {"content": [{"type": "text", "text": "..."}], "isError": false} 형식으로 결과를 반환하며, 치명적 런타임 오류가 발생하더라도 JSON-RPC 레벨의 커넥션을 끊지 않고 isError: true 플래그로 모델에 안전하게 에러 피드백을 전달한다.

2) Resources (수동적 컨텍스트 데이터)

동작 특성: REST의 GET과 유사하게 상태를 변경하지 않는 읽기 전용 데이터 스트림이다.

URI 기반 식별: file:///workspace/src/app.py, postgres://schema/users, notion://docs/spec 등 고유 URI 체계로 관리된다.

구독(Subscription) 지원: 리소스 내용이 외부에서 변경되었을 때(resources/updated) 클라이언트에 알림을 보내 최신 상태로 컨텍스트를 동기화할 수 있다.

3) Prompts (사용자 주도 상호작용 템플릿)

동작 특성: 사용자가 슬래시 커맨드(/)나 UI 드롭다운을 통해 직접 선택하는 사전 정의된 프롬프트 워크플로다.

동적 파라미터 바인딩: 예컨대 /code-review 프롬프트에 language: "python", severity: "high"와 같은 인자를 넘겨 표준화된 프롬프트 메시지 배열을 동적으로 조합해 Host에 제공한다.

3. 트랜스포트 계층(Transport Layer) 해부: Stdio vs Streamable HTTP

MCP는 데이터 계층(JSON-RPC 2.0)과 전송 계층(Transport)이 완벽히 분리되어 있어 어떤 네트워크/프로세스 환경에서도 동일한 메시지 포맷을 유지한다.

MCP 프로토콜 라이프사이클(초기화 핸드셰이크, 기능 목록 조회, 툴 호출 실행 및 Stderr 로깅 격리)의 세부 JSON-RPC 2.0 시퀀스를 도식화한 다이어그램이다.

1) Stdio 트랜스포트: 로컬 서브프로세스 IPC

동작 방식: MCP Client가 OS 시스템 명령으로 MCP Server를 자식 프로세스(Child Process)로 기동하고, 표준 입출력 스트림(stdin/stdout)을 통해 개행 문자(\n)로 구분된 JSON-RPC 문자열을 주고받는다.

성능과 단순성: 별도의 네트워크 포트 바인딩이나 방화벽 설정 없이 OS 커널 레벨 파이프를 사용하므로 지연 시간(Latency)이 거의 0에 가깝고 로컬 개발 도구에 가장 적합하다.

★ 핵심 주의점 — stdout 오염 방지 규칙(Stdout Pollution Rule):

Stdio 환경에서 서버 프로세스의 stdout은 오직 유효한 JSON-RPC 2.0 메시지만 흘러야 한다.

만약 코드 내에서 print("connecting...")이나 서드파티 라이브러리의 표준 출력 디버그 로그가 stdout으로 한 줄이라도 누출되면, 클라이언트의 JSON 파서가 즉시 JSONDecodeError를 일으키고 전체 세션이 파두(Crash)된다.

따라서 모든 진단 로그, 진행 상황 안내, 내부 디버깅 메시지는 반드시 표준 에러(stderr) 또는 MCP의 notifications/message 로깅 프로토콜로만 출력해야 한다.

2) Streamable HTTP 트랜스포트: 차세대 원격 클라우드 전송

기존 HTTP+SSE 방식의 퇴출: 초기 MCP 사양은 알림을 받기 위한 GET /sse 엔드포인트와 요청을 전송하기 위한 POST /message 2개의 엔드포인트를 혼용하여 프록시 구성과 세션 유지 관리가 까다로웠다.

단일 HTTP POST 스트리밍: 최신 표준인 Streamable HTTP는 단일 HTTP POST 요청 위에서 청크 전송 인코딩(Chunked Transfer Encoding)을 활용해 양방향성 스트리밍 응답을 전송한다.

엔터프라이즈 보안 및 멀티테넌시: 원격 마이크로서비스 배포 시 OAuth 2.1 인증과 **RFC 8707 리소스 지시자(Resource Indicators)**를 결합하여 중간 대리인 공격(Confused Deputy Attack)과 토큰 무단 재사용을 원천 차단한다.

4. 도구 연동 방식 및 프로토콜 특성 비교

AI 모델과 외부 도구를 연동하는 주요 방식들의 구조적 차이를 비교하면 다음과 같다.

구분	1. 독자 프레임워크 플러그인 (LangChain/Llama)	2. 모델별 Native Function Calling (OpenAI/Anthropic)	3. MCP Stdio 트랜스포트 (로컬 프로세스)	4. MCP Streamable HTTP (원격 클라우드)
결합도 및 표준화	특정 프레임워크 종속 ( $O(M \times N)$ 파편화)	특정 LLM 공급자 API 스키마 종속	개방형 표준 버스 ( $O(M + N)$ 상호운용)	개방형 표준 버스 ( $O(M + N)$ 상호운용)
구동 위치	호스트 애플리케이션 프로세스 내부	원격 LLM API 추론 서버 레이어	로컬 OS 격리 서브프로세스 (Child Process)	원격 마이크로서비스 / 서버리스 컨테이너
통신 프로토콜	In-memory Python/TS 함수 호출	REST HTTPS JSON 페이로드	JSON-RPC 2.0 over Stdio (stdin/stdout)	JSON-RPC 2.0 over Streamable HTTP (POST)
보안 및 격리 수준	동일 프로세스 메모리 공유 (취약점 노출 위험)	API 토큰 단위 인증	OS 프로세스 격리 + Stderr 진단 분리	OAuth 2.1 + RFC 8707 리소스 지시자 격리
확장성 및 다중 호스트 지원	다른 에이전트/도구 재사용 불가능	플랫폼 간 변환 레이어 필수	모든 MCP 호스트(Claude, Cursor 등) 즉시 공유	수천 개 에이전트 클라이언트 수용 가능
스트림 무결성 요구	해당 없음	HTTP 응답 본문 파싱	stdout 엄격 격리 필수 (stderr 전용 로깅)	표준 HTTP 스트림 프레임 청크

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

실제 MCP 사양의 핵심 상태 전이와 JSON-RPC 2.0 규칙을 로컬 Python 스크립트(test_mcp_protocol.py)로 모델링하여 검증을 진행했다.

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

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

초기화 핸드셰이크 및 미초기화 요청 가드 (Case 1): 서버 기동 직후 initialize 절차를 거치지 않고 tools/list를 호출할 경우 표준 규약에 따라 즉시 -32600 (InvalidRequest) 에러로 요청이 차단되며, 클라이언트의 initialize 요청 및 notifications/initialized 알림을 온전히 수신한 뒤에만 일반 요청이 승인됨을 확인했다.

도구 파라미터 JSON Schema 유효성 검사 (Case 2): 등록된 calculate_hash 도구 호출 시 필수 매개변수(algorithm)가 누락되거나 타입 불일치(정수형 rounds에 문자열 전달)가 발생하면 비즈니스 로직에 진입하기 전 -32602 (InvalidParams) 에러가 즉시 반환됨을 검증했다.

정상 도구 호출 및 CallToolResult 캡슐화 (Case 3): 유효한 인자가 전달되었을 때 등록된 핸들러가 정상 실행되고, 그 결과가 MCP 표준 규격인 {"content": [{"type": "text", "text": "..."}], "isError": false} 구조로 안전하게 래핑되어 응답됨을 확인했다.

Stdio 트랜스포트 스트림 무결성 및 Stderr 격리 (Case 4): 서버 내부에서 데이터베이스 연결 진단 등의 로그를 기록할 때 stdout 버퍼는 완전히 빈 문자열(0바이트)을 유지하고 오직 stderr로만 로그 라인이 방출되어, Stdio 환경에서 JSON-RPC 파서가 오염되지 않음을 검증했다.

디렉터리 순회 공격 방어 및 JSON-RPC 표준 에러 규약 (Case 5): resources/read 요청 시 상위 디렉터리 순회 탈출 문자열(../)이 포함된 악의적 URI를 감지하여 차단하고, 정의되지 않은 메서드 호출 시 -32601 (MethodNotFound), 깨진 JSON 수신 시 -32700 (ParseError)가 표준 스펙대로 반환됨을 입증했다.

검증 범위 명시: 위 결과는 단일 프로세스 메모리 상에서의 개행 구분 JSON-RPC 2.0 파싱 파이프라인, 초기화 상태 기계, 도구 스키마 유효성 검사 및 스트림 버퍼 격리의 프로토콜 규격 무결성 검증이다. 실제 수천 개 노드가 분산된 원격 Streamable HTTP 환경에서의 네트워크 지연, WebSocket 역다중화, 하드웨어 방화벽 및 OAuth 2.1 인가 서버 연동 성능은 별도의 인프라 부하 테스트 환경에서 측정되어야 한다.