[케클러 인터뷰 시리즈] #6 - 백업만으로는 부족하다, 공공 DR의 새로운 기준

 

kt cloud 마케팅커뮤니케이션팀

 

📝 요약 SUMMARY

‘기술이 장르가 되는 곳, kt cloud의 케클러 인터뷰 시리즈’는 케클러들의 목소리를 통해 고객의 다음 문제를 먼저 고민하는 kt cloud의 기술적 지향점과 해법을 전합니다.

여섯 번째 호에서는 공공 클라우드 전환과 국가 *재해복구(Disaster Recovery, 이하 DR) 기술 컨설팅을 이끌고 있는 kt cloud Cloud컨설팅팀 김광배 팀장을 만났습니다.

달라진 공공 DR 정책과 A1~A4 등급별 아키텍처, 비용 효율적인 설계 방식부터 실제 서비스 복구를 검증하는 방법까지 살펴봅니다.

 

#ktcloud #공공DR #공공클라우드 #재해복구 #서비스연속성

---

kt cloud Cloud컨설팅팀 김광배 팀장

 

안녕하세요. kt cloud 마케팅커뮤니케이션팀입니다.

 

공공기관의 정보시스템에 *장애가 발생하면 민원 접수가 지연되고 행정업무가 중단됩니다. 시스템에 따라서는 국민의 안전과 일상생활에도 직접적인 영향을 미칠 수 있습니다.

2025년 9월 발생한 국가정보자원관리원(이하 국정자원) 대전센터 화재는 이러한 위험을 보여준 사례입니다. 당시 700여 개 정보시스템이 일시에 중단되면서 주요 행정서비스에 차질이 발생했고, 국민들도 큰 불편을 겪었습니다.

이후 정부는 2026년 2월 「AI정부 인프라·거버넌스 혁신 추진방향」을 발표하고, 4월에는 「행정기관 및 공공기관 정보시스템 안정성 고시」를 시행했습니다. 8월에는 국민에게 미치는 영향도를 기준으로 1만 5,033개 공공 정보시스템의 등급을 재분류했습니다. 공공 DR의 기준이 달라지고 있는 것입니다.

 

그렇다면 DR센터를 구축하고 데이터를 백업해 두는 것만으로 실제 *재해 상황에서 서비스를 복구할 수 있을까요?

데이터가 남아 있더라도 애플리케이션과 네트워크, 인증 시스템 등이 정상적으로 작동하지 않으면 서비스를 이용할 수 없습니다. 중요한 것은 장애 발생 시 서비스를 얼마나 신속하고 정확하게 복구할 수 있느냐는 점입니다.

 

이번 인터뷰에서는 kt cloud Cloud컨설팅팀 김광배 팀장과 함께 달라진 공공 DR 기준과 이에 대응하는 클라우드 아키텍처, 실제 복구 역량을 확보하기 위한 기술과 운영 방안을 살펴봤습니다.

 

💡이야기를 시작하며

김광배 팀장 | kt cloud Cloud컨설팅팀

1995년 KT 입사 이후 차세대 IT 시스템 구축, 유무선 통합 BSS 구축, 클라우드 네이티브 전환 등 다양한 프로젝트를 수행해 왔습니다.

2025년에는 국정자원 대전센터 화재복구 전환사업을 총괄했으며, 2026년부터는 경북도청 kt cloud PLATFORM 전환사업 TF를 이끌고 있습니다. 국정자원 DR 구축을 위한 정보화전략계획(ISP) 수립과 행정안전부 Active-Active DR 구축 관련 ISP 사업도 지원하고 있습니다.
현재는 kt cloud Cloud컨설팅팀 팀장으로서 고객과 MSP를 대상으로 기술 컨설팅, 클라우드 사업 제안 및 수행을 총괄하고 있습니다.

 이번 인터뷰의 주인공이 꼽은 ‘이 글이 필요한 분들’

↳ 공공 정보시스템의 DR 구축과 고도화를 검토하는 공공기관 IT 담당자

