LLM | MCP란?

AI를 사용해 직접 만든 이미지입니다.

MCP란 AI 애플리케이션이 외부의 데이터와 기능을 사용할 수 있도록 연결 방식을 표준화한 프로토콜이다.

이번 글에서는 MCP가 왜 등장했는지부터 Host, Client, Server의 관계, 그리고 Tools, Resources, Prompts가 무엇인지까지 차근차근 정리해보려고 한다.

 

이 글은 MCP 26.07.28 프로토콜을 기준으로 정리했다. MCP는 빠르게 발전하고 있기 때문에 과거 문서나 예제를 볼 때는 사용 중인 프로토콜 버전을 함께 확인하는 것이 좋다.

---

 

MCP의 필요성

먼저 아주 간단한 상황을 하나 생각해보자. AI에게 다음과 같이 요청한다고 가정해보자. "내 캘린더에서 다음 주 일정을 찾아서 정리해줘."

사람 입장에서는 간단한 요청처럼 보인다.

하지만 LLM 자체는 내 Google Calendar에 접근할 수 없다.

사용자 -> LLM -> ??? -> Google Calendar

결국 LLM과 외부 시스템 사이를 연결해주는 무언가가 필요하다.

물론 기존 API를 직접 연결할 수도 있다. 문제는 연결해야 할 서비스가 많아질 때다.

예를 들어 AI 애플리케이션에서 다음과 같은 서비스들을 사용하고 싶다고 해보자.

GitHub
Slack
Notion
Google Drive
PostgreSQL
Jira
Google Calendar

그리고 이 기능을 사용하는 AI 애플리케이션 역시 하나가 아닐 수 있다.

ChatGPT
Claude
Cursor
VS Code
사내 AI Agent

 

각 애플리케이션이 각각의 서비스와 직접 연결하면 구조가 금방 복잡해진다.

Claude ───── GitHub
Claude ───── Slack
Claude ───── Notion

ChatGPT ──── GitHub
ChatGPT ──── Slack
ChatGPT ──── Notion

Cursor ───── GitHub
Cursor ───── Slack
Cursor ───── Notion

서비스마다 인증 방식과 API 형식이 다르고, AI 애플리케이션마다 외부 기능을 등록하는 방식도 다르다. 연결 대상이 늘어날수록 통합 코드 역시 계속 증가한다.

AI를 사용해 직접 만든 이미지입니다.

 

MCP는 이 문제를 해결하기 위해 등장했다.

AI Application
      ↓
     MCP
      ↓
External System

즉 핵심은 다음과 같다.

AI 애플리케이션과 외부 시스템 사이의 연결 인터페이스를 표준화한다.

MCP 공식 문서에서는 이를 흔히 AI 애플리케이션을 위한 USB-C에 비유한다. USB-C 규격을 지원하는 장치라면 동일한 인터페이스를 통해 다양한 장치를 연결할 수 있듯이, MCP라는 공통 규격을 사용하면 AI 애플리케이션과 외부 시스템을 보다 일관된 방식으로 연결할 수 있다는 의미다.

 

MCP는 LLM 자체가 사용하는 프로토콜이 아니라 AI 애플리케이션과 외부 시스템을 연결하기 위한 프로토콜이다.

예를 들어 구조를 단순화하면 다음과 같다.

사용자
  ↓
AI Application
  ├── LLM
  │
  └── MCP Client
        ↓
     MCP Server
        ↓
 GitHub / DB / Slack / Files

여기서 LLM은 사용자의 요청을 이해하고 어떤 작업이 필요한지 판단한다. 반면 MCP는 필요한 데이터나 기능을 외부에서 가져오기 위한 연결 방법을 제공한다.

따라서 이렇게 구분하면 이해하기 쉽다.

LLM = 생각하고 판단하는 역할

MCP = 외부 세계와 연결하는 규격

즉, MCP ≠ LLM API 다.

AI를 사용해 직접 만든 이미지입니다.

 

 

MCP의 핵심 구조: Host, Client, Server

MCP를 이해할 때 가장 먼저 알아야 할 개념이 세 가지 있다.

• Host
• Client
• Server

 

전체 구조는 다음과 같다.

AI를 사용해 직접 만든 이미지입니다.

 

 

Host

Host는 MCP를 사용하는 AI 애플리케이션이다. 예를 들면 다음과 같은 프로그램이 Host가 될 수 있다.

Claude
ChatGPT
Cursor
VS Code
사내 AI Agent

