Model Context Protocol (MCP) 표준 아키텍처 해부: JSON-RPC 2.0 라이프사이클·Stdio/SSE 전송 계층·Tools/Resources/Prompts 3대 프리미티브와 컨텍스트 오염 방지

Model Context Protocol(MCP)의 호스트-클라이언트-서버 삼각 아키텍처와 3대 핵심 프리미티브 상호작용을 추상화한 개념 일러스트

인공지능 모델(LLM)과 자율 에이전트(Autonomous Agent)가 단순한 텍스트 생성을 넘어 외부 데이터베이스를 조회하고, 터미널 명령을 실행하며, 브라우저를 조작하는 등 실무 워크플로 깊숙이 침투하면서 외부 도구 및 리소스와의 연동 표준화가 엔지니어링의 핵심 과제로 떠올랐다. 지금까지는 각 AI 모델 제공자(Anthropic, OpenAI, Google)나 오케스트레이션 프레임워크마다 제각기 다른 독자적 함수 호출(Function Calling) 포맷과 바인딩 로직을 유지해 왔기 때문에, 새로운 데이터 소스나 도구를 하나 추가할 때마다 모든 에이전트 프레임워크에 맞추어 N벌의 커넥터를 작성해야 하는 M×N 결합도 비용이 발생했다.

Anthropic이 주도하고 오픈소스 생태계가 빠르게 채택하고 있는 **Model Context Protocol(MCP)**은 이러한 분절된 생태계를 단일 개방형 표준 프로토콜로 통합하기 위해 설계되었다 (Model Context Protocol 공식 명세, MCP GitHub 레포지토리). JSON-RPC 2.0 통신 규약을 기반으로 AI 호스트(Host), 프로토콜 클라이언트(Client), 외부 도구 서버(Server) 간의 통신과 권한 모델을 정의하며, 로컬 IPC 파이프(Stdio)와 원격 웹 스트리밍(SSE)을 모두 지원한다.

핵심 판단 기준을 먼저 요약하면, Model Context Protocol(MCP) 도입 시 가장 주의 깊게 설계해야 할 지점은 ① 모델이 자율적으로 판단해 실행하는 도구(Tools, tools/call), 애플리케이션이 읽기 전용으로 안전하게 주입하는 데이터 소스(Resources, resources/read), 사용자가 UI를 통해 명시적으로 워크플로를 지시하는 프롬프트(Prompts, prompts/get)의 3대 프리미티브 역할 분담을 엄격히 구분하고 권한 경계를 격리하는 것이다. 또한 ② 로컬 IPC 파이프 기반의 Stdio 전송 계층에서는 표준 출력(stdout)이 오직 개행(\n)으로 구분된 순수 JSON-RPC 메시지만 흘려보내는 데이터 버스이므로, 서버 코드 내에서 디버그용 print()나 로깅 출력이 단 한 줄이라도 stdout으로 누출되면 클라이언트의 JSON 파서가 깨지며(-32700 ParseError) 세션이 즉시 단절되므로 모든 로그를 반드시 stderr로 강제 분리해야 한다. 마지막으로 ③ 도구 인자 파싱 시 JSON Schema 기반의 엄격한 유효성 검사(-32602 InvalidParams)와 realpath 기반의 샌드박스 경로 검증을 수행하지 않으면 원격 코드 실행이나 디렉터리 순회(Path Traversal) 공격에 무방비로 노출될 수 있다. 이 글은 공식 MCP 명세(2024-11-05 리비전)와 런타임 구현체를 교차 검증해 정리한 글이며, 특정 벤더의 독점 구현이 아닌 개방형 프로토콜 표준 구조와 로컬 Python 6대 불변식 검증 시뮬레이션을 기준으로 설명한다.

1. M×N 연동 복잡도를 1:1 표준 인터페이스로 바꾸는 삼각 아키텍처

기존의 LLM 에이전트 연동 방식은 애플리케이션마다 도구 스키마 변환기와 API 핸들러를 중복 구현해야 했다. MCP는 이를 세 가지 주체(Host, Client, Server)로 분리된 삼각 토폴로지로 구조화하여 해결한다 (MCP Architecture 개요).

