데이터센터 한 곳이 불타자 대한민국 행정이 멈췄다 — DR 구축, 이제는 선택이 아니다

들어가며 — 2025년 9월 26일 저녁, 대한민국 행정이 멈췄다(1)

2025년 9월 26일. 대전 유성구 국가정보자원관리원(이하 국정자원) 본원 5층 전산실에서 불이 났다. 원인은 의외로 허무했다. 리튬이온 배터리를 서버실 밖으로 이전하는 작업 중 배터리 하나에서 불꽃이 튀었고, 배터리 열폭주가 시작됐다. 자동소화 설비가 작동했지만 역부족이었다. 화재 확산을 막기 위해 결국 전원이 차단됐고, 그 순간 정부24, 우체국 금융, 모바일 신분증, 국민신문고 등 700여 개 행정 시스템이 일제히 셧다운됐다.

복구에 걸린 시간? 무려 95일이다.

세계 최고 수준의 ‘디지털 플랫폼 정부’를 자처하던 대한민국이, 배터리 하나의 화재에 두 달 넘게 행정 마비 상태를 이어간 것이다.

나는 이 사건을 뉴스로 보면서 솔직히 복잡한 감정이 들었다. 한편으로는 충격이었고, 다른 한편으로는 “그럴 줄 알았다”는 느낌이 공존했다. IT 인프라 프로젝트를 오래 해온 사람이라면 이해할 것이다. 예산 삭감, 형식적인 DR 테스트, 서류상으로만 존재하는 BCP(업무연속성계획) — 이 구조적 문제는 어제오늘의 이야기가 아니다.

이번 포스팅에서는 그 사건을 출발점 삼아, 데이터센터 구축 유형과 재해복구(DR) 전략 전반을 처음부터 체계적으로 정리하고자 한다. 이론만이 아닌, 현장에서 겪어온 맥락을 함께 녹여보겠다.

2. 데이터센터 구축 유형 총정리

데이터센터를 처음 설계하거나 ISP를 수행할 때, 제일 먼저 부딪히는 질문이 있다. “우리는 어떤 형태의 데이터센터를 가져갈 것인가?” 이 질문에 대한 답을 모르고 RFP를 쓰거나 벤더 제안서를 받으면, 나중에 걷잡을 수 없는 방향으로 흘러간다.

2-1. 소유 방식에 따른 분류

① 자체 구축형 (On-Premise IDC)

기업이 직접 부지를 확보하고 전력·냉각·네트워크 인프라를 모두 구축하는 방식이다. 초기 투자 비용이 막대하지만 보안 통제권이 완전히 자사에 있고, 규정 준수 관리에서도 유연하다. 금융권 대형 은행, 통신사, 대기업 계열사 등이 여전히 이 방식을 유지하고 있다.

장점: 최고 수준의 보안·통제, 커스터마이징 자유도 최대
단점: CapEx(자본지출) 부담, 전문 운영 인력 필요, 확장성 제한

② 코로케이션(Co-location, Colo)

기업이 서버 장비를 직접 소유하되, 데이터센터 시설(전력·냉각·회선·보안)은 전문 IDC 사업자에게 임차하는 방식이다. KT IDC, LG U+ IDC, 코스콤 IDC 같은 곳이 대표적이다. 국내 중견기업과 공공기관이 가장 많이 채택하는 유형이기도 하다.

장점: 시설 투자 없이 안정된 인프라 이용, 이중 전원·이중 냉각 등 Tier 보장
단점: 장비 관리 인력은 자체 부담, 이전·확장 시 물리적 제약

③ 매니지드 서비스(Managed Service)

시설과 장비 모두 IDC 사업자가 소유·운영하며, 기업은 서비스 사용료만 지불한다. 서버 구성, OS 관리, 패치, 모니터링까지 IDC 사업자가 담당한다.

④ 퍼블릭 클라우드(Public Cloud)

AWS, Azure, GCP, NCP(Naver Cloud Platform), KT Cloud 같은 클라우드 사업자의 인프라를 필요할 때 빌려 쓰는 방식이다. IaaS/PaaS/SaaS 형태로 제공된다. 최근 공공 부문에서도 G-클라우드(행정·공공기관 전용)와 민간 클라우드를 병행하는 하이브리드 구조가 빠르게 확산 중이다.

⑤ 하이브리드 클라우드(Hybrid Cloud)

온프레미스 또는 프라이빗 클라우드와 퍼블릭 클라우드를 조합하는 방식이다. 민감 데이터는 내부에, 탄력적 워크로드는 클라우드에 — 이 구조가 2025년 현재 엔터프라이즈 표준으로 자리 잡았다.

