MCP(Model Context Protocol)를 처음 보면 "Tool Calling이랑 뭐가 다른가?"라는 질문이 먼저 나온다.

개발 관점에서는 이렇게 나누면 이해하기 쉽다.

  • Tool Calling: 모델이 어떤 도구를 호출할지 결정하는 메커니즘
  • MCP: AI application과 외부 시스템 사이의 도구, 리소스, 프롬프트를 표준 인터페이스로 노출하는 프로토콜
  • LangGraph: MCP tool 호출을 포함한 실행 workflow를 그래프 형태로 설계하는 도구

MCP는 특정 모델이나 특정 앱 전용 플러그인이라기보다, AI 애플리케이션이 외부 시스템과 통신하는 방법을 표준화하려는 시도에 가깝다. 공식 문서 기준으로 2026-06-10 확인 시점의 current protocol version은 2025-11-25다.

1. MCP가 해결하려는 문제

LLM 애플리케이션을 만들다 보면 곧바로 이런 요구가 나온다.

실험 결과 JSON을 읽어서 요약하고 Notion에 저장해줘.
사내 DB에서 고객 주문 이력을 조회해서 답변해줘.
PDF를 읽고 핵심 내용을 Slack으로 보내줘.

문장 생성만 보면 LLM이 할 수 있다. 하지만 파일 읽기, DB 조회, Notion 저장, Slack 발송은 외부 시스템 실행이다.

이때 매번 애플리케이션마다 다음 코드를 새로 작성하면 구조가 금방 지저분해진다.

  • 파일 시스템 접근 코드
  • API 인증 코드
  • tool schema 정의
  • tool discovery 로직
  • 실행 결과 변환
  • 권한과 로그 처리

MCP는 이 부분을 Host - Client - Server 구조로 나눈다.

2. MCP의 세 참여자

공식 아키텍처에서 핵심 참여자는 세 가지다.

구성 요소역할
MCP Host사용자가 상호작용하는 AI 애플리케이션. 예: IDE, 데스크톱 AI 앱, 업무용 챗봇
MCP ClientHost가 특정 MCP Server와 통신하기 위해 생성하는 연결 컴포넌트
MCP Servertools, 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를 설명한다.

3. Server가 제공하는 세 가지 primitive

처음에는 tools만 기억해도 되지만, MCP Server는 세 가지 큰 기능을 제공할 수 있다.

Primitive설명예시
Tools모델이 호출할 수 있는 실행 함수PDF 읽기, DB 조회, Notion 페이지 생성
Resources애플리케이션이 컨텍스트로 읽을 수 있는 데이터파일 내용, DB schema, API 응답
Prompts재사용 가능한 작업 템플릿회의록 요약, 보고서 초안, 여행 계획

실무에서 가장 먼저 체감되는 것은 Tools다. 사용자의 자연어 요청을 보고 모델이 필요한 tool을 선택하고, Host가 그 호출을 MCP Client를 통해 Server로 보낸다.

4. fastmcp로 보는 MCP 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에 전달한다.

5. Host/Client 쪽 흐름

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가 담당한다.

6. MCP와 RAG의 차이

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이 두 결과를 바탕으로 답변

7. MCP와 LangGraph를 같이 볼 때

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이 항상 성공하지 않는다.

  • Vector DB 검색 결과가 비어 있음
  • 외부 API가 timeout 발생
  • 사용자의 질문이 모호함
  • 권한이 없어 실행 실패
  • 재시도하다가 무한 루프 위험 발생

따라서 실무에서는 MCP Tool을 붙인 뒤 다음 질문을 해야 한다.

  1. 이 tool은 읽기 전용인가, 쓰기 가능한가
  2. 실패 시 재시도할 것인가, 중단할 것인가
  3. 사용자의 승인이 필요한 작업인가
  4. tool 실행 로그가 남는가
  5. workflow가 무한 루프에 빠지지 않는가

MCP만 붙인다고 Agent 설계가 끝나는 것은 아니다. MCP는 연결 표준이고, workflow 설계는 별도의 문제다.

8. 실무 체크리스트

처음 MCP를 도입한다면 다음 순서를 권장한다.

  1. 읽기 전용 tool부터 만든다.
  2. tool description과 input schema를 명확히 쓴다.
  3. 접근 가능한 파일, 페이지, DB 범위를 최소화한다.
  4. 쓰기 작업은 사용자 승인 단계를 둔다.
  5. tool call 로그와 실패 로그를 남긴다.
  6. API key와 token은 환경변수나 안전한 secret manager로 관리한다.
  7. RAG, LangGraph, MCP의 책임을 섞지 않는다.

교육생 프로젝트를 리뷰하다 보면 처음부터 "AI가 모든 시스템을 자동으로 업데이트"하게 만들고 싶어 하는 경우가 있다. 하지만 실무에서는 반대로 시작하는 편이 좋다.

먼저 읽기, 요약, 초안 생성부터 시작한다.

그 다음 승인된 쓰기 작업을 붙인다.

마지막으로 workflow와 운영 로그를 설계한다.

정리

MCP는 AI가 외부 시스템과 연결되는 표준 프로토콜이다.

개발자가 처음 이해해야 할 핵심은 다음이다.

  • Host는 사용자 경험과 전체 orchestration을 담당한다.
  • Client는 특정 MCP Server와의 연결을 담당한다.
  • Server는 tools, resources, prompts를 제공한다.
  • Tool Calling은 모델의 호출 판단이고, MCP는 그 도구를 표준 방식으로 연결하는 구조다.
  • RAG는 근거 검색 패턴이고, MCP는 외부 capability 연결 프로토콜이다.
  • LangGraph는 MCP tool 호출을 포함한 workflow를 설계하는 데 유용하다.

MCP를 배우는 목표는 "새로운 라이브러리 하나 더 쓰기"가 아니다.

LLM이 판단할 일, 서버가 실행할 일, 사람이 승인할 일을 분리해서 안정적인 AI 업무 자동화를 설계하는 것이다.

참고 자료

profile
생성형 AI, RAG, AI Agent를 가르치는 강사 김민수입니다. 교육 현장과 실무에서 얻은 경험을 기록합니다. 강의 및 교육 문의는 rlaalstn1504@naver.com으로 연락 부탁드립니다.

0개의 댓글