재해복구 계획을 훈련으로 확인하는 방법

재해복구 계획을 작성하는 것과 그 절차로 서비스를 복구해 보는 것은 달랐습니다. 계획에는 한 줄인 작업도 실제로 진행하면 백업을 찾고, 접근 권한을 확인하고, 복원한 데이터와 서비스의 상태를 검증해야 했습니다.

운영 중에는 DR 계획을 정기적으로 갱신하고 훈련을 진행했습니다. 이 글은 당시 DR 업무와 플랫폼 전환 이후의 확인 범위를 함께 정리한 기록입니다.

복구 범위와 순서

DR 계획에는 복구할 시스템과 우선순위, 실행 절차, 담당자와 연락 경로, 백업·복원 방법, 복구 뒤 확인할 기능을 정리했습니다.

서비스의 업무상 중요도와 기술적인 복구 순서를 함께 봐야 합니다. 주문·결제 기능을 먼저 복구하고 싶더라도 그 기능이 사용하는 저장소와 인증·외부 연동이 준비돼야 동작할 수 있습니다.

플랫폼 전환 뒤에는 과거 주문을 조회하는 BLOHA 같은 연결 서비스도 확인 범위에 포함됐습니다. 새 플랫폼의 화면이 열리는지 외에, 이전 시스템에 남은 주문을 실제로 조회할 수 있는지도 봐야 했습니다.

RTO와 RPO

복구 목표는 서비스의 영향과 데이터 처리 특성에 맞춰 정합니다.

목표값과 훈련 결과는 구분해서 남겨야 합니다. 서버가 켜진 시각과 사용자가 필요한 기능을 다시 사용할 수 있게 된 시각도 다를 수 있습니다.

백업 복원과 기능 확인

백업 작업의 성공 기록만으로 복원을 확인할 수는 없습니다. 실제로 읽을 수 있는 백업인지, 복원에 필요한 암호화 키와 접근 권한이 준비돼 있는지, 실행 절차가 현재 환경과 맞는지 확인해야 합니다.

복원한 뒤에는 서비스 기동과 데이터 상태를 봅니다. 주문 조회나 필요한 후속 처리 등 복구 범위로 정한 시나리오가 동작해야 합니다. 백업 시점에 없던 변경분을 어떻게 처리할지도 확인할 항목입니다.

복제본으로 전환하는 구성이라면 복제 지연과 전환 시점의 데이터 차이를 살펴봐야 합니다. 백업 복원과 대기 시스템 전환은 서로 다른 복구 방법이므로, 실제 구성에 맞는 절차로 훈련해야 합니다.

담당자와 연락 경로

계획을 작성한 사람만 실행할 수 있는 절차라면 담당자가 없을 때 막힐 수 있습니다. 대체 담당자가 필요한 권한과 도구에 접근하고, 문서의 입력값과 확인 기준을 따라갈 수 있는지도 봐야 했습니다.

재해 상황을 누가 판단하고, 어느 경로로 담당자를 모으며, 진행 상황을 누구에게 알릴지도 훈련에 포함됩니다. 연락처나 권한이 오래된 상태로 남아 있으면 기술적인 복구 작업을 시작하기 전부터 시간이 걸릴 수 있습니다.

훈련 결과의 반영

훈련 중에 막히거나 예상보다 오래 걸린 항목은 기록하고 후속 조치로 연결했습니다. 명령이 바뀌었는지, 접근이 준비되지 않았는지, 기능 확인 기준이 모호했는지에 따라 보완할 대상도 달랐습니다.

훈련을 한 번 끝낸 것과 복구 목표를 달성한 것은 별도입니다. 목표를 맞추지 못한 결과도 남겨야 다음 훈련에서 개선 여부를 확인할 수 있습니다. 계획을 갱신할 때는 문장을 고친 것뿐 아니라, 문제가 됐던 절차가 다시 실행되는지 확인할 필요가 있었습니다.

다음 글에서는 취약점 점검과 침투 테스트 결과를 수정으로 연결하는 과정을 다룹니다.

참고 자료

• AWS Well-Architected: 재해복구 목표와 RTO·RPO