🎯 SLO? SLA? 헷갈리는 SRE 용어, 피자 가게 비유로 5분 만에 끝내기!

안녕하세요! 👋 IT 기술 블로그를 읽거나 DevOps, SRE 관련 대화를 나누다 보면 SLI, SLO, SLA 같은 낯선 용어들 때문에 고개를 갸우뚱한 적 없으신가요? "서비스 품질이 중요하다는 건 알겠는데, 그래서 이게 다 무슨 뜻이지?" 하는 분들을 위해 준비했습니다.

 

오늘은 서비스 안정성의 핵심 지표인 서비스 품질 삼총사, SLI, SLO, SLA에 대해 알아보겠습니다. 복잡한 개념은 잠시 잊고, 우리 동네 피자 가게 이야기에 귀 기울여 보세요. 🍕 어느새 모든 개념을 완벽하게 이해하게 되실 거예요!

 

 

📈 서비스 품질 삼총사: SLI, SLO, SLA를 소개합니다!

세 용어는 각각 따로 노는 개념이 아니라, 서로 끈끈하게 연결된 관계입니다. 서비스의 품질을 측정하고(SLI), 목표를 설정한 뒤(SLO), 고객과 약속(SLA)하는 흐름으로 이해하면 아주 쉽습니다. 자, 한 명씩 만나볼까요?

 

1. 🔬 SLI (Service Level Indicator) - 서비스 수준 지표

가장 기본이 되는 SLI는 '서비스의 건강 상태를 보여주는 계기판'이라고 생각하면 됩니다. 우리 서비스의 품질을 정량적으로 측정하기 위한 지표 그 자체죠.

• 🤔 핵심 질문: "우리는 무엇을 측정해야 할까?"
• 🏥 비유: 병원의 온도계, 혈압계
• 역할: 구체적인 숫자로 현재 상태를 객관적으로 보여줍니다.

주요 SLI 예시:

• 가용성 (Availability): 서비스가 얼마나 오랫동안 정상적으로 작동했는가?
  • 측정 방식: (성공한 요청 수 / 전체 요청 수) * 100
• 지연 시간 (Latency): 사용자가 요청을 보낸 후 응답을 받기까지 얼마나 걸렸는가?
  • 측정 방식: API 요청 처리 시간 (ms)
• 에러율 (Error Rate): 요청 중 얼마나 많은 요청이 실패했는가?
  • 측정 방식: (5xx 에러 발생 수 / 전체 요청 수) * 100

SLI는 막연히 "우리 서비스는 빨라"가 아니라, "우리 서비스의 평균 응답 시간은 150ms야"라고 말할 수 있게 해주는 기준점입니다.

 

2. 🎯 SLO (Service Level Objective) - 서비스 수준 목표

SLO는 위에서 측정한 SLI를 바탕으로 우리가 달성하고자 하는 구체적인 목표치입니다. 이것은 외부에 공개되는 약속이라기보다는, 개발팀과 운영팀이 지켜야 할 내부적인 품질 목표입니다.

• 🤔 핵심 질문: "측정된 값이 어느 수준이어야 사용자가 만족할까?"
• 🌡️ 비유: "실내 온도를 항상 24도로 유지하자!"는 목표 온도 설정
• 역할: 막연한 '개선'이 아닌, 명확한 목표를 제시하여 팀의 방향을 정해줍니다.

주요 SLO 예시:

• "월간 가용성(SLI)은 99.9% 이상이어야 한다." (Four Nines)
• "홈페이지 접속 요청의 95%는 300ms 이내에 처리되어야 한다."
• "결제 API의 에러율(SLI)은 0.1% 미만으로 유지해야 한다."

SLO는 "사용자가 불편함을 느끼지 않을 마지노선"을 정하는 것이라고 할 수 있습니다.

 

3. ✍️ SLA (Service Level Agreement) - 서비스 수준 계약

