9월 25일부터 26일 오후까지 ChatGPT를 쓰면서 여러 가지가 한꺼번에 달라진 느낌을 받았다. UI도 바뀌었고, 예전에 되던 동작이 안 보이기도 하고, 모델 선택이나 Work 쪽도 묘하게 달라졌다.

처음에는 그냥 내 계정에 새 UI가 들어온 정도로 생각했는데 Reddit과 디시인사이드를 찾아보니 비슷한 이야기가 상당히 많이 나오고 있었다. 특히 이번에는 공식 릴리스 노트에 적힌 변경점보다 사용자들이 실제 화면에서 발견한 변화가 훨씬 많다는 점이 눈에 띄었다.

그리고 나한테는 하나가 더 있었다.

MCP 자체에는 별 불만이 없었다. 내가 사용하는 MCP 서버나 local workflow가 갑자기 이상해진 것도 아니었다. 문제는 어제오늘 들어 OpenAI의 보안·안전 판정에 의해 tool call이 실행되기 전에 차단되는 일이 너무 자주 생겼다는 것이다. 더 답답한 건 똑같은 작업인데 어떤 때는 허용되고, 어떤 때는 차단된다는 점이었다.

그래서 이번에는 2026년 9월 25일부터 26일 오후까지 나온 Reddit, 디시인사이드, OpenAI Developer Community 글과 공식 문서를 같이 훑어봤다. 누가 맞고 틀린지를 판정하기보다는 실제로 어떤 변화와 불만이 반복해서 나오고 있는지를 모으는 쪽으로 정리했다.

짧은 기간에 UI, 모델, 서비스 상태와 보안 차단 변화가 한꺼번에 겹친 ChatGPT 사용 경험을 표현한 편집 일러스트

공식 릴리스 노트보다 실제 체감 변화가 훨씬 많았음

OpenAI의 ChatGPT 공식 릴리스 노트를 보면 9월 25일 항목으로 명시된 주요 변화는 Security history다.

설정의 Security and login에서 최근 로그인·로그아웃, MFA, 패스키와 보안 설정 변경 이력을 볼 수 있게 됐다.

그런데 실제 커뮤니티에서 25~26일 이야기하는 것은 이 정도가 아니다.

Reddit과 디시에서는 사이드바, 설정 화면, 글꼴, 아이콘 위치, 긴 대화 탐색, 임시 채팅 저장, 모델 선택 방식, Work, Codex, 이미지 생성, 사용량 리셋까지 여러 부분이 동시에 바뀌었다는 이야기가 계속 나왔다.

공식 릴리스 노트만 보고서는 지금 사용자들이 왜 갑자기 불편하다고 하는지 전부 이해하기 어려운 상태였다.

새 UI는 호불호가 크게 갈림

9월 25일 r/ChatGPT에는 New ChatGPT Update Sucks라는 글이 올라왔다.

작성자가 적은 불편은 꽤 구체적이었다.

  • 가운데 클릭으로 채팅을 새 탭에서 여는 동작이 사라졌다는 것
  • 아이콘 위치가 바뀌거나 점 세 개 메뉴 안으로 들어갔다는 것
  • Temporary Chat을 일반 채팅으로 저장하던 기능이 안 보인다는 것
  • 긴 채팅에서 멈춤이 생긴다는 것
  • 새 사이드바와 설정 메뉴가 불편하다는 것
  • 긴 대화에서 사용하던 navigation ladder와 버전 이동 방식이 달라졌다는 것
  • Project에서 ZIP 파일을 컨텍스트로 쓰던 흐름이 깨졌다는 것

별도의 UI 불만 글에서는 긴 대화를 탐색하던 기능이 깨지고, 그걸 보완하려고 사용하던 Greasemonkey 스크립트까지 새 UI에서 동작하지 않는다고 했다.

디시 챗GPT 갤러리에서도 25일 새벽부터 비슷한 반응이 있었다. 마크다운 표현 방식과 폰트, 전체 UI가 묘하게 달라졌다는 글에서는 가독성이 이전과 다르다는 불만이 나왔다.