Host는 사용자의 요청을 받고 LLM을 실행하며, MCP Client를 관리한다. 쉽게 말하면 우리가 실제로 사용하는 AI 프로그램 전체라고 볼 수 있다.

 

Client

Client는 Host 내부에서 MCP Server와 통신하는 역할을 한다. 예를 들어 어떤 AI 애플리케이션이 GitHub MCP Server를 사용한다고 해보자.

AI Application (Host)
        │
   MCP Client
        │
   MCP Server
        │
      GitHub

MCP Client는 Server가 어떤 기능을 제공하는지 확인하고, 필요한 기능을 호출하고, 결과를 받아 Host에 전달한다.

 

Server

MCP Server는 실제 데이터나 기능을 MCP 규격에 맞게 제공하는 프로그램이다. 예를 들어 다음과 같은 MCP Server를 만들 수 있다.

GitHub MCP Server
Filesystem MCP Server
PostgreSQL MCP Server
Slack MCP Server
Calendar MCP Server
사내 문서 MCP Server

중요한 점은 MCP Server 자체가 반드시 데이터를 가지고 있어야 하는 것은 아니라는 것이다.

 

예를 들어 GitHub MCP Server의 내부는 다음과 같을 수 있다.

AI
 ↓
MCP Client
 ↓
GitHub MCP Server
 ↓
GitHub API
 ↓
GitHub

즉 MCP Server는 기존 API나 데이터베이스, 파일 시스템 등을 AI가 사용할 수 있는 MCP 인터페이스로 감싸주는 어댑터 역할을 한다고 생각하면 이해하기 쉽다.

 

 

MCP Server가 제공하는 세 가지 핵심 기능

MCP Server를 공부할 때 반드시 알아야 할 개념이 있다.

Tools
Resources
Prompts

이 세 개의 차이를 이해하면 MCP의 전체 구조가 훨씬 명확해진다.

 

Tools - AI가 실행할 수 있는 행동

Tool은 AI가 실행할 수 있는 기능이다. 예를 들어 GitHub MCP Server라면 다음과 같은 Tool을 제공할 수 있다.

create_issue
get_issue
list_pull_requests
add_comment

Calendar MCP Server라면 이런 Tool이 있을 수 있다.

get_events
create_event
delete_event

Database MCP Server라면 다음과 같은 기능도 가능하다.

query_database

 

MCP Client는 서버에 어떤 Tool이 존재하는지 요청할 수 있다.

대표적인 요청이 다음과 같다.

tools/list

그리고 특정 Tool을 실행할 때는:

tools/call

을 사용한다.

Tool은 입력값의 구조도 정의한다. 예를 들어 날씨를 조회하는 Tool이 있다면 개념적으로 다음과 같은 형태가 될 수 있다.

{
  "name": "get_weather",
  "description": "특정 지역의 현재 날씨를 조회합니다.",
  "inputSchema": {
    "location": "string"
  }
}

덕분에 AI는 이 Tool이 어떤 기능인지, 어떤 입력값이 필요한지 알 수 있다.

 

Resources - AI가 사용할 데이터

Resource는 AI에게 제공되는 데이터 또는 Context다. 예를 들어 다음과 같은 것들이 Resource가 될 수 있다.

파일 내용
README
DB Schema
회사 내부 문서
설정 파일
API 응답
Knowledge Base

특정 Resource를 URI 형태로 표현할 수도 있다.

resource://company/engineering-guide

resource://company/database-schema

resource://project/README

Tool과 Resource의 차이는 이렇게 생각하면 쉽다.

Resource
→ 정보를 읽는다.

Tool
→ 무엇인가를 실행한다.

예를 들어:

회사 개발 가이드 읽기
→ Resource

GitHub Issue 생성
→ Tool

이다.

 

Prompts - 재사용 가능한 작업 템플릿

Prompt는 이름 그대로 프롬프트이지만, 단순히 사용자가 입력하는 프롬프트와는 조금 다르다. MCP Server에서 제공하는 Prompt는 재사용 가능한 작업 템플릿에 가깝다.

예를 들어 GitHub 관련 MCP Server가 다음과 같은 Prompt를 제공할 수 있다.

review_pull_request

summarize_issue

prepare_release_notes

review_pull_request라는 Prompt가 내부적으로 다음과 같은 템플릿을 가지고 있을 수 있다.

다음 Pull Request를 검토하세요.

1. 버그 가능성
2. 보안 문제
3. 성능 문제
4. 코드 스타일
5. 개선 사항

사용자는 복잡한 프롬프트를 매번 직접 작성할 필요 없이 이미 정의된 작업 템플릿을 사용할 수 있다.

 