2-2. Tier 등급 이해 (TIA-942 기준)

데이터센터를 평가할 때 반드시 나오는 개념이 Tier 등급이다. TIA-942(미국 통신산업협회 기준)를 기준으로 4단계로 구분된다.

Tier	가용성	연간 허용 다운타임	이중화 수준	특징
Tier 1	99.671%	28.8시간	단일 경로	단일 전원·냉각, SPOF 존재
Tier 2	99.741%	22.0시간	부분 이중화	일부 구성요소 이중화
Tier 3	99.982%	1.6시간	N+1 이중화	무중단 유지보수 가능
Tier 4	99.995%	26.3분	2N 이중화	완전 이중화, Fault-tolerant

국내 금융권 핵심 전산센터는 대부분 Tier 3~4를 요구한다. 공공 부문은 이번 국정자원 사태 이전까지 Tier 2 수준에 머물러 있는 곳이 상당수였다는 게 업계의 공통된 진단이다.

3. 재해복구(DR) 구축 등급과 핵심 지표 이해

3-1. RTO와 RPO — DR의 두 축

DR 프로젝트를 처음 수행하거나 ISP를 진행할 때 가장 먼저 정의해야 할 개념이 RTO와 RPO다. 이 두 지표를 제대로 정의하지 않으면 DR 전략이 흔들린다.

RTO (Recovery Time Objective, 목표 복구 시간): 재해 발생 이후 서비스를 재개하기까지 허용되는 최대 시간. 예를 들어 “RTO 4시간”이라면, 장애 발생 후 4시간 이내에 서비스가 복구돼야 한다.
RPO (Recovery Point Objective, 목표 복구 시점): 재해 발생 시 허용되는 데이터 손실 범위. “RPO 1시간”이라면, 최대 1시간치 데이터까지는 손실을 감내할 수 있다는 뜻이다.

RTO가 짧을수록, RPO가 0에 가까울수록 구축 비용이 기하급수적으로 올라간다. 이 둘의 조합이 DR 등급을 결정하고, 곧 예산을 결정한다. 발주기관이 “최고 등급으로 해달라”고 말하는 것과 예산이 맞지 않는 경우가 현장에서는 비일비재하다.

3-2. DR 구축 등급 분류 (국내 기준)

국내에서는 행정안전부 지침과 금융감독원 IT 감독 규정 등을 기준으로 DR 등급을 다음과 같이 구분한다.

등급	유형	RTO	RPO	특징
1등급	미러 사이트(Mirror Site)	즉시(0)	0	실시간 양방향 동기화, 글로벌 빅테크·1금융권
2등급	핫 사이트(Hot Site)	4시간 이내	최소화	대기 상태 실시간 미러링, 즉각 전환 가능
3등급	웜 사이트(Warm Site)	수일~수주	수시간~1일	주기적 백업, 인프라 사전 구성
4등급	콜드 사이트(Cold Site)	수주~수개월	최대 수일	데이터만 보관, 복구 시 인프라 신규 구성

이번 국정자원 대전센터 사태는 대부분의 시스템이 3~4등급 수준의 DR 체계를 갖추고 있었던 게 피해를 키웠다. ‘데이터 4중 백업’은 되어 있었지만, 서비스 환경 전체를 즉시 되살리는 체계는 없었다는 것이 핵심 문제였다.

4. DR 구축 4가지 전략과 비교 분석

4-1. 백업 및 복원 (Backup & Restore)

가장 기본적이고 비용이 낮은 전략이다. 정기적으로 데이터를 백업해 원격지 스토리지에 저장하고, 재해 발생 시 새로운 환경을 처음부터 구축해 복원한다. 클라우드 환경에서는 다른 리전의 S3/Object Storage에 스냅샷을 저장하는 방식이 대표적이다.

RTO: 수 시간~수 일
RPO: 백업 주기에 따라 수 시간
비용: 낮음
적합 대상: 비핵심 시스템, 개발·테스트 환경, 예산이 극히 제한된 조직

실무에서 이 방식의 함정은 “백업은 했는데 복원 테스트를 한 번도 안 해봤다”는 경우다. 백업이 있다고 복구가 된다는 보장은 없다. DR 드릴(Drill, 모의 훈련)이 왜 필수인지가 여기서 나온다.

4-2. 파일럿 라이트(Pilot Light)

