왜 장애는 반복되는가, 그리고 기업이 취할 수 있는 대응은 무엇인가
2025년은 단일 클라우드 벤더에 비즈니스를 전적으로 의존한 기업들에게 매우 힘든 해였습니다. 12월, Snowflake 고객들은 스키마 업데이트가 여러 리전에 연쇄적으로 전파되면서 13시간 동안 쿼리 실행이 중단되는 상황을 지켜볼 수밖에 없었습니다. Databricks 사용자들은 며칠간 AI 서비스 성능 저하를 겪어야 했습니다.
10월에는 Amazon Web Services(AWS)의 US-East-1 리전이 15시간 동안 다운되었습니다. DynamoDB에서 발생한 DNS 오류로 1,000개 이상의 기업 서비스가 중단되었습니다. 6월에는 Google Cloud의 Service Control 바이너리에서 발생한 널 포인터 예외로 인해 Cloud Storage, Compute Engine, BigQuery를 포함한 많은 시스템이 몇 시간 동안 비활성화 *되었고, 그 여파는 Spotify, Discord, OpenAI에까지 미쳤습니다.
모든 사고에서는 공통된 양상이 나타났습니다. 고객은 페이지 새로 고침 버튼을 누르며 누군가 문제를 해결해 주기를 기다릴 수밖에 없었습니다. 벤더 간 차이는 장애가 발생하는지 여부가 아니라, 장애 발생 시 고객이 선택할 수 있는 대응책이 있는지에 달려 있습니다.
패턴: 전 세계에 영향을 미치는 단일 장애 지점
12월에 발생한 Snowflake 사태 *는 하위 호환되지 않는 데이터베이스 스키마 업데이트로 촉발되었습니다. 버전 불일치 오류로 인해 AWS, Microsoft Azure, Google Cloud Platform(GCP) 전반의 여러 리전에서 작업이 실패하거나 무기한 중단되었습니다. Snowflake는 사전에 영향을 받지 않는 리전으로 복제를 구성해 둔 고객을 제외하고는 별다른 대안이 없다고 밝혔습니다. 나머지 고객은 그저 기다릴 수밖에 없었습니다.
Databricks의 12월 장애* 는 수일에 걸쳐 이어졌으며, Unity Catalog 문제, 여러 리전에서의 컴퓨팅 성능 저하, 그리고 며칠간 지속된 Mosaic AI 중단을 초래했습니다. 상태 업데이트에는 계속해서 “잠재적인 완화 방안을 위해 클라우드 제공업체와 협력 중”이라는 문구만 표시되었습니다. 이 문구는 의존 관계를 명확히 보여줍니다. 즉, Azure에 문제가 생기면, Azure 리전에서 Databricks를 사용하는 고객도 그대로 영향을 받습니다.
*Google Cloud의 6월 사고 역시 동일한 취약점을 드러냈습니다. 빈 필드가 포함된 잘못된 정책이 글로벌 구성 테이블에 삽입되면서 몇 초 만에 전 세계로 복제되었습니다. 손상된 데이터로 인해 핵심 서비스가 7.5시간 동안 크래시 루프를 겪으며 중단되었습니다. 초기에는 Google 자체 상태 대시보드조차 접근할 수 없어 SRE 팀도 피해 범위를 즉시 확인할 수 없었습니다.
장애 원인이 물리적 문제가 아니라 논리적 문제일 경우, 지역별 이중화는 효과가 없습니다. 플랫폼이 전 세계적으로 동기화된 메타데이터나 공유 구성을 기반으로 운영될 때, 단 한 번의 잘못된 업데이트가 모든 리전으로 퍼집니다. 이로 인해 장애는 리전을 넘어 이동합니다.
또한 이러한 상황에서는 인프라는 분산되어 있지만, 통제는 여전히 중앙에 집중되어 있습니다. Snowflake의 제어 플레인이 중단되면, 그 하위에서 AWS, Azure, Google Cloud를 운영한다는 사실은 의미가 없습니다. Databricks가 Azure의 복구를 기다리는 동안에는 멀티 클라우드라는 마케팅 메시지도 아무런 도움이 되지 않습니다. 결국 단일 장애 지점은 맨 위에 위치한 독점적 계층에 존재합니다.
애널리스트들의 경고
Gartner®의 2025년 클라우드 도입 트렌드 분석 *에 따르면, 2029년까지 전체 조직의 절반 이상이 멀티 클라우드 구현에서 기대한 성과를 얻지 못할 것으로 전망됩니다. 핵심 문제는 바로 환경 간 상호운용성 부족입니다.
Forrester의 보고서 2026년 전망: 클라우드 장애, 프라이빗 클라우드 기반 프라이빗 AI, 그리고 네오클라우드의 부상(Predictions 2026: Cloud Outages, Private AI On Private Clouds, And The Rise Of The Neoclouds)에서는 2026년에 최소 두 차례 이상 며칠간 지속되는 대규모 클라우드 장애가 발생할 것으로 예측하고 있습니다. 현재 클라우드 산업은 하이퍼스케일러들이 AI 네이티브 데이터 센터 구축 경쟁을 벌이며 대규모 인프라 전환을 겪고 있습니다. 이러한 투자는 대가를 수반합니다. 기존 x86 및 ARM 환경이 후순위로 밀리면서, 노후화된 인프라가 점점 복잡해지는 환경 속에서 한계를 드러내고 있습니다.
같은 Forrester 전망에서는 2026년에 최소 15%의 기업이 프라이빗 클라우드를 기반으로 한 프라이빗 AI 배포로 전환할 것으로 내다보고 있습니다. 그 배경으로는 AI 비용 상승, 데이터 락인에 대한 우려, 그리고 점점 특정 벤더의 우선순위에 맞춰 최적화되는 인프라에 의존함으로써 발생하는 운영 리스크가 있습니다. 2025년에 연이어 발생한 클라우드 장애는 워크로드가 제공업체의 최우선 과제가 아닐 때 어떤 일이 벌어지는지를 미리 보여 준 사례였습니다.
Cloudera의 복원력 중심 아키텍처 설계
대부분의 기업은 인수합병, 섀도 IT 또는 각 분야에서 가장 우수한 도구를 개별적으로 선택한 결과로 인해 ‘의도치 않은 멀티 클라우드’ 아키텍처를 갖게 됩니다. 이는 계획된 설계의 결과가 아니라 우연의 산물입니다. 워크로드는 여러 제공업체에 흩어져 있지만, 장애가 발생했을 때 데이터와 워크로드를 자유롭게 이동할 수 있는 역량은 부족한 경우가 많습니다.
복원력을 고려한 아키텍처 설계란 데이터 및 AI 플랫폼이 이식성을 제공하고 단일 장애 지점을 제거하도록 구성하는 것을 의미합니다.
Cloudera 플랫폼 *은 이식성을 핵심으로 설계되며 운영 연속성을 유지하기 위해 환경 간 자유로운 장애 조치를 지원합니다. 워크로드와 데이터는 AWS, Azure, Google Cloud, 그리고 온프레미스 환경 간에 재작성, 마찰 또는 벤더 종속 없이 이동할 수 있습니다. 또한 전역적인 비하위호환 업데이트가 강제로 적용되지 않습니다.
피할 수 없는 장애가 발생했을 때에도 기업에는 선택지가 있습니다. 다른 클라우드로 장애 조치를 수행하거나 워크로드를 다시 데이터 센터로 되돌릴 수 있습니다. 단순히 상태 페이지만 바라보며 기다릴 필요 없이 데이터가 어디에 있든 일관된 운영과 규정 준수를 유지하며 완전한 통제권을 확보할 수 있습니다.
Cloudera와 함께 복원력 있는 아키텍처를 설계하는 방법에 대해 더 자세히 알아보려면, 블로그 데이터 복원력을 위한 아키텍처 설계: Cloudera로 비즈니스 연속성 보장(Architecting for Data Resilience: Ensuring Business Continuity with Cloudera)을 참고하시기 바랍니다.
향후 전망
AI 인프라 확장은 기존 시스템에 부담을 주고 있으며, 주요 애널리스트들은 앞으로 더 큰 변동성을 예상하고 있습니다. Forrester는 며칠간 이어지는 클라우드 장애를, Gartner는 방어적 성격의 멀티 클라우드 도입 확대를 전망하고 있습니다. 2026년을 안정적으로 보낼 수 있는 기업은 복원력을 단순한 규정 준수 항목이 아니라 아키텍처 원칙으로 받아들이는 기업이 될 것입니다.
Cloudera는 버튼 하나로 클라우드 간 장애 조치를 제공하지는 않습니다. 사실, 그러한 기능을 즉시 제공하는 플랫폼은 존재하지 않습니다. 그러나 Cloudera는 독점 플랫폼과 달리 이러한 복원력을 구조적으로 지원할 수 있는 역량을 갖추고 있습니다.
2025년의 장애가 불편함을 느끼게 했다면, 지금이 바로 그 이야기를 나눌 시점입니다. 결국에는 클라우드도 누군가의 컴퓨터에 불과합니다. 그리고 컴퓨터에 문제가 생겼을 때는 이를 대체할 또 다른 선택지가 있어야 합니다.
Cloudera와 함께 복원력을 고려한 아키텍처를 설계하는 방법에 대해 알아보려면, 전문 서비스 팀에 문의 *하거나 제품 데모를 확인하거나 5일 무료 평가판을 신청해 보시기 바랍니다.
