Docker와 가상 머신 비교: 5분 만에 이해하는 성능 차이와 선택 기준

팀 회의에서 대표가 물었습니다. “신규 프로젝트에는 Docker와 가상 머신 중 무엇을 쓸 건가요?” 둘 다 사용해 본 적은 있었지만, 차이를 명확하게 설명하려니 막막했습니다. 자리로 돌아와 검색해 보니 온라인 글은 지나치게 이론적이거나 “Docker가 더 가볍다”는 말로 끝나는 경우가 많았습니다. 무엇이 가벼운지, 성능 차이가 얼마나 나는지, 어떤 상황에서 무엇을 써야 하는지는 제대로 설명하지 않았습니다.

사흘 동안 파고든 끝에야 이 문제를 제대로 이해했습니다. 가장 쉬운 방식으로 Docker와 가상 머신의 차이를 정리해 보겠습니다. 두 기술의 본질적인 차이, 실제 성능 차이, 기술을 빠르게 선택할 수 있는 의사결정 트리까지 확인할 수 있습니다.

본질적인 차이—컨테이너 화물 vs 독립된 방

먼저 가장 이해하기 쉬운 비유부터 살펴보겠습니다.

가상 머신은 건물 안의 독립된 주거 공간과 같습니다. 각 집에는 주방, 화장실, 전기와 수도 시설이 따로 있어 완전한 생활 단위를 이룹니다. 나는 2층에 살고 이웃은 3층에 살며 서로 간섭하지 않습니다. 각 가상 머신도 Windows나 Linux 같은 완전한 운영체제를 실행합니다. 자체 커널, 드라이버, 시스템 서비스를 모두 갖추고 있습니다.

Docker 컨테이너는 부두의 컨테이너 화물과 같습니다. 모든 컨테이너가 크레인, 전력 시스템, 도로망 같은 부두의 기반 시설을 공유합니다. 컨테이너 안에는 애플리케이션과 필요한 의존성만 들어가며, 각 컨테이너마다 기반 시설을 따로 마련할 필요가 없습니다. Docker 컨테이너는 호스트 운영체제의 커널을 공유하고 애플리케이션과 실행 환경만 패키징합니다.

작아 보이는 이 차이는 모든 측면에 영향을 줍니다.

아키텍처를 보면 가상 머신에는 Guest OS(게스트 운영체제)와 Hypervisor(가상화 계층)라는 두 겹의 부담이 더 있습니다. Hypervisor는 CPU, 메모리, 디스크, 네트워크 인터페이스 등 하드웨어 환경 전체를 에뮬레이션해야 합니다. 각 가상 머신이 시작될 때는 컴퓨터를 재부팅하는 것처럼 완전한 운영체제를 먼저 시작하고 커널을 로드한 뒤 서비스를 초기화해야 합니다.

Docker는 어떨까요? 호스트 커널 위에서 바로 실행됩니다. 컨테이너를 시작하는 일은 프로세스 하나를 시작하는 것과 같아서 몇 초면 충분합니다. 하드웨어 가상화 오버헤드도, 별도의 운영체제 계층도 없어 매우 가볍습니다.

커널을 공유해도 괜찮을지 의문이 들 수 있습니다. 뒤에서 살펴보겠지만 바로 이 점이 Docker의 약점입니다. 격리 수준이 가상 머신보다 낮기 때문입니다. 하지만 동시에 빠르고 가볍고 리소스를 적게 사용하는 장점의 원천이기도 합니다.

이 본질적인 차이를 이해하면 뒤에 나오는 성능 비교와 사용 사례도 자연스럽게 연결됩니다.

성능 대결—데이터로 비교하기

이론만으로는 부족하니 데이터를 살펴보겠습니다.

시작 속도: 초 단위 vs 분 단위

지난주 구성까지 마친 가상 머신(2코어 4GB)을 시작해 봤습니다. 전원을 켠 뒤 SSH로 로그인할 수 있을 때까지 거의 4분이 걸렸습니다. 그사이에 커피를 내리고 SNS 게시물도 몇 개 훑어볼 수 있었습니다.

같은 Redis 서비스를 Docker로 시작하는 데는 얼마나 걸렸을까요? 3초였습니다.

마우스에서 손을 떼기도 전에 끝났습니다.

