금요일 오후에 서버가 멈추고 여섯 시간 만에 복구됐다고 해 봅니다. 그날 결제는 통째로 날아갔고, 고객센터에는 전화가 쌓였습니다. 매출 손실은 수백만 원인데, 다행히 클라우드 계약에는 SLA라는 것이 붙어 있습니다.
SLA는 서비스 수준 협약, 즉 가용률이 약속한 선 아래로 떨어지면 요금을 얼마나 돌려주는지 정해 둔 문서입니다. 그런데 계산식에 실제 장애 시간을 넣어 보면 돌아오는 금액이 기대와 한참 다릅니다.
월 가용률은 분 단위로 계산되고, 경계선이 이미 정해져 있습니다
거의 모든 SLA가 같은 공식을 씁니다. 가비아 클라우드 서버 SLA의 표현을 그대로 옮기면 "월 가용률(%) = 100 × [1 − 장애 시간의 합(분) / 해당 월의 총 시간(분)]"입니다.
30일인 달은 총 43,200분입니다. 여기에 대입하면 구간 경계가 분 단위로 나옵니다. 99.9%선은 43.2분, 99.0%선은 432분(7.2시간), 95.0%선은 2,160분(36시간)입니다.
여섯 시간, 그러니까 360분 멈추면 월 가용률은 99.17%입니다. 하루 장사를 통째로 망친 사고인데 숫자로는 99% 위에 남습니다. 보상표의 맨 아래 칸에 걸린다는 뜻입니다.
AWS는 여섯 시간 장애에 월 요금의 10%를 돌려줍니다
AWS EC2의 Compute SLA는 인스턴스 단위로 가동률이 99.5% 미만 99.0% 이상이면 10%, 99.0% 미만 95.0% 이상이면 30%, 95% 미만이면 100%의 서비스 크레딧을 줍니다. 리전 단위는 99.99% 미만부터 10% 구간이 시작됩니다.
앞에서 나온 99.17%는 첫 칸입니다. 그 달 EC2 요금이 200만 원이었다면 크레딧은 20만 원입니다. 날아간 하루 매출이 500만 원이었다면 4%를 받는 셈입니다.
게다가 크레딧은 현금이 아닙니다. AWS 문서는 크레딧을 월 청구액의 비율로 계산해 이후 요금에서 차감한다고 적고 있습니다. 환불도, 다른 계정으로 이전도 되지 않습니다.
Azure와 가비아도 구간만 다를 뿐 구조는 같습니다
Azure 가상 머신은 구성에 따라 보장치가 갈립니다. Premium SSD나 Ultra Disk를 쓰는 단일 인스턴스는 99.9%, 가용성 집합은 99.95%, 두 개 이상의 가용성 영역에 나눠 배치하면 99.99%입니다.
크레딧은 보장치에 미달하면 10%, 99% 미만이면 25%, 95% 미만이면 100%입니다. 가비아 클라우드 서버는 99.0~99.9%에 10%, 95.0~99.0%에 25%, 95% 미만에 50%를 줍니다. 상한이 50%라는 점이 다릅니다.
세 곳 모두 여섯 시간 장애는 10% 칸입니다. 어느 클라우드를 쓰든 하루치 사고에 대한 답은 월 요금의 10분의 1로 같습니다.
웹호스팅은 크레딧 대신 배상액 공식을 씁니다
카페24 호스팅 이용약관 제40조는 방식이 다릅니다. 4시간 이상 연속으로 서비스가 중지되면 최근 3개월의 1일 평균요금에 장애 시간을 24로 나눈 값을 곱하고, 거기에 다시 3을 곱한 금액을 배상합니다.
월 3만 원짜리 웹호스팅에서 여섯 시간 장애가 났다고 해 봅니다. 1일 평균요금 1,000원에 0.25를 곱하고 3을 곱하면 750원입니다. 그날 매출이 얼마였든 배상액은 750원입니다.
기준 시간을 못 넘기면 0원이라는 점도 봐야 합니다. 3시간 50분 장애는 4시간에 미치지 못하므로 아예 배상 대상이 아닙니다.
SLA는 손해를 메워 주는 보험이 아니라, 못 쓴 시간만큼 요금을 깎아 주는 환불 규정입니다.
금액이 적은 이유는 기준이 매출이 아니라 요금이기 때문입니다
모든 계산식에서 비율을 곱하는 대상은 그 달의 서비스 이용요금입니다. 매출도, 집행한 광고비도, 사과 쿠폰 비용도 식에 들어가지 않습니다. 서버 요금이 매출의 1%라면 보상도 그 1% 안에서만 움직입니다.
제외 사유도 넓게 잡혀 있습니다. AWS SLA는 통제 범위 밖의 불가항력, 고객 측 장비와 소프트웨어 문제, 고객의 조치 지연으로 생긴 중단을 가용률 계산에서 빼도록 적고 있습니다.
크레딧은 자동으로 들어오지 않고 기한이 지나면 사라집니다
AWS는 장애가 발생한 청구 주기 이후 두 번째 청구 주기가 끝나기 전까지 크레딧을 신청하라고 정해 두었습니다. 신청서를 넣지 않으면 아무 일도 일어나지 않습니다.
카페24 약관은 더 짧습니다. 배상 청구권은 사유를 안 날부터 3개월, 사유가 발생한 날부터 1년이 지나면 소멸합니다. 장애 시각과 복구 시각을 기록해 둔 쪽이 유리합니다.
그래서 외부 모니터링 서비스의 다운타임 로그를 따로 보관하는 습관이 필요합니다. 신청서에 첨부할 증거는 결국 고객이 만들어야 합니다.
SLA에는 이것이 유일한 구제수단이라고 못 박혀 있습니다
AWS Compute SLA에는 "this SLA sets forth your sole and exclusive remedies"라는 문장이 있습니다. 이 SLA가 유일하고 배타적인 구제수단이라는 뜻입니다. 크레딧을 받으면 계약서 안에서 더 청구할 근거는 남지 않습니다.
국내법에 기댈 여지도 생각보다 좁습니다. 클라우드컴퓨팅 발전 및 이용자 보호에 관한 법률 제29조는 손해배상 청구를 인정하지만, 요건이 "이 법의 규정을 위반한 행위"입니다. 단순 장애가 곧바로 여기에 들어맞지는 않습니다.
남는 손해는 외주·유지보수 계약서에 따로 적어야 합니다
클라우드사에서 못 받는 금액은 결국 시스템을 만들고 운영하는 회사와의 계약에서 다뤄야 합니다. 실무에서 받아 보는 표준 계약서에는 대개 아래 항목이 비어 있습니다.
- 장애의 정의와 측정 주체: 무엇을 중단으로 볼지, 누구의 로그를 기준으로 삼을지 적습니다.
- 복구 목표 시간과 초과 시 위약금: 시간당 정액으로 정해야 나중에 계산 다툼이 없습니다.
- 배상 한도: 월 유지보수비가 아니라 연간 계약금액을 기준으로 올려 협상합니다.
- 간접손해 면책의 예외: 중단으로 인한 일실이익을 한도 안에서 배상 대상에 포함시킵니다.
- 클라우드 크레딧 승계: 운영사가 받은 크레딧을 발주자에게 넘기도록 적습니다.
- 백업 주기와 복구 시연 의무: 주기를 어겼을 때의 대금 감액까지 함께 적습니다.
- 장애 보고서 제출 기한: 원인과 재발 방지책을 며칠 안에 낼지 숫자로 정합니다.
이 가운데 실제 입금액을 바꾸는 것은 위약금과 배상 한도 두 가지입니다. 나머지는 분쟁이 벌어졌을 때 사실관계를 정리해 주는 장치에 가깝습니다.
계약서를 고쳐도 메워지지 않는 부분이 있습니다
한도를 크게 적어도 상대에게 지급 능력이 없으면 종이에 그칩니다. 개발사가 5인 규모인데 한도를 연 매출 수준으로 잡는 조항은 협상에서 거절당하거나, 받아들여져도 회수되지 않습니다.
책임 분계점도 미리 그어야 합니다. 리전 전체 장애처럼 운영사가 통제할 수 없는 원인까지 위약금 대상으로 묶으면, 그 위험이 견적에 얹혀 월 유지보수비로 돌아옵니다.
월 유지보수비가 50만 원 수준인 계약이라면 이 협상 자체가 남는 장사가 아닙니다. 그때는 배상 조항 대신 백업 주기와 복구 절차만 확실히 적어 두세요. 비슷한 판단 기준은 실무 가이드와 운영 노트에 정리하고 있고, 계약서 검토가 필요하면 Codeforest로 문의하세요. 원문 조건은 AWS Compute SLA에서 직접 확인할 수 있습니다.
결론: 보상은 요금에서 나오니 손해는 계약서에서 챙기세요
여섯 시간 장애의 정산 결과는 분명합니다. AWS와 Azure, 가비아는 월 요금의 10%, 카페24 웹호스팅은 750원 수준입니다. 날아간 하루 매출과 견줄 수 있는 금액이 아닙니다.
그러니 클라우드 SLA는 요금 환불 규정으로만 취급하고, 신청 기한만 놓치지 않으면 됩니다. 실제 손해를 메우는 문장은 복구 목표 시간, 위약금, 배상 한도, 크레딧 승계를 적어 넣은 외주·유지보수 계약서 안에 있습니다.
