백업은 있는데 복구가 늦다면? RPO·RTO로 정할 운영 기준

오늘의 인사이트 요약

• RPO는 감수할 데이터 손실의 시간 범위, RTO는 허용할 서비스 중단 시간의 목표입니다.

• 백업 성공 여부와 실제로 업무를 재개할 수 있는지는 따로 확인합니다.

• 업무별 목표를 정하고 복원 테스트에서 데이터와 이용 흐름을 함께 검증합니다.

백업이 정상적으로 저장됐다는 알림을 받아도 장애가 났을 때 언제 서비스를 다시 열 수 있는지는 분명하지 않을 수 있습니다. 마지막으로 복원할 데이터가 언제의 것인지도 별개의 질문입니다. RPO와 RTO는 이 두 문제를 나눠 이야기하는 기준입니다. 오늘은 두 용어의 차이와 서비스 운영에서 확인할 내용을 알아보겠습니다.

1. RPO와 RTO는 무엇이 다를까?

RPO는 복구할 때 감수할 데이터 손실의 시간 범위입니다. 장애가 발생한 시점에서 얼마나 이전의 데이터까지 되돌아가도 업무상 허용할 수 있는지 정합니다. 데이터 몇 건이 사라져도 되는지를 직접 나타내는 값은 아니므로, 같은 시간이라도 업무와 처리량에 따라 영향은 달라집니다.

RTO는 서비스가 중단되면 언제까지 다시 이용할 수 있어야 하는지 정하는 복구 시간 목표입니다. 데이터 사본을 준비하는 것만으로 끝나지 않고, 실제 서비스를 재개할 상태까지 복구하는 시간을 봅니다. AWS는 두 목표를 데이터 손실의 허용 범위와 서비스 중단의 허용 시간으로 구분합니다. 정의와 관계는 AWS의 재해 복구 설명에서 살펴보실 수 있습니다.

같은 장애를 서로 다른 방향으로 보는 기준

가상의 서비스에서 오후 3시에 장애가 났고 마지막으로 복원 가능한 데이터가 오후 2시 50분의 것이라고 해보겠습니다. 되돌아갈 데이터 시점과 장애 사이에는 10분의 차이가 있습니다. RPO를 5분으로 정했다면 이 복구 시점은 목표에 미치지 못합니다. 이 숫자는 개념을 설명하는 가정이며 권장 기준이 아닙니다.

서비스를 오후 3시 30분에 다시 열었다면 중단 시간은 30분입니다. 이 시간은 데이터 시점의 차이와 구분해 RTO 목표에 대조합니다. 빨리 재개했어도 데이터가 너무 오래됐다면 문제가 남고, 최신 데이터가 있어도 서비스를 오래 열지 못했다면 다른 문제가 남습니다.

2. 백업 주기만 확인하면 충분할까?

백업을 자주 만들면 복구할 시점을 더 촘촘히 확보하는 데 도움이 됩니다. 다만 설정한 주기와 사용 가능한 복원 시점이 항상 같다고 가정하면 안 됩니다. 작업이 실패했거나 사본이 손상됐거나 복원에 필요한 파일이 빠지면 가장 최근 백업을 사용하지 못할 수 있습니다.

서비스가 재개되려면 데이터 외에도 애플리케이션과 실행 환경이 맞아야 합니다. 서버 설정, 인증 정보, 저장 파일, 외부 연동 등 무엇이 필요한지 확인합니다. 데이터베이스 복원 완료 알림이 떴다는 이유만으로 로그인과 조회·저장이 모두 정상이라고 판단하지 않습니다.

복제와 과거 시점 복원은 역할이 다릅니다

다른 서버에 데이터를 복제해 두면 서버 장애 때 이용할 사본을 확보할 수 있습니다. 하지만 잘못된 수정이나 삭제가 복제됐다면 오류 이전의 상태를 되찾는 데는 별도 복구 방법이 필요합니다. 백업·복제·특정 시점 복원 중 어떤 조합을 쓸지는 장애 유형과 데이터의 특성을 함께 보고 정합니다.

목표가 짧을수록 추가 자원과 자동화, 훈련에 드는 비용과 운영 부담도 검토합니다. 모든 기능에 같은 목표를 넣기보다 중단됐을 때의 영향을 구분하는 편이 현실적입니다. 업무 요구에 맞춰 복구 목표와 대응 방식을 연결하는 원칙은 AWS의 재해 복구 설계 안내를 참고해 보세요.

3. 복원 테스트에서는 무엇을 확인할까?

복원 테스트는 백업 파일이 있다는 확인에서 멈추지 않고 다시 읽고 사용할 수 있는지 살펴보는 과정입니다. 운영과 분리한 환경에 복원해 영향을 피하고, 데이터가 누락되거나 손상되지 않았는지 확인합니다. 조회만 되고 첨부 파일은 열리지 않는 식의 문제도 업무 흐름에 따라 찾아봅니다.

소요 시간을 기록할 때는 복원 명령을 누른 시각만 쓰지 말고 중단부터 이용 재개까지의 범위를 분명히 합니다. 담당자에게 연락하고 접근 권한을 확보하는 과정, 환경 준비와 검증도 실제 대응에서는 시간을 씁니다. 데이터 복구 작업이 빠르더라도 다른 절차가 오래 걸리면 서비스 전체의 목표를 넘길 수 있습니다.

목표와 실제 결과를 나눠 남기기

목표값과 테스트에서 측정한 값은 구분합니다. 원하는 복구 시간을 문서에 적었다는 사실이 그 시간 안에 복구된다는 증거는 아닙니다. 사용한 백업 시점과 복원 결과, 전체 소요 시간, 막힌 절차를 함께 남겨 다음 점검에서 개선됐는지 확인합니다.

복원 뒤 데이터를 실제로 조회하고 무결성과 목표 시간을 확인하는 항목은 AWS의 백업 복원 검증 지침에서 더 구체적으로 볼 수 있습니다. 데이터 복원 절차를 문서화하고 담당자가 수행하도록 준비하는 방법은 Google Cloud의 데이터 손실 복구 테스트 안내도 참고해 보세요. 서비스가 바뀌면 복구 절차와 목표의 적합성도 다시 살펴봅니다.

구축 이후 운영까지 고려해 서비스 계획하기

똑똑한개발자는 프로덕트 기획·디자인·개발·운영 경험을 바탕으로 서비스를 구축합니다. 아래 소개서 장표는 AX 시스템 구축 이후 활용 교육과 운영 관리까지 이어가려는 방향을 담고 있습니다. 교육 협업은 추진 중이고 운영 자동화는 향후 계획·초기 파일럿 단계로 구분되며, 복구 시간의 달성을 입증하는 자료는 아닙니다.

서비스 구축과 운영에서 확인할 범위를 함께 정리하고 싶다면 아래 똑똑한개발자 링크로 이야기 나눠주세요! 감사합니다.