반대로 새 UI를 좋아한다는 사람도 분명히 있다.

r/ChatGPT의 New ChatGPT Update? I must say I quite like it! 글은 새 디자인을 마음에 들어 하는 쪽의 반응을 보여준다. Maps가 더 눈에 띄는 기능으로 들어온 점이나, 메시지 안에서 폼이나 표 같은 인터랙티브 요소가 적극적으로 나오는 변화를 좋게 보는 댓글도 있었다.

그래서 새 UI에 대한 반응을 단순히 “다들 싫어한다”로 정리하기는 어렵다.

다만 내가 찾아본 25~26일 글에서는 디자인 자체보다 기존에 손에 익었던 작업 흐름이 갑자기 달라졌다는 불만이 특히 많이 보였다.

같은 ChatGPT 변경을 두고 긍정과 불만 반응이 양쪽으로 갈리는 커뮤니티 분위기를 표현한 편집 일러스트

Temporary Chat 저장 기능은 특히 혼란스러움

이 부분은 변화가 얼마나 빠르게 들어오고 빠지는지 보여주는 사례였다.

9월 13일에는 Reddit에서 Temporary Chat을 일반 채팅으로 저장할 수 있게 됐다는 글이 큰 반응을 얻었다.

그런데 9월 25일에는 새 UI에서 Temporary Chat의 Save 버튼이 사라졌다는 글이 다시 올라왔다. HTML에서도 버튼을 찾을 수 없다는 설명까지 붙었다.

흥미로운 건 OpenAI 도움말에서는 이 기능을 여전히 Temporary Chat을 일반 채팅으로 저장할 수 있는 기능으로 설명하고 있다는 점이다.

즉 적어도 25일 사용자 화면에서는 공식 문서에 존재한다고 적힌 기능과 실제 UI가 일치하지 않는다는 보고가 나온 셈이다.

이게 완전한 기능 삭제인지, 일시적인 UI 버그인지, 계정별 롤아웃 차이인지는 현재 자료만으로 판정하지 않았다.

GPT-6 Sol도 반응이 꽤 많이 갈림

GPT-6 Sol과 Luna는 9월 22일 공개됐다.

OpenAI의 공식 발표에서 강조하는 핵심은 성능뿐 아니라 비용 효율이다. API 가격은 GPT-5.6 Sol과 Luna의 프로모션 가격 대비 각각 크게 낮아졌고, GPT-6 Sol과 Luna는 먼저 ChatGPT Work와 Codex에 제공됐다. 공식 발표 시점에는 일반 Chat에는 아직 제공되지 않는다고 명시돼 있었다.

그런데 25~26일 커뮤니티 반응을 보면 평가 기준이 꽤 다르다.

어떤 사용자는 GPT-6 Sol을 저렴한 일상용 worker로 괜찮게 본다. 반대로 어떤 사용자는 5.6 Sol보다 코딩의 세부사항을 자주 놓치거나, 깊게 생각하는 느낌이 줄었다고 말한다.

9월 25일 r/OpenAI의 Sol 6 is like Opus 5 토론에서도 가격 대비 성능을 장점으로 보는 쪽과, 결과물 자체가 이전보다 마음에 들지 않는다는 쪽이 같이 나왔다.

26일에는 r/ChatGPT에 7월이 ChatGPT의 정점이었던 것 같다는 취지의 글도 올라왔다. Plus 사용 제한, 5.6 Sol과 6 Sol의 체감 차이, Work 모델 사용 경험이 한꺼번에 언급됐다.

디시에서도 26일 오후 5.6 Sol Max가 사라진 것 같다는 글이 올라오는 등, 새 모델 자체보다 기존 5.6 Sol 선택지가 어떻게 바뀌는지를 신경 쓰는 반응이 계속 보였다.

나는 여기서 모델 우열을 정하지 않았다. 같은 모델도 코딩, 글쓰기, 장기 작업, 빠른 반복 같은 사용 방식에 따라 평가가 꽤 달라지고 있었다.

