* 이 게시물은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
(MCP 시리즈 ①) 개념
LLM에 외부 도구를 붙여본 사람은 다 안다. 슬랙 붙일 때 다르고, 노션 붙일 때 다르고, 사내 API 붙일 때 또 다르다. 도구마다 연동 코드를 새로 짜다 보면 이게 맞나 싶어진다. MCP(Model Context Protocol)는 바로 그 지점을 겨냥한다. 모델과 도구를 잇는 방식을 하나의 규격으로 통일해 버린 거다.
비유하자면 USB-C다. 예전엔 기기마다 충전 단자가 제각각이라 어댑터를 잔뜩 들고 다녔다. USB-C가 표준이 되고 나선 케이블 하나로 다 된다. MCP도 똑같다. 한 번 MCP 방식으로 도구를 만들어 두면, Claude Desktop이든 Claude Code든 Cursor든 그 도구를 그대로 꽂아 쓸 수 있다. Anthropic이 2024년 말에 공개했고, 2025년 말에는 리눅스 재단 산하 Agentic AI Foundation에 기증돼 AWS·구글·마이크로소프트·OpenAI 등이 함께 참여하는 열린 표준이 됐다(관리는 기존 메인테이너가 그대로 이어간다).
구조는 단순하다. 서버가 도구와 데이터를 내놓고, 클라이언트(Claude 같은 앱)가 거기에 연결한다. 서버가 내놓는 건 크게 셋이다.
- 도구(Tools) — 모델이 호출하는 함수. “날씨 조회”, “주문 검색” 같은 것.
- 리소스(Resources) — 모델이 읽어가는 데이터. 파일, 문서, DB 레코드.
- 프롬프트(Prompts) — 재사용할 지시 템플릿.
코드로 보면 이 셋은 이렇게 데코레이터 하나씩으로 나뉜다.
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("demo")
@mcp.tool() # 도구: 모델이 호출하는 함수
def add(a: int, b: int) -> int:
"""두 수를 더한다."""
return a + b
@mcp.resource("docs://policy") # 리소스: 모델이 읽어가는 데이터
def policy() -> str:
return open("policy.md").read()
@mcp.prompt() # 프롬프트: 재사용 지시 템플릿
def review(code: str) -> str:
return f"다음 코드를 리뷰해줘:\n{code}"
연결 방식은 두 가지다. 내 컴퓨터 안에서 도는 로컬 서버는 표준입출력(stdio)으로 붙고, 원격 서버는 HTTP로 붙는다. 로컬 도구를 만들 땐 stdio가 제일 간단해서, 다음 편에서도 그걸로 시작할 거다. 그리고 하나의 클라이언트에 슬랙 서버·노션 서버·사내 서버를 동시에 여러 개 꽂을 수 있다 — 도구 묶음을 서버 단위로 나눠 조립하는 게 MCP식 설계다.
연결이 성립하는 순간 — initialize 핸드셰이크
‘클라이언트가 서버에 연결한다’의 실체도 한 단계 들여다보자. 연결 직후 양쪽은 initialize로 자기가 할 수 있는 것(capabilities)을 교환한다. 이 악수가 끝나야 도구 목록 조회(tools/list)와 호출(tools/call)이 오간다.
→ 클라이언트: {"method":"initialize","params":{
"protocolVersion":"2025-06-18",
"capabilities":{}, "clientInfo":{"name":"claude-desktop"}}}
← 서버: {"result":{"capabilities":{"tools":{}}, ← "나는 도구를 제공한다"
"serverInfo":{"name":"weather"}}}
→ 클라이언트: {"method":"tools/list"} ← 이제부터 본편
버전과 capabilities를 먼저 맞추기 때문에, 서버가 리소스를 지원하지 않으면 클라이언트는 아예 묻지 않는다. “규격으로 통일했다”는 말은 이렇게 연결 절차까지 표준이라는 뜻이다.
function calling과 뭐가 다른가
가장 흔한 질문이다. function calling은 ‘모델이 함수를 부를 수 있다’는 모델 API의 기능이고, MCP는 ‘그 도구를 어떻게 서버로 노출하고 클라이언트와 잇느냐’의 표준 프로토콜이다. 층이 다르다. MCP 서버 내부는 결국 function calling으로 도구를 실행하지만, MCP는 그걸 재사용·공유 가능한 규격으로 감싼다. 그래서 한 번 만들면 여러 클라이언트가 쓴다.
언제 쓰고 언제 안 쓰나
도구가 하나뿐이고 한 앱 안에서만 쓴다면 굳이 MCP가 아니어도 된다 — 그냥 function calling으로 충분하다. MCP가 빛나는 건 여러 도구를 여러 곳(여러 클라이언트·팀)에서 재사용할 때다. ‘표준의 이득’은 규모가 생길 때 나온다. 이 시리즈는 그 규모를 전제로 서버 만들기(2편)·연결(3편)·보안(5편)을 차례로 다룬다.
왜 지금 뜨냐면, 에이전트가 유행하면서 “도구를 어떻게 연결하냐”가 병목이 됐기 때문이다. 표준이 생기니 한 번 만든 서버를 여러 곳에서 재사용하게 됐고, 남이 만든 MCP 서버를 그냥 가져다 쓰는 생태계도 커지고 있다. 다음 편에선 진짜로 30줄짜리 서버를 하나 만들어 본다.
자주 묻는 질문 (FAQ)
MCP는 함수 호출(function calling)과 뭐가 다른가요?
함수 호출이 모델과 앱 사이의 개별 약속이라면, MCP는 그 도구·데이터 연결을 표준 프로토콜로 만든 것입니다. 한 번 만든 MCP 서버를 여러 클라이언트가 재사용할 수 있습니다.
MCP를 꼭 써야 하나요?
도구가 한둘이면 직접 연동이 더 간단합니다. 여러 도구를 여러 앱에서 재사용하거나 생태계 호환이 필요할 때 MCP의 이점이 커집니다.

답글 남기기