Claude는 2026년 9월 22일 여러 모델에서 오류가 증가하는 장애를 겪었습니다. Anthropic의 최종 장애 업데이트에 따르면 영향 시간대는 00:50~02:10 UTC로, 총 80분입니다. 장애는 02:35 UTC에 해결된 것으로 표시됐습니다. 영향이 있었다고 기재된 구성 요소에는 claude.ai, API, Code, Cowork가 포함됩니다. 기록에는 모든 요청이 실패했다고 나와 있지 않으며, 근본 원인에 관한 공개된 설명도 없습니다. Anthropic의 장애 기록
업무 절차 안에서 AI를 사용하는 기업의 경우, 서비스 복구는 문제의 일부만 해결합니다. 고객 요청이 여전히 대기 중일 수 있습니다. 자동 처리 시도가 진행 중인 동안 누군가 수동으로 사례를 처리하기 시작했을 수도 있습니다. 관리자는 어떤 작업을 재개할 수 있고 어떤 작업을 먼저 확인해야 하는지 알아야 합니다.
아이디어를 구상할 때 가끔 도우미를 사용할 수 없는 것은 불편한 일입니다. 하지만 같은 서비스가 접수된 사례를 분류하고, 답변 초안을 작성하고, 기록을 갱신하는 데 쓰인다면 중단은 운영상의 문제가 됩니다. 유용한 대비책은 AI 서비스에 접속하지 않고도 직원들이 따를 수 있는 간단한 연속성 계획입니다.
이 안내서에서는 가상의 고객 서비스 데스크를 통해 그런 계획이 어떻게 작동할 수 있는지 보여 줍니다. 제시하는 절차는 조정하고 연습해 볼 제안이지, BIG CHANGE가 실시한 시험도 이번 장애로 영향을 받은 고객에 관한 설명도 아닙니다.
AI 없이도 유지할 수 있는 서비스를 정하세요
소규모 장비 공급업체에서 도우미가 접수된 고객 지원 메시지를 분류하고 승인된 제품 정보를 바탕으로 답변을 준비한다고 가정해 봅시다. 직원은 보내기 전에 답변을 검토합니다. 답변에 대한 책임은 여전히 사람이 지지만, 업무 대기열을 정리하는 데 이 시스템을 의존합니다.
도우미가 응답을 멈추면 관리자는 고객 서비스 데스크가 무엇을 계속 약속할 수 있는지 먼저 결정해야 합니다. 직원은 접수 확인을 계속 보내고, 기한이 임박한 사례를 처리하는 한편, 일상적인 제품 설명은 미룰 수 있습니다. 도우미를 거치지 않고도 원래 메시지와 승인된 참고 자료를 이용할 수 있어야 합니다. 그렇지 않으면 ‘수동으로 전환하라’는 지시만 있을 뿐, 실제로 실행할 수단은 없습니다.
축소된 서비스를 미리 정해 두세요. 이를 가동할 권한이 있는 사람, 중단할 업무, 나머지 일을 맡을 직원을 지정하세요. 임시 조치를 재평가하는 사람 없이 오후 내내 그대로 두지 않도록 검토 시점도 정하세요. 고객 안내에는 지연과 긴급 지원을 받을 수 있는 경로를 설명하되, 팀이 지킬 수 있는 내용만 약속해야 합니다.
Google의 엔지니어링 지침은 과부하 상황에서 기능을 축소하고, 트래픽을 제한하며, 중요한 요청을 우선 처리하는 방안을 설명합니다. 이는 확립된 신뢰성 기법이지, 이번 Claude 장애의 원인에 대한 진단은 아닙니다. 이를 고객 서비스 데스크에 적용하면 정상 처리를 계속할 수 없을 때 업무 범위를 의도적으로 줄이는 데 도움이 됩니다. Google SRE: 과부하 처리
축소된 서비스에도 처리 용량 한도가 필요합니다. 두 사람이 보통 훨씬 많은 요청을 처리하는 자동화 시스템의 업무를 아무런 논의 없이 떠맡을 수는 없습니다. 처리할 수 있는 양, 대기하게 될 업무, 추가 지원이 필요한 시점을 기록하세요. 정상 서비스가 이어지는 것처럼 보이는 자동 접수 확인보다, 지킬 수 있는 응답 시간 안내가 고객에게 더 도움이 됩니다.
대화 밖에 업무 기록을 남기세요
모델을 사용할 수 없는 동안에도 고객 서비스 데스크가 읽을 수 있는 사례 기록이 필요합니다. 기존 고객 지원 시스템일 수도 있습니다. 중요한 점은 중단된 도우미에게 상황을 재구성해 달라고 요청하지 않고도 기업이 무슨 일이 있었는지 확인할 수 있어야 한다는 것입니다.
각 사례의 원래 요청, 책임자 또는 담당 절차, 마지막으로 확인된 조치를 보존하세요. 저장된 초안과 전송된 답변은 다릅니다. 고객 기록에 제안된 변경과 해당 시스템에서 확인된 변경도 서로 다릅니다. 이를 구분할 증거를 저장하되, 기초가 되는 고객 정보에 적용되는 것과 동일한 접근 제한을 지키세요.
중단 중에는 업무를 다음과 같은 실용적인 범주로 나누세요:
- 시작 전: 처리가 시작되지 않았고 외부 조치도 취해지지 않았습니다.
- 일부 준비됨: 분류나 초안은 있지만 다음 단계는 완료되지 않았습니다.
- 완료 확인: 대상 시스템에 의도한 조치가 기록되어 있습니다.
- 불확실: 조치를 시도했지만 완료 여부를 확인할 수 없습니다.
불확실한 사례는 재개하기 전에 관련 시스템을 확인할 수 있는 사람에게 맡기세요. 연결이 끊겼을 때 도우미가 답변을 준비 중이었다면 초안을 새로 만드는 것은 문제가 없을 수 있습니다. 별도 도구가 답변을 보내고 있었다면 전체 작업을 반복할 때 같은 답변이 두 번 전송될 수 있습니다. 이러한 구분을 업무 기록에 남겨야 합니다.
Anthropic의 API 문서에 따르면 스트리밍 응답은 초기 HTTP 200 성공 응답 뒤에도 실패할 수 있습니다. 첫 문구가 나타났거나 초기 상태 코드가 도착했다는 사실만으로 답변 전체를 받았다고 볼 수 없습니다. 연동 시스템이 완료 여부를 확인하고 일부만 처리된 작업은 부분 완료 상태로 보존하도록 하세요. Claude API 오류 문서
재시도에는 횟수 제한과 담당자를 두세요
재시도는 일시적인 오류를 해결할 수 있습니다. 하지만 각 계층에서 같은 작업을 독립적으로 반복하면 불확실성이 더 오래 이어질 수도 있습니다. 재시도 버튼이나 자동 반복 절차를 추가하기 전에 소프트웨어 공급업체에 클라이언트 라이브러리 내부에서 이미 재시도가 일어나는지 확인하세요.
Anthropic에 따르면 공식 SDK는 일시적 오류에 대해 기본적으로 지연 시간을 늘려 가며 두 번 자동 재시도하고, 제공된 경우 retry-after 지시를 따릅니다. 오류 문서는 일시적인 서버 문제와 인증, 권한, 잘못된 요청으로 인한 실패도 구분합니다. 모든 오류가 같은 요청을 반복하면 해결된다고 가정해서는 안 됩니다. Claude에 문서화된 재시도 동작
고객 서비스 데스크의 운영 규칙에는 자동 시도를 언제 멈추고 그 뒤 사례를 누구에게 전달할지 명시해야 합니다. 문제 해결을 위해 요청 식별자를 보존하세요. 직원이 작업이 대기 중인지, 재시도 중인지, 담당자 확인을 기다리는지 볼 수 있게 해 경쟁하는 시도를 자신도 모르게 시작하지 않도록 하세요.
AWS는 응답이 도착하지 않았더라도 작업 자체는 성공했을 수 있다고 설명합니다. 멱등 API는 명시적 요청 식별자를 사용해 재요청을 알아보고 추가 부작용을 막습니다. 이 계약은 수신 서비스가 이행해야 합니다. 내부 사례 번호만 붙인다고 같은 보호가 생기는 것은 아닙니다. AWS: 안전한 재시도를 위한 멱등 API
업무 흐름에서 수행하는 조치에 관해 구체적으로 질문하세요. 재시도가 지원 티켓을 하나 더 만들거나 이메일을 한 번 더 보낼 수 있나요? 중복 방지 기능이 없다면 재시도 전에 대상 시스템의 기록을 확인해야 합니다. 텍스트 생성을 재시도하는 일과 전체 업무 절차를 반복하는 일은 서로 다른 결정이 필요합니다.
대체 모델에는 더 좁은 역할을 맡기세요
대체 AI 서비스는 업무를 계속 진행하는 데 도움이 될 수 있지만, 계정을 하나 더 만드는 것만으로 대체 수단이 마련되는 것은 아닙니다. 대체 서비스에는 적절한 지침과 승인된 참고 자료, 데이터를 처리할 권한이 필요합니다. 기업이 사용할 때 필요한 용량도 확보되어야 합니다.
완전히 대체하기 전에 범위를 제한한 대체 작업을 정하세요. 가상의 고객 서비스 데스크라면 다른 모델이 일상적인 메시지를 분류하고 직원이 고객에게 보낼 답변을 처리할 수 있습니다. 모호한 제품명이나 담당자에게 넘겨야 하는 요청을 포함해 대표 사례를 통해 평가할 수 있습니다. 답변이 유창하다는 사실만으로 회사의 고객 지원 규칙을 따랐다고 입증되지는 않습니다.
장애가 발생하기 전에 대체 서비스로 보낼 수 있는 정보를 정하세요. 직원이 고객 기록을 개인 계정에 붙여 넣는 식으로 즉흥 대응해서는 안 됩니다. 조달 과정에서 대체 서비스의 데이터 처리 조건과 접근 관리 방식을 확인하고, 결과 품질과 가격도 함께 살피세요.
모델 이름이 다르다는 것만으로 가용성까지 독립적이라고 볼 수는 없습니다. 대체 서비스도 같은 로그인, 네트워크 연결, 문서 저장소, 오케스트레이션 소프트웨어에 의존할 수 있습니다. 제안된 대안이 실제로 어떤 의존성을 피하는지 그려 보세요. 이 과정을 거치면 같은 장애 연결 뒤에 모델을 하나 더 두는 것보다, 접근 가능한 참고 문서와 수동 대기열이 더 유용한 보호책이라는 점이 드러날 수 있습니다.
지침이 바뀌고 제품 지식이 오래되면 대체 수단도 유지 관리가 필요합니다. 직원은 거의 쓰지 않는 절차도 연습해야 합니다. 소규모 기업은 전체 운영을 복제하는 비용을 지불하기보다 더 느린 수동 서비스를 유지하는 편이 합리적일 수 있습니다. 지연된 업무의 비용과 잘못된 답변의 피해를 고려해 선택해야 합니다.
검토한 대기열로 업무를 재개하세요
제공업체가 복구를 알리면 정상 처리를 다시 시작하기 전에 자체 업무 흐름을 소규모로 시험하세요. 문서 조회와 기록 갱신 등 기업에 필요한 기능을 실제로 시험하는 사례를 포함하세요. 모델의 답변이 성공했다고 해서 연결된 모든 시스템이 준비되었다고 볼 수는 없습니다.
그런 다음 대기 중인 업무를 살피세요. 수동으로 이미 처리한 사례를 제거하고, 불확실한 조치를 확인하고, 상황이 달라진 요청을 찾아내세요. 중단 중에 고객이 새 정보를 보냈을 수도 있습니다. 기술 장애가 끝난 뒤 오래된 사례 버전을 바탕으로 답변을 생성하면 새로운 문제가 생길 수 있습니다.
남은 업무는 통제된 묶음으로 처리하세요. 새로 들어오는 긴급 요청을 처리할 여력을 남기고 대기열이 줄고 있는지 살피세요. 새로 시도하는 작업이 모두 성공해도 유입량이 가용 처리 용량을 모두 차지한다면 대기 업무는 계속 쌓입니다. 밀린 업무를 따라잡으려면 추가 인력, 일시적인 서비스 축소, 또는 응답 시간을 현실적으로 연장하는 일이 필요할 수 있습니다.
별도의 수치 예시로, 시간당 24건이 접수되고 처리가 30분간 중단된다고 가정해 봅시다. 그러면 12건이 대기합니다. 이후 데스크가 시간당 36건을 처리하는 동안 시간당 24건이 계속 들어오면, 대기 업무를 모두 처리하는 데 한 시간이 걸립니다. 이는 설명을 위한 가정이지 Claude 장애를 측정한 결과가 아닙니다.
Google의 서비스 수준 목표 지침은 사용자에게 중요한 결과와 이를 제공하는 데 필요한 의존성에서 출발합니다. 이 고객 서비스 데스크의 유용한 지표는 약속한 시간 안에 적절한 답변을 받은 긴급 사례의 비율일 수 있습니다. 제공업체의 가용성도 중요하지만, 기업은 고객이 실제로 서비스를 받았는지도 알아야 합니다. Google SRE: 서비스 수준 목표 구현
정상적인 고객 서비스가 재개된 시각, 해결되지 않은 사례 수, 이후 필요했던 정정 사항을 기록하세요. 이런 지표는 제공업체의 상태 페이지에서 파악할 수 없는 복구 업무를 드러냅니다.
자동화를 확대하기 전에 한 번의 중단 상황을 연습하세요
짧은 탁상 훈련은 실제 고객에게 영향을 주지 않고도 접근 권한이나 책임자 누락을 찾아낼 수 있습니다. 가상의 고객 지원 사례 몇 개를 사용해 다음 순서로 진행하세요:
- 답변을 준비하는 도중 모델을 사용할 수 없게 된다고 가정합니다. 누가 축소 서비스를 가동하며 직원은 원래 요청을 어디서 확인하는지 묻습니다.
- 한 사례는 답변이 전송된 것으로 확인되고 다른 사례는 전송 시도가 불확실하다고 가정합니다. 팀이 어느 시스템에서 결과를 확인할 수 있는지 아는지 살펴보세요.
- 새 사례가 계속 접수되는 동안 제공업체가 복구됐다고 가정합니다. 어떤 업무를 먼저 재개하고 수동으로 완료한 사례를 대기열에서 어떻게 제외할지 결정합니다.
- 계획을 작성하지 않은 사람에게 절차를 설명해 보게 하고, 부족한 권한이나 기록이 무엇인지 확인합니다.
훈련으로 답을 얻지 못한 질문을 적어 두세요. 기존 대기열 접근 권한, 명확한 일시 중지 기능, 저장된 확인 기록, 복구 책임자 지정처럼 작은 수정만으로 해결될 수 있습니다. 그 어떤 것도 서비스 중단이 없음을 보장하지는 않습니다. 각각은 자동화의 이점을 버리지 않으면서 중단을 더 쉽게 통제하도록 도울 수 있습니다.
도우미에게 또 다른 운영 책임을 맡기기 전에 동료에게 장애 중 그 책임을 어떻게 처리할지 설명해 달라고 하세요. 답변이 사용할 수 없는 도우미가 자신이 무엇을 하던 중이었는지 기억하는 데 달려 있다면 연속성 계획에는 아직 보완할 부분이 있습니다.
