RTO와 RPO를 정하는 일은 “백업을 몇 시간마다 할 것인가”나 “대기 리전을 운영할 것인가”부터 고르는 일이 아니다. 먼저 어떤 업무가 얼마나 오래 멈출 수 있는지, 그리고 어느 시점 이후의 데이터 손실부터 받아들일 수 없는지를 정해야 한다.
그다음에야 복구 환경을 평소부터 어디까지 준비할지, 데이터를 얼마나 자주 보호할지, 자동화와 운영 인력에 어느 정도 투자할지를 비교할 수 있다. 같은 1시간의 RTO라도 장애 범위, 데이터 크기, 자동화 수준, 외부 의존성, 복구 인력에 따라 필요한 구조는 달라진다.
따라서 RTO와 RPO는 인프라 상품의 사양이라기보다 업무의 허용 한계를 기술 설계와 예산으로 번역한 목표에 가깝다. 백업 작업이 성공했다는 기록만으로는 이 목표를 충족했다고 판단할 수 없다. 실제 복구 경로를 끝까지 실행하고 서비스와 데이터가 사용할 수 있는 상태인지 확인해야 한다. (nvlpubs.nist.gov)
서버가 아니라 업무 프로세스와 서비스부터 나눈다
재해복구 목표를 “운영 서버 RTO 4시간”처럼 인프라 단위로만 정하면 무엇을 4시간 안에 복구해야 하는지 불분명해진다.
하나의 애플리케이션 안에서도 업무 중요도는 다를 수 있다. 예를 들어 주문 접수는 즉시 복구가 필요하지만 과거 통계 리포트는 나중에 다시 계산할 수 있다. 고객의 신규 요청을 받는 기능은 유지하면서 관리자용 추천 기능이나 배치 분석은 잠시 중단하는 축소 운영도 가능할 수 있다.
복구 목표의 첫 단위는 다음 중 하나여야 한다.
- 고객이나 직원이 끝내야 하는 중요한 업무 프로세스
- 로그인·주문·결제·접수·승인처럼 종료 조건이 분명한 서비스 흐름
- 별도 Owner와 복구 우선순위를 가질 수 있는 워크로드
AWS는 워크로드별로 복구 목표를 정의하고 상·하류 의존성과 데이터 재구성 가능성을 함께 검토하도록 권고한다. Microsoft의 지침도 하나의 시스템 전체에 단일 목표를 붙이기보다 중요 흐름과 구성요소별 요구를 구분하도록 한다. (docs.aws.amazon.com)
여기서 반드시 정해야 할 것이 최소 허용 복구 상태다. 모든 기능과 과거 데이터가 완전히 정상화된 상태만 복구 완료로 볼 것인지, 핵심 거래만 가능한 축소 상태도 임시 복구로 인정할 것인지에 따라 필요한 투자 수준이 크게 달라진다.
MTD, RTO, RPO는 같은 숫자가 아니다
NIST SP 800-34 Rev.1은 업무가 감당할 수 있는 최대 중단 시간을 MTD(Maximum Tolerable Downtime)라고 부른다. MTD는 시스템 한 대의 장애 시간이 아니라, 업무 프로세스가 멈춘 상태와 그 영향을 조직이 받아들일 수 있는 최대 총시간이다.
RTO(Recovery Time Objective)는 중단된 서비스나 자원을 어느 시간 안에 복구할 것인지 정한 목표다. NIST는 일반적으로 RTO가 MTD보다 짧아야 한다고 설명한다. 기술적인 서비스 복구 이후에도 손실 데이터 재구성, 밀린 작업 처리, 데이터 정합성 확인, 고객 안내와 정상 운영 복귀에 시간이 필요하기 때문이다. (nvlpubs.nist.gov)
실무에서는 다음 관계를 점검할 수 있다.
목표 RTO
+ 데이터 재구성·정합성 확인 시간
+ 밀린 업무 처리와 정상화 시간
≤ MTD이 식은 표준에 정의된 계산 공식이 아니라, RTO를 MTD와 혼동하지 않기 위한 계획용 검증식이다. 서비스가 기술적으로 켜진 뒤 업무를 정상적으로 수행할 수 있기까지 3시간이 더 필요하다면, RTO를 MTD와 같은 값으로 잡아서는 안 된다.
RPO(Recovery Point Objective)는 장애 이전 어느 시점의 데이터 상태까지 복구해야 하는지 나타낸다. RPO가 30분이라는 말은 원칙적으로 최대 30분 전 시점으로 돌아갈 수 있다는 시간 목표이지, 실제로 몇 건의 주문이나 얼마의 금액을 잃을 수 있다는 뜻은 아니다. 데이터 변경 속도와 업무 가치가 다르면 같은 30분도 전혀 다른 손실을 만든다. (docs.cloud.google.com)
따라서 RPO를 승인할 때는 시간과 함께 다음을 적어야 한다.
- 해당 시간 동안 예상되는 거래·파일·작업량
- 손실될 수 있는 금액이나 고객 영향
- 외부 시스템에서 다시 가져올 수 있는지
- 로그나 원천 데이터로 재생성할 수 있는지
- 사람이 다시 입력해야 한다면 필요한 시간과 인원
- 재구성이 불가능한 데이터인지
RTO는 복구 작업 전체의 시간 예산이다
RTO를 현실적으로 정하려면 복구 과정을 하나의 숫자로 뭉치지 말고 시간 예산으로 분해해야 한다.
장애 탐지
+ 영향 확인과 복구 선언
+ 담당자 집결·권한 확보
+ 복구 환경 활성화
+ 데이터 복원 또는 동기화
+ 의존 서비스 복구
+ 애플리케이션 기동
+ 기능·데이터 검증
+ 트래픽 전환과 사용자 재개
≤ 목표 RTO이 역시 특정 표준의 공식이 아니라, 공식 지침에 흩어진 복구 단계를 하나의 측정 경로로 정리한 것이다. NIST는 통지, 활성화, 복구, 재구성과 검증을 별도 단계로 다루며 Azure 지침은 사람의 의사결정과 Runbook, 연락 체계, 실제 Failover·Restore 시간을 목표 안에서 검토하도록 한다. (nvlpubs.nist.gov)
RTO 시계의 시작과 종료도 명시해야 한다.
이 글에서는 사용자에게 실제 영향이 시작된 시점부터 합의된 최소 복구 상태가 검증된 시점까지를 비즈니스 RTO로 측정할 것을 권한다. 장애 선언 이후부터 자동화 실행 완료까지만 측정하면 탐지 지연, 의사결정, 자격 증명 확보와 검증 시간이 숫자 밖으로 빠질 수 있다.
운영 개선을 위해서는 내부 구간도 별도로 측정할 수 있다.
- 사용자 영향 시작 → 탐지
- 탐지 → 장애 선언
- 선언 → 복구 작업 시작
- 작업 시작 → 인프라·데이터 복원
- 복원 → 기능 검증 완료
- 검증 완료 → 사용자 트래픽 재개
이렇게 해야 비용을 어디에 투자해야 RTO가 실제로 줄어드는지 찾을 수 있다. 대기 서버를 추가하는 것보다 선언 권한을 명확히 하거나 자격 증명 접근을 정리하는 편이 더 큰 개선을 만들 수도 있다.
RPO는 데이터마다 다르게 정할 수 있다
하나의 서비스에 있는 모든 데이터를 같은 RPO로 보호할 필요는 없다. 먼저 데이터를 다음처럼 분류한다.
| 데이터 분류 | 예 | 확인할 질문 | 목표에 미치는 영향 |
|---|---|---|---|
| 원천 거래 데이터 | 주문, 결제 상태, 승인 기록 | 다른 곳에서 다시 얻을 수 있는가 | 손실 허용 범위가 작고 정합성 검증이 중요할 수 있음 |
| 외부에서 재수집 가능한 데이터 | 외부 API 응답, 수신 메시지 | 원 제공자가 재전송·재조회할 수 있는가 | 외부 시스템의 보존 기간과 RPO가 의존 조건이 됨 |
| 파생 데이터 | 검색 색인, 캐시, 통계 집계 | 원천에서 다시 만들 수 있는가 | 데이터 RPO보다 재생성 시간이 RTO를 제한할 수 있음 |
| 사람이 재구성할 수 있는 데이터 | 일부 승인 메모, 업무 상태 | 누가 어떤 근거로 다시 입력하는가 | 인력·오류·재처리 시간이 MTD를 소비함 |
| 재구성 불가능한 데이터 | 업로드 원본, 일회성 입력 | 복사본이나 원본이 다른 곳에 존재하는가 | 더 엄격한 보호 목표가 필요할 수 있음 |
AWS Well-Architected는 데이터가 다른 원천에서 다시 만들어질 수 있는지, 해당 원천의 RPO는 무엇인지까지 확인하도록 한다. 재생성 가능한 데이터라면 저장 복제 수준을 낮출 여지가 있지만 재생성에 걸리는 시간과 원천 의존성이 RTO와 MTD 안에 들어와야 한다. (docs.aws.amazon.com)
예를 들어 검색 색인을 모두 잃어도 원본 데이터베이스에서 다시 생성할 수 있다면 색인 자체의 RPO는 비교적 느슨하게 둘 수 있다. 그러나 재생성에 10시간이 걸리고 검색 기능의 RTO가 2시간이라면 그 설계는 목표를 만족하지 못한다. 이 경우 필요한 투자는 데이터 복제일 수도 있고 색인 재생성 속도 개선이나 축소 검색 기능일 수도 있다.
의존성의 복구 목표가 서비스보다 느리면 목표를 달성할 수 없다
서비스 복구는 애플리케이션과 데이터베이스만의 문제가 아니다. 다음 요소 중 하나라도 준비되지 않으면 전체 경로가 멈출 수 있다.
- Identity Provider와 관리자 인증
- DNS, 네트워크, 인증서와 방화벽 규칙
- 암호화 키와 Secret
- 메시지 큐와 이벤트 스트림
- 외부 결제·메시징·지도·인증 API
- 데이터 공급자
- 모니터링과 로그
- 배포 도구와 코드 저장소
- 고객 안내 채널
- 클라우드·통신사·외부 운영사의 지원
- 복구를 승인하고 수행할 사람
AWS와 Azure의 복구 지침은 상·하류 의존성, 인증·네트워크·모니터링, 외부 서비스와 복구 담당자를 함께 확인하도록 한다. 개별 구성요소의 목표가 전체 서비스 목표와 맞지 않으면 복구 계획은 문서상 숫자에 그친다. (docs.aws.amazon.com)
각 Dependency에는 최소한 다음을 기록한다.
Dependency
Owner
지원하는 업무
자체 RTO·RPO 또는 복구 약속
실제 확인된 복구 능력
대체 경로
우리 서비스 목표와의 차이외부 API가 24시간 안에 복구된다는 조건인데 우리 서비스 RTO를 1시간으로 승인하려면, 그 API 없이도 동작하는 축소 모드나 대체 공급자가 있어야 한다. 그렇지 않으면 1시간이라는 숫자는 실현 가능한 목표가 아니다.
사람과 절차도 복구 아키텍처다
복구 환경이 자동으로 준비되어 있어도 사람이 다음 질문에 답하지 못하면 RTO는 길어진다.
- 누가 재해 상황을 선언하는가
- 근무시간 밖에는 누가 결정하는가
- 복구 환경의 계정과 키에 접근할 수 있는가
- 어떤 순서로 서비스를 올리는가
- 데이터 충돌이 생기면 누가 기준 상태를 결정하는가
- 고객·경영진·외부 공급자에게 누가 알리는가
- Failover 이후 원래 환경으로 돌아가는 조건은 무엇인가
NIST는 복구 계획에 역할, 연락 체계, 통지, 훈련과 연습을 포함하고 실제 테스트를 통해 계획의 결함을 찾도록 한다. Azure도 Runbook, 의사결정자, 커뮤니케이션 계획과 사람 기반 통제를 복구 능력의 일부로 다룬다. (nvlpubs.nist.gov)
Runbook이나 연락처가 장애가 난 주 시스템 안에만 있다면 실제 재해 중에는 접근할 수 없다. 복구 절차, 자격 증명 획득 방법, 담당자 연락처와 상태 공지 수단은 주 장애 도메인과 분리해 접근 가능해야 한다.
복구 환경은 ‘존재’보다 ‘현재 상태’를 확인해야 한다
복구용 환경이 만들어져 있다는 사실만으로 사용할 수 있는 상태라고 볼 수는 없다.
평소 사용하지 않는 환경에서는 다음과 같은 Drift가 생기기 쉽다.
- 애플리케이션 버전 차이
- 운영 환경과 다른 설정
- 만료된 인증서
- 누락된 Secret과 권한
- 잘못된 DNS·방화벽 규칙
- 부족한 인스턴스·스토리지·API 할당량
- 다른 데이터베이스 스키마
- 연결되지 않은 로그와 모니터링
- 실제 트래픽을 처리하지 못하는 용량
AWS와 Azure의 현재 지침은 복구 환경의 구성·데이터 정합성, 할당량, 네트워크·Identity·모니터링과 실제 복구 Drill을 함께 검증하도록 한다. (docs.aws.amazon.com)
복구 환경의 준비 상태는 “있음/없음”보다 다음처럼 기록하는 편이 낫다.
- 코드와 설정으로 재구축 가능
- 핵심 기반 환경만 상시 준비
- 축소 용량의 대기 환경 준비
- 운영 수준의 대기 환경 준비
- 여러 환경이 동시에 실제 트래픽 처리
이 상태는 복구 Pattern을 설명할 뿐 특정 RTO와 자동으로 연결되지 않는다. 자동화 품질, 데이터 양, 실패 범위, 팀 숙련도에 따라 같은 Pattern에서도 실제 복구 시간은 달라진다.
Service Recovery Objective Worksheet
다음 Worksheet는 서비스별로 RTO·RPO 목표와 투자 근거를 함께 기록하기 위한 템플릿이다.
1. 업무와 허용 영향
| 필드 | 기입 내용 | 완료 기준 |
|---|---|---|
| Service / Process ID | 복구 목표를 소유하는 서비스·업무 이름 | 서버명이나 DB명이 아니라 업무 결과가 드러남 |
| Critical Flow | 사용자가 완료해야 하는 핵심 흐름 | 시작·종료 조건이 명확함 |
| Business Owner | 업무 영향과 목표를 승인할 사람 | 기술팀만이 아니라 업무 책임자가 포함됨 |
| Recovery Decision Authority | 복구·Failover를 선언할 사람과 대체자 | 근무시간 밖 대체 권한까지 있음 |
| Users / Deadline | 영향받는 사용자, 마감시간, 성수기 | 시간대에 따라 영향이 달라지는지 기록 |
| Failure Scenarios in Scope | 인스턴스, 데이터 손상, 계정 상실, 네트워크, 리전 등 | 이번 목표가 다루는 장애 범위가 명확함 |
| Impact Timeline | 중단 15분·1시간·4시간·1일 등 시점별 영향 | 금액·고객·규제·안전·운영 영향을 구분 |
| MTD | 업무가 감당할 수 있는 최대 총중단 시간 | 근거와 승인자가 있음 |
| Minimum Recovery State | 전체·축소·수동 대체 중 허용 가능한 상태 | “복구 완료”의 기능·용량 조건이 측정 가능함 |
2. RTO·RPO와 데이터 재구성
| 필드 | 기입 내용 | 완료 기준 |
|---|---|---|
| Target RTO | 목표 복구 시간 | 시작·종료 시점과 장애 범위가 함께 정의됨 |
| RTO Time Budget | 탐지, 선언, 접근, 환경, 데이터, Dependency, 검증, 트래픽별 예산 | 각 구간의 Owner가 있음 |
| Data Sets | 서비스가 필요로 하는 데이터 목록 | 원천·파생·외부·수동 재구성 가능 여부가 구분됨 |
| Target RPO by Data Set | 데이터별 허용 손실 시간 | 서비스 전체에 무조건 같은 값이 적용되지 않음 |
| Loss at RPO | 해당 시간 동안 예상되는 거래·금액·작업량 | 시간 목표가 업무 영향으로 변환됨 |
| Reconstruction Source | 원천 로그, 외부 시스템, 사용자 원본 등 | 실제 접근 가능성과 보존 기간이 확인됨 |
| Reconstruction Effort | 자동·수동 절차, 인원, 예상 소요시간 | MTD 계산에 포함됨 |
| Reconciliation / Catch-up | 중복 제거, 재처리, 밀린 작업, 고객 조정 | 기술 기동 이후의 업무 정상화가 포함됨 |
| MTD Consistency Check | RTO + 재구성·정상화 시간 ≤ MTD |
초과 시 목표·설계·업무 대체 중 하나를 수정 |
3. Dependency·환경·사람·커뮤니케이션
| 필드 | 기입 내용 | 완료 기준 |
|---|---|---|
| Upstream Dependencies | Identity, DNS, 네트워크, 키, 외부 API, 원천 데이터 | Owner·복구 능력·대체 경로가 기록됨 |
| Downstream Dependencies | 이 서비스를 기다리는 다른 업무·시스템 | 복구 순서와 영향이 정리됨 |
| Dependency Objective Gap | 각 Dependency의 목표와 서비스 목표 차이 | 느린 Dependency에는 우회 방법이 있음 |
| Recovery Environment | 재구축·기반 준비·대기·동시 운영 등 현재 상태 | 용량·설정·할당량이 검증됨 |
| Configuration Control | IaC, 설정 버전, Secret·인증서 관리 | 운영 환경과의 Drift를 찾을 수 있음 |
| People and Roles | Incident Lead, 기술 담당, 업무 승인자, 커뮤니케이션 담당 | 대체자와 근무시간 외 연락 체계가 있음 |
| Credential Access | 계정·키·Break-glass 접근 절차 | 주 환경 장애 중에도 접근 가능함 |
| Runbook | 선언부터 복구·검증·복귀까지의 순서 | 실행 명령뿐 아니라 판단 조건이 포함됨 |
| Communication | 내부 보고 고객 공지, Vendor Escalation, 갱신 주기 | 주 시스템과 독립된 연락 수단이 있음 |
4. 검증과 투자 결정
| 필드 | 기입 내용 | 완료 기준 |
|---|---|---|
| Test Scenario | 실제로 검증한 장애 범위 | 목표의 Scope와 동일함 |
| Validation Criteria | 핵심 흐름, 데이터 무결성, 권한, 보안, 모니터링, 용량 | 서버 기동 여부만으로 종료하지 않음 |
| Last Exercise | 마지막 복구 Drill 날짜와 환경 | 대표 데이터 규모와 Dependency가 포함됨 |
| Measured Recovery Duration | 영향 시작부터 검증 완료까지 실측 시간 | 목표 RTO와 직접 비교 가능함 |
| Actual Data Loss Window | 복구 후 확인된 실제 데이터 손실 구간 | 목표 RPO와 직접 비교 가능함 |
| Reconstruction Duration | 손실 데이터와 밀린 업무를 정상화한 시간 | MTD 검증에 사용됨 |
| Current Gap | 목표 미달 구간과 원인 | 인프라·자동화·사람·Dependency로 분해됨 |
| Improvement Option | 목표를 개선할 수 있는 설계·운영 대안 | 특정 상품명보다 필요한 역량이 적힘 |
| Incremental Annual Cost | 추가 자원·도구·개발·훈련·지원 비용 | 기존 비용과 분리됨 |
| Expected Benefit | 줄어드는 중단 영향과 데이터 손실 | 금액화가 어렵다면 영향 등급과 근거 기록 |
| Approval | 목표·예산·잔여 위험 승인자 | Business Owner와 기술 Owner가 함께 승인 |
| Next Review | 다음 Drill과 목표 재검토일 | 서비스·Dependency 변경과 연동됨 |
Worksheet의 증거 상태
각 서비스의 목표에는 다음 상태 중 하나를 붙이는 것이 좋다.
| 상태 | 의미 |
|---|---|
| 검증됨 | 대표적인 장애 범위와 데이터 규모로 전체 경로를 실행했고 목표 안에 복구함 |
| 추정치 | 설계와 Runbook은 있으나 Dependency를 포함한 전체 복구 Drill이 아직 없음 |
| 미충족 | 실측 결과가 목표를 넘거나 필요한 복구 경로가 존재하지 않음 |
추정치를 검증됨처럼 보고하지 않는 것이 중요하다. 테스트하지 않은 1시간 RTO는 약속이 아니라 가설이다.
복구 Pattern은 목표 시간에 고정 매핑하지 않는다
복구 환경을 어느 수준까지 미리 준비할지는 다음처럼 비교할 수 있다. 아래 분류는 Vendor 상품 등급이 아니라 준비 상태를 비교하기 위한 추상화다.
| Recovery Pattern | 장애 전 준비 상태 | 주요 지연 요인 | 주요 비용·운영 부담 | 적합성을 검토할 조건 |
|---|---|---|---|---|
| 코드로 재구축 후 데이터 복원 | 운영 외 환경은 거의 없음 | 자원 생성, 설정, 대용량 데이터 복원, 검증 | 평상시 자원비는 낮지만 자동화·복원 속도 의존도가 큼 | 중단 허용 시간이 비교적 길고 환경을 일관되게 재구축할 수 있을 때 |
| 기반 환경 상시 준비 후 확장 | 네트워크·Identity·핵심 데이터 경로가 준비됨 | 용량 확장, 애플리케이션 배포, 최신 데이터 적용 | 기반 자원, Drift 관리, 확장 자동화 | 일부 기반 요소 준비가 복구 시간을 크게 줄일 때 |
| 대기 환경 상시 유지 | 애플리케이션과 데이터가 축소 또는 운영 수준으로 준비됨 | 전환 판단, 데이터 수렴, 검증, 트래픽 변경 | 중복 자원, 지속 동기화, 패치·보안·Drill | 재구축 시간이 목표의 주요 병목일 때 |
| 여러 환경에서 동시 서비스 | 둘 이상의 환경이 실제 트래픽을 처리함 | 장애 격리, 쓰기 정합성, 부분 장애 판정 | 가장 높은 설계·데이터·운영 복잡성, 지속 용량 | 특정 장애 도메인의 중단을 서비스가 흡수해야 할 때 |
공식 클라우드 지침도 사업 목표, 실패 범위, Dependency와 비용을 먼저 확인한 뒤 복구 구조를 선택하도록 한다. Pattern 이름이나 예시 시간은 조직의 자동화 수준과 시스템 구조를 대신할 수 없다. (docs.aws.amazon.com)
“RTO 1시간이면 무조건 Multi-Region” 같은 규칙은 성립하지 않는다.
단일 인스턴스 장애만 Scope에 포함되고 환경을 빠르게 재구성할 수 있다면 다른 구조로도 목표를 달성할 수 있다. 반대로 리전 전체 상실, 계정 접근 불가, 외부 Identity 장애까지 Scope에 포함한다면 단순한 대기 서버만으로는 부족할 수 있다. 데이터 손상이나 잘못된 배포처럼 여러 환경에 동시에 영향을 줄 수 있는 사건도 별도로 고려해야 한다. (docs.cloud.google.com)
목표 시간 하나가 아키텍처를 결정하는 것이 아니라 다음 조합이 결정한다.
허용 중단·데이터 손실
× 다루려는 실패 범위
× 데이터와 Dependency 특성
× 자동화·사람·절차의 현재 능력
× 검증된 복구 결과
× 지불 가능한 비용목표를 강화할수록 무엇에 비용이 드는가
RTO와 RPO가 짧아질수록 비용은 단순히 백업 저장공간만 늘어나는 방식으로 증가하지 않는다. 일정 지점을 넘으면 새로운 복구 환경, 지속 복제, 자동화, 인력과 운영 통제가 필요해져 비용이 계단식으로 커질 수 있다. NIST와 주요 클라우드의 공식 지침도 짧은 목표가 더 높은 비용과 관리 복잡성을 요구하며 조직별로 적정 균형점이 다르다고 설명한다. (nvlpubs.nist.gov)
RTO를 줄일 때 증가하는 비용
- 미리 준비한 Compute·Network·Database 용량
- 환경 생성과 배포 자동화
- 설정·Secret·인증서·할당량의 지속 정합성 관리
- 빠른 장애 탐지와 선언 체계
- 근무시간 외 대응 인력
- 반복적인 Failover·Failback Drill
- Dependency의 더 강한 지원 계약이나 대체 경로
- 축소 운영 기능 개발
RPO를 줄일 때 증가하는 비용
- 더 잦은 데이터 보호와 로그 보존
- 지속 복제와 네트워크 사용량
- 쓰기 정합성·중복·순서 문제를 다루는 설계
- 더 많은 복구 지점과 보존 관리
- 데이터 무결성 확인과 Reconciliation
- 원천 데이터와 외부 시스템의 보존·재전송 역량
RTO와 RPO를 동시에 줄일 때 증가하는 비용
두 목표를 함께 강화하면 빠르게 준비된 환경과 최신 데이터가 동시에 필요해진다. 여기에 Failover 이후의 정합성, 원래 환경으로 돌아가는 Failback, 여러 환경의 패치와 보안, 지속적인 검증 부담이 더해진다.
예산 검토에서는 “상위 DR 등급으로 전환”이라고 표현하기보다 다음처럼 증분 역량을 비교하는 것이 낫다.
| 대안 | 개선되는 구간 | 추가되는 역량 | 연간 증분 비용 | 목표 달성 근거 |
|---|---|---|---|---|
| A | 장애 선언 시간 | 당직·권한·Runbook 개선 | Drill 결과 | |
| B | 환경 준비 시간 | 자동화된 재구축·기반 환경 준비 | 재구축 테스트 | |
| C | 데이터 복구 시간 | 더 짧은 보호 주기·복제·재생성 개선 | 실제 데이터 규모 복원 | |
| D | Dependency 지연 | 대체 경로·지원 계약·축소 운영 | 통합 장애 테스트 |
먼저 병목을 찾고 그 구간에 투자해야 한다. 데이터 복원에 20분밖에 걸리지 않는데 장애 선언에 2시간이 걸린다면 더 비싼 복제 기술만 추가해도 RTO는 거의 줄어들지 않는다.
Restore Test는 업무가 다시 가능한지 확인할 때 끝난다
복구 완료 시점을 “인스턴스가 실행 중”이나 “데이터베이스 연결 성공”으로 잡으면 실제 업무 복구 시간보다 짧게 측정된다.
복구 검증에는 최소한 다음이 포함되어야 한다.
- 핵심 사용자 흐름의 성공
- 데이터 무결성과 기준 시점 확인
- 인증·권한과 암호화 키
- 외부 Dependency 연결
- 충분한 처리 용량
- 로그·모니터링·알림
- 보안 통제
- 새 데이터 쓰기와 후속 처리
- 고객·업무 담당자의 Acceptance
- 밀린 작업과 데이터 재구성 절차
NIST는 기능·회귀·데이터 검증이 완료된 뒤 시스템을 복구된 상태로 선언하도록 한다. Google의 공식 지침도 복원 테스트를 데이터 파일 확인에 한정하지 않고 애플리케이션 스택과 핵심 인프라를 복원된 데이터로 검증하도록 한다. (nvlpubs.nist.gov)
백업 생성 기록은 입력 증거일 뿐이다. RTO와 RPO를 충족했다는 증거는 합의된 장애 범위에서 전체 복구 경로를 실행한 결과다.
자주 발생하는 잘못된 판단
| 잘못된 판단 | 문제가 되는 이유 | 수정 방법 |
|---|---|---|
| 회사 전체에 RTO·RPO 하나를 적용한다 | 업무 중요도와 데이터 특성이 다름 | 서비스·Critical Flow·데이터별로 구분 |
| 백업 주기가 곧 달성된 RPO라고 본다 | 실패·지연·손상·복원 불가를 반영하지 못함 | 실제 복구된 시점과 데이터 손실 구간 측정 |
| 서버가 켜지면 RTO를 달성했다고 본다 | Dependency·데이터·업무 기능·검증이 빠짐 | 최소 허용 복구 상태와 Acceptance 정의 |
| Vendor SLA나 MTTR을 우리 RTO로 사용한다 | 공급자 자원 수준과 업무 복구 완료는 다름 | 전체 서비스 경로의 목표와 실측값 관리 |
| Dependency의 목표를 확인하지 않는다 | 가장 느린 의존성이 전체 복구를 제한함 | Dependency별 목표·실측·우회 경로 기록 |
| 사람과 연락 시간을 계산하지 않는다 | 선언·접근·승인 지연이 RTO 밖으로 숨음 | 사람·절차·커뮤니케이션을 시간 예산에 포함 |
| 특정 RTO를 특정 Pattern에 자동 연결한다 | 실패 범위·데이터·자동화·팀 능력이 다름 | 복구 경로를 설계하고 Drill로 증명 |
| 한 번 성공한 테스트로 영구 승인한다 | 데이터 규모·구성·Dependency가 계속 바뀜 | 변경과 정기 Drill에 맞춰 목표 재검토 |
목표는 합의하고, 설계하고, 측정한 뒤 다시 협상한다
RTO와 RPO를 정하는 순서는 다음과 같다.
업무 프로세스와 Owner 정의
→ 시간에 따른 중단 영향과 MTD 확인
→ 최소 허용 복구 상태 정의
→ 데이터별 RPO와 재구성 가능성 확인
→ Dependency·사람·복구 환경을 포함해 RTO 분해
→ 복구 Pattern과 증분 비용 비교
→ 전체 경로 Drill
→ 실측 결과와 목표 차이 확인
→ 투자·축소 운영·목표 조정 중 하나를 승인목표를 달성할 수 없다면 선택지는 세 가지다.
- 복구 환경·데이터 보호·자동화·사람에 더 투자한다.
- 핵심 기능만 먼저 살리는 축소 운영이나 수동 대체 절차를 설계한다.
- 업무 책임자와 허용 중단·데이터 손실 목표를 다시 협상한다.
해서는 안 되는 선택은 검증되지 않은 숫자를 그대로 유지하는 것이다.
RTO와 RPO는 짧을수록 좋은 점수가 아니다. 업무가 실제로 필요로 하는 수준이고 Dependency와 사람을 포함한 전체 경로로 검증되며 조직이 그 비용과 잔여 위험을 승인할 수 있을 때 유효한 복구 목표가 된다.