가상화 DR 한계 — 재해복구 전환을 검토하는 5가지 기준

TL;DR — 클라우드 네이티브 재해복구는 과거 시점을 되살리는 대신 정해 둔 상태를 다시 만드는 방식이라, 복구가 수 시간에서 수 분으로 줄고 라이선스 비용이 약 30~60% 내려갑니다.

2026년 공공기관 프로덕션 운영 환경에서 재해복구 전환을 검토하는 의사결정권자가 가장 먼저 물어야 할 질문은 클라우드 네이티브 재해복구가 왜 지금의 가상화 방식보다 나은가 하는 것입니다. 이 글은 클라우드네이티브TV가 공개한 영상 ‘EP.01 클라우드 네이티브 재해복구: 가상화 방식의 한계와 대안'(약 9분 31초)이 그 근거를 어떻게 풀어 가는지를 캡처 8장과 함께 주장 단위로 정리하기 위해 썼습니다. 어떻게 복구 시간이 줄어드는지, Kubernetes 기반 전환을 도입하기 전에 무엇을 따져야 하는지를 영상을 보지 않은 독자도 따라올 수 있는 방식으로 풀었습니다.

클라우드네이티브TV의 이 영상은 공공기관의 클라우드 네이티브 재해복구 구축 방안 가운데 1장, 곧 ‘왜 가상화 방식에서 옮겨야 하는가’를 다룹니다. 영상은 다섯 가지 핵심 메시지로 시작해 외부 압력과 가상화의 한계를 짚고, 정해 둔 상태를 다시 만드는 원리와 다섯 차원 비교, 복구 시간축으로 이어집니다.

영상에서 다루는 순서는 다음과 같습니다.

• 의사결정을 위한 다섯 가지 핵심 메시지 (0:27)
• 세 가지 외부 압력과 가상화 재해복구의 한계 (4:04)
• 깃옵스로 정해 둔 상태를 재현하는 원리 (5:53)
• 다섯 차원 비교 (7:14)
• 직렬 복구에서 병렬 복구로 (8:37)

영상의 설명을 질문으로 바꾸면 여덟 가지입니다. 아래 여덟 개 절이 이 순서대로 답하고, 그 뒤에 영상 밖의 보충 두 절을 덧붙였습니다.

1. 의사결정권자에게 전해야 할 핵심 메시지는 무엇인가?
2. 다섯 메시지는 왜 하나의 인과 사슬로 읽어야 하는가?
3. 왜 하필 지금 재해복구 전환을 이야기해야 하는가?
4. 가상화 재해복구는 어떤 구조적 한계를 안고 있는가?
5. 클라우드 네이티브 재해복구는 어떻게 상태를 다시 만드는가?
6. 데이터는 왜 애플리케이션과 떼어 복제하는가?
7. 다섯 차원에서 두 방식은 어떻게 다른가?
8. 복구 시간은 왜 수 시간에서 수 분으로 줄어드는가?

영상은 본론에 들어가기 전에 핵심 메시지 다섯 가지를 화면 하나에 모아 보여 줍니다. 회의에서 바로 인용할 수 있도록 결론부터 압축한 것입니다.

첫째, 재해복구의 방식이 바뀌었습니다. 과거 시점을 되살리던 방식이 정해 둔 상태를 다시 만드는 방식으로 옮겨 왔습니다. 둘째, 쿠버네티스가 두 센터를 함께 돌리는 액티브 액티브 운영의 바탕을 갖췄습니다. 셋째, 데이터베이스 동기화는 업무 성격에 맞춰 네 가지 유형 중에서 고릅니다. 넷째, 자원과 라이선스 비용을 약 30~60% 줄이고 목표 복구 시간(RTO)을 한 자릿수 분으로 줄입니다. 다섯째, 국내 정책 요건과 잘 맞아떨어집니다.

▲ 다섯 가지 핵심 메시지 한눈에 보기 (영상 0:27)

