SLO(Service Level Objective)란? AI 서비스가 지켜야 할 성능 목표

TL;DR

SLO(Service Level Objective)는 일정 기간 동안 서비스가 달성하려는 신뢰성과 성능 수준을 수치로 정한 목표입니다. AI 서비스에서는 요청 성공률과 응답 시간뿐 아니라 첫 토큰이 나오기까지 걸린 시간, 유해하거나 관련 없는 답변의 비율, 에이전트의 작업 완료율도 목표가 될 수 있습니다. SLO는 측정값인 SLI와 다르고 고객과 맺는 계약인 SLA와도 다릅니다. 좋은 SLO는 사용자가 실제로 느끼는 품질을 기준으로 측정 항목, 목표값, 기간을 함께 적습니다.

핵심 3줄 요약

• 핵심 1
  SLO는 측정 가능한 서비스 목표입니다. 무엇을 측정할지, 어느 수준을 목표로 할지, 얼마 동안 평가할지를 한 문장에 담습니다.
• 핵심 2
  AI 서비스는 속도와 가동률만 보면 부족합니다. 성공률·레이턴시와 함께 답변 관련성, 안전성, 작업 완료율처럼 사용자 결과에 가까운 지표도 살펴야 합니다.
• 핵심 3
  100%를 무조건 목표로 삼지 않습니다. 사용자가 필요한 수준과 운영 비용을 따져 목표를 정하고 허용 가능한 실패 범위인 오류 예산을 관리합니다.

이 글에서 다룰 내용

SLO를 한 문장으로 정의하면 무엇인가요?

한 문장 정의: SLO는 서비스 수준 지표인 SLI가 정해진 기간 동안 달성해야 할 목표값 또는 목표 범위입니다.

Google SRE는 SLO를 SLI로 측정하는 서비스 수준의 목표값이나 범위로 정의합니다. Google Cloud 문서도 SLO가 SLI, 성능 목표, 측정 기간으로 구성된다고 설명합니다.

예를 들어 “최근 30일 동안 고객 상담 AI 요청의 99%가 시스템 오류 없이 처리된다”는 SLO가 될 수 있습니다. 이 문장에는 성공한 요청의 비율이라는 측정 항목, 99%라는 목표, 최근 30일이라는 기간이 모두 들어 있습니다.

“응답이 빨라야 한다”처럼 방향만 적은 문장은 운영 원칙일 수는 있어도 완전한 SLO는 아닙니다. 무엇을 빠르다고 볼지, 몇 퍼센트의 요청이 그 기준을 만족해야 하는지, 어느 기간에 측정할지를 정해야 실제 결과와 비교할 수 있습니다.

한 줄 정리: SLO는 “좋은 서비스를 제공하자”는 다짐을 측정 가능한 목표로 바꾼 문장입니다.

왜 AI 서비스를 사용할 때 중요한가요?

첫째, 팀이 말하는 좋은 AI의 기준을 맞출 수 있습니다. 개발자는 오류율을 보고 사용자는 답변 속도와 해결 여부를 봅니다. 제품 담당자는 전환율이나 상담 이관률을 볼 수 있습니다. SLO를 정하면 어떤 사용자 경험을 우선 지킬지 합의하기 쉬워집니다.

둘째, 장애가 나기 전 품질 저하를 알아차릴 수 있습니다. 서비스가 완전히 멈추지 않아도 응답이 느려지거나 RAG가 관련 없는 문서를 가져오거나 에이전트의 작업 완료율이 떨어질 수 있습니다. Google Cloud의 AI/ML 신뢰성 지침은 요청 성공률, 응답 레이턴시, 관련 없거나 유해한 출력 비율, 에이전트 작업 성공률 등을 AI 시스템의 신뢰성 지표 예로 듭니다.

셋째, 출시 속도와 안정성의 균형을 데이터로 판단할 수 있습니다. SLO에 남은 오류 예산이 충분하면 통제된 배포를 진행할 여지가 있습니다. 오류 예산이 거의 소진됐다면 새 기능보다 복구와 안정화에 집중할 근거가 생깁니다.

넷째, 외부 AI API의 상태와 내 서비스의 상태를 구분할 수 있습니다. 모델 공급자의 API가 정상이어도 자체 프롬프트, 검색, 권한 확인, 후처리, 데이터베이스 중 하나가 느리거나 실패하면 사용자는 문제를 겪습니다. 공급자 SLA만으로 최종 제품의 신뢰성을 설명할 수 없는 이유입니다.