핵심 데이터베이스와 중요 서비스만 원격지에 최소한으로 복제해 두고, 재해 발생 시 나머지 컴퓨팅 자원을 신속히 확장(Scale-Out)해 서비스를 복구하는 방식이다. 불씨(Pilot Light)만 꺼지지 않게 유지하다가 필요 시 빠르게 불을 키우는 개념이다.

RTO: 수십 분~수 시간
RPO: 수 분~수십 분
비용: 중간 (DB 복제 비용만 상시 발생)
적합 대상: 중요도 중상급 서비스, 클라우드 환경

4-3. 웜 스탠바이(Warm Standby)

DR 사이트에 축소 규모(Scaled-Down) 버전의 시스템을 상시 운영하며, 실시간에 가깝게 데이터를 동기화한다. 재해 발생 시 DR 사이트의 자원을 풀 스케일로 확장하면 서비스 재개가 가능하다.

RTO: 수십 분 이내
RPO: 수 초~수 분
비용: 높음 (상시 운영 인프라 필요)
적합 대상: 준핵심 서비스, B2C 대면 서비스

4-4. 멀티-사이트 액티브-액티브(Multi-Site Active-Active)

주 센터와 DR 센터가 동시에 트래픽을 처리하며 항상 양쪽이 ‘살아있는’ 상태를 유지하는 방식이다. 한쪽이 다운되면 나머지가 즉각 전체 트래픽을 처리한다. 이 방식에서 RTO는 사실상 0이다.

RTO: 수 초 이내 (사실상 0)
RPO: 0 (실시간 동기화)
비용: 매우 높음 (양쪽 전체 인프라 상시 운영)
적합 대상: 금융 핵심 시스템, 국가 핵심 인프라, 글로벌 서비스

국정자원 화재 이후 행정안전부가 발표한 대책의 핵심이 바로 국가 핵심(A1) 등급 시스템에 ‘실시간 액티브-액티브 DR’ 구축 의무화와 RTO 1시간 이내 적용이다. 방향은 맞다. 문제는 이걸 실현할 예산과 기술력이 따라주느냐다.

5. 클라우드 DR 시대 — DRaaS와 멀티클라우드 전략

5-1. DRaaS(DR as a Service)의 부상

물리적 DR 센터를 자체 구축하는 방식의 가장 큰 문제는 재해가 없는 평상시에 모든 인프라가 유휴 상태로 비용만 먹는다는 점이다. 핫 사이트를 구축해두면 DR 시스템을 위한 서버·네트워크·스토리지가 항상 돌아가지만, 정작 쓰는 날은 거의 없다. 이 비효율을 해결한 게 클라우드 기반 DRaaS다.

DRaaS는 클라우드 사업자의 인프라를 DR 환경으로 활용해, 평상시에는 최소 비용만 쓰다가 재해 발생 시 빠르게 자원을 확장해 서비스를 복구한다. 대표적인 솔루션으로는 AWS CloudEndure(현 AWS DRS), Azure Site Recovery, Zerto, Veeam 등이 있다.

국내에서는 NCP의 서버 마이그레이션, KT Cloud의 DR 서비스, 삼성SDS의 SCP(Samsung Cloud Platform) 기반 DR 등이 활발하게 제공되고 있다.

5-2. 멀티클라우드 DR — 단일 클라우드의 함정

클라우드로 DR을 전환한다고 해서 끝이 아니다. 단일 클라우드에만 의존하면 그 클라우드 사업자 자체가 장애를 일으킬 때 또 무너진다. 2017년 AWS 버지니아 리전 장애, 2023년 KT 클라우드 장애가 대표 사례다.

이 때문에 멀티클라우드 DR 전략이 2025년 이후 빠르게 확산되고 있다. 주 센터는 NCP, DR은 AWS 코리아 리전으로, 혹은 주 시스템은 온프레미스, DR 1은 KT Cloud, DR 2는 Azure Korea로 분산하는 구조다.

단, 멀티클라우드는 비용·복잡성·운영 부담을 모두 높인다. 클라우드마다 API, 네트워크 구성, 보안 정책이 다르기 때문에 통합 관리 계층(Control Plane)이 없으면 오히려 리스크가 커진다. 이것을 해결하기 위해 Terraform 같은 IaC(Infrastructure as Code)와 Kubernetes 멀티클러스터 운영 툴, HashiCorp Vault 같은 시크릿 관리 솔루션이 필수로 따라붙는다.

5-3. 공공 부문의 특수성 — PPP 클라우드와 G-클라우드

