Booil Jung

하이퍼바이저

초기 컴퓨터 시스템은 하나의 물리적 하드웨어에서 단 하나의 운영체제(OS)만을 실행할 수 있었으며, 이는 컴퓨팅 자원이 상당 부분 유휴 상태로 남아 낭비되는 근본적인 비효율성 문제를 야기했다.1 이러한 한계를 극복하기 위해 1960년대 IBM 메인프레임에서 처음 등장한 가상화 개념은 자원 활용률을 극대화하기 위한 혁신적인 해법을 제시했다.3 이 가상화 기술을 구현하는 핵심 소프트웨어 계층이 바로 하이퍼바이저(Hypervisor)이다. ‘하이퍼바이저’라는 용어는 당시 운영체제의 핵심 커널을 ‘슈퍼바이저(Supervisor)’라고 부르던 것에서 유래했으며, 이를 넘어선 상위 관리자라는 의미를 내포한다.3

오늘날 하이퍼바이저는 현대 IT 인프라의 표준 기술로 확고히 자리 잡았다. 물리적 서버의 활용도를 극대화하고 4, 데이터센터 운영을 통합하며 7, 기업 환경에 필수적인 유연성과 확장성을 제공한다.1 특히, Amazon Web Services(AWS), Microsoft Azure, Google Cloud 등 모든 주요 퍼블릭 클라우드 서비스 제공업체는 하이퍼바이저 기반의 가상화 기술을 통해 IaaS(Infrastructure as a Service), PaaS, SaaS와 같은 핵심 서비스를 제공하며, 이는 클라우드 컴퓨팅 경제의 근간을 이룬다.2

본 보고서는 하이퍼바이저의 기본 개념과 아키텍처 유형론에서 시작하여, CPU, 메모리, I/O 가상화를 가능하게 하는 핵심 기술들을 심층적으로 분석한다. 이후 VMware, KVM, Hyper-V 등 시장을 주도하는 주요 하이퍼바이저 생태계를 비교하고, 라이브 마이그레이션과 가상 데스크톱 인프라(VDI) 같은 고급 활용 사례를 살펴본다. 또한, 하이퍼재킹(Hyperjacking)과 같은 중대한 보안 위협과 그에 대한 방어 전략, 시장 동향 및 복잡한 라이선스 모델의 변화를 조망한다. 마지막으로, 컨테이너, 마이크로VM, 유니커널과 같은 새로운 기술 패러다임과의 관계 속에서 하이퍼바이저의 미래 진화 방향을 고찰하며 마무리한다.

이 장에서는 하이퍼바이저의 본질을 정의하고, 가장 기본적인 분류 체계인 타입 1과 타입 2 아키텍처를 다각도로 비교 분석하여 기술 선택의 근본적인 트레이드오프를 이해한다.

하이퍼바이저는 가상 머신 모니터(Virtual Machine Monitor, VMM)라고도 불리며, 단일 물리적 하드웨어(호스트) 위에 각기 다른 운영체제를 가진 여러 개의 가상 머신(게스트)을 생성하고 실행하는 소프트웨어 계층이다.1 하이퍼바이저의 핵심 역할은 물리적 리소스, 즉 CPU, 메모리, 스토리지, 네트워크 자원을 하나의 거대한 풀(Pool)로 묶어 추상화하고, 각 가상 머신(VM)의 요구에 따라 필요한 만큼 논리적으로 분할하여 할당하는 것이다.1

이 과정을 통해 하이퍼바이저는 VM 간의 완벽한 격리(Isolation)를 보장한다. 이는 가상화의 가장 중요한 가치 중 하나로, 하나의 VM에서 발생하는 시스템 충돌이나 보안 침해가 다른 VM의 운영에 전혀 영향을 미치지 않도록 하여 전체 시스템의 안정성과 신뢰성을 크게 향상시킨다.1 각 게스트 VM은 자신이 마치 독립된 물리적 하드웨어를 단독으로 사용하는 것처럼 작동하며, 자신이 가상화된 환경에서 실행되고 있다는 사실이나 다른 VM과 물리적 리소스를 공유하고 있다는 사실조차 인지하지 못한다.12

하이퍼바이저는 그 아키텍처, 즉 하드웨어와의 상호작용 방식에 따라 크게 두 가지 유형으로 분류된다.

타입 1 (네이티브/베어메탈 하이퍼바이저): 이 유형의 하이퍼바이저는 물리적 서버의 하드웨어 위에 직접 설치되어 실행된다. 즉, 별도의 호스트 운영체제 없이 하이퍼바이저 자체가 운영체제와 같은 역할을 수행하며 하드웨어를 직접 제어한다.6 ‘베어메탈(Bare-metal)’이라는 이름은 아무것도 없는 금속 위에 직접 설치된다는 의미에서 유래했다.

• 대표 예시: VMware ESXi, Microsoft Hyper-V, Xen, Kernel-based Virtual Machine (KVM), Proxmox VE.11

타입 2 (호스트형 하이퍼바이저): 이 유형은 Windows, macOS, Linux와 같은 기존의 호스트 운영체제 위에 하나의 애플리케이션처럼 설치되어 실행된다.13 하이퍼바이저는 호스트 OS를 통해 하드웨어 자원에 접근하며, VM은 호스트 OS의 프로세스로 관리된다.

• 대표 예시: Oracle VirtualBox, VMware Workstation/Player, Parallels Desktop for Mac, QEMU (소프트웨어 에뮬레이션 모드).11

타입 1과 타입 2 하이퍼바이저의 선택은 단순한 기술 선호의 문제가 아니라, 성능, 보안, 관리, 비용 등 다양한 요소 간의 트레이드오프를 고려한 전략적 결정이다.

• 성능: 타입 1 하이퍼바이저는 호스트 OS라는 중간 계층이 존재하지 않아 소프트웨어 오버헤드가 적고, 하드웨어에 직접 접근하여 리소스를 할당하므로 월등한 성능을 제공한다.19 반면, 타입 2는 모든 하드웨어 요청이 호스트 OS를 거쳐야 하므로 추가적인 지연 시간(Latency)이 발생하며 성능이 상대적으로 낮다.5
• 보안: 보안 관점에서 타입 1은 하이퍼바이저 자체에만 집중하면 되므로 공격 표면(Attack Surface)이 작고, VM 간의 격리 수준이 높아 근본적으로 더 안전한 구조를 가진다.5 타입 2는 하이퍼바이저 자체의 보안뿐만 아니라 기반이 되는 호스트 OS의 보안에도 의존한다. 만약 호스트 OS에 보안 취약점이 존재한다면, 그 위에서 실행되는 모든 VM이 위험에 처할 수 있다.22
• 관리 용이성 및 비용: 타입 2는 일반 애플리케이션처럼 설치가 간편하고 기존의 데스크톱 환경을 그대로 활용할 수 있어, 여러 OS를 테스트하려는 개인 사용자나 개발자에게 매우 편리하며 초기 비용이 저렴하다.12 반면, 타입 1은 설치와 구성이 상대적으로 복잡하고, 관리를 위해 별도의 관리용 콘솔이나 원격 PC가 필요하여 전문 지식이 요구된다. 하지만 수백, 수천 개의 VM을 안정적으로 운영해야 하는 대규모 엔터프라이즈 데이터센터 환경에서는 타입 1이 필수적인 선택이다.12

이러한 명확한 구분 속에서 KVM과 같은 하이퍼바이저는 독특한 위치를 차지한다. KVM은 리눅스 커널의 일부인 모듈로 동작하기 때문에, 호스트 OS(리눅스)가 필요하다는 점에서는 타입 2와 유사해 보인다. 그러나 KVM은 커널의 핵심적인 부분으로서 하드웨어 가속 기능을 직접 활용하고, VM을 일반 리눅스 프로세스처럼 관리하면서도 타입 1에 필적하는 성능과 격리를 제공한다. 이 때문에 종종 ‘타입 1.5’ 하이퍼바이저로 불리기도 하며 12, 이는 순수한 베어메탈이나 호스트형 모델에서 벗어나, OS와의 긴밀한 통합을 통해 관리 편의성과 고성능을 동시에 달성하려는 현대 하이퍼바이저 아키텍처의 진화 방향을 보여준다. Microsoft의 Hyper-V 역시 OS 역할로 설치되지만, 하이퍼바이저 계층이 하드웨어 바로 위에서 작동하는 유사한 하이브리드 아키텍처를 채택하고 있다.3

비교 항목	타입 1 (베어메탈/네이티브)	타입 2 (호스트형)
아키텍처 (위치)	물리 하드웨어 위에 직접 설치 및 실행	호스트 운영체제(OS) 위의 애플리케이션으로 실행
성능	오버헤드가 적고 하드웨어를 직접 제어하여 고성능 제공 19	호스트 OS를 경유하여 하드웨어에 접근하므로 지연 시간 발생 및 성능 저하 5
보안	공격 표면이 작고 VM 간 격리 수준이 높아 더 안전함 19	호스트 OS의 취약점을 상속받을 수 있어 상대적으로 보안에 취약함 25
안정성	호스트 OS가 없어 불안정성 위험이 적고, 한 VM의 문제가 다른 VM에 영향을 미치지 않음 6	호스트 OS의 안정성에 직접적인 영향을 받음 5
관리 용이성	전문 지식이 필요하며 별도의 관리 콘솔이 요구되어 구성이 복잡함 18	일반 애플리케이션처럼 설치 및 사용이 간편하여 사용자 친화적임 19
주요 사용 사례	엔터프라이즈 데이터센터, 클라우드 컴퓨팅, 프로덕션 서버 환경 12	개인용 PC, 개발 및 테스트 환경, 여러 OS 동시 사용 11
대표 제품	VMware ESXi, Microsoft Hyper-V, KVM, Xen, Proxmox VE 11	Oracle VirtualBox, VMware Workstation, Parallels Desktop 11

이 장에서는 하이퍼바이저가 가상 머신을 구현하는 데 사용하는 CPU, 메모리, I/O 관련 핵심 기술들을 기술적으로 깊이 파고들어, 가상화의 성능과 효율성이 어떻게 확보되는지 그 원리를 규명한다. 가상화 기술의 발전 과정은 하이퍼바이저의 소프트웨어적 중재를 최소화하고, 하드웨어의 역할을 극대화하는 방향으로 전개되어 왔다. 이는 가상화의 근본적인 성능 병목 지점이 하이퍼바이저의 개입 행위 자체에 있음을 방증하며, 성능에 민감한 데이터 경로(Data Path)는 하드웨어에 맡기고 하이퍼바이저는 제어 경로(Control Path)에 집중하는 아키텍처로 진화해왔음을 보여준다.

하드웨어 가상화 지원(Hardware-Assisted Virtualization): 초기 x86 아키텍처는 가상화에 필요한 조건을 만족하지 못해, 하이퍼바이저는 민감한 명령어를 스캔하고 동적으로 코드를 수정하는 바이너리 변환(Binary Translation)과 같은 복잡하고 성능 저하가 큰 소프트웨어 기법에 의존해야 했다. 2005년을 전후로 Intel이 VT-x(Virtualization Technology)를, AMD가 AMD-V(AMD Virtualization)를 도입하면서 이 문제가 하드웨어 수준에서 해결되었다.35

작동 원리: Root & Non-Root 모드: VT-x 기술의 핵심은 CPU에 기존의 보호 링(Ring 0-3)과는 별개의 새로운 실행 모드를 도입한 것이다. 바로 하이퍼바이저가 실행되는 ‘VMX root mode’와 게스트 VM이 실행되는 ‘VMX non-root mode’이다.35 게스트 OS는 non-root 모드의 가장 높은 권한 수준인 Ring 0에서 실행되어 대부분의 명령어를 네이티브 속도로 처리할 수 있다. 그러나 시스템 전체에 영향을 미치는 특정 권한 명령어(privileged instruction)를 실행하려고 하면, CPU는 이를 감지하고 ‘VM exit’이라는 이벤트를 발생시켜 제어권을 root 모드에서 대기 중인 하이퍼바이저로 강제 전환한다. 하이퍼바이저는 해당 작업을 안전하게 처리한 후, ‘VM entry’를 통해 다시 제어권을 게스트 VM으로 돌려준다.35

