SLA SLO SLI 차이 (서비스 상태, 목표, 약속)
API 운영에서 SLA, SLO, SLI는 서비스 신뢰성을 정의하는 핵심 개념입니다. 그러나 많은 경우 이 세 가지를 혼동하거나, 단순히 동일한 의미로 사용하는 경우가 많습니다. SLA, SLO, SLI — 세 단어가 다 똑같아 보인다고 느끼신 적 있으신가요? API 운영을 처음 맡았을 때 팀장이 "SLO부터 잡아"라고 했는데, 속으로 'SLA랑 뭐가 다르지?'라고 생각했던 기억이 납니다. 실제로는 각각의 역할과 목적이 명확히 구분되며, 이를 제대로 이해해야 안정적인 서비스 운영이 가능합니다. 이 글에서는 SLA, SLO, SLI의 차이를 구조적으로 정리하고, 실무에서 어떻게 활용해야 하는지 설명합니다.
SLI, 숫자로 말하는 서비스 상태
SLI(Service Level Indicator)는 서비스 신뢰성을 측정하는 가장 기초 단위입니다. 쉽게 말해 "지금 시스템이 얼마나 잘 돌아가고 있냐"를 수치로 뽑아낸 것입니다. 응답 시간(Response Time), 에러율(Error Rate), 가용성(Availability) 같은 지표들이 여기 해당합니다.
SLI를 그냥 '모니터링 수치' 정도로 여겼습니다. 그런데 그게 아니었습니다. SLI는 이후 SLO와 SLA를 설계하는 토대가 되기 때문에, 어떤 지표를 선택하느냐 자체가 서비스 신뢰성 전략의 시작점입니다. 잘못된 SLI를 잡으면 아무리 좋은 목표를 세워도 의미가 없어집니다.
가용성(Availability)이란 전체 시간 중 시스템이 정상적으로 작동한 시간의 비율을 뜻합니다. 예를 들어 99.9% 가용성이라면 한 달 기준 약 43분 정도의 다운타임이 허용된다는 의미입니다. 에러율(Error Rate)은 전체 요청 중 오류가 반환된 비율로, API 안정성을 판단하는 핵심 SLI 중 하나입니다.
일반적으로 SLI는 많으면 많을수록 좋다고 생각하는 분들도 있는데, 저는 오히려 반대 경험을 했습니다. 지표를 10개씩 잡아놨더니 정작 중요한 이상 신호를 놓치는 일이 생겼습니다. 서비스 특성에 맞는 3~5개의 핵심 SLI를 선별하는 것이 훨씬 실용적입니다. 출처: Google SRE Book에서도 측정 지표의 선택보다 '올바른 지표의 선택'이 중요하다고 명시하고 있습니다.
SLO, 현실과 이상 사이에서 목표를 잡는 법
SLO(Service Level Objective)는 SLI에 대한 내부 목표값입니다. "응답 시간 200ms 이하를 99% 요청에서 충족한다"처럼, 측정 지표에 구체적인 기준선을 붙인 것입니다. 이 목표값이 곧 운영팀의 행동 기준이 됩니다.
SLO를 처음 잡을 때 실수를 했습니다. '우리가 최고여야 한다'는 심리로 가용성 SLO를 99.99%로 잡았습니다. 그런데 이걸 유지하려니 장애 한 번 나면 팀 전체가 밤새 비상이었습니다. 과도하게 높은 SLO는 운영 비용을 폭발적으로 늘립니다. 반대로 너무 낮으면 실제로 서비스 품질이 떨어져도 아무도 경보를 울리지 않습니다.
이 균형을 잡는 데 도움이 된 개념이 에러 버짓(Error Budget)입니다. 에러 버짓이란 SLO를 역산해서 나오는 "허용 가능한 실패의 여유분"을 뜻합니다. 99.9% 가용성 SLO라면 한 달에 약 43분의 장애는 허용 범위 안에 있다는 뜻입니다. 이 개념을 도입하고 나서 팀 내에서 "지금 에러 버짓을 얼마나 썼냐"는 식으로 대화하게 됐고, 운영 의사결정이 훨씬 명확해졌습니다.
SLO를 잘 설계하기 위해 제가 실제로 적용해본 순서는 다음과 같습니다.
- 현재 시스템의 실측 SLI 데이터를 최소 4주치 수집한다. 목표는 현실 위에 세워야 합니다.
- 사용자 불만이 실제로 발생한 임계값을 파악한다. 이 지점이 SLO의 하한선이 됩니다.
- 운영 가능한 수준인지 엔지니어링 팀과 검토한다. 의욕이 앞선 목표는 오히려 팀을 지치게 만듭니다.
- 분기마다 SLO를 재검토하고 조정한다. SLO는 고정값이 아니라 살아있는 기준입니다.
SLO를 한 번 설정하면 영구적이라고 보는 시각도 있는데, 개인적으로는 그 관점이 더 위험하다고 생각합니다. 서비스는 계속 변하고, 목표도 그에 맞춰 진화해야 합니다.
SLA, 계약서 한 줄이 불러오는 무게감
SLA(Service Level Agreement)는 서비스 제공자와 고객 사이의 공식 계약입니다. SLO가 내부 목표라면, SLA는 그 목표를 외부에 약속한 것입니다. 이를 충족하지 못하면 페널티(Penalty) — 즉 위약금이나 서비스 크레딧 환불 같은 실질적 보상 의무가 발생합니다.
SLA를 처음 작성할 때 "SLO랑 같은 숫자 쓰면 되겠지"라고 생각했는데, 법무팀이 검토 후 한마디를 던졌습니다. "이 수치 못 지키면 계약 위반입니다." 그 순간 SLA와 SLO의 차이가 머릿속에서 완전히 분리됐습니다.
일반적으로 SLA는 SLO보다 약간 낮은 수준으로 설정합니다. SLO가 내부적으로 99.9%를 목표로 한다면, SLA는 99.5% 수준으로 외부에 약속하는 식입니다. 이 여유분이 없으면 조금만 상황이 나빠져도 곧바로 계약 위반이 됩니다. 출처: Google Cloud SLA를 보면 실제 클라우드 서비스들이 어떤 방식으로 SLA를 구성하는지 확인할 수 있습니다.
SLA에는 단순히 가용성 수치만 들어가는 게 아닙니다. 장애 발생 시 통보 시간, 복구 목표 시간인 RTO(Recovery Time Objective — 장애 발생 후 서비스가 정상 복구되기까지 허용되는 최대 시간), 그리고 고객 지원 응답 시간 등이 복합적으로 포함됩니다. 제 경험상 이 세부 항목들을 소홀히 했다가 나중에 고객사와 해석 충돌이 생기는 경우가 꽤 있었습니다. SLA는 작성할 때부터 모호한 표현을 철저히 제거해야 합니다.
SLA를 법적 의미가 없는 참고 문서 정도로 보는 분들도 있는데, B2B 환경에서 SLA는 실제 계약서에 첨부되는 구속력 있는 문서입니다. 숫자 하나를 잘못 적으면 연간 수천만 원의 크레딧 환불로 이어질 수 있습니다.
SLI → SLO → SLA로 이어지는 구조는 단순해 보이지만, 층위를 혼동하면 운영 현장에서 꽤 큰 혼란이 생깁니다. 측정에서 시작해서 목표를 잡고, 그 목표를 검증한 뒤에야 외부 약속으로 나가는 순서가 맞습니다. 이 순서를 역으로 밟거나 뭉뚱그리면 어느 순간 계약 위반 통보를 받거나, 팀 전체가 달성 불가능한 목표에 지쳐가는 상황을 맞게 됩니다. 개념 구분이 이론처럼 느껴지더라도, 실제 운영에서 이 세 가지를 명확히 구분하는 팀과 그렇지 않은 팀의 차이는 생각보다 훨씬 크게 나타납니다.
참고:
댓글
댓글 쓰기