DR, nTOPS, 그리고 복구 실패의 구조
2025년 9월 26일 저녁 국가정보자원관리원 대전센터 전산실에서 UPS 리튬이온 배터리에서 시작된 화재 이후, 정부24 일부 기능, 모바일 신분증 일부 기능, 우체국 금융 등 대민 서비스와 내부 행정 업무 시스템이 동시에 중단되었다. 초기에는 장애 시스템 수가 647개로 발표됐지만, 이후 관제 시스템(nTOPS) 데이터 일부가 복구되면서 중단된 정보시스템 수가 709개로 정정되었다. 1등급 핵심 시스템, 2등급 중요 시스템을 포함해 정부 행정망의 중추 역할을 하는 서비스들까지 다수 멈췄다.
이 상황은 국가 전산망이 “주센터가 정지해도 백업센터로 전환되어 서비스는 유지된다”는 전제를 현실에서 달성하지 못했다는 것을 의미한다. 행정안전부와 국가정보자원관리원은 과거 여러 차례 “대전센터가 화재나 지진 등으로 한꺼번에 소실돼도 실시간 백업된 자료로 3시간 이내 복구할 수 있다”고 설명해 왔다.
이 발언은 2022년 10월 판교 SK C&C 데이터센터 화재 이후 ‘카카오톡 먹통’ 사태를 점검하는 자리에서도 반복됐다.
하지만 실제 복구는 3시간 단위 대응이 아니라 수일·수주 단위로 진행됐다. 화재 발생 후 1주일 시점인 10월 3일 오후 기준 복구율은 약 17.9%로 집계됐고, 10월 4일에도 복구율은 20% 수준에 머물렀다. 10월 13일에도 전체 복구율은 36.7% 수준으로 발표됐고, 화재 발생 21일이 지난 10월 17일 오후 9시 기준으로도 전체 709개 시스템 중 357개(50.4%)만 정상화된 상태였다.
정부 발표로 보면 대규모 국가 전산망은 “수 시간 내 복구”가 아니라 “수 주 내 절반 정상화, 나머지는 이후 순차 복구”라는 실제 성능을 드러낸 셈이다. 이 괴리는 단순한 지연 문제가 아니라, 재해복구(Disaster Recovery, DR) 체계가 설계 수준에서 약속된 방식대로 동작하지 않았음을 보여준다.
국가정보자원관리원은 대전센터 외에 광주, 대구 센터를 운영해 왔고, 별도로 충남 공주에 ‘재해복구 전용 데이터센터’, 이른바 공주 DR센터(공주 백업센터)를 추진해 왔다.
공주센터는 지하 터널형 구조, EMP(전자기 펄스)·화생방·지진 등에 대비 가능한 고방호 인프라로 설계됐다고 정부는 설명해왔다. 즉, 전통적인 의미의 ‘벙커형’ 예비 거점이다.
문제는 이 시설이 수년 동안 “있다”는 말은 반복됐지만, “운영 중인 세컨더리 센터”로 기능하지 못했다는 점이다. 공주 DR센터는 애초 재해복구 전용 거점으로 2010년대 초반부터 논의돼 왔으나, 예산과 사업 구조 문제로 개소가 반복적으로 지연돼 왔다. 사업자 선정 유찰, 공사 중단, 비용 증액, 계획 변경 등으로 실제 상시 운영 개시는 계속 뒤로 밀렸다. 당초 2012년까지 운영 개시를 목표로 했다는 보도도 있으나, 완공은 2023년 5월에야 이뤄졌고 이후에도 개청은 수차례 미뤄졌다.
특히 2023년 11월 정부 행정망 마비 사태 이후 정부는 공주센터를 단순 백업 저장고가 아니라 액티브-액티브(Active-Active), 즉 주센터와 동시에 돌아가는 ‘동시 운용형’ 재해복구 거점으로 격상시키겠다고 방침을 바꿨다. 액티브-액티브 방식은 어느 한쪽 센터가 내려가도 다른 쪽이 즉시 서비스를 이어받도록 설계하는 구조다. 그러나 이 목표를 반영하면서 센터 개소 일정은 다시 연기됐고, 실제로는 “완전히 가동 중인 세컨더리 서비스 존”으로 전환되지 못한 상태에서 이번 화재를 맞았다.
화재 이후 정부가 선택한 1차 물리적 대책은 “대전센터에서 손상된 시스템 중에서 더 이상 가동이 불가능한 것들을 대구센터로 이전한다”는 방식이었다. 정부 발표에 따르면, 특히 직접 피해를 받은 전산실 구역(대전센터 5층 7-1 상면)에서 운용 중이던 약 96개 시스템은 장비 자체가 전소하거나 고열·그을음·분진으로 훼손돼 대전에서 그대로 복구하기 어렵다고 판단되었고, 이들을 대구센터로 옮기는 작업이 시작되었다. 이 이전은 단순한 ‘장비 이동’이 아니라 사실상 ‘재구축’에 가깝다.
기존 하드웨어를 닦아 다른 랙에 꽂는 수준이 아니라, 대구센터 내에 별도의 민관 협력형 클라우드 존을 마련해 새로운 인프라 위에 해당 업무 시스템을 다시 띄우는 절차다. 정부는 이 작업에 대해 “4주 정도의 복구 목표”를 언급했지만, 동시에 여러 부처와 유관 기관을 물려놓은 복합 시스템은 더 오래 걸릴 수 있다고 설명했다. 즉 현재의 대구 이전은 상시 준비되어 있던 자동 전환 시나리오가 아니라, 화재 이후 긴급하게 가동된 우회 경로다.
이 사실은 곧, 공주 DR센터가 ‘물리적 최후 거점’, 대구센터 내 민관 협력형 클라우드 존이 ‘운영 복구 거점’이라는 이원 구조가 실제로는 아직 제도화된 이중센터 운영 모델이 아니었다는 점을 보여준다.
DR이 선언·계획 단계에서만 존재하고, “주센터가 타격을 받으면 어디로 넘긴다”라는 실행 가능한 운용 플로우(런북)는 완결돼 있지 않았다는 방증이다. 다시 말하면, 방호력은 있었지만 운용력은 준비돼 있지 않았다. 이 간극이 결국 “3시간 내 복구” 약속과 현실 사이의 격차를 만든 직접 요인 중 하나다.
전산 시스템 DR(Disaster Recovery)의 목적은 “백업 데이터를 보관한다”가 아니다. 목적은 “주센터(운영 시스템)가 죽어도 업무가 멈추지 않게 한다”이다. 즉 DR은 단순한 저장소가 아니라 ‘두 번째 운영 시스템’이어야 한다.
이걸 이해하려면 RTO(Recovery Time Objective, 복구 시간 목표)와 RPO(Recovery Point Objective, 복구 지점 목표)라는 두 지표를 봐야 한다. RTO는 서비스가 중단된 순간부터 다시 가동될 때까지 허용 가능한 최대 정지 시간이다. 예를 들어 RTO 3시간이면, 사고가 나도 3시간 안에는 서비스를 다시 열어야 한다는 뜻이다. RPO는 데이터 유실 허용 범위다. RPO 5분이면, 사고가 나도 최대 5분 전 시점까지만 데이터가 사라질 수 있다는 뜻이다.
이 두 지표는 선언만으로 달성되지 않는다. DR센터가 실제로 운영 가능한 형태여야 숫자에 현실성이 생긴다.
여기서 핵심은 DR이 “데이터만 있는 저장소”로는 역할을 못 한다는 점이다. 전자정부 서비스는 단순히 데이터베이스 스냅샷만 있으면 곧바로 복구되는 시스템이 아니다. 민원 접수, 전자결재, 행정 내부 승인 라인, 대국민 인증, 우정·지급 계좌 연계, 부처 간 API 연동 등은 애플리케이션 실행 환경 전체가 따라붙어야 돌아간다. 운영체제(OS) 버전, 미들웨어, 애플리케이션 바이너리, 설정값, 보안정책, 계정/권한 구조, 부처 간 네트워크 라우팅, 방화벽 룰, 공공망 인증 경로까지 그대로 있어야 한다. 그래야 “주센터가 멈췄을 때 DR센터가 바로 이어받아 국민이 계속 쓸 수 있는 시스템”이 된다.
따라서 DR센터는 단순 보관소가 아니라 운영센터의 ‘거의 동일한 복제본(형상 복제)’이어야 하고, 평상시에도 그 상태를 유지하고 있어야 한다. 이건 데이터만 실시간 복제한다고 해결되지 않는다. 서비스 전체의 런타임 환경을 동기화해야 한다.
이 요구를 충족하기 위해 일반적으로 쓰는 모델이 액티브-액티브(Active-Active)와 액티브-스탠바이(Active-Standby)다. 액티브-액티브는 두 리전(센터)이 동시에 실제 트래픽을 처리하고 서로 실시간 복제한다. 어느 한 리전이 물리적으로 손상되면 나머지 리전이 즉각 모든 트래픽을 받아서 다운타임을 분 단위로 줄인다. 여기서 DR센터는 ‘놀고 있는 백업’이 아니라 이미 운영 중인 두 번째 본부다.
액티브-스탠바이는 주센터가 전체 트래픽을 처리하고 DR센터는 평상시 외부 트래픽을 받지 않지만, 운영체제·애플리케이션 스택·네트워크 경로·권한 구조까지 사전 배치된 상태로 대기한다. 데이터는 동기 또는 준동기 복제로 따라붙는다. 사고가 나면 DR센터는 즉시 활성화되어 주센터처럼 동작한다. 이 구조가 제대로 준비돼 있으면 RTO를 “수 시간”으로 설정할 수 있다.
공공 부문에서 반복적으로 나온 “센터가 한꺼번에 소실돼도 실시간 백업된 자료로 3시간 이내 복구 가능하다”는 설명은 사실상 이 시나리오를 전제로 한 말이다. 즉, DR센터가 주센터와 같은 형상으로 준비돼 있고, RTO 목표(3시간)를 충족할 만큼 즉시 인계가 가능하다는 전제였다.
그러나 이번 화재에서는 그 전제가 충족되지 않았다.
실제로는 “백업된 데이터”는 있었지만, DR센터가 주센터와 동일한 애플리케이션/네트워크/권한 구조까지 상시 유지한 ‘두 번째 운영 시스템’으로 준비돼 있지 않았다.
공주 DR센터는 방호력 있는 예비 거점이었지만 실사용 트래픽을 즉시 받아서 민원·인증·지급 업무를 처리하는 운영 리전으로 상시 돌아가고 있지 않았다. 대구센터는 화재 이후에야 급하게 ‘민관 협력형 클라우드 존’을 만들어 96개 핵심 시스템을 재구축하는 형태로 쓰이기 시작했다. 이건 사후 대응이지, 사전에 정의된 페일오버가 아니다.
결과적으로 “DR센터는 있다”라는 말이 실제로 의미하려면, DR센터가 운영센터와 같은 애플리케이션 스택, 네트워크 경로, 권한 체계, 연계 구성을 이미 들고 있고 전환 시 곧바로 그 상태로 올라올 수 있어야 한다. 그래야 국민과 공무원 입장에서는 “끊김이 없었다”고 체감한다. 그게 안 돼 있으면 그건 DR이 아니라 단순 백업창고다. 단순 백업창고만으로는 RTO 3시간 같은 수치를 달성할 수 없다.
이 지점이 이번 사고에서 드러난 본질적 문제다.
복구 과정에서 지적된 핵심 중 하나는 nTOPS였다.
nTOPS는 국가정보자원관리원의 통합운영관리 시스템으로 소개되며, 단순 모니터링 도구가 아니라 CMDB(Configuration Management Database)를 포함한 통합 관제·운영(ITSM) 시스템에 해당한다는 점이 정부 브리핑과 후속 보도에서 확인됐다.
CMDB는 현재 어떤 서버, 어떤 스토리지, 어떤 네트워크 장비가 어떤 서비스에 붙어 있는지, 해당 서비스의 담당 부서는 어디인지, 우선 복구해야 할 순서는 무엇인지, 전환(페일오버) 시 어떤 의존성을 같이 옮겨야 하는지 등 복구의 ‘지도’를 담고 있다. 평시에는 인벤토리 관리처럼 보일 수 있지만, 대규모 장애 시에는 복구 우선순위 결정, 영향도 분석, 부처별 연락·조정, RTO/RPO 준수 여부 판단, DR 전환 절차 실행 순서를 모두 이 시스템에서 뽑는다. 즉 CMDB는 복구의 관제 두뇌다.
문제는 그 두뇌 자체가 동일 실패영역 안에 있었다는 점이다. 대전센터 화재와 함께 nTOPS도 정상 가동되지 못했고, 정부는 초기에 “장애 시스템 수 647개”라고 발표했다가, nTOPS 데이터 일부를 복구한 뒤에서야 실제 영향 범위가 709개라는 사실을 다시 확인하고 정정했다. 이 정정은 10월 9일 브리핑에서 공식화됐다.
이 상황은 복구팀이 재해 직후 몇 시간 안에 “우선순위 A, B, C 시스템은 어디에 있고 어떤 순서로 붙여야 한다”를 자동으로 받아보지 못했다는 것을 의미한다. 다시 말해, 복구는 초반에 체계적 전환이 아니라 수작업에 가까운 탐색과 확인, 물리 장비 회수·청소·이전, 개별 서비스별 재기동 검증이라는 방식으로 흘렀다. 이로 인해 복구 초반 속도는 구조적으로 제한됐다.
운영상으로 보면, 관제·CMDB 시스템은 반드시 다른 리전(예: 공주 DR센터나 별도 상주 리전)에 읽기 전용 복제본 형태로 상시 유지돼야 한다. 그래야 주센터가 불이 나도 복구지휘본부는 온전히 살아 있고, 어떤 시스템을 어디서 어떻게 살릴지, 어느 부처에 어느 순서로 통보할지 즉시 알 수 있다. 이번 사례에서 그 구조는 사실상 부재했다.
복구에는 최대 800여 명 규모의 인력이 투입됐다. 행정안전부와 중앙재난안전대책본부는 추석 연휴 기간을 “복구 골든타임”으로 규정하고, 공무원 약 220명, 상주 사업자 인력 약 570명, 분진 제거·기술 지원 전문 인력 약 30명 등 총 800명 안팎을 현장에 투입했다고 밝혔다.
그럼에도 복구율은 9월 30일 기준 83개 시스템 재가동 수준(일부 1등급 포함), 10월 3일 17.9%, 10월 4일 20% 안팎, 10월 13일 36.7%, 10월 17일 50.4% 등 단계적으로만 올라갔다.
다시 말해 24시간 단위의 기동 반전이 아니라, ‘며칠 단위로 몇 퍼센트 포인트씩’ 움직이는 형태였다.
복구가 이 속도로 갈 수밖에 없는 구조적 이유는 명확하다.
첫째, 주센터 상면 자체가 직접 피해를 입어 하드웨어를 회수해 세척·점검·이전한 다음에야 전원을 넣을 수 있었다. 이 과정은 자동화할 수 없다.
둘째, 서비스별 의존관계 지도 역할을 하는 nTOPS/CMDB가 함께 마비되어 복구 우선순위와 전환 절차를 현장에서 즉시 참조하기 어려웠다.
셋째, 공주 DR센터 등 예비 거점은 “즉시 가동되는 2차 운영 존(Secondary Production Zone)”이 아니었기 때문에, 전환은 곧바로 스위치오버 형태로 일어나지 못했다.
넷째, DR 훈련 자체가 분기 단위로 반복되는 정례 운영 루틴이 아니었기 때문에, 실제 전환을 마치 일상 업무처럼 수행할 수 있는 숙련도가 축적돼 있다고 보기 어려운 상황이었다.
여기에 더해, 대구센터 이전 계획 자체가 복구 조직의 한계를 적나라하게 드러냈다.
DR이 액티브-액티브 형태로 상시 운영됐다면 주센터가 꺼진 직후 트래픽과 업무 처리는 자동 또는 준자동으로 다른 리전에 넘어갔어야 한다. 하지만 실제로는 “대상 시스템 96개를 대구센터에 새로 올린다”는 계획을 화재 이후에 세워서 진행 중인 상태다. 이 ‘이전’은 전자정부 서비스 특성상 단순 서버 부팅으로 끝나지 않는다. 각 시스템은 부처 간 연계 회선, 인증/권한 구조, 결재·처리 플로우, 대국민 포털 연동, 심지어 금융·지급 계정 연결까지 묶여 있기 때문에, 서비스 하나를 다른 센터에서 띄우려면 주변부 행정 로직까지 이식해야 한다. 이건 이미 설계돼 있어야 하는 영역이지, 사고 이후에 수작업으로 재구성할 영역이 아니다.
또한 정부가 설명한 “민관 협력형 클라우드 존”은 평소에 상시 운용되는 정규 세컨더리 존이 아니라, 비상 대응으로 급조된 형태에 가깝다.
즉, 지금 진행 중인 대구 이전은 ‘우리가 준비해둔 DR 전환 절차가 정상 작동했다’는 증거가 아니라, ‘준비해두지 못한 DR을 화재 이후에 현장에서 조립해서 올리는 중’이라는 증거다. 이건 곧 복구 속도가 수 주 단위로 늘어진 구조적 이유이기도 하다.
결국 복구는 “계획된 자동전환”이 아니라 “현장 동원+수작업 복원”이었다. 이 방식은 물리적으로 많은 인력을 투입해도 RTO를 근본적으로 줄이지 못한다.
이번 화재는 공공 부문의 DR·BCP(업무 연속성 계획) 의무가 여전히 선언적이라는 점을 보여줬다.
정부는 2023년 11월 행정 전산망 마비 사태 이후, 2024년 1월 31일 ‘디지털 행정서비스 국민신뢰 제고 대책’을 발표하며 1·2등급 핵심 정보시스템 전반에 재해복구시스템을 구축하고, 이중화·이원화 체계를 단계적으로 확대하겠다고 공언했다.
이 대책은 “상시 장애 예방”, “신속한 대응·복구”, “서비스 안정성 기반 강화”를 핵심 축으로 삼고, 특히 중요도 높은 정보시스템(1·2등급)에 대해 DR과 무중단 체계를 강화하겠다고 제시했다.
그러나 뒤이어 내려간 예산·편성 단계에서는, 일부 부처에 ‘1·2등급 시스템 이중화 신규 구축 투자를 금지한다’는 취지의 지침이 전달됐다는 비판이 국회 측에서 공개됐다. 즉 중앙 차원의 공개 발표와, 실제 예산 기획 라인에서 전달된 메시지가 충돌했다는 지적이다. 그 결과 2025 회계연도 편성 과정에서는 신규 DR 구축 요구가 사실상 반영되지 못한 것으로 보도됐다.
민간 영역과 비교하면 대비된다. 2022년 10월 SK C&C 판교 데이터센터 화재로 카카오 서비스가 수일간 중단된 이후, 이른바 ‘카카오 먹통 방지법’으로 불리는 법·제도 개정이 추진되었다.
이 개정의 흐름은 일정 규모 이상의 부가통신사업자와 집적정보통신시설(대형 데이터센터) 사업자에게까지 재난관리 의무를 확장하고, 데이터센터 이중화·분산, 다중 전력공급, DR 계획 수립과 훈련, 복구·고지 의무 등을 강제하는 방향으로 갔다. 즉 일정 규모 이상 민간 플랫폼과 데이터센터 사업자는 법령으로 이중화와 복구 체계를 갖추도록 관리 대상에 편입됐다.
반면 국가정보자원관리원 대전·광주·대구 센터와 같은 공공 전산센터는 국가 핵심 행정 인프라임에도 불구하고, 동일 수준의 강제적 이중화·DR 의무 규정을 직접적으로 적용받지 않는 구조였다. 공주 DR센터는 수년째 “열릴 예정인” 예비 전산센터였고, 핵심 전자정부 서비스의 무중단 전환을 전제로 한 액티브-액티브 운용까지는 제도화·예산화되지 못했다. 그 결과, 공공 인프라가 민간 플랫폼보다 낮은 법적 복원력 요구치를 가진 역전 현상이 만들어졌다.
운영 관점에서 앞으로 필요한 변화는 “복구를 빨리 하는 조직”이 아니라 “끊기지 않는 조직”으로의 전환이다. 이 전환은 기술적 회복 탄력성과 조직적 회복 탄력성 두 축으로 나뉜다.
기술적 회복 탄력성 측면에서 DR센터(공주 등)는 더 이상 “백업 데이터 보관소”가 아니라 실제 트래픽을 넘길 수 있는 동시 운용 거점이어야 한다. 액티브-액티브 또는 액티브-스탠바이 구조를 시스템 등급별로 명확히 적용하고, RTO·RPO 목표(예: 3시간 복구)를 단순 공언이 아니라 등급별 의무 요건으로 관리해야 한다. 등급이 높은 핵심 시스템일수록 이 요건은 의무화되어야 하며, 이를 위한 네트워크 라우팅, 인증 계층 전환, 전자문서·민원 처리 계정 이관, 결제·지불 계좌 처리, 민원 접수 창구까지 포함한 전체 업무 플로우 단위의 페일오버가 실제로 가능한지 정기적으로 시험해야 한다. 이 시험은 통상 ‘게임데이(game day)’ 훈련으로 불리는 방식, 즉 실제 트래픽 일부 또는 전부를 DR 리전에 붙였다가 원복하는 반복 훈련 형태로 정례화할 수 있다.
화재 이후 행안부가 공주센터를 DR 핵심 거점으로 전환하겠다고 한 이상, 이 거점은 상시로 그 역할을 입증해야 한다.
조직적 회복 탄력성 측면에서 복구의 두뇌 역할을 하는 nTOPS·CMDB는 주센터와 다른 리전에 분산 배치돼야 하고, 재난 상황에서도 읽기 전용이라도 즉시 조회 가능한 상태로 유지돼야 한다.
관제와 CMDB가 동일한 실패영역 안에 있으면, 복구팀은 우선순위가 뭔지조차 모르는 상태에서 장비를 닦고 케이블을 꽂는 상황으로 떨어진다.
이번 화재에서 실제로 nTOPS 데이터가 부분 복구된 뒤에야 전체 영향 시스템 수(709개)가 확정됐다는 점은 복구 지휘 체계가 초기에 마비됐음을 보여준다. 이 구조를 반복하지 않으려면 관제·CMDB의 다중화가 기술 요건이 아니라 필수 운영 요건으로 올라가야 한다.
여기에 한 가지 축이 더 필요하다. 앞으로의 DR은 “공주 DR센터 하나로 충분한가?”라는 질문에서 출발하면 안 된다. 지금 드러난 실제 운영 형태를 기준으로 하면, 공주 DR센터는 고방호·장기 존속형(데이터를 지키는 마지막 금고)에 가깝고, 대구센터는 실제 대민/업무 서비스를 다시 띄울 수 있는 가동형 회복 거점으로 쓰이기 시작했다.
즉 국가 정보자원 관리 구조는 사실상 다중 리전 구조(주 센터 / 가동형 세컨더리 센터 / 장기보존형 백업 센터)로 재정의돼야 한다. 이건 민간에서 이미 표준화된 패턴이다. 대형 클라우드·IDC 사업자는 보통 “운영 리전(즉시 트래픽 수용 가능)”과 “콜드 백업 리전(최후 보존)”을 분리해 설계하고, 여기에 리전 간 실시간 또는 준실시간 복제(액티브-액티브 또는 액티브-스탠바이)를 붙인다.
정부도 같은 모델을 따라야 한다. 공주는 “언제든 잃지 않고 보전해야 할 최종 원장과 핵심 데이터, 장기 보관 자산” 역할, 대구는 “즉각 트래픽을 받아서 업무/민원 처리를 재개할 수 있는 운영 리전” 역할, 그리고 기존 대전 본원은 더 이상 단일 장애점이 아니라 이 세 축 중 하나로 재배치되어야 한다.
이런 구조가 정식 운영모델로 고시되지 않으면, 다음 사고 때도 “백업센터는 있었지만 바로 못 돌렸다”는 같은 보고서가 반복될 수밖에 없다.
이 방향은 단순히 “장비를 더 사라”가 아니다.
회복 탄력성은 인프라 설계, DR 거점의 상시 가동성, CMDB의 다중화, DR 게임데이 훈련, RTO/RPO 준수 모니터링, 그리고 이를 감시하고 책임지는 거버넌스까지 포함한 전 과정의 운영 모델이다.
지금까지 공공 전산망은 이를 “예산이 확보되면 추진할 항목”으로 취급해 왔다. 하지만 화재로 확인된 바와 같이 국가 전산망은 더 이상 개별 부처 전산실의 성격이 아니다. 전 국민이 이용하는 행정 서비스, 금융 서비스, 신분 증빙 서비스가 여기에 올라간다.
결론적으로, 이번 사고는 단순한 장비 고장이 아니라 운영 모델의 실패다.
“3시간 내 복구”라는 선언과 실제 복구 속도의 간극은, DR이 문서상 존재했지만 실행 가능한 상태로 상시 유지되지 않았다는 것을 입증했다. 앞으로의 기준은 선언이 아니라 측정 가능한 RTO/RPO, 운영센터와 동일한 형상을 유지하는 다중 리전(주센터 / 운영형 세컨더리 / 장기보존형 백업), 관제·CMDB의 이중화, 정례화된 전환 훈련, 그리고 이를 의무화하고 점검·평가하는 법적 체계다. 이것이 없다면, 같은 유형의 사고는 다시 발생하고 같은 방식으로 복구될 것이다.