VMCS (Virtual Machine Control Structure): 이 모든 전환 과정은 VMCS라는 특별한 하드웨어 자료구조에 의해 제어된다. VMCS는 각 가상 CPU(vCPU)의 상태(각종 레지스터 값 등)와 VM exit 및 VM entry 시의 동작 방식을 상세히 기술하는 제어 정보를 담고 있다. 하이퍼바이저는 VMCS의 특정 비트를 설정함으로써 어떤 명령어를 실행할 때 VM exit을 발생시킬지를 결정하고, 전환 시 저장 및 복원할 상태를 지정한다.35

CPU 스케줄링: 하이퍼바이저는 한정된 수의 물리적 CPU 코어를 수많은 가상 CPU(vCPU)에 시분할 방식으로 공정하게 할당하는 스케줄러 역할을 수행한다. 예를 들어 Microsoft Hyper-V는 워크로드 특성에 따라 선택할 수 있는 다양한 스케줄러 유형을 제공한다. ‘클래식 스케줄러’는 일반적인 가상화 시나리오와 리소스 오버커밋 환경에 최적화되어 있고, ‘코어 스케줄러’는 동일한 물리 코어의 SMT(Simultaneous Multi-threading) 스레드에 다른 VM의 vCPU가 동시에 스케줄링되는 것을 방지하여 보안 격리를 강화하는 데 중점을 둔다.38 또한, 멀티스레드 애플리케이션의 스레드 간 통신 패턴을 분석하여 관련 vCPU들을 같은 물리 코어에 스케줄링함으로써 동기화 오버헤드를 줄이는 협력 스케줄링 기법도 연구되고 있다.40 대부분의 VM이 할당된 CPU 자원을 항상 100% 사용하지 않는다는 통계적 특성을 활용하여, 물리적 코어 수보다 더 많은 vCPU를 생성하여 할당하는 CPU 오버커밋(Overcommit)은 자원 활용률을 극대화하는 보편적인 기술이다.41

메모리 가상화는 CPU 가상화보다 더 복잡한 과제를 안고 있다. VM 내부의 애플리케이션이 사용하는 가상 주소(Guest Virtual Address, GVA)는 먼저 게스트 OS의 페이지 테이블을 통해 게스트 물리 주소(Guest Physical Address, GPA)로 변환된다. 하이퍼바이저는 이 GPA를 다시 호스트 시스템의 실제 물리 주소(Host Physical Address, HPA)로 한 번 더 변환해야 한다.

하드웨어 지원 (Nested/Extended Paging): 초기 하이퍼바이저는 이 2단계 주소 변환을 소프트웨어적으로 처리하기 위해 ‘섀도우 페이지 테이블(Shadow Page Tables)’이라는 기법을 사용했다. 하이퍼바이저가 각 VM의 페이지 테이블 변경을 감시하고, GVA에서 HPA로 직접 변환되는 섀도우 테이블을 유지 관리하는 방식이었으나, 이로 인한 오버헤드가 매우 컸다.43 이 문제를 해결하기 위해 Intel은 EPT(Extended Page Tables)를, AMD는 NPT(Nested Page Tables) 또는 RVI(Rapid Virtualization Indexing)라는 하드웨어 지원 기술을 도입했다. 이 기술들은 2단계 주소 변환 과정을 CPU의 메모리 관리 장치(MMU)가 직접 하드웨어적으로 처리하도록 하여, 섀도우 페이징으로 인한 성능 저하를 극적으로 개선했다.37

메모리 오버커밋(Memory Overcommit): CPU 오버커밋과 마찬가지로, 물리 메모리의 총량보다 더 많은 메모리를 VM들에 할당하는 기술이다. 이는 대부분의 VM이 할당된 메모리 전체를 항상 활발하게 사용하지 않는다는 가정에 기반하며, 유휴 상태인 VM의 메모리를 회수하여 메모리가 더 필요한 다른 VM에 동적으로 재할당함으로써 전체 서버의 메모리 사용률과 VM 집적도를 높이는 경제적인 기술이다.12

그러나 메모리 오버커밋은 경제적 효율성과 성능 안정성 사이의 위험한 줄타기와 같다. 실제 물리 메모리가 부족해지는 메모리 경합 상황이 발생하면, 하이퍼바이저는 다음과 같은 메모리 회수 기술(Memory Reclamation Techniques)들을 동원하여 여유 공간을 확보하려 시도하며, 이는 필연적으로 성능 저하를 수반한다.

• 투명한 페이지 공유 (Transparent Page Sharing, TPS): 여러 VM에서 실행되는 동일한 OS나 애플리케이션은 동일한 내용의 메모리 페이지를 다수 포함하고 있을 가능성이 높다. TPS는 이러한 중복 페이지를 찾아내 해시값으로 비교한 뒤, 동일한 페이지는 단 하나의 물리 메모리 복사본만 남기고 공유(Copy-on-Write 방식)하여 메모리를 절약하는 기술이다. 하지만 이 기술은 미세한 타이밍 차이를 이용해 다른 VM의 메모리 내용을 유추할 수 있는 캐시 사이드 채널 공격(side-channel attack)에 취약하다는 점이 발견되어, 현재 대부분의 하이퍼바이저에서는 보안상의 이유로 기본적으로 비활성화되어 있다.45
• 벌루닝 (Ballooning): 하이퍼바이저가 메모리 회수가 필요할 때 사용하는 가장 일반적인 기법이다. VM 내부에 설치된 특수 드라이버(벌룬 드라이버)를 통해 게스트 OS에게 메모리 할당을 요청한다. 이 드라이버는 게스트 OS로부터 메모리를 할당받아 사용하지 않고 ‘부풀려’ 놓기만 한다(pinning). 그러면 게스트 OS는 가용 메모리가 줄어든 것으로 인식하고, 자체적인 메모리 관리 메커니즘(페이징 등)을 통해 우선순위가 낮은 페이지들을 디스크로 스왑 아웃하여 메모리를 확보한다. 이때 벌룬 드라이버가 점유했던 물리 메모리 페이지를 하이퍼바이저가 회수하여 다른 VM에 할당하는 방식이다.44 게스트 OS와 협력하는 방식이지만, 불필요한 스와핑을 유발하여 성능을 저하시킬 수 있다.
• 메모리 압축 (Memory Compression): 디스크로 페이지를 내리는(swapping) 것보다 메모리 내에서 페이지를 압축하는 것이 더 빠르다는 점에 착안한 기술이다. 하이퍼바이저는 스왑 아웃 대상이 된 페이지들을 디스크로 보내기 전에 먼저 압축하여 메모리 내의 별도 압축 캐시에 저장한다. 이를 통해 디스크 I/O를 줄일 수 있지만, 압축 및 해제 과정에서 CPU 자원을 소모한다.45
• 하이퍼바이저 스와핑 (Hypervisor Swapping): 앞선 방법들로도 충분한 메모리를 확보하지 못했을 때 사용하는 최후의 수단이다. 하이퍼바이저가 게스트 OS의 의사와 상관없이 강제로 VM의 메모리 페이지를 디스크의 스왑 파일(.vswp 등)로 내리는 방식이다. 게스트 OS가 어떤 페이지를 활발하게 사용하는지 알 수 없기 때문에 성능에 치명적인 페이지를 스왑 아웃할 위험이 있으며, 가장 큰 성능 저하를 유발한다.44

이처럼 메모리 오버커밋은 잠재적인 성능 저하와 보안 리스크를 감수하고 경제적 이득을 취하는 운영상의 ‘정책(Policy)’에 가깝다. 따라서 성공적인 가상화 환경 구축은 기술 자체뿐만 아니라, 워크로드 특성을 정확히 이해하고 오버커밋 수준을 정교하게 조절하는 운영 역량에 크게 좌우된다.

가상 환경에서 I/O(입출력)를 처리하는 것은 성능에 큰 영향을 미친다. I/O 가상화 기술은 호환성과 성능 사이의 트레이드오프 속에서 발전해왔다.

• 소프트웨어 에뮬레이션: 가장 기본적인 방식으로, 하이퍼바이저가 실제 하드웨어를 본떠 가상의 I/O 장치(예: 가상 네트워크 카드)를 완전히 소프트웨어로 구현한다. VM의 I/O 요청은 하이퍼바이저에 의해 가로채져 에뮬레이션된 장치를 통해 처리된 후 실제 하드웨어로 전달된다. 모든 하드웨어에서 작동하여 호환성은 높지만, 모든 요청이 하이퍼바이저를 거치므로 CPU 오버헤드가 매우 크고 성능이 가장 낮다.46
• 패스스루 (Passthrough / VT-d, AMD-Vi): 성능을 극대화하기 위한 방식으로, IOMMU(I/O Memory Management Unit)라는 하드웨어 지원(Intel VT-d, AMD-Vi)을 사용하여 물리 I/O 장치(예: 고성능 GPU, 네트워크 카드) 전체를 특정 VM 하나에 직접 할당한다. VM은 하이퍼바이저를 거의 거치지 않고 장치에 직접 접근하므로 네이티브에 가까운 성능을 낼 수 있다. 하지만 해당 장치는 다른 VM과 공유할 수 없게 되어 가상화의 핵심 이점인 유연성과 자원 공유 능력을 상실하게 된다.
• SR-IOV (Single Root I/O Virtualization): 패스스루의 성능과 가상화의 유연성을 절충한 기술로, PCIe 표준의 일부이다. SR-IOV는 단일 물리 장치를 여러 개의 가상 장치처럼 보이게 하여 여러 VM이 공유하면서도 직접 접근할 수 있도록 한다.47
  • 아키텍처: SR-IOV를 지원하는 장치는 하나의 물리적 기능(Physical Function, PF)과 여러 개의 가상 기능(Virtual Functions, VF)으로 나뉜다. PF는 모든 기능을 갖춘 PCIe 장치로, 하이퍼바이저가 제어하며 VF를 생성하고 관리하는 역할을 한다. 각 VF는 I/O에 필요한 최소한의 기능만 가진 경량 PCIe 장치로, 개별 VM에 직접 할당될 수 있다.46
  • 성능 향상 원리: VF를 할당받은 VM은 하이퍼바이저의 가상 스위치와 같은 소프트웨어 계층을 완전히 우회하여 하드웨어와 직접적인 데이터 경로(Data Path)를 형성한다. IOMMU는 각 VF의 메모리 접근과 인터럽트를 하드웨어 수준에서 격리하고 해당 VM으로 직접 라우팅해준다. 이로 인해 소프트웨어 에뮬레이션 계층에서 발생하는 I/O 오버헤드가 거의 제거되어, 지연 시간이 크게 감소하고 네이티브에 가까운 네트워크 성능을 달성할 수 있다.46

이 장에서는 시장을 주도하는 주요 하이퍼바이저들의 아키텍처, 핵심 기능, 관리 생태계를 비교 분석하여, 각 솔루션이 어떤 전략적 가치를 제공하는지 평가한다. 하이퍼바이저의 시장 성공은 단순히 기술적 우위만으로 결정되지 않으며, 개발자와 운영자에게 얼마나 친숙한 경험을 제공하고 기존 생태계와 얼마나 잘 통합되는지가 더 중요한 요소로 작용하는 경우가 많다. 또한, 주요 하이퍼바이저 아키텍처들은 공통적으로 시스템의 안정성과 보안을 높이기 위해, 핵심 격리 기능(데이터부)과 복잡한 관리 및 드라이버 로직(제어부)을 분리하는 디자인 패턴을 따르고 있다.

VMware ESXi는 엔터프라이즈 서버 가상화 시장에서 오랫동안 지배적인 위치를 차지해 온 타입 1 베어메탈 하이퍼바이저이다.

