서비스 SLI·SLO 지표 정하는 방법 5단계

핵심 요약
  • 사용자에게 중요한 여정부터 골라야 합니다.
  • SLI는 성공·전체 요청처럼 계산 가능해야 합니다.
  • SLO는 기간과 오류 예산을 함께 정합니다.

서비스 SLI·SLO는 모니터링 화면에 있는 지표를 골라 숫자를 붙이는 방식으로 정하지 않습니다. 먼저 사용자가 서비스에서 반드시 성공해야 하는 일을 정하고, 그 성공 여부를 수치로 측정하는 SLI(서비스 수준 지표)를 만든 다음, 측정 기간과 목표값인 SLO(서비스 수준 목표)를 합의해야 합니다. 아래 5단계를 따르면 지표가 실제 사용자 경험과 운영 판단에 연결됩니다.

SLI와 SLO를 사용자 경험에서 출발시키기

결제 성공 비율을 측정 지표로 삼고 일정 기간의 목표와 서비스 계약을 구분해 설명하는 모습

SLI는 서비스 품질의 한 측면을 정량적으로 측정한 값이고, SLO는 그 값이 일정 기간 동안 달성해야 할 목표입니다. 예를 들어 결제 서비스에서 “결제가 성공적으로 끝나는가”를 중요하게 본다면, 결제 성공 요청의 비율을 SLI 후보로 삼고 그 비율의 목표와 측정 기간을 SLO로 정할 수 있습니다. 반면 SLA(서비스 수준 계약)는 고객과의 약속 및 목표 미달 시의 결과를 포함할 수 있으므로, 내부 운영 목표인 SLO와 구분해야 합니다.

Google SRE 가이드는 추적할 수 있는 모든 메트릭을 SLI로 삼기보다 사용자가 원하는 것을 먼저 파악하고 대표 지표 몇 개에 집중할 것을 권합니다. 목표를 먼저 생각한 뒤 적절한 측정 지표를 거꾸로 찾는 접근도 유용합니다. Google SRE의 SLO 정의와 지표 선택 안내에서 지표 모델링과 목표 설정 원칙을 확인할 수 있습니다.

서비스 SLI·SLO를 정하는 5단계

핵심 사용자 여정 선정부터 SLI 측정과 오류 예산 대응까지 다섯 단계로 정리한 도식

1단계: 핵심 사용자 여정을 고릅니다

사용자가 서비스에서 얻으려는 결과를 짧은 여정으로 적습니다. 예를 들어 쇼핑 서비스라면 상품 탐색보다 “장바구니에서 결제를 마치고 주문 확인을 받는 과정”이 핵심일 수 있습니다. 사용 빈도만으로 정하지 말고, 실패했을 때 사용자가 목표를 달성하지 못하는지, 사업에 어떤 영향이 있는지도 함께 살펴보세요. 여러 기능을 한 지표에 뭉뚱그리면 어느 경험이 나빠졌는지 알아내기 어렵습니다.

2단계: 사용자 관점의 SLI 후보를 정합니다

여정마다 성공 여부를 측정할 수 있는 항목을 고릅니다. 사용자 대면 서비스에서는 가용성, 지연 시간, 오류율이 흔한 후보입니다. 저장 서비스는 데이터 내구성, 비동기 파이프라인은 처리량과 완료 지연이 더 중요할 수 있습니다. 정확성도 핵심입니다. 요청에 응답했더라도 결과가 틀리면 사용자가 기대한 성공으로 볼 수 없기 때문입니다.

  • 가용성: 정상 처리된 요청 수를 전체 유효 요청 수와 비교합니다.
  • 지연 시간: 정한 응답 시간 기준 안에 끝난 요청의 비율이나 백분위수를 봅니다.
  • 정확성·완료율: 결과 검증을 통과했거나 작업이 끝난 비율을 측정합니다.

3단계: 측정 정의를 문장과 계산식으로 고정합니다

“빠른 응답”이나 “오류가 적음”만으로는 팀마다 해석이 다릅니다. 어떤 요청을 포함하는지, 성공으로 보는 조건은 무엇인지, 어디서 측정하는지, 어떤 시간 단위로 집계하는지를 기록하세요. 이벤트 기반 SLI는 보통 성공한 이벤트 수를 전체 적격 이벤트 수로 나눕니다. 예를 들어 응답 시간이 기준 이내인 요청 수를 전체 적격 요청 수로 나누면 “기준 시간 안에 응답한 요청 비율”이 됩니다.

평균 지연 시간만 보면 소수의 매우 느린 요청이 가려질 수 있습니다. 사용자 경험에 긴 꼬리 지연이 중요하다면 p95나 p99 같은 백분위수를 함께 검토하거나, 기준 시간 이내 요청 비율을 SLI로 정의하세요. 분모에서 제외할 요청이 있다면 이유와 규칙을 명시해야 합니다. 사용자에게 실제로 발생한 실패를 편의상 제외하면 지표가 현실을 왜곡합니다.

