[MCP] AI와 외부 시스템을 연결하는 표준, MCP(Model Context Protocol)란?

 

AI가 외부 시스템을 사용하려면?

 

일반적인 LLM은 사용자의 입력을 받아 학습된 지식과 전달받은 Context를 바탕으로 응답을 생성한다. 

하지만 실제 AI 애플리케이션에는 응답을 생성하는 것만으로 해결할 수 없는 작업이 많다. 

 

ex)

" GitHub에서 현재 열려 있는 Issue를 찾아줘 "

" 오늘 들어온 주문을 DB에서 조회해줘 "

" 프로젝트 문서를 읽고 내용을 요약해줘 "

" 내 일정을 확인해서 회의 가능한 시간을 찾아줘. "

 

이러한 작업을 수행하려면, AI는 단순히 내용을 생성하는 것을 넘어 실제 데이터가 존재하는 시스템에 접근해야 한다. 

GitHub     → Issue 조회
Database   → 주문 데이터 조회
File       → 문서 읽기
Calendar   → 일정 조회

 

LLM 자체가 이러한 외부 시스템에 자동으로 접근하는 것은 아님. 

따라서 실제 AI 애플리케이션에는 모델과 외부 시스템 사이를 연결하는 기능이 필요. 

 

그런데, 연결해야 하는 시스템이 계속 늘어나고 각 서비스마다 서로 다른 연결 방식을 AI 애플리케이션이 직접 이해하고 구현해야 한다면, 외부 시스템이 늘어날수록 연결 구조도 복잡해짐

=> 문제인 이유

• 어떤 기능을 사용할 수 있는지
• 어떤 형식으로 요청해야 하는지
• 어떤 형식으로 결과를 반환하는지
• 인증과 권한을 어떻게 처리하는지
• 오류가 발생했을 때 어떻게 처리하는지

새로운 외부 시스템을 추가할 때마다 이러한 연결 규칙을 다시 구현해야 하고, 

기존 API가 변경되면 관련된 연결 코드도 함께 수정해야 함. 

=> 필요한 것은 모든 외부 시스템을 동일하게 만드는 것.

 

결국, AI와 여러 외부 시스템을 연결하는 방식을 하나의 공통된 형태로 만들 수 있는가? 

이 문제를 해결하기 위해 등장한 것이 MCP(Model Context Protocol) 

기존

AI Application
 ├─ 시스템 A 전용 연결
 ├─ 시스템 B 전용 연결
 └─ 시스템 C 전용 연결


공통 규칙이 있다면

AI Application
       ↕
   공통 연결 규칙
       ↕
시스템 A / B / C

 

---

 

MCP (Model Context Protocol) 란?

 

AI Application이 외부 데이터 소스와 도구 등에 연결할 수 있도록 표준화된 방식을 제공하는 오픈 프로토콜(공통된 규칙)

※ MCP는 LLM이 외부 시스템에 직접 접근하게 만드는 기술이 아니라, 

AI Application이 MCP Server의 기능을 발견하고 호출할 수 있도록 Client와 Server 사이의 표준화된 연결 방식을 제공하는 것

AI Application
       ↕
      MCP
       ↕
외부 시스템과 연결하는 구현
       ↕
GitHub / Database / File System / ...

 

무엇을 표준화하는가?

AI Application과 MCP Server 사이의 통신 방식

(MCP 범위 : Context 교환을 위한 Protocol )

※ MCP가 표준화하는 대상은 외부 시스템의 내부 구현이 아님.

 

영역	역할
메시지 형식	Client와 Server가 요청과 응답을 어떤 형태로 주고받을지 정의
기능 발견	Server가 어떤 기능을 제공하는지 Client가 확인할 수 있는 방법 정의
기능 사용	제공된 Tool, Resource 등을 조회하거나 사용하는 방법 정의
결과 반환	실행하거나 조회한 결과를 어떤 구조로 반환할지 정의
전송 방식	Client와 Server 사이에서 메시지를 실제로 전달하는 방식 정의

 

