Recovery/DR 테스트로 복구 역량을 검증하는 방법

복구 계획은 실제 전환으로 검증된다

클라우드와 하이브리드 인프라에서 비즈니스 연속성을 확보하려면 Recovery/DR Test를 정기적으로 수행해야 한다. 이 테스트는 장애나 재해가 발생했을 때 서비스가 목표 복구 시간(RTO)과 데이터 손실 한도(RPO) 안에서 돌아오는지를 운영 환경의 관점에서 확인한다.

계획서를 검토하는 데 그치지 않는다. 실제 페일오버와 페일보백을 실행해 애플리케이션, 데이터베이스, 스토리지, 네트워크, 아이덴티티·보안, 운영 절차가 함께 작동하는지를 입증한다. 검증 대상에는 RTO/RPO 달성 여부, 서비스 의존성, 데이터 일관성과 무결성, 자동화 수준, 운영 인력의 숙련도가 포함된다.

목표와 실패 조건을 먼저 고정한다

테스트 기준은 비즈니스 임팩트 분석(BIA)에서 시작한다. 서비스 우선순위와 서비스별 RTO/RPO를 정한 뒤, 테스트 결과를 그 기준과 비교해 ±오차를 측정하고 보고한다. 경계값에 따른 합격·불합격 기준, 예외 승인 방식, 재테스트 정책도 사전에 정해둔다.

시나리오는 한 종류의 장애에 머물지 않는다. 컴포넌트 장애, 영역·리전 장애, 랜섬웨어에 따른 데이터 손상, 네트워크 분단, 공급자 계정 차단처럼 위협 모델을 반영한다. 테이블탑 논의에서 시작해 부분 실습과 전면 페일오버로 범위를 넓히며, 무작위 실패를 주입하는 Chaos 시나리오를 병행해 블랙스완 상황도 다룬다.

테스트 환경은 생산 환경과 분리한다. 네트워크와 계정을 격리하고, 생산 데이터는 마스킹하거나 샘플링하며, IaC로 환경을 빠르게 만들고 폐기한다. KMS 키와 시크릿 로테이션, 최소 권한, 감사 로그도 이 과정의 통제 대상이다.

전환부터 원복까지 이어지는 운영 흐름

계획 단계에서는 BIA 결과, 서비스 목록과 의존성 맵, RTO/RPO, 규제 요건을 입력으로 삼는다. 테스트 범위와 시나리오, 성공·롤백 기준을 정하고 위험 평가와 변경 승인을 거쳐 테스트 계획서, 커뮤니케이션 플랜, 리소스 예약을 마련한다.

준비 단계에서는 IaC 템플릿, 마스킹 데이터셋, 접근 권한을 바탕으로 격리 환경을 생성한다. 데이터 동기화와 검증을 마친 뒤 모니터링·로그 파이프라인을 연결하고, 준비 완료 체크리스트와 시작 승인을 남긴다.

실행 단계에서는 승인된 런북과 전환 윈도우에 따라 DNS·GLB 트래픽을 전환하고, DB 승격·리더 선출과 메시지 브로커 포인터 조정을 수행한다. 전환 완료 시점과 RTO 실측값, 운영 상태 대시보드를 결과로 남긴다.

검증에서는 기준 메트릭, 샘플 쿼리, 트랜잭션 시나리오를 사용해 기능·성능·보안을 확인한다. 데이터 정합성과 사용자 여정을 점검한 뒤 합격, 부분합격, 불합격으로 판정하고 이슈를 기록한다. 종료 시에는 원복 절차와 데이터 재동기화, 구성 상태 기준선화를 수행해 종료 보고서, 개선 백로그, 재발 방지 조치를 만든다.

⤢✕

검증 강도에 따라 달라지는 테스트 방식

테스트 유형	성능	확장성	일관성	안정성	운영 편의
테이블탑(시뮬레이션)	낮음	높음	낮음	중	높음
컴포넌트 수준(부분 실습)	중	중	중	중	중
전면 페일오버(프로덕션 또는 프로덕션 유사)	높음	높음	높음	높음	낮음
카오스/회복 탄력성 실험	중	높음	중	중	중

전면 페일오버는 실제 RTO/RPO를 확인하기에 적합하지만 리스크와 운영 부담이 크다. 반면 테이블탑은 비용 대비 커뮤니케이션과 의사결정 과정의 검증에 효과적이다.

환경별로 확인할 복구 지점

멀티 리전 DR에서는 Route 53 헬스체크 기반 장애 조치, RDS Cross-Region Read Replica 승격, S3 CRR 검증, CloudFront 오리진 전환을 확인한다. DNS TTL 사전 축소, 스키마 드리프트 탐지, IAM/KMS 키의 교차 계정 권한 점검이 함께 필요하다.

