가상화의 또 다른 축 — Proxmox와 VM, 그리고 컨테이너의 공존

컨테이너가 애플리케이션 패키징과 배포의 기본 표준이 되었지만, 인프라의 모든 영역을 컨테이너만으로 해결할 수는 없습니다. 리눅스 네임스페이스와 cgroups 기반의 컨테이너는 호스트 커널을 공유하기 때문에, 하드웨어 수준의 물리적 격리나 이종 OS 구동, 엄격한 멀티 테넌시 환경에서는 한계가 분명합니다.

실제 데이터센터와 온프레미스 환경에서 가상머신(VM)과 컨테이너는 대립하는 기술이 아니라 함께 맞물려 돌아가는 보완재입니다. 오픈소스 가상화 플랫폼인 Proxmox VE 는 하드웨어 전가상화를 지원하는 KVM과 경량 시스템 컨테이너인 LXC를 함께 다루며, 워크로드 성격에 맞춰 인프라 계층을 유연하게 나눌 수 있게 돕습니다.

1. 베어메탈 가상화 플랫폼 Proxmox VE

VMware의 라이선스 정책 변경 이후 오픈소스 하이퍼바이저 대안으로 Proxmox VE가 많은 주목을 받았습니다. 데비안 리눅스를 기반으로 하는 Proxmox VE는 하드웨어 위에 직접 설치되는 Type-1 하이퍼바이저 플랫폼으로, 컴퓨팅 자원뿐 아니라 ZFS/Ceph 기반 스토리지와 소프트웨어 정의 네트워크(SDN)를 하나의 웹 대시보드와 클러스터 엔진(corosync)으로 관리합니다.

flowchart TD
    UI["<b>Proxmox VE Web Management UI & REST API</b>"]

    subgraph Compute["Virtualization Compute Layer"]
        direction LR
        KVM["<b>KVM (Full Virtualization VM)</b><br/>• Dedicated kernel & virtual hardware<br/>• Windows, Linux, BSD support<br/>• Hardware-level isolation"]
        LXC["<b>LXC (System Containers)</b><br/>• Shared host kernel (cgroups/namespaces)<br/>• Full systemd OS environment<br/>• Near-zero memory overhead"]
    end

    subgraph StorageNetwork["Storage & Networking Fabric"]
        direction LR
        Storage["<b>ZFS / Ceph Distributed Storage</b><br/>• Local copy-on-write snapshots<br/>• Distributed block & file cluster"]
        Network["<b>Linux Bridge / Open vSwitch</b><br/>• VLAN isolation & SDN<br/>• Failover bonding"]
    end

    OS["<b>Debian Linux Core (KVM Kernel Module)</b>"]
    HW["<b>Physical Hardware (CPU VT-x/AMD-V, RAM, NVMe, NIC)</b>"]

    UI --> Compute
    Compute --> StorageNetwork
    StorageNetwork --> OS
    OS --> HW

Proxmox의 가장 큰 특징은 하드웨어를 통째로 가상화하는 KVM과, 호스트 커널을 공유하면서도 OS 환경을 제공하는 LXC를 하나의 관리 도구 안에서 유연하게 선택해 쓸 수 있다는 점입니다.

2. 하드웨어 가상화와 커널 공유의 차이

가상머신과 컨테이너의 본질적인 차이는 ‘격리 경계를 어디에 두는가’에서 갈립니다.

KVM (Kernel-based Virtual Machine)

KVM은 리눅스 커널을 Type-1 하이퍼바이저로 동작하게 만드는 커널 모듈입니다. CPU의 하드웨어 가상화 확장(Intel VT-x, AMD-V)을 이용해 가상 머신의 CPU 명령을 물리 코어에서 직접 실행하고, 중첩 페이지 테이블(EPT/NPT)로 가상머신의 메모리를 물리 메모리와 완전히 차단합니다. 디스크나 네트워크 같은 입출력 장치는 QEMU와 virtio 드라이버를 통해 호스트와 직접 메모리 링 버퍼를 교환하며 I/O 병목을 줄입니다.

LXC (Linux Containers)

LXC는 도커와 마찬가지로 리눅스 커널의 네임스페이스와 cgroups를 공유하지만, 앱 하나만 띄우는 것이 아니라 ‘OS 환경 전체’를 컨테이너 안에 담습니다. 내부에서 systemd가 1번 프로세스(PID 1)로 기동되어 SSHD, Cron, 로깅 데몬 등이 일반 리눅스 서버처럼 동작합니다. 별도의 OS 커널을 띄우지 않기 때문에 메모리 낭비가 거의 없고, 1초도 안 되는 시간에 부팅되는 ‘초경량 가상머신’처럼 다룰 수 있습니다.

Docker 및 containerd (애플리케이션 컨테이너)

도커나 containerd는 마이크로서비스 배포와 단일 프로세스 관리에 초점을 맞춘 컨테이너 런타임입니다. 컨테이너의 생명주기가 단일 앱 프로세스의 수명과 직결되며, 불변(Immutable) 이미지 레이어로 애플리케이션을 빌드하고 배포하는 데 최적화되어 있습니다.

3. 공유 커널의 한계와 VM의 역할

컨테이너가 아무리 가볍고 빠르더라도, 호스트 커널을 공유한다는 구조적 한계 때문에 다음과 같은 요구사항 앞에서는 가상머신을 쓸 수밖에 없습니다.