• 아키텍처: ESXi는 ‘VMkernel’이라는 자체 개발한 마이크로커널 위에서 동작한다. 이 커널은 가상 머신 실행에 필수적인 자원 스케줄링과 하드웨어 추상화에만 집중하도록 설계되었다. 설치 공간이 수백 MB 수준으로 매우 작아 HDD, SSD뿐만 아니라 USB 메모리나 SD 카드에도 설치하여 운영할 수 있어 유연성이 높고 공격 표면이 작다.49
• 핵심 기능 및 생태계: VMware의 진정한 강점은 ESXi 단독이 아닌, vSphere라는 포괄적인 관리 플랫폼 생태계에 있다.
  • vCenter Server: 여러 ESXi 호스트와 그 위에서 실행되는 수천 개의 가상 머신을 단일 인터페이스에서 중앙 집중적으로 관리하고 제어하는 핵심 관리 플랫폼이다. 라이브 마이그레이션, 고가용성 설정 등 모든 고급 기능이 vCenter를 통해 구현된다.49
  • vSphere Suite: vSphere는 다음과 같은 강력한 엔터프라이즈급 기능들을 포함한다.
    • vMotion: 실행 중인 VM을 서비스 중단 없이 다른 ESXi 호스트로 이동시키는 라이브 마이그레이션 기능.
    • High Availability (HA): 호스트 장애 발생 시 다른 정상 호스트에서 VM을 자동으로 재시작하여 다운타임을 최소화한다.50
    • Distributed Resource Scheduler (DRS): 클러스터 내의 호스트들 간의 부하를 모니터링하여 VM을 자동으로 분산 배치함으로써 리소스 활용을 최적화한다.
    • Fault Tolerance (FT): 주 VM과 동일한 복제 VM을 다른 호스트에 생성하여 실시간으로 동기화함으로써, 호스트 장애 시에도 전혀 중단 없이(zero downtime) 서비스를 유지한다.50
  • 스토리지 및 보안: VMware는 VMFS(Virtual Machine File System)라는 고성능 클러스터 파일 시스템을 사용하여 여러 호스트가 공유 스토리지에 동시에 접근할 수 있도록 한다. 또한, 서버의 내장 디스크들을 묶어 고성능 공유 스토리지를 만드는 vSAN(소프트웨어 정의 스토리지)과 스토리지 정책 기반으로 VM 디스크를 관리하는 vVols 등 진보된 스토리지 기술을 제공한다.50 보안 측면에서도 호스트 기반 방화벽, 메모리 공간 배치 난수화(Memory Hardening), 하드웨어 신뢰점(TPM 2.0) 지원, UEFI 보안 부팅, 외부 접근을 원천 차단하는 Lockdown Mode 등 강력한 다층 보안 기능을 내장하고 있다.49

KVM(Kernel-based Virtual Machine)은 리눅스 가상화의 사실상 표준으로 자리 잡은 오픈소스 하이퍼바이저이다.

• 아키텍처: KVM은 2007년부터 리눅스 커널의 정식 일부로 포함된 커널 모듈(kvm.ko)이다.11 KVM 모듈 자체의 역할은 CPU와 메모리의 하드웨어 가상화 기능(Intel VT-x, AMD-V)을 활성화하고,

  /dev/kvm이라는 장치 파일을 통해 사용자 공간 프로그램이 가상 머신을 제어할 수 있는 인터페이스를 제공하는 것이다.24 즉, KVM은 리눅스 커널을 타입 1 하이퍼바이저로 변모시킨다.

• 핵심 기능 및 생태계: KVM의 힘은 사용자 공간의 파트너들과의 협력을 통해 발휘된다.

  • QEMU: KVM의 가장 중요한 사용자 공간(userspace) 파트너이다. KVM이 CPU와 메모리 가상화라는 핵심 엔진 역할을 한다면, QEMU는 가상 디스크, 가상 네트워크 카드, USB 등 주변 장치에 대한 에뮬레이션과 전체 가상 머신 프로세스의 관리 및 실행을 담당한다. KVM과 함께 사용될 때 QEMU는 하드웨어 가속을 통해 거의 네이티브에 가까운 성능을 내며, KVM이 없을 경우 순수한 소프트웨어 에뮬레이터로도 동작할 수 있다.32
  • libvirt: KVM/QEMU를 포함한 다양한 하이퍼바이저(Xen, VirtualBox 등)를 일관된 API로 제어할 수 있도록 추상화한 관리 라이브러리 및 데몬이다. 개발자나 관리자는 libvirt가 제공하는 virsh 커맨드라인 툴이나 각종 GUI 툴(예: virt-manager)을 통해 VM의 생성, 시작, 중지, 마이그레이션, 스토리지/네트워크 구성 등을 손쉽게 관리할 수 있다.52
  • 장점: KVM의 가장 큰 장점은 오픈 소스로서 비용 효율적이며, 리눅스 생태계의 방대한 기능과 도구들을 그대로 활용할 수 있다는 점이다. 안정적인 리눅스 스케줄러, 다양한 파일 시스템, 강력한 보안 기능(SELinux) 등이 모두 KVM 가상화 환경에 자연스럽게 적용된다.54 이러한 유연성과 확장성 덕분에 OpenStack과 같은 주요 오픈소스 클라우드 플랫폼의 기본 하이퍼바이저로 널리 채택되었다.32
  • 보안: KVM은 SELinux(Security-Enhanced Linux) 및 sVirt와 결합하여 각 VM 프로세스에 대해 강력한 필수 접근 제어(Mandatory Access Control, MAC) 정책을 적용한다. 이를 통해 VM 간의 정보 흐름을 통제하고, 설령 하나의 VM이 침해되더라도 다른 VM이나 호스트 시스템으로 피해가 확산되는 것을 효과적으로 방지한다.54

Hyper-V는 Microsoft가 Windows Server 및 Windows 클라이언트 OS에 내장한 타입 1 하이퍼바이저이다.

• 아키텍처: Hyper-V는 Windows Server에 ‘역할(Role)’로 설치되지만, 그 아키텍처는 일반적인 애플리케이션과 근본적으로 다르다. 설치가 완료되고 시스템이 재부팅되면, 하드웨어 위에 Windows 하이퍼바이저 계층이 직접 실행된다. 그리고 기존의 Windows Server OS는 ‘루트 파티션(Root Partition)’ 또는 ‘부모 파티션(Parent Partition)’이라는 특별한 권한을 가진 가상 머신 안에서 동작하게 된다. 사용자가 생성하는 모든 게스트 VM은 ‘자식 파티션(Child Partition)’으로 만들어진다.33
• 핵심 기능 및 생태계: Hyper-V의 강점은 Microsoft의 방대한 서버 생태계와의 깊은 통합에 있다.
  • 파티션과 VMBus: 루트 파티션은 시스템의 모든 물리 하드웨어에 직접 접근할 수 있는 유일한 파티션으로, 장치 드라이버와 전원 관리 등 시스템 수준의 기능을 관리한다. 자식 파티션은 물리 하드웨어에 직접 접근할 수 없으며, 모든 I/O 요청은 VMBus(Virtual Machine Bus)라는 고속 메모리 기반 통신 채널을 통해 루트 파티션으로 전달되어 처리된다. 이 구조는 장치 드라이버를 루트 파티션에 격리하여 시스템 전체의 안정성을 높인다.33
  • Windows 생태계 통합: Hyper-V는 Active Directory를 통한 인증 및 정책 관리, System Center Virtual Machine Manager(SCVMM)를 통한 중앙 집중식 데이터센터 관리, Windows Failover Clustering을 통한 고가용성 구성 등 Microsoft의 핵심 서버 기술들과 완벽하게 통합되어, Windows 중심의 IT 환경에서 매우 강력한 관리 편의성과 시너지를 제공한다.56
  • 주요 기능: 엔터프라이즈 환경에 필수적인 기능들을 충실히 제공한다. 여기에는 무중단 서비스 이전을 위한 Live Migration, 원격지 재해 복구를 위한 Hyper-V Replica, 가상 SAN 환경 구성을 위한 가상 파이버 채널, 고성능 네트워킹을 위한 SR-IOV, 클러스터 환경에서 공유 디스크를 만들기 위한 공유 VHDX 파일 등이 포함된다.56
  • SLAT 요구사항: 효율적인 메모리 가상화를 위해 SLAT(Second Level Address Translation), 즉 Intel의 EPT나 AMD의 NPT와 같은 하드웨어 지원 기능이 CPU에 필수적으로 요구된다. 이는 하이퍼바이저의 소프트웨어 오버헤드를 줄여 성능을 향상시키는 핵심 기술이다.59

Xen은 KVM보다 먼저 등장하여 오픈소스 가상화 시장을 개척한 선구적인 타입 1 하이퍼바이저이다.

• 아키텍처: Xen은 마이크로커널 디자인 철학을 채택하여, 하이퍼바이저 자체는 매우 작고(<1MB) 가볍게 유지된다. Xen 하이퍼바이저는 CPU 스케줄링, 메모리 분할, 인터럽트 처리와 같은 가장 핵심적인 기능만을 수행한다.60
• Domain 0 (Dom0): Xen 아키텍처의 가장 큰 특징은 ‘Domain 0’라는 특권 가상 머신의 존재다. Dom0은 시스템의 모든 물리 장치 드라이버와 관리 도구 스택(Toolstack)을 포함하고 있다. 다른 모든 일반 게스트 VM(Domain U 또는 DomU)은 물리 하드웨어에 직접 접근할 수 없으며, 모든 I/O 요청은 Dom0을 통해 처리된다. 이 구조는 장치 드라이버를 하이퍼바이저 핵심부로부터 격리하여, 드라이버 충돌이 전체 시스템의 안정성을 해치는 것을 방지하는 보안상 이점을 가진다.24
• 가상화 방식: Xen은 두 가지 주요 가상화 모드를 지원한다.
  • 반가상화 (Paravirtualization, PV): Xen이 초기에 명성을 얻게 된 핵심 기술이다. 이는 게스트 OS의 커널을 일부 수정하여, 게스트가 자신이 가상화 환경에서 실행되고 있음을 인지하고 ‘하이퍼콜(Hypercall)’이라는 최적화된 인터페이스를 통해 하이퍼바이저와 직접 통신하는 방식이다. 이를 통해 하드웨어 가상화 지원(VT-x/AMD-V)이 없던 시절에도 높은 성능을 달성할 수 있었다.31
  • 전가상화 (Hardware-assisted Virtualization, HVM): Intel VT-x나 AMD-V와 같은 하드웨어 지원을 사용하여 수정되지 않은 상용 OS(예: Windows)를 실행하는 방식이다. 이 모드에서 Xen은 QEMU를 사용하여 BIOS, IDE 컨트롤러 등 표준 PC 하드웨어를 에뮬레이션한다.60
• 현재 위상: KVM이 리눅스 커널에 통합되면서 많은 리눅스 기반 가상화 시장의 주도권을 넘겨주었지만, Xen은 여전히 일부 대규모 퍼블릭 클라우드(특히 AWS의 초기 인프라)와 높은 수준의 보안 및 격리가 요구되는 시스템, 그리고 임베디드 시스템 분야에서 강력한 입지를 유지하고 있다.62 드라이버를 Dom0에 격리하는 독특한 아키텍처는 여전히 보안 관점에서 중요한 가치를 지닌다.60

Oracle VirtualBox와 VMware Workstation/Player는 데스크톱 환경에서 가장 널리 사용되는 타입 2 호스트형 하이퍼바이저이다. 이들의 주된 목적은 프로덕션 서버 운영이 아니라, 개인용 PC에 간편하게 가상 환경을 구축하여 다른 운영체제를 체험하거나, 소프트웨어를 개발하고 테스트하는 것이다.26

이들 제품은 사용자 친화적인 그래픽 인터페이스(GUI)를 제공하며, 개발 및 테스트 작업의 편의성을 높이는 다양한 기능에 중점을 둔다. 대표적인 기능으로는 특정 시점의 VM 상태를 그대로 저장했다가 언제든지 복원할 수 있는 ‘스냅샷(Snapshot)’, 호스트 PC와 게스트 VM 간에 파일을 쉽게 주고받을 수 있는 ‘공유 폴더’ 및 ‘드래그 앤 드롭’, 물리 USB 장치를 VM에 직접 연결하는 기능 등이 있다.9

하지만 이들의 아키텍처적 한계는 명확하다. 모든 하드웨어 접근이 호스트 OS를 통해 이루어지기 때문에 타입 1 하이퍼바이저에 비해 성능 오버헤드가 크고, 호스트 OS의 안정성과 보안에 직접적인 영향을 받는다. 이러한 이유로 대규모 워크로드를 처리하거나 높은 수준의 안정성과 보안이 요구되는 프로덕션 서버 환경에는 부적합하다.22