비교 항목	기존 독자적 연동 (Ad-hoc)	Model Context Protocol (MCP 표준)	실무적 엔지니어링 이점
1. 결합도 구조	모델·프레임워크별 커스텀 래퍼 작성 (M×N 복잡도)	표준 JSON-RPC 2.0 인터페이스 단일화 (M+N 복잡도)	새로운 MCP 서버 하나만 개발하면 Claude Desktop, IDE, CLI 에이전트 전반에서 즉시 재사용 가능
2. 통신 프로토콜	REST API, 웹훅, 임의의 소켓 등 비표준 구현	엄격한 JSON-RPC 2.0 상태 머신 및 에러 코드 규약	요청 ID 추적, 취소 토큰(Cancellation), 진행률 스트리밍(Progress), 배치 처리가 프로토콜 레벨에서 표준화
3. 전송 계층 분리	애플리케이션 내 라이브러리 직접 링크 및 프로세스 혼재	Stdio(로컬 프로세스 파이프) 및 SSE(원격 HTTP 스트림) 분리	서버가 별도 프로세스 또는 원격 컨테이너에서 독립 실행되므로 장애 격리와 언어 독립성 확보
4. 데이터 및 도구 격리	시스템 프롬프트 내에 모든 문서와 도구 명세를 문자열로 주입	Tools(실행), Resources(데이터), Prompts(워크플로)로 역할 분리	불필요한 프롬프트 토큰 낭비 방지, 데이터 읽기와 사이드이펙트 실행의 보안 권한 경계 명확화

1.1 삼각 아키텍처의 3대 핵심 참여자

AI Host Application: Claude Desktop, Antigravity IDE, Cursor 등 사용자가 직접 상호작용하는 최상위 호스트 환경이다. 호스트는 LLM 모델을 구동하고 사용자의 보안 승인(Consent) UI를 관장한다.

MCP Client: 호스트 내부에서 MCP 서버와의 연결 수명 주기(Connection Lifecycle), 기능 협상(Capabilities Negotiation), 메시지 직렬화 및 라우팅을 담당하는 프로토콜 엔진이다. 1개의 호스트는 여러 개의 MCP Client를 띄워 여러 MCP Server와 동시 통신할 수 있다.

MCP Server: 로컬 또는 원격에서 실행되며 특정 도메인의 도구, 파일, 데이터베이스, API를 래핑하여 표준 규격으로 제공하는 경량 프로세스다.

Model Context Protocol(MCP) 삼각 아키텍처 및 3대 핵심 프리미티브·라이프사이클 요약 다이어그램 (고해상도 PNG)

2. 3대 핵심 프리미티브: Tools vs Resources vs Prompts 역할 분담

MCP의 가장 강력한 설계 철학은 외부 컨텍스트를 그 성격과 제어 주체에 따라 세 가지 프리미티브로 엄격히 나누어 다룬다는 점이다 (MCP Core Primitives).

2.1 Tools (모델 주도형 도구 실행)

제어 주체: AI 모델 (Model-Controlled)

핵심 메서드: tools/list, tools/call

동작 방식: 모델이 추론 과정에서 외부 세계에 영향을 미치거나(Side-effect) 계산 결과를 얻기 위해 호출한다. 서버는 도구 이름, 설명, JSON Schema 형식의 inputSchema를 클라이언트에 제공하며, 모델이 파라미터를 완성해 요청하면 서버가 실행 후 content 배열과 에러 여부(isError)를 반환한다.

보안 원칙: 도구 실행은 파일 수정, 데이터베이스 쓰기, 셸 명령 실행 등 시스템 변경을 유발할 수 있으므로, 클라이언트/호스트 레벨에서 반드시 사용자의 사전 승인(Human-in-the-loop) 가드레일이 적용될 수 있어야 한다.

2.2 Resources (애플리케이션 주도형 데이터 소스)

제어 주체: 호스트 및 사용자 (Application-Controlled)

핵심 메서드: resources/list, resources/read, resources/subscribe

동작 방식: 파일 내용, 로그 파일, 데이터베이스 스키마 등 부수 효과(Side-effect)가 없는 읽기 전용 데이터를 컨텍스트로 주입할 때 사용한다. 모든 리소스는 file:///logs/app.log나 postgres://db/schema처럼 고유한 URI로 식별되며, MIME Type(text/plain, application/json 등)과 함께 텍스트 또는 Base64 바이너리 형태로 전달된다.

