DR Plan과 실운영 DR 훈련은 무엇을 검증해야 하나
DR(Disaster Recovery, 재해복구) 계획은 거의 모든 서비스 조직이 ‘가지고 있다’고 말하지만, 실제로 훈련(drill)을 수행하여 계획이 동작함을 검증한 조직은 많지 않다. 계획서에 적힌 RTO(Recovery Time Objective)와 RPO(Recovery Point Objective)가 실제 훈련에서 달성되지 않으면, 그 계획은 종이 위의 환상에 불과하다.
RTO는 복구 목표 시간, RPO는 허용 가능한 데이터 손실 시점(시간) 기준이다.
DR 문서의 목적은 “참고 문서”가 아니라 “그 문서만으로 실제 복구를 재현하는 실행 기준”이다.
DR를 왜 하는가
- 장애를 “막는 것”만으로는 한계가 있기 때문에, 장애 이후 복구 가능성을 설계해야 한다.
- 매출 손실, 고객 신뢰 하락, 규제 리스크를 줄이기 위해 복구 시간/데이터 손실 허용치를 사전에 합의해야 한다.
- 운영팀/개발팀/비즈니스팀이 같은 기준으로 의사결정할 수 있게 공통 복구 기준이 필요하다.
DR 기본 개념 빠르게 보기
| 항목 | 의미 | 실무 질문 |
|---|---|---|
RTO | 장애 후 서비스 복구까지 허용 시간 | ”몇 시간 안에 다시 주문이 가능해야 하는가?” |
RPO | 허용 가능한 데이터 손실 시점 | ”최대 몇 분/시간치 데이터 손실을 감수할 수 있는가?” |
| Failover | 주 시스템에서 대체 시스템으로 전환 | ”전환 절차를 사람 개입 최소화로 실행 가능한가?” |
| Failback | 주 시스템으로 재복귀 | ”긴급 전환 후 정상 구조로 안전하게 돌아올 수 있는가?” |
일반적으로 쓰는 DR 아키텍처
| 패턴 | 장점 | 한계 | 적합한 상황 |
|---|---|---|---|
| Backup & Restore | 비용이 낮고 단순 | 복구 시간이 길다 | 비핵심 시스템 |
| Warm Standby | 복구 속도와 비용 균형 | 운영 복잡도 증가 | 대부분의 커머스 백엔드 |
| Active-Active | 가용성이 가장 높다 | 비용/운영 난이도 높음 | 초고가용성 핵심 도메인 |
전환기 DR에서 본 서비스 체인 관점
이 체계에서 핵심은 애플리케이션 한 개 복구가 아니라, 주문/결제/조회 경로 전체가 다시 살아나는지 확인하는 것이다. 특히 BLOHA 같은 브리지 구성요소가 포함되면 “글로벌만 복구”로는 실제 고객 경험이 복원되지 않는다.
이 글은 Nike 플랫폼 전환기에서 운영했던 DR Plan과 실제 DR 훈련 경험을 기록한다. 핵심은 단일 서버 복구가 아니라 주문/결제/조회 체인을 목표 RTO/RPO 안에서 복원하는 것이었고, 그 범위에는 BLOHA 같은 브리지 구성요소도 포함됐다. 이 체계는 2021년 운영 안정성·보안 체계를 정비하던 시점부터 시작해 현재까지 연간 DR 계획 업데이트와 훈련으로 계속 운영되고 있다.
ISMS 요구사항도 중요한 배경이었다. 계획만 있고 검증하지 않으면 심사에서 지적을 받을 수 있으므로, 문서 유지와 실제 drill은 한 세트로 운영해야 했다.
DR Plan에 포함되어야 하는 것들
| 구성 항목 | 반드시 적어야 할 내용 | 누락 시 리스크 |
|---|---|---|
| 복구 대상/우선순위 | 시스템 목록, 비즈니스 영향 기준, 복구 순서 | 복구 순서 혼선, 핵심 기능 지연 |
| 목표값 | 시스템별 RTO/RPO | 성공 기준 불명확 |
| 실행 절차 | step-by-step 명령/입력값/검증 기준 | 담당자별 편차, 재현 불가 |
| 책임/연락망 | 역할, 대체 담당자, 연락 채널 | 담당자 부재 시 정지 |
| 데이터 복구 | 백업 위치, 복원 방법, 정합성 확인 방법 | 복원 실패, 데이터 불일치 |
| 사후 검증 | 핵심 시나리오 체크리스트, 실패 기록 방식 | “복구 완료” 오판 |
핵심 원칙은 “플랜에 적힌 내용만으로 복구가 가능해야 한다”이다. 구두 지식이나 특정 개인의 숙련도에 의존하면 DR이 아니라 개인 역량 테스트가 된다.
DR 훈련에서 검증해야 하는 것
복원 가능성 검증
백업 파일이 실제로 복구 가능한지, 복원 절차가 문서대로 실행되는지를 확인한다.
목표값 검증
복구 소요 시간이 RTO 이내인지, 복원 시점이 RPO 이내인지 측정한다.
기능 검증
복원 이후 주문/결제/조회 핵심 흐름이 정상 동작하는지 시나리오로 검증한다.
운영 검증
담당자 교대, 연락망, 의사결정 채널이 훈련 중 실제로 작동하는지 점검한다.
피드백 반영
drill 중 실패·지연 항목을 전수 기록하고 후속 조치와 함께 다음 버전 Plan에 반영한다.
훈련과 실제의 차이 — 무엇이 잘못되었나
| 자주 막히는 지점 | 발생 원인 | 개선 방식 |
|---|---|---|
| 복원 예상 시간 초과 | 절차가 한 줄 요약 수준 | 명령 단위 runbook으로 세분화 |
| 담당자 부재 시 정지 | 개인 암묵지 의존 | 대체 담당자/권한 절차 명시 |
| 검증 누락 | “서비스 뜸”만 확인 | 핵심 비즈니스 시나리오 체크 추가 |
| 연락 지연 | 채널/연락처 최신화 실패 | 훈련 전 연락망 리허설 |
실제 drill 중 플랜대로 진행했는데 막히는 지점이 나오면 예외 처리로 넘기지 않고 전부 기록했다. 이후 액션 아이템으로 원인 제거와 문서 보완을 수행하고, 다음 훈련 전에 DR Plan을 업데이트했다.
Failover 절차와 데이터 정합성
Failover(장애 전환)는 주 시스템에서 보조 시스템으로 서비스를 전환하는 것이다. DR 훈련에서는 이 failover가 실제로 동작하는지, 전환 후 보조 시스템이 정상적으로 서비스를 제공하는지를 검증해야 한다.
Failover 후 데이터 정합성(data consistency)도 검증 항목이다. 주 시스템의 데이터와 보조 시스템의 데이터가 동기화되어 있어야 하는데, 비동기 복제(asynchronous replication)를 사용하는 경우 failover 시점에 일부 데이터가 보조 시스템에 반영되지 않았을 수 있다. 이 데이터 손실량이 RPO 이내인지를 확인해야 한다.
커뮤니케이션 체인 검증
DR 상황에서는 기술 복구와 동시에 커뮤니케이션 체인을 검증해야 한다.
- 누가 재해 상황을 선언하는지
- 어떤 채널로 팀을 소집하는지
- 외부 이해관계자(경영진/고객/파트너)에게 어떤 순서로 알리는지
- 복구 진행 상황을 어떤 주기로 공유하는지
DR 훈련의 비용과 효과
DR 훈련은 비용이 든다. 참여 인원의 시간, 테스트 환경 구축 비용, 실서비스에 영향을 줄 수 있는 위험 등이 비용이다. 하지만 이 비용은 실제 재해 상황에서 복구에 실패했을 때의 비용에 비하면 미미하다. 서비스가 몇 시간 또는 며칠 중단되었을 때의 매출 손실, 고객 이탈, 브랜드 손상을 생각하면 DR 훈련은 보험과 같다.
운영 안정성과 보안은 개별 도구의 문제가 아니라 개발 흐름과 운영 기준을 바꾸는 구조적 작업이었다. 다음 글에서는 2021 - 취약점 점검과 pen test 대응은 왜 상시 체계여야 하나를 통해 이 흐름을 계속 좁혀 본다.
DR 설계의 장단점
DR 체계의 장점은 장애 상황에서 판단 속도를 높인다는 점이다. 복구 순서, 역할, 검증 기준이 문서화돼 있으면 위기 상황에서도 우선순위를 빠르게 정할 수 있다. 특히 훈련을 병행하면 문서와 실제 실행 간의 간극을 줄일 수 있다.
단점은 유지 비용이 크다는 점이다. 정기 훈련, 환경 유지, 시나리오 업데이트가 필요하고, 평상시에는 투자 대비 효과가 작아 보일 수 있다. 그러나 실제 장애가 발생했을 때 이 비용은 복구 실패 비용보다 훨씬 작다.
DR 훈련 검증 항목
- RTO/RPO 목표가 실제 복구 절차에서 달성 가능한지 측정한다.
- 백업 복원본으로 실제 서비스 기동과 핵심 데이터 조회를 검증한다.
- 장애 커뮤니케이션 채널/연락망의 실효성을 훈련 중 점검한다.
- 역할 분담(지휘/복구/검증)의 병목 구간을 훈련 로그로 기록한다.
- 플랜 단계만으로 복구 가능한지 점검하고, 문서 외 의존(구두 지식/개인 노하우)을 제거한다.
- drill 중 실패·지연 항목을 전수 기록해 후속 조치 및 다음 버전 DR Plan에 반영한다.
DR 훈련의 완료 기준은 문서를 읽는 것이 아니라, DR Plan에 적힌 절차만으로 실제 복구를 수행해 RTO/RPO 목표를 달성하고, 훈련 중 발견된 실패·지연 항목을 기록해 다음 버전 Plan에 반영하는 것이다.