세상은 역시 어딘가 주먹구구로 돌아간다.
평소 AI 업계를 보고 있으면 미래의 문턱에 서 있는 기분이 든다. 모델은 코드를 쓰고 어려운 문제를 푼다. 에이전트는 업무 흐름 전체를 맡겠다고 한다. 인간에게 얼마나 많은 일이 남을지를 두고 벌이는 논의도 갈수록 뜨겁다. 그런데 정작 일을 시키려는 순간, 화면에는 한참을 기다려도 답이 나오지 않는다.
많은 사람이 AI 업계의 기준으로 여기는 DeepSeek조차 결정적인 순간에 삐끗한다.
DeepSeek가 공개한 공지에 따르면 2026년 10월 15일 베이징 시간(UTC+8) 오전 8시 11분부터 오후 1시 4분까지 서비스 시스템에 장애가 발생해 해당 시간 동안 API를 정상적으로 이용할 수 없었다. 공지에 적힌 시작과 종료 시각을 계산하면 4시간 53분, 거의 다섯 시간이다. “반나절이나 먹통이었다”는 말에는 화가 섞여 있겠지만, 오전의 대부분을 허비한 것은 분명하다.[1][2]
DeepSeek 서비스 복구 및 보상 공지. 독자 제공. 공지에 적힌 시각과 보상 조건은 당일 보도와 일치한다.
그저 대화를 나누는 중이었다면 잠시 쉬면 그만이다. 하지만 API가 제품이나 고객 지원, 콘텐츠 처리, 기업 내부 업무에 연결돼 있다면 상위 서비스가 멈출 때 뒤따르는 작업도 기다려야 할 수 있다. 사용자는 당신의 납품을 재촉하고, 고객은 당신의 팀을 찾는다. 평소 모델이 문제를 잘 푼다는 이유로 몇 시간의 공백을 순순히 받아들여 주지는 않는다.
이번 장애가 가장 또렷하게 일깨운 것은 모델의 능력과 서비스의 신뢰성을 따로 평가해야 한다는 점이다.
모델이 문제에 정확히 답할 수 있는가와, 업무에 필요한 순간 그 답을 제때 내놓을 수 있는가는 별개의 문제다. 앞의 질문은 순위표와 발표회에서 쉽게 주목받는다. 뒤의 질문은 대개 사고가 나고 나서야 진지하게 논의된다. 실제로 AI에 의지해 일하는 사람에게는 어느 쪽도 빠질 수 없다.
“결국 주먹구구였나” 하는 탄식은 이런 간극에서 나온다. 눈앞에는 우주를 논하고 프로그램을 쓰는 지능이 있다. 하지만 그것을 떠받치는 것은 고장 날 수 있는 기계와 소프트웨어, 사람이다. 아무리 기술의 후광이 강해도 모니터링과 이중화, 장애 복구라는 구체적인 일을 건너뛸 수는 없다.
그래도 불평은 불평이고, 이번 DeepSeek의 보상은 공정하게 평가할 만하다.
공지에 따르면 DeepSeek는 각 계정의 직전 7일, 즉 10월 8일부터 10월 14일까지의 실제 사용액 전액을 같은 금액의 크레딧으로 돌려준다. 크레딧은 자동 지급되며, 이후 API 요금은 크레딧 잔액에서 우선 차감된다.[1][2]
예를 들어 그 7일 동안 100위안을 쓴 계정이라면 공지의 조건에 따라 100위안의 크레딧을 받게 된다. 장애가 있었던 몇 시간에 해당하는 요금만 보상하는 데 그치지 않고, 직전 일주일의 사용액 전체를 보상의 기준으로 삼았다. 성의 있는 대응이다.
물론 크레딧은 현금 환불과 다르다. 앞으로 7일 동안 원하는 만큼 무제한으로 쓸 수 있다는 뜻도 아니다. 지급액은 정해진 과거 7일간의 실제 사용액에 따라 결정되고, 향후 API 요금을 차감하는 데 쓰인다. 이 점을 정확히 설명한다고 해서 이번 보상을 좋게 평가하는 데 지장이 생기지는 않는다.
책임감 있게 느껴지는 대목은 장애에 대해 명확한 비용을 부담하고, 사용자들이 저마다 증빙을 모아 여러 번 신청하는 수고도 덜어줬다는 것이다. 서비스를 계속 쓸 개발자에게 자동으로 지급되고 곧바로 요금에서 차감되는 방식은 실질적인 가치가 있다.
이 보상의 무게는 회사에 “돈 걱정이 없다”는 꼬리표를 붙이는 데 있지 않다. 사과를 사용자가 실제로 쓸 수 있는 잔액으로 바꿨다는 점이 이번 대응에서 높이 살 부분이다.
그렇다고 보상을 칭찬하면서 장애마저 좋은 일로 포장할 수는 없다.
API 청구서 바깥에는 업무 중단과 납품 지연, 고객 이탈의 위험도 있다. 크레딧이 모든 팀의 손실을 메워주지는 못할 수 있다. 돈은 보전할 수 있어도 잃어버린 시간과 손상된 신뢰를 회복하려면 더 오래 걸린다. DeepSeek는 이번 대응으로 좋은 평가를 받을 만하고, 동시에 안정성에 대한 질문도 계속 받아야 한다.
공지에는 단일 장애점이 되는 의존 관계를 정리하고 분리하겠다는 내용도 있다.[1] 이렇게 강력한 모델을 제공하는 서비스가 무엇에 발목을 잡혔을까? 장애가 시작된 시각은 베이징 시간 오전 8시 11분이다. 이 시각을 보면 확인해볼 만한 가능성 하나가 떠오른다. 밤사이 반영한 변경의 약점이 아침 트래픽 앞에서 드러난 것은 아닐까.
먼저 선을 긋자. DeepSeek는 이 공지에서 기술적 근본 원인을 공개하지 않았다. 밤사이 배포가 있었는지, 아침 트래픽이 뚜렷하게 늘었는지도 로그와 모니터링으로 확인해야 한다. 여기서는 이 한 가지 가능성만 따라가며 어떤 일이 벌어질 수 있는지 살펴보자.
밤사이 공용 서비스 하나를 업데이트했다고 가정해보자. 요청이 모델에 도달하기 전에 API 키와 사용 가능한 잔액을 확인하는 서비스다. 새 버전은 실행되고 검사도 통과한다. 다만 원래 캐시에서 읽던 검사 하나가 매번 데이터베이스에 질의하는 방식으로 바뀌었다. 여기서 말하는 서비스와 변경 내용은 예시이며, DeepSeek의 내부 구현으로 밝혀진 사실이 아니다.
밤에는 요청이 적다. 질의 한 번 더 한다고 별일 없어 보인다. API는 여전히 응답하고, 테스트에도 오류가 없으며, 모니터링 화면은 초록색일 수도 있다. 하지만 시스템의 처리 능력 일부는 이미 조용히 사라졌다.
아침이 되고 사람들이 일을 시작하면 제품의 호출과 백그라운드 작업이 차례로 몰려든다. 마침내 요청이 들어오는 속도가 이 공용 서비스의 처리 속도를 넘어선다. 요청들이 데이터베이스 연결을 기다리며 줄을 서고, 대기 중인 요청이 자원을 더 붙잡으면서 나중에 들어온 요청은 한층 오래 기다려야 한다.
아침 식당에 계산대가 하나만 열린 셈이다. 주방은 음식을 만들 수 있고 요리사도 자리에 있다. 그래도 손님은 모두 같은 계산대를 먼저 거쳐야 한다. 입구가 막히면 뒤에 아무리 큰 주방이 있어도 힘을 쓸 수 없다.
그다음부터 문제는 스스로 불어난다. 호출한 쪽은 결과를 오래 기다리다가 시간 초과로 재시도한다. 일부 하위 제품도 사용자를 대신해 재시도할 수 있다. 앞선 요청이 제때 취소되지 않았다면 이전 일이 끝나기도 전에 새 일이 밀려온다. 실제로 새로 발생한 업무가 폭증하지 않았어도 시스템이 감당하는 요청은 눈덩이처럼 불어날 수 있다.
이때는 버전을 되돌려도 서비스가 곧바로 살아난다는 보장이 없다. 밀린 요청은 남아 있고, 연결 풀은 회복되지 않았으며, 바깥에서는 재시도가 계속 문을 두드린다. 서비스가 겨우 한숨을 돌리면 부하가 다시 짓누른다. 복구하려면 유입량을 제한하고, 무의미한 재시도를 끊고, 기한이 지난 작업을 버린 뒤 트래픽을 조금씩 열어야 할 수 있다. 잘못된 코드를 고치는 일과 시스템을 다시 일으켜 세우는 일은 때로 서로 다른 두 번의 싸움이다.
이 흐름에서는 변경이 문제를 심고, 트래픽이 드러내며, 적체와 재시도가 키운다. 비싼 추론 클러스터가 함께 고장 난 것이 아니라, 그 앞의 좁은 문에 요청이 막혀 있을 수도 있다. 단일 장애점 역시 외따로 놓인 서버 한 대일 필요는 없다. 여러 복제본이 모두 피할 수 없는 하나의 공통 의존 대상일 수 있다.
비슷한 증폭 과정에는 공개된 선례가 있다. Google Cloud의 2025년 6월 사고 분석에는 할당량 정책 데이터가 Service Control의 비정상 종료를 유발한 뒤, 복구 과정에서 재시작이 집중되며 기반 데이터베이스에 부하를 주고 일부 지역의 복구를 늦췄다는 내용이 나온다.[3] 이는 “처음 원인을 고쳐도 시스템의 혼잡은 계속될 수 있다”는 설명에 기술적 근거가 있음을 보여준다. DeepSeek에서도 같은 일이 일어났다고 단정할 증거는 아니다.
이 시나리오를 검증하려면 여러 시간선을 포개야 한다. 장애 전에 무엇을 바꿨는지, 트래픽은 언제 늘었는지, 공용 서비스의 지연과 대기열, 연결 사용량은 언제부터 이상해졌는지, 재시도도 그에 따라 증가했는지, 롤백이나 유입 제한 뒤에는 무슨 일이 생겼는지 확인해야 한다. 이 과정이 시간순으로 맞아떨어져야 추측에도 무게가 실린다. 오전 8시 11분이라는 시각은 질문을 던질 근거일 뿐, 사건을 해결했다고 선언할 근거는 못 된다.
“동종 문제의 재발을 막겠다”는 것은 약속이다. 그 약속이 지켜졌는지는 앞으로의 서비스 기록이 답할 것이다.
이번 일은 AI를 업무에 연결하는 모든 사람에게도 경고를 보낸다. 멈췄을 때 이어갈 길을 준비해야 한다.
중요한 업무라면 상위 모델을 잠시 이용할 수 없을 때 작업을 대기열에 넣을 수 있는지, 검증된 대체 서비스로 전환할 수 있는지, 아니면 사람에게 넘길 수 있는지 미리 생각해둬야 한다. 재시도가 필요하다면 횟수를 제한하고 간격을 점차 늘리며 실행 시점도 분산해야 한다. 상위 서비스의 장애에 기름을 더 부어서는 안 된다. 특히 결제나 메시지 전송, 데이터 변경을 하는 업무는 서비스 복구 뒤 중복 실행을 막는 장치도 필요하다.
이런 준비에는 미래적인 화려함이 별로 없다. 그래도 다음 장애 때 지금의 사업을 지켜줄 수 있다. AI를 진지하게 쓸수록 “이렇게 대단한 회사라면 문제없겠지”라는 기대에 모든 것을 걸어서는 안 된다.
DeepSeek가 거의 다섯 시간 동안 멈춘 것은 충분히 불평할 만하다. 높은 기대를 받는 AI 서비스라면 신뢰성이라는 과제도 제대로 해내야 한다. 직전 7일간의 사용액을 크레딧으로 보상한 것 역시 좋게 평가할 만하다. 문제가 생기면 인정하고, 비용을 부담하고, 꾸준히 안정적인 서비스를 제공하며 신뢰를 되찾는 태도는 격려받아야 한다.
세상은 정말 생각보다 주먹구구인지도 모른다. 우리는 실수를 줄이라고 요구할 이유가 있고, 누군가 책임지려 할 때 “이번 대응은 정직하고 후했다”고 말할 이유도 있다.