비교 항목	VMware vSphere/ESXi	KVM/QEMU	Microsoft Hyper-V	Xen
유형	타입 1 (베어메탈)	타입 1.5 (커널 통합)	타입 1 (하이퍼바이저 역할)	타입 1 (마이크로커널)
아키텍처 특징	VMkernel이라는 자체 마이크로커널 기반. vCenter를 통한 중앙 관리.	리눅스 커널 모듈(KVM) + 사용자 공간 에뮬레이션(QEMU)의 조합.	하이퍼바이저 위에 루트 파티션(호스트 OS)과 자식 파티션(게스트 VM) 구조.	경량 하이퍼바이저 + 특권 관리 VM(Dom0) 구조.
관리 도구/생태계	vCenter Server, vSphere Client. 풍부한 3rd-party 솔루션 생태계.	libvirt, virsh, virt-manager. OpenStack 등 오픈소스 클라우드와 강력한 통합.	Hyper-V Manager, System Center (SCVMM), Windows Admin Center. AD와 완벽 통합.	XenCenter, xl/xm 커맨드라인. Citrix Hypervisor 등 상용 솔루션 존재.
핵심 강점	강력한 엔터프라이즈 기능(vMotion, HA, DRS), 안정성, 포괄적인 관리 기능.	오픈 소스, 비용 효율성, 리눅스 생태계와의 완벽한 통합, 높은 유연성.	Windows Server 생태계와의 깊은 통합, 관리 편의성, 강력한 AD 연동.	강력한 보안 격리(드라이버 도메인), 반가상화(PV)를 통한 고성능, 작은 공격 표면.
주요 사용처	대규모 엔터프라이즈 데이터센터, 프라이빗/하이브리드 클라우드.	퍼블릭/프라이빗 클라우드(OpenStack), 리눅스 기반 서버 가상화, 컨테이너 호스팅.	Windows 중심의 기업 환경, VDI, Microsoft Azure의 기반 기술.	대규모 클라우드 인프라(초기 AWS), 보안이 중요한 시스템, 임베디드 가상화.

이 장에서는 하이퍼바이저가 제공하는 핵심적인 고급 기능들을 살펴보고, 실제 엔터프라이즈 환경에서 어떻게 활용되어 비즈니스 연속성과 운영 효율성을 높이는지 구체적인 사례를 통해 분석한다. 이러한 고급 기능들은 하이퍼바이저가 단순한 서버 통합 도구를 넘어, 동적이고 탄력적인 IT 인프라를 구축하는 핵심 동력임을 보여준다.

라이브 마이그레이션(Live Migration)은 실행 중인 가상 머신(VM)을 사용자나 애플리케이션의 서비스 중단 없이(Zero Downtime) 하나의 물리적 호스트에서 다른 물리적 호스트로 실시간으로 이동시키는 기술이다.70 VMware에서는 이를 vMotion이라고 부른다. 이 기능은 계획된 하드웨어 유지보수(예: 펌웨어 업데이트, 부품 교체)를 다운타임 없이 수행하거나, 특정 호스트에 부하가 집중될 때 워크로드를 다른 호스트로 분산시켜 성능을 최적화(Load Balancing)하고, 사용량이 적은 시간에는 VM을 소수의 호스트에 통합한 뒤 나머지 호스트의 전원을 꺼 에너지를 절약하는 등 현대 데이터센터 운영에 필수적인 유연성을 제공한다.70

라이브 마이그레이션이 성공적으로 이루어지기 위해서는 몇 가지 전제 조건이 충족되어야 한다. 소스 호스트와 대상 호스트는 동일한 CPU 제조사(예: 모두 Intel 또는 모두 AMD)의 프로세서를 사용해야 하며, 가급적 동일한 세대의 CPU를 사용하는 것이 권장된다. 또한, VM의 가상 디스크 파일이 저장된 스토리지는 두 호스트가 모두 접근할 수 있는 공유 스토리지(SAN, NAS 등)여야 한다. 마지막으로, VM이 연결된 가상 네트워크(가상 스위치 이름 등) 구성이 두 호스트 간에 동일해야 원활한 네트워크 연결성이 유지된다.71

라이브 마이그레이션의 핵심 프로세스는 ‘반복적 메모리 복사(Pre-copy 또는 Iterative Memory Copy)’ 방식으로 이루어진다.

1. 준비 (Preparation): 마이그레이션이 시작되면, 소스 호스트는 대상 호스트와 제어 채널을 설정하고 이동할 VM의 구성 정보(vCPU 수, 메모리 크기, 가상 장치 등)를 전송한다. 대상 호스트는 이 정보를 바탕으로 VM을 실행할 준비를 하며, 리소스를 예약하고 비어있는 ‘스켈레톤(skeleton) VM’을 생성한다.70
2. 반복적 메모리 복사 (Iterative Memory Copy): 이 단계가 라이브 마이그레이션의 핵심이다. 소스 호스트의 VM은 계속해서 정상적으로 실행되는 상태에서, 하이퍼바이저는 VM이 사용 중인 전체 메모리 페이지를 네트워크를 통해 대상 호스트로 복사하기 시작한다. 동시에, 하이퍼바이저는 이 복사 과정 중에 내용이 변경되는 메모리 페이지(dirty pages)를 추적한다.70
3. 변경분 전송 (Dirty Page Transfer): 첫 번째 전체 메모리 복사가 완료되면, 하이퍼바이저는 그동안 추적해 둔 변경된 페이지들만 다시 대상 호스트로 전송한다. 이 과정을 여러 번 반복하면서, 매 라운드마다 전송해야 할 데이터의 양은 점차 줄어든다. 이 과정은 VM의 워크로드(메모리 변경률)와 네트워크 대역폭에 따라 수 초에서 수 분이 소요될 수 있다.71
4. 중단 및 전환 (Stop-and-Copy): 전송해야 할 메모리 변경분의 양이 매우 적어져 아주 짧은 시간 내에 전송이 가능하다고 판단되면, 하이퍼바이저는 소스 VM의 실행을 아주 짧은 순간(수십~수백 밀리초) 동안 일시 중지(pause)시킨다. 이 짧은 중단 시간 동안 최종적으로 남은 변경분과 CPU 레지스터 상태, 장치 상태 등 VM의 실행 상태를 모두 대상 호스트로 전송한다. 전송이 완료되면 즉시 대상 호스트에서 VM의 실행을 재개(resume)한다. 이 전체 전환 시간은 일반적인 네트워크 애플리케이션의 TCP 타임아웃 값보다 훨씬 짧기 때문에, 클라이언트는 서비스 중단을 거의 인지하지 못한다.70
5. 완료 (Completion): 대상 호스트의 VM이 정상적으로 실행을 시작하면, 대상 호스트가 새로운 주 노드가 된다. 이후 소스 호스트는 원래의 VM을 메모리에서 삭제하고 리소스를 해제함으로써 마이그레이션 프로세스가 완료된다.70

이처럼 라이브 마이그레이션의 성공은 단순히 하이퍼바이저 소프트웨어의 기능에만 의존하는 것이 아니다. 대용량의 메모리 데이터를 신속하게 전송할 수 있는 고대역폭, 저지연 네트워크 인프라와 모든 호스트가 안정적으로 접근할 수 있는 고성능 공유 스토리지 아키텍처가 반드시 뒷받침되어야 한다. 즉, 가상화의 고급 기능은 이를 지원하는 물리적 인프라의 설계와 성능에 의해 그 실효성이 결정되는 것이다.

비즈니스 연속성은 모든 기업 IT의 핵심 목표이며, 하이퍼바이저는 이를 달성하기 위한 강력한 기능들을 제공한다.

• 고가용성 (High Availability, HA): HA는 주로 단일 데이터센터 내에서 계획되지 않은 다운타임을 최소화하는 데 중점을 둔다. VMware HA나 Hyper-V Failover Clustering과 같은 기능은 클러스터로 묶인 여러 호스트들을 지속적으로 감시한다. 만약 특정 호스트에 하드웨어 장애나 OS 충돌이 발생하면, 클러스터는 이를 감지하고 해당 호스트에서 실행되던 모든 VM들을 클러스터 내의 다른 정상적인 호스트에서 자동으로 재시작한다. 이 과정에서 VM은 재부팅되지만, 서비스 중단 시간을 수 분 내로 최소화할 수 있다.50
• 재해 복구 (Disaster Recovery, DR): DR은 지진, 화재, 정전 등 데이터센터 전체에 영향을 미치는 광범위한 재해에 대비하는 전략이다. 하이퍼바이저 기반 복제(Replication) 기술이 핵심적인 역할을 한다.
  • Hyper-V Replica: 추가적인 스토리지 복제 솔루션 없이 Hyper-V 자체 기능만으로 주 데이터센터(Primary Site)의 VM 변경 사항을 원격지의 복구 사이트(Replica Site)로 주기적으로(비동기 방식) 복제한다. 재해 발생 시 복구 사이트에서 복제된 VM을 수동 또는 자동으로 가동하여 서비스를 재개할 수 있다.56
  • VMware vSphere Replication: ESXi 커널 수준에서 VM의 디스크 I/O를 직접 모니터링하여 변경된 데이터 블록만을 효율적으로 원격 사이트로 복제한다. 이 기능은 VMware SRM(Site Recovery Manager)과 같은 재해 복구 자동화 솔루션과 통합되어, 복구 계획 수립, 테스트, 실제 장애 조치(Failover) 및 복구(Failback) 과정을 자동화된 워크플로우로 관리할 수 있게 해준다.50
• 스냅샷 (Snapshot): 스냅샷은 특정 시점의 VM 상태, 즉 디스크, 메모리, 장치 구성을 그대로 보존하는 파일이다. 이는 시스템 업데이트나 중요한 변경 작업을 수행하기 전에 안전한 복원 지점을 만드는 용도로 널리 사용된다. 또한, 정기적인 스냅샷은 백업 솔루션과 연계하여 빠르고 효율적인 VM 단위 백업 및 복구를 가능하게 한다.7

가상 데스크톱 인프라(VDI)는 데스크톱 컴퓨팅 환경을 중앙에서 관리하고 사용자에게 서비스 형태로 제공하는 모델로, 하이퍼바이저 기술의 중요한 활용 사례 중 하나이다.

• 개념: VDI는 데이터센터의 중앙 서버에서 Windows 10/11과 같은 클라이언트 운영체제를 다수의 VM 형태로 실행하고, 사용자는 씬 클라이언트, 제로 클라이언트, 노트북, 태블릿 등 다양한 개인 장치를 통해 네트워크로 자신의 가상 데스크톱에 원격으로 접속하여 업무를 수행하는 방식이다.4

• 아키텍처: VDI 환경은 크게 세 가지 요소로 구성된다. 첫째, ESXi나 Hyper-V와 같은 하이퍼바이저가 가상 데스크톱 VM들을 호스팅한다. 둘째, 연결 브로커(Connection Broker)가 사용자 인증을 처리하고 각 사용자의 요청을 적절한 가상 데스크톱 풀이나 개인 데스크톱에 연결해주는 중개자 역할을 한다. 셋째, 사용자는 원격 디스플레이 프로토콜(예: RDP, PCoIP)을 통해 자신의 장치에서 가상 데스크톱 화면을 전송받고 키보드/마우스 입력을 전달한다.4

• 장점 및 활용 분야: VDI는 다음과 같은 명확한 이점을 제공한다.

  • 중앙 관리 및 보안 강화: 모든 데스크톱 OS, 애플리케이션, 데이터가 중앙 서버에 통합 관리되므로, 보안 패치, 소프트웨어 업데이트, 데이터 백업 등을 일괄적으로 수행할 수 있다. 중요한 기업 데이터가 사용자 개인 장치에 저장되지 않아 데이터 유출 및 손실 위험이 크게 감소한다.77

  • 원격 근무 및 BYOD(Bring Your Own Device) 지원: 사용자는 인터넷이 연결된 곳이라면 어디서든, 어떤 장치를 사용하든 일관된 자신의 업무 환경에 안전하게 접근할 수 있다. 이는 유연한 근무 형태를 지원하고 직원 만족도를 높인다.77

  • 신속한 배포 및 유연성: 새로운 직원을 위한 데스크톱 환경을 몇 분 안에 프로비저닝하거나, 특정 프로젝트를 위한 표준화된 개발 환경을 신속하게 배포할 수 있다.77

    이러한 장점 덕분에 VDI는 원격 근무 환경, 보안이 중요한 금융 및 공공 기관, 표준화된 환경이 필요한 콜센터 및 교육 기관, 민감한 환자 정보를 다루는 의료 분야(EHR 접근) 등에서 널리 활용되고 있다.78 VDI는 단순히 PC를 서버로 옮기는 기술을 넘어, 사용자의 ‘업무 공간(Workspace)’ 자체를 물리적 장치로부터 완전히 분리하여, 중앙에서 통제되고 필요에 따라 서비스 형태로 제공되는 ‘업무 환경의 서비스화(Workspace-as-a-Service)’를 구현하는 전략적 도구로 평가받는다.

