사이버 정전 또다시 발생

[2025.10.22 자 미라클레터 ‘또다시 발생한 사이버 정전’ 발췌]

지난 10월 20일 미국에서 많은 사람들이 불편한 상황을 경험했습니다. 미국에서 많이 쓰는 ‘왓츠앱’과 ‘벤모’와 같은 앱이 작동을 멈췄다고 하는데, 원인은 AWS(아마존 웹 서비스) 오류 때문이라고 합니다. 이 때문에 게임 플랫폼 포트나이트를 비롯해, 스냅챗, 왓츠앱, 줌, 레딧, 페이스북, 인스타그램, 넷플릭스 등에서 오류가 발생했다고 합니다.

이번 시간에는 문제가된 클라우드 서비스에 대해 정리해보고 왜 대규모 먹통 사태가 발생했는지 함께 알아보고자 합니다.

클라우드 서비스란?

이미지 출처: AWS

인터넷만 연결이 되어 있다면 이제 누구든 거대한 컴퓨팅 자원을 빌릴 수 있는 시대입니다. 과거에는 ‘서버’와 ‘스토리지’가 있어야만 했는데 이제는 ‘클라우드’라는 서비스를 통해 필요한 만큼, 필요한 시점에 컴퓨팅 자원을 사용할 수 있게 되었습니다.

‘구름’이라는 뜻을 가진 클라우드 서비스는 인터넷이라는 거대한 네트워크를 통해 서버, 데이터 베이스, 애플리케이션 등을 가상 환경에서 제공하는 IT 인프라입니다.

문서 작업을 위해 마이크로소프트 워드, 한글을 설치하는 대신 웹에서 바로 문서를 작성하는 ‘구글 문서(Google Docs)’를 사용할 수 있고, 사진을 스마트폰에만 저장하지 않고 구글 포토나 아이클라우드(iCloud)에 저장하는 것도 모두 클라우드 서비스의 한 예로 볼 수 있습니다.

게임도 마찬가지입니다. 예전에는 CD를 사서 PC에 설치한 후 게임을 해야했습니다. 저장 공간도 필요했고요. 하지만 요즘 게임은 설치하지 않아도 됩니다. 게임은 클라우드 서버에서 실행되고, 화면만 인터넷을 통해 실시간으로 받아보며 게임을 즐길 수 있습니다.

서버를 구매하고 데이터센터 구축하려면 많은 시간과 자본이 필요한 만큼 클라우드를 사용하면 클릭 몇 번으로 글로벌 서비스를 시작할 수 있습니다. 개발 환경 구축과 테스트, 배포 역시 클라우드 안에서 이뤄집니다. 개발자는 더 이상 하드웨어나 시스템 설정 등에 시간을 낭비할 필요도 없습니다. 보안과 유지보수 역시 클라우드 업체가 대신합니다.

AWS와 마이크로소프트 애저, IBM 클라우드, 오라클 클라우드 등 주요 세계적 기업들이 이러한 클라우드를 제공하고 있습니다. 국내 업체로는 네이버 클라우드 플랫폼, KT클라우드, NHN클라우드, 삼성SDS의 SCP 등을 꼽을 수 있습니다.

클라우드 기업들은 사용자가 직접 원하는 환경을 구성할 수 있도록 돕거나 개발자가 애플리케이션을 만들고 운영하는 데 필요한 플랫폼을 제공하고 또는 구글 문서나 줌처럼 사용자가 소프트웨어를 별도 내려받지 않아도 브라우저를 통해 바로 사용할 수 있도록 제공하는 등 다양한 방식으로 서비스를 제공하고 있습니다.

이처럼 클라우드는 원하는 형태의 자원을 필요한 만큼만 사용하는 구조로 되어 있어 기업과 개인 모두에게 큰 효율성을 제공합니다. 자체 시스템을 구축하는 데 드는 비용과 시간, 운영의 복잡함을 줄일 수 있다는 점에서 매우 매력적인 선택지일 수밖에 없습니다.

이번 사건이 발생한 이유

이미지 출처: wired.com

문제가 된 것은 미국 버지니아 북부에 있는 AWS 데이터센터에서 발생한 내부 시스템 오류였습니다. 약 두 시간 동안 수많은 디지털 인프라가 멈췄습니다. 이와 관련된 오류 신고는 800만건 이상 발생했습니다. 주로 미국과 영국에서 보고되었습니다.

