에러버짓으로 설계하는 SRE 릴리즈 안정성 테스트

SLO·SLI와 에러버짓을 릴리즈 게이팅에 연결해 카나리 배포, 자동 분석, 롤백 정책을 운영하는 SRE 테스트 체계

2026-08-14 · 최초 발행 2025-12-24

테스트 결과가 아니라 에러버짓으로 릴리즈를 판단한다

SRE 관점의 테스트는 기능이 요구사항에 맞는지 확인하는 데서 끝나지 않는다. SLO·SLI와 에러버짓을 기준으로, 변경이 운영 환경의 신뢰도와 회복탄력성에 어떤 영향을 주는지까지 다루는 품질 보증 체계다.

SLI(Service Level Indicator)는 가용성, 오류율, 지연시간 p95/p99처럼 사용자가 체감하는 품질을 나타내는 지표다. SLO(Service Level Objective)는 이 지표에 부여한 목표치다. 예를 들어 월간 가용성 SLO가 99.9%라면, 에러버짓은 그 목표에서 허용된 실패량인 0.1%가 된다. 30일을 기준으로 하면 30일×24×60=43,200분이며, 허용 장애 시간은 43.2분이다.

릴리즈 안정성은 변경이 서비스 품질을 떨어뜨리지 않도록 관리하는 문제다. 변경 실패율, MTTR, 롤백 성공률을 주요 지표로 삼고, 배포를 단계적으로 진행하면서 자동 분석 결과에 따라 승인하거나 멈춘다.

이때 테스트 범위는 정적 분석과 단위·통합·계약·성능·부하·혼란 테스트 같은 사전 검증뿐 아니라, 카나리 자동 분석과 런타임 SLO 모니터링까지 포함한다. 에러버짓 잔량과 변경 위험도를 조합해 테스트 강도와 배포 정책을 달리 적용한다.

에러버짓이 남아 있는 만큼만 변경을 허용한다

에러버짓 잔량은 릴리즈 게이팅의 1급 신호가 된다. 잔량이 정해진 임계치 아래로 내려가면 변경을 동결하고, 승인권자를 상향하는 절차를 적용할 수 있다.

예를 들어 잔량이 30% 미만이면 카나리 배포를 필수로 두고 트래픽을 5%→25%→50%→100%로 확대한다. 잔량이 10% 미만일 때는 핵심 경로 변경을 막고, 비차단형 실험만 허용한다.

관찰가능성도 테스트의 일부로 취급한다. 테스트 환경과 프로덕션에 동일한 계측 지표를 적용하고, 분산 트레이싱, RED/USE 지표, 에러 이벤트 코릴레이션으로 자동 판정을 구성한다. 코드 커버리지 대신 사용자 중심 SLI를 합격 기준으로 삼는 방식이다.

카나리, 블루/그린, 피처 플래그는 트래픽을 나누고 자동 롤백을 수행하는 수단이다. 자동 분석은 오류율 차이, 지연시간 분포 변화, SLA 위반 예측을 베이지안 또는 시그널 탐지 방식으로 판단한다.

장애 주입도 운영 가능한 테스트로 만든다. 네트워크 지연, 패킷 손실, 종속성 실패를 주입해 서킷브레이커·리트라이·타임아웃을 검증하고, 에러버짓 소비량을 시뮬레이션해 릴리즈 영향을 미리 추정한다. 플레이북도 함께 점검해 MTTR을 낮춘다.

데이터 변경은 배포와 별개로 다루지 않는다

스키마 변경에는 Expand-Contract 패턴을 적용하고, 전방 호환 가능한 스키마를 우선한다. Dual-Write/Read 경로를 검증하며, 마이그레이션의 롤백 경로와 락·트랜잭션 영향을 의무적으로 분석한다. 배치 작업과 온라인 DDL은 분리해 운영한다.

쓰기 경합 구간을 줄이고, 온라인 스키마 변경으로 LOCK을 최소화하며, 읽기와 쓰기를 분리한다. 롤백이 필요한 경우에는 이벤트 소싱 또는 체인지로그를 이용해 상태를 복원하고, 분산 트랜잭션은 사가 패턴으로 보상 처리한다.

릴리즈 게이트가 처리하는 입력과 결과

게이팅은 코드 변경, 위험도 태깅, 최근 30일의 SLI·SLO·에러버짓, 실험 플래그 설정을 입력으로 받는다.

CI에서는 정적 분석, 단위·계약 테스트, 컨테이너 이미지 서명과 취약점 스캔을 수행한다. 프리프로덕션에서는 리허설 배포와 부하·혼란 테스트를 거친 뒤 카나리 1~5% 실험으로 이어진다. 자동 분석은 기준선과 오류율·지연시간·자원 메트릭을 비교하고, 에러버짓 소비를 예측한다.

임계치를 충족하면 배포 범위를 점진적으로 넓힌다. 충족하지 못하면 자동 롤백과 알림을 수행한다. 결과물은 승인된 릴리즈, 중단 또는 롤백 및 RCA 티켓, 에러버짓 소비 리포트다.

