VMware와 같은 가상머신(VM) 환경을 사용하던 기업이 다른 VM 솔루션으로 갈아타는 사례가 늘고 있습니다. 브로드컴의 VMware 인수 이후 라이선스 비용 상승 우려 등으로 ‘탈(脫) VMware’ 움직임이 나타나면서, 일부 기업은 퍼블릭 클라우드의 IaaS(인프라형 서비스)나 하이퍼컨버지드 인프라(HCI) 등 다른 VM 환경으로의 전환을 검토하고 있습니다.

그러나 이렇게 한 VM에서 다른 VM으로 갈아탄다고 해서 근본적인 IT 환경이 개선되지는 않습니다. 결국 운영 중인 시스템을 여기저기로 옮겨 놓는 수고만 들 뿐,클라우드 네이티브와 같은 혁신적인 이점은 얻기 어렵습니다.

아래에서 그 이유를 살펴보겠습니다.

가상머신(Virtual Machine, VM)은 하이퍼바이저(Hypervisor)를 통해 물리 자원을 추상화하고, 각 VM 내부에 독립적인 커널과 운영체제(Guest OS)를 포함하는 완전한 시스템 환경을 제공합니다. 이러한 구조는 프로세스 격리와 보안 측면에서는 이점이 있지만, OS 단위의 중복이 필연적으로 발생하며 리소스 효율성과 운영 복잡성 측면에서 한계를 내포합니다.

VMware 환경에서 운영하던 VM을 클라우드 서비스 제공업체(CSP)의 IaaS VM으로, 혹은 사내의 다른 하이퍼바이저(KVM, Hyper-V 등) 환경으로 옮기는 시나리오를 생각해 보십시오. 무엇이 근본적으로 변할까요?

정답은 ‘아무것도 변하지 않는다’입니다.

이는 실질적으로 동일한 가상화 아키텍처를 유지한 채 단지 하이퍼바이저만 교체하는 것에 불과합니다. 이 경우 애플리케이션은 여전히 Guest OS 상에 종속되며, OS별로 관리 주체가 필요하고, 커널 패치, 업데이트, 보안 강화, 라이선스 관리 등의 운영 부담은 변화 없이 유지됩니다.

VM 에서 다른 VM 환경으로 전환은 마치 구조가 개선되는 것처럼 보일 수 있으나, 실제로는 다음과 같은 문제를 그대로 유지합니다:

• OS 단위 중복 운영: 각 VM에 독립된 OS 인스턴스가 존재하여 메모리/스토리지 자원을 과잉 소비
• 패치 및 보안 관리의 복잡도 지속: Guest OS 마다 개별적으로 보안 정책과 업데이트를 적용해야 함
• 라이선스 관리 및 비용 누적: 커머셜 OS의 경우 VM 수 만큼 라이선스가 중복 부여됨
• 부팅 지연과 오버헤드: VM은 커널 초기화 및 시스템 서비스 구동으로 인한 기동 시간 증가

따라서 VM 기반 인프라에서 다른 VM 플랫폼으로의 마이그레이션은 ‘기술적 리프레시’의 의미는 가질 수 있어도, 운영 효율성, 개발 생산성, 애플리케이션 탄력성 측면에서는 아무런 개선을 제공하지 않습니다.

더 큰 문제는 애플리케이션 아키텍처와 운영 프로세스가 그대로라는 점입니다. VM 플랫폼을 바꿔도 기존 레거시 애플리케이션이 모놀리식(거대 단일 애플리케이션) 구조라면, 단지 그것을 새로운 VM 위로 “들어서 옮긴(Lift & Shift)” 것에 불과합니다. 실제로 과거의 클라우드 전환은 “레거시 시스템을 그대로 클라우드 환경으로 이전하는 수준”에 그쳤습니다 이렇게 코드 수정이나 아키텍처 변경 없이 VM만 옮기는 방식은 현 상태를 유지한 채 인프라만 바꾸는 빠른 방법이지만, 모던한 기술 도입이나 표준 개선이 전혀 이루어지지 않습니다. 다시 말해 새 기술에 대한 학습이나 코드 개선이 없으니, 달라지는 것은 운영자 입장에서 사용하는 관리도구 정도뿐입니다.

