클로드 8월 잦은 장애, 업무 멈춤 줄이는 법

8월에만 몇 번 멈췄나

8월 24일 오후, 클로드가 약 3시간 동안 흔들렸다. 앤트로픽 상태 페이지 기준으로 오후 1시 50분부터 4시 36분까지 오퍼스5, 페이블5 등 여러 모델에서 요청 오류가 났고, 클로드 웹과 API, 클로드 코드, 코워크가 함께 영향을 받았다. 앤트로픽은 이번 장애의 구체적 원인은 공개하지 않았다.

문제는 이번이 처음이 아니라는 점이다. 상태 페이지 이력을 보면 8월에만 6일, 7일, 14일, 16일, 18일, 19일, 20일, 24일 등 여러 날짜에 장애나 성능 저하가 기록됐다. 16일에는 인증과 성능 문제로 여러 서비스가 영향을 받았고, 18일에는 여러 모델 가운데 오퍼스5의 영향 시간이 상대적으로 길었다.

90일 가동률로 보면 대부분 서비스가 99% 초반대다. 숫자만 보면 높아 보이지만, 99.3%는 90일 중 약 15시간이 정상이 아니었다는 뜻이다. 업무 시간에 그 시간이 몰리면 체감은 수치보다 훨씬 크다.

서비스	90일 가동률
claude.ai	99.33%
Claude Code	99.35%
Claude API	99.43%
Claude Cowork	99.44%

장애는 한 종류가 아니다

Photo by Luke Chesser on Unsplash

대응을 정하려면 먼저 장애의 종류를 구분해야 한다. 8월 기록을 보면 크게 세 가지다.

첫째는 접속·인증 장애다. 로그인이 안 되거나 서비스 자체가 열리지 않는 경우다. 이때는 개별 대화나 모델을 바꿔도 소용이 없고, 복구를 기다리는 것 외에 할 수 있는 일이 적다.

둘째는 특정 모델 오류다. 8월 24일처럼 "요청에 오류가 늘어난" 형태로, 오퍼스5나 페이블5 같은 일부 모델에서만 응답이 실패한다. 이 경우는 정상 작동하는 다른 모델로 옮기면 작업을 이어갈 수 있다.

셋째는 성능 저하다. 접속은 되는데 느려지거나 응답 품질이 평소 같지 않은 상태다. 8월 20일 사례가 여기에 가깝다. 눈에 잘 안 띄어서, 장애인지 내 문제인지 헷갈리기 쉽다.

업무 중단을 줄이는 습관

원인은 사용자가 통제할 수 없다. 통제할 수 있는 건 장애가 났을 때의 손실 크기다.

가장 기본은 중간 저장이다. 클로드 코드처럼 오래 걸리는 작업은 결과가 한 번에 날아가면 타격이 크다. 긴 작업을 잘게 나누고, 중요한 산출물은 별도 파일이나 저장소에 그때그때 남겨두면 복구 부담이 줄어든다.

다음은 대체 경로 확보다. 같은 일을 처리할 수 있는 다른 도구를 미리 한두 개 정해두는 것이다. 다른 계열의 대형 언어모델이나 로컬 편집기, 오프라인에서 진행 가능한 작업을 구분해두면 접속 장애 때도 손을 놓지 않는다.

마감이 걸린 작업이라면 한 서비스에 전부 의존하지 않는 편이 현실적이다. 반대로 시간 여유가 있는 작업은 장애가 지나갈 때까지 기다리는 편이 오히려 효율적일 수 있다.

장애가 의심될 때 확인 순서

응답이 이상할 때 원인을 혼자 추측하기보다, 순서대로 확인하는 편이 빠르다.

• 먼저 status.claude.com에 접속해 현재 상태와 진행 중인 장애가 있는지 본다.
• 전체가 아니라 특정 서비스나 모델만 문제인지 컴포넌트별 표시를 확인한다.
• 모델 문제라면 정상인 다른 모델로 바꿔 같은 작업을 시도한다.
• 접속 자체가 안 되면 복구를 기다리되, 상태 페이지의 이메일·Slack 알림을 구독해두면 복구 시점을 놓치지 않는다.

현재 상태 페이지는 "모든 시스템 정상"으로 표시돼 있다. 다만 8월의 기록이 보여주듯 이 표시는 언제든 바뀔 수 있고, 원인이 항상 공개되지도 않는다. 준비의 요령은 원인을 맞히는 게 아니라, 멈춰도 잃을 게 적도록 평소 작업 방식을 바꿔두는 데 있다.

출처

1. 클로드 장애 3시간여 만에 복구…미토스5·페이블5 영향
2. Claude 서비스 상태 페이지
3. 클로드 장애 8월 잇따라 발생, 개발 작업 중단…지금 확인할 것