103. SLA (Service Level Agreement)

💡 핵심 인사이트
SLA(서비스 수준 협약)는 IT 서비스를 제공하는 측(클라우드 벤더, 외주업체)과 서비스를 받는 측(고객)이 맺는 가장 최상위의 비즈니스적/법적 계약서입니다.
SLO가 우리 팀의 '희망 목표'라면, SLA는 **"이 선(SLI 지표)을 밑돌면 우리가 당신에게 현금으로 위약금을 환불해 주겠다"**는 피도 눈물도 없는 엄격한 보증 수표입니다.

Ⅰ. SLA의 본질: "약속과 처벌"

AWS(아마존 웹 서비스) 같은 클라우드를 빌려 쓰는 기업 입장에서 생각해 봅시다. 우리 회사의 11번가 쇼핑몰 서버를 아마존에 맡겼는데, 블랙프라이데이 날 아마존 서버가 3시간 동안 터져서 수십억 원의 매출이 날아갔습니다. 이때 아마존이 "아이고, 저희도 99.9%(SLO) 목표로 열심히 했는데 죄송합니다. 다음엔 잘할게요."라고 말로만 때우면 고객은 분통이 터집니다.

이를 막기 위해 서비스 계약을 맺을 때 명시하는 것이 SLA입니다.

구조: "우리가 제공하는 서비스 지표(가용성)가 X 퍼센트 밑으로 떨어지면, 우리는 당신에게 Y 퍼센트의 요금을 배상(할인)하겠다."

Ⅱ. SLA의 핵심 구성 요소

훌륭한 SLA 문서에는 다음과 같은 항목이 모호한 형용사("최대한 빨리")가 아니라 컴퓨터로 잴 수 있는 명확한 숫자(SLI)로 박혀 있어야 합니다.

가용성 (Availability, Uptime): "월간 서버 접속 가능 시간 99.9% 보장"
응답 시간 (Response Time): "웹 페이지 로딩 2초 이내 보장"
MTTR (평균 복구 시간): "서버가 죽었을 때 연락 주면 1시간 이내에 무조건 고쳐서 원상 복구함"
패널티 조항 (Service Credits): 가장 중요. 위 가용성이 99.0% 밑으로 떨어질 경우, 다음 달 클라우드 사용 요금의 10%를 깎아주는 크레딧을 발행한다.

Ⅲ. SRE 관점에서의 SLA 아키텍처

앞서 배운 개념들을 총동원하여 하나의 아키텍처로 묶어봅시다.

SLI (지표): 모니터링 툴(Datadog)이 매초 감시하는 현재 내 서버의 가동률. (현재 99.95%)
SLO (내부 목표): SRE 팀과 개발팀이 합의한 우리 내부의 쫀쫀한 목표치. (99.9%)
SLA (고객 계약): 고객에게 법적으로 약속한 여유 있는 보증선. (99.5%)

만약 SLI가 계속 떨어져서 99.9% 선이 깨지면? SLO는 위반했지만, 아직 SLA(99.5%)까지는 방어막이 남아 있으므로 위약금은 물지 않습니다. 이때 SRE 팀은 에러 예산(Error Budget)이 바닥났음을 선언하고, 코드 배포를 강제로 멈추게(Freeze) 하여 뼈아픈 SLA 위반(재정적 타격)이 터지기 전에 선제적으로 시스템을 수술대 위에 올리는 것입니다.

📢 섹션 요약 비유: SLI가 자동차 계기판의 **'현재 속도(110km/h)'**이고, SLO가 내가 마음속으로 정한 **'과속 안 하겠다는 다짐(100km/h)'**이라면, SLA는 경찰이 들고 있는 **'법적 과속 단속 카메라 기준(120km/h)'**입니다. 내 다짐(SLO)을 어겨서 110km/h를 밟더라도 당장 벌금은 안 내지만 위험합니다. 하지만 120km/h(SLA)를 넘기는 순간 얄짤없이 10만 원짜리 벌금 통지서(위약금)가 날아오는 냉혹한 현실의 경계선입니다.