# Custom MCP 수정 후 Web ChatGPT에 변경 사항을 반영하는 방법 > Canonical: https://dealcut.net/posts/chatgpt-custom-mcp-update-refresh-guide > Markdown alternate: https://dealcut.net/posts/chatgpt-custom-mcp-update-refresh-guide.md > Published: 2026-08-20T10:45:00.000Z > Updated: 2026-08-20T11:10:00.000Z > Category: 그 밖의 기록 ChatGPT Business에서 custom MCP를 수정한 뒤 서버 restart, tunnel reconnect, 새 채팅, MCP 재등록이 각각 언제 필요한지 tool discovery와 frozen snapshot 계층을 기준으로 정리합니다. ![노트북에서 MCP 서버와 클라우드, ChatGPT 도구 정의가 연결되는 계층을 추상화한 대표 이미지](https://cdn.dealcut.net/m/01/f4/13/f413a647cf016fa7-720.webp) ## 1. 가장 중요한 결론 Custom MCP를 수정한 뒤 Web ChatGPT에서 변경 사항을 반영시키는 문제는 단순히 > “터널을 재시작할까, MCP를 다시 등록할까?” 의 2가지 문제가 아닙니다. 실제로는 대략 다음 계층으로 나누어 생각해야 합니다. ```text MCP 소스 코드 ↓ MCP 서버 프로세스 ↓ 공개 transport / tunnel ↓ MCP protocol discovery ↓ ChatGPT의 MCP 앱 등록 상태 / tool snapshot ↓ 개별 ChatGPT 채팅에 주입된 tool definitions ↓ 모델의 실제 named-tool invocation ``` 그리고 인증이 별도의 횡단 계층으로 끼어 있습니다. ```text OAuth / auth metadata ↓ transport + app registration 둘 다에 영향 ``` 따라서 무엇을 변경했느냐에 따라 필요한 조치가 달라집니다. 가장 실용적으로 줄이면 이렇습니다. **내부 코드만 바뀜 → 서버 reload/restart.** **연결 경로만 꼬임 → tunnel/transport reconnect.** **tool contract가 바뀜 → ChatGPT 쪽 MCP 등록 상태를 새로 discovery하게 해야 함.** **ChatGPT 등록 상태는 최신인데 기존 채팅만 구버전 → 새 채팅.** **등록 상태 자체를 갱신할 방법이 현재 UI에 없음 → MCP 재등록.** 이 마지막 부분이 특히 **현재 Business Web ChatGPT 환경에서 중요합니다.** --- ## 2. OpenAI 문서와 실제 Web UI를 분리해서 생각해야 합니다 현재 OpenAI 공식 문서는 상당히 흥미로운 상태입니다. 문서에는 custom MCP 앱을 구성하면서 endpoint를 입력하고 인증을 설정한 뒤 **`Scan Tools`****를 클릭**하라고 명시되어 있습니다. 동시에 Business에서는 게시된 앱의 tool/metadata를 현재 업데이트할 수 없고, 변경하려면 recreate/republish해야 한다고 설명합니다. ([OpenAI Help Center](https://help.openai.com/en/articles/12584461-developer-mode-and-full-mcp-connectors-in-chatgpt "https://help.openai.com/en/articles/12584461-developer-mode-and-full-mcp-connectors-in-chatgpt")) 그런데 실제 사용 중인 Business Web ChatGPT에는 **`Scan Tools`****라는 메뉴나 도구가 없습니다.** 이 두 사실은 충돌해 보이지만, 문서 맨 위의 다음 설명과 연결됩니다. > Full MCP는 Business/Enterprise/Edu에 beta로 rollout 중이며 functionality, UI, permissions가 변경될 수 있다. 즉 현재 상황은 다음처럼 보는 것이 가장 안전합니다. ```text OpenAI documentation └─ 제품이 지향하는 개념적 workflow 실제 Business Web UI └─ 현재 해당 workspace/account에 실제 배포된 workflow ``` 둘이 반드시 1:1 대응하는 것은 아닙니다. ([OpenAI Help Center](https://help.openai.com/en/articles/12584461-developer-mode-and-full-mcp-connectors-in-chatgpt "https://help.openai.com/en/articles/12584461-developer-mode-and-full-mcp-connectors-in-chatgpt")) 따라서 앞으로는 `Scan Tools`라는 **UI 명칭 자체를 운영 개념으로 사용하면 안 됩니다.** 대신 저는 다음 용어를 사용하는 것이 좋다고 봅니다. > **registration-level tool rediscovery** 즉, **“ChatGPT에 등록된 MCP app이 MCP 서버의 현재 tool definitions를 다시 발견하게 만드는 과정”** 입니다. 현재 어떤 UI에서는 Refresh일 수 있고, 어떤 UI에서는 앱 재생성일 수 있고, 어떤 환경에서는 MCP를 삭제했다가 다시 등록해야 할 수도 있습니다. 핵심은 버튼 이름이 아니라 **결과적으로 새로운 tool snapshot이 만들어졌느냐**입니다. --- ## 3. OpenAI 문서에서 신뢰할 만한 부분과 덜 신뢰해야 할 부분 이 구분이 굉장히 중요합니다. ### 비교적 신뢰도가 높은 부분 OpenAI 문서는 현재 MCP 앱에 대해 **“frozen snapshot”**이라는 개념을 명시적으로 설명합니다. 관리자가 MCP 앱을 승인한 뒤에는 ChatGPT가 사용 가능한 tools와 inputs의 고정 snapshot을 사용하고, 개발자가 서버를 수정하더라도 변경 사항이 자동 적용되는 것은 아니라고 합니다. ([OpenAI Help Center](https://help.openai.com/ko-kr/articles/12584461-chatgpt%EC%9D%98-%EA%B0%9C%EB%B0%9C%EC%9E%90-%EB%AA%A8%EB%93%9C-%EB%B0%8F-mcp-%EC%95%B1-%EB%B2%A0%ED%83%80 "https://help.openai.com/ko-kr/articles/12584461-chatgpt%EC%9D%98-%EA%B0%9C%EB%B0%9C%EC%9E%90-%EB%AA%A8%EB%93%9C-%EB%B0%8F-mcp-%EC%95%B1-%EB%B2%A0%ED%83%80")) 이것은 실제 경험과도 매우 잘 일치합니다. 또한 OpenAI는 live MCP와 frozen snapshot이 달라지면 tool call이 실패할 수 있고, optional parameter 추가처럼 backward-compatible한 변경은 계속 동작할 수도 있다고 명시합니다. ([OpenAI Help Center](https://help.openai.com/ko-kr/articles/12584461-developer-mode-and-full-mcp-connectors-in-chatgpt-beta "https://help.openai.com/ko-kr/articles/12584461-developer-mode-and-full-mcp-connectors-in-chatgpt-beta")) 이것도 실제 MCP 개발 경험과 정확히 맞습니다. ### 주의해서 봐야 하는 부분 반면 다음과 같은 것은 실제 UI에 그대로 존재한다고 전제하면 안 됩니다. ```text Scan Tools 버튼 메뉴 위치 특정 Settings 경로 Refresh 버튼의 존재 여부 Draft/Publish UX의 정확한 구조 각 플랜에서 동일하게 보이는 관리 화면 ``` 특히 공식 문서가 **현재도** **`Scan Tools`****를 명시하지만 실제 Business UI에는 없다**는 것이 좋은 반례입니다. 따라서: > **OpenAI 문서는 상태 모델과 제한사항을 이해하는 자료로 사용하고, UI 조작 순서는 실제 계정에서 검증한다.** 이것이 현재 MCP 개발에서는 가장 안전한 접근입니다. --- ## 4. MCP 서버 프로세스 계층 가장 아래쪽부터 보겠습니다. 예를 들어 MCP tool이: ```text search_files(query) ``` 이고 내부에서 실행하는 DB 쿼리만 변경했다고 하겠습니다. 기존: ```text SELECT ... ``` 새 버전: ```text SELECT ... optimized ... ``` 하지만 다음은 전혀 바뀌지 않았습니다. ```text tool name description inputSchema outputSchema annotations ``` 이것은 **runtime implementation change**입니다. ChatGPT가 알아야 할 내용이 없습니다. 필요한 것은 보통 MCP 서버 프로세스에 새로운 코드가 올라가게 하는 것뿐입니다. ```text code 변경 ↓ server restart / hot reload ``` 여기서 tunnel까지 재시작해야 할 이유는 원칙적으로 없습니다. --- ## 5. 그런데 왜 “터널만 껐다 켰는데 해결되는” 경우가 있는가 여기서 실제 경험과 이론이 어긋나는 것처럼 보입니다. 터널은 보통: ```text ChatGPT ↓ public URL ↓ tunnel ↓ localhost MCP ``` 에서 transport 역할을 합니다. 터널 자체가 MCP의 `inputSchema`를 이해하는 것은 아닙니다. 그런데 터널을 restart하면 여러 일이 동시에 발생할 수 있습니다. ```text 기존 HTTP 연결 종료 MCP transport session 종료 새 transport connection 생성 MCP initialize 재실행 server capability 재확인 server process와 새 연결 경우에 따라 tool discovery 재실행 ``` 따라서 겉으로는: > “cloudflared 껐다 켰더니 해결됐다.” 처럼 보입니다. 하지만 실제 원인이 꼭 Cloudflare tunnel의 캐시였다는 뜻은 아닙니다. 더 정확하게는: > **transport reconnect가 MCP session/discovery를 부수 효과로 다시 발생시켰을 가능성** 이 있습니다. 따라서 tunnel restart는 **schema refresh API로 생각해서는 안 됩니다.** --- ## 6. MCP protocol 자체에도 tool discovery라는 계층이 있습니다 MCP 서버는 자신이 제공하는 tool들을 클라이언트에게 공개합니다. 개념적으로: ```text tools/list ``` 입니다. MCP 공식 specification에는 서버 capability로: ```text tools: listChanged: true ``` 를 광고할 수 있고, tool이 추가·제거·수정된 경우: ```text notifications/tools/list_changed ``` 를 보낼 수 있도록 정의되어 있습니다. ([Model Context Protocol](https://modelcontextprotocol.io/specification/2025-06-18/schema "https://modelcontextprotocol.io/specification/2025-06-18/schema")) 즉 MCP 프로토콜 자체는: ```text tool이 변경됨 ↓ 서버가 client에 notification ↓ client가 tools/list 다시 요청 ``` 이라는 동적 갱신 구조를 가질 수 있습니다. 여기서 중요한 점이 하나 있습니다. **MCP protocol이 tool refresh를 지원한다는 사실과 ChatGPT가 그 변경을 워크스페이스에 자동 승인한다는 것은 전혀 다른 문제입니다.** --- ## 7. MCP discovery와 ChatGPT의 보안/승인 snapshot은 다른 계층입니다 이것이 전체 문제의 중심입니다. MCP protocol에서는 서버가: ```text render_chart 변경됨! ``` 이라고 알려줄 수 있습니다. 하지만 ChatGPT 입장에서는 custom MCP가 조직에서 사용할 수 있는 action을 제공하므로: ```text 서버가 새로운 tool을 추가했다 → 자동으로 사용자에게 제공 ``` 해 버리는 것은 보안 측면에서 위험할 수 있습니다. 따라서 OpenAI는 승인된 app에 대해 frozen snapshot 개념을 둡니다. ([OpenAI Help Center](https://help.openai.com/ko-kr/articles/12584461-developer-mode-and-full-mcp-connectors-in-chatgpt-beta "https://help.openai.com/ko-kr/articles/12584461-developer-mode-and-full-mcp-connectors-in-chatgpt-beta")) 즉: ```text Live MCP server tools/list ↓ ChatGPT registration/approval layer ↓ approved/frozen tool definitions ``` 입니다. ![MCP 서버 도구 목록이 프로토콜 탐색을 거쳐 ChatGPT의 등록·승인 스냅샷과 개별 채팅의 도구 정의로 전달되는 흐름](https://cdn.dealcut.net/m/01/46/19/46196f690ef30c98-720.webp) 그래서 MCP의 `notifications/tools/list_changed`가 정상 작동한다고 하더라도: ```text MCP protocol level = 변경 감지 가능 ``` 이지, ```text ChatGPT workspace level = 새 tool 자동 사용 ``` 을 의미하지는 않습니다. --- ## 8. Business에서는 이것이 더 중요합니다 현재 OpenAI 공식 문서는 Business에 대해: > 게시된 앱의 tools 또는 metadata를 업데이트하려면 recreate and republish해야 한다. 고 설명합니다. ([OpenAI Help Center](https://help.openai.com/en/articles/12584461-developer-mode-and-full-mcp-connectors-in-chatgpt "https://help.openai.com/en/articles/12584461-developer-mode-and-full-mcp-connectors-in-chatgpt")) 이 **제약 자체는 중요한 정보**입니다. 하지만 앞서 설명한 것처럼 문서가 말하는 구체적인 UI: ```text Scan Tools Draft Publish ... ``` 가 현재 Business UI와 정확하게 일치한다고 보기는 어렵습니다. 따라서 실제 Business 환경에서는 다음처럼 해석하는 것이 더 좋습니다. ```text 서버 schema 변경 ↓ 현재 ChatGPT가 새 schema를 발견했는가? ↓ YES ─→ 새 채팅에서 검증 ↓ NO ↓ 현재 UI에 registration-level refresh 기능이 있는가? ↓ YES ─→ 그 기능 사용 NO ─→ MCP 재등록 ``` 여기서 **MCP 재등록은 단순한 편법이 아닙니다.** 현재 Business UI에서 registration snapshot을 강제로 다시 만들 수 있는 가장 확실한 수단일 수 있습니다. --- ## 9. MCP를 “새로 등록하면” 무엇이 달라지는가 여기서 재등록의 의미를 이해하는 것이 중요합니다. 기존 MCP: ```text App registration A endpoint authentication tool snapshot v10 ``` 를 삭제하고 다시 등록하면 개념적으로: ```text App registration B endpoint authentication fresh MCP discovery tool snapshot v11 ``` 이 만들어집니다. 따라서 재등록은 여러 상태를 한 번에 초기화할 가능성이 있습니다. ```text MCP app identity endpoint association authentication state 일부 tool definitions input schemas output schemas tool metadata 승인 snapshot ``` 그래서 다음과 같은 상황에서는 터널 restart로 해결되지 않지만 재등록으로 해결되는 것이 자연스럽습니다. ```text 서버 v11 터널 정상 tools/list v11 ChatGPT app v10 snapshot ``` 터널을 아무리 껐다 켜도: ```text ChatGPT app = v10 ``` 이면 모델은 계속 v10 schema만 봅니다. 재등록: ```text ChatGPT app v10 ↓ discard ↓ fresh registration ↓ ChatGPT app v11 ``` 이 되어야 해결됩니다. --- ## 10. 그리고 한 단계 더 있습니다: 개별 채팅의 tool definition 이것도 매우 중요합니다. ChatGPT의 app registration이 이미 v11이라고 하더라도 **현재 열려 있는 채팅은 v10 tool definition을 가지고 있을 수 있습니다.** 구조를 단순화하면: ```text MCP server v11 ↓ ChatGPT app registry v11 ↓ Conversation 생성 ↓ conversation tool-definition snapshot ``` 입니다. 그래서 이런 상황이 가능합니다. ```text 서버 v11 ChatGPT MCP registration v11 기존 채팅 v10 새 채팅 v11 ``` 이 경우 MCP를 재등록할 필요가 없습니다. **새 채팅만 만들면 됩니다.** 앞선 local-blog Phase 13에서 정확히 이 형태가 관찰되었습니다. 기존 채팅의 tool-definition은 과거 schema를 가지고 있었지만 fresh chat에서는 `render_diagram`과 `render_chart`의 새로운 semantic parameters가 노출되었습니다. --- ## 11. 그래서 “새 채팅”과 “MCP 재등록”은 완전히 다른 조치입니다 이 구분을 명확히 해야 합니다. ### 새 채팅 해결하는 것: ```text conversation-local tool schema stale ``` 해결하지 못하는 것: ```text ChatGPT app registration 자체가 stale ``` ### MCP 재등록 해결할 수 있는 것: ```text registration-level stale snapshot endpoint metadata tool discovery 상태 일부 auth/connection metadata ``` 그리고 새로 등록한 후에는 **fresh chat에서 검증하는 것**이 안전합니다. 즉 재등록과 새 채팅은 경쟁 관계가 아닙니다. ```text registration refresh + fresh conversation ``` 처럼 서로 다른 캐시를 제거합니다. --- ## 12. 변경 종류별로 다시 분류해 보면 실무에서는 다음 표가 가장 유용합니다. | 변경 | 서버 restart | tunnel restart | 새 채팅 | MCP 재등록 가능성 | | --- | --- | --- | --- | --- | | tool 내부 로직 | ○ | 보통 X | X | X | | DB 쿼리 변경 | ○ | X | X | X | | 로그 추가 | ○ | X | X | X | | 성능 개선 | ○ | X | X | X | | env 변경 | 보통 ○ | 경우에 따라 | X | 보통 X | | 서버 local port 변경 | ○ | ○/mapping 변경 | 보통 X | public URL 같으면 X | | public MCP URL 변경 | ○ | ○ | ○ | **높음** | | MCP path 변경 | ○ | ○/설정 | ○ | **높음** | | tool description 변경 | ○ | X | ○ | **stale하면 높음** | | tool 추가 | ○ | X | ○ | **높음** | | tool 삭제 | ○ | X | ○ | **높음** | | tool rename | ○ | X | ○ | **높음** | | optional parameter 추가 | ○ | X | 권장 | 새 field가 안 보이면 필요 | | required parameter 추가 | ○ | X | **필수** | **매우 높음** | | parameter rename | ○ | X | **필수** | **매우 높음** | | inputSchema 구조 변경 | ○ | X | **필수** | **높음** | | outputSchema 변경 | ○ | X | **필수** | **높음** | | annotations 변경 | ○ | X | 권장 | stale하면 필요 | | OAuth issuer 변경 | ○ | 경우에 따라 | ○ | **매우 높음** | | OAuth scopes 변경 | ○ | 경우에 따라 | ○ | **높음** | | 인증 방식 자체 변경 | ○ | 경우에 따라 | ○ | **매우 높음** | 여기서 중요한 점은 **현재 Business에는** **`Scan Tools`****라는 실제 UI가 있다는 가정을 제거했다는 것**입니다. 재-discovery가 필요할 경우 사용할 수 있는 실제 UI 기능이 없다면 **MCP 재등록을 registration refresh 방법으로 사용**하는 것이 현재 환경에서는 합리적입니다. --- ## 13. Optional parameter 추가가 가장 헷갈리는 사례입니다 예를 들어 기존 tool이: ```json { "query": "string" } ``` 이었다고 하겠습니다. 서버 v2: ```json { "query": "string", "limit": "number, optional" } ``` 으로 바뀝니다. 구버전 ChatGPT snapshot도: ```json { "query": "hello" } ``` 를 보내면 서버가 받을 수 있습니다. 그래서 tool 호출은 성공합니다. OpenAI도 optional parameter 추가와 같은 backward-compatible 변경은 기존 frozen snapshot에서도 계속 작동할 수 있다고 설명합니다. 하지만 모델이 보는 schema가 아직: ```text query ``` 뿐이라면 `limit`이라는 field는 사용할 수 없습니다. 이 때문에 개발자가 착각하기 쉽습니다. > “새 버전도 정상 작동하네. schema도 업데이트됐겠지.” 아닙니다. 정확한 결론은: ```text 기존 schema와 새 서버가 호환된다 ``` 일 뿐입니다. **새 schema가 ChatGPT에 반영됐다는 증거가 아닙니다.** --- ## 14. required parameter 추가는 바로 문제를 드러냅니다 기존 ChatGPT snapshot: ```json { "query": "hello" } ``` 새 서버: ```json { "query": "hello", "workspaceId": "required" } ``` 이면 ChatGPT는 계속: ```json { "query": "hello" } ``` 를 보내려고 합니다. 그리고 서버는: ```text INVALID_PARAMS workspaceId required ``` 를 반환합니다. OpenAI 문서가 설명하는 live MCP와 frozen snapshot mismatch가 바로 이런 경우입니다. 이 상황에서: ```text tunnel restart tunnel restart tunnel restart ``` 를 반복해도 app-level schema가 바뀌지 않으면 해결되지 않습니다. 현재 Business UI에 tool refresh 기능이 없다면 이 시점에서 **MCP 재등록을 고려하는 것이 맞습니다.** --- ## 15. Tool description만 변경했어도 중요할 수 있습니다 예를 들어: ```text search_files "Search files." ``` 에서: ```text search_files "Semantically searches source content. Use find_files instead when locating paths." ``` 로 description을 변경했다고 하겠습니다. JSON schema는 그대로입니다. 서버 호출도 정상입니다. 하지만 모델의 tool selection에는 큰 영향을 줄 수 있습니다. LLM에게: ```text tool name description parameter description schema ``` 가 모두 tool-selection context이기 때문입니다. 따라서 description 변경은 protocol적으로는 가벼워 보여도 **LLM behavior 관점에서는 contract change**로 보는 것이 좋습니다. --- ## 16. Output schema도 contract입니다 이 부분도 종종 놓칩니다. 기존: ```json { "result": "..." } ``` 새 버전: ```json { "result": "...", "quality": { "status": "pass" } } ``` 정도라면 backward compatible할 수 있습니다. 하지만: ```json { "result": "..." } ``` 에서: ```json { "data": { "result": "..." } } ``` 으로 바꾸면 adapter가 이전 output contract를 기대할 경우 문제가 생길 수 있습니다. 따라서 다음 모두를 하나의 **tool contract**로 봐야 합니다. ```text tool name description inputSchema outputSchema annotations read/write semantics ``` --- ## 17. Tunnel URL이 바뀌면 이야기가 완전히 달라집니다 예를 들어 ChatGPT에: ```text https://abc.example.com/mcp ``` 가 등록되어 있는데 tunnel restart 후 실제 endpoint가: ```text https://xyz.example.com/mcp ``` 가 되었다면 이것은 cache 문제가 아닙니다. 등록된 endpoint 자체가 잘못된 것입니다. 이 경우: ```text 새 채팅 ``` 은 아무 효과가 없습니다. ```text MCP 등록 정보 수정 또는 MCP 재등록 ``` 이 필요합니다. 그래서 custom MCP를 자주 수정한다면 **public endpoint를 최대한 고정시키는 것**이 매우 중요합니다. 이렇게 만들면: ```text ChatGPT ↓ https://local-blog.example.com/mcp ↓ stable tunnel ↓ 현재 MCP server ``` 서버를 열 번 바꿔도 ChatGPT 등록 endpoint는 그대로 유지됩니다. --- ## 18. OAuth/auth 변경은 별도 클래스입니다 다음은 schema 변경보다 훨씬 강한 변경으로 봐야 합니다. ```text OAuth issuer authorization endpoint token endpoint scope audience client registration 인증 mechanism ``` 이런 것을 바꾸면 ChatGPT가 가지고 있는: ```text authorization state connection metadata token issuer discovery ``` 가 현재 서버와 맞지 않을 수 있습니다. 따라서 auth 관련 구조 변경 후에는 tunnel restart보다 **connection/app registration 재설정** 가능성을 먼저 생각하는 것이 좋습니다. --- ## 19. 공식 문서가 틀렸다기보다 “레이어가 다르다”고 보는 것이 좋습니다 조금 더 정확하게 표현하면: > “OpenAI 문서가 실제 환경을 대표하지 못하는 경우가 있다.” 가 맞습니다. 특히 현재처럼 베타 롤아웃 중일 때는: ```text documentation version backend rollout version workspace feature flag plan account UI experiment region client bundle version ``` 등이 일치하지 않을 수 있습니다. 현재 공식 문서도 바로 그 가능성을 인정하며 UI와 permissions가 변경될 수 있다고 명시하고 있습니다. 그래서 MCP 문제를 디버깅할 때 증거 우선순위를 저는 이렇게 두는 것이 좋다고 봅니다. ### 1순위 — 실제 named-tool schema와 호출 결과 실제로 현재 ChatGPT에: ```text render_chart(template, data, ...) ``` 가 보이는가? 그리고 호출되는가? ### 2순위 — MCP 서버 자체에서 관찰되는 현재 상태 ```text server_version tool_schema_version build_sha tools/list ``` ### 3순위 — 실제 현재 Web ChatGPT UI Refresh가 있는가? 재등록밖에 없는가? ### 4순위 — OpenAI 공식 문서 제품의 의도된 제약/개념을 이해하는 데 매우 중요하지만, 버튼명과 UI workflow는 실제 환경과 어긋날 수 있음. 이 순서가 실전에서는 가장 신뢰성이 높습니다. --- ## 20. 그래서 MCP마다 `server_version`과 `tool_schema_version`을 분리해야 합니다 이건 여러 custom MCP를 운용할 경우 거의 필수에 가깝다고 생각합니다. 예: ```json { "server_version": "1.5.0", "tool_schema_version": 11 } ``` 왜 두 개를 나누느냐면: ```text server 1.5.1 schema 11 ``` 은 내부 구현만 변경된 것일 수 있습니다. 반대로: ```text server 1.6.0 schema 12 ``` 라면 ChatGPT가 알아야 하는 contract 변경이 있다는 뜻입니다. 그러면 디버깅할 때: ```text get_workspace_info → server=1.6.0 → schema=12 ``` 인데 실제 ChatGPT tool definition은 schema 11 수준이라면 즉시 결론을 낼 수 있습니다. ```text 서버 최신 transport 정상 ChatGPT-side tool snapshot stale ``` 입니다. 터널을 조사할 필요가 크게 줄어듭니다. --- ## 21. 한 단계 더 나아가 `schema_fingerprint`도 추천합니다 예를 들어: ```json { "server_version": "1.5.0", "tool_schema_version": 11, "tool_schema_fingerprint": "sha256:53bd..." } ``` 처럼 두는 것입니다. fingerprint는 예를 들어 다음을 canonicalize해서 계산합니다. ```text 모든 tool name description inputSchema outputSchema annotations ``` 그리고 tool 이름 순으로 정렬한 뒤 hash합니다. 그러면: ```text 서버 fingerprint = ABC ChatGPT가 실제 노출하는 schema = XYZ ``` 같은 차이를 자동화된 검증으로 잡아낼 수 있습니다. --- ## 22. 변경을 세 종류로 나누는 것이 가장 좋습니다 ### A. Runtime change ChatGPT가 알 필요 없는 변경입니다. ```text SQL filesystem implementation 성능 logging bug fix 내부 validation dependency update ``` 필요 조치: ```text server reload/restart ``` --- ### B. Contract change ChatGPT가 알아야 하는 변경입니다. ```text tool 추가/삭제 tool rename description inputSchema outputSchema required/optional annotations tool semantics ``` 필요 조치: ```text server update ↓ ChatGPT registration-level rediscovery ↓ fresh chat ↓ named-tool test ``` 현재 Business UI에 명시적인 rediscovery/refresh 기능이 없고 기존 registration이 stale하다면: ```text MCP 재등록 ``` 이 현실적인 방법입니다. --- ### C. Identity change MCP 연결 자체의 정체성이 바뀐 경우입니다. ```text public URL hostname /mcp endpoint OAuth issuer auth scheme ``` 이 경우: ```text connection/app 재구성 ``` 또는: ```text MCP 재등록 ``` 가능성이 매우 높습니다. --- ## 23. 실제 Business 환경에서 사용할 판단 트리 지금 상황을 기준으로 하면 이 절차가 가장 실용적입니다. ```text MCP를 수정했다 │ ▼ tool contract가 바뀌었는가? │ ┌────┴────┐ NO YES │ │ ▼ ▼ 서버 서버 restart restart │ │ ▼ ▼ 새 채팅 생성 테스트 │ ▼ 새 schema가 보이는가? │ ┌─────┴─────┐ YES NO │ │ ▼ ▼ named-tool ChatGPT registration 실제 호출 snapshot이 stale할 가능성 │ ▼ 현재 UI에 refresh/ rediscovery 기능이 있는가? │ ┌─────┴─────┐ YES NO │ │ ▼ ▼ 실행 MCP 재등록 │ ▼ 새 채팅 │ ▼ named-tool 검증 ``` ![MCP 변경 내용을 분류한 뒤 서버를 업데이트하고 새 채팅에서 도구 스키마를 검증한 후 필요할 때 MCP를 재등록하는 실전 절차](https://cdn.dealcut.net/m/01/8b/62/8b629e770ecc7d44-720.webp) 여기에는 **`Scan Tools`****라는 단계가 없습니다.** 그 버튼이 실제 환경에 존재하지 않기 때문입니다. --- ## 24. “터널만 재시작하면 되는 경우”를 정확하게 정의하면 다음과 같은 경우입니다. ```text MCP 등록 identity 동일 public URL 동일 tool contract 동일 ChatGPT snapshot도 사용할 수 있음 transport/session 또는 server process만 stale ``` 예: ```text 코드 bug fix ↓ server reload 안 됨 ↓ tunnel reconnect 과정에서 server/session 재연결 ↓ 정상 ``` 또는: ```text MCP connection이 끊김 ↓ tunnel restart ↓ 새 transport connection ↓ 정상 ``` 이것은 registration 문제와 다릅니다. --- ## 25. “MCP를 새로 등록해야 하는 경우”를 정확하게 정의하면 다음 조건이 특히 강한 신호입니다. ### ① 서버가 최신이라는 것이 확인됨 ```text server_version = latest ``` ### ② 호출도 서버까지 도달함 즉 tunnel은 정상. ### ③ 그런데 ChatGPT가 보여주는 tool schema가 옛날임 예: ```text server schema 11 ChatGPT: render_chart(spec) 실제 최신: render_chart(template, title, data, ...) ``` ### ④ 새 채팅에서도 여전히 옛 schema 이 순간에는 conversation cache 문제가 아닙니다. ```text registration-level snapshot stale ``` 을 강하게 의심할 수 있습니다. ### ⑤ 현재 Business UI에 refresh/rescan 기능이 없음 그렇다면 **MCP 재등록**이 가장 직접적인 해결책입니다. 이것이 현재 실제 환경을 반영한 판단입니다. --- ## 26. 반대로 새 채팅만 하면 되는 경우 다음 형태입니다. ```text 서버 최신 ChatGPT registration 최신 기존 chat = old schema 새 chat = new schema ``` 이 경우: ```text MCP 삭제 MCP 재등록 tunnel restart ``` 은 모두 과잉 대응입니다. 새 채팅이면 충분합니다. --- ## 27. local-blog Phase 13은 아주 좋은 진단 사례였습니다 당시 상태를 이 모델로 표현하면: ```text local-blog MCP server 1.5.0 / schema 11 │ │ 정상 ▼ transport/tunnel │ │ 정상 ▼ ChatGPT MCP environment │ ├─ 이전 대화: old tool-definition │ └─ fresh chat: semantic schema 11 ``` fresh chat에서는 실제: ```text render_diagram( template="linear-process", nodes=... ) ``` 와: ```text render_chart( template="comparison", title=..., data=... ) ``` 형태의 semantic named-tool 호출이 성공했습니다. 즉 이 사례에서는 **서버를 다시 등록할 필요도, tunnel을 재설정할 필요도 없었고 conversation-level tool cache가 핵심이었습니다.** --- ## 28. MCP protocol의 list-change notification도 만능 해결책은 아닙니다 서버 쪽에서는 가능하면: ```text tools.listChanged = true ``` 를 지원하는 것이 좋습니다. MCP specification은 tool list가 변경되었을 때 서버가 `notifications/tools/list_changed`를 보낼 수 있도록 공식 정의하고 있습니다. 그러나 이것을: > “이걸 구현하면 Web ChatGPT의 tool schema가 자동 갱신된다.” 라고 가정하면 안 됩니다. 정확한 의미는: > **MCP client가 변경 사실을 감지할 수 있는 protocol mechanism이 있다.** 입니다. ChatGPT가: ```text MCP notification ↓ workspace approved snapshot ↓ conversation definitions ``` 각 단계를 어떻게 관리하는지는 별개의 제품 정책입니다. 그리고 OpenAI의 frozen-snapshot 정책 때문에 서버가 임의로 새로운 action을 자동 활성화하지 않는 쪽이 오히려 자연스럽습니다. --- ## 29. 여러 custom MCP를 사용한다면 저는 공통 운영 계약을 이렇게 만들겠습니다 각 MCP에 최소한: ```json { "server_version": "1.5.0", "tool_schema_version": 11, "tool_schema_fingerprint": "sha256:...", "build_sha": "e9032b..." } ``` 를 노출합니다. 그리고 변경 전에 분류합니다. ```text RUNTIME CONTRACT IDENTITY ``` 배포 후에는 다음 순서로 검증합니다. ```text 1. MCP server version 확인 2. tool_schema_version 확인 3. public endpoint connectivity 확인 4. fresh ChatGPT conversation 생성 5. 실제 노출된 tool signature 확인 6. previewOnly/read-only named-tool 호출 7. schema가 stale하면 registration-level 문제로 분류 8. 현재 UI에 refresh가 없다면 MCP 재등록 9. 다시 fresh chat 10. 실제 named-tool 재검증 ``` 이렇게 하면 “일단 터널 껐다 켜 보기”에 의존하지 않아도 됩니다. --- ## 30. 가장 중요한 운영 원칙 앞으로는 세 문장만 기억해도 상당 부분 정리됩니다. **첫째, 서버 version과 ChatGPT가 알고 있는 tool schema는 같은 것이 아닙니다.** **둘째, ChatGPT의 MCP 등록 snapshot과 개별 채팅의 tool-definition snapshot도 같은 것이 아닙니다.** **셋째, OpenAI 공식 문서의 UI 절차와 현재 Business Web ChatGPT의 실제 UI도 같은 것이라고 가정하면 안 됩니다.** 따라서 실전에서는: ```text 공식 문서에 Scan Tools가 적혀 있다 ``` 보다: ```text 내 Business UI에 실제로 그 기능이 있는가? ``` 가 더 중요합니다. 현재 환경에는 없으므로 저는 앞으로 이 문제를 설명할 때: > `Scan Tools를 실행한다` 가 아니라 > **“ChatGPT 쪽 registration-level tool discovery를 새로 만들어야 하며, 현재 Business UI에서 별도 refresh/rescan 수단이 없다면 MCP를 재등록한다.”** 라고 표현하는 것이 정확하다고 봅니다. 그리고 이 관점으로 보면 “어떤 때는 터널 재시작만으로 되고, 어떤 때는 재등록해야 한다”는 현상도 일관되게 설명됩니다. ```text 터널 restart = transport/session 계층 재설정 새 chat = conversation tool-definition 계층 재설정 MCP 재등록 = ChatGPT app registration/tool-snapshot 계층 재설정 ``` **서로 완전히 다른 캐시와 상태를 초기화하는 작업**이기 때문에, 변경 종류에 따라 필요한 조치가 달라지는 것입니다.