# agentsre/sre_paranoia_gates.py

from dataclasses import dataclass, field  
from typing import List, Optional, Callable  
from datetime import datetime, timezone, timedelta  
from enum import Enum  
import json

class GateResult(Enum):
    PASS = "pass"  
    FAIL = "fail"  
    WARN = "warn" # 차단하지는 않지만 SRE 검토를 위해 로그를 남김

모든 게이트 체크는 통과(pass) 또는 실패(fail) 여부가 로그로 남습니다.
통과는 신뢰를 구축합니다. 실패는 배포를 차단합니다.
경고(warn)는 차단하지 않으면서 SRE 검토를 위해 표면화됩니다.
...

게이트는 숙련된 SRE가 변경 사항을 적용하기 전에 던지는 다섯 가지 질문을 인코딩합니다:
    Gate 1: 롤백(rollback) 경로가 테스트되었으며 5분 이내에 완료되는가?
    Gate 2: 배포 중 진행 중인 트래픽(in-flight traffic)이 처리되는가?
...

if not last_drill_date:
    return ParanoiaGateCheck(
        gate_id="SPG-001",
...

failures = []

if graceful_shutdown < 30:
...

def gate_degraded_load_test(context: dict, owner: str) -> ParanoiaGateCheck:  
"""  
개발자는 모든 의존성(dependency)이 정상인 상태에서 명목 부하(nominal load)로 테스트합니다.  
SRE는 하나의 핵심 의존성이 저하된 상태에서 피크 부하(peak load)로 테스트합니다.  
진짜 질문은 이것입니다: 당신이 유발한 재시도 폭풍(retry storm) 중에 상위 시스템(upstream)이 당신을 속도 제한(rate-limit)한다면 어떤 일이 벌어질까요?  
"""  
load_test = context.get("load_testing", {})  
tested_at_peak = load_test.get("tested_at_peak_load", False)  
tested_with_degraded_dep = load_test.get("tested_with_degraded_dependency", False)  
retry_storm_tested = load_test.get("retry_storm_simulation", False)

# Gate 4: 폭발 반경 생존성 (Blast radius survivability)

def gate_blast_radius_survivability(context: dict, owner: str) -> ParanoiaGateCheck:  
"""  
SRE의 질문: 만약 새벽 2시에 엔지니어 한 명만 당직(on-call) 중일 때 이 문제가 발생한다면,  
그 혼자서 이를 격리(contain)할 수 있습니까? 아니면 엔지니어 세 명과 워룸(war room)이 필요합니까?  
"""  
blast = context.get("blast_radius", {})  
downstream_count = blast.get("downstream_service_count", 0)  
contains_payment_path = blast.get("contains_payment_path", False)  
single_engineer_containable = blast.get("single_engineer_containable", None)  
has_circuit_breaker = blast.get("circuit_breaker_configured", False)

# Gate 5: SLO 에러 예산 확인 (SLO error budget check)

def gate_error_budget(context: dict, owner: str) -> ParanoiaGateCheck:  
"""  
개발자들이 묻지 않는 질문: 에러 예산(error budget)이 얼마나 남아 있는가?  
만약 예산이 20% 미만이라면, 사소하지 않은(non-trivial) 무엇인가를 배포하는 것은  
팀이 명시적으로 결정하지 않은 신뢰성(reliability)에 대한 도박입니다.  
"""  
slo = context.get("slo", {})  
budget_remaining_pct = slo.get("error_budget_remaining_pct", 100.0)  
is_critical_change = context.get("is_critical_change", False)

전체 게이트 스위트 실행
python# CI/CD 파이프라인에서 사용하기

runner = SREParanoiaGateRunner(
    service_name="payments-service",
    sre_owner="platform-sre-team"
)

# 다섯 개의 게이트 모두 등록하기

runner.register(gate_rollback_readiness)
runner.register(gate_in_flight_traffic)
runner.register(gate_degraded_load_test)
runner.register(gate_blast_radius_survivability)
runner.register(gate_error_budget)

# 배포 메타데이터에서 컨텍스트 구축하기

context = {
    "rollback": {
        "last_tested_at": "2026-06-01T09:00:00Z",
        "p95_duration_minutes": 3.5
    },
    "deployment": {
        "graceful_shutdown_seconds": 60,
        "connection_draining_enabled": True,
        "schema_backward_compatible": True
    },
    "load_testing": {
        "tested_at_peak_load": True,
        "tested_with_degraded_dependency": False, # 경고 (WARN)
        "retry_storm_simulation": False
    },
    "blast_radius": {
        "downstream_service_count": 4,
        "contains_payment_path": True,
        "single_engineer_containable": True,
        "circuit_breaker_configured": True
    },
    "slo": {
        "error_budget_remaining_pct": 42.0
    },
    "is_critical_change": False
}

result = runner.run_all(context)
print(json.dumps(result, indent=2))

# CI/CD에서: 승인되지 않은 경우 파이프라인 실패시키기

if not result["deployment_approved"]:  
    raise SystemExit("SRE Paranoia Gates가 배포를 차단했습니다. 위의 게이트 결과를 확인하세요.")  

이 방식이 문화(Culture)보다 더 효과적인 이유  
2026년에 신뢰성(Reliability) 측면에서 승리하는 팀은 가장 정교한 AI 스택을 가진 팀이 아닙니다. 그들은 지능형 도구(Intelligent tooling)를 진정한 엔지니어링 문화와 결합하고, 단순히 알림(Alert)이 발생하는 방식이 아니라 책임(Ownership)이 흐르는 방식을 바꾸는 힘든 작업을 수행한 팀들입니다. Sherlocks AI  

SRE Paranoia Gates는 책임(Ownership)의 흐름이 실제로 어떻게 변하는지를 보여줍니다. SRE가 모든 배포 검토 회의에 참석할 필요가 없습니다. SRE의 질문들이 이미 파이프라인에 들어있기 때문입니다. 변경 사항을 배포하는 개발자는 배포 컨텍스트(Deployment context)를 채움으로써 그 질문에 답하거나, 게이트가 배포를 차단함으로써 왜 그 질문들이 중요한지를 배우게 됩니다.  

이것이 바로 올바르게 수행된 쉬프트 레프트 (Shift left)입니다. "개발자에게 SRE처럼 생각하도록 가르치는 것"이 아니라, SRE가 생각하는 바를 시스템 자체에 인코딩(Encode)하는 것입니다.  

코드는 agentsre/sre_paranoia_gates.py에 있습니다. MIT 라이선스입니다.  
Ajay Devineni | AWS Community Builder | Senior SRE/Platform Engineer

github.com/Ajay150313/agentsre | dev.to/ajaydevineni  
[![ ](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fmetnnmm1dchj1ho24e2p.jpeg)](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fmetnnmm1dchj1ho24e2p.jpeg)