GPT-6 Astra와 5.6 Sol의 차이를 따로 조사했던 내용은 GPT-6 Astra 성능 분석 글에도 정리해 두었다.

장애와 사용량 문제까지 같이 겹침

이번 이틀의 반응을 더 복잡하게 만드는 게 실제 장애 체감이다.

26일 디시 챗GPT 갤러리 목록을 보면 401 Unauthorized, message stream error, Codex가 멈췄다는 글, Work나 Chat이 안 된다는 글이 여러 시간대에 이어졌다.

오후에도 “지금 지피티 먹통인거 맞지?” 같은 글과 정상적으로 된다는 글이 비슷한 시간대에 함께 나왔다.

사용량 리셋 시간이 달라 보인다는 글도 있었고, 모델마다 reasoning effort 선택지가 이전과 다르다고 느끼는 글도 나왔다.

그래서 25~26일의 불만 중 일부는 UI 변경 때문이고, 일부는 모델 롤아웃 때문이며, 일부는 장애나 사용량 표시 문제와 겹쳐 있을 가능성이 있다.

이 여러 가지가 같은 이틀에 한꺼번에 체감됐다는 게 더 혼란스러운 부분이었다.

내가 더 신경 쓰인 건 MCP가 아니라 그 앞의 보안 차단이었음

여기부터는 내가 이번에 가장 답답했던 부분이다.

MCP 연결 자체는 잘 된다. 읽기나 상태 확인도 된다. 서버 쪽 workflow도 이전과 크게 달라진 것이 없다.

그런데 write나 외부 상태를 바꾸는 작업을 시키면 MCP 서버에 요청이 도착하기도 전에 OpenAI 쪽에서 safety check로 막히는 경우가 갑자기 많아졌다.

그리고 같은 작업을 다시 시도하면 이번에는 되는 경우가 있다.

내가 보기에는 이게 MCP 서버가 거부하는 문제와는 완전히 다르다.

대략 흐름을 단순화하면 이렇다.

ChatGPT → OpenAI의 tool safety/pre-dispatch 판정 → MCP server → 실제 작업

지금 문제가 되는 사례는 두 번째 단계에서 멈춘다.

ChatGPT에서 MCP 서버로 향하는 요청이 서버에 도달하기 전 보안 판정 단계에서 차단되는 흐름을 표현한 편집 다이어그램

9월 25일에 거의 같은 버그 리포트가 올라옴

이 부분을 찾다가 꽤 놀랐다.

9월 25일 OpenAI Developer Community에 ChatGPT safety layer blocks valid MCP tool calls라는 버그 리포트가 올라왔다.

환경은 Custom MCP connector와 GPT-5.6 Sol이었다.

작성자는 9월 23일경부터 이전에는 잘 되던 평범한 write operation이 ChatGPT에서 차단되기 시작했다고 적었다.

검색, 읽기, 진단 같은 read-only 작업은 정상적으로 되는데 다음과 같은 write가 실행 전에 막힌다는 내용이었다.

  • 기존 entity 업데이트
  • entity 생성
  • 링크 추가·수정
  • 일반적인 catalog mutation

중요한 건 해당 connector가 이미 Allow all actions / full access로 설정돼 있었다는 점이다.

더 중요한 건 차단된 write가 MCP 서버 로그에 아예 나타나지 않았다는 것이다.

연결을 끊었다 다시 붙이거나, 새 대화를 만들거나, 권한을 다시 주거나, 서로 다른 무해한 write를 테스트해도 같은 문제가 재현됐다고 한다.

내가 어제오늘 겪은 현상과 구조가 굉장히 비슷하다.

이런 현상은 이번에 처음 나온 것도 아니었음

조금 더 찾아보니 7월에도 같은 계열의 보고가 있었다.

OpenAI Developer Community의 MCP tool call safety block 스레드에서는 심지어 읽기 전용 비행기 검색 tool이 MCP 서버에 도착하기 전에 차단된 사례가 보고됐다.

