6.1 서비스 수준 지표, 목표, 오류 예산

개요 및 동기

구글에서 개척되어 Site Reliability Engineering 책에 문서화된 사이트 신뢰성 엔지니어링(SRE) 규율은 이 주제가 직접 구축하는 용어를 기여했다: 서비스 수준 지표(SLI)는 서비스 건강의 직접 측정된 신호, 즉 요청 지연 시간, 오류율, 가용성이다. 서비스 수준 목표(SLO)는 그 지표의 목표 범위이며, 예를 들어 요청의 99.9%가 200밀리초 이내에 성공한다. 그리고 오류 예산은 허용된 미달, 즉 실패가 허용되는 요청의 0.1%이며, 제거해야 할 결함이 아니라 위험을 의도적으로 감수하는 데 사용될 수 있는 소비 가능한 자원으로 취급된다: 위험한 변경을 배포하거나, 실험을 실행하거나, 단순히 완벽한 신뢰성이 달성 가능하지 않으며 어느 지점을 넘어서면 그 비용만큼의 가치가 없다는 것을 받아들이는 것이다.

0을 향해 최소화할 숫자가 아니라 소비 가능한 자원으로서의 오류 예산이라는 이 마지막 아이디어가 이 주제에서, 그리고 아마도 이 부 전체에서 단일하게 가장 중요한 개념이다. 그것은 많은 조직을 괴롭히는 긴장을 해결한다: 엔지니어링은 기능을 배포하고 합리적인 위험을 감수하고 싶어 하고, 운영은 최대 안정성을 원한다. 공유되고 정량화된 오류 예산 없이는, 이것은 끝없고 정치적으로 격앙된 협상이 된다. 그것이 있으면, 단순하고 객관적인 규칙이 된다: 예산이 남아 있는 동안은 자유롭게 소비하고, 일단 소진되면 자동으로 속도를 늦추고 안정성 작업을 우선시하라. 이것은 철학적 불일치를 산술적 불일치로 바꾼다.

대규모 팀에게 SLO와 오류 예산은 신뢰성을 모든 팀이 막연한 죄책감을 느끼면서 조용히 충족시키지 못하는, 도달할 수 없고 명시되지 않은 절대치가 아니라 측정 가능하고 협상 가능하게 만드는 것이다. 엔터프라이즈 조직은 SLO를 사용해 팀 간 그리고 고객과의 명확하고 계약적인 기대치를 설정한다. 중요한 공공 인프라를 운영하는 정부 조직은 그것을 사용해 어떤 실제 시스템도 지속할 수 없는 불가능한 완벽함의 기준이 아니라 방어 가능하고 공개적으로 정당화할 수 있는 신뢰성 목표를 설정한다.

핵심 원칙

100% 신뢰성은 거의 모든 시스템에 대해 잘못된 목표다. 그것은 보통 달성 불가능하며, 어느 지점을 넘어서 그것을 추구하는 것은 의미 있는 사용자 혜택 없이 적극적으로 속도를 교환해 버린다.
SLO는 안심이 되는 소리로 선택된 임의의 둥근 숫자가 아니라 사용자가 실제로 알아채고 신경 쓰는 것을 반영해야 한다.
오류 예산은 신뢰성을 소비 가능한 자원으로 바꾸어, 엔지니어링과 운영 둘 다에게 언제 빨리 배포하고 언제 속도를 늦출지에 대한 공유되고 객관적인 규칙을 준다.
SLI는 가능한 한 사용자의 실제 경험으로부터 측정되어야 한다, 내부 시스템이 스스로 보고하는 건강 상태만이 아니라.
오류 예산 소진은 매번 일어날 때마다의 임기응변 논쟁이 아니라 미리 정해지고 합의된 대응을 촉발한다.

권장 사항

진정한 사용자 경험을 반영하는 SLI를 선택하라

사용자가 실제 문제를 경험하는 동안 “건강함”을 보고할 수 있는 내부 서비스 건강 점검만이 아니라, 가능한 한 실제 사용자 경험에 가깝게 측정된 지표를 선택하라: 엣지나 로드 밸런서에서 측정된 요청 성공률과 지연 시간. 사용자가 실제로 결코 알아채지 못하는 것, 즉 전체 요청이 여전히 실패하는 동안 내부 구성 요소가 기술적으로 가동 중인 것을 측정하는 SLI는, 그것을 계측하기가 아무리 쉽더라도 잘못된 것을 측정하고 있는 것이다.

