VPS, VM, VPC 차이점 완벽 정리

VPS, VM 및 VPC의 개념

VM(가상 머신)은 소프트웨어로 구현된 컴퓨터입니다. 하이퍼바이저는 물리적 서버 한 대를 여러 개의 독립적인 머신으로 분할하며, 각 머신은 고유한 커널을 실행합니다. VPS(가상 사설 서버)는 운영체제, 일반적으로 root 접근 권한, 월간 이용료가 포함된 상품 형태의 서버 대여 서비스입니다. 대부분의 VPS 플랜은 가상 머신이지만, 일부 호스트는 호스트 커널을 공유하는 컨테이너를 같은 이름으로 판매하기도 합니다. VPC(가상 사설 클라우드)는 서버가 아닙니다. 이는 클라우드 계정 내에서 사용자가 정의하는 사설 네트워크이며, 이 안에 리소스를 배치합니다. VM은 일반적인 기술이며, VPS는 상품이고, VPC는 그 상품을 둘러싼 네트워크입니다.

이 세 가지 용어 중 두 가지는 머신을 설명하고, 나머지 하나는 네트워크를 설명합니다. 대부분의 혼란은 이 불일치에서 발생합니다. 사람들이 마치 같은 선반에 있는 세 가지 상품인 것처럼 비교하기 때문입니다.

가상 머신(VM)이란 무엇인가

하이퍼바이저는 하드웨어인 것처럼 가장하는 계층입니다. 각 게스트에게 가상 CPU, 메모리 블록, 가상 디스크, 가상 네트워크 카드를 할당하고 게스트끼리 서로를 보지 못하게 격리합니다. 서버 환경에서는 KVM, Xen, Hyper-V, VMware ESXi가 주로 사용됩니다. 현대의 하이퍼바이저는 CPU 가상화 확장 기능(Intel VT-x, AMD-V)을 활용하므로, 게스트의 명령어는 해석되는 방식이 아니라 실제 CPU에서 네이티브에 가까운 속도로 실행됩니다.

시스템 관리자에게 중요한 부분은 커널입니다. VM은 자체 커널로 부팅되므로 배포판을 선택하고, 커널 모듈을 로드하며, 자신에게만 적용되는 sysctl 값을 설정할 수 있습니다. 이는 호스트 커널을 공유하며 프로세스와 파일에 대한 독자적인 뷰만 제공받는 컨테이너(LXC, Docker)와는 다른 점입니다.

모든 Linux 시스템에서 다음 명령 한 줄로 결과를 확인할 수 있습니다.

systemd-detect-virt

kvm는 KVM 하이퍼바이저 위에서 실행 중인 가상 머신임을 의미합니다. lxc 또는 openvz는 다른 사용자의 커널 위에서 실행되는 컨테이너 내부에 있음을 의미합니다. none는 지원되는 가상화 기술이 감지되지 않았음을 의미합니다. 해당 명령어를 사용할 수 없는 경우, lscpu | grep -i hypervisor를 통해 하이퍼바이저 정보를 확인할 수 있으나 컨테이너 여부는 식별하지 못합니다.

VPS란 무엇인가

VPS는 격리된 서버, 주로 VM을 상용화한 형태입니다. 기반 기술은 가상화이며, "VPS"라는 명칭은 이를 상품화하기 위한 요소들, 즉 재설치 가능한 OS 이미지, IP 주소, 대역폭 할당량, 제어판, 월별 요금, 그리고 호스트 장애 시 문의할 수 있는 지원 체계를 포함합니다. "Private"이라는 용어는 수백 개의 사이트가 하나의 운영 체제와 하나의 PHP 설정을 공유하는 공유 호스팅과 구분하기 위해 사용됩니다.

