RTO와 RPO로 재해복구 수준과 비용을 정하는 법

서버가 아니라 업무 프로세스와 서비스부터 나눈다

RTO와 RPO를 정하는 일은 “백업을 몇 시간마다 할 것인가”나 “대기 리전을 운영할 것인가”부터 고르는 일이 아닙니다. 먼저 어떤 업무가 얼마나 오래 멈춰도 되는지, 그리고 어느 시점 이후의 데이터 손실부터 받아들이지 못하는지를 정합니다. 그다음에야 복구 환경을 평소부터 어디까지 준비할지, 데이터를 얼마나 자주 보호할지, 자동화와 운영 인력에 얼마를 넣을지를 비교합니다.

같은 1시간의 RTO라도 장애 범위와 데이터 크기, 자동화 수준, 외부 의존성, 복구 인력에 따라 필요한 구조가 달라집니다. 그래서 RTO와 RPO는 인프라 상품의 사양이라기보다 업무의 허용 한계를 기술 설계와 예산으로 옮긴 목표에 가깝습니다. 백업 작업이 성공했다는 기록만으로는 목표 달성을 판단하지 못합니다. 실제 복구 경로를 끝까지 실행하고 서비스와 데이터가 쓸 수 있는 상태인지 확인해야 합니다.^[1]

재해복구 목표를 “운영 서버 RTO 4시간”처럼 인프라 단위로만 정하면 무엇을 4시간 안에 복구해야 하는지 흐려집니다. 하나의 애플리케이션 안에서도 업무 중요도는 다릅니다. 주문 접수는 즉시 복구가 필요하지만 과거 통계 리포트는 나중에 다시 계산합니다. 고객의 신규 요청을 받는 기능은 유지하면서 관리자용 추천 기능이나 배치 분석은 잠시 멈추는 축소 운영도 선택지입니다.

복구 목표의 첫 단위는 셋 중 하나여야 합니다. 고객이나 직원이 끝내야 하는 중요한 업무 프로세스, 로그인·주문·결제·접수·승인처럼 종료 조건이 분명한 서비스 흐름, 별도 Owner와 복구 우선순위를 두는 워크로드입니다. AWS는 워크로드별로 복구 목표를 정의하고 상·하류 의존성과 데이터 재구성 가능성을 함께 검토하도록 권합니다.^[4] Microsoft의 지침도 하나의 시스템 전체에 단일 목표를 붙이기보다 중요 흐름과 구성요소별 요구를 가르도록 합니다.^[2]

여기서 반드시 정해야 할 것이 최소 허용 복구 상태입니다. 모든 기능과 과거 데이터가 완전히 정상화된 상태만 복구 완료로 볼 것인지, 핵심 거래만 가능한 축소 상태도 임시 복구로 인정할 것인지에 따라 필요한 투자 수준이 크게 달라집니다.

MTD, RTO, RPO는 같은 숫자가 아니다

NIST SP 800-34 Rev.1은 업무가 감당하는 최대 중단 시간을 MTD라고 부릅니다. RTO는 그 안에서 중단된 서비스나 자원을 되살릴 목표입니다. RPO는 어느 시점의 데이터 상태까지 되돌릴 것인지를 나타냅니다. 세 지표의 뜻은 다음과 같습니다.^[1]

실무에서는 목표 RTO에 데이터 재구성과 정합성 확인 시간, 밀린 업무 처리와 정상화 시간을 더한 값이 MTD 이하인지 점검합니다. 이 식은 표준에 정의된 계산 공식이 아니라 RTO를 MTD와 혼동하지 않기 위한 계획용 검증식입니다. 서비스가 기술적으로 켜진 뒤 업무를 정상적으로 수행하기까지 3시간이 더 필요하다면, RTO를 MTD와 같은 값으로 잡아서는 안 됩니다.

RPO가 30분이라는 말은 원칙적으로 최대 30분 전 시점으로 돌아간다는 시간 목표이지, 실제로 몇 건의 주문이나 얼마의 금액을 잃는다는 뜻이 아닙니다. 데이터 변경 속도와 업무 가치가 다르면 같은 30분도 전혀 다른 손실로 이어집니다.^[3]

따라서 RPO를 승인할 때는 시간과 함께 여섯 가지를 적습니다. 해당 시간 동안 예상되는 거래·파일·작업량, 손실될 금액이나 고객 영향, 외부 시스템에서 다시 가져오는지 여부, 로그나 원천 데이터로 재생성하는지 여부, 사람이 다시 입력해야 한다면 필요한 시간과 인원, 그리고 재구성이 불가능한 데이터인지입니다.

