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

측정할 수 있다고 약속할 수 있는 건 아니다

처음 SLO를 잡을 때 팀 전체가 같은 실수를 한다. 메트릭 대시보드를 열고 “이미 측정하고 있으니 이걸 SLO로 쓰면 되겠다”고 생각하는 것.

막상 해보면 전혀 다른 문제다. 측정 가능성과 약속 가능성은 완전히 다른 축이다. 우리 팀은 2026년 초에 API 응답 p99 latency를 SLO로 선언했다가 두 달 만에 내부에서 조용히 폐기했다. Prometheus에서 숫자는 잘 나왔다. 그런데 그 숫자가 올라간 이유의 70%가 특정 배치 작업 때문이었고, 그 배치는 사용자 경험과 직접 관련이 없었다. 숫자는 빨간데 실제 사용자는 아무 불편도 없는 상황이 반복됐다. SLO 위반 알람이 뜰 때마다 온콜이 들여다보고 “또 배치네”하고 닫는 패턴. 알람 피로가 쌓이는 속도가 SLO 신뢰도가 무너지는 속도와 같았다.

사용자 여정을 안 보고 엔드포인트를 본다

지표를 고를 때 보통은 엔드포인트별로 나눈다. /api/search, /api/checkout, /api/profile 각각에 가용성 99.9%를 붙이는 식. 처음엔 깔끔해 보인다.

실제 사용자는 /api/search 하나만 쓰는 게 아니라, search → product-detail → add-to-cart → checkout 을 연달아 거친다. 각 엔드포인트가 99.9%여도 6단계를 다 통과할 확률은 수학적으로 약 99.4%까지 떨어진다. 이 간극을 처음엔 생각 못 했다.
/api/profile은 메인 플로우에 없는데도 엔드포인트가 존재한다는 이유로 SLO 대상이 됐다. 위반이 나도 아무도 심각하게 안 받아들였다. 엔지니어는 “이거 중요한 거야?”를 계속 묻게 됐고, SLO의 우선순위 기능이 완전히 사라졌다.
결국 우리는 핵심 구매 플로우 전체를 하나의 user journey SLO로 묶었다. 개별 지표보다 숫자는 낮게 나왔지만, 그게 실제 현실에 가까웠다.

에러 버짓을 숫자로만 선언한다

99.9%라고 정하면 한 달에 43분 다운을 허용한다는 뜻이다. 이걸 팀 모두가 알고 있었다. 그런데 막상 장애가 나면 아무도 에러 버짓을 떠올리지 않았다.

에러 버짓을 선언할 때 “이번 달 버짓 소진율”을 매주 팀 전체가 보는 자리에 올리지 않으면 숫자는 문서에만 사는 숫자가 된다. 우리 팀은 Slack에 매주 월요일 오전 9시에 버짓 소진율을 자동으로 올리는 봇을 붙였다. 처음 한 달은 아무도 반응 안 했다. 두 번째 달에 소진율이 68%를 넘어서자 PO가 먼저 배포 일정을 뒤로 미루자고 말했다. 그게 처음으로 에러 버짓이 실제 의사결정을 바꾼 순간이었다. 숫자가 의례적인 주석이 아니라 협상 도구가 되는 데 두 달이 걸린 셈이다.

외부 의존성을 SLO 밖에 놓는다

자사 서비스만 SLO 범위에 넣고 외부 API나 서드파티 SDK는 “우리 책임이 아니니까”라고 뺀다. 현실에서 이건 거의 항상 틀린 판단이다.

결제 게이트웨이 응답이 3초를 넘으면 사용자 입장에서 우리 서비스가 느린 거다. 어디서 느린지 사용자는 모른다. SLO에 외부 의존성이 빠져 있으면 실제 사용자 경험은 나쁜데 내부 지표는 녹색인 상황이 반복된다.
실제로 결제 게이트웨이가 주중 오전에 p95 응답을 4.2초까지 올린 사건이 있었다. 우리 SLO는 이상 없음. 고객 문의는 당일 평소의 3배. 이 불일치가 반복되면 팀 외부에서 SLO를 신뢰하지 않게 된다.
외부 의존성은 직접 제어할 수 없어도 측정은 할 수 있다. 제어할 수 없다고 측정도 안 하는 건 다른 이야기다. dependency latency를 별도 대시보드에 올리고 SLO 리뷰 때 함께 보는 것만으로도 현실 감각이 달라진다.

이해관계자 동의 없이 번호만 정한다

엔지니어링 팀이 99.95%를 정했다. PM은 “그게 뭔데요?”라고 물었다. 이 대화가 SLO 선언 후 세 달째에 처음 일어났다. 그 사이 SLO는 엔지니어만 아는 내부 문서였다.

SLO는 기술 지표가 아니라 약속이다. 그 약속의 상대방이 누구인지 정하지 않으면 숫자는 공허해진다. 우리는 SLO 초안을 만든 직후 PM·CS팀장·사업 파트너 한 명씩을 붙잡고 30분씩 설명했다. “99.9%가 무슨 뜻인지”보다 “한 달에 몇 분까지 서비스가 느려져도 우리가 허용할 수 있는가”를 일상어로 물었다. 그 대화에서 CS팀장이 “결제 관련은 10분도 너무 많다”고 말했고, 결제 플로우만 99.95%로 분리하게 됐다. 기술 논의만으로는 절대 못 나온 숫자였다.

다음 한 가지

다음 SLO 리뷰 때, 각 지표 옆에 “이 숫자가 나빠졌을 때 실제로 누가 제일 먼저 고통받는가”를 한 줄씩 붙여 놓는다.

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

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