우연이 아닙니다. 가상 머신은 커널 초기화, 시스템 서비스 시작, 네트워크 설정 등 완전한 운영체제를 구성하는 모든 과정을 거쳐야 합니다. Docker 컨테이너는 이미 실행 중인 커널 위에서 프로세스 하나만 시작하면 됩니다.

리소스 사용량: MB 단위 vs GB 단위

리소스 사용량의 차이는 더 큽니다. Docker 자체의 오버헤드는 얼마나 될까요? 메모리 6~8MB입니다. 잘못 본 것이 아닙니다. 한 자릿수 MB입니다.

제가 실행한 Redis 컨테이너는 실제로 CPU 0.08%, 메모리 2.6MB를 사용했습니다. 존재감이 거의 없을 만큼 가볍습니다.

가상 머신은 어떨까요? 내부에서 아무것도 실행하지 않아도 운영체제만으로 최소 1~2GB의 메모리를 사용합니다. MySQL을 가상 머신에서 실행하려면 메모리 4GB부터 잡아야 합니다.

이 차이는 냉정한 현실로 이어집니다. 같은 물리 서버에서 가상 머신은 많아야 수십 개를 실행하지만, Docker 컨테이너는 1,000개 이상 실행할 수 있습니다. 실제 운영 환경에서 32코어 128GB 서버 한 대가 Docker 컨테이너 800개 이상을 여유롭게 실행하는 모습을 본 적이 있습니다. 가상 머신이었다면 30개도 버거웠을 것입니다.

성능 오버헤드: 네이티브에 가까움 vs 체감되는 저하

Vultr - 고성능 NVMe 클라우드 서버, 전 세계 32개 노드, Docker 원클릭 배포

요금 보기 →광고

한 연구 기관의 비교 테스트에 따르면 Docker 컨테이너는 거의 모든 상황에서 네이티브 애플리케이션과 비슷한 성능을 보였고, 별도의 가상화 오버헤드가 없어 일부 상황에서는 더 빨랐습니다. 가상 머신은 보통 10~20%의 성능 오버헤드가 발생합니다.

CPU 집약적인 작업에서는 차이가 특히 두드러집니다. 대규모 프로젝트를 직접 컴파일해 보니 가상 머신에서는 25분, 컨테이너에서는 21분, 물리 서버에서는 20분이 걸렸습니다. 컨테이너의 성능 손실은 거의 없었습니다.

한눈에 볼 수 있도록 표로 비교해 보겠습니다.

이 표를 보면 오늘날 마이크로서비스 아키텍처가 Docker로 이동하는 이유를 알 수 있습니다. 리소스 활용률이 한 자릿수나 차이 나니 매력적일 수밖에 없습니다.

격리와 보안—강할수록 좋은 것은 아닙니다

성능상의 장점을 살펴봤으니 이제 Docker의 약점을 이야기해 보겠습니다.

격리 수준의 차이

가상 머신은 하드웨어 수준으로 격리됩니다. 각 가상 머신에 독립된 운영체제 커널이 있어 완전히 분리된 두 대의 컴퓨터와 같습니다. 가상 머신 A가 해킹당하더라도 이론적으로 공격자가 가상 머신 B나 호스트로 이동할 수 없습니다. 이를 ‘강한 격리’라고 합니다.

Docker는 프로세스 수준으로 격리됩니다. 모든 컨테이너가 호스트 커널을 공유하고 Linux의 namespace와 cgroups 기술로 리소스를 분리합니다. 듣기만 해도 가상 머신만큼 안전해 보이지는 않습니다.

실제로도 그렇습니다. 컨테이너 이스케이프(Container Escape)는 Docker를 겨냥한 공격 방식입니다. 공격자가 컨테이너의 취약점을 찾으면 격리를 벗어나 호스트를 직접 공격할 수 있습니다. 지난해 공개된 CVE-2024-21626 취약점은 공격자가 컨테이너에서 호스트로 탈출할 수 있게 했습니다.

가상 머신에는 이런 위험이 없을까요? 위험은 있지만 공격 난도가 훨씬 높습니다.

어떤 상황에서 반드시 가상 머신을 써야 할까요?

Docker가 안전하지 않다는 뜻은 아닙니다. 격리가 얼마나 필요한 상황인지가 핵심입니다.