MTD

MTD는 업무 프로세스가 멈춘 상태와 그 영향을 조직이 받아들일 수 있는 최대 총시간입니다. 시스템 한 대의 장애 시간이 아닙니다.

RTO

RTO는 중단된 서비스나 자원을 어느 시간 안에 복구할 것인지 정한 목표입니다. 일반적으로 MTD보다 짧아야 합니다.

RPO

RPO는 장애 이전 어느 시점의 데이터 상태까지 되돌릴 것인지를 나타내는 시간 목표입니다. 잃을 건수나 금액을 뜻하지 않습니다.

RTO는 복구 작업 전체의 시간 예산이다

RTO를 현실적으로 정하려면 복구 과정을 하나의 숫자로 뭉치지 말고 시간 예산으로 분해합니다. 장애 탐지, 영향 확인과 복구 선언, 담당자 집결과 권한 확보, 복구 환경 활성화, 데이터 복원 또는 동기화, 의존 서비스 복구, 애플리케이션 기동, 기능·데이터 검증, 트래픽 전환과 사용자 재개의 합이 목표 RTO 이하여야 합니다.

이 역시 특정 표준의 공식이 아니라 공식 지침에 흩어진 복구 단계를 하나의 측정 경로로 모은 것입니다. NIST는 통지, 활성화, 복구, 재구성과 검증을 별도 단계로 다루며 Azure 지침은 사람의 의사결정과 Runbook, 연락 체계, 실제 Failover·Restore 시간을 목표 안에서 검토하도록 합니다.^[1]

RTO 시계의 시작과 종료도 밝혀야 합니다. 이 글에서는 사용자에게 실제 영향이 시작된 시점부터 합의된 최소 복구 상태가 검증된 시점까지를 비즈니스 RTO로 재기를 권합니다. 장애 선언 이후부터 자동화 실행 완료까지만 재면 탐지 지연과 의사결정, 자격 증명 확보, 검증 시간이 숫자 밖으로 빠집니다.

운영 개선을 위해서는 내부 구간도 따로 잽니다. 사용자 영향 시작에서 탐지까지, 탐지에서 장애 선언까지, 선언에서 복구 작업 시작까지, 작업 시작에서 인프라·데이터 복원까지, 복원에서 기능 검증 완료까지, 검증 완료에서 사용자 트래픽 재개까지입니다. 이렇게 해야 어디에 투자하면 RTO가 실제로 줄어드는지 드러납니다. 대기 서버를 추가하는 것보다 선언 권한을 분명히 하거나 자격 증명 접근을 정리하는 편이 더 큰 개선으로 이어지기도 합니다.

RPO는 데이터마다 다르게 정할 수 있다

하나의 서비스에 있는 모든 데이터를 같은 RPO로 보호할 필요는 없습니다. 먼저 데이터를 다섯 갈래로 나눕니다.

AWS Well-Architected는 데이터가 다른 원천에서 다시 만들어지는지, 해당 원천의 RPO는 무엇인지까지 확인하도록 합니다. 재생성 가능한 데이터라면 저장 복제 수준을 낮출 여지가 있습니다. 다만 재생성에 걸리는 시간과 원천 의존성이 RTO와 MTD 안에 들어와야 합니다.^[2]

검색 색인을 모두 잃어도 원본 데이터베이스에서 다시 만든다면 색인 자체의 RPO는 비교적 느슨하게 둡니다. 그러나 재생성에 10시간이 걸리고 검색 기능의 RTO가 2시간이라면 그 설계는 목표를 만족하지 못합니다. 이때 필요한 투자는 데이터 복제일 수도 있고 색인 재생성 속도 개선이나 축소 검색 기능일 수도 있습니다.

의존성의 복구 목표가 서비스보다 느리면 목표를 달성할 수 없다

서비스 복구는 애플리케이션과 데이터베이스만의 문제가 아닙니다. 한 의존성이라도 준비되지 않으면 전체 경로가 멈춥니다. Identity Provider와 관리자 인증, DNS와 네트워크, 인증서와 방화벽 규칙, 암호화 키와 Secret, 메시지 큐와 이벤트 스트림을 확인합니다. 외부 결제·메시징·지도·인증 API, 데이터 공급자, 모니터링과 로그, 배포 도구와 코드 저장소, 고객 안내 채널도 확인합니다. 클라우드·통신사·외부 운영사의 지원, 복구를 승인하고 수행할 사람도 준비돼 있어야 합니다.