임의의 둥근 숫자가 아니라 사용자가 실제로 필요로 하는 것에 근거해 SLO 목표를 설정하라

단순히 인상적으로 엄격하게 들린다는 이유로 “99.99% 가동 시간” 같은 목표를 설정하려는 반사적 충동을 물리쳐라. 대신 과거 인시던트 데이터, 사용자 조사, 그리고 신뢰성의 각 추가 증분을 달성하는 데 드는 입증된 비용에 근거해 사용자가 진정으로 알아채고 신경 쓰는 신뢰성 수준을 조사하라. 99.9%에서 99.99%로 가는 것은 흔히 99%에서 99.9%로 가는 것보다 훨씬 더 많은 엔지니어링 노력이 들며, 점점 줄어들고 결국 무시할 수 있는 사용자가 인지할 수 있는 혜택을 위해서이기 때문이다.

오류 예산을 소진에 대한 미리 정해진 대응을 가진 소비 가능한 자원으로 취급하라

SLO로부터 직접 오류 예산을 계산하고(30일에 걸친 99.9% 가용성 목표는 대략 43분의 허용된 다운타임을 허용한다) 그것에 맞서 지출을 지속적으로 추적하라. 예산이 소진되면 무슨 일이 일어나는지 특정 인시던트보다 미리, 사전에 합의하라: 흔하고 효과적인 정책은 기능 작업이 일시 중지되고 팀의 우선순위가 예산이 회복될 때까지 자동으로 신뢰성 작업으로 전환되는 것이다. 이 미리 정해진 규칙은 개별 인시던트마다 압박 아래서 트레이드오프를 다시 논쟁할 필요성을 제거한다.

오류 예산을 사용해 의도적이고 정보에 근거한 위험 결정을 내려라

건강하고 소비되지 않은 오류 예산은 비축할 것이 아니다. 그것은 합리적인 위험을 감수하고, 상승했지만 용인 가능한 위험을 가진 변경을 배포하고, 카오스 엔지니어링 실험을 실행하거나(자매 서적 software-engineering-guide의 카오스 엔지니어링 주제가 이것을 직접 다룬다) 더 위험한 아키텍처 변경을 받아들일 허가다. 예산이 존재하는 것은 구체적으로 의도적으로 소비되기 위해서이지 손대지 않은 채 보존되기 위해서가 아니기 때문이다. 결코 소비되지 않는 오류 예산은 지나치게 보수적인 팀이나 실제로 달성된 신뢰성에 비해 너무 느슨하게 설정된 SLO 중 하나를 시사하며, 둘 다 조사할 가치가 있다.

관성이 아니라 증거에 근거해 SLO를 주기적으로 검토하고 수정하라

몇 년 전에 설정된 SLO는 더 이상 현재 사용자 기대, 시스템 아키텍처, 비즈니스 우선순위를 반영하지 않을 수 있다. SLO를 정기적인 주기로 검토하여, 과거 달성된 신뢰성, 사용자 피드백, 그리고 그 목표가 다른 곳에서 더 많은 속도를 가능하게 하도록 조여질 수 있는 쉽게 충족되는 목표이거나 팀이 충족시키기를 사실상 포기한 비현실적인 목표가 아니라 여전히 의미 있는 트레이드오프 지점을 나타내는지 확인하라.

트레이드오프: 장단점

접근법	장점	단점
공식 SLO 없음(암묵적인 “가능한 한 신뢰성 있게”)	설정할 오버헤드 없음	속도와 안정성 사이의 끝없고 근거 없는 협상; 공유된 규칙 없음
열망적이고 매우 높은 SLO(99.99% 이상)	신뢰성에 대한 진지함을 신호함	흔히 불필요한 비용; 사용자가 실제로 알아채는 것을 넘어선 점점 줄어드는 수익
증거 기반이고 사용자 경험에 근거한 SLO	진정한 가치를 반영함; 방어 가능하고 달성 가능함	올바르게 설정하려면 실제 데이터와 분석이 필요함
미리 정해진 소진 대응을 가진 오류 예산	임기응변 협상을 제거함; 객관적이고 빠른 의사 결정	미리 정해진 규칙을 실제로 지키려면 조직적 동의와 규율이 필요함