캡처는 M1부터 M5까지 번호를 붙여 메시지를 한 줄씩 적고, 오른쪽 열에 본문에서 입증하는 장을 표시합니다. M1은 1~6장, M2는 2장, M3는 4장, M4는 5~6장, M5는 9장에서 다룬다고 되어 있습니다. 위쪽 노란 띠에는 이 다섯 줄이 독립된 결론이 아니라 서로 이어진 사슬이라는 요지가 적혀 있습니다.

이 표의 장점은 읽는 사람이 어느 장을 먼저 읽어야 하는지 곧바로 알 수 있다는 점입니다. 비용 담당자는 M4 줄을, 정책 담당자는 M5 줄을 따라가면 됩니다. 영상은 이 첫 화면을 두고 회의에서 가장 자주 언급되는 숫자가 M4의 30~60% 비용 절감과 한 자릿수 분의 복구 시간이라고 짚습니다.

영상이 강조하는 점은 다섯 가지 메시지가 따로 떨어진 결론이 아니라는 것입니다. 방식이 바뀌어야 구조가 서고, 구조가 서야 데이터 선택지가 넓어집니다. 그렇게 모인 힘이 비용과 시간을 줄이고, 결국 정책 요건까지 채웁니다.

영상은 이를 셔츠의 첫 단추에 빗댑니다. 첫 단추를 제대로 끼우면 나머지 단추가 차례로 맞는다는 것입니다. 그래서 영상의 첫 장은 방식의 변화, 곧 재해복구를 어떤 모델로 보느냐에서 시작합니다. 비용 절감 숫자만 떼어 내 들고 가면 설득력이 약해지고, 방식의 변화가 구조와 데이터 선택으로 이어지는 흐름을 함께 보여 주어야 한다는 뜻입니다.

▲ 독립 결론이 아닌 인과 사슬 (영상 3:24)

캡처에서는 노란 띠의 핵심 통찰이 강조됩니다. 내용은 모델 전환이 구조를, 구조가 데이터 선택을, 그 결합이 정량 우위를, 우위가 정책 정합성을 만든다는 한 문장입니다. 표의 다섯 줄이 위에서 아래로 한 방향으로 이어져 읽힙니다.

이 사슬을 의사결정 자료에 옮길 때는 순서를 지키는 것이 좋습니다. 비용을 먼저 말하면 “왜 비용이 줄어드는가”라는 질문이 곧바로 따라오고, 방식의 변화를 먼저 말하면 비용과 시간이 그 결과로 자연스럽게 설명됩니다.

영상은 왜 하필 지금 전환을 이야기해야 하는지를 세 가지 압력으로 설명합니다. 최근 2~3년 사이 세 압력이 한꺼번에 커졌다는 것입니다.

첫 번째는 업무 시스템이 컨테이너로 옮겨 가는 흐름입니다. 새로 만드는 시스템은 대부분 쿠버네티스 위에서 돌아가는데, 재해복구만 가상화에 남겨 두면 시스템을 두 벌 운영하게 됩니다. 두 번째는 가상화 라이선스 비용이 해마다 오른다는 점입니다. 평소 꺼 둔 대기 장비에도 똑같이 비용이 붙습니다. 세 번째는 화재와 장애 같은 사이버 재해가 잦아진 것입니다. 백업 데이터까지 공격 대상이 되면 과거 시점으로 되돌려도 깨끗하다고 장담할 수 없습니다.

▲ 전환을 밀어붙이는 세 가지 외부 압력 (영상 4:04)

캡처 위쪽 노란 띠는 세 가지 압력이 함께 밀려온다는 요지를 적고, 아래 카드 세 장이 ‘워크로드 컨테이너 이동’, ‘가상화 라이선스 상승’, ‘사이버 재해 빈도 증가’를 하나씩 설명합니다. 카드마다 업무 시스템의 컨테이너화, 평시에도 붙는 대기 장비 비용, 백업 데이터까지 노리는 공격이라는 한 줄 근거가 달려 있습니다.

