IT
1. 지금의 위협은 예전과 다르다2. 수동 보호 도메인이 왜 문제인가3. 카테고리 기반 정책: "새 VM 만들면 자동으로 보호된다"4. 복구 계획(Recovery Plans): 데이터만 있어도 소용없다부팅 순서 제어 (Stage Management)네트워크 매핑과 IP 문제: 여기서 많이 막힌다동기식과 비동기식 혼합은 안 된다5. NCI 7.5: 규모와 유연성의 확장6. 테스트를 안 하면 계획이 아니다기술 말고 '사람 테스트'도 해야 한다7. NC2로 TCO 절감: Pilot Light 전략Zero Compute DR과 MSTVMware에서 Nutanix로 전환하는 팀이라면8. 보안: 복구 사이트도 Zero Trust가 필요하다네트워크 보안 정책 복제랜섬웨어 대응: 불변 스토리지와 클린룸 복구HYCU 연동AI 워크로드와 컨테이너도 보호 대상이다정리: DR 전략 점검을 위한 세 가지 기준
IT 인프라를 운영하다 보면 DR 플랜이 "있기는 한데 실제로 돌아갈지는 모르겠다"는 상태로 방치되는 경우를 종종 본다. 1년에 한 번, 주말 밤을 새워가며 하는 페일오버 테스트가 전부인 팀도 있고, 그마저도 테스트 중에 실제 서비스가 영향받아 다들 쉬쉬하는 경우도 있다.
현실에서 서비스 중단이 1시간 이어질 때 직접 손실만 억 단위를 넘는 기업이 생각보다 많다. 거기에 브랜드 이미지 손상과 고객 이탈까지 더하면 숫자는 더 커진다.
문제는 기술이 없어서가 아니다. 대부분 위협 환경이 바뀌었는데 DR 전략이 따라가지 못한 것이다.
이 글에서는 Nutanix 플랫폼 기반의 현대적인 DR 체계를 어떻게 구성할 수 있는지, 실무 관점에서 짚어보려 한다.
1. 지금의 위협은 예전과 다르다
예전 DR의 주적은 명확했다. 자연재해, 화재, 하드웨어 고장. "데이터를 멀리 있는 백업 사이트에 복사해두면 된다"는 논리가 통하던 시절이다.
지금은 상황이 다르다.
하드웨어 조달 리스크: CPU와 메모리 납기가 12개월을 넘는 상황에서, 두 번째 DR 사이트를 물리 장비로 온전히 갖추기가 쉽지 않다. 온프레미스 하드웨어 가격은 2026년 기준으로 40%까지 오를 수 있다는 분석도 나온다. 이런 상황에서 모든 DR 인프라를 온프레미스 장비에만 의존하는 건 리스크가 크다.
랜섬웨어: 최근 공격자들은 파일을 암호화하기 전에 백업 서버를 먼저 찾아서 지운다. "백업 있으면 괜찮다"는 논리가 더 이상 통하지 않는다.
규제 강화: 금융권과 헬스케어는 물론이고, 일반 기업도 SOC2나 GDPR 같은 데이터 거버넌스 요구가 점점 구체화되고 있다. "복구할 수 있다"는 말 대신 "테스트 기록과 감사 추적 문서"를 요구하는 시대다.
하이브리드의 복잡성: 온프레미스에서 시작해 하이브리드 클라우드로 확장하면서, 오히려 어느 데이터가 어디 있고 어떻게 보호되는지 파악하기가 더 어려워진 팀이 많다.
이런 환경에서 기존의 수동 백업+페일오버 방식은 근본적인 한계에 부딪혔다.
2. 수동 보호 도메인이 왜 문제인가
Nutanix를 써온 팀이라면 "보호 도메인(Protection Domain)"이 익숙할 거다. Prism Element에서 VM들을 일일이 골라 일관성 그룹에 넣고, 복제 일정을 설정하는 방식이다.
규모가 작고 환경이 고정적이라면 나름 직관적이다. 그런데 VM이 수백, 수천 개로 늘고, 개발팀이 하루에도 몇 개씩 새 VM을 만들어내는 환경에서는 보호 누락 문제가 반드시 생긴다.
개발팀이 새 데이터베이스 서버를 배포했는데, 인프라 팀이 보호 도메인에 추가하는 것을 빠뜨리는 상황이다. 이게 쌓이다가 실제 재해가 터지면, 복구해 보니 중요한 VM 몇 개가 통째로 날아간 상태가 된다.
"그런 실수를 왜 해?"라고 할 수도 있지만, 수동으로 관리해야 하는 VM이 수천 개라면 하나쯤 빠지는 건 구조적으로 막기 어렵다.
3. 카테고리 기반 정책: "새 VM 만들면 자동으로 보호된다"
Nutanix의 현대적 DR 접근법은 이 문제를 구조적으로 해결한다.
Prism Central 기반의 카테고리(Category) 태그 시스템을 사용하면, VM을 일일이 보호 도메인에 등록하는 작업 자체가 없어진다.
방식은 간단하다.
1.
관리자는 Production, Database, Tier-1 같은 비즈니스 분류에 맞는 카테고리를 만들어 두고
2.
각 카테고리에 RPO, RTO 등 보호 정책을 미리 연결한다
3.
이후 개발팀이 VM을 만들 때 카테고리 태그만 붙이면, 나머지는 자동으로 처리된다
새 VM이 생성되는 즉시 정책이 자동으로 상속되기 때문에, 누락이 구조적으로 불가능해진다. "만들었으면 이미 보호된다"는 상태가 되는 것이다.
항목 | 보호 도메인 (기존) | 카테고리 기반 (현대적) |
관리 콘솔 | Prism Element (클러스터별) | Prism Central (중앙 통합) |
보호 단위 | 수동 VM 선택 | 카테고리 태그 기반 자동 |
누락 리스크 | 수동 추가 누락 가능 | 구조적으로 누락 차단 |
운영 부담 | VM 증가할수록 비례 증가 | 태그 정책만 관리하면 됨 |
4. 복구 계획(Recovery Plans): 데이터만 있어도 소용없다
"백업은 잘 돼 있어요"라는 팀에게 꼭 물어보는 게 있다. "서비스를 올바른 순서로 복구하는 계획은 있나요?"
데이터를 복구 사이트로 잘 복제해 두었다 해도, 순서를 틀리면 다 소용없다. DNS가 안 뜬 상태에서 웹 서버를 먼저 올리거나, 데이터베이스보다 애플리케이션이 먼저 부팅되면 시스템 전체가 오류를 뱉는다.
Nutanix의 Recovery Plans는 이 복구 순서 문제를 자동화한다.
부팅 순서 제어 (Stage Management)
실제 엔터프라이즈 환경 기준으로 보통 이런 순서로 구성한다.
•
Stage 0: Active Directory, DNS, DHCP 등 기반 인프라부터 올린다. 이게 완전히 뜨기 전까지 나머지 VM 부팅은 차단된다.
•
Stage 1: DB 서버, 모니터링, 인증 서버. Stage 0 완료 후 의도적인 딜레이를 주는 것이 중요하다.
•
Stage 2 이상: 미들웨어, 웹 서버, 실제 서비스 레이어.
이 순서를 정책으로 정의해두면, 재해 상황에서 "뭐부터 올려야 하지?"를 기억에 의존할 필요가 없다. 수동 검증 수십 단계가 클릭 하나로 처리된다.
네트워크 매핑과 IP 문제: 여기서 많이 막힌다
Recovery Plan 구성할 때 의외로 자주 놓치는 부분이 있다.
복구 계획이 VM의 네트워크 인터페이스를 DR 사이트의 VLAN에 연결해주는 것은 해준다. 그런데 VM 내부 OS에 정적으로 박혀있는 IP 주소는 기본적으로 건드리지 않는다.
DR 사이트 서브넷 대역이 프라이머리 사이트와 다른 경우, VM은 올라왔는데 네트워크를 못 찾는 상황이 된다. 이를 해결하려면 두 가지가 필요하다.
•
보호 대상 VM 전체에 Nutanix Guest Tools(NGT) 설치. 이게 없으면 게스트 OS 제어가 안 된다.
•
Recovery Plan에 In-Guest 스크립트를 구성해서, 복구 후 자동으로 IP 변경, DNS 업데이트, 로드밸런서 재등록이 실행되도록 한다.
사전에 이 구성을 빠뜨리면 복구 완료 직전에 네트워크 문제로 발이 묶이는 상황이 생긴다.
동기식과 비동기식 혼합은 안 된다
설계 시 기억해둘 제약이 하나 더 있다. 단일 Recovery Plan 안에서 동기식(Sync)과 비동기식(Async/Near-Sync) 복제 방식을 혼합해서 사용할 수 없다. 둘의 복구 메커니즘이 근본적으로 달라서 충돌이 생긴다. 워크로드 특성에 맞게 복구 계획을 분리해서 구성해야 한다.
5. NCI 7.5: 규모와 유연성의 확장
NCI 7.5에서 주목할 변화는 단일 보호 정책 내에서 최대 4개 사이트로 데이터를 분산 복제할 수 있게 됐다는 점이다.
RPO 요구사항에 따라 사이트별로 다른 복제 방식을 조합할 수 있다.
•
Metro Availability (RPO 0): 근거리 동기식 복제. 금융권 핵심 데이터에 적합하다. 사이트 간 RTT 5ms 미만 유지가 필수이고, 스플릿 브레인 방지를 위해 Witness VM을 제3의 사이트에 따로 배치해야 한다.
•
NearSync (RPO 20초 ~ 15분): 거리가 멀어 Metro를 쓸 수 없는 경우에 쓴다. 대역폭 부족 시 자동으로 비동기로 전환했다가, 상황이 나아지면 다시 NearSync로 복귀하는 유연함이 장점이다.
•
MST (Multicloud Snapshot Technology): 퍼블릭 클라우드 오브젝트 스토리지에 장기 보관용으로 보내는 방식이다.
이 세 가지를 조합하면 단일 정책 아래에서 이런 구성이 가능하다.
•
사이트 A ↔ 사이트 B: Metro Sync (로컬 HA)
•
사이트 A → 사이트 C: NearSync (지역 재해 대비)
•
사이트 A → 퍼블릭 클라우드: MST (장기 보관 및 규정 준수)
그 외에 주목할 변화들:
•
VM 수용 규모가 단일 환경에서 최대 10,000개까지 확대됐다.
•
Dual Prism Central 지원: Prism Central 자체가 장애나도 다른 쪽 PC가 오케스트레이션을 이어받는다.
•
Pure Storage 연동: 기존 Pure Storage SAN을 쓰는 AHV 환경에 Prism Central 기반 비동기 복제를 얹을 수 있다. VMware에서 Nutanix AHV로 전환하려는데 기존 스토리지 자산이 걱정됐던 팀들에게 현실적인 선택지가 생긴 셈이다.
6. 테스트를 안 하면 계획이 아니다
많은 팀이 DR 테스트를 꺼리는 이유는 단순하다. 테스트 자체가 운영 환경에 영향을 주기 때문이다. 실제로 예전 방식에서는 DR 테스트 도중 실수로 실제 서비스 중단이 생기는 경우도 있었다.
그러다 보니 대부분 팀에서 DR 테스트는 1년에 한두 번, 제한된 범위에서만 형식적으로 하는 수준이 됐다.
Nutanix의 Test Bubble 기능은 이 문제를 다르게 풀었다.
테스트 실행 시 라이브 데이터가 아닌 최신 복제 스냅샷을 가져와서, 완전히 격리된 Layer 2 가상 네트워크에서 VM들을 올린다. 이 샌드박스는 물리 네트워크와 라우팅이 원천적으로 단절되어 있어서, 테스트 VM들이 프로덕션 VM과 같은 IP로 뜨더라도 충돌이 없다.
결과적으로 업무 시간에도 테스트가 가능하고, 서비스 영향 없이 실제 부팅 순서와 In-Guest 스크립트 동작을 전부 확인할 수 있다. 테스트 결과는 자동으로 감사 추적 보고서로 생성된다. 규제 요구사항 대응을 위해 별도로 문서를 만들 필요가 없어진다.
기술 말고 '사람 테스트'도 해야 한다
DR 테스트에서 자주 빠뜨리는 게 있다. 기술적인 복구보다 "사람이 실제로 원격에서 복구를 실행할 수 있는가"다.
•
재해 발생 시 인프라 팀이 VPN을 통해 복구 도구에 접근할 수 있는가?
•
런북과 비밀번호 관리 도구가 장애가 난 프라이머리 사이트 서버에만 저장되어 있지는 않은가?
•
내부 이메일과 슬랙이 다운됐을 때 팀 간 소통할 외부 채널이 있는가?
•
DR 사이트 IP에서도 외부 서비스 연동이 정상 동작하도록 화이트리스트 설정이 되어 있는가?
이런 인적, 운영적 측면까지 포함한 "버그 아웃(Bug Out) 시나리오"를 정기적으로 훈련하는 팀이 실제 재해에서도 빠르게 대응한다.
7. NC2로 TCO 절감: Pilot Light 전략
기존 DR 구성에서 가장 큰 비용 문제는 DR 사이트의 하드웨어가 평소엔 거의 안 쓰인다는 거다. 재해가 언제 올지 모르니 항상 켜두어야 하고, 그 유지비가 매달 나간다.
Nutanix Cloud Clusters(NC2) + Pilot Light 전략은 이 문제를 다르게 접근한다.
1.
평소엔 VM 데이터를 AWS S3 같은 저렴한 오브젝트 스토리지에 지속 복제해 둔다.
2.
비용의 대부분을 차지하는 컴퓨팅 노드는 Hibernate 상태로 꺼둔다. 이때는 컴퓨팅 비용이 발생하지 않는다.
3.
실제 재해 시에만 Resume 버튼으로 클러스터를 깨워 서비스를 올린다.
컴퓨팅 비용이 실제로 필요한 순간에만 발생하기 때문에 전체 TCO가 크게 줄어든다. Nutanix 측에서는 최대 53%까지 절감 가능하다고 밝힌다.
온프레미스 워크로드를 그대로 클라우드로 확장하는 방식이라 리팩토링이 필요 없다는 것도 장점이다. 기존에 쓰던 툴과 프로세스를 그대로 쓸 수 있다.
Zero Compute DR과 MST
MST 기능은 한 단계 더 나아간다. 라이브 클러스터를 기동하지 않고도 온프레미스 스냅샷을 퍼블릭 클라우드 오브젝트 스토리지로 직접 전송한다.
NCI 7.5 기준으로 최대 1PB 규모의 데이터와 5,000개 엔티티까지 지원한다. 클라우드 컴퓨팅 노드를 하나도 쓰지 않으면서도 대용량 데이터를 클라우드에 보관하는 'Zero Compute DR'이 가능해진다. 하드웨어 조달이 막히는 상황에서도 데이터 보호를 유지하는 현실적인 방법이다.
VMware에서 Nutanix로 전환하는 팀이라면
Broadcom의 VMware 인수 이후 라이선스 비용 이슈로 Nutanix 전환을 검토하는 팀들이 늘었다. 이때 주의할 게 있다. 마이그레이션 자체가 또 다른 서비스 중단의 원인이 되면 안 된다.
Nutanix Move 툴을 쓰면 기존 VMware VM을 리팩토링 없이 AHV로 이전할 수 있다. HD한국조선해양이 이 방식으로 전환해 TCO 30%를 절감했고, 현대엔지니어링은 가상화 구축 기간을 3개월에서 1개월 이내로 줄인 사례가 있다.
8. 보안: 복구 사이트도 Zero Trust가 필요하다
DR 사이트를 잘 구성해도, 보안 설정이 프라이머리보다 느슨하면 문제가 생긴다. 랜섬웨어가 메인 사이트를 감염시킨 후 복구 사이트로 그대로 옮겨타는 시나리오가 실제로 있다.
네트워크 보안 정책 복제
NCI 7.5의 VPC Policy Sync 기능은 프라이머리 사이트에 설정된 Flow Network Security 정책을 DR 사이트에 자동으로 동기화한다. 마이크로 세그멘테이션 정책, VLAN 규칙, VPC 구성 등 최대 1,000개까지 복제된다.
VM이 DR 사이트에서 뜨는 순간부터 프라이머리와 동일한 Zero Trust 정책이 적용된다. 복구 직후 보안 구성을 수동으로 다시 맞춰야 하는 공백이 없어진다.
랜섬웨어 대응: 불변 스토리지와 클린룸 복구
랜섬웨어 방어에서 핵심은 두 가지다.
첫째, 백업 데이터를 건드릴 수 없게 만들기. Nutanix Objects의 WORM(Write Once Read Many) 정책으로 백업 데이터에 불변성을 적용한다. 관리자 계정이 탈취되더라도 백업을 삭제하거나 수정할 수 없다.
둘째, 복구 전에 감염 여부 확인하기. 랜섬웨어 감염이 의심될 때, 오염된 스냅샷을 바로 프로덕션으로 올리는 건 위험하다. 외부 네트워크와 완전히 격리된 클린룸 환경에 먼저 복구해서 바이러스 스캔 및 무결성 검증을 마친 후, 이상 없을 때만 실제 서비스로 올리는 방식이다.
Nutanix Data Lens(NDL)의 랜섬웨어 탐지 기능은 비정상적인 암호화 시도를 감지하면 자동으로 격리 조치를 취한다.
HYCU 연동
서드파티 솔루션인 HYCU는 Nutanix Prism과 AHV 가상화 레이어, Nutanix Database Service, NC2 환경까지 네이티브 수준으로 통합된다. 에이전트 없이 VM과 애플리케이션 컨텍스트를 인식하며 백업을 처리하고, RBAC와 MFA 기반의 접근 제어를 제공한다.
AI 워크로드와 컨테이너도 보호 대상이다
VM만 보호하면 끝나지 않는다. 수개월 학습시킨 AI 모델 데이터가 날아가는 것도 재해다.
Nutanix는 Cisco HCI C240 M7에 NVIDIA L40S GPU를 결합한 AI 워크로드 보호 아키텍처를 제공하고, Enterprise AI Gateway 2.6이 모델 데이터 거버넌스를 담당한다.
쿠버네티스 환경이라면 NKP(Nutanix Kubernetes Platform)와 연동된 NDK가 컨테이너 영구 볼륨까지 VM 수준의 데이터 보호를 확장한다. NKP Starter 에디션은 NCI Pro/Ultimate 구독 고객에게 추가 비용 없이 제공된다.
정리: DR 전략 점검을 위한 세 가지 기준
첫째, 보호 누락이 구조적으로 불가능한 환경인가. VM이 생성되는 즉시 보호가 시작되어야 한다. 수동 등록에 의존하는 구조는 규모가 커질수록 위험해진다. 카테고리 기반 정책 상속이 이 문제를 해결한다.
둘째, 운영 영향 없이 상시 테스트가 가능한가. 테스트하기 어려운 DR 플랜은 실제로 안 된다고 봐야 한다. Test Bubble처럼 서비스 중단 없이 언제든 테스트하고 감사 증적도 남길 수 있는 환경이 필요하다.
셋째, 비용 구조가 지속 가능한가. 아무리 좋은 DR 구성도 유지 비용이 너무 크면 결국 흐지부지된다. NC2 Pilot Light 모델처럼 평소엔 스토리지 비용만, 필요할 때만 컴퓨팅을 쓰는 방식이 현실적인 대안이다.
지금 운영 중인 인프라의 복구 계획이 어느 수준에 있는지 한번 점검해보자. 특히 마지막으로 테스트한 날짜와 그때 IP 매핑이 현재 환경과 일치하는지부터 확인하는 것을 권한다.
'BLOGGER' 구독하기
사이트를 구독하면 새 포스트 등 최신 업데이트를 알림과 메일로 가장 먼저 받아보실 수 있습니다.
Slashpage에 가입하고 'BLOGGER'을 구독하세요!
Slashpage에 가입하고 'BLOGGER'을 구독하세요!
