ChatGPT와 Claude와 Grok이 같은 시각에 멈췄다: 공급자를 늘려도 안 걸리는 구간

9월 3일 미국 동부 시간 오전, Downdetector 그래프 세 개가 같은 모양으로 솟았다. OpenAI의 ChatGPT, Anthropic의 Claude, xAI의 Grok이 함께 내려갔다. 개별 서비스 장애는 흔하다. 세 곳이 같은 시각에 흔들리는 건 흔하지 않다.

Anthropic 상태 페이지 기록으로 보면 조사 시작이 동부 시간 오전 9시 41분경이었고, 수정 배포가 UTC 16시 23분, 영향 종료가 UTC 16시 16분이다. 영향을 받은 모델은 Claude Mythos 5.1, Fable 5.1, Opus 5이고 사용자들은 529 Overloaded를 받았다. 서버 쪽이 포화됐다는 신호다.

OpenAI 쪽은 ChatGPT와 Codex 전반의 오류율 상승으로 기록됐다. 대화만 안 된 게 아니라 로그인, 파일 업로드, 음성 모드, 검색, 딥 리서치, 이미지 생성이 함께 영향권에 들어갔다. Grok은 xAI가 문제를 확인하고 작업 중이라고 공지했다. Google의 Gemini에도 이상 보고가 있었지만 공식 장애 공지는 안 나왔다.

한 줄 정리

주요 AI 서비스 세 곳이 같은 오전에 함께 멈췄고 공급자를 여러 곳 붙여 둔 것만으로는 안 막히는 구간이 드러났다.

한눈에 보기

서비스	상태 기록	영향 범위
Claude	오전 9시 41분경 조사 시작, UTC 16시 16분 영향 종료	Mythos 5.1, Fable 5.1, Opus 5, 529 Overloaded
ChatGPT	오류율 상승 공지 후 해소	대화, 로그인, 파일 업로드, 음성, 검색, 딥 리서치, 이미지
Grok	xAI가 이슈 확인	서비스 전반
Gemini	공식 공지 없음	이상 보고만 접수

원인은 아직 어느 회사도 공식으로 밝히지 않았다. 같은 날 Microsoft Azure에도 장애가 있었고 일부 매체가 연결 가능성을 제기했다. 세 회사 중 어디도 이를 확인해 주지 않았다. 추정을 사실로 옮겨 적을 자리는 아니다.

갈아타기가 안 되는 층이 따로 있다

"한 곳이 죽으면 다른 곳으로 넘긴다"는 대비책은 모델 호출에만 통한다. 어제 흔들린 건 그 아래층이었다. ChatGPT 쪽에서 로그인과 파일 업로드가 같이 막힌 게 그 증거다. 브라우저 앱에 파일을 올려 쓰던 방식이면 대체 모델 API 키를 열 장 갖고 있어도 그 순간엔 못 쓴다.

여기서 팀마다 피해가 갈린다. 대화형으로 쓰던 사람은 커피를 마시고 돌아오면 된다. 세 시간은 짜증나지만 복구된다. 반대로 정해진 시각에 도는 무인 작업은 그냥 실패한다. 오전 8시에 초안을 만들어 놓기로 한 잡, 매시 정각에 문의를 분류하는 잡, 밤사이 재고를 정리하는 잡. 아무도 안 보는 사이에 그날 몫이 비고, 다음 날 아침에야 빈 자리가 보인다.

529는 "다시 걸어라"가 아니다

Claude 쪽에서 나온 529 Overloaded는 서버가 지금 감당이 안 된다는 신호다. 이 상황에서 흔한 실수가 즉시 재시도다. 실패하면 바로 다시 걸고 또 실패하면 또 거는 루프가 여러 클라이언트에서 동시에 돌면, 회복하려는 서버에 원래보다 많은 요청이 몰린다. 우리 쪽 청구서도 같이 는다.

무인 파이프라인에 재시도를 넣을 거라면 간격을 늘려 가며 몇 번까지만 시도할지, 그다음엔 무엇을 할지를 같이 정해 둬야 한다. 한 시간 넘게 안 되는 장애에서 재시도만으로 넘어가는 경우는 별로 없다.

공급자 수보다 실패 상관관계

멀티 프로바이더 구성은 좋은 습관이다. 다만 어제 같은 사건은 그 습관의 가정을 건드린다. 서로 다른 회사의 서비스가 같은 시각에 흔들린다면 공급자를 셋으로 늘려도 상관관계가 안 떨어진다. 원인이 무엇이었든, 여러 프런티어 서비스가 겹치는 인프라 위에 서 있을 가능성 자체는 남는다.

그래서 대비의 축을 하나 더 잡는 게 맞는다. 지금까지가 "누구에게 요청할까"였다면 두 번째 축은 "지금 못 하면 어떻게 할까"다. 이건 공급자를 늘려서 푸는 문제가 아니다.

두 번째 축에 들어가는 답은 대개 시시하다. 로컬 모델로 품질을 낮춰 계속 돌리기, 다음 슬롯으로 미루기, 그날은 아예 거르고 사람에게 알리기. 셋 다 대단한 엔지니어링이 아니고 조건문 몇 줄이다. 다만 이 셋 중 무엇을 할지 미리 정해 둔 팀이 드물다. 아무것도 안 정하면 코드는 예외를 던지고 로그 한 줄을 남긴 뒤 끝난다.

anyAX 관점

이 사이트의 발행 파이프라인도 매일 오전 7시 45분과 8시에 launchd 잡으로 돈다. 어제 장애가 한국 시간으로 밤에 걸쳤으니 이번엔 안 겹쳤다. 다음번에도 안 겹친다는 보장은 없다.

정지 세 시간에서 실제로 값이 갈리는 건 코드가 아니라 그 코드에 적어 둔 한 줄이다. 실패했을 때 재시도할지, 오늘은 건너뛸지, 사람에게 알릴지. 셋 중 하나를 미리 안 골라 두면 기본값은 조용한 실패다. 조용한 실패가 며칠 쌓이면 파이프라인이 죽은 것과 아무 소식이 없는 것을 구분할 방법이 없어진다.

오늘 할 일은 세 줄짜리 점검이다. 자동으로 도는 작업 목록을 적고, 각각에 대해 API가 세 시간 안 될 때 무엇이 일어나는지 옆에 쓰고, "아무 일도 안 일어난다"고 적힌 줄이 몇 개인지 센다. 이 셈은 15분이면 끝난다. 어제 아침에 그 15분을 이미 써 둔 팀은 자기 잡이 무엇을 했는지 알고, 안 써 둔 팀은 어제 무슨 일이 있었는지도 지금 모른다.