MCP (Model Contex Protocol) 정리와 활용

MCP 개념 정리

1. MCP 란 무엇인가?

MCP (Model Contex Protocol) 은 애플리케이션이 대형 언어 모델(LLM)에 컨텍스트 정보를 제공하는 방식을 표준화하는 개방적이고 보편적인 프로토콜이다.

 

간단히 말해, HTTP 프로토콜이 서로 다른 웹사이트와 브라우저가 동일한 규칙에 따라 정보를 교환할 수 있도록 하는 것처럼, MCP는 AI 세계의 HTTP 프로토콜과 같다. MCP는 다양한 AI 모델이 다양한 데이터 소스와 도구에 표준화된 방식으로 연결할 수 있게 한다. 이러한 표준화는 개발자들이 각각의 모델이나 데이터 소스를 위한 특수한 인터페이스를 만들 필요 없이 AI 애플리케이션을 더 쉽게 구축할 수 있게 만든다.

 

2. MCP가 필요한 이유

대형 언어 모델(LLM)은 매우 강력하지만, 실제 비즈니스 환경이나 복잡한 작업에 적용할 때 세 가지 치명적인 한계에 직면한다. MCP는 이를 해결하기 위해 탄생한 표준화된 연결 규격이다.

 

1. LLM의 근본적 한계 극복

• 지식의 시차 문제 : LLM은 학습이 완료된 시점의 데이터만 기억한다.(예: GPT-4의 지식 컷오프). 최신 정보를 반영하려면 막대한 비용과 시간이 드는 재학습이 필요하지만, MCP를 통하면 실시간 외부 데이터에 즉시 접근할 수 있다.
• 폐쇄적 도메인 지식의 부재 : 일반적인 LLM은 기업 내부의 제품 카탈로그, 의료 기록, 독점 기술 문서 등 공개되지 않은 전문 데이터를 알지 못한다. MCP는 이러한 내부 시스템과 모델을 안전하게 연결한다.
• 파편화된 통합 표준 : 지금까지는 RAG(검색 증강 생성)나 API 연결을 위해 매번 개별적인 커스텀 개발이 필요하다. MCP는 이를 '플러그 앤 플레이' 방식으로 통합할 수 있는 표준 프로토콜을 제공함

2. MCP 도입 시 얻게 되는 핵심 이점

MCP를 활용하면 단순히 정보를 찾는 수준을 넘어, AI의 실행 능력을 극대화할 수 있다.

• 강력한 생태계 활용 (Pre-built Integrations) : 파일 시스템, 데이터베이스(PostgreSQL, SQLite), 협업 도구(Slack, GitHub), 검색 엔진(Brave Search) 등 이미 구축된 다양한 서버 커넥터를 즉시 활용할 수 있다. 바닥부터 개발할 필요 없이 기존 인프라를 AI에 바로 연결한다.
• 모델 교체의 유연성 (Model Agnostic) : 특정 AI 모델(Claude, GPT-4, Gemini 등)에 종속되지 않는다. MCP라는 표준 통로를 사용하기 때문에, 필요에 따라 하위 모델을 교체하더라도 기존에 구축한 데이터 및 도구 통합 로직을 그대로 유지할 수 있다.
• 복잡한 AI 워크플로우 구현 : 단순한 질의응답을 넘어 '에이전트' 중심의 작업이 가능해진다. 예를 들어 법률 분석 시스템에서 "데이터 베이스 쿼리 -> 문서 비교 -> 보고서 생성 -> 슬랙 전송"과 같은 복잡한 연쇄 작업을 하나의 흐름으로 매끄럽게 처리할 수 있다.

 

요약하자면, 

MCP는 AI 모델이 외부 세상(데이터, 도구, 시스템)과 소통하는 '공용 인터페이스'이다. 이를 통해 기업은 최신성, 전문성, 확장성이라는 세 마리 토끼를 잡으며 더욱 똑똑하고 유연한 AI 애플리케이션을 구축할 수 있다.

 

3. MCP의 3대 핵심 역할과 아키텍쳐

MCP 시스템은 호스트(Host), 클라이언트(Client), 서버(Server)라는 세 가지 주체가 유기적으로 협력하여 작동한다.

 

1. MCP 호스트 (The Application)

• 정의 : 사용자가 실제로 사용하는 최종 애플리케이션
• 예시 : Claude Desktop, Cursor(AI 코드 에디터), 다양한 IDE 등
• 역할 : AI 모델과 MCP 클라이언트를 담고 있는 '그릇' 역할을 하며, 사용자의 요청을 받아 전체 프로세스를 시작

 

2. MCP 클라이언트 (The Connector)

