1. 서비스 범위 확정 및 SLI 선정·계산식 정의

SLI (Sevice Level Indicator)란?

서비스 품질을 나타내는 실제 측정 지표이다. 모니터링 시스템에서 수집하는 메트릭이 SLI가 되며, 이 값이 SLO 목표를 달성하는지 지속적으로 추적한다.

SLI 유형과 측정 방법을 아래와 같이 정의한다.

SLI 유형	정의	측정 방법
가용성(Availability)	정상 응답 비율	성공 요청 수 / 전체 요청 수 x 100
지연시간(Latency)	요청 처리 시간	P50, P95, P99 백분위
에러율(Error Rate)	오류 응답 비율	5xx 응답 수 / 전체 응답 수 x 100
처리량(Throughput)	단위 시간당 처리 건수	초당 요청 수(RPS)

• 평균값은 극단적 값에 왜곡될 수 있어, 백분위를 사용한다.

  • P50 : 전체 요청의 50%가 이 시간 이내에 응답. 일반적인 사용자 경험을 나타냄
  • P95 : 전체 요청의 95%가 이 시간 이내에 응답. 대부분의 사용자 경험을 대표
  • P99 : 전체 요청의 99%가 이 시간 이내에 응답. 거의 모든 사용자의 최악의 경험을 반영

• 참고자료 : https://newrelic.com/kr/blog/observability/what-are-slos-slis-slas

• 참고자료 : https://wikidocs.net/341086

---

2. 가용성·오류율·P95·P99 SLO 목표 설정

SLO (Service Level Objective)란?

SLI에 대해 팀이 합의한 목표 수치다. 근거 없이 "업계 표준" 수치를 그대로 가져오지 않고, 이미 실측한 서비스별 처리 용량과 우리 팀의 실제 제약(인프라 2명, on-call 체계 없음, GCP 크레딧 예산)을 근거로 정한다.

SLI	SLO 목표	근거
가용성	99.9% 이상 (월 43분 허용)	인프라 담당 2명이 상시 대기(on-call)하는 구조가 아니라, 장애 인지·복구까지 사람이 수동으로 대응하는 시간이 걸린다는 점을 감안했다. 설계 단계에서 지정한 99.9%(월 43분 허용)로 목표를 설정한다. Backend/Frontend를 2대(active-standby)로 구성한 것도 처리 용량이 아니라 이 가용성 목표를 지키기 위한 장치임을 재확인한다.
에러율	1% 미만	기존 3단계 설계에서 이미 판정 기준으로 쓰던 값과 동일하게 유지한다. 실측 결과(Backend 90RPS까지 오류율 0%, AI 비동기 3RPS부터 7.69%로 급증)를 보면, 이 기준을 넘는 시점이 곧 "포화 시작 지점"과 거의 일치해서 조기 경보 지표로도 유효하다.
지연시간 P95	500ms 이하 (API 공통)	기존 판정 기준과 동일. 실측 결과 v2 Peak RPS(30) 시점 Backend P95는 17ms로 목표 대비 약 29배 여유가 있어, 이 기준이 지금 트래픽 규모에서는 넉넉하다는 것도 같이 확인됐다.
지연시간 P99	1,000ms 이하 (API 공통)	이 항목은 아직 실측 데이터가 없다. 기존 부하테스트(backend_test.js 등)는 P95만 threshold로 걸어뒀고 P99는 수집하지 않았다. 우선 P95 목표의 2배를 잠정 목표로 잡아두고, 실제 P99를 측정한 뒤 이 문서의 목표치를 재조정한다.
처리량	서비스별 v2 Peak 이상 (Backend 30RPS, AI 동기 챗봇 6RPS, AI 비동기 2RPS, Chat 동시접속 330명, Frontend 무관)	이미 실측 완료된 v2 Peak 목표치를 그대로 SLO 하한선으로 사용한다.