작성자는 tool을 read-only로 설정했고 실제로 예약, 수정, 삭제를 전혀 하지 않는 검색 기능이라고 설명했다. 그래도 OpenAI safety check에서 막혔다.

이후 다른 개발자들도 비슷한 간헐적 차단을 보고했다.

그리고 이건 단순 커뮤니티 추측만 있었던 게 아니다.

8월 5일 OpenAI Support는 같은 스레드에서 일부 정상적인 read-only app action이 MCP 서버에 도달하기 전에 safety check에 의해 잘못 차단되는 문제를 확인했고 개선을 배포했다고 답했다.

8월 16일에도 개선을 배포했지만 일부 요청은 여전히 영향을 받을 수 있고 조사를 계속하고 있다는 답변이 올라왔다.

따라서 정상적인 tool call이 safety layer에서 오탐으로 막힐 수 있다는 현상 자체는 이미 OpenAI가 인정한 전력이 있다.

다만 9월 25~26일에 내가 체감한 빈도 증가가 정확히 같은 원인 때문인지는 별개의 문제다.

제일 이상한 건 같은 요청이 되기도 하고 안 되기도 한다는 점

내가 불편했던 핵심은 이거였다.

어떤 작업 자체가 정책상 완전히 금지된 것이라면 항상 차단되는 쪽이 오히려 이해하기 쉽다.

그런데 같은 MCP, 같은 종류의 작업, 사실상 같은 요청인데

차단 → 다시 시도 → 성공

같은 식으로 결과가 달라질 때가 있다.

Reddit에서도 비슷한 경험이 보고된 적이 있다.

r/OpenAI의 GitHub connector와 Custom MCP safety check 관련 글에서는 어떤 file write는 되고 거의 같은 write는 차단된다는 이야기가 나왔다.

댓글의 Google Drive 사용자는 같은 Spreadsheet write를 반복했는데 처음 두 번은 차단되고 세 번째에는 성공했다고 적었다.

9월 중순 OpenAI Developer Community의 Google Drive connector 관련 버그 보고에서도 비슷한 패턴이 나왔다. 같은 문서와 비슷한 호출이 safety block이나 parsing error를 내다가 별다른 변경 없이 재시도했을 때 성공했다는 내용이다.

이런 사례만 놓고 보면 사용자가 느끼는 “랜덤함”은 나 혼자만의 경험은 아니다.

물론 내부 classifier가 실제로 랜덤하게 판정한다고 단정할 수는 없다. OpenAI가 내부 risk signal이나 threshold를 공개하지 않았기 때문이다.

Allow all actions를 켜도 safety layer까지 꺼지는 것은 아님

이 부분은 공식 문서에서 확인할 수 있다.

OpenAI의 Developer mode and MCP apps in ChatGPT 문서는 write 또는 modify action에서 ChatGPT가

  • app permission
  • action의 context
  • action의 potential impact

등을 기준으로 confirmation을 요구할 수 있다고 설명한다.

그리고 특히 위험하다고 판정된 일부 action은 사용자에게 승인 버튼을 보여주는 대신 바로 차단될 수 있다고 적혀 있다.

즉

Allow all actions = OpenAI safety layer 비활성화

가 아니다.

Allow all actions를 줘도 그 뒤에 별도의 safety 판정이 남아 있다.

이전에 Custom MCP 승인창을 줄이는 방법을 정리하면서도 이 차이를 다뤘다.

그때는 주로 App permissions와 승인창을 어떻게 줄이느냐가 관심사였다면, 이번에 체감한 문제는 승인을 이미 해둔 정상 작업까지 실행 전에 차단되는 현상이라는 점에서 다르다.

같은 tool call이라도 대화 맥락까지 같이 보는 구조일 가능성

공식 문서에 나오는 표현 중 눈에 띄는 것이 action’s context다.

이 말 그대로라면 safety 판정이 단순히 tool 이름 하나만 보는 구조는 아니다.

