경영진이 묻습니다. "우리 서비스 안정적이에요?" 누구는 "네, 거의 안 죽어요", 누구는 "지난주 두 번 느렸어요"라고 답합니다. 감으로 말할 뿐 숫자가 없습니다. 한편 장애가 날 때마다 "누가 그랬어?"로 범인을 찾자, 사람들이 장애를 숨기기 시작하고 솔직한 분석이 사라집니다. 같은 장애가 세 번째 반복됩니다. 신뢰성은 '느낌'이 아니라 지표(SLO)로 관리하고, 장애는 '비난'이 아니라 학습(포스트모템)으로 다뤄야 합니다. 이것이 성숙한 운영 문화입니다.
- 1SLI·SLO·SLA의 차이를 "측정값·목표·계약"으로 구분할 수 있다
- 2에러버짓으로 "안정성 vs 배포 속도"를 데이터로 결정하는 법을 설명할 수 있다
- 3비난 없는 포스트모템이 재발 방지에 효과적인 이유를 설명할 수 있다
- 4관측성 세 기둥(메트릭·로그·트레이스)으로 장애를 추적하는 흐름을 설명할 수 있다
SLI · SLO · SLA — 신뢰성을 숫자로
측정값 → 내부 목표 → 외부 계약
"안정적이에요?"에 숫자로 답하려면 이 세 가지를 구분해야 합니다.
SLI (Indicator, 측정값): 실제 가용성 99.95%, p95 지연 320ms
SLO (Objective, 내부목표): 가용성 99.9% 이상, p95 < 500ms ← 우리가 지키려는 선
SLA (Agreement, 외부계약): 99.5% 보장, 미달 시 요금 보상 ← 고객과의 약속
관계: SLA(99.5%) < SLO(99.9%) ← SLO를 더 빡빡하게
→ 계약(SLA) 위반 전에 내부 경보(SLO)가 먼저 울려 대응할 여유
핵심: SLI는 [[glossary-observability]]의 메트릭으로 측정합니다. SLO는 "100%를 목표하지 않는다"는 게 중요 — 100% 가용성은 비현실적이고 비용이 무한대입니다. 적정한 불완전함을 목표로 잡는 것이 SRE의 출발점입니다.
에러버짓 — 안정성 vs 속도를 데이터로
허용된 실패의 양을 예산처럼 쓴다
SLO가 99.9%면 0.1%의 실패가 허용됩니다. 이 허용량이 에러버짓입니다.
SLO 99.9% (30일 기준) → 허용 다운타임 ≈ 43분/월 = 에러버짓
버짓이 남음(장애 적음) → 위험 감수 OK: 빠르게 배포·실험·새 기능
버짓 소진(장애 누적) → 안정화 모드: 새 기능 동결, 신뢰성 작업 우선
→ "배포를 더 할까 말까"를 감정·정치가 아니라 '남은 버짓'으로 결정
이것이 [[release-strategy]]의 배포 속도와 안정성 사이의 긴장을 푸는 도구입니다. 개발팀은 빠르게 내보내고 싶고 운영팀은 안정을 원하는데, 에러버짓은 공통의 객관적 기준을 줍니다 — "이번 달 버짓 다 썼으니 안정화 먼저"는 누구의 의견이 아니라 데이터입니다. PM은 이를 통해 기능 출시와 신뢰성 투자의 균형을 정량적으로 조율합니다.
포스트모템 — 비난이 아니라 학습
사람이 아니라 시스템을 고친다
장애 후 '누가 그랬나'를 찾으면, 사람들은 장애를 숨기고 솔직한 분석이 사라집니다. 비난 없는(blameless) 포스트모템은 질문을 바꿉니다.
비난형(나쁨): "왜 김OO이 잘못된 명령을 쳤나?" → 숨김·방어·재발
비난없음(좋음): "왜 시스템이 그 실수를 막지 못했나?"
→ 가드레일 부재? 확인 절차 없음? 위험한 명령에 안전장치 없음?
→ 사람이 아니라 '실수를 허용한 시스템'을 고침 → 재발 방지
포스트모템 구성:
1. 타임라인(언제 무슨 일이) 2. 영향(사용자·매출)
3. 근본원인(RCA) 4. 재발방지 액션(담당·기한, 테스트/자동화/알람 추가)
핵심: 인간은 반드시 실수합니다. 좋은 시스템은 '실수해도 큰일 안 나게' 만듭니다([[code-review-pr]]의 게이트, [[release-strategy]]의 롤백, [[test-strategy]]의 회귀 테스트). 포스트모템의 액션이 다음 장애를 막는 가드레일이 됩니다. [[dev-roles-collaboration]]의 인시던트 역할(IC·Comms)도 여기서 작동합니다.
신뢰성 운영 점검 — 직접 확인
조직의 신뢰성 운영이 '느낌'인지 '지표·문화'인지 점검합니다.
□ 핵심 지표(가용성·지연·에러율)를 SLI로 측정 중인가? ([[glossary-observability]])
→ 없으면 "안정적이에요?"에 숫자로 답 불가
□ SLO가 정의돼 있고, 에러버짓 소진 시 행동(안정화 모드)이 합의됐나?
→ 없으면 배포 속도 vs 안정성이 매번 정치적 논쟁
□ 모든 의미있는 장애에 비난 없는 포스트모템 + 재발방지 액션이 있나?
→ 없으면 같은 장애 반복
□ 온콜(당번)·인시던트 역할(IC)이 정해져 있나? ([[dev-roles-collaboration]])
→ 없으면 장애 초동에 "누가?"로 시간 허비
성숙도 점검 예:
SLI 측정 ✓ (Prometheus/Grafana)
SLO/에러버짓 ✗ 목표선 없음 → 배포 판단이 감
포스트모템 △ 작성하나 액션 추적 안 됨 → 재발
온콜/IC ✗ → 장애 시 우왕좌왕([[dev-roles-collaboration]])
→ SLO 정의 + 포스트모템 액션 추적 + 온콜표가 다음 개선 1순위
echo 'SLI 측정·SLO 정의·버짓 추적·포스트모템 루틴 확인'- SLI 측정이 없으면 신뢰성을 "느낌"으로 말하는 것 — 먼저 가용성·p95 지연·에러율을 메트릭으로 측정([[glossary-observability]]). 측정 없이는 목표(SLO)도 없다
- SLO·에러버짓이 없으면 "배포 더 할까"가 매번 정치적 논쟁 → 버짓을 정의해 "남으면 빠르게, 소진되면 안정화"를 데이터로 결정
- 포스트모템을 작성만 하고 재발방지 액션을 추적·완료 안 하면 같은 장애 반복 → 액션을 [[roadmap-issue-tracking]] 이슈로 박아 담당·기한 추적
- 온콜·IC(인시던트 지휘)가 없으면 장애 초동에 "누가 대응?"으로 MTTR 악화([[dev-roles-collaboration]]) → 온콜표·역할을 평시에 합의
상황: 장애가 날 때마다 "누가 배포했어?", "누가 그 명령 쳤어?"로 책임을 추궁합니다. 그러자 사람들이 작은 장애를 보고하지 않고 조용히 덮기 시작하고, 근본 원인 분석이 사라져 같은 유형의 장애가 반복됩니다. 정작 "우리 서비스 안정적인가"엔 아무도 숫자로 답하지 못합니다.
원인: 비난 문화 + 지표 부재의 결합입니다. 비난은 투명성을 죽여 학습을 막고, SLO·에러버짓이 없어 안정성을 객관적으로 관리하지 못합니다. 신뢰성이 '느낌'과 '정치'의 영역에 머뭅니다.
진단:
□ 최근 장애의 포스트모템이 '사람'을 지목하나, '시스템'을 지목하나?
□ 재발한 장애가 있나? (학습 실패의 증거)
□ "안정적인가?"에 SLI 숫자로 답할 수 있나?
해결: (1) 비난 없는 포스트모템 도입 — '누구'가 아니라 '왜 시스템이 막지 못했나'를 묻고, 재발방지 액션(가드레일·테스트·자동화·알람)을 [[roadmap-issue-tracking]] 이슈로 추적. (2) 핵심 SLI를 측정하고 SLO·에러버짓을 정의해 안정성을 데이터로 관리. (3) 온콜·IC 역할을 평시에 합의([[dev-roles-collaboration]]). 신뢰성은 영웅의 야근이 아니라, 측정·문화·시스템으로 만들어집니다.
인프라/SRE로서 이 모듈은 당신 직무의 핵심 철학입니다 — 신뢰성을 SLI로 측정하고 SLO·에러버짓으로 '안정성 vs 속도'를 데이터로 조율하며([[glossary-observability]]·[[release-strategy]]), 장애는 비난 없는 포스트모템으로 학습해 시스템을 고칩니다. 에러버짓은 개발팀과의 오랜 긴장(빠른 배포 vs 안정)을 푸는 공통 언어가 됩니다. PM은 SLO를 비기능 요구([[requirements-prd]])로 명시하고, 에러버짓 소진 시 '안정화 모드'를 로드맵에 반영하며, 포스트모템 액션이 기술 부채([[tech-debt-refactoring]])처럼 꾸준히 상환되도록 우선순위를 지킵니다.
이것으로 본론 6개 Phase(개발자의 언어·큰그림·요구사항·협업·배포·아키텍처·품질문화)를 마칩니다. 이어지는 '용어사전(Phase G)'에서 도메인별 실무 용어를 빠르게 해독하는 레퍼런스를 제공합니다.