KVM, Container, MicroVM — 가상화 격리 아키텍처 분석

유정빈·2026년 6월 15일

컴퓨터 아키텍처에서 가상화(Virtualization)는 물리 자원의 효율성을 극대화하고 독립적인 실행 환경을 보장하는 핵심 기술입니다.

단일 물리 머신의 CPU, 메모리, 입출력(I/O) 대역폭을 여러 격리 환경으로 나누어 분배하는 가상화 기술은 현대 클라우드 컴퓨팅 인프라의 근간이 되었습니다.

단순히 가상화 기술과 역사적 배경과 병목 해결 과정, 그리고 최신 클라우드 인프라의 다차원 격리 모델과 트레이드오프를 깊이 있게 분석합니다.

1. 가상화가 필요했던 이유

기존 인프라 환경에서 서버는 "1 Application = 1 Physical Server" 구조로 운영되었습니다. 이 방식은 애플리케이션 간의 독립성을 보장했으나 자원이 크게 낭비되었습니다.

평균 CPU 사용률 5~15%: 물리 서버 자원 대부분이 유휴(Idle) 상태로 방치되어 공간과 전력이 낭비되었습니다.
낮은 확장성 및 긴 프로비저닝 주기: 새로운 서비스를 배포하고자 서버 하드웨어를 구매하고 OS를 설치하는 과정에 몇 주에서 몇 달씩 소요되었습니다.

가상화는 이와 같은 물리 자원의 경직성과 비효율성을 해결하고 자원 집적도(Density)와 결함 격리(Fault Isolation)를 확보하고자 등장했습니다.

x86의 구조적 한계와 Popek-Goldberg 요구사항

초기 x86(IA-32) 아키텍처는 가상화를 자체적으로 지원하기에 설계상 한계가 있었습니다.

가상화를 구현하려면 Popek-Goldberg 가상화 요구사항을 충족해야 합니다.
모든 민감한 명령어(시스템 자원 설정이나 하드웨어 상태를 바꾸는 특권 명령어)가 비특권 모드(Guest OS가 실행되는 모드)에서 실행될 때 하이퍼바이저로 트랩(Trap)되어 처리되어야 한다는 조건입니다.

그러나 초기 x86 아키텍처에는 `SGDT`, `SIDT`, `PUSHF`, `POPF` 등 비특권 모드(Ring 1~3)에서 호출하더라도 트랩을 유발하지 않고 조용히 실패하거나 호스트 상태를 그대로 노출하는 17개의 민감한 비특권 명령어(Sensitive Non-privileged Instructions)가 존재했습니다.

이를 해결하고자 하이퍼바이저들은 다음과 같은 우회 방법을 사용했습니다.

완전 가상화 (Full Virtualization) & 바이너리 번역 (Binary Translation):
Guest OS가 실행할 특권 명령어를 하이퍼바이저가 실시간으로 안전한 코드로 번역하여 실행하는 방식입니다. 다만 CPU 오버헤드가 크다는 단점이 있었습니다.
반가상화 (Paravirtualization):
Guest OS의 커널 코드를 직접 수정하여 특권 명령어가 수행되어야 할 자리에 하이퍼바이저를 직접 호출하는 하이퍼콜(Hypercall) 인터페이스를 심는 방식입니다.
커널 소스가 닫혀 있는 독점 OS(예: Windows)에는 적용하기 어려웠습니다.

이후 2005~2006년 Intel의 Intel VT-x 및 AMD의 AMD-V와 같은 하드웨어 지원 가상화(Hardware-Assisted Virtualization)가 출시되면서 x86의 구조적 제약이 해소되었습니다.

CPU 하드웨어 자체에 하이퍼바이저용 권한 모드인 VMX Root Mode와 Guest OS를 위한 VMX Non-Root Mode가 내장되어 Guest OS 코드 수정 없이도 민감한 명령어를 실행할 때 하드웨어 수준에서 자동으로 하이퍼바이저에 제어권을 넘겨주는 VMEXIT 메커니즘이 완성되었습니다.

