CH10-MCP는 '또 다른 API'가 아니다 — 표준 프로토콜로 모든 LLM에 외부 시스템을 연결하는 법

AGENTIC AI DESIGN PATTERNS · 10

AI 세계의 USB Type-C — Model Context Protocol(MCP) 완벽 정리

LLM과 외부 시스템을 잇는 표준 프로토콜: 3대 구성요소(Tools·Resources·Prompts), JSON-RPC 흐름, STDIO·HTTP 통신, FastMCP 서버 2종 + Google ADK 클라이언트, OAuth 2.1 보안과 엔터프라이즈 적용까지

🟢 입문~중급 ⏱️ 약 18분 🔧 Python · FastMCP · Google ADK 🏢 엔터프라이즈

TL;DR — 메모리·학습으로 똑똑해진 에이전트도 결국 외부 시스템(CRM·캘린더·DB)과 연결돼야 일을 합니다. 기존엔 LLM마다·서비스마다 연동 코드를 새로 짰지만(N×M), MCP는 그 연결을 표준화한 개방형 프로토콜 — AI 세계의 USB Type-C입니다. 한 번 만든 MCP Server를 모든 LLM이 재사용하죠. LLM ↔ MCP Client ↔ MCP Server ↔ 외부 구성요소는 Tools·Resources·Prompts 3종, 통신은 STDIO(로컬)·HTTP+SSE(원격), 구현은 FastMCP 서버 2종 + Google ADK 클라이언트로 보여줍니다.

목 차

1. 왜 MCP인가 2. 개념과 오해 3. 3대 구성요소 4. 아키텍처·동작 흐름 5. 구현① FastMCP 서버 6. 구현② ADK 클라이언트 7. 구현③ HTTP 서버 8. MCP vs Function Calling 9. 통신 방식(Transport) 10. 엔터프라이즈 11. 보안 12. 베스트 프랙티스

1. 왜 MCP인가 — 배우는 AI에서 연결되는 AI로

지난 편까지 에이전트는 기억하고 배우는 단계에 이르렀습니다. 하지만 혼자만의 지식으로는 한계가 분명합니다. "김철수 고객 정보 알려줘", "내일 회의 자료 정리해줘" 같은 요청을 처리하려면 결국 외부 시스템(CRM·캘린더·DB·이메일)과 연결돼야 합니다. 문제는 그 연결 방식이 제각각이었다는 점입니다.

기존에는 LLM 제공사(OpenAI·Google·Anthropic)마다 Tool/Function Calling 규격이 달랐고, 서비스를 붙일 때마다 새 통합 코드를 짜야 했습니다. LLM M개 × 서비스 N개 = M×N개의 통합 코드를 떠안는 셈이죠. MCP는 이 조합 폭발을 M+N으로 줄입니다. 비유하자면 예전엔 기기마다 라이트닝·마이크로USB·USB-A가 따로였지만, 지금은 USB Type-C 하나로 통하는 것과 같습니다.

🔌 MCP 없는 세상 — 매번 새 통합

❌ LLM마다 다른 규격 — Function Calling 방식 제각각

❌ M×N 통합 지옥 — LLM×서비스 조합마다 코드

❌ 강한 커플링 — 새 LLM 추가 시 전부 재작성

❌ 수동 등록 — 도구 자동 발견 불가

🔋 MCP 있는 세상 — 한 번 작성, 어디서든

✅ 단일 표준 — JSON-RPC 2.0 기반 프로토콜

✅ M+N으로 축소 — MCP Server 한 번 작성 후 재사용

✅ LLM 독립 — 느슨한 결합, 새 모델도 그대로 연결

✅ 자동 발견 — 도구 Discovery 내장

그림 1. MCP는 LLM×서비스의 M×N 통합을 M+N 표준 연결로 바꾼다.

그래서 2025년 기업들이 MCP에 주목합니다. 2025년 3월 Anthropic이 MCP를 Linux Foundation에 기부해 중립적 거버넌스를 확보했고, OpenAI·Google·Microsoft가 지원을 선언했으며, SDK는 월 9,700만+ 다운로드를 돌파했습니다. 에이전트 시대의 "표준 통신 규격"이 자리를 잡은 것입니다.

