AIREITERChatGPT MCP 서버는 /mcp가 응답한다고 배포가 끝나는 게 아닙니다. ChatGPT가 서버에 접속하고, 적절한 도구를 검색하고, 사용자를 인증한 뒤, 상황에 맞는 도구를 선택할 수 있어야 합니다. 대부분의 팀에는 관리형 호스팅이 합리적인 기본값이고, 사설 인프라를 계속 사용해야 한다면 Secure MCP Tunnel이 적합합니다.
코드보다 먼저 배포 경계를 정하자
어디까지를 배포 대상으로 삼을지에 따라 전송 방식, 인증 구현 범위, 운영 부담, 공개 가능 여부가 달라집니다. ChatGPT는 원격 MCP 클라이언트입니다. 일부 데스크톱 클라이언트처럼 로컬 stdio 프로세스를 직접 실행하지는 않습니다(OpenAI Help Center).
| 배포 방식 | ChatGPT 연결 방식 | 적합한 경우 | 주요 비용 |
|---|---|---|---|
| 관리형 퍼블릭 호스팅 | 안정적인 HTTPS Streamable HTTP 엔드포인트 | 대부분의 팀용·고객용 앱 | 플랫폼 제약과 벤더 종속성 |
| 직접 관리하는 퍼블릭 엔드포인트 | 컨테이너, VM 또는 클러스터에 구축한 안정적인 HTTPS 엔드포인트 | 컴플라이언스나 네트워크 요구사항이 있는 기존 플랫폼 팀 | TLS, 스케일링, 패치, 롤백, 모니터링을 직접 책임져야 함 |
| Secure MCP Tunnel | OpenAI 호스팅 엔드포인트가 사설 stdio 또는 HTTP 서버로 요청을 중계 | 온프레미스 시스템, 사설 네트워크, 개발 환경 | 정상 작동하는 tunnel-client가 가용성의 일부가 됨 |
기본값으로 관리형 호스팅을 선택하자 MCP 서버가 무상태이고 트래픽이 간헐적으로 발생하며, 팀에 이미 안정적인 퍼블릭 애플리케이션 플랫폼이 없다면 관리형 호스팅이 가장 현실적입니다. Vercel의 라우트 핸들러 패턴과 Cloudflare의 무상태 Worker 패턴은 모두 ChatGPT가 요구하는 안정적인 HTTPS 엔드포인트를 제공합니다. 다만 선택하기 전에 각 플랫폼의 요청 처리 시간, 스트리밍, 상태 유지 제약을 확인해야 합니다(Vercel, Cloudflare).
퍼블릭 엔드포인트를 직접 운영하자 서버가 기존 데이터베이스와 가까운 위치에 있어야 하거나, 이미 구축된 ID 인프라를 사용해야 하거나, 데이터 레지던시 통제를 충족해야 할 때 적합합니다. 서버리스의 실행 시간 모델에 맞지 않는 작업을 처리해야 할 때도 마찬가지입니다. 다만 시크릿 관리, 배포 롤백, 알림, 온콜 담당자를 이미 갖춘 팀일 때만 이 선택을 정당화할 수 있습니다.
Secure MCP Tunnel을 사용하자 퍼블릭 인바운드 연결이 적절한 보안 경계가 아닐 때 선택하면 됩니다. OpenAI의 터널 클라이언트는 api.openai.com:443으로 아웃바운드 HTTPS 연결을 열고, 요청을 사설 HTTP 또는 stdio 서버로 전달합니다. 인터넷에 인바운드 리스너를 노출할 필요가 없습니다. 다만 OpenAI 배포 문서에 따르면 Secure MCP Tunnel은 안정적으로 공개 접근할 수 있는 HTTPS 엔드포인트를 요구하는 퍼블릭 제출 요건을 충족하지 않습니다(OpenAI tunnel documentation, OpenAI build guidance).
로컬 도구를 운영 환경의 ChatGPT MCP 서버로 옮기는 순서
안정적인 ChatGPT MCP 서버 배포는 도구 동작, 프로토콜 동작, 운영 환경 연결성, 모델 라우팅을 각각 별도의 게이트로 검증합니다. 한 단계를 통과했다고 다음 단계까지 통과한 것은 아닙니다.
1. 역할이 분명한 도구와 안정적인 계약부터 정의한다
먼저 사용자가 인식할 수 있는 행동 하나당 도구 하나를 배정합니다. OpenAI의 구축 가이드도 서로 무관한 모드를 하나의 도구에 몰아넣는 대신 list_projects, get_project, update_project를 별도 도구로 구성합니다(OpenAI developer documentation). 각 도구에는 행동을 드러내는 이름, 정확한 설명, 명시적인 입력 스키마, 유용한 출력, 올바른 안전성 주석이 필요합니다.
상태를 변경할 수 없는 도구에만 readOnlyHint: true를 지정합니다. 되돌릴 수 없거나 복구가 어려운 효과가 발생하면 destructiveHint: true를 사용하고, 개방형 외부 엔터티에 접근하는 도구에는 openWorldHint: true를 지정합니다. OpenAI는 이 주석을 도구 동작과 안전성 처리를 위해 모델에 제공되는 메타데이터로 설명하고 있습니다. 단, 보호된 요청에 대한 권한 검사는 서버가 매번 직접 수행해야 합니다(OpenAI developer documentation).
이후 호출에서 같은 레코드를 수정할 가능성이 있다면 structuredContent에 안정적인 레코드 식별자를 반환합니다. 토큰, 시크릿, 불필요한 개인정보는 content, structuredContent, _meta 어디에도 넣지 않는 편이 좋습니다. OpenAI도 _meta가 모델에는 보이지 않지만 안전한 저장소는 아니라고 명시합니다.
2. 로컬에서 Streamable HTTP를 노출한다
ChatGPT의 일반적인 원격 연결은 보통 /mcp에서 Streamable HTTP를 사용합니다. 이 경로는 관례일 뿐 반드시 고정해야 하는 것은 아니지만, ChatGPT에는 실제로 배포된 전체 URL을 입력해야 합니다(OpenAI connection guide).
서버를 로컬에서 실행한 뒤 MCP Inspector를 엽니다.
npx @modelcontextprotocol/inspector@latestInspector를 http://localhost:3000/mcp 같은 URL에 연결합니다. 초기화를 확인하고 도구 목록을 불러온 다음, 모든 도구를 유효한 요청, 잘못된 스키마, 누락된 식별자, 빈 결과 상황에서 각각 호출해 봅니다. 보호된 도구라면 자격 증명이 없거나 부족할 때 요청이 안전하게 거부되는지도 확인해야 합니다.
3. 외부에 공개하기 전에 운영 환경의 접근 제어를 추가한다
공개된 헬스 체크가 있다고 해서 도구 표면 전체를 공개해도 되는 것은 아닙니다. 도구가 의도적으로 공개한 읽기 전용 데이터만 제공한다면 인증 없는 엔드포인트도 가능할 수 있습니다. 하지만 비공개 데이터, 사용자별 데이터, 상태를 변경하는 작업에는 모든 요청에 대한 인증과 권한 검사가 필요합니다(OpenAI build guidance).
OAuth로 보호되는 MCP에서 서버는 리소스 서버 역할을 합니다. 인증되지 않은 요청에는 401을 반환하고, 일반적으로 /.well-known/oauth-protected-resource에 있는 보호 리소스 메타데이터를 클라이언트에 안내합니다. 인증 흐름에는 PKCE, 최소 범위의 토큰, 엄격한 발급자와 대상(audience) 검증이 포함되어야 하며, 지속적인 연결에 필요하다면 리프레시 토큰도 지원해야 합니다(OpenAI Help Center).
MCP 액세스 토큰과 업스트림 서비스가 모두 bearer 토큰을 인식한다는 이유만으로 해당 토큰을 그대로 전달해서는 안 됩니다. 토큰은 요청을 받는 리소스를 대상으로 발급된 것이어야 합니다. 다운스트림 호출에는 서비스 자격 증명이나 적절한 토큰 교환 설계를 사용해야 합니다(MCP deployment security guide).
4. 변경할 수 없는 후보 빌드를 배포한다
Inspector를 통과한 것과 동일한 빌드를 프리뷰 또는 스테이징 엔드포인트에 배포한 다음, 해당 아티팩트를 운영 환경으로 승격합니다. 운영 엔드포인트는 HTTPS를 사용하고, 전체 MCP 경로를 유지하며, 필요한 의존성에 연결되고, 시크릿은 호스팅 플랫폼의 시크릿 저장소에 보관해야 합니다.
간단한 Vercel 기준 경로를 따른다면 mcp-handler, @modelcontextprotocol/server, zod를 설치하고, 반환된 Web 핸들러를 app/api/mcp/route.ts에 마운트합니다. 이어서 GET과 POST용으로 export한 뒤 다음 명령으로 배포합니다.
npx vercel deploy --prod그러면 ChatGPT 연결 URL은 https://your-project.vercel.app/api/mcp 형태가 됩니다. Vercel은 Fluid compute에서 기본 함수 실행 시간으로 300초를 제공하며, 요건을 충족하는 유료 구성에서는 더 높은 한도를 지원합니다. 따라서 한 번의 요청보다 오래 걸리는 작업은 유휴 스트림을 계속 열어두기보다 재개 가능한 작업으로 분리해야 합니다(Vercel deployment guide). 선택한 런타임이 의도적으로 공유 상태를 지원하지 않는 한 라우트는 무상태로 유지합니다.
ChatGPT를 연결하기 전에 다음 네 가지 운영 제어를 추가합니다.
- 비용이 큰 도구에는 요청 타임아웃과 속도 제한을 설정합니다.
- 토큰이나 민감한 결과를 기록하지 않으면서 초기화 실패와 도구 실패를 로깅합니다.
- 각 호출에 릴리스 식별자를 남겨 장애가 어떤 배포 코드에서 발생했는지 추적할 수 있게 합니다.
- 도구 스키마나 권한 검사에 문제가 생겼을 때 사용할 롤백 절차를 테스트해 둡니다.
localhost가 아니라 운영 URL을 대상으로 MCP Inspector를 실행합니다. 도구 검색, 스키마, 주석, 인증, 정상 호출, 오류를 다시 확인해야 합니다. 로컬에서는 정상 작동했던 애플리케이션도 로드 밸런서, 프록시, CORS 규칙, ID 공급자의 리디렉션에서 실패할 수 있습니다.
접근 제어는 세 계층으로 나눠 설계한다
ChatGPT MCP 접근 제어에는 서로 독립적인 세 가지 집행 계층이 있습니다. OAuth를 활성화하는 것만으로는 신원 계층만 처리할 뿐입니다.
| 계층 | 집행 지점 | 결정해야 할 내용 |
|---|---|---|
| 워크스페이스 접근 | ChatGPT 관리자 제어 | 누가 앱을 만들고, 게시하고, 활성화하고, 사용할 수 있는가? |
| 사용자 신원 | OAuth 인증 서버와 MCP 리소스 서버 | 어떤 계정이 호출하고 있으며, 토큰이 이 서버에 유효한가? |
| 리소스·작업 권한 | MCP 도구 핸들러와 백엔드 | 이 사용자가 이 테넌트, 레코드, 환경에서 해당 작업을 수행할 수 있는가? |
ChatGPT Business에서는 관리자나 소유자가 개발자 모드와 게시 권한을 관리합니다. Enterprise와 Edu 워크스페이스에는 개발자 접근, 앱 접근, 작업에 대한 RBAC가 추가됩니다(OpenAI Help Center). 이런 제어는 ChatGPT가 앱을 사용할 수 있는지를 결정할 뿐입니다. 백엔드에서 호출자가 고객 A의 레코드를 수정할 권한이 있다는 사실까지 증명해 주지는 않습니다.
MCP 핸들러는 검증된 자격 증명에서 신원을 가져오고, 모든 호출에 대해 테넌트와 객체 단위의 권한을 적용해야 합니다. 모델이 생성한 인자에 포함된 사용자 ID, 조직 ID, 역할을 신원의 증거로 받아들여서는 안 됩니다. 모든 도구 인자는 신뢰할 수 없는 입력으로 취급해야 합니다.
읽기 범위와 쓰기 범위를 분리합니다. 예를 들어 projects:read는 넓게 허용하되 projects:write는 편집자에게만 부여하고, 파괴적인 작업을 실행하기 전에는 서버에서 최신 권한을 다시 확인할 수 있습니다. ChatGPT가 중요한 작업에 대해 확인을 요청할 수는 있지만, 확인은 사용자 경험을 위한 안전장치일 뿐 권한 제어가 아닙니다.
프롬프트 인젝션도 접근 제어의 문제로 봐야 합니다. 도구 출력과 검색된 문서에 악의적인 지시가 포함될 수 있으므로, 쓰기 도구는 가능한 한 좁은 작업만 노출하고 허용된 필드를 서버에서 검증해야 합니다. 범용 execute_action 도구 하나로 모든 작업을 처리하면 라우팅의 모호성과 피해 범위가 모두 커집니다.
ChatGPT에서 앱을 연결하고 테스트하고 게시하는 방법
엔드포인트를 연결하면 초안 앱과 메타데이터 스냅샷이 생성됩니다. 게시하면 검토된 구성을 워크스페이스에서 사용할 수 있게 되지만, 이것은 서버 코드를 배포하는 작업과는 별개입니다.
- 해당 ChatGPT 워크스페이스 정책에 따라 개발자 모드를 활성화합니다.
- 앱 생성 흐름을 열고
/mcp가 마운트된 경로라면 이를 포함한 전체 HTTPS MCP URL을 입력합니다. - 인증 방식을 선택하고 필요하다면 OAuth를 완료합니다.
- Scan Tools를 실행해 검색된 이름, 스키마, 주석, 작업을 모두 확인한 뒤 초안을 생성합니다.
- 워크스페이스에 게시하기 전에 새 채팅에서 초안을 테스트합니다.
사설 서버라면 연결 방식으로 Tunnel을 선택한 뒤 연결된 터널을 고르거나 tunnel_id를 입력합니다. 운영자에게는 OpenAI Platform의 Tunnels Read + Use 권한이 필요하며, ChatGPT 개발자 모드는 별도의 워크스페이스 권한으로 유지됩니다(OpenAI tunnel documentation).
메타데이터 변경에는 명시적인 수명 주기가 필요합니다. 개발자 모드 연결이라면 서버를 배포하거나 재시작하고, 연결을 연 다음 Refresh를 선택해 변경된 메타데이터를 확인하고 새 대화를 시작합니다. OpenAI의 현재 Business 안내에 따르면 게시된 앱에서 도구나 메타데이터를 변경하려면 앱을 다시 만들고 재게시해야 합니다. Enterprise/Edu 관리자는 작업을 새로 고치고 변경 사항을 검토한 뒤 새 작업을 활성화할 수 있으며, 새 작업은 기본적으로 비활성화되어 있습니다(OpenAI Help Center).
그래도 서버 정책은 하위 호환성을 우선하는 것이 가장 안전합니다. 선택적 필드와 새 도구를 추가하고, 기존 도구의 의미를 조용히 바꾸지 않습니다. 승인된 모든 스냅샷과 클라이언트가 이전할 때까지 기존 스키마를 유지합니다.
실제 ChatGPT 사용자가 보게 될 동작을 테스트한다
프로토콜 테스트는 서버가 응답할 수 있다는 사실을 검증합니다. 반면 ChatGPT 테스트는 모델이 의도한 도구를 선택하고, 적절한 인자를 전달하며, 경계를 지키고, 관련 없는 상황에서는 도구를 사용하지 않는지를 검증합니다.
Reddit 사용자 u/EmailNo8428은 이 문제를 두 계층으로 나눠 설명했습니다.
“실제로는 두 가지를 동시에 테스트하는 셈입니다. 도구 로직과 특정 클라이언트가 그 도구를 호출하는 방식이죠.” (r/mcp)
다음 사례를 포함한 작고 버전 관리되는 평가 세트를 만듭니다.
| 사례 | 기대 결과 |
|---|---|
| 직접 요청 | 유효한 인자로 지정된 기능을 선택함 |
| 간접 요청 | 사용자 목표에서 올바른 도구를 추론함 |
| 후속 요청 | 이전에 반환된 안정적인 식별자를 재사용함 |
| 부정 요청 | MCP 도구를 호출하지 않음 |
| 권한 부족 | 데이터를 유출하지 않고 유용한 권한 오류를 반환함 |
| 쓰기 요청 | 범위가 좁은 쓰기 도구를 선택하고 해당되는 확인 절차를 실행함 |
| 모호한 요청 | 인자를 지어내지 않고 필요한 정보를 요청함 |
| 빈 결과 | 전송 오류나 스키마 오류가 아닌 유효한 빈 상태를 반환함 |
선택된 도구, 인자, 반환 결과, 오류, 확인 동작을 기록합니다. 도구 이름, 설명, 스키마, 주석, 인증 규칙, 결과 형태가 바뀔 때마다 영향을 받는 사례를 다시 실행해야 합니다. OpenAI도 연결 가이드에서 동일한 새로 고침과 재테스트 주기를 안내합니다.
Inspector는 통과했지만 ChatGPT에서 라우팅이 엉뚱하다면 도구의 경계, 설명, 스키마를 더 명확하게 다듬어야 할 가능성이 큽니다. 반대로 라우팅은 정확하지만 401이 반환되거나 타임아웃이 발생하거나 상태가 사라진다면 인프라 또는 권한 문제입니다. 두 진단을 분리하면 수정 작업을 훨씬 빠르게 진행할 수 있습니다.
FAQ
ChatGPT가 localhost나 stdio MCP 서버에 직접 연결할 수 있나요?
아니요. ChatGPT는 일반적으로 원격 MCP 엔드포인트에 연결합니다. OpenAI Secure MCP Tunnel을 사용하면 퍼블릭 인바운드 연결 없이 사설 stdio 또는 HTTP 서버로 요청을 중계할 수 있습니다. 개발 단계에서는 임시 HTTPS 터널을 사용할 수 있지만 퍼블릭 플러그인 제출에는 사용할 수 없습니다.
ChatGPT MCP 서버에는 공개 HTTPS 엔드포인트가 필요한가요?
일반적인 원격 연결과 퍼블릭 플러그인 제출에는 안정적인 HTTPS가 필요합니다. 사설 개발자 모드 서버는 Secure MCP Tunnel을 사용할 수 있으며, 이 경우 서버는 고객이 관리하는 환경 안에 그대로 둘 수 있습니다.
search와 fetch가 필수인가요?
아닙니다. OpenAI는 연결된 서버에 더 이상 이 두 도구가 필수는 아니라고 설명합니다. 다만 회사 지식 검색이나 딥 리서치 검색 화면에 앱이 참여해야 한다면 표준 search와 fetch 계약을 구현해야 합니다(OpenAI Help Center).
배포했는데도 ChatGPT에 이전 도구가 계속 표시되는 이유는 무엇인가요?
ChatGPT는 모든 코드 배포를 승인된 도구 변경으로 간주하지 않고, 검색된 메타데이터를 저장합니다. 개발자 모드 연결은 새로 고친 뒤 새 대화를 시작해야 하며, 게시된 워크스페이스 앱은 요금제에 따른 검토 및 재게시 절차를 따라야 합니다.