99.9%와 99.99%의 차이는 연간 8시간 vs 52분이다. Google이 만든 SRE(사이트 신뢰성 엔지니어링)는 소프트웨어 엔지니어가 운영을 설계할 때 어떤 일이 벌어지는지 보여준다. SLI/SLO/SLA부터 에러 버짓, 카오스 엔지니어링, 한국 기업 사례까지 — SRE의 모든 것을 정리한다.
"우리 서비스 가용성 99.9%입니다."
이 말을 들으면 대부분 "거의 완벽하네"라고 생각한다. 하지만 숫자를 펼쳐보면 이야기가 달라진다.
99.9%에서 99.99%로 가는 데는 나인(9) 하나가 추가될 뿐이다. 하지만 허용 다운타임은 8시간 45분에서 52분 33초로 — 거의 10배 줄어든다. 이 0.09%의 차이가 사용자 이탈, 매출 손실, 브랜드 신뢰도를 좌우한다.
Amazon은 100ms의 지연이 매출 1%를 떨어뜨린다고 밝혔다. 서비스가 살아 있는 것은 기능이 아니라 사업의 전제 조건이다. 그래서 Google은 2003년, 소프트웨어 엔지니어에게 운영을 맡기면 어떤 일이 벌어질까?라는 질문에서 SRE를 만들었다.
2003년, Google의 엔지니어링 VP Ben Treynor Sloss는 혁명적인 실험을 시작했다. 전통적인 운영(Ops) 팀 대신, 소프트웨어 엔지니어로 구성된 팀에게 프로덕션 시스템의 운영을 맡긴 것이다.
그의 유명한 정의:
"SRE is what happens when you ask a software engineer to design an operations function."
아이디어는 단순했다: 전통적 운영팀은 문제가 생기면 수동으로 고쳤지만, 소프트웨어 엔지니어라면 이 반복을 코드로 해결할 것이다.
| 비교 항목 | 전통적 Ops | SRE |
|---|---|---|
| 팀 구성 | 시스템 관리자 중심 | 소프트웨어 엔지니어 중심 |
| 문제 해결 방식 | 수동 대응 (티켓 기반) | 자동화 코드 작성 |
| 확장 방식 | 인원 충원 | 시스템/도구 개선 |
| 장애 대응 | "누가 실수했나" | "시스템이 왜 허용했나" |
| 성공 기준 | 장애 0건 | 에러 버짓 내 운영 |
| 변경 속도 | 느림 (변경 = 위험) | 빠름 (자동화된 안전장치) |
핵심은 마인드셋의 전환이다. 전통적 운영은 "변경은 위험하다, 최소화하라"였다면, SRE는 "변경은 불가피하다, 안전하게 빠르게 하라"로 바뀌었다. 2026년 현재, SRE 팀은 Google 검색, Gmail, YouTube 등 모든 핵심 서비스의 신뢰성을 책임진다.
SRE의 출발점은 "좋은 서비스란 무엇인가?"를 숫자로 정의하는 것이다. 감각이나 직관이 아니라, 측정 가능한 지표로.
SLI(Service Level Indicator)는 서비스 품질을 나타내는 정량적 측정값이다. "서비스가 좋다/나쁘다"를 판단하는 온도계 같은 것이다.
대표적인 SLI 4가지:
SLO(Service Level Objective)는 SLI에 목표값을 설정한 것이다. "가용성 99.95%를 유지하겠다"는 약속이다.
SLO를 설정할 때 흔한 실수: 100%를 목표로 잡는 것이다. 100%는 달성 불가능할 뿐 아니라, 모든 변경(배포, 업데이트)을 막는 독이 된다. SRE는 의도적으로 100% 미만의 목표를 설정한다 — 이것이 다음에 나올 "에러 버짓"의 출발점이다.
SLA(Service Level Agreement)는 SLO를 비즈니스 계약으로 만든 것이다. SLO를 지키지 못하면 고객에게 크레딧, 환불, 위약금 등을 제공한다.
| 구분 | SLO | SLA |
|---|---|---|
| 대상 | 내부 엔지니어링 팀 | 외부 고객 |
| 강제력 | 기술적 목표 | 법적/계약적 구속력 |
| 수준 | 더 엄격 (여유분 확보) | SLO보다 약간 느슨 |
| 예시 | 가용성 99.95% | 가용성 99.9% (미달 시 10% 크레딧) |
SRE에서 가장 반직관적이면서 가장 혁신적인 개념이 에러 버짓(Error Budget)이다.
에러 버짓의 공식은 단순하다:
SLO가 99.95%라면, 에러 버짓은 0.05%이다. 월간 요청 1억 건 기준으로 50,000건의 에러가 허용된다는 뜻이다.
에러 버짓의 진짜 힘: 개발팀("빨리 배포")과 운영팀("건드리지 마라")의 갈등을 데이터로 해결한다. "에러 버짓이 남아있는가?"라는 객관적 질문으로 바꾸는 것이다.
SRE에서 토일(Toil)은 단순 반복적이고, 자동화 가능하며, 서비스 성장에 비례해서 늘어나는 운영 작업을 말한다.
예를 들어, "수동 서버 증설"은 토일이고, "자동 스케일링 시스템 구축"은 엔지니어링 워크이다.
Google SRE의 핵심 원칙: SRE 엔지니어의 업무 시간 중 토일은 최대 50%로 제한한다. 나머지 50% 이상은 반드시 엔지니어링 프로젝트 — 즉 자동화, 도구 개발, 시스템 설계 — 에 투자해야 한다.
토일이 50%를 넘으면 자동화 프로젝트를 시작하거나 인원을 충원해야 한다. 토일을 줄이는 것은 게으른 것이 아니라, 시스템이 인간 없이도 스스로 회복하도록 만드는 엔지니어링이다.
장애가 발생했을 때 가장 먼저 나오는 질문: "지금 무슨 일이 벌어지고 있는가?"
이 질문에 답하려면 시스템이 관측 가능(observable)해야 한다. SRE에서는 이를 옵저버빌리티(Observability)라 부르며, 세 가지 기둥으로 구성된다.
상황: 사용자가 "결제가 안 돼요"라고 신고했다.
대표적 도구 조합: 메트릭은 Prometheus + Grafana(오픈소스) 또는 Datadog(SaaS), 로그는 ELK Stack 또는 Splunk, 트레이스는 Jaeger 또는 Datadog APM. 올인원이 필요하면 Datadog이 대세이다.
모니터링에서 가장 흔한 실수는 알림 피로(Alert Fatigue)이다. Google SRE의 원칙: 긴급하고, 행동 가능하고, 중복 없는 알림만 보낸다. "CPU 90% 초과" 같은 원인 기반이 아니라, "에러율이 SLO를 위협" 같은 결과 기반 알림을 사용한다.
서비스는 24시간 돌아간다. 새벽 3시에 장애가 나면 누군가는 대응해야 한다. 이것이 온콜(On-Call) 제도이다.
SRE 팀원들은 1~2주 간격으로 온콜 로테이션을 돈다. 알림을 5분 내에 확인하고, 필요하면 에스컬레이션한다. Google의 규칙: 교대 근무당 페이지(알림) 최대 2건. 그 이상이면 시스템에 구조적 문제가 있다는 뜻이다.
대규모 장애가 발생하면 인시던트 관리 프로세스가 작동한다. 핵심은 역할 분담:
장애가 복구된 후에는 포스트모텀(사후 분석)을 작성한다. SRE에서 포스트모텀의 핵심 원칙은 블레임리스(Blameless) — 사람을 탓하지 않는 것이다.
"김 대리가 실수로 프로덕션 DB를 날렸다" ← 나쁜 포스트모텀 "프로덕션 DB 삭제 명령이 확인 절차 없이 실행 가능했다" ← 좋은 포스트모텀
2010년, Netflix가 AWS로 이전하면서 카오스 몽키(Chaos Monkey)를 만들었다. 이름 그대로, 프로덕션 환경에서 무작위로 서버를 꺼버리는 프로그램이다.
논리는 명확하다: 통제된 환경에서 미리 경험하는 것이 새벽 3시에 당하는 것보다 낫다.
대표 도구: Netflix의 Chaos Monkey(무작위 인스턴스 종료), Gremlin(GUI 기반 안전한 실험), CNCF의 Litmus(K8s 네이티브), AWS FIS(관리형), Chaos Mesh(네트워크 장애 주입).
단, 준비 없이 시작하면 진짜 장애가 된다. 모니터링이 먼저 갖춰져야 하고, 롤백 계획이 필수이며, 범위를 좁게(인스턴스 1개부터) 시작해야 한다.
이 세 가지 용어는 종종 혼동된다. 정리하면:
| 비교 항목 | DevOps | SRE | Platform Engineering |
|---|---|---|---|
| 본질 | 문화/철학 | 직무/역할 | 제품/플랫폼 |
| 핵심 질문 | "개발과 운영을 어떻게 합칠까?" | "서비스를 어떻게 신뢰성 있게 운영할까?" | "개발자가 셀프서비스로 인프라를 쓰게 하려면?" |
| 탄생 | 2009년 (Patrick Debois) | 2003년 (Google) | 2020년대 (진화) |
| 초점 | CI/CD 파이프라인, 협업 | SLO, 에러 버짓, 인시던트 | IDP (내부 개발자 플랫폼) |
| 결과물 | 파이프라인, 자동화 프로세스 | SLO 대시보드, 런북, 자동 복구 | 셀프서비스 포털, 골든 패스 |
| 관계 | 방향성 (Why) | 구현체 (How) | 플랫폼 (What) |
Google이 직접 밝힌 정의: "Class SRE implements interface DevOps." DevOps는 인터페이스(원칙)이고, SRE는 그 구현체(실천)이고, Platform Engineering은 그 결과물의 제품화이다.
세 가지는 상호 배타적이지 않다. DevOps 문화 + SRE 방법론 + Platform Engineering의 개발자 경험이 이상적인 조합이다.
2022년 10월 15일, 카카오의 SK C&C 판교 데이터센터에서 화재가 발생했다. 카카오톡, 카카오맵, 카카오페이, 카카오택시 — 사실상 한국인의 디지털 생활 전체가 동시에 멈췄다.
네이버는 서비스별 세분화된 SLO와 에러 버짓 기반 배포를 운영한다. 특히 자체 개발한 분산 트레이싱 도구 Pinpoint는 GitHub 13,000+ 스타를 받은 세계적인 오픈소스 APM으로 성장했다.
토스는 송금 성공률 SLO 99.99% 이상을 유지한다. 장애 감지부터 에스컬레이션까지 자동화하고, PG사 연동 실패 등 금융 특화 카오스 엔지니어링을 정기 실행한다. 블레임리스 포스트모텀을 전사에 공개하는 문화도 주목할 만하다.
2022년 카카오 사태를 기점으로, SRE는 한국 IT 업계에서 가장 빠르게 성장하는 직군이 되었다. 카카오, 네이버, 토스, 쿠팡, 배달의민족 모두 SRE 채용을 대폭 확대 중이다.
세 권 모두 Google이 무료로 공개했다. sre.google/books에서 전문을 읽을 수 있다.
SRE를 시작하려면 어떤 도구부터 익혀야 할까? 단계별로 정리했다.
인시던트 관리 도구는 PagerDuty(시장 1위, AI 자동 분류), OpsGenie(Atlassian 통합, $9.45~/월), Grafana OnCall(오픈소스, 무료)이 대표적이다.
SRE가 되려면 어떤 경로를 밟아야 할까?
핵심 역량: Python/Go 프로그래밍, Linux, AWS/GCP 클라우드, Docker + Kubernetes, Terraform(IaC), Prometheus + Grafana(모니터링), TCP/IP/DNS 네트워크 기초, 그리고 장애 상황의 소통 능력.
이 글에서 다룬 내용을 한 장으로 정리하면:
SRE는 도구의 집합이 아니라, 서비스 신뢰성을 엔지니어링 문제로 접근하는 사고방식이다. "100%는 불가능하다"를 받아들이는 겸손, 장애에서 배우는 블레임리스 문화, 반복을 참지 않는 자동화 본능, 모든 것을 숫자로 결정하는 원칙.
카카오 사태가 보여주었듯, SRE는 평소에는 보이지 않지만 없으면 모든 것이 멈추는 일이다. 처음 시작한다면, Google SRE Book을 읽고, Prometheus + Grafana를 로컬에 띄우고, 자신의 서비스에 SLO를 하나 설정해보자. 그것이 첫 걸음이다.