공공 부문은 망 분리, 개인정보보호법, ISMS-P 인증 등 규제 환경이 민간보다 훨씬 엄격하다. 이 때문에 아무 클라우드나 쓸 수 없고, 과학기술정보통신부 인증을 받은 CSAP(클라우드 보안 인증) 취득 사업자의 서비스만 활용할 수 있다.

행안부는 이번 국정자원 화재 이후 **총 3,463억 원 규모의 ‘2026년 재해복구시스템 구축 사업’**을 추진 중이다. 1만 5,000여 개 공공 정보시스템에 DR 체계를 구축하고, 대전센터를 2030년까지 단계적으로 폐쇄한다는 계획이다. 이 사업을 둘러싼 ISP 단계부터 주요 IT 기업들의 수주 경쟁이 이미 뜨겁게 달아오르고 있다.

6. 2025~2026 최신 기술 트렌드

6-1. AI 기반 예측 유지보수 (Predictive Maintenance)

데이터센터 장애의 패러다임이 **사후 대응(Reactive)에서 사전 예방(Predictive)**으로 전환되고 있다. 전력 설비, 냉각 시스템, 배터리(UPS)의 센서 데이터를 실시간으로 수집하고 ML 모델로 이상 징후를 탐지해, 장애가 발생하기 전에 유지보수를 수행한다.

이번 국정자원 화재도 배터리 셀의 온도 이상이 사전에 감지됐다면 작업 일정을 조정할 수 있었을 것이다. AI 예측 유지보수 시스템은 커패시터 수명 예측, 팬 이상 감지, 냉각 시스템 누수 탐지 등 다양한 영역에서 적용 범위가 확대되는 추세다.

6-2. 액체 냉각의 급부상 — DLC와 침지 냉각

AI 데이터센터의 랙 전력밀도가 폭발적으로 증가하면서 공기 냉각만으로는 한계에 도달했다는 것이 업계 공통의 인식이다.

2017년 표준 서버 랙의 전력밀도는 15kW 수준이었다. 그런데 2025년 엔비디아 GB200 NVL72 랙은 132kW, 2027년 출시 예정인 Rubin Ultra 랙은 무려 600kW에 달한다. 불과 10년 사이 40배가 뛴 것이다.

이를 감당하기 위한 냉각 기술 로드맵은 크게 3단계로 진화한다.

DLC (Direct Liquid Cooling): 서버 내부 핵심 부품에 직접 냉각수를 순환시키는 방식. 현재 하이퍼스케일 AI 데이터센터의 표준으로 자리 잡는 중
침지 냉각 (Immersion Cooling): 서버 자체를 절연 오일이나 냉각액에 담그는 방식. 전력 효율(PUE) 극적 개선
마이크로유체 냉각 (Microfluidic Cooling): 실리콘 내부에 미세 채널을 형성해 칩 수준에서 직접 냉각하는 차세대 방식. 2025~2040년 사이 상용화 전환 예상

6-3. 소버린 AI와 데이터 주권 이슈

AI 데이터센터 구축 흐름이 미국·중국 중심에서 전 세계로 분산되는 추세가 가속화되고 있다. 각국 정부가 자국 내 AI 인프라를 직접 통제하려는 ‘소버린 AI(Sovereign AI)’ 전략을 채택하면서, 국내에서도 공공·금융 분야 데이터의 국내 저장 의무화와 국산 클라우드 활성화가 주요 정책 의제로 부상했다.

SKT가 엔비디아 블랙웰 B200 기반 GPUaaS ‘해인(海印)’을 출시한 것도 이 맥락이다. 데이터센터 ISP나 클라우드 전환 프로젝트에서 데이터 주권 이슈는 이제 기술 결정보다 앞선 정치적·정책적 제약 조건으로 작용한다.

6-4. IaC와 자동화 기반 DR 현대화

전통적인 DR은 “재해 발생 → 담당자 전화 연락 → 매뉴얼 꺼내서 복구 절차 수행”이었다. 이 방식은 RTO를 수 시간 이내로 단축하는 데 근본적인 한계가 있다.

최신 DR 아키텍처는 Terraform + Ansible + CI/CD 파이프라인을 기반으로 인프라 전체를 코드화(IaC)하고, 재해 발생 시 버튼 하나로 복구 인프라 전체를 자동으로 프로비저닝한다. AWS DRS(Disaster Recovery Service), Azure Site Recovery 같은 서비스들이 이 자동화를 클라우드 네이티브 방식으로 제공한다.

7. 현장에서 체감한 DR 프로젝트의 현실

이론과 현실 사이의 괴리를 솔직하게 얘기해야겠다.