하이퍼바이저의 브랜드만 바뀔 뿐, ‘OS라는 거대한 종속성‘으로부터 단 한 걸음도 벗어나지 못합니다. 결국 이러한 편의는 “벤더(또는 구현자)에게만 이득일 뿐 최종 사용자(기업)에게는 이득이 아니다”라는 지적도 있습니다.

컨테이너 기술로의 전환은 OS로부터의 해방이라는 매력적인 약속을 합니다. 컨테이너는 호스트 OS의 커널을 공유하며 애플리케이션과 그 종속성(라이브러리, 바이너리 등)만을 격리된 공간(Userspace)에 패키징합니다. 이는 놀라운 수준의 가벼움과 이식성을 제공합니다. 하지만 여기서 많은 분들이 간과하는 지점이 있습니다.

컨테이너는 호스트 OS의 커널을 공유하며, 사용자 공간(User Space)에 애플리케이션과 그 종속성만을 패키징합니다. 이를 통해 다음과 같은 장점이 발생합니다:

• 커널 공유를 통한 자원 최적화: 중복 OS가 제거되며, 메모리와 스토리지 자원 사용량이 대폭 절감
• 빠른 프로비저닝: 컨테이너는 VM 대비 수 초 내로 기동 가능
• 라이프사이클 단순화: OS 패치, 보안 관리가 호스트 단위로 통합됨
• CI/CD 및 Immutable Infrastructure에 적합: 인프라 변경을 코드화하고 재현 가능성을 확보

그러나 VM 위에 컨테이너를 배포하는 경우, 이로 인해 이중 모니터링, 이중 장애 대응, 이중 보안 관리라는 운영 오버헤드가 추가될 수 있습니다.

VM 환경에서 컨테이너를 운영한다면, 우리는 결국 ‘컨테이너를 실행하기 위한 Guest OS’ 즉 컨테이너를 위한 Guest OS를 추가로 운영해야 하므로 VM과 컨테이너 두 환경의 관리 포인트가 공존하게 됩니다. 즉, VM이라는 큰 상자 안에 컨테이너라는 작은 상자를 넣는 꼴이 되며, 상자 두 개를 모두 관리해야 하는 이중고에 시달릴 수 있습니다.

근본적인 운영 혁신은 VM 간 마이그레이션이 아니라, 애플리케이션의 배포 단위를 컨테이너로 표준화하고, 이를 쿠버네티스 (Kubernetes) 와 같은 오케스트레이션 플랫폼 위에서 운영하는 클라우드 네이티브 아키텍처의 도입을 통해 이루어집니다.

이러한 구조에서는

• OS는 단지 컨테이너 런타임을 위한 최소 기반으로 축소
• 애플리케이션은 YAML 기반의 선언형 구성과 GitOps 방식으로 통합 관리
• 서비스 디스커버리, 오토스케일링, 롤링 업데이트 등 고도화된 운영 기법이 기본 제공
• 인프라의 상태를 코드 수준에서 감시하고, 정책 기반 제어가 가능

결론적으로, VM에서 다른 VM으로의 전환은 단지 하드웨어 추상화 계층의 교체일 뿐이며, 레거시 아키텍처와 운영 부담이라는 본질적인 한계를 타개하지 못합니다. 반면, 클라우드 네이티브로의 전환은 운영 단순화, 애플리케이션 이식성, 자원 효율화, 자동화된 운영을 실현할 수 있는 기술적 전환점입니다.

DevOps 구현, 운영 자동화, 하이브리드 클라우드 활용 측면에서도 달라지는 것이 없습니다.

VM 환경을 옮긴다고 해서 CI/CD 파이프라인이 자동 생기는 것도 아니고, 새로운 플랫폼에 맞춰 운영을 자동화하는 도구가 저절로 구축되는 것도 아닙니다. 예를 들어 컨테이너 및 쿠버네티스 같은클라우드 네이티브 플랫폼을 도입해야만 비로소 자동화와 이식성의 이점을 살릴 수 있습니다.

