Kubernetes,Whitepaper,미분류
공공기관 DR, 가상화에서 클라우드 네이티브로 전환
# 공공기관 DR, 가상화에서 클라우드 네이티브로 전환해야 하는 이유
2026년 06월 29일

왜 지금 — 가상화 DR의 비용 압력이 임계점에 왔다
가상화 DR 사이트는 평시 자원 활용률이 5~15%에 머뭅니다. 호스트·스토리지·하이퍼바이저·게스트 OS·미들웨어 등 3단 라이선스가 운영 사이트와 동등하게 DR 사이트에도 청구되므로, 5년 갱신 주기마다 ROI 시트의 적자 폭이 누적됩니다. 최근 하이퍼바이저 라이선스 정책 개편이 이 압력을 가속하고, 랜섬웨어가 백업 매체 자체를 암호화하는 사이버 재해 시나리오가 보고되면서 “백업 시점을 복원하면 안전하다”는 전제도 흔들리고 있습니다.
운영 워크로드가 컨테이너로 이동할수록 가상화 DR 사이트는 별도 인력·라이선스를 추가로 요구합니다. 세 압력이 겹치는 DR 갱신 주기 시점이 클라우드 네이티브 전환을 검토할 최적의 기회입니다.
CNF 백서 구독하기🔔
새로운 백서가 발간되면 가장 먼저 안내드려요!
CNF가 전하는 최신 백서와 클라우드 인사이트를 가장 빠르게 만나보실 수 있습니다.
진심으로 구독 부탁드립니다 🙏
무엇이 문제인가 — 가상화 Active-Active의 4중 종속
가상화 환경에서 Active-Active DR을 시도하면 반드시 네 가지 종속이 서로를 강화합니다.
라이선스 이중 지불. 두 사이트 모두에서 트랜잭션을 처리하므로 코어·소켓 라이선스가 두 번 청구됩니다. Active-Active의 ROI 논리가 라이선스 비용 앞에서 무너집니다.
공유 스토리지 쿼럼 락. 두 사이트가 같은 가상 디스크에 동시 쓰기를 시도하면 분산 락 매니저가 한쪽만 허용합니다. 사이트 간 거리가 늘어날수록 락 합의 지연이 응답시간 SLA를 무너뜨립니다. 가상화 Active-Active가 실무에서 Active-Standby로 회귀하는 1차 원인이 여기에 있습니다.
가상 IP·L2 확장 종속. 동일 서비스를 양쪽 사이트에 노출하려면 사이트 간 L2 네트워크 확장이 필요하고, 한쪽의 네트워크 사고가 두 사이트로 전파되는 장애 도메인 묶임이 발생합니다.
세션 사이트 고정. 상태 저장 세션이 특정 사이트에 묶여 있어 페일오버 시 세션이 끊깁니다. 세션 저장소를 외부로 분리하지 않는 한 무중단 전환이 성립하지 않습니다.
라이선스·스토리지·IP·세션의 4중 종속은 강결합 구조로, 이 구조가 7단계 직렬 복구와 결합하면 RTO는 수 시간~수 일 범위를 벗어나기 어렵습니다.
무엇을 어떻게 — Kubernetes 기반 3단 병렬 복구 패턴
Kubernetes는 이 4중 종속을 구조적으로 해소합니다. 컨테이너 이미지는 라이선스 단위가 아니며, Service(서비스) 리소스가 IP를 추상화합니다. 상태 비저장(Stateless) 워크로드는 두 클러스터에 동시 실행하고, 상태 저장(Stateful) 워크로드는 StatefulSet(스테이트풀셋)으로 분리해 별도 일관성 모델을 적용합니다.
클라우드 네이티브 DR의 복구 구조는 세 단으로 단순화됩니다.
| 단 | 책임 | 대표 CNCF 프로젝트 |
|---|---|---|
| 1 | 선언적 매니페스트 동기 | Argo CD, Helm |
| 2 | 이미지 불변성·서명 검증 | Sigstore Cosign, OCI Distribution |
| 3 | 데이터·볼륨 복제 | Velero, CSI 스냅샷 |
Argo CD(아르고 CD)의 ApplicationSet 컨트롤러는 단일 Git 저장소를 SSoT(단일 진실 원본)로 삼아 두 클러스터의 매니페스트를 자동 동기화합니다. 드리프트(선언 상태와 실제 상태가 어긋나는 현상)가 감지되면 컨트롤러가 즉시 수렴시키며, 페일오버 트리거는 라벨 변경 한 줄로 단순화됩니다.
Istio(이스티오) Service Mesh는 Multi-Primary 모델로 mTLS(상호 TLS 인증) 기반 트래픽 라우팅을 통합 운영합니다. VirtualService 가중치 한 줄로 50/50, 카나리 5/95 같은 점진적 트래픽 분기를 즉시 실현합니다.
아래는 Argo CD ApplicationSet으로 두 클러스터에 동일 애플리케이션을 선언적으로 배포하는 예시입니다.
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: dr-workload
namespace: argocd
spec:
generators:
- list:
elements:
- cluster: primary-site
url: https://primary.k8s.example.com
- cluster: dr-site
url: https://dr.k8s.example.com
template:
metadata:
name: '-app'
spec:
project: default
source:
repoURL: https://git.example.com/manifests.git
targetRevision: main
path: apps/workload
destination:
server: ''
namespace: production
syncPolicy:
automated:
prune: true
selfHeal: true
이 단일 정의로 두 클러스터 모두에 동일 매니페스트가 자동 배포·갱신됩니다. selfHeal: true 옵션이 드리프트를 자동 복구합니다. Velero(벨레로)는 영속 볼륨과 Kubernetes 오브젝트를 매니페스트와 분리해 백업·복원하므로 애플리케이션 페일오버가 데이터 복제 완료를 기다리지 않고 시작될 수 있습니다.
도입 전후 — 정량 비교
국내외 대규모 기관의 DR 훈련 실측 사례와 클라우드 네이티브 전환 도입 효과를 비교하면 다음과 같습니다.
| 지표 | 가상화 DR | Kubernetes 기반 DR |
|---|---|---|
| 복구 절차 단계 수 | 7단계 직렬 | 3단 병렬 |
| RTO | 수 시간 ~ 수 일 | 한 자릿수 분 |
| DR 사이트 자원·라이선스 비용 | 기준 | 약 30~60% 절감 |
| 야간·주말 호출 빈도 | 기준 | 약 1/3 수준 |
GitOps 환경에서는 매니페스트 동기·이미지 부팅·트래픽 전환이 거의 동시에 진행되어, 7단계 직렬 복구 대비 RTO가 극적으로 단축됩니다.
CNCF 생태계 정합
클라우드 네이티브 DR의 각 구성 요소는 CNCF 프로젝트로 직접 매핑됩니다.
| DR 요소 | CNCF 프로젝트 | 역할 |
|---|---|---|
| 선언적 배포 및 GitOps | Argo CD, Helm | Git 저장소 → 멀티 클러스터 자동 동기 |
| 트래픽 라우팅 | Istio | mTLS 기반 멀티 클러스터 Service Mesh |
| 관측 가능성 | Prometheus, OpenTelemetry | 양 클러스터 메트릭·트레이스 수집 |
| 네트워크 정책·보안 | Cilium/eBPF | 클러스터 간 네트워크 정책 및 패킷 관측 |
| 백업·복원 | Velero | PV·K8s 오브젝트 백업 및 멀티 클러스터 복원 |
Cilium(실리엄)/eBPF는 커널 수준에서 네트워크 정책을 강제해 사이드카 없이도 세밀한 관측이 가능합니다. OpenTelemetry(오픈텔레메트리)는 두 클러스터의 트레이스·메트릭·로그를 단일 표준으로 수집해 DR 훈련 결과를 정량으로 증적합니다. 모든 프로젝트가 vendor-neutral 오픈 스탠다드를 따르므로 특정 벤더에 종속되지 않습니다.
자주 묻는 질문
가상화 인프라를 그대로 두고 Kubernetes DR만 추가할 수 있습니까?
단기 가능하지만, 운영 이중화가 장기 리스크입니다. 가상화 사이트와 Kubernetes DR 사이트를 별도 운영하면 두 기술 스택에 대한 인력·라이선스·절차가 동시에 유지되어야 합니다. 점진적 전환 경로로는 신규 워크로드를 Kubernetes 기반으로 구축하고, 기존 워크로드를 차세대 고도화 시점에 순차 이전하는 방식이 일반적입니다.
Kubernetes Active-Active에서 데이터베이스 일관성은 어떻게 보장합니까?
워크로드 유형에 따라 네 가지 카테고리를 선택합니다. 결제·재고 같은 강한 일관성 워크로드는 PostgreSQL Patroni 기반 동기 복제(RPO 0), 세션·로그 워크로드는 Debezium + Kafka 기반 CDC 비동기 복제를 적용합니다. 분산 SQL(CockroachDB, YugabyteDB)은 신규 글로벌 트랜잭션 워크로드에 우선 검토하고, NoSQL(Cassandra, MongoDB)은 시계열·카탈로그·이벤트 워크로드에 적합합니다. SLA 합의 회의에서 워크로드별로 카테고리를 매핑하는 것이 출발점입니다.
Service Mesh 도입이 운영 부담을 크게 늘리지 않습니까?
초기 학습 비용은 실재합니다. Istio 사이드카 자원 오버헤드, mTLS 인증서 관리, 멀티 클러스터 네트워크 설계가 신규 역량을 요구합니다. 다만 Argo CD와 결합하면 VirtualService 트래픽 분기 비율을 매니페스트 한 줄 변경으로 관리할 수 있어 운영 단순화 효과가 있습니다. 컨테이너 플랫폼이 있으나 Service Mesh가 없다면 멀티 클러스터 라우팅 PoC를 다음 단계로 검토하십시오.
국내 공공기관 정책과 정합성이 있습니까?
행정안전부 재해복구 지침과 KISA ISMS-P 통제 항목(변경 통제·재해복구 무결성 확인)이 GitOps 방식의 변경 추적과 Sigstore Cosign 서명 검증과 직접 매핑됩니다. Git 커밋 이력이 감사 증적이 되고, 정책 엔진(Kyverno)이 미서명 이미지를 입수 시점에 자동 차단합니다. 「전자정부법」의 정보시스템 안전성·신뢰성 제고(재해복구 포함) 의무와도 정합성이 확보됩니다.
DR 훈련 주기를 얼마나 늘릴 수 있습니까?
가상화 DR에서 격년·연 1회였던 훈련이 클라우드 네이티브 환경에서는 분기·월 단위 자동 검증으로 이동합니다. Argo CD의 드리프트 탐지가 상시 작동하고, Chaos Engineering 도구와 결합하면 평시 운영에서 페일오버 경로 건강이 지속 확인됩니다. 별도 DR 훈련 일정을 잡지 않아도 평시 운영의 부산물로 DR 가능성이 증적됩니다.
기술적 우위 요약과 결론
핵심 우위는 네 가지입니다. 첫째, 동일 워크로드 기준 자원·라이선스를 약 30~60% 절감합니다. 둘째, GitOps 매니페스트가 감사 증적이 되어 ISMS-P 변경 통제 요구사항을 자동 충족합니다. 셋째, Sigstore Cosign 서명 검증이 랜섬웨어 위조 이미지를 입수 시점에 차단합니다. 넷째, DR이 평시 운영의 부산물이 되어 야간·주말 호출 빈도가 약 1/3로 줄어듭니다.
DR 갱신 주기가 다가오고 있다면, 현 가상화 사이트의 7단계 직렬 복구를 그대로 연장하는 대신 Kubernetes 기반 3단 병렬 구조로의 전환을 다음 분기 기술 검토 의제로 올리십시오. CNCF 생태계의 Argo CD, Istio, Velero, Prometheus, OpenTelemetry가 각각 선언적 배포·트래픽 라우팅·백업복원·관측 가능성을 담당하는 vendor-neutral 조합이 이미 준비되어 있습니다.
참고 리소스
클라우드 네이티브 DR 구성 요소의 상세 설계·정량 분석·정책 정합성 전체 내용은 백서 PDF를 통해 확인하실 수 있습니다.
