하이퍼바이저, 그리고 VM vs 컨테이너

하이퍼바이저 (Hypervisor)

하이퍼바이저는 한 대의 물리 서버 위에서 여러 개의 가상 머신(VM)을 동시에 돌릴 수 있게 해주는 소프트웨어다. "가짜 컴퓨터를 여러 개 만들어내는 관리자" 정도로 이해하면 된다.

---

Type 1 (베어메탈) — 하드웨어 위에 바로 설치

별도의 OS 없이, 하드웨어에 하이퍼바이저 자체가 직접 설치되는 방식이다. 하이퍼바이저 자신이 사실상 OS 역할까지 겸한다고 보면 된다.

 

대표적으로 기업 데이터센터에서 가장 널리 쓰이는 VMware ESXi가 있다. 서버를 사면 그 위에 Windows나 Linux를 먼저 깔지 않고 ESXi를 바로 설치한다. Windows Server에 내장된 Hyper-V도 서버 관리자 역할(Role)로 추가하면 베어메탈에 가깝게 동작한다. 오픈소스 하이퍼바이저인 Xen은 예전 AWS EC2가 초창기에 채택했던 방식이기도 하다(지금은 AWS가 자체 개발한 Nitro로 많이 넘어갔다).

 

성능이 좋은 이유는 간단하다. 하드웨어와 VM 사이에 중간 단계, 즉 호스트 OS라는 게 없기 때문이다. 자원을 오가는 경로가 짧으니 그만큼 손실도 적다. 그래서 실제 데이터센터나 클라우드 업체(AWS, Azure, GCP 전부)는 예외 없이 Type 1을 쓴다.

---

Type 2 (호스트형) — 기존 OS 위에 얹는 방식

 

이미 깔려 있는 Windows나 macOS 같은 일반 OS 위에, 하이퍼바이저를 그냥 하나의 프로그램처럼 설치해서 쓰는 방식이다.

내 Windows PC 위에 설치해서 그 안에서 또 다른 OS를 띄워 테스트하는 VMware Workstation/Fusion, 개발자들이 로컬에서 "리눅스 환경 하나만 잠깐 써보고 싶은데" 할 때 흔히 쓰는 무료 도구 VirtualBox, Mac에서 Windows를 돌리고 싶을 때 쓰는 Parallels Desktop이 대표적이다.

 

데이터센터에서 이 방식을 쓰지 않는 이유는 계층이 하나 더 늘어나기 때문이다. 자원 요청이 "VM → 하이퍼바이저 → 호스트 OS → 하드웨어" 순서로 한 단계 더 거쳐야 해서 그만큼 성능 손실이 생긴다. 대신 설치가 쉽고 평소 쓰던 PC에서 바로 테스트해볼 수 있다는 편의성 덕분에 개인 개발이나 학습 용도로는 여전히 애용된다.

---

VM vs 컨테이너

VM — OS 전체를 통째로 복제

VM은 하이퍼바이저 위에 커널까지 포함한 OS 전체를 새로 띄우는 방식이다. VM 하나하나가 각자 독립된 완전한 컴퓨터처럼 동작한다.

AWS EC2의 기본 architecture

 

AWS EC2 인스턴스 하나를 띄운다고 생각해보면 감이 잘 온다. Ubuntu를 선택하면, 그 인스턴스 안에는 Ubuntu의 커널부터 전체 파일시스템까지 통째로 새로 만들어진다. 인스턴스 하나 부팅하는 데 보통 수십 초에서 1분 정도 걸리는 이유가 바로 이 "OS 전체를 새로 켜는" 과정 때문이다.

 

VM A와 VM B는 커널부터 완전히 분리되어 있어서, VM A에서 아무리 문제가 생겨도 VM B에는 구조적으로 영향을 주기 어렵다. 은행 같은 곳에서 민감한 시스템을 VM으로 분리해서 운영하는 이유가 여기 있다.

---

컨테이너 — 커널은 공유, 프로세스만 격리

컨테이너는 호스트 OS의 커널을 그대로 같이 쓰면서, 프로세스 단위로만 격리한다. 새 OS를 켜는 게 아니라, 이미 켜져 있는 OS 위에서 "울타리 쳐진 프로세스"를 하나 실행하는 것에 가깝다.

 

Docker로 Nginx 컨테이너를 하나 띄운다고 하면, 이건 새로운 OS를 부팅하는 게 아니라 호스트에 이미 떠 있는 리눅스 커널 위에서 "Nginx 프로세스 + 그 프로세스 전용 파일 환경"만 딱 만들어서 실행하는 것이다. 그래서 부팅이 아니라 그냥 실행이고, 보통 1초 이내로 뜬다.

 

가벼운 이유는 명확하다. OS를 통째로 새로 켜는 VM과 달리, 이미 떠 있는 커널을 재활용하기 때문에 메모리도 훨씬 적게 먹고 속도도 압도적으로 빠르다. 같은 서버 한 대에 VM은 많아야 몇십 개 띄울 수 있는 반면, 컨테이너는 수백 개까지도 띄울 수 있다.

 

다만 커널을 공유한다는 게 곧 약점이기도 하다. 만약 커널 자체에 취약점이 있다면, 한 컨테이너에서 문제가 생겼을 때 같은 호스트의 다른 컨테이너나 호스트 자체에 영향을 줄 가능성이 VM보다 크다. 그래서 정말 민감한 워크로드를 컨테이너로 돌릴 때는 커널 격리를 강화한 별도 기술(gVisor, Kata Containers 등)을 추가로 쓰기도 한다.

---

표로 비교하면

구분	VM	컨테이너
가상화 단위	OS 전체(커널 포함)	프로세스 (커널 공유)
부팅 속도	수십 초~분 단위	1초 이내
자원 사용량	무겁다 (OS마다 별도 메모리/CPU)	가볍다
격리 수준	강함 (커널부터 분리)	상대적으로 약함 (커널 공유)
대표 예시	VMware VM, AWS EC2	Docker, Kubernetes Pod
대표 사용처	민감 시스템, 완전 독립 환경 필요 시	마이크로서비스, 빠른 배포/확장

---

실무에서는 이렇게 섞어 쓴다

 

재밌는 건, 실제 클라우드에서는 VM과 컨테이너가 배타적이지 않고 겹쳐서 쓰인다는 점이다. Kubernetes 클러스터를 구성할 때, 그 클러스터를 이루는 노드(서버) 자체는 보통 VM(예: AWS EC2)이고, 그 VM 안에서 다시 여러 개의 컨테이너(Pod)를 띄운다. 즉 "큰 격리 단위는 VM으로, 그 안의 빠른 배포 단위는 컨테이너로" 이중 구조를 쓰는 게 요즘 클라우드 인프라의 표준적인 모습이다.

---

정리

 

하이퍼바이저는 Type 1(베어메탈)이 성능 때문에 실제 데이터센터/클라우드의 표준이고, Type 2(호스트형)는 편의성 덕분에 개인 테스트용으로 쓰인다.

VM과 컨테이너는 "OS 전체를 복제하느냐, 커널만 공유하고 프로세스만 나누느냐"의 차이이며, 이는 곧 격리 수준과 가벼움 사이의 트레이드오프로 이어진다. 그리고 실무에서는 이 둘을 겹겹이 쌓아 VM 위에 컨테이너를 올리는 방식으로, 격리와 속도를 동시에 챙기는 구조가 표준으로 자리잡았다.