다섯째, AI 품질을 서버 정상 여부와 분리해 볼 수 있습니다. HTTP 요청이 성공했더라도 답변이 질문과 무관하거나 안전 기준을 어기거나 작업을 끝내지 못할 수 있습니다. 기술 지표와 결과 품질 지표를 함께 둬야 이런 실패가 가려지지 않습니다.

핵심 인사이트: AI 서비스가 온라인 상태라는 사실과 사용자의 일을 제대로 끝냈다는 사실은 다릅니다. SLO는 두 결과를 각각 측정하게 해 줍니다.

쉬운 예시로 이해해 볼까요?

감자나라ai님이 쇼핑몰 고객 상담 AI를 운영한다고 가정해 보겠습니다. 이 AI는 배송 조회, 반품 절차 안내, 상담원 연결을 처리합니다.

첫 번째 SLO는 가용성을 다룹니다. “최근 28일 동안 유효한 상담 요청의 99.5%가 시스템 오류 없이 응답을 받는다”처럼 정할 수 있습니다.

두 번째 SLO는 속도를 봅니다. “최근 28일 동안 응답의 95%에서 사용자가 첫 답변을 3초 안에 본다”처럼 첫 응답 시간을 목표로 삼을 수 있습니다.

세 번째 SLO는 업무 결과를 봅니다. “배송 조회 요청의 98%가 주문 정보를 정확히 확인하거나 안전하게 상담원에게 이관된다”처럼 성공 조건을 정할 수 있습니다. 이 지표는 테스트 정답, 업무 로그, 사람 검토 같은 별도 측정 절차가 필요합니다.

서비스가 빠르게 답했지만 잘못된 주문 정보를 보여 줬다면 속도 SLO는 만족해도 업무 성공 SLO는 실패합니다. 반대로 정확한 답을 줬지만 사용자가 오래 기다렸다면 품질 SLO는 통과하고 레이턴시 SLO는 실패할 수 있습니다. 여러 SLO를 나눠 보는 이유가 여기에 있습니다.

쉬운 비유: 학교 성적표에서 출석률, 시험 점수, 과제 제출률을 따로 보는 것과 비슷합니다. 하나의 숫자가 좋다고 모든 상태가 좋은 것은 아닙니다.

SLO는 어떻게 구성하나요?

1. 사용자가 중요하게 느끼는 결과를 정합니다

측정하기 쉬운 서버 CPU 사용률부터 고르지 않습니다. 사용자가 답을 받았는지, 기다림이 길지 않았는지, 맡긴 일이 끝났는지처럼 실제 경험에서 시작합니다. Google SRE도 측정하기 쉬운 항목보다 사용자에게 중요한 행동을 먼저 생각하라고 권합니다.

2. 그 결과를 나타내는 SLI를 고릅니다

SLI는 서비스 상태를 수치로 보여 주는 측정값입니다. 성공한 요청 비율, 특정 시간 안에 끝난 응답 비율, 관련 있는 검색 결과 비율, 안전 기준을 통과한 출력 비율, 사람이 개입하지 않고 끝난 작업 비율 등이 후보입니다.

3. 좋은 이벤트와 전체 이벤트를 정의합니다

성공률을 계산하려면 무엇이 성공이고 어떤 요청을 전체에 넣을지 정해야 합니다. 사용자가 취소한 요청, 잘못된 인증 정보, 내부 테스트 트래픽을 포함할지에 따라 결과가 달라집니다. 정의를 문서에 남겨야 팀마다 다른 숫자를 보지 않습니다.

4. 목표값과 측정 기간을 정합니다

99%, 99.9% 같은 목표 숫자만 적어서는 부족합니다. 7일인지 28일인지, 달력 기준 한 달인지 이동 기간인지 함께 정합니다. 사용자 피해와 과거 성능, 개선 비용을 보고 달성 가능하면서도 의미 있는 수준을 고릅니다.

5. 목표를 벗어났을 때 할 일을 연결합니다

오류 예산이 빠르게 줄면 경고를 보내고 배포 속도를 낮추거나 장애 원인을 조사합니다. 품질 SLO가 떨어지면 문제 대화 표본을 모아 프롬프트, 검색, 모델, 안전 필터를 나눠 확인합니다. 조치가 없는 SLO는 대시보드 장식에 그치기 쉽습니다.

