클라우드 장애 대응이란 클라우드 서비스 제공업체의 인프라나 특정 서비스가 정상적으로 작동하지 않을 때, 이를 이용하는 기업이나 개인이 업무 중단을 최소화하기 위해 취하는 일련의 조치를 가리킨다. 이 글은 클라우드 장애가 왜 발생하는지, 장애가 발생했을 때 무엇을 먼저 확인해야 하는지, 그리고 평소에 어떤 방식으로 대비해 두어야 하는지를 차례로 정리한다.
클라우드 서비스는 물리적으로 수많은 서버와 네트워크 장비가 얽혀 있는 구조 위에서 운영된다. 규모가 커질수록 한 지점의 결함이 여러 서비스로 번질 가능성도 함께 커진다. 그래서 서비스 규모가 크든 작든 장애 자체를 완전히 없애는 것은 사실상 불가능하고, 장애가 발생했을 때 얼마나 빨리 감지하고 얼마나 좁은 범위로 막아내는지가 관건이 된다. 이런 이유로 클라우드를 이용하는 쪽에서도 장애를 전제로 한 대응 체계를 갖춰두는 것이 중요하다.
여러 사업자에서 반복되는 장애, 무엇이 공통점인가
아마존, 마이크로소프트, 구글 같은 해외 사업자든 네이버, kt, nhn 같은 국내 사업자든, 대형 클라우드 사업자도 예외 없이 서비스 중단을 겪어 왔다는 점은 이용자 사이에 잘 알려진 사실이다. 특정 사고의 원인이나 규모를 하나로 단정하기는 어렵지만, 장애가 발생하는 경로는 크게 몇 갈래로 나뉜다. 특정 지역 데이터센터의 전력이나 냉각 설비 문제, 네트워크 설정 변경 과정에서의 오류, 소프트웨어 배포 중 발생한 결함이 대표적이다.
이런 원인들은 사업자 규모와 무관하게 발생할 수 있다는 공통점이 있다. 그래서 어느 사업자가 더 안정적인가를 묻기보다는 내가 쓰는 서비스가 장애 상황에서 얼마나 빨리 복구되는가, 장애 중에도 대체 경로가 있는가를 살피는 편이 실질적인 판단에 도움이 된다. 사업자 선택보다 이용자 쪽의 대비 체계가 실제 피해 규모를 가르는 경우가 많다.
장애가 발생했을 때 무엇부터 확인하나
서비스가 갑자기 느려지거나 접속이 되지 않을 때 가장 먼저 할 일은 문제가 내 쪽 네트워크나 설정에 있는지, 아니면 클라우드 사업자 쪽 장애인지를 가려내는 것이다. 대부분의 사업자는 서비스 상태를 실시간으로 보여주는 페이지를 운영하므로, 이곳에서 장애 여부와 영향 범위를 먼저 확인하는 것이 순서다. 사내 시스템에서만 문제가 보인다면 원인이 사업자가 아니라 내부 설정이나 연동 구간에 있을 가능성도 함께 살펴야 한다.
사업자 쪽 장애로 확인되면, 다음으로는 영향을 받는 서비스 범위를 좁혀서 파악해야 한다. 전체 서비스가 멈춘 것인지, 특정 기능이나 특정 지역만 영향을 받는 것인지에 따라 대응 방식이 달라지기 때문이다. 이 단계에서는 임직원이나 고객에게 상황을 알리는 절차, 대체 업무 수단으로 전환하는 절차를 미리 정해 둔 매뉴얼대로 움직이는 것이 혼선을 줄이는 방법이다.
흔히 하는 오해
클라우드에 데이터를 올려두면 장애나 손실 걱정이 없다고 생각하는 경우가 있는데, 이는 사실과 다르다. 클라우드 사업자는 인프라의 가용성을 관리하지만, 이용자가 직접 올린 데이터의 백업이나 복구 정책은 별도로 이용자가 설정해야 하는 경우가 대부분이다. 서비스 약관에 명시된 책임 범위를 확인하지 않은 채 막연히 안전할 것이라고 여기는 것이 가장 흔한 오해다.
또 하나는 여러 서비스를 같은 사업자, 같은 지역에 몰아 두고도 이중화가 되어 있다고 착각하는 경우다. 물리적으로 같은 데이터센터나 같은 지역에 자원이 몰려 있으면, 그 지역에 문제가 생겼을 때 이중화한 자원도 함께 멈출 수 있다. 진짜 이중화는 지역이나 사업자를 분산하는 구조까지 포함해야 의미가 있다.
해외 제도와 국내 제도는 다르게 봐야 한다
해외 일부 사업자는 서비스 장애 시 이용 요금 일부를 크레딧으로 환급하는 방식의 약관을 운영하기도 하는데, 이는 각 사업자와 이용자 사이의 개별 계약 조건에 따라 정해지는 것이지 법으로 정해진 공통 기준이 아니다. 국내 사업자의 보상 방식이나 절차도 사업자마다, 계약마다 다르게 설계되어 있으므로, 해외 사례를 그대로 국내 상황에 대입해서 판단하면 안 된다. 계약서와 서비스 약관에 명시된 조항을 직접 확인하는 것이 유일하게 정확한 방법이다.
| 구분 | 확인할 내용 |
|---|---|
| 장애 감지 | 사업자 상태 페이지, 내부 모니터링 알림 |
| 원인 구분 | 내 쪽 설정 문제인지 사업자 쪽 장애인지 |
| 영향 범위 | 전체 서비스인지 특정 기능·지역인지 |
| 대응 절차 | 대체 업무 수단, 공지 절차, 복구 후 재점검 |
| 사전 대비 | 백업 정책, 이중화 구조, 계약상 책임 범위 |
클라우드 장애 대응은 사고가 난 다음에 급하게 만드는 것이 아니라, 평소에 백업과 이중화, 대체 업무 절차를 정리해 두고 계약서의 책임 범위를 파악해 두는 데서 시작된다. 실제 장애가 발생했을 때는 사업자의 공식 상태 페이지에서 장애 여부와 범위를 먼저 확인하고, 서비스 약관과 계약서에서 자신이 가입한 상품의 보상·복구 조건을 다시 살펴보는 것이 다음 순서다.
· · · · · · · · · ·
스페셜타임스는 AI 기술의 도움을 받아 더 빠르고 다양한 뉴스를 독자에게 전달하기 위해 노력하고 있습니다.