SLA를 검수기준으로 - 가용성 숫자의 함정 (05/08)

AI 시대의 클라우드·인프라 발주 가이드 · Ep.05

99.9%는 안심의 숫자가 아니다.
한 달에 43분의 숫자다.

SLA를 검수기준으로 - 가용성 숫자의 함정 · HFC Consulting

---

코파일럿이 이틀 동안 침묵한 날, 계약서의 SLA가 그 이틀을 어떻게 계산하는지 물었던 브리핑이 있었다(Brief 23). 이번 화는 그 질문을 발주 실무의 언어로 끝까지 밀고 간다. 숫자를 읽는 법, 보상의 실체, 그리고 간격을 메우는 설계의 순서다.

SLA는 계약서에서 가장 숫자가 많은 페이지이고, 가장 잘못 읽히는 페이지다. 숫자가 크니 안심하고, 안심하니 읽지 않는다. 읽기는 장애가 난 다음 날에야 시작된다.

9가 하나 늘 때마다

가용성 숫자는 허용된 중단 시간으로 번역해야 의미가 보인다.

가용성	월 허용 중단	연 허용 중단
99.0%	약 7.3시간	약 3.7일
99.9%	약 43분	약 8.8시간
99.99%	약 4.3분	약 53분

숫자보다 중요한 것이 측정 조항이다. 무엇을 중단으로 세는가(전면 장애만인가, 성능 저하도인가), 어느 단위로 재는가(리전인가, 인스턴스인가), 무엇이 제외되는가(계획 정비, 불가항력, 고객 설정 오류). 같은 99.9%라도 측정 조항에 따라 전혀 다른 약속이 된다.

측정 단위의 차이는 실제 SLA 문서에서 그대로 확인된다. 대표적인 클라우드 SLA는 리전 수준과 개별 인스턴스 수준의 가용성을 별도 기준으로 약속한다. 리전 SLA가 99.99%라는 문장을 "내 서버가 99.99% 살아 있다"로 읽으면 오독이다. 리전 전체가 살아 있어도 내 인스턴스는 멈출 수 있고, 그 경우는 다른 기준과 다른 크레딧이 적용된다. 어느 단위의 약속이 우리 업무에 해당하는지부터 확인해야 한다.

크레딧은 보상이 아니다

SLA 위반의 대가는 대개 서비스 크레딧이다. 대표적인 클라우드 SLA는 월 가용성이 99.99% 아래로 내려가면 이용료의 10%, 99% 아래면 30%, 95% 아래에서 100%를 크레딧으로 준다(Amazon EC2 SLA). 뒤집어 읽으면, 한 달의 5%인 36시간이 멈춰도 돌려받는 것은 그 서비스 요금의 일부라는 뜻이다. 멈춘 36시간 동안의 영업 손실, 민원, 복구 인건비는 계산에 없다. 4화에서 본 책임 한계 조항이 그것들을 배제하고 있기 때문이다.

그 손실이 관념이 아니라는 것은 조사로 확인된다. 업타임 인스티튜트의 2026년 장애 분석에서 응답자의 57%가 최근 대형 장애의 비용이 10만 달러를 넘었다고 답했고, 5분의 1은 100만 달러를 넘겼다. 그리고 지난 9년간 공개 보고된 장애의 약 3분의 2는 클라우드·통신 등 제3자 서비스 제공자의 몫이었다(Uptime Institute, 2026). 장애는 남의 설비에서 나고, 손실은 내 조직에서 난다. 이 비대칭이 SLA의 본질이다.

SLA를 검수기준으로 바꾸는 법

출발점은 공급자의 숫자가 아니라 업무의 요구다. 이 업무가 몇 분까지 멈춰도 되는가를 먼저 정하고, 공급자 SLA가 그 요구에 못 미치는 간격을 설계로 메운다. 이중화, 대체 수단, 수동 절차가 그 간격의 이름이다. AI 서비스라면 간격이 더 넓다. 모델 API의 정지는 데이터베이스 정지와 달리 업무 절차 한가운데를 끊기 때문이다.

AI 서비스에는 가용성 숫자가 잡지 못하는 장애가 하나 더 있다. 품질 저하다. 서비스는 살아 있는데 응답이 느려지거나 오류율이 치솟는 상태는 대부분의 SLA에서 중단으로 계산되지 않는다. 업무 입장에서는 멈춘 것과 다르지 않은데도 그렇다. 그래서 AI 서비스의 SLA 요구서에는 가용성 외에 응답 지연과 오류율 지표를 별도 항목으로 넣고, 초과 시의 절차를 명시할 필요가 있다.

반론 — "표준 서비스의 SLA는 협상이 안 되는데, 요구서가 무슨 의미인가."

대응 — 요구서의 상대는 공급자만이 아니다. 공급자 SLA를 못 올리면 그 간격은 구성으로 올린다. 복수 리전 배치, 대체 모델 경로, 캐시 응답, 수동 절차가 그 수단이고, 전부 구축 사업의 과업으로 발주할 수 있는 항목이다. 요구서는 협상 문서이기 이전에 설계 입력 문서다.

SLA 검토 체크포인트 — 업무별 허용 중단 시간 정의 / 측정 단위·제외 조항 확인 / 크레딧 상한과 청구 절차(자동인가 신청인가) / 공급자 SLA와 업무 요구의 간격 목록 / 간격을 메우는 이중화·대체 절차의 과업화

멈춘 날의 발주자

운영 단계의 SLA 관리 체계는 SM 연재에서 다룬 틀(7기 1화)과 이어진다. 발주 단계에서 정한 숫자는 운영 단계에서 매달 검증되어야 한다. 크레딧 청구가 자동이 아닌 계약이라면, 청구하지 않은 위반은 없었던 일이 된다. 장애 기록과 청구 절차를 운영 과업으로 명문화하는 이유다. 실무에서는 장애 시각과 범위를 공급자 상태 페이지에만 의존하지 말고 자체 모니터링 기록으로 남겨야 한다. 크레딧 청구의 입증 책임은 대개 고객에게 있고, 기록이 없는 장애는 계약상 일어나지 않은 장애이기 때문이다.

SLA가 멈춘 날의 계산서라면, 다음 화는 떠나는 날의 계산서다. 들어갈 때는 보이지 않던 문, 출구 조항으로 간다.

본 글은 일반적인 정보 제공을 목적으로 하며, 개별 사안에 대한 법률 자문이 아닙니다. 구체적인 계약·법률 판단은 반드시 전문가의 자문을 받으시기 바랍니다.

📎 더 읽을거리

Uptime Institute 연례 장애 분석 2026 (보도자료) — 장애 비용 분포와 제3자 제공자 비중의 출처

Amazon EC2 서비스 수준 계약 (AWS) — 크레딧 구간 구조의 실제 원문

HFC의 관점

SLA 검토의 핵심은 공급자의 숫자를 업무의 언어로 번역하는 일입니다. HFC컨설팅은 업무 영향 분석, SLA 간격 진단, 이중화·대체 절차의 과업 설계까지 실무 자문을 제공합니다. 멈춘 날의 계산을 멈추기 전에 해 두고 싶다면 문의해 주십시오.

changks@hfcconsulting.co.kr

1영업일 이내 답변 · 주식회사 에이치에프씨 컨설팅 · 대표이사 장기석

---

📚 AI 시대의 클라우드·인프라 발주 가이드

◀ 이전 편: 클라우드 계약서 독해 - 약관은 협상 대상인가 (04/08)

다음 편 ▶ 종속 없이 사는 법 - 전환 비용과 출구 조항 (06/08)

연재 전체 보기 →