쿠버네티스는 컨테이너화된 애플리케이션을 자동 배포하고 스케일링하며, 장애가 발생하면 스스로 치유(self-healing)하는 기능까지 제공합니다. 이러한 클라우드 네이티브 운영환경이 아니고서는 멀티클라우드·하이브리드 환경을 일관되게 관리하기 어렵습니다. 단순 VM 이전으로는 여러 환경에 걸친 워크로드 이식성이나 자동 확장 같은 혜택을 기대하기 어렵습니다.

DevOps 문화의 핵심은 ‘Immutable Infrastructure(불변 인프라)’ 개념에 있습니다. 즉, 한번 배포된 인프라(서버, 컨테이너 등)는 변경하지 않고, 변경이 필요할 경우 기존 인프라를 폐기하고 새로운 버전으로 교체하는 방식입니다. 이는 예측 가능성을 높이고, 구성 오류(Configuration Drift)를 방지하며, 빠르고 안정적인 배포를 가능하게 합니다.

하지만 거대한 Guest OS를 포함한 VM은 본질적으로 ‘Mutable(가변)’합니다. 우리는 운영 중인 VM에 접속해 설정을 바꾸고, 패치를 적용하며, 애플리케이션을 업데이트합니다. 이러한 ‘눈송이 서버(Snowflake Server)’들은 각각 미세하게 다른 구성을 갖게 되어 자동화의 걸림돌이 됩니다. VM을 다른 VM 환경으로 옮긴다고 해서 이 본질이 바뀌지 않습니다. 여전히 우리는 스크립트 기반의 불안정한 자동화에 의존하거나, 수동 작업의 늪에서 벗어나기 어렵습니다.

반면, 컨테이너와 쿠버네티스는 불변 인프라를 완벽하게 지원합니다. 컨테이너 이미지는 그 자체로 완전하고 불변하는 배포 단위이며, 쿠버네티스는 선언적 API를 통해 원하는 상태를 정의하면 현재 상태를 그에 맞게 자동으로 조정해 줍니다. 이것이 진정한 의미의 자동화입니다.

VM 간 이전이 하이브리드 클라우드 전략에 도움이 될 것이라는 기대 역시 환상에 가깝습니다. 각 하이퍼바이저와 클라우드 플랫폼은 서로 다른 VM 이미지 포맷(VMDK, VHD, QCOW2 등)과 네트워크, 스토리지 구성을 사용합니다. 한 환경의 VM을 다른 환경으로 옮기기 위해서는 복잡한 변환 과정과 수동 재구성 작업이 필수적입니다. 이는 워크로드의 이동성을 심각하게 저해하며, 특정 벤더나 플랫폼에 대한 종속성(Lock-in)을 심화시킬 뿐입니다.

진정한 워크로드 이식성은 OCI(Open Container Initiative) 표준을 따르는 컨테이너 이미지에서 나옵니다. 동일한 컨테이너 이미지는 온프레미스 쿠버네티스 클러스터, AWS의 EKS, Google의 GKE, Azure의 AKS 등 어디서든 수정 없이 동일하게 실행될 수 있습니다. 이것이 바로 기업이 원하는 진정한 의미의 하이브리드/멀티 클라우드 유연성입니다.

VM 플랫폼만 바꾼 상태에서는 기존 환경의 단점이 그대로 남습니다. 운영팀 입장에서도 익숙한 방식이라 편할 뿐, 새로운 기술 역량이 생기는 것이 아니므로 혁신이나 비용 효율 측면의 개선은 없습니다.

가트너도 전통적인 리프트앤시프트식 접근은 클라우드의 이점을 살리지 못하고 유지보수 복잡성만 키운다고 지적했으며, 결국 이런 방식은 필연적으로 나중에 클라우드 네이티브 재구축을 해야 하는 일의 연장선일 뿐 이라고 분석했습니다. 실제로 “리프트앤시프트는 결국 향후 클라우드 네이티브로 재설계해야 할 작업을 미뤄두는 것에 불과하며, 그 과정에서도 용량, 인력, 비용, 시간 투자는 여전히 든다”고 합니다.

다시 말해 지금 이사를 가든, 나중에 다시 집을 개조하든 결국 두 번 투자 하게 된다는 뜻입니다.

