개요
OpenAI가 2026년 6월 5일 오후, 일부 사용자 계정을 시스템 오류로 잘못 정지시키는 사고를 냈다. 상태 페이지의 인시던트 보고에 따르면 오후 1시 26분 조사가 시작됐고, 2시 52분에 원인이 특정됐으며, 3시 19분에 완화 조치가 적용되고 4시 9분에 영향받은 사용자의 서비스가 복원됐다. 구독 정보와 크레딧을 정리하는 후속 작업은 다음 날 새벽 6시 16분에 마무리됐다. 다운타임 자체는 짧았지만, AI 제품을 일상 작업의 일부로 끌어들인 사용자 입장에서 보면 “내 ChatGPT 계정이 갑자기 잠기는” 사건이 어떤 모습으로 나타나는지를 그대로 보여준 사례다.
핵심 요약
- OpenAI는 시스템 이슈로 일부 사용자 계정이 잘못된 기준으로 정지되는 사고를 겪었고, 상태 페이지에 인시던트(ejj40mae)로 정식 기록했다.
- 타임라인은 6월 5일 오후 1시 26분 조사 시작 → 2시 20분 이슈 확인 → 2시 52분 원인 식별 → 3시 19분 완화 조치 → 4시 9분 서비스 복원 순으로 진행됐다.
- 계정 접근 복원까지 걸린 시간은 약 2시간 43분이고, 구독·크레딧 정리 등 후처리는 다음 날 새벽 6시 16분에 최종 종료됐다.
- 원인은 일부 사용자 계정을 잘못 정지(incorrectly suspended)시킨 내부 이슈로 공식 정리됐고, 영향받은 사용자에게는 계정·구독 관련 안내 이메일이 별도 발송됐다.
- 상태 페이지 상으로 별도 컴포넌트가 영향 표시되지 않은 점, 그리고 가용성이 집계 수준으로 보고된다는 안내가 함께 명시됐다는 점도 함께 봐 둘 디테일이다.
6월 5일 오후, 약 3시간 동안 일어난 일
사고는 6월 5일 금요일 오후에 OpenAI 내부 모니터링과 사용자 제보가 겹치며 가시화됐다. 오후 1시 26분, OpenAI는 “일부 사용자가 OpenAI 계정 접근에 문제를 겪을 수 있다"는 인시던트를 열고 조사를 시작했다. 약 한 시간 뒤인 2시 20분에는 문제가 재현되고 영향 범위가 확인됐고, 2시 52분에는 “일부 사용자 계정이 잘못 정지된 이슈"라는 원인이 특정됐다.
원인이 잡힌 뒤 OpenAI는 곧바로 완화 조치를 준비했고, 3시 19분에 완화가 적용됐다. 그로부터 약 50분 뒤인 4시 9분, 영향받은 사용자에 대한 서비스가 복원됐다. 즉, “계정에 접근할 수 없는 상태"가 명시적으로 지속된 시간은 약 2시간 43분 구간이었던 셈이다.
다만 인시던트는 이 시점에 완전히 닫히지 않았다. 잘못 정지가 일어난 동안 영향을 받은 구독 상태나 크레딧을 다시 정리하는 작업이 남아 있었기 때문이다. 최종 해결(resolved) 시점은 토요일 6월 6일 새벽 6시 16분으로 기록됐고, 그 사이 영향받은 사용자에게는 계정과 구독 정보를 다시 확인할 수 있도록 이메일 안내가 발송됐다.
짧은 사고가 무겁게 읽히는 이유
상태 페이지의 표면적인 영향만 보면 이번 사고는 “특정 사용자 일부의 일시적 접근 차단"으로 가볍게 분류할 수도 있다. 실제로 인시던트 페이지에는 “공식적으로 영향 표시된 컴포넌트가 없다"고 명시돼 있고, 가용성 지표가 집계 수준이라 개인 단위로는 체감과 다를 수 있다는 안내가 함께 붙어 있다.
그럼에도 의미가 작지 않은 이유는 두 가지다. 첫째, 이번 사고가 모델 오류나 응답 품질 저하가 아니라 “계정이 잘못 정지됐다"는 신뢰 영역의 실패였다는 점이다. 계정이 정지되는 순간 사용자는 단순한 응답 실패가 아니라 자신의 데이터·구독·크레딧이 한꺼번에 차단되는 경험을 한다. 다시 풀려나도, “왜 갑자기 차단됐고 다시 차단되지 않으리라는 보장은 어디 있는지"라는 질문이 남는다.
둘째, 이번 인시던트는 약 2시간 43분의 계정 다운타임에 더해, 구독·크레딧 정리가 다음 날 새벽까지 이어졌다는 점에서 “운영자 입장의 사고 종료 시점"과 “사용자 입장의 사고 종료 시점"이 다를 수 있음을 다시 보여준다. AI 제품을 핵심 워크플로에 묶어 둔 팀이라면, 이런 후처리 구간이 자사 서비스로는 어떻게 번역되는지 한 번씩 점검해 둘 만하다.
실무자가 볼 핵심 포인트
SaaS·프로덕트 운영팀이라면 이번 사례를 “AI 모델이 죽는 시나리오"만이 아니라 “AI 벤더 쪽 계정·인증이 죽는 시나리오"로 별도 분리해 두는 것이 좋다. 모델 호출 실패는 폴백 모델로 대응할 수 있지만, 계정 단위가 차단되면 API 키, 결제, 사용량 추적이 한꺼번에 무력화된다. 동일 사용자에 대해 다른 인증·결제 경로가 있는지, 그리고 그 경로가 같은 벤더에 묶여 있지 않은지를 다시 확인해 두자.
SRE·플랫폼 엔지니어에게는 “외부 벤더에서 계정 단위 차단이 일어났을 때” 우리 시스템이 어떤 신호를 잡는지 한 번 더 확인할 거리다. 일반적인 모델 호출 실패 대시보드만으로는 잘못 정지 같은 권한 단의 변화는 늦게 잡히기 쉽다. 인증 실패·결제 실패·구독 만료 신호를 별도 알람으로 끌어내는 편이 안전하다.
커뮤니케이션·CS 담당자라면 이번 OpenAI의 인시던트 표기 방식을 살펴 둘 만하다. 컴포넌트 영향 표시가 없는 사고임에도 별도 인시던트로 등록하고, 타임라인을 분 단위까지 공개하면서, 영향받은 사용자에게 이메일로 후속 안내를 보낸 흐름은 같은 유형의 사고가 자사에서 일어났을 때 메시지 톤을 잡는 좋은 참고가 된다.
AI 제품을 도입한 사용자 본인이라면 이번 사건을 계기로 ChatGPT나 OpenAI 계정 안에 모아 둔 결과물·대화·결제 정보가 외부 백업으로도 남아 있는지 한 번 점검할 때다. 자주 쓰는 대화·문서를 주기적으로 내보내 두고, 결제 영수증과 크레딧 잔량을 별도 위치에 기록해 두는 작은 습관이 다음 사고에서 체감 피해를 크게 줄여 준다.