MCP (Model Context Protocol)

무엇인가

MCP는 AI 모델이 외부 도구·데이터에 연결될 때 쓰는 공통 규격이다. USB-C 케이블이 노트북·휴대폰·모니터를 한 가지 방식으로 잇듯이, MCP는 다양한 모델이 다양한 도구를 같은 방식으로 부르도록 만들어 준다.

왜 만들어졌나

[[frontier-model]] 같은 강력한 LLM이 등장하면서, 모델은 단순히 답을 생성하는 것을 넘어 파일을 읽고, 데이터베이스를 조회하고, 코드를 실행하기 시작했다. 그런데 모델마다 도구를 연결하는 방식이 달라서, 도구를 만드는 쪽도 모델을 쓰는 쪽도 매번 새로 배워야 했다.

Anthropic은 2024년 11월 MCP를 공개하면서 이 부분을 표준화하자고 제안했다. "한 번만 도구를 만들면, MCP를 지원하는 어떤 모델에서도 그대로 쓸 수 있다"는 그림이다.

어떻게 작동하는가

MCP는 크게 두 역할로 나뉜다.

• MCP 서버: 도구·데이터·프롬프트를 외부에 노출하는 쪽. 예를 들어 GitHub 저장소를 다루는 서버, 로컬 파일시스템을 다루는 서버처럼.
• MCP 클라이언트: 서버에 연결해서 도구를 호출하는 쪽. 보통 모델을 띄우는 앱(데스크톱 챗봇, IDE 확장 등)이 클라이언트가 된다.

서버와 클라이언트는 정해진 메시지 형식으로 대화한다. "어떤 도구가 있나요?" "이 도구를 이런 인자로 실행해 주세요" "결과는 이렇습니다" 같은 흐름이다.

어디서 쓰는가

가장 눈에 띄는 사례는 데스크톱 챗 앱이다. 사용자가 자신의 컴퓨터에 MCP 서버 몇 개를 설치해 두면, 모델이 그 도구들(파일 읽기, 검색, 메모 정리 등)을 자연스럽게 활용한다. IDE 확장이나 [[langchain]] 같은 프레임워크에서도 MCP 서버를 그대로 끌어다 쓸 수 있도록 어댑터가 늘어나는 추세다.

알아 두면 좋은 것

MCP는 만능이 아니다. 권한·인증은 여전히 서버 쪽에서 잘 설계해야 하고, 모델이 도구를 잘못 부르는 문제는 별도로 챙겨야 한다. 그러나 "도구 연결의 사실상 표준" 자리를 가장 먼저 노린 후보라는 점은 분명하다.

개요

MCP(Model Context Protocol)는 LLM 호스트와 외부 도구·데이터를 잇는 JSON-RPC 기반 프로토콜이다. Anthropic이 2024년 11월 공개했고, Python·TypeScript SDK가 함께 제공된다. 핵심 아이디어는 "한 번 만든 MCP 서버를 여러 클라이언트에서 그대로 쓸 수 있게 한다"는 것.

핵심 프리미티브

MCP 서버는 세 가지를 노출할 수 있다.

• Tools: 모델이 호출할 함수. function calling과 비슷하지만 스키마·인자·반환이 표준화돼 있다.
• Resources: 모델이 읽을 컨텍스트 데이터. URI로 식별하며, 정적 파일부터 동적 API 결과까지 추상화한다.
• Prompts: 사용자가 골라서 끼워 넣을 수 있는 프롬프트 템플릿.

여기에 sampling 같은 양방향 기능도 정의돼 있어, 서버가 거꾸로 클라이언트(=모델 호스트)에게 텍스트 생성을 요청할 수도 있다.

트랜스포트

• stdio: 로컬에서 서버를 자식 프로세스로 띄우고 표준 입출력으로 통신. 데스크톱 클라이언트의 기본 방식.
• HTTP + SSE / streamable HTTP: 원격 서버용. 비동기 이벤트 푸시가 필요한 경우에 쓴다.

트랜스포트는 갈아끼울 수 있고, 메시지 포맷(JSON-RPC 2.0)은 동일하다.

서버 하나 만들기 (예시 흐름)

Python SDK 기준 최소 구현은 이렇게 짧다.

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("weather")

@mcp.tool()
def get_forecast(city: str) -> str:
    return fetch_forecast(city)

if __name__ == "__main__":
    mcp.run()

이 서버를 클라이언트 설정 파일에 등록하면 끝이다. 클라이언트가 자동으로 capability를 협상하고 도구 목록을 받아 간다.

클라이언트 쪽 패턴

직접 MCP 클라이언트를 짜는 경우는 대개 두 가지다. (1) 일반 LLM API를 쓰면서 MCP 서버를 도구로 노출하고 싶을 때 — function calling으로 변환하는 어댑터를 둔다. (2) [[langchain]]·LlamaIndex 같은 프레임워크에서 기존 에이전트에 MCP 서버를 꽂을 때.

실무에서 챙길 것