↳ RTO·RPO에 맞는 재해복구 아키텍처를 설계하는 클라우드 아키텍트

↳ 공공 클라우드 전환과 DR사업을 수행하는 사업 담당자

---

Part 1. 데이터는 복구했는데, 서비스는 왜 작동하지 않을까?

데이터 백업과 실제 서비스 복구의 차이

 

과거 공공 DR은 서버와 스토리지를 이중화하고, 데이터를 원격지에 백업하는 등 인프라 확보에 중점을 뒀습니다. 하지만 실제 재해 상황에서는 백업 데이터가 남아 있다는 사실만으로 서비스 복구를 보장할 수 없습니다.

 

김광배 팀장은 공공 DR이 과거의 ‘보험성 백업 체계’에서 ‘상시 운영되는 국가 디지털 서비스의 핵심 인프라’로 바뀌고 있다고 설명합니다.

 

예를 들어 A 공공기관의 민원 시스템에 장애가 발생했다고 가정해 보겠습니다.

DR센터에 *데이터베이스(이하 DB)를 정상적으로 복제하고 장애 발생 후 복구했더라도, 민원인이 제출한 첨부파일이 복제되지 않았다면 실제 업무를 처리하기 어렵습니다. 인증 시스템이나 외부기관 연계가 복구되지 않은 경우도 마찬가지입니다. 서버가 정상적으로 작동하더라도 사용자가 로그인하거나 민원을 처리할 수 없다면 서비스가 복구됐다고 볼 수 없습니다.

따라서 공공 DR은 DB와 파일뿐 아니라 애플리케이션, 네트워크, 보안, 인증, 외부기관 연계까지 함께 고려해야 합니다.

 

이러한 복구 수준을 판단하는 대표적인 지표가 RTO와 RPO입니다.

 

💡RTO와 RPO, 복구 가능성을 판단하는 두 가지 기준

✅ RTO(Recovery Time Objective, 복구시간목표)

• 재해 발생 시 서비스를 복구하기 위해 설정한 목표 시간입니다.
• 재해를 선포한 시점부터 DR 시스템을 가동하고 핵심 기능이 정상임을 확인한 시점까지를 기준으로 합니다.
• 실제 서비스 중단을 최소화하려면 장애 인지, 재해 선포, 전환 승인, 데이터 복구, 네트워크 전환과 핵심 기능도 함께 점검해야 합니다.

✅ RPO(Recovery Point Objective, 복구시점목표)

• 재해 발생 시 허용할 수 있는 데이터 손실 범위를 시간으로 나타낸 목표입니다.
• DB뿐 아니라 파일과 메시지, 외부기관 연계 데이터까지 포함해 업무 단위로 설정해야 합니다.
• DB의 접수정보와 첨부파일이 서로 다른 시점으로 복구된다면 실제 업무 처리에 문제가 생길 수 있습니다.

---

Part 2. 복구목표에 따라 달라지는 DR 설계

A1~A4 등급별 공공 DR 아키텍처 예시

 

모든 공공 정보시스템에 동일한 DR 구조가 필요한 것은 아닙니다. 국민의 생명과 안전에 직결되는 시스템과 일반 행정지원 시스템은 장애 발생 시 영향도와 허용 가능한 중단 시간이 다르기 때문입니다.

 

김광배 팀장은 DR 방식을 결정할 때 서비스 중단이 국민과 행정업무에 미치는 영향을 먼저 살펴야 한다고 설명합니다. 장애 발생 시 다른 채널로 업무를 대체할 수 있는지, 어떤 기능부터 복구해야 하는지도 중요한 기준입니다.

특히 A1 등급이라고 해서 모든 서비스를 반드시 *Active-Active로 구성해야 하는 것은 아닙니다. 같은 시스템 안에서도 핵심 업무와 부가 기능의 중요도가 다르므로, 업무영향도 분석을 통해 적정 복구 수준을 결정해야 합니다.

 

① 등급별 복구목표와 DR 아키텍처