AWS와 Azure의 복구 지침은 상·하류 의존성, 인증·네트워크·모니터링, 외부 서비스와 복구 담당자를 함께 확인하도록 합니다. 개별 구성요소의 목표가 전체 서비스 목표와 맞지 않으면 복구 계획은 문서상 숫자에 그칩니다.^[2]

각 Dependency에는 최소한 일곱 항목을 적습니다. Dependency 이름, Owner, 지원하는 업무, 자체 RTO·RPO 또는 복구 약속, 실제 확인된 복구 능력, 대체 경로, 우리 서비스 목표와의 차이입니다.

외부 API가 24시간 안에 복구된다는 조건인데 우리 서비스 RTO를 1시간으로 승인하려면, 그 API 없이도 동작하는 축소 모드나 대체 공급자가 있어야 합니다. 그렇지 않으면 1시간이라는 숫자는 실현 가능한 목표가 아닙니다.

사람과 절차도 복구 아키텍처다

복구 환경이 자동으로 준비돼 있어도 사람이 일곱 질문에 답하지 못하면 RTO는 길어집니다. 누가 재해 상황을 선언하는가. 근무시간 밖에는 누가 결정하는가. 복구 환경의 계정과 키에 접근하는가. 어떤 순서로 서비스를 올리는가. 데이터 충돌이 생기면 누가 기준 상태를 정하는가. 고객과 경영진과 외부 공급자에게 누가 알리는가. Failover 이후 원래 환경으로 돌아가는 조건은 무엇인가입니다.

NIST는 복구 계획에 역할과 연락 체계, 통지, 훈련과 연습을 넣고 실제 테스트로 계획의 결함을 찾도록 합니다. Azure도 Runbook과 의사결정자, 커뮤니케이션 계획과 사람 기반 통제를 복구 능력의 일부로 다룹니다.^[1]

Runbook이나 연락처가 장애가 난 주 시스템 안에만 있다면 실제 재해 중에는 열지 못합니다. 복구 절차와 자격 증명 획득 방법, 담당자 연락처와 상태 공지 수단은 주 장애 도메인과 떨어진 곳에서 접근돼야 합니다.

복구 환경은 ‘존재’보다 ‘현재 상태’를 확인해야 한다

복구용 환경이 만들어져 있다는 사실만으로 쓸 수 있는 상태라고 보지 못합니다. 평소 쓰지 않는 환경에서는 Drift가 생기기 쉽습니다. 애플리케이션 버전 차이, 운영 환경과 다른 설정, 만료된 인증서, 누락된 Secret과 권한, 잘못된 DNS·방화벽 규칙, 부족한 인스턴스·스토리지·API 할당량, 다른 데이터베이스 스키마, 연결되지 않은 로그와 모니터링, 실제 트래픽을 감당하지 못하는 용량입니다.

AWS와 Azure의 현재 지침은 복구 환경의 구성과 데이터 정합성, 할당량, 네트워크·Identity·모니터링과 실제 복구 Drill을 함께 검증하도록 합니다.^[2][5]

복구 환경의 준비 상태는 “있음·없음”보다 다섯 단계로 적는 편이 낫습니다. 코드와 설정으로 재구축 가능, 핵심 기반 환경만 상시 준비, 축소 용량의 대기 환경 준비, 운영 수준의 대기 환경 준비, 여러 환경이 동시에 실제 트래픽 처리입니다. 이 상태는 복구 Pattern을 설명할 뿐 특정 RTO와 자동으로 이어지지 않습니다. 자동화 품질과 데이터 양, 실패 범위, 팀 숙련도에 따라 같은 Pattern에서도 실제 복구 시간은 달라집니다.

Service Recovery Objective Worksheet

다음 워크시트는 서비스별로 RTO·RPO 목표와 투자 근거를 함께 적기 위한 템플릿입니다. 네 블록으로 나뉩니다. 업무와 허용 영향, RTO·RPO와 데이터 재구성, 의존성과 환경·사람·커뮤니케이션, 검증과 투자 결정입니다.