2. 가상화 기술의 진화

가상화 및 격리 기술은 단순히 나열하는 데 그치지 않고 성능 손실 줄이기, 기동 시간 단축, 보안 격리 수준 향상이라는 세 가지 목표를 향해 진화했습니다.

Physical Server: 하드웨어 리소스를 직접 점유하며 격리 경계가 없음.
Hypervisor (VM): 하드웨어를 에뮬레이션하여 운영체제를 완전히 분리. 강력한 격리(Security)를 제공하지만 무겁고 부팅이 느림.
Hardware-Assisted Virtualization: CPU 지원(VT-x)으로 VM 성능을 개선하고 하이퍼콜 표준화 적용.
Container: 호스트 커널을 공유하여 에뮬레이션 레이어 제거. 초경량이며 밀리초(ms) 단위 기동 속도 확보.
MicroVM & Sandbox: 컨테이너의 기동 속도와 VM의 하드웨어 격리 수준을 절충한 하이브리드 기술.

3. Type 1 vs. Type 2 하이퍼바이저

하이퍼바이저(Hypervisor) 또는 가상 머신 모니터(Virtual Machine Monitor, VMM)는 물리 호스트 시스템 위에 가상 머신(Virtual Machine, VM)을 생성하고 관리하는 소프트웨어 계층입니다.

Type 1 (Bare-Metal/Native) 하이퍼바이저:
- 하이퍼바이저가 호스트 OS 없이 물리 하드웨어 바로 위에서 구동되는 아키텍처입니다(예: VMware ESXi, Xen, KVM).
- 하이퍼바이저 자체가 최소한의 OS 역할을 수행하므로 OS 구동에 낭비되는 자원이 없고 디바이스 드라이버가 하이퍼바이저에 내장되어 입출력 성능 손실이 매우 적습니다.

Type 2 (Hosted) 하이퍼바이저:
- 일반 호스트 운영체제(Windows, macOS 등) 위에 하나의 애플리케이션처럼 설치되어 작동하는 하이퍼바이저입니다(예: VirtualBox, VMware Workstation).
- Guest OS가 하드웨어 제어를 요청할 때마다 `Guest OS -> 하이퍼바이저 -> Host OS -> 물리 하드웨어` 순서로 컨텍스트 스위칭이 일어나므로 입출력(I/O) 지연이 늘어나고 성능이 떨어집니다.

4. KVM & QEMU 아키텍처

리눅스 환경에서 널리 쓰이는 가상화는 커널 모듈인 KVM (Kernel-based Virtual Machine)과 사용자 공간 에뮬레이터인 QEMU의 조합으로 이루어집니다.

KVM:
리눅스 커널을 하이퍼바이저(Type 1)로 변환해 주는 커널 모듈입니다. CPU의 하드웨어 가상화 기술(Intel VT-x)을 활성화해 Guest OS의 CPU/메모리 연산을 하드웨어 수준에서 직접 실행(VMX Non-Root Mode)하도록 지원합니다.
QEMU:
사용자 공간에서 작동하며 PCI 버스, 디스크 컨트롤러, 네트워크 카드 등 가상 하드웨어 디바이스들을 에뮬레이션합니다. KVM은 CPU와 메모리 가상화만 담당하므로 나머지 주변 장치는 QEMU가 직접 가상화하여 온전한 VM 환경을 구축합니다.

VMEXIT 작동 메커니즘

Guest OS가 실행되는 동안 하드웨어 가상화 모드(VMX Non-Root Mode)에서 실행할 수 없는 명령(예: 실제 하드웨어 포트에 접근하는 I/O 포트 입출력, CPU 상태 레지스터 조작 등)을 만나면 CPU는 동작을 멈추고 제어권을 호스트 KVM으로 넘깁니다. 이를 VMEXIT라고 합니다.

