칼럼 | 한 바구니 클라우드 전략의 위험···AWS 장애가 드러낸 분산의 필요성

‘클라우드가 디지털 전환의 핵심 인프라’라는 말은 이제 상투적인 표현이 됐지만, 이번 AWS 장애와 같은 사건은 기업의 클라우드 의존도가 얼마나 절대적인지를 적나라하게 보여줬다. 지난 20일 발생한 AWS 장애로 전 세계 수천 개의 기업이 영향을 받았다. SaaS 기업부터 전자상거래 업체에 이르기까지 매출이 중단되거나 사라졌고, 고객 경험이 악화되며 브랜드 신뢰도까지 위협받았다.

이처럼 장애로 인해 직접적인 재무 손실을 입은 기업의 좌절감은 깊다. 수십 년 동안 클라우드 아키텍처를 자문해온 필자에게, 이런 사건이 발생할 때마다 기업들은 같은 질문을 던진다. 바로 ‘이번 손실을 어떻게 회복하고, 앞으로 이런 심각한 중단 사태를 막으려면 어떻게 해야 하나?’라는 질문읻다.

이 질문에 대한 첫 단계는 장애의 사실 관계와 영향을 정확히 파악하는 것이다. AWS와 같은 클라우드 사업자는 일반적으로 사고 직후 신속하게 사고 보고서와 공지를 공개한다. 이 보고서에는 장애의 원인, 복구까지 걸린 시간, 영향을 받은 서비스 등이 상세히 담긴다.

문제의 원인을 따지는 데만 몰두하기보다, 기술적·계약적 현실을 명확히 이해하는 것이 향후 대응의 핵심이다. 기업이 우선적으로 수집해야 할 주요 정보는 다음과 같다.

• 어떤 서비스나 워크로드가 얼마 동안 영향을 받았는가?
• 직접적인 비즈니스 영향은 무엇인가? 예를 들어 거래 실패, 고객 이탈, 연쇄 비용이 발생했는가?
• 서비스 수준 계약(SLA)에 실제로 어떤 보장이 명시돼 있으며, 이번 장애가 그 보장을 위반했는가?

‘클라우드가 멈췄다’는 단순한 사실만으로는 부족하다. 장애의 지속 시간, 영향을 받은 영역, 핵심 비즈니스 기능의 중요도 등 구체적인 내용이 향후 대응 방안을 결정짓는다.

클라우드 SLA와 보상의 한계

현실적으로 많은 기업이 공공 클라우드 계약의 보장 수준을 과대평가한다. AWS, 애저, 구글 클라우드 등 주요 하이퍼스케일러는 명확한 SLA를 제공하지만, 실제 보상 범위는 극히 제한적이며 대부분의 경우 기업이 입은 실질적인 손실을 보전하지 못한다.

일반적으로 SLA는 월 사용량의 일정 비율을 기준으로 서비스 크레딧을 제공한다. 예를 들어 웹 애플리케이션이 2시간 동안 중단되고 SLA에 ‘99.99% 가용성’이 명시돼 있다면, 향후 일정 비율의 사용 요금이 크레딧으로 환급될 수 있다. 그러나 수억 원대 손실을 입은 기업에게 이런 보상은 사실상 의미가 없다.

또한 보상을 받기 위해서는 일정 기간 내에 클레임을 제기해야 하고, 직접적인 피해를 명확히 입증해야 한다. 서비스 제공자는 매출 손실, 고객사로부터의 위약금, 브랜드 훼손 등 간접적 피해에 대해선 책임지지 않는다. 이는 기업의 몫이다. 받아들이기 어려운 현실이지만, 이를 사전에 명확히 이해하는 것이 예상치 못한 상황에서 당황하지 않는 가장 좋은 방법이다.

법적 대응의 한계

법적 조치를 고려할 수도 있지만, 대부분의 경우 결과는 만족스럽지 않다. 클라우드 계약서는 수많은 법률 전문가들이 서비스 제공자의 책임을 철저히 제한하도록 설계했다. 대부분의 약관에는 ‘간접적 또는 결과적 손해에 대한 책임을 부인하며’, ‘직접 손해 배상액은 최근 한 달간 납부한 금액을 한도로 한다’는 내용이 명시돼 있다.

