6편 · 약 18분

MCP(Model Context Protocol): LLM이 도구를 연결하는 방식의 표준화

통합 코드가 쌓이는 이유

LLM 응용을 처음 만들 때는 단순하다. API를 호출하고 응답을 표시한다. 그런데 실제 업무에 쓸 시스템을 만들기 시작하면 모델이 외부와 통신해야 하는 순간이 생긴다. 데이터베이스 조회, REST API 호출, 파일 읽기, 웹 검색. 팀마다 이 연결을 각자 방식으로 구현해왔다. 함수 호출 시그니처가 달랐고, 인증 방식이 달랐으며, 에러 처리 규약도 달랐다.

모델이 바뀔 때마다 통합 코드를 다시 써야 했다. 도구가 바뀌면 호출 쪽도 바꿔야 했다. 한 팀이 만든 연결 방식을 다른 팀이 재사용하기 어려웠다.

MCP(Model Context Protocol)은 이 조각화 문제를 해결하기 위해 Anthropic이 2024년 11월 공개한 오픈 표준이다. 어떤 LLM 응용이든, 어떤 외부 도구나 데이터 소스든, 단일한 방식으로 연결할 수 있게 한다. USB-C가 다양한 기기를 단일 포트로 연결하듯, MCP는 LLM과 도구 사이의 공통 어댑터다.

2025년 12월, Anthropic은 MCP를 Linux Foundation 산하 Agentic AI Foundation(AAIF)에 기증했다. Anthropic, Block, OpenAI가 공동 창립한 중립 재단이다. 프로토콜이 특정 벤더에 종속되지 않게 하기 위한 거버넌스 결정이었다. 현재 안정 스펙은 2025년 11월 25일 발행된 버전이다.

이 장은 MCP 공식 스펙(2025-11-25), MCP 공식 블로그, OWASP MCP 보안 가이드, Anthropic 발표 자료를 기준으로 한다. 2026년 로드맵 항목은 확정 전 변경될 수 있으며 출처를 명시했다.

아키텍처: Host, Client, Server

MCP 3계층 아키텍처 — Host·Client·Server 역할과 통신 경로

MCP 아키텍처는 세 개의 역할로 구성된다.

Host: 사용자가 직접 상호작용하는 LLM 응용 프로그램. Claude Desktop, IDE AI 플러그인, 내부 챗봇이 모두 호스트다. 호스트는 대화를 소유하고, 모델을 호출하며, 사용자 동의를 관리한다. 보안 결정의 최종 책임자다. 어떤 서버의 어떤 도구를 실행할지 결정하는 권한이 호스트에 있다.

Client: 호스트 프로세스 안에서 MCP 서버와 1:1 stateful 세션을 유지하는 컴포넌트. 하나의 클라이언트는 하나의 서버와만 연결된다. JSON-RPC 메시지 라우팅, 구독 관리, 타임아웃 처리를 담당한다.

Server: 실제 기능을 노출하는 경량 프로세스. 데이터베이스 드라이버, API 클라이언트, 파일 시스템 접근이 서버로 래핑된다. 서버는 호스트를 신뢰하지 않는다는 원칙으로 설계됐다. 들어오는 모든 요청을 자신의 권한 범위 안에서만 처리한다.

JSON-RPC 2.0과 세션 생명주기

MCP 메시지는 모두 JSON-RPC 2.0 규격을 따른다. 요청(id 있음), 응답(id 있음), 알림(id 없음·응답 없음) 세 유형이 있다.

요청 (클라이언트 → 서버):
  { "jsonrpc": "2.0", "id": 42, "method": "tools/call",
    "params": { "name": "query_db", "arguments": { "sql": "SELECT ..." } } }

응답 (서버 → 클라이언트):
  { "jsonrpc": "2.0", "id": 42, "result": { "content": [...] } }

알림 (단방향, 응답 없음):
  { "jsonrpc": "2.0", "method": "notifications/tools/list_changed" }

세션은 세 단계를 순서대로 따른다. 순서를 위반하면 프로토콜 오류가 발생한다.

① 초기화 (블로킹)

Client → Server: initialize — protocolVersion, capabilities, clientInfo 전송

Server → Client: initialize result — 서버 지원 버전·기능 반환

Client → Server: initialized (알림) — 세션 활성화. 이후 운영 단계 시작

→

② 운영 (무제한)

도구 실행: tools/call

리소스 읽기: resources/read

