SLO 뜻: 서비스 신뢰성 목표와 에러 예산을 엑셀/시트로 추적하기

SLO 뜻은 무엇인가요? SLO(서비스 신뢰성 목표, Service Level Objective)는 특정 서비스에 대해 설정하는 신뢰성 목표를 시간 구간 단위로 숫자로 표기한 것입니다. "30일 동안 요청의 99.9% 성공"이 바로 SLO입니다. 이 수치를 통해 팀은 언제 배포를 멈추고 안정성 개선에 집중할지를 알 수 있습니다. 그리고 바탕에 깔린 수학은 단순한 나눗셈이기 때문에, 스프레드시트라면 충분히 처리할 수 있습니다.

공식은 이미 가져왔습니다. 이제 여러분이 숫자만 집어넣으면 됩니다.

헷갈리는 세 글자, 정리해 드립니다

SLI, SLO, SLA. 회의 중에 자주 헷갈리는데, 짧은 버전입니다.

• SLI(서비스 수준 지표): 측정하는 것. 오류 없이 반환하는 요청의 비율, 300ms 내에 로드되는 페이지의 비율, 시간 내에 완료되는 작업의 비율.

• SLO(서비스 수준 목표): 그 측정치에 대한 목표. "SLI는 30일 동안 최소 99.9% 이상이어야 한다."

• SLA(서비스 수준 협약): 목표에 붙어있는 계약, 주로 돈. 환불이나 크레딧이 따라옵니다.

가장 간단한 테스트는 Google SRE 책에서 나온 것입니다: 목표를 못 달성하면 어떻게 되는가를 물어보세요. 계약상 아무것도 일어나지 않으면, 그것은 SLO이지 SLA가 아닙니다. 여러분의 SLO는 체결한 모든 SLA보다 더 엄격해야 하므로, 고객이 환불을 받기 전에 경고를 받을 수 있습니다.

스프레드시트 말로는: SLI는 측정값의 한 열이고, SLO는 목표가 들어있는 한 칸이고, SLA는 누군가 법무팀이 간직하고 있는 PDF입니다.

99.9%와 99.99%는 완전히 다른 약속입니다

9 하나가 늘어날 때마다 허용 다운타임이 열 배 줄어듭니다. 30일(43,200분)을 기준으로 각 목표가 허용하는 다운타임입니다:

• 99%: 1% 예산, 432분(7.2시간) / 30일

• 99.5%: 0.5% 예산, 216분(3.6시간)

• 99.9%: 0.1% 예산, 43.2분

• 99.95%: 0.05% 예산, 21.6분

• 99.99%: 0.01% 예산, 4.32분

마지막 줄이 함정입니다. 월 4분이라는 것은 인간이 알림을 받고 읽기도 전에 예산이 바닥난다는 뜻입니다. 대부분의 사내 툴, 대시보드, 소규모 SaaS는 이 정도까지 필요 없으며, 여기까지 가는 데 드는 비용도 상당합니다.

고객이 구체적으로 요청하지 않는 한 99.99%는 건너뛰세요. Google의 조언도 명확합니다: 나중에 더 엄격하게 만들 수 있도록 먼저 여유 있는 목표부터 시작하세요. 처음부터 너무 엄격한 목표는 모두가 그 숫자를 무시하도록 만듭니다.

에러 예산: 팀이 실제로 싸우는 숫자

에러 예산은 SLO가 허용하는 여유분입니다. 목표가 99.9%이면 예산은 0.1%입니다. 30일 동안 "나쁜" 시간 43.2분을 쓸 수 있다는 뜻입니다.

연료 게이지처럼 생각하세요. 위험한 배포가 연료를 소모합니다. 잘못된 데이터베이스 마이그레이션이 연료를 소모합니다. 새벽 3시 장애도 연료를 많이 소모합니다. 탱크가 가득 차 있으면 더 빨리 배포하세요. 비면 기능 추가를 멈추고 신뢰성을 다시 올리세요.

Google의 자체 정책은 구체적입니다: 4주 창에서 서비스가 예산을 초과 소모하면, P0 수정과 보안 패치를 제외한 모든 변경을 중단합니다. 예산은 처벌이 아니라 협상 도구입니다. 제품 매니저와 엔지니어가 감정이 아니라 같은 셀을 보면서 논쟁할 수 있게 해줍니다.

같은 서비스를 여럿이 만지면 할 가치가 있습니다. 홀로 운영하는 랜딩페이지 하나와 연락처 폼이면 오버일 수 있습니다.

사용자가 실제로 알아차릴 SLI를 선택하기

좋은 SLI는 사람이 실제로 느낄 수 있는 순간을 설명합니다. 세 가지가 대부분의 서비스를 커버합니다:

