테크

2026-07-27

SLO, 에러예산, 번레이트가 뭔가요?

가용성 목표를 높게 잡는다고 해서 서비스가 반드시 더 안정적으로 운영되는 것은 아닙니다. 가용성 목표를 99.9%로 잡은 팀과 100%로 잡은 팀을 가정해 보겠습니다. 100%를 목표로 한 팀은 작은 실패까지 모두 막으려다 과도한 비용을 쓰거나, 장애를 우려해 배포와 변경에 지나치게 보수적으로 접근할 수 있습니다. 반면 99.9%를 선택한 팀은 허용 가능한 실패의 범위를 정하고, 그 안에서 서비스의 안정성과 개발 속도 사이의 균형을 조정할 수 있습니다. 목표를 낮게 잡아서가 아니라, 실패를 측정하고 관리하는 방식이 다르기 때문입니다.

신뢰성을 숫자로 관리하는 팀은 SLO, 에러예산(허용된 실패량), 번레이트(그 실패량을 태우는 속도)라는 세 가지 개념을 함께 씁니다. 이름은 낯설지만 원리는 단순합니다. 이 글에서 SLI·SLO·SLA가 어떻게 다른지, 에러예산과 번레이트가 SLO에서 어떻게 나오는지, 번레이트 알림이 정적 임계값 알림의 한계를 어떻게 보완하는지 정리하려고 합니다.

‍

SLI, SLO, SLA는 어떻게 다른가요?

SLI, SLO, SLA는 이름이 비슷하지만 각각 실제 결과, 운영 목표, 고객과의 약속을 뜻합니다.

로그인 요청이 1,000번 들어온 서비스를 예로 들어 보겠습니다. 이 가운데 997번이 정상적으로 처리됐다면 실제 로그인 성공률은 99.7%입니다. 이처럼 서비스가 실제로 얼마나 잘 작동했는지를 나타내는 값이 SLI(Service Level Indicator, 서비스 수준 지표) 입니다.

SLI: 실제 로그인 성공률은 99.7%다.

운영팀은 실제 결과를 측정하는 데서 그치지 않고, 서비스가 어느 수준을 유지해야 하는지도 정합니다. 예를 들어 로그인 성공률을 최근 30일 동안 99.9% 이상으로 유지하기로 했다면 이것이 SLO(Service Level Objective, 서비스 수준 목표) 입니다.

SLO: 최근 30일 동안 로그인 성공률을 99.9% 이상으로 유지한다.

SLI가 실제로 나온 결과라면, SLO는 팀이 달성하려는 목표입니다. 실제 성공률이 99.7%라면 SLI는 99.7%이고, 목표가 99.9%라면 현재 SLO를 달성하지 못한 상태입니다.

SLA(Service Level Agreement, 서비스 수준 협약) 는 고객에게 어느 수준의 서비스를 제공할 것인지 공식적으로 약속한 내용입니다. 약속한 수준을 지키지 못했을 때 제공할 보상이나 대응 조건이 함께 포함되기도 합니다.

SLA: 월간 로그인 성공률이 99.5%보다 낮으면 이용 요금의 일부를 서비스 크레딧으로 제공한다.

세 개념을 정리하면 다음과 같습니다.

SLI: 서비스가 실제로 얼마나 잘 작동했는지 보여주는 값
SLO: 운영팀이 달성하려고 정한 목표
SLA: 고객에게 공식적으로 보장한 서비스 수준

쉽게 말하면 SLI로 현재 상태를 확인하고, SLO를 기준으로 서비스를 운영하며, SLA를 통해 고객에게 서비스 수준을 약속합니다.

일반적으로 내부에서 관리하는 SLO는 고객에게 약속한 SLA보다 조금 더 높게 설정합니다. 예를 들어 내부 SLO는 99.9%로 관리하고, SLA는 99.5%로 정할 수 있습니다. 그래야 서비스 상태가 나빠졌을 때 SLA를 위반하기 전에 문제를 발견하고 대응할 수 있습니다.

‍

SLO에서 에러예산과 번레이트가 나오는 과정

SLO를 정하면 허용 가능한 실패량인 에러예산이 정해집니다. 여기에 실제 실패율을 대입하면 에러예산이 얼마나 빠르게 줄어드는지, 즉 번레이트를 계산할 수 있습니다. 세 개념은 별개가 아니라 하나의 흐름으로 연결됩니다.

‍

SLO에서 에러예산과 번레이트는 어떻게 계산하나요?

에러예산(error budget) 은 SLO를 지키면서 허용할 수 있는 실패량입니다. SLO가 99.9%라면 에러예산은 100%에서 99.9%를 뺀 0.1%입니다.

에러예산 = 100% − SLO

