운영 대시보드의 서버 상태는 모두 초록색인데 고객은 주문을 완료하지 못한다. 첫 화면과 상품 조회는 열리지만 마지막 결제 확인이 계속 실패한다. 서버 가동률만 보고 있으면 이런 장애는 늦게 발견된다. 고객은 서버 한 대를 사용하는 것이 아니라 목적을 이루기 위한 여러 단계의 흐름을 사용한다. 서비스 수준 목표(SLO)는 그 흐름에서 무엇을 ‘정상’으로 볼지 합의하는 방법이다.
Google SRE의 SLO 적용 안내는 SLO를 서비스의 신뢰성 목표로 설명하고, 사용자가 실제로 겪는 결과에 맞는 측정값을 선택하라고 권한다. 복잡한 대시보드부터 만드는 것이 아니라 업무에 중요한 성공 경로 하나를 고르는 데서 시작한다.
고객이 끝내야 하는 일부터 고른다
쇼핑몰이라면 주문 완료, B2B 업무 시스템이라면 승인 제출, 문의 사이트라면 문의 접수가 중요할 수 있다. 이 중 하나를 고르고 시작부터 완료까지의 경로를 그린다. 경로 중 어느 단계가 실패하면 고객이 목적을 이루지 못하는지 묻는다. 검색이 느려도 직접 URL로 들어갈 수 있는 서비스와 검색 없이는 어떤 상품도 찾을 수 없는 서비스는 같은 ‘검색 장애’를 다르게 평가해야 한다.
한 번에 서비스 전체의 단일 가용성 수치를 만들지 않는다. 읽기 요청과 쓰기 요청, 고객용 화면과 관리자 배치 작업은 실패 영향이 다르다. 서로 다른 작업을 한 숫자에 섞으면 트래픽이 많은 쉬운 요청이 중요한 결제 실패를 가린다. 우선 핵심 사용자 여정 1~2개에 대한 목표를 만들고, 필요할 때 범위를 넓힌다.
SLI는 실제 경험을 측정하는 비율이다
서비스 수준 지표(SLI)는 목표를 재는 구체적인 측정값이다. 예를 들어 ‘유효한 주문 제출 중 정해진 시간 안에 확정 결과를 받은 비율’은 고객 결과에 가깝다. 분자와 분모에 무엇을 넣는지 명확히 해야 한다. 사용자가 입력을 잘못해서 받은 검증 오류는 서비스 장애로 셀 것인가? 외부 결제사의 거절은 어떻게 다룰 것인가? 자동 테스트 트래픽이나 관리자의 수동 재처리는 포함할 것인가? 선택 자체보다 일관되게 문서화하고 실제 고객 영향을 반영하는지가 중요하다.
측정 위치도 결과를 바꾼다. 서버 내부 로그만 보면 요청이 서버까지 오지 못한 장애를 놓칠 수 있다. 로드밸런서, 브라우저, 모바일 앱, 주기적인 외부 합성 테스트는 각각 보이는 범위가 다르다. 모든 수단을 한꺼번에 붙이기보다, 선택한 사용자 여정의 실패를 실제로 관찰할 수 있는 위치를 고른다. Google SRE의 SLO 정의도 지표가 의사결정에 도움이 되는지를 강조한다.
SLO는 숫자 목표이고 SLA와는 다르다
SLI가 측정값이라면 SLO는 ‘정해진 기간 동안 이 비율을 어느 수준 이상 유지하겠다’는 내부 목표다. 예를 들어 최근 4주를 보거나 달력을 기준으로 한 달을 볼 수 있다. 목표 값은 경쟁사가 쓰는 유명한 숫자를 그대로 복사하지 않는다. 현재 성능, 고객 기대, 개선 비용, 장애의 업무 영향을 함께 보고 정한다. 외부 고객과 계약상 보상 조건을 약속하는 SLA는 별도의 법적·상업적 결정이며, SLO를 정했다고 자동으로 성립하지 않는다.
측정 기간이 짧으면 작은 사고에도 지표가 크게 흔들리고, 너무 길면 최근 악화를 늦게 본다. 배치 작업처럼 하루에 몇 번 안 일어나는 일은 요청 비율만으로 판단하기 어렵다. 이럴 때는 마감 시각까지 결과물이 나왔는지, 특정 기간의 데이터가 얼마나 늦었는지처럼 결과 중심의 지표가 맞을 수 있다. SLO는 운영팀의 취향이 아니라 고객이 기다릴 수 있는 시간과 업무 영향에 맞춰야 한다.
오류 예산은 출시와 안정성의 대화 도구다
SLO가 100%가 아니면 목표와 완전 무오류 사이에 허용된 실패 범위가 생긴다. 이것을 오류 예산이라고 부른다. 예산을 벌금처럼 쓰지 말고, 더 빨리 출시할지 안정화 작업을 우선할지 판단하는 신호로 쓴다. 예산이 충분하면 작은 사용자 집단에 새 기능을 출시해 배울 여지가 있다. 예산을 빠르게 소진하는 상황에서는 신규 출시보다 원인 분석, 안전장치, 자동 복구를 우선한다.
Google SRE의 오류 예산 정책 예시도 예산을 개발팀을 벌주는 수단이 아니라 안정성 개선의 우선순위를 정하는 장치로 다룬다. 각 회사는 무엇을 출시 중단으로 볼지, 보안 수정과 긴급 장애 복구를 어떻게 예외 처리할지 직접 정해야 한다. 예산 계산이 신뢰받으려면 SLI의 분모와 제외 기준을 제품·개발·운영이 함께 이해해야 한다.
경보는 원인보다 고객 영향을 먼저 알려야 한다
CPU 상승 경보만으로 당직자를 깨우면 실제 사용자 장애와 무관한 알림이 많아진다. 반대로 주문 성공률이 급격히 떨어지거나 지연이 쌓이면 우선 확인해야 한다. Google SRE의 SLO 경보 안내는 오류 예산 소모 속도와 측정 기간을 함께 고려하는 방식을 설명한다. 트래픽이 적은 서비스에서는 실패 요청 한 건이 비율을 크게 흔들리므로 단기 경보에만 의존하지 말고 실제 사례와 합성 테스트를 함께 본다.
장애가 끝나면 ‘서버가 언제 다시 초록색이 됐는가’만 기록하지 않는다. 어떤 사용자 여정이 얼마 동안 영향을 받았고, 고객이 다시 시도해야 했는지, 데이터가 복구되었는지 확인한다. SLO 측정이 실제 불편을 놓쳤다면 지표 정의를 고친다. 처음 만든 목표를 지키는 것이 목적이 아니라 고객 경험을 더 정확하게 표현하는 것이 목적이다.
첫 SLO 체크리스트
- 고객이 끝내야 할 핵심 업무 1~2개를 골랐는가?
- 성공·실패·제외 기준을 분자와 분모로 적었는가?
- 실제 고객 실패를 볼 수 있는 측정 위치인가?
- 측정 기간과 목표를 업무 영향으로 합의했는가?
- 오류 예산을 출시·안정화 결정에 연결했는가?
- 적은 트래픽과 합성 테스트의 한계를 고려했는가?
- 장애 후 지표가 놓친 고객 경험을 재검토하는가?
좋은 SLO는 멋진 소수점보다 팀이 같은 장애를 같은 의미로 이해하게 하는 문장에 가깝다. 서버가 살아 있는지보다 고객이 일을 끝낼 수 있는지를 기준으로 삼으면 운영의 우선순위도 선명해진다.