진정한 변화는 애플리케이션의 배포 단위를 컨테이너로 표준화하고, 이를 쿠버네티스와 같은 컨테이너 오케스트레이션 플랫폼 위에서 관리하는 ‘클라우드 네이티브’ 패러다임으로의 전환에서 시작됩니다. 이 패러다임은 OS를 애플리케이션의 일부가 아닌, 컨테이너를 실행하기 위한 최소한의 기반(Underlying Infrastructure)으로 취급하게 만듭니다. VM에서 다른 VM으로의 이전은 이러한 근본적인 패러다임 전환과는 거리가 먼, 단순한 ‘이사’에 불과합니다.

그렇다면 왜 많은 조직이 여전히 VM에서 VM으로의 전환을 고려하는 것일까요? 그 이면에는 ‘운영자의 익숙함‘이라는 강력한 관성이 자리 잡고 있습니다. 시스템 관리자들은 수년간 리눅스나 윈도우 서버를 관리해 온 경험이 있습니다. VM에 접속해 명령어를 입력하고, 설정 파일을 수정하는 방식이 손에 익숙합니다. VM 환경이 바뀌더라도 이 운영 방식은 크게 변하지 않으므로, 변화에 대한 심리적 저항이 적습니다.

하지만 이 ‘익숙함’은 값비싼 대가를 치릅니다.

첫째, 비용 효율성이 없습니다.

VM을 다른 곳으로 옮기는 프로젝트 자체에 상당한 시간과 인력, 그리고 잠재적 다운타임 리스크라는 비용이 발생합니다. 이는 마치 낡은 가구를 구조가 똑같은 옆집으로 옮기는 것과 같습니다. 이사하는 수고만 들었을 뿐, 생활 환경은 전혀 나아지지 않습니다. 오히려 운영체제 라이선스 비용, 더 높은 사양의 인스턴스 비용 등 눈에 보이지 않는 비용은 그대로 유지되거나 증가할 수 있습니다.

둘째, 인력의 성장 기회를 박탈합니다.

기존의 운영 방식을 고수하는 것은 팀원들이 클라우드 네이티브 기술 스택(컨테이너, 쿠버네티스, 서비스 메시, GitOps 등)을 학습하고 경험할 기회를 빼앗는 것과 같습니다. 이는 장기적으로 조직의 기술 경쟁력을 약화시키고, 유능한 엔지니어들이 성장의 기회를 찾아 떠나게 만드는 요인이 될 수 있습니다.

IT전문가로서 우리가 던져야 할 질문은 “우리의 VM을 어디로 옮길까?”가 아닙니다.

“우리의 애플리케이션과 인프라를 어떻게 현대화하여 비즈니스 민첩성을 확보할까?”가 되어야 합니다.

VM에서 다른 VM으로의 전환은 이 질문에 대한 해답이 될 수 없습니다. 그것은 문제를 해결하는 것이 아니라, 문제를 다른 장소로 옮겨 놓는 것에 불과합니다.

진정한 변화는 애플리케이션을 더 작고 독립적인 서비스(MSA, Microservices Architecture)로 분해하고, 이를 컨테이너로 패키징하며, 쿠버네티스 위에서 탄력적으로 운영하는 클라우드 네이티브로의 여정에서 시작됩니다. 물론 이 길은 처음에는 더 어렵고 많은 학습을 요구합니다. 하지만 이 길만이 OS 종속성에서 벗어나고, 진정한 자동화를 구현하며, 어떤 클라우드 환경에서든 자유로운 하이브리드 전략을 구사할 수 있게 해주는 유일한 길입니다.

• 클라우드 송환 이란 무엇인가? 왜 지금 주목받는가?
• 가상화 엔지니어가 Kubernetes 를 이해하지 못하는 이유는?
• Kubernetes (쿠버네티스) 도입을 가로막는 오해와 장벽 12가지
• 불변의 인프라스트럭처(Immutable Infrastructure) 란 무엇인가?
• [자료 다운로드] 불변의 인프라스트럭처란? | 클라우드 시대의 새로운 운영 패러다임