DR 전략을 아무리 잘 설계해도, "정말 작동하는가"는 별개의 문제다. 종이 위의 RTO 5분은 실제 장애가 닥쳤을 때 30분이 될 수 있고, "Multi-AZ라 괜찮다"던 시스템이 막상 한 AZ가 죽자 무너지기도 한다. 소프트웨어 신뢰성의 불편한 진실은 "테스트하지 않은 복구는 작동하지 않는다"는 것이다. 그래서 등장한 것이 카오스 엔지니어링(Chaos Engineering) — 멀쩡한 시스템에 의도적으로 장애를 주입해, 장애가 진짜로 닥치기 전에 약점을 미리 드러내는 방법론이다.
AWS는 이를 두 서비스로 제품화했다. Resilience Hub는 워크로드를 분석해 "당신의 RTO/RPO 목표 대비 실제로 얼마나 견딜 수 있는가"를 측정·평가하고, **FIS(Fault Injection Service, 옛 Fault Injection Simulator)**는 EC2 종료·네트워크 지연·API 스로틀 같은 장애를 실제로 주입한다. 핵심은 둘을 결합해 "측정 → 실험 → 개선"의 루프를 자동화하는 것이다. 오늘은 카오스 엔지니어링이 어디서 왔는지(Netflix), 그 과학적 방법론이 무엇인지, FIS가 어떤 안전장치(Stop Condition)로 운영 사고를 막는지, 그리고 이 모든 것을 정기 자동화하는 패턴을 깊이 본다.