KVM vs. OpenVZ vs. LXC: VPS 가상화 방식이 실제로 무엇을 허용하는가

같은 페이지에 VPS 요금제 두 개. 4 vCPU, 8 GB RAM, 160 GB 스토리지, 가격도 거의 같습니다. 하나는 KVM이라고 적혀 있고 다른 하나는 OpenVZ입니다. 두 페이지 어디에도 그 단어가 무엇을 바꾸는지는 나와 있지 않습니다.

그 단어는 무엇을 실행할 수 있는지를 바꿉니다. VPS 가상화 방식은 단순한 성능상의 각주가 아닙니다. 커널을 직접 제어하는지, Windows가 가능한지, 제공업체의 도움 없이 Docker가 동작하는지를 결정합니다. KVM, OpenVZ, LXC의 비교는 속도 문제이기 이전에 기능 문제입니다.

이 가이드는 이 구매 결정과 가장 관련이 깊은 세 가지 명칭을 다룹니다. Xen, VMware, Hyper-V를 비롯한 다른 가상화 플랫폼도 있지만, 이번 3자 비교의 범위 밖입니다.

요약

• KVM 는 각 VPS에 고유한 게스트 커널을 제공합니다. Docker는 정상적으로 동작하고 Windows도 기술적으로 가능하며, 대개 커널 모듈을 로드하거나 커스텀 커널을 부팅할 수 있습니다. 다만 KVM만으로는 전용 CPU나 RAM이 보장되지 않으며, 자원 보장은 여전히 제공업체와 요금제에 달려 있습니다.
• OpenVZ VPS 요금제는 보통 호스트 커널을 공유하는 Linux 컨테이너입니다. OpenVZ 7에서 Docker는 제공업체가 호환되는 커널과 템플릿 구성을 사용할 때만 실행됩니다. 호스트 커널은 교체할 수 없고, RAM을 넘어서는 메모리는 게스트가 관리하는 일반 디스크 스왑이 아니라 제공업체가 제어하는 VSwap으로 처리됩니다.
• LXC 도 호스트 커널을 공유하지만, 메인라인 Linux의 격리 기능을 기반으로 합니다. 호스트가 필요한 기능을 활성화하면 Docker를 실행할 수 있지만, Proxmox는 최대한의 격리와 라이브 마이그레이션이 필요한 워크로드에서는 컨테이너를 QEMU 가상 머신 안에 중첩하도록 권장합니다.
• 컨테이너는 대개 실행 중에 크기를 조정하기가 더 쉽습니다. KVM 역시 CPU와 메모리 핫플러그를 지원할 수 있으므로 "KVM은 항상 재부팅이 필요하다"는 안전한 구매 기준이 아닙니다. 해당 플랫폼이 실제로 무엇을 지원하는지 제공업체에 문의하세요.
• Docker나 Windows, 커널 수준의 커스터마이징이 전혀 필요 없는 정적 사이트나 소규모 LAMP 스택이라면 실질적인 차이는 작을 수 있습니다. 그래도 격리 수준, 수명 주기, 자원 정책은 다를 수 있습니다.

나머지 모든 차이를 만들어내는 단 하나의 차이

KVM은 호스트의 각 VPS에 고유한 게스트 커널을 제공합니다. OpenVZ 컨테이너와 LXC 컨테이너는 호스트가 부팅한 커널을 사용합니다.

KVM은 x86 하드웨어를 위한 전가상화 솔루션입니다 이며 가상화 확장 기능이 필요합니다. 2.6.20 버전부터 메인라인 Linux 커널에 통합되었습니다. 각 게스트는 가상 하드웨어를 인식하고 자체 운영체제와 커널을 부팅합니다.

컨테이너 방식은 다르게 동작합니다. LXC는 Linux 커널의 격리 기능을 위한 사용자 공간 인터페이스이며 여기에는 네임스페이스, cgroup, capabilities, seccomp, 보안 프로파일이 포함됩니다. 별도의 커널을 부팅하지 않고도 일반적인 Linux 설치 환경에 가까운 환경을 제공하는 것을 목표로 합니다.

OpenVZ 컨테이너도 큰 틀에서는 같은 공유 커널 모델을 따르지만, OpenVZ는 자체 플랫폼과 커널 스택을 사용합니다. OpenVZ 7은 컨테이너와 KVM 가상 머신을 모두 관리할 수 있지만, 시중의 VPS 요금제에 "OpenVZ"라고 적혀 있다면 판매되는 것은 보통 컨테이너 방식입니다.

