💡 핵심 인사이트
SRE(사이트 신뢰성 공학)는 구글(Google)이 고안한 운영 철학으로, 애자일/데브옵스의 "빨리 배포하자!"는 압박 속에서도 시스템이 죽지 않도록, '운영(Ops) 업무'를 마치 '소프트웨어 개발(코딩)'처럼 엔지니어링 방식으로 풀어나가는 혁신적인 관리 기법입니다.
핵심 무기는 "시스템이 가끔은 죽어도 된다"라고 수학적으로 허락해 주는 **'에러 예산(Error Budget)'**입니다.

Ⅰ. SRE의 탄생 (데브옵스의 구체적 실천법)

"DevOps는 철학(종교)이고, SRE는 그 종교를 믿는 사제들의 구체적인 행동 양식(교리)이다."

• 문제: 데브옵스 문화에서 "개발과 운영이 친하게 지내자!"라고 외쳤지만, 구체적으로 어떻게 일해야 하는지 룰이 없었습니다.
• 구글의 해답 (SRE): 기존 운영팀(마우스 클릭만 하던 IT 관리자)을 다 해고하고, 그 자리에 코딩을 기가 막히게 잘하는 소프트웨어 개발자들을 앉혀서 '운영(Ops)'을 맡겼습니다.
• 이들 SRE 엔지니어들은 서버가 죽으면 밤새 매뉴얼을 뒤져 재부팅하는 노가다를 하는 대신, "자동으로 서버가 살아나는 AI 코드를 짜버리자"라며 모든 인프라 장애와 운영을 철저한 **'코드 기반의 자동화(IaC)'**로 해결해 버립니다.

Ⅱ. 완벽을 포기하다: SLI, SLO, SLA

SRE의 가장 위대한 깨달음은 **"100% 무결점 시스템은 불가능하며, 사실 사용자도 그걸 원하지 않는다"**는 점입니다. (너무 완벽하게 만들려면 돈이 100배 더 듭니다.) 그래서 구글은 목표치를 낮춥니다.

1. SLI (지표): 현재 서버가 성공적으로 응답하는 비율 (예: 측정한 결과 99.95%)
2. SLO (목표) ★SRE의 척추: 경영진과 SRE 팀이 합의한 내부 타협점. "우리 서버는 딱 99.9%까지만 살려놓자!" (100%를 포기함).
3. SLA (계약): 고객과 법적으로 도장 찍은 약속. 위반 시 위약금 발생 (예: "99.0% 안 되면 돈 물어줄게"). 방어적으로 잡기 때문에 항상 SLO보다 숫자가 낮습니다.

Ⅲ. 혁명의 도구: 에러 예산 (Error Budget)

SLO를 99.9%로 잡았다는 것은, 한 달에 약 **43분 동안은 서버가 펑 터져서 먹통이 되어도 용서해 주겠다(합법적인 장애 허용 시간)**는 뜻입니다. 이 43분의 합법적 장애 시간을 **'에러 예산(Error Budget)'**이라고 부르며, 개발팀과 운영팀의 싸움을 끝내는 절대 반지가 됩니다.

[에러 예산의 활용법]

• 개발팀의 공격: 개발팀이 신기능을 마구 배포합니다. 배포하다가 서버가 가끔 터집니다. 운영팀이 화내려 할 때 개발팀이 말합니다. "아직 이번 달 에러 예산 43분 중에 20분밖에 안 까먹었잖아? 합법이야! 나 더 배포할래!" (민첩성 보장).
• 에러 예산 소진 시 (코드 프리즈): 무리한 배포로 결국 서버가 계속 터져서 43분의 예산을 다 써버렸습니다. ➔ SRE의 강력한 룰: 예산이 바닥나는 즉시 그 달의 모든 신기능 배포는 **강제 올스톱(동결)**됩니다. 개발팀은 남은 기간 동안 닥치고 신기능 개발을 멈춘 채, 시스템의 안정을 위한 버그 패치와 리팩토링(신뢰성 작업)에만 매달려야 합니다.

📢 섹션 요약 비유: SRE의 에러 예산은 개발팀에게 쥐여준 **'합법적인 지각 쿠폰(월 43분)'**입니다. 개발팀은 지각 쿠폰이 남아있는 한 맘 편히 아슬아슬하게 뛰어오며(빠른 배포와 도전) 혁신을 이룹니다. 하지만 쿠폰을 다 써버리면 지각이 절대 용납되지 않아, 그날부터는 무조건 회사 앞에서 텐트를 치고 자며(시스템 안정화 올인) 룰을 지켜야 하는 완벽한 완급 조절 시스템입니다.