국가정보자원관리원 공주센터의 본래 목적은 “데이터는 다중화하고, 전환은 자동화하며, 운영은 상시화”하여 국가 디지털 서비스의 연속성을 지키는 데 있다는 점입니다.
<<목차>>
1. 국가정보자원관리원 공주센터의 탄생 배경
2. 지연의 역사: 착공부터 건축 완료까지의 우여곡절
3. 설계 의도: ‘트윈’ 백업과 초탄성 시나리오
4. 현 상황 점검: 왜 즉각적 대체가 어려웠나
5. 기술적 교훈: 배터리, UPS 아키텍처, 집중 리스크
결론
이번 사태는 ‘시설이 서 있다’와 ‘운영이 준비됐다’의 간극, ‘데이터 백업’과 ‘서비스 복구’의 간극을 동시에 드러냈습니다. 공주의 임무는 단순 보관소가 아니라, 자동화된 전환 절차와 인력 숙련이 결합된 실전형 복원력 허브를 구현하는 것입니다. 예산·조달·훈련이 뒤따라야만, 다음 사고에서 시민이 체감하는 중단 시간을 분·시간 단위로 줄일 수 있습니다. 또한 전력·배터리 계통의 안전 표준과 소방 대응 매뉴얼을 선진화해, 화재가 서비스 전국 중단으로 비화하는 사슬을 끊어야 합니다. 분산과 표준화, 그리고 투명한 지표 관리가 핵심 열쇠입니다. 결국 ‘재난에도 행정은 멈추지 않는다’는 약속을 기술과 거버넌스로 증명해야 합니다.
근거1. 국가정보자원관리원 공주센터의 탄생 배경
국가정보자원관리원 공주센터는 대전·광주·대구 거점을 보완하고 전국 행정업무의 연속성을 보장하기 위한 재난복구(Disaster Recovery) 전용 센터로 기획되었습니다. 정부는 2008년 중기계획에서 비상 상황에 대비한 전용 백업 시설의 필요성을 천명했고, 이후 여러 차례 설계·입지·예산 검토를 거쳤습니다. 2019년 행정안전부와 관리원이 착공을 공식화했으며, 목표는 원본 센터 장애 시 핵심 시스템을 신속히 대체·복구하는 체계를 갖추는 것이었습니다. 설계 철학에는 화생방(CBRN) 대응, 내진, 물리·환경적 격리, 장기 정전·통신두절 대비 같은 극한 시나리오가 반영되었습니다. 또한 데이터 이중화와 주기적 모의훈련을 통해 목표복구시점(RPO)과 목표복구시간(RTO)을 관리하는 것이 기본 축으로 제시되었습니다. 즉, 본원과 동일한 품질의 서비스 연속성을 지방 거점과 함께 떠받치는 하이엔드 DR 허브로 자리매김하려 했던 것입니다.
근거2. 지연의 역사: 착공부터 건축 완료까지의 우여곡절
현실은 순탄치 않았습니다. 입찰 방식 변경과 공사비 증액, 적정성 재검토, 감리비 부족 등의 사유로 일정이 반복 지연되었습니다. 계획 수립 후 상당 기간이 흐른 뒤에야 2019년에 착공했고, 건물 자체의 준공은 2023년 5월에야 마무리되었습니다. 그러나 건물이 서는 것과 ‘전산환경 구축’은 별개의 과업이라, 핵심 인프라 설치·통합·검증 예산 집행이 지체되었습니다. 2024년에 전산환경 구축 예산이 편성되었으나 연내 집행이 지연되었고, 2025년도 예산안에서는 감액 편성이 이루어졌다는 지적이 제기되었습니다. 이런 맥락은 “종이 위의 대비”와 “실전 용도의 대비”가 얼마나 다를 수 있는지 보여줍니다. 결과적으로 물리 인프라 완공 이후에도 운영 개시는 더디게 흘렀습니다.
근거3. 설계 의도: ‘트윈’ 백업과 초탄성 시나리오
이 거점의 핵심 역할은 다른 센터들에 장애가 발생해도 데이터 보호와 서비스 재가동을 가능하게 하는 이른바 ‘트윈’ 백업입니다. 전쟁·재난·사이버공격 같은 복합 재해에 대비해 구조적으로 강화된 내진 설계와 차폐, 장기 단전 대비, 독립된 통신 경로 등이 고려되었습니다. 또한 주 센터의 원본과 동일한 수준으로 복제본을 보관·검증하고, 정기·수시 백업 및 복구 리허설을 통해 전환 절차를 숙달하는 것이 목표였습니다. 이러한 특수 설계는 단일 장애 지점(SPoF) 위험을 낮추고, 다중 거점 간 역할 분산을 전제로 합니다. 실제로 운영이 본격화되면 다른 권역 센터들과의 상호검증, 교차 전환, 격년 단위의 풀스케일 복구훈련 같은 체계가 필요합니다. 결국 설계 의도는 ‘극한 상황에서도 행정은 멈추지 않는다’는 약속을 기술과 절차로 구체화하는 데 있습니다.
근거4. 현 상황 점검: 왜 즉각적 대체가 어려웠나
최근 위기 국면에서 공주 거점은 주·월 단위 데이터 백업 중심으로 운영되어, 시스템 단위의 즉각 전환까지는 미치지 못했다는 현장 증언이 나왔습니다. 다시 말해 데이터 복제는 있었지만, 애플리케이션·네트워크·보안정책·계정체계까지 포함한 ‘엔드 투 엔드’ 전환 시나리오가 완비되지 않았던 것입니다. 복구 개시 이후 엿새째에 이르러서야 약 99개 시스템이 복구되는 등 속도는 제한적이었습니다. 기획 의도대로라면 장애 발생 시 서비스 셋을 단계적으로 끌어올릴 플레이북과 자동·반자동 오케스트레이션이 준비되어야 합니다. 또한 인력·예산·조달 절차의 선제적 집행과 정례 점검이 뒷받침되지 않으면, 실제 사고에서는 ‘계획된 복원력’이 ‘종이 위의 복원력’에 머물기 쉽습니다. 이번 사례는 “백업 존재=즉시 복구 가능”이 아님을 분명히 보여주었습니다.
근거5. 기술적 교훈: 배터리, UPS 아키텍처, 집중 리스크
화재 원인으로 지목된 배터리 모듈 이슈는 대규모 UPS 설계·운영에서 화재 억제와 격리, 수평·수직 확산 차단이 얼마나 중요한지를 드러냈습니다. 단순 랙 기반 UPS 대비 ESS 수준의 화재 억제 기능, 열폭주 차단 설비, 배터리 이송·정지 절차의 세이프가드가 기준화되어야 한다는 지적이 나왔습니다. 또한 1,600여 정부 시스템 중 647개가 특정 거점에 집중되면서, 단일 사고가 국가 디지털 서비스의 대면 기능까지 마비시킨 ‘집중 리스크’가 현실화되었습니다. 클라우드 스토리지(G-Drive) 파괴와 개별 업무 파일의 광범위한 손실은, 데이터 계층의 다중화와 오프사이트·오프라인 백업 필요성을 재확인시켰습니다. 더불어 침수(수중) 방식 등 비상 진화 전술의 한계와 부작용, 장시간 정전에 대비한 절차적 대응의 표준화 문제도 드러났습니다. 결론적으로 전력·냉각·네트워크·어플리케이션 계층 전반의 ‘다층 방호’가 필수이며, 특히 배터리와 전력 계통의 안전 표준을 고도화해야 합니다.
마치며
2025년 9월 26일 대전 본원 데이터센터 화재로 647개 정부 온라인 시스템이 동시 중단되면서, 재난복구 인프라의 현실 점검이 불가피해졌습니다. 화재는 리튬이온 배터리에서 시작되어 수백 개 모듈로 확산했고, 진화에만 약 22시간이 소요되었다는 보도가 잇따랐습니다. 이 여파로 공공문서 저장소(G-Drive) 등 핵심 업무 파일이 소실되어 75만 명의 공무원이 사용하던 자료 일부가 사라졌다는 발표가 있었습니다. 사흘~엿새 사이 복구된 시스템 수는 수십~약 100개 수준으로 알려졌고, 대민 서비스 전반의 연속성이 흔들렸습니다. 이러한 사태는 “최후의 보루”로 기획된 재난복구 전용 거점의 준비 상태가 충분했는지 근본적 질문을 던집니다. 그리고 바로 이 지점에서 공주의 역할과 과제가 선명하게 드러납니다.
※주의 ※
현재 "국가정보자원관리원" 와 관련하여 방대한 내용과 정보가 존재하여 하나의 포스팅에 담지 못하고 있습니다.
이와 관련하여 더 많은 정보를 일목요연하게 보고 싶으신 분은 여기에서 모든 정보를 보실 수 있습니다.