실전 팁: SLO 문장은 “어떤 요청 중 몇 퍼센트가 어떤 조건을 만족하며 어느 기간에 측정되는가”를 다른 팀도 같은 방식으로 계산할 수 있게 적으세요.

비슷한 용어와 무엇이 다른가요?

SLI와의 차이

SLI(Service Level Indicator)는 실제로 측정한 서비스 수준입니다. SLO는 그 SLI가 도달해야 할 목표입니다. “성공 요청 비율이 이번 주 99.2%였다”는 SLI 결과이고 “28일 동안 99.5% 이상을 유지한다”는 SLO입니다.

SLA와의 차이

SLA(Service Level Agreement)는 서비스 제공자와 고객 사이의 약속이나 계약입니다. 목표를 못 지켰을 때 서비스 크레딧 같은 결과가 포함될 수 있습니다. Microsoft는 SLO를 자체 워크로드에 정하는 내부 신뢰성 목표로 설명하고 SLA의 숫자를 그대로 자사 SLO로 복사하지 말라고 안내합니다.

오류 예산과의 차이

오류 예산은 SLO를 지키면서 허용되는 실패 범위입니다. 가용성 SLO가 99%라면 같은 측정 기준에서 나머지 1%가 오류 예산의 출발점이 됩니다. 실패할 권리가 아니라 배포와 안정화 결정을 돕는 관리 기준입니다.

KPI와의 차이

KPI는 매출, 전환율, 유지율, 상담 비용처럼 사업 성과를 보는 지표입니다. SLO는 사용자가 필요한 서비스 수준을 기술·운영 관점에서 정한 목표입니다. 둘은 연결될 수 있지만 같은 뜻은 아닙니다. AI 응답 성공률이 떨어져 구매 전환율이 낮아질 수 있으므로 원인과 사업 영향을 함께 볼 수 있습니다.

모델 평가 지표와의 차이

정확도, F1 점수, 유해성 평가 점수는 모델이나 AI 결과의 품질을 측정합니다. 이런 값이 서비스 SLI의 재료가 될 수는 있지만 SLO에는 운영 기간과 사용자 트래픽, 전체 제품 경로가 함께 반영됩니다. 오프라인 평가 점수가 높다고 운영 SLO를 자동으로 만족하는 것은 아닙니다.

비교 정리: SLI는 실제 측정값, SLO는 내부 목표, SLA는 고객과의 약속, 오류 예산은 허용 범위, KPI는 사업 성과입니다.

AI 제품에서는 어떤 SLO를 정할 수 있나요?

챗봇과 생성형 AI

요청 성공률, 첫 토큰 시간, 전체 응답 시간, 관련 없는 답변 비율, 유해 출력 비율을 볼 수 있습니다. 답변 품질은 자동 평가만 믿지 말고 표본 사람 검토와 사용자 피드백으로 교차 확인합니다.

RAG와 사내 문서 검색

검색 결과가 정답 근거를 포함한 비율, 최신 문서를 가져온 비율, 권한 없는 문서가 노출되지 않은 비율, 출처 링크가 정상인 비율을 정할 수 있습니다. 최종 답변만 보면 검색 단계의 실패를 놓칠 수 있어 검색과 생성 지표를 나눕니다.

AI 에이전트와 자동화

작업 완료율, 사람 승인 없이 허용된 범위에서 끝난 비율, 잘못된 외부 실행 비율, 안전하게 중단하거나 사람에게 넘긴 비율을 봅니다. 자동화가 실패했을 때 무리하게 계속 실행하는 것보다 안전한 이관이 좋은 결과일 수 있습니다.

모델 학습과 배치 작업

정해진 시간 안에 끝난 작업 비율, 체크포인트 복구 성공률, 데이터 처리 성공률, 결과 전달 지연을 측정할 수 있습니다. 온라인 응답 서비스와 사용자가 기대하는 시간이 다르므로 같은 레이턴시 기준을 적용하지 않습니다.

한 줄 정리: AI SLO는 모델 호출 한 번보다 사용자의 요청이 검색·모델·도구·후처리를 거쳐 안전하게 끝나는 전체 경로를 봐야 합니다.

사용할 때 무엇을 주의해야 하나요?