서로 다른 고객에게 서비스를 제공하는 클라우드 서비스 사업자라면 고객 사이를 완전히 격리해야 하므로 가상 머신을 사용해야 합니다. Alibaba Cloud나 AWS 같은 퍼블릭 클라우드도 기반 계층에서 서로 다른 테넌트를 가상 머신으로 격리합니다. 고객 A와 고객 B가 커널을 공유하게 할 수는 없습니다. A가 공격받았을 때 B까지 피해를 볼 수 있기 때문입니다.

엄격한 규정 준수 요구 사항이 있는 금융 회사라면 감사 담당자가 Docker의 공유 커널 구조를 보고 승인을 거부할 수도 있습니다. 이런 경우에는 가상 머신을 사용하는 편이 안전합니다.

사용자가 제출한 임의의 코드를 대신 실행하는 온라인 코드 컴파일 플랫폼처럼 신뢰할 수 없는 코드를 실행해야 한다면 Docker는 위험 부담이 너무 크므로 가상 머신을 써야 합니다.

Docker 보안을 강화하는 방법

그렇지만 대부분의 상황은 이 정도로 극단적이지 않습니다. 사내 마이크로서비스가 모두 직접 작성한 코드라면 Docker로 충분합니다. 다음 세 가지만 지키면 됩니다.

1. root 사용자로 컨테이너를 실행하지 않습니다. 컨테이너는 기본적으로 root 권한으로 실행되므로 침해됐을 때 피해가 커질 수 있습니다. 권한이 없는 사용자로 바꾸세요.
2. 컨테이너 권한(Capabilities)을 제한합니다. 컨테이너에 필요하지 않은 시스템 권한을 과도하게 부여하지 마세요.
3. 이미지 취약점을 정기적으로 스캔합니다. Trivy 같은 도구로 검사하고 취약점이 발견되면 기본 이미지를 제때 업데이트하세요.

저희 팀은 현재 모든 Docker 컨테이너에 이 세 가지 조치를 적용하고 있으며 2년 동안 보안 문제가 발생하지 않았습니다.

결국 필요한 격리 수준은 위협 모델에 따라 달라집니다. 사내 애플리케이션에는 Docker로 충분하며, 외부에 노출되는 멀티테넌트 환경이라면 가상 머신을 고려해야 합니다.

사용 사례—의사결정 트리

지금까지의 내용을 바탕으로 어떤 때에 무엇을 선택해야 하는지 간단한 의사결정 과정을 살펴보겠습니다.

Docker를 우선 선택해야 하는 4가지 상황

1. 마이크로서비스 아키텍처

마이크로서비스를 구축하고 있다면 고민하지 말고 Docker를 선택하세요.

마이크로서비스는 대규모 애플리케이션을 수십 개 또는 수백 개의 작은 서비스로 나누고 각 서비스를 독립적으로 배포하는 구조입니다. 가상 머신을 사용하면 사용자 서비스에 VM 하나, 주문 서비스에 VM 하나, 결제 서비스에 VM 하나가 필요해 리소스를 감당하기 어렵습니다.

Docker는 가볍고, 몇 초 만에 시작하며, 높은 밀도를 제공하므로 이런 구조에 정확히 맞습니다. 전자상거래 플랫폼의 사용자 서비스, 주문 서비스, 결제 서비스를 각각 컨테이너로 실행하면 리소스가 서로 분리되고 수평 확장도 순식간에 끝납니다.

예전에 참여한 프로젝트에서는 30개가 넘는 마이크로서비스를 모두 컨테이너화해 서버 5대에 배포했습니다. 가상 머신을 사용했다면 서버 비용만 세 배로 늘었을 것입니다.

2. DevOps와 CI/CD 파이프라인

개발, 테스트, 운영 환경이 서로 다른 문제는 모든 개발자의 악몽입니다. “내 컴퓨터에서는 되는데요”라는 말을 수도 없이 들어봤을 것입니다.

Docker는 바로 이 문제를 해결하기 위해 만들어졌습니다. 애플리케이션과 의존성을 모두 이미지에 넣으면 개발 환경에서 실행되던 것이 테스트 환경과 운영 환경에서도 그대로 실행됩니다. 환경이 완전히 동일해집니다.

