백업 파일이 존재한다는 사실과 서비스를 복구할 수 있다는 사실은 다릅니다. 장애 때 어느 시점까지 데이터를 되돌릴 수 있고 언제 다시 업무를 시작할 수 있는지 테스트해야 합니다. RPO와 RTO를 문서에만 적지 말고 복구 훈련의 측정값으로 만들 필요가 있습니다.
두 목표의 의미를 분리한다
RPO는 허용 가능한 데이터 손실 구간, RTO는 중단부터 서비스 복구까지 허용하는 시간입니다. '매일 백업'만으로 두 값을 보장하지 못합니다. 업무별 영향과 비용을 놓고 고객·운영팀이 합의해야 합니다.
복구 순서를 서비스 의존성으로 만든다
DB를 복원해도 인증, 파일 저장소, DNS, 외부 연동이 준비되지 않으면 사용자는 일을 못 합니다. 핵심 사용자 흐름을 기준으로 복구 순서를 정하고 담당자·접근 권한·비상 연락망을 확인합니다. 계획서는 담당자가 부재해도 실행 가능해야 합니다.
격리된 환경에서 실제 복원을 해 본다
운영 시스템을 건드리지 않는 환경에 백업을 복원하고 무결성과 애플리케이션 기능을 검사합니다. 복구 파일이 열리는 것과 최근 주문이 정상 조회되는 것은 다릅니다. 데이터베이스 스키마와 앱 버전의 호환성도 확인합니다.
측정값을 목표와 비교한다
복원 시작과 핵심 기능 정상화 시각을 기록해 실측 RTO를 계산합니다. 마지막 일관된 데이터 시점으로 실측 RPO를 계산합니다. 목표를 넘었다면 백업 주기, 자동화, 복구 인프라 중 무엇이 병목인지 찾습니다.
훈련 후 변경을 운영에 반영한다
복구 절차는 시스템이 바뀔 때마다 낡아집니다. 새 저장소나 외부 의존성이 생기면 복구 목록도 갱신합니다. 정기 훈련에서 발견한 누락을 소유자와 완료 시한이 있는 개선 항목으로 남깁니다.
현장에 적용할 때의 순서
- 핵심 업무 흐름별 RPO·RTO를 합의한다
- 격리 환경에서 전체 복구 절차를 실행한다
- 실측 결과와 목표 차이를 개선 항목으로 만든다
주의할 실패: 백업 파일만 확인하면 인증·DNS·외부 연동 실패를 놓칠 수 있다.
관찰할 지표: 실측 RPO·RTO, 복원 실패, 훈련 개선 항목 완료율을 본다.
적용 전 체크리스트
- 업무별 RPO·RTO가 합의돼 있는가
- 백업 복원 뒤 핵심 사용자 흐름을 시험하는가
- 복구 훈련의 실측 시간과 개선 항목을 기록하는가
참고 자료
AWS Well-Architected: plan for disaster recovery. AWS Well-Architected는 업무 필요에 따른 RPO·RTO 설정과 DR 테스트를 권장합니다. 본문 절차는 서비스 규모와 의존성에 맞게 조정해야 합니다.
이미지와 도식은 이해를 돕기 위한 개념 시각화입니다. 특정 고객의 실제 설비·데이터·화면을 재현한 것이 아닙니다.
#재해복구 #백업 #RPO #RTO #운영안정성 #복구훈련 #SaaS #서비스연속성 #장애대응 #데이터복원