에러예산을 표현하는 단위는 SLI에 따라 달라집니다. 요청 성공률을 측정한다면 전체 요청의 0.1%까지 실패를 허용할 수 있다는 뜻입니다. 예를 들어 30일 동안 요청이 100만 건 발생했다면 에러예산은 실패 요청 1,000건입니다. 시간을 기준으로 가용성을 측정한다면 서비스 중단 시간으로도 표현할 수 있습니다. 99.9% SLO를 30일 기준으로 환산하면 약 43분입니다. 목표를 99.95%로 높이면 약 22분으로 줄고, 99%로 낮추면 약 7시간 12분으로 늘어납니다. 에러예산은 데이터 요금제의 남은 용량과 비슷합니다. 다만 예산이 남은 만큼 장애를 일으켜도 된다는 뜻은 아닙니다. 예산이 충분하면 새로운 기능과 변경을 이어갈 여유가 있지만, 빠르게 줄어들면 배포 속도를 조절하고 안정성 개선을 우선해야 합니다.

번레이트(burn rate) 는 에러예산이 기준보다 얼마나 빠르게 소진되고 있는지를 나타냅니다. 실제 실패율을 SLO에서 허용한 실패율로 나누어 계산합니다.

번레이트 = 실제 실패율 ÷ 허용 실패율

번레이트가 1배라면 현재 실패율이 측정 기간 내내 이어졌을 때 에러예산을 정확히 모두 소진한다는 뜻입니다. 1배보다 낮으면 예산을 천천히 사용하고 있고, 1배보다 높으면 현재 상태가 계속될 경우 SLO를 위반하게 됩니다. 예를 들어 측정 기간이 30일일 때 번레이트가 10배로 유지되면 한 달치 에러예산을 약 3일 만에 소진합니다. 번레이트가 14.4배라면 약 50시간, 즉 이틀 남짓 만에 예산이 바닥납니다.

‍

번레이트 알림은 정적 임계값과 어떻게 다른가요?

“에러율이 5%를 넘으면 알림”처럼 고정된 기준을 사용하면 순간적으로 수치가 튀었다가 회복된 상황에도 알림이 발생할 수 있습니다. 반대로 임계값보다 낮은 에러가 오랫동안 이어지면서 에러예산을 소진하는 상황은 놓칠 수 있습니다.

번레이트 알림은 에러율 자체보다 현재 실패가 에러예산을 얼마나 빠르게 소진하는지를 봅니다. 따라서 짧고 큰 장애뿐 아니라 낮은 에러율이 오래 지속되는 문제도 SLO에 미치는 영향을 기준으로 판단할 수 있습니다.

Google SRE 워크북은 긴 시간 창과 짧은 시간 창을 함께 확인하는 방식을 제안합니다. 예를 들어 최근 1시간과 최근 5분의 번레이트가 모두 14.4배를 넘거나, 최근 6시간과 최근 30분의 번레이트가 모두 6배를 넘을 때 알림을 발생시킬 수 있습니다. 긴 창으로 문제가 지속됐는지 확인하고, 짧은 창으로 지금도 에러예산이 빠르게 소진되고 있는지 확인해 불필요한 알림을 줄이는 방식입니다.

‍

왜 100% 가용성을 목표로 잡지 않을까요?

100% 가용성은 가장 안전한 목표처럼 보이지만 SLO에서는 보통 가장 좋은 목표가 아닙니다. 신뢰성 목표는 가능한 가장 높은 숫자가 아닌 사용자가 만족할 수 있는 수준과 이를 유지하는 데 필요한 비용을 함께 고려해 정해야 합니다. 서비스 자체가 정상이어도 사용자와 서비스 사이에는 네트워크, DNS, 통신사 회선, 사용자 단말 등 여러 구간이 있습니다. 이 중 한 곳에서만 문제가 생겨도 사용자는 실패를 경험할 수 있습니다. 따라서 마지막 0.001%까지 높이기 위해 큰 비용을 들이더라도 사용자가 그 차이를 체감하지 못할 수 있습니다. 100% 목표에 허용할 수 있는 실패가 없다는 문제도 있습니다. 작은 장애나 오류도 모두 목표 위반이 되기 때문에 팀은 새로운 기능을 배포하거나 시스템을 변경할 때 지나치게 보수적으로 움직일 수 있습니다. 높은 신뢰성을 유지하려다 오히려 필요한 개선과 변경이 늦어집니다.

SLO는 이런 상황에서 안정성과 개발 속도 사이의 기준이 됩니다. 에러예산이 충분히 남아 있다면 팀은 합의한 절차에 따라 배포와 변경을 이어갈 수 있습니다. 반대로 예산을 빠르게 소진했거나 모두 사용했다면, 에러예산 정책에 따라 신규 변경을 줄이고 안정성 개선을 우선할 수 있습니다. 이렇게 하면 개발팀과 운영팀이 “빨리 배포해야 한다”거나 “장애가 나면 안 된다”는 의견만으로 대립하지 않아도 됩니다. 남아 있는 에러예산이라는 공통의 숫자를 기준으로 지금은 변경을 이어갈 때인지 안정화에 집중할 때인지 판단할 수 있습니다. SLO는 실패를 허용하기 위한 목표가 아니라, 필요한 신뢰성과 변화의 속도를 함께 관리하기 위한 합의 기준입니다.

