1편 · 약 22분

SRE 기초와 에러 버짓: 신뢰성 공학의 원칙

신뢰성은 피처다

"서비스가 안 죽으면 된다"는 생각은 운영 현실에서 금방 한계에 부딪힌다. 아무도 쓰지 않는 서비스는 100% 가용성이 의미 없고, 하루 수억 건 트랜잭션을 처리하는 서비스는 99.9%로도 사용자가 매일 에러를 경험한다. 신뢰성의 목표를 "최대화"로 놓으면 모든 변경이 적이 된다. 배포를 줄이고, 기능을 안 만들고, 롤백을 거듭하다 보면 결국 제품도, 팀도 느려진다.

Google이 SRE(Site Reliability Engineering) 개념을 만들며 낸 첫 번째 답은 이것이다.

신뢰성은 가장 중요한 피처다. 그리고 피처처럼 관리해야 한다.

신뢰성을 정량화하고, 목표를 정하고, 그 목표에 도달하면 나머지 예산은 혁신에 쓴다. 이것이 에러 버짓의 아이디어다.

SRE란 무엇인가

SRE는 Google이 2003년부터 발전시켜 온 운영 방법론이다. 소프트웨어 엔지니어가 전통적 시스템 관리자 역할을 맡되, 운영 문제를 소프트웨어 문제로 푼다는 발상에서 출발했다.

개념을 처음 접할 때 흔히 나오는 오해는 "SRE = DevOps"다. 둘은 같은 방향을 보지만 결이 다르다.

항목	DevOps	SRE
성격	문화·철학·관행	구체적 역할·구현 방식
목표	개발-운영 통합, 빠른 배포	신뢰성 확보, 에러 버짓으로 속도와 안정성 균형
측정	DORA metrics, deploy frequency	SLO, 에러 버짓 소비율, 토일 비율
원칙	자동화, 협업, 지속적 개선	SLO 기반 판단, 50% 규칙, 토일 제거

DevOps를 문화 운동에 비유한다면, SRE는 그 문화를 실천하는 하나의 설계 패턴이라고 이해하면 된다.

SRE의 다섯 가지 원칙

Google SRE 북이 제시하는 핵심 원칙을 실무 관점으로 정리하면 다음과 같다.

1. SLO를 신뢰성의 언어로 삼는다

장애를 "있다/없다"가 아니라 "에러 버짓을 얼마나 소비했는가"로 표현한다. SLO(Service Level Objective)가 93%라면 에러 버짓은 7%다. 이 숫자가 팀이 공유하는 운영 판단의 기준이 된다.

2. 에러 버짓으로 속도와 안정성을 균형시킨다

에러 버짓이 남아 있으면 배포를 진행한다. 에러 버짓이 소진되면 새 기능 배포를 멈추고 신뢰성 작업에 집중한다. "배포해도 되는가?"의 판단을 사람 간 협의가 아니라 데이터로 한다.

3. 토일을 제거한다

토일(toil)은 반복적이고 자동화 가능하고 서비스 성장과 함께 선형으로 증가하는 수동 작업이다. SRE 팀은 전체 업무의 50% 이상을 토일로 쓰지 않는 것을 목표로 한다.

4. 관측성을 공학의 기반으로 둔다

"어떤 일이 일어났는가"를 지속적으로 측정한다. 알림은 SLO 소비 기반이며, 페이지는 사람이 즉각 행동해야 할 때만 보낸다.

5. 포스트모텀 문화로 학습한다

장애를 개인의 실수가 아닌 시스템의 취약점으로 본다. 재발 방지 액션 아이템이 완료될 때까지 포스트모텀 사이클이 닫히지 않는다.

에러 버짓이란

에러 버짓은 SLO가 허용하는 불신뢰성의 총량이다.

에러 버짓 = 1 - SLO

예: SLO = 99.9%
    에러 버짓 = 0.1%
    한 달(720h) 기준 허용 다운타임 ≈ 43.2분

주어진 기간(보통 28~30일 롤링, 또는 분기) 안에서 얼마만큼의 장애가 허용되는지를 수치로 표현한 것이다.

에러 버짓이 강력한 이유는 개발팀과 SRE팀 양쪽 모두에게 같은 숫자를 준다는 점이다. "배포할 수 있는가?"는 더 이상 의견의 문제가 아니다. 에러 버짓이 50% 이상 남았으면 배포 가능, 소진되었으면 배포 보류가 기본 정책이다.

에러 버짓과 배포 정책

Google SRE 북은 이렇게 정리한다. SLO를 달성하고 있으면 릴리스 정책에 따라 배포한다. 에러 버짓이 4주 윈도우 기준 소진됐으면 P0 또는 보안 픽스 외 배포를 중단한다. 중단은 벌칙이 아니다. 데이터가 "지금은 안정성이 새 기능보다 더 중요하다"고 말하는 것이다.

SLO 측정
28일 롤링 윈도우 → 에러 버짓 계산
소비량 확인 → 배포 판단
버짓 남음 → 배포 진행
버짓 소진 → 신뢰성 집중

버짓 소진 시 집중 항목

장애 원인 분석 토일 제거 자동화 인프라 안정화

버짓 여유 시 집중 항목

기능 배포 실험·A/B 테스트 인프라 개선 배포

에러 버짓과 배포 정책 결정 흐름

토일: SRE 팀을 잠식하는 작업

토일은 다음 특성을 모두 가진 작업이다.

수동(manual): 사람이 직접 실행한다.
반복(repetitive): 비슷한 작업을 계속 한다.
자동화 가능(automatable): 스크립트나 시스템으로 대체할 수 있다.
전술적(tactical): 즉각 해결하지만 장기 개선이 없다.
지속적 가치 없음(no enduring value): 끝냈을 때 시스템이 더 좋아지지 않는다.
선형 증가(linear scale): 서비스가 커질수록 작업량도 늘어난다.

