베어메탈 시대
처음엔 단순했습니다. 물리 서버 한 대에 OS를 설치하고, 그 위에 애플리케이션을 올렸습니다.
문제는 자원 낭비였습니다. CPU 사용률이 10%인 서버가 랙에 줄줄이 꽂혀 있고, 새 서비스를 띄우려면 서버를 구매해서 IDC에 입고하고 OS를 깔아야 했습니다. 수주가 걸리는 일이었죠.
하이퍼바이저의 등장
2000년대 초반, 하이퍼바이저가 게임을 바꿨습니다. 하나의 물리 서버 위에 여러 개의 가상 머신(VM)을 올릴 수 있게 된 겁니다.
- Type 1 (베어메탈형): 하드웨어 위에 직접 설치. VMware ESXi, Xen, KVM이 여기에 해당합니다. 프로덕션 환경의 표준.
- Type 2 (호스트형): 기존 OS 위에 설치. VirtualBox, VMware Workstation 같은 것들. 개발/테스트용.
VM 덕분에 서버 한 대로 여러 워크로드를 격리해서 돌릴 수 있게 되었고, 리소스 효율이 극적으로 올라갔습니다. 클라우드(AWS EC2, GCP Compute Engine)도 결국 이 기술 위에 세워졌습니다.
VM의 한계
하지만 VM에도 단점이 있었습니다:
- Guest OS를 통째로 띄우니 이미지가 수 GB 단위
- 부팅에 수십 초~수 분 소요
- OS마다 커널, 라이브러리, 패치를 각각 관리해야 함
- 같은 호스트에 VM 수십 개를 올리면 오버헤드가 무시 못할 수준
“애플리케이션 하나 띄우는 데 OS 전체가 필요한가?”라는 질문이 자연스럽게 나왔습니다.
컨테이너 혁명
컨테이너는 그 질문에 대한 답입니다. 호스트 커널을 공유하면서 프로세스 단위로 격리합니다. Linux의 cgroup과 namespace 기술이 핵심이고, 2013년 Docker가 이를 쉽게 쓸 수 있도록 포장하면서 대중화되었습니다.
# VM: OS 이미지 수 GB, 부팅 수십 초
# 컨테이너: 이미지 수십 MB, 시작 수 초
docker run -d --name my-app nginx:alpine커널을 공유하기 때문에 오버헤드가 거의 없고, 이미지가 가볍고, 시작이 빠릅니다.
세 시대 비교
| 항목 | 베어메탈 | 하이퍼바이저(VM) | 컨테이너 |
|---|---|---|---|
| 격리 수준 | 물리적 분리 | 하드웨어 수준 가상화 | 프로세스 수준 격리 |
| 시작 시간 | 수 분 (OS 설치 포함) | 수십 초~수 분 | 수 초 |
| 이미지 크기 | — | 수 GB | 수십~수백 MB |
| 리소스 효율 | 낮음 | 중간 | 높음 |
| 밀도 (서버당) | 1 워크로드 | 수십 VM | 수백 컨테이너 |
그래서 지금은
현재 프로덕션 인프라의 표준은 컨테이너 + 쿠버네티스 조합입니다. 그 위에 서비스 메시, GitOps, 옵저버빌리티 스택이 쌓이고 있고요.
그리고 다음 물결도 보이기 시작합니다:
- 서버리스 (Lambda, Cloud Run) — 컨테이너조차 의식하지 않는 추상화
- WebAssembly (Wasm) — 컨테이너보다 가볍고 빠른 샌드박스, 엣지 환경에서 주목
인프라의 방향은 항상 같았습니다. 더 가볍게, 더 빠르게, 더 많이 격리하면서 자원을 효율적으로 쓰는 것. 그 흐름을 이해하면 다음에 뭐가 오든 맥락이 잡힙니다.