2. 개념과 오해 — MCP는 또 다른 API가 아니다

정의부터 못 박습니다. Model Context Protocol(MCP)은 LLM이 외부 시스템과 통신하기 위한 개방형 표준 프로토콜입니다. 핵심은 "프로토콜"이라는 단어입니다. HTTP가 웹 통신의 표준인 것처럼, MCP는 AI와 외부 시스템 통신의 표준입니다.

⚠️ 흔한 오해 — "MCP = 또 다른 API 규격이다"

MCP는 단순 API가 아니라 프로토콜입니다. 그래서 따라오는 오해가 둘 더 있습니다. ① MCP Server ≠ 웹 서버 — 사용자가 직접 접속하는 서버가 아니라, LLM이 쓸 도구·리소스를 제공하는 "브릿지/어댑터"입니다. ② Client-Server 역할 혼동 — LLM 쪽에서 MCP Client가 동작하고, 외부 서비스가 MCP Server로 감싸집니다. 방향을 헷갈리면 전체 그림이 뒤집힙니다.

쉬운 비유로, Function Calling이 "가게마다 다른 결제 시스템"(A마트 포인트카드, B마트 전용앱, C마트 현금만)이라면, MCP는 "신용카드·간편결제 표준"입니다. 한 번 배우면 어느 가게든 같은 방식으로 결제하죠. 이 표준화가 가져오는 4대 가치는 표준화 · 재사용성 · 분리(LLM 로직 ↔ 외부 연동) · 보안(OAuth 2.1)입니다.

3. 3대 구성요소 — Tools · Resources · Prompts

MCP Server가 LLM에게 제공할 수 있는 것은 정확히 세 가지입니다. 회사에 빗대면 업무 처리 시스템(Tools)·공유 폴더(Resources)·업무 매뉴얼(Prompts)이고, 코드로는 데코레이터 하나씩으로 등록합니다.

🔧 Tools (도구)

실행 · 양방향 (입력→처리→출력)

LLM이 실행할 수 있는 함수. 이메일 발송, DB 쿼리, 파일 생성, API 호출.

@mcp_server.tool

📚 Resources (리소스)

조회 · 단방향 (읽기 전용)

LLM이 읽을 수 있는 정적 데이터. 설정 파일, 문서, DB 스키마.

@mcp_server.resource("task://stats")

📝 Prompts (프롬프트)

템플릿 · 재사용 (일관 품질)

재사용 가능한 프롬프트 템플릿. "데일리 스탠드업", "코드 리뷰 체크리스트".

@mcp_server.prompt

그림 2. MCP 3대 구성요소 — 실행(Tools)·읽기(Resources)·템플릿(Prompts).

핵심 차이는 방향성입니다. Tools는 부수효과(side-effect)를 일으키는 양방향 동작이고, Resources는 상태를 바꾸지 않는 읽기 전용입니다. 그래서 보안 정책도 갈립니다 — "조회는 전체 허용, 실행은 권한 분리"가 가능해지는 이유죠(11장에서 다시 다룹니다).

4. 아키텍처와 동작 흐름 — JSON-RPC로 도는 5단계

전체 그림은 4계층입니다. Host 앱 안에 LLM과 MCP Client가 있고, Client는 표준 프로토콜로 여러 MCP Server에 연결되며, 각 Server는 실제 외부 시스템(파일·DB)을 감쌉니다. Client는 프로토콜(JSON-RPC 2.0)·세션 라이프사이클·도구 발견과 호출을 책임집니다.

🧠 LLM Layer (Gemini · GPT · Claude)

↕

🔗 MCP Client

프로토콜 관리(JSON-RPC 2.0) · 세션 라이프사이클 · 도구 발견/호출

↕  표준 프로토콜  ↕

🗂️ MCP Server A — 파일시스템

Tools: read_file · write_file · list_dir
↓ Local Files