2026년 행정안전부는 공공 정보시스템을 국민에게 미치는 영향과 서비스 중요도에 따라 A1~A4 등급으로 구분하고, 등급별 DR 구축 기준을 구체화했습니다.

kt cloud Cloud컨설팅팀은 이러한 복구목표에 맞춰 다양한 클라우드 아키텍처를 조합하는 방식을 제안합니다.

 

등급	정보시스템 유형	RTO(복구시간목표)	RPO(복구시점목표)	kt cloud DR 설계 예시
A1	국가 핵심	1시간 이내	0(실시간)	서울 리전 Multi-AZ 기반 Active-Active + 원격지(경북 리전) DR
A2	대국민 필수	3~12시간 이내	수 분	서울 리전 Multi-AZ + 경북 리전 *Hot Standby
A3	행정 중요	1~5일 이내	수 분	*Warm Standby 또는 *Pilot Light ※재해 시 IaC 기반 자원 확장
A4	국민·행정 일반	3주 이내	1~7일	원격지 소산백업 + *Cold DR

※ kt cloud 인프라를 활용한 DR 아키텍처 예시이며, 실제 구성은 고객 시스템의 요구사항에 따라 달라질 수 있습니다.

 

복구시간이 짧아야 하는 시스템은 복수의 환경에서 서비스를 운영하는 Active-Active 방식과 원격지 DR을 결합할 수 있습니다. 반면 복구시간에 여유가 있는 시스템은 평상시 최소한의 자원만 유지하고, 장애 발생 시 필요한 자원을 생성하거나 백업 데이터를 복원하는 방식이 적합할 수 있습니다.

 

② Active-Active의 비용 최적화, 자원 운영 방식이 관건

DR 설계에서는 복구 성능과 함께 비용도 고려해야 합니다.

복구시간을 줄이기 위해 두 센터에 모든 자원을 최대 용량으로 운영한다면 비용 부담이 커집니다. 하지만 시스템 특성에 따라 자원 운영 방식을 달리할 수 있습니다.

전체 서비스에 필요한 자원 용량을 100이라고 가정해 보겠습니다.

 

양쪽 센터에서 각각 100을 상시 운영하는 대신, 평상시에는 두 센터가 각각 50씩 트래픽을 처리하고 장애 발생 시 정상 센터를 100까지 자동 확장하도록 설계하는 방식입니다.

웹·WAS 등 무상태(Stateless) 애플리케이션은 컨테이너와 *코드형 인프라(IaC)를 활용해 이러한 구조를 비교적 유연하게 구현할 수 있습니다. 다만 장애 시 추가 자원을 확보할 수 있어야 하며, 확장에 필요한 시간도 RTO에 포함해야 합니다.

반면 DB와 스토리지, 보안장비, 외부기관 연계회선처럼 즉시 확장하기 어려운 자원은 사전에 필요한 용량과 연결 구조를 확보해야 합니다.

 

데이터 보호도 별도로 고려해야 합니다. 실시간 복제 환경에서는 운영자의 실수나 랜섬웨어로 손상된 데이터까지 DR 환경에 복제될 수 있으므로, 원격지 소산백업과 불변 백업 등의 보호 체계가 필요합니다.

비용 효율적인 DR 설계는 평상시 유지하는 자원을 최소화하면서도, 장애 발생 시 필요한 복구 성능을 확보하는 데 달려 있습니다.

---

Part 3. 센터 화재부터 광역재해까지, 훈련으로 입증하는 DR

Multi-AZ와 Multi-Region

 

DR을 구축했다면 다음으로 확인해야 할 것은 실제 장애 상황에서 정상적으로 작동하는지입니다.

이를 위해서는 장애 범위에 맞는 아키텍처와 정기적인 전환훈련이 필요합니다.

 

① Multi-AZ와 Multi-Region, 각각 어떤 역할을 할까?

Multi-AZ(Multiple Availability Zones, 다중 가용 영역)는 하나의 리전 안에서 물리적으로 분리된 여러 가용영역에 서비스를 분산하는 구조입니다. 특정 데이터센터에 장애가 발생하더라도 다른 AZ에서 서비스를 계속 제공할 수 있도록 설계합니다.

 

