“Docker로 다 되는 거 아니에요? 왜 굳이 VPS를 따로 써야 하죠?” 실제로 많이 받는 질문입니다. 결론부터 말하면 컨테이너와 가상서버는 경쟁 관계가 아니라 다른 레이어입니다. 이 글에서는 두 기술이 근본적으로 어떻게 다른지, 그리고 실제 워크로드에서 무엇을 선택해야 하는지를 정리합니다.
근본적인 차이 — 무엇을 격리하는가
[가상서버 / KVM]
물리 하드웨어 → Hypervisor(KVM) → 게스트 커널 A / 게스트 커널 B / ...
각 VM은 완전히 독립된 커널을 가짐
[컨테이너 / Docker]
물리 하드웨어 → 호스트 OS 커널 (하나)
→ 컨테이너 A / 컨테이너 B / ...
모든 컨테이너가 호스트 커널을 공유
가장 중요한 차이는 커널을 공유하느냐입니다. VM은 자체 커널을 가진 독립된 컴퓨터처럼 동작하지만, 컨테이너는 프로세스를 격리된 네임스페이스 안에 가둔 것에 가깝습니다. 이 한 가지 차이에서 나머지 차이들이 대부분 파생됩니다.
비교표
| 항목 | 가상서버(KVM) | 컨테이너(Docker) |
|---|---|---|
| 커널 | 게스트마다 독립 | 호스트와 공유 |
| 부팅 시간 | 수십 초~수 분 | 수백 밀리초~수 초 |
| 리소스 오버헤드 | 상대적으로 큼(커널 중복) | 작음(프로세스 수준) |
| 보안 경계 | 강함(하드웨어 가상화 수준) | 상대적으로 약함(커널 공유) |
| OS 다양성 | 게스트마다 다른 OS 가능(Windows·Linux 혼재) | 호스트와 같은 커널 계열만 |
| 이식성 | 이미지 크기 크고 무거움 | 이미지 가볍고 빠름 |
| 적합 단위 | “서버 한 대” 전체 | “프로세스 하나” |
보안 경계 — 가장 실무적으로 중요한 차이
컨테이너는 chroot·네임스페이스·cgroups를 조합한 격리이지, 하드웨어 수준의 격리가 아닙니다. 호스트 커널에 취약점이 있거나 컨테이너가 --privileged로 실행되면, 이론적으로 컨테이너 탈출(container escape)이 가능합니다.
반면 KVM 기반 VM은 CPU의 가상화 확장(Intel VT-x/AMD-V)을 이용해 하드웨어 수준에서 게스트를 분리합니다. VM 탈출도 이론적으로는 존재하지만(하이퍼바이저 취약점), 컨테이너 탈출보다 공격 표면이 훨씬 좁습니다.
실무 기준: 신뢰할 수 없는 코드(멀티테넌트 SaaS의 고객 코드, 검증되지 않은 서드파티 워크로드)를 돌린다면 VM 격리를 우선 고려하세요. 내가 작성하고 통제하는 애플리케이션이라면 컨테이너로 충분한 경우가 대부분입니다.
리소스 오버헤드 — 숫자로 보기
같은 4vCPU/8GB 사양이라고 가정할 때 대략적인 체감 차이입니다.
- VM: 게스트 커널이 별도로 메모리 수백 MB~1GB를 사용, 부팅에 수십 초. 대신 리소스 예약이 명확해 “옆방 소음”이 적음.
- 컨테이너: 커널 오버헤드가 거의 없어 같은 하드웨어에 훨씬 많은 인스턴스를 밀집시킬 수 있음. 대신
cgroups제한을 정확히 걸지 않으면 한 컨테이너가 폭주할 때 이웃 컨테이너에 영향을 줄 수 있음.
마이크로서비스처럼 프로세스 단위가 작고 많을수록 컨테이너의 이점이 커지고, 반대로 하나의 애플리케이션이 리소스를 통째로 쓰는 구조일수록 VM과의 차이가 줄어듭니다.
실제 선택 기준
컨테이너(Docker/Kubernetes)가 유리한 경우
- 마이크로서비스 아키텍처, 배포 빈도가 높은 애플리케이션
- CI/CD 파이프라인에서 빌드·테스트 환경을 빠르게 띄웠다 내려야 할 때
- 같은 서버에 여러 애플리케이션을 밀집 배치해야 할 때
가상서버(VM/KVM)가 유리한 경우
- 신뢰 경계가 다른 워크로드를 함께 운영해야 할 때(멀티테넌트)
- Windows처럼 호스트와 다른 커널의 OS가 필요할 때
- 커널 파라미터·드라이버 수준까지 직접 통제해야 할 때
- 게임서버·DB처럼 “리소스를 통째로 예약”하는 것이 성능에 직결될 때 — 관련해서 NUMA·CPU pinning 튜닝도 VM 환경에서만 의미가 있는 최적화입니다.
실무에서는 섞어 쓰는 것이 정답인 경우가 많음
가장 흔한 실전 구성은 VM 위에 컨테이너를 올리는 것입니다. VPS·전용서버(VM 또는 베어메탈) 하나를 임대해 그 안에서 Docker로 여러 서비스를 컨테이너 단위로 운영하는 방식입니다. 이렇게 하면 VM 수준의 격리(임대 서버 간 경계)와 컨테이너 수준의 배포 유연성을 동시에 얻습니다.
KVM 자체의 내부 구조(virtio·IOMMU·ballooning)가 궁금하다면 KVM 가상화 깊이 파헤치기에서 더 다룹니다.
자주 묻는 질문
Q. Kubernetes를 쓰면 VM이 필요 없나요? Kubernetes 자체도 결국 어딘가의 노드(VM 또는 베어메탈) 위에서 돌아갑니다. 클라우드 매니지드 K8s를 쓰더라도 내부적으로는 VM 노드 풀 위에 컨테이너가 스케줄링되는 구조인 경우가 많습니다.
Q. 컨테이너는 VM보다 무조건 가볍고 좋은 거 아닌가요? 가볍고 빠른 대신 격리 수준이 낮다는 트레이드오프가 있습니다. “가볍다=항상 좋다”가 아니라 워크로드의 신뢰 경계에 맞춰 선택해야 합니다.
Q. 개인 프로젝트인데 뭘 써야 하나요? 소규모라면 VPS 한 대에 Docker Compose로 여러 서비스를 올리는 구성이 비용·운영 난이도 면에서 가장 무난합니다.
마치며
컨테이너와 VM은 대체재가 아니라 격리 수준이 다른 도구입니다. “가볍고 빠른 배포 단위”가 필요하면 컨테이너, “독립된 컴퓨터 수준의 경계”가 필요하면 VM입니다. 대부분의 실무는 VM 위에 컨테이너를 올리는 조합으로 귀결됩니다.
TCP-80.NET VPS·전용서버 모두 Docker를 자유롭게 설치해 컨테이너 워크로드를 올릴 수 있습니다. 구성이 고민되면 텔레그램 @tcp80net으로 문의해 주세요.