SLO를 처음 정할 때 빠지는 함정

99.9%는 숫자가 아니라 감각이다

처음 SLO를 잡을 때 팀 전체가 “99.9% 하면 되지 않나요?” 로 모인다. 그 숫자가 왜 나왔는지 아무도 설명하지 못한 채로.

99.9%는 월 43분 다운타임이다. 직접 계산해보면 생각보다 넉넉해 보인다. 그런데 우리 서비스가 새벽 2시에 배포하고 매주 금요일 저녁에 트래픽이 몰린다면, 43분이 어느 시점에 소진되느냐가 전부 달라진다. 숫자는 같아도 체감은 완전히 다르다.
우리 팀은 올해 초 결제 서비스에 99.95% SLO를 적었다. 월 21분. 막상 지켜보니 배포 한 번에 롤링 재시작이 4~5분씩 먹혔다. 배포가 한 달에 6번이면 계산이 안 맞는다. 처음부터 배포 창을 제외할지 포함할지 정했어야 했는데, 그 논의를 미뤘다.
SLI를 먼저 정하기 전에 숫자부터 잡는 게 함정이다. “99.9%가 우리한테 현실적인가” 질문보다 “업계 표준이 99.9%잖아요” 가 먼저 나온다면, 그건 약속이 아니라 장식이다.

개발팀은 서버 응답 기준으로, 인프라팀은 로드밸런서 기준으로, 고객팀은 사용자 화면 기준으로 가용성을 본다. 세 숫자가 같은 날이 별로 없다.

우리가 겪은 사건 하나. 로드밸런서 health check는 200을 내뱉는데 실제 API 응답 바디에 {"status": "error"} 가 섞여 나왔다. 인프라 대시보드는 초록, 슬랙에는 장애 신고가 쌓였다. 그날 SLO는 위반했나 안 했나? 회의가 1시간 넘게 걸렸다.
SLI 정의에 “무엇을 기준으로 성공으로 본다” 를 문서에 한 줄 써야 한다. HTTP 200이 기준인지, 200이면서 응답 바디에 error 필드가 없는 게 기준인지. 이걸 안 적으면 장애가 났을 때 측정 기준을 두고 싸우게 된다.
지금은 SLI 정의 문서 맨 위에 “이 지표를 어느 계층에서 수집하는가” 한 줄을 강제로 넣는다. 클라이언트 사이드인지 서버 사이드인지, 합성 모니터링인지 실사용자 트래픽인지. 안 적힌 SLI는 리뷰에서 반려한다.

Error Budget 개념을 도입하면 팀이 무서워한다. 그런데 무서워하는 이유가 보통 “우리가 써도 되나?” 라서다.

올해 3월, Error Budget이 월 50% 소진됐을 때 누가 결정권을 갖는지 몰라서 배포를 멈췄다. 기능팀은 릴리즈를 하고 싶고, SRE는 멈추자고 했다. 에스컬레이션 라인이 없으니 반나절 동안 아무것도 못했다.
Error Budget Policy를 SLO 문서랑 같이 쓰지 않으면 Budget은 숫자일 뿐이다. “Budget의 몇 퍼센트가 소진되면 누가 무엇을 한다” 를 미리 적어야 한다. 30% 소진 시 배포 속도 조절, 50% 소진 시 기능 배포 동결, 100% 도달 시 서비스 오너에게 에스컬레이션. 이 세 줄이 없으면 Policy가 아니라 그냥 모니터링이다.
지금 우리 팀은 Error Budget Policy를 SLO 정의 PR에 같이 올리는 걸 규칙으로 박았다. SLO 문서만 머지되고 Policy 없이 운영하다 사고 났던 경험 때문이다.

SLO를 엔지니어링팀이 만들고 Product에 공유하는 흐름이 대부분이다. 공유가 동의로 바뀌는 순간이 없다.

작년 말, 우리 팀이 검색 서비스 SLO를 95%로 잡았다. Product 팀에 슬랙으로 링크 하나 던졌다. 3개월 뒤 검색 장애가 났을 때 PM이 “이 서비스가 95%였어요?” 라고 물었다. 동의한 게 아니었다.
SLO는 엔지니어링 팀 내부 기준이 아니라 서비스에 대한 약속이다. 약속이라면 상대방이 내용을 이해하고 사인한 상태여야 한다. 숫자 하나가 아니라 “이 숫자가 깨졌을 때 고객에게 어떤 영향이 있나” 를 같이 확인해야 한다.
지금은 SLO 설정 때 Product, CS, 영업 각 1명씩 리뷰어로 넣는다. 기술적 내용을 다 설명하는 게 아니라, “이 조건이 깨지면 어떤 사용자 경험이 나빠진다” 한 문장을 문서에 적고 그것에 동의받는 방식으로.

이게 제일 자주 보이는 간극이다. SLO는 99.9%인데 알람은 CPU 80%, 메모리 70%, 에러율 5%로 따로 논다.

SLO 기반 알람을 안 걸면 SLO는 월말에 대시보드 보면서 “아 이번 달 지켰네” 확인하는 의식이 된다. 월 중간에 Budget이 절반 날아가도 아무도 모른다.
Burn Rate 알람을 안 쓰는 이유가 보통 “설정이 복잡하다” 인데, 막상 해보면 Prometheus + Alertmanager 기준으로 룰 5줄이다. 1시간 내에 Budget의 2% 이상 소진되면 알람, 6시간 내에 5% 이상이면 PagerDuty. 이것만 걸어도 실시간으로 SLO 소진 속도를 느낄 수 있다.
SLO 문서를 쓸 때 “이 SLO 를 지키기 위한 알람은 무엇인가” 를 같은 문서 안에 적게 했다. 알람이 없는 SLO 는 미완성으로 본다.

다음 SLO 리뷰 때, Error Budget Policy를 SLO 문서 PR에 같이 붙이지 않은 것들을 하나씩 찾아서 채운다.

🛒 이 글과 어울리는 추천 상품

위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.