보안 원칙: 모델이 임의로 호출하여 쓰는 것이 아니라, 사용자가 첨부하거나 호스트가 상황에 맞춰 수동적으로 주입하므로 예측 가능성이 높고 토큰 누수를 제어하기 쉽다.

2.3 Prompts (사용자 주도형 대화 워크플로)

제어 주체: 사용자 (User-Controlled)

핵심 메서드: prompts/list, prompts/get

동작 방식: 서버가 사전에 정의해 둔 구조화된 프롬프트 템플릿이다. 사용자가 슬래시 커맨드(예: /code-review, /generate-sql) 형태로 선택하면, 서버가 정의된 인자를 받아 치환한 뒤 LLM에 전달할 완성된 메시지 배열(messages: [{"role": "user", "content": ...}])을 합성해 반환한다.

3. 전송 계층(Transport) 심층 비교: Stdio vs SSE

MCP는 전송 계층과 애플리케이션 메시지 계층을 완전히 분리해 설계되었다 (MCP Transports 레퍼런스). 모든 메시지는 JSON-RPC 2.0 포맷을 따르지만, 실행 위치에 따라 두 가지 전송 방식을 선택한다.

3.1 Stdio 전송 계층 (로컬 프로세스 파이프)

로컬 데스크톱 앱이나 CLI 에이전트에서 가장 널리 쓰이는 기본 전송 방식이다. 호스트가 자식 프로세스로 MCP 서버를 스폰(Spawn)하고 표준 입출력 파이프를 통해 통신한다.

프레이밍 규약: 개행(\n)으로 구분되는 JSON 스트림(ndjson)을 사용한다. 즉, 1개의 요청 또는 응답은 반드시 단 한 줄의 완전한 JSON 문자열이어야 하며 개행 문자로 끝나야 한다.

로깅 격리 함정 (치명적): 서버 프로세스가 디버깅을 위해 표준 출력(stdout)에 print("Debug log")나 console.log()를 출력하면, 클라이언트는 이를 JSON-RPC 메시지로 파싱하려 시도하다가 즉시 -32700 ParseError를 일으키고 세션이 끊어진다. 서버의 모든 디버그 로그와 추적 정보는 반드시 표준 에러(stderr)로 출력해야 한다.

3.2 SSE 전송 계층 (원격 HTTP 스트리밍)

원격 클라우드 서버, 사내 인트라넷, 도커 컨테이너 등 네트워크 경계를 넘어 분산 실행되는 환경에서 사용된다.

단방향 스트리밍 + 역방향 POST 구조:

클라이언트가 서버의 GET /sse 엔드포인트로 연결하여 Server-Sent Events 채널을 연다.

서버는 첫 번째 이벤트로 고유 세션 ID가 포함된 endpoint 이벤트를 클라이언트에 전달한다.

클라이언트는 이후의 모든 JSON-RPC 요청을 해당 세션의 POST /message?sessionId=... 엔드포인트로 보낸다.

서버는 처리 결과나 비동기 알림을 열려 있는 SSE 스트림을 통해 실시간으로 밀어준다(Push).

4. 혼동하기 쉬운 5가지 프로토콜 경계와 보안 함정

MCP 기반 시스템을 구축하거나 디버깅할 때 빈번히 발생하는 5가지 기술적 경계와 위험 요소는 다음과 같다:

초기화 핸드셰이크가 완료되기 전에 일반 메서드를 호출하면 즉시 거부된다: 클라이언트는 연결 직후 반드시 initialize 요청을 보내 프로토콜 버전과 Capabilities를 협상해야 하며, 서버 응답을 받은 후 notifications/initialized 알림을 전송해야 한다. 이 2단계 핸드셰이크가 끝나기 전에는 ping을 제외한 tools/list나 resources/read 호출이 -32002 ServerNotInitialized 에러로 실패한다.

Stdio 전송에서 stdout 오염은 프로토콜 파괴로 직결된다: 서드파티 라이브러리가 초기화 중 stdout으로 출력하는 배너나 경고 문구 하나만으로도 JSON-RPC 파서가 완전히 정지된다. 실무에서는 프로세스 시작 시점부터 언어 레벨에서 stdout을 JSON-RPC 전용 채널로 래핑하고 나머지 런타임 표준 출력을 stderr로 리다이렉트해야 한다.

