‘백업은 매일 됩니다’라는 답을 들었는데도 장애 날 새벽에 복구가 멈추는 경우가 있다. 데이터베이스 파일은 있지만 업로드 파일이 없거나, 복원된 서버가 옛 설정을 읽거나, 서비스는 켜졌지만 로그인과 주문 조회가 실패한다. 백업 작업의 성공은 복구 가능성의 증거가 아니다. 복구된 서비스로 실제 업무를 다시 할 수 있어야 백업이 목적을 달성한 것이다.
AWS Well-Architected의 백업 지침도 데이터·애플리케이션·설정을 보호하고 정기적으로 복원해 무결성과 절차를 확인하도록 권한다. 특정 클라우드를 쓰지 않아도 원칙은 같다. 이번 글은 웹서비스나 사내 업무 시스템에서 복구 연습을 처음 설계할 때의 순서를 다룬다.
복구 목표는 IT팀이 숫자부터 정하지 않는다
RPO(복구 시점 목표)는 사고 직전부터 어느 시점의 데이터까지 되돌아가도 업무가 감당할 수 있는지를 뜻한다. RTO(복구 시간 목표)는 중단 후 언제까지 서비스를 다시 사용할 수 있어야 하는지를 뜻한다. AWS의 복구 목표 설명은 두 목표를 업무 영향에 따라 정하고 기술 전략을 선택할 기준으로 사용한다. ‘한 시간마다 백업하니 RPO는 한 시간’이라고 단정하기도 이르다. 실제 백업 완료 시각, 복제 지연, 손상 발견 시점에 따라 마지막으로 신뢰할 수 있는 복구점이 달라진다.
업무 담당자에게 먼저 물어야 한다. 접수된 고객 요청 몇 건을 다시 받아야 하는가? 주문과 결제 사이 상태를 재구성할 수 있는가? 서비스가 멈춘 동안 수기로 처리할 수 있는가? 같은 시스템 안에서도 고객 게시판과 결제 승인 작업은 허용 손실이 다르다. 목표를 정한 뒤 백업 주기, 보관 위치, 대기 환경, 수동 운영 절차의 비용을 비교해야 한다.
복원 대상은 데이터베이스 하나가 아니다
복구할 시스템을 구성하는 목록을 만든다. 데이터베이스, 사용자가 올린 파일, 애플리케이션 코드와 의존성, 배포 설정, 도메인·인증서, 외부 연동 정보, 암호화 키의 복구 경로가 서로 맞아야 한다. 키 자체를 평문으로 백업하라는 뜻은 아니다. 필요한 권한과 복구 절차가 장애 시에도 작동하는지 확인하라는 뜻이다. 비밀번호 재설정 메일이나 결제 웹훅처럼 외부 시스템과 이어지는 업무는 복구 후 중복 처리·누락 위험도 검토한다.
파일과 DB의 시점이 어긋나면 게시물에는 첨부 URL이 있는데 실제 파일은 없을 수 있다. 반대로 파일만 남고 DB 참조가 사라질 수도 있다. 그래서 ‘무엇을 어느 순서로 복원하는가’가 문서화돼야 한다. 준비물 목록이 빠졌다면 복구 담당자의 기억에 의존하게 된다.
사고 유형도 나눠 본다. 서버가 사라진 경우에는 새 환경을 빠르게 세우는 것이 중요하지만, 관리자가 잘못 삭제한 경우에는 모든 데이터를 통째로 어제 시점으로 되돌리면 다른 고객의 정상 작업까지 잃는다. 악성 변경이 늦게 발견된 경우 가장 최근 백업도 이미 오염됐을 수 있다. 전체 복구, 특정 데이터 복원, 특정 시점 복원 중 어느 경로가 필요한지에 따라 백업 보관과 연습 내용이 달라진다. 복구 목표는 장애 시나리오별로 검토해야 한다.
복구 리허설은 격리된 환경에서 처음부터 끝까지
연습은 운영 환경을 건드리지 않는 별도 공간에서 시작한다. 먼저 복구 대상과 사용 가능한 백업의 시각을 기록한다. 그다음 새 환경에 인프라와 앱을 만들고, 데이터와 파일을 복원하고, 비밀정보와 외부 연동을 안전한 시험용으로 연결한다. 실제 고객에게 메일이 가거나 결제 요청이 나가지 않게 차단한 상태에서 사용자 시나리오를 실행한다. 로그인, 검색, 주요 화면, 파일 다운로드, 관리자 기능을 차례로 확인하고 발견한 결함을 기록한다.
시간 측정은 ‘복원 명령 실행’만 재지 않는다. 장애 인지, 의사결정, 접근 권한 확보, 복구 대상 선택, 검증, 서비스 전환까지 포함해야 실제 RTO를 알 수 있다. RPO도 복원된 데이터에서 가장 최신의 정상 거래나 문의가 어디까지 있는지 조회해 확인한다. AWS의 주기적 복구 시험 지침은 복원 결과의 사용 가능성과 목표 충족을 시험하라고 설명한다.
연습 후에는 런북을 고친다
복구 리허설에서 사람이 헤맨 순간이 다음 개선 항목이다. 누가 복구를 선언하는지, 어떤 백업을 고를지, 누가 외부 연동을 다시 켤지, 고객에게 언제 공지할지 런북에 적는다. 단순히 ‘복구 성공’이라고 남기지 말고 걸린 시간, 데이터 공백, 실패한 점검, 수동 조치, 재시험 날짜를 기록한다. 서비스 구조가 바뀔 때마다 백업 대상과 복구 절차도 함께 바뀌어야 한다.
복원 결과가 정상이라고 판단할 기준을 연습 전에 합의한다. 앱이 HTTP 200을 돌려주는 것만으로는 부족하다. 관리자와 일반 사용자가 로그인할 수 있고, 최근 데이터의 범위가 예상과 같고, 첨부를 열 수 있으며, 주요 쓰기 작업이 시험 환경에서 성공해야 한다. 이 확인이 끝난 뒤에야 외부 연동을 되살리고 트래픽을 돌리는 순서를 정한다. 검증되지 않은 복구본을 급히 공개하면 장애를 한 번 더 겪을 수 있다.
첫 복구 연습 체크리스트
- 업무 기준으로 RPO와 RTO를 정했는가?
- DB, 파일, 앱, 설정, 인증·외부 연동을 목록화했는가?
- 운영과 분리된 환경에서 복원했는가?
- 실제 사용자 업무를 끝까지 시험했는가?
- 복원 데이터의 시각과 누락 범위를 확인했는가?
- 장애 인지부터 서비스 재개까지 시간을 쟀는가?
- 발견한 공백을 런북과 다음 연습에 반영했는가?
백업은 사고 전에 만드는 파일이고, 복구 능력은 사고 전에 연습해 쌓는 운영 자산이다. 백업 성공 알림보다 복구 리허설의 결과가 서비스를 지킬 수 있는지를 더 잘 말해 준다.