예를 들어 내부적으로 다음과 같은 정보가 함께 고려될 가능성을 생각해볼 수 있다.

  • tool definition
  • tool arguments
  • 현재 대화 맥락
  • 직전에 수행한 action
  • 외부 상태를 실제로 변경하는지
  • 되돌리기 어려운 작업인지
  • open-world 시스템에 영향을 주는지
  • 다른 safety/security signal

하지만 여기부터는 어디까지나 가능한 구조를 설명하는 것이다.

OpenAI는 정확히 어떤 신호를 어떤 비중으로 평가하는지 공개하지 않았다.

그래서 “동일 JSON이면 왜 같은 결과가 안 나오느냐”는 질문에 현재 공개 자료만으로 정확한 답을 만들 수는 없다.

실제로 커뮤니티에서는 특정 대화에서 한 번 차단된 뒤 후속 호출까지 영향을 받는 것 같다는 사용자 가설도 있고, 반대로 새 대화를 만들어도 계속 막혔다는 9월 25일 사례도 있다.

한 가지 원인으로 전부 설명하기는 어렵다.

tool metadata와 description도 영향을 줄 수 있다는 경험담

Custom MCP 개발자들 사이에서는 tool metadata와 description을 더 정확하게 쓴 뒤 차단이 줄었다는 경험담도 있다.

예를 들어 실제로 파괴적이지 않은 draft 작업이라면 description에

  • delete하지 않음
  • publish하지 않음
  • 외부 recipient에게 보내지 않음

같은 실제 동작 범위를 명확히 적고, MCP annotation도 실제 동작에 맞게 선언하는 방식이다.

반대로 승인이나 safety check를 줄이려고 위험한 write tool을 거짓으로 read-only라고 표시하는 것은 맞지 않는다.

그리고 metadata를 정확하게 작성해도 차단이 완전히 사라졌다는 공통 결론이 나온 것은 아니다.

이미 read-only annotation을 정확하게 넣었는데도 오탐이 발생한 사례가 있기 때문이다.

최근 추가된 cyber·bio 추가 안전 검사와는 구분해서 봐야 함

최근 OpenAI는 별도로 Additional safety checks for biological and cybersecurity requests 문서를 업데이트했다.

일부 cyber·bio 요청에는 추가 automated safeguard가 동작해서 응답이 평소보다 오래 걸릴 수 있고, 안전하게 제공할 수 있다고 판단되면 계속 진행하며 그렇지 않으면 결과를 보여주지 않을 수 있다는 내용이다.

OpenAI는 추가 검사 메시지가 떴다는 것 자체가 사용자가 Usage Policies를 위반했다고 판정됐다는 뜻은 아니라고도 명시한다.

다만 이것과 MCP tool call의 pre-dispatch safety block을 같은 시스템이라고 볼 근거는 없다.

현재 공개 정보로는

  1. ChatGPT/Codex/API의 cyber·bio 추가 safety check
  2. MCP/App action의 tool-call safety/confirmation layer

를 구분해서 보는 편이 맞다.

9월 23~26일에 실제로 safety threshold가 바뀐 것인지는 확인되지 않음

여기서는 선을 그어야 한다.

확인되는 사실은 다음과 같다.

  • 9월 25일 신규 MCP 버그 리포트가 올라왔다.
  • 작성자는 9월 23일경부터 정상 write가 갑자기 차단되기 시작했다고 했다.
  • 같은 connector에서 read는 되고 write는 MCP 서버에 도착하기 전에 막혔다.
  • 과거에도 같은 종류의 false safety block이 있었고 OpenAI Support가 이를 인정했다.

반면 확인되지 않은 것은 다음이다.

  • OpenAI가 9월 23~25일 MCP safety classifier의 threshold를 실제로 강화했는지
  • 특정 새 모델 배포와 이 문제가 직접 연결돼 있는지
  • 새 UI rollout과 safety block 증가가 같은 배포에 포함돼 있는지
  • 같은 요청이 허용됐다가 차단되는 정확한 내부 원인이 무엇인지