따라서 세 가지를 다시 정리하면 다음과 같다.

Resources = 데이터

Tools = 행동

Prompts = 작업 템플릿

 

 

 

실제 MCP Tool 호출

사용자가 AI에게 다음과 같이 요청한다고 해보자.

"서울 날씨 알려줘."

AI 애플리케이션에는 Weather MCP Server가 연결되어 있다고 가정한다.

AI를 사용해 직접 만든 이미지입니다.

 

1. MCP Server가 Tool을 제공한다

Weather MCP Server에는 다음과 같은 Tool이 있다.

get_weather(location)

 

2. Client가 사용할 수 있는 Tool을 확인한다

MCP Client는 Server에 다음과 같은 요청을 보낼 수 있다.

tools/list

Server는 자신이 제공하는 Tool에 대한 정보를 반환한다.

예를 들면:

{
  "name": "get_weather",
  "description": "특정 지역의 현재 날씨를 조회합니다.",
  "inputSchema": {
    "location": "string"
  }
}

 

3. LLM이 필요한 Tool을 판단한다

사용자의 요청은 다음과 같다.

서울 날씨 알려줘.

AI 애플리케이션은 LLM에게 현재 사용할 수 있는 Tool 정보를 함께 제공할 수 있다.

LLM은 요청을 분석하고 다음과 같이 판단한다.

날씨를 조회해야 한다.

사용할 Tool:
get_weather

입력:
location = "Seoul"

 

4. MCP Client가 Tool을 호출한다

Client가 Server에 요청한다.

tools/call

개념적으로는 다음과 같은 데이터가 전달될 수 있다.

{
  "name": "get_weather",
  "arguments": {
    "location": "Seoul"
  }
}

 

5. MCP Server가 실제 API를 호출한다

Server 내부에서는 실제 날씨 API를 사용할 수 있다.

Weather MCP Server
       ↓
Weather API

 

6. 결과가 MCP Client로 돌아온다

예를 들어 다음과 같은 데이터가 반환됐다고 해보자.

{
  "temperature": 28,
  "condition": "cloudy"
}

 

7. LLM이 최종 답변을 만든다

MCP를 통해 전달받은 결과를 바탕으로 LLM이 사용자에게 자연어로 응답한다.

현재 서울은 흐리고 기온은 약 28°C입니다.

 

전체 흐름을 합치면 다음과 같다.

User
 ↓
AI Application
 ↓
LLM
 ↓
필요한 Tool 판단
 ↓
MCP Client
 ↓
MCP Server
 ↓
External API
 ↓
MCP Server
 ↓
MCP Client
 ↓
LLM
 ↓
User

 

MCP가 LLM에게 어떤 Tool을 선택해야 하는지 판단하는 방법까지 정의하는 것은 아니다.

MCP는 Tool을 발견하고 호출하고 결과를 전달하는 인터페이스를 정의한다. 실제로 Tool 정보를 LLM에게 어떻게 전달하고, LLM의 결과를 어떻게 해석할지는 Host의 구현 영역이다.

 

 

MCP와 API 차이점

실제로 많은 MCP Server 내부에서는 기존 API를 사용한다.

API는 일반적으로 특정 서비스가 자신의 기능을 프로그램에서 사용할 수 있도록 제공하는 인터페이스다. 반면 MCP는 AI 애플리케이션이 외부 데이터와 기능을 발견하고 사용하는 방법을 표준화한다.

API	서비스 기능을 프로그램에서 사용할 수 있도록 제공
MCP	AI가 외부 기능과 데이터를 사용하는 방법을 표준화
MCP Server	MCP와 실제 API·DB·파일 등을 연결

따라서 MCP가 기존 API를 없애는 것이 아니다. 오히려 기존 API 위에 MCP Server가 만들어지는 경우가 많다.

 

 

Function Calling과 MCP의 차이점

Function Calling과 MCP도 자주 비교된다. Function Calling은 일반적으로 LLM에게 사용할 수 있는 함수를 알려주는 기능이다.

예를 들어 모델에게:

{
  "name": "get_weather",
  "parameters": {
    "location": "string"
  }
}

같은 정보를 제공한다.

그러면 모델은 사용자의 요청을 보고:

get_weather("Seoul")

를 호출해야 한다고 판단할 수 있다.

그렇다면 MCP와 무슨 차이가 있을까?

Function Calling은 주로 모델이 어떤 함수를 호출할 것인가 라는 문제에 가깝다.