영상은 이 세 압력이 서로를 더 키운다고 말합니다. 컨테이너로 옮겨 갈수록 가상화 쪽 재해복구의 이중 운영 부담이 커지고, 비용이 오를수록 대기 장비를 유지하는 일이 부담스러워지며, 재해가 잦아질수록 시점 복원의 한계가 드러납니다. 그래서 전환은 선택이 아니라 필수가 된다는 것이 이 장면의 결론입니다.

같은 장면 아래쪽에는 가상화 재해복구의 한계가 네 가지 수치로 요약되어 있습니다. 영상은 이 네 가지를 차례로 읽어 줍니다.

첫째, 대기 자원은 평소 5~15%만 쓰입니다. 둘째, 라이선스가 세 겹으로 쌓여 비용을 이중으로 냅니다. 셋째, 아이피와 스토리지에 묶여 있어 자동 전환에 한계가 있습니다. 넷째, 복구 일곱 단계 가운데 다섯 단계는 사람이 직접 손을 대야 해서 야간이나 주말에도 담당자를 불러야 합니다.

▲ 가상화 재해복구의 구조적 한계 네 가지 (영상 4:59)

캡처 아래쪽 띠의 제목은 ‘가상화 DR의 구조적 한계 — ROI 시트에 누적되는 4항목’입니다. 칸마다 큰 글씨로 5~15%, ×2, IP·스토리지, 5/7이 적혀 있고, 각각 평시 자원 활용, 3단 라이선스 이중 지불, 종속에 따른 자동 전환 한계, 단계가 인적 개입이라는 설명이 붙습니다. 이 네 칸이 모두 비용 시트에 쌓이는 항목이라는 점이 제목의 뜻입니다.

영상은 이 비용을 일 년에 한두 번 쓸 비상용 차를 사 두고 보험료는 매달 내는 셈에 빗댑니다. 다행히 이 숫자는 기관의 계약서와 자원 목록만 있으면 바로 계산됩니다. 그래서 전환 검토는 추정이 아니라 우리 기관의 실제 계약과 자원 목록을 넣어 보는 일에서 시작할 수 있습니다.

그렇다면 클라우드 네이티브는 무엇이 다를까요. 영상의 답은 핵심이 과거를 되살리는 것이 아니라 정해 둔 상태를 다시 만드는 것이라는 데 있습니다. 이 원리는 세 가지 장치가 함께 움직여 완성됩니다.

첫째는 설정을 코드로 적어 두고 자동으로 맞추는 방식, 곧 깃옵스(GitOps)입니다. 깃 저장소가 단일 기준점이 되어 어긋난 설정을 스스로 되돌립니다. 둘째는 한 번 만든 이미지를 바꾸지 않고 서명해 두는 이미지 불변성입니다. 셋째는 데이터 복제입니다.

▲ 상태를 재현하는 세 가지 장치 (영상 5:53)

캡처 왼쪽에는 번호를 붙인 세 카드가 있습니다. 1번 선언적 매니페스트 동기는 Argo CD ApplicationSet과 Git을 단일 기준점으로 쓰고, 2번 이미지 불변성·서명은 Harbor와 Sigstore Cosign으로 같은 다이제스트가 곧 비트 단위 동일 보증이라고 적습니다. 3번 데이터 복제는 Velero와 데이터베이스 네이티브 복제, CSI 스냅샷을 들고 있습니다. 오른쪽에는 복구 시간이 수 시간~수 일에서 수 분으로, 평시 활용률이 30~50%에서 70~90%로, 복구 절차가 직렬 7단계에서 병렬 3단계로 바뀐다는 비교가 있습니다.

영상은 이 차이를 이렇게 비유합니다. 가상화는 손으로 쓴 원본을 통째로 옮겨 적는 일과 같고, 클라우드 네이티브는 설계도를 넘겨주고 찍어내는 일에 가깝습니다. 옮겨 적기는 사람이 붙어야 하지만 찍어내기는 버튼 하나면 된다는 것입니다.

세 장치 가운데 데이터 복제는 따로 짚을 만한 설계 결정을 담고 있습니다. 영상은 데이터를 애플리케이션과 일부러 떼어서 따로 복제한다고 설명합니다.

