2025년 9월 26일 오후 8시 20분경, 국가정보자원관리원 대전센터 5층 전산실에서 화재가 발생했다.
2014년 설치된 무정전전원장치(UPS) 리튬이온 배터리를 지하로 이전하는 작업 중 발생한 불은 배터리 팩 384개를 전소시켰고, 큰 불길은 약 10시간여 만에 잡혔으며 완전 진화는 약 22시간 후였다.
전산실 내부 온도는 보도에 따르면 약 160℃까지 올라갔다고 한다.
초기 647개로 집계됐던 장애 시스템은 관제 시스템(nTOPS) 일부 복구 후 709개로 정정됐다.
정부24, 모바일 신분증은 일부 기능, 우체국 금융 등 주요 대민 서비스가 동시에 중단됐다.
이 가운데 대전 본원 5층 7-1 전산실에서 운용되던 G-드라이브(G-Drive)는 전소로 사실상 복구 불가로 확인됐다. 해당 저장소에 있던 다수의 업무 자료는 회수가 불가능하다.
처음에는 대수롭지 않은 화재로 여겼다.
한 상면(Floor) 정도에 피해가 가고, 그 상면의 시스템만 영향받는 정도로 생각했다.
그러나 이후 보도를 통해 대전 센터 전체 시스템이 치명적 타격을 입었다는 사실을 알게 됐다.
사태의 심각성을 다시 인식하게 된 순간이었다.
이전 2023년 행정망 마비 사태 때 행정망 마비 사태에 대한 문제점과 개선 방안에 대한 기고를 한 매체에 한 적이 있었는데 설마 그것 이상의 심각성을 가질까.. 하는 안일한 생각을 가졌었다.
개인적으로 느끼는 더 큰 우려는 2023년 행정망 사태보다 몇 배나 심각한 상황임에도 이에 대한 사회적 관심도가 현저히 낮다는 점이었다. 내란 청산, 외교 현안 등 굵직한 정치적 이슈에 묻혀 국가 디지털 인프라의 취약성은 피상적으로만 다뤄지고 있다. 이 글을 쓰는 이유다.
화재 발생 21일이 지난 10월 17일 현재, 복구율은 50.4%다. 709개 시스템 중 357개가 정상화됐고, 352개 시스템은 여전히 중단 상태다.
정부가 제시한 단계별 복구 목표(10월 말·11월 중 일부)는 불투명하다.
복구 작업 일주일째인 10월 3일, 국가전산망 장애 업무를 총괄하던 행정안전부 디지털정부혁신실 소속 서기관이 정부세종청사에서 극단적 선택을 했다.
이 사태는 단순 화재가 아니다.
재해복구(DR) 시스템이 작동하지 않았고, 복구를 지휘해야 할 관제 시스템 nTOPS도 함께 무너졌다.
설계된 안전망은 있었지만, 결정적 순간에 하나도 기능하지 않았다.
이 사태는 충분히 예측 가능했다. 2023년 11월 17일, 라우터 포트 불량으로 추정되는 장애로 새올행정시스템과 정부 24를 포함한 189개 행정정보시스템이 사흘간 마비됐다.
당시 정부는 대국민 사과와 함께 "이중화 운영 체계 구축"과 "재해복구시스템 보강"을 약속했다.
그러나 약속은 이행되지 않았다. 2024년 1월 31일, 행정안전부는 '디지털 행정서비스 국민신뢰 제고 대책'을 발표하며 1·2등급 정보시스템 전반에 재해복구시스템을 구축하겠다고 밝혔다.
이후 실제 예산·지침 단계에서는 실시간 동기화 방식의 효과성에 문제를 제기하는 취지의 방침이 공유됐다는 지적이 있었다.
결과적으로 2025년도 예산 편성에서 신규 재해복구시스템 구축 요구는 한 건도 없었다.
2023년 행정망 마비 사태 이후 2년도 채 안 되는 시점에서 더 큰 재난이 왔다.
이번에는 화재라는 물리적 재앙이었고, 피해 시스템은 189개에서 709개로 3.75배 증가했다.
복구 시간도 3일에서 21일이 넘도록 진행 중이며, 여전히 절반만 복구된 상태로 파악되고 있다.
2023년 사태는 연일 언론 톱뉴스를 장식하며 장관 사퇴 압박까지 이어졌다.
그러나 이번 사태는 내란 청산, 외교 현안 등 정치적 이슈에 묻혀 상대적으로 주목받지 못하고 있다.
더 심각한 재난이고, 더 큰 구조적 문제를 드러냈음에도, 논의는 피상적이고 대책은 미온적이다.
화재 자체를 비판하는 것은 공정하지 않다. 데이터센터 화재는 드물지만 발생한다.
2021년 3월 10일, 프랑스 스트라스부르의 OVHcloud 데이터센터에서 UPS 관련 화재가 발생해 SBG2 건물을 완전히 소실시키고 인접한 SBG1에도 피해를 입혔다. 화재는 전력실에서 시작됐고, 100명의 소방관과 44대의 소방차가 6시간 동안 진화 작업을 벌였다.
그러나 OVHcloud는 즉시 고객들에게 재해복구 계획 발동을 권고했고, 유럽 내 15개 데이터센터의 여유 용량을 활용해 복구 작업을 시작했다. 화재 발생 한 달 뒤, 공개 클라우드 VM의 80%, 베어메탈 서비스의 25%가 복구됐다. 문제는 자동 소화 시스템 부재, 목재 천장 사용, 자연 환기 방식으로 인한 화재 확산 등 설계 결함이 드러났다는 점이다. OVHcloud는 이후 전사적 개선 작업에 착수했고, 140명 이상의 고객이 제기한 1,000만 유로 규모의 집단 소송에 직면했다.
데이터센터 화재는 발생할 수 있다. 문제는 대응이다. OVHcloud는 화재 직후 즉각 대응했고, 고객 커뮤니케이션을 유지했으며, 대체 용량을 제공했다. 반면 우리는 21일이 지나도록 절반만 복구했고, 담당 공무원 한 명이 목숨을 잃었다.
더 심각한 문제는 같은 실패가 반복되고 있다는 점이다.
리튬이온 배터리의 '열 폭주(Thermal Runaway)' 특성을 과소평가했다.
2014년 설치된 11년 된 배터리는 성능보증기간(10년)을 넘겼지만, 2025년 6월 점검에서 "이상 없음" 판정을 받았다. 배터리와 서버 간 거리는 보도에 따르면 약 60cm였고, 일반 가스소화설비로는 진압이 어려운 리튬 화재를 막을 대책이 없었다. (서버 간 간격 1.2m 수치는 공식 자료 확인 전이라 판단을 일단 보류한다.)
더 근본적인 문제는 대전 센터의 태생적 한계다.
대전 센터는 2005년 옛 KT 전화국(또는 연구시설) 건물을 리모델링해 데이터센터로 전용했다.
이후 건립된 광주, 대구 센터와는 데이터센터의 설계 기준과 안전 등급이 다르다.
전화국을 데이터센터로 개조한 구조는 현대적 데이터센터가 갖춰야 할 화재 구획(Fire Compartment), 내화 구조, 소화 시스템, 공조 설비 등의 요구사항을 충분히 충족하지 못한다는 지적이 있었다.
국가정보자원관리원 3개 센터는 소방 특별점검 제외 논란이 있었고, 2024년 5월 화재 안전 조사에서 대전 본원의 2~5층 전산실과 보안 구역은 "소화가스가 터질 우려"를 이유로 조사에서 제외됐다는 보도가 있었다.
위험을 알면서도 점검하지 않았고, 개선하지 않았다.
아이러니하게도 이 사고는 2022년 SK C&C 판교 데이터센터 화재를 교훈 삼아, 배터리를 서버에서 분리하려던 바로 그 작업 중에 발생했다.
위험을 알고 있었고, 위험을 제거하려 했지만, 그 과정에서 더 큰 재난을 만들었다.
사기업 데이터센터 화재의 문제를 예방하기 위한 조치는 발동되었으나 정작 정부와 공공 부문의 문제 예방을 위한 사전적 조치는 없었다.
이번 화재의 근본 원인은 노후화된 건물 구조와 부적절한 설계에서 기인한 바가 있다.
복구의 두뇌인 nTOPS가 동일 센터 내에 있어 함께 무너졌다.
단일 장애점(Single Point of Failure)이었던 것이다.
공주 DR센터는 존재했지만 자동 전환(Failover)되지 않았다.
2022년 강동석 당시 국가정보자원관리원장은 "재해복구시스템은 실시간 백업된 자료로 3시간 이내 복구 가능"하다고 공언했다. 실전 전환 훈련은 확인되지 않았다는 지적이 뒤따랐다.
800여 명의 인력을 투입하고도 복구는 더뎠다. 9월 28일 네트워크 장비 재가동률 50%, 9월 30일 복구율 14%, 10월 4일 20%, 10월 6일 24%, 10월 17일 50.4%. 공식 브리핑 시점에 따라 수치는 다소 차이가 난다. 직접 피해를 받은 96개 시스템을 대구 센터로 이전하는 데만 4주가 걸릴 것으로 예상된다.
안전망은 있었지만 작동하지 않았다.
nTOPS의 성격과 CMDB의 역할
- nTOPS는 단순 모니터링이 아니라, CMDB(Configuration Management Database)를 포함한 통합 운영·관제(ITSM) 시스템이다.
- CMDB는 다음 정보를 단일 사실원천(Single Source of Truth)으로 묶는다
즉, 자산 목록(서버·네트워크·저장장치·전원), 서비스-시스템 의존관계(Topology/Service Map), 운영 매뉴얼·런북, 소유 부서·담당자 연락망, RTO(Recovery Time objective, 복구시간목표)/RPO(Recovery Point Objective, 복구지점목표)·우선순위, 변경 이력(Change History), DR 매핑과 전환 절차를 포함한다.
- 대규모 장애 시, CMDB는 영향도 분석(Impact Analysis), 복구 순서 결정(서비스 우선순위), 의존성 기반 전환(Dependency-aware Failover), 용량·대체 경로 배정의 근거가 된다.
- CMDB가 멈추면, 복구는 자산·의존관계가 보이지 않는 상태에서 수작업 추정과 개인 기억에 의존하게 된다. 이는 복구 지연·오판·중복 작업으로 직결된다.
운영 상의 필수 조건
- CMDB는 별도 리전의 읽기 전용 재해 복구 시스템(Read-only DR)을 상시 유지해야 한다. 스냅샷 주기화(예: 시간·일 단위), 자동 탐지(Discovery)·관제(Observability)와의 연동으로 최신성을 담보한다.
- 관제·CMDB를 동일 실패영역(Failure Domain)에 두는 설계는 구조적 결함이다. 최소 2개 리전 분산과 정기 복원 훈련(게임데이)이 필요하다.
시설(전기·소방)과 시스템(서버·애플리케이션) 관리 주체가 달라 통합 대응이 불가능했다.
앞서 언급한 소방 특별점검 제외 논란과 2024년 5월 조사 제외 보도는 제도적 공백을 시사한다.
DR 구축 예산은 2025년 24억 원 규모의 ‘실증’ 사업에 그쳤다.
액티브-액티브(Active-Active) 방식의 완전한 이중화가 아닌, 일부 시스템을 시험하는 수준이었다.
2023년 국가행정망 전산마비 사태 이후 정부는 이 시스템 도입을 약속했으나, 실제로는 컨설팅을 마치고 실증 사업 수준에 머물렀다.
감사원은 2025년 9월 29일, 2023년 전산망 마비 당시 노후장비 관리 부실을 이미 확인했음에도 재발 방지 방안을 마련하지 못했다고 지적했다.
위험은 식별됐지만, 예산은 배정되지 않았고, 훈련은 실시되지 않았다.
그리고 위험의 가장 친한 친구인 재난이 찾아왔다.
이 사태를 반복하지 않기 위한 대책은 명확하다. 단, 실행이 문제다.
급진적 목표보다는 실행 가능한 단계적 접근이 필요하다.
노후 인프라 전수조사 및 라이프사이클 관리 체계 구축
이번 사고의 직접 원인은 11년 된 UPS 배터리였다. 그러나 문제는 UPS만이 아니다.
내용연한에 도달한 모든 인프라 - UPS, 네트워크 장비, 서버, 스토리지, 공조 설비, 소방 설비 - 를 긴급 점검하고 교체 우선순위를 결정해야 한다.
민간에서는 서버나 네트워크 장비의 평균 내용연한을 5~7년으로 정하고, 내용연한이 다가오기 전 미리 장비 교체 계획을 수립한다. 정부도 동일한 기준을 적용해야 한다.
11년 된 배터리가 "이상 없음" 판정을 받는 체계 자체가 문제다.
일회성 점검으로 끝나서는 안 된다.
모든 핵심 인프라에 대한 라이프사이클 관리 체계를 구축해야 한다.
도입 시기, 내용 연한, 점검 이력, 교체 계획을 체계적으로 관리하고, 내용 연한 1년 전부터 예산을 확보하여 서비스 중단 없이 교체할 수 있어야 한다.
이를 위해서는 관점의 근본적 전환이 필요하다. IT 인프라를 '소모되는 비용'이 아닌 '유지해야 할 자산'의 관점으로 바라봐야 한다.
당연히 예산은 더 소요된다. 하지만 이것은 비용이 아니라 투자다.
노후 인프라를 방치하다 재난이 오면 복구 비용은 물론, 국가 신뢰도 손실, 업무 마비로 인한 사회적 비용까지 감안하면 예방적 투자가 훨씬 경제적이다.
공주 DR센터 실질적 작동 검증
공주 DR센터가 존재하지만 이번 사태에서 작동하지 않았다.
데이터 백업만 있고 애플리케이션이 작동하지 않으면 아무 소용이 없다.
DR이 "있다"는 것과 "작동한다"는 것은 완전히 다른 문제다.
즉시 실제 전환 테스트를 실시하고, 미작동 원인을 규명하며, 자동 Failover 체계를 구축해야 한다.
nTOPS의 물리적 분리
관제 시스템을 재난 현장과 다른 리전에 이중화하여 단일 장애점을 제거한다.
복구의 두뇌가 재난 현장과 함께 무너지는 구조는 설계 결함이다.
서버존-UPS존 물리적 격리 설계 및 착수
배터리와 서버를 완전히 분리하는 구조 개선 작업에 착수해야 한다.
보도에 나온 60cm 수준의 이격은 화재 확산을 막을 수 없다. 대전, 광주, 대구 3개 센터 모두에 대한 물리적 격리 설계를 완료하고 단계적 시공에 들어가야 한다.
리튬 배터리 전용 소화시스템 도입
일반 가스소화설비로는 진압이 불가능한 리튬 화재에 대응할 수 있는 전용 소화 체계를 구축한다.
리튬이온 배터리 화재는 손상된 배터리가 단시간에 섭씨 1,000도까지 치솟는 '열 폭주'로 발생하며, 물리적 냉각·침수 등 특화 대응이 요구된다.
국가정보자원관리원 3개 센터의 소방 안전관리 체계 전면 재점검이 필요하다.
분기별 'DR 게임데이'와 'BCP 시뮬레이션' 제도화
실제 트래픽을 전환하는 DR 훈련을 의무화해야 한다.
한 번도 실제로 전환해보지 않은 DR은 재난 시 작동을 보장할 수 없다.
2022년 "3시간 내 복구" 공언이 무색하게 실전 전환 훈련은 확인되지 않았다는 점이 이를 증명한다.
그러나 DR 게임데이만으로는 충분하지 않다.
시스템이 복구되어도 업무 프로세스가 작동하지 않으면 무용지물이다.
BCP(Business Continuity Plan, 업무 연속성 계획) 시뮬레이션을 통해 재난 상황에서의 의사결정 체계, 담당자 연락망, 부처 간 협조 체계, 대국민 커뮤니케이션 프로토콜을 실제로 작동시켜봐야 한다.
이번 사태에서 800명을 투입했지만 복구가 더딘 이유 중 하나는 명확한 BCP 실행 체계의 부재 때문이다.
DR은 기술의 문제고, BCP는 조직의 문제다.
둘 다 훈련하지 않으면 재난 시 작동하지 않는다.
국가 전산망 거버넌스 조직 신설
현재 문제의 근본은 컨트롤 타워의 부재다.
시설(전기·소방)과 시스템(서버·애플리케이션) 관리 주체가 분절되어 있고, 전체를 조망하며 정책을 수립하고 실행할 조직이 없다.
단순 BCP/DR 관리를 넘어, 국가 행정망 전체의 아키텍처를 설계하고, 시스템 등급별 인프라 전략을 수립하며, 예산과 평가 체계를 관리할 수 있는 전담 거버넌스 조직이 필요하다.
이 조직은 IT 전담 공무원으로 구성되어야 하며, 기존 조직에 부가된 업무가 아닌 국가 전산망만을 전담해야 한다.
시스템 평가, 모니터링, 신규 시스템의 기능적(애플리케이션)/비기능적(인프라 및 보안) 요구사항 및 구조(아키텍처) 설계, 그리고 무엇보다 재난 대응과 회복 탄력성 확보를 총괄할 수 있어야 한다.
시스템 등급별 차별화된 인프라 전략 수립
현재 정부 시스템은 중요도에 따라 1~4등급으로 분류된다. 그러나 모든 시스템에 동일한 인프라 전략을 적용하는 것은 비효율적이다.
1등급 핵심 시스템은 Active-Active 구조로 실시간 이중화하고, 2등급은 Active-Standby로 신속 전환 가능한 구조를, 3~4등급은 정부 보안 규격을 충족하는 민간 클라우드 활용을 적극 검토해야 한다.
특히 4등급 시스템의 경우 민간 클라우드를 활용하면 재난 시 복구 시간을 대폭 단축할 수 있다.
이번 사태에서 96개 시스템을 대구 센터로 이전하는 데 4주가 소요될 것으로 예상되는데, 사전에 민간 클라우드와 협약을 맺어두면 수일 내 복구가 가능할 것이다.
시스템 등급별 차별화 전략은 자원의 효율적 배분과 신속한 복구를 동시에 가능하게 한다.
핵심 시스템의 분산 배치
현재 대전 본원에 709개 시스템이 집중 배치되어 있다. 한 센터의 물리적 재난이 전체 시스템을 무력화시키는 구조다.
1~2등급 핵심 시스템을 대전, 광주, 대구에 분산 배치하고, 각 센터가 다른 센터의 백업 역할을 할 수 있도록 재설계해야 한다. 이는 단순 데이터 백업이 아닌, 서비스 연속성을 보장하는 Active-Active 또는 Active-Standby 구조를 의미한다.
재발 방지와 회복 탄력성 체계 구축
포스트모템의 본질은 사고 원인 분석을 통한 재발 방지와 회복 탄력성(Resilience) 확보다.
이번 사고의 직접 원인인 노후 UPS 배터리 관리 실패는 재발해서는 안 된다.
하지만 동시에 인정해야 할 사실이 있다.
완벽한 재발 방지는 불가능하다. 예상치 못한 재난은 언제든 발생할 수 있다.
따라서 더 중요한 것은 회복 탄력성(Resilience)이다.
사고가 발생하더라도 피해를 최소화하고, 신속하게 서비스를 재개할 수 있는 체계를 구축해야 한다.
이를 위해 아래의 요건이 필요하다.
- 정기적 재난 시나리오 훈련: 분기별 DR 게임데이를 통해 실제 전환 훈련을 반복한다.
훈련하지 않은 재해복구 계획은 계획일 뿐이다.
- 복구 시간 목표(RTO) 명확화: 시스템 등급별로 복구 시간 목표를 설정하고, 이를 달성하지 못하면 책임을 묻는다.
- 사고 대응 프로토콜 표준화: 재난 발생 시 누가, 무엇을, 언제, 어떻게 할지 명확한 프로토콜을 수립하고 정기적으로 업데이트한다.
- 포스트모템 문화 정착: 사고 발생 시 책임 공방이 아닌, 원인 분석과 개선에 집중하는 문화를 만든다.
이번 사고 역시 이 포스트모템을 통해 구체적 개선안이 도출되고 실행되어야 한다.
OVHcloud는 화재 직후 고객에게 즉시 DR 계획 발동을 권고했고, 유럽 내 15개 데이터센터의 여유 용량을 활용해 한 달 내 공개 클라우드 VM의 80%를 복구했다. 우리는 21일이 지나도 50%만 복구했다. 차이는 회복 탄력성이다.
통합 BCP/DR 관리 조직 신설
시설과 시스템의 분절된 관리 체계를 통합한다. 국가 행정망의 전체 아키텍처를 설계하고, 기능별 시스템을 설계할 수 있는 IT 전담 공무원 조직 설립을 고려해야 한다. 기존 조직 활용이 아닌, 국가 전산망만 전담할 수 있는 별도 조직이 필요하다.
BCP/DR을 법적 의무로 격상
업무 연속성 계획(Business Continuity Plan)과 재해복구를 선택이 아닌 의무로 만든다.
미이행 시 예산 삭감이라는 강력한 페널티를 부여해야 한다.
현재는 "당장 문제없는" 항목이 평가에서 후순위로 밀린다. 사고가 나기 전까지는 비용으로만 취급된다.
UPS를 ‘국가 정보자산’으로 회계 처리하자는 뜻이 아니다. 설비는 설비대로, 데이터·서비스는 그 성격대로 관리해야 한다. 목표는 분개 변경이 아니라 계획된 교체·갱신이 가능한 수명주기 예산 체계다.
- 설비 본체(UPS 정류기·인버터·스위치기어, 발전기, 냉각·소화, 서버·스토리지·네트워크): CAPEX로 취득·감가상각, 운영·정비는 OPEX. 장비군별 교체 로드맵(5~10년)을 고정 캘린더로 운용해야 한다.
- 교체성 부품(배터리 팩 등): 교체충당금 또는 OPEX로 주기 교체(4~7년). SoH(State of Health)·내부저항·온도 이력을 KPI로 관리해야 한다.
- 소프트웨어·라이선스/SaaS: 서비스 성격에 맞춰 OPEX(구독) 중심으로 보안·업그레이드 주기를 계약에 내재화 해야한다.
- 데이터·DR/백업·소버린 클라우드: 회계상 자산이 아니라 정책·거버넌스 대상이다. 가용성·RTO/RPO·게임데이 비용을 상시 OPEX 예산으로 확보해야 한다.
관리 지표는 단순 예산 집행이 아니라 상태와 리스크를 본다.
- Asset Age Profile(평균 장비 연령), Replacement Backlog(교체 적체), 배터리 SoH 열화 추세, DR 게임데이 성공률, RTO/RPO 달성률.
- 교체가 밀린 지점에서 사고가 난다. 교체 적체 금액을 정례 보고항목으로 만들어야 한다.
요점은 간단하다.
설비는 CAPEX/OPEX로, 부품은 교체충당금으로, DR·백업·클라우드는 상시 서비스 예산으로. 이 구조가 없으면, 다시 같은 이유로 멈춘다.
예방적 투자 평가 KPI 도입
현재 평가 체계는 '사고가 나지 않았다'를 성과로 인정하지 않는다.
그러나 단순히 사고 발생 여부만을 평가 지표로 삼는 것은 또 다른 문제를 낳는다.
운 좋게 사고가 나지 않은 것도 성과가 되고, 문제를 은폐하거나 소극적으로 관리하는 유인이 생긴다.
중요한 것은 사고가 나지 않도록 제대로된 예방 활동의 수행여부이다.
평가해야 할 것은 결과가 아니라 프로세스다.
구체적인 예방 활동 KPI는 다음과 같다:
- 장비 교체 로드맵 준수율: 내용연한 도래 장비의 계획된 교체 실행률
- 노후 인프라 비율: 전체 장비 중 내용연한(7년) 초과 장비 비율을 10% 이하로 유지
- 배터리 건강도(SoH) 측정 주기 준수: 분기별 측정 및 이력 관리 실시율
- DR 게임데이 실시: 분기별 실제 전환 훈련 실시 여부 (연 4회 필수)
- BCP 시뮬레이션: 연 2회 이상 전 부처 참여 시뮬레이션 실시
- 취약점 발견 및 조치율: 헬스체크를 통해 발견된 취약점의 90일 내 조치 완료율
- 예방적 투자 예산 집행률: 승인된 노후 장비 교체 예산의 연내 집행률
이러한 지표들은 사고 발생 전에 측정 가능하고, 지속적인 개선을 유도하며, 조직이 실제로 예방 활동에 투자하고 있는지를 평가한다.
'사고가 나지 않았다'는 이러한 활동의 결과일 뿐, 그 자체가 평가 대상이 되어서는 안 된다.
이 글은 총론이다.
앞으로 이어질 시리즈에서는 리튬 배터리 열 폭주의 기술적 메커니즘, nTOPS와 DR의 운영 설계 원칙, 그리고 OVHcloud 화재 같은 해외 사례 비교를 통해 구체적 청사진을 제시할 것이다.
이 포스트모템의 목적은 과거를 비난하는 것이 아니다.
두 번 다시 같은 실패를 반복하지 않기 위해, 무엇이 잘못됐고 무엇을 바꿔야 하는지 냉정하게 기록하는 것이다.
장애는 발생할 수 있다.
문제는 대응이고, 재발 방지다.
국가 디지털 인프라의 심장은 다시 뛰기 시작했다.
하지만 절반만 뛰고 있고, 언제 다시 멈출지 모른다. 이제 우리가 답해야 할 질문은 하나다.
"다음번에는 멈추지 않을 것인가?"
독자분들께 이런 요청을 하지 않지만...
이 글이 매우 중요한 내용을 담고 있다고 생각하시면 주변에 많이 알려주시기 바랍니다.
IT 시스템의 구축/운영 전문가로서 이번 사고는 반드시 다시 점검하고 체계를 갖추는 것이 대한민국 전체로 매우 중요한 일이라 생각하기 때문입니다.