‘불가능한 일’이 또다시 일어났다. 디지털 경제의 중추이자 세계 최대 클라우드 서비스 업체인 AWS에서 대규모 서비스 중단 사태가 발생했다. IT 업계에서 일하거나 클라우드 서비스에 의존하는 사람이라면 굳이 속보를 보지 않아도 상황이 심상치 않다는 것을 바로 알 수 있었다. 생산성이 급격히 떨어지고, 웹사이트는 로드되지 않았으며, 비즈니스 시스템은 멈춰 섰다. 전 세계 상거래의 분주함마저 멎은 듯한 몇 시간이 이어졌다. 이번 사태는 전자상거래 대기업부터 스타트업, 그리고 필자의 컨설팅 사업에 이르기까지 광범위한 영향을 미쳤다.

AWS 상태 페이지를 빠르게 확인한 결과, 미국과 유럽 전역의 리전에서 서비스 저하가 보고되고 있었다. 상황을 파악하려는 기업 고객의 전화로 상담 창구는 마비됐다. 청구서 처리가 중단되고, 일정 관리 시스템은 디지털 먼지로 흩어졌으며, 피해는 걷잡을 수 없이 확산됐다. 필자의 작은 사업체에서만 약 3,000달러의 생산성 손실이 발생했다고 추정되는데, 포천지 선정 500대 기업이 입은 손실은 이보다 훨씬 클 것으로 보인다. 전 세계적으로는 피해 규모가 수백만 달러에 달할 것으로 보인다.

서비스 중단 사고의 원인과 과정

화면이 멈추고 경고 알림이 쏟아지기 시작했을 때, 가장 먼저 떠오른 생각은 “사고인가, 공격인가?”였다. AWS 엔지니어링팀은 아직 근본 원인을 조사 중이다. 초기 분석에 따르면, 정기적인 인프라 확장 과정에서 네트워크 관리 시스템의 설정 오류가 발생한 것으로 보인다. 엔터프라이즈 SaaS 확산과 생성형 AI 학습 워크로드를 필두로 클라우드 자원 수요가 폭발적으로 증가하면서 클라우드 서비스 업체는 물리 인프라를 꾸준히 확장하고 성능을 개선해야 한다. 그러나 이번 사태에서는 일상적인 변경 작업 하나가 핵심 라우팅 장비의 장애를 유발했고, 그 결과 여러 AWS 가용영역으로 장애가 확산됐다.

AWS는 즉시 변경 사항을 롤백하고 영향을 받은 구성 요소를 격리했다. AWS 지원팀은 신속하게 공지를 올렸지만, 예고된 대로 기술적인 설명에 치중해 구체적인 내용은 부족했다. 자동 확장, 로드 밸런싱, 트래픽 라우팅 문제는 연쇄적으로 다른 서비스에도 영향을 미쳤다. 이번 사건은 ‘탄력성’과 ‘가용 영역’이라는 화려한 단어에도 불구하고, 클라우드 인프라 역시 결국 물리 법칙과 소프트웨어 결함에서 완전히 자유롭지 않다는 사실을 일깨워줬다.

몇 시간 뒤 네트워크 엔지니어가 분산 시스템을 수동으로 재조정하고 정상 작동을 검증한 후에야 완전 복구가 이뤄졌다. 연결은 회복됐지만 일부 고객은 데이터 불일치, API 복구 지연, 처리 속도 저하 등을 보고했다. 클라이언트와의 커뮤니케이션 재개, 프로세스 재설정, 백로그 처리에 쫓기는 혼란 속에서 많은 기업이 다시 한번 절감했다. 비즈니스 연속성은 서비스 업체의 마케팅 문구가 아니라 현실적인 대비에서 비롯된다는 점을.

‘총알도 막는’ SLA 신화

일부 기업은 AWS의 전설적인 SLA에 따라 즉각적인 보상을 기대했다. 그러나 현실은 냉정했다. SLA 크레딧은 매출이 추락할 때 위로가 되지 않는다. CIO라면 누구나 한 번쯤 경험했듯, 업계 최고 수준의 SLA도 실제 다운타임의 피해를 보상하지는 못한다. SLA는 잃어버린 매출, 손상된 명성, 피로에 지친 팀의 스트레스를 되돌려주지 않는다.