CI/CD 파이프라인에도 잘 맞습니다. Jenkins에서 자동 빌드할 때마다 깨끗한 환경이 필요하다면 Docker 컨테이너를 시작해 테스트를 실행한 뒤 삭제하면 됩니다. 전체 과정이 20초면 끝납니다. 가상 머신을 사용하면 시작에만 5분을 기다려야 하고 환경도 수동으로 정리해야 합니다.

3. 빠른 배포와 탄력적 확장

밤 11시에 갑자기 트래픽이 몰려 인스턴스 10개를 긴급히 확장해야 한다고 가정해 보겠습니다.

Docker: 몇 초 안에 컨테이너 10개가 모두 시작됩니다.
가상 머신: 각 가상 머신을 시작하는 데 5분씩, 10대면 50분을 기다려야 합니다. 그 전에 사용자는 이미 떠났을 것입니다.

KiloClaw - 기업용 매니지드 OpenClaw, AI Agent 오케스트레이션 및 스마트 라우팅

시작하기 →광고

탄력적 확장이 바로 Docker의 핵심 강점입니다. K8s(Kubernetes)는 트래픽에 따라 컨테이너 수를 자동으로 확장하거나 축소할 수 있고 사용자는 이를 알아차리지 못합니다. 가상 머신으로는 이 속도를 구현할 수 없습니다.

4. 개발 환경 통일

5명으로 구성된 팀에서 한 명은 macOS, 다른 한 명은 Windows, 또 다른 한 명은 Ubuntu를 사용한다고 해 보겠습니다. 사람마다 MySQL과 Node 버전이 달라 매일 서로 “네 환경에서는 실행돼?”라고 묻게 됩니다.

Docker 환경 이미지 하나를 마련하면 모두가 docker-compose up 명령 한 번으로 MySQL, Redis, Nginx를 함께 시작할 수 있습니다. 버전이 고정되고 환경이 통일되어 더는 환경 문제로 씨름할 필요가 없습니다.

가상 머신을 반드시 선택해야 하는 4가지 상황

1. 전통적인 모놀리식 애플리케이션

회사에 10년 된 ERP 시스템이 있다고 가정해 보겠습니다. Java 6와 Oracle 데이터베이스를 사용하고 CentOS 6에서 실행되는 데다 코드가 수십만 줄이라 수정하기도 어렵고 손대기도 두렵습니다.

이런 경우에는 Docker로 옮기려고 애쓰지 마세요. 가상 머신에서 그대로 실행하는 편이 낫습니다. 무엇보다 안정성이 중요하며, 컨테이너화 전환에는 비용과 위험이 너무 큽니다.

2. 여러 운영체제가 필요한 경우

Windows 애플리케이션과 Linux 애플리케이션을 동시에 실행해야 할 수 있습니다. 예를 들어 테스트 팀이 Windows Server에서 .NET 프로그램을, Linux에서 Java 서비스를 실행해야 하는 경우입니다.

Docker는 적합하지 않습니다. 주로 Linux 컨테이너를 실행하며 Windows 컨테이너도 있지만 지원 수준이 매우 낮습니다. 한 대에는 Windows를, 다른 한 대에는 Linux를 설치한 가상 머신을 사용해야 합니다.

Mac에서 Windows 소프트웨어를 테스트해야 하는 개발자도 VMware나 VirtualBox로 Windows 가상 머신을 실행해야 합니다.

3. 강력한 격리가 필요한 경우

클라우드 사업자나 멀티테넌트 SaaS 플랫폼은 고객 사이를 완전히 격리해야 합니다. 고객마다 독립된 커널을 가진 VM을 하나씩 제공하세요.

금융 업계나 정부 프로젝트는 규정 준수 요구 사항이 엄격하며 감사 과정에서 강력한 격리를 증명해야 합니다. Docker의 공유 커널 방식으로는 감사를 통과하지 못할 수 있습니다.

4. 완전한 운영체제 환경을 재현해야 하는 경우

임베디드 시스템의 드라이버를 개발하면서 특정 커널 버전과 하드웨어 환경이 필요할 수 있습니다. 또는 운영체제와 관련된 저수준 개발을 할 수도 있습니다.

Docker는 호스트 커널을 공유하므로 이런 상황에 맞지 않습니다. 가상 머신은 하드웨어와 커널을 완전하게 재현할 수 있어 필요한 환경을 자유롭게 설치할 수 있습니다.