Guest OS: I/O 명령 수행 시도.
CPU: 하드웨어 가상화 기능에 의해 하이퍼바이저 모드로 제어권 전환 (VMEXIT 발생).
KVM (Kernel): 하드웨어 트랩을 수신하고 CPU 레지스터 상태를 확인하여 가상 하드웨어 조작이 필요함을 판별.
QEMU (User Space): KVM이 전달한 상태값을 바탕으로 가상 디바이스 상태를 업데이트하거나 호스트 파일 시스템에 접근하여 가상 디바이스 입출력을 에뮬레이션.
KVM & CPU: 작업이 완료되면 CPU 컨텍스트를 Guest OS 상태로 복구하고 다시 Guest OS 모드로 진입 (VMENTER 발생).

이 과정은 사용자 공간과 커널 공간, 호스트와 게스트 간에 상당한 컨텍스트 스위칭 비용을 유발합니다. 따라서 VMEXIT가 자주 발생하면 가상 머신의 성능을 떨어뜨리는 주원인이 됩니다.

5. VirtIO와 I/O 성능 최적화

초기 VM 가상화 성능 최적화의 최대 과제는 가상 장치 에뮬레이션 시 빈번히 발생하는 VMEXIT를 줄이는 일이었습니다. 이를 해결하고자 나타난 규격이 VirtIO 가상화 프레임워크입니다.

VirtIO는 Guest OS가 가상 드라이버임을 인지하고 작동하는 반가상화(Paravirtualized) 드라이버 방식입니다. 기존 물리 디바이스 규격(예: Intel e1000 랜카드)의 느린 에뮬레이션 단계를 거치지 않습니다.

동작 원리:
Guest OS 내부의 VirtIO Front-end 드라이버와 Host(QEMU/KVM)에 상주하는 VirtIO Back-end 드라이버가 물리 디바이스 인터페이스 대신 약속된 공유 메모리 영역인 Virtqueue(공유 메모리 링 버퍼)로 직접 패킷과 데이터를 교환합니다.
오버헤드 감소 메커니즘:
- 배치 처리(Batching): I/O 요청 하나당 VMEXIT를 한 번씩 유발하던 전통적인 방식과 달리 Guest는 Virtqueue에 여러 요청을 적재한 뒤 하이퍼콜(Doorbell) 한 번으로 Host에 일괄 통지합니다.
- 폴링 모드(Polling Mode): 초고속 I/O가 지속되는 고부하 환경에서는 Host와 Guest가 인터럽트 및 하이퍼콜 통지를 전혀 쓰지 않고 Virtqueue의 링 버퍼를 주기적으로 체크하는 폴링 방식으로 구동해 VMEXIT 오버헤드를 최소화합니다.
실무적 영향: VirtIO가 탑재된 가상 디스크(`virtio-blk`) 및 네트워크 인터페이스(`virtio-net`)를 채택할 경우 가상화 I/O 성능이 물리 머신의 95~98% 수준에 달할 정도로 안정적인 성능을 냅니다.

6. 컨테이너 가상화

운영체제 수준 가상화(Containerization)는 하드웨어 추상화 계층을 완전히 제거하고 호스트 리눅스 커널 하나를 여러 사용자 공간(User Space)이 안전하게 나누어 쓰는 모델입니다.

컨테이너 가상화는 하이퍼바이저와 중복 OS 커널을 걷어내어 기동 시간을 밀리초(ms) 단위로 단축합니다.

또한 네이티브 환경 대비 가상화 오버헤드가 거의 없어 높은 자원 집적도(Density)를 확보할 수 있습니다.

이를 구현하고자 리눅스 커널은 두 가지 핵심 기술을 제공합니다.

1) Namespaces: 자원 논리 격리

하나의 운영체제 내에서 특정 프로세스 그룹이 자원을 독점하는 것처럼 격리해 주는 기술입니다.

