TECH 카테고리
MCP 서버 구축, 공식 문서로 확인한 5가지 함정
FastMCP로 10분 만에 서버를 띄울 수 있는 건 사실입니다. 문제는 그 10분짜리 서버가 실제 운영 환경에서 어떤 리스크를 안고 있는지를 아무도 명확하게 말해주지 않는다는 점입니다. 보안 연구팀이 인터넷을 스캔했을 때, 외부에 노출된 MCP 서버 1,862개 중 인증이 적용된 서버는 단 한 개도 없었습니다. (출처: Knostic Research, 2025)
MCP가 1년 만에 기반 인프라가 된 이유
Anthropic이 MCP(Model Context Protocol)를 공개한 건 2024년 11월입니다. 그로부터 불과 4개월 뒤인 2025년 3월, OpenAI가 ChatGPT Desktop·Agents SDK·Responses API 전체에 MCP 지원을 추가했습니다. Sam Altman이 직접 “사람들이 MCP를 좋아한다”고 말했고, Google은 Vertex AI에, Microsoft는 GitHub Copilot과 Semantic Kernel에 통합했습니다. (출처: TechCrunch, 2025.03.26)
채택 속도가 이렇게 빨랐던 건 MCP가 해결한 문제가 명확했기 때문입니다. MCP 이전에는 Claude가 Google Drive를 읽으려면 별도 커스텀 통합이 필요했고, ChatGPT가 같은 데이터에 접근하려면 또 다른 통합이 필요했습니다. MCP는 이 N×M 문제를 제거했습니다. MCP 서버 하나를 만들면 MCP를 지원하는 모든 AI 클라이언트가 바로 연결됩니다.
공식 스펙은 JSON-RPC 2.0 기반으로 호스트(LLM 앱), 클라이언트(앱 내 커넥터), 서버(컨텍스트·기능 제공) 세 계층으로 구성됩니다. 서버가 제공할 수 있는 기능은 Resources(데이터), Tools(AI가 실행하는 함수), Prompts(템플릿 메시지) 세 가지입니다. (출처: MCP 공식 스펙 2025-03-26, modelcontextprotocol.io)
💡 공식 발표문과 실제 채택 흐름을 같이 놓고 보니, MCP가 빠르게 퍼진 건 기술적 우위보다 “표준 선점”의 힘이 컸습니다. Linux Foundation 산하로 거버넌스가 이전된 것도 같은 맥락입니다.
FastMCP로 실제 서버 만들기 — 핵심 3단계
MCP 스펙 원문 자체는 JSON-RPC 메시지 처리, 세션 상태 관리, 요청·응답 포맷 구현까지 직접 해야 합니다. 실무에서 이 보일러플레이트를 없애주는 게 FastMCP 라이브러리입니다. (출처: gofastmcp.com 공식 문서)
① 설치 및 기본 서버 생성
먼저 FastMCP를 설치하고 서버 인스턴스를 만드는 것부터 시작합니다.
pip install fastmcpfrom fastmcp import FastMCP
mcp = FastMCP(name="My MCP Server")② 툴 등록 — @mcp.tool 데코레이터
Python 함수에 @mcp.tool 데코레이터를 붙이면, FastMCP가 함수명을 툴 이름으로, docstring을 AI용 설명으로, 타입 힌트를 JSON Schema로 자동 변환합니다. 프로토콜 보일러플레이트를 직접 작성할 필요가 없습니다.
@mcp.tool
def get_weather(location: str) -> str:
"""Returns current weather for a given city."""
# 실제 날씨 API 호출 로직
return f"{location}의 현재 날씨 정보"③ 리소스 등록 및 서버 실행
리소스는 읽기 전용 데이터를 제공합니다. URI 패턴에 {변수명}을 넣으면 동적 리소스 템플릿이 됩니다. mcp.run()으로 서버를 시작하면 기본 STDIO 트랜스포트로 Claude Desktop 등 MCP 클라이언트와 통신합니다.
@mcp.resource("user://{user_id}/profile")
def get_user_profile(user_id: str) -> dict:
"""사용자 프로필 데이터를 반환합니다."""
return {"id": user_id, "status": "active"}
if __name__ == "__main__":
mcp.run()💡 클라이언트가 tools/list를 요청하면 서버가 등록된 툴 목록과 스키마를 실시간으로 반환합니다. OpenAPI 스펙처럼 개발자가 사전에 읽는 문서가 아니라, AI 에이전트가 연결 시점마다 동적으로 받아가는 라이브 카탈로그입니다.
툴 설계를 잘못하면 오히려 AI 성능이 떨어집니다
대부분의 가이드가 빠뜨리는 부분이 여기 있습니다. FastMCP나 공식 OpenAPI 변환 도구를 쓰면 기존 REST API의 모든 엔드포인트를 MCP 툴로 한 번에 변환할 수 있습니다. 그런데 이렇게 하면 오히려 AI 에이전트의 응답 품질이 낮아집니다. (출처: WorkOS MCP vs REST 분석, 2026.03.13)
이유는 토큰 비용 구조에 있습니다. REST API를 쓰는 개발자는 코드를 한 번 짜면 get_user() → get_orders(user_id) → get_shipments(order_id)를 빠른 네트워크 요청으로 순차 호출합니다. 반면 LLM 에이전트는 컨텍스트 윈도우에 등록된 모든 툴 설명을 로드한 뒤, 어떤 툴을 호출할지 추론합니다. 툴이 50개면 50개의 설명이 전부 토큰으로 소비됩니다. 에이전트의 반복은 프로그래밍 반복과 달리, 매 호출마다 토큰과 지연 시간을 씁니다.
🔍 나쁜 설계 vs 좋은 설계 — 직접 비교
| 방식 | 나쁜 설계 (API 1:1 변환) | 좋은 설계 (결과 중심 설계) |
|---|---|---|
| 툴 구성 | get_user, get_orders, get_shipments (3개) |
track_order(email) (1개) |
| AI 호출 횟수 | 3회 (각 단계 추론 포함) | 1회 |
| 컨텍스트 오염 | 중간 결과물이 컨텍스트에 누적 | 최종 응답만 반환 |
| 응답 품질 | 중간 실패 시 전체 태스크 중단 위험 | 내부에서 에러 처리 후 완성된 답 반환 |
툴 설계의 기준은 “REST API 구조를 그대로 반영하는 것”이 아니라 “AI가 사용자 질문에 답하기 위해 한 번에 받아야 할 정보가 무엇인가”여야 합니다. MCP 서버를 만든다는 건 개발자가 쓸 API를 만드는 게 아니라, AI가 쓸 UI를 만드는 것과 같습니다.
MCP 서버가 REST를 대체하지 않는 진짜 이유
“MCP가 나왔으니 REST API는 이제 필요 없다”는 말이 개발자 커뮤니티에서 돌고 있습니다. 실제 구조를 보면 정반대입니다. GitHub MCP 서버를 예로 들면, AI 에이전트에게는 repository/list라는 MCP 툴로 보이지만, 그 내부에서는 GitHub REST API를 호출하고 있습니다. MCP 레이어는 AI가 이해할 수 있는 인터페이스를 제공하고, 실제 비즈니스 로직은 기존 REST API가 그대로 처리합니다.
Web·모바일 앱, 마이크로서비스 간 통신, 고성능 데이터 조회처럼 인간 개발자가 결정적 코드를 작성하는 시나리오에서는 REST가 여전히 맞습니다. HTTP 캐싱, CDN, 로드밸런서 같은 수십 년치 인프라가 REST를 지원합니다. MCP가 필요한 순간은 클라이언트가 LLM 에이전트일 때, 즉 런타임에 어떤 API를 호출할지 스스로 추론해야 할 때입니다.
💡 MCP 서버와 REST API의 역할 분리를 실제 아키텍처로 보면: LLM 에이전트 → MCP 프로토콜(도구 발견·세션 관리) → 기존 REST API(비즈니스 로직). 대체가 아니라 래핑(wrapping) 구조입니다.
MCP 인증 방식도 REST와 다릅니다. REST는 API 키부터 커스텀 헤더까지 방식이 제각각이지만, MCP 공식 스펙은 OAuth 2.1 + PKCE를 명시합니다. 에이전트가 사용자 대신 행동할 때 “어떤 사용자가 어떤 작업을 허가했는지”를 스코프 토큰으로 증명하는 구조입니다. (출처: MCP Authorization Specification, 2025.11)
지금 당장 확인해야 할 보안 이슈 5가지
솔직히 말하면, MCP 관련 한국어 블로그 대부분은 “이렇게 만들면 됩니다”에서 끝납니다. 이미 운영 중인 서버가 있다면 아래 5가지를 먼저 확인해야 합니다.
Knostic 연구팀이 2025년 인터넷에서 발견한 MCP 서버 1,862개 전수 조사 결과, 직접 테스트한 119개 전부가 인증 없이 내부 툴 목록 조회를 허용했습니다. 이는 어떤 조직이 어떤 데이터 소스를 연결했는지 외부에 그대로 노출된 상태입니다. (출처: Dark Reading, 2025) 외부 접근이 가능한 MCP 서버에 인증이 없으면, 내부 시스템 구성이 공개된 것과 같습니다.
JFrog 보안 연구팀이 2025년 7월 공개한 취약점으로, CVSS 9.6(심각)입니다. mcp-remote 패키지 0.0.5~0.1.15 버전에서 신뢰할 수 없는 MCP 서버에 연결할 때 임의 OS 명령 실행이 가능합니다. 취약 버전 누적 다운로드 수가 437,000+입니다. (출처: JFrog Security Research, 2025.07) 지금 즉시 0.1.16 이상으로 업데이트해야 합니다.
Backslash Security가 2025년 6월 발견한 문제로, 수백 개의 MCP 서버가 0.0.0.0(모든 네트워크 인터페이스)에 바인딩되어 있었습니다. 공용 WiFi를 포함한 같은 네트워크의 누구든 접근 가능한 상태입니다. 로컬 MCP 서버는 반드시 127.0.0.1(localhost)에만 바인딩해야 합니다.
여러 MCP 툴을 조합할 때 의도치 않은 데이터 유출 경로가 생깁니다. 악의적으로 설계된 툴이 신뢰할 수 있는 툴을 교체하거나, 프롬프트 인젝션 공격이 AI가 호출하는 툴과 파라미터를 조작할 수 있습니다. Palo Alto Networks 분석에 따르면, 공개된 MCP 서버의 43%가 커맨드 인젝션 취약점을 갖고 있습니다. (출처: Palo Alto Networks, 2025)
2025년 5월 Asana가 MCP 서버를 출시한 날부터 35일간, 멀티테넌트 격리 로직 버그로 인해 약 1,000개 기업 고객의 태스크·프로젝트·코멘트·파일이 다른 조직에 노출되었습니다. 외부 해킹이 아닌 자체 구현 오류였습니다. (출처: BleepingComputer, 2025.06) MCP를 연동한 SaaS라면 멀티테넌트 격리 테스트가 출시 전 필수입니다.
2026 로드맵에서 달라지는 것들
MCP 공식 로드맵(modelcontextprotocol.io/development/roadmap)에는 현재 우선순위 4개 영역이 명시되어 있습니다. 이 중 실제 MCP 서버 구축에 바로 영향을 주는 부분을 정리합니다.
트랜스포트 진화 — 수평 확장 지원
현재 Streamable HTTP는 프로덕션 수준이지만, 로드밸런서·프록시 뒤에서 수평 확장할 때 세션 유지에 문제가 있습니다. 로드맵은 서버 재시작과 스케일아웃이 클라이언트에게 투명하게 보이도록 세션 이동(session migration) 스펙을 추가할 예정입니다. 지금 스테이트풀 세션에 의존한 구조로 만든다면, 이 변화에 맞춰 수정이 필요할 수 있습니다. (출처: MCP 공식 로드맵, 2026.03.05)
MCP Server Cards — 서버 메타데이터 표준화
.well-known URL로 서버 메타데이터를 공개하는 표준이 추가됩니다. 브라우저, 크롤러, 레지스트리가 서버에 직접 연결하지 않고도 어떤 기능을 제공하는지 파악할 수 있게 됩니다. AI 에이전트가 MCP 서버를 자동 발견하는 생태계가 열리는 신호입니다.
엔터프라이즈 WG — 감사 로그·SSO 통합
로드맵은 엔터프라이즈 배포에서 필요한 감사 추적(end-to-end audit trail), SSO 통합 인증 경로, 게이트웨이 패턴을 별도 Enterprise Working Group이 담당하도록 명시했습니다. 현재 이 부분이 공식 스펙에서 미지원이라는 점은, 엔터프라이즈 MCP 구축 시 직접 구현해야 한다는 뜻입니다.
💡 로드맵 원문을 읽으면 알 수 있는 것: “감사 로그와 SSO 통합은 지금 공식 스펙에 없다.” 대부분의 한국어 블로그가 다루지 않는 부분입니다. 기업 환경에서 MCP를 도입하려면 이 공백을 직접 채워야 합니다.
Q&A
마치며
MCP 서버를 “빠르게 만드는 법”은 이미 충분한 자료가 있습니다. 그런데 막상 만들어보면 질문이 달라집니다. 인증은 어떻게 걸지, 툴을 몇 개나 노출해야 하는지, 운영 환경에서 어떤 리스크가 생기는지 — 이 부분들이 실제로 결정을 어렵게 만드는 지점입니다.
공식 문서와 보안 연구 자료를 같이 읽으면 그림이 달라집니다. FastMCP로 5분 만에 서버를 띄울 수 있다는 게 사실이고, 동시에 그 서버가 0.0.0.0에 바인딩된 채 인터넷에 노출될 수 있다는 것도 사실입니다. 두 가지를 함께 알고 시작해야 한다는 게 결론입니다.
2026 로드맵을 보면 MCP는 계속 빠르게 바뀝니다. 세션 스케일아웃, Server Cards, 엔터프라이즈 인증 등 아직 공식 스펙에 없는 것들이 순서대로 추가될 예정입니다. 지금 구조를 어떻게 잡느냐에 따라 나중에 수정 비용이 크게 달라질 것입니다.
본 포스팅 참고 자료
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. MCP 스펙은 현재 활발히 업데이트 중이며, 본문의 내용은 2025-03-26 스펙 기준입니다. 보안 CVE 정보는 공식 NVD 또는 해당 패키지 공식 채널에서 최신 상태를 확인하시기 바랍니다.
댓글 남기기