온프레미스에서 클라우드로 이어지는 하이브리드 DR은 백업 카탈로그 복구, 서브넷·보안 그룹 격리, IP 매핑과 네트워크 NAT 규칙 재작성, 디렉터리 서비스 연동을 다룬다. 네임서비스(split-horizon)의 일관성과 라이선스 리호스트 정책 준수도 검증 범위다.

PostgreSQL 중심의 DR에서는 스탠바이 승격(pg_ctl promote), 커넥션 재시도, 시퀀스 갭과 트랜잭션 재처리를 확인한다. pg_hba.conf, replication slots 상태, 해시·카운트를 활용한 일관성 검사를 자동화 대상으로 둔다.

랜섬웨어 대응 DR은 불변(Immutable) 백업에서 격리 복구를 수행하고 IOC 스캔과 서명·무결성 검증을 마친 뒤 재가동한다. Object Lock과 보존 정책 준수, 백업 체인 신뢰도 지수 관리가 핵심 점검 항목이다.

PostgreSQL 리플리카 지연으로 RPO를 점검하기

전제조건은 PostgreSQL 13+, 리플리카 서버 접근 가능, psql 설치다. RPO 목표(예: 60초)와 리플리카 지연을 비교해 기준을 넘으면 비상 알림 또는 롤백 트리거로 연결할 수 있다.

#!/usr/bin/env bash
# check_rpo.sh - Verify PostgreSQL replica delay <= TARGET_RPO_SEC
# Usage: CHECK_HOST=replica.example.com CHECK_DB=app TARGET_RPO_SEC=60 ./check_rpo.sh

set -euo pipefail

CHECK_HOST="${CHECK_HOST:-localhost}"
CHECK_DB="${CHECK_DB:-postgres}"
TARGET_RPO_SEC="${TARGET_RPO_SEC:-60}"

delay_sec=$(psql "host=${CHECK_HOST} dbname=${CHECK_DB}" -Atc \
  "SELECT COALESCE(EXTRACT(EPOCH FROM now() - pg_last_xact_replay_timestamp()),0)::int;")

echo "Replica delay(sec)=${delay_sec}, Target RPO(sec)=${TARGET_RPO_SEC}"

if (( delay_sec > TARGET_RPO_SEC )); then
  echo "RPO violation: delay ${delay_sec}s > target ${TARGET_RPO_SEC}s" >&2
  exit 2
else
  echo "RPO OK"
fi

CI/CD 파이프라인과 ChatOps에 연계하면 전환 전후의 점검을 자동화할 수 있다. 실패 결과는 전환 중지와 롤백 기준에 연결한다.

격리·데이터 보호·자동화 사이의 균형

테스트 환경은 프로덕션 자격증명과 네트워크에서 분리하고, 실시간 접근 승인으로 일시 권한을 부여한다. 다만 분리 강도를 높일수록 테스트 현실감은 낮아지고 운영 복잡도는 높아진다. 관측과 추적 채널은 공용 표준으로 두는 방식으로 절충할 수 있다.

PII 마스킹, 암호화 키 이중화, 백업 무결성의 주기적 검증은 데이터 보호와 규정 준수를 위한 원칙이다. 강한 마스킹은 테스트 정확도를 떨어뜨릴 수 있으므로 핵심 경로에는 합성 데이터와 샘플 실데이터를 혼합 적용한다.

선언적 IaC와 런북 자동화를 기본으로 하되 승인과 판단에는 휴먼 게이트를 남긴다. 자동화 범위가 넓어지면 속도와 일관성은 높아지지만, 드리프트와 구성 결함이 대규모로 전파될 위험도 커진다. 변경 관리와 점진 롤아웃이 이를 완화한다.

반복 훈련으로 얻는 운영 변화

Recovery/DR 테스트는 MTTR을 30~60% 단축하고, RTO 달성률을 95%+ 향상시키며, 데이터 정합성 결함 조기 발견율을 2배로 높일 수 있다. 전환 실패율은 50% 이상 감소하고 재해 복구 훈련 소요 시간은 40% 단축된다.

운영 팀의 숙련도와 의사결정의 속도·정확성이 개선되고, 감사 대응력도 강화된다. 경영진 신뢰를 확보하는 동시에 레질리언스 중심의 개발·운영 문화를 정착시키는 기반이 된다.

분기별 테이블탑, 반기별 부분 실습, 연 1회 전면 페일오버를 주기적으로 운영하면 가용성과 데이터 일관성을 지속해서 검증할 수 있다.