• 가용성(Availability): 성공하는 요청의 비율. 측정하기 쉽고 설명하기도 쉽습니다.

• 지연시간(Latency): 임계값보다 빠른 요청의 비율. "95% 검색이 300ms 내 반환"은 평균보다 훨씬 낫습니다. 평균은 느린 꼬리를 숨기거든요.

• 신선도(Freshness): 데이터 파이프라인이나 리포트의 경우, 마감 시간 전에 완료되는 실행의 비율. 스프레드시트 담당자에겐 안성맞춤입니다: "아침 판매 시트는 주중 99% 확률로 8시까지 업데이트된다."

SLI를 분수로 표현하세요: 좋은 이벤트 ÷ 전체 이벤트. 이 습관 하나가 모든 SLO를 한 칸으로 계산 가능하게 만들고, 장애 중이 아니라 장애 전에 "좋음"의 정의를 내리도록 강제합니다.

시간 구간은 30일 롤링이 표준입니다. 달력 월은 더 간단하지만, 달 말에 위험한 배포를 미루게 하기 십상입니다. 시트에서는 롤링 윈도는 Incidents 탭을 TODAY()-30일 이내로 필터하는 것만으로 됩니다: SUMIFS(Incidents!C:C,Incidents!A:A,">="&TODAY()-30).

구글 시트나 엑셀에서 SLO 추적기 만들기 (10분)

모니터링 플랫폼은 없어도 됩니다. 두 개 탭만 있으면 됩니다: Incidents와 SLO.

Incidents 탭에는 각 장애마다 시작 시간(A열), 끝 시간(B열), 지속 시간(C열)을 기록합니다:

=(B2-A2)*24*60

• B2와 A2: 장애의 끝 시간과 시작 시간.

• *24*60: 날짜 단위 차이를 분 단위로 변환합니다.

엑셀과 시트 모든 버전에서 작동합니다.

이제 SLO 탭입니다. A열에 레이블을 쓰고 B열에 공식을 넣으세요:

B1: 0.999                         (여러분의 SLO 목표)
B2: 30                            (시간 구간, 일)
B3: =B2*24*60                     (시간 구간의 총 분)
B4: =B3*(1-B1)                    (에러 예산, 분 단위)
B5: =SUM(Incidents!C2:C)          (지금까지의 다운타임)
B6: =1-B5/B3                      (실제 가용성)
B7: =B4-B5                        (남은 예산, 분 단위)
B8: =B5/B4                        (소모한 예산의 비율)

99.9% 목표라면 B3은 43200, B4는 43.2가 나옵니다. 12분 장애를 기록하면 B8은 27.8%를 표시합니다. 실제 셀에서는 이렇게 나타납니다.

B5의 C2:C 참고: 끝이 열려있는 범위는 시트 문법입니다. 엑셀이라면 Incidents!C2:C500 같은 고정 범위나 테이블 참조를 쓰세요.

상태 칸을 추가하면 숫자를 읽지 않아도 됩니다:

=IF(B8>=1,"배포 중단",IF(B8>=0.5,"주의","배포 진행"))

• B8>=1: 예산을 다 썼거나 초과했습니다.

• B8>=0.5: 절반 소모했으므로 위험한 변경을 검토하세요.

• 그 외: 초록불입니다.

임계값은 여러분이 정하세요. 50%는 출발점이지 절대의 법칙이 아닙니다.

자신의 시트 공식이 헷갈린다면? 평문으로 설명해 주면 도구가 대신 짜줄 수 있습니다.

분 대신 요청으로 세기

시간 기반 추적은 설명하기 쉽지만 거칠습니다. 새벽 4시 아무도 없을 때 5분 다운은 정오의 5분과 영향이 다릅니다. 진지한 팀들은 SLI를 요청으로 정의합니다.

요청 로그를 탭에 붙여넣되, HTTP 상태 코드가 B열에 오도록 합니다. 그러면:

=1-COUNTIF(B2:B,">=500")/COUNTA(B2:B)

• COUNTIF(B2:B,">=500"): 서버 오류를 반환한 요청을 셉니다.

• COUNTA(B2:B): 모든 요청을 셉니다. 1에서 오류 비율을 빼면 성공 비율입니다.

결과가 여러분의 가용성 SLI입니다. 목표 셀과 비교하면 SLO 전체가 한 줄입니다. 엑셀 2016과 365 모두 COUNTIF를 받으니, B2:B를 고정 범위로 바꾸기만 하면 됩니다.

솔직한 경고 둘입니다. 스프레드시트는 수백만 행에서 질식합니다. 원본 로그 대신 일일 합계를 내보내세요. 그리고 4xx 응답은 보통 사용자 실수이지 여러분의 장애가 아니므로, 그 규칙을 정해두고 적으세요.

번인율: 늦기 전에 경고하는 공식

