2월 초 10시간 동안 이어진 마이크로소프트 애저 클라우드의 장애는 클라우드도 장애에서 자유롭지 않다는 사실을 다시 한번 선명하게 보여줬다. 2월 2일 19시 46분 애저 클라우드 플랫폼은 마이크로소프트 매니지드 스토리지 계정에 영향을 주는 정책 설정 오류에서 촉발된 연쇄적인 문제를 겪기 시작했다. 겉으로는 사소해 보이는 오류가 확산되며 클라우드의 정상적인 운영을 떠받치는 핵심 계층인 가상머신 운영과 관리형 ID를 마비시켰다.

문제가 잦아들기 시작한 시점은 다음 날 6시 5분으로, 10시간이 지난 뒤였다. 여러 지역의 기업 고객이 가상머신을 배포하거나 확장하지 못했다. 미션 크리티컬 개발 파이프라인은 멈춰 섰고, 수백 곳의 기업이 애저에서 가장 단순한 작업조차 수행하기 어려웠다. 여파는 애저 데브옵스(Azure DevOps)와 깃허브 액션(GitHub Actions)을 거치는 CI/CD 파이프라인을 포함해 개발자 생산성의 핵심인 프로덕션 시스템과 워크플로우 전반으로 번졌다. 문제를 키운 요인으로 관리형 ID 서비스가 지목되는데, 특히 미국 동부와 서부에서 인증과 클라우드 리소스 접근이 끊기며 쿠버네티스 클러스터부터 분석 플랫폼, AI 운영까지 주요 애저 서비스 전반이 영향을 받았다.

사후 보고서의 결론은 익숙하다. 초기 수정 조치가 서비스 트래픽 급증을 유발해 이미 버거운 플랫폼을 추가로 압박한다. 인프라 확장이나 서비스 일시 중단 같은 완화 조치를 통해 결국 질서를 회복하지만, 피해가 발생한 뒤였다. 운영 중단은 생산성 손실과 배포 지연으로 이어졌고, 더 은밀하지만 더 위험한 결과로 대형 클라우드 장애가 현대 엔터프라이즈 IT 영역에서 ‘원래 그런 것’이라는 인식을 강화했다.

이런 사고가 헤드라인에 자주 등장하고, 개별 사건이 서로 비슷해 보인다는 점에서 이제 질문이 필요하다. 왜 이런 장애가 매월, 때로는 매주 벌어지는 이야기로 굳어지고 있는가? 클라우드 컴퓨팅 세계에서 무엇이 바뀌었기에 불안정의 새 국면이 열렸는가? 필자는 여러 흐름이 합쳐지며 이런 장애가 더 흔해졌을 뿐 아니라 더 파괴적이고 예방도 더 어려워졌다고 본다.

어느새 스며든 인적 오류

클라우드 컴퓨팅의 경제적 현실이 달라졌다는 점은 널리 알려져 있다. 무제한 성장의 시대는 끝났다. 수요 급증 속도에 맞춰 인력 규모가 계속 늘어나지 않는다. 마이크로소프트, AWS, 구글 같은 하이퍼스케일러는 최근 수년간 대규모 감원을 발표했고, 감원은 플랫폼을 안정적으로 운영하고 프로덕션 반영 전에 오류를 잡아내는 운영·지원·엔지니어링 조직에 불균형하게 집중되는 경우가 많았다.

예상 가능한 결과는 숙련 엔지니어와 아키텍트가 떠나면 조직 내에서 충분한 지식을 갖추지 못한 인력이 빈자리를 메우는 흐름이다. 플랫폼 운영, 트러블슈팅, 위기 대응 경험이 충분하지 않다. 역량이 있어도 이런 ‘2군 인력’은 애저 클라우드처럼 거대하고 상호 연결된 시스템에서 작은 변경이 어떤 파급을 만드는지 예측할 기술과 지식이 부족할 수 있다.

