요약: Secure MCP Tunnel은 사내망이나 온프레미스에 있는 MCP 서버를 공인 인터넷에 노출하지 않고 OpenAI 제품에서 호출하게 해주는 구조입니다. tunnel-client가 내부 네트워크에서 outbound HTTPS로 OpenAI에 연결하고, 대기 중인 MCP 요청을 가져와 내부 서버로 전달한 뒤 응답을 돌려줍니다. 핵심은 inbound 포트를 열지 않는다는 점입니다.
MCP(Model Context Protocol)는 에이전트가 도구와 데이터를 쓰게 만드는 실용적인 방식입니다. 문제는 많은 MCP 서버가 내부 시스템과 붙어 있다는 점입니다. 사내 Jira, 고객 DB, 배포 도구, 로그 검색, 재고 시스템, 사설 REST API가 MCP 뒤에 연결될 수 있습니다. 이런 서버를 외부에서 접근 가능한 URL로 열면 공격면이 급격히 커집니다.
개발팀은 종종 빠른 테스트를 위해 ngrok, 임시 reverse proxy, public load balancer를 사용합니다. 데모에는 편하지만 운영에는 위험합니다. 인증 설정이 약하거나, 허용 도구가 과도하거나, 로그에 민감정보가 남을 수 있습니다. 더 큰 문제는 “AI 제품이 내부 도구를 써야 한다”는 이유로 방화벽 예외가 계속 늘어난다는 것입니다.
Secure MCP Tunnel은 이 구조를 뒤집습니다. 외부에서 내부로 들어오는 길을 열지 않고, 내부에서 OpenAI 쪽으로 나가는 연결만 유지합니다. 기업 네트워크에서 outbound HTTPS는 관리하기 쉽고, inbound 공개 포트보다 위험이 낮습니다.
OpenAI 문서에 따르면 Secure MCP Tunnel은 OpenAI-hosted MCP endpoint와 내부 tunnel-client로 구성됩니다. OpenAI 제품이 hosted tunnel endpoint로 MCP 요청을 보내면, 내부에서 실행 중인 tunnel-client가 long-poll로 queued work를 가져옵니다. 그런 다음 요청을 내부 MCP 서버로 전달하고, 응답을 같은 tunnel path로 돌려보냅니다.
이 방식에서는 MCP 서버 주소가 외부에 공개되지 않습니다. MCP 서버는 stdio command일 수도 있고, 내부 HTTP URL일 수도 있습니다. tunnel-client만 내부 서버에 접근할 수 있으면 됩니다. 네트워크 요구사항도 명확합니다. tunnel-client host는 api.openai.com:443 또는 mTLS 구성 시 mtls.api.openai.com:443으로 outbound HTTPS를 열 수 있어야 하고, 내부 MCP 서버에 로컬 또는 사설 네트워크로 접근할 수 있어야 합니다.
streaming 결과도 고려되어 있습니다. connector가 streamed results를 요청하면 tunnel path가 중간 server-sent events를 전달할 수 있습니다. 장기 실행 도구나 진행 상태를 보여줘야 하는 에이전트 workflow에 중요합니다.
가장 단순한 배포는 Kubernetes sidecar입니다. MCP 서버와 tunnel-client를 같은 Pod에 넣고 localhost로 연결합니다. 네트워크 경계가 작고, 배포 단위가 명확합니다. MCP 서버가 하나이고 해당 서버만 OpenAI 제품에 노출하면 되는 경우에 적합합니다.
두 번째는 dedicated Kubernetes deployment입니다. MCP 서버가 이미 사내 Service로 떠 있고 여러 tunnel-client가 접근해야 할 때 사용합니다. 이 경우 network policy로 tunnel-client namespace가 MCP service에 접근할 수 있는 범위를 제한해야 합니다. tunnel-client가 너무 많은 내부 서비스에 접근할 수 있으면 터널이 사실상 범용 프록시가 됩니다.
세 번째는 VM 또는 systemd service입니다. 온프레미스 서버, 사설 DB 근처, 레거시 네트워크에서 유용합니다. 운영팀이 기존 방식으로 프로세스 health check, 로그 수집, 재시작 정책을 관리할 수 있습니다. 어떤 패턴이든 tunnel-client는 /healthz, /readyz, /metrics와 loopback admin UI를 제공하므로 readiness와 polling 상태를 반드시 모니터링해야 합니다.
Secure MCP Tunnel에서 헷갈리기 쉬운 부분은 권한입니다. OpenAI Platform tunnel permissions와 ChatGPT developer-mode access는 별개입니다. 터널을 만들거나 수정하려면 Tunnels Read + Manage가 필요합니다. tunnel-client를 실행하거나 connector 설정에서 터널을 선택하려면 Tunnels Read + Use가 필요합니다.
ChatGPT Enterprise나 Edu에서 custom connector를 쓰려면 workspace admin이 developer mode 또는 create custom MCP connectors 권한을 줘야 합니다. Platform organization에 터널이 있어도 ChatGPT workspace에 association이 없으면 connector 설정에 터널이 보이지 않을 수 있습니다.
운영 runbook에는 “터널이 보이지 않을 때 확인할 것”을 넣어야 합니다. 첫째, 터널이 대상 ChatGPT workspace와 연결되어 있는지 봅니다. 둘째, 사용자가 Tunnels Use 권한을 갖고 있는지 확인합니다. 셋째, Platform organization과 workspace mapping이 자동으로 연결되지 않는 enterprise 구조라면 OpenAI account team의 수동 association이 필요할 수 있습니다.
Secure MCP Tunnel은 내부 서버를 공개하지 않는 transport입니다. 이것만으로 MCP 도구의 권한 문제가 해결되지는 않습니다. 내부 MCP 서버는 여전히 자체 인증, authorization, input validation, audit logging을 가져야 합니다.
예를 들어 “고객 정보 조회” 도구가 있다면 tunnel-client를 통해 들어온 요청이 어떤 사용자 또는 workspace context에서 왔는지 확인해야 합니다. MCP 서버가 모든 요청을 admin으로 처리하면 터널을 안전하게 구성해도 데이터 접근 사고가 날 수 있습니다. 도구별로 읽기와 쓰기를 분리하고, 삭제·결제·권한 변경 같은 작업은 별도 승인 단계를 둬야 합니다.
문서상 Secure MCP Tunnel metadata 변경은 API Platform Audit logs에 tunnel.created, tunnel.updated, tunnel.deleted 이벤트로 노출됩니다. 하지만 tunnel transport 요청 자체가 모든 앱 이벤트를 대신 기록하는 것은 아닙니다. ChatGPT app invocation log나 app auth lifecycle log는 앱 경로의 정상 로깅 정책을 따라야 합니다. 즉, “터널 로그”, “MCP 서버 로그”, “제품 호출 로그”를 각각 봐야 합니다.
운영에서 가장 흔한 장애는 tunnel-client가 멈췄거나, private MCP server에 접근하지 못하거나, workspace association이 빠진 경우입니다. tunnel-client doctor --profile --explain은 프로필 검증에 유용합니다. 배포 직후 doctor를 실행하고, /readyz가 성공해야 rollout을 완료하는 식으로 운영할 수 있습니다.
또한 raw HTTP logging은 기본적으로 꺼져 있고 support exports는 redacted된다고 문서가 설명합니다. 디버깅을 위해 무작정 raw request를 남기면 민감정보가 노출될 수 있습니다. 디버그 로그는 기간과 접근자를 제한하고, 운영 기본값은 최소 로그로 유지하는 편이 안전합니다.
출처: OpenAI Secure MCP Tunnel 문서, OpenAI API changelog 2026년 5월 19일.