Resources 프리미티브의 경로 순회(Path Traversal) 공격 방어는 서버의 책임이다: resources/read 요청으로 들어오는 URI 파라미터(예: file:///logs/../../../../etc/passwd)를 검증 없이 파일시스템 경로로 변환하면 샌드박스 탈출 취약점이 발생한다. 반드시 os.path.realpath()나 pathlib.Path.resolve()를 통해 허용된 베이스 디렉터리 내부인지 검증하는 가드레일이 필수적이다.

JSON Schema 타입 불일치는 모델 환각(Hallucination) 시 즉시 -32602 에러를 반환해야 한다: 모델이 필수 파라미터를 누락하거나 숫자가 와야 할 자리에 문자열을 넘겼을 때 내부 비즈니스 로직에서 예외가 터지게 두면 안 된다. 디스패처 레벨에서 스키마를 사전 검증하여 정확한 -32602 InvalidParams 에러를 반환해야 모델이 스스로 파라미터를 교정해 재시도할 수 있다.

서버 리소스나 도구 목록이 동적으로 변할 때는 listChanged 알림을 발행해야 한다: 실행 중 파일이 추가되거나 사용자 권한 변경으로 사용 가능한 도구가 달라졌음에도 notifications/tools/list_changed 알림을 보내지 않으면, 클라이언트는 최초 캐시된 스키마만 유지하므로 최신 도구를 찾지 못하거나 삭제된 도구를 호출해 런타임 오류가 반복된다.

5. 실무 적용 코드: 안전한 Stdio 기반 TypeScript MCP 서버 예제

아래 코드는 공식 TypeScript SDK(@modelcontextprotocol/sdk)를 기반으로 Stdio 로깅 격리, JSON Schema 도구 검증, 읽기 전용 리소스 안전 경로 검사를 적용한 프로덕션 표준 패턴이다.

6. 로컬 Python 6대 프로토콜 불변식 검증 시뮬레이션

아래 스크립트는 공식 MCP 사양의 핵심 불변식 6종(① 초기화 전 호출 차단 및 핸드셰이크 상태 전이, ② JSON Schema 기반 필수 인자 검증 및 도구 에러 격리, ③ 리소스 URI 스킴 바인딩 및 MIME Type 처리, ④ 프롬프트 템플릿 인자 바인딩, ⑤ Stdio 개행 기반 ndjson 프레이밍 및 파싱 복원력, ⑥ 샌드박스 경로 순회 차단)을 순수 Python 환경에서 재현 검증한다.

로컬 터미널에서 스크립트를 실행한 결과는 다음과 같았다:

7. 실무 MCP 서버 구축 및 운영 점검 체크리스트

표준 출력(stdout) 순도 보장 및 로깅 격리: Stdio 모드로 실행되는 MCP 서버에서 서드파티 라이브러리나 디버그 코드가 stdout으로 비JSON 문자열을 내보내지 않도록, 모든 로그는 반드시 stderr로 출력하거나 전용 파일 로거로 우회한다.

2단계 핸드셰이크 및 프로토콜 버전 협상 준수: initialize 응답에 지원 프로토콜 버전(2024-11-05)을 명시하고, 클라이언트로부터 notifications/initialized 알림을 수신하기 전까지는 모든 비즈니스 요청을 거부하도록 상태 머신을 방어적으로 구축한다.

리소스(Resources) 접근 시 샌드박스 경로 엄격 검증: URI 파라미터를 역참조할 때 realpath 정규화를 거쳐 지정된 루트 디렉터리를 벗어나는 경로 순회(../) 시도를 원천 차단한다.

도구(Tools)의 JSON Schema 필수 인자 사전 검증: 모델의 파라미터 생성 오류나 환각에 대비하여, 필수 필드 누락이나 타입 불일치 시 isError: true 대신 JSON-RPC 규약에 따른 -32602 InvalidParams 에러를 명확히 반환해 모델의 자체 복구 루프를 지원한다.

도구 부수효과(Side-effects)에 대한 사용자 승인 가드레일 확보: 파일 삭제, 외부 API 발송, 셸 스크립트 실행 등 시스템 상태를 영구 변경하는 도구는 호스트 애플리케이션의 확인 프롬프트와 연동되도록 메타데이터와 안전 정책을 정의한다.