최근 애저 클라우드의 장애는 이런 인적 오류의 전형으로, 잘못 적용된 정책이 가상머신 확장 패키지에 필요한 스토리지 리소스 접근을 막았다. 변경은 과거 이슈를 잘 모르는 담당자가 서두르거나 맥락을 오해한 채 진행했을 가능성이 크다. 그 결과, 광범위한 서비스 장애는 사실상 피하기 어려웠다. 인력 구조의 변화가 지속되는 한 이런 인적 오류는 흔하고 반복될 가능성이 크다.

과거보다 커진 피해

장애의 충격을 키우는 또 다른 흐름은 복원력에 대한 상대적 안일함이다. 오랫동안 기업은 워크로드를 클라우드로 ‘리프트 앤 시프트’ 방식으로 옮기는 데 만족하며 민첩성과 확장성의 이점을 누렸고, 그런 이전에 필요한 수준의 중복 구성과 재해 복구에는 투자하지 않는 경우가 많았다.

기업 문화에서는 클라우드 장애가 불가피하며, 장애 완화는 서비스 업체의 몫이라는 인식이 커지고 있다. 이런 인식은 비현실적 기대이자 위험한 책임 방기이다. 복원력은 전적으로 아웃소싱할 수 없고, 기업 애플리케이션 아키텍처와 배포 전략 전반에 의도적으로 설계돼야 한다.

하지만 컨설팅 현장에서 확인되는 현실과 다수의 CIO·CTO가 개인적으로 인정하는 현실은 복원력이 너무 쉽게 뒷전으로 밀린다는 것이다. 애저, AWS, 구글 클라우드 장애가 잠깐만 발생해도 영향은 IT 부서를 훌쩍 넘어선다. 매출 흐름이 멈추고, 지원 대기열은 넘친다. 고객 신뢰는 흔들리고, 복구 비용은 금전·평판 측면 모두에서 급등한다. 하지만 멀티클라우드 전략, 하이브리드 중복 구성, 페일오버 대비책에 대한 투자는 위험 증가 속도를 따라가지 못하고 있다. 기업은 복원력 투자를 소홀히 한 대가를 치르고 있으며, 클라우드를 더 폭넓게 채택할수록 비용은 더 커질 것이다.

한계점에 도달한 시스템의 복잡성

하이퍼스케일 클라우드 운영은 본질적으로 복잡하다. 플랫폼이 성공할수록 규모와 복잡성이 커지며 AI, 분석, 보안, 사물인터넷 같은 광범위한 서비스를 지원한다. 계층화된 제어 플레인은 서로 얽혀 있어 마이크로소프트 애저 사례처럼 하나의 설정 오류가 곧바로 대형 재난으로 번질 수 있다.

규모가 커질수록 오류 없이 운영하기가 어려워진다. 자동화 도구가 도움을 주지만, 코드 변경과 기능 추가, 통합이 늘어날수록 오류의 확률이 올라간다. 기업이 더 많은 데이터와 로직을 클라우드로 옮기면서 작은 장애도 큰 영향을 낳는다. 서비스 업체는 혁신, 비용 절감, 확장 압박을 동시에 받으며, 목표 달성을 위해 단순함을 희생하는 경우가 많다.

기업과 서비스 업체 모두의 대응이 필요하다

최근 발생한 애저 클라우드의 장애를 분석하면, 변화가 필요하다는 점은 분명하다. 클라우드 서비스 업체는 감원이나 플랫폼 신뢰성 투자 축소 같은 비용 절감 조치가 결국 대가를 치르게 된다는 사실을 인정해야 한다. 클라우드 서비스 업체는 교육 강화, 프로세스 자동화, 운영 투명성 확대에 더 집중해야 한다.

기업도 장애를 불가피하거나 피할 수 없는 것으로 취급할 여유가 없다. 아키텍처 복원력 투자, 페일오버 전략의 지속적 테스트, 여러 클라우드로의 분산은 베스트 프랙티스가 아니라 생존 전략이다.

클라우드는 혁신의 엔진으로 남아 있지만, 이 파트너십의 양쪽이 수준을 끌어올리지 못하면 클라우드 장애는 시계추처럼 반복될 것이다. 그리고 그 후폭풍은 더 멀리 번지고, 더 깊은 상처를 남길 것이다.
dl-itworldkorea@foundryco.com