VPS는 기술 용어가 아닌 상품명이므로 항상 완전한 VM을 의미하지는 않습니다. 일부 저가형 플랜은 컨테이너를 같은 명칭으로 판매하며, 많은 업체가 사용하는 컨테이너 플랫폼인 OpenVZ는 자사의 컨테이너를 "가상 사설 서버(virtual private servers)라고도 함"이라고 설명합니다. 이 차이는 커널을 제어해야 할 때 처음 드러납니다. 컨테이너 기반 플랜에서는 호스트의 커널을 사용하므로 이를 변경할 수 없습니다. sudo modprobe wireguard은 호스트가 모듈을 이미 로드했더라도 컨테이너의 모듈 디렉터리에서 해당 모듈을 찾지 못하면 실패합니다. 또한 누락된 모듈을 로드하려면 호스트 커널을 변경할 권한이 필요합니다. 호스트 커널이 WireGuard를 지원하지 않으면 인터페이스 생성(ip link add dev wg0 type wireguard)이 RTNETLINK answers: Operation not supported 오류와 함께 실패합니다. 이때 wg-quick은 설치된 경우 사용자 공간 구현(기본값 wireguard-go)으로 대체하며 "Missing WireGuard kernel module. Falling back to slow userspace implementation."이라는 메시지를 출력합니다. 이러한 대체 방식도 컨테이너가 TUN 장치를 사용할 수 있도록 허용되어야 하며, 모든 호스트가 이를 허용하는 것은 아닙니다. 사용자 공간 바이너리가 없으면 wg-quick는 오류와 함께 중단됩니다. KVM 플랜에서는 커널을 직접 제어할 수 있습니다. WireGuard를 설치하고, 모듈이 로드되지 않았다면 직접 로드한 뒤 인터페이스를 구성하면 터널이 활성화됩니다. Docker, VPN, 커스텀 커널 또는 서버 내부에서 자체 가상 머신을 실행할 계획이라면 구매 전에 가상화 유형을 확인하십시오. VPS 내부에서 가상 머신 실행을 위해서는 호스트에서 중첩 가상화(nested virtualisation)가 활성화된 KVM이 필요하며, 이는 지원하는 플랜이 더욱 제한적입니다.

VPC란 무엇인가

VPC는 클라우드 공급자 내부의 소프트웨어 정의 네트워크입니다. 대부분의 클라우드에서는 10.0.0.0/16과 같은 CIDR 표기법으로 주소 범위를 지정한 뒤, 그 안에서 서브넷을 분할합니다(Google Cloud는 네트워크 전체 범위를 지정하는 대신 각 지역 서브넷에 자체 범위를 할당합니다). 여기에 라우팅 테이블을 연결하고 리소스 앞단에 방화벽 규칙(보안 그룹)을 설정합니다. VPC에는 CPU, 메모리, 디스크가 없습니다. 로그인할 대상도 존재하지 않습니다. VPC 내의 모든 서버를 삭제해도 VPC는 그대로 남아 있으며, 비어 있는 상태로 유지되므로 대개 비용이 발생하지 않습니다.

VPC를 사용하는 이유는 사설 주소를 얻기 위함입니다. 동일한 VPC 내의 두 서버는 공급자의 내부 패브릭망에서 10.0.1.15와 같은 주소로 통신하므로, 트래픽이 공용 인터넷을 거치지 않으며 인터넷 송신 요금도 부과되지 않습니다. 따라서 데이터베이스는 사설 주소로만 수신 대기하도록 설정할 수 있으며, 외부로 노출되는 포트가 전혀 없게 됩니다.

ip -4 addr show

10.0.0.0/8, 172.16.0.0/12 또는 192.168.0.0/16 내부의 주소는 사설 주소입니다. 공용 주소가 있다고 해서 서버가 인터넷에서 바로 접속 가능한 것은 아니며, 라우팅 및 방화벽 규칙이 접근을 허용해야만 통신이 가능합니다.

VPC를 사용하면 서버가 비공개 상태가 됩니까?