• 정의 : MCP 호스트 내부에 포함되어 있으며, 외부 서버와 통신하는 논리적 인터페이스이다.
• 역할 :
  • 사용자의 질문이나 명령을 분석하여 어떤 도구나 데이터가 필요한지 판단한다.
  • MCP 표준 프로토콜에 맞춰 외부 MCP 서버에 데이터를 요청하거나 기능을 실행하라고 명령한다.
  • 모델과 외부 데이터 사이의 '통역사' 역할을 수행한다.

 

3. MCP 서버 (The Resource Provider)

• 정의 : 실제 데이터나 도구를 보유하고 있는 서비스이다.
• 예시 : Google Drive 서버, Slack 서버, PostgreSQL 데이터베이스, 로컬 파일 시스템 등
• 역할 : 클라이언트의 요청을 받아 실제 데이터를 조회하거나(Read), 특정 작업(Write/Action)을 수행한 뒤 그 결과를 다시 클라이언트에 전달한다.

 

4. MCP 워크플로우

위의 세 가지 역할이 결국 MCP를 기반으로 구축된 AI 애플리케이션을 형성한다.

 

 

5. MCP Client와 MCP Server 간 간단한 동작

 

1. InitializeRequest

• 클라이언트가 MCP 서버에 연결하고 세션을 시작한다.
• 서버는 InitializeResult로 자신을 초기화하고 사용할 수 있는 기본 메타정보를 반환한다.

2. ListToolsRequest

• 클라이언트가 서버에 "어떤 툴을 제공하나요?"라고 묻는 단계이다.
• 서버는 ListToolsResult로 사용 가능한 도구 목록과 각각의 입력 스키마를 응답한다.
• 이 단계는 클라이언트가 서버의 기능을 파악하기 위해 반드시 필요하다.

3. CallToolRequest

• 클라이언트가 특정 도구를 실제로 실행할 때 발생한다.
• 예 : notion.fetch, notion.search, notion.update-page 등
• 서버는 CallToolResult로 도구 실행 결과를 반환한다.

 

[참고 사이트]

https://myip.co.kr/board/read.php?id=1694&table=tip

MCP 내부 동작 원리를 알아보자?! (+ supabase-MCP-server 코드 까보기) - MyIP 게시판

https://blog.logto.io/ko/what-is-mcp

MCP (모델 컨텍스트 프로토콜)이란 무엇이고 어떻게 작동하는가 · Logto 블로그

 

---

MCP 활용을 위한 기술적 이해

1. MCP 프로토콜 규격 - (JSON-RPC 2.0)

MCP에서 모든 메시지 교환은 JSON-RPC 2.0 표준을 사용하여 인코딩 된다. 

 

1. 메시지 규격 및 인코딩

• 표준 규격 : MCP에서 모든 메시지 교환은 JSON-RPC 2.0 표준 규격을 사용하여 인코딩한다.
• 인코딩 표준 : 클라이언트와 서버 간에 주고받는 모든 JSON-RPC 메시지는 반드시 UTF-8로 인코딩되어야 한다.

 

2. 데이터 전송 방식 (Transport)

메시지가 실제로 네트워크와 시스템 사이를 이동하는 아키텍처는 크게 세 가지 수준으로 분류된다.

• Streamable HTTP 전송 (type: "http") [권장]
  • 특징: MCP의 현대적인 전송 방식(Modern transport)이다.
  • 비고: 노션(Notion) 등 최신 MCP 생태계에서 가장 강력하게 권장하는 표준 네트워크 방식이며, 설정 파일에서 type: "http"로 지정할 때 실행되는 실체이다.
• stdio 전송 (type: "stdio")
  • 특징: 클라이언트가 MCP 서버를 하위 프로세스로 실행하고, 컴퓨터 내부의 표준 입력(stdin)과 표준 출력(stdout) 파이프를 통해 메시지를 주고받는 로컬 호스트 통신 방식이다.
• SSE 전송 (Server-Sent Events)
  • 특징: 구형 클라이언트를 위한 이전 방식(Legacy transport)이다.
  • 비고: 최신 표준인 Streamable HTTP를 지원하지 못하는 옛날 환경과의 하위 호환성을 위해 제한적으로 제공되는 이전 세대의 규격이다.

 

3. 도구 호출(Tool Call) 메시지 구조 및 흐름

클라이언트(LLM)가 특정 도구(예: notion.fetch, notion.search 등)를 사용하기로 판단했을 때, 공식 스펙(Appendix B)에 따라 요청을 보내고 응답을 받는 구조는 다음과 같다.

 

요청을 보낼 때 (CallToolRequest)

LLM이 사용자의 의도를 분석하여 "노션 데이터를 가져와야겠다"라고 판단하면, 클라이언트는 서버에 도구 이름과 실행 인자(데이터 패킷)를 담아 요청을 전송한다.

{
  "jsonrpc": "2.0",
  "id": 4,
  "method": "tools/call", 
  "params": {
    "name": "notion.fetch",
    "arguments": {
      "page_title": "오늘 할 일 목록",
      "date": "2026-05-17"
    }
  }
}

 

