핵심 인사이트
- 본질: RTO는 '얼마나 빨리 복구하느냐'(시간), RPO는 '얼마나 최신 데이터를 복구하느냐'(데이터 손실 허용치)로 재해 복구 설계의 두 축이다.
- 가치: RTO·RPO가 낮을수록 비즈니스 영향은 줄어들지만 DR 비용은 기하급수적으로 증가한다. BIA 기반으로 비용 대비 최적 목표치를 설정해야 한다.
- 판단 포인트: RTO 0(무중단)·RPO 0(데이터 무손실)은 미러 사이트만 가능하며 가장 비싸다. 미러→핫→웜→콜드 순으로 RTO/RPO가 길어지며 비용은 낮아진다.
Ⅰ. 개요 및 필요성
RTO(Recovery Time Objective, 복구 목표 시간)는 재해 발생 후 서비스가 완전히 복구되어야 하는 최대 허용 시간이다. RPO(Recovery Point Objective, 복구 목표 시점)는 재해 발생 시 복구할 수 있는 데이터의 최신 시점으로, 마지막 백업 시점부터 장애 발생 시점 사이의 데이터 손실 허용량이다. 두 지표는 BIA(Business Impact Analysis)를 통해 비즈니스 요구사항으로 결정되며, IT 시스템의 DR 설계를 규정한다.
예를 들어, 은행의 핵심 거래 시스템은 RTO 30분·RPO 0분(무손실)이 요구되지만, 내부 교육 시스템은 RTO 48시간·RPO 24시간으로 충분할 수 있다. 이 차이는 DR 인프라 투자 결정의 과학적 근거다.
📢 섹션 요약 비유: RTO는 불이 난 후 소방차가 도착해야 하는 목표 시간이고, RPO는 '최소한 어제까지의 집 사진은 남아있어야 한다'는 요구다.
Ⅱ. 아키텍처 및 핵심 원리
| 지표 | 정의 | 측정 단위 | DR 사이트 연관성 |
|---|---|---|---|
| RTO | 재해 발생 ~ 서비스 복구 목표 시간 | 분, 시간, 일 | 낮을수록 핫/미러 사이트 필요 |
| RPO | 복구 가능한 데이터의 최신 시점 | 분, 시간, 일 | 낮을수록 실시간 복제 필요 |
| MTTR | 실제 평균 복구 시간 (목표 vs 실적) | 시간 | RTO와 비교해 성과 측정 |
| MAO | 비즈니스 허용 최대 중단 시간 | 시간 | RTO의 상한선 |
┌───────────────────────────────────────────────────────────────┐
│ RTO / RPO 개념 타임라인 │
│ │
│ 정상 운영 장애 발생 복구 완료 │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ────●───────────────●───────────────●────────────▶ 시간 │
│ │ │ │ │
│ │←── RPO ──────▶│ │ │
│ │ (이 데이터부터 복구 필요) │ │
│ │ │ │
│ │ │←──── RTO ────▶│ │
│ │ │ (이 시간 내 복구 완료 필요) │
│ │
│ RPO = 마지막 복구 가능 시점 ~ 장애 시점 사이의 데이터 손실 │
│ RTO = 장애 발생 ~ 서비스 완전 복구까지 허용 시간 │
└───────────────────────────────────────────────────────────────┘
📢 섹션 요약 비유: RPO는 '어제 저장한 Word 파일까지는 복구돼야 해'이고, RTO는 '컴퓨터가 2시간 안에 다시 켜져야 해'다. 둘 다 짧을수록 좋지만 비싸진다.
Ⅲ. 비교 및 연결
| DR 유형 | RTO | RPO | 비용 | 기술 |
|---|---|---|---|---|
| 미러 사이트 | 0 (무중단) | 0 (무손실) | 매우 높음 | Active-Active, 실시간 복제 |
| 핫 사이트 | 수 분~1시간 | 수 분 | 높음 | Active-Standby, 실시간 복제 |
| 웜 사이트 | 수 시간 | 수 시간 | 중간 | 주기적 복제, 준비된 인프라 |
| 콜드 사이트 | 수 일 | 24시간+ | 낮음 | 테이프/백업, 빈 공간 |
📢 섹션 요약 비유: 미러는 '쌍둥이 식당'(한 곳이 닫혀도 즉시 영업), 핫은 '직원 대기 중인 예비 식당', 웜은 '몇 시간이면 열 수 있는 창고', 콜드는 '빈 건물만 있는 땅'이다.
Ⅳ. 실무 적용 및 기술사 판단
클라우드 환경에서는 AWS RDS Multi-AZ(RTO 수 분·RPO 수 초), S3 Cross-Region Replication(RPO 수 초~수 분) 등으로 전통적 미러/핫 사이트 구현 비용이 대폭 낮아졌다. 그러나 RTO·RPO 달성 여부는 정기 DR 테스트를 통해 검증해야 한다. '목표(Objective)'와 '실제 성과(Actual)'의 갭을 매년 DR 훈련 보고서에 기록하고 개선하는 것이 성숙한 BCP 운영의 증거다.
📢 섹션 요약 비유: RTO·RPO는 스포츠 기록 목표다. '100m를 10초에 뛰겠다'고 목표를 세워도, 실제 훈련에서 13초가 나오면 목표를 재검토하거나 훈련을 강화해야 한다.
Ⅴ. 기대효과 및 결론
명확한 RTO·RPO 정의는 DR 인프라 투자의 ROI를 최대화하고, 서비스 중단 시 이해관계자에게 투명한 복구 계획을 제시한다. 클라우드·IaC(Infrastructure as Code) 결합으로 RPO 0·RTO 수 분 수준의 복구를 오온프레미스 대비 1/3 비용으로 달성하는 사례가 늘고 있다.
📢 섹션 요약 비유: RTO·RPO는 보험 계약서의 보장 조건이다. 명확하게 숫자로 정의해야 재난이 발생했을 때 '얼마나 빨리, 얼마나 많은 데이터를 돌려받을 수 있는지' 아무도 다투지 않는다.
📌 관련 개념 맵
| 개념 | 설명 | 연관 키워드 |
|---|---|---|
| RTO (Recovery Time Objective) | 서비스 복구 목표 시간 | DR 사이트, BCP |
| RPO (Recovery Point Objective) | 데이터 손실 허용 목표 시점 | 백업, 복제 |
| MAO (Maximum Acceptable Outage) | 비즈니스 허용 최대 중단 시간 | BIA, BCP |
| MTTR (Mean Time To Repair) | 실제 평균 복구 시간 | 인시던트 관리, SLA |
| IaC (Infrastructure as Code) | 코드 기반 인프라 관리 | Terraform, 클라우드 DR |
👶 어린이를 위한 3줄 비유 설명
- RTO는 숙제를 잃어버렸을 때 '2시간 안에 다시 써야 해'처럼 복구 시간 목표예요.
- RPO는 '어제까지 쓴 내용은 꼭 기억해야 해'처럼 얼마나 오래된 데이터까지 허용하는지예요.
- 둘 다 짧을수록 완벽하지만 비용이 많이 들어서, 중요한 숙제일수록 더 자주 저장해두는 게 맞아요.