클라우드 환경에서 시스템 장애나 자연재해, 랜섬웨어 공격 등으로 인한 서비스 중단은 기업의 비즈니스 연속성에 치명적인 영향을 미칩니다. 이에 대비하기 위한 핵심 전략이 바로 DR(Disaster Recovery, 재해복구)이며, 그 중심에는 RTO(Recovery Time Objective)와 RPO(Recovery Point Objective)가 있습니다. 이번 글에서는 클라우드 DR 설계 시 반드시 고려해야 할 RTO/RPO 개념과 이를 달성하기 위한 구조적 접근법을 깊이 있게 분석합니다.
1. RTO와 RPO의 정의
RTO (Recovery Time Objective)
RTO는 장애 발생 시 서비스가 복구되기까지 허용 가능한 최대 시간을 의미합니다. 예를 들어 RTO가 1시간이라면, 시스템 장애 발생 후 1시간 내에 서비스를 복구해야 합니다.
RPO (Recovery Point Objective)
RPO는 장애 시점 기준으로 데이터 손실이 허용되는 최대 시점을 뜻합니다. 예를 들어 RPO가 10분이라면, 데이터 백업은 최소 10분 단위로 수행되어야 합니다.
| 구분 | RTO | RPO |
|---|---|---|
| 정의 | 복구까지 허용 가능한 최대 시간 | 손실이 허용 가능한 데이터 시점 |
| 중점 영역 | 서비스 복구 속도 | 데이터 백업 주기 |
| 설계 영향 요소 | 컴퓨팅 리소스, 자동화, 복구 절차 | 스토리지 복제, 백업 주기, 네트워크 대역폭 |
RTO와 RPO는 DR 전략의 성능 목표치이자, 비용·아키텍처·운영 난이도에 직접적인 영향을 미치는 핵심 지표입니다.
2. 클라우드 환경에서의 DR 유형
클라우드 DR은 아키텍처와 비용 구조에 따라 여러 형태로 구분됩니다. 각 모델은 RTO/RPO 목표 수준에 따라 선택됩니다.
① 백업 & 복원 (Backup & Restore)
- RTO: 수 시간 ~ 수일
- RPO: 수 시간
- 백업 데이터를 S3, Blob Storage 등에 저장 후 필요 시 복구
- 가장 비용 효율적이지만 복구 속도는 느림
② 파일럿 라이트 (Pilot Light)
- RTO: 수십 분
- RPO: 수 분 ~ 수십 분
- 핵심 구성 요소만 상시 구동하고, 장애 시 나머지를 빠르게 기동
- AWS에서는 RDS Read Replica, AMI 기반 복원 전략 활용
③ 웜 스탠바이 (Warm Standby)
- RTO: 수 분
- RPO: 수 분
- 축소된 규모의 운영 환경을 유지하다 장애 시 즉시 확장(Auto Scaling)
- 비용과 복구 속도의 균형이 뛰어난 구조
④ 멀티 사이트 액티브-액티브 (Multi-Site Active-Active)
- RTO: 실시간
- RPO: 거의 0
- 두 개 이상의 리전에서 서비스 동시 운영
- 복제 지연 최소화, 무중단 장애 대응 가능
- 가장 높은 안정성을 제공하지만 비용 부담이 큼
3. RTO/RPO 목표 수립 시 고려 요소
RTO와 RPO는 단순히 ‘짧을수록 좋은 값’이 아닙니다. 각 기업의 비즈니스 중요도, 데이터 특성, 예산에 따라 합리적인 목표를 설정해야 합니다.
- 💼 비즈니스 중요도 분석(BIA, Business Impact Analysis): 서비스 중단이 비즈니스에 미치는 손실 규모를 수치화합니다.
- 🧩 시스템 간 의존성 분석: 데이터베이스, 인증 서버, API 게이트웨이 등 상호 의존 관계를 파악해야 합니다.
- 💰 비용 대비 복원성 검토: 초저 RTO/RPO 달성을 위해선 높은 인프라 비용이 발생합니다.
- 🌐 지리적 이중화: 단일 리전 장애를 대비해 별도 리전에 복제 또는 페일오버 구성을 고려합니다.
4. 클라우드 DR 설계 시 핵심 기술 요소
① 데이터 복제(Replication)
- 동기 복제(Synchronous): 데이터 유실 거의 0, RPO≈0
- 비동기 복제(Asynchronous): 지연 허용, 비용 절감 가능
- 예: AWS Aurora Global Database, Azure SQL Geo-Replication, GCP Spanner
② 스냅샷 및 버전 관리
- 주기적 스냅샷 저장으로 특정 시점(Point-in-Time) 복구 가능
- Immutable Storage를 통해 랜섬웨어 대응
- 예: Amazon EBS Snapshot, Azure Recovery Vault
③ 자동화된 페일오버(Failover)
- DNS 기반 장애 전환 (Route 53, Cloud DNS)
- 헬스체크 기반 자동 전환
- CI/CD 파이프라인과 연동하여 자동 복구 테스트 가능
④ IaC 기반 복구 자동화
- Terraform, AWS CloudFormation, Azure Bicep 등으로 복구 환경 자동 구축
- 코드형 인프라를 통한 일관된 복원성 확보
5. 실무 적용 예시: AWS 기반 DR 설계
AWS를 예시로 RTO/RPO 요구사항에 따른 DR 구조를 간략히 살펴보겠습니다.
| 전략 | RTO | RPO | 구성 예시 |
|---|---|---|---|
| Backup & Restore | 4시간 | 1시간 | S3 + Glacier 백업 |
| Pilot Light | 30분 | 10분 | AMI, RDS Read Replica |
| Warm Standby | 10분 | 5분 | Auto Scaling, Cross-Region Replication |
| Active-Active | 실시간 | 0 | Multi-Region Load Balancer, Aurora Global |
6. DR 테스트 및 검증
DR 설계의 완성은 ‘실제 복구가 가능한지’에 달려 있습니다. 주기적인 DR 테스트는 설계 신뢰성 확보의 마지막 단계입니다.
- 🧠 Tabletop Exercise: 복구 시나리오를 문서 기반으로 점검
- ⚙️ Simulation Test: 실제 장애 환경을 가정한 복원 실습
- 🧾 자동화 테스트: IaC 스크립트를 통한 정기적 복구 검증
7. 결론
클라우드 재해복구는 단순히 백업을 넘어서, 비즈니스 연속성(BCP, Business Continuity Planning)의 핵심 구성요소입니다. RTO와 RPO를 명확히 정의하면, 서비스 중단 시에도 비즈니스 가치 손실을 최소화할 수 있습니다. 결국 DR 설계는 기술이 아니라 리스크 관리 전략이며, 클라우드의 탄력성과 자동화를 적극 활용할수록 보다 견고하고 지능적인 복구 체계를 구축할 수 있습니다.