핵심 긴장은 열망 대 달성 가능성이다. 높고 열망적인 SLO는 품질에 대한 진지함을 신호하는 것처럼 느껴지지만, 사용자가 실제로 알아채는 것을 넘어서 신뢰성을 추구하는 것은 진정한 혜택 없이 진짜 속도를 교환해 버리며, 팀이 결코 실제로 충족시키지 못하는 비현실적인 목표는 모두에게 SLO를 전혀 진지하게 받아들이지 않도록 가르친다. 열망이나 스코어카드에서 엄격해 보이려는 욕구가 아니라 실제 증거, 즉 사용자가 무엇을 알아채는지, 시스템이 과거에 무엇을 달성했는지, 각 추가 증분이 얼마나 드는지에 SLO를 근거함으로써 그 긴장을 해결하라.

팀과 논의할 질문

우리의 현재 SLO는 사용자가 실제로 알아채는 것에 대한 증거에 근거하고 있는가, 아니면 높은 숫자가 적절히 진지하게 느껴져서 열망적으로 설정되었는가? 가능하다면 현재 목표의 기원을 추적하고 그것이 실제 사용자 조사를 반영하는지 아니면 엔지니어링 직관만을 반영하는지 정직하게 평가하라.
우리는 오류 예산 소진에 대한 미리 정해지고 합의된 대응을 가지고 있는가, 아니면 그것이 일어날 때마다 트레이드오프가 다시 논쟁되는가? 정직한 답이 후자라면, 다음 인시던트가 압박 아래서 그 논쟁을 강요하기 전에 그 간극을 메울 가치가 있다.
우리의 오류 예산은 계산된 위험 변경이나 실험에 실제로 의도적으로 소비된 적이 있는가, 아니면 인시던트를 통해 우연히만 소비되는가? 결코 의도적으로 소비되지 않는 예산은 그것이 가능하게 하도록 존재하는 정당한 기회를 놓치고 있는 지나치게 조심스러운 팀을 시사할 수 있다.
우리의 SLI는 진정한 사용자 경험으로부터 측정되는가, 아니면 사용자가 실제로 마주치는 것을 반영하지 못할 수 있는 내부 시스템 건강으로부터 측정되는가? 이 특정한 구분에 맞서 현재 계측을 확인하라. 그것은 그렇지 않으면 성숙한 신뢰성 프로그램에서도 흔한 간극이다.
우리는 마지막으로 언제 현재 증거에 맞서 SLO를 검토했으며, 그것을 수정할 정당성을 줄 사용자 기대, 시스템 아키텍처, 비즈니스 우선순위 중 무엇이 바뀌었는가? 최근 검토를 기억할 수 없다면, 그 부재 자체가 논의할 가치가 있다.
우리의 현재 SLO를 신뢰성의 추가 “9” 하나만큼 올리는 데 엔지니어링 노력으로 얼마나 비용이 들 것이며, 그 비용이 진정한 사용자 혜택으로 정당화될 것인가? 이 구체적인 비용 편익 프레이밍은 열망 대 달성 가능성 긴장을 추상적인 선호가 아니라 실제 숫자에 근거하도록 돕는다.

분야별 관점

스타트업. 공식 SLO는 흔히 매우 초기에는 불필요한데, 팀이 신뢰성 문제에 직접적이고 비공식적으로 대응할 수 있을 때다. 가동 시간에 의존하는 실제 유료 고객이 있게 되면 적어도 대략적이고 비공식적인 SLO를 채택하라. 명시적인 목표의 규율은, 느슨하게 추적되는 것이라도, 대부분의 젊은 회사가 생각하는 것보다 더 일찍 기능 압박에 맞서 신뢰성 작업을 우선시하는 데 도움이 되기 때문이다.

중소기업. 대부분의 현대 호스팅 및 관측 가능성 플랫폼은 최소한의 설정으로 기본 가동 시간과 지연 시간 데이터를 보고한다. 이것을 사용해 제한된 운영 역량으로 현실적으로 추적하거나 행동할 수 없는 열망적인 SLO가 아니라 단순하고 달성 가능한 SLO를 설정하라.