프롬프트 조회: prompts/get

목록 변경 알림: notifications/tools/list_changed

→

③ 종료

close 알림 또는 연결 끊김으로 세션 정리

세션 내 협상된 기능은 해당 세션에만 유효

기능 협상 (capability negotiation)

초기화 단계에서 양측이 지원하는 선택적 기능을 합의. 합의된 기능 밖의 메서드 호출은 오류 반환

주요 협상 항목: listChanged (목록 변경 알림), subscribe (리소스 개별 구독), roots (클라이언트 파일시스템 루트 노출), sampling (서버가 LLM 추론 요청)

MCP 세션 생명주기 — 3단계 흐름

기능 협상을 통해 양측은 이 세션에서 어떤 옵션 기능을 사용할지 명시적으로 합의한다. 합의되지 않은 기능을 호출하면 프로토콜 오류가 반환된다. 이 덕분에 클라이언트와 서버가 각자 다른 기능 집합을 지원해도 안전하게 함께 동작할 수 있다.

3가지 핵심 프리미티브

Tools — LLM이 실행을 요청하는 함수

도구는 LLM이 서버에게 "이것을 실행해줘"라고 요청하는 함수다. 데이터베이스 조회, API 호출, 계산이 모두 도구로 노출된다. 서버는 JSON Schema로 입력 파라미터를 정의하고, LLM은 이 스키마를 보고 적절한 인자를 생성해 호출을 요청한다.

{
  "name": "query_database",
  "description": "SQL SELECT 쿼리를 실행하고 결과 행을 반환합니다",
  "inputSchema": {
    "type": "object",
    "properties": {
      "sql":   { "type": "string",  "description": "실행할 SELECT 쿼리" },
      "limit": { "type": "integer", "description": "최대 결과 행 수 (기본 100)" }
    },
    "required": ["sql"]
  }
}

도구 실행은 외부 상태를 변경할 수 있다. 따라서 호스트가 사용자 동의를 받은 후 실행하는 것이 MCP 규약의 핵심 요구사항이다.

Resources — 읽기 전용 컨텍스트 데이터

리소스는 LLM의 컨텍스트를 풍부하게 만드는 읽기 전용 데이터다. 파일 내용, 데이터베이스 스키마, API 문서, 로그 항목이 리소스로 노출된다.

도구가 "무언가를 한다"면, 리소스는 "무언가를 안다". 리소스 접근은 외부 상태를 변경하지 않으므로 도구보다 낮은 신뢰 수준에서도 허용될 수 있다.

각 리소스는 URI로 식별된다. 예를 들어 db://schema/users 또는 file:///workspace/config.yaml 형식이다. 서버는 resources/list 메서드로 사용 가능한 리소스 목록을, resources/read 로 실제 내용을 제공한다.

Prompts — 재사용 가능한 메시지 템플릿

프롬프트는 특정 태스크를 위해 서버가 사전 정의한 메시지 시퀀스다. 코드 리뷰 요청, 장애 분석, SQL 최적화 같은 반복 태스크를 프롬프트로 만들어두면, 클라이언트가 prompts/list와 prompts/get으로 조회해 LLM 컨텍스트에 주입할 수 있다.

트랜스포트 레이어

MCP는 전송 계층을 추상화해 두 가지 트랜스포트를 공식 지원한다.

트랜스포트	용도	동작 방식
stdio	로컬 서버 (같은 머신)	클라이언트가 서버를 subprocess로 실행. stdin/stdout으로 JSON-RPC 메시지 교환. 가장 단순하고 격리 수준이 높음
Streamable HTTP	원격 서버 (HTTPS)	POST로 요청, SSE(Server-Sent Events)로 응답과 알림. 다중 클라이언트 지원. 프로덕션 원격 배포에 적합

구 HTTP+SSE 트랜스포트는 2025년 3월 스펙에서 deprecated됐다. 새 프로젝트는 Streamable HTTP를 사용한다.

2026년 로드맵에는 Stateless Streamable HTTP가 포함됐다. 여러 서버 인스턴스 간에 세션 상태를 공유하지 않아도 로드밸런서 뒤에서 수평 확장이 가능하도록 트랜스포트를 진화시키는 작업이다. 이 변화는 Q1 2026 SEP 확정을 목표로 했으나 스펙 포함 시점은 다음 릴리스에서 확인해야 한다.

Sampling — 서버가 LLM을 역으로 호출하는 패턴

