Secure MCP Tunnel 등장: private MCP 서버를 공개 엔드포인트 없이 연결하는 실무 의미

요약: Secure MCP Tunnel은 private MCP 서버를 인터넷에 공개하지 않고 ChatGPT, Codex 같은 OpenAI 제품에서 호출할 수 있게 하는 구조다. 핵심 키워드는 private MCP server, Secure MCP Tunnel, outbound HTTPS, enterprise AI tool integration이다. 사내 데이터를 AI 도구와 연결하려는 개발팀이라면 네트워크 설계부터 다시 봐야 한다.

MCP가 빠르게 퍼지면서 가장 큰 현실 문제가 드러났다. 정말 가치 있는 MCP 서버는 대개 공개 인터넷에 올리고 싶지 않은 곳에 있다. 사내 서비스 mesh, 쿠버네티스 클러스터, 개발자 노트북, 내부 문서 검색 API, 고객 운영 시스템 같은 곳이다. AI 제품에서 쓰려면 reachability가 필요하지만, 공개 endpoint를 열면 보안 리뷰와 운영 부담이 커진다.

OpenAI가 설명한 Secure MCP Tunnel의 방향은 이 문제를 정면으로 다룬다. private MCP 서버가 inbound traffic을 받는 대신, 고객 환경 안에서 작은 tunnel client가 outbound HTTPS connection을 만든다. OpenAI 제품 쪽 요청은 tunnel endpoint로 들어오고, 고객 환경 안의 client가 그 요청을 집어와 local MCP 서버에 전달한 뒤 같은 경로로 응답한다.

왜 공개 엔드포인트가 위험한 기본값인가

사내 MCP 서버를 연결하려는 팀이 흔히 고르는 방식은 세 가지다. 첫째, public endpoint를 만든다. 빠르지만 private boundary를 약하게 만든다. 둘째, third-party tunnel provider를 쓴다. 편하지만 보안 검토 대상이 하나 더 늘어난다. 셋째, VPN이나 peering으로 네트워크를 넓힌다. 강력하지만 좁은 도구 연결 하나에는 과하다.

Secure MCP Tunnel은 이 기본값을 뒤집는다. private side가 먼저 outbound 연결을 만들고, 공개 인터넷에서 사내 서버로 직접 들어오는 길은 만들지 않는다. 엔터프라이즈 방화벽과 프록시 환경에서 outbound HTTPS는 이미 익숙한 패턴이다. long-polling 기반으로 시작한 것도 운영적으로 지루한 선택을 한 셈이다. 화려한 실시간 네트워크보다 방화벽, proxy, backpressure를 설명하기 쉬운 쪽을 택했다.

개발자에게 이 차이는 크다. '우리 MCP 서버를 어디에 배포해야 하나'라는 질문이 '서버 근처에서 tunnel client를 어떻게 운영하고 제한할 것인가'로 바뀐다. 네트워크 노출 면적이 줄어들고, 승인된 local target만 열 수 있다.

MCP streaming과 인증까지 고려해야 한다

MCP는 단순 HTTP proxy로만 보면 부족하다. JSON-RPC request와 response, streaming event, notification, OAuth discovery 같은 흐름이 섞인다. private MCP 서버가 OAuth를 쓴다면 hosted product가 인증 방식을 알아야 하지만, 그렇다고 authorization server까지 무제한으로 열면 안 된다.

OpenAI의 설명에서 중요한 제약은 tunnel이 일반 VPN이 아니라는 점이다. customer-run client는 configured private service로만 요청을 전달한다. private authorization server가 필요하면 어떤 component가 그 OAuth flow를 수행할지 명확히 정해야 한다. custom CA bundle, outbound proxy, MCP-side mTLS 같은 엔터프라이즈 네트워크 조건도 client 설정에서 다뤄야 한다.

이 구조를 제대로 쓰려면 MCP server 자체도 인증과 권한을 가져야 한다. tunnel이 있다고 해서 내부 API를 익명으로 열어두면 안 된다. tool마다 read-only, write, destructive action을 나누고, OpenAI workspace와 tunnel identity를 운영 정책에 매핑해야 한다.