DR 프로젝트를 진행하면서 가장 자주 목격하는 문제는 세 가지다.

첫째, 서류 DR이다. BCP 문서와 DR 매뉴얼은 두껍게 만들어져 있는데, 실제로 DR 드릴(복구 훈련)을 수행해본 적이 없는 경우가 태반이다. 작년에 한 번 했는데 담당자가 바뀌었다. 시스템이 바뀌었는데 매뉴얼이 업데이트되지 않았다. 이런 사례가 공공·금융·제조 할 것 없이 넘쳐난다.

둘째, RTO·RPO와 예산의 괴리다. “RTO 1시간, RPO 제로”를 요구하면서 예산은 콜드 사이트 수준으로 잡아오는 경우가 있다. ISP/ISMP 단계에서 이 간극을 메우는 게 컨설턴트의 역할이지만, 발주처가 이미 마음속으로 예산 상한선을 정해두고 그에 맞춰 RTO·RPO를 역산하는 경우도 적지 않다.

셋째, DR 테스트의 공포다. 실제 운영 중인 시스템에서 DR 전환 테스트를 하면 서비스에 영향이 갈 수 있다. 그래서 담당자들은 DR 테스트를 미룬다. 미루다 보면 1년, 2년이 간다. 그리고 실제 재해가 터지면 제대로 작동하지 않는다.

국정자원 사태가 이것을 극적으로 증명했다. 행안부의 분석처럼 “데이터는 있었지만 서비스 전체를 되살리는 체계가 없었다.”

현장에서 DR 프로젝트를 제대로 하려면 몇 가지 원칙이 필요하다.

DR은 연간 정기 훈련이 아니라 분기 또는 월 단위 자동화 테스트여야 한다
IaC 기반 자동 프로비저닝을 구성하면 DR 테스트의 부담이 극적으로 줄어든다
RTO·RPO는 비즈니스 임팩트 분석(BIA)에서 출발해야 하며, 시스템별로 차등 적용해야 한다
DR 예산은 ‘보험료’ 개념으로 접근해야 한다. 안 쓰면 다행이지만, 필요할 때 없으면 파국이다

8. 마치며 — ISP를 제대로 하면 보인다

데이터센터 구축 ISP를 수행하다 보면 의뢰기관의 DR 수준을 금방 알 수 있다. 현황 인터뷰에서 “DR 구성이 어떻게 되나요?”라고 물으면 돌아오는 대답이 크게 세 종류다.

“물리적으로 이중화되어 있고 자동 전환이 됩니다.” → 잘 되어 있는 조직
“백업은 있고, 복구 절차 문서도 있습니다.” → 보통 수준
“그게 어떻게 되는지 담당자한테 물어봐야 할 것 같아요.” → 적신호

대부분의 조직은 두 번째와 세 번째 사이 어딘가에 있다.

2025년 9월 국정자원 화재는 IT 인프라를 설계하고 운영하는 모든 사람에게 불편하지만 중요한 진실을 다시 확인시켜줬다. 재해복구는 구축이 끝이 아니라 시작이다. 정기적 훈련, 자동화, 지속적인 아키텍처 고도화가 따라오지 않으면 DR은 그냥 서류 더미다.

이제 정부는 3,463억 원 규모의 공공 DR 구축 사업을 본격화하고 있고, 1만 5,000여 개 시스템에 체계적인 DR을 구현하는 5년짜리 여정을 시작했다. 이 사업을 수행할 IT 컨설팅사와 SI 기업들에게는 큰 기회이자, 동시에 무거운 책임이다.

기술은 빠르게 진화한다. AI 기반 예측 유지보수, 액체 냉각, 멀티클라우드 DR, IaC 자동화 — 이 모든 것들이 지금 이 순간에도 현장에서 실제로 구현되고 있다. 중요한 것은 트렌드를 아는 것이 아니라, 그것을 우리 조직의 현실에 맞게 적용하는 판단력이다.

ISP를 제대로 하면 보인다. 현황이 보이고, 문제가 보이고, 길이 보인다. 결국 좋은 컨설턴트는 좋은 질문을 먼저 던지는 사람이다.

이 글은 IT 인프라 프로젝트 현장의 경험과 공개된 최신 자료를 바탕으로 작성되었습니다. 본문 내 수치와 사례는 참고 목적이며, 실제 프로젝트 적용 시 해당 환경에 맞는 전문가 검토가 필요합니다.

이 글이 도움이 됐다면 공유해 주세요. 댓글로 현장 경험을 나눠주시면 더 깊은 대화를 이어갈 수 있습니다.