카나리 중 p99 지연시간이 기준선보다 +20%를 넘거나 오류율이 +0.3%p 이상 오르면 즉시 롤백한다. 관찰 데이터가 결측되거나 지연되면 Fail-Closed 기본값을 적용해 동결한 뒤 재시도한다. 데이터 마이그레이션 실패에는 작은 배치, 재시도-Idempotency, Backoff를 포함한 트랜잭션 세이프가드를 적용한다.

CI 단계: 정적 분석/단위/계약테스트 통과스테이징: 부하/혼란 테스트실행카나리 1~5% 트래픽 전환자동 분석: 기준선 대비 비교예(통과)아니오(불통과)배포 완료 후: 포스트 릴리즈모니터링RCA 생성/재시도 윈도우 설정코드 변경(PR)배포 아티팩트(서명/스캔 완료)성능/복원력 결과실시간 SLI수집(오류율/지연시간/자원)에러버짓 잔량 = 정책 임계값프로덕션 점진배포(5%→25%→50%→100%)릴리즈 중단 자동 롤백에러버짓 소비 리포트/알림

배포 방식별로 달라지는 안정성의 성격

전략 성능 확장성 일관성 안정성 운영 편의
빅뱅 배포 초기 고부하 위험 높음 낮음 높음(단일 변경) 낮음(대규모 실패 시 영향 큼) 높음(단순 절차)
블루/그린 예측 가능 중간 중간(데이터 동기화 이슈) 높음(즉시 스위치/롤백) 중간(이중 인프라 필요)
카나리 실측 기반 튜닝 용이 높음 중간(버전 혼재 고려) 매우 높음(점진/자동 롤백) 중간(자동 분석 구성 필요)
피처 플래그 낮은 성능 영향 매우 높음 낮음~중간(코드 경로 분기) 높음(런타임 토글) 높음(세분 제어/실험 용이)

에러버짓 잔량에 따른 정책 기준

월간 SLO가 99.9%이면 허용 실패는 0.1%, 에러버짓은 43.2분이다. 월간 SLO가 99.95%라면 허용 실패는 0.05%, 에러버짓은 21.6분이다.

잔량이 50% 이상이면 표준 테스트와 간소화한 카나리를 적용할 수 있다. 20% 이상 50% 미만에서는 카나리를 필수로 하고, 단계 확대 대기시간을 늘리며 추가 카오스 체크를 수행한다. 20% 미만이면 변경을 동결하고, 다중 서명을 거친 긴급 핫픽스만 허용한다.

자동 분석에서는 오류율 Δ+0.2%p 초과, p99 지연시간 Δ+15% 초과, CPU 또는 메모리 사용량 Δ+20% 초과를 불통과 기준으로 삼는다. 사용자 여정 기반 합성 모니터링 실패율이 0.5%보다 높아도 불통과다.

서비스 성격에 따른 적용 결과

대규모 SaaS 마이크로서비스에서는 잦은 배포로 변경 실패율이 높아질 수 있다. 서비스별 에러버짓을 독립 관리하고 카나리와 자동 분석을 도입한 결과, 변경 실패율은 3.8%→1.2%, MTTR은 45분→18분, 가용성 SLO 위반 건수는 월 6건→2건으로 나타났다.

피크 트래픽을 다루는 모바일 백엔드에서는 피크 전후의 제한 창구(rate limit)와 카나리 점진률을 동적으로 조정한다. 이 방식으로 피크 기간 오류율은 0.9%→0.3%가 되었고, 롤백 자동화로 장애 지속시간은 60% 감소했다.

배치와 스트리밍을 함께 운영하는 데이터 플랫폼에서는 스키마 변경이 소비자 장애로 이어질 수 있다. Expand-Contract, 컨슈머 드리븐 계약 테스트, Dual-Read 검증을 적용한 결과 데이터 파이프라인 SLA 위반은 70% 감소했고, 롤아웃 시간은 50% 단축됐다.

운영 체계가 가져오는 변화와 비용

자동 게이팅과 분석을 도입하면 변경 실패율은 5070% 감소하고, MTTR은 3060% 단축되며, SLO 위반 건수는 4060% 감소한다. 배포 리드타임도 2040% 단축될 수 있다.

품질 논의는 데이터 중심으로 바뀌고, 개발·운영·비즈니스가 공유하는 언어가 생긴다. 위험 기반 의사결정 문화가 자리 잡으면 불필요한 릴리즈 심의 절차도 줄일 수 있다.

이를 위해 SLI 정의와 기준선을 표준화하고 에러버짓 대시보드를 실시간으로 공개한다. 자동 롤백과 수동 승인을 병행하며, 릴리즈 뒤 24시간 집중 모니터링 창구를 운영한다. 카나리 분석에는 p값과 효과크기를 고려한 통계적 판정을 도입하고, SLO 기반 알람으로 알람 노이즈를 관리한다.

엄격한 게이팅은 빠른 릴리즈와 충돌할 수 있으므로 완화 모드와 강화 모드를 상황에 맞춰 전환해야 한다. 관찰가능성과 자동 분석에는 초기 구축 비용이 들며, 운영 단순화와의 균형이 필요하다. 피처 플래그를 과도하게 사용하면 코드 복잡도와 일관성이 낮아질 수 있으므로 수명 주기 관리 정책도 함께 둬야 한다.

SRE에러버짓릴리즈 안정성카나리 배포관찰가능성