MCP는 조금 더 넓은 문제를 다룬다.

외부 Tool을 어디에서 발견할 것인가? / Tool은 어떤 형태로 정의될 것인가? / Client와 Server는 어떻게 통신할 것인가? / Tool 호출 결과를 어떤 방식으로 주고받을 것인가?

 

실제로는 다음처럼 함께 사용될 수 있다.

User
 ↓
LLM
 ↓
Tool 선택
 ↓
MCP
 ↓
Tool 실행

 

 

MCP 통신 방식

AI를 사용해 직접 만든 이미지입니다.

MCP의 데이터 계층은 JSON-RPC 2.0을 기반으로 한다. 예를 들어 사용할 수 있는 Tool 목록을 가져오는 요청은 개념적으로 다음과 비슷하다.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list"
}

이를 보면 MCP가 특별한 마법 같은 AI 기술이라기보다는 익숙한 Client-Server 통신 기술 위에서 만들어졌다는 것을 알 수 있다.

즉 MCP 역시 결국:

Request
 ↓
Server
 ↓
Response

구조를 가진 프로토콜이다. 다만 AI 애플리케이션에서 외부 Context와 Tool을 사용하기 위한 규칙들이 정의되어 있다는 점이 핵심이다.

 

stdio와 Streamable HTTP

Client와 Server가 실제로 통신하려면 전송 방법이 필요하다. 현재 MCP에서 주로 사용되는 Transport는 다음 두 가지다.

stdio

Streamable HTTP

 

stdio

stdio는 로컬 MCP Server를 실행할 때 많이 사용된다.

AI Application
      │
      │ stdin / stdout
      ▼
Local MCP Server

Host가 MCP Server 프로그램을 직접 실행하고 표준 입력과 표준 출력을 통해 메시지를 주고받는다.

예를 들면:

Cursor
 ↓
node filesystem-server.js

처럼 로컬 프로그램을 실행하고 통신하는 방식이다. 파일 시스템이나 로컬 개발 환경을 다루는 MCP Server에서 특히 자연스럽다.

 

Streamable HTTP

원격 MCP Server를 사용한다면 HTTP 기반으로 통신할 수 있다.

AI Application
      │
      │ HTTP
      ▼
<https://example.com/mcp>

이를 이용하면 서버를 클라우드나 사내 인프라에 배포하고 여러 AI 애플리케이션에서 접근하도록 구성할 수도 있다.

 

 

MCP에서 보안 중요성

MCP를 통해 AI가 외부 시스템을 사용할 수 있다는 것은 굉장히 강력하다. 하지만 강력한 만큼 위험도 커진다.

예를 들어 다음과 같은 Tool이 있다고 해보자.

delete_file

send_email

execute_sql

create_payment

AI가 Tool을 호출한다는 것은 단순히 답변을 생성하는 것을 넘어 실제 시스템의 상태를 변경할 수도 있다는 뜻이다.

예를 들어:

"필요 없는 파일들 정리해줘."

라는 모호한 요청 때문에 AI가 중요한 파일을 삭제한다면 큰 문제가 발생할 수 있다. 또한 외부 MCP Server를 연결하는 순간 새로운 신뢰 경계가 생긴다. 그 서버가 정말 믿을 수 있는지, 어느 데이터까지 접근할 수 있는지, 어떤 Tool을 실행할 수 있는지 확인해야 한다.

따라서 MCP 기반 시스템에서는 특히 다음과 같은 문제를 중요하게 생각해야 한다.

사용자 승인

최소 권한

인증 / 인가

Tool 실행 범위 제한

민감 데이터 보호

외부 MCP Server 신뢰성

특히 데이터를 변경하거나 삭제하는 작업은 가능한 한 사용자 확인 단계를 거치는 구조가 안전하다.

 

---

정리

LLM
= 생각하고 판단한다.

MCP
= 연결 방법을 정의한다.

MCP Server
= 외부 기능과 데이터를 제공한다.

API / DB / File
= 실제 외부 시스템이다.

결국 MCP가 해결하려는 문제는 AI가 외부 세계와 어떻게 연결될 것인가이다.

지금까지는 각 AI 서비스나 Agent가 외부 도구를 연결하는 방법을 각자 만들어왔다면, MCP는 그 연결 부분에 공통 규격을 만들려는 시도라고 볼 수 있다. 그리고 이 점 때문에 MCP는 단순한 Tool Calling 라이브러리라기보다 앞으로 AI Agent와 외부 서비스를 연결하는 중요한 인터페이스 계층으로 볼 필요가 있다.