🗄️ MCP Server B — 데이터베이스

Tools: query_db · insert_record
↓ PostgreSQL DB

그림 3. MCP 4계층 아키텍처 — LLM ↔ Client ↔ 여러 Server ↔ 외부 시스템.

사용자가 "오늘 일정 알려줘"라고 하면 다음 5단계가 흐릅니다. 색은 역할입니다 — 주황=LLM 추론, 파랑=Client 통신, 슬레이트=Server 처리, 초록=결과.

1

LLM 분석

Reason

"get_today_events 도구 필요"

→

2

Client 요청

tools/call

JSON-RPC 2.0 전송

→

3

Server 처리

Execute

외부 API 호출·포맷팅

→

4

Server 응답

result

events 데이터 반환

→

5

LLM 응답

Respond

자연어로 일정 안내

LLM은 무슨 도구를 부를지만 정하고, 어떻게 부르는지는 Client/Server의 표준이 담당한다 — 관심사 분리

그림 4. "오늘 일정 알려줘" 한 줄이 도는 5단계 요청 처리 흐름.

2단계의 요청과 4단계의 응답은 모두 JSON-RPC 2.0 봉투에 담깁니다. 메서드 tools/call로 도구 이름과 인자를 보내면, 같은 id로 결과가 돌아옵니다.

JSON-RPC 2.0 · tools/call 요청과 result 응답

// 2. Client → Server 요청 { "jsonrpc": "2.0", "method": "tools/call", "params": { "name": "get_today_events", "arguments": { "date": "2025-01-04" } }, "id": 1 } // 4. Server → Client 응답 (같은 id로 매칭) { "jsonrpc": "2.0", "result": { "events": [ {"time": "09:00", "title": "팀 스탠드업"}, {"time": "14:00", "title": "고객 미팅"} ] }, "id": 1 }

5. 구현 ① FastMCP 기본 서버 — STDIO로 도구 노출

첫 구현은 2025년 가장 인기 있는 서버 프레임워크 FastMCP로 작업(Task) 관리 서버를 만듭니다. 데코레이터 하나로 Tools·Resources·Prompts를 모두 등록하는 게 핵심입니다. 타입 힌트가 그대로 입력 스키마가 되고, docstring이 도구 설명이 됩니다.

PYTHON · FastMCP — Tool·Resource·Prompt 등록

from fastmcp import FastMCP mcp_server = FastMCP(name="Task Management MCP Server") # 🔧 Tool — 타입 힌트=입력 스키마, docstring=도구 설명 @mcp_server.tool def create_task(title: str, description: str, priority: int = 3) -> str: """새로운 작업을 생성합니다.""" task = task_store.create(TaskCreateRequest(title, description, priority=priority)) return json.dumps(asdict(task), ensure_ascii=False) # 📚 Resource — 읽기 전용 정적 데이터 (URI로 식별) @mcp_server.resource("task://stats") def get_task_statistics() -> str: return json.dumps({"total": len(task_store.list())}, ensure_ascii=False) # 📝 Prompt — 재사용 템플릿 @mcp_server.prompt def daily_standup_prompt() -> str: return "## 데일리 스탠드업 리포트를 작성해주세요 ..."

서버 실행은 한 줄입니다. STDIO 모드로 띄우면 같은 머신의 MCP Client와 표준 입출력(stdin/stdout)으로 통신합니다. 예제 서버는 도구 7종(create/get/list/update/delete/search/overdue), 리소스 2종, 프롬프트 3종을 노출합니다.

PYTHON · STDIO 모드로 서버 기동

if __name__ == "__main__": # 로컬 MCP Client와 stdin/stdout으로 통신 mcp_server.run(transport="stdio")

6. 구현 ② Google ADK MCP 클라이언트 — 서버를 도구로

반대편입니다. Google ADK는 MCPToolset으로 외부 MCP Server를 에이전트의 도구로 네이티브하게 끌어옵니다. 여기서는 공식 파일시스템 MCP Server(@modelcontextprotocol/server-filesystem)를 npx로 띄워 STDIO로 연결합니다.