아래의 모든 기능 차이는 여기서 비롯됩니다. 커널 모듈은 내가 제어하는 커널에 로드해야 합니다. 다른 운영체제에는 다른 커널이 필요합니다. Docker에는 커널 수준의 네임스페이스가 필요하며, 그것은 커널 자체가 있는 곳에서 사용할 수 있어야 합니다. 이 경계의 KVM 쪽에서 하이퍼바이저 계층은 흔히 다음과 같이 나뉘는 아키텍처를 따릅니다. 타입 1 및 타입 2 하이퍼바이저.

LXC는 자체 관리 서버와 일부 호스팅 플랫폼을 포함해 Proxmox 환경에서 자주 등장합니다. LXC의 고급 기능을 켤 수 있는지는 그 호스트를 누가 통제하느냐에 달려 있습니다.

읽기

KVM vs. OpenVZ 2022: 가상화의 강자는 누구인가?

각 방식이 실행을 허용하는 것

구매를 좌우하는 축은 커널 제어권, 게스트 운영체제 지원, Docker 호환성, 메모리 동작 방식, 크기 조정, 자원 정책입니다.

무엇을 선택해야 할까요? Windows, 커스텀 커널, 게스트가 로드하는 모듈, 또는 예측 가능한 Docker 호스트가 필요하다면 KVM이 가장 깔끔한 답입니다. OpenVZ와 LXC도 효율적인 Linux 환경이 될 수 있지만, 커널 수준의 결정권은 제공업체에 남습니다.

이것은 벤치마크가 아니라 기능 지도입니다. 스토리지 지연, 네트워크 품질, CPU 세대, 호스트 사용률, 제공업체의 자원 할당 정책에 대해서는 아무것도 말해주지 않습니다. 같은 가상화 방식을 쓰는 두 제공업체가 아주 다른 머신을 내놓을 수 있습니다.

구매자가 시간을 잃는 지점이 바로 이 조건부 항목들입니다. 예전에 호스트 쪽에서 필요한 네트워크 기능이 열려 있지 않은 컨테이너 VPS에 VPN을 배포한 적이 있습니다. 인터페이스가 올라오지 않았고, 해결하려면 게스트 내부의 설정 변경이 아니라 지원 티켓이 필요했습니다. 컨테이너 요금제를 고를 때는 VPN에 필요한 바로 그 장치나 커널 기능을 제공업체가 열어주는지 확인하세요. KVM이라면 보통 게스트 안에서 직접 제어할 수 있습니다.

왜 Docker가 대부분의 구매를 결정짓는 질문인가

요구사항에 Docker가 등장하는 순간, 컨테이너 VPS와 KVM VPS의 비교는 더 이상 추상적인 문제가 아닙니다. Docker 자체가 커널 네임스페이스, cgroup, 네트워킹, 스토리지 드라이버를 사용하기 때문입니다. KVM 안에서 이 기능들은 내가 제어하는 게스트 커널에 속합니다. OpenVZ나 LXC 안에서는 결국 호스트에 달려 있습니다.

OpenVZ에서의 Docker

OpenVZ에서의 Docker 지원은 사용자보다 상위 계층에서 내려지는 프로비저닝 결정입니다. SolusVM 지원 문서 에 따르면 특정 3.10 계열 커널 릴리스부터는 OpenVZ 7 안에서 Docker를 실행할 수 있지만, 표준 레거시 사전 생성 템플릿에서는 Docker가 동작하지 않는다고도 밝히고 있습니다. 컨테이너는 EZ 템플릿이나 적합한 커스텀 템플릿을 사용해야 합니다. 같은 문서는 CentOS 8 게스트를 제외합니다.

그렇다면 Docker는 OpenVZ에서 동작할까요? 때에 따라 다릅니다. 제공업체가 호환되는 OpenVZ 7 커널과 적합한 템플릿 경로를 바탕으로 서비스를 구축해 두어야 합니다. 요금제 페이지에 명확히 나와 있지 않다면 구매 전에 지원팀에 문의하고 답변을 서면으로 남겨 두세요.

호스트 구성이 호환되지 않으면 VPS 안에서 Docker 플래그를 바꿔도 근본 문제는 해결되지 않습니다. 제공업체가 컨테이너 구성을 바꾸거나 다른 가상화 방식으로 옮겨 주어야 합니다.

LXC에서의 Docker

호스트가 필요한 기능을 열어 두면 LXC 안에서도 Docker를 실행할 수 있습니다. Proxmox에서는 보통 컨테이너 중첩과 keyctl 가 비특권 컨테이너에 필요합니다.

더 중요한 구매 신호는 플랫폼 개발사의 권장 사항입니다. Proxmox 문서는 컨테이너를 Proxmox QEMU 가상 머신 안에 중첩하는 것이 여전히 권장되는 방식이라고 밝히고 있습니다. 이는 최대한의 격리와 라이브 마이그레이션이 필요한 사례를 두고 하는 말이며, LXC 시스템 컨테이너에서 직접 실행하는 대신이라는 뜻입니다.