아니요, 이는 세 가지 용어와 관련하여 가장 비용이 많이 드는 오해입니다. VPC는 라우팅과 주소 지정을 제어할 뿐, 인터넷이 해당 머신에 접근할 수 있는지 여부를 결정하지 않습니다. 인스턴스에 공인 IP가 할당되어 있고, 서브넷이 인터넷으로 라우팅되며, 보안 규칙이 0.0.0.0/0에서 오는 22번 포트 접근을 허용한다면, 해당 서버는 VPC 사용 여부와 관계없이 다른 모든 서버와 동일하게 노출됩니다. 기본 VPC에서는 인터넷으로 향하는 라우팅이 이미 설정되어 있습니다. VPC를 통해 얻는 격리란 리소스에 공인 주소를 전혀 부여하지 않을 수 있다는 점과, 어떤 서브넷이 어떤 서브넷과 통신할 수 있는지 규칙을 정할 수 있다는 점입니다.

이 세 가지 용어는 서로 다른 종류의 격리를 보장합니다. VM은 컴퓨팅을 격리합니다. 하이퍼바이저가 CPU 시간과 메모리를 분리하므로 다른 게스트가 사용자의 RAM을 읽을 수 없습니다. 하지만 디스크와 네트워크에 대한 격리는 더 취약하며, 동일한 호스트를 사용하는 다른 사용자의 작업량이 많으면 성능 저하가 발생할 수 있습니다. 컨테이너 기반 VPS는 커널을 공유하므로 커널 수준의 버그는 공유 위험이 됩니다. VPC는 컴퓨팅에 대해 어떠한 격리도 제공하지 않습니다. VPC는 오직 네트워크 형태만 제어합니다.

가격 책정의 사고방식

VPS는 일반적으로 고정된 사양의 장비를 고정된 월 요금으로 판매합니다. 월이 시작되기 전에 청구 금액을 알 수 있으며, 디스크와 데이터 전송 허용량이 요금에 포함되어 있습니다. 이러한 예측 가능성이 소규모 워크로드 운영 시 클라우드 인스턴스 대신 VPS를 선택하는 주된 이유입니다.

클라우드 VM은 종량제로 운영됩니다. 인스턴스는 시간당 또는 초당 요금이 청구되며, 디스크, 스냅샷, 로드 밸런서, 아웃바운드 트래픽은 별도로 과금됩니다. VPC 자체는 보통 무료이지만, 여기에 연결된 관리형 구성 요소는 그렇지 않습니다. 프라이빗 인스턴스가 인터넷에 연결되도록 돕는 NAT gateway는 시간당 요금이 부과되며, 트래픽 과금 방식은 제공업체마다 다릅니다. AWS는 NAT gateway가 처리하는 기가바이트당 요금을 추가하는 반면, OVHcloud는 Public Cloud Gateway에 대해 시간당 및 사용량 기반 요금을 부과하며 트래픽 비용을 포함합니다. AWS에서는 가용 영역(availability zones)을 넘나드는 트래픽에도 요금이 부과되지만, Azure는 동일 리전 내 가용 영역 간 트래픽에는 요금을 부과하지 않습니다. 2026년 10월 27일 기준으로, AWS VPC 가이드에 따르면 각 리전에 기본 VPC가 제공됩니다. 한편 AWS VPC FAQ에 따르면 2013년 3월 18일 이전에 생성된 계정은 이전에 EC2 인스턴스를 실행하거나 ELB, RDS, ElastiCache, Redshift 리소스를 프로비저닝하지 않은 활성화된 리전에서 기본 VPC를 사용할 수 있습니다. 삭제된 기본 VPC는 다시 생성할 수는 있지만 복구할 수는 없습니다. Google Cloud는 관리자가 기능을 끄지 않는 한 모든 새 프로젝트에 기본 네트워크를 제공하며, Azure는 기존 가상 네트워크를 선택하지 않으면 새 VM과 함께 가상 네트워크를 생성합니다. 어느 경우든 사용자의 클라우드 VM은 요청 여부와 관계없이 이러한 네트워크 중 하나 내부에 위치하게 됩니다.

실제로 필요한 것은 무엇인가

