사내 MCP 서버를 외부에 공개하지 않고 OpenAI와 연결하는 방법

AI를 회사 업무에 붙이려 하면 모델 성능이나 프롬프트보다 먼저 부딪히는 문제가 있습니다.

회사 안에 있는 문서와 업무 시스템을 외부의 AI가 어떻게 안전하게 사용할 수 있을까?

고객 관리 시스템, 운영 어드민, 배포 도구, 내부 API처럼 중요한 서비스는 대부분 사내망에 있습니다. 외부 요청을 받지 않도록 막아둔 것이 정상입니다. 하지만 ChatGPT나 Codex가 실제 업무를 도우려면 언젠가는 이런 내부 도구와 연결되어야 합니다.

OpenAI가 공개한 Secure MCP Tunnel은 이 문제를 다룹니다. 내부 MCP 서버에 공개 주소를 만들거나 인바운드 방화벽 포트를 열지 않고, 내부에서 시작한 아웃바운드 HTTPS 연결을 통해 지원되는 OpenAI 제품과 요청을 주고받는 방식입니다.

이 글에서는 Secure MCP Tunnel의 구조와 장점, 도입 전에 꼭 확인해야 할 보안 경계를 쉽게 정리합니다.

Secure MCP Tunnel이란?

MCP(Model Context Protocol)는 AI가 외부 도구와 데이터를 표준화된 방식으로 사용할 수 있게 만든 프로토콜입니다. 사내 문서 검색, 고객 정보 조회, 배포 상태 확인 같은 기능을 MCP 서버의 도구로 제공하면 AI가 필요할 때 호출할 수 있습니다.

문제는 가치 있는 MCP 서버일수록 공개 인터넷에서 접근하지 못하게 운영하는 경우가 많다는 점입니다. 기존에는 다음과 같은 방법을 검토해야 했습니다.

MCP 서버에 공개 엔드포인트 만들기
별도의 프록시나 서드파티 터널 운영하기
VPN이나 네트워크 피어링으로 넓은 연결 만들기

Secure MCP Tunnel은 연결 방향을 반대로 바꿉니다. 사내망에서 실행한 tunnel-client가 OpenAI에 먼저 아웃바운드 HTTPS 연결을 만들고, 승인된 MCP 서버로 요청을 전달합니다.

사내망 내부 서버와 OpenAI 제품을 제한된 아웃바운드 연결로 잇는 구조

내부 서버가 외부 요청을 직접 받는 구조가 아닙니다. 회사 안의 담당자가 정해진 창구에서 요청을 가져와 처리한 뒤 결과만 돌려주는 방식에 가깝습니다.

요청은 어떻게 오갈까?

전체 흐름은 다음과 같습니다.

OpenAI Platform에서 터널 엔드포인트를 만들고 tunnel_id를 발급받습니다.
내부 MCP 서버에 접근할 수 있는 사내 환경에서 tunnel-client를 실행합니다.
tunnel-client에 터널 ID와 MCP 서버 주소 또는 실행 명령을 설정합니다.
ChatGPT, Codex, Responses API 같은 지원 제품이 OpenAI의 터널 엔드포인트로 MCP 요청을 보냅니다.
tunnel-client가 대기 중인 요청을 가져와 내부 MCP 서버에 전달하고, 응답을 같은 경로로 돌려보냅니다.

OpenAI의 구현은 아웃바운드 HTTPS와 롱 폴링(long-polling)을 사용합니다. 클라이언트가 처리할 수 있는 만큼 요청을 가져오므로 자연스럽게 역압(backpressure)을 적용할 수 있고, 스트리밍이 필요하면 중간 Server-Sent Events도 전달할 수 있습니다.

기본 네트워크 요구사항은 단순합니다. tunnel-client를 실행하는 호스트가 내부 MCP 서버에 접근할 수 있어야 하고, 기본 설정에서는 api.openai.com:443으로 아웃바운드 HTTPS 통신을 할 수 있어야 합니다. 제어 구간에 mTLS를 적용하면 mtls.api.openai.com:443을 사용합니다.