AI Agent와의 관계

AI Agent
 ├─ Model
 ├─ Instructions / Context
 ├─ Harness / Runtime
 ├─ Tool 사용
 │     ↓
 │    MCP 사용 가능
 │     ↓
 │   MCP Server
 │
 └─ 실행 Loop

=> AI Agent가 외부 Tool이나 데이터에 접근할 때 사용할 수 있는 연결 방법 중 하나가 MCP 

---

 

MCP의 구조

 

구성	설명
Host	사용자가 실제로 사용하는 AI Application  EX) Claude Code, Claude Desktop
Client	Host 내부에서 특정 MCP Server와 통신하는 구성요소  - 하나의 Client가 하나의 특정 Server와 연결되는 구조
Server	AI Application에서 사용할 수 있는 데이터나 기능을 MCP방식으로 제공하는 프로그램  ex) GitHub MCP Server → GitHub 관련 데이터와 기능 제공

 

 

---

 

MCP Server가 제공하는 Tools · Resources · Prompts

 

 

기능	주된 제어 주체	설명
Tools	model-controlled : 제공된 Tool 중 어떤 Tool이 필요한지 모델이 사용자 요청과 Context를 바탕으로 판단하고 호출할 수 있도록 설계되어 있음.	LLM이 외부 시스템과 상호작용 할 수 있는 실행 가능한 기능 예를들어 다음과 같은 기능을 Tool로 제공할 수 있음 search_issues(), create_issue(), query_database() 구조] Client는 tools/lists로 사용할 수 있는 Tools를 확인하고,  필요한 Tools은 tools/call로 실행 다만, 실제 구현에서는 사용자 확인 UI 등을 통해 Tool 실행을 통제할 수 있으며,  공식 사양에도 보안상 사용자가 Tool 실행을 거부할 수 있는 human-in-the-loop 구조를 권장
Resources	Application	LLM이 작업을 수행할 때 Context로 사용할 수 있는 데이터를 제공 ex) 프로젝트 파일, 문서, Database Schema, Application 설정, 사용자에게 필요한 데이터 각각의 Resource는 URI를 통해 식별됨.  ex)  file:///project/README.md database://schema/orders docs://project/api 구조] Client는 resources/list로 Resource를 확인하고 resources/read로 내용을 가져올 수 있음.
Prompts	User	MCP Server가 제공하는 재사용 가능한 Prompt Template => 구조화된 Message와 Instruction을 제공하는 Template  ex) 코드 관련 MCP Server라면 /code-review, /bug-analysis, /explain-code 와 같은 작업 Template를 제공할 수 있음. 특징] - 단순한 문자열만 있는 것이 아니라, 필요한 인자를 정의할 수도 있음 ex) code-review => 입력 : code, language, review_type  구조] Client는 prompts/list로 사용 가능한 Prompt를 확인하고 prompts/get으로 특정 Prompts와 인자를 가져올 수 있음.

 

 

Q] LLM이 Tool을 선택해서 실행한다면 MCP와 Tool Calling은 같은 개념일까?

A]

 

구분	Tool Calling	MCP
핵심 역할	모델이 필요한 Tool을 선택하고 호출 요청 생성	AI Application과 외부 Tool·데이터 제공자 사이의 연결 방식을 표준화
중심 대상	Model ↔ Tool	MCP Client ↔ MCP Server
하는 일	어떤 Tool을 사용할지 결정하고 인자 생성	Tool을 발견하고 호출하고 결과를 전달하는 공통 규칙 제공
Tool 정의	Application이 모델에 Tool 정보를 제공	MCP Server가 Tool을 노출
외부 시스템 연결	Application이 직접 구현할 수 있음	MCP Server가 외부 시스템과 연결 가능
관계	Tool 사용 메커니즘	Tool을 공급하고 연결하는 Protocol
함께 사용 가능?	가능	가능