Multi-Region은 주 리전 전체를 사용할 수 없는 광역재해에 대비합니다. 대규모 화재나 정전, 공통 네트워크·플랫폼 장애 등은 여러 AZ에 동시에 영향을 미칠 수 있기 때문입니다.

 

kt cloud는 서울 리전의 목동·용산 Multi-AZ와 서울에서 약 200km 떨어진 경북 리전을 활용한 DR 아키텍처를 구성할 수 있습니다. 평상시에는 서울 Multi-AZ에서 서비스를 운영하고, 주 리전 전체에 장애가 발생하면 경북 리전으로 전환하는 방식입니다. 이때 데이터 복제와 *GSLB(Global Server Load Balancing)를 활용해 사용자 트래픽을 다른 리전으로 연결할 수 있습니다.

다만 리전 간 비동기 복제에서는 장애 직전의 일부 데이터가 DR 리전에 반영되지 않았을 수 있습니다. 따라서 업무별 RPO와 데이터 정합성 요구사항에 맞춰 복제 방식과 복구 순서를 결정해야 합니다.

 

② 실제 전환훈련에서는 무엇을 확인해야 할까?

DR 훈련은 DR센터의 서버가 정상적으로 켜지는지만 확인하는 과정이 아닙니다. 서비스 전환부터 핵심 업무의 정상 작동, 주 운영환경으로의 복귀까지 점검해야 합니다.

 

 

검증 영역	반드시 확인할 사항
서비스 전환	장애 감지, GSLB·DNS 전환, 애플리케이션 기동
데이터 복구	복제 지연, DB 승격, RPO 충족, 데이터 정합성
네트워크·보안	방화벽, 라우팅, 인증서, VPN·전용회선, 외부기관 연계
운영 절차	재해 선포, 전환 승인, 담당자 연락, 의사결정 권한
업무 검증	로그인, 조회·등록, 배치 및 대외 연계
*원복(Failback)	데이터 역동기화, 주센터 재가동, 트래픽 재전환

 

이 중 특히 주의해야 할 과정이 원복(Failback)입니다.

DR 환경으로 서비스를 전환한 뒤 주 운영환경이 복구되면, DR 환경에서 새로 생성된 데이터를 다시 반영하고 서비스를 원래 환경으로 되돌려야 합니다.

김광배 팀장은 이러한 데이터 역동기화와 원복 절차가 실제 DR 운영에서 어려운 과제 중 하나라고 설명합니다. 전환뿐 아니라 원복까지 검증해야 하는 이유입니다.

 

③ 공공 DR 훈련, 등급에 따라 달라지는 기준

「행정기관 및 공공기관 정보시스템 안정성 고시」 제20조는 정보시스템 등급 별 DR 훈련 유형과 주기를 규정하고 있습니다.

 

등급	DR 훈련 기준
A1·A2	연 1회 이상 실전환 훈련
A3	연 1회 이상 도상훈련, 3년에 1회 이상 모의훈련
A4	연 1회 이상 원격지 소산 데이터 복구를 포함한 도상훈련

※ 공공 DR 훈련의 예외 적용 요건은 「행정기관 및 공공기관 정보시스템 안정성 고시」 제20조를 참고해 주세요.

 

훈련 결과는 성공 여부뿐 아니라 단계별 복구 소요시간과 데이터 손실 여부를 함께 확인해야 합니다.

반복적인 훈련으로 문제점을 찾아 개선하고, 목표한 RTO와 RPO를 실제로 충족하는지 검증하는 것이 중요합니다.

---

Part 4. AI 서비스의 DR은 무엇이 다를까?

AI 추론·학습 워크로드별 복구 전략

 

AI 서비스가 확대되면서 재해복구 시 고려해야 할 대상도 늘어나고 있습니다.

기존 업무시스템의 데이터와 애플리케이션뿐 아니라 AI 모델, GPU 자원, 학습 *체크포인트까지 보호해야 하기 때문입니다. 특히 AI 추론과 학습은 운영 방식이 달라 각각에 맞는 복구 전략이 필요합니다.

 

