가. SRE의 개념과 DevOps와의 차이
나. SLI·SLO·SLA의 개념과 관계
다. 에러 버짓(Error Budget) 운영 방식
라. 토일(Toil) 자동화와 SRE 도입 시 조직적 고려사항
I. 개요
Google은 2003년부터 소프트웨어 엔지니어링 원칙을 시스템 운영에 적용하는 SRE 방법론을 내부적으로 발전시켜왔다. 2016년 《Site Reliability Engineering》 서적 출판 이후 전 세계 대형 서비스 기업의 표준적인 운영 방식으로 자리잡았다. SRE는 단순한 운영 자동화가 아닌, 신뢰성을 정량적으로 측정하고 개발 속도와 균형을 맞추는 엔지니어링 규율이다.
가. SRE 개념과 DevOps와의 차이
SRE(Site Reliability Engineering)란 소프트웨어 엔지니어링 기법을 인프라·운영 문제에 적용하여 시스템의 신뢰성·확장성·효율성을 높이는 구글이 정립한 운영 방법론이다.
Google의 정의: “SRE는 소프트웨어 엔지니어에게 과거 운영팀이 해왔던 일을 시키면 어떻게 되는지의 결과다.”
| 구분 | 전통 운영(Ops) | DevOps | SRE |
|---|---|---|---|
| 목표 | 안정성 유지 | 빠른 배포·협업 | 신뢰성 + 배포 속도 균형 |
| 신뢰성 측정 | 정성적 (큰 이슈 없음) | 배포 빈도·리드타임 | SLI/SLO로 정량 측정 |
| 운영 방식 | 수동 운영 중심 | 자동화 파이프라인 | 자동화 + 토일 제거 의무화 |
| 배포 통제 | 변경 최소화 추구 | 변경 장려 | 에러 버짓 내 배포 허용 |
| 인력 구성 | 운영 전문가 | 개발+운영 협업팀 | 소프트웨어 엔지니어가 운영 담당 |
나. SLI · SLO · SLA 개념과 관계
- SLI (Service Level Indicator): 서비스 신뢰성을 측정하는 정량 지표. 대표 SLI: 가용성(성공 요청 / 전체 요청), P99 레이턴시, 오류율, 처리량(Throughput)
- SLO (Service Level Objective): SLI에 대한 내부 목표값. 예) “28일 롤링 윈도우 기준 가용성 SLI ≥ 99.9%”. SLA보다 엄격하게 설정하여 완충 여유를 둠
- SLA (Service Level Agreement): SLO를 기반으로 고객·파트너와 맺는 법적 계약. 위반 시 서비스 크레딧 환불 등 패널티 발생. 일반적으로 SLO보다 느슨하게 설정
| 서비스 유형 | SLI 항목 | SLO 목표 | SLA 계약 |
|---|---|---|---|
| API 서비스 | 성공 응답 비율 | 99.95% / 28일 | 99.9% / 월 |
| 검색 서비스 | P99 레이턴시 | < 200ms (95%) | < 500ms |
| 결제 서비스 | 트랜잭션 성공률 | 99.99% / 28일 | 99.95% |
다. 에러 버짓(Error Budget) 운영 방식
에러 버짓이란 SLO를 달성하면서도 허용 가능한 장애·다운타임의 총량이다. SLO가 99.9%라면, 에러 버짓 = 0.1% = 월 43.8분의 다운타임이 허용된다.
에러 버짓 충분 시
- 새 기능 배포 적극 허용
- 실험적 변경 시도 가능
- 개발팀 배포 속도 우선
에러 버짓 소진 시
- 신규 기능 배포 동결
- 신뢰성 개선 작업에 집중
- 포스트모텀(재발방지) 의무화
에러 버짓의 핵심 가치는 신뢰성과 개발 속도의 갈등을 객관적 숫자로 중재한다는 것이다. SRE팀이 “배포 금지”를 감정으로 결정하는 것이 아니라, “버짓이 남았으니 배포 가능 / 소진됐으니 동결”로 데이터 기반 의사결정이 가능해진다.
라. 토일 자동화와 도입 고려사항
토일(Toil)이란 반복적·수동적·자동화 가능하며 장기적 가치가 없는 운영 작업을 의미한다. 예) 수동 배포, 정기 재시작, 알람 수동 확인. SRE 원칙은 운영 업무의 50% 이하를 토일로 유지하고 나머지는 엔지니어링(자동화·플랫폼 개선)에 투자해야 한다고 규정한다.
| 조직적 고려사항 | 내용 |
|---|---|
| SRE팀 채용 기준 | 운영 경험 + 소프트웨어 엔지니어링 역량 모두 보유. 순수 Ops 인력과 구별 |
| On-call 부담 관리 | On-call 로테이션 설계, 알람 피로(Alert Fatigue) 방지, 알람의 100%가 실행 가능(Actionable)해야 함 |
| 포스트모텀 문화 | 장애 발생 시 비난 없는(Blameless) 포스트모텀 의무화. 시스템·프로세스 개선에 집중 |
| SLO 수준 결정 | 99.999%는 비용이 매우 높음. 서비스 중요도에 따라 현실적 SLO 설정 (Over-engineering 주의) |
SRE 3대 지표: SLI(측정) → SLO(내부목표) → SLA(고객계약)
에러 버짓 = 1 – SLO. 버짓 소진 시 배포 동결, 충분 시 배포 가속
토일 50% 이하 원칙 | Blameless 포스트모텀 | On-call = 소프트웨어 엔지니어