Ⅰ. MCP(Model Context Protocol)란?
MCP(Model Context Protocol)는 2024년 11월 Anthropic이 공개한 개방형 표준입니다. 목표는 AI 모델이 고립된 채 텍스트만 처리하는 한계를 줄이고, 실제 업무 시스템에 존재하는 데이터와 도구를 표준 방식으로 연결하는 것입니다.
기존에는 AI 애플리케이션마다 GitHub, Slack, DB, 파일시스템, 사내 API에 대한 커넥터를 각각 만들어야 했습니다. MCP는 이 문제를 “각 애플리케이션별 개별 연동”에서 “표준 MCP 서버를 통한 재사용 가능한 연동” 구조로 바꿉니다.
2025년 11월 25일 기준 최신 MCP 스펙은 JSON-RPC 2.0, 상태 기반 연결, 기능 협상, Tools·Resources·Prompts, Roots·Sampling·Elicitation, Streamable HTTP, OAuth 2.1 기반 인가 흐름을 중심으로 정리되어 있습니다. 다만 OAuth는 모든 구현에 강제되는 요소가 아니라 HTTP 기반 원격 MCP에서 따라야 할 권장 표준에 가깝습니다.
따라서 MCP를 “LLM 전용 USB-C”라고 비유할 수는 있지만, 더 정확히는 AI 호스트와 외부 도구·데이터 서버 사이의 표준 통신 규약이라고 설명하는 것이 좋습니다.
Ⅱ. MCP가 해결하는 LLM 통합의 문제
| 통합 난제 | 기존 방식의 한계 | MCP의 개선 방향 |
| 통합 복잡도 | LLM 애플리케이션마다 외부 도구별 커넥터를 따로 개발해야 합니다. | MCP 서버를 한 번 구현하면 MCP를 지원하는 여러 호스트에서 재사용할 수 있습니다. |
| 도구 발견 | 사용 가능한 함수와 API 설명을 프롬프트에 직접 넣거나 별도 설정으로 관리해야 합니다. | tools/list, resources/list, prompts/list 같은 표준 메서드로 런타임에 탐색할 수 있습니다. |
| 컨텍스트 주입 | 파일, DB 결과, 문서 내용을 그대로 프롬프트에 붙여 컨텍스트 낭비와 보안 문제가 생깁니다. | Resources를 URI 기반으로 제공해 필요한 시점에 필요한 데이터만 읽는 구조를 만들 수 있습니다. |
| 프롬프트 재사용 | 업무 프롬프트를 애플리케이션마다 복사해 관리하면서 버전 관리가 어려워집니다. | Prompts 프리미티브로 파라미터가 있는 재사용 템플릿을 서버가 공개할 수 있습니다. |
| 권한과 보안 | API 키가 코드나 설정 파일에 흩어지고, 사용자 승인 흐름이 애플리케이션마다 달라집니다. | 원격 HTTP MCP에서는 OAuth 2.1 계열 인가와 사용자 동의 UI를 결합해 최소 권한 접근을 설계할 수 있습니다. |
| 벤더 종속 | 각 모델 벤더의 Tool Calling 스키마가 달라 이식성이 낮습니다. | 도구·리소스·프롬프트 제공 방식을 프로토콜 레벨에서 표준화해 이식성을 높입니다. |
Ⅲ. MCP 주요 특징
: MCP는 특정 모델이나 특정 클라우드에 묶이지 않는 방식으로 AI 애플리케이션과 외부 시스템의 연결 구조를 정의합니다.
ⅱ. 세 가지 서버 기능: 서버는 Tools, Resources, Prompts를 제공합니다. Tools는 실행, Resources는 참조, Prompts는 재사용 가능한 업무 흐름에 가깝습니다.
ⅲ. 세 가지 클라이언트 기능: 클라이언트는 Roots, Sampling, Elicitation을 제공할 수 있습니다. 이는 파일 접근 경계, 서버 주도 LLM 질의, 사용자 추가 입력 요청에 해당합니다.
ⅳ. JSON-RPC 2.0 기반: 요청, 응답, 알림 메시지를 JSON-RPC 2.0 형식으로 주고받아 구현체 간 호환성을 높입니다.
ⅴ. 상태 기반 연결: 초기화와 기능 협상을 거친 뒤 세션을 유지하면서 도구 호출, 리소스 읽기, 진행률 알림, 취소 등을 처리합니다.
ⅵ. 원격 MCP 보안 강화: Streamable HTTP에서는 Origin 검증, 인증, 세션 ID 보호, HTTPS, OAuth 기반 인가가 중요합니다.
Ⅳ. MCP 동작 방식
MCP 세션은 일반적으로 초기화 → 기능 협상 → 프리미티브 발견 → 호출·응답 → 알림·취소·종료 순서로 동작합니다.
ⅰ. MCP 세션 흐름
| 단계 | 구분 | 대표 메서드 | 설명 |
| 1단계 | 초기화 | initialize | 클라이언트와 서버가 프로토콜 버전, 이름, 기능 목록을 교환합니다. |
| 2단계 | 세션 활성화 | initialized | 초기화가 끝났음을 알리고 이후 일반 메서드 호출을 시작합니다. |
| 3단계 | 기능 발견 | tools/list resources/list prompts/list |
사용 가능한 도구, 리소스, 프롬프트를 조회합니다. |
| 4단계 | 실행과 참조 | tools/call resources/read prompts/get |
AI가 필요한 도구를 실행하거나 리소스를 읽고 프롬프트 템플릿을 가져옵니다. |
| 5단계 | 양방향 이벤트 | notifications/* sampling/* elicitation/* |
진행률, 로그, 목록 변경, 사용자 추가 입력, 서버 주도 LLM 요청 등을 처리합니다. |
| 6단계 | 취소와 종료 | cancelled DELETE /mcp |
장시간 작업 취소, HTTP 세션 종료, 연결 해제를 처리합니다. |
Ⅴ. MCP 아키텍처 구성
MCP는 크게 Host, Client, Server, Transport, Authorization, Registry로 나누어 이해하면 쉽습니다.
ⅰ. 아키텍처 구성
Claude Desktop, IDE, ChatGPT 앱, 사내 AI 포털처럼 사용자가 직접 접하는 AI 애플리케이션입니다.
Host 내부에서 특정 MCP Server와 1:1 세션을 유지하는 연결 컴포넌트입니다.
도구, 리소스, 프롬프트를 표준 메서드로 공개하는 로컬 프로세스 또는 원격 서비스입니다.
| 구성 | 요소 | 역할 예시 또는 비고 |
| Host | 사용자 UI, 모델 호출, 승인 화면, 컨텍스트 조합을 담당합니다. | AI 데스크톱 앱, IDE, 사내 포털 |
| Client | Host 안에서 MCP Server와 세션을 만들고 JSON-RPC 메시지를 주고받습니다. | 서버 하나당 클라이언트 세션 하나로 이해하면 쉽습니다. |
| Server | 업무 시스템, 파일, DB, API, 브라우저 자동화 기능을 Tools·Resources·Prompts로 제공합니다. | Filesystem, GitHub, Postgres, Slack, Playwright 등 |
| Transport | JSON-RPC 메시지를 전달하는 통신 계층입니다. | 표준 전송은 stdio와 Streamable HTTP입니다. |
| Authorization | 원격 MCP 서버에서 사용자 인증, 권한 범위, 토큰 발급, 동의를 처리합니다. | OAuth 2.1, Protected Resource Metadata, OIDC Discovery |
| Registry | 공개 MCP 서버의 메타데이터를 검색하고 설치 정보를 제공하는 생태계 구성 요소입니다. | 공식 MCP Registry는 아직 Preview 단계입니다. |
ⅲ. 전송 방식 비교
| 전송 방식 | 특징 | 장점 | 주의 사항 |
| stdio | Host가 로컬 MCP 서버를 자식 프로세스로 실행하고 stdin/stdout으로 JSON-RPC를 주고받습니다. | 구성이 단순하고 로컬 개발에 적합합니다. | stdout에는 MCP 메시지만 출력해야 하며, 일반 로그는 stderr로 보내야 합니다. |
| Streamable HTTP | 단일 MCP 엔드포인트에서 HTTP POST/GET과 선택적 SSE 스트림을 사용합니다. | 원격 서버, 조직 공용 서버, 게이트웨이에 적합합니다. | Origin 검증, 인증, HTTPS, 세션 ID 보호가 필수입니다. |
| HTTP+SSE 레거시 | 초기 버전에서 사용된 방식이며 최신 스펙에서는 Streamable HTTP로 대체되었습니다. | 구형 서버와의 호환성에 필요할 수 있습니다. | 신규 구현은 Streamable HTTP를 우선 고려하는 것이 좋습니다. |
| 커스텀 전송 | 구현체가 필요에 따라 WebSocket, Unix Socket 등을 사용할 수 있습니다. | 특수 환경에 맞춘 최적화가 가능합니다. | JSON-RPC 메시지 형식과 생명주기 요구사항을 유지해야 합니다. |
Ⅵ. MCP 설치와 사용 방법
MCP 자체는 프로토콜이므로 설치의 실체는 SDK 설치 → 서버 작성 또는 실행 → 호스트에 등록 → Inspector로 검증입니다.
ⅰ. Python SDK 설치
# uv 설치 후 프로젝트 생성
uv init my-mcp-server
cd my-mcp-server
uv add "mcp[cli]"
# 버전 확인
uv run mcp version
ⅱ. TypeScript SDK 설치
mkdir my-mcp-server
cd my-mcp-server
npm init -y
npm i @modelcontextprotocol/sdk zod
npm i -D typescript tsx @types/node
npx tsc --init
ⅲ. Python FastMCP 예시
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("ops-helper")
@mcp.tool()
def check_service(name: str) -> str:
"""서비스 상태를 확인합니다."""
return f"{name} 서비스 상태를 확인했습니다."
@mcp.resource("service://list")
def service_list() -> str:
return "nginx, postgresql, redis, zabbix-agent"
@mcp.prompt()
def incident_summary(system: str) -> str:
return f"{system} 장애 원인을 5줄로 요약해 주세요."
if __name__ == "__main__":
mcp.run()
ⅳ. Inspector로 디버깅
npx @modelcontextprotocol/inspector \
uv run python server.py
ⅴ. 원격 Streamable HTTP 서버 예시
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("remote-ops", stateless_http=True)
@mcp.tool()
def ping(target: str) -> str:
return f"{target} 점검 요청을 수신했습니다."
mcp.run(
transport="streamable-http",
host="127.0.0.1",
port=8000
)
원격 MCP 서버는 반드시 HTTPS, 인증, Origin 검증, 접근 로그, 권한 분리, 비밀정보 마스킹을 적용해야 합니다. 로컬 테스트가 아니라면 0.0.0.0 바인딩을 무심코 사용하지 않는 것이 좋습니다.
Ⅶ. MCP 활용 방안
| 활용 분야 | 주요 유스케이스 | MCP 적용 포인트 |
| AI 코딩 에이전트 | 코드 검색, 테스트 실행, PR 생성, 코드 리뷰 | Filesystem, Git, GitHub, 터미널, 테스트 러너를 MCP 서버로 묶어 여러 IDE에서 재사용합니다. |
| 사내 지식 검색 | Confluence, Notion, Jira, Slack 질의 | 사용자 권한에 맞게 문서와 티켓을 조회하고, 필요한 근거만 모델에 전달합니다. |
| DevOps·SRE | 장애 분석, 로그 조회, 배포 상태 점검, 롤백 제안 | Kubernetes, Grafana, Prometheus, GitHub Actions, PagerDuty를 도구화할 수 있습니다. |
| 데이터 분석·BI | SQL 생성, 지표 조회, 대시보드 설명 | 읽기 전용 DB 계정과 쿼리 제한을 적용해 안전한 분석 보조 도구로 구성합니다. |
| 보안 운영 | SIEM 이벤트 요약, 취약점 티켓 생성, 정책 점검 | 민감 로그와 계정정보가 모델에 과도하게 전달되지 않도록 마스킹과 승인 흐름을 둡니다. |
| 업무 자동화 | 브라우저 조작, 양식 작성, 내부 API 호출 | Playwright 같은 브라우저 자동화 서버를 사용하되, 접근 가능한 도메인과 액션을 제한합니다. |
Ⅷ. 보안 주의사항과 트러블슈팅
MCP는 외부 시스템 접근과 도구 실행을 표준화하므로 편리하지만, 동시에 보안 위험도 커집니다. 특히 Tools는 사실상 코드 실행 경로가 될 수 있으므로 신뢰 경계와 승인 흐름을 분명히 해야 합니다.
ⅰ. 운영 전 체크리스트
- 도구 권한 최소화: 읽기 전용으로 충분한 도구는 쓰기 권한을 부여하지 않습니다.
- 명시적 사용자 승인: 파일 삭제, 배포, 결제, 계정 변경 같은 액션은 반드시 사용자 확인을 거칩니다.
- 비밀정보 차단: 토큰, 비밀번호, 개인정보, 내부망 주소가 도구 설명이나 응답에 노출되지 않도록 마스킹합니다.
- 서버 신뢰성 검증: 공식 제공 서버인지, 누가 운영하는지, 코드와 배포 경로를 확인합니다.
- Origin 검증: Streamable HTTP 서버는 DNS rebinding 방지를 위해 Origin 헤더를 검증합니다.
- 로그 분리: stdio 서버는 stdout에 MCP 메시지만 출력하고, 일반 로그는 stderr로 출력합니다.
- 감사 로그: 누가 어떤 도구를 언제 호출했는지 남겨야 사고 추적이 가능합니다.
ⅱ. 자주 발생하는 문제
| 증상 | 원인 후보 | 조치 방법 |
| 서버 연결은 되지만 도구 목록이 보이지 않습니다. | 초기화 실패, capabilities 불일치, tools/list 구현 누락 | Inspector로 initialize 응답과 tools/list 결과를 확인합니다. |
| stdio 서버가 바로 종료됩니다. | 환경변수 누락, 실행 경로 오류, stdout에 일반 로그 출력 | 명령어를 터미널에서 직접 실행하고 로그는 stderr로 분리합니다. |
| HTTP 서버에서 403이 발생합니다. | Origin 검증 실패, 인증 토큰 누락, 권한 범위 부족 | 허용 Origin, OAuth scope, Authorization 헤더를 확인합니다. |
| 도구 호출 결과가 모델에 이상하게 전달됩니다. | 응답 스키마 불일치, 과도한 텍스트 반환, 민감정보 포함 | 응답을 구조화하고 길이를 제한하며 마스킹을 적용합니다. |
| 구형 클라이언트와 원격 서버가 호환되지 않습니다. | HTTP+SSE 레거시와 Streamable HTTP 차이 | 서버에서 레거시 엔드포인트와 최신 /mcp 엔드포인트를 병행 지원할지 검토합니다. |
'AI(Artificial Intelligence)' 카테고리의 다른 글
| StatefulSet 멀티노드 LLM 추론 한계 끝낸 K8s LeaderWorkerSet (1) | 2026.06.18 |
|---|---|
| 다중 LLM 키·라우팅 지옥 끝낸 LiteLLM 2.x AI Gateway (0) | 2026.06.09 |
| 상태 기반 AI Agent를 안정적으로 설계하기 위한 Agent Orchestration Framework, LangGraph (0) | 2026.06.08 |
| Mojo 완벽 정리 - Python superset이자 MLIR 기반 AI 시스템 언어 (0) | 2026.05.31 |
| "Lambda는 부족하고 EKS는 무겁다: Modal이 GPU 인프라를 혁신하는 방법" (0) | 2026.05.22 |