문제가 된 곳은 “us-east-1”이라 불리는 북버지니아 리전(region)입니다. 이곳은 AWS에서 가장 규모가 큰 핵심 인프라 중 하나로 파급력 역시 클 수밖에 없었습니다. 확인 결과, ‘DNS’라는 시스템에서 고장이 난것으로 파악됩니다. DNS는 인터넷 주소를 전화번호부처럼 관리해주는 시스템인데요. 인터넷에서 컴퓨터끼리는 숫자 주소, 즉 IP로 통신합니다.

예를 들어 github의 서버 주소가 223.130.195.200이라고 가정해 보겠습니다. 이를 외우기 어렵습니다. 그래서 우리는 https://github.com와 같은 문자 주소, 즉 도메인을 대신 씁니다. 여기서 DNS가 등장합니다. DNS는 사람이 친 도메인 이름을 컴퓨터가 이해할 수 있는 숫자 주소로 바꿔주는 시스템입니다.

즉 사용자가 브라우저에 https://github.com를 입력하면, 컴퓨터가 DNS에 묻습니다. “이 주소 숫자 IP가 뭐야?” 그럼, DNS 서버가 대답합니다. “223.130.195.200이야” 그럼 이 숫자를 이용해 github의 실제 서버에 연결됩니다. 브라우저에 github 홈 화면이 뜨는 거죠. 즉 DNS는 전화번호부와 같다고 볼 수 있습니다.

경제적 피해 집계 수조원, 대안은?

이번 사태는 이 DNS가 고장이 나면서 웹사이트들이 서버로 가는 길을 찾지 못하게 되었습니다. 이는 AWS가 만든 데이터저장소, 즉 데이터베이스인 DynamoDB에도 영향을 미칩니다. 웹사이트나 앱은 사용자 정보와 로그인 기록, 주문 내용과 같은 데이터를 항상 저장하고 불러와야 합니다. 이걸 직접 관리하지 않고 AWS의 DynamoDB 서버에 맡겨둔다고 합니다. 역시 하나의 인터넷 서버인데요. DNS가 고장 나면 다른 프로그램들이 DynamoDB 서버 주소를 못 찾게 됩니다. 그 결과 로그인, 결제, 채팅, 데이터 저장과 관련된 기능도 멈춰버립니다.

스냅챗은 로그인 불가, 슬랙은 메시지 전송 오류, 벤모는 결제 오류, 핀터레스트는 아예 화면 안뜸. 정확한 발생 시점은 10월 19일 오후 11시 49분(현지시간)부터 10월 20일 새벽 2시 24분까지 이며, 복구는 10월 20일 오후 3시에 완료되었다고 합니다.

“갑자기 왜 DNS가 고장 났을까”라는 생각이 드는데요. 이유는 잘못된 업데이트 때문이었어요. DynamoDB API내 새로운 기술 패치를 적용한 후 내부 DNS 시스템이 엔드 포인트 주소를 잘못 해석했다고 합니다. AWS가 DynamoDB를 새로 고치다가 주소표를 잘못 붙여놓은 겁니다. 문득 업데이트 후 오류라는 말을 들으니 지난해 있었던 크라우드스트라이크의 ‘사이버 정전’이 떠오릅니다.

이번 사태는 “한 곳에만 기대면, 함께 멈춘다”는 사실을 보여줍니다. 그래서 요즘 기업들은 다중 리전 또는 멀티 클라우드 전략을 택하고 있습니다. 같은 AWS 안에서도 두 개 이상의 리전을 동시에 혹은 한쪽은 대기 상태로 운영해, 한 리전이 멈춰도 트래픽이 자동으로 다른 곳으로 넘어가게 하는 전략입니다.

핵심 시스템은 AWS와 애저, 구글 클라우드 등으로 나눠 두면 한 업체 장애에 발목을 잡히지 않습니다. 물론 비용은 많이 들테지만요. 이밖에 DNS 분리, 네트워크 복원력 확대 등 다양한 대안이 나오고 있습니다. 이번 사태로 인한 경제적 피해는 명확하지 않지만 일단 ‘조단위’ 라고 합니다.

이번 AWS 장애는 단순한 기술 문제가 아니라 세계가 얼마나 소수의 클라우드 기업에 의존하고 있는지를 보여준 사건이라는 생각이 듭니다. 인터넷은 분산되어 있지만, 그 기반은 몇몇 기업의 데이터센터에 집중되어 있습니다. 클라우드는 효율성과 안정성을 약속했지만 그 편리함은 동시에 ‘단일 실패’라는 위험을 낳았습니다.

기술은 점점 강력해지지만 그만큼 하나의 오류가 더 큰 충격을 일으키는 시대이기도 합니다. 이번 사고는 우리가 얼마나 연결되어 있는지를, 그리고 그 연결이 얼마나 쉽게 흔들릴 수 있는지를 다시 일깨워준 것 같습니다.