9월 25일 공식 ChatGPT 릴리스 노트에는 Security history가 추가됐다는 내용은 있지만 MCP safety policy를 강화했다는 항목은 없다.

그래서 “OpenAI가 어제 보안 정책을 강화해서 전부 막히기 시작했다”라고 단정할 근거는 아직 없다.

하지만 “9월 23일경부터 이전에 잘 되던 정상 MCP write가 OpenAI safety layer에서 갑자기 차단되기 시작했다는 신규 보고가 있고, 과거 동일 계열 오탐을 OpenAI가 공식적으로 인정한 적이 있다”까지는 확인할 수 있었다.

지금 내가 체감한 문제를 한 문장으로 정리하면

내 경우에는 MCP 자체가 불안정해서 작업이 실패하는 느낌은 아니었다.

오히려 MCP에 도착하기 전 단계에서 ChatGPT가 tool call을 허용할지 말지를 결정하는 부분이 이전보다 훨씬 자주 개입하고, 그 결과가 일관적이지 않게 느껴지는 것이 가장 불편했다.

서버 로그에 호출 자체가 없다면 MCP 쪽에서 고칠 것도 없다.

더구나 같은 정상 작업을 다시 요청했을 때 이번에는 성공한다면 사용자 입장에서는 무엇을 바꿔야 하는지도 알기 어렵다.

현재 커뮤니티에서 가장 많이 요구하는 것도 비슷하다.

단순히 “safety check에서 막혔다”가 아니라

  • 어떤 tool definition이 문제였는지
  • 어떤 argument가 문제였는지
  • action type 때문인지
  • 대화 맥락 때문인지
  • 왜 MCP server에 보내기 전에 차단했는지

최소한의 진단 정보를 보여달라는 요구다.

9월 25~26일 변경을 같이 보면 더 혼란스러운 이유

이틀치 반응을 한꺼번에 놓고 보면 단순히 모델 하나가 바뀐 사건이 아니다.

  • 새 UI와 사이드바
  • Temporary Chat 저장 버튼 혼란
  • 긴 대화 navigation 변화
  • 모델 선택과 reasoning effort 체감 변화
  • GPT-6 Sol과 5.6 Sol 비교
  • Work·Codex 동작
  • 사용량과 리셋 시간
  • 서비스 장애
  • 이미지 생성 체감
  • MCP/App safety block

이런 것들이 거의 같은 시기에 같이 이야기되고 있다.

공식 릴리스 노트에 하나의 대형 업데이트로 정리돼 있는 변화가 아니라, 사용자 입장에서는 여러 rollout과 서비스 상태 변화가 한꺼번에 겹친 것처럼 보인다.

그래서 지금 커뮤니티 반응의 핵심은 “새 기능이 많아졌다”라기보다 어제까지 알던 ChatGPT의 사용법과 동작 규칙이 짧은 기간에 너무 많이 달라진 것 같다는 쪽에 더 가깝게 느껴진다.

이번 조사에서 참고한 주요 자료

이번 글은 2026년 9월 25일~26일의 커뮤니티 반응을 중심으로 보고, 안전 차단 문제는 과거 동일 사례까지 거슬러 올라가 확인했다.

커뮤니티 게시물은 통제된 실험이 아니라 사용자 경험담이다. 추천·조회·댓글 수는 계속 변하고, 계정·요금제·롤아웃 시점에 따라 실제 화면도 다를 수 있다.

그래서 이 글에서도 “커뮤니티가 이렇게 말했다”와 “OpenAI 공식 문서가 이렇게 설명한다”를 가능한 한 분리했다.

지금 시점에서 내가 가장 궁금한 것은 새 UI보다 오히려 정상적인 MCP write가 왜 어떤 때는 통과하고 어떤 때는 safety layer에서 잘리는지, 그리고 이게 9월 23일 전후의 변화와 실제로 연결돼 있는지다.

적어도 지금까지 찾은 자료를 보면 비슷한 현상을 겪는 사용자가 나 혼자만은 아니었다.