PID Namespace: 호스트 프로세스 트리와 분리된 독자적인 PID 체계를 부여하여 컨테이너 내부 프로세스가 PID 1번을 갖도록 분리합니다.
NET Namespace: 독립적인 네트워크 디바이스, IP 주소, 라우팅 테이블, 포트 바인딩을 격리하여 관리합니다.
MNT Namespace: 호스트 파일 시스템 마운트 포인트와 독립된 격리 마운트 트리를 제공하여 컨테이너 내부의 변경 사항이 호스트로 유출되지 않도록 차단합니다.
IPC, UTS, USER Namespace: 프로세스 간 통신(IPC), 호스트네임(UTS), 사용자/그룹 ID 매핑(USER)을 독립적으로 분리합니다.

2) cgroups: 물리 자원 한도 제어

프로세스 그룹별로 물리적 하드웨어 자원(CPU, 메모리, 스토리지 I/O, 네트워크 대역폭)의 사용 한도를 제한하고 추적하는 커널 기능입니다.

cgroups v1 vs. cgroups v2:
- cgroups v1은 각 자원 서브시스템(CPU, 메모리, 블록 I/O 등)이 독립된 개별 디렉터리 계층 구조로 마운트되어 관리되었습니다.
  이로 인해 메모리 부족으로 디스크 쓰기 버퍼가 지연될 때(writeback) 메모리 컨트롤러와 블록 I/O 컨트롤러가 연동되지 않아 I/O 스로틀링이 오작동하는 등 자원을 복합적으로 제어하는 데 한계가 있었습니다.
- cgroups v2는 모든 자원 컨트롤러가 하나의 통합 계층 구조(Unified Hierarchy) 아래 작동하도록 재설계되었습니다.
  프로세스는 오직 하나의 리프 노드에만 속하므로 메모리 사용량에 비례하여 스토리지 I/O 속도를 조절하는 등 자원을 정교하게 통제하고 이웃 간섭 현상(Noisy Neighbor)을 방지합니다.

7. 컨테이너 보안과 커널 공유 리스크

컨테이너의 치명적인 약점은 모든 컨테이너가 호스트의 리눅스 커널 하나를 공유(Shared Kernel)한다는 사실에서 비롯됩니다.

만약 컨테이너 내부의 루트 권한을 획득한 공격자가 커널 취약점(예: 권한 상승, 커널 코드 버그)으로 호스트 커널을 장악하면 같은 호스트에서 실행 중인 다른 컨테이너의 데이터나 제어권을 탈취하는 컨테이너 탈출(Container Breakout) 위협에 노출됩니다.

이를 방어하고자 현대 컨테이너 런타임은 다음과 같은 다중 보안 장벽을 세웁니다.

User Namespace:
컨테이너 내부의 `root (UID 0)` 권한을 호스트 OS 관점의 일반 사용자(예: `UID 10001`)로 매핑합니다. 설령 컨테이너 내부에서 권한을 장악하더라도 호스트 전체로 위협이 확산되지 않습니다.
Linux Capabilities:
루트 권한을 세분화해 컨테이너가 최소한의 특권만 쓰도록 기본 권한 집합을 차단합니다 (예: 시스템 시간 변경 `CAP_SYS_TIME` 차단, 로우 소켓 제어 `CAP_NET_RAW` 박탈 등).
Seccomp (Secure Computing Mode):
프로세스가 호스트 커널에 요청할 수 있는 시스템 콜을 화이트리스트로 제한합니다.
예컨대 컨테이너에 불필요한 커널 모듈 로딩(`init_module`)이나 재부팅(`reboot`) 등의 위험한 시스템 콜이 호출되면 커널 수준에서 즉각 차단하고 프로세스를 종료합니다.
LSM (Linux Security Module):
AppArmor나 SELinux를 결합해 프로세스가 파일 시스템 경로, 포트 번호 등에 접근하는 행위를 보안 프로필 기준으로 커널 단에서 강제 접근 제어(MAC)합니다.

