클라우드 SLA를 계약서로 읽는 법: SLO·에러버짓·보상 조항
SLI·SLO·에러버짓의 3단 구조부터 보안·지원·보상 조항까지, 클라우드 SLA 계약서를 구성하는 다섯 조항을 실무 관점에서 정리한다.
2026-08-13 · 최초 발행 2025-12-03
클라우드 컴퓨팅 Service Level Agreement(SLA)를 도입하는 핵심 의의는 서비스 가용성·성능·보안에 대한 가시성과 책임 경계를 계약으로 명확히 하는 데 있다. 비즈니스 연속성, 규제 준수, 비용-위험 균형을 운영하는 메커니즘이기도 하다. 멀티·하이브리드 클라우드가 퍼지면서 표준화된 측정·모니터링·보상 체계를 세워야 할 필요성이 함께 커졌다.
문서 하나에 담기는 핵심 개념
SLA(Service Level Agreement)는 제공자와 고객 간 서비스 수준 계약 문서로, 역할·책임·측정·보고·보상·예외 조항을 포함한다. SLO(Service Level Objective)는 이를 달성하기 위한 구체 목표값이다 — 예를 들면 월간 가용성 99.95%, p95 응답시간 300ms 이하 같은 식이다. SLI(Service Level Indicator)는 SLO 달성 여부를 판단하는 측정 지표로, 5xx 비율이나 성공 요청 비율, 지역별 지연시간이 여기 해당한다.
에러 버짓(Error Budget)은 1-SLO로 계산되는 허용 실패량이다. 99.9% 가용성이라면 월간 허용 중단 시간이 43.2분이라는 뜻이다. RTO/RPO는 재해 복구 목표 시간·시점으로 SLA의 연속성 요구와 정합성을 맞추는 장치이고, 공유 책임 모델은 제공자와 고객 간 보안·운영 경계를 명확히 하는데 IaaS·PaaS·SaaS에 따라 고객 책임 범위가 달라진다.
계약서에 실제로 들어가는 조항
가용성·성능 지표 체계는 가용성, 지연시간, 처리량, 오류율 같은 핵심 KPI를 명세하고 측정 창(월/분기)과 집계 방식(p90/p95/p99)을 명시한다. 계획된 점검·불가항력·고객 귀책 같은 제외 조건도 정의하며, 단일 리전과 다중 리전 구조는 가용성 계산 방식을 따로 명세해야 한다.
보안·컴플라이언스 범위는 암호화, 키 관리, 접근 통제, 감사로그 보존 기간 같은 최소 보안 기준과 금융·의료·공공 규제 준수, 데이터 주권 요건을 담는다. 취약점 대응 SLA는 크리티컬 패치를 24~72시간 이내에, 침해사고 통지는 72시간 이내에 하도록 명세하는 것이 일반적이다.
지원·에스컬레이션은 케이스 심각도(S1~S4)별 첫 응답 시간·해결 목표·연락 채널(24x7/영업시간)을 정의하고 RACI(Responsible, Accountable, Consulted, Informed)를 명확히 한다. 장애 조기 경보, 변경 공지 리드타임, CAB(Change Advisory Board) 연계 절차도 포함된다.
측정·검증·가시성은 SLI 수집원(서버측 텔레메트리, RUM, 외부 합성 모니터링)과 시간 동기화 기준을 정의하고 제3자 검증이나 감사 로그 제공 메커니즘을 포함한다. 월간 리포트 포맷, API 제공 여부, 데이터 보존 기간도 규정한다.
보상·예외·종료 조항은 위반 등급별 서비스 크레딧 산정식과 한도를 정의하고, 반복 위반 시 계약 해지·페널티·개선계획 요구 절차를 담는다. MSA·주계약과의 우선순위, 법적 관할, 분쟁 해결 방식도 여기서 정한다.
SLA는 어떻게 만들어지고 운영되는가
비즈니스의 RTO/RPO, 규제 요건, 예산·위험 한계, 사용자 경험 목표를 입력으로 받아 중요도 티어링, SLO 후보 산정, 아키텍처 적합성 검토, 법무·보안 리뷰, 프로바이더 협상을 거친다. 결과물은 서명된 SLA, 모니터링 대시보드, 경보·에스컬레이션 런북, 월간 리포트 템플릿이다. 합의에 실패하면 범위·비용을 재협상하고, 측정이 불가능하면 대체 SLI나 독립 합성 모니터링을 적용하며, 반복 위반은 RCA와 개선계획을 필수화한다.
계약은 실제로 어떻게 다른가
금융 거래 시스템의 멀티 리전 액티브-액티브 구성은 SLO를 99.99% 가용성, p99 지연 150ms 이하로 잡는다. 이중화 라우팅, 합의형 DB, 카나리 배포로 에러 버짓을 지키고, 합성 모니터링과 고객 여정 RUM을 병행 측정하며, 리전이 단절되면 자동 페일오버로 RTO 5분 내 복구를 목표한다.
B2B SaaS 구독형 서비스는 월 99.9% 가용성, API p95 300ms, 웹훅 재시도 보장을 SLO로 두고 요청 재시도와 Idempotency 키로 일관성을 유지한다. 고객별 테넌트 격리와 심각도 기반 24x7 지원 SLA를 운영한다.
데이터 분석 PaaS는 배치 완료 시간 99%를 30분 이내, 대기열 처리율 95%를 5분 내로 잡고 스팟·온디맨드 혼합과 스케일 아웃 정책을 연동한다. 대규모 이벤트 기간에는 임시 SLO 조정과 크레딧 기준을 사전 합의로 적용한다.
숫자 하나가 갖는 무게
30일 기준으로 보면 허용 중단 시간의 격차가 크다. 99.9%는 약 43.2분, 99.95%는 약 21.6분, 99.99%는 약 4.32분까지 줄어든다. 에러 버짓 기반으로 변경 속도를 조절하면 배포 실패율이 20~40% 줄어드는 것으로 보고되고, 측정·보고를 표준화하면 RCA 리드타임이 30% 이상 단축되며 규제 감사 대응 시간도 함께 줄어든다. 반복 위반 시 자동 크레딧 정산과 개선계획을 강제화하는 공급자 관리 체계까지 갖추면 서비스 품질이 구조적으로 안정된다.
모범사례와 트레이드오프
모니터링은 공급자 메트릭과 외부 합성 모니터링을 병행하는 게 안전하다 — 비용은 늘지만 독립 검증을 확보할 수 있다. 지표는 핵심 사용자 여정 중심으로 5~7개에 집중하는 편이 낫다 — 단순성을 얻는 대신 상세 진단력은 떨어진다. 에러 버짓이 소진되면 배포를 동결하고 품질 개선에 집중하는 정책은 출시가 늦어지는 대신 장기 신뢰성을 높인다. 리전·존을 분산하면 고가용성은 쉬워지지만 데이터 일관성 복잡도와 비용이 늘어난다. 계약에는 예정된 점검·고객 귀책 제외 조항을 명확히 해야 분쟁이 줄지만, 고객이 체감하는 가용성은 오히려 낮아 보일 수 있다.
서비스 모델마다 다른 기준선
| 지표 | IaaS | PaaS | SaaS |
|---|---|---|---|
| 성능 | 인스턴스·네트워크 선택에 따른 가변성 높음 | 런타임 관리형 최적화, 튜닝 여지 제한 | 애플리케이션 최적화 내장, 사용자 제어 최소 |
| 확장성 | 수동/정책 기반 오토스케일 옵션 제공 | 수평 자동확장 성숙도 높음 | 내부 자동 확장, 외부 확장 제어 어려움 |
| 일관성 | 스토리지/DB 선택에 따라 강/최종 선택 | 매니지드 서비스 제약 내 일관성 옵션 제공 | 기능 수준에서 일관성 보장, 세부 제어 불가 |
| 안정성 | 99.5~99.99% 구성 가능(설계 의존) | 99.9~99.99% 제공 일반 | 99.9~99.99% 공표 빈도 높음 |
| 운영 편의 | 고객 책임 범위 큼 | 런타임·패치 제공자 책임 확대 | 고객은 설정/데이터/접근 제어 중심 |
Prometheus로 에러버짓 소진을 감시하려면
전제조건은 Prometheus 2.47 이상과 Alertmanager, 합성 체크 지표(http_success_total, http_requests_total) 수집 환경이다. 아래는 28일 가용성 SLO(99.9%)에 대한 에러 버짓 소진 경보를 구성하는 예시다.
# recording rule: 28일 이동 창 성공 비율
groups:
- name: slo-availability
interval: 1m
rules:
- record: slo:availability_ratio_28d
expr: sum_over_time(http_success_total[28d]) / sum_over_time(http_requests_total[28d])
# alert: 에러 버짓 임계치 경보(버짓 < 20%)
- name: alerts
rules:
- alert: SLOErrorBudgetBurn
expr: (1 - slo:availability_ratio_28d) > 0.001 * 0.8
for: 15m
labels:
severity: critical
annotations:
summary: "SLO 에러 버짓 소진 임계치 초과(28일 창)"
runbook: "https://internal.example.com/runbooks/slo-burn"측정 가능한 목표(SLO)와 검증 가능한 지표(SLI), 명확한 책임·보상 체계가 갖춰지면 SLA는 운영 리스크 관리 장치로 작동한다. 에러 버짓 기반의 변경 속도 제어를 멀티 리전 설계와 결합하면 신뢰성과 혁신 속도의 균형을 잡을 수 있고, 표준화된 절차와 자동화된 가시성은 분쟁을 예방하며 규제·감사 대응 비용을 구조적으로 줄여준다.