• 웹사이트, 앱, 게임 서버 또는 VPN을 위한 서버 한 대: VPS가 적합합니다. 새 VPS에서의 첫 10분은 요금제 명칭보다 훨씬 중요합니다.
• 사설 주소로 서로 통신해야 하는 여러 대의 서버: VPC 또는 VPS 제공업체가 다른 이름으로 제공하는 사설 네트워크 기능이 필요합니다.
• 데이터센터 전체가 마비되어도 운영되어야 하는 워크로드: 여러 영역(zone)을 갖춘 클라우드, 즉 VPC 내부의 VM이 필요합니다.
• 커널에 대한 완전한 제어권 또는 그 위에 직접 올리는 하이퍼바이저: KVM 기반 VPS(하이퍼바이저를 원한다면 중첩 가상화 활성화 필요) 또는 전용 서버가 필요하며, 비교 시 요금제 뒤에 숨겨진 디스크 유형을 확인하십시오.

대부분의 단일 서버 프로젝트는 VPC가 필요하지 않습니다. VPS와 함께 제공되는 사설 네트워크 기능만으로도 소규모 서버군을 운영하기에는 충분합니다.

FAQ

VPS와 VM은 같은 것입니까?

대체로 그렇지만 항상 그런 것은 아닙니다. KVM, Xen, VMware 기반의 모든 VPS는 가상 머신(VM)이지만, 모든 가상 머신이 VPS인 것은 아닙니다. 예를 들어 VirtualBox를 사용하여 노트북에서 실행하는 VM은 누구의 상품도 아니기 때문입니다. 반대로 모든 VPS가 VM인 것도 아닙니다. OpenVZ나 LXC 기반의 플랜은 호스트 커널을 공유하는 컨테이너이며, OpenVZ는 자체 컨테이너를 가상 프라이빗 서버(Virtual Private Server)라고 부릅니다. 커널 접근 권한이 필요한 경우 systemd-detect-virt을 통해 확인하십시오.

VPC 안에 VPS를 넣을 수 있습니까?

일반적으로 불가능합니다. VPC는 특정 클라우드 제공업체의 구성 요소이기 때문입니다. AWS는 동일 조직 내 계정 간 서브넷 공유를 지원하기도 합니다. 독립적인 제공업체의 VPS는 해당 제공업체의 네트워크상에 존재합니다. 두 환경 사이에 프라이빗 연결이 필요하다면 대신 VPN 터널을 구축하여 VPS가 해당 터널을 통해 프라이빗 서브넷에 접근하도록 해야 합니다.

왜 클라우드 비용이 동일한 사양의 VPS보다 비쌉니까?

인스턴스 가격은 비용의 일부일 뿐입니다. 계량형 클라우드에서는 스토리지, 스냅샷, 아웃바운드 트래픽, 로드 밸런서, NAT 게이트웨이가 별도의 항목으로 청구됩니다. NAT 게이트웨이 하나만으로도 소형 VPS 한 대의 월 비용보다 더 많은 금액이 발생할 수 있습니다. 고정 가격제 VPS는 디스크와 데이터 전송 허용량을 하나의 금액에 포함하므로, 동일한 워크로드라도 VPS가 더 저렴해 보이는 경우가 많습니다.

서버에 실제 커널 접근 권한이 있는지 어떻게 확인합니까?

systemd-detect-virt를 실행하여 결과를 확인하십시오. kvm, xen, vmware(또는 최신 EC2 인스턴스의 경우 amazon)가 출력되면 자체 커널을 보유한 것이며 modprobe를 통해 커널 모듈을 로드할 수 있습니다. lxc, lxc-libvirt, openvz이 출력되면 호스트 커널을 공유하는 상태입니다. 이 경우 모듈 로드에는 호스트 커널 권한이 필요하며, /proc/sys 하위의 네임스페이스 설정(네트워크 설정 포함)은 호스트가 허용하는 범위 내에서만 구성할 수 있습니다. 두 번째 확인 방법은 uname -r를 사용하는 것입니다. 컨테이너 플랜에서는 배포판에서 제공한 적 없는 커널 버전이 표시되는 경우가 많습니다.