Tool Calling은 모델에게 사용할 수 있는 Tool을 알려주고, 모델이 필요하다고 판단하면 Tool 이름과 필요한 인자를 포함한 호출 요청을 생성하는 방식

 

MCP는 어떤 Tool을 선택할지 판단하는 기술이 아니라, MCP Server가 제공하는 Tool을 Client가 발견하고 실행할 수 있도록 Client-Server 사이의 규칙을 정의 

=> AI Application이 여러 MCP Server에서 Tool을 가져와 하나의 Tool Registry로 구성하고, 

LLM이 이 Tool들을 사용할 수 있음.

 

MCP를 사용하면 Tool이 반드시 Application 내부에 직접 구현되어 있을 필요가 없다. 

=> MCP Server가 Tool을 제공할 수 있음. 

MCP에서는 Client가 tools/list로 Server의 Tool을 발견할 수 있고, Tool은 이름과 입력 Schema 등의 Metadata를 포함해 제공 됨.

---

 

동작

 

 

구분	설명
1. 사용할 수 있는 기능을 확인	MCP Server가 어떤 기능을 제공하는지 알아야 함.  - tools/list를 통해 사용할 수 있는 Tool을 조회할 수 있음 - server/discover를 통해 Server가 지원하는 Protocol Version과 Capability를 미리 확인 가능  ex) GitHub MCP Server 가 다음과 같은 기능을 제공한다고 가정 GitHub MCP Server ├─ search_issues ├─ get_issue └─ create_issue => MCP Client에서는 Sever가 제공하는 Tool 목록을 확인할 수 있음. .
2. LLM이 필요한 Tool을 선택	어떤 Tool을 사용할지 판단하는 것은 MCP 자체가 아님,  MCP는 Server가 Tool을 노출하고 Client가 이를 발견 · 호출 할 수 있는 규칙을 제공.
3. MCP Client가 Server에 Tool 실행 요청	MCP에서는 Tool 실행에 tools/call을 사용함.  Client-Server 사이의 요청·응답은 JSON-RPC 기반으로 정의되어 있음.  중요한 점은, Client는 API를 어떻게 호출해야 하는지 알 필요가 없다.  Client가 알아야 하는 것은 MCP Server가 제공하는 Tool과 그 호출 방법
4. MCP Server가 실제 작업 수행
5. 실행 결과 반환	MCP는 Client와 Server사이에 요청과 응답을 주고받는 기본 Message  Pattern을 정의
6. LLM이 최종 응답 생성

 

 

---

 

MCP는 어떻게 통신할까?

 

 

구분	역할	주로 사용하는 상황
JSON-RPC	MCP 요청·응답 등의 메시지 형식 => MCP 메세지를 JSON-RPC로 인코딩하며 UTF-8로 전달하도록 정의함. 구성] - method : 어떤 MCP 기능을 요청하는가 - params : 요청에 필요한 값 - id : 요청과 응답을 연결하기 위한 식별자  ex) {   "jsonrpc": "2.0",   "id": 1,   "method": "tools/call",    "params": {     "name": "get_weather",     "arguments": {       "location": "Seoul"     }   } }	모든 MCP 통신
stdio	Client와 Server가 표준 입력(stdin)과 표준 출력(stdout)을 이용해 통신하는 방식 Client가 MCP Server를 subprocess로 실행하고,  Server는 stdin으로 JSON-RPC 메세제를 읽고 stdout으로 결과를 반환하도록 정의	로컬 MCP Server
Streamable HTTP	HTTP를 통해 메시지 전달 MCP Server가 다른 서버나 Cloud환경에 있다면 stdio처럼 로컬 subprocess로 실행할 수 없음.  => 이때 사용할 수 있는 표준 Transport가 Streamable HTTP	원격 MCP Server