8. MicroVM & Sandbox Containers

컨테이너의 경량성과 가상 머신(VM)의 강력한 보안 격리를 결합하고자 현대 클라우드 인프라에서는 새로운 샌드박싱 기술을 적극 도입하고 있습니다.

1) Firecracker (MicroVM)

AWS가 서버리스 컴퓨팅(AWS Lambda, Fargate)의 순간 기동성 및 다중 테넌트 격리 안전성을 보장하고자 개발한 Rust 기반의 미니멀 VMM입니다.

아키텍처:
Linux KVM 모듈을 직접 호출해 VM의 하드웨어 수준 격리는 실현하되 QEMU가 지니고 있던 무겁고 느린 레거시 가상 하드웨어 에뮬레이션(PCI 버스, ACPI 등)을 제거했습니다.
오직 가상 CPU 구동과 최소한의 가상 장치인 `VirtIO-net`, `VirtIO-block`, `VirtIO-vsock`만을 구현했습니다.
정량적 특징:
기동 시간이 100~125ms 수준으로 일반 컨테이너 수준에 필적하며 VM 인스턴스 1개당 메모리 오버헤드가 5MB 이하에 불과해 물리 장비 한 대에 수천 개의 격리 가상 머신을 고밀도로 적재할 수 있습니다.

2) Kata Containers

컨테이너의 경량 패키징 및 OCI(Open Container Initiative) 표준 생태계를 그대로 사용하되 하부 가상화는 경량 VM(QEMU 또는 Cloud Hypervisor) 격리를 활용하는 통합 런타임입니다.
K8s의 CRI와 밀접히 융합되고 컨테이너 Pod 단위로 Guest OS 커널을 띄우는 이중 외피 방식을 취합니다.

3) gVisor

Google이 개발한 컨테이너 샌드박스로 Host Kernel과 Guest Application의 연결 통로를 차단하는 아키텍처를 가집니다.

동작 원리:
Rust/Go로 작성된 Sentry라는 사용자 공간 프로세스가 Guest Application의 시스템 콜을 완전히 가로챕니다.
Sentry가 리눅스 커널이 제공해야 할 300개 이상의 시스템 콜을 직접 처리하므로 호스트 커널은 직접적인 타격을 입지 않습니다.
트레이드오프:
시스템 콜이 발생할 때마다 Sentry 내부에서 번역 및 에뮬레이션 비용이 추가되므로 디스크 및 네트워크 입출력이 잦은 I/O 바운드 워크로드에서는 성능이 떨어집니다.

9. 클라우드 서비스별 가상화 설계

현대 클라우드 제공업체(CSP)들은 단순히 기술적 유행을 따르지 않고 비즈니스 모델과 격리 리스크의 상관관계를 고려해 가상화 아키텍처를 설계합니다.

AWS / Cloudflare 설계 의도

AWS EC2 (Elastic Compute Cloud):
- 기반 기술: KVM 기반 기술을 활용한 AWS 커스텀 하이퍼바이저 (AWS Nitro Hypervisor)
- 설계 의도:
  EC2는 수백만 명의 임의 고객이 동일한 하드웨어를 나누어 쓰는 대표적인 멀티테넌트(Multi-tenant) 환경입니다.
  
  컨테이너와 같은 커널 공유 모델은 호스트 커널의 단일 취약점(예: Dirty COW 등)만으로도 이웃 테넌트의 메모리에 접근 가능한 보안 위협에 노출되기 쉽습니다.
  
  따라서 AWS는 고객 간의 강력한 결함 격리(Fault Isolation)와 정보 보안 장벽을 확실히 제공하고자 가상 I/O 처리를 Nitro 전용 PCI 하드웨어 카드로 오프로딩하여 오버헤드를 최소화하면서 하드웨어 가상화(VM) 기반 아키텍처를 유지합니다.