서비스 제공자가 ‘악의적 행위’나 ‘중대한 과실’을 저질렀다는 사실을 입증하지 않는 한, 법원은 이런 계약 조항을 대부분 인정한다. 금융 플랫폼과 같이 대규모 영향을 미쳐 규제 당국의 조사를 받는 경우를 제외하면, 대부분의 기업이 취할 수 있는 현실적인 대응책은 SLA 크레딧 절차뿐이다.

소송은 막대한 법률 비용이 들 뿐 아니라, 회수 가능한 손해액이 미미하기 때문에 시간과 비용 대비 효용이 거의 없다.

비즈니스 연속성 전략 재점검

다음 단계는 기업의 리스크 프로파일과 클라우드 아키텍처를 재검토하는 것이다. 기술 업계의 격언 “모든 달걀을 한 바구니에 담지 말라”는 클라우드 전략에도 그대로 적용된다.

많은 엔지니어링 팀이 공공 클라우드의 안정성과 분산 구조를 신뢰하지만, 실제 장애가 발생하면 불편한 진실이 드러난다. 단일 리전(region) 배포, 미흡한 페일오버 체계, 멀티클라우드 또는 하이브리드 전략 부재는 기업을 취약하게 만든다.

이럴 때 필요한 것은 냉정하고 정직한 사후 분석이다. 어떤 시스템이 실패했는가? 특정 클라우드 제공자나 리전에만 의존했는가? 자동 페일오버 등 복원력 확보를 위한 자체 설계가 실제로 작동했는가?

많은 기업이 사고 후에야 백업 설정이 잘못돼 있었거나, 중요 시스템에 이중화 설계가 부족했으며, 복구 매뉴얼이 오래되거나 검증되지 않았다는 사실을 깨닫는다. 이런 허점은 사업자의 장애를 기업 전체의 위기로 키운다.

진정한 복원력을 위한 세 가지 단계

공공 클라우드 장애 이후 기업이 단순히 보상에만 의존한다면 근본적인 문제 해결은 어렵다. 이제는 실질적인 보호 전략을 수립해야 한다. 이번 사고와 과거의 사례에서 얻은 교훈을 바탕으로, 모든 조직이 반드시 실행해야 할 세 가지 핵심 조치를 정리하면 다음과 같다.

첫째, 아키텍처를 점검하고 실질적인 이중화(redundancy)를 구축해야 한다. 주요 클라우드 사업자가 제공하는 여러 가용영역(availability zone)을 적극 활용하고, 핵심 워크로드에는 다중 리전(multiregion)이나 멀티클라우드(multicloud) 기반의 복원력을 진지하게 고려해야 한다. 비즈니스가 장시간의 서비스 중단을 감당할 수 없다면, 이런 투자는 선택이 아니라 필수다.

둘째, 사고 대응(incident response)과 재해 복구(disaster recovery) 계획을 재검토하고 갱신해야 한다. 문서로만 존재하는 이론적 절차는 아무런 의미가 없다. 실제 장애를 가정한 테스트와 시뮬레이션을 정기적으로 수행해 기술적 측면뿐 아니라 비즈니스 프로세스 차원에서도 대응 체계를 점검해야 한다. 대응 매뉴얼의 정확성과 역할 분담의 명확성, 그리고 각 팀의 긴급 대응 능력이 확보돼야 한다. 빠르고 조직적인 대응이 짧은 중단과 대규모 재난을 가르는 결정적 차이를 만든다.

셋째, 클라우드 계약과 서비스 수준 계약(SLA)을 명확히 이해하고, 가능하다면 더 나은 조건으로 협상해야 한다. 기업 규모가 충분히 크다면, 클라우드 제공자와 맞춤형 계약(custom agreement)을 논의할 수도 있다. 장애가 발생하면 세부 내용을 철저히 기록하고, 보상 청구는 즉시 진행해야 한다. 그보다 더 중요한 것은 ‘보장된 가용성’ 수치에만 의존하지 않고, 실제 위험 요소를 자사 비즈니스 및 고객과의 SLA에 반영하는 것이다.

클라우드 장애는 이제 드문 일이 아니다. 기업이 클라우드에 대한 의존도를 높일수록 그만큼 위험도 커진다. 진정한 복원력을 갖춘 기업은 장애를 단순한 사고가 아니라 ‘학습의 기회’로 삼는다. 다음 위기가 닥치기 전에 기술적 방어력과 계약적 안전망을 강화하는 것이야말로 가장 확실한 대비책이다. 결국, 최고의 공격 전략은 언제나 견고한 방어에서 시작된다.
dl-ciokorea@foundryco.com