개발 환경에서 운영 환경까지 같은 루프를 유지한다

흥미로운 부분은 developer experience다. tunnel client는 노트북에서 MCP 서버 옆에 띄워 테스트할 수 있고, 나중에 Kubernetes나 VM으로 옮겨도 같은 정신 모델을 유지한다. '서버 근처에서 client를 실행한다', 'client가 local MCP 서버에 닿는지 확인한다', 'client가 OpenAI-facing path를 연다'는 흐름이다.

이 루프가 중요한 이유는 AI 도구 연결이 보통 플랫폼팀, 보안팀, 제품팀 사이에 걸리기 때문이다. 개발자는 빨리 실험하고 싶고, 보안팀은 공개 endpoint를 싫어하고, 플랫폼팀은 VPN 예외를 늘리고 싶지 않다. outbound-only tunnel은 각자의 요구를 완벽히 해결하지는 않아도 논의 단위를 작게 만든다.

또 하나의 포인트는 open-source tunnel client다. 고객 환경 안에서 실행되는 코드는 검사 가능해야 한다. 어떤 outbound connection을 여는지, 어떤 request를 전달하는지, 어떤 config로 제한되는지 리뷰할 수 있어야 enterprise adoption이 가능하다.

REST API까지 확장될 때의 주의점

OpenAI는 MCP만이 아니라 Harpoon이라는 REST target 확장도 언급한다. 아직 모든 내부 workflow가 MCP 서버로 포장된 것은 아니기 때문이다. 기존 REST API를 approved target으로 등록하고, OpenAI-side caller가 label을 호출하면 실제 HTTP 요청은 고객 환경 안에서 나가는 식이다.

여기서 가장 조심할 점은 label이 일반 네트워크 브리지가 되지 않게 하는 것이다. allowed methods, response-size limit, timeout, redirect policy, target registration을 좁게 관리해야 한다. '내부 API를 AI가 쓸 수 있다'는 문장만 보면 편리하지만, 운영 관점에서는 작은 API gateway를 하나 더 만든 것과 비슷하다.

따라서 처음에는 read-only target만 열고, audit log와 rate limit을 붙이고, 실제 write는 별도 approval 경로로 분리하는 편이 안전하다.

도입 설계 예시

예를 들어 고객지원팀이 내부 계정 상태를 조회하는 MCP 서버를 쓰고 싶다고 하자. public endpoint를 열지 않고, support-tools namespace 안에서 tunnel client를 배포한다. client는 http://account-mcp.internal:8080 하나만 target으로 가진다. OpenAI workspace의 support agent만 tunnel을 사용할 수 있게 묶는다. 조회 tool은 고객 ID, 최근 결제 상태, 최근 장애 이력만 반환한다. 환불, 플랜 변경, 이메일 발송은 포함하지 않는다.

이후 write action이 필요해지면 바로 tool에 추가하지 않는다. 먼저 draft 생성 tool을 만들고, 상담원이 CRM에서 확인 후 실행하게 한다. 충분히 안정되면 approval event와 함께 제한된 write tool을 연다. 이 순서가 사고 가능성을 줄인다.

실행 체크리스트

• private MCP 서버를 public endpoint로 열기 전에 outbound tunnel 가능성을 검토한다.
• tunnel client가 접근 가능한 local target을 명시적으로 제한한다.
• read-only tool부터 시작하고 write tool은 별도 approval을 요구한다.
• custom CA, proxy, mTLS, OAuth discovery 흐름을 운영 문서에 적는다.
• tunnel client 로그, target별 request count, error rate를 수집한다.
• response-size limit과 timeout을 기본값이 아니라 정책으로 정한다.
• REST target을 열 때는 allowed method와 redirect policy를 먼저 고정한다.
• 보안 리뷰에는 모델 프롬프트보다 네트워크 경계와 tool 권한표를 먼저 가져간다.