혼합 사용이 가장 현실적인 선택입니다

실제로 대부분의 회사는 두 기술을 함께 사용합니다.

저희 회사를 예로 들면 다음과 같습니다.

• 핵심 거래 시스템(5년 동안 안정적으로 운영): 가상 머신
• 새로 개발한 API 게이트웨이와 마이크로서비스: Docker + Kubernetes
• 개발 및 테스트 환경: 모두 Docker
• Windows 사무용 시스템 테스트: VMware 가상 머신

이렇게 하면 핵심 비즈니스의 안정성을 보장하면서 컨테이너 기술의 민첩성도 누릴 수 있습니다.

한눈에 보는 의사결정 트리

애플리케이션이 신규 개발인가요?
├─ 예 → 마이크로서비스 아키텍처인가요?
│   ├─ 예 → Docker 선택 ✅
│   └─ 아니요 → 배포를 자주 업데이트해야 하나요?
│       ├─ 예 → Docker 선택 ✅
│       └─ 아니요 → 다른 요인을 기준으로 결정
└─ 아니요(레거시 시스템) → 특정 OS/커널이 필요한가요?
    ├─ 예 → 가상 머신 선택 ✅
    └─ 아니요 → 강력한 격리가 필요한가요?
        ├─ 예 → 가상 머신 선택 ✅
        └─ 아니요 → 컨테이너화 전환 가능 → Docker 선택 ✅

이 흐름도를 따라가면 대부분의 경우 결정을 내릴 수 있습니다.

실제 사례—다른 팀은 어떻게 선택했을까요?

이론만으로는 부족하니 실제 상황 몇 가지를 살펴보겠습니다.

사례 1: 스타트업의 All-in Docker

한 친구가 다니는 SaaS 스타트업은 팀원이 15명입니다. 처음에는 서버 예산이 부족해 Alibaba Cloud ECS(4코어 8GB) 3대로 십여 개의 서비스를 실행해야 했습니다.

가상 머신을 사용했다면 물리 서버 3대에서 VM을 최대 15개만 실행해도 리소스가 바닥났을 것입니다. 이 회사는 곧바로 Docker + Kubernetes를 도입했고, 서버 3대에서 컨테이너 60개 이상을 실행하면서도 여유가 있었습니다.

개발 환경도 통일했습니다. 신규 입사자는 첫날 코드를 clone하고 docker-compose up을 실행해 5분 만에 환경을 구성할 수 있었습니다. 예전에는 가상 머신으로 환경을 설정하는 데 반나절이 걸렸습니다.

비용은 얼마나 절약했을까요? 회사의 추산에 따르면 가상 머신을 사용했다면 서버 10대를 구매해야 했습니다. 지금은 3대면 충분해 매년 서버 비용 수만 위안을 절약하고 있습니다.

Alibaba Cloud - 개발자 클라우드 1순위, Lighthouse 서버 15% 할인

15% 할인 받기 →광고

스타트업에는 말 그대로 현금과 같은 가치입니다.

사례 2: 전통 기업의 점진적인 전환

한 제조 회사는 SAP와 Oracle 데이터베이스로 구성된 핵심 ERP 시스템을 15년 동안 사용했습니다. 이 시스템은 오래된 IBM 서버 여러 대의 가상 머신에서 실행되고 있어 손댈 수 없는 상태였습니다.

그러나 지난해 디지털 전환을 추진하며 새로운 공급망 시스템을 개발해야 했습니다. IT 책임자는 현명하게도 핵심 ERP는 그대로 두고 신규 비즈니스만 Docker 마이크로서비스 아키텍처로 구성했습니다.

현재 아키텍처는 다음과 같습니다.

• 기존 ERP: 가상 머신, 서버 5대, 매우 안정적으로 운영
• 신규 공급망 시스템: Docker + K8s, 서버 3대, 컨테이너 70개 이상
• 두 시스템은 API 게이트웨이를 통해 연동

수백 명이 이 시스템으로 업무를 처리하는 만큼 핵심 시스템의 안정성을 지키면서도 신규 비즈니스에는 민첩성을 확보했습니다. 전형적인 ‘바이모달 IT’ 사례입니다.

사례 3: 클라우드 사업자의 보안 격리

