본문으로 건너뛰기

안동민 개발노트

본문 시작

가상화의 개념

하이퍼바이저 유형과 전가상화·반가상화·하드웨어 지원 가상화가 CPU·메모리·I/O를 격리하는 방식을 이해합니다.

클라우드 서비스에서 서버를 생성하면 몇 분 안에 사용할 수 있습니다.

이 서버는 물리 서버일까요?

아닙니다.

하나의 물리 서버 위에 여러 개의 가상 서버가 동작하고 있습니다.

이것을 가능하게 하는 기술이 가상화(Virtualization)입니다.

가상화는 현대 클라우드 인프라의 기반이며, OS 과목의 거의 모든 개념이 여기서 다시 등장합니다.


가상화란 무엇인가

가상화는 물리적 하드웨어 위에 소프트웨어로 가상의 하드웨어를 만드는 기술입니다.

하나의 물리 서버에서 여러 운영체제를 독립적으로 실행할 수 있습니다.

왜 가상화가 필요한가

자원 효율: 서버 한 대가 CPU의 10%만 사용하고 있다면 나머지 90%가 낭비됩니다.

가상화를 통해 하나의 물리 서버에서 여러 서비스를 운영하면 자원 활용률을 70~80%까지 높일 수 있습니다.

격리(Isolation): 서비스 A의 크래시가 서비스 B에 영향을 주지 않아야 합니다.

각 가상 머신은 독립된 OS를 가지므로, 한 VM이 충돌해도 다른 VM은 정상 동작합니다.

유연성: 물리 서버를 구매하고 설치하는 데 수 주가 걸리지만, VM은 수 분 내에 생성하고 삭제할 수 있습니다.

이식성: VM 이미지를 복사하면 다른 물리 서버에서 동일한 환경을 즉시 실행할 수 있습니다.

개발 환경과 프로덕션 환경의 차이를 줄입니다.


하이퍼바이저

하이퍼바이저(Hypervisor)는 가상 머신을 생성하고 관리하는 소프트웨어입니다.

VMM(Virtual Machine Monitor)이라고도 합니다.

Type 1 (베어메탈, Native)

하드웨어 위에 직접 설치됩니다.

호스트 OS가 없거나 최소한입니다.

하이퍼바이저 자체가 하드웨어를 직접 제어합니다.

베어메탈 하이퍼바이저

데이터센터와 클라우드에서는 호스트 OS 위의 앱보다, 하드웨어에 가까운 얇은 계층이 CPU·메모리·I/O 격리를 담당하는 구조가 흔하다.

  1. 핵심 구조
    Hardware → Hypervisor → VMs

    핵심 구조 Hardware → Hypervisor → VMs 각 VM은 독립 OS를 가지지만 실제 CPU와 장치는 하이퍼바이저가 중재한다.

  2. VM A
    실행 스택

    VM A Guest OS 웹 서버와 앱 런타임 VM B Guest OS 데이터베이스 서비스 VM C Guest OS 배치 워커와 도구 HV 하이퍼바이저 / VMM vCPU 스케줄링, 메모리 격리, 가상 장치, VM Exit 처리를 담당한다. HW 물리 하드웨어 CPU 가상화 확장, 메모리, NIC, 스토리지, IOMMU 같은 실제 자원이다.

  3. 성능

    하드웨어 지원과 I/O 오프로드가 있으면 오버헤드를 크게 줄일 수 있다.

  4. 보안

    VM마다 독립 커널을 두어 컨테이너보다 강한 경계를 제공한다.

  5. 관리

    클러스터 단위로 VM 배치, 장애 복구, 라이브 마이그레이션을 설계한다.

  • VMware ESXi: 엔터프라이즈 환경에서 널리 사용되는 베어메탈 하이퍼바이저
  • Microsoft Hyper-V: Windows Server에 내장
  • Xen: 초기 클라우드 인프라와 여러 가상화 환경에서 널리 사용
  • KVM: Linux 커널에 통합된 하이퍼바이저. 여러 클라우드와 서버 가상화 환경에서 사용

성능이 우수하여 데이터센터와 클라우드에서 사용됩니다.

