SRE란 무엇인가 — 왜 필요한가

EKS 관측 플랫폼을 만들고, KEDA/Karpenter로 오토스케일링을 붙이고, 장애를 직접 겪으며 대응해보면 자연스럽게 드는 질문이 있다. "이거 결국 SRE 아니야?" 맞기도 하고, 정확히는 아니기도 하다. 관측 스택을 만드는 건 SRE가 하는 일 중 하나지, SRE라는 역할 자체를 정의하지는 않는다. SRE가 뭔지 제대로 짚고 넘어가면 이후 글들이 왜 이 순서로 이어지는지가 보인다.

SRE의 정의

SRE(Site Reliability Engineering)는 Google이 2000년대 초반에 만든 개념으로, 만든 사람인 Ben Treynor Sloss의 정의가 가장 자주 인용된다.

"SRE is what happens when you ask a software engineer to design an operations team." (소프트웨어 엔지니어에게 운영팀을 설계해보라고 시키면 나오는 결과물이 SRE다.)

풀어 쓰면 이렇다. 전통적인 운영(Ops)팀은 수작업으로 서버를 관리하고, 장애가 나면 사람이 직접 들어가 고친다. SRE는 그 운영 문제를 소프트웨어 엔지니어링 문제로 취급한다. 반복되는 운영 작업은 코드로 자동화하고, "얼마나 안정적이어야 하는가"를 감(feel)이 아니라 숫자(SLI/SLO)로 정의하고, 그 숫자를 근거로 언제 무엇에 시간을 쓸지 결정한다.

SRE와 DevOps의 관계도 자주 헷갈린다. DevOps는 "개발과 운영을 가르지 말고 함께 움직이자"는 철학·문화적 개념이라 구체적으로 어떻게 실행하라는 규정이 없다. SRE는 Google이 실제로 운영한 DevOps의 구체적인 구현체 하나에 가깝다 — SLO, 에러버짓, 토일(toil) 관리, 블레임리스 포스트모템 같은 명시적 관행(practice)의 집합으로 그 철학을 실행한다.

1DevOps  = "개발과 운영이 협업해야 한다"는 철학, 구현 방법은 조직마다 다름
2SRE     = 그 철학의 한 구현체. Google이 실제로 쓴, 측정 가능한 관행들의 집합

왜 필요했나 — 전통적 구조의 문제

Dev팀과 Ops팀을 분리해두면 구조적으로 인센티브가 반대 방향을 향한다.

이 구도에서는 Ops가 배포를 막을수록 "안전"하고, Dev가 빨리 낼수록 "생산적"이라고 서로 다르게 평가받는다. 같은 회사인데 목표가 충돌한다. 게다가 시스템이 커질수록(마이크로서비스, 다중 리전, 24/7 트래픽) 사람이 수작업으로 대응하는 방식 자체가 규모를 못 따라간다 — 서버가 10대일 땐 한 명이 SSH로 들어가 고칠 수 있지만, 파드가 수천 개인 클러스터에서는 불가능하다.

SRE는 이 갈등을 감정이나 조직 논쟁이 아니라 숫자로 풀자는 제안이다. 그 숫자가 SLI/SLO/에러버짓이다 — "이번 달 실패해도 되는 양"을 미리 정해두면, 그 예산 안에서는 Dev가 마음껏 배포해도 되고, 예산을 다 쓰면 자동으로 안정화에 집중한다. Dev와 Ops가 싸울 필요 없이 같은 숫자를 보고 우선순위를 정한다.

SRE vs 전통 Ops vs DevOps

SRE의 핵심 원칙

Google SRE 책이 정리한 관행들을 요약하면 아래로 모인다.

