하이퍼바이저부터 Docker까지: 가상화 기술과 성능 튜닝 실무 가이드
Type 1/Type 2 하이퍼바이저와 Docker 컨테이너의 구조 차이, 그리고 CPU·메모리·스토리지·네트워크 단에서 가상화 오버헤드를 줄이는 방법을 정리한다
2026-08-12 · 최초 발행 2026-01-16
물리 서버 한 대를 여러 독립된 실행 환경으로 쪼개 쓰는 방법은 크게 두 갈래다. 하드웨어를 통째로 흉내 내는 하이퍼바이저 기반 가상 머신, 그리고 커널을 공유하면서 프로세스만 격리하는 컨테이너. 둘의 경계선을 어디에 긋느냐에 따라 성능, 격리 수준, 운영 복잡도가 크게 달라진다.
가상화가 해결하는 문제
가상화는 물리적 자원(CPU, 메모리, 디스크, 네트워크)을 논리적으로 쪼개거나 묶어서 독립된 실행 환경을 만드는 기술이다. 각 환경은 서로 격리되어 있고(Isolation), 상태를 저장해 다른 곳으로 옮길 수 있으며(Encapsulation), 물리적 구성이 바뀌어도 영향을 받지 않는다.
이게 실무에서 갖는 의미는 명확하다. 물리 서버 수를 줄여 전력·공간 비용을 아끼고, 스냅샷과 라이브 마이그레이션으로 운영 부담을 낮추고, 개발·테스트 환경을 빠르게 복제해 여러 OS를 동시에 검증할 수 있다. 장애가 나도 백업 VM으로 빠르게 복구할 수 있다는 점도 크다.
하이퍼바이저: 베어메탈이냐 호스티드냐
가상 머신을 만들고 관리하는 소프트웨어 계층이 하이퍼바이저(VMM, Virtual Machine Monitor)다. CPU 스케줄링, 메모리 관리, I/O 에뮬레이션, 자원 격리를 담당하며, 어디에 설치되느냐로 두 종류로 나뉜다.
Type 1(베어메탈) 은 물리 하드웨어 위에 직접 설치된다.
+---------------------------+
| 가상 머신들 |
+---------------------------+
| Type 1 하이퍼바이저 |
+---------------------------+
| 물리 하드웨어 |
+---------------------------+
VMware ESXi, Microsoft Hyper-V, Citrix XenServer, Linux 커널 모듈인 KVM, Oracle VM Server가 여기 속한다. OS 계층이 없으니 오버헤드가 낮고 성능이 높지만, 그만큼 하드웨어 호환성이 까다롭고 설치·관리가 복잡하다. 데이터센터 서버 통합, AWS·Azure 같은 클라우드 서비스, 엔터프라이즈 가상화처럼 고성능이 필요한 환경에 쓰인다.
Type 2(호스티드) 는 기존 운영체제 위에서 일반 애플리케이션처럼 실행된다.
+---------------------------+
| 가상 머신들 |
+---------------------------+
| Type 2 하이퍼바이저 |
+---------------------------+
| 호스트 OS |
+---------------------------+
| 물리 하드웨어 |
+---------------------------+
VMware Workstation·Fusion, Oracle VirtualBox, Parallels Desktop, QEMU가 대표적이다. 설치가 간편하고 하드웨어 지원 범위도 넓어 호스트 OS와 동시에 쓰기 좋지만, OS 계층이 하나 더 끼는 만큼 성능 오버헤드와 자원 경쟁이 생긴다. 개발·테스트 환경, 데스크톱 가상화, 교육용 실습처럼 개인 사용자 환경에 어울린다.
| 특성 | Type 1 | Type 2 |
|---|---|---|
| 설치 위치 | 베어메탈 | 호스트 OS 위 |
| 성능 | 높음 | 중간 |
| 오버헤드 | 낮음 | 높음 |
| 설치 | 복잡 | 간단 |
| 적용 대상 | 데이터센터 | 개발 환경 |
| 대표 제품 | ESXi, Hyper-V | VirtualBox, VMware WS |
컨테이너는 왜 가벼운가
컨테이너는 운영체제 수준 가상화로, 호스트 커널을 그대로 공유하면서 프로세스만 격리한다. 별도 OS가 필요 없으니 이미지 크기는 MB 단위, 시작 시간은 초 단위, 오버헤드는 거의 없는 수준까지 떨어진다. 반면 VM은 각자 Guest OS를 통째로 띄우기 때문에 GB 단위 크기와 분 단위 부팅, 10~20% 수준의 오버헤드를 감수해야 한다.
Docker Engine은 세 층으로 나뉜다. 데몬 프로세스인 dockerd, 실제 컨테이너 런타임인 containerd, OCI 표준을 구현하는 runc다. 이미지는 레이어드 파일 시스템 위에 만들어진 읽기 전용 템플릿이고(OverlayFS·AUFS 같은 Union FS를 씀), 컨테이너는 그 이미지에 쓰기 가능한 최상위 레이어를 얹은 실행 인스턴스다. 이미지를 주고받는 곳이 레지스트리인데, 공개용은 Docker Hub, 조직 내부용은 Private Registry를 쓴다.
이 격리를 실제로 만드는 건 리눅스 커널 기능 세 가지의 조합이다.
- Linux Namespace — PID(프로세스), NET(네트워크 인터페이스), MNT(마운트 포인트), UTS(호스트명), IPC(프로세스 간 통신), USER(사용자·그룹)를 각각 별도 네임스페이스로 분리한다.
- cgroups(Control Groups) — CPU 사용률, 메모리, 디스크 I/O, 네트워크 대역폭에 상한을 건다.
- Union File System — 레이어 기반 이미지에 Copy-on-Write를 적용해 이미지 빌드를 빠르게 하고 스토리지를 절약한다.
워크플로우는 Dockerfile 작성 → docker build로 이미지 생성 → docker push로 레지스트리 업로드, 그리고 운영 쪽에서는 docker pull로 이미지를 받아 docker run으로 컨테이너를 띄우고 docker logs·docker stop/start로 제어하는 흐름이다.
컨테이너가 여러 대로 늘어나면 오케스트레이션이 필요해진다. Kubernetes는 배포 자동화, 로드 밸런싱, self-healing, 롤링 업데이트, 서비스 디스커버리를 제공하며 Pod(최소 배포 단위)·Service(네트워크 엔드포인트)·Deployment·ReplicaSet 같은 개념으로 구성된다. 더 간단한 설정으로 소규모 클러스터를 운영하려면 Docker 네이티브 오케스트레이션인 Docker Swarm도 선택지다.
오버헤드를 줄이는 지점들
가상화 성능 최적화는 결국 "OS 계층이 하나 더 낀 대가"를 어디서 얼마나 회수하느냐의 문제다.
하드웨어 단에서는 Intel VT-x / AMD-V가 CPU 수준에서 가상화를 지원해 Guest OS 명령을 직접 실행하게 해주고 트랩·에뮬레이션을 줄여 성능을 10~20% 끌어올린다. Intel VT-d / AMD-Vi(IOMMU)는 DMA Remapping과 장치 직접 할당(Device Passthrough)으로 I/O 가상화 성능을 높이고, EPT(Extended Page Tables)·NPT(Nested Page Tables)는 2단계 페이지 테이블로 메모리 주소 변환과 TLB 성능을 개선한다.
CPU 쪽에서는 vCPU를 물리 CPU에 고정하는 CPU Pinning으로 캐시 효율을 높이고 컨텍스트 스위칭을 줄인다. 대규모 시스템에서는 NUMA를 인식해 로컬 메모리 접근을 우선하는 스케줄링이 중요해지고, vCPU를 물리 CPU보다 많이 할당하는 오버커밋은 1:4 이하 수준을 유지하며 사용률을 지켜봐야 한다.
메모리는 오버커밋을 다루는 기법이 여럿이다. Ballooning은 Guest OS에 드라이버를 설치해 필요할 때 메모리를 회수하고, Memory Compression은 자주 안 쓰는 페이지를 압축해 스왑보다 빠르지만 CPU 부담이 생긴다. Transparent Page Sharing(TPS)은 동일 페이지를 Copy-on-Write로 공유하는데 보안 이슈 때문에 일부 환경에서는 비활성화되어 있다. Huge Pages(2MB, 1GB)는 TLB 미스를 줄여 메모리 집약적인 애플리케이션에 유리하다.
스토리지에서는 사용한 만큼만 할당하는 Thin Provisioning(오버커밋 주의), 가상 디스크 포맷 선택(Raw는 최고 성능에 기능 제한, QCOW2는 스냅샷 지원 대신 약간 느림, VMDK는 VMware 표준), I/O 스케줄러 설정(호스트는 deadline·noop, 게스트는 SSD면 noop·HDD면 deadline)이 성능을 가른다. SR-IOV로 물리 장치를 여러 가상 장치로 쪼개거나 PCIe Passthrough로 장치를 통째로 할당하면 최고 성능을 얻지만 마이그레이션이 제약된다.
네트워크도 마찬가지 원리다. SR-IOV는 NIC의 가상 함수(VF)를 직접 할당해 하이퍼바이저를 우회하므로 거의 네이티브 성능을 낸다. virtio는 반가상화 네트워크 드라이버로 낮은 오버헤드와 폭넓은 지원을 제공하고, vhost-net은 virtio 처리를 커널 공간에서 수행해 컨텍스트 스위칭을 줄인다. 토폴로지는 유연성이 필요하면 브리지 모드, 격리가 필요하면 NAT 모드, 내부 통신만 필요하면 호스트 전용 모드를 고른다.
측정 없이는 튜닝도 없다
최적화가 실제로 먹혔는지 확인하려면 지표를 봐야 한다. CPU는 CPU Ready Time(대기 시간)·사용률·컨텍스트 스위칭 횟수, 메모리는 스왑 비율·Ballooning 사용량·페이지 공유 비율, 스토리지는 IOPS·레이턴시·처리량, 네트워크는 패킷 손실률·지연 시간·대역폭 사용률을 본다.
종합 벤치마크로는 SPECvirt, VMmark가 표준으로 쓰이고, 개별 성능은 Sysbench(CPU·메모리·I/O), iperf(네트워크), fio(스토리지 I/O), stress-ng(스트레스 테스트)로 측정한다. 모니터링은 오픈소스 쪽에서 Prometheus + Grafana(시계열), Nagios(알림), Zabbix(통합 모니터링)를 많이 쓰고, 상용으로는 VMware의 vRealize Operations, Microsoft의 System Center, 클라우드 네이티브 환경의 Datadog이 있다.
VM과 컨테이너를 섞는 이유
컨테이너의 속도와 VM의 격리를 동시에 가지려는 시도도 있다. Kata Containers는 컨테이너 하나하나를 경량 VM 안에서 실행해 Kubernetes와 호환되면서도 강화된 보안 격리를 확보하고, 컨테이너에 가까운 속도를 낸다.
AWS Lambda와 Fargate에서 쓰는 Firecracker는 더 극단적이다. 디바이스 모델을 최소화해 125ms 이내에 부팅하고 5MB 수준의 메모리 오버헤드만 남기면서도 멀티테넌트 환경에서 안전하게 격리한다. 구조는 이렇다.
Firecracker VMM → KVM → 경량 Guest Kernel → 애플리케이션
VMM 자체를 얇게 만들어 마이크로VM의 오버헤드를 줄이는 접근이다.
어디에 뭘 쓸지
고성능·안정성이 최우선인 엔터프라이즈 서버 통합에는 Type 1 하이퍼바이저(ESXi, Hyper-V)가 맞고, 편의성과 다양한 OS 테스트가 필요한 개발 환경에는 Type 2(VirtualBox)가 낫다. 마이크로서비스 배포처럼 빠른 배포·확장이 중요하면 Docker + Kubernetes 조합이 기본값이고, CI/CD 파이프라인도 빌드 속도와 재현성 때문에 컨테이너 쪽이 유리하다. 멀티테넌트 클라우드처럼 강한 격리와 효율을 동시에 요구하는 상황이라면 VM과 컨테이너를 섞는 하이브리드 구성을 고려할 만하다.