백업과 재해 복구는 비슷해 보이지만 목적이 다릅니다. 백업이 복구에 사용할 데이터 사본을 준비하는 일이라면, 재해 복구는 장애 원인 확인부터 시스템 복원, 데이터 검증, 업무 재개까지의 전체 실행 체계입니다.
📌 핵심 5줄 요약
1. 백업은 데이터를 복사해 보관하는 활동이고, 재해 복구는 장애 후 서비스를 되살리는 운영 계획입니다.
2. RPO는 장애 발생 전 어느 시점까지의 데이터를 복구해야 하는지 정하는 기준입니다.
3. RTO는 시스템이나 업무를 허용 가능한 시간 안에 복구해야 한다는 기준입니다.
4. 복구 시나리오는 랜섬웨어, 서버 장애, 정전, 데이터 손상처럼 상황별로 실행할 절차입니다.
5. 복구 목표는 백업 담당자만 정하는 것이 아니라 업무 중요도와 중단 손실을 기준으로 정해야 합니다.
📌 목차
01 | 백업과 재해 복구의 기본 차이
02 | 백업의 역할과 한계
03 | 재해 복구의 범위
04 | RPO란 무엇인가
05 | RTO란 무엇인가
06 | RPO와 RTO 비교
07 | 복구 시나리오의 의미
08 | 장애 유형별 복구 시나리오
09 | RPO와 RTO를 정하는 방법
10 | 복구 우선순위 정하기
11 | 백업 방식과 저장 위치
12 | 복구 테스트와 검증
13 | 자주 생기는 오해와 주의사항
01 | 백업과 재해 복구의 기본 차이
백업은 파일, 데이터베이스, 가상머신 이미지, 시스템 설정 등을 별도의 저장 위치에 복사하는 작업입니다. 목적은 삭제, 손상, 암호화, 장비 고장 등이 발생했을 때 과거 상태의 데이터를 되돌리는 데 있습니다.
재해 복구는 백업 데이터를 활용해 실제 서비스를 복원하는 전체 과정입니다. 복구 대상에는 데이터뿐 아니라 서버, 네트워크, 애플리케이션, 인증 체계, 운영 담당자, 외부 서비스 연계가 포함될 수 있습니다.
02 | 백업의 역할과 한계
백업은 재해 복구의 중요한 구성 요소지만 백업만으로 복구가 완료되지는 않습니다. 백업 파일이 있어도 복구 서버가 없거나, 복구 권한을 잃었거나, 애플리케이션 설정과 암호화 키가 빠져 있으면 업무 재개가 지연될 수 있습니다.
또한 최근 백업 자체가 랜섬웨어에 의해 암호화되거나 삭제될 수 있습니다. 따라서 백업 성공 여부뿐 아니라 실제 파일을 열 수 있는지, 필요한 시점으로 복원되는지, 운영 환경에서 서비스가 작동하는지까지 확인해야 합니다.
03 | 재해 복구의 범위
재해 복구 계획에는 장애 감지, 영향 판단, 복구 선언, 담당자 연락, 대체 환경 전환, 데이터 복원, 서비스 점검, 업무 재개, 원래 환경으로의 복귀가 포함될 수 있습니다.
NIST는 정보기술 비상계획을 수립할 때 업무 영향 분석, 예방 통제, 복구 전략, 계획서 작성, 테스트·훈련, 유지관리 등을 단계적으로 다루도록 제시합니다. 즉 재해 복구는 백업 제품을 도입하는 프로젝트가 아니라 운영 체계를 설계하고 반복 검증하는 과정입니다.
04 | RPO란 무엇인가
RPO는 Recovery Point Objective의 약자로, 장애가 발생한 뒤 어느 시점까지의 데이터를 복구해야 하는지를 뜻합니다. NIST는 RPO를 장애 또는 중단 이전의 특정 시점까지 데이터를 복구해야 하는 기준으로 설명합니다.
예를 들어 RPO가 4시간이라면 최악의 경우 최근 4시간 동안 입력된 데이터가 사라질 가능성을 감수한다는 의미입니다. RPO는 백업 주기와 직접 연결되지만, 백업 주기가 4시간이라는 사실만으로 실제 RPO 4시간이 보장되는 것은 아닙니다. 복제 지연, 백업 실패, 복구 가능한 시점의 상태를 함께 확인해야 합니다.
05 | RTO란 무엇인가
RTO는 Recovery Time Objective의 약자로, 시스템이나 업무가 중단된 뒤 허용 가능한 시간 안에 복구해야 하는 목표입니다. NIST는 시스템 자원이 지원하는 업무에 unacceptable impact가 발생하기 전까지 허용되는 최대 비가용 시간을 RTO로 설명합니다.
RTO를 정할 때는 단순히 서버가 켜지는 시간을 보지 않습니다. 로그인, 데이터베이스 연결, 외부 연동, 주요 기능 점검, 사용자의 업무 재개까지 포함할지 명확히 정해야 합니다. 복구 완료의 정의가 불분명하면 목표를 달성했는지 판단하기 어렵습니다.
06 | RPO와 RTO 비교
| 구분 | 확인할 내용 |
|---|---|
| RPO | 데이터를 어느 시점까지 복구해야 하는가 |
| RTO | 서비스와 업무를 얼마 안에 복구해야 하는가 |
| 백업과의 관계 | 백업 주기와 복구 가능한 데이터 시점을 결정하는 기준 |
| 재해 복구와의 관계 | 복구 절차, 기술, 인력, 대체 환경을 설계하는 기준 |
| 대표 질문 | 얼마나 잃을 수 있는가, 얼마나 오래 멈출 수 있는가 |
RPO는 데이터 손실 허용 범위에 가깝고, RTO는 서비스 중단 허용 범위에 가깝습니다. 따라서 RPO가 짧아도 복구 절차가 느리면 RTO를 달성하지 못하고, RTO가 짧아도 데이터 복제나 백업이 부족하면 필요한 데이터를 복구하지 못합니다.
07 | 복구 시나리오의 의미
복구 시나리오는 특정 장애가 발생했다는 가정 아래 누가, 무엇을, 어떤 순서로 조치할지를 정리한 실행 문서입니다. 일반적인 선언문보다 실제 명령, 담당자, 연락처, 접근 권한, 복구 순서, 검증 방법이 포함되어야 실효성이 높습니다.
예를 들어 ‘서버 장애에 대응한다’고만 적는 것은 시나리오가 아닙니다. 장애 확인, 영향 범위 기록, 대체 서버 전환, 데이터 복원, 애플리케이션 기동, 주요 기능 테스트, 사용자 공지까지 단계가 구체적으로 이어져야 합니다.
08 | 장애 유형별 복구 시나리오
랜섬웨어 또는 악성코드 감염
감염 의심 장비를 네트워크에서 격리하고 증거와 영향 범위를 보존한 뒤, 감염되지 않은 복구 지점을 선별합니다. 백업을 바로 덮어쓰지 말고 백업 저장소 자체의 감염 여부와 관리자 계정 침해 여부를 먼저 확인해야 합니다.
서버 또는 저장장치 고장
장애 장비를 진단하면서 대체 장비나 예비 환경으로 서비스를 전환합니다. 이후 운영체제, 애플리케이션, 데이터베이스, 설정 파일, 인증서와 키를 정해진 순서로 복구합니다.
데이터베이스 손상 또는 사용자 실수
전체 백업을 복원할지, 특정 시점 복구를 할지, 손상된 일부 데이터를 별도 환경에서 추출할지 판단합니다. 원본에 바로 복원하기보다 별도 공간에서 검증한 후 운영 데이터에 반영하는 방식이 안전합니다.
정전·화재·침수 등 시설 장애
현장 복구가 가능한지 판단하고, 불가능하면 다른 장소나 클라우드 환경으로 업무를 전환합니다. 이때 IT 복구뿐 아니라 직원 연락, 고객 안내, 수기 업무, 외부 공급업체와의 협업도 함께 다뤄야 합니다.
09 | RPO와 RTO를 정하는 방법
먼저 업무 영향 분석을 통해 어떤 업무가 중단되면 손실이 커지는지 확인합니다. 매출, 고객 서비스, 법정 기한, 안전, 계약상 의무, 내부 운영 의존성을 기준으로 업무별 우선순위를 나눕니다.
그다음 업무 담당자에게 두 가지를 질문합니다. 첫째, 데이터는 최대 어느 정도 기간까지 다시 입력하거나 대체할 수 있는가입니다. 둘째, 업무가 최대 얼마 동안 중단되어도 감당할 수 있는가입니다. 첫 번째 답이 RPO 설정에, 두 번째 답이 RTO 설정에 활용됩니다.
목표는 기술 담당자가 임의로 정하기보다 업무 책임자와 합의해야 합니다. 너무 짧은 RPO와 RTO를 설정하면 비용과 운영 복잡도가 커지고, 지나치게 느슨하면 실제 장애 때 손실을 감당하기 어려워집니다.
10 | 복구 우선순위 정하기
모든 시스템을 동시에 복구할 수 없다면 업무 의존성을 기준으로 순서를 정해야 합니다. 일반적으로 인증·네트워크 같은 기반 구성, 데이터베이스와 핵심 저장소, 주요 애플리케이션, 외부 연계, 보고·분석 시스템 순으로 검토합니다.
다만 조직마다 순서는 달라질 수 있습니다. 고객 주문 시스템이 특정 인증 서비스에 의존한다면 인증 체계를 먼저 복구해야 하고, 생산 설비가 별도 제어망을 사용한다면 일반 사무 시스템보다 해당 제어 환경이 우선일 수 있습니다.
11 | 백업 방식과 저장 위치
전체 백업은 복구가 단순한 대신 저장 공간과 시간이 많이 필요할 수 있습니다. 증분 백업은 마지막 백업 이후 변경분만 저장해 효율적이지만, 복원 시 여러 백업 세트가 필요할 수 있습니다. 차등 백업은 마지막 전체 백업 이후 변경분을 누적하는 방식으로, 저장량과 복구 복잡도가 중간에 위치합니다.
저장 위치는 운영 시스템과 물리적으로 분리해야 합니다. 동일한 장비나 동일한 계정에만 백업이 있으면 장비 고장, 계정 탈취, 랜섬웨어, 시설 재해가 백업까지 동시에 영향을 줄 수 있습니다. 오프사이트 저장, 접근 권한 분리, 변경 불가 저장소 등은 위협 모델에 맞춰 검토할 수 있습니다.
12 | 복구 테스트와 검증
백업 성공 알림은 복구 가능성을 의미하지 않습니다. 실제로 파일을 복원하고 데이터베이스를 기동하며 애플리케이션이 정상 작동하는지 확인해야 합니다. NIST 자료도 복구 계획의 테스트와 훈련, 백업 데이터 및 시스템 설정의 검증을 중요한 절차로 다룹니다.
테스트 결과에는 실제 복구에 걸린 시간, 복구된 데이터의 시점, 누락된 설정, 권한 문제, 외부 연계 실패, 담당자 연락 가능 여부를 기록합니다. 테스트에서 RPO와 RTO를 충족하지 못했다면 백업 주기, 복구 인프라, 절차 또는 인력 배치를 수정해야 합니다.
13 | 자주 생기는 오해와 주의사항
백업이 있으면 안전하다는 오해: 백업이 있어도 복구 권한, 암호화 키, 라이선스, 네트워크 설정, 운영 절차가 없으면 서비스를 되살리지 못할 수 있습니다.
RPO와 백업 주기가 같다는 오해: 백업 작업이 실패하거나 저장은 되었지만 복구할 수 없는 상태라면 목표 RPO가 지켜지지 않습니다.
RTO를 서버 부팅 시간으로만 보는 오해: 업무 사용자가 실제로 일을 시작할 수 있는 상태까지의 시간이 기준인지 정해야 합니다.
한 번 만든 계획이면 충분하다는 오해: 시스템 변경, 담당자 변경, 공급업체 변경, 백업 위치 변경이 생기면 복구 계획도 함께 갱신해야 합니다. Ready.gov 역시 IT 복구 계획을 업무연속성 계획과 함께 수립하고, 훈련과 테스트를 준비의 핵심 요소로 안내합니다.
14 | 실무 체크리스트와 적용 순서
처음 구축한다면 다음 순서로 진행하면 됩니다.
1. 핵심 업무와 업무별 담당자를 목록화합니다.
2. 업무별 허용 데이터 손실과 중단 시간을 정해 RPO·RTO를 합의합니다.
3. 필요한 데이터, 시스템 설정, 인증서, 암호화 키, 외부 연계를 식별합니다.
4. 백업 주기와 저장 위치, 접근 권한, 보존 정책을 설계합니다.
5. 랜섬웨어, 장비 장애, 데이터 손상, 시설 재해 등 주요 시나리오를 문서화합니다.
6. 복구 담당자와 대체 담당자를 지정하고 연락 방법을 별도로 보관합니다.
7. 정기적으로 복구 테스트를 실시하고 결과에 따라 계획을 수정합니다.
복구 문서는 운영 중인 시스템과 분리해 보관하되, 장애 상황에서도 승인된 담당자가 접근할 수 있어야 합니다. 계획서 자체가 손상되거나 접근 불가능하면 실제 복구 절차가 시작되기도 전에 지연될 수 있습니다.
☑ 체크리스트
□ 업무별 RPO와 RTO가 문서로 합의되어 있는가
□ 백업 성공 여부가 아니라 실제 복구 가능성을 검증했는가
□ 운영 환경과 백업 저장소의 계정·권한이 분리되어 있는가
□ 랜섬웨어와 계정 탈취를 고려한 복구 지점이 있는가
□ 시스템 설정, 인증서, 암호화 키, 외부 연계 정보가 포함되어 있는가
□ 담당자 부재 시 대체 담당자가 지정되어 있는가
□ 복구 테스트 결과와 개선 사항을 기록하고 있는가
📖 자주하는 질문 Q&A
RPO가 짧을수록 무조건 좋은가요?
아닙니다. RPO가 짧아질수록 더 자주 백업하거나 실시간 복제하는 구조가 필요해질 수 있습니다. 데이터 가치와 재입력 가능성, 비용, 복구 복잡도를 함께 비교해 정해야 합니다.
RTO와 복구 시간은 같은 뜻인가요?
실무에서는 비슷하게 사용되지만 RTO는 목표 기준입니다. 실제 복구 시간은 테스트나 장애 상황에서 측정되는 결과이며, 실제 시간이 RTO보다 길다면 복구 전략을 개선해야 합니다.
개인 사용자도 RPO와 RTO를 정해야 하나요?
정식 용어를 사용하지 않더라도 기준을 정해두면 유용합니다. 예를 들어 사진은 어느 시점까지 잃을 수 있는지, 컴퓨터를 몇 시간 안에 다시 사용해야 하는지를 정하면 백업 주기와 복구 방법을 선택하기 쉬워집니다.
클라우드에 저장하면 재해 복구가 끝난 것인가요?
아닙니다. 클라우드 저장은 저장 위치 중 하나일 뿐입니다. 계정 탈취, 잘못된 삭제, 동기화 오류, 서비스 장애, 복구 권한 문제까지 고려하고 실제 복원 테스트를 해야 합니다.
📝 마무리
백업은 복구에 필요한 데이터를 준비하는 일이고, 재해 복구는 장애 이후 업무를 다시 운영하는 체계입니다. RPO는 허용 가능한 데이터 손실 범위, RTO는 허용 가능한 서비스 중단 시간을 뜻하며, 복구 시나리오는 이를 실제 절차로 구현합니다. 핵심 업무부터 목표를 정하고 백업·복구 테스트까지 반복해야 계획이 실제 장애 대응 능력으로 이어집니다.