하이퍼바이저는 가상화 인프라의 모든 것을 통제하는 핵심 구성 요소이므로, 그 자체로 가장 중요하고 민감한 공격 대상이 된다. 하이퍼바이저의 보안은 개별적인 보안 기능의 집합이 아니라, 시스템 아키텍처 설계 단계에서부터 공격 표면을 최소화하고 하드웨어부터 애플리케이션까지 이어지는 ‘신뢰의 사슬(Chain of Trust)’을 구축하는 문제로 접근해야 한다. 가상화는 하이퍼바이저라는 새로운 공격 지점을 만들지만, 동시에 VM 단위의 강력한 격리라는 새로운 방어 수단을 제공하는 양면성을 지닌다.

하이퍼바이저는 모든 VM의 실행을 중재하고 리소스를 할당하는 ‘신(God)’과 같은 위치에 있다. 만약 하이퍼바이저 계층이 침해당한다면, 그 위에서 동작하는 모든 VM의 데이터와 제어권이 공격자에게 넘어갈 수 있다. 이는 가상화 환경에서 가장 치명적인 단일 장애점(Single Point of Failure)으로 간주된다.11

• 하이퍼재킹 (Hyperjacking): 이는 가장 정교하고 위험한 공격 중 하나로, 공격자가 악성코드를 이용해 시스템에서 실행 중인 합법적인 하이퍼바이저를 변조하거나, 혹은 더 낮은 계층에 악의적인 하이퍼바이저를 몰래 설치하여 시스템 전체를 장악하는 공격을 의미한다. ‘하이퍼바이저’와 ‘하이재킹’의 합성어이다.82 공격이 성공하면, 악성 하이퍼바이저는 모든 VM의 메모리, 네트워크 트래픽, 디스크 I/O를 감시하고 조작할 수 있으며, 기존의 보안 소프트웨어로는 탐지가 거의 불가능하다.82
• VM 탈출 (VM Escape): 가상 머신 내부에서 실행되는 공격 코드가 하이퍼바이저의 소프트웨어 취약점(예: 버퍼 오버플로우, 로직 오류)을 악용하여 VM의 격리된 환경을 벗어나, 호스트 운영체제나 다른 VM의 메모리 공간에 접근하는 공격이다. 이는 가상화의 핵심 전제인 ‘격리(Isolation)’ 원칙을 완전히 무너뜨리는 심각한 위협이다.81 과거 Xen, VMware 등 주요 하이퍼바이저에서 실제 VM 탈출 취약점이 발견된 사례가 있다.86
• 기타 위협:
  • 서비스 거부 (Denial of Service, DoS): 악의적인 VM이 하이퍼바이저의 CPU, 메모리, I/O 자원을 과도하게 요청하여 고갈시킴으로써, 동일 호스트의 다른 모든 VM의 서비스를 마비시키는 공격.80
  • VM 간 사이드 채널 공격 (Inter-VM Side-Channel Attack): 동일한 물리 CPU의 캐시나 메모리 버스를 공유하는 VM들이 서로의 작업 내용을 미세한 시간 차이나 전력 소모 패턴 등을 통해 유추하는 공격.
  • VM 이미지 및 스냅샷 탈취: 관리되지 않는 VM 이미지 파일이나 스냅샷 파일이 유출될 경우, 그 안에 포함된 민감한 데이터나 시스템 계정 정보가 노출될 수 있다.
  • VM 스프롤 (VM Sprawl): 제대로 관리되지 않고 방치된 VM들이 증가하는 현상. 이러한 VM들은 보안 패치가 적용되지 않거나 취약한 설정으로 남아, 공격자가 내부 네트워크에 침투하는 경로로 악용될 수 있다.81

가상화 환경의 신뢰성을 보장하기 위해서는 하드웨어부터 애플리케이션까지 아우르는 다층적인 방어 전략이 필수적이다.

• 기본 방어 전략:
  • 지속적인 패치 관리: 하이퍼바이저, 게스트 OS, 관리 도구 등 모든 구성 요소에 대해 알려진 보안 취약점을 해결하기 위해 정기적으로 최신 보안 패치를 적용하는 것이 가장 기본적이고 중요한 방어 수단이다.80
  • 최소 권한 원칙 기반의 접근 제어: 하이퍼바이저 관리 인터페이스(예: vCenter, Hyper-V Manager)에 대한 접근 권한을 반드시 필요한 관리자에게만 부여하고, 다중 인증(MFA)과 역할 기반 접근 제어(RBAC)를 통해 권한을 세분화해야 한다.80
  • 네트워크 분리 및 분할: 관리 트래픽, 스토리지 트래픽, 라이브 마이그레이션 트래픽, VM 간 통신 트래픽 등을 물리적 또는 가상랜(VLAN)을 이용해 논리적으로 분리하여, 하나의 네트워크가 침해되더라도 다른 네트워크로 피해가 확산되는 것을 방지해야 한다.84
• 격리 강화 기술:
  • 하드웨어 기반 보안 (Hardware-based Security):
    • TPM (Trusted Platform Module): 서버에 내장된 보안 칩인 TPM을 활용하여, 시스템 부팅 시 하이퍼바이저와 핵심 드라이버들의 암호화 해시값을 측정하고, 사전에 정의된 정상 값과 비교하여 시스템의 무결성을 검증한다. 이를 통해 악성 하이퍼바이저가 로드되는 것을 방지할 수 있다.49
    • Intel TXT / AMD-V Secure Loader: 신뢰할 수 있는 실행 기술(Trusted Execution Technology)을 사용하여, 하이퍼바이저가 하드웨어적으로 보호되는 격리된 메모리 영역에서 실행되도록 보장한다.
  • 커널 및 OS 수준 보안:
    • SELinux/sVirt: KVM 환경에서 SELinux와 sVirt를 함께 사용하면, 각 VM 프로세스에 대해 강제적 접근 통제(MAC) 보안 정책을 적용할 수 있다. 이는 각 VM이 접근할 수 있는 파일, 장치, 네트워크 포트 등을 엄격하게 제한하여, VM 탈출 공격이 성공하더라도 공격자가 호스트 시스템에서 할 수 있는 행위를 크게 제약한다.54
    • Shielded VMs (Hyper-V) / vSphere Trust Authority (VMware): 이 기술들은 VM의 가상 디스크(VHDX/VMDK)와 실행 상태를 암호화하고, 신뢰할 수 있는 것으로 인증된 호스트에서만 해당 VM이 실행되도록 강제한다. 이를 통해 악의적인 스토리지 관리자나 데이터센터 내부자, 혹은 탈취된 하드웨어로부터 VM 데이터를 보호할 수 있다.
• 지속적인 모니터링 및 탐지:
  • 하이퍼바이저, 호스트 OS, vCenter 등 관리 시스템의 모든 로그를 중앙 로그 관리 시스템(SIEM 등)으로 전송하여 비정상적인 활동(예: 실패한 로그인 시도, 비정상적인 리소스 사용, 권한 변경 시도)을 실시간으로 탐지하고 분석해야 한다.82
  • 가상화 환경에 특화된 침입 탐지/방지 시스템(IDS/IPS)을 도입하여 VM 간의 네트워크 트래픽을 감시하고, 최신 위협 인텔리전스를 활용하여 알려진 공격 패턴을 차단해야 한다.

이 장에서는 2024년 현재 하이퍼바이저 시장의 규모와 성장 동인을 분석하고, 특히 VMware와 Microsoft의 라이선스 모델 변화가 사용자에게 미치는 전략적, 경제적 영향을 심층적으로 분석한다. 벤더의 라이선스 정책은 단순한 가격 책정을 넘어, 기술 로드맵과 고객을 자사 생태계에 묶어두려는 락인(Lock-in) 전략을 반영하므로, 이에 대한 깊이 있는 이해는 기술 도입 의사결정에 매우 중요하다.

• 시장 규모 및 전망: 2024년 글로벌 하이퍼바이저 시장의 가치는 약 67억 달러에서 70억 달러 사이로 평가된다. 시장은 향후 몇 년간 꾸준한 성장을 지속하여, 2031년까지 연평균 성장률(CAGR) 4.2%에서 6%를 기록하며 약 90억 달러에서 127억 달러 규모에 이를 것으로 전망된다.87
• 주요 성장 동인:
  • 클라우드 및 가상화 기술의 지속적인 확산: 기업들이 IT 인프라 비용을 절감하고 운영 효율성을 높이려는 노력이 계속되면서 가상화 기술 채택이 증가하는 것이 가장 근본적인 성장 동력이다.88
  • 신기술과의 융합: 엣지 컴퓨팅, 사물 인터넷(IoT), 인공지능(AI) 및 머신러닝(ML)과 같은 신기술 분야의 성장이 하이퍼바이저에 대한 새로운 수요를 창출하고 있다. 예를 들어, 엣지 디바이스에서 여러 기능을 격리하여 실행하거나 AI 워크로드를 효율적으로 관리하기 위해 경량 하이퍼바이저가 활용된다.88
  • 재해 복구 및 비즈니스 연속성 강화: 사이버 공격과 자연재해의 위협이 증가함에 따라, 기업들은 비즈니스 연속성을 보장하기 위해 가상화 기반의 안정적인 재해 복구(DR) 솔루션에 대한 투자를 늘리고 있다.89
  • SMB 및 신규 산업 분야의 채택 확대: 과거 대기업 중심으로 도입되던 가상화 기술이 이제는 중소기업(SMB)으로까지 확산되고 있다. 또한, 자율주행차와 같이 여러 운영체제(예: 인포테인먼트용 OS, 주행 제어용 실시간 OS)를 하나의 하드웨어에서 안전하게 격리하여 실행해야 하는 자동차 산업에서도 하이퍼바이저의 역할이 중요해지고 있다.88
• 시장 지배 구조: 지리적으로는 IT 인프라가 발달하고 기술 혁신을 주도하는 북미 지역이 가장 큰 시장 점유율을 차지하고 있다. 벤더 측면에서는 VMware와 Microsoft가 엔터프라이즈 시장을 강력하게 주도하고 있으며, 그 뒤를 오픈소스 기반의 솔루션들이 잇고 있다.88

VMware vSphere 라이선스 모델 변화 (Broadcom 인수 이후):

Broadcom에 인수된 후 VMware의 라이선스 정책은 시장에 큰 파장을 일으키며 급격하게 변화했다.

• 영구 라이선스에서 구독(Subscription) 모델로의 전면 전환: 과거 VMware의 주력 모델은 한 번 구매하면 소프트웨어를 영구적으로 소유하고 지원 계약(SnS)만 갱신하는 ‘영구 라이선스’ 방식이었다. 이는 장기적인 비용 예측을 가능하게 했다. 그러나 이제 이 모델은 폐지되고, 연간 또는 다년 계약 기반의 ‘구독 라이선스’로 완전히 전환되었다. 이로 인해 고객들은 지속적으로 비용을 지불해야 하는 구조가 되었다.90
• CPU 소켓 단위에서 코어(Core) 단위 과금으로의 전환: 과거에는 서버에 장착된 물리 CPU 소켓 수에 따라 라이선스 비용을 부과했다. 하지만 이제는 CPU에 포함된 물리적 코어(Core) 수를 기준으로 비용을 책정한다. 특히, CPU당 최소 16코어에 대한 라이선스를 구매해야 한다는 조건이 붙어, 코어 수가 적은 CPU를 사용하더라도 최소 16코어 비용을 지불해야 한다.90
• 사용자에게 미치는 영향: 이러한 변화는 특히 최신 고밀도 코어 CPU를 사용하는 고객에게 상당한 비용 증가를 초래한다. 예를 들어, 과거에는 2개의 32코어 CPU가 장착된 서버에 2개의 CPU 라이선스만 필요했지만, 이제는 총 64코어에 대한 라이선스가 필요하게 된다. 또한, 영구 라이선스의 예측 가능성이 사라지고, 필요하지 않은 기능까지 포함된 번들 제품을 구독해야 하는 경우가 발생하면서 고객의 비용 통제력이 약화되고 기술 선택의 유연성이 감소했다는 비판을 받고 있다.90 이러한 변화는 단순한 가격 정책 변경을 넘어, 고객을 VMware의 통합 클라우드 플랫폼인 VMware Cloud Foundation(VCF) 생태계에 더 깊이 묶어두려는 고도의 ‘락인(Lock-in) 전략’으로 해석될 수 있다.

