SLO 뜻은? 1인 개발자를 위한 실전 가이드
요약
SLO 뜻은 서비스 신뢰도를 측정 가능한 지표로 나타낸 내부 목표치입니다. 예를 들어 30일 동안 요청의 99.9%가 성공하는 것이죠. 목표와 100%의 차이가 에러 버짓이고, 99.9%라면 한 달에 약 43분입니다. 1인 개발자는 99%에서 99.5%로 시작하고, 실제 사용자 경로를 측정하고, 잡음 대신 번 레이트로 알림을 받고, 버짓으로 배포할지 안정성을 고칠지 판단하면 됩니다.
SLO 뜻은 간단합니다. 서비스가 얼마나 자주 제대로 동작해야 하는지를 정해진 기간 동안 측정하는 목표 숫자예요. "30일 동안 요청의 99.9%가 성공한다"가 바로 SLO입니다. "사이트는 그럭저럭 괜찮은 것 같아요" 같은 막연한 느낌을 확인할 수 있는 숫자로 바꿔 주고, 기능 배포를 멈추고 안정성부터 고쳐야 할 때를 알려 줍니다.
이 개념을 쓰는 데 플랫폼 팀이 있을 필요는 없습니다. API 하나와 Postgres 데이터베이스 하나로 돌아가는 1인 개발자도 오후 한나절이면 쓸 만한 SLO를 만들 수 있어요. 이 글에서는 용어의 뜻, 숫자를 고르는 방법, 그리고 어디서 자주 틀어지는지를 정리합니다.
새벽 2시, 아무도 앱이 고장 났는지 몰랐다
주간 사용자가 400명인 사이드 프로젝트를 떠올려 보세요. 어느 날 밤 체크아웃 엔드포인트가 약 20분 동안 500 에러를 반환합니다. 아무도 트윗하거나 메일을 보내지 않아요. 사흘 뒤 지원 메시지 한 통을 보고서야 알게 됩니다.
그게 나쁜 일이었을까요? 목표가 없으면 답할 수 없습니다. 목표가 있다면 답할 수 있어요. SLO가 월 43분 정도의 실패를 허용하는데 이번 밤에 20분을 썼다면, 한 번의 나쁜 밤으로 허용량의 거의 절반을 쓴 셈입니다. SLO의 핵심이 바로 이것입니다. 막연한 느낌을 예산으로 바꿔 줍니다.
세 가지 약어, 용어집 말투 없이
SLI, SLO, SLA는 자주 헷갈립니다. 짧게 정리해 볼게요.
SLI(서비스 수준 지표)는 측정값입니다. "최근 30일 동안 HTTP 요청 중 5xx가 아닌 상태 코드를 받은 비율"이 SLI입니다. 전체 이벤트 중 좋은 이벤트의 비율이에요.
SLO(서비스 수준 목표)는 그 측정값의 목표치입니다. "이 비율이 99.9% 이상을 유지해야 한다"가 SLO예요. 내부 목표라서 직접 정하고 바꿀 수 있고, 어겼다고 누가 고소하지도 않습니다.
SLA(서비스 수준 협약)는 결과가 따르는 계약입니다. 보통 환불이나 크레딧이 걸려 있어요. 대부분의 사이드 프로젝트에는 SLA가 없고, 그래도 괜찮습니다. SLA 없이도 SLO는 운영할 수 있어요. 더 자세한 내용은 Google SRE 워크북의 SLO 구현 챕터가 표준 참고 자료입니다.
순서가 중요합니다. SLI를 먼저 고르고, 그다음 SLO를 정하세요. SLA는 유료 고객이 서면으로 요구할 때만 생각하면 됩니다.
에러 버짓: 작업 방식을 바꾸는 부분
99.9% SLO는 이벤트의 0.1%까지 실패해도 된다는 뜻이기도 합니다. 이 허용분이 에러 버짓이고, 이 아이디어에서 가장 쓸모 있는 절반입니다.
30일짜리 한 달 기준으로 99.9% 가용성이면 약 43분의 다운타임이 허용됩니다. 계산은 30일 × 24시간 × 60분 = 43,200분에 0.001을 곱하는 것입니다. 99% 목표면 약 7.2시간, 99.99% 목표면 약 4.3분입니다.
작은 프로젝트가 높은 목표를 잡으면 안 되는 이유가 이 마지막 두 숫자에 있습니다. 한 달에 4분이면 잘못된 배포 한 번과 롤백 한 번만으로 목표를 깨게 돼요. 실제로 사람들이 걸리는 지점은 이것입니다. 목표를 높게 잡을수록 시간이 제품 만들기보다 숫자 방어에 더 많이 들어갑니다.
버짓은 다음에 무엇을 만들지 정하는 기준도 됩니다. 버짓이 거의 남아 있으면 위험한 기능을 배포하세요. 버짓이 많이 줄었다면 불안정한 부분부터 고칩니다. 회의가 필요 없고, 대시보드에 있는 숫자 하나면 충분합니다.
측정 가능한 SLI 고르는 법
사용자가 "고장났다"고 느끼는 기준부터 생각하세요. 웹 앱이라면 대개 두 가지 질문으로 정리됩니다. 요청이 성공했는가, 그리고 충분히 빨랐는가.
대부분의 사이드 프로젝트는 SLI 두 개로 가치의 90% 정도를 잡을 수 있어요.
가용성: 좋은 요청 수를 전체 요청 수로 나눈 값. 여기서 좋은 요청은 5xx가 아닌 응답입니다.
지연 시간: 임계값 안에 응답한 요청의 비율. 예를 들어 요청의 95%가 500ms 안에 응답하는 식입니다.
지연 시간은 평균이 아니라 임계값 안에 들어간 요청의 비율로 적어야 합니다. 평균은 느린 꼬리를 가려 버리고, 사용자가 떠나는 곳이 바로 그 느린 꼬리입니다. 평균이 300ms라도 p99는 4초일 수 있어요.
가능한 한 사용자와 가까운 지점에서 측정하세요. 같은 VPC 안에서 /healthz를 핑하는 헬스 체크는 프로세스가 살아 있다는 것만 알려 줍니다. 사용자가 로그인할 수 있는지는 알려 주지 않아요. 측정을 하나만 할 수 있다면 로그인이나 결제 같은 실제 사용자 경로를 외부에서 찔러 보세요.
숫자 고르기: 생각보다 낮게 시작하세요
새 프로젝트의 솔직한 답은 99% 또는 99.5%입니다. 최근 30일 데이터를 보고 실제로 제공한 수준을 파악한 다음, 그보다 살짝 낮게 SLO를 잡으세요. 사용자가 불평하면 그때 조이면 됩니다.
1인 프로젝트를 위한 대략적인 기준은 이렇습니다.
수익 없는 취미용 도구: 99%면 충분합니다. 한 달에 약 7시간의 장애는 대부분의 사용자가 눈치채지 못해요.
고객 수십 명의 유료 SaaS: 제품이 시간에 얼마나 민감한지에 따라 99.5%에서 99.9% 사이.
고객이 업무 시간에 의존하는 서비스: 99.9%. 단, 약속하기 전에 롤백 경로를 먼저 테스트하세요.
직접 해 봤습니다. 최적은 아니지만 해 볼 만한 방식이에요. 100%를 매번 달성하는 SLO는 너무 낮게 잡힌 숫자이고, 매달 놓치는 SLO는 아무도 믿지 않는 숫자입니다. 가끔은 놓치는 것을 목표로 하세요. 버짓이 제 역할을 하는 때가 바로 그때입니다.
이건 가동 시간 모니터링에 기능만 더 붙인 것 아닌가요?
완전히 같지는 않아요. 겹치는 부분은 있습니다. 핑 모니터는 특정 분에 사이트가 응답했는지를 알려 줍니다. SLO는 한 달 동안 실제 사용자 요청 중 몇 퍼센트가 성공했는지, 그리고 그것이 다음 결정에 무엇을 의미하는지 알려 줘요.
2주 동안 핑 모니터는 매분 초록불인데, 느린 데이터베이스 쿼리 하나 때문에 로그인한 사용자 3%의 대시보드 페이지가 타임아웃 난다고 해 봅시다. 모니터는 모든 게 괜찮다고 말합니다. SLI는 지연 시간 목표를 놓쳤다고 말하죠. 월요일에 무엇을 할지 바꾸는 쪽은 SLI뿐입니다.
핑 모니터는 그래도 계속 유지하세요. 비용이 적고 전체 장애를 빨리 잡아냅니다. 다만 "정상 동작"의 정의가 아니라 입력값 하나로만 다루세요.
오늘 바로 적어 볼 수 있는 작은 SLO
시작하는 데 벤더가 필요하지 않습니다. 저장소에 SLO.md라는 파일을 만들고 아래처럼 적어 보세요.
service: checkout-api
window: 30d
slis:
availability:
good: http_status < 500
total: all requests except /healthz
latency:
good: response_time < 500ms
total: all requests except /healthz
objectives:
availability: 99.5%
latency: 95%
if_budget_burned:
- freeze non-urgent features
- fix the top error source first스택이 이미 요청 수를 내보내고 있다면, Prometheus 스타일의 가용성 SLI는 한 줄이면 됩니다.
sum(rate(http_requests_total{status!~"5.."}[30d]))
/ sum(rate(http_requests_total[30d]))그 비율을 목표와 비교하면 SLO 대시보드의 핵심이 완성됩니다. 나머지는 다 장식이에요. 패널 세 개면 충분합니다. 현재 SLI, 남은 버짓, 그리고 번 레이트 선 그래프입니다.
잡음마다 알림 말고, 번 레이트로 알림 받기
거의 모든 사람이 하는 실수는 에러율이 임계값을 넘을 때마다 알림을 받는 것입니다. 90초짜리 스파이크 때문에 새벽 3시에 깨고, 그 스파이크가 한 달 버짓의 0.2%를 날려 먹는 식이죠.
번 레이트가 이 문제를 해결합니다. 버짓을 쓰는 속도가, 기간이 끝날 때 버짓이 정확히 바닥나는 속도와 비교해 얼마나 빠른지를 묻습니다. 번 레이트 1은 한 달을 버짓 없이 끝내되 놀랄 일은 없다는 뜻입니다. 번 레이트 10이면 사흘이면 바닥난다는 뜻이에요.
한 사람이 운영하기 좋은 설정은 알림 두 개입니다. 빠른 알림은 1시간 동안 번 레이트가 10을 넘을 때 울려서 깨우는 용도예요. 느린 알림은 하루 동안 번 레이트가 2 안팎일 때 아침에 처리할 티켓이 되게 하는 용도입니다. 이 방식의 근거는 Google SRE 책의 SLO 챕터에 있고, 다중 기간 버전은 위의 워크북에 나옵니다.
운영자가 나 혼자일 때 어떤 도구를 쓸까
숫자가 중요해지기 전까지는 스프레드시트와 cron 작업으로 SLO를 연습할 수 있어요. 숫자가 중요해지면 도구가 값을 합니다. 기능 목록보다 스택이 더 많은 것을 결정하지만, 살펴볼 만한 도구는 세 가지입니다.
Grafana는 이미 Prometheus 메트릭을 내보내고 있는 사람에게 기본 선택지입니다. 무료 티어가 사이드 프로젝트에 넉넉하고, SLO 기능이 아마 이미 가지고 있는 데이터 위에서 돌아갑니다. 메트릭 파이프라인이 아직 없고 만들 생각도 없다면 건너뛰세요.
New Relic은 월 100GB 수집 무료 티어가 있고 플랫폼 안에 SLO 도구가 들어 있습니다. 에이전트 기반이라 설정이 간단해서, 설정에 시간을 들이기 싫은 사람에게 맞아요. 대신 무료 한도를 넘으면 비용을 예측하기 어려워집니다.
Datadog은 가장 완성도가 높고 가장 비쌉니다. 인프라, APM, 로그가 각각 따로 과금돼요. 주변에서 팀이 커지고 있다면 가치가 있지만, 누군가 비용을 대신 내주지 않는다면 1인 프로젝트에는 건너뛰세요.
어떤 도구를 고르든 첫날 SLO를 열다섯 개 정의하고 싶은 충동은 참으세요. 사용자에게 보이는 서비스 하나당 가용성 SLO 하나와 지연 시간 SLO 하나면 배우기에 충분합니다.
실제 숫자로 계산한 한 달
SLO가 30일 동안 99.5% 가용성이고, 한 달에 약 600,000건의 요청을 처리한다고 해 봅시다. 이 목표는 실패를 0.5%까지 허용하니, 버짓이 바닥나기 전까지 실패 3,000건을 허용하는 셈입니다.
9일째에 잘못된 마이그레이션 때문에 25분 동안 500 에러가 나고, 실패 요청 1,100건이 생겼다고 해요. 그 저녁 하루 만에 버짓의 약 37%를 쓴 겁니다. 17일째에는 서드파티 API가 타임아웃을 내면서 900건이 더 날아갑니다. 이제 약 67%를 썼고, 남은 날은 13일입니다.
여기서 버짓이 제 역할을 합니다. 당황할 필요는 없지만, 20일째에 계획해 둔 위험한 리팩터링을 배포하면 안 돼요. 대신 그 서드파티 호출에 타임아웃과 폴백을 넣고, 빠뜨렸던 마이그레이션 검사를 작성한 뒤, 리팩터링은 다음 달로 미룹니다.
결론은 실패가 나쁘다는 뜻이 아닙니다. 실패는 예상된 것이고 이미 비용에 반영돼 있어요. 이 숫자가 주는 것은 "지금 이 위험을 감당할 여유가 있나?"라는 질문에 대한 차분하고 공유 가능한 답입니다. 방 안에 있는 사람이 나 하나뿐이어도 말이에요.
숫자를 언제 다시 볼지
SLO는 분기마다 한 번, 또는 크게 놓쳤거나 버짓을 거의 쓰지 않은 달이 지난 뒤에 점검하세요. 두 달 연속 놓쳤다면 시스템에 실제 작업이 필요하거나, 목표가 현재 단계에 비해 공격적이었다는 뜻입니다. 둘 다 유용한 사실이에요.
유료 고객이 생기면 "고장났다"가 그들에게 무슨 뜻인지 물어보세요. 주간 리포트를 돌리는 고객은 토요일 밤의 짧은 장애가 아니라 월요일 아침을 신경 씁니다. 그 시간대에만 목표를 더 조이는 식으로 SLO에 반영할 수 있어요.
SLO를 쓸모없게 만드는 세 가지 실수
사용자가 느끼는 것 대신 측정하기 쉬운 것을 재는 실수. CPU 사용률은 SLI가 아닙니다. 사용자는 CPU가 40%인지 관심이 없어요. 페이지가 떴는지에 관심이 있습니다.
야망으로 목표를 정하는 실수. "다섯 개의 9를 원한다"는 말은 진지하게 들리지만, 데이터베이스가 작은 VM의 단일 인스턴스라면 아무 의미가 없습니다. 관찰된 현실로 SLO를 정하고, 시스템을 개선하고, 그다음에 숫자를 조이세요.
버짓을 쓰지 않는 실수. 매달 버짓을 98% 남기고 끝낸다면 배포 속도가 너무 느리거나 목표가 너무 느슨한 거예요. 쓰지 않은 버짓은 낭비된 위험 감수 능력입니다.
SLO에 가장 먼저 넣을 것은 무엇인가요?
망가지면 사용자가 바로 알아챌 엔드포인트 하나를 고르세요. 지난달에 실제로 제공한 수준보다 0.5포인트 낮게 목표를 잡고, 30일 뒤에 다시 확인하세요. 이 습관을 연습할 사이드 프로젝트가 필요하다면, 내 앱들을 위한 작은 가동 시간·지연 시간 대시보드가 좋은 주말 프로젝트가 됩니다. 여러분이 지금 가장 믿지 않는 서비스는 어느 것인가요?