기존 연결 방식과 무엇이 다를까?

공개 엔드포인트는 접근하기 쉽지만 새로운 인바운드 경로가 생깁니다. VPN이나 네트워크 피어링은 내부 서비스 하나를 연결하려는 목적에 비해 범위가 커질 수 있습니다. 서드파티 터널을 사용하면 연결 경로에 또 다른 공급자가 들어가므로 보안 검토와 운영 대상도 늘어납니다.

Secure MCP Tunnel은 회사 전체 네트워크가 아니라 설정한 MCP 서버까지의 좁은 경로를 만듭니다.

내부 MCP 서버는 공개 주소를 가질 필요가 없습니다.
외부에서 사내망으로 들어오는 방화벽 포트를 열지 않습니다.
터널 클라이언트가 접근할 MCP 서버를 명시적으로 설정합니다.
터널 사용 권한은 기존 OpenAI 조직과 워크스페이스 컨텍스트에 연결됩니다.
내부에서 실행되는 클라이언트는 오픈소스이므로 코드와 동작을 검토할 수 있습니다.

개발자는 노트북에서 먼저 연결을 시험한 뒤 같은 구성을 VM, Kubernetes 사이드카 또는 별도 배포 환경으로 옮길 수 있습니다. 운영팀은 헬스 체크, 준비 상태, 로그, 로컬 관리 UI를 통해 클라이언트 상태를 확인할 수 있습니다.

회사 전체를 여는 통로는 아니다

Secure MCP Tunnel을 일반적인 VPN처럼 이해하면 안 됩니다. 터널은 내부 네트워크 전체에 접근할 수 있는 범용 통로가 아니라, 고객이 설정한 대상에만 연결되는 제한된 전송 경로입니다.

예를 들어 터널 클라이언트가 사내 문서 검색 MCP 서버에만 접근하도록 구성했다면, 같은 네트워크에 있는 고객 DB나 파일 서버까지 자동으로 접근할 수 있는 것은 아닙니다. MCP 서버 자체의 도구와 권한도 최소 범위로 설계해야 합니다.

인증도 같은 원칙을 따릅니다. 내부 MCP 서버의 OAuth 검색 과정은 터널을 통해 전달할 수 있고, 커스텀 CA, 아웃바운드 프록시, 클라이언트 인증서, MCP 구간의 mTLS 같은 기업 환경도 지원합니다. 다만 비공개 인증 서버가 있다면 OAuth를 실제로 수행하는 구성 요소에서 그 서버에 접근할 수 있어야 합니다. 터널이 관련된 모든 내부 엔드포인트를 자동으로 열어주지는 않습니다.

꼭 알아야 할 보안 경계

여기서 가장 중요한 오해를 짚고 넘어가야 합니다.

MCP 서버를 외부에 공개하지 않는다는 말이 데이터가 외부로 나가지 않는다는 뜻은 아닙니다.

도구 호출 요청, 응답, 스트리밍 이벤트는 OpenAI가 호스팅하는 터널 엔드포인트를 통해 전달됩니다. 따라서 어떤 데이터와 작업을 MCP 도구로 제공할지, OpenAI 제품 사용이 회사 정책상 허용되는지, 제품별 데이터 처리와 보존 정책이 조직 요구사항에 맞는지를 별도로 검토해야 합니다.

또한 터널 전송 로그와 제품 수준의 감사 로그는 범위가 다릅니다. 공식 문서에 따르면 터널 메타데이터의 생성·수정·삭제는 Platform 감사 로그에 남지만, 개별 터널 전송 요청은 ChatGPT Compliance Platform의 앱 이벤트로 기록되지 않습니다. ChatGPT에서 커스텀 앱이 호출되면 일반적인 앱 수준의 규정 준수 로그가 별도로 적용됩니다. 조직의 감사 요구사항을 이 두 계층에 맞춰 확인해야 합니다.

권한도 두 곳에서 확인해야 한다

터널을 사용할 때는 OpenAI Platform 권한과 ChatGPT 워크스페이스 권한을 구분해야 합니다.