Microsoft Hyper-V 라이선스 모델:

Microsoft의 전략은 VMware와는 다르다. Hyper-V 기능 자체는 Windows Server에 포함된 무료 기능으로 제공하여 초기 도입 장벽을 낮추고, 대신 핵심 수익원인 Windows Server OS 및 Azure 클라우드 판매를 촉진하는 ‘생태계 확장 전략’을 구사한다.

• Windows Server 에디션에 따른 가상화 권한: Hyper-V 위에서 실행할 수 있는 Windows Server 게스트 VM의 수는 호스트에 설치된 Windows Server 라이선스 에디션에 따라 결정된다.
  • Standard Edition: 2개의 가상 운영 환경(OSEs), 즉 2개의 Windows Server VM 또는 2개의 Hyper-V 컨테이너를 실행할 수 있는 권한을 제공한다. 가상화 밀도가 낮은 환경에 적합하다. 만약 2개 이상의 VM을 실행하고 싶다면, 서버의 모든 물리 코어에 대해 Standard 라이선스를 추가로 구매(재라이선싱)해야 한다.93
  • Datacenter Edition: 라이선스가 부여된 호스트 위에서 무제한의 Windows Server VM 및 Hyper-V 컨테이너를 실행할 수 있는 권한을 제공한다. 대규모 가상화 및 프라이빗 클라우드 환경에 필수적이다. 또한 Storage Spaces Direct, Shielded VM과 같은 고급 기능은 Datacenter 에디션에서만 제공된다.93
• 라이선싱 방식: 두 에디션 모두 서버에 장착된 모든 물리 코어를 라이선싱해야 하는 ‘코어 기반’ 모델을 따른다(프로세서당 최소 8코어, 서버당 최소 16코어). 또한, 서버에 접속하는 모든 사용자나 장치에 대해 별도의 CAL(Client Access License)을 구매해야 하는 요구사항이 있다.93 이 모델은 고객이 가상화를 많이 사용할수록 더 상위 에디션인 Datacenter를 구매하도록 자연스럽게 유도하며, Azure Hybrid Benefit과 같은 프로그램을 통해 온프레미스 라이선스를 Azure 클라우드 사용 할인으로 연결시켜 자사 생태계로의 전환을 촉진한다.

이 장에서는 하이퍼바이저가 컨테이너 기술과의 경쟁 및 공존 관계 속에서 어떻게 진화하고 있으며, 마이크로VM과 유니커널이라는 새로운 패러다임이 미래 IT 인프라에 어떤 변화를 가져올지 전망한다. ‘One-size-fits-all’ 가상화 시대는 저물고, 워크로드의 특성에 최적화된 다양한 ‘격리 프리미티브(Isolation Primitives)’를 선택하고 조합하는 시대로 진입하고 있다. 이 과정에서 하이퍼바이저는 사라지는 것이 아니라, 인프라의 더 깊은 곳으로 투명하게 내재화되며 그 중요성을 더욱 강화하고 있다.

• 아키텍처 차이:
  • 가상 머신 (VM): 하이퍼바이저를 통해 물리적 하드웨어를 가상화한다. 각 VM은 자체적인 게스트 OS 커널을 포함하여 완벽하게 독립된 컴퓨팅 환경을 제공한다. 이로 인해 하드웨어 수준의 강력한 격리(Isolation)를 보장하지만, 게스트 OS를 포함하기 때문에 이미지 크기가 크고(기가바이트 단위), 부팅 시간이 길며(분 단위), 리소스 오버헤드가 상대적으로 크다.6
  • 컨테이너 (예: Docker): 컨테이너 엔진(예: Docker Engine)을 통해 호스트 OS의 커널을 공유하며, 애플리케이션과 그 실행에 필요한 라이브러리 및 종속성만을 패키징한다. OS 수준의 가상화 방식으로, 게스트 OS가 없어 매우 가볍고(메가바이트 단위), 시작 속도가 빠르며(초 단위), 이식성이 뛰어나다. 하지만 모든 컨테이너가 동일한 호스트 커널을 공유하므로, 커널 취약점이 발생할 경우 모든 컨테이너가 영향을 받을 수 있어 VM보다 격리 수준이 낮다는 평가를 받는다.11
• 사용 사례 및 공존: VM과 컨테이너는 경쟁 관계라기보다는 상호 보완적인 관계에 가깝다. 서로 다른 종류의 OS를 실행해야 하거나, 레거시 애플리케이션을 운영하고, 강력한 보안과 완전한 환경 격리가 최우선 순위일 경우에는 VM이 적합하다.96 반면, 마이크로서비스 아키텍처를 기반으로 애플리케이션을 개발하고, CI/CD 파이프라인을 통해 신속하게 배포와 확장을 반복해야 하는 클라우드 네이티브 환경에서는 컨테이너가 압도적으로 유리하다.95 현실에서는 이 두 기술이 함께 사용되는 경우가 많다. 예를 들어, 보안과 관리의 용이성을 위해 먼저 VM으로 큰 격리 단위를 만든 후, 그 VM 내부에 다수의 컨테이너를 배포하여 애플리케이션을 운영하는 방식이 널리 사용된다.100

컨테이너의 속도와 밀도, 그리고 VM의 강력한 보안과 격리라는 두 가지 장점을 모두 취하려는 요구는 ‘경량 가상화’라는 새로운 기술 흐름을 낳았다.

• Firecracker: AWS가 서버리스 컴퓨팅 서비스인 Lambda와 Fargate를 위해 개발한 오픈소스 가상 머신 모니터(VMM)이다. KVM을 기반으로 하지만, 기존 QEMU와 달리 서버리스 함수 실행에 불필요한 거의 모든 레거시 장치(USB, 그래픽 카드, 사운드 카드 등) 에뮬레이션 코드를 제거했다. 그 결과, 수십 밀리초 내에 부팅이 가능하고 수 MB의 메모리만 사용하는 초경량 가상 머신, 즉 ‘마이크로VM(microVM)’을 생성할 수 있다. Firecracker는 단일 호스트에서 수천 개의 마이크로VM을 높은 밀도로 실행하면서도 하드웨어 기반의 강력한 보안 격리를 제공하는 데 초점을 맞추고 있다.101
• Kata Containers: 컨테이너를 생성할 때마다 그 컨테이너를 경량 VM 내부에서 실행하여 하드웨어 수준의 격리를 제공하는 OCI(Open Container Initiative) 호환 컨테이너 런타임이다. 개발자나 운영자는 Docker나 Kubernetes에서 일반 컨테이너를 다루는 것과 동일한 명령과 워크플로우를 사용하지만, 내부적으로는 Kata 런타임이 각 컨테이너(또는 파드)를 위한 전용 VM을 생성하고 그 안에서 컨테이너를 실행한다. 이를 통해 컨테이너의 편리한 사용성과 VM의 강력한 보안을 결합하여, 특히 신뢰할 수 없는 코드를 실행하거나 여러 테넌트가 인프라를 공유하는 다중 테넌트(multi-tenant) 환경에서 보안을 크게 강화할 수 있다.106

유니커널(Unikernel)은 가상화의 개념을 극한으로 밀어붙인 새로운 접근법이다.

• 개념: 유니커널은 애플리케이션 코드와 그 실행에 필요한 최소한의 OS 라이브러리 및 장치 드라이버만을 선택하여 하나의 파일로 정적 링크(statically link)하는 기술이다. 이렇게 만들어진 이미지는 셸, 다중 프로세스, 사용자 구분 등 범용 OS의 복잡한 기능이 모두 제거된, 단일 목적을 가진 단일 주소 공간의 실행 파일이 된다. 이 이미지는 별도의 OS 없이 하이퍼바이저 위에서 직접 실행된다.111
• 장점:
  • 극대화된 보안: 사용되지 않는 모든 시스템 콜, 라이브러리, 유틸리티가 코드베이스에서 원천적으로 제거되므로 공격 표면이 극도로 작아진다.111
  • 초소형, 초고속: 이미지는 수 MB에 불과하며, 단일 프로세스로 동작하여 부팅이 매우 빠르다. 이는 요청이 들어올 때 즉시 VM을 생성하여 대응하는 온디맨드 서비스에 적합하다.111
  • 최적화된 성능: 커널 모드와 사용자 모드 간의 전환으로 인한 오버헤드가 없으며, 애플리케이션과 OS 라이브러리가 하나의 단위로 컴파일되므로 전체 시스템에 걸친 최적화가 가능하다.111
• 단점 및 한계: 유니커널은 범용성이 매우 낮고, 한번 컴파일된 후에는 수정이 불가능하며, 문제가 발생했을 때 디버깅이 어렵다는 단점이 있다. 또한 기존 애플리케이션을 유니커널로 변환하기 위한 개발 생태계가 아직 성숙하지 않았다. 현재로서는 네트워크 기능(방화벽, 로드밸런서 등)이나 특정 프로토콜을 처리하는 단일 목적의 마이크로서비스, 또는 IoT와 같은 임베디드 시스템에 더 적합한 기술로 평가받는다.111

이러한 기술들의 등장은 하이퍼바이저가 사라지는 것이 아니라, 오히려 그 역할이 더욱 중요해지고 있음을 시사한다. 최종 사용자는 컨테이너나 서버리스 함수와 같은 더 높은 수준의 추상화와 상호작용하지만, 그 기반에서는 여전히 하이퍼바이저가 하드웨어 가속을 통해 강력한 보안과 격리를 ‘투명하게’ 제공하고 있다. 하이퍼바이저는 사용자에게 직접 노출되는 관리 대상에서, 클라우드 네이티브 플랫폼의 보이지 않는 신뢰 기반(underlying fabric)으로 진화하고 있는 것이다.

하이퍼바이저는 지난 수십 년간 IT 인프라의 발전을 이끌어온 핵심 동력이다. 이는 단순히 하나의 서버에서 여러 운영체제를 실행하는 도구를 넘어, 물리적 자원의 한계를 극복하고 IT 환경에 전례 없는 효율성, 유연성, 그리고 안정성을 부여하는 근간 기술로 자리매김했다. 본 보고서는 하이퍼바이저의 근본적인 아키텍처인 타입 1과 타입 2의 트레이드오프에서 시작하여, CPU(VT-x/AMD-V), 메모리(EPT/NPT), I/O(SR-IOV) 가상화 기술이 어떻게 하드웨어의 힘을 빌려 소프트웨어의 한계를 극복해왔는지 심층적으로 분석했다. VMware, KVM, Hyper-V와 같은 주요 생태계는 각기 다른 아키텍처와 비즈니스 전략을 통해 시장에서 경쟁하며 발전해왔으며, 라이브 마이그레이션, 고가용성, VDI와 같은 고급 기능들은 기업의 비즈니스 민첩성과 연속성을 새로운 차원으로 끌어올렸다.

컨테이너와 서버리스 패러다임이 클라우드 네이티브 시대를 주도하면서 한때 하이퍼바이저의 역할이 축소될 것이라는 전망도 있었지만, 현실은 정반대의 방향으로 전개되고 있다. Kata Containers가 컨테이너 보안을 위해 하이퍼바이저를 활용하고, AWS Lambda가 Firecracker라는 KVM 기반 마이크로VM 위에서 동작하는 사례는 이를 명확히 보여준다. 미래의 하이퍼바이저는 그 중요성이 줄어드는 것이 아니라, 오히려 더 가볍고, 더 빠르며, 더 안전한 형태로 진화하여 클라우드 네이티브 스택의 가장 낮은 계층에서 ‘신뢰의 근원(Root of Trust)’으로서의 역할을 더욱 공고히 할 것이다. 즉, 관리의 복잡성은 Kubernetes와 같은 상위 오케스트레이션 플랫폼으로 넘어가고, 하이퍼바이저는 외부에는 거의 드러나지 않으면서 순수한 ‘격리 엔진(Isolation Engine)’으로서의 본질에 더욱 집중하게 될 것이다.

이러한 변화의 흐름 속에서 기술 아키텍트와 IT 의사결정권자는 다음과 같은 전략적 관점을 견지해야 한다.