이렇게 하면 데이터 복제가 끝나기를 기다리지 않고 서비스 전환을 시작할 수 있습니다. 애플리케이션은 이미지와 선언만으로 새 센터에서 다시 만들어지고, 데이터는 그와 독립된 경로로 따라옵니다. 두 일이 서로를 기다리지 않으므로 전체 복구가 겹쳐 진행됩니다.

▲ 데이터는 애플리케이션과 떼어 따로 복제 (영상 6:47)

캡처에서는 세 번째 카드인 데이터 복제에 진한 분홍색 테두리가 쳐져 있습니다. 카드의 부제는 애플리케이션 상태를 의도적으로 분리한다는 뜻이고, 사용하는 도구로는 Velero와 데이터베이스 네이티브 복제, CSI 스냅샷이 적혀 있습니다. 위쪽 띠에는 이 세 메커니즘이 결합해 상태를 복원하는 대신 재현한다는 요지가 다시 나옵니다.

앞서 다섯 메시지 가운데 M3가 데이터베이스 동기화를 업무 성격에 맞춰 네 가지 유형 중에서 고른다고 했던 것과 이어집니다. 데이터를 분리해 두었기 때문에 업무별로 다른 복제 방식을 고를 여지가 생기는 것입니다.

영상은 두 방식을 다섯 가지 차원에서 나란히 비교합니다. 결론은 분명합니다. 다섯 차원 모두에서 클라우드 네이티브가 앞서고, 그중 격차가 가장 큰 곳은 복구 시간과 평소 자원 효율입니다.

가상화는 복구에 수 시간, 길게는 수 일이 걸리고, 클라우드 네이티브는 이를 수 분으로 줄입니다. 라이선스는 세 겹에서 한 겹으로 줄어 비용이 30~60% 내려갑니다. 복구 절차는 차례로 밟던 일곱 단계가 동시에 도는 세 단계가 되고, 애플리케이션 전환이 데이터 복제를 기다리지 않는 점도 큰 차이입니다.

▲ 다섯 차원 비교표 (영상 7:14)

캡처의 표는 평가 차원을 복구 시간(RTO), 복구 시점(RPO), 자동화 수준, 평시 자원 활용, 라이선스 운영 비용으로 나눕니다. 가상화 DR 열은 수 시간~수 일, 분~시간, 낮음(수동 절차 의존), 30~50%, 3단(HV+OS+MM)이고, 클라우드 네이티브 DR 열은 수 분, 초~분, 높음(GitOps 선언적 재현), 70~90%, 단일(약 30~60% 절감)입니다.

영상은 이를 모든 과목에서 앞서는데 그중 몇 과목은 점수 차가 크게 벌어진 성적표에 빗댑니다. 의사결정 자료에서는 다섯 차원을 한 장에 놓고 보여 주는 것이 효과적이고, 표가 보여 주듯 어느 한 항목만 앞서는 것이 아니라는 점이 설득의 핵심입니다.

영상의 마지막 장면은 재해가 난 뒤 두 방식의 복구 과정을 시간 순서로 펼쳐 보여 줍니다. 가상화 재해복구는 과거 시점을 되살리는 방식입니다. 백업을 확인하고, 하드웨어를 배정하고, 운영체제를 부팅합니다. 이어서 미들웨어를 띄우고 애플리케이션을 복구하며, 네트워크를 다시 설정하고 데이터를 검증한 뒤에야 서비스가 재개됩니다.

일곱 단계가 줄지어 쌓이다 보니 약 4~12시간이 걸립니다. 클라우드 네이티브는 정해 둔 상태를 다시 만드는 방식입니다. 전환을 시작하면 깃옵스가 설정을 맞추고, 사용자 요청을 새 센터로 옮깁니다. 이 세 단계가 동시에 돌아 약 5~15분이면 서비스가 재개됩니다.

▲ 직렬 7단계와 병렬 3단계의 복구 시간축 (영상 8:37)

