SLI, SLO, SLA 구분: 지표에서 목표, 계약까지

SLI, SLO, SLA는 한 글자 차이라 뭉뚱그려 쓰이기 쉽지만, 셋은 층이 다른 개념입니다. 한 줄로 가르면 SLI는 측정값, SLO는 내부 목표, SLA는 외부 계약입니다. 전편에서 SRE의 출발점이 신뢰성의 정량화라고 했는데, 그 정량화가 바로 이 세 층으로 이뤄집니다. 이 글은 정의 나열이 아니라 “우리 서비스에 실제로 정하는 순서"로 풀어 갑니다.

SLI: 무엇을 잴 것인가 #

SLI(Service Level Indicator)는 서비스 수준을 나타내는 측정값입니다. 핵심은 “사용자가 체감하는 것"을 재야 한다는 점입니다. CPU 사용률은 사용자가 체감하지 않으므로 SLI가 아닙니다(운영 지표일 뿐입니다). 사용자가 체감하는 것은 요청이 성공했는가, 얼마나 빨랐는가입니다.

실무에서 SLI는 대부분 비율로 정의합니다. “좋은 이벤트 ÷ 전체 이벤트"의 형태입니다.

• 가용성 SLI: 성공 응답(5xx가 아닌 응답) ÷ 전체 요청
• 지연시간 SLI: 300ms 안에 응답한 요청 ÷ 전체 요청
• 품질·정합성 SLI: 오류 없이 처리된 작업 ÷ 전체 작업 (배치·파이프라인)

지연시간을 “평균 응답 시간"이 아니라 “임계값 안에 든 요청의 비율"로 정의하는 것이 요령입니다. 평균은 다수의 빠른 요청이 소수의 느린 경험을 가리는 반면, 비율 방식은 “사용자의 몇 %가 좋은 경험을 했는가"를 직접 말해 줍니다. 측정 위치도 정해야 합니다. 서버 로그 기준인지, 로드밸런서 기준인지, 실제 클라이언트 기준인지에 따라 같은 서비스의 SLI가 달라집니다. 가능하면 사용자에 가까운 쪽(로드밸런서 이상)을 권합니다.

SLI는 두세 개면 충분합니다. 지표 열 개를 SLI로 선언하면 아무것도 목표가 아니게 됩니다.

SLO: 어느 수준을 약속할 것인가 (내부용) #

SLO(Service Level Objective)는 SLI에 목표치를 붙인 것입니다. “가용성 SLI ≥ 99.9% (30일 구간)“처럼 지표 + 목표 + 측정 구간의 세트입니다.

수치를 정하는 현실적인 방법은 위에서 내려오는 것이 아니라 아래에서 올라가는 것입니다.

1. 현재 성능을 먼저 잽니다. 지난 한두 달의 SLI가 사실상의 현재 수준입니다.
2. 사용자와 비즈니스가 요구하는 하한을 확인합니다. 이 서비스가 한 달에 몇 분 멈추면 실제로 문제가 되는가?
3. 현재 수준과 요구 하한 사이에서, 지킬 수 있는 값으로 시작합니다. 처음부터 공격적인 목표를 걸면 첫 달부터 위반 상태로 시작해 제도 자체가 무력화됩니다.

여기서 “나인(9)“의 감각이 필요합니다. 허용 다운타임으로 환산하면 목표의 무게가 보입니다.

나인 하나를 올릴 때마다 비용은 자릿수가 달라질 만큼 뜁니다. 그리고 100%는 목표가 될 수 없습니다. 사용자의 회선, 클라우드의 하한보다 높은 신뢰성은 사용자가 구분할 수도 없습니다. 이 “남겨 둔 실패의 몫"이 다음 편에서 다룰 Error Budget이 됩니다.

SLA: 어기면 배상하는 외부 계약 #

SLA(Service Level Agreement)는 고객과의 계약입니다. 수준을 어기면 크레딧·환불 같은 배상이 따르는 법적 문서이고, 그래서 숫자를 정하는 주체도 엔지니어링이 아니라 비즈니스·법무가 됩니다.

실무 규칙은 하나입니다. SLA는 SLO보다 느슨하게 둡니다. 내부 목표(SLO) 99.95%, 외부 계약(SLA) 99.9%처럼 층을 두면, SLO 위반이 곧바로 배상 사고가 되지 않고 대응할 완충이 생깁니다. SLO를 그대로 SLA로 파는 것은 완충 없이 목표를 계약으로 만드는 실수입니다. 클라우드 공급자들의 SLA(예: 배상 조건이 붙은 99.9%대)가 그들의 내부 목표보다 느슨한 값이라는 것도 같은 구조입니다.

거꾸로 읽는 법도 있습니다. 외부 서비스의 SLA는 “그 이하로 떨어지면 돈을 돌려준다"는 뜻이지 “그 수준이 보장된다"는 뜻이 아닙니다. 의존하는 서비스의 SLA가 우리 SLO보다 낮다면, 우리 SLO는 그 의존성만으로 이미 위태롭습니다. 직렬로 의존하는 컴포넌트의 가용성은 곱셈으로 떨어진다는 것(99.9% 둘이 직렬이면 99.8%)까지 계산에 넣어야 합니다.

세 층을 한 줄에 놓기 #

주문 API를 예로 세 층을 채우면 이렇게 됩니다.

• SLI: 5xx가 아닌 응답 비율(가용성), 500ms 내 응답 비율(지연), 로드밸런서 기준
• SLO: 30일 구간에서 가용성 99.9%, 지연 99% (내부 목표, 대시보드와 알림의 기준)
• SLA: 월 가용성 99.5% 미달 시 크레딧 배상 (고객 계약, 비즈니스가 결정)

흔한 실수 세 가지도 함께 적어 둡니다. 사용자가 체감하지 않는 지표(CPU, 노드 수)를 SLI로 삼는 것, 측정 없이 SLO 숫자부터 선언하는 것, SLO와 SLA를 같은 값으로 두는 것입니다.

정리 #

• SLI는 측정값, SLO는 내부 목표, SLA는 배상이 걸린 외부 계약입니다. 층이 다릅니다.
• SLI는 사용자가 체감하는 것을 “좋은 이벤트의 비율"로 정의하고, 두세 개로 좁힙니다. 지연시간도 평균이 아니라 임계값 내 비율로 잡습니다.
• SLO는 현재 실측과 비즈니스 하한 사이에서 지킬 수 있는 값으로 시작합니다. 나인 하나에 비용은 자릿수가 달라질 만큼 뜁니다.
• SLA는 SLO보다 느슨하게 둬서 완충을 만들고, 의존 서비스의 SLA는 곱셈으로 우리 목표를 깎는다는 것을 계산에 넣습니다.
• 100%는 목표가 아닙니다. 남겨 둔 실패의 몫을 예산으로 쓰는 방법이 다음 편의 Error Budget입니다.