재해복구 RTO/RPO 정의와 연습

도입

DR 전략은 평시에 비용으로 보이지만 장애 순간에는 생존 조건이 된다. 많은 조직이 RTO/RPO를 숫자로만 정하고 실제 복구 절차를 검증하지 않아 목표를 달성하지 못한다. 이 글은 서비스 특성에 맞는 RTO/RPO를 정의하고 연습 주기를 설계하는 실무 방법을 설명한다.

재해복구 RTO/RPO 정의와 연습 커버 — Wikimedia Commons 기반 무료 이미지

문제 정의

재해복구가 실패하는 원인은 기술보다 가정 누락이다.

핵심 서비스와 비핵심 서비스를 구분하지 않아 동일 목표를 강제한다.
백업은 존재하지만 복원 검증이 없어 실제 복구 시간을 예측할 수 없다.
DR 전환 시 DNS, 시크릿, 배치 잡 순서가 문서화되지 않았다.

RTO/RPO는 SLA 문구가 아니라 시퀀스다. 복구 순서와 의사결정자를 포함한 플레이북이 있어야 의미가 있다.

핵심 개념

관점	설계 기준	검증 포인트
분류	서비스 티어별 목표 분리	Tier1 목표 달성률
데이터 보호	스냅샷 + WAL + 오프사이트	복원 시점 오차
전환 절차	네트워크/애플리케이션/배치 순차	총 복구 시간
훈련	분기별 DR Drill	실제 대비 오차

가장 효과적인 개선은 드릴 자동화다. 복구 명령과 검증 리포트를 스크립트로 만들어 반복성 있는 연습을 수행해야 한다.

코드 예시 1: 복구 체크 스크립트

#!/usr/bin/env bash
set -euo pipefail

./scripts/dr/restore-db.sh --target-time "$1"
./scripts/dr/restore-object-storage.sh
./scripts/dr/switch-dns.sh --to standby
./scripts/dr/health-check.sh --region standby

printf "DR drill completed at %s\n" "$(date -Iseconds)"

코드 예시 2: RTO/RPO 목표 선언

services:
  checkout:
    tier: 1
    rto_minutes: 30
    rpo_minutes: 5
  blog:
    tier: 2
    rto_minutes: 120
    rpo_minutes: 30
  analytics:
    tier: 3
    rto_minutes: 360
    rpo_minutes: 120

아키텍처 흐름

Mermaid diagram rendering...

트레이드오프

RTO/RPO를 공격적으로 잡으면 인프라 이중화 비용이 크게 증가한다.
자동화된 DR은 빠르지만 스크립트 자체 검증이 없으면 위험하다.
드릴 빈도를 높이면 준비도는 오르지만 운영팀 시간 비용이 커진다.

정리

DR은 문서가 아니라 반복 연습으로 완성된다. 티어별 목표를 명확히 나누고 복구 절차를 자동화하면 실제 장애에서도 예측 가능한 복구 시간을 달성할 수 있다.

이미지 출처

Cover: source link
License: AGPL / Author: Proxmox Server Solutions GmbH
Note: Wikimedia Commons 무료 라이선스 이미지를 다운로드 후 1600px 기준 JPG로 최적화했습니다.

도입