엔터프라이즈. 이 규모에서 SLO는 흔히 실제 재무적 결과를 가진 계약적 서비스 수준 계약을 뒷받침하며, 이는 증거 기반 목표 설정과 규율 있는 오류 예산 관리를 특히 중요하게 만든다. 편리한 내부 건강 점검이 아니라 진정한 사용자 경험에 근거한 SLI에 투자하고, 압박 아래서 필요해지기 전에 경영진의 동의와 함께 미리 정해진 소진 대응 정책을 공식적으로 확립하라.

정부. 중요한 인프라에 대한 공공 부문 신뢰성 목표는 때때로 법적이거나 규제적인 무게를 지니며, 감사나 공개 인시던트 중에 발견된 비현실적이고 달성되지 않은 목표는 제도적 신뢰성에 상당한 피해를 준다. 진정하고 문서화된 사용자와 미션 필요에 근거해 목표를 설정하고, 도달할 수 없는 완벽함의 기준을 암시하는 대신 오류 예산이 나타내는 의도적인 트레이드오프에 대해 공개적으로 투명하라.

사례

엔터프라이즈. 한 클라우드 스토리지 회사는 수년 동안 공식 SLO 없이 “최대 가동 시간”을 목표로 삼았으며, 이는 제품 팀(기능을 빨리 배포하고 싶어 함)과 인프라 팀(최대한의 신중함을 원함) 사이의 만성적이고 해결되지 않은 긴장으로 이어졌고, 모든 릴리스 계획 회의에서 새로 다시 논쟁되었다. 명시적인 오류 예산과 미리 정해진 정책(예산이 소진되면 기능 작업이 자동으로 일시 중지됨)을 가진 공식 99.95% 가용성 SLO를 채택하는 것은 반복되는 협상을 완전히 해결했다: 두 팀 모두 같은 숫자를 보고 같은 규칙에 동의할 수 있었으며, 그 회사는 예산이 건강한 기간 동안 배포된 기능의 측정 가능한 증가와, 정책이 의도한 바로 그대로, 다음 해에 걸쳐 예산이 진정으로 소진된 두 기간 동안의 측정 가능하고 의도적인 둔화를 보고했다.

정부. 한 국립 기상청의 공공 경보 시스템은 수년 동안 문서화된 목표 없이 “항상 가용함”이라는 비공식적 기대 아래 운영되었으며, 명시되지 않은 사실상 불가능한 기준을 충족시키려는 온콜 팀에 상당하고 해결되지 않은 운영 스트레스를 주었다. 명확하게 전달된 공공 오류 예산 설명과 함께 새로 채택된 공식 SLO(99.9% 가용성)는 운영 팀에게 예산 내에서 계획된 유지보수 창을 예약할 명시적이고 방어 가능한 허가를 주었다. 이것은 장기적인 시스템 건강을 위해 진정으로 필요했을 때조차 이전의 명시되지 않은 “항상 가용함” 기대가 정치적으로 하기 어렵게 만들었던 것이다. 오류 예산 개념을 숨기지 않고 직접 설명한 공공 소통은 서비스 품질에 대한 헌신의 약화가 아니라 정직하고 성숙한 운영 관행의 신호로 호의적으로 받아들여졌다.

비즈니스 사례: 동기, ROI, TCO

SLO와 오류 예산을 공식적으로 채택하는 수익은 그렇지 않으면 끝없고 정치적으로 비용이 드는 속도와 안정성 사이의 협상을 단일하고 공유되며 객관적인 규칙으로 해결하는 것이다. 위의 클라우드 스토리지 사례는 이것을 구체적으로 보여 준다: 두 팀 사이의 수년에 걸친 반복적이고 해결되지 않은 긴장이 단일한 공식 목표와 미리 정해진 정책으로 해결되었으며, 이는 이전에 같은 트레이드오프를 반복적으로 다시 논쟁하는 데 들어갔던 상당한 조직적 에너지를 해방시켰다.

총 소유 비용은 증거 기반 목표를 올바르게 설정하는 분석 노력과 특별히 원하는 기능을 어쨌든 배포하려는 압박 아래서도 미리 정해진 소진 대응을 지키는 규율을 포함한다. 그 규율 비용은 실재하지만, 모든 계획 주기에서 무기한으로 조직적 에너지를 소비하는 해결되지 않은 만성적 협상의 지속적인 비용보다 훨씬 낮다.

안티패턴과 함정

