Remote MCP를 제대로 쓰려면 서버 하나만 띄우는 것으로는 부족합니다. 실무에서는 에이전트, MCP 서버, 게이트웨이, 상태 저장 계층, 관측성까지 함께 설계해야 합니다.
이 글은 Remote MCP를 아키텍처 관점에서 나누는 방법을 다룹니다. OpenAI, Cloudflare, FastMCP를 따로 보는 것이 아니라 하나의 실행 경로로 묶어 이해하는 데 초점을 둡니다.
개요 #
가장 단순한 구조는 다음과 같습니다.
- 에이전트가 사용자 의도를 해석합니다.
- 게이트웨이가 도구 접근을 통제합니다.
- MCP 서버가 외부 기능을 제공합니다.
- 상태 저장 계층이 세션과 승인 정보를 유지합니다.
이 구조는 OpenAI Remote MCP란 무엇인가: Responses API에서 외부 도구를 연결하는 실무 가이드와 FastMCP란 무엇인가: 2026년 Python MCP 서버 실무 가이드를 함께 읽으면 더 쉽게 이해할 수 있습니다.
왜 주목받는가 #
Remote MCP가 아키텍처로 중요한 이유는 세 가지입니다.
- 도구가 여러 개가 되면 단일 서버로는 관리가 어렵습니다.
- 승인, 보안, 로깅이 도구 호출마다 달라집니다.
- 에이전트와 도구의 수명 주기가 서로 다릅니다.
즉, “MCP 서버를 어떻게 만들까”보다 “MCP 호출 경로를 어떻게 나눌까”가 더 중요해집니다.
빠른 시작 #
작게 시작하려면 다음 순서를 추천합니다.
- 읽기 전용 도구 하나를 Remote MCP로 붙입니다.
- 승인 필요한 도구를 따로 분리합니다.
- 세션 상태를 저장하는 계층을 추가합니다.
- 관측성 로그를 분리합니다.
이 순서로 가면 처음부터 너무 많은 것을 바꾸지 않아도 됩니다. 먼저 조회형 워크로드로 확인하고, 그다음 쓰기 작업과 승인 작업을 넣는 편이 안전합니다.
설계 포인트 #
Remote MCP 아키텍처에서 가장 자주 놓치는 부분은 책임 분리입니다.
- 에이전트는 판단만 합니다.
- MCP 서버는 도구 실행만 합니다.
- 게이트웨이는 접근 통제만 합니다.
- 상태 저장 레이어는 세션과 정책만 관리합니다.
Cloudflare를 쓰는 경우, Workers는 라우팅과 실행에, Durable Objects는 세션 상태에, Remote MCP 서버는 외부 기능에 배치하는 식으로 나눌 수 있습니다. 이런 구조는 Cloudflare MCPAgent란 무엇인가: Cloudflare Agents와 Remote MCP를 연결하는 실무 가이드와도 잘 맞습니다.
여기에 FastMCP를 붙이면 Python 쪽 서버 구현이 쉬워지고, OpenAI 쪽에서는 Remote MCP connector로 호출 경로를 단순화할 수 있습니다.
보안 체크리스트 #
- 도구별 권한을 함수 단위로 나눕니다.
- 승인 상태와 실행 상태를 분리합니다.
- 로그는 사용자 식별 정보와 도구 입력을 구분해 저장합니다.
- 외부 서버는 trust zone 별로 나눕니다.
- 실패 시 재시도 정책을 무한 루프로 만들지 않습니다.
- 비정상 응답은 에이전트가 그대로 신뢰하지 않도록 검증합니다.
특히 보안 관점에서는 “게이트웨이를 하나 두면 해결된다”는 생각이 위험합니다. 게이트웨이는 통제 지점일 뿐이고, 정책은 여전히 서버와 상태 계층에도 있어야 합니다.
결론 #
Remote MCP는 도구 연결 기술이 아니라 분산된 책임을 묶는 설계 문제입니다. 에이전트, 게이트웨이, MCP 서버, 상태 저장 계층을 분리하면 확장성과 보안이 같이 좋아집니다.
처음에는 단순하게 시작하되, 호출 수가 늘어나는 순간부터는 구조를 분리해야 합니다. 그 시점이 오기 전에 승인과 로그 설계를 먼저 넣는 것이 가장 비용이 적습니다.