각 서비스의 목표에는 증거 상태를 하나 붙입니다. 추정치를 검증됨으로 보고하지 않습니다. 테스트하지 않은 1시간 RTO는 약속이 아니라 가설입니다.

검증됨

대표적인 장애 범위와 데이터 규모로 전체 경로를 실행했고 목표 안에 복구한 상태입니다.

추정치

설계와 Runbook은 있으나 Dependency를 포함한 전체 복구 Drill이 아직 없는 상태입니다.

미충족

실측 결과가 목표를 넘거나 필요한 복구 경로가 존재하지 않는 상태입니다.

복구 Pattern은 목표 시간에 고정 매핑하지 않는다

복구 환경을 어느 수준까지 미리 준비할지는 네 갈래로 비교합니다. 아래 분류는 Vendor 상품 등급이 아니라 준비 상태를 비교하기 위한 추상화입니다.

공식 클라우드 지침도 사업 목표와 실패 범위, Dependency와 비용을 먼저 확인한 뒤 복구 구조를 고르도록 합니다. Pattern 이름이나 예시 시간은 조직의 자동화 수준과 시스템 구조를 대신하지 못합니다.^[2]

“RTO 1시간이면 무조건 Multi-Region” 같은 규칙은 성립하지 않습니다. 단일 인스턴스 장애만 Scope에 들어가고 환경을 빠르게 재구성한다면 다른 구조로도 목표에 닿습니다. 반대로 리전 전체 상실과 계정 접근 불가, 외부 Identity 장애까지 Scope에 넣는다면 단순한 대기 서버만으로는 모자랍니다. 데이터 손상이나 잘못된 배포처럼 여러 환경에 동시에 영향을 주는 사건도 따로 고려해야 합니다.^[6]

목표 시간 하나가 아키텍처를 정하지 않습니다. 허용 중단·데이터 손실, 다루려는 실패 범위, 데이터와 Dependency 특성, 자동화·사람·절차의 현재 능력, 검증된 복구 결과, 지불 가능한 비용의 조합이 정합니다.

코드로 재구축 후 데이터 복원

장애 전 준비 상태: 운영 외 환경은 거의 없음 / 주요 지연 요인: 자원 생성, 설정, 대용량 데이터 복원, 검증 / 주요 비용·운영 부담: 평상시 자원비는 낮지만 자동화와 복원 속도에 크게 의존 / 적합성을 검토할 조건: 중단 허용 시간이 비교적 길고 환경을 일관되게 재구축할 때

기반 환경 상시 준비 후 확장

장애 전 준비 상태: 네트워크·Identity·핵심 데이터 경로가 준비됨 / 주요 지연 요인: 용량 확장, 애플리케이션 배포, 최신 데이터 적용 / 주요 비용·운영 부담: 기반 자원, Drift 관리, 확장 자동화 / 적합성을 검토할 조건: 일부 기반 요소 준비가 복구 시간을 크게 줄일 때

대기 환경 상시 유지

장애 전 준비 상태: 애플리케이션과 데이터가 축소 또는 운영 수준으로 준비됨 / 주요 지연 요인: 전환 판단, 데이터 수렴, 검증, 트래픽 변경 / 주요 비용·운영 부담: 중복 자원, 지속 동기화, 패치·보안·Drill / 적합성을 검토할 조건: 재구축 시간이 목표의 주요 병목일 때

여러 환경에서 동시 서비스

장애 전 준비 상태: 둘 이상의 환경이 실제 트래픽을 처리함 / 주요 지연 요인: 장애 격리, 쓰기 정합성, 부분 장애 판정 / 주요 비용·운영 부담: 가장 높은 설계·데이터·운영 복잡성, 지속 용량 / 적합성을 검토할 조건: 특정 장애 도메인의 중단을 서비스가 흡수해야 할 때

목표를 강화할수록 무엇에 비용이 드는가

RTO와 RPO가 짧아질수록 비용은 백업 저장공간만 늘어나는 방식으로 커지지 않습니다. 일정 지점을 넘으면 새로운 복구 환경과 지속 복제, 자동화, 인력과 운영 통제가 필요해져 비용이 계단식으로 뜁니다. NIST와 주요 클라우드의 공식 지침도 짧은 목표가 더 높은 비용과 관리 복잡성을 요구하며 조직마다 적정 균형점이 다르다고 설명합니다.^[1]