PYTHON · Google ADK MCPToolset 연결

from google.adk.agents import LlmAgent from google.adk.tools.mcp_tool.mcp_toolset import ( MCPToolset, StdioServerParameters) # 파일시스템 MCP Server를 STDIO로 기동해 도구로 흡수 fs_toolset = MCPToolset( connection_params=StdioServerParameters( command="npx", args=["-y", "@modelcontextprotocol/server-filesystem", "/tmp"], ), ) agent = LlmAgent( model="gemini-2.0-flash", name="file_assistant", instruction="파일 시스템 관리를 돕는 어시스턴트입니다.", tools=[fs_toolset], # ← MCP 도구가 일반 도구처럼 등록됨 )

에이전트 입장에서 MCP 도구는 일반 도구와 구분되지 않습니다. "현재 폴더의 파일 목록을 보여줘"라고 하면 LLM이 알아서 list_dir를 고릅니다. 원격 서버면 StdioServerParameters 대신 SSE 파라미터로 바꾸기만 하면 됩니다(9장). 한 번 만든 서버를 어떤 클라이언트든 재사용하는 MCP의 가치가 여기서 드러납니다.

7. 구현 ③ FastMCP HTTP 서버 — 원격 CRM 연동

셋째는 클라우드 배포용 HTTP 서버입니다. 같은 FastMCP 코드에서 transport만 바꾸면 원격 통신이 됩니다. 예제는 실무에 가까운 CRM MCP Server — 고객 조회, 상호작용 기록, 영업 파이프라인, 매출 예측 도구를 노출합니다.

PYTHON · CRM 도구 + HTTP 기동

mcp_server = FastMCP(name="CRM MCP Server") @mcp_server.tool def get_customer(customer_id: str) -> str: """특정 고객 정보를 조회합니다.""" logger.info(f"고객 조회: {customer_id}") customer = crm_db.customers.get(customer_id) return json.dumps(asdict(customer), ensure_ascii=False) @mcp_server.tool def get_revenue_forecast() -> str: """파이프라인 기반 매출을 예측합니다.""" active = [o for o in opps if o.stage not in ("closed_won","closed_lost")] weighted = sum(o.value * o.probability / 100 for o in active) # 가중 예측 return json.dumps({"weighted_forecast": weighted}, ensure_ascii=False) if __name__ == "__main__": # STDIO → HTTP 한 줄 변경으로 원격 배포 mcp_server.run(transport="http", host="127.0.0.1", port=8080)

원격이 되는 순간 인증이 필수입니다. 데모는 간단한 API Key로 시작하지만, 프로덕션은 OAuth 2.1 기반 JWT를 씁니다. FastMCP는 JWTVerifier를 서버 생성 시 끼워 넣는 방식으로 표준을 지원합니다.

PYTHON · 프로덕션 인증 (OAuth 2.1 / JWT)

from fastmcp.server.auth import JWTVerifier auth = JWTVerifier(public_key=..., audience="crm-server") mcp = FastMCP(name="CRM Server", auth=auth) # 모든 요청에 토큰 검증 # API 요청 헤더: Authorization: Bearer <token>

8. MCP vs Tool Function Calling — 무엇이 다른가

"그냥 Function Calling 쓰면 되지 않나?"라는 질문에 답하는 표입니다. 둘은 대체재가 아니라 추상화 계층이 다릅니다 — MCP는 Function Calling을 표준 프로토콜로 감싸 재사용·발견·분리를 더합니다.

구분	Tool Function Calling	Model Context Protocol
표준화	각 LLM마다 다른 구현 방식	단일 표준 프로토콜
범위	특정 LLM에 종속	LLM 독립적 (어디서든 동작)
아키텍처	직접 통합 (커플링 강함)	Client-Server 분리 (느슨)
발견	수동 등록 필요	자동 도구 발견(Discovery)
재사용성	낮음 (LLM별 재작성)	높음 (한 번 작성, 어디서든)

그림 5. MCP vs Tool Function Calling — 같은 목표, 다른 추상화 수준.

