2026년 10월 20일, Google Cloud 런던 리전의 한 가용 영역에서 거의 8시간 동안 정전이 발생했어요. 닷새 전에는 DeepSeek도 오전 내내 서비스가 중단됐고요. 많은 개발자가 자기 AI 애플리케이션도 다음번에 함께 멈추는 건 아닐지 걱정하고 있어요.
상위 서비스는 언제든 중단될 수 있어요. 모델 API만 호출하는 사람은 서버실을 옮길 필요는 없지만, 서비스를 한 모델에만 맡겨서는 안 돼요.
핵심 가치: 이 글을 읽고 나면 어떤 상황에서 조치해야 하고 어떤 상황에서는 그럴 필요가 없는지 구분할 수 있어요. 또 모델을 위한 대체 경로를 어떻게 마련할지도 알 수 있어요.
이번 주 두 차례 서비스 중단, 각각 무엇이 멈췄나
먼저 Google Cloud부터 살펴볼게요. 2026년 10월 20일 베이징 시간 14:08부터 22:00까지, 런던 리전의 europe-west2-b 가용 영역 한 곳이 전력 공급 문제로 중단됐어요. 총 7시간 52분 동안 이어졌죠. 영향을 받은 것은 해당 가용 영역에 배포된 컴퓨팅, 스토리지, 데이터베이스, 네트워크였어요. 모델 API만 원격으로 호출하는 사람은 이번 사고의 직접적인 영향 범위에 들지 않았어요. 하지만 서비스가 마침 그 영역에서 실행 중이었다면, 그날 오후 백그라운드 작업과 데이터베이스 연결, 외부 API가 모두 멈춰 설 수밖에 없었어요. 미리 대신 처리해 둘 수 있는 일도 아니고요.
다음은 DeepSeek예요. 2026년 10월 15일 베이징 시간 08:11부터 웹사이트, 대화 서비스, V4 Pro와 V4.1 Flash API 일부가 중단됐어요. 공식 상태 페이지에 기록된 중단 시간은 4시간 52분이며, 당일 13:04에 복구됐어요. 차이신과 사우스차이나모닝포스트는 ‘거의 5시간’이라고 보도했지만, 정확한 시간은 공식 기록을 기준으로 보면 돼요. DeepSeek는 이후 10월 8일부터 14일까지의 사용 금액을 크레딧으로 환급했어요. 원인은 공식적으로 발표되지 않았으므로 여기서는 추측하지 않을게요. 사용자 입장에서는 그날 오전에 서비스를 쓸 수 있었는지 여부가 중요해요. 그 이유가 무엇인지는 부차적이고, 두 번째 경로를 마련해 뒀는지가 관건이죠.
그림: DeepSeek이 사용자에게 발송한 서비스 복구 및 보상 안내. 베이징 시간 기준 10월 15일 8시 11분부터 13시 4분까지 API 서비스를 정상적으로 이용할 수 없었어요. 10월 8일부터 14일까지 계정에서 사용한 금액 전액을 크레딧으로 환급하며, 크레딧은 자동으로 지급돼요. API 이용 요금은 크레딧 잔액에서 먼저 차감돼요.
두 사고에서 문제가 된 지점은 같아요. 모델은 그날의 업무 흐름을 구성하는 한 단계예요. API가 끊기면 코드 작성, 자료 검색, 일괄 처리 작업도 그 자리에서 멈춰요. 상위 서비스가 복구될 때까지 기다리다 보면 반나절이 훌쩍 지나가죠. 크레딧 환급은 요금을 보전해 주지만, 중단된 업무까지 되돌려 주진 않아요. 팀에서 그날 번역 작업을 마치거나 평가를 한 차례 돌리고, 출시를 서둘러야 했다면 사후 보상을 받는다고 해서 일이 저절로 끝나는 건 아니에요. 일정은 뒤로 밀리고 다음 날 업무 부담도 커지죠.
| 항목 | 확인된 Google Cloud 사고 내용 |
|---|---|
| 사고 번호 | Xs2XTHzAVC9YnafnPyzj |
| 영향 범위 | europe-west2 리전 내 europe-west2-b 가용 영역 |
| 원인 | 전력 공급 문제. 공식적으로 추가 세부 정보는 공개되지 않음 |
| 시작 시간 | 베이징 시간 2026-10-20 14:08 |
| 종료 시간 | 베이징 시간 2026-10-20 22:00, 총 7시간 52분 |
| 영향 없음 | Looker Studio |
가용 영역과 리전은 어떻게 다를까
‘런던 정전’이라는 말을 보고 런던 전체의 Google Cloud가 멈췄다고 생각하기 쉽지만, 실제로는 그렇지 않아요. 리전(europe-west2)은 Google이 런던에 운영하는 데이터센터 구역 전체라고 보면 돼요. 가용 영역(europe-west2-a, b, c)은 그 안에 서로 분리된 여러 데이터센터예요. 한 곳에 문제가 생겨도 다른 곳이 버틸 수 있도록 각 영역은 전원과 네트워크를 독립적으로 구성하도록 설계돼 있어요. 이번에는 세 곳 중 한 곳만 전원이 끊겼고, 나머지 두 곳은 정상적으로 운영됐어요.
따라서 실제 피해를 본 곳은 서비스를 b 영역에만 둔 팀이에요. 서비스가 a와 c 영역에도 분산돼 있었다면 트래픽을 정상 운영 중인 영역으로 돌려 피해를 줄일 수 있었어요. 모델 API만 원격으로 호출하는 사람은 이번 정전으로 거의 영향을 받지 않았고요.
두 차례 서비스 중단을 비교해 보면
| 비교 항목 | Google Cloud 런던 | DeepSeek |
|---|---|---|
| 시간(베이징 시간) | 2026-10-20 14:08~22:00 | 2026-10-15 08:11~13:04 |
| 중단 시간 | 7시간 52분 | 4시간 52분 |
| 중단된 서비스 | europe-west2-b의 컴퓨팅, 스토리지, 데이터베이스, 네트워크 | 웹사이트, 대화 서비스, V4 Pro 및 V4.1 Flash API |
| 원인 | 전력 공급 문제. 추가 세부 정보는 공개되지 않음 | 공식 발표 없음 |
| 사후 조치 | 가능하다면 다른 가용 영역이나 리전으로 이전하라고 권고 | 10월 8일부터 14일까지의 사용 금액을 크레딧으로 환급 |
| 모델 API만 호출하는 사람 | 직접적인 영향 범위에 들지 않음 | 직접적인 영향 대상. 대체 경로가 없다면 기다릴 수밖에 없음 |
두 사고를 나란히 놓고 보면 차이가 분명해요. Google Cloud 사고는 b 영역에 서버를 둔 사람들이 영향을 받았고, 해결책은 여러 가용 영역에 분산 배포하는 거예요. DeepSeek 사고는 한 모델만 연결한 사람들이 영향을 받았고, 해결책은 미리 대체 모델을 정해 두는 거죠. 앞의 문제는 데이터센터에 관한 것이고, 뒤의 문제는 모델 호출에 관한 거예요. 아래에서는 두 번째 경우를 다룰게요.
이번 장애에서 얻은 교훈
한 곳은 언제든 장애가 날 수 있으니, 미리 두 번째, 세 번째 대안을 마련해 두세요. 가능하면 서로 다른 업체를 선택하는 게 좋습니다. 같은 업체의 저렴한 요금제로 바꾸는 건 대안이 아니에요. 업체 전체에 문제가 생기면 두 요금제가 함께 중단될 수 있습니다.
전환 시점도 중요해요. 429, 500, 502, 503, 504 오류와 타임아웃이 발생했을 때만 다른 모델로 전환하세요. 상대 서비스가 일시적으로 요청을 처리하지 못하는 상황이라, 다른 모델로 바꾸면 성공할 가능성이 있습니다. 401, 403 오류나 콘텐츠 안전 정책에 따른 거부가 발생했을 때는 전환하지 마세요. API 키나 콘텐츠 자체의 문제이므로 모델을 열 개 바꿔도 똑같이 거부됩니다. 그리고 한 가지 더 구분해야 해요. 장애가 발생한 가용 영역에 직접 배포한 데이터베이스나 스토리지는 모델을 바꿔도 복구되지 않습니다. 가용 영역 간 배포를 검토해야 해요. 모델 장애 대비책과 데이터센터 재해 복구는 서로 다른 문제이니 혼동하지 마세요.
대체 경로를 마련한 뒤에는 장애가 끝났다고 해도 제거하지 마세요. 평소에는 추가 요청을 발생시키지 않고, 주 모델이 한 번에 성공하면 사용되지 않아요. 하지만 다음 장애가 발생하면 자동으로 작동하므로 한밤중에 일어나 코드를 수정할 필요가 없습니다. 설정을 시작하기 전에 각 모델에 가장 간단한 요청을 하나씩 보내 모델 이름을 정확히 입력했는지, 정상적으로 응답하는지 확인하세요. 그런 다음 모델을 어떻게 연결할지 고민하면 됩니다. 모델마다 응답 스타일이 다를 수 있으므로 출력 형식이 중요한 서비스라면 system 프롬프트에 형식을 명확히 지정해 모델 전환에 따른 차이를 줄이세요.
대체 경로 설정은 어떻게 정할까요?
‘실패하면 전환한다’는 것만으로는 충분하지 않아요. 너무 빨리 전환해도, 너무 늦게 전환해도 문제가 생길 수 있습니다. 자주 묻는 설정 몇 가지를 정리했어요. 정해진 답은 없으니 서비스 상황에 맞게 적용하면 됩니다.
| 설정 | 권장 사항 | 이유 |
|---|---|---|
| 같은 모델에 몇 번 재시도할까요? | 최대 1회, 그래도 실패하면 다음 모델로 전환 | 상위 서비스에 장애가 났을 때 같은 모델로 계속 재시도하면 대기열에 한 번 더 들어가는 데 그칠 수 있어요. |
| 요청당 얼마나 기다릴까요? | 대화형 서비스는 짧게, 긴 글 생성은 길게 | 너무 오래 기다리면 사용자는 전환되기도 전에 페이지를 닫을 수 있어요. |
| 429가 발생하면 어떻게 할까요? | 1~2초 정도 기다린 뒤 전환 | 일시적인 트래픽 급증으로 인한 제한일 수 있어요. 잠시 지나면 해결되기도 합니다. |
| 전체 요청 처리 시간은 얼마나 허용할까요? | 세 모델을 모두 합쳐 사용자가 기다릴 수 있는 시간을 넘지 않도록 설정 | 세 모델 모두 느릴 때 요청이 계속 대기 상태로 남는 것을 방지해요. |
| 어떤 로그를 기록할까요? | 어떤 모델이 성공하거나 실패했는지, 오류 코드가 무엇인지 기록 | 나중에 어느 업체에 문제가 있었는지 확인하고 전환 순서를 조정할 수 있어요. |
| 언제 알림을 보낼까요? | 대체 모델 사용 비율이 갑자기 높아질 때 | 대체 경로가 작동하면 사용자도 팀도 문제를 알아차리지 못할 수 있어요. 주 모델에 문제가 생겼다는 사실을 누군가는 알아야 합니다. |
마지막 항목은 가장 쉽게 놓치는 부분이에요. 대체 경로가 잘 작동할수록 주 모델에 문제가 생겨도 조용히 넘어갑니다. 로그를 확인하는 사람이 없다면 주 모델이 하루 내내 중단됐는데도 모두가 정상이라고 생각할 수 있어요. 하지만 청구서에는 대체 모델 호출이 잔뜩 쌓여 있겠죠.
모델을 바꿔도 API 키는 그대로
장애 대비에서 가장 부담스러운 건 큰 규모의 개편이에요. 모델마다 계정을 따로 만들고, 주소를 바꾸고, 요청 형식까지 수정해야 한다면 대부분의 팀은 다음에 문제가 생길 때까지 미루게 되죠.
APIYI에서는 같은 주소 https://api.apiyi.com/v1/chat/completions와 같은 API 키를 사용하고, 요청 본문에서 model만 바꾸면 돼요. 주 모델로 claude-opus-5-5를 사용하다 실패하면 claude-sonnet-5-5로, 다시 실패하면 gemini-4-argon으로 전환하는 식이에요. 앞의 두 모델은 같은 업체의 제품이고 세 번째는 다른 업체의 모델이라, 한 업체에 문제가 생겨도 대안이 있어요. 수정 범위도 작아요. 비즈니스 코드에 순서대로 시도할 모델 이름 목록만 추가하면 되죠. 요청 형식과 인증 방식, 반환 구조는 그대로라 테스트하기도 간단해요.
| 순서 | 모델 이름 | 입력 가격 | 출력 가격 | 역할 |
|---|---|---|---|---|
| 1 | claude-opus-5-5 | 4 | 20 | 주 모델 |
| 2 | claude-sonnet-5-5 | 2 | 10 | 첫 번째 대체 모델, 같은 업체의 저렴한 모델 |
| 3 | gemini-4-argon | 2 | 10 | 두 번째 대체 모델, 다른 업체 |
| 교체 가능 | gpt-6-astra | 10 | 50 | 더 비싼 대체 모델, OpenAI 인터페이스만 사용 |
| 교체 가능 | deepseek-v4.1-flash | 0.30 | 1.20 | 저렴한 대체 모델 |
위 표의 가격 단위는 달러/토큰 100만 개이며, 2026-10-21 가격 페이지의 배율 1을 기준으로 정리했어요. 가격은 변경될 수 있으니 api.apiyi.com 가격 페이지를 확인하세요.
세 단계로 장애 대비 설정하기
1단계, API 키 발급하기. api.apiyi.com에 가입해 API 키를 만드세요. 사용량만큼 과금되고, 중국 내에서 직접 연결할 수 있으며 해외 신용카드를 등록할 필요도 없어요. 이 API 키 하나로 표에 있는 모든 모델을 호출할 수 있어요.
2단계, 모델을 하나씩 테스트하기. 인터페이스 주소에 https://api.apiyi.com/v1을 입력하세요. OpenAI 인터페이스 형식과 호환되므로, 기존에 OpenAI 공식 라이브러리로 작성한 코드도 주소와 API 키만 바꾸면 사용할 수 있어요. 같은 프롬프트로 claude-opus-5-5, claude-sonnet-5-5, gemini-4-argon을 각각 호출해 정상적으로 응답하는지, 형식이 예상과 일치하는지 확인하세요.
3단계, 순서를 정한 뒤 장애 상황을 재현하기. 세 모델의 이름을 설정에 순서대로 입력하고, 앞 절의 규칙에 따라 언제 전환할지 정하세요. 설정을 마쳤다고 바로 배포하지 말고, 먼저 주 모델의 대기 시간을 일시적으로 짧게 설정해 일부러 시간 초과가 발생하게 해보세요. 요청이 두 번째 모델로 넘어가는지, 로그에 전환 내역이 남는지 확인하면 돼요. 테스트를 통과해야 비로소 대체 경로를 제대로 마련한 거예요. 자세한 매개변수는 docs.apiyi.com의 연동 문서를 확인하세요.
업무 유형별 모델 순서 정하기
이 글에서 기본으로 제안하는 순서는 품질을 우선한 설정이지, 유일한 정답은 아니에요. 업무에 따라 첫 번째 모델은 달라질 수 있어요.
| 업무 유형 | 권장 순서 | 이유 |
|---|---|---|
| 코드 작성, 복잡한 추론 | claude-opus-5-5 → claude-sonnet-5-5 → gemini-4-argon | 품질 우선. 이 글의 기본 순서예요. |
| 고객 지원, 일상 대화 | claude-sonnet-5-5 → gemini-4-argon → deepseek-v4.1-flash | 호출량이 많고 단가에 민감하므로 주 모델을 가장 비싼 모델로 할 필요가 없어요. |
| 대량 번역, 요약 | deepseek-v4.1-flash → gemini-4-argon → claude-sonnet-5-5 | 호출량이 많으니 저렴한 모델을 먼저 쓰고, 실패하면 더 나은 모델로 넘어가요. |
| 출력 형식이 중요한 업무 | 같은 업체의 두 모델을 앞에, 다른 업체 모델을 마지막에 배치 | 같은 업체의 모델은 보통 답변 스타일이 비슷해 전환했을 때 차이가 적어요. |
순서를 정할 때는 두 가지만 기억하세요. 마지막 모델은 가능하면 다른 업체 제품으로 선택하고, 단가는 해당 업무의 가치에 맞추면 돼요. 대량 번역 사례를 보면 장애 대비의 효과도 알 수 있어요. 10월 15일에 첫 번째 모델인 DeepSeek가 중단됐다면, 요청이 뒤에 배치한 두 업체의 모델로 자동 전환되어 작업을 계속 처리했을 거예요.
분명히 짚고 넘어갈 점은, 모델 전환은 ‘모델 호출이 중단되지 않게’ 해줄 뿐 데이터센터 정전까지 해결해주지는 않는다는 거예요.
업스트림은 중단될 수 있어요. 다른 경로를 미리 마련하세요
공개된 사례로는 2026년 10월 15일 DeepSeek 공식 장애가 있어요. 당시 APIYI는 볼케이노 엔진의 풀버전 채널로 전환했고, 모델명을 바꾸지 않아도 프로덕션 환경이 정상화됐어요. 자세한 내용은 docs.apiyi.com 실시간 업데이트에서 확인할 수 있어요.
업스트림 서비스는 중단될 수 있어요. 누구의 잘못이라고 할 수는 없죠. 몇 시간 동안 손 놓고 기다리는 것보다 대체 경로를 미리 마련해두는 편이 나아요. 평소에는 비용도 인력도 거의 들지 않고, 장애가 발생하기 전에 준비만 해두면 돼요. 장애가 난 뒤에 시작하면 발만 동동 구르면서 코드를 수정해야 하죠.
장애가 발생한 날, 먼저 확인할 곳
요청이 갑자기 대규모로 실패한다면 코드를 바로 수정하지 말고, 2분만 들여 세 곳을 확인하세요. 첫째, 데이터센터 차원의 문제인지 Google Cloud Service Health를 살펴보세요. 둘째, 해당 모델 업체의 공식 상태 페이지를 확인하세요. 이번 사례라면 DeepSeek 상태 페이지예요. 셋째, docs.apiyi.com의 실시간 업데이트를 확인하세요. APIYI의 업스트림 경로에 변경이 있으면 여기에 안내돼요.
세 곳 모두 정상이라면 그다음에 직접 운영 환경을 확인하세요. API 키가 만료되지 않았는지, 잔액이 충분한지, 네트워크 출구와 DNS에 문제가 없는지 살펴보면 돼요. 순서를 거꾸로 하면 자기 코드만 한참 들여다보다가 결국 업스트림 문제였다는 걸 뒤늦게 알게 될 수 있어요.
오늘 바로 할 수 있는 네 가지
- 서비스에서 모델을 호출하는 곳을 모두 찾아 어떤 곳이 한 업체 모델만 연결되어 있는지 확인하세요.
- 한 업체 모델만 연결된 곳마다 다른 업체의 대체 모델을 하나 이상 추가하세요.
- 앞서 설명한 규칙에 따라 429, 5xx, 시간 초과일 때만 모델을 전환하고, 전환할 때마다 로그에 기록하세요.
- 주 모델이 시간 초과되도록 일부러 한 번 설정해 요청이 실제로 대체 모델로 넘어가는지 확인하세요.
이 네 가지를 마치면 다음에 데이터센터 정전이나 모델 업체의 서비스 중단이 발생하더라도 애플리케이션이 몇 초 느려질 뿐, 반나절 동안 멈추지는 않을 거예요.
자주 묻는 질문
Q1: Google Cloud 런던 데이터센터가 정전된 뒤 바로 런던을 떠나야 하나요?
꼭 그렇지는 않아요. 공식 권고는 ‘가능하다면’이지 모두 즉시 이전하라는 뜻은 아니에요. europe-west2-b에서 워크로드를 운영하는 팀은 다른 가용 영역이나 리전으로 이전할 수 있는지 검토해보세요. 모델 API만 호출하는 팀은 이전할 필요 없이 모델 장애 대비 설정부터 마련하면 돼요.
Q2: 모델을 바꾸면 비용이 더 많이 드나요?
위 순서대로라면 오히려 저렴해요. 주 모델인 claude-opus-5-5의 입력 가격은 4, 출력 가격은 20이고, 두 대체 모델은 입력 2, 출력 10이에요. 입력 10, 출력 50인 gpt-6-astra 같은 모델을 대체 모델 목록에 넣어야 비용이 올라가요.
Q3: API 키 하나로 여러 업체의 모델을 모두 호출할 수 있나요?
네. 이 모델들은 모두 같은 OpenAI 호환 주소를 사용하므로 API 키는 하나면 되고, `model`만 바꾸면 돼요. 단, gpt-6-astra는 OpenAI 인터페이스만 사용하니 호출할 때 참고하세요.
Q4: 대체 모델로 전환하면 답변 품질이 떨어지지 않나요?
차이가 날 수 있어요. 특히 가장 강력한 모델에서 저렴한 모델로 바꾸면 더 그렇죠. 그래도 대부분의 업무에서는 오류가 나는 것보다 조금 느리고 답변이 약간 아쉬운 편이 나아요. 출력 형식이 중요한 업무라면 system 프롬프트에 출력 형식을 명확히 지정하세요. 또 2단계에서 설명한 방법으로 여러 모델의 결과를 미리 비교해보고, 차이를 파악한 뒤 배포하면 돼요.
Q5: 평소에 장애가 없더라도 대체 모델을 준비해두면 비용이 더 드나요?
아니요. 사용량 기반 과금은 실제로 요청을 보낸 경우에만 발생해요. 주 모델이 한 번에 성공하면 대체 모델은 호출되지 않으므로 비용도 들지 않아요. 실제로 필요한 건 연동에 드는 약간의 시간과 테스트할 때 실행하는 몇 번의 요청뿐이에요.
핵심 요점 Key Takeaways
- 두 차례의 중단: Google Cloud europe-west2-b에서 7시간 52분간 정전이 발생했고, DeepSeek는 공식 기록상 4시간 52분간 중단됐어요.
- 사실관계: 유럽 전체가 중단된 것은 아니며, 모델 자체도 이로 인해 서비스가 중단된 것은 아니에요. DeepSeek는 원인을 공개하지 않았어요.
- 전환 조건: 429, 500, 502, 503, 504 오류와 시간 초과일 때만 전환하세요. 401, 403, 콘텐츠 안전 정책에 따른 거부는 전환하지 않아요.
- 방법: 가능하면 다른 업체의 모델을 대체 모델로 준비하세요. 같은 주소와 API 키를 사용하고
model만 바꾸면 돼요. - 검증: 설정을 마친 뒤 주 모델에서 일부러 시간 초과를 한 번 발생시켜 요청이 대체 모델로 넘어가는지, 로그에 기록되는지 확인하세요.
크레딧 보상으로 청구 금액은 메울 수 있어도 중단된 업무까지 되돌릴 수는 없어요. 모델 순서를 미리 정해두면 다음에 업스트림 문제가 생겨도 사용자는 몇 초 느려졌다고 느끼는 데 그칠 거예요.
참고 자료
- Google Cloud Service Health: europe-west2 여러 서비스 장애(Xs2XTHzAVC9YnafnPyzj), 2026-10-20
- Google Cloud Service Health: Google SecOps europe-west2 보안 제품 장애(별도 기록), 2026-10-20
- BBC: Google Cloud 장애로 영국 은행과 공공 서비스가 영향을 받았다는 보도, 2026-10-20
- DeepSeek 공식 상태 페이지: 2026-10-15 서비스 중단 기록
- 공식 문서: docs.apiyi.com 실시간 업데이트
작성자: APIYI 기술팀
기술 관련 소통: 모델 장애 대비 설정 중 문제가 생기면 댓글로 의견을 나눠주세요.