한 소규모 클라우드 사업자는 기업에 가상 호스팅 서비스를 제공하며 고객마다 독립적인 실행 환경을 마련해야 했습니다.

처음에는 비용이 저렴한 Docker를 고려했습니다. 하지만 기술 책임자는 고객 사이에 강력한 격리가 필요하다는 이유로 반대했습니다. 고객 한 곳의 웹사이트가 해킹되더라도 다른 고객에게 영향을 줘서는 안 됩니다. Docker는 커널을 공유하므로 위험이 너무 컸습니다.

결국 KVM 가상 머신을 선택했습니다. 고객마다 독립된 커널을 가진 VM 하나를 제공했습니다. 비용은 더 들지만 보안을 보장할 수 있고, 고객도 계약서에 명시된 ‘독립 가상 서버’가 컨테이너가 아니라는 점을 인정했습니다.

보안을 비용보다 우선한 전형적인 사례입니다.

사례 4: 하이브리드 클라우드 아키텍처의 모범 사례

게임 사업을 하는 한 인터넷 기업은 데이터 보안 요구 사항 때문에 핵심 데이터베이스를 자체 데이터 센터에 두어야 했지만, 게임 서버는 이벤트 기간의 급격한 트래픽 증가에 맞춰 탄력적으로 확장해야 했습니다.

이 회사의 구성은 다음과 같습니다.

• 자체 데이터 센터: MySQL 주 데이터베이스를 가상 머신에서 실행, 안정성을 최우선으로 고려
• 클라우드: 게임 서비스를 모두 Docker로 전환하고 K8s에 연결해 트래픽 급증 시 자동 확장
• 이벤트 기간: 컨테이너 10개에서 100개로 10분 만에 확장
• 이벤트 종료: 컨테이너 20개로 자동 축소해 비용 절감

이 아키텍처는 안정성, 탄력성, 비용의 균형을 맞췄습니다. 핵심에는 VM을, 가장자리에는 Docker를 사용해 각 기술의 장점을 취했습니다.

이 사례들을 보면 절대적인 정답과 오답이 있는 것이 아니라 상황에 맞는 선택이 있을 뿐이라는 사실을 알 수 있습니다.

결론

Docker와 가상 머신은 양자택일의 대상이 아니라 서로 다른 장점을 가진 도구입니다.

신규 프로젝트를 개발하고 빠른 반복과 일관된 환경을 원한다면 Docker가 더 좋은 선택입니다. 시작이 빠르고 리소스를 적게 사용하며 마이크로서비스 아키텍처와 DevOps 프로세스에 잘 맞습니다. 저도 새 프로젝트는 대부분 Docker로 시작하는데 정말 편리합니다.

레거시 시스템을 유지 관리하거나, 강력한 격리가 필요하거나, 여러 운영체제를 실행해야 한다면 가상 머신이 더 적합합니다. 안정성과 보안을 보장하므로 필요한 상황에서는 망설이지 말고 사용하세요.

실제로 많은 회사가 두 기술을 함께 사용합니다. 핵심 시스템은 안정성을 위해 가상 머신을, 주변 서비스는 속도를 위해 Docker를 사용합니다. 원칙에만 얽매일 필요는 없습니다. 실용적인 선택이 가장 중요합니다.

마지막으로 세 가지 실행 방안을 제안합니다.

1. 프로젝트 평가하기: 앞의 의사결정 트리를 기준으로 5분 동안 현재 프로젝트에 무엇이 적합한지 판단하세요.
2. 작은 범위에서 시험하기: Docker를 사용하기로 했다면 처음부터 모든 것을 컨테이너화하지 말고 비핵심 서비스부터 시작하세요.
3. 꾸준히 학습하기: 컨테이너 기술은 빠르게 발전하고 있습니다. Kubernetes, Serverless, 엣지 컴퓨팅도 계속 진화하므로 호기심을 유지하세요.

Docker에 관심이 있다면 다음 글에서는 《Docker 입문 실습: 설치부터 첫 번째 컨테이너까지》를 다룰 예정입니다. 직접 따라 하며 시작할 수 있도록 안내하겠습니다.

도구를 제대로 선택하면 적은 노력으로 더 큰 결과를 얻을 수 있습니다. 이 글이 올바른 선택에 도움이 되기를 바랍니다.