캡처는 위쪽 줄에 가상화 DR의 일곱 단계를 재해 발생부터 서비스 재개까지 한 줄로 늘어놓고 ‘약 4~12시간(직렬 누적)’이라고 표시합니다. 아래쪽 줄에는 클라우드 네이티브 DR의 세 단계가 겹쳐 놓여 ‘약 5~15분(병렬 처리)’이라고 적혀 있습니다. 두 줄의 길이 차이가 곧 복구 시간의 차이입니다.

영상은 차이의 본질이 단계의 개수가 아니라 차례로 하던 일을 동시에 하게 되었다는 점이라고 못 박습니다. 혼자 명절 음식을 하나씩 만드는 것과 온 가족이 나눠 만드는 것의 차이라는 비유가 이어집니다. 영상은 이렇게 재해복구가 왜 바뀌어야 하는지를 정리하고, 그 차이가 결국 몇 시간과 몇 분이라는 복구 시간으로 드러난다고 끝맺습니다.

영상은 복구 시간을 RTO라는 용어로 부르고 다섯 차원 표에서 복구 시점(RPO)도 함께 비교합니다. 두 용어를 헷갈리면 목표를 잘못 세우게 되므로 의사결정 자료에는 정의를 한 줄씩 붙여 두는 것이 좋습니다.

영상이 말하는 한 자릿수 분의 복구는 RTO의 이야기이고, 표의 ‘초~분’은 RPO의 이야기입니다. 두 숫자는 서로 다른 장치가 책임집니다. 앞의 것은 선언과 이미지로 애플리케이션을 다시 만드는 속도가, 뒤의 것은 데이터 복제 방식이 좌우합니다. 깃옵스를 쓰는 Argo CD의 동작 방식은 Argo CD 공식 문서에서, 이미지 서명은 Sigstore Cosign 문서에서, 쿠버네티스 볼륨 스냅샷은 Kubernetes 볼륨 스냅샷 문서에서 확인할 수 있습니다. 같은 주제를 발표 자료로 먼저 보려면 클라우드 네이티브 DR 구축 방안 발표 자료를 참고할 수 있습니다.

영상이 보여 준 한계와 장치를 점검 항목으로 바꾸면 우리 기관에 맞는 검토 질문이 나옵니다. 아래 표는 영상의 내용을 질문으로 옮긴 것입니다.

네 영역 가운데 하나라도 비어 있으면 앞에서 본 복구 시간 단축의 이점이 줄어듭니다. 예를 들어 설정이 사람 손에 의존하고 있다면 깃옵스가 기준으로 삼을 선언이 없어 병렬 복구가 성립하지 않습니다. 따라서 전환 전에 비용 계산, 수동 단계 수 세기, 선언 상태 정비, 데이터 복제 방식 정의를 먼저 해야 한다는 점을 기억해 두면 됩니다. 공공기관이 가상화에서 옮겨 간 흐름은 공공기관 DR 전환 사례에, 가상화 방식 자체의 한계는 가상화의 한계, 클라우드 네이티브 아키텍처가 해결하는 법에 정리돼 있습니다. 쿠버네티스 자체를 먼저 이해하려면 쿠버네티스란 무엇인가와 쿠버네티스 아키텍처 완벽 정리가 도움이 됩니다.

클라우드 네이티브 재해복구는 과거 시점을 되살리는 대신 정해 둔 상태를 다시 만드는 방식이고, 그 차이는 복구 시간과 비용으로 드러납니다.

클라우드 네이티브 재해복구는 가상화 재해복구와 무엇이 다른가요?

과거 시점을 되살리는 대신 정해 둔 상태를 다시 만드는 방식이며, 복구가 수 시간에서 수 분으로 줄어듭니다. 영상은 가상화가 일곱 단계를 차례로 밟아 약 4~12시간이 걸리는 반면, 클라우드 네이티브는 세 단계가 동시에 돌아 약 5~15분이면 서비스가 재개된다고 설명합니다.

지금 재해복구 전환을 검토해야 하는 이유는 무엇인가요?