터널 생성·수정: Tunnels Read + Manage
tunnel-client 실행과 터널 선택: Tunnels Read + Use
ChatGPT에서 앱 연결: 별도의 개발자 모드 권한

Platform 조직 소유자나 RBAC 관리자가 터널 권한을 부여하고, Enterprise/Edu 환경의 ChatGPT 개발자 모드는 워크스페이스 관리자가 허용합니다. Platform에서 터널을 만들었다고 ChatGPT에서 바로 보이는 것은 아닙니다. 터널과 대상 Platform 조직 또는 ChatGPT 워크스페이스의 연결도 설정해야 합니다.

기존 내부 REST API도 연결할 수 있을까?

모든 내부 도구가 이미 MCP 서버로 만들어진 것은 아닙니다. OpenAI는 공식 개발자 글에서 Harpoon이라는 방식을 통해 승인된 REST 대상에도 같은 제한적 연결 모델을 적용한다고 설명합니다.

아무 URL이나 호출하는 구조가 아니라, 고객이 터널 클라이언트에 이름이 붙은 대상을 등록하고 OpenAI 쪽에서는 그 이름으로 호출합니다. 허용 HTTP 메서드, 응답 크기, 시간 제한, 리디렉션 정책, 터널 접근 제어로 범위를 제한합니다.

핵심은 MCP와 같습니다. 내부 네트워크 전체를 연결하는 대신, 사용이 승인된 대상만 명시적으로 등록하는 것입니다.

도입 전에 확인할 체크리스트

기술적으로 연결할 수 있다는 사실만으로 운영 준비가 끝나지는 않습니다. 최소한 다음 항목을 함께 검토해야 합니다.

데이터와 권한

OpenAI 제품으로 전달할 수 있는 데이터 범위가 정해져 있는가?
MCP 서버와 각 도구가 최소 권한으로 동작하는가?
읽기 작업과 변경 작업을 구분하고, 중요한 작업에 사용자 승인을 두었는가?
Platform 조직과 ChatGPT 워크스페이스 연결 범위가 적절한가?

네트워크와 인증

tunnel-client 호스트의 아웃바운드 HTTPS 정책이 허용되는가?
클라이언트가 승인된 MCP 서버에만 접근하도록 제한했는가?
사내 프록시, 커스텀 CA, OAuth, mTLS 구성이 실제 환경과 맞는가?
API 키와 인증서를 안전하게 저장하고 교체할 방법이 있는가?

운영과 감사

tunnel-client를 누가, 어디에서 운영할 것인가?
헬스 체크와 준비 상태를 모니터링하고 장애 알림을 받을 수 있는가?
앱 호출 로그와 터널 메타데이터 감사 로그로 필요한 추적이 가능한가?
클라이언트 업데이트와 비밀 정보 교체 절차가 준비되어 있는가?

처음에는 조회 전용 도구 하나와 테스트 데이터로 시작하는 편이 좋습니다. 연결과 권한, 로그를 확인한 뒤 변경 작업이나 민감 데이터로 범위를 넓혀야 문제를 구분하기 쉽습니다.

정리

OpenAI Secure MCP Tunnel은 사내 MCP 서버를 공개 인터넷에 노출하지 않고 지원되는 OpenAI 제품과 연결하는 방법입니다. 내부에서 실행한 tunnel-client가 아웃바운드 HTTPS로 요청을 가져오고, 승인된 MCP 서버에 전달한 뒤 응답을 같은 경로로 반환합니다.

이 구조의 장점은 회사 네트워크 전체를 넓게 연결하지 않고도 작은 단위로 실험할 수 있다는 점입니다. 하지만 터널 자체가 보안 검토를 대신해 주지는 않습니다. 전달 데이터, MCP 도구의 권한, 조직과 워크스페이스 접근 제어, 감사 로그, 비밀 정보 관리까지 함께 설계해야 합니다.

사내망 때문에 AI 도입이 막혀 있었다면, 조회 전용 MCP 도구 하나를 명시적으로 연결하고 검증하는 것부터 시작해 볼 수 있습니다.