① AI 추론과 학습, 서로 다른 복구 전략

대국민 AI 추론 서비스는 장애 발생 시에도 이용자가 서비스를 계속 사용할 수 있도록 신속하게 전환하는 것이 중요합니다.

이를 위해 복수 리전에 최소한의 서비스 용량을 유지하고, 장애가 발생하면 정상 리전의 자원을 확장하는 방식을 고려할 수 있습니다.

반면 대규모 AI 학습은 중단된 작업을 처음부터 다시 시작하지 않도록 준비해야 합니다. 학습데이터와 모델, 학습 상태를 기록한 체크포인트를 원격지에 보관하고, 장애 발생 시 다른 GPU 자원에서 작업을 이어가는 방식입니다.

GPU는 비용이 높은 자원인 만큼, 모든 리전에 동일한 규모로 운영하기보다 워크로드의 중요도와 복구목표에 따라 자원을 배분할 필요가 있습니다.

 

② AI 모델뿐 아니라 학습·배포 환경도 복구해야 한다

AI 워크로드의 주요 복구 대상과 고려사항은 다음과 같습니다.

 

복구 대상	주요 고려사항
학습데이터	대용량 데이터 전송, 변경분 복제, 버전 관리
AI 모델	모델 레지스트리 이중화, 버전·메타데이터 보존
GPU 자원	대체 GPU 확보, 예약 용량과 우선순위
학습 작업	체크포인트 저장, 중단 지점부터 재시작
추론 서비스	다른 리전으로 재배포, 트래픽 전환
AI 파이프라인	데이터 수집·전처리·학습·배포 환경 복구

 

예를 들어 학습 체크포인트가 남아 있더라도 해당 모델 버전이나 학습데이터에 접근할 수 없다면 중단된 작업을 재개하기 어렵습니다.

따라서 AI 서비스의 DR은 데이터와 모델의 보존 상태는 물론, 대체 GPU 확보와 실행 환경의 재구성 가능 여부까지 함께 검토해야 합니다.

---

Part 5. kt cloud PLATFORM, 공공 DR을 어떻게 지원할까?

kt cloud PLATFORM의 공공 DR 고도화 방향

 

공공 DR 정책과 기술 환경이 달라지면서 클라우드 플랫폼에도 보다 체계적인 재해복구 기능이 요구되고 있습니다.

김광배 팀장은 kt cloud PLATFORM의 공공 DR 발전 방향으로 표준 아키텍처, 클라우드 네이티브 기반 복구, 전환 자동화, 광역 DR, AI 워크로드 지원을 제시했습니다.

 

① 공공 DR 표준 아키텍처

정보시스템의 A1~A4 등급과 복구목표에 따라 선택할 수 있는 표준 DR 모델을 마련하는 방안입니다.

백업·복구 방식과 인프라 구성을 표준화하면 기관별 설계 부담을 줄일 수 있습니다. 향후 패키지형 DR 서비스로 제공해 공공기관이 클라우드 도입 단계부터 재해복구를 함께 준비할 수 있도록 하는 방향도 검토하고 있습니다.

 

② 클라우드 네이티브 기반 서비스 복구

컨테이너 이미지, Kubernetes 설정, 네트워크·보안정책 등을 코드로 관리하면 다른 리전에서도 동일한 서비스 환경을 신속하게 구성할 수 있습니다.

kt cloud PLATFORM은 이러한 기술을 기반으로 서비스 구성과 의존관계를 관리하고, 장애 발생 시 애플리케이션 환경을 효율적으로 복구하는 방향으로 고도화를 추진하고 있습니다.

 

③ DR 전환 자동화와 통합 관리

장애 감지부터 DB 승격, 서버·컨테이너 확장, GSLB 전환, 핵심 기능 점검까지 복구 절차를 자동화하는 DR 오케스트레이션도 중요한 과제입니다.

kt cloud는 DR 환경의 상태와 전환 과정을 관리하기 위한 대시보드 및 자동화 플랫폼을 준비하고 있습니다.