4단계: 목표값과 기간을 이해관계자와 합의합니다

목표는 현재 시스템이 겨우 달성하는 수치를 복사해 정하지 마세요. 사용자의 기대, 제품 영향, 기술적 가능성, 운영 비용을 함께 고려해야 합니다. 처음부터 지나치게 빡빡한 목표를 정하면 불필요한 작업을 유발할 수 있고, 지나치게 느슨하면 중요한 저하를 놓칠 수 있습니다. 우선 측정 자료와 사용자 요구를 바탕으로 현실적인 목표를 제안하고, 제품·개발·운영 담당자가 같은 의미로 이해하는지 확인하세요.

기간은 사용 패턴과 의사결정 주기에 맞춰 정합니다. 짧은 창은 최근 문제를 빠르게 드러내지만 변동이 크고, 긴 창은 장기 성과를 보여주지만 급격한 저하를 늦게 드러낼 수 있습니다. 목표 문장에는 지표, 대상 범위, 기준, 측정 기간을 함께 넣으세요.

5단계: 오류 예산과 대응 규칙을 연결합니다

오류 예산은 SLO가 허용하는 실패분입니다. 비율형 SLO에서 목표가 99.9%라면 남은 0.1%가 해당 기간의 허용 실패 비율입니다. 이는 가용성 시간 기준과 요청 비율 기준이 서로 다른 계산임을 기억해야 합니다. 오류 예산을 소진하는 속도가 빨라질 때 어떤 배포나 운영 조치를 검토할지 팀 규칙으로 정하면 SLO가 대시보드 숫자에 머물지 않습니다.

서비스 유형 SLI 후보 정의할 때 확인할 점
사용자 대면 API 가용성, 지연 시간 적격 요청 범위와 응답 기준
결제·주문 흐름 성공률, 정확성 최종 완료와 중복·오류 판정
데이터 파이프라인 완료율, 처리 지연 완료 시점과 허용 지연 시간

실무 적용 전 점검할 기준

서버 응답부터 화면 렌더링과 결제까지 사용자 여정을 점검하는 모습

지표가 실제로 측정 가능한지 확인합니다

서버 지표만으로 사용자 경험을 완전히 대변하지 못하는 경우가 있습니다. 서버 응답은 성공했지만 화면 렌더링이나 외부 결제 단계가 실패할 수 있습니다. 사용자 여정의 핵심 결과를 직접 측정할 수 있는지 확인하고, 어렵다면 서버 측 지표가 무엇을 대리하는지 명시하세요. 저트래픽 서비스는 요청 수가 적어 짧은 구간의 비율이 크게 출렁일 수 있으므로, 창 길이와 경보 조건을 함께 검토해야 합니다.

측정 결과가 행동으로 이어지는지 살핍니다

SLI가 나빠졌을 때 담당자가 원인을 좁히고 조치할 수 있어야 합니다. 지표가 여러 서비스의 트래픽이나 오류를 한데 섞어 보여준다면, 서비스·지역·요청 종류별로 분석 가능한 구분이 필요할 수 있습니다. 반대로 지표가 너무 많으면 중요한 사용자 여정에 집중하기 어렵습니다. 핵심 SLO 몇 개를 우선하고, 진단용 보조 메트릭과 목표 지표를 구분하세요.

자주 묻는 질문

Q. SLI와 SLO는 각각 몇 개 정해야 하나요?

정해진 개수보다 핵심 사용자 여정을 빠짐없이 대표하는지가 중요합니다. 처음에는 핵심 여정별로 꼭 필요한 지표부터 시작하고, 중복되거나 실제 판단에 쓰이지 않는 지표는 정리하세요.

Q. 현재 성능이 좋은 수치를 그대로 SLO로 삼아도 되나요?

현재 성능은 목표 설정의 참고 자료지만 목표 자체의 근거가 되지는 않습니다. 사용자 기대와 사업 영향, 달성 가능성을 함께 검토해야 합니다. 현재 수치에 맞춰 목표를 고정하면 개선 여지를 막거나 불필요하게 엄격한 약속을 만들 수 있습니다.

Q. 평균 응답 시간만으로 지연 시간 SLI를 만들어도 되나요?

평균은 일부 느린 요청을 가릴 수 있어 사용자 경험을 충분히 설명하지 못할 수 있습니다. 지연 시간 분포와 p95·p99 또는 기준 시간 내 응답 비율을 살펴보고 서비스 특성에 맞는 방식을 고르세요.

Q. SLO를 고객에게 공개하면 SLA가 되나요?

공개 여부만으로 자동으로 SLA가 되는 것은 아닙니다. SLA는 보통 적용 범위와 측정 방식, 목표 미달 시 결과 등 고객과의 계약 조건을 포함합니다. 내부 SLO를 외부 약속으로 사용하려면 계약과 지원 체계를 별도로 검토해야 합니다.

참고자료

관련 글 보기