MCP 2025-11-25 스펙에서 Sampling 기능이 추가됐다. 일반적인 흐름에서는 호스트가 LLM을 호출하고 LLM이 서버에 도구를 요청한다. Sampling은 이 방향을 뒤집는다. 서버가 클라이언트에게 "이 컨텍스트로 LLM을 호출해줘"라고 요청할 수 있다.

복잡한 에이전트 흐름에서 유용하다. 서버가 중간 결과를 LLM에게 평가시키거나, 다음 스텝의 파라미터를 LLM에게 생성하게 할 수 있다. 그러나 이 기능은 서버가 LLM 호출에 영향을 줄 수 있어 보안 검토가 필수다. 서버가 호스트의 승인 없이 임의 컨텍스트로 모델을 호출하지 못하도록 호스트가 명시적으로 허용해야 한다.

보안 고려사항

2026년 2월, OWASP는 "MCP 서버 개발을 위한 실용 보안 가이드"를 발표했다. 주요 위험 지점은 세 가지다.

도구 입력 검증: 모든 도구 파라미터를 정의된 스키마로 엄격하게 검증한다. 사용자 입력을 셸 명령, SQL 쿼리, 파일 경로에 직접 전달하지 않는다. 서버는 입력을 신뢰하지 않는 외부 데이터로 취급한다.

권한 최소화: 서버는 실제로 필요한 권한만 가진다. 읽기 전용 데이터베이스 서버에 쓰기 권한을 주지 않는다. 파일 서버의 접근 경로를 /workspace 같은 특정 디렉터리로 제한한다.

신뢰 경계 명시: 호스트는 어떤 서버를 신뢰하는지 명시적으로 관리한다. 서버가 자신의 권한 범위를 스스로 선언하도록 허용하면 악의적 서버가 권한을 초과 선언할 수 있다.

MCP 서버를 직접 만들 때의 판단 기준

stdio가 적합한 경우

로컬 개발 환경 또는 단일 머신 배포

서버를 호스트와 같은 머신에서 subprocess로 실행 가능

네트워크 노출이 필요하지 않음

보안 격리가 프로세스 레벨로 충분

Streamable HTTP가 적합한 경우

여러 클라이언트(팀 전체)가 같은 서버를 사용

원격 머신에 서버를 배포

OAuth / OpenID Connect 기반 인증 필요

수평 확장·로드밸런서 뒤에 배포

프리미티브 선택 기준

Tool: 외부 상태 변경 또는 부작용이 있는 모든 작업. 실행 전 호스트의 사용자 동의 절차를 설계에 포함한다

Resource: 읽기 전용 데이터 제공. 파일 내용, 스키마, 문서처럼 LLM이 컨텍스트로 읽어야 하는 모든 것

Prompt: 반복 태스크의 메시지 시퀀스를 표준화. 팀이 공통으로 쓰는 분석·리뷰 워크플로에 적합

보안 체크리스트

도구 inputSchema를 엄격하게 정의하고 서버 측에서 재검증한다

사용자 입력을 SQL·셸·파일 경로에 직접 보간하지 않는다

서버에 최소 권한만 부여한다 — DB 읽기 전용, 파일 경로 화이트리스트

Sampling 기능을 활성화하면 호스트가 서버의 LLM 호출 요청을 반드시 심사한다

MCP 서버 설계 체크리스트

정리

MCP가 해결하는 문제는 단순하다. LLM 응용마다 다르게 구현하던 도구 연결을 단일한 표준으로 통일한다. 한 번 MCP 서버를 만들면 Claude Desktop, IDE 플러그인, 내부 챗봇 어디에서든 재사용할 수 있다. 한 번 MCP 클라이언트를 구현하면 어떤 MCP 서버도 연결할 수 있다.

아키텍처적으로 세 역할의 분리가 핵심이다. 호스트는 사용자 동의와 보안을 담당하고, 클라이언트는 프로토콜 세션을 유지하며, 서버는 기능을 노출한다. 서버는 호스트를 신뢰하지 않고, 호스트는 서버를 허용 목록으로 관리한다.

현재 안정 스펙(2025-11-25)의 Sampling, Elicitation, OAuth 지원은 에이전트 시나리오에서 MCP 범위를 크게 확장했다. 다음 스펙 릴리스에서 Stateless HTTP 트랜스포트가 정식화되면 서버의 수평 확장이 더 자연스러워질 것이다.