LXC 호스트를 직접 관리한다면 이 절충안을 스스로 판단하고 업그레이드도 원하는 일정에 시험해 볼 수 있습니다. LXC VPS를 임대한다면 커널, 보안 프로파일, 고급 기능 플래그는 제공업체가 통제합니다. 컨테이너 안에서 root 권한이 있으면 충분하다고 가정하지 말고, 지원되는 구성을 확인하세요.

KVM에서의 Docker

Docker가 대체로 잘 동작하는 이유는 Linux 게스트가 자체 커널 환경을 제어하기 때문입니다. 게스트 위에는 LXC 중첩 스위치도, OpenVZ 템플릿 요구사항도 없습니다. 그래도 지원되는 Linux 배포판, 호환되는 커널, 워크로드에 충분한 RAM과 스토리지는 여전히 필요합니다.

게스트 커널을 소유한다는 것은 그것을 관리해야 한다는 뜻이기도 합니다. 언매니지드 VPS에서는 업데이트, 방화벽 규칙, Docker 보안, 백업이 모두 사용자의 몫으로 남습니다.

핵심 요점: Docker가 OpenVZ나 LXC를 불가능하게 만드는 것은 아니지만, 제공업체의 구성을 애플리케이션 신뢰성의 일부로 만들어 버립니다. 임대해 쓰는 프로덕션 Docker 호스트라면 KVM이 그 추가 의존성을 없애 줍니다.

"4 vCPU"가 전용 CPU 코어 4개를 뜻하는가

자체 모니터링에서는 CPU가 한가한데도 느리게 느껴지는 VPS. 사람들이 가장 자주 이야기하는 증상입니다. 이를 가능하게 하는 것이 컨테이너 가상화입니다. 자원 경합은 게스트가 볼 수 있는 층보다 한 단계 아래에서 벌어지므로, 게스트 자신의 지표에는 아무 이상도 나타나지 않습니다.

그 메커니즘은 낮은 오버헤드 그 자체입니다. 컨테이너는 완전한 가상 머신보다 호스트에 훨씬 적은 비용을 지우므로, 같은 하드웨어에 더 많이 들어갑니다. 이런 밀도는 만들기 저렴하고 게스트 내부에서는 알아채기 어려워, 오버셀링이 KVM보다 OpenVZ에서 구조적으로 더 쉬워집니다. KVM이라고 해서 제공업체가 호스트를 빽빽이 채우는 것을 막지는 못합니다. 다만 게스트마다 실제 메모리와 실제 CPU 지분을 확보하므로, 얼마나 채울 수 있는지에 산술적 상한이 생깁니다. 진단 측면은 별도의 안내가 있습니다. 제공업체가 오버셀링을 하고 있는지 판별하는 법.

메모리의 동작 방식도 다릅니다. OpenVZ에서는 디스크 스왑을 추가 메모리로 쓸 수 없으므로, 요금제 페이지의 RAM 수치는 완만한 경사가 아니라 벽입니다. 메모리 압박을 받는 KVM 게스트는 느려집니다. 메모리 압박을 받는 OpenVZ 컨테이너는 프로세스가 강제 종료됩니다.

격리 측면의 결과도 있는데, 사람들이 가장 과소평가하는 부분이 바로 이것입니다. 컨테이너의 메모리는 KVM 게스트의 메모리와 달리 호스트에서 주소 지정이 가능합니다. 게스트 내부의 디스크 암호화는 디스크를 도난당했을 때 여전히 지켜 줍니다. 하지만 실행 중인 컨테이너의 키를, 그것을 돌리고 있는 바로 그 머신으로부터 지켜 주지는 못합니다. 위협 모델에 호스트 운영자가 포함된다면 공유 커널은 잘못된 토대입니다. 게스트 안의 어떤 설정으로도 이는 달라지지 않습니다.

핵심 요점: 요금제 페이지의 같은 숫자라도 방식에 따라 약속의 성격이 다릅니다. KVM에서는 할당량입니다. OpenVZ에서는 함께 나눠 쓰는 상한선입니다.

OpenVZ가 여전히 합리적인 경우와 그 앞날

정적 사이트나 트래픽이 적은 LAMP 스택을 운영한다면, OpenVZ가 제한하는 기능을 한 번도 건드리지 않을 수도 있습니다. Windows도, 커스텀 커널도, 게스트가 로드하는 모듈도, 프로덕션 Docker도 필요 없습니다. 그렇게 좁은 워크로드라면 잘 운영되는 OpenVZ 컨테이너로도 여전히 충분합니다.