예산의 27.8%를 소모했다는 것을 아는 것도 좋습니다. 지금 소모율이 달력 속도보다 빠르다는 것을 아는 것은 더 유용합니다. 그 비율이 번인율입니다.

=B8/(B9/B2)

• B8: 지금까지 소모한 예산의 비율.

• B9: 창 안에서 흐른 일수(직접 입력하거나 =TODAY()-B10, B10에 창 시작 날짜).

• B2: 창 전체 일수.

번인율 1은 창이 정확히 0 예산으로 끝난다는 뜻입니다. 1 이상이면 동결로 향합니다. 1 이하면 여유가 있습니다. 30일 창의 10일째에 이미 60%를 소모했다면 번인율은 1.8입니다. 이 숫자가 화면에 나가야 할 것입니다.

이것이 큰 모니터링 도구들이 번인율 알림에 쓰는 같은 개념입니다. 시트는 새벽 3시에 여러분을 호출하지는 않으니, 리포팅 계층으로 취급하고 알림 계층으로 삼지 마세요.

실제 숫자로 된 예입니다. SLO는 99.9% / 30일이므로 예산은 43.2분입니다. 1-8일: 나쁜 배포로 체크아웃 페이지가 14분 다운합니다. 예산의 32.4%, 창의 1/4에서 이미 소모했으니 번인율은 약 1.2입니다. 화염은 아직인데 시트가 "주의"라고 말하니, 다음 위험한 마이그레이션은 이단계 검토를 받습니다. 15일: 제공 업체 장애가 30분 추가합니다. 총 44분, 101.9% 소모. 상태 칸이 "배포 중단"으로 뒤집히고, 우선순위 대화가 감정이 아니라 숫자를 보면서 시작됩니다.

전체 가치가 바로 이것입니다. 9의 개수가 아니라 모두가 손가락질할 수 있는 한 셀입니다.

스프레드시트로는 언제까지만 할까요

이런 추적기는 서비스 1-2개와 주간 리뷰에는 좋습니다. 수십 개 서비스, 자동 데이터 수집, 분 단위 알림이 필요해지면 부숴집니다.

이제 제대로 된 옵저버빌리티 도구를 보세요. Datadog과 Grafana 모두 메트릭에서 직접 SLI를 당겨 예산을 그려주는 SLO 기능을 내장하고 있습니다.

Prometheus를 이미 쓰면서 오픈소스를 원한다면 Grafana. 직접 뭔가 운영하는 대신 비용을 내고 싶으면 Datadog. 어쨌든 월간 리뷰 데크용 시트는 간직하세요. 그 방에 있는 모든 사람이 열 수 있고 벤더 로그인이 필요 없거든요.

SLI 첫 세트를 서비스에 맞게 짜는 데 도움을 원한다면, 범용 어시스턴트가 나쁜 브레인스토밍 파트너는 아닙니다. 그것이 주는 모든 숫자를 확인하세요. 그럴듯하지만 가짜 목표를 기꺼이 지어낼 테니까요.

SLO를 쓸모없게 만드는 실수와 월요일에 할 일

Biscuit이 본 몇 가지 패턴은 망합니다:

• 현재 성과를 목표로 복사-붙여넣기. 지난 분기가 99.97%였다면, SLO도 99.97%로 잠그는 것은 지속할 수 없는 속도를 고착합니다.

• SLO가 너무 많음. 서비스당 2-3개. 그 이상이면 아무도 어느 것이 중요한지 기억 못 합니다.

• 쉬운 것 재기, 사람이 느끼는 것 아니기. CPU 사용률은 SLI가 아닙니다. 실패한 체크아웃입니다.

• 결과가 없음. 에러 예산 정책 없는 SLO는 소원입니다. 50%, 100%, 150% 소모 시 일어날 일을 미리 정하세요.

• 목표를 다시 보지 않음. 분기마다 검토하세요. 예산을 절대 다 못 쓴다면 목표가 너무 여유 있는 것이고, 항상 초과한다면 너무 빡빡한 것입니다.

이제 월요일 부분입니다. 한 서비스를 고르세요. 엔지니어가 아닌 사람도 따라갈 수 있는 한 문장으로 SLI 하나를 쓰세요. 99.5%나 99.9% 중 여유 있는 목표를 정하세요. 위의 두 탭을 만들고, 지난 달의 장애를 기록한 후, 예산이 뭐라고 하는지 보세요.

"우린 그걸 300% 소모했어"라면 모두가 피곤한 이유를 찾은 것입니다. "4% 소모했어"라면 목표를 더 엄격하게 하거나 더 빨리 배포하세요. 어느 쪽이든 이제 감정 대신 싸울 숫자가 있습니다.

Good boy. 이제 그 장애들을 기록하세요.