‍

첫 SLO는 어떻게 설정하나요?

개념을 이해했다면 이제 첫 SLO를 설정할 차례입니다. 처음부터 모든 서비스에 SLO를 적용하려고 할 필요는 없습니다. 로그인, 결제, 상품 검색처럼 실패했을 때 사용자에게 직접 영향을 주는 핵심 흐름 하나부터 시작하는 것이 좋습니다.

첫 SLI는 내부 시스템의 상태보다 사용자가 실제로 경험한 결과를 기준으로 정합니다. CPU 사용률과 메모리 사용량도 운영에 중요한 지표지만, 사용자가 요청에 성공했는지 또는 충분히 빠른 응답을 받았는지를 직접 보여주지는 않습니다. 이런 지표는 문제의 원인을 찾는 데 활용하고, SLI는 사용자 경험을 나타내는 값으로 정하는 편이 좋습니다.

처음에는 가용성과 지연시간 가운데 하나를 선택해도 충분합니다.

가용성 SLI: 전체 요청 중 성공한 요청의 비율
지연시간 SLI: 전체 요청 중 정해진 시간 안에 처리된 요청의 비율

다음으로 측정 기간과 목표치를 붙이면 첫 SLO가 됩니다.

최근 30일 동안 로그인 요청의 99.9% 이상을 성공적으로 처리한다.

지연시간을 관리하려면 별도의 SLO를 정할 수 있습니다.

최근 30일 동안 로그인 요청의 95% 이상을 300ms 안에 처리한다.

목표치는 처음부터 완벽하게 정할 필요가 없습니다. 최근 몇 주간의 실제 측정값을 확인하고, 사용자가 기대하는 수준과 기능 실패가 미치는 영향을 함께 고려해 달성 가능한 기준부터 시작합니다. 이후 에러예산의 소진 추이와 사용자 경험을 살펴보며 목표치와 측정 기간을 조정하면 됩니다. 첫 SLO의 목적은 완벽한 숫자를 고르는 것이 아니라, 중요한 사용자 경험을 실제로 측정하고 팀이 함께 관리할 기준을 만드는 데 있습니다.

‍

마치며

SLO는 서비스 신뢰성을 감이 아니라 숫자로 관리하고, 팀이 운영 기준에 합의하도록 돕는 도구입니다. SLI로 사용자가 경험하는 서비스 품질을 측정하고 SLO로 목표를 정하면, 허용 가능한 실패량인 에러예산을 계산할 수 있습니다. 여기에 실제 실패율을 적용하면 에러예산이 소진되는 속도인 번레이트도 확인할 수 있습니다.

무조건 100%를 추구하기보다 사용자에게 필요한 신뢰성 수준을 정하고, 안정성과 변화의 속도를 함께 관리하는 것이 SLO의 핵심입니다. 처음부터 모든 기능에 적용할 필요는 없습니다. 로그인이나 결제처럼 사용자에게 중요한 흐름 하나를 골라 첫 SLI와 SLO를 설정해 보세요. 여러 서비스 지표를 한 곳에서 확인하고 싶다면 와탭을 15일 무료로 체험해 보세요.

‍

자주 묻는 질문

‍

가용성 목표를 100%로 설정하면 안 되나요?

일반적으로 권하지 않습니다. 서비스가 정상이어도 네트워크, DNS, 사용자 단말 문제로 실패가 발생할 수 있고, 100%를 유지하려면 큰 비용이 듭니다. 서비스 특성과 사용자 기대 수준을 고려해 99.9%나 99.95%처럼 현실적인 목표를 설정하는 편이 좋습니다.

‍

SLO와 SLA는 무엇이 다른가요?

SLO는 서비스가 달성하려는 신뢰성 목표이고, SLA는 고객과 합의한 서비스 수준입니다. SLA에는 약속을 지키지 못했을 때의 보상 조건이 포함될 수 있습니다. 보통 SLA 위반 전에 대응할 수 있도록 내부 SLO를 더 높게 설정합니다.

‍

번레이트 알림은 정적 임계값 알림과 무엇이 다른가요?

정적 임계값 알림은 에러율이 정해진 기준을 넘었는지 확인합니다. 번레이트 알림은 에러예산이 얼마나 빠르게 소진되는지를 봅니다. 따라서 순간적인 수치보다 현재 문제가 SLO에 미치는 영향을 기준으로 대응할 수 있습니다.

‍

에러예산을 모두 사용하면 어떻게 하나요?

팀이 정한 에러예산 정책에 따라 신규 배포를 줄이고 안정성 개선을 우선합니다. 에러예산이 반복해서 바닥난다면 실제 서비스 품질, SLI 측정 방식, SLO 목표치가 적절한지 함께 검토해야 합니다.

‍

더 읽을거리

‍

참고 자료

박수빈

Technical Writer, WhaTap

와탭랩스(WhaTap)에서 기술 콘텐츠를 기획하고 작성하는 엔지니어로 일하고 있습니다.