181. SLO (Service Level Objective, 서비스 수준 목표)

핵심 인사이트 (3줄 요약)

1. 본질: SLO (Service Level Objective)는 SLI (Service Level Indicator)에 목표치와 평가 창을 얹어, "어느 수준까지 품질을 유지할 것인가"를 수치로 고정한 내부 운영 기준이다.
2. 가치: SLO가 있어야 배포 속도, 장애 대응, 투자 우선순위가 감정이 아니라 Error Budget 기반 의사결정으로 연결된다.
3. 판단 포인트: 좋은 SLO는 높아 보이는 숫자가 아니라 사용자 체감과 운영 비용을 함께 감당할 수 있는 목표이며, 숫자 하나를 올릴 때마다 허용 실패량은 급격히 줄어든다.

Ⅰ. 개요 및 필요성

SLO (Service Level Objective)는 서비스가 "충분히 좋다"고 말할 수 있는 내부 목표선이다. SLI가 현재 품질을 재는 계기판이라면, SLO는 그 계기판을 보고 어느 구간까지 허용할지를 정한 운영 기준이다. 예를 들어 로그인 API (Application Programming Interface)의 성공률을 30일 동안 99.95% 이상 유지하겠다고 정하면, 그 순간부터 팀은 품질을 숫자로 논의할 수 있다.

SLO가 필요한 이유는 메트릭만 많다고 운영이 명확해지지 않기 때문이다. CPU (Central Processing Unit) 사용률, p95 지연시간, 오류율이 동시에 보이더라도 "지금 배포해도 되는가"라는 질문에는 여전히 팀마다 다른 답을 낼 수 있다. 제품팀은 더 빨리 출시하고 싶고, 운영팀은 장애를 줄이고 싶어 하므로, 둘 사이에 공통된 기준선이 없으면 속도와 안정성은 늘 충돌한다.

또한 SLO는 100% 신뢰성을 목표로 삼지 않는다는 점에서 중요하다. 100%는 기술적으로도 비싸고, 조직적으로도 혁신을 멈추게 만든다. 결국 SLO는 "얼마나 완벽해야 하는가"가 아니라, "사용자가 불편을 느끼지 않는 수준을 어떤 비용으로 유지할 것인가"를 정하는 경제적 의사결정이다.

아래 그림은 목표 없는 관측과 SLO 기반 운영의 차이를 보여 준다.

┌──────────────────────────────────────────────────────────────┐
│ 목표 없는 운영 vs SLO 기반 운영                               │
├──────────────────────────────────────────────────────────────┤
│ 메트릭만 있음: CPU 70%, p95 420ms, 오류율 0.3%              │
│   └─ 팀마다 해석이 달라 배포 판단이 흔들림                  │
│                                                              │
│ SLO 있음: 로그인 성공률 99.95%, p95 300ms (30일)            │
│   ├─ 목표 이내  -> 기능 배포 가능                            │
│   └─ 목표 이탈  -> 안정화 우선, Error Budget 점검           │
└──────────────────────────────────────────────────────────────┘

이 그림의 핵심은 SLO가 단순 보고서 숫자가 아니라, 변경 관리와 장애 대응의 기준점이라는 사실이다. 즉 SLO가 정의되는 순간부터 관측성은 모니터링을 넘어 운영 정책이 된다.

• 📢 섹션 요약 비유: SLO는 시험 점수 자체가 아니라 "이 점수 이상이면 합격"이라고 정한 기준선과 같다. 점수만 보면 해석이 갈리지만, 합격선이 있으면 다음 행동이 분명해진다.

Ⅱ. 아키텍처 및 핵심 원리

SLO는 보통 네 가지 요소로 설계된다. 첫째, 어떤 사용자 여정을 볼지 정한다. 둘째, 그 여정을 수치화하는 SLI를 고른다. 셋째, 28일 또는 30일 같은 롤링 윈도우에서 목표치를 선언한다. 넷째, 목표를 벗어날 때 어떤 운영 조치를 취할지 Error Budget 정책을 연결한다.