Type 2 (호스트형, Hosted)

일반 OS(Windows, macOS, Linux) 위에 애플리케이션처럼 설치됩니다.

호스트형 하이퍼바이저

개발자 노트북이나 테스트 환경에서는 설치와 사용이 쉬운 대신, I/O와 장치 접근이 호스트 OS 경로를 더 많이 지난다.

  1. 핵심 구조
    Hardware → Host OS → Hypervisor App → VM

    핵심 구조 Hardware → Host OS → Hypervisor App → VM 편의성은 높지만 데이터센터용 베어메탈 구조와 성능·운영 목적이 다르다.

  2. VM 1
    실행 스택

    VM 1 Linux Guest 개발 서버 VM 2 Windows Guest 호환성 테스트 Tools Snapshot 복구와 실험 APP VirtualBox, VMware Workstation, Parallels VM 프로세스, 가상 장치, UI, 스냅샷 기능을 제공한다. OS 호스트 운영체제 파일 시스템, 네트워크 스택, 장치 드라이버, 전원 관리를 먼저 소유한다. HW 노트북/데스크톱 하드웨어 CPU 가상화 확장을 쓰더라도 I/O 경로는 호스트 OS 정책의 영향을 받는다.

  3. Type 1

    하드웨어에 가깝고 서버 가상화와 클라우드 운영에 적합하다.

  4. Type 2

    호스트 OS 위에서 편하게 VM을 띄우는 개발·실습 환경에 적합하다.

  5. 공통점

    둘 다 CPU 가상화 지원과 가상 장치 모델을 활용해 게스트 OS를 실행한다.

  • VirtualBox: 무료, 크로스 플랫폼
  • VMware Workstation/Fusion: 유료, 높은 호환성
  • Parallels Desktop: macOS 전용

개발 환경이나 테스트 용도로 사용됩니다.

호스트 OS를 거치므로 Type 1보다 성능 오버헤드가 있습니다.

KVM — 경계가 모호한 하이퍼바이저

KVM(Kernel-based Virtual Machine)은 Linux 커널의 모듈입니다.

Linux를 부팅하면 일반 OS처럼 보이지만, KVM 모듈을 로드하면 커널이 CPU의 가상화 확장을 사용해 VM 실행을 직접 관리합니다.

그래서 단순히 Type 1/Type 2 중 하나로만 외우기보다, Linux 커널이 하이퍼바이저 역할을 하고 QEMU 같은 사용자 공간 도구가 장치 에뮬레이션과 관리 기능을 보탠다고 이해하는 편이 정확합니다.

kvm_check.py
import subprocess

def check_virtualization():
    """시스템의 가상화 지원 확인"""
    # CPU 가상화 지원 확인
    with open("/proc/cpuinfo") as f:
        cpuinfo = f.read()

    if "vmx" in cpuinfo:
        print("Intel VT-x 지원")
    elif "svm" in cpuinfo:
        print("AMD-V 지원")
    else:
        print("하드웨어 가상화 미지원")

    # KVM 모듈 로드 확인
    result = subprocess.run(["lsmod"], capture_output=True, text=True)
    if "kvm" in result.stdout:
        print("KVM 모듈 로드됨")
    else:
        print("KVM 모듈 미로드")

    # 현재 가상환경에서 실행 중인지 확인
    result = subprocess.run(
        ["systemd-detect-virt"], capture_output=True, text=True
    )
    virt = result.stdout.strip()
    if virt == "none":
        print("물리 머신에서 실행 중")
    else:
        print(f"가상 환경에서 실행 중: {virt}")

전가상화와 반가상화

전가상화(Full Virtualization): 게스트 OS가 자신이 가상 환경에서 돌고 있다는 사실을 몰라도 실행될 수 있습니다.

게스트 OS를 수정할 필요가 없다는 것이 핵심입니다.

과거에는 특권 명령을 소프트웨어로 변환하는 Binary Translation이 중요했지만, 현대 시스템에서는 VT-x/AMD-V 같은 하드웨어 지원으로 많은 트랩과 전환을 CPU가 직접 처리합니다.