뒤에 증거가 없는 열망적인 SLO 설정하기: 팀이 더 이상 진지하게 받아들이지 않는 비현실적인 목표, 혹은 사용자가 알아채지 못하는 혜택을 쫓는 불필요하게 비싼 목표를 만들어 낸다.
오류 예산 소진에 대한 미리 정해진 대응이 없음: 그것이 일어날 때마다 압박 아래서 같은 어려운 트레이드오프 논쟁을 강요한다.
진정한 사용자 경험이 아니라 내부 시스템 건강으로부터 SLI 측정하기: 사용자가 실제 문제를 경험하는 동안 “건강함”을 보고할 수 있다.
건강한 오류 예산을 결코 실제로 의도적으로 소비하지 않기: 지나친 조심스러움과 놓친 정당한 기회를 시사할 수 있다.
목표를 한 번 설정하고 결코 다시 방문하지 않기: 사용자 기대, 아키텍처, 우선순위가 변하면서 SLO가 진부해질 수 있다.
압박 아래서 오류 예산 정책을 선택 사항으로 취급하기: 불편할 때마다 무시되는 미리 정해진 규칙은 진정한 의사 결정 가치를 제공하지 않는다.

성숙도 모델

1단계, 시작: 신뢰성 목표가 암묵적이거나 열망적이며, 공식 SLO, SLI, 오류 예산이 정의되어 있지 않다.
2단계, 개발: 일부 서비스는 비공식 SLO를 가지고 있지만, SLI가 진정한 사용자 경험을 반영하지 못할 수 있고 미리 정해진 소진 정책이 없다.
3단계, 표준화: 진정한 사용자 경험 SLI와 미리 정해진 오류 예산 소진 정책을 가진 증거 기반 SLO가 중요한 서비스 전반에 걸쳐 일관되게 확립된다.
4단계, 관리: 오류 예산이 계산된 위험 감수에 적극적이고 의도적으로 소비되며, SLO가 정기적이고 증거 기반 주기로 검토되고 수정된다.
5단계, 조율: SLO와 오류 예산이 속도와 안정성의 균형을 맞추는 공유되고 객관적인 메커니즘으로서 조직 전체에 통합되며, 조직은 근거 없는 협상이 그만큼 효과적으로 해결하지 못했을 프레임워크가 가능하게 한 특정 결정을 지적할 수 있다.

논의를 위한 아이디어

우리의 현재 SLO는 증거에 근거하고 있는가, 아니면 열망에 근거하고 있는가?
우리는 압박 아래서도 실제로 지킬 오류 예산 소진에 대한 미리 정해진 대응을 가지고 있는가?
우리는 마지막으로 언제 계산된 위험에 건강한 오류 예산을 의도적으로 소비했는가?
우리의 SLI는 진정한 사용자 경험을 측정하고 있는가, 아니면 편리한 내부 건강 점검을 측정하고 있는가?
우리의 SLO를 추가 “9” 하나만큼 올리는 데 얼마나 비용이 들 것이며, 그 비용이 정당화될 것인가?

핵심 요약

서비스 수준 지표(SLI)는 진정한 사용자 경험을 측정한다. 서비스 수준 목표(SLO)는 그것의 증거 기반 목표다. 오류 예산은 의도적으로 소비 가능한 허용된 미달이다.
100% 신뢰성은 보통 잘못된 목표다. 사용자가 실제로 알아채는 것과 각 추가 증분이 진정으로 드는 비용에 SLO를 근거하라.
오류 예산을 미리 정해진 소진 대응을 가진 소비 가능한 자원으로 취급하여, 매번 압박 아래서 속도 대 안정성을 다시 논쟁할 필요성을 제거하라.
편리한 내부 건강 점검이 아니라 진정한 사용자 경험으로부터 SLI를 측정하라.
SLO를 주기적으로 검토하고 수정하라. 증거에 근거해, 진부한 목표는 시스템과 그 사용자가 변하면서 유용성을 잃기 때문이다.

참고 문헌 및 추가 자료

Site Reliability Engineering: How Google Runs Production Systems, by Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy, eds.
The Site Reliability Workbook, by Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, and Stephen Thorne, eds.
Implementing Service Level Objectives, by Alex Hidalgo.
Accelerate: The Science of Lean Software and DevOps, by Nicole Forsgren, Jez Humble, and Gene Kim.