• 위험을 받아들인다(Embracing Risk) — 100% 신뢰성은 목표가 아니다. 100%를 향할수록 비용은 기하급수로 늘고, 어차피 클라이언트·네트워크·전원 같은 외부 요인이 100%를 막는다. "적정 신뢰성"을 사업이 정하게 하고, 그 이상은 낭비로 본다.
• SLI / SLO / 에러버짓 — 무엇을 잴지(SLI), 목표치가 얼마인지(SLO), 그 여유를 어떻게 쓸지(에러버짓)를 숫자로 합의한다. Dev/Ops 갈등을 정량적으로 중재하는 핵심 도구.
• 토일(Toil) 줄이기 — 반복적이고, 자동화 가능하고, 장기적 가치가 없는 수작업(재시작, 수동 스케일링, 티켓 처리 등)을 토일이라 부르고, SRE 업무 시간의 50% 이하로 유지하는 걸 원칙으로 삼는다. 나머지 시간은 엔지니어링(자동화, 도구 개발)에 쓴다.
• 증상 기반 모니터링 — 원인이 될 만한 모든 지표에 알림을 걸지 않고, 사용자가 느끼는 증상(SLI)에 알림을 건다. 원인 지표(CPU, 메모리)와 증상 지표(SLI)를 구분해야 하는 이유와 같은 맥락이다.
• 자동화 — 사람이 반복하는 절차는 스크립트나 오퍼레이터로 옮긴다. KEDA/Karpenter의 자동 스케일링이나 ArgoCD의 GitOps 동기화가 이 원칙의 실제 사례다.
• 점진적 배포(Progressive Delivery) — 한 번에 전체를 배포하지 않고 카나리, 블루/그린, 단계적 롤아웃으로 위험을 줄인다. 문제가 생기면 자동 롤백.
• 용량 계획(Capacity Planning) — 트래픽 성장을 예측해 미리 확보하되, 과도한 여유는 낭비이므로 오토스케일링과 병행한다.
• 블레임리스 포스트모템(Blameless Postmortem) — 장애 후 "누가 잘못했나"가 아니라 "시스템이 왜 이 실수를 막지 못했나"를 묻는다. 책임 추궁은 다음번엔 실수를 숨기게 만들 뿐, 시스템을 안 고친다.
• 지속 가능한 온콜(Sustainable On-call) — 온콜 부담이 특정 개인에게 과하게 쏠리지 않도록 로테이션·알림 규칙을 설계한다. 밤마다 오탐 알림에 깨우는 구조는 SRE가 실패한 상태로 본다.

지금까지 만든 것들이 실은 SRE였다

각각은 따로 보면 인프라 작업 같지만, "사람이 반복 수작업으로 하던 걸 자동화하고, 안정성을 감이 아니라 숫자로 재고 대응한다"는 한 가지 원칙 아래 있다. 이게 SRE가 인프라 엔지니어링과 다른 지점이다 — 인프라를 잘 다루는 게 목적이 아니라, 그걸 통해 신뢰성을 측정 가능하고 지속 가능하게 만드는 게 목적이다.

흔한 오해

• "SRE = 인프라 엔지니어를 부르는 새 이름이다" — 아니다. 인프라를 잘 아는 건 필요조건이지만, SRE의 정체성은 소프트웨어 엔지니어링으로 운영 문제를 푼다는 접근 방식에 있다. 코드를 안 짜고 수작업만 반복하면 SRE가 아니라 전통 Ops다.
• "SRE는 항상 시스템이 안 죽게 만드는 팀이다" — 반대에 가깝다. SRE는 "얼마나 죽어도 되는지"를 먼저 정한다(에러버짓). 100% 무중단을 추구하지 않는다.
• "모니터링 대시보드를 잘 만들면 SRE다" — 대시보드는 도구다. SLO를 정의하고, 그 위반 속도로 알림을 설계하고, 포스트모템으로 시스템을 고치는 프로세스 전체가 SRE다.
• "작은 팀엔 필요 없다" — 원칙 자체는 규모와 무관하다. 서비스가 하나뿐이어도 "언제 사람이 깨어나야 하는가"를 숫자로 정해두면 이미 SRE적으로 일하는 것이다. Google 규모의 조직 구조가 필요한 게 아니다.

정리

한 줄 요약: SRE는 "서버를 잘 관리하는 팀"이 아니라, "안정성을 소프트웨어 엔지니어링 문제로 바꿔서 자동화·수치화·프로세스화하는 접근"이다. 관측 스택, 오토스케일링, 장애 대응, SLO — 지금까지의 글들은 전부 이 접근을 하나씩 실제로 적용해본 기록이다.