첫째, 100%를 습관적으로 목표로 삼지 않습니다. Google SRE는 100%를 고집하면 비용이 커지고 배포와 개선이 지나치게 느려질 수 있다고 설명합니다. 사용자가 차이를 느끼는 수준과 실패의 피해를 기준으로 정해야 합니다.

둘째, 평균만 보지 않습니다. 평균 응답 시간이 좋아도 일부 사용자는 매우 느린 답을 받을 수 있습니다. 백분위수나 기준 시간 안에 끝난 요청 비율을 함께 보면 긴 지연이 평균에 가려지는 일을 줄일 수 있습니다.

셋째, 가용성과 정확성을 섞지 않습니다. 시스템 오류 없이 응답했다는 사실은 답이 맞다는 뜻이 아닙니다. 속도, 성공, 관련성, 안전성, 작업 완료를 필요한 만큼 분리합니다.

넷째, 공급자 SLA를 내 제품 SLO로 그대로 쓰지 않습니다. AI 제품은 모델 API 외에도 네트워크, 검색, 데이터베이스, 프롬프트, 도구, 자체 코드에 의존합니다. 사용자가 경험하는 전체 경로를 기준으로 별도 목표를 세웁니다.

다섯째, 측정 대상이 바뀌면 기준도 다시 검토합니다. 모델, 프롬프트, 사용자층, 언어, 트래픽 유형이 달라지면 예전 SLO가 현재의 사용자 경험을 제대로 나타내지 못할 수 있습니다.

여섯째, 품질 자동 평가를 절대 기준으로 두지 않습니다. 평가 모델과 규칙도 오류와 편향이 있을 수 있습니다. 중요한 안전·정확성 SLO는 사람 검토, 재현 가능한 테스트셋, 실제 사용자 결과를 함께 사용합니다.

주의: SLO를 달성했다는 사실은 모든 요청이 성공했다는 뜻이 아닙니다. 집계된 목표 안에 어떤 사용자와 어떤 실패가 포함됐는지 반드시 살펴야 합니다.

자주 묻는 질문

Q1. SLO는 개발자만 알아야 하나요?

아닙니다. 제품 담당자는 어떤 사용자 경험을 지킬지 정하고 운영팀은 측정과 대응을 맡습니다. 고객 지원과 보안 담당자도 실패 기준과 이관 절차를 만드는 데 참여할 수 있습니다.

Q2. SLO는 반드시 99.9%처럼 가용성으로 정해야 하나요?

아닙니다. 응답 시간, 작업 성공률, 데이터 최신성, 관련 없는 답변 비율, 안전한 이관 비율처럼 사용자에게 중요한 측정값을 목표로 정할 수 있습니다.

Q3. SLO와 SLA 중 어느 것을 먼저 정해야 하나요?

자체 제품을 운영한다면 사용자 요구와 실제 시스템 성능을 바탕으로 내부 SLO를 먼저 설계하는 편이 실무에 도움이 됩니다. 외부 공급자의 SLA는 의존 서비스가 약속한 최소 조건으로 참고하되 최종 제품의 목표를 대신하지는 않습니다.

Q4. SLO를 한 번 정하면 계속 유지해도 되나요?

정기적으로 다시 봐야 합니다. 사용자 요구, 트래픽, 모델, 제품 기능이 달라지면 목표와 측정 방식도 바뀔 수 있습니다. 기준을 자주 바꿔 과거 실패를 숨기지는 말고 변경 이유와 적용 시점을 기록합니다.

Q5. AI 답변 품질도 SLO로 만들 수 있나요?

가능합니다. 관련성, 사실성, 안전성, 작업 완료처럼 평가할 항목과 통과 기준을 먼저 정의해야 합니다. 자동 평가, 테스트 정답, 사람 검토, 사용자 피드백을 조합하고 평가 자체의 오류도 점검합니다.

출처

마무리

SLO는 AI 서비스의 신뢰성을 막연한 인상 대신 측정 가능한 목표로 다루게 해 줍니다. 측정 항목인 SLI, 목표값, 기간을 함께 적고 속도·가용성·답변 품질·작업 완료를 필요한 만큼 나누는 것이 출발점입니다.

감자나라ai님이 AI 제품이나 자동화를 점검할 때는 “서비스가 켜져 있는가” 다음에 “사용자가 원하는 일을 허용된 시간과 품질 안에서 끝냈는가”를 물어보세요. 이 질문을 수치와 기간으로 옮기면 운영에 쓸 수 있는 SLO가 됩니다.