① 커널 보안 취약점과 멀티 테넌시 격리

컨테이너 내부의 프로세스는 시스템 콜을 호출할 때 호스트 리눅스 커널과 직접 대화합니다. 즉, 호스트 커널 자체가 모든 컨테이너의 잠재적인 공격 표면입니다. 커널 내부의 권한 상승 취약점(Dirty Pipe, Dirty COW 등)이 터지면 컨테이너 탈출(Container Escape)을 통해 호스트 전체와 다른 컨테이너가 장악될 위험이 있습니다. 서로 신뢰할 수 없는 다수의 테넌트(Untrusted Multi-tenancy)를 격리해야 하는 클라우드 인프라나 금융 시스템에서 CPU 링 레벨과 MMU로 하드웨어 격리를 제공하는 KVM이나 Firecracker 같은 VM이 필수적인 이유입니다.

② 윈도우 및 이종 운영체제 지원

컨테이너는 호스트의 리눅스 커널을 빌려 쓰므로, 리눅스 호스트 위에서 윈도우 OS나 FreeBSD, 특정 커널 패치가 필요한 레거시 운영체제를 띄울 수 없습니다. 액티브 디렉터리(AD)나 윈도우 전용 애플리케이션, 독자 커널을 요구하는 서비스는 KVM 전가상화가 필수입니다.

③ 하드웨어 직결 제어와 PCIe 패스스루

GPU, 100GbE 네트워크 카드, NVMe 스토리지 컨트롤러 같은 물리 하드웨어를 특정 인스턴스에 1:1로 직접 넘겨 최대 성능을 뽑아내려면 IOMMU 기반의 PCIe 패스스루가 필요합니다. 하이퍼바이저 환경에서는 호스트의 VFIO 드라이버를 통해 물리 장치를 게스트 VM에 직접 바인딩하여 네이티브 하드웨어 성능을 온전히 활용할 수 있습니다.

4. 베어메탈 K8s와 Proxmox 기반 K8s

인프라를 구축할 때 흔히 마주하는 고민은 쿠버네티스를 물리 서버에 바로 올릴 것인가, 아니면 Proxmox 같은 하이퍼바이저 위에 VM으로 올릴 것인가입니다.

flowchart TD
    HW1["Physical Bare-metal Server"]
    OS1["Linux Host OS (Debian / Ubuntu)"]
    CR1["containerd Container Runtime"]
    PODS1["<b>Kubernetes Pods</b><br/>• 100% native hardware performance<br/>• Zero virtualization overhead"]

    HW1 --> OS1 --> CR1 --> PODS1

flowchart TD
    HW2["Physical Bare-metal Server"]
    PVE["<b>Proxmox VE (KVM Hypervisor)</b>"]
    VM1["<b>VM 1 (Talos / Ubuntu K8s)</b><br/>• Live migration & snapshot isolation"]
    VM2["<b>VM 2 (Windows / Standalone DB)</b><br/>• Dedicated OS kernel"]
    LXC2["<b>LXC Container (Utility)</b><br/>• Lightweight OS container"]

    HW2 --> PVE
    PVE --> VM1
    PVE --> VM2
    PVE --> LXC2

베어메탈 쿠버네티스

가상화 계층이 없어 CPU와 메모리, 네트워크 성능을 손실 없이 100% 활용할 수 있습니다. 대규모 분산 모델 학습(LLM/AI), 초고성능 인메모리 DB처럼 마이크로초 단위의 지연 시간이나 극한의 처리량이 중요한 환경에 적합합니다. 다만 물리 서버 점검 시 노드를 드레인(Drain)하고 파드를 재스케줄링해야 하며, 하드웨어 수준의 스냅샷 백업은 어렵습니다.

Proxmox / KVM 기반 쿠버네티스

물리 노드에 문제가 생기거나 서버 점검이 필요할 때, 라이브 마이그레이션(Live Migration)을 통해 실행 중인 K8s 노드 VM을 무중단으로 다른 물리 서버로 옮길 수 있습니다. ZFS나 Ceph 분산 스토리지를 연동해 노드 스냅샷을 수초 만에 생성하고 롤백하는 운영 편의성도 큽니다. 또한 API로만 제어되는 불변(Immutable) OS인 탈로스 리눅스(Talos Linux) VM을 조합하면, 물리 서버 위에 직접 세팅하는 것보다 훨씬 깔끔하고 일관된 클러스터를 운영할 수 있습니다.

5. 격리와 성능의 트레이드오프

가상머신과 컨테이너의 선택은 우열의 문제가 아니라, 격리 수준과 성능 오버헤드 사이의 트레이드오프입니다.

컨테이너는 빠른 배포와 높은 집적도에서 강점을 갖지만 보안 경계가 호스트 커널 하나에 묶여 있습니다. 반면 가상머신은 약간의 CPU/메모리 가상화 비용을 치르는 대신 확실한 고장 도메인과 하드웨어 수준의 격리를 제공합니다.

결국 핵심은 경계를 나누는 기준입니다. 신뢰할 수 없는 외부 코드를 실행하거나 독자 OS가 필요한 워크로드는 KVM 가상머신으로 격리하고, 상태 없는 고밀도 웹 서비스는 컨테이너로 패키징하며, 단일 호스트의 유틸리티 데몬은 LXC로 가볍게 띄우는 식의 계층적 구성이 인프라의 안정성과 효율을 모두 챙기는 현실적인 해법입니다.