정리하면, 도구가 1~2개고 한 LLM에만 묶여 있다면 Function Calling으로 충분합니다. 하지만 여러 서비스를 여러 에이전트가 공유하거나 LLM을 갈아탈 여지가 있다면, 표준화·재사용의 이득이 커지는 MCP가 답입니다.

9. 통신 방식(Transport) — STDIO vs HTTP+SSE

MCP는 두 가지 전송 방식을 지원합니다. 같은 머신이면 STDIO, 원격이면 HTTP+SSE. 코드는 거의 그대로고 연결 파라미터/transport만 바뀝니다.

💻 STDIO — 로컬 전용

방식: stdin/stdout 프로세스 통신

✅ 빠름 · 보안 우수(네트워크 노출 0) · 설정 간단

⚠️ 같은 머신에서만 가능

transport="stdio"

🌐 HTTP + SSE — 원격

방식: HTTP POST 요청 + SSE 스트림 응답

✅ 원격 접근 · 확장성 · 로드밸런싱

⚠️ 네트워크 지연 · OAuth 2.1 보안 필수

transport="http"

그림 6. 두 Transport — 로컬(STDIO)과 원격(HTTP+SSE)의 트레이드오프.

2025년 사양은 원격 운영을 한층 다듬었습니다. 2025.11 업데이트로 Tasks(장시간 비동기 작업), Statelessness(무상태 아키텍처 권장), Async Operations, 도구 주석(Annotations) 강화가 추가됐습니다 — 모두 클라우드 스케일에서 MCP를 안정적으로 굴리기 위한 장치입니다.

10. 엔터프라이즈 — CRM·ERP·Groupware의 MCP ROI

MCP의 진짜 매력은 엔터프라이즈에서 드러납니다. 시스템마다 따로 짜던 AI 연동을 MCP Server 하나로 통일하고, 사용자는 자연어로 모든 시스템과 대화합니다. 시스템별 적용과 측정 효과입니다.

🤝 CRM

고객 360 조회 · 후속조치 · 영업기회 분석

고객 정보 조회 3분 → 5초

미팅 일정 잡기 10분 → 30초

영업팀 10명 월 480시간 절감

투자회수 약 0.3개월

🏭 ERP

재고 조회 · 재무 분석 · 발주·비용 승인

승인 처리 15분 → 2분 (87%↓)

리포트 생성 1시간 → 5분 (92%↓)

조회/분석 시간 70%↓

재고 비용 15%↓

💬 Groupware

통합 검색 · 결재 처리 · 회의·보고서

정보 검색 15분 → 10초 (99%↓)

결재 처리 5분 → 30초 (90%↓)

보고서 작성 2시간 → 30분 (75%↓)

결재 지연 2일 → 4시간

그림 7. 엔터프라이즈 MCP 적용과 효과 — CRM·ERP·Groupware별 핵심 ROI.

종합하면 적용전략 추정 기준 연간 비용 절감 2억 6천만원 + 매출 증가 10억 2천만원 규모입니다(CRM 1.2억 절감·7.2억 매출, ERP 8천만 절감·3억 재고 최적화, Groupware 6천만 절감). 도입은 12개월 4단계 — 파일럿(1~3개월) → 확장(4~6) → 통합(7~9) → 최적화(10~12) — 로 점진 배포하고, 그 위에 MCP Gateway(인증·Rate Limiting·로깅·Circuit Breaker)를 두어 전사 트래픽을 관리합니다.

11. 보안 — 민감 데이터에 AI를 붙일 때

MCP Server는 LLM을 사내 민감 데이터로 연결하는 통로입니다. 편리한 만큼 공격 표면도 넓어집니다. 그래서 보안은 선택이 아니라 전제입니다. 4개 계층으로 방어합니다.

① 인증 (Authentication)

OAuth 2.1 기반 토큰, JWT 검증(FastMCP JWTVerifier), 2025.06 RFC 8707 Resource Indicators 지원.

② 인가 (Authorization)

