SRE 프랙티스, 지표를 운영 결정으로 바꾸는 법
SRE 프랙티스는 관측성 데이터를 SLI, SLO, Error Budget, 정책 실행으로 연결해 배포와 안정화 결정을 수치화하는 방법이다. 이 스크립트는 SLI/SLO/SLA, Error Budget, 장애 대응, Postmortem, Toil 제거의 핵심 메커니즘과 흔한 실패 모드를 정리한다.
Script Companion
오디오와 함께 스크립트 보기
- 01
SRE 프랙티스의 출발점은 관측성 도구를 갖추는 것과 그 데이터로 의사결정을 하는 것이 다르다는 데 있다. CloudWatch로 메트릭을 모으고, Logs, Metrics, Traces로 장애를 나중에 설명할 수는 있다. 하지만 장애 중에 무엇을 멈추고 무엇을 계속할지는 자동으로 정해지지 않는다. SRE는 증상을 사용자 영향 SLI, 내부 목표 SLO, 허용 실패량 Error Budget, 정책 실행으로 연결해서 대시보드가 빨갛다는 상태를 이번 주 신규 기능 배포를 멈춘다는 운영 결정으로 바꾼다.
- 02
가용성의 9가 몇 개인지는 단순한 숫자 장식이 아니다. 99%는 연간 약 87.6시간의 다운타임이고, 99.9%는 약 8.7시간, 99.99%는 약 52분, 99.999%는 약 5분이다. 99%에서 99.9%로 올리는 것과 99.99%에서 99.999%로 올리는 것은 비용의 크기가 다르다. SRE는 이 차이를 감으로 처리하지 않고, 서비스 성격과 비즈니스 영향에 맞춰 수치로 관리한다. 완벽한 안정성 자체보다, 어느 수준의 신뢰성을 목표로 할지 명시하는 것이 먼저다.
- 03
실제 장애 사례는 SRE가 왜 필요한지 보여준다. 2025년 10월 AWS us-east-1 장애는 약 14시간 32분 동안 이어졌고, DynamoDB 자동 DNS 관리 시스템의 latent race condition이 빈 DNS 레코드를 만들며 EC2 신규 인스턴스 시작 실패, NLB 연결 오류, Lambda, ECS, EKS, Fargate 지연으로 전파됐다. 2017년 S3 us-east-1 장애는 잘못된 입력으로 의도보다 많은 S3 subsystem 서버가 제거되면서 약 4시간 17분 동안 영향을 남겼다. 두 사례 모두 Postmortem, Action Items, 시스템 개선의 사이클이 없었다면 같은 유형의 장애가 더 빨리 재발할 수 있었다.
- 04
플랫폼 엔지니어에게 SRE는 다른 팀의 인프라를 책임질 때 필요한 공통 언어다. 배포했더니 서비스가 느려졌다는 말만 있으면 어디서 시작할지 불분명하지만, p99 응답시간이 500ms를 초과했다는 식으로 말하면 조사와 의사결정의 출발점이 생긴다. 프론트엔드 경험도 여기서 이어진다. 사이트가 느리다는 정성적 불만을 LCP, FID, CLS 같은 Core Web Vitals로 정량화해 본 경험은 사용자 관점의 SLI를 설계하는 데 직접 도움이 된다.
- 05
SLI, SLO, SLA는 신뢰성을 말하는 세 단계 언어다. SLI, Service Level Indicator는 사용자가 실제로 경험하는 것을 측정하는 지표다. 서버 CPU 사용률 자체보다 내 요청이 성공했는지, 응답이 빠른지가 더 중요하다. SLO, Service Level Objective는 이 SLI의 내부 목표값이다. 예를 들어 API 가용성 SLI가 한 달간 99.9% 이상이어야 한다는 식이다. SLA, Service Level Agreement는 고객이나 파트너와의 외부 계약이며, 위반하면 환불이나 서비스 크레딧 같은 페널티가 생긴다.
- 06
SLO가 100%가 아닌 이유는 완벽한 시스템이 없다는 전제와 연결된다. 100% 가용성을 목표로 하면 배포도 변경도 어려워지고, 중복화와 페일오버 비용은 기하급수적으로 커진다. 사용자가 겪는 네트워크나 클라이언트 장애처럼 서비스 바깥의 원인도 존재한다. 그래서 SLO는 달성 가능한 목표를 정하고 그 안에서 변경을 계속하기 위한 기준이다. 중요한 관계는 SLA보다 SLO가 더 엄격해야 한다는 점이다. 외부 계약이 99.9%라면 내부 목표를 99.95%처럼 더 높게 잡아야 계약 위반 전에 내부 경보가 울릴 수 있다.
- 07
처음 SLO를 정할 때는 숫자를 먼저 고정하지 않는다. 측정 방식, 기준선, 사용자 영향, 정책 순서로 정해야 한다. AWS CloudWatch Application Signals는 SLO를 period-based와 request-based로 나눈다. period-based SLO는 good periods를 total periods로 나누므로 5분 단위 중 99.9%가 정상 같은 운영 창에 맞고, request-based SLO는 good requests를 total requests로 나누므로 결제 API처럼 요청 단위 성공과 실패가 명확한 서비스에 맞다. 신규 서비스라면 최소 2주에서 30일 기준선을 보고, 현재 실측보다 약간 느슨한 SLO로 시작하는 편이 안전하다.
- 08
SLO 선택의 위험은 결제 API 예시에서 분명해진다. 30일 동안 3,000,000건 중 2,997,235건이 성공했다면 실측 가용성은 99.91%다. 이 상태에서 99.99% SLO를 바로 걸면 허용 실패가 월 300건뿐이라 작은 배포 한 번으로 정책이 멈출 수 있다. 반대로 99.9% SLO는 허용 실패가 3,000건이고, 이미 765건을 사용한 상태이므로 남은 2,235건 안에서 카나리 배포와 안정화 작업을 조절할 수 있다. 처음엔 낮게 시작하고 점진적으로 상향하는 접근이 현실적이다.
- 09
Error Budget은 개발팀과 운영팀의 갈등을 수치로 바꾸는 장치다. 개발팀은 빨리 배포하고 싶고, 운영팀은 장애 위험을 줄이고 싶다. 이때 얼마나 위험해도 되는가에 대한 공통 언어가 없으면 매번 사람 대 사람의 충돌이 된다. Error Budget은 SLO가 허용하는 실패량이며, 요약하면 1에서 SLO를 뺀 값이다. 잔여 예산이 50% 이상이면 공격적 배포와 신규 기능 실험이 가능하고, 25%에서 50% 사이면 원인 점검과 낮은 리스크의 배포만 허용한다. 25% 미만이면 신규 기능 개발을 멈추고 안정화에 집중하며, 0% 이하이면 배포 동결과 정책 발동으로 이어진다.
- 10
Error Budget Policy는 SLO 위반 시 어떤 행동이 자동으로 발동되는지 문서화한 규칙이다. Google SRE Workbook의 예시는 변경이 장애의 주요 원인이라는 전제 아래, 단일 사고가 4주 Error Budget의 20%를 넘게 쓰면 Postmortem과 P0 Action Item을 요구한다. 같은 유형의 장애가 분기 Error Budget의 20%를 넘게 쓰면 다음 분기 계획에 P0 항목을 넣도록 한다. 또한 Google의 배경 설명은 변경이 장애의 약 70%를 차지한다고 설명한다. 핵심은 예산이 소진되면 무조건 동결한다는 단순 규칙이 아니라, 어떤 사고가 제품 개발보다 안정화 작업을 우선하게 만드는지 숫자로 정하는 것이다.
- 11
Error Budget Policy를 기계적으로 적용하면 서비스가 건강한데도 배포가 멈추는 silent failure가 생길 수 있다. 부하 테스트, 보안 스캔, 내부 배치 재처리처럼 SLO 대상 사용자가 아닌 트래픽이 실패를 만들었는데 이를 실제 사용자 오류로 집계하면 잘못된 정책이 발동된다. 그래서 배포 차단 전에 SLI 분모를 확인해야 한다. load-test, security-scanner, synthetic-canary가 실패 상위라면 사용자 SLO 위반으로 처리하지 말고 SLI 필터를 수정한다. 반대로 일반 브라우저나 모바일 앱 user agent가 상위라면 정책을 발동하고 신규 기능 배포를 멈춘다.
- 12
장애 대응에서는 심각도 분류와 완화 우선순위가 중요하다. SEV1은 전체 서비스 중단이나 데이터 유실 위험처럼 즉시 대응하고 경영진 보고가 필요한 상황이다. SEV2는 결제나 로그인 같은 주요 기능 장애이며, SEV3은 부분 기능 저하나 성능 저하, SEV4는 경미한 이슈나 UI 버그에 가깝다. 대응 흐름은 탐지, 분류, 완화, 해결, Postmortem으로 이어진다. 여기서 완화가 핵심이다. 장애 중에 원인 분석만 오래 하면 사용자 피해가 커지므로, 먼저 롤백해서 서비스를 살리고 그다음 원인을 찾는 것이 SRE의 우선순위다.
- 13
운영 흐름은 서비스 배포 이후 SLI 수집에서 시작해 SLO와 Error Budget 계산, 알람 탐지, Incident Response, Postmortem과 Toil 감소로 다시 돌아온다. ALB 액세스 로그, CloudWatch Application Signals, NestJS Custom Metrics 같은 측정 소스를 통해 가용성, p99 지연시간, 에러율을 본다. 예산이 정상이라면 배포를 허용하고, 주의 구간이면 배포 전 SRE 리뷰를 요구하며, 위험 구간이면 배포 동결과 안정화 스프린트로 전환한다. 알람은 CloudWatch Alarm, SNS, PagerDuty나 Slack을 거쳐 On-call 담당자에게 전달되고, Runbook은 대응자가 같은 절차로 복구를 시작하게 만든다.
- 14
흔한 실패 모드는 알람과 Postmortem에서 자주 드러난다. PagerDuty 알람이 하루 평균 50건 이상 호출되면 On-call 담당자가 알람을 무시하거나 습관적으로 ACK만 누를 수 있고, 실제 장애가 알람 속에 묻힌다. 이때는 최근 1개월 알람 중 실제 조치가 필요했던 비율을 감사하고, 목표를 알람의 80% 이상이 실제 조치 필요인 상태로 둔다. CPU 사용률만 보는 알람보다 API 에러율처럼 사용자 영향이 있는 증상 기반 알람이 낫고, CloudWatch Composite Alarm으로 CPU와 에러율 조건을 함께 묶을 수 있다. Postmortem도 문서만 쌓이면 부족하다. Action Items에는 담당자, 기한, 검증 방법이 있어야 한다.
- 15
Toil 제거는 플랫폼 엔지니어의 중요한 역할이다. 매주 수동 배포, 알람 확인 뒤 ECS 태스크 수동 재시작, RDS 슬로우 쿼리 로그 수동 추출처럼 반복 작업은 팀의 엔지니어링 시간을 계속 소모한다. 자동화 우선순위는 감이 아니라 회수 기간으로 볼 수 있다. 예를 들어 CloudWatch 알람 확인 후 ECS 태스크를 수동 재시작하는 작업이 주당 3시간을 쓰고, ECS 헬스체크와 자동복구 구성에 4시간이 든다면 회수 기간은 약 1.3주다. 이런 작업부터 자동화하면 SLI 안정화와 Error Budget 확보에도 연결된다.
- 16
정리하면 SRE 프랙티스는 지표 수집을 넘어서 운영 행동을 표준화하는 체계다. SLI는 측정, SLO는 목표, SLA는 계약이며, SLO는 SLA보다 엄격해야 한다. Error Budget은 배포와 안정화의 균형을 수치로 표현하고, 정책은 잔여 예산에 따라 배포 허용, 리뷰, 동결을 결정한다. 장애 대응은 원인 분석보다 완화를 먼저 두고, Postmortem은 개인 비난이 아니라 시스템이 왜 허용했는지와 Action Items 실행으로 이어져야 한다. 마지막으로 플랫폼 팀은 반복 수동 작업을 줄여 SLI 안정화와 운영 의사결정의 품질을 높인다.
같은 레이어