반가상화(Paravirtualization): 게스트 OS 또는 게스트 드라이버가 가상 환경을 인지하고, 실제 장치를 흉내 낸 느린 경로 대신 하이퍼바이저가 제공하는 최적화된 인터페이스를 사용합니다.

초기 Xen처럼 커널 수정이 필요한 방식도 있었지만, 현대에는 VirtIO처럼 게스트 드라이버를 통해 실용적으로 적용되는 경우가 많습니다.

VirtIO — 반가상화의 실용적 해결

완전한 하드웨어 에뮬레이션(e1000 NIC, IDE 디스크)은 호환성은 좋지만 I/O 경로가 길어질 수 있습니다.

VirtIO는 게스트와 호스트 사이에 최적화된 가상 장치 인터페이스를 제공합니다.

게스트에 VirtIO 드라이버를 설치하면, 네트워크와 디스크 I/O에서 에뮬레이션 장치보다 훨씬 낮은 오버헤드를 기대할 수 있습니다.

장치 유형에뮬레이션VirtIO
네트워크e1000 같은 에뮬레이션 NICvirtio-net
디스크IDE/SATA 에뮬레이션virtio-blk, virtio-scsi
에뮬레이션과 가상화 드라이버

전가상화는 게스트 수정을 줄이고, VirtIO 같은 반가상화 장치는 게스트와 하이퍼바이저 사이의 입출력 경로를 짧게 만든다.

  1. 게스트 드라이버

    표준 장치로 인식해 별도 수정 없이 요청을 보낸다.

  2. 장치 흉내

    하이퍼바이저가 실제 하드웨어처럼 레지스터와 인터럽트를 흉내 낸다.

  3. 호스트 입출력

    호환성은 높지만 변환 단계가 많아 지연이 커질 수 있다.

  4. 가상화 인지 드라이버

    게스트가 최적화된 큐에 네트워크와 디스크 요청을 넣는다.

  5. 공유 큐 처리

    하이퍼바이저와 호스트 도구가 약속된 형식으로 요청을 바로 처리한다.

  6. 낮은 오버헤드

    불필요한 장치 흉내가 줄어 대량 입출력에서 효율이 좋아진다.


하드웨어 지원 가상화

현대 CPU는 가상화를 하드웨어로 지원합니다.

Intel의 VT-x(2005~)와 AMD의 AMD-V(2006~)가 대표적입니다.

하드웨어 가상화 지원이 있으면 CPU는 하이퍼바이저와 게스트를 분리해서 실행할 수 있는 모드를 제공합니다.

하이퍼바이저는 더 높은 제어 권한에서, 게스트 OS는 격리된 VM 실행 모드에서 동작합니다.

게스트의 민감한 동작은 CPU가 VM Exit를 발생시켜 하이퍼바이저에 넘깁니다.

이 덕분에 예전처럼 모든 특권 명령을 소프트웨어로 번역할 필요가 크게 줄었습니다.

기술대상효과
VT-x / AMD-VCPU 명령어특권 명령 트랩 자동화
EPT / NPT메모리2단계 주소 변환 하드웨어 처리
VT-d / IOMMUI/O 장치장치의 VM 직접 할당 (Passthrough)
SR-IOVNIC하나의 물리 NIC를 여러 가상 NIC로 분할

EPT(Extended Page Tables): 게스트 가상 → 게스트 물리 → 호스트 물리의 2단계 주소 변환을 하드웨어가 처리합니다.

이전에는 섀도 페이지 테이블을 소프트웨어로 관리해야 했고, 이것은 오버헤드가 컸습니다.

VT-d / IOMMU: 물리 장치를 VM에 직접 할당합니다.

GPU 패스스루가 대표적 — ML 워크로드에서 VM 안에서도 네이티브 GPU 성능을 얻을 수 있습니다.

VM 성능 지원 요소

VT-x와 AMD-V는 게스트 특권 명령을 VM Exit로 넘기고, EPT/NPT와 IOMMU는 메모리와 장치 접근의 가상화 비용을 줄인다.

  1. guest OS
    guest OS
  2. 게스트 커널

    자신의 페이지 테이블과 장치 드라이버를 가진 독립 OS처럼 실행된다.

  3. 민감 명령

    제어 레지스터, 인터럽트, I/O 포트 접근