도구별 권한 분리(읽기 전용 vs 쓰기 가능), 역할 기반 접근 제어(RBAC), 리소스 범위 제한(특정 폴더만).

③ 프롬프트 인젝션 방지 ⚠️

사용자 입력 검증·이스케이프, 도구 파라미터 타입 검증, 민감 정보 필터링. 인젝션으로 권한이 우회되지 않도록 막는 MCP 고유의 핵심 위협.

④ 전송 보안 (Transport)

원격 통신은 HTTPS 필수, TLS 1.3 권장, 민감 데이터 암호화·응답 마스킹(주민번호·급여)·민감 정보 캐싱 금지.

엔터프라이즈에서는 여기에 감사(Audit) 계층을 더합니다 — 모든 MCP 호출 로깅, 민감 데이터 접근 알림, 이상 패턴 탐지. 그리고 성능 기준(응답 <500ms, 동시 100명+, 장애 5분 내 복구)을 핵심 성공 요인(CSF)으로 못 박습니다.

12. 베스트 프랙티스 — MCP를 쓸 자리와 피할 자리

MCP는 강력하지만 만능은 아닙니다. 표준화의 이득이 통합 오버헤드를 넘어서는 자리에 써야 합니다.

✅ 권장

여러 서비스를 여러 에이전트가 공유할 때

CRM·ERP·Groupware 등 사내 시스템 통합

LLM을 갈아탈 여지가 있는 장기 프로젝트

파일·DB·GitHub·Slack 등 표준 도구 연동

⛔ 비권장

도구 1~2개를 한 LLM에만 붙이는 경우

초저지연이 생명인 실시간 처리(통신 오버헤드)

보안 검토 없이 민감 데이터에 즉시 연결

단순 일회성 스크립트 (표준화 이득 적음)

실무 체크리스트: ① 서버는 한 번, 클라이언트는 여러 번 — 재사용을 전제로 설계 ② Tools는 좁고 명확하게, docstring·타입 힌트를 도구 설명으로 정성껏 ③ 읽기/쓰기 도구 권한 분리 ④ 로컬은 STDIO·원격은 HTTP+OAuth 2.1 ⑤ 모든 호출 로깅·감사 ⑥ 프롬프트 인젝션 입력 검증 ⑦ 장시간 작업은 2025 Tasks로, 응답 <500ms를 목표로.

★ 마치며

"순서대로 쪼개라"가 체이닝, "입력에 따라 길을 나눠라"가 라우팅, "독립 작업은 동시에"가 병렬화, "쓴 다음 읽고 고쳐라"가 리플렉션, "모르면 도구를 써라"가 도구 사용, "언제 어떤 순서로 쓸지 계획하라"가 플래닝, "전문가가 협력하라"가 멀티 에이전트, "겪은 것을 기억하라"가 메모리, "겪은 것에서 배워라"가 학습이었다면 — MCP는 "하나의 표준으로 외부와 연결하라"입니다. 이제 에이전트는 USB-C 하나로 세상의 모든 시스템에 꽂힙니다. 그런데 도구가 많아질수록 새 질문이 생깁니다 — "무엇을 향해, 어디까지 잘하고 있는가?" 다음 편 목표 설정과 모니터링(Goal Setting & Monitoring)에서는 에이전트가 스스로 목표를 세우고 성과를 점검하는 법을 다룹니다.

시리즈: 01 Prompt Chaining → 02 Routing → 03 Parallelization → 04 Reflection → 05 Tool Use → 06 Planning → 07 Multi-Agent → 08 Memory → 09 Learning & Adaptation → 10 Model Context Protocol → (다음) 11 Goal Setting & Monitoring

#MCP #ModelContextProtocol #FastMCP #GoogleADK #AI에이전트 #JSONRPC #OAuth2 #생성형AI

안내: 본 글은 Agentic AI Design Patterns 학습 자료(교재·패턴정의·엔터프라이즈 적용전략·구현 3종)를 재구성한 교육용 콘텐츠입니다. 코드는 개념 설명용 예시이며, 프레임워크 API는 버전에 따라 달라질 수 있습니다.