1. ‘최고의’ 하이퍼바이저는 없다. ‘최적의’ 아키텍처만 있을 뿐이다: 특정 하이퍼바이저가 모든 상황에 절대적으로 우월한 경우는 없다. 워크로드의 성능 요구사항, 보안 민감도, 기존 기술 스택과의 통합성, 운영 모델, 그리고 총소유비용(TCO)을 종합적으로 고려하여 VMware, KVM, Hyper-V, 혹은 경량 가상화 솔루션 등 자사의 비즈니스 목표에 가장 부합하는 최적의 기술 스택을 선택해야 한다.
2. 라이선스 모델을 전략적으로 분석하라: 벤더의 라이선스 정책은 단순한 비용 문제가 아니라, 해당 기업의 기술 로드맵과 고객 락인(Lock-in) 전략을 반영하는 중요한 지표이다. 특히 최근 VMware의 급격한 라이선스 모델 변화는 장기적인 총소유비용(TCO)과 기술적 유연성에 큰 영향을 미칠 수 있으므로, 신중한 분석과 대안 검토가 필요하다.
3. 보안은 아키텍처 단계에서부터 시작된다: 하이퍼바이저 보안은 침해 사고 발생 후 대응하는 것이 아니라, 시스템 설계 단계에서부터 공격 표면을 최소화하고 하드웨어부터 애플리케이션까지 이어지는 신뢰 경계를 설정함으로써 선제적으로 구현되어야 한다.

4. 컨테이너와 VM의 공존을 준비하라: 미래의 데이터센터는 VM과 컨테이너가 각자의 장점을 살려 공존하는 하이브리드 환경이 될 것이다. 두 기술의 특성을 깊이 이해하고, 이들을 통합하여 관리하며 시너지를 창출할 수 있는 기술적 역량과 관리 플랫폼을 확보하는 것이 차세대 IT 인프라 경쟁력의 핵심이 될 것이다.

5. 하이퍼바이저란 무엇인가요? - IBM, accessed July 15, 2025, https://www.ibm.com/kr-ko/think/topics/hypervisors
6. What are hypervisors? A complete guide - Nutanix, accessed July 15, 2025, https://www.nutanix.com/info/hypervisor
7. 하이퍼바이저 - 위키백과, 우리 모두의 백과사전, accessed July 15, 2025, https://ko.wikipedia.org/wiki/%ED%95%98%EC%9D%B4%ED%8D%BC%EB%B0%94%EC%9D%B4%EC%A0%80
8. What Is a Hypervisor and How Does It Work? - Citrix, accessed July 15, 2025, https://www.citrix.com/glossary/what-is-hypervisor.html
9. Hypervisor(하이퍼바이저)란? - Kaden Sungbin Cho - 티스토리, accessed July 15, 2025, https://kadensungbincho.tistory.com/190
10. 하이퍼바이저란 무엇인가요? - AWS, accessed July 15, 2025, https://aws.amazon.com/ko/what-is/hypervisor/
11. What is a Hypervisor? - AWS, accessed July 15, 2025, https://aws.amazon.com/what-is/hypervisor/
12. What is a Hypervisor? - VMware, accessed July 15, 2025, https://www.vmware.com/topics/hypervisor
13. 클라우드이해하기 2: 하이퍼바이저와 가상화(1) - Medium, accessed July 15, 2025, https://medium.com/@ch.lee2/%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-2-%ED%95%98%EC%9D%B4%ED%8D%BC%EB%B0%94%EC%9D%B4%EC%A0%80%EC%99%80-%EA%B0%80%EC%83%81%ED%99%94-1-9f8f78187bc7

14. What Are Hypervisors?

    IBM, accessed July 15, 2025, https://www.ibm.com/think/topics/hypervisors

15. 하이퍼바이저(Hypervisor, Hyper V)란? - Red Hat, accessed July 15, 2025, https://www.redhat.com/ko/topics/virtualization/what-is-a-hypervisor
16. 하이퍼바이저(Hypervisor) - DevOps Story - 티스토리, accessed July 15, 2025, https://cwal.tistory.com/15
17. 하이퍼바이저 개념 및 유형 - Note - 티스토리, accessed July 15, 2025, https://joodaeng.tistory.com/entry/%ED%95%98%EC%9D%B4%ED%8D%BC%EB%B0%94%EC%9D%B4%EC%A0%80-%EA%B0%9C%EB%85%90-%EB%B0%8F-%EC%9C%A0%ED%98%95
18. aws.amazon.com, accessed July 15, 2025, https://aws.amazon.com/what-is/hypervisor/#:~:text=A%20hypervisor%20is%20a%20software,individual%20virtual%20machines%20as%20required.
19. 하이퍼바이저 란 - 엔지니어 김인겸 - 티스토리, accessed July 15, 2025, https://dlsrua09.tistory.com/m/107
20. What is a hypervisor? - Red Hat, accessed July 15, 2025, https://www.redhat.com/en/topics/virtualization/what-is-a-hypervisor
21. [가상화] 3. 가상머신(VM)과 하이퍼바이저 쉽게 이해하기 - 일취월장, accessed July 15, 2025, https://selog.tistory.com/entry/%EA%B0%80%EC%83%81%ED%99%94-%EA%B0%80%EC%83%81%EB%A8%B8%EC%8B%A0VM%EA%B3%BC-%ED%95%98%EC%9D%B4%ED%8D%BC%EB%B0%94%EC%9D%B4%EC%A0%80-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0
22. 하이퍼바이저(Hypervisor) 개념 및 종류 - 뭉게뭉게 클라우드 - 티스토리, accessed July 15, 2025, https://nice-engineer.tistory.com/entry/%ED%95%98%EC%9D%B4%ED%8D%BC%EB%B0%94%EC%9D%B4%EC%A0%80Hypervisor-%EA%B0%9C%EB%85%90-%EB%B0%8F-%EC%A2%85%EB%A5%98
23. 1형 및 2형 하이퍼바이저 비교 - 하이퍼바이저 유형 간의 차이점 - AWS, accessed July 15, 2025, https://aws.amazon.com/ko/compare/the-difference-between-type-1-and-type-2-hypervisors/
24. 하이퍼바이저(Hypervisor)란? - 용어 사전 - 티스토리, accessed July 15, 2025, https://tech1.tistory.com/75
25. 하이퍼바이저란? - 태어난김에 개발자 - 티스토리, accessed July 15, 2025, https://born-dev.tistory.com/38
26. Type 1 vs Type 2 Hypervisors: Key Differences Explained - StorMagic, accessed July 15, 2025, https://stormagic.com/company/blog/type-1-vs-type-2-hypervisors/
27. 하이퍼바이저 - 나무위키, accessed July 15, 2025, https://namu.wiki/w/%ED%95%98%EC%9D%B4%ED%8D%BC%EB%B0%94%EC%9D%B4%EC%A0%80
28. [04.29-30] KVM, 하이퍼바이저, 전가상화, 반가상화, bridge대역 추가 - 채소의 코딩세상, accessed July 15, 2025, https://vegetableworld.tistory.com/149
29. [Cloud] Type1 vs Type2 가상화 비교 - hyeonnnnn - 티스토리, accessed July 15, 2025, https://ju-hyeon.tistory.com/41
30. [스터디 정리] 하이퍼바이저의 종류 - syyim, accessed July 15, 2025, https://lovejaco.github.io/posts/two-types-of-hypervisors/
31. 가상화 기본 개념 - Younghun Go - 티스토리, accessed July 15, 2025, https://yh-kr.tistory.com/26
32. Type 1 vs. Type 2 Hypervisor: What’s the Difference? - Sangfor Technologies, accessed July 15, 2025, https://www.sangfor.com/glossary/cloud-and-infrastructure/type-1-vs-type-2-hypervisor-key-differences
33. What’s the difference between type 1 and type 2 hypervisors? - IONOS, accessed July 15, 2025, https://www.ionos.com/digitalguide/server/know-how/hypervisor-type-1-and-type-2/
34. Type 1 vs Type 2 Hypervisors - Difference Between Hypervisor Types - AWS, accessed July 15, 2025, https://aws.amazon.com/compare/the-difference-between-type-1-and-type-2-hypervisors/
35. 하이퍼바이저 (Hypervisor)란? 가상화의 종류 - velog, accessed July 15, 2025, https://velog.io/@inhwa1025/%ED%95%98%EC%9D%B4%ED%8D%BC%EB%B0%94%EC%9D%B4%EC%A0%80-Hypervisor%EB%9E%80-%EA%B0%80%EC%83%81%ED%99%94%EC%9D%98-%EC%A2%85%EB%A5%98
36. KVM - 나무위키, accessed July 15, 2025, https://namu.wiki/w/KVM

37. Hyper-v 아키텍처

    Microsoft Learn, accessed July 15, 2025, https://learn.microsoft.com/ko-kr/virtualization/hyper-v-on-windows/reference/hyper-v-architecture

38. 하이퍼바이저(Hypervisor) - 비트코기의 IT Note - 티스토리, accessed July 15, 2025, https://itpenote.tistory.com/678
39. Intel VT-x and AMD SVM - Hardware Virtualization: the Nuts and Bolts, accessed July 15, 2025, https://www.anandtech.com/show/2480/9
40. Understanding Hardware-Assisted Virtualization - ADMIN Magazine, accessed July 15, 2025, https://www.admin-magazine.com/Articles/Hardware-assisted-Virtualization
41. Intel Virtualisation: How VT-x, KVM and QEMU Work Together - Binary Debt, accessed July 15, 2025, https://binarydebt.wordpress.com/2018/10/14/intel-virtualisation-how-vt-x-kvm-and-qemu-work-together/
42. Hyper-V 하이퍼바이저 스케줄러 유형 선택 관련 정보 - Learn Microsoft, accessed July 15, 2025, https://learn.microsoft.com/ko-kr/windows-server/virtualization/hyper-v/manage/about-hyper-v-scheduler-type-selection
43. Hyper-V 하이퍼바이저 스케줄러 유형 관리 - Learn Microsoft, accessed July 15, 2025, https://learn.microsoft.com/ko-kr/windows-server/virtualization/hyper-v/manage/manage-hyper-v-scheduler-types
44. KR101534137B1 - 가상머신을 위한 협력 스케줄링 방법 - Google Patents, accessed July 15, 2025, https://patents.google.com/patent/KR101534137B1/ko
45. 가상화 관련 용어에 대해 알아보자 - Hun, accessed July 15, 2025, https://20h.dev/post/cloud/virtualization-terms/

46. 6장. KVM으로 과다 할당

    가상화 관리 가이드

    Red Hat Enterprise Linux, accessed July 15, 2025, https://docs.redhat.com/ko/documentation/red_hat_enterprise_linux/6/html/virtualization_administration_guide/chap-virtualization-tips_and_tricks-overcommitting_with_kvm

47. 중첩 가상화 환경에서 메모리 오버커밋을 하는 하이퍼바이저 VM과 중첩 VM의 성능 평가, accessed July 15, 2025, https://koreascience.kr/article/CFKO201335553770993.pdf
48. vSphere Resource Monitoring - 가상 CPU 및 메모리 개념 - ma-you-ing - 티스토리, accessed July 15, 2025, https://ma-you-ing.tistory.com/33
49. Virtualization 101 - (3.1) 메모리 오버커밋과 메모리 여유공간 확보 방법, accessed July 15, 2025, https://velog.io/@sjuhwan/Virtualization-101-3-1-%EB%A9%94%EB%AA%A8%EB%A6%AC-%EC%98%A4%EB%B2%84%EC%BB%A4%EB%B0%8B%EA%B3%BC-%EB%A9%94%EB%AA%A8%EB%A6%AC-%EC%97%AC%EC%9C%A0%EA%B3%B5%EA%B0%84-%ED%99%95%EB%B3%B4-%EB%B0%A9%EB%B2%95

50. 단일 루트 I/O 가상화 개요(SR-IOV) - Windows drivers

    Microsoft Learn, accessed July 15, 2025, https://learn.microsoft.com/ko-kr/windows-hardware/drivers/network/overview-of-single-root-i-o-virtualization–sr-iov-