가장 많이 쓰는 계산은 단순하다. 가용성 SLO라면 Error Budget = 1 - SLO다. 예를 들어 30일 기준 99.9% 가용성 SLO는 전체 43,200분 중 0.1%인 43.2분의 실패 시간을 허용한다. 여기서 중요한 것은 이 43.2분이 "장애를 허용한다"는 뜻이 아니라, 그 범위를 넘기기 전에 어떤 변경을 멈추고 어떤 개선을 우선할지 판단하는 운영 자산이라는 점이다.

아래 흐름은 SLO가 측정값에서 운영 정책으로 변하는 과정을 보여 준다.

┌──────────────────────────────────────────────────────────────┐
│ SLO가 운영 판단으로 바뀌는 흐름                              │
├──────────────────────────────────────────────────────────────┤
│ 사용자 요청                                                  │
│    │                                                         │
│    ▼                                                         │
│ SLI 계산: good / total, p95, freshness                       │
│    │                                                         │
│    ├─ 30일 목표치 비교 ───────▶ SLO 달성 / 미달              │
│    │                                                         │
│    └─ 허용 실패량 계산 ────▶ Error Budget                    │
│                              │                               │
│                              ├─ 잔여 충분 -> 배포·실험 가능  │
│                              └─ 급감 중     -> 변경 제한     │
└──────────────────────────────────────────────────────────────┘

실무에서는 Burn Rate도 함께 본다. Burn Rate는 Error Budget이 얼마나 빠르게 소진되는지 보는 속도 지표다. 같은 1% 오류율이라도 5분 안에 급격히 치솟는 장애와, 며칠 동안 천천히 악화되는 문제는 대응 방식이 다르므로 SLO는 반드시 시간축과 함께 운영되어야 한다.

• 📢 섹션 요약 비유: SLO는 용돈 한도를 정해 두는 가계부와 같다. 한 달 예산이 있으면 오늘 얼마를 써도 되는지 계산할 수 있고, 너무 빨리 쓰면 남은 기간을 아껴야 한다.

Ⅲ. 비교 및 연결

SLO를 정확히 이해하려면 SLI, SLA (Service Level Agreement)와의 경계를 먼저 나눠야 한다. SLI는 실측값이고, SLO는 내부 목표이며, SLA는 외부 계약이다. 따라서 SLO는 SLI보다 추상적이어서는 안 되고, SLA보다 느슨해서도 안 된다.

SLO 숫자는 보기엔 비슷해 보여도 허용 실패량 차이는 매우 크다. 99.9%에서 99.99%로 한 자리만 올려도 허용 가능한 월간 실패 시간은 10분의 1로 줄어든다. 그래서 "한 자릿수 더 올리자"는 말은 대개 다중화, 테스트, 자동 복구, 관측성 투자까지 함께 요구하는 아키텍처 변화다.

또한 모든 SLO가 가용성일 필요는 없다. 사용자 화면은 지연시간 SLO가 더 중요할 수 있고, 데이터 파이프라인은 신선도나 완결성 SLO가 더 중요할 수 있다. 결국 SLO는 "서비스마다 무엇이 실패인가"를 정의하는 작업이며, 같은 99.9%라도 서비스 종류에 따라 의미가 달라진다.

• 📢 섹션 요약 비유: 99.9와 99.99의 차이는 키가 1cm 커지는 차이가 아니라, 시험에서 틀려도 되는 문제 수가 10문제에서 1문제로 줄어드는 차이와 같다. 숫자는 비슷해 보여도 부담은 전혀 다르다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서 좋은 SLO는 "측정 가능함"과 "행동 가능함"을 동시에 만족해야 한다. 사용자가 실제로 체감하는 핵심 여정을 고르고, 목표를 벗어날 때 배포 속도·장애 대응·개선 우선순위가 어떻게 바뀌는지 미리 정책으로 정해 두어야 한다. 숫자만 있고 조치가 없으면 SLO는 화려한 대시보드에 그친다.

실무 체크리스트는 다음과 같다.

