MCP(Model Context Protocol)를 처음 보면 "Tool Calling이랑 뭐가 다른가?"라는 질문이 먼저 나온다.
개발 관점에서는 이렇게 나누면 이해하기 쉽다.
MCP는 특정 모델이나 특정 앱 전용 플러그인이라기보다, AI 애플리케이션이 외부 시스템과 통신하는 방법을 표준화하려는 시도에 가깝다. 공식 문서 기준으로 2026-06-10 확인 시점의 current protocol version은 2025-11-25다.
LLM 애플리케이션을 만들다 보면 곧바로 이런 요구가 나온다.
실험 결과 JSON을 읽어서 요약하고 Notion에 저장해줘.
사내 DB에서 고객 주문 이력을 조회해서 답변해줘.
PDF를 읽고 핵심 내용을 Slack으로 보내줘.
문장 생성만 보면 LLM이 할 수 있다. 하지만 파일 읽기, DB 조회, Notion 저장, Slack 발송은 외부 시스템 실행이다.
이때 매번 애플리케이션마다 다음 코드를 새로 작성하면 구조가 금방 지저분해진다.
MCP는 이 부분을 Host - Client - Server 구조로 나눈다.

공식 아키텍처에서 핵심 참여자는 세 가지다.
| 구성 요소 | 역할 |
|---|---|
| MCP Host | 사용자가 상호작용하는 AI 애플리케이션. 예: IDE, 데스크톱 AI 앱, 업무용 챗봇 |
| MCP Client | Host가 특정 MCP Server와 통신하기 위해 생성하는 연결 컴포넌트 |
| MCP Server | tools, resources, prompts 같은 capability를 제공하는 프로그램 |
중요한 점은 보통 Host가 여러 MCP Server에 붙을 때, 각 Server마다 Client 연결을 가진다는 점이다.
User
-> MCP Host
-> MCP Client A -> Filesystem MCP Server
-> MCP Client B -> Notion MCP Server
-> MCP Client C -> Database MCP Server
MCP Server는 로컬 프로세스로 실행될 수도 있고, 원격 서버로 운영될 수도 있다. 공식 문서에서는 로컬 프로세스 간 통신에 stdio transport, 원격 통신에 Streamable HTTP transport를 설명한다.
처음에는 tools만 기억해도 되지만, MCP Server는 세 가지 큰 기능을 제공할 수 있다.
| Primitive | 설명 | 예시 |
|---|---|---|
| Tools | 모델이 호출할 수 있는 실행 함수 | PDF 읽기, DB 조회, Notion 페이지 생성 |
| Resources | 애플리케이션이 컨텍스트로 읽을 수 있는 데이터 | 파일 내용, DB schema, API 응답 |
| Prompts | 재사용 가능한 작업 템플릿 | 회의록 요약, 보고서 초안, 여행 계획 |
실무에서 가장 먼저 체감되는 것은 Tools다. 사용자의 자연어 요청을 보고 모델이 필요한 tool을 선택하고, Host가 그 호출을 MCP Client를 통해 Server로 보낸다.
langchain-web-chatbot-edu-2026/MCP기초.ipynb에서는 fastmcp를 사용해 MCP Server를 단순하게 구현한다. 아래 코드는 게시용으로 단순화한 예시다.
from fastmcp import FastMCP
from pypdf import PdfReader
mcp = FastMCP("DocumentAutomationServer")
@mcp.tool()
def read_pdf_file(file_path: str) -> str:
"""PDF 파일을 읽어 텍스트를 반환한다."""
reader = PdfReader(file_path)
pages: list[str] = []
for page in reader.pages:
text = page.extract_text() or ""
pages.append(text)
return "\n".join(pages)
@mcp.tool()
def save_summary(title: str, summary: str) -> str:
"""요약 결과를 외부 시스템에 저장한다. 실제 구현에서는 Notion, DB, Slack 등으로 교체한다."""
return f"saved: {title}\n{summary[:200]}"
if __name__ == "__main__":
mcp.run()
이 코드에서 중요한 부분은 @mcp.tool()이다.
일반 Python 함수가 MCP Tool로 노출된다. Server는 tool 이름, 설명, 입력 스키마를 제공하고, Client는 이를 discovery한 뒤 Host에 전달한다.
Host는 사용자와 대화하고, MCP Client는 Server와 통신한다. 교안에서는 stdio_client, ClientSession, load_mcp_tools를 사용해 MCP Server의 tool을 불러오는 흐름을 다룬다.
import asyncio
from mcp import ClientSession
from mcp.client.stdio import StdioServerParameters, stdio_client
from langchain_mcp_adapters.tools import load_mcp_tools
async def load_tools_from_server():
params = StdioServerParameters(
command="python",
args=["mcp_server.py"],
)
async with stdio_client(params) as (read, write):
async with ClientSession(read, write) as session:
await session.initialize()
tools = await load_mcp_tools(session)
return tools
tools = asyncio.run(load_tools_from_server())
실제 Agent 구성에서는 이 tools를 LLM에 바인딩하거나 Agent 생성 함수에 전달한다.
핵심 실행 흐름은 다음과 같다.
1. Host가 MCP Server와 연결한다.
2. Client가 tools/list로 사용 가능한 도구를 확인한다.
3. 모델이 사용자 요청을 보고 tool call을 결정한다.
4. Host가 tool call을 MCP Client로 라우팅한다.
5. Server가 tools/call을 실행한다.
6. 실행 결과가 다시 LLM 컨텍스트로 들어간다.
7. LLM이 최종 응답을 생성한다.
즉, 모델이 파일 시스템이나 Notion을 직접 조작하는 것이 아니다. 모델은 "어떤 tool이 필요하다"고 판단하고, 실제 실행은 MCP Server가 담당한다.
RAG와 MCP를 같은 층에서 비교하면 헷갈린다.
RAG는 주로 답변 근거를 제공하기 위한 패턴이다.
Question -> Retrieve documents -> Generate answer with context
MCP는 외부 시스템의 capability를 AI 애플리케이션에 제공하는 프로토콜이다.
AI application -> MCP Client -> MCP Server -> Tool/Resource/Prompt
예를 들어 사내문서 챗봇이라면 RAG는 문서 검색과 답변 근거에 관여한다. MCP는 그 챗봇이 파일 시스템, Notion, DB, Slack, 사내 API와 연결되는 인터페이스를 제공할 수 있다.
둘은 대체 관계가 아니라 결합될 수 있다.
질문
-> RAG로 사내문서 검색
-> MCP Tool로 최신 업무 시스템 조회
-> LLM이 두 결과를 바탕으로 답변
MCP는 "도구를 어떻게 노출하고 호출할 것인가"에 가깝다.
LangGraph는 "그 도구 호출을 어떤 workflow 안에서 실행할 것인가"에 가깝다.