온콜 티켓 처리, 수동 배포 확인, 임시 스크립트 실행, 반복되는 사용자 요청 처리가 대표적인 토일이다.

Google SRE 북의 50% 규칙은 명확하다. SRE 팀의 시간 중 50% 이상이 토일로 소비된다면 그것은 팀 운영 문제다. 관리자는 추가 인력 채용, 엔지니어링 작업 재배분, 토일을 생성하는 시스템 개선 중 하나를 선택해야 한다.

토일 비율을 추적하는 실용적 방법은 다음과 같다.

2~4주 동안 팀원이 실제 업무 시간을 기록한다.
각 활동을 '토일', '개선 엔지니어링', '기타'로 분류한다.
티켓 시스템에서 반복 티켓 비율을 계산한다.
온콜 handoff 노트에서 반복 패턴을 추출한다.

SRE 팀의 구조와 역할

SRE 팀을 어떻게 구성하느냐는 조직 규모에 따라 다르지만, 역할의 분리 원칙은 공통이다.

개발팀(product/dev)은 기능과 속도에 책임이 있다. SRE팀은 신뢰성과 운영 효율에 책임이 있다. 이 둘은 에러 버짓이라는 공통 언어로 협상한다.

중요한 점은 SRE가 단순한 운영팀이 아니라는 것이다. SRE 엔지니어는 소프트웨어 엔지니어로서 운영 문제를 코드로 푼다. 반복 작업을 줄이는 자동화, 플랫폼 개선, 관측성 시스템 구축이 주 업무이며, 온콜과 장애 대응은 그 부산물이지 목적이 아니다.

SRE와 개발팀의 협력 구조

신뢰성 목표의 실용적 기준

SLO를 처음 설정할 때 가장 흔한 실수는 "99.99%면 좋은 거 아닌가?"다. 높은 SLO는 높은 비용을 요구한다. 장애를 허용하는 에러 버짓이 줄어들수록 모든 변경이 더 신중해지고, 인프라에 더 많은 투자가 필요하다.

Google의 가이드라인은 현재 사용자가 실제로 경험하는 신뢰성 수준에서 출발한다.

실용적 SLO 설정 프로세스:
1. 사용자가 "충분히 신뢰할 수 있다"고 느끼는 수준 파악
2. 현재 측정값 확인 (지난 90일 SLI 데이터)
3. 현재 측정값 ± 작은 안전 여유
4. 분기마다 검토, 조건이 바뀌면 재설정

99.99% SLO는 대부분의 서비스에 과잉 투자다. 99.9%도 한 달에 43분의 다운타임으로, 많은 내부 서비스에 충분하다. 일부 데이터 플랫폼 파이프라인의 경우 "24시간 내 완료"라는 freshness SLO가 가용성 SLO보다 훨씬 의미 있을 수 있다.

포스트모텀: 장애에서 학습하기

포스트모텀은 장애가 일어난 후 시스템의 취약점을 찾고 재발 방지 액션 아이템을 만드는 프로세스다. 핵심 원칙은 비난 없는 포스트모텀(blameless postmortem)이다. 사람을 비난하면 팀이 숨기고, 숨기면 학습이 없다.

좋은 포스트모텀의 구성 요소는 다음과 같다.

타임라인: 실제로 무슨 일이 언제 일어났는가.
영향도: 사용자, 비즈니스, SLO에 어떤 영향을 미쳤는가.
근본 원인: 왜 일어났는가. 5-Why 방법으로 깊이 파고든다.
감지와 대응: 감지가 늦었는가? 대응이 느렸는가?
액션 아이템: 구체적이고 담당자와 마감일이 있는 개선 과제.

포스트모텀은 서비스 신뢰성이 어떻게 개선되는지 보여주는 가장 중요한 문서다. 팀의 학습을 반영해 wiki나 런북이 업데이트될 때 비로소 포스트모텀 사이클이 닫힌다.

실무 체크리스트: SRE 시작점

SRE를 처음 도입하거나 현재 상태를 점검할 때 사용하는 기준이다.

서비스마다 측정하는 SLI가 있는가?
SLO가 정해져 있고, 관련 팀 모두가 동의했는가?
에러 버짓 소비량을 주간 또는 월간으로 리뷰하는가?
에러 버짓 정책(소진 시 배포 중단 등)이 문서화되어 있는가?
팀의 토일 비율을 측정한 적 있는가?
온콜 알림이 사람이 즉각 행동해야 할 것들만 포함하는가?
지난 6개월 내 포스트모텀이 있었고, 액션 아이템 추적 중인가?
신뢰성 작업에 실제로 엔지니어링 시간을 할당하고 있는가?

하나라도 "아니오"가 있다면 그것이 SRE 도입의 첫 번째 대상이다.

References

Google SRE Book, "Introduction," https://sre.google/sre-book/introduction/
Google SRE Book, "Embracing Risk," https://sre.google/sre-book/embracing-risk/
Google SRE Book, "Eliminating Toil," https://sre.google/sre-book/eliminating-toil/
Google SRE Workbook, "Implementing SLOs," https://sre.google/workbook/implementing-slos/
Google SRE Workbook, "Error Budget Policy," https://sre.google/workbook/error-budget-policy/
Atlassian, "What is SRE?" https://www.atlassian.com/incident-management/devops/sre
IBM, "7 Principles of Site Reliability Engineering," https://www.ibm.com/think/insights/sre-principles
SRE School, "What is SRE? Meaning, Architecture, Examples," https://sreschool.com/blog/sre-2/