RTO를 줄이면 다음 항목에 비용이 붙습니다. 미리 준비한 Compute·Network·Database 용량, 환경 생성과 배포 자동화, 설정·Secret·인증서·할당량의 지속 정합성 관리입니다. 나머지는 빠른 장애 탐지와 선언 체계, 근무시간 외 대응 인력, 반복적인 Failover·Failback Drill, Dependency의 더 강한 지원 계약이나 대체 경로, 축소 운영 기능 개발입니다.

RPO를 줄이면 더 잦은 데이터 보호와 로그 보존, 지속 복제와 네트워크 사용량, 쓰기 정합성·중복·순서 문제를 다루는 설계에 비용이 붙습니다. 더 많은 복구 지점과 보존 관리, 데이터 무결성 확인과 Reconciliation, 원천 데이터와 외부 시스템의 보존·재전송 역량에 비용이 붙습니다.

두 목표를 함께 강화하면 빠르게 준비된 환경과 최신 데이터가 동시에 필요해집니다. 여기에 Failover 이후의 정합성, 원래 환경으로 돌아가는 Failback, 여러 환경의 패치와 보안, 지속적인 검증 부담이 더해집니다. 예산 검토에서는 “상위 DR 등급으로 전환”이라고 적기보다 증분 역량을 나란히 비교하는 편이 낫습니다.

먼저 병목을 찾고 그 구간에 투자해야 합니다. 데이터 복원에 20분밖에 걸리지 않는데 장애 선언에 2시간이 걸린다면, 더 비싼 복제 기술만 추가해도 RTO는 거의 줄지 않습니다.

Restore Test는 업무가 다시 가능한지 확인할 때 끝난다

복구 완료 시점을 “인스턴스가 실행 중”이나 “데이터베이스 연결 성공”으로 잡으면 실제 업무 복구 시간보다 짧게 측정됩니다. 복구 검증에는 최소한 열 가지가 들어가야 합니다. 핵심 사용자 흐름의 성공, 데이터 무결성과 기준 시점 확인, 인증·권한과 암호화 키, 외부 Dependency 연결, 충분한 처리 용량입니다. 나머지는 로그·모니터링·알림, 보안 통제, 새 데이터 쓰기와 후속 처리, 고객과 업무 담당자의 Acceptance, 밀린 작업과 데이터 재구성 절차입니다.

NIST는 기능·회귀·데이터 검증이 끝난 뒤 시스템을 복구된 상태로 선언하도록 합니다. Google의 공식 지침도 복원 테스트를 데이터 파일 확인에 한정하지 않고 애플리케이션 스택과 핵심 인프라를 복원된 데이터로 검증하도록 합니다.^[1][3]

백업 생성 기록은 입력 증거일 뿐입니다. RTO와 RPO를 충족했다는 증거는 합의된 장애 범위에서 전체 복구 경로를 실행한 결과입니다.

자주 발생하는 잘못된 판단

여덟 가지가 반복해서 나옵니다. 각 항목은 왜 문제가 되는지와 무엇으로 바꾸는지를 함께 봅니다.

목표는 합의하고, 설계하고, 측정한 뒤 다시 협상한다

RTO와 RPO를 정하는 순서는 이렇습니다. 업무 프로세스와 Owner를 정의합니다. 시간에 따른 중단 영향과 MTD를 확인한 뒤 최소 허용 복구 상태를 정의합니다. 이어 데이터별 RPO와 재구성 가능성을 확인합니다. 그다음 Dependency와 사람, 복구 환경을 넣어 RTO를 분해합니다. 복구 Pattern과 증분 비용을 비교한 뒤 전체 경로를 Drill로 돌리고, 실측 결과와 목표의 차이를 확인해 투자·축소 운영·목표 조정 가운데 하나를 승인합니다.

목표에 닿지 못한다면 선택지는 셋입니다. 복구 환경과 데이터 보호, 자동화, 사람에 더 투자하거나, 핵심 기능만 먼저 살리는 축소 운영이나 수동 대체 절차를 설계하거나, 업무 책임자와 허용 중단·데이터 손실 목표를 다시 협상하는 것입니다. 해서는 안 되는 선택은 검증되지 않은 숫자를 그대로 두는 것입니다.

RTO와 RPO는 짧을수록 좋은 점수가 아닙니다. 업무에 실제로 필요한 수준일 때 유효합니다. Dependency와 사람을 포함한 전체 경로로 검증되고 조직이 그 비용과 잔여 위험을 승인할 때 비로소 복구 목표가 됩니다.