hardware_virt_check.sh
# Intel VT-x 지원 확인
grep -c vmx /proc/cpuinfo   # 0이면 미지원

# AMD-V 지원 확인
grep -c svm /proc/cpuinfo

# IOMMU 활성화 확인
dmesg | grep -i iommu

# VM 성능에 큰 영향을 주는 EPT 지원 확인
cat /sys/module/kvm_intel/parameters/ept  # Y

AWS EC2의 Nitro System처럼 현대 클라우드는 네트워크와 스토리지 I/O의 많은 부분을 전용 하드웨어나 별도 제어 평면으로 오프로드합니다.

그래서 최신 VM은 예전 가상화보다 훨씬 낮은 오버헤드를 보이지만, 실제 성능 차이는 워크로드, 인스턴스 유형, I/O 경로에 따라 달라집니다.

하이퍼바이저 성능 비교

베어메탈형, 호스트형, 커널 기반 가상화는 배치 위치가 다르며, 실제 성능은 주소 변환과 장치 경로에서 크게 갈린다.

  1. 베어메탈형
    데이터센터와 클라우드

    베어메탈형 하드웨어 위에서 하이퍼바이저가 직접 실행되어 호스트 운영체제 경유 비용을 줄인다.

  2. 호스트형
    개발과 테스트

    호스트형 일반 운영체제 위의 응용 프로그램처럼 동작해 설치가 쉽지만 입출력 경로가 길다.

  3. 커널 기반
    리눅스 커널과 사용자 도구

    커널 기반 커널이 가상 실행을 관리하고 사용자 공간 도구가 장치 에뮬레이션과 관리를 맡는다.

  4. 성능 판단 기준

    특권 명령 게스트의 민감한 동작은 가상 머신 이탈로 하이퍼바이저에 전달된다. 하드웨어 가상화 지원이 비용을 낮춘다. 메모리 변환 게스트 가상 주소에서 게스트 물리 주소, 호스트 물리 주소로 이어지는 두 단계 변환이 핵심이다. 확장 페이지 테이블이 소프트웨어 관리 부담을 줄인다. 장치 입출력 에뮬레이션 장치는 기존 게스트 OS를 그대로 붙이고, 가상화 친화 드라이버와 장치 직접 할당은 지연을 줄인다. 격리 장치 관리 장치가 메모리 침범을 막는다.

다음 절에서는 가상화보다 가벼운 격리 기술인 컨테이너를 다루겠습니다.

VM exit는 게스트와 호스트 사이의 ‘선택적 왕복’이다

일반 명령과 보통의 주소 변환은 하드웨어에서 계속 진행된다. 가상화 제어가 가로채도록 설정한 이벤트만 호스트로 전환되고, KVM 내부 처리와 userspace VMM 처리가 다시 갈린다.

  1. guest 실행

    VCPU가 일반 명령을 직접 실행한다. guest mode

  2. exit 발생

    설정된 intercept, PIO·MMIO 같은 이벤트가 제어권을 넘긴다. VM exit

  3. KVM 분류

    커널 안에서 끝낼지 VMM에 반환할지 결정한다. exit reason

  4. VMM 중재

    필요할 때 I/O·MMIO를 에뮬레이션하고 결과를 채운다. KVM_EXIT_IO

  5. guest 복귀

    다음 KVM_RUN에서 미완료 동작을 끝내고 VCPU를 재개한다. VM entry

  6. 메모리 nested paging

    EPT/NPT가 일반적인 2단계 변환을 하드웨어로 처리한다. 모든 메모리 접근이 exit를 만드는 것은 아니다. GVA → GPA → HPA

  7. 장치 virtio

    guest 드라이버와 hypervisor가 virtqueue 계약을 공유해 완전한 하드웨어 에뮬레이션 비용을 줄인다.

  8. 원인

    어떤 명령·I/O·정책이 exit를 만들었는가

  9. 상태

    kernel 안에서 끝났는가, VMM까지 반환됐는가

  10. 검증

    kvm:kvm_exit 와 kvm_run.exit_reason 으로 빈도·종류를 확인