1. MCP 의 등장 배경
LLM의 특성과 구조적 한계
MCP를 이해하기 위해서는 먼저 LLM(Large Language Model)의 특성과 한계에 대해 이해할 필요가 있다.
LLM은 대규모 텍스트 데이터를 사전에 학습해, 주어진 맥락이나 질문에 대해 다음에 올 토큰(token=단어와 비슷)을 확룰적으로 예측하고 생성하는 모델이다. 이를 통해 자연스러운 문장 생성, 요약, 질의응답은 가능하지만, 구조적 특성으로 인한 명확한 한계도 있다.
(1) 최신 정보 및 미지의 지식에 대한 한계
- LLM은 학습된 시점까지의 정적인 데이터를 기반으로 동작한다.
- 따라서 학습하지 않은 데이터, 학습 시점 이후의 사건이나 실시간 데이터는 알 수 없다.
- 이로 인해 사실처럼 그럴듯하게 잘못된 답변을 생성하는 “할루시네이션(hallucination)” 문제가 발생할 수 있다.
(2) 실제 행동, 처리 불가
- LLM은 단순히 텍스트를 생성하는 모델이며, 스스로 외부 시스템을 호출하거나 데이터를 변경할 수 없다.
- 즉, 파일의 저장, 데이터베이스 조회와 수정, API 호출과 같은 실제 동작은 할 수 없는 것이다.
- 하지만 요즘 AI 챗봇 서비스를 보면 LLM이 검색, 문서 생성, 데이터 분석 등을 수행하는 것처럼 보이는데, 이는 LLM 외부에 실행을 담당하는 별도의 컴포넌트가 존재하기 때문이다.
LLM의 한계를 극복하기 위한 접근
(1) 정보 보강 : RAG
RAG(Retrieval-Augmented Generation; 검색 증강 생성)는 주어진 맥락이나 사용자의 질의에 대해 외부의 관련 정보를 검색(Retrieve)하고, 검색된 결과를 맥락정보(Context)로 활용하여 LLM 모델이 답변을 생성하는 방식이다.
RAG를 활용하면 사용자가 지정한 신뢰성 있는 출처의 데이터나 최신 데이터 소스를 기반으로 정보를 검색한 뒤 답변을 생성할 수 있다. 이를 통해 학습하지 않은 정보에 대해 추측으로 답변하는 할루시네이션을 완화시킬 수 있다.
(2) 행동 확장 : 에이전트와 툴
LLM이 직접 어떤 작업을 처리할 수 없다는 한계를 극복하기 위해 LLM은 판단과 계획을 담당하고, 실제 처리는 외부 컴포넌트가 수행하는 구조가 도입되었다.
이때 API 호출, 데이터 조회, 파일 생성 등의 외부 시스템과 상호작용하여 실제 작업을 수행하는 주체를 에이전트(agent) 또는 툴(tool) 이라고 부른다.
RAG 구조 또한 신뢰성 있고 최신의 정보를 “검색”하는 역할이고, LLM이 직접 수행하지 못하는 작업을 대신 처리한다는 점에서 에이전트나 툴의 한 형태로 볼 수 있다.
MCP의 등장
LLM의 한계를 극복하기 위해 LLM을 외부 데이터나 시스템, 툴에 연결하는 사례가 많아지게 되었다. 하지만 이때 문제가 생기게 되는데, 매번 인터페이스를 구현하는 작업이 반복되고, 통신 방식도 통일되지 않음에 따라 개발비용이 늘어나고, 확장성이 저해되는 등의 문제가 발생하였다.
이에 LLM과 외부 시스템 간의 상호작용을 표준화할 필요성이 대두되었고, 이러한 배경에서 등장한 것이 바로 MCP(Model Context Protocol)다.
MCP는 공식적으로 “AI 애플리케이션을 외부의 시스템과 연결하는 오픈소스 표준”이라고 정의된다. (pen-source standard for connecting AI applications to external systems.)
즉, MCP는 LLM이 외부 데이터와 툴을 일관된 방식으로 이해하고, 예측 가능한 형태로 상호작용할 수 있도록 하는 연결 계층의 표준 프로토콜이다.
2. MCP 의 정의와 개념
공식 정의
MCP(Model Context Protocol)는 공식적으로 다음과 같이 정의된다.
“AI 애플리케이션을 외부의 시스템과 연결하는 오픈소스 표준”
(pen-source standard for connecting AI applications to external systems.)
이름으로 이해하는 MCP
Model
- “고립된 두뇌”
- MCP에서의 Model은 ChatGPT, Claude와 같은 대형 언어 모델(LLM) 을 의미한다.
- 모델은 스스로 외부 세계에 접근하지 못하는 논리적 판단 주체이며, MCP를 통해 전달된 정보를 바탕으로 추론과 결정을 수행한다.
Context
- “모델 외부의 정보”
- 모델이 올바른 판단을 내리기 위해 필요한 모델 외부의 모든 정보를 의미한다.
- Context는 다음을 포함한다 : 데이터(Resource), 실행 가능한 기능(Tool), 모델에게 제공되는 시스템/프롬프트 정보
Protocol
- “연결을 위한 표준 규격”
- Protocol은 Model과 Context를 연결하기 위한 표준화된 통신 규칙이다.
- JSON-RPC라는 메시지 형식을 따르며, 데이터 전송 방식(transport)은 상황에 따라 여러 방식을 지원한다.
MCP를 통해 할 수 있는 일
- AI application(ChatGPT, Claude등)이 데이터소스와 연결될 수 있다.(로컬파일, 데이터베이스 등)
- AI application이 외부 툴(검색엔진, 계산기 등)과 연결될 수 있다.
- AI application이 외부 워크플로와 연결될 수 있다. (데이터 소스 및 도구와 결합되어 특정 비즈니스 목표를 달성하게 만드는 ‘구조화된 명령 체계’)
MCP 의 아키텍처 구성 요소
MCP는 클라이언트-서버 구조를 따른다. MCP 구조는 Host, Client, Server 세 가지 구성 요소로 이루어져 있다.
| 구성 요소 | 설명 |
|---|---|
| MCP Host | - 실제 사용자가 상호작용하는 AI 애플리케이션 - 하나 이상의 MCP 클라이언트를 관리한다. - Client를 통해 Server로부터 받은 Context를 추론에 활용한다. - Curosr, VSCode 등 IDE, Claude Code Desktop, Gemini CLI 등이 Host가 될 수 있다. |
| MCP Client | - Host를 대신해 MCP Server와 통신하는 중간 계층 - Server와 연결을 유지하고, Context를 가져와 Host에 전달한다. |
| MCP Server | - MCP Client에 Context를 제공하는 프로그램 - 데이터(Resource)나 실행 가능한 Tool 을 노출(expose)한다. |
하나의 AI 애플리케이션(MCP Host)은 연결될 MCP Server 마다 하나의 MCP Client를 생성하며, 생성된 각 MCP Client는 특정 MCP Server와 1대1의 전용 연결을 유지한다.
식당 비유로 이해하는 MCP의 구조
- MCP Host : 손님이 앉는 식당 테이블. 손님이 상호작용하는 공간으로, 메뉴를 보고 웨이터에게 주문하고, 음식을 받는다.
- MCP Client : 주문을 받고 음식을 전달하는 웨이터. 손님에게 주문을 받아 주방에 전달하고, 주방에서 나온 음식을 전달한다.
- MCP Server : 요리를 만드는 주방(셰프). 주문을 받아 실제 요리를 만들고, 이를 제공하는 역할을 한다.
손님은 주방에 직접 가지 않으며, 웨이터를 통해 표준화된 방식으로 주문과 응답이 오간다.
MCP 의 통신 방식
- MCP는 JSON-RPC 메시지 형식을 따른다.
- 데이터 전송 방식(transport)은 환경에 따라 유연하게 선택할 수 있다.
Stdio (Standard Input/Output)
동일한 머신에서 실행 중인 프로세스 간 통신을 위해 표준 입력(stdin)과 표준 출력(stdout)을 사용한다. 네트워크를 거치지 않기 때문에 오버헤드가 거의 없고 설정이 단순하다. 별도의 포트 개방이나 인증 설정이 필요 없다.
로컬 환경에서 가장 흔한 방식이다. IDE나 애플리케이션이 MCP 서버를 자식 프로세스로 실행하는 구조에서 사용된다. (예: IDE ↔ 로컬 MCP Server)
Streamable HTTP Transport
HTTP POST를 통해 요청을 전달하고, 서버는 Server-Sent Events(SSE)를 통해 응답을 스트리밍할 수 있다. 표준 HTTP 인증 방식(API Key, Bearer Token, OAuth 등)을 지원하며 HTTPS 기반 보안 통신이 가능하다.
네트워크를 통한 원격 통신에 사용된다. 클라우드 기반 MCP 서버, SaaS 도구, 기업 내부 API 서버와의 연결에 적합하다.
사용자 정의 Transport
MCP는 확장성을 고려해 설계되었으며, 필요 시 개발자가 직접 새로운 운송 수단을 구현할 수 있다. (예: Unix Domain Socket, Shared Memory, 고성능 전용 프로토콜 등)
특수한 성능·보안 요구가 있는 환경에서 사용 가능하다. 다만 생태계 호환성을 위해 대부분의 MCP 서버는 Stdio 또는 HTTP 기반 방식을 채택한다.
Reference
What is the Model Context Protocol (MCP)? - Model Context Protocol
Architecture overview - Model Context Protocol
Comments