1. 사용자 여정이 명확한가, 아니면 단순 인프라 지표를 목표로 삼고 있는가?
2. good, bad, eligible 요청의 분모와 분자가 논쟁 없이 정의되는가?
3. 5분·1시간 같은 빠른 경보 창과 30일 같은 장기 목표 창을 분리했는가?
4. Error Budget이 50%, 25%, 10% 이하일 때 배포 정책이 어떻게 달라지는가?
5. 목표치가 과거 운영 데이터와 사용자 기대를 모두 반영하는가?

안티패턴도 분명하다. 첫째, 모든 서비스에 99.99%를 일괄 적용하는 방식이다. 둘째, SLO를 한 번 정한 뒤 분기별 재평가 없이 영구 기준으로 두는 방식이다. 셋째, 지연시간 SLO를 평균값으로만 두어 tail latency를 숨기는 방식이다. 기술사 답안에서는 "SLO를 정한다"보다 서비스별 SLI 선정 → 목표치 결정 → Error Budget 정책 연결까지 설명해야 판단력이 드러난다.

• 📢 섹션 요약 비유: SLO 운영은 자동차 속도 제한과 같다. 제한 속도만 적어 두면 끝이 아니라, 과속 경고가 울릴 때 감속할지, 휴게소에 들를지, 차를 점검할지까지 함께 정해 두어야 안전하게 달릴 수 있다.

Ⅴ. 기대효과 및 결론

좋은 SLO는 조직 안에서 "충분히 안정적이다"를 같은 숫자로 말하게 만든다. 개발팀은 새 기능 배포가 신뢰성에 미치는 영향을 이해하고, SRE (Site Reliability Engineering)와 운영팀은 어느 문제를 먼저 고쳐야 하는지 우선순위를 세울 수 있다. 경영진 입장에서도 신뢰성 투자가 단순 비용이 아니라 SLA 방어와 고객 경험 보호라는 점을 설명하기 쉬워진다.

물론 SLO가 만능은 아니다. 잘못 정의된 SLI 위에 세운 SLO는 오히려 팀을 엉뚱한 숫자에 집착하게 만들 수 있고, 너무 많은 SLO는 관측 피로만 키운다. 그래서 핵심 사용자 여정을 대표하는 소수의 SLO와, 원인 분석을 위한 풍부한 진단 메트릭을 분리해서 가져가는 것이 중요하다.

결론적으로 SLO는 신뢰성을 숫자로 표현한 운영 언어다. 핵심은 높은 숫자를 자랑하는 것이 아니라, 서비스가 감당할 수 있는 품질 목표를 정하고 그 범위 안에서 가장 빠르게 개선과 배포를 반복하는 데 있다. 기억해야 할 포인트는 하나다. SLO는 완벽함의 선언이 아니라, 신뢰성과 혁신의 균형점이다.

• 📢 섹션 요약 비유: 좋은 SLO는 무조건 최고 점수를 강요하는 담임이 아니라, 학생이 무너지지 않으면서도 꾸준히 성장하도록 현실적인 목표와 공부 계획을 함께 잡아 주는 코치와 같다.

📌 관련 개념 맵

📈 관련 키워드 및 발전 흐름도

핵심 사용자 여정 정의
    │
    ▼
SLI (Service Level Indicator) 계산
    │
    ▼
SLO (Service Level Objective) 목표치 설정
    │
    ▼
Error Budget · Burn Rate 운영
    │
    ▼
배포 정책 · 안정화 투자 의사결정
    │
    ▼
SLA (Service Level Agreement) 및 고객 신뢰 관리

이 흐름은 단순 관측 수치가 내부 운영 목표로 바뀌고, 다시 계약과 고객 신뢰 관리까지 확장되는 과정을 보여 준다.

👶 어린이를 위한 3줄 비유 설명

1. SLO는 "하루에 숙제를 몇 개까지 틀려도 괜찮은지"를 미리 정해 둔 약속이에요.
2. 그래서 조금 실수해도 바로 혼나는 게 아니라, 남은 기회를 보면서 공부 계획을 고칠 수 있어요.
3. 하지만 약속보다 많이 틀리기 시작하면 놀기보다 먼저 왜 자꾸 틀리는지부터 고쳐야 해요.