51. SR-IOV - IBM, accessed July 15, 2025, https://www.ibm.com/docs/ko/power10/9105-22B?topic=networking-single-root-io-virtualization
52. I/O Virtualization Hardware - ssup2 Blog / Software, accessed July 15, 2025, https://ssup2.github.io/blog-software/docs/theory-analysis/io-virtualization-hardware/
53. vSphere ESXi 기본개념과 기능 - Watch & Learn - 티스토리, accessed July 15, 2025, https://watch-n-learn.tistory.com/100
54. VMware vSphere 표준 제안서 - 이십일세기소프트, accessed July 15, 2025, https://21soft.co.kr/pdf/solution/6.%EA%B0%80%EC%83%81%ED%99%94%EC%86%94%EB%A3%A8%EC%85%98vmware%ED%91%9C%EC%A4%80%EC%A0%9C%EC%95%88%EC%84%9C_21CS.pdf
55. VMware vSphere 솔루션 개요, accessed July 15, 2025, https://docs.netapp.com/ko-kr/ontap-apps-dbs/vmware/vmware_vmsc_solution.html
56. KVM 가상화 개요, accessed July 15, 2025, https://docs.netapp.com/ko-kr/netapp-solutions/kvm/kvm-overview.html
57. QEMU - ArchWiki, accessed July 15, 2025, https://wiki.archlinux.org/title/QEMU
58. KVM이란? - Red Hat, accessed July 15, 2025, https://www.redhat.com/ko/topics/virtualization/what-is-KVM
59. All you need to know about KVM userspace - Red Hat, accessed July 15, 2025, https://www.redhat.com/en/blog/all-you-need-know-about-kvm-userspace

60. Hyper-V 기술 개요

    Microsoft Learn, accessed July 15, 2025, https://learn.microsoft.com/ko-kr/windows-server/virtualization/hyper-v/hyper-v-overview

61. 부록 B: Hyper-V 아키텍처 및 기능 개요 - BizTalk Server

    Microsoft Learn, accessed July 15, 2025, https://learn.microsoft.com/ko-kr/biztalk/technical-guides/appendix-b-hyper-v-architecture-and-feature-overview

62. Hyper-V technology overview

    Microsoft Learn, accessed July 15, 2025, https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/hyper-v-overview

63. [Hyper-V] Hyper-V 시작하기 - 김사장네 - 티스토리, accessed July 15, 2025, https://ceokim08.tistory.com/47
64. Xen Project Software Overview, accessed July 15, 2025, https://wiki.xenproject.org/wiki/Xen_Project_Software_Overview
65. Xen virtualization architecture - Unitrends Administrator’s Guide, accessed July 15, 2025, https://guides.unitrends.com/documents/legacy-rs-ueb-admin-guide/content/lag/xen_virtualization_architectur.htm
66. Xen vs KVM: What Is The Difference? - ServerMania, accessed July 15, 2025, https://www.servermania.com/kb/articles/xen-vs-kvm
67. Xen vs. KVM in performance - Server Fault, accessed July 15, 2025, https://serverfault.com/questions/41972/xen-vs-kvm-in-performance

68. Xen vs. KVM - Comparison of Hypervisors

    Storware BLOG, accessed July 15, 2025, https://storware.eu/blog/xen-vs-kvm-comparison-of-hypervisors/

69. Oracle VirtualBox 가상머신 만들기 - 바닥코딩 - 티스토리, accessed July 15, 2025, https://dkkim2318.tistory.com/116
70. Oracle VM VirtualBox란 무엇인가 - 오경석의 개발노트 - 티스토리, accessed July 15, 2025, https://proengineer.tistory.com/50
71. VMware 가상머신 환경 구축 & Ubuntu 리눅스 설치 (2024.03.01. 작성), accessed July 15, 2025, https://hackingisly.tistory.com/545
72. VirtualBox - 나무위키, accessed July 15, 2025, https://namu.wiki/w/VirtualBox
73. [vmware] vmware는 왜 쓰는가? 여러 장점과 서버 구축 가능!, accessed July 15, 2025, https://louis-j.tistory.com/entry/vmware-vmware%EB%8A%94-%EC%99%9C-%EC%93%B0%EB%8A%94%EA%B0%80-%EC%97%AC%EB%9F%AC-%EC%9E%A5%EC%A0%90%EA%B3%BC-%EC%84%9C%EB%B2%84-%EA%B5%AC%EC%B6%95-%EA%B0%80%EB%8A%A5
74. 실시간 마이그레이션이란? - Red Hat, accessed July 15, 2025, https://www.redhat.com/ko/topics/virtualization/what-is-live-migration
75. Hyper-V R2 Live Migration - Simple Talk - Redgate Software, accessed July 15, 2025, https://www.red-gate.com/simple-talk/devops/containers-and-virtualization/hyper-v-r2-live-migration/
76. Hyper-V - VM Live Migration, accessed July 15, 2025, https://ramprasadtech.com/wp-content/uploads/2017/10/Live-Migration-Deep-dive.pdf

77. 2.3. Migration

    가상화 시작하기 가이드

    Red Hat Enterprise Linux

    7, accessed July 15, 2025, https://docs.redhat.com/ko/documentation/red_hat_enterprise_linux/7/html/virtualization_getting_started_guide/sec-migration

78. 실시간 마이그레이션 문제 해결 - Windows Server - Learn Microsoft, accessed July 15, 2025, https://learn.microsoft.com/ko-kr/troubleshoot/windows-server/virtualization/troubleshoot-live-migration-issues
79. Virtio live migration technical deep dive - Red Hat Developer, accessed July 15, 2025, https://developers.redhat.com/articles/2024/02/21/virtio-live-migration-technical-deep-dive
80. 클러스터 환경에 Hyper-V Live Migration을 구축합니다 - NetApp, accessed July 15, 2025, https://docs.netapp.com/ko-kr/ontap-apps-dbs/microsoft/win_deploy_hyperv_lmce.html
81. What Is Virtual Desktop Infrastructure (VDI)? - Microsoft Azure, accessed July 15, 2025, https://azure.microsoft.com/en-us/resources/cloud-computing-dictionary/what-is-virtual-desktop-infrastructure-vdi
82. What is VDI? Virtual Desktop Infrastructure Explained - Nutanix, accessed July 15, 2025, https://www.nutanix.com/info/what-is-vdi

83. What is Hyper-V VDI and Its Benefits

    DiskInternals, accessed July 15, 2025, https://www.diskinternals.com/vmfs-recovery/hyper-v-vdi/

84. Hypervisor Security in Cloud Computing - GeeksforGeeks, accessed July 15, 2025, https://www.geeksforgeeks.org/devops/hypervisor-security-in-cloud-computing/
85. How to Secure Virtualized Environments, accessed July 15, 2025, https://www.aquasec.com/cloud-native-academy/cspm/virtualized-security/
86. What Is Hyperjacking? Everything You Need to Know - ServerWatch, accessed July 15, 2025, https://www.serverwatch.com/virtualization/hyperjacking/
87. Preventing Hyperjacking in a virtual environment - Entrust, accessed July 15, 2025, https://www.entrust.com/blog/2022/11/preventing-hyperjacking-in-a-virtual-environment
88. What Is A Hypervisor-Level Attack? - ITU Online IT Training, accessed July 15, 2025, https://www.ituonline.com/tech-definitions/what-is-a-hypervisor-level-attack/
89. Virtualization Under Siege: A Deep Dive into VMware’s Hypervisor Security Nightmare, accessed July 15, 2025, https://cybersrcc.com/2025/03/11/virtualization-under-siege-a-deep-dive-into-vmwares-hypervisor-security-nightmare/
90. Virtual machine escape - Wikipedia, accessed July 15, 2025, https://en.wikipedia.org/wiki/Virtual_machine_escape
91. www.reanin.com, accessed July 15, 2025, https://www.reanin.com/reports/global-hypervisor-market#:~:text=In%20the%20year%202024%2C%20the,(CAGR)%20of%204.2%25.
92. Global Hypervisor Market Growth, Share, Size, Trends and Forecast (2025 - 2031), accessed July 15, 2025, https://www.reanin.com/reports/global-hypervisor-market
93. Hypervisor Market Growth, Trends Analysis Report by 2033 - Business Research Insights, accessed July 15, 2025, https://www.businessresearchinsights.com/market-reports/hypervisor-market-118279
94. VMware vSphere Pricing: Costs, Licensing & Alternatives - Apporto, accessed July 15, 2025, https://www.apporto.com/vmware-pricing-and-licensing
95. Licensing and Subscription in vSphere - Broadcom TechDocs, accessed July 15, 2025, https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vcenter-and-host-management-8-0/license-management-host-management/licensing-for-products-in-vsphere-host-management.html
96. VMware vSphere Pricing in 2024: Licensing and Overhead Costs - V2 Cloud, accessed July 15, 2025, https://v2cloud.com/blog/vmware-vsphere-licensing-and-costs

97. Microsoft Windows Server

    Microsoft Licensing Resources, accessed July 15, 2025, https://www.microsoft.com/en-us/licensing/product-licensing/windows-server

98. Windows Server Core Licensing Calculator - HPE Support, accessed July 15, 2025, https://support.hpe.com/docs/display/public/hpe-ms-licensing-cal/index.html
99. Docker Containers vs. VMs: A Look at the Pros and Cons - Backblaze, accessed July 15, 2025, https://www.backblaze.com/blog/vm-vs-containers/
100. VM vs. Container: Ultimate 2024 Showdown - Aqua Security, accessed July 15, 2025, https://www.aquasec.com/cloud-native-academy/docker-container/vm-vs-container/
101. Docker vs. Virtual Machines: Differences You Should Know - QA, accessed July 15, 2025, https://www.qa.com/en-us/resources/blog/docker-vs-virtual-machines-differences-you-should-know/
102. Performance comparison between docker and virtual machine - Vinchin Backup & Recovery, accessed July 15, 2025, https://www.vinchin.com/vm-tips/performance-comparison-between-docker-and-virtual-machine.html
103. Are there any reasons to choose VMs over containers? : r/devops - Reddit, accessed July 15, 2025, https://www.reddit.com/r/devops/comments/qvzrkm/are_there_any_reasons_to_choose_vms_over/
104. Container Vs Hypervisor: The Verdict - Nutanix, accessed July 15, 2025, https://www.nutanix.com/how-to/container-vs-hypervisor-the-verdict
105. Will OpenMetal OpenStack Offer Serverless or Cloud-Hypervisor vs Unikernel vs Firecracker, accessed July 15, 2025, https://openmetal.io/resources/blog/openstack-cloud-hypervisor-unikernel-firecracker/
106. Exploring the Power of AWS Lambda: A Deep Dive into Firecracker MicroVMs, accessed July 15, 2025, https://businesscompassllc.com/exploring-the-power-of-aws-lambda-a-deep-dive-into-firecracker-microvms/
107. Firecracker internals: a deep dive inside the technology powering AWS Lambda, accessed July 15, 2025, https://www.talhoffman.com/2021/07/18/firecracker-internals/
108. Deep dive into firecracker-containerd - awsstatic.com, accessed July 15, 2025, https://d1.awsstatic.com/events/reinvent/2019/REPEAT_1_Deep_dive_into_firecracker-containerd_CON408-R1.pdf
109. How AWS Firecracker works: a deep dive - Unixism, accessed July 15, 2025, https://unixism.net/2019/10/how-aws-firecracker-works-a-deep-dive/
110. kata-containers/docs/design/architecture/README.md at main - GitHub, accessed July 15, 2025, https://github.com/kata-containers/kata-containers/blob/main/docs/design/architecture/README.md
111. What are Kata Containers? - Bunny.net, accessed July 15, 2025, https://bunny.net/academy/computing/what-are-kata-containers/
112. Kata Containers: An Overview - Arun Prasad - Medium, accessed July 15, 2025, https://arunprasad86.medium.com/kata-containers-an-overview-7ed95dacfb7a

113. Kata Containers - Open Source Container Runtime Software

     Kata Containers, accessed July 15, 2025, https://katacontainers.io/

114. Kata Containers: a Revolution in Container Isolation? › Cloudification - We build Clouds ☁️, accessed July 15, 2025, https://cloudification.io/cloud-blog/kata-containers-workload-isolation/
115. Unikernel - Wikipedia, accessed July 15, 2025, https://en.wikipedia.org/wiki/Unikernel
116. All About Unikernels: Part 1, What They Are, What They Do, and What’s New, accessed July 15, 2025, https://blog.container-solutions.com/all-about-unikernels-part-1-what-they-are
117. en.wikipedia.org, accessed July 15, 2025, https://en.wikipedia.org/wiki/Unikernel#:~:text=Unikernels%20lend%20themselves%20to%20creating,Unikernels’%20high%20degree%20of%20specialization.
118. Are unikernels dead? : r/osdev - Reddit, accessed July 15, 2025, https://www.reddit.com/r/osdev/comments/1alh52u/are_unikernels_dead/