[Daily morning study] SRE(Site Reliability Engineering)와 SLO/SLI/SLA 개념

08 Jul 2026 in Daily morning study / Devops

#daily morning study

SRE란 무엇인가

SRE(Site Reliability Engineering)는 Google이 2003년부터 도입한 운영 방식으로, 소프트웨어 엔지니어링 원칙을 인프라 운영에 적용하는 개념이다. 핵심 아이디어는 단순하다. 시스템을 안정적으로 운영하는 일 자체를 소프트웨어 문제로 바라보고, 수동 작업을 자동화하며 장애를 예측 가능하게 만드는 것이다.

전통적인 Ops팀이 “변경은 곧 위험”이라는 관점을 가진 반면, SRE는 적절한 수준의 불안정성(unreliability)을 허용하면서 개발 속도와 안정성의 균형을 맞춘다.

핵심 지표: SLI, SLO, SLA

SLI (Service Level Indicator)

SLI는 서비스 품질을 측정하는 구체적인 지표다. 실제로 수집하는 메트릭이다.

가용성: (성공 응답 수) / (전체 요청 수)
지연 시간: 요청의 95%가 300ms 이내에 응답
처리량: 초당 처리 가능한 요청 수
에러율: 전체 요청 대비 5xx 응답 비율

SLI = 지난 30일간 성공 응답 / 전체 요청
    = 999,500 / 1,000,000
    = 99.95%

SLO (Service Level Objective)

SLO는 SLI에 대해 내부적으로 설정하는 목표치다. 팀이 달성하려는 신뢰성 기준이다.

SLO: 가용성 99.9% (월간 기준)
     → 허용 다운타임: 약 43.8분/월

SLO: p99 지연 시간 < 500ms
     → 99%의 요청이 500ms 이내 응답

SLO는 외부에 공개되지 않는 내부 목표이며, SLA보다 엄격하게 설정하는 것이 일반적이다. 실제 성능이 SLO를 위협하기 시작할 때 내부적으로 경보를 울릴 수 있기 때문이다.

SLA (Service Level Agreement)

SLA는 서비스 제공자와 고객 사이의 계약이다. SLO를 위반했을 때 금전적 보상, 크레딧 지급 등의 페널티가 따른다.

SLA: 월간 가용성 99.5% 보장
     → 미달 시 서비스 크레딧 환급

구분	대상	위반 결과
SLI	내부 측정 지표	—
SLO	내부 목표	엔지니어링 대응
SLA	외부 계약	금전적 페널티

Error Budget (에러 예산)

Error Budget은 SRE의 핵심 개념 중 하나다. SLO를 기반으로 허용 가능한 장애 시간 또는 오류량을 수치화한 것이다.

SLO = 99.9%라면
Error Budget = 100% - 99.9% = 0.1%

30일 기준:
  = 30일 × 24시간 × 60분 × 0.001
  = 43.2분

에러 예산이 남아 있으면 개발팀은 새 기능 배포, 실험 등을 자유롭게 진행할 수 있다. 반면 에러 예산이 소진되면 안정화 작업에 집중해야 한다. 이를 통해 개발팀과 운영팀 사이의 긴장을 조율하는 공통 기준이 된다.

Error Budget 정책 예시

에러 예산 75% 이상 잔여:  → 새 기능 배포 자유롭게 진행
에러 예산 25~75% 잔여:    → 배포 전 리뷰 강화
에러 예산 25% 미만 잔여:  → 안정화 스프린트 전환, 배포 동결
에러 예산 소진:            → 포스트모텀 필수, 재발방지 우선

Toil (반복 수동 작업) 줄이기

SRE의 중요한 원칙 중 하나가 Toil 최소화다. Toil은 다음 특성을 가진 운영 작업이다.

수동으로 수행된다
반복적이고 자동화 가능하다
비즈니스 가치를 직접 창출하지 않는다
서비스 규모가 커질수록 선형적으로 늘어난다

대표적인 Toil 예시:

매번 수동으로 서버에 SSH 접속해서 로그 확인
배포마다 사람이 직접 헬스체크 수행
알람이 울릴 때마다 같은 방법으로 재시작

SRE 팀은 전체 시간의 50% 이상을 Toil에 쓰지 않도록 한다. 이를 초과하면 Toil 제거를 최우선 과제로 삼는다.

알람 설계: Alerting on SLOs

SLO 기반 알람 설계는 단순히 임계값을 초과했을 때 알림을 보내는 것과 다르다. 에러 예산 소진 속도(Burn Rate)를 기준으로 알람을 설계한다.

Burn Rate = 현재 에러율 / SLO 에러율

SLO = 99.9% → 허용 에러율 = 0.1%
현재 에러율 = 1%

Burn Rate = 1% / 0.1% = 10배
→ 에러 예산이 정상 속도의 10배로 소진 중
→ 4.32분(43.2분 ÷ 10) 만에 예산 소진

Burn Rate가 높을수록 즉각적인 대응이 필요하다. 너무 낮은 임계값은 Alert Fatigue(알람 피로)를 유발하므로, 실제로 대응이 필요한 상황에만 알람을 보내도록 설계한다.

Blameless Postmortem (무결 포스트모텀)

장애 발생 후 포스트모텀을 작성하는 것은 SRE 문화의 핵심이다. 중요한 원칙은 비난 없이(blameless) 진행한다는 것이다.

개인의 실수를 탓하는 대신, 시스템이 왜 그런 상황을 허용했는지 구조적 원인을 찾는다. “A가 설정 파일을 잘못 올렸다”가 아니라 “설정 파일 변경이 운영 환경에 바로 반영될 수 있는 구조적 허점이 있었다”고 분석한다.

포스트모텀 구성 요소:

요약: 사고 개요, 영향 범위, 지속 시간
타임라인: 감지 → 대응 → 복구 과정 시간순 정리
근본 원인 분석 (RCA): 5 Why 기법 활용
재발 방지 액션 아이템: 담당자와 기한 명시
학습한 것들

SRE vs DevOps

SRE와 DevOps는 종종 혼용되지만 차이가 있다.

항목	DevOps	SRE
성격	문화/철학	구체적 구현 방식
주요 관심사	개발-운영 협업	신뢰성 측정과 자동화
방법론	유연함	데이터 기반, 수치화
기원	커뮤니티 주도	Google 주도

Google 식 표현으로는 “SRE는 DevOps를 구현하는 하나의 방법”이다.

실무에서의 SRE 적용 포인트

SLI 선정 기준

사용자 경험에 직접 영향을 주는 지표를 고른다. 서버 CPU 사용률보다 응답 시간이 더 좋은 SLI다. 수집이 어렵지 않고, 의미 있는 변화를 감지할 수 있어야 한다.

SLO 설정 시 주의점

처음부터 너무 높게 설정하지 않는다. 99.99%를 처음부터 목표로 하면 개발 속도가 크게 제약된다.
현재 실제 성능을 측정해서 현실적인 SLO를 먼저 설정하고, 점진적으로 올린다.
SLA는 SLO보다 5~10% 낮게 설정해서 버퍼를 확보한다.

가용성과 다운타임 환산

가용성	연간 다운타임	월간 다운타임
99%	3.65일	7.2시간
99.9%	8.76시간	43.8분
99.99%	52.6분	4.38분
99.999%	5.26분	26.3초

정리

SLI는 측정하는 것, SLO는 목표로 하는 것, SLA는 계약하는 것
Error Budget은 SLO를 기반으로 허용된 실패 여유량이며, 개발과 안정성의 균형 기준이 됨
Burn Rate 기반 알람 설계로 Alert Fatigue를 줄일 수 있음
Toil을 정량화하고 50% 이하로 관리하는 것이 SRE의 실천 원칙
Blameless Postmortem으로 장애를 학습 기회로 만드는 문화가 핵심