• 권한 모델: MCP 자체에는 인증·권한 표준이 빈약하다. 서버에서 직접 토큰·스코프를 관리해야 한다.
• 에러 처리: 도구 실패는 JSON-RPC 에러로 돌아온다. 모델이 이해할 수 있는 자연어 메시지로 변환해 주면 회복 성공률이 올라간다.
• 장기 실행: 오래 걸리는 작업은 progress notification으로 진척률을 흘려 보내는 패턴이 권장된다.
• 로컬 vs 원격: 민감 데이터는 stdio 기반 로컬 서버에, 협업 데이터는 HTTP 원격 서버에 둔다는 식으로 신뢰 경계를 분리하면 권한 설계가 단순해진다.

설계 목표

MCP는 LLM이 도구·컨텍스트와 상호작용할 때 발생하는 두 종류의 단편화 문제를 풀려 한다. (1) 모델 공급자별로 다른 function calling 포맷, (2) 도구 통합 프레임워크([[langchain]], LlamaIndex 등)별로 다른 추상화. Anthropic은 2024년 11월 이 두 층을 떼어 내, 도구 측이 한 번 노출하면 어떤 호스트든 같은 방식으로 소비할 수 있는 portable한 인터페이스를 정의했다.

프로토콜 구조

전송은 JSON-RPC 2.0 위에 얹는다. 클라이언트–서버 양방향 메시지를 정의하며, 트랜스포트는 stdio, HTTP+SSE, streamable HTTP 등 여러 옵션을 둔다. 메시지는 세 종류다.

• Requests: 응답을 기대하는 호출. id, method, params.
• Notifications: 응답이 없는 단방향 메시지(progress, log 등).
• Responses: request에 대응. result 또는 error.

핸드셰이크 단계에서 클라이언트–서버는 initialize 요청으로 capability negotiation을 수행한다. "이 서버는 tools·resources·prompts 중 무엇을 지원하는가? 클라이언트는 sampling을 받아 줄 수 있는가?" 같은 능력 집합을 명시적으로 합의하고, 그 후의 모든 호출은 합의된 범위 안에서만 일어난다.

핵심 프리미티브

• Tool: 모델이 호출 가능한 함수. JSON Schema로 인자·반환을 명세한다. function calling과 직접 매핑되지만, 명세·실행 책임이 서버로 분리됐다는 점이 다르다.
• Resource: URI로 식별되는 컨텍스트 데이터. 호스트가 모델 컨텍스트에 어떻게 끼워 넣을지는 호스트 정책에 맡긴다.
• Prompt: 사용자가 명시적으로 선택할 수 있는 사전 정의 워크플로 템플릿.
• Sampling: 서버가 클라이언트에 LLM 추론을 위임. 서버 자체가 에이전틱 행동을 하면서 모델 능력을 빌려 쓸 수 있는 후크.

비교와 위치

function calling 단독 모델과 비교하면 MCP는 한 단계 위의 추상화다. function calling은 "모델이 어떤 함수를 부를지 결정"하는 메커니즘이고, MCP는 "그 함수가 어디에서 어떻게 발견·노출되는지"까지 표준화한다. 결과적으로 [[langchain]] 같은 도구 통합 라이브러리와 일정 부분 겹치지만, MCP는 라이브러리가 아니라 와이어 프로토콜이라는 점에서 층위가 다르다.

[[reasoning-model]]·[[frontier-model]] 시대로 가면서 모델이 더 길고 복잡한 도구 호출 시퀀스를 다루게 됐고, 이때 도구·자원의 발견·호출 메커니즘은 시스템 신뢰성에 직결된다. MCP는 "에이전트 프레임워크가 빠르게 진화해도 도구 측은 안정적 인터페이스를 유지"하도록 하는 어댑터 층 역할을 노린다.

한계와 열린 문제

• 인증·권한: 프로토콜 자체는 트랜스포트와 메서드만 정의하고, 누가 어떤 도구를 부를 수 있는지는 정의하지 않는다. 다중 사용자 환경에서는 별도 권한층이 필수다.
• 신뢰 경계: MCP 서버는 임의의 코드 실행을 노출하기 쉬워, 외부 서버를 신뢰할 때의 리스크가 크다. 서명·샌드박싱은 생태계 차원의 숙제다.
• 표준화 단계: 신생 표준이라 SDK·클라이언트 구현이 빠르게 바뀌고 있다. spec 자체도 streamable HTTP 같은 항목이 사후 추가됐다.
• 비용 모델: sampling처럼 서버가 모델 호출을 요청하는 흐름에서 비용·할당량이 누구에게 청구되는지는 설계자가 명시적으로 풀어야 한다.
• 평가의 부재: function calling 정확도 벤치마크는 많지만, MCP 서버 호출 흐름 자체의 신뢰성을 측정하는 표준 평가는 아직 정착되지 않았다.

이 용어를 언급한 기사

• OpenAI, 생명과학 추론 모델 'GPT-Rosalind' 공개