수명 주기는 10년 전보다 더 많은 주의를 요구합니다. OpenVZ 7은 RHEL 7의 커널 계열, 즉 3.10 버전을 기반으로 합니다. 벤더가 패치를 백포트하므로 버전 번호만으로 유지 보수되는 엔터프라이즈 커널에 보안 수정이 빠져 있다고 단정할 수는 없습니다. 다만 더 새로운 커널 인터페이스를 전제로 하는 소프트웨어와의 호환성은 확인해 두어야 합니다.

The open-source OpenVZ project and the commercial Virtuozzo product are on separate tracks, and the commercial one has published dates. Virtuozzo Hybrid Server 7 reached end of maintenance in July 2024 and is listed for end of life in December 2027 in the 공식 수명 주기 정책.

그렇다고 지금 잘 돌아가는 OpenVZ 사이트가 망가지는 것은 아닙니다. 다만 새로 오래 쓸 워크로드를 맡기기 전에 제공업체의 마이그레이션 계획이 중요해집니다. 어떤 OpenVZ 또는 Virtuozzo 버전이 돌아가는지, 보안 수정은 어떻게 전달되는지, 어떤 마이그레이션 경로가 있는지 물어보세요.

요금제 페이지에 가상화 방식이 적혀 있지 않다면, 가격으로 유추하지 말고 지원팀에 문의하세요. 그 답변은 서면으로 남겨 둘 가치가 있습니다.

워크로드 기준으로 고르기

기술이 아니라 요구사항에서 출발하세요.

워크로드에 자체 커널이 필요하면 KVM을 고르세요

다음 중 하나라도 필요하다면 KVM이 곧바로 답입니다:

• 게스트 운영체제로서의 Windows
• 커스텀 커널
• 게스트가 로드하는 커널 모듈
• 컨테이너 안의 컨테이너 의존성이 없는 프로덕션 Docker
• 제공업체가 열어 준 경우의 중첩 가상화
• 게스트가 제어하는 스왑과 커널 튜닝

Windows가 결정적인 이유는 OpenVZ 컨테이너와 LXC 컨테이너 모두 Linux 호스트 커널을 쓰기 때문입니다. 애플리케이션 자체에 Linux와 Windows 중 무엇을 고를지는 소프트웨어 호환성, 운영, 라이선스가 얽힌 별개의 문제입니다. Linux와 Windows VPS 비교 그 결정에 대해서는 다음 글을 참고하세요.

효율적인 Linux 시스템 컨테이너를 원한다면 LXC를 고르세요

워크로드가 Linux 전용이고, 별도의 커널이 필요 없으며, 낮은 오버헤드나 호스트가 관리하는 빠른 변경에서 이득을 본다면 LXC가 합리적입니다. 특히 Proxmox나 LXC 호스트를 직접 관리할 때 유용합니다.

임대하는 LXC VPS라면 Docker 지원 여부, 필요한 장치, 보안 모드, 백업 동작 방식, 그리고 고급 기능을 켤 수 있는지를 확인하세요.

단순하고 검증된 Linux 워크로드라면 OpenVZ도 고려하세요

기본적인 웹사이트, 소규모 LAMP 스택, DNS 서비스, 또는 그와 비슷하게 일반적인 Linux 워크로드라면 다음 조건이 갖춰질 때 OpenVZ도 여전히 받아들일 만합니다:

• 제공업체가 플랫폼 버전을 문서로 밝히고 있을 것.
• 사용하는 소프트웨어가 제공되는 커널 환경을 지원할 것.
• Windows나 커널 커스터마이징이 필요하지 않을 것.
• Docker가 필요 없거나 명시적으로 지원될 것.
• 제공업체에 신뢰할 만한 보안 및 마이그레이션 계획이 있을 것.
• 가격이나 운영 모델이 그것을 선택할 실질적인 이유를 줄 것.

예전 비교 글이 OpenVZ가 항상 더 싸다고 말한다는 이유만으로 선택하지 마세요. 지금의 요금제, 지원, 자원 정책, 마이그레이션 선택지를 비교하세요.

답이 KVM으로 귀결됐다면, 그것은 취향이 아니라 제약이 내린 결론입니다. Cloudzy의 KVM VPS 는 AMD EPYC과 순수 NVMe 위에서 60초 만에 부팅되며, 모든 인스턴스가 고유한 게스트 커널을 갖습니다. 커널 모듈이 로드되고, 커스텀 커널이 부팅되며, Linux와 Windows 게스트를 모두 지원합니다. Docker는 마켓플레이스에 있습니다 직접 설치하고 싶지 않다면 이용해 보세요.

자주 묻는 질문

systemd-detect-virt