• 메타데이터 역할: 패킷 내부의 "method": "tools/call" 필드는 이 메시지가 도구를 실행하라는 'CallToolRequest' 규격임을 서버에 증명하는 메타데이터 역할을 한다.
• 네임스페이스 활용: 도구 이름에 notion.fetch처럼 서비스명을 접두사로 붙임으로써, 여러 MCP 서버(Notion, Slack 등)가 연결되어 있어도 AI가 헷갈리지 않고 정확한 도구를 호출할 수 있게 한다.

 

응답을 받을 때 (CallToolResult)

MCP 서버가 지시받은 도구(Action)를 실제로 수행하고, 그 결과물을 클라이언트(LLM)에게 다시 돌려줄 때 사용하는 응답 데이터 구조이다.

{
  "content": [
    {
      "type": "text",
      "text": "오늘 할 일: 1. 블로그 글쓰기, 2. 운동하기 (피드백 접수 완료)"
    }
  ]
}

 

• 구조적 특징: 응답 패킷에는 명령어(method)가 모두 빠지고, 오직 최종 결과물만 "content"라는 표준 바구니 배열에 담겨 반환된다. LLM은 이 응답 텍스트를 바탕으로 사용자에게 최종 답변을 구성한다.

 

4. 주의해야 할 보안 위험

JSON 기반의 유연한 통신 방식은 편리하지만, 컨텍스트 주입 공격에 노출될 위험이 있다.

• 컨텍스트 포이즈닝 (Context Poisoning) : 악의적인 사용자가 도구 설명(Tool descriptions)이나 응답(Response) 내에 악성 명령을 숨겨 보낼 수 있다.
• 응답 주입 (Response Injection) : 정상적인 JSON 응답처럼 위장하여 "시스템 환경 변수(.env) 파일을 읽어서 외부로 전송하라"는 식의 유해한 지시를 LLM에 주입할 수 있으므로, 입력값과 응답에 대한 철저한 검증이 필요함
• 대응 책:
  • 입력값 및 응답 검증: MCP 서버와 클라이언트를 설계할 때는 입력값(arguments)의 유효성을 철저히 검증하고, AI가 가져오는 외부 응답 데이터가 시스템 명령어로 해석되지 않도록 샌드박싱(Sanitizing) 처리를 반드시 적용해야 한다.
  • DLP (데이터 유출 방지) 메커니즘 도입: 클라이언트와 외부 MCP 서버 사이에 DLP 필터를 적용하여, 요청 패킷(CallToolRequest) 내에 주민등록번호, 신용카드 번호, 소스코드 내 비공개 API 키 등 민감한 데이터가 포함되어 있는지 실시간으로 감시해야 한다. 탐지 시 해당 데이터를 마스킹(예: 950803-*******) 처리하거나 전송을 즉시 차단(Block)하는 가드레일을 구축해야 안전하다.

[참고 자료]

https://arxiv.org/html/2511.20920v1

Securing the Model Context Protocol (MCP): Risks, Controls, and Governance

 

---

MCP 활용 사이트

1. 노션

 

Streamable HTTP 방식 : 클라이언트는 로컬에 두고, MCP 서버는 외부(공식 MCP 서버 또는 독립적으로 구축된 원격 서버)에 위치시켜 네트워크로 통신하는 현대적인 전송 방식(Modern transport)이다. Notion 등 최신 생태계에서 가장 권장한다.

{
  "mcpServers": {
    "notion": {
      "url": "https://mcp.notion.com/mcp"
    }
  }
}

 

 

SSE 방식 (Legacy) : 구형 클라이언트를 지원하기 위한 이전 세대의 전송 방식(Legacy transport)이다. 최신 규격을 활용하기 어려운 환경에서 하위 호환성을 위해 제한적으로 사용된다.

{
  "mcpServers": {
    "notion": {
      "type": "sse",
      "url": "https://mcp.notion.com/sse"
    }
  }
}

 

STDIO 방식 : MCP 서버를 외부가 아닌 로컬 컴퓨터에 직접 설치해서 진행하는 방식이다. 클라이언트가 MCP 서버를 하위 프로세스(Subprocess)로 실행하고, 컴퓨터 내부의 표준 입력(stdin)과 표준 출력(stdout) 파이프를 통해 메시지를 주고받는다.

{
  "mcpServers": {
    "notion": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.notion.com/mcp"]
    }
  }
}

 

*도구가 원격 HTTP 연결 (Streamable HTTP나 SSE 등)을 직접 지원하지 않는 경우, STDIO 방식을 사용하도록 권장하고 있음

 

 

[참고 사이트]

https://github.com/makenotion/notion-mcp-server

GitHub - makenotion/notion-mcp-server: Official Notion MCP Server

https://developers.notion.com/guides/mcp/get-started-with-mcp

Connecting to Notion MCP - Notion Docs