클로드·깃허브 동시 장애, 529 오류와 상태 페이지 읽는 법

깃허브 장애 제보 뒤 클로드 CLI가 529를 뱉었다

8월 24일, 방에서는 배포 작업 중 깃허브 서버가 말썽이라는 제보가 먼저 올라왔다. 곧이어 클로드 CLI에서 529 오류가 난다는 질문이 이어졌다. 누군가 상태 페이지 링크를 공유하면서 확인이 이어졌다. 깃허브는 8월 한 달에만 6일과 10일, 11일, 17일, 24일 등 여러 날에 크고 작은 장애를 냈다. 그중 17일은 이슈·PR·API·액션·코파일럿까지 7시간 47분 동안 오류율이 최고 20%(아카이브 다운로드는 50%)까지 치솟은 대형 장애였다. 앤트로픽 쪽은 같은 시기 8월 24일 05시06분 UTC에 미토스5·페이블5·오퍼스5·오퍼스4.8에 걸친 오류 증가를 인지했다고 상태 페이지에 올렸다. 원인 파악까지 21분, 완전 정상화까지는 그보다 훨씬 오래 걸렸다.

두 회사가 같은 주에 흔들린 셈이다. 배포 파이프라인이 깃허브와 클로드 코드 양쪽에 걸쳐 있는 팀이라면 이번 주 체감 장애가 유독 잦았을 만하다.

529는 어떤 오류이고 상태 페이지는 무엇을 보여주나

클로드 API 문서는 529를 overloaded_error로 정의한다. 계정별 요청 한도를 넘겨 나는 429 rate_limit_error와 달리, 529는 앤트로픽 추론 서버 전체가 트래픽을 감당하지 못해 새 요청을 일시적으로 거절한다는 뜻이다. 방금 전까지 잘 돌던 코드가 아무것도 바꾸지 않았는데 갑자기 529를 뱉을 수 있는 이유가 여기 있다. 문제는 사용자 쪽 코드가 아니라 서버 용량이다. 지수 백오프로 재시도하거나 잠시 기다리는 것 말고는 사용자가 할 수 있는 일이 많지 않다.

status.claude.com은 클로드닷ai, 클로드 콘솔, API(api.anthropic.com), 클로드 코드, 클로드 코워크, 클로드 포 거번먼트를 따로따로 추적한다. 챗 앱과 API는 별도 구성요소로 추적되며, 챗은 멀쩡한데 API만 장애를 겪거나 그 반대인 경우가 있다. 인시던트 상태는 조사 중·원인 파악·모니터링·해결·포스트모템 순으로 갱신된다. 영향도는 없음·경미·주요·심각 네 단계로 나뉜다. 방에서 공유된 상태 페이지 링크는 웹훅과 RSS·Atom 피드도 지원한다. 매번 페이지를 새로고침하는 대신 구독해 두면 장애 시작과 해결을 알림으로 받을 수 있다.

8월 한 달 동안 반복된 패턴

8월 24일 장애는 고립된 사건이 아니다. 앤트로픽은 5일, 12일, 13일, 16일, 18일, 20일, 24일 등 여러 날에 걸쳐 장애를 냈다. StatusGator 집계로는 올해 1월 이후 클로드 관련 인시던트가 잇따랐다. 테크타임스는 8월 5일 장애를 "164번째"로 세면서, 공교롭게도 360억 달러 규모의 추가 칩 파이낸싱 논의가 보도된 다음 날 벌어졌다고 짚었다. 다리오 아모데이 CEO는 회사가 컴퓨트 제약 상태라고 여러 차례 밝혀왔다. 투자 약정과 실제 배치된 서버 용량 사이에 시차가 있다. 클로드 수요가 빠르게 늘면서 인프라가 압박받고 있다는 설명이다.

같은 주 안에서도 지역과 계정에 따라 체감이 갈렸다는 방의 보고는 이 구조와 맞아떨어진다. 한국·일본·베트남 사용자가 서로 다른 정도로 영향을 받았다는 이야기가 나왔다. 상태 페이지가 구성요소를 세분화해 추적하는 이유와 같은 맥락이다. 상태 페이지가 구성요소별 상태를 따로 표시하므로, 같은 시각에도 서비스별 상태가 다를 수 있다.

이 격차는 상용과 정부용 사이에서 더 극단적으로 드러난다. 테크타임스 8월 24일 보도에 따르면 상용 클로드는 최근 30일 동안 28차례 장애를 겪은 반면, 팔란티어의 연방 클라우드에서 FedRAMP High 인증을 받아 운영되는 클로드 포 거번먼트는 최근 90일 구간 가동률 100%를 기록했다. 별도의 FedRAMP High 승인 환경에서 운영된다는 차이가 있다.

장애 중 방에서 나온 대응, 그리고 실제로 걸어둘 수 있는 안전장치

장애가 길어지자 방에서는 코덱스 실행, 다른 작업으로 전환, 키로 같은 대체 도구 사용이 언급됐다. 실사용자들 사이에서도 비슷한 흐름이 자주 보인다. 클로드 코드 하나에만 파이프라인을 걸어둔 팀일수록 장애 때마다 작업이 통째로 멈춘다. 그 경험이 반복되면 커서·코덱스 CLI·클라인처럼 다른 모델로도 돌릴 수 있는 도구를 병행하자는 의견으로 이어지는 편이다. 다만 앤트로픽 모델에만 있는 워크플로를 옮기는 데 드는 비용과, 완전히 새 도구로 갈아타는 번거로움 사이에서 다들 결정을 미루고 있다는 반응도 함께 나온다.

수동으로 도구를 바꾸는 것보다 먼저 걸어둘 수 있는 장치가 클로드 코드 자체에 있다. 2.1.166 버전부터 정식 지원되는 fallbackModel 설정은 settings.json에 다음처럼 최대 세 개까지 백업 모델을 순서대로 지정해 둘 수 있다.

{"fallbackModel": ["claude-sonnet-5", "claude-haiku-4-5"]}

기본 모델이 과부하·사용 불가 상태이거나 다른 비재시도성 서버 오류를 반환하면 클로드 코드가 지정된 순서대로 다음 모델을 시도한다. 전환이 일어났다는 알림도 띄운다. 단 이 전환은 해당 턴 한 번에만 적용된다. 다음 메시지부터는 다시 기본 모델을 먼저 시도하며, 인증·결제·요청 한도·요청 크기·전송 오류에는 작동하지 않는다. 헤드리스 세션에서만 되던 --fallback-model 플래그도 2.1.166부터 대화형 세션에 적용됐다. 1인 개발자나 소규모 팀 입장에서는 게이트웨이 단에서 여러 공급사를 라우팅하는 구성까지 가지 않아도, 이 설정과 상태 페이지 구독으로 장애에 대비할 수 있다.

컴퓨트 투자와 실제 배치 용량 사이의 시차가 좁혀지기 전까지는 이런 장애가 8월처럼 며칠 간격으로 반복될 가능성이 높다. fallbackModel 하나로 모든 장애를 피할 수는 없지만, 529가 뜬 순간 코드를 의심하는 대신 상태 페이지부터 열어보는 습관과 백업 모델 체인 정도는 지금 걸어둘 수 있는 최소한의 대비다.