티스토리 뷰
목차
어제(9월3일) 밤, 챗GPT·클로드·그록이 한꺼번에 먹통이 됐다는 소식이 해외 매체를 타고 퍼졌다.
오늘 이 블로그의 오늘자 핫키워드 목록에도 챗GPT가 2·3위로 올라와 있었다.
이 블로그는 하루 세 편을 크론이 무인으로 발행한다.
그 세 편을 실제로 써내는 손이 바로 클로드(Claude)다. 그래서 이 소식을 보자마자 제일 먼저 든 생각은 "어제 우리 배치는 괜찮았나"였다.
그날 밤, 세 곳이 순서대로 무너졌다
보도를 종합하면 장애는 한꺼번에 터진 게 아니라 순서가 있었다.
한국시간 기준으로 그록(xAI)이 9월3일 밤 22시30분 무렵 먼저 흔들렸고, 한 시간 뒤인 23시30분 무렵 클로드(Anthropic)에서 오류가 나타났다고 보도됐다.
출처 : 위키트리(wikitree.co.kr)
챗GPT는 가장 늦게, 날짜가 바뀐 9월4일 자정 무렵부터 로그인·이미지 생성·검색 기능까지 함께 먹통이 됐고 다운디텍터에는 관련 신고가 4만 건을 넘었다고 알려졌다.
같은 시간대 구글 제미나이 API에서도 문제가 감지됐다는 보도가 있었다.
미국 쪽 매체는 이 시각을 현지시간 오전 11시 무렵으로 짚었고, 오픈AI는 "오류가 늘고 있다"고, 앤트로픽은 "여러 클로드 모델에서 오류율이 올라갔다"고 각각 공지했다고 전해졌다.
같은 시간대 마이크로소프트 애저 인프라에서도 장애 신고가 있어 연관 가능성이 제기됐지만, 어느 회사도 공식적으로 원인을 확정하지는 않았다.
출처 : Axios(axios.com), Forbes(forbes.com)
우리 로그를 열어봤다
이 블로그의 무인 배치는 그날 어떻게 지나갔을까.
직접 로그를 대조해봤다.
| 시각(KST) | 무슨 일이 있었나 | 확인 상태 |
|---|---|---|
| 9/3 새벽 04시대 | VPS 무인 배치가 그날 글 3편(이슈 1편·구축 2편)을 정상 발행 완료 | 자체 로그(progress.md) |
| 9/3 오전 10:16 | 예정에 없던 재실행 크론이 같은 배치를 재점검 — 이상 없이 완주 상태 재확인 | 자체 로그(progress.md) |
| 9/3 밤 22:30 | 그록(xAI) 장애 시작으로 보도됨 | 위키트리 보도 |
| 9/3 밤 23:30 | 클로드(Anthropic) 장애 시작으로 보도됨 | 위키트리 보도 |
| 9/4 자정 | 챗GPT(OpenAI) 장애 시작, 다운디텍터 신고 4만건 초과로 보도됨 | 위키트리 보도 |
표로 늘어놓고 보니 답이 어느 정도 보인다.
기록에 남은 두 차례 실행(새벽 04시대, 오전 10:16)은 그날 밤 장애가 시작되기 한참 전에 이미 끝나 있었다. 이번엔 장애를 피해간 게 아니라, 애초에 겹칠 시간이 없었던 것에 가깝다.
다만 이건 어디까지나 로그에 남은 두 차례 실행 기준이다.
그날 밤 22시30분부터 자정 사이에 뭔가 추가로 돌았는지는 기록에 남아있지 않아 확인할 수 없었다. 그러니 정확한 이유를 완전히 단정하기는 어렵다 — "시간대가 안 겹쳤을 가능성이 크다" 정도로만 말할 수 있다.
더 중요한 건 따로 있었다
그런데 로그를 대조하다가 다른 게 눈에 들어왔다.
이 자동화 전체를 관리하는 내부 운영 지침에는 이런 문장이 적혀 있다.
VPS에서 이뤄지는 클로드 호출도 (대표) 나와 동일한 구독 한도를 함께 쓴다. 반복되는 파이프라인은 기본적으로 가벼운 모델(하이쿠)을 쓰고, 한도를 넘으면 즉시 멈추고 다시 시도하지 않는다.
이건 원래 장애 대응 규정이 아니다.
사용량 한도를 넘었을 때 어떻게 하느냐를 정한 방침이다. 그런데 곱씹어보니 이 방침 자체가 이 자동화의 진짜 구조를 그대로 드러내고 있었다.
"멈추면 다시 시도하지 않는다"는 건, 바꿔 말하면 이 파이프라인 뒤에 클로드 하나만 서 있고 그 뒤를 받쳐줄 두 번째 프로바이더가 없다는 뜻이다.
한도 초과든 진짜 장애든, 클로드 쪽에서 응답이 끊기는 순간 이 배치는 그냥 멈춘다. 다른 모델로 넘어가는 절차는 없다.
이번엔 시간이 겹치지 않아 운이 좋았던 셈이지만, 다음에도 그러리라는 보장은 없다.
장애가 한 시간만 늦게 시작됐어도, 혹은 새벽 배치 시간이 조금만 늦었어도 이야기는 달라졌을 수 있다.
지금 확인해볼 것
이번 일로 뭔가 거창하게 고쳤다고 말하고 싶지만, 솔직히 아직 손대지 않았다.
지금 확인만 해둔 상태다.
- 내 자동화가 AI API 하나에만 의존하고 있는지 점검했는가
- 장애·한도초과가 났을 때 그걸 알아차릴 알림 장치(텔레그램 등)가 있는가
- 재시도 로직이나 다른 프로바이더로 넘어가는 대체 경로가 있는가, 없다면 없다는 사실 자체를 인지하고 있는가
- 본인 크론 실행 시각과 장애 발생 시각이 겹치는지 로그로 직접 대조해본 적이 있는가
Q. 그럼 이제 다른 AI로 이중화할 계획인가?
아직 결정한 건 없다. 클로드 하나에 의존하는 구조라는 것을 이번에 확인했을 뿐이고, 대체 경로를 실제로 만드는 건 다음 단계 얘기다.
Q. 이번 장애로 이 블로그 발행에 문제가 생겼나?
아니다. 확인 결과 그날 배치 2회(새벽·오전) 모두 이상 없이 완주했고, 그 뒤 시점에 별도 발행 시도가 있었는지는 기록에 없어 확인되지 않는다.
1인이 여러 자동화를 굴리다 보면 이런 식으로 "어? 이거 다 하나에 걸려 있었네"를 뒤늦게 깨닫는 순간이 온다.
오늘은 그 구조적 위험을 고친 날이 아니라, 확인한 날로 기록해둔다.
이 배치가 실제로 어떤 안전장치를 이미 갖추고 어떤 걸 아직 안 갖췄는지는 무인 발행 3중 안전장치 글에, 발행 자체가 API가 아니라 브라우저 자동화로 돌아가는 구조는 티스토리 브라우저 자동화 글에 정리해뒀다. 클로드 API 자체의 비용 구조가 궁금하면 클로드 API 가격 글도 함께 보면 이해가 빠르다.