AWS 15시간 서버 장애, 무엇이 문제였나?
2025년 10월 20일, 인터넷이 멈췄다
2025년 10월 20일 오후 4시 10분, 전 세계 인터넷에 이상 신호가 감지되기 시작했어요. 스냅챗으로 친구에게 메시지를 보내려던 사용자들은 전송 실패 화면을 마주했고, 배틀그라운드에 접속하려던 게이머들은 서버 오류 메시지를 보게 됐죠. 로빈후드와 코인베이스에서 투자 포트폴리오를 확인하려던 사람들은 금융 거래가 중단됐다는 사실을 깨달았습니다.
원인은 하나였어요. 아마존웹서비스(AWS)의 미국 버지니아 북부에 위치한 US-EAST-1 리전에서 발생한 장애였습니다. 이 단일 지점의 오류가 전 세계 1,000개 이상의 서비스를 15시간 동안 마비시켰죠. 국내에서도 삼성월렛에서 간헐적인 결제 오류가 발생했고, 크래프톤의 배틀그라운드 접속이 끊겼으며, 수많은 기업들이 비즈니스 중단이라는 초유의 사태를 겪었습니다. [1]
이 사건은 단순한 기술적 결함이 아니에요. 현대 디지털 사회가 안고 있는 구조적 취약점, 즉 클라우드 중앙집중화의 위험성을 적나라하게 보여준 경고였습니다.
무엇이 문제였나: DNS 오류가 촉발한 도미노 붕괴
DynamoDB DNS 해석 실패의 연쇄반응
장애의 시작은 매우 작은 오류였어요. AWS의 핵심 데이터베이스 서비스인 DynamoDB를 업데이트하는 과정에서 DNS(도메인 네임 시스템) 오류가 발생한 거예요. DNS는 인터넷의 '주소록'과 같은 역할을 하는데, 이게 고장 나면서 DynamoDB API 엔드포인트의 정확한 주소를 찾을 수 없게 됐죠. [2]
"주소를 못 찾으면 다른 서비스를 쓰면 되지 않나요?"라고 생각할 수 있지만, 문제는 그렇게 단순하지 않았어요. US-EAST-1 리전은 AWS에서 가장 오래되고 규모가 큰 데이터센터 허브로, 전 세계 AWS 트래픽의 약 3분의 1이 이곳을 거쳐 가거든요. 많은 글로벌 기업들이 이 리전을 '기본 설정'으로 사용하고 있었던 거죠.
더 심각한 건, DynamoDB가 단순한 데이터베이스가 아니라는 점이에요. AWS의 핵심 제어 시스템인 '컨트롤 플레인'이 이 서비스에 의존하고 있었거든요. DynamoDB가 먹통이 되자, 사용자 인증을 담당하는 IAM(Identity and Access Management), 로깅 시스템, 모니터링 도구까지 연쇄적으로 마비됐습니다. 마치 교통 신호등이 고장 나자 도시 전체의 교통이 마비되는 것과 같은 상황이었어요.
15시간의 복구 과정: 예상보다 긴 지옥
AWS 엔지니어들은 장애 발생 3시간 만에 근본 원인을 파악했어요. 하지만 문제 해결은 그보다 훨씬 오래 걸렸죠. 오전 7시가 되어서야 모든 서비스가 정상으로 돌아왔으니, 총 15시간이 소요된 셈이에요.
왜 이렇게 오래 걸렸을까요? 아이러니하게도, 장애를 모니터링하고 복구 작업을 조율해야 할 '관측 가능성(Observability)' 도구들까지 같은 리전에 있었기 때문이에요. 환자의 상태를 확인해야 하는데 청진기와 체온계마저 고장 난 상황과 같았던 거죠.
LinkedIn의 클라우드 전문가들은 이를 "관측 가능성의 실패"라고 지적했어요. 모니터링 도구조차 같은 클라우드에 의존하는 구조적 모순이 복구 시간을 배로 늘렸다는 거예요.
왜 이렇게 피해가 컸나: '모든 달걀을 한 바구니에' 담은 대가
클라우드 시장의 과도한 집중
2025년 2분기 기준, 전 세계 클라우드 시장은 사실상 세 기업이 장악하고 있어요.
클라우드 제공업체 | 글로벌 점유율 | 한국 점유율 |
|---|---|---|
AWS(아마존) | 30% | 60.1% |
애저(마이크로소프트) | 20% | 24% |
구글 클라우드 | 13% | 19.9% |
주목할 점은 한국의 AWS 의존도가 글로벌 평균의 두 배에 달한다는 거예요. 삼성전자, 현대자동차, 넥슨, 크래프톤 같은 주요 대기업들도 AWS 인프라를 핵심적으로 활용하고 있죠. 이는 한 곳에서 문제가 생기면 국내 디지털 경제 전반이 흔들릴 수 있다는 뜻이에요.
월스트리트저널은 이번 사태를 보도하며 "클라우드 서비스 중단은 드문 일이 아니지만, 더 많은 기업이 클라우드에 의존하게 되면서 그 심각성이 기하급수적으로 커지고 있다"고 지적했어요.
단일 실패 지점(SPOF)의 위험
SPOF(Single Point of Failure, 단일 실패 지점)란, 시스템에서 한 부분이 고장 나면 전체가 멈춰버리는 취약점을 말해요. 이번 AWS 장애는 SPOF의 교과서적인 사례였죠.
현대 클라우드 서비스는 수많은 마이크로서비스들이 복잡하게 연결된 구조예요. EC2 인스턴스가 DynamoDB에 접근하려면 IAM을 통해 인증을 받아야 하고, 로깅을 위해서는 CloudWatch와 연결돼야 하죠. 이런 '서비스 체이닝' 구조에서 DynamoDB라는 핵심 고리가 끊어지자, 물리적으로는 멀쩡한 다른 서비스들까지 논리적으로 접근이 불가능해진 거예요.
더 심각한 건, 글로벌 서비스로 분류되는 IAM이나 DynamoDB 글로벌 테이블 같은 기능들도 내부적으로는 US-EAST-1 엔드포인트에 의존하고 있었다는 점이에요. '리전 격리(Regional Isolation)' 아키텍처가 무력화된 순간이었죠.
어디서 어떻게 먹통이 되었나: 피해 서비스 현황
소비자 서비스: 일상이 멈췄다
이번 장애로 가장 먼저 타격을 받은 건 일상적으로 사용하는 소비자 서비스들이었어요.
스냅챗: 메시지 전송과 스토리 업로드가 불가능해졌어요. 전 세계 수억 명의 사용자들이 소통 창구를 잃었죠.
벤모/로빈후드: 금융 거래가 중단됐어요. 특히 암호화폐 거래소 코인베이스에서는 변동성이 큰 시장 상황에서 매매를 하지 못해 손실을 본 투자자들도 있었어요.
Reddit/Signal: 소셜 미디어와 메신저 앱들이 먹통이 되면서, 사람들은 장애 상황을 알리기 위해 경쟁사 서비스로 몰려들었죠.
Roblox/포트나이트: 게임 로그인이 실패하면서, 주말을 게임으로 즐기려던 수백만 명의 게이머들이 좌절했어요.
디즈니+/HBO Max: 스트리밍 서비스들이 끊임없이 버퍼링을 반복했어요.
기업 서비스: 비즈니스가 멈췄다
소비자 불편을 넘어, 기업 비즈니스에도 직격탄이 떨어졌어요.
유나이티드 항공: 체크인 시스템이 마비되면서, 공항 카운터에 긴 줄이 형성됐어요.
Perplexity AI: AI 검색 서비스가 완전히 중단돼, 사용자들은 대안을 찾아야 했죠.
영국 국세청(HMRC): 정부 서비스까지 영향을 받으면서, 세금 신고나 행정 업무가 멈췄어요.
로이드 은행/핼리팩스: 뱅킹 서비스가 마비되면서, 송금이나 결제가 불가능해졌어요.
국내에서는 삼성월렛이 작동하지 않아 결제가 불가능했고, 크래프톤의 배틀그라운드 접속이 끊기면서 게이머들의 불만이 폭주했죠.
업계 추정에 따르면, 기업들은 다운타임으로 인해 시간당 수백만 달러의 손실을 입었어요. 전자상거래는 분당 약 22만 달러, 대기업은 시간당 100만~500만 달러의 손실이 발생할 수 있다는 분석도 있어요.
보이지 않는 피해: IoT와 스마트 홈
언론에 크게 보도되지 않았지만, 일상 속 IoT 기기들도 영향을 받았어요. Ring 스마트 도어벨이 작동하지 않아 방문객을 확인할 수 없었고, Alexa 음성비서가 응답하지 않아 스마트 홈 제어가 불가능해진 사례도 많았죠.
이는 클라우드에 의존하는 IoT 생태계의 취약성을 여실히 드러낸 순간이었어요. 내 집 안의 기기인데도, 멀리 미국 버지니아의 서버가 멈추면 쓸 수 없게 되는 구조적 모순이 현실화된 거죠.
멀티 클라우드의 대안과 한계
이번 사태 이후, 전문가들은 '멀티 클라우드' 전략을 대안으로 제시하고 있어요. 동일한 데이터를 AWS뿐 아니라 MS 애저, 구글 클라우드 등 여러 곳에 동시에 저장해서, 한 곳이 다운돼도 다른 곳으로 즉시 전환하자는 거죠.
이론적으로는 완벽해요. 하지만 현실은 녹록지 않죠.
멀티 클라우드의 3가지 현실적 장벽:
비용 폭증: 데이터를 여러 클라우드에 중복 저장하고, 클라우드 간 데이터 전송 비용을 부담해야 해요. 기업 입장에서는 클라우드 비용이 2배 이상 증가할 수 있어요.
구현의 복잡성: 각 클라우드 제공업체마다 API와 서비스 구조가 달라요. 이를 통합 관리하려면 전문 인력과 복잡한 오케스트레이션 시스템이 필요하죠.
근본적 한계: 멀티 클라우드를 구축해도, 핵심 데이터베이스나 인증 시스템이 여전히 단일 리전에 의존한다면 의미가 없어요. 이번 장애처럼 컨트롤 플레인이 마비되면 다른 리전으로 전환조차 할 수 없거든요.
한국의 클라우드 보안 전문가 김명주 서울여대 교수는 "멀티 클라우드는 기술적으로 해결하기 어려운 문제이며, 기업 입장에서 비용 증가가 큰 장벽"이라고 지적했어요. [3]
결국 많은 기업들이 멀티 클라우드의 필요성은 알지만, 비용 때문에 실제로 구현하지 못하고 있는 게 현실이에요. 2023년 플렉세라 보고서에 따르면, 클라우드 간 워크로드를 실제로 이동하고 있다고 답한 기업은 37%에 불과했어요.
로컬 LLM과 온디바이스 AI로의 전환
클라우드에서 벗어나는 AI의 흐름
클라우드 중앙집중화의 위험이 현실화되면서, 이제 업계는 근본적인 대안을 모색하고 있어요. 그 중심에 '온디바이스 AI'와 '로컬 LLM'이 있죠.
온디바이스 AI란, 클라우드 서버를 거치지 않고 사용자의 기기(PC, 스마트폰, 엣지 장치) 내부에서 직접 AI 모델을 실행하는 기술이에요. 로컬 LLM은 대규모 언어 모델을 인터넷 연결 없이 로컬 환경에서 구동하는 방식이고요.
왜 이 기술들이 주목받고 있을까요?
온디바이스 AI가 주목받는 3가지 이유:
네트워크 불안정성 극복: AWS 같은 클라우드가 다운돼도, 내 PC나 스마트폰의 AI는 계속 작동해요. 인터넷 연결 자체가 필요 없으니까요.
데이터 주권 확보: 회사의 기밀 문서나 개인 정보가 외부 서버로 전송되지 않아요. 데이터가 내 기기 안에서만 처리되니, 유출 위험이 원천 차단되는 거죠.
반복 비용 절감: 클라우드 AI는 사용할 때마다 API 비용을 지불해야 해요. 하지만 로컬 LLM은 한 번 설치하면 무제한으로 사용할 수 있죠.
실제로 최근 고성능 로컬 LLM 모델들이 속속 등장하고 있어요. LG전자의 엑사원 4.0, 알리바바의 Qwen 3.0, 마이크로소프트의 Phi-3.5, 구글의 Gemma 3 등이 대표적이죠. 이들은 클라우드 기반 LLM에 버금가는 성능을 보이면서도, 일반 PC나 노트북에서도 실행 가능한 경량화를 달성했어요.
오프라인 작동의 결정적 장점
로컬 LLM의 가장 큰 강점은 '오프라인 작동'이에요. 이게 왜 중요할까요?
오프라인 AI의 3가지 핵심 가치:
가치 | 클라우드 AI | 온디바이스/로컬 AI |
|---|---|---|
장애 대응 | AWS 다운 시 전면 중단 | 클라우드 장애와 무관하게 작동 |
보안 | 데이터가 외부 서버로 전송 | 데이터가 기기 내부에서만 처리 |
비용 | 사용량에 따른 반복 과금 | 초기 구축 후 추가 비용 없음 |
특히 보안이 중요한 환경에서는 로컬 AI가 필수예요. 금융권에서 고객 데이터를 분석하거나, 연구 기관에서 미공개 논문을 검토하거나, 기업에서 내부 기밀 문서를 검색할 때, 데이터가 외부로 나가는 순간 유출 위험이 생기거든요.
사내 폐쇄망(인트라넷)만 있는 환경에서도 로컬 AI는 완벽하게 작동해요. 인터넷 연결이 아예 없어도 문제없이 쓸 수 있는 거죠. 이는 국방, 의료, 연구개발 같은 보안이 최우선인 분야에서 엄청난 경쟁력이 돼요.
실제 활용 사례와 효과
"이론은 좋은데, 실제로 쓰이나요?"라는 질문이 나올 수 있어요. 답은 "이미 쓰이고 있고, 효과도 입증됐다"예요.
로컬 LLM 도입 성공 사례:
- 문서 검색 자동화: 한 기업이 사내 기술 문서와 매뉴얼 검색에 로컬 LLM을 도입한 결과, 연간 API 이용료를 90% 절감했어요. AWS DNS 장애가 발생해도 업무에 전혀 지장이 없었죠. [4]
- 연구 기관의 보안 강화: 대학과 연구 기관에서는 민감한 연구 데이터와 미공개 논문을 다루기 위해 로컬 LLM을 검토하고 있어요. 외부 AI 서비스에 업로드할 수 없는 데이터를 안전하게 처리하면서도 AI의 효율을 누릴 수 있기 때문이죠.
- 금융권의 프라이빗 LLM: 케이뱅크는 인터넷 은행 최초로 금융 특화 프라이빗 LLM을 도입했고, KB국민카드와 신한은행도 자체 LLM 플랫폼을 구축했어요. 고객 데이터 보호 규정을 준수하면서도 AI 기반 고객 상담과 데이터 분석이 가능해진 거죠. [5]
흥미로운 건, 최근 경량 LLM 모델들은 고가의 GPU 없이도 일반 노트북에서 실행 가능하다는 점이에요. 과거에는 로컬 LLM을 구축하려면 수천만 원대의 GPU 서버가 필요했지만, 이제는 개인 개발자나 중소기업도 부담 없이 도입할 수 있는 수준이 됐죠.
클라우드 의존에서 벗어날 때
2025년 10월 20일의 AWS 장애는 단순한 기술적 사고가 아니었어요. 이는 현대 디지털 사회가 소수의 클라우드 제공업체에 과도하게 의존하는 구조적 위험을 적나라하게 보여준 경고였죠.
이번 사건이 우리에게 알려준 3가지 진실:
클라우드는 만능이 아니다: 아무리 안정적인 클라우드라도 장애는 발생할 수 있어요. 그리고 그 파급력은 상상 이상이죠.
멀티 클라우드는 만병통치약이 아니다: 이론적으로는 완벽하지만, 비용과 복잡성이라는 현실적 장벽이 있어요.
진짜 대안은 로컬로의 회귀다: 핵심 업무와 민감 데이터는 로컬에서 처리하고, 클라우드는 보조 수단으로 활용하는 하이브리드 전략이 필요해요.
특히 문서 검색, 데이터 분석, 연구 개발 같은 핵심 업무는 로컬 AI로 전환해야 클라우드 장애로부터 자유로워질 수 있어요.
"그런데 어떻게 시작해야 하나요?"라는 질문이 있다면, 로컬독스(Localdocs) 같은 오프라인 AI 문서 검색 솔루션이 좋은 출발점이 될 수 있어요. 로컬독스는 PC에 직접 설치되어 100% 오프라인으로 작동하며, 회사의 PDF 문서나 기술 자료를 인터넷 연결 없이 AI로 검색하고 분석할 수 있죠. AWS가 다운돼도, 인터넷이 끊겨도, 여러분의 업무는 계속됩니다.
클라우드는 여전히 유용한 도구예요. 하지만 모든 달걀을 한 바구니에 담는 위험은 이제 충분히 경험했죠. 중요한 업무는 로컬에서, 클라우드는 보조 수단으로. 이것이 이번 AWS 대란이 우리에게 남긴 가장 중요한 교훈이에요.
여러분의 필요에 맞는 현명한 도구 선택으로, 클라우드 장애로부터 자유로운 진정한 데이터 주권을 확보하시길 바랍니다.
참고자료
[1] AWS 장애로 퍼플렉시티·배그·삼성페이 등 간헐적 오류
[2] 아마존웹서비스(AWS) 서버 중단 … 전 세계 인터넷 혼란이 벌어진 이유는?
[3] 美 아마존 서버 장애로 세계 웹사이트·앱 멈췄다