콘텐츠로 건너뛰기

SRE·SLO 완벽 가이드: 에러 버짓으로 안정성을 관리하는 법

서비스가 잘 돌아가는지를 ‘감’으로 관리하면 장애가 반복되고, 반대로 100% 완벽을 좇으면 배포가 느려집니다. SRE(Site Reliability Engineering, 사이트 신뢰성 엔지니어링)는 구글이 정립한 방법론으로, 소프트웨어 엔지니어링 방식으로 시스템 안정성을 측정 가능한 목표로 만들어 운영합니다. 핵심 도구는 SLI·SLO·SLA와 ‘에러 버짓’입니다. 이 글에서 개념과 실무 관점을 정리합니다.

핵심 요약

  • SRE는 소프트웨어 엔지니어링으로 운영·안정성 문제를 푸는 방법론입니다(구글 발).
  • 안정성을 SLI(측정 지표) → SLO(목표치) → SLA(고객 계약) 순서로 수치화합니다.
  • 에러 버짓 = 100% − SLO. 허용된 실패량으로, 남으면 새 기능 배포, 소진되면 안정화에 집중합니다.
  • 100% 안정성은 비효율적입니다. 서비스에 맞는 적정 목표(예: 99.9%)를 정하는 것이 SRE의 출발점입니다.

SRE란 무엇인가

SRE는 운영을 엔지니어링 문제로 다루는 접근입니다. 수작업 대응 대신 지표를 정의하고, 목표를 수치로 세우고, 반복 작업(토일, toil)을 코드로 자동화합니다. 구글은 “SRE는 DevOps를 구체적으로 구현한 것”이라고 설명하는데, 핵심은 ‘안정성을 측정하고 목표에 따라 의사결정한다’는 데 있습니다.

SLI · SLO · SLA

세 용어는 안정성을 수치화하는 뼈대입니다. 헷갈리기 쉬워 표로 정리했습니다.

용어예시
SLI (지표)실제로 측정하는 값가용성, 지연시간, 오류율
SLO (목표)내부적으로 정한 목표치월 99.9% 가용성
SLA (계약)고객과의 약정 + 위반 시 보상99.9% 미달 시 요금 환급

에러 버짓이란

  • 정의: 에러 버짓 = 100% − SLO. SLO가 99.9%라면 0.1%가 허용된 실패량입니다.
  • 용도: 버짓이 남으면 새 기능 배포·실험을 가속하고, 소진되면 배포를 멈추고 안정화에 집중합니다.
  • 효과: ‘안정성 vs 배포 속도’라는 해묵은 갈등을 감정이 아니라 데이터로 조정합니다.

SRE vs DevOps

둘은 경쟁 관계가 아닙니다. DevOps가 개발과 운영의 벽을 허무는 ‘문화·철학’이라면, SRE는 그것을 SLO·에러 버짓·자동화 같은 구체적 실천으로 구현한 것입니다. 배포 파이프라인은 CI/CDGitOps로, 상태 측정은 관측으로 이어집니다.

인프라·취업 관점

  • 측정이 기본: SLI를 재려면 옵저버빌리티(로그·메트릭·트레이스)가 전제입니다.
  • 운영 문화: 온콜(on-call), 비난 없는 포스트모템(postmortem), 토일 자동화가 SRE의 일상입니다.
  • 환경: 쿠버네티스 위에서의 신뢰성 설계가 중요하며, Prometheus·Grafana·PagerDuty가 대표 도구입니다.
  • 채용 관점: ‘SLO 설계’, ‘에러 버짓 운영’, ‘온콜·장애 대응’, ‘Prometheus/Grafana’는 SRE·플랫폼 직무 공고의 핵심 키워드입니다.

자주 묻는 질문(FAQ)

SLO는 몇 %로 잡아야 하나요?

서비스 특성에 따라 다릅니다. 99.9%가 흔하지만, 무조건 높일수록 좋은 것은 아닙니다. 목표를 올릴수록 비용과 개발 속도 저하가 커지므로, 사용자가 체감하는 수준에서 ‘적정선’을 정하는 것이 중요합니다.

SRE와 DevOps는 무엇이 다른가요?

DevOps는 개발·운영 협업의 문화·철학이고, SRE는 그것을 SLO·에러 버짓·자동화로 구현한 구체적 방법론입니다. “SRE는 DevOps의 한 구현체”라고 이해하면 쉽습니다.

에러 버짓이 소진되면 어떻게 하나요?

보통 새 기능 배포를 잠시 멈추고 안정성 개선에 집중합니다. 즉 에러 버짓은 배포 속도를 조절하는 ‘신호등’ 역할을 합니다.

신입이 SRE를 어디까지 알아야 하나요?

SLI·SLO·SLA와 에러 버짓의 개념, 옵저버빌리티의 역할, 온콜·포스트모템 문화, Prometheus·Grafana의 쓰임을 이해하면 SRE·플랫폼 직무에서 확실한 강점이 됩니다.

더 읽어보기

※ 이 글은 SRE·SLO의 핵심 개념을 정리한 입문·실무 안내용 자료입니다. 실제 목표치와 운영 방식은 서비스 특성과 조직 상황에 따라 달라질 수 있습니다.

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다