OpenAI Secure MCP Tunnel: private MCP 서버를 public으로 만들지 않는 연결 방식
OpenAI Secure MCP Tunnel 공개, 핵심은 사내 MCP 서버를 인터넷에 직접 노출하지 않는 연결 구조였다
한눈에 보기
- 발표 내용: OpenAI가 private MCP 서버를 public endpoint로 만들지 않고 OpenAI 제품에 연결하는 Secure MCP Tunnel 구조를 공개했다.
- 핵심 변화: 고객 환경 안의
tunnel-client가 outbound HTTPS로 OpenAI와 연결하고, MCP 요청을 내부 서버로 전달한다. - 한 줄 결론: MCP를 사내 도구에 붙이려는 팀에게는 기능보다 보안 경계 설계가 먼저라는 점을 보여주는 업데이트다.
이번 발표, 뭐가 나왔나
OpenAI Developers Blog에 2026년 6월 26일 Making private MCP servers reachable without making them public이라는 글이 올라왔다. 핵심은 Secure MCP Tunnel이다. 기업 내부망, private service mesh, 개발자 노트북 안에 있는 MCP 서버를 인터넷에 직접 공개하지 않고도 ChatGPT, Codex 같은 OpenAI 제품에서 표준 MCP 요청 흐름으로 쓰게 하는 방식이다.
OpenAI는 기존 방식이 public endpoint를 만들거나, 추가 proxy 인프라를 두거나, VPN/peering 같은 네트워크 확장을 요구하는 경우가 많았다고 설명한다. Secure MCP Tunnel은 고객 환경 안에서 작은 클라이언트를 실행하고, 이 클라이언트가 OpenAI로 outbound HTTPS 연결을 만드는 쪽으로 문제를 푼다.
핵심 변화 3가지
1. private MCP 서버를 public으로 열지 않는다
이번 구조의 첫 번째 포인트는 MCP 서버가 inbound public traffic을 받을 필요가 없다는 점이다. 고객은 private MCP 서버가 이미 접근 가능한 네트워크 안에서 tunnel-client를 실행한다. 이 클라이언트가 OpenAI-hosted MCP endpoint와 outbound-only 연결을 만든다.
사용자 입장에서는 "AI가 사내 도구를 쓴다"는 말보다 "사내 도구를 어디까지 열어야 하느냐"가 더 현실적인 문제다. Secure MCP Tunnel은 이 경계를 넓히기보다, 설정된 private tool로 향하는 좁은 통로를 만드는 쪽에 가깝다.
2. 요청은 OpenAI 쪽 endpoint에 쌓이고 client가 가져간다
OpenAI 제품은 OpenAI-hosted tunnel endpoint로 MCP JSON-RPC 요청을 보낸다. 그 요청은 tunnel service에 보관되거나 스트리밍되고, 고객 환경 안에서 실행 중인 tunnel-client가 처리할 수 있는 만큼 가져간다. 이후 client는 approved local server로 요청을 전달하고, 응답과 notification을 같은 tunnel 경로로 돌려보낸다.
OpenAI가 long-poll 방식을 먼저 택한 이유도 실무적이다. outbound HTTPS는 기업 방화벽과 proxy 환경에서 익숙하고, long-polling은 클라이언트가 감당 가능한 만큼만 작업을 가져가게 해 queue가 무한정 쌓이는 문제를 줄일 수 있다.
3. 보안 검토 가능한 작은 client를 전제로 한다
원문에서 반복되는 키워드는 inspectable client다. 고객 환경 안에서 실행되는 코드라면 보안팀이 무엇을 하는지 볼 수 있어야 한다. OpenAI는 tunnel client가 고객 통제 아래 실행되고, private MCP 주소는 고객 환경 내부에서만 사용되며, tunnel access가 OpenAI organization, workspace context, configured tunnel identity와 연결된다고 설명한다.
또한 private MCP 서버가 OAuth, private CA, outbound proxy, MCP-side mTLS를 쓸 수 있다는 점도 다룬다. 다만 Secure MCP Tunnel은 모든 사내 네트워크를 OpenAI에 열어주는 bridge가 아니다. authorization server가 private이면 OAuth flow를 수행하는 component가 여전히 그 서버에 닿을 수 있어야 한다는 경계도 명시돼 있다.
그래서 실제로 뭐가 달라지나
일반 사용자 기준
일반 사용자가 바로 버튼 하나로 체감할 기능은 아니다. 하지만 회사에서 ChatGPT나 Codex가 내부 도구와 연결되는 경험은 더 자연스러워질 수 있다. 예를 들어 공개 URL을 만들기 어려운 사내 시스템을 AI 도구와 연결할 때, 보안 검토의 출발점이 달라진다.
개발자 기준
개발자는 MCP 서버를 public endpoint로 배포하지 않고도 실험할 수 있는 길이 생긴다. 공식 가이드는 private MCP 서버가 닿는 네트워크 안에서 tunnel-client를 실행하고, tunnel identity와 private MCP server address를 설정하는 흐름을 설명한다. 개발자 노트북에서 시작해 Kubernetes, VM, 고객이 제어하는 다른 환경으로 옮기는 모델도 언급된다.
창업자/업무 활용 기준
업무 자동화 제품이나 내부 AI 에이전트를 만들 때 가장 민감한 부분은 데이터 접근 경계다. Secure MCP Tunnel은 "AI가 사내 시스템에 접근한다"는 제안을 보안팀이 검토할 수 있는 형태로 바꾸는 데 의미가 있다. 다만 요금, 일반 제공 범위, 제품별 지원 상태는 공식 가이드와 계정 권한 기준으로 따로 확인해야 한다.
좋은 점
- private MCP 서버를 인터넷에 직접 공개하지 않아도 OpenAI 제품과 연결할 수 있다.
- outbound HTTPS와 long-poll 구조라 기업 네트워크 환경에서 설명하기 쉽다.
- customer-run client, 명시적 destination configuration, tunnel identity 같은 보안 검토 지점이 있다.
아쉬운 점
- 초기 설정, tunnel identity, private MCP 주소, proxy/CA/mTLS 같은 운영 설정은 여전히 필요하다.
- OAuth 서버나 관련 내부 시스템 접근 경계는 자동으로 해결되지 않는다.
- 요금, 제품별 지원 범위, 사용 신청 절차는 아직 계정과 문서 기준으로 확인이 필요하다.
내 생각
이번 글은 "MCP가 더 강해졌다"보다 "MCP를 실제 회사 안에서 어떻게 붙일 것인가"에 가까운 이야기다. AI 에이전트가 내부 도구를 쓰려면 결국 네트워크, 권한, 감사, 장애 대응이 따라온다. 여기서 public endpoint를 열어버리는 방식은 빠르지만, 보안 검토 단계에서 바로 막힐 수 있다.
Secure MCP Tunnel의 방향은 꽤 현실적이다. 사내 서버를 밖으로 꺼내지 않고, 고객 환경 안의 작은 client가 필요한 요청만 가져가게 한다. 이 방식은 화려하진 않지만 엔터프라이즈 환경에서는 오히려 설득력이 있다.
다만 이것이 모든 내부망 연동 문제를 해결하는 만능 터널은 아니다. OpenAI도 일반-purpose network bridge가 아니라고 선을 긋는다. 그래서 실제 도입에서는 "어떤 MCP server를 열 것인가", "어떤 workspace에서 허용할 것인가", "OAuth와 인증 흐름은 어디서 처리할 것인가"를 같이 설계해야 한다.
결론
OpenAI Secure MCP Tunnel은 MCP가 실험 도구에서 사내 업무 인프라로 들어갈 때 필요한 연결 방식을 보여준다. 핵심은 private MCP 서버를 public으로 만들지 않고, 고객 환경에서 시작되는 outbound 연결로 OpenAI 제품과 이어주는 것이다.
한 줄 평: "MCP의 다음 과제는 기능 확장이 아니라, 사내 보안 경계를 유지한 연결 방식이다."
회사에서 MCP를 붙인다면 가장 먼저 막힐 지점이 네트워크인지, 권한인지, 감사 로그인지 댓글로 남겨줘도 좋겠다.