AWS EKS (Elastic Kubernetes Service):
- 기반 기술: OS Level Container (containerd / runc)
- 설계 의도:
  신속한 오토 스케일링과 고밀도 자원 집적(Density)이 중요한 마이크로서비스 아키텍처(MSA)를 대상으로 합니다.
  
  동일 조직이나 신뢰할 수 있는 워크로드 간의 격리 환경을 구축할 때는 가상 머신의 OS 오버헤드를 최소화하고 네이페이스와 cgroups v2를 적용해 인프라 운영 비용을 낮춥니다.
AWS Lambda & Fargate:
- 기반 기술: AWS Firecracker MicroVM
- 설계 의도:
  Lambda의 핵심 성능 지표(KPI)는 Cold Start Latency 단축이며 인프라 비용 효율화도 중요한 목표입니다.
  
  일반적인 VM은 격리가 우수하지만 부팅에 수십 초가 걸려 서버리스 환경에 부적합하고, 컨테이너는 부팅은 빠르나 멀티테넌트 환경에서 타 고객의 악성 코드 실행에 따른 커널 탈출 위협에 노출됩니다.
  
  이에 AWS는 수조 건의 Lambda 호출 처리 시 발생하는 인프라 비용 문제를 해결하고 강력한 테넌트 격리를 보장하고자 KVM 코어를 활용하되 불필요한 가상 디바이스(PCI 버스 등)를 모두 제외한 경량 VMM인 Firecracker를 개발했습니다.
  
  이로써 안전한 하드웨어 격리와 100~125ms 수준의 기동 속도를 확보했습니다.
Cloudflare Workers:
- 기반 기술: V8 engine Isolates Sandbox
- 설계 의도:
  OS 수준의 가상화나 하이퍼바이저 격리마저 무겁다고 판단되는 초경량 엣지(Edge) 연산 영역용 설계입니다.
  
  Chrome 브라우저에 내장된 V8 런타임 내의 독립적인 실행 컨텍스트(Isolates)만을 샌드박싱하여 단일 OS 프로세스 상에서 수천 개의 함수를 실행합니다.
  
  기동 속도는 거의 즉시에 가깝고 프로세스/스레드 스위칭 비용이 실질적으로 소멸되어 가장 가벼운 엣지 서버리스 구조를 이룹니다.

정량 비교 매트릭스

10. 결론

현대 인프라스트럭처 엔지니어링은 "가상 머신과 컨테이너의 경쟁 구도"가 아닙니다.

프로덕션 환경의 목적에 따라 격리 신뢰도(Fault Isolation), 리소스 집적도(Density),
기동 레이턴시(Start-up Latency), 운영 관리성의 다차원적 변수들 사이에서 엔지니어링 트레이드오프를 조율하는 설계 영역입니다.

보안 및 결함 격리 우선:
외부 고객들의 비인가 코드가 실행되는 멀티테넌트 환경이나 금융/의료 등 민감 데이터를 다루는 경우 호스트 커널의 취약점 방어가 최우선이므로 커스텀 KVM 기반 하이퍼바이저 격리 장벽을 필수로 설치합니다.
고밀도 및 신속 확장 우선:
동일 조직 내부의 신뢰할 수 있는 앱들이 동작하며 신속한 오토 스케일링이 필요할 때는 단일 커널 공유 기반 컨테이너 가상화를 설계의 핵심으로 둡니다.
서버리스 및 엣지 컴퓨팅:
기동 속도와 보안 격리라는 대립되는 가치를 절충하고자 AWS Lambda와 같이 Firecracker MicroVM을 채택하거나 극단적인 레이턴시 제어를 위해 V8 Isolate로 방향을 설정합니다.

가상화 기술은 서로를 도태시키지 않고 현대 하이퍼스케일 클라우드 생태계의 다양한 구조적 계층에서 서로 다른 문제를 해결하며 상호보완적으로 공존하고 있습니다.

유정빈

cloud

이전 포스트

[OS 2편] CPU 스케줄링과 big.LITTLE 구조

다음 포스트