SLA는 우리가 정한 목표(SLO)를 지키지 못했을 때 어떤 책임을 질 것인지 고객과 맺는 공식적인 계약입니다. 만약의 사태에 대한 보상안이 포함된, 법적 효력을 가질 수 있는 약속이죠.

• 🤔 핵심 질문: "목표를 지키지 못하면 고객에게 무엇을 해주어야 하나?"
• 📜 비유: "목표 온도를 못 맞추면 냉방 요금을 10% 환불해 드립니다"라는 계약서
• 역할: 고객에게 서비스 품질에 대한 신뢰를 주고, 비즈니스를 보호하는 장치입니다.

SLA 예시:

• "월간 가용성이 99.9%(SLO)에 미치지 못할 경우, 다음 달 서비스 이용료의 10%를 환불해 드립니다."

보통 SLA는 비즈니스를 보호하기 위해 내부 목표인 SLO보다 약간 더 여유 있는 수치로 설정됩니다.

 

🍕 이해가 쏙쏙! 우리 동네 피자 가게 이야기

아직도 헷갈리신다면, 이 피자 가게 이야기에 집중해 보세요!

• 🔬 SLI (지표): 주문이 들어온 순간부터 고객에게 피자가 전달되기까지의 '실제 배달 시간'을 하나하나 측정합니다. (예: 25분, 32분, 18분...)
• 🎯 SLO (내부 목표): 사장님은 가게의 품질 유지를 위해 "전체 배달 주문의 95%는 30분 안에 완료한다!" 라는 내부 목표를 세웁니다. 이 목표를 위해 주방 동선과 배달 시스템을 계속 개선하죠.
• ✍️ SLA (고객과의 계약): 전단지에는 "40분 안에 배달되지 않으면 피자는 공짜!" 라고 광고합니다. 고객에게는 이 약속을 통해 서비스 품질에 대한 확신을 줍니다. (내부 목표 30분보다 10분의 여유를 두었죠!)

어떤가요? 이제 세 가지의 관계가 명확하게 그려지시나요?

 

👑 SLO의 핵심, '오류 예산(Error Budget)'을 아시나요?

SLO를 설정하면 아주 강력한 무기, '오류 예산' 이 생깁니다.

• 오류 예산 = 100% - SLO

만약 우리 서비스의 가용성 SLO가 99.9%라면, 오류 예산은 0.1%가 됩니다. 한 달(30일) 기준으로 약 43분의 시간이 주어지는 셈이죠.

이 43분은 우리 서비스가 '실패해도 괜찮은 시간' 입니다. 개발팀은 이 예산 안에서 새로운 기능을 배포하며 위험을 감수할 수도 있고, 시스템 점검을 위해 잠시 서비스를 내릴 수도 있습니다.

만약 장애가 발생해서 이 오류 예산을 모두 소진한다면? 🚨 그때는 모든 신규 기능 개발을 멈추고 서비스 안정화 작업에만 집중해야 한다는 강력한 데이터 기반의 의사결정을 내릴 수 있습니다. 즉, 오류 예산은 '혁신의 속도'와 '서비스의 안정성' 사이에서 똑똑한 줄다리기를 할 수 있게 해주는 최고의 도구입니다.

 

마치며

이제 SLI, SLO, SLA는 더 이상 어려운 암호가 아닐 겁니다.

• SLI로 우리 서비스의 건강을 측정하고,
• SLO로 사용자가 만족할 만한 목표를 세우며,
• SLA로 고객에게 신뢰를 약속하는 것.

이 세 가지 개념은 막연한 감에 의존하던 서비스 관리를 데이터 기반의 과학적인 영역으로 이끌어주는 핵심 열쇠입니다. 여러분의 서비스에도 오늘 배운 개념들을 적용하여 사용자와 개발팀 모두가 행복한 서비스를 만들어가시길 바랍니다!

---

태그: SLO, SLI, SLA, SRE, DevOps, 서비스 수준 목표, 오류 예산, Observability, 모니터링