컨테이너 확산, 가상화 라이선스 비용 상승, 사이버 재해 증가라는 세 압력이 최근 2~3년 사이 동시에 커졌기 때문입니다. 영상은 이 압력들이 서로를 키우므로 전환이 선택이 아니라 필수가 된다고 말합니다. 재해복구만 가상화에 남기면 시스템을 두 벌 운영하게 됩니다.

가상화 재해복구의 구조적 한계는 무엇인가요?

평시 활용률 5~15%, 라이선스 이중 지불, 아이피·스토리지 종속, 복구 7단계 중 5단계 수동이라는 네 가지입니다. 대기 자원은 평소 5~15%만 쓰이고 라이선스는 세 겹으로 쌓이며, 자동 전환에 한계가 있어 야간이나 주말에도 담당자를 불러야 합니다.

깃옵스와 이미지 불변성, 데이터 복제는 각각 어떤 역할을 하나요?

깃옵스는 설정을 기준점에 맞춰 되돌리고, 이미지 불변성은 같은 이미지를 보증하며, 데이터 복제는 데이터를 따로 옮깁니다. 영상은 깃 저장소를 단일 기준점으로 삼아 어긋난 설정을 스스로 되돌리고, 한 번 만든 이미지를 바꾸지 않고 서명해 두며, 데이터는 애플리케이션과 떼어 복제한다고 설명합니다.

데이터를 애플리케이션과 떼어 복제하면 무엇이 좋아지나요?

데이터 복제가 끝나기를 기다리지 않고 서비스 전환을 시작할 수 있어 복구가 겹쳐 진행됩니다. 애플리케이션은 이미지와 선언으로 새 센터에서 다시 만들어지고 데이터는 독립된 경로로 따라오므로, 가상화의 일곱 단계가 거의 동시에 도는 세 단계로 줄어듭니다.

클라우드 네이티브 재해복구로 옮기면 비용은 얼마나 줄어드나요?

영상은 자원과 라이선스 비용이 약 30~60% 줄어든다고 설명하며, 라이선스는 세 겹에서 한 겹으로 줄어듭니다. 평시 자원 활용률도 30~50%에서 70~90%로 오릅니다. 이 숫자는 기관의 계약서와 자원 목록만 있으면 바로 계산해 볼 수 있습니다.

클라우드 네이티브 재해복구를 더 깊이 살펴볼 때 볼 원 영상과 이어서 읽을 글, 공식 문서를 모았습니다.

• 클라우드 네이티브 DR 구축 방안 발표 자료 — 공공기관 재해복구 전환
• 공공기관 DR 전환 사례 — 가상화에서 클라우드 네이티브로
• 가상화의 한계, 클라우드 네이티브 아키텍처가 해결하는 법
• 쿠버네티스(Kubernetes)란 무엇인가 — 개념과 도입 이유
• 쿠버네티스 아키텍처 완벽 정리 — 컨트롤 플레인부터 워커 노드까지
• 쿠버네티스 vs 도커 차이 완벽 정리 — 관계와 언제 무엇을 쓸까
• 컨테이너와 쿠버네티스 — 각각의 역할과 함께 쓰는 이유
• 쿠버네티스 운영 자동화 — 이해해야 신뢰할 수 있는 이유
• 쿠버네티스 도입 전후 비교 — 운영자가 알아야 할 변화
• 쿠버네티스 도입을 막는 오해와 장벽 12가지
• EP.01 클라우드 네이티브 재해복구: 가상화 방식의 한계와 대안 — 클라우드네이티브TV, 이 글이 정리한 원 영상
• Argo CD 공식 문서 — 깃옵스 기반 선언적 배포
• Sigstore Cosign 개요 — 컨테이너 이미지 서명과 검증
• Kubernetes 공식 문서: Volume Snapshots — 볼륨 스냅샷을 통한 데이터 복제
• Velero 공식 문서 — 쿠버네티스 백업과 복구 도구
• Kubernetes 공식 문서: Deployment — 선언한 상태를 유지하는 배포 방식