예를 들어 part3_nlp/3-7.Langgraph와MCP.ipynb에서는 Routing, Retry, Fallback 구조를 다룬다.(https://github.com/rlaalstn1504/part3_nlp/blob/main/3-7.Langraph%EC%99%80MCP.ipynb)
실제 업무 자동화에서는 tool call이 항상 성공하지 않는다.
따라서 실무에서는 MCP Tool을 붙인 뒤 다음 질문을 해야 한다.
MCP만 붙인다고 Agent 설계가 끝나는 것은 아니다. MCP는 연결 표준이고, workflow 설계는 별도의 문제다.
처음 MCP를 도입한다면 다음 순서를 권장한다.
교육생 프로젝트를 리뷰하다 보면 처음부터 "AI가 모든 시스템을 자동으로 업데이트"하게 만들고 싶어 하는 경우가 있다. 하지만 실무에서는 반대로 시작하는 편이 좋다.
먼저 읽기, 요약, 초안 생성부터 시작한다.
그 다음 승인된 쓰기 작업을 붙인다.
마지막으로 workflow와 운영 로그를 설계한다.
MCP는 AI가 외부 시스템과 연결되는 표준 프로토콜이다.
개발자가 처음 이해해야 할 핵심은 다음이다.
MCP를 배우는 목표는 "새로운 라이브러리 하나 더 쓰기"가 아니다.
LLM이 판단할 일, 서버가 실행할 일, 사람이 승인할 일을 분리해서 안정적인 AI 업무 자동화를 설계하는 것이다.