환경 문제, 그리고 두 가지 해결책
애플리케이션이 정상적으로 실행되기 위해서는 코드뿐만 아니라 특정 버전의 운영체제(OS), 라이브러리, 각종 설정 파일 등 수많은 '종속성'들이 필요하다. 개발 환경과 운영 환경의 미세한 차이가 애플리케이션의 오작동을 유발하는 것이다.
이 고질적인 문제를 해결하기 위해 두 가지 혁신적인 기술이 등장했다. 첫 번째 해결책은 가상 머신(Virtual Machine, VM)이다. VM은 운영체제를 포함한 컴퓨터 전체를 하나의 파일로 묶어버리는 획기적인 기술로, 하드웨어 자원의 효율성을 극대화하며 IT 인프라의 풍경을 바꾸었다.
그리고 시간이 흘러, 더 빠르고 민첩한 개발 환경에 대한 요구가 커지면서 두 번째 해결책인 컨테이너(Container)가 등장했다. 컨테이너는 OS 전체가 아닌, 애플리케이션과 그에 필요한 종속성만을 가볍게 포장하는 새로운 접근 방식을 제시했다.
많은 사람들이 컨테이너를 그저 '가벼운 VM' 정도로 오해하곤 한다. 하지만 이는 두 기술의 본질을 놓치는 것이다. 이 글의 핵심 목표는 바로 그 오해를 바로잡는 것이다. 컨테이너는 VM의 축소판이 아니며, 두 기술은 근본적으로 다른 아키텍처와 철학을 가지고 있다. 이 차이를 이해하는 것은 현대 IT 기술을 제대로 파악하기 위한 첫걸음이다. 기술의 발전은 단순히 더 효율적인 인프라를 구축하는 것에서, 더 빠르고 안정적으로 소프트웨어를 배포하는 방향으로 그 무게 중심을 옮겨왔다. VM이 전자의 시대정신을 대표한다면, 컨테이너는 후자의 요구에 부응하며 탄생한 기술이다.
가상 머신(VM)은 어떻게 작동하는가?
컨테이너를 이해하기에 앞서, 그 선배 격인 가상 머신(VM)의 작동 원리를 명확히 알아야 한다. VM은 오늘날 클라우드 컴퓨팅의 기반을 이루는 핵심 기술이다.
가상화란 무엇인가?
가상화는 소프트웨어를 사용해 물리적인 컴퓨터 한 대를 마치 여러 대의 독립된 컴퓨터처럼 사용할 수 있게 만드는 기술이다. 이 기술 덕분에 하나의 고성능 서버 위에서 각기 다른 운영체제를 가진 여러 가상 컴퓨터를 동시에 실행할 수 있게 되었고, 이는 과거에 단일 애플리케이션만 실행하며 자원을 낭비하던 물리 서버의 활용도를 극적으로 끌어올렸다.
마법의 배후, 하이퍼바이저
이러한 가상화의 '마법'을 가능하게 하는 것이 바로 하이퍼바이저(Hypervisor)라는 특별한 소프트웨어이다. 하이퍼바이저는 물리적 하드웨어와 그 위에서 실행되는 가상 머신들 사이에 위치하는 추상화 계층이다. 하이퍼바이저의 역할은 물리 서버의 CPU, 메모리, 스토리지 같은 자원들을 각 VM에 적절히 나누어주고, 각각의 VM이 마치 자신만의 전용 하드웨어를 가지고 있는 것처럼 착각하게 만드는 것이다.
[출처: https://www.dnsstuff.com/what-is-hypervisor]
비유로 이해하기: 아파트
VM의 개념을 더 쉽게 이해하기 위해 '아파트'에 비유해 보겠다.
- 물리 서버: 전기, 수도 등 기반 시설이 갖춰진 '땅'이다.
- 하이퍼바이저: 그 땅 위에 거대한 '아파트 건물'을 짓는 설계자이자 건설사이다.
- 가상 머신(VM): 아파트 건물의 각 '세대'이다. 여기서 가장 중요한 점은, 각 세대가 완벽히 독립된 하나의 '집'이라는 사실이다. 모든 세대는 각자의 현관문, 주방, 화장실, 배관, 전기 설비를 갖추고 있다. 이는 VM이 게스트 운영체제(Guest OS)를 포함한 완전한 컴퓨터 시스템을 갖추고 있음을 의미한다.
이 비유는 VM의 장단점을 명확하게 보여준다. 옆집의 배관 문제(한 VM의 오류)가 우리 집에 영향을 주지 않는 것처럼, VM은 매우 강력한 격리 수준을 자랑한다. 하지만 모든 세대가 필수 인프라를 중복으로 설치해야 하므로 자원 소모가 크고 "무겁다"는 단점도 동시에 설명해 준다.
가상 머신의 핵심 특징
- 장점
- 격리와 보안: 각 VM은 자신만의 운영체제를 가진 완전한 독립 시스템이므로, 하나의 VM에서 발생한 충돌이나 보안 침해가 다른 VM에 영향을 미치지 않는다. 이는 하드웨어 수준의 격리이다.
- 운영체제 유연성: 하이퍼바이저 위에서는 리눅스 VM과 윈도우 VM을 나란히 실행하는 것이 가능하다. 각자 완전한 OS를 가지고 있기 때문이다.
- 단점
- 무거운 리소스 사용량: 각 VM은 완전한 OS 복사본을 필요로 하며, 이는 수 기가바이트(GB)에 달하는 디스크 공간과 상당한 양의 메모리, CPU 자원을 소모한다.
- 느린 시작 시간: VM을 부팅하는 것은 실제 컴퓨터를 켜는 것과 같다. 전체 운영체제를 로드해야 하므로 시작하는 데 수 분이 걸릴 수 있다.
[출처: https://cloud.theodo.com/en/blog/container-docker-oci]
컨테이너는 무엇이 다른가?
VM이 IT 인프라의 효율성을 혁신했다면, 컨테이너는 소프트웨어 개발과 배포의 속도와 안정성을 혁신하고 있다. 이제 컨테이너의 세계로 들어가 보겠다.
컨테이너란 무엇인가?
컨테이너는 애플리케이션 코드를 그 실행에 필요한 모든 종속성(라이브러리, 시스템 도구, 런타임 등)과 함께 패키징하는 표준화된 소프트웨어 단위이다. 이를 통해 애플리케이션이 개발 환경에서 테스트, 운영 환경으로 이동할 때에도 빠르고 안정적으로 동일하게 실행되도록 보장한다. 즉, 컨테이너는 애플리케이션을 실제 구동 환경으로부터 추상화하는 논리적인 포장 기술이다.
컨테이너 엔진 (예: 도커)
컨테이너는 컨테이너 엔진(가장 유명한 예로 도커(Docker)가 있다)에 의해 관리된다. 컨테이너 엔진은 호스트 운영체제 위에서 컨테이너를 생성, 실행, 중지하는 등 전체 생명주기를 관리하는 역할을 수행한다.
[출처: https://cloud.theodo.com/en/blog/container-docker-oci]
비유로 이해하기: 하숙집
컨테이너를 아파트와 대조되는 '하숙집'에 비유해 보겠다.
- 물리 서버 + 호스트 OS: 이미 모든 기능이 완비된 하나의 커다란 '집'이다. 이 집에는 모두가 함께 사용하는 주방, 화장실, 그리고 공동의 배관 및 전기 시스템(호스트 OS와 그 커널을 의미)이 갖춰져 있다.
- 컨테이너: 그 집 안에 있는 각각의 '개인 방'이다. 하숙집에 새로 들어오는 사람은 자신만의 주방이나 화장실을 만들 필요가 없다. 그저 자신의 개인 짐(애플리케이션과 그 라이_브러리/바이너리)만 가지고 들어와 집의 공용 인프라를 사용하면 된다.
이 비유는 컨테이너가 왜 그렇게 가볍고 빠른지를 직관적으로 설명한다. 모든 입주자(애플리케이션)를 위해 집 전체를 새로 짓는 것이 아니라, 이미 있는 집의 방 하나만 꾸미면 되기 때문이다. 각자의 방은 독립된 공간으로 격리되지만, 모두가 집이라는 하나의 기반(호스트 OS 커널)을 공유한다.
컨테이너의 핵심 특징
- 장점
- 가벼움과 속도: 컨테이너는 완전한 OS를 포함하지 않기 때문에 이미지 크기가 기가바이트가 아닌 메가바이트(MB) 단위로 매우 작다. 부팅할 OS가 없으므로 사실상 호스트 OS 위의 격리된 프로세스로서 수 초 내에 시작된다.
- 뛰어난 이식성: 컨테이너 이미지는 표준화된 패키지이다. 개발자 노트북에서 만들어진 컨테이너는 컨테이너 엔진이 설치된 다른 어떤 환경(물리 서버, 가상 머신, 온프레미스, 클라우드)에서도 동일하게 실행된다. 이것이 바로 '한 번 빌드해서, 어디서든 실행한다(build once, run anywhere)'는 약속의 실현이다.
- 높은 효율성과 집적도: 차지하는 공간이 작기 때문에 하나의 서버에 VM보다 훨씬 더 많은 수의 컨테이너를 실행할 수 있다. 이는 자원 활용률을 극대화한다.
- 단점
- 상대적으로 약한 격리: 한 호스트의 모든 컨테이너는 동일한 OS 커널을 공유한다. 만약 호스트 커널에 심각한 보안 취약점이 발견된다면, 이론적으로 모든 컨테이너가 위험에 처할 수 있다. 격리 수준이 하드웨어 수준이 아닌 프로세스 수준이기 때문이다.
- OS 종속성: 호스트의 커널을 공유한다는 것은 곧 OS에 종속된다는 의미이다. 특별한 기술 없이는 리눅스 호스트에서 윈도우 컨테이너를 직접 실행할 수 없으며, 그 반대도 마찬가지이다.
왜 컨테이너는 가상화가 아닌가?
많은 사람들이 컨테이너를 'OS 수준 가상화'라고 부르기도 하지만, 왜 컨테이너는 VM이 제공하는 전통적인 의미의 '가상화'와는 근본적으로 다른 것이다.
하드웨어 가상화 vs. OS 가상화
결론부터 명확히 하자면, 가상 머신은 하드웨어를 가상화하고, 컨테이너는 운영체제를 가상화한다. 이는 정도의 차이가 아니라 종류의 차이이다.
-
VM 스택: 하드웨어 → 하이퍼바이저 → [게스트 OS 1 + 앱 1], [게스트 OS 2 + 앱 2], ...
각 VM은 무겁지만 완벽히 독립된 개체이다. 하이퍼바이저의 임무는 게스트 OS를 속여서 마치 자신만의 물리적 머신을 가지고 있다고 믿게 만드는 것이다. -
컨테이너 스택: 하드웨어 → 호스트 OS (커널 포함) → 컨테이너 엔진 → [앱 1], [앱 2]...
애플리케이션들은 호스트 OS의 커널 위에서 직접 격리된 프로세스로 실행된다. 컨테이너 엔진의 임무는 이 격리 상태를 만들고 유지하는 것이다.
'커널 공유'
두 기술의 가장 근본적인 차이는 바로 '커널 공유' 여부이다.
먼저 OS 커널(Kernel)이 무엇인지 간단히 짚고 가겠다. 커널은 운영체제의 '뇌' 또는 '핵심'이다. CPU, 메모리, 주변 장치 등 하드웨어를 관리하고 다른 모든 프로그램이 실행될 수 있도록 중재하는 가장 기본적인 소프트웨어 계층이다.
[출처: https://ko.wikipedia.org/wiki/%EC%BB%A4%EB%84%90_%28%EC%BB%B4%ED%93%A8%ED%8C%85%29]
여기서 중요한 점은 "컨테이너는 호스트 OS를 공유하는 게 아니라 호스트 커널을 공유한다"는 것이다. 이는 매우 다른 이야기이다. 컨테이너는 OS의 모든 구성요소(시스템 라이브러리, 유틸리티 등)를 통째로 공유하는 것이 아니라, 오직 핵심 기능인 커널의 스케줄링 및 관리 기능에만 접근한다.
[출처: https://www.redhat.com/ko/blog/architecting-containers-part-1-why-understanding-user-space-vs-kernel-space-matters]
이것이 어떻게 가능한 것이다. 바로 리눅스 커널에 내장된 두 가지 핵심 기술 덕분이다.
- 네임스페이스 (Namespaces): 격리를 제공한다. 네임스페이스는 특정 프로세스가 자신만의 독립된 시스템 자원(프로세스 ID, 네트워크 인터페이스, 파일 시스템 등)을 가지고 있는 것처럼 보이게 만든다. 마치 프로세스에 눈가리개를 씌워 자기 자신만의 작은 세상만 볼 수 있도록 하는 것과 같다.
- 컨트롤 그룹 (cgroups): 자원 제한 및 관리를 담당한다. 컨트롤 그룹은 특정 컨테이너가 CPU나 메모리 같은 시스템 자원을 독차지하지 못하도록 제한하여 호스트와 다른 컨테이너들을 보호한다. 각 프로세스에 자원 사용 예산을 할당하는 것과 같다.
[출처: https://medium.com/@mrdevsecops/namespace-vs-cgroup-60c832c6b8c8]
결론적으로, VM은 물리적 머신 전체를 에뮬레이션하는 가상 컴퓨터인 반면, 컨테이너는 호스트 OS의 커널 위에서 네임스페이스와 cgroups를 통해 격리된 프로세스에 불과하다. 따라서 컨테이너는 '작은 VM'이 아니라, 애플리케이션을 격리하고 패키징하는 근본적으로 다르고 훨씬 효율적인 접근 방식이다.
이러한 '커널 공유'라는 아키텍처적 선택은 컨테이너의 가장 큰 장점(속도, 효율성)과 가장 주된 약점(공유된 보안 운명)을 동시에 낳는 양날의 검이다. 커널을 포함하거나 부팅할 필요가 없기 때문에 컨테이너는 분 단위가 아닌 초 단위로 시작하고, 기가바이트가 아닌 메가바이트 단위의 크기를 가질 수 있다. 하지만 바로 그 공유된 커널이 단일 실패 지점이자 공격 표면이 되기도 한다. 커널의 취약점이 악용되면 하나의 컨테이너를 통해 호스트 전체와 다른 모든 컨테이너가 장악될 수 있는 위험이 존재한다. 이 본질적인 트레이드오프는 기술 선택에 있어 단순히 '어느 것이 더 좋은가'가 아니라, '어떤 사용 사례에 어떤 위험/보상 프로필이 더 적합한가'를 고민하게 만든다.
언제 무엇을 사용해야 할까?
이제 두 기술의 차이점을 명확히 이해했다. 실제 상황에서 어떤 기술을 선택해야 할지 구체적인 가이드라인을 살펴보겠다.
가상 머신(VM)을 선택해야 할 때
다음과 같은 상황에서는 VM이 더 적합한 선택이다:
- 최고 수준의 보안과 격리가 필요할 때: 여러 고객의 애플리케이션을 동시에 호스팅하는 클라우드 서비스 제공업체처럼, 각 사용자 간의 완벽한 분리가 필수적인 경우이다. VM의 강력한 하드웨어 경계는 타협할 수 없는 장점이다. 민감한 환자 데이터를 다루는 의료 시스템 역시 좋은 예시이다.
- 하나의 서버에서 여러 종류의 운영체제를 실행해야 할 때: 리눅스 기반의 최신 인프라 위에서 오래된 윈도우 애플리케이션을 실행해야 하는 경우처럼, 서로 다른 OS 환경이 필요하다면 VM이 유일한 해답이다.
- 모놀리식(Monolithic) 레거시 애플리케이션을 다룰 때: 거대하고 각 기능이 긴밀하게 결합된 기존 애플리케이션들은 컨테이너로 분해하기 어려운 경우가 많다. 이런 경우, 애플리케이션을 있는 그대로 VM으로 옮기는 '리프트 앤 시프트(lift and shift)' 방식이 더 현실적이다.
컨테이너를 선택해야 할 때
반면, 다음과 같은 현대적인 개발 환경에서는 컨테이너가 압도적인 우위를 보인다:
- 마이크로서비스 아키텍처(MSA)로 클라우드 네이티브 애플리케이션을 구축할 때: 작고 독립적인 서비스들로 애플리케이션을 구성하는 MSA에서, 각 서비스를 패키징하고 배포하는 데 컨테이너는 완벽한 도구이다.
- 개발 수명주기의 속도와 효율성을 최우선으로 할 때: 데브옵스(DevOps) 및 CI/CD(지속적 통합/지속적 배포) 파이프라인에서 빌드와 테스트를 위해 수시로 환경을 만들고 없애야 할 때, 수 초 만에 가능한 컨테이너는 게임 체인저이다.
- 여러 클라우드와 온프레미스 환경 간의 높은 이식성이 필요할 때: '한 번 빌드해서 어디서든 실행'되는 컨테이너의 특성은 하이브리드 및 멀티 클라우드 전략을 단순화하는 핵심 요소이다.
한눈에 보는 비교표
두 기술의 차이점을 한눈에 파악할 수 있도록 표로 정리했다.
| 기능 | 가상 머신 (VM) | 컨테이너 |
|---|---|---|
| 핵심 개념 | 하드웨어 에뮬레이션 | 격리된 프로세스 |
| 가상화 수준 | 하드웨어 수준 | 운영체제 수준 |
| 핵심 기술 | 하이퍼바이저 | 컨테이너 엔진 & OS 커널 기능 |
| 운영체제(OS) | 자체 게스트 OS 포함한다. | 호스트 OS 커널 공유한다. |
| 크기 | 매우 크다. (수 GB) | 매우 작다. (수 MB) |
| 시작 시간 | 느리다. (수 분) | 매우 빠르다. (수 초) |
| 리소스 효율성 | 낮다. (높은 오버헤드) | 높다. (낮은 오버헤드) |
| 격리 수준 | 강하다. (하드웨어 경계) | 상대적으로 약하다. (프로세스 경계) |
| 이식성 | 제한적이다. (하이퍼바이저 종속성) | 매우 높다. (환경에 독립적) |
| 주요 사용 사례 | 레거시 앱, 멀티 OS 환경, 높은 보안 요구 | 마이크로서비스, CI/CD, 클라우드 네이티브 앱 |
VM과 컨테이너의 시너지
VM과 컨테이너의 선택이 항상 양자택일인 것은 아니다. 실제로 기업 환경과 클라우드 컴퓨팅에서 가장 강력하고 보편적인 패턴 중 하나는 이 둘을 결합하여 사용하는 것이다.
이 하이브리드 아키텍처는 다음과 같이 구성된다: 물리 서버 위에 하이퍼바이저가 여러 VM을 호스팅하고, 각각의 VM 내부에 컨테이너 엔진을 설치하여 그 위에서 다수의 컨테이너를 실행하는 방식이다.
이 접근 방식은 '두 세계의 장점'을 모두 취할 수 있게 해준다.
- 보안: VM이 제공하는 강력한 하드웨어 수준의 격리가 견고한 보안 경계 역할을 한다. 만약 하나의 컨테이너가 침해되더라도 공격자는 여전히 VM이라는 샌드박스 안에 갇히게 되어, 다른 VM이나 호스트 시스템에 영향을 미치기 어렵다.
- 이식성과 민첩성: 그 안전한 VM 내부에서는 컨테이너의 모든 장점을 그대로 누릴 수 있다. 빠른 배포, 손쉬운 확장, 그리고 애플리케이션의 이식성 높은 워크플로우를 모두 활용할 수 있다.
구글 쿠버네티스 엔진(GKE)이나 아마존 EKS와 같은 주요 클라우드 제공업체의 관리형 쿠버네티스 서비스가 바로 이런 방식으로 작동하는 경우가 많다. 쿠버네티스 클러스터의 '노드(Node)'는 실제로는 VM이며, 우리의 애플리케이션 컨테이너들은 이 노드들 위에서 실행된다.
