47. 에러 버짓 (Error Budget)

⚠️ 이 문서는 구글의 SRE(사이트 신뢰성 공학) 철학에서 "시스템이 100% 완벽하게 다운되지 않아야 한다"는 강박을 버리고, 허용 가능한 장애율(SLO 위반분)을 '합법적인 예산(Budget)'으로 취급하여 개발 속도와 시스템 안정성 간의 갈등을 기계적으로 조율하는 에러 버짓(장애 예산) 개념을 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 우리가 달성하기로 한 서비스 수준 목표(SLO)가 '99.9% 가용성'이라면, 100%에서 이를 뺀 '나머지 0.1%'의 장애 시간(한 달에 약 43분)을 개발팀이 마음대로 쓸 수 있는 통장 잔고처럼 생각하는 것이다.
  2. 가치: 항상 무사안일을 추구하는 운영팀(Ops)과 무조건 새로운 기능을 빨리 배포하고 싶은 개발팀(Dev) 사이의 영원한 감정싸움을 종식시키고, '숫자(데이터)'에 기반한 객관적인 배포 의사결정을 가능하게 한다.
  3. 기술 체계: 에러 버짓이 남아있으면 과감한 배포와 실험을 승인하고, 버짓이 고갈(Exhausted)되면 신규 배포를 전면 중단(Freeze)하고 오직 안정성 확보(버그 픽스 등)에만 매달리게 하는 규정(Policy)으로 작동한다.

Ⅰ. 100% 가용성의 허상과 개발-운영의 갈등

시스템이 단 1초도 안 죽는다는 것은 물리적으로 불가능하며 경제적으로도 비합리적이다.

  1. 가용성의 한계 효용:
    • 가용성을 99%에서 99.9%로 올리는 비용보다, 99.9%에서 99.99%로 올리는 비용이 10배 이상 든다. 스마트폰 통신망 자체가 가끔 끊기는데, 뒷단 서버를 100%로 무한정 유지하려는 것은 엄청난 낭비다.
  2. 사일로(Silo)의 갈등:
    • 개발자(Dev)의 인사 평가는 "얼마나 많은 신기능을 빨리 출시했는가"에 달렸고, 운영자(Ops)의 평가는 "서버가 얼마나 안 죽었는가"에 달렸다.
    • 운영팀은 서버가 죽는 걸 막기 위해 개발팀의 배포 일정을 어떻게든 늦추고 검열하려 하며, 개발팀은 이를 답답해한다.

📢 섹션 요약 비유: 완벽한 무균실(100% 가용성)을 만들기 위해 소독 비용에 전 재산을 쏟는 낭비 대신, "우리 몸은 한 달에 감기 한 번(0.1%) 정도 걸려도 생명에 지장이 없다"고 합의하고, 남는 돈과 체력으로 밖으로 뛰어나가 활기차게 노는(신규 기능 개발) 구글식 철학입니다.

Ⅱ. 에러 버짓의 수학적 원리와 운영 방식

버짓(예산)은 매달 초기화되는 마이너스 통장과 같다.

  1. 에러 버짓의 계산 (SLI와 SLO):
    • 사용자 지표(SLI)를 측정하여, 우리 서비스의 허용선(SLO)을 월간 99.9%로 합의했다고 치자.
    • 한 달은 약 43,200분이다. 0.1%의 에러 버짓은 43,200 * 0.001 = 43.2분이다.
    • 즉, 우리는 한 달 동안 서버를 43.2분 동안 완전히 죽여도(에러를 뿜어도) 고객과의 약속을 어긴 것이 아니다.
  2. 통장 잔고의 활용 (Risk Taking):
    • 43분의 예산이 넉넉히 남아있다면, 개발팀은 혁신적이고 약간은 불안정한 코드를 과감하게 배포해도 운영팀이 막지 않는다. (혁신 장려)
  3. 버짓 고갈 시의 강제 조치 (Freeze):
    • 만약 이달 초반에 대형 장애가 터져서 43분의 에러 버짓을 다 써버렸다면?
    • 남은 한 달 동안 개발팀은 '신규 기능 배포 전면 금지' 조치를 당한다. 모든 엔지니어링 리소스는 코드 리팩토링, 테스트 코드 보강, 장애 대응 자동화 등 시스템 '안정성'을 복구하는 데 강제로 투입되어야 한다.

📢 섹션 요약 비유: 엄마(운영)가 아이(개발)에게 한 달에 피시방을 43분 갈 수 있는 용돈(버짓)을 줍니다. 아이는 용돈이 남았으면 자유롭게 게임(새 배포)을 할 수 있지만, 용돈을 다 써버리면 남은 한 달 동안은 강제로 집에서 공부(안정성 복구)만 해야 하는 객관적인 규칙입니다.

Ⅲ. 문화적 혁신: Blameless (비난 없는 장애 처리)

에러 버짓은 사람을 탓하는 문화를 시스템이 책임지는 문화로 바꾼다.

  1. 책임 소재의 명확화:
    • 버짓 룰을 합의했다면, 버짓 범위 내에서 발생한 장애는 배포를 한 개발자의 잘못도 아니고, 시스템을 못 막은 운영팀 잘못도 아니다. 그것은 "혁신을 위해 회사가 기꺼이 지불한 정상적인 비용"일 뿐이다.
  2. 데이터 기반 협상:
    • 비즈니스 부서(기획팀)가 "이 기능 당장 이번 주에 출시해 줘!"라고 억지를 부릴 때, 엔지니어들은 "현재 에러 버짓이 바닥나서 정책상 이번 주는 배포 불가합니다. 버짓이 충전되는 다음 달 1일에 배포하겠습니다"라며 감정 소모 없이 데이터로 방어할 수 있다.

📢 섹션 요약 비유: 교통사고가 났을 때 운전자를 욕하며 싸우는 것이 아니라, "과속방지턱(SLO)을 넘지 않고 규정 속도로 달리다 난 사고는 자동차 제조 결함(시스템 취약점)이니, 운전자를 문책하지 말고 차체 강화(리팩토링)에 투자하자"는 선진적 기업 문화입니다.