최근 리전 단위의 장애가 늘어나고 있는 이유는 AI를 중심으로 한 수요가 급증하면서 초대형 데이터센터가 감당해야 할 부하가 커졌기 때문이다. 결국 클라우드의 ‘안전망’은 점점 신뢰성을 잃어가고 있다.

이처럼 불안정성이 커지는 원인은 명확하다. 클라우드는 단일 시스템이 아니다. 신규 리전, 데이터센터, 기술 업데이트가 추가될 때마다 라우팅 인프라와 물리적 연결, 종속 시스템이 복잡해진다. AI/ML 워크로드는 높은 연산 및 저장 성능을 요구하며, 이런 부하가 증가할수록 인프라의 보이지 않던 균열이 드러난다. 수요가 운영을 한계까지 밀어붙이면, 보이지 않고 매끄럽게 연결되어야 하는 인프라의 균열이 드러나기 시작한다.

다음 장애에 대비하라

이번 서비스 중단 사태는 경종이 됐다. 헤드라인은 곧 사라지고, AWS를 비롯한 클라우드 서비스 업체는 더 높은 신뢰성을 약속할 것이다. 그러나 반드시 기억해야 한다. 얼마나 많은 ‘9’를 보장하든, 진정한 비즈니스 복원력은 기업 내부에서 시작된다. 다음 ‘벼락’이 떨어졌을 때 생존하려면, 기업이 스스로 위험을 관리해야 한다.

첫째, 멀티클라우드와 하이브리드 아키텍처에 투자하라. 아무리 큰 클라우드 서비스 업체라도 단일 클라우드에 의존하는 것은 모든 달걀을 한 바구니에 담는 것과 같다. AWS, 애저, 구글 클라우드, 또는 온프레미스 시스템 간에 애플리케이션을 이식할 수 있도록 설계하면, 재해 발생 시 보조 플랫폼으로 신속히 전환할 수 있다. 복잡하고 비용이 더 들긴 하지만, 수백만 달러의 손실을 막을 수 있다면 충분히 가치 있는 선택이다.

둘째, 탐지와 대응 과정을 자동화하라. 장애를 얼마나 빨리 감지하고 대응하느냐가 위기를 버티는 기업과 침몰하는 기업을 가른다. 자동 모니터링은 단순한 시스템 상태 점검을 넘어, 애플리케이션 수준의 기능성과 비즈니스 KPI까지 감시해야 한다. 시스템은 경보를 발송하고, 자동 복구를 시도하거나 최소한 서비스의 품질 저하를 완화하는 지침을 실행해야 한다. 사람의 반응 속도는 ‘분’ 단위지만, 클라우드 장애는 ‘초’ 단위로 발생한다.

셋째, 재해 복구 계획을 문서로만 남기지 말고 실제로 훈련하라. 비즈니스 연속성은 현실적인 조건에서 검증될 때만 확보된다. 정기적으로 클라우드 장애를 시뮬레이션해 서비스를 끄고, 트래픽을 우회시키며, 의도적으로 혼란을 주는 ‘카오스 테스트’를 수행하는 기업이 실제 재해 상황에 가장 잘 대응한다. 반복 훈련을 통해 쌓은 ‘근육 기억’은 위기 상황에서 생사를 가른다. 직원이 실제 상황에서 매뉴얼을 처음 펼치는 일은 없어야 한다.

이번 AWS 장애로 인한 생산성 손실은 앞으로 몇 주 동안 계산될 것이다. 많은 기업은 큰 대가를 치르고 나서야 교훈을 얻는다. 하지만 분명한 것은 이번이 마지막 장애가 아니라는 점이다. 글로벌 디지털 경제가 확장되고 AI가 더 많은 대역폭과 연산력을 요구할수록, 장애는 더욱 빈번해질 가능성이 높다.

IT 책임자와 기업 경영진은 클라우드 서비스 업체가 더 투명하게 정보를 공개하고 더 나은 도구를 제공하기를 기대할 수 있다. 그러나 최선의 방어는 ‘선제적 복원력 전략’이다. 클라우드는 미래이지만, 맑은 날뿐 아니라 폭풍의 날에도 견딜 준비가 필요하다.
dl-itworldkorea@foundryco.com