이를 통해 복구 단계별 소요시간과 데이터 상태를 기록하고, RTO·RPO 충족 여부를 지속적으로 확인할 수 있도록 하는 것이 목표입니다.

 

④ 서울·경북 리전 기반 광역 DR

서울 목동·용산 Multi-AZ와 경북 리전을 연계해 데이터센터 단위 장애와 광역재해에 대응하는 DR 구성을 지원하는 방향입니다.

공공기관의 서비스 중요도와 복구목표에 따라 Multi-AZ와 Multi-Region을 조합해 적용할 수 있습니다.

 

⑤ AI 워크로드 DR 지원

AI 데이터와 모델, 학습 체크포인트 보호를 비롯해 GPU 자원 예약과 자동 재배치, 모델 재배포 등 AI 서비스에 필요한 복구 기능도 발전 과제로 제시했습니다.

다만 자동화 과정에서 오류가 확산되지 않도록 불변 백업, 배포 승인, 보안정책 검증, 자동화 중단장치 등의 안전장치도 함께 고려해야 합니다.

 

kt cloud는 기술과 운영 체계를 지속적으로 고도화해 공공기관이 안정적으로 서비스를 운영하고, 재해 발생 시에도 신속하게 복구할 수 있도록 지원할 계획입니다.

 

 

 

---

📚 관련 용어 설명

• 장애: 정보시스템 사용자 관점에서 서비스 이용이 불가능하거나, 불편이 발생하여 정보시스템에서 제공하는 서비스의 정상적인 활용이 어려운 상태입니다.
• 재해: 재난 또는 이에 준하는 외부요인으로 인한 정보시스템의 파손 및 가동 중단이 발생하거나 정보시스템 내부 결함 등으로 인해 발생한 장애가 장시간 지속되는 상태입니다.
• DR(Disaster Recovery, 재해복구): 재난이나 대규모 장애 발생 시 데이터와 서비스를 복구하기 위한 기술·운영 체계입니다.
• DB(Database, 데이터베이스): 데이터를 체계적으로 저장·관리하고 조회·처리할 수 있도록 구성한 시스템의 데이터 저장소입니다.
• Multi-AZ: 하나의 리전 내 여러 가용영역에 시스템을 분산해 고가용성을 확보하는 구조입니다.
• Multi-Region: 지리적으로 분리된 여러 리전을 활용해 광역재해에 대응하는 구조입니다.
• Active-Active: 두 개 이상의 데이터센터가 동시에 서비스 트래픽을 처리하는 구조로, 장애 발생 시 한쪽이 중단 되더라도 다른 센터가 즉시 서비스를 지속해 무중단 운영이 가능한 방식입니다.
• Hot Standby: 대기 환경에 필요한 시스템을 가동해 장애 발생 시 신속하게 전환할 수 있도록 준비하는 방식입니다.
• Warm Standby: DR 환경에 축소된 서비스 용량을 상시 운영하고 장애 시 이를 확장하는 방식입니다.
• Pilot Light: DR 환경에 핵심 데이터와 기반 구성을 유지하고 장애 시 필요한 자원을 생성 및 확장하는 방식입니다.
• Cold DR: 평상시에는 운영 자원을 최소화하고 장애 발생 시 백업 데이터를 복원하고 필요한 환경을 구성하는 방식입니다.
• IaC(Infrastructure as Code): 서버·네트워크 등 인프라 구성을 코드로 정의하고 배포 및 관리하는 방식입니다.
• GSLB(Global Server Load Balancing): 여러 지역의 서비스 상태 등을 고려해 사용자 트래픽을 적절한 서비스 위치로 연결하는 기술입니다.
• Failback(원복): DR 환경으로 전환한 서비스를 주 운영환경으로 다시 복귀시키는 과정입니다.
• Checkpoint(체크포인트): AI 학습 작업의 중간 상태를 저장해 중단 이후 해당 지점부터 작업을 재개할 수 있도록 하는 데이터입니다.