도커, 하이퍼바이저 없는 격리가 표준이 되기까지

가상머신은 하이퍼바이저 위에 게스트 OS를 통째로 올려야 해서 기동에 수분이 걸린다. 도커는 그 하이퍼바이저 자체를 거치지 않는다. 리눅스 컨테이너(Linux Container) 기술을 표준화한 오픈소스 플랫폼으로서, 호스트 커널을 그대로 공유한 채 애플리케이션을 격리 실행하는 게 도커의 본질이다. LXC에서 출발했지만 지금은 OCI(Open Container Initiative) 표준과 runc 런타임을 기반으로 동작하며, 이 표준화 덕분에 개발-운영 환경 일관성과 높은 이식성을 확보해 마이크로서비스·CI/CD·멀티클라우드에 최적화된 배포 방식을 만든다.

하이퍼바이저를 빼면 격리는 어떻게 되는가

컨테이너는 호스트 리눅스 커널을 공유하고, 네임스페이스(namespace)와 cgroups로 격리와 리소스 제어를 수행한다. 파일시스템은 Union/OverlayFS(주로 overlay2) 기반으로 레이어를 합성한다. 하이퍼바이저가 없다는 것은 VM 대비 오버헤드와 부팅 시간이 작고 같은 호스트에서 컨테이너 밀도를 높일 수 있다는 뜻이지만, Windows·Mac에서는 경량 VM을 통해 리눅스 커널을 대신 제공해야 한다는 예외가 남는다. 이 위에서 OCI Image/Runtime 표준을 채택하고 containerd + runc 체계를 쓰며, Dockerfile로 이미지를 선언적으로 빌드해 레지스트리에 저장·배포한다.

계층으로 나뉜 이유는 안정성이다

Docker Engine은 dockerd → containerd → runc로 이어지는 계층 구조를 쓴다. 런타임을 분리해 둔 덕분에 한 계층을 교체하거나 업그레이드해도 나머지 계층의 안정성·유지보수성이 흔들리지 않는다. 격리·자원 관리는 Control Group(cgroups)·Namespace·Capabilities로 구현된다.

이미지는 불변(Immutable)이며 Copy-on-Write 레이어 구조를 활용해 각 레이어가 변경사항만 저장하고, 빌드 캐시로 반복 빌드를 가속한다. Dockerfile 기반의 선언적 빌드가 재현 가능한 환경을 만드는 지점이 여기다.

네트워킹은 Bridge·Host·Overlay·Macvlan 등 드라이버를 제공하고, 포트 매핑과 서비스 디스커버리를 지원한다. CNM(Container Network Model) 기반이라 오케스트레이터와 연동이 쉽다.

레지스트리가 무결성을 보장하는 방식

Docker Hub, Private Registry, ECR/GCR/ACR 등을 지원하며, 콘텐츠 주소 기반(digest)으로 무결성을 확보한다. 이미지 서명(Notary), 취약점 스캔과 정책 기반 배포 파이프라인을 여기에 얹을 수 있다는 게 단순히 이미지를 어딘가에 저장하는 것 이상의 의미를 가진다 — 배포되는 이미지가 빌드 시점과 동일하다는 것을 암호학적으로 보장하는 계층이기 때문이다.

오케스트레이션 연계도 이 표준화 위에서 이뤄진다. Docker Compose로 로컬 멀티컨테이너 구성을 관리하고, Swarm·Kubernetes와 연동해 확장·자가치유·롤링 업데이트를 구현한다.

VM과 비교하면 밀도와 격리가 반비례한다

항목	컨테이너	가상머신(VM)
성능	커널 공유로 오버헤드 낮음, 기동 수초 이내	하이퍼바이저/게스트 OS 오버헤드, 기동 수분
확장성	고밀도 배치 용이, 수십~수백 Pod/노드	밀도 제한 상대적으로 큼
일관성	이미지 불변성으로 환경 재현성 우수	골든 이미지 관리 부담, 드리프트 위험
안정성	프로세스 격리 기반, 커널 이슈의 공진 가능성	강한 경계(게스트 OS)로 격리성 높음
운영 편의	이미지/레지스트리/CI 통합 용이	패치/에이전트/OS 관리 부담 큼

실제 활용 사례

CI/CD 파이프라인 자동화 — 코드 커밋 → Docker Build(스캔 포함) → 레지스트리 푸시 → 스테이징 배포 → Canary/롤링 프로덕션 배포로 이어지고, 테스트 환경을 재현하고 배포 실패 시 이미지 태그 롤백을 간소화한다. 마이크로서비스 표준 런타임 — 서비스별 독립 이미지와 리소스 제한을 두고 공통 베이스 이미지·런타임 버전을 표준화해 운영 복잡도를 줄인다. 데이터/배치 처리 — 이벤트 드리븐 단발성 워커 컨테이너로 탄력적으로 처리하고 작업 종료 시 자동 회수로 비용을 최적화한다. 레거시 포장(컨테이너라이제이션) — 종속 라이브러리를 포함한 이미지화로 환경 충돌을 없애고 점진적 전환으로 다운타임을 최소화한다.

구현 절차: 최소 이미지에서 배포까지

전제조건은 Linux Kernel 5.10+, Docker Engine 24+, BuildKit 활성화(DOCKER_BUILDKIT=1)다.

# syntax=docker/dockerfile:1.6
FROM gcr.io/distroless/static-debian12 AS runtime
COPY app /app
USER 65532:65532
EXPOSE 8080
ENTRYPOINT ["/app"]

빌드·실행 시 자원 제한, 읽기전용 루트fs, 비루트 사용자를 함께 건다.

docker build -t demo:web .
docker run -d --name web \
  --read-only --pids-limit=256 --cpus=0.5 --memory=256m \
  -p 8080:8080 --cap-drop=ALL --security-opt no-new-privileges \
  demo:web

네트워크·볼륨 구성도 같은 방식으로 선언한다.

docker network create --driver bridge app-net
docker volume create app-data
docker run -d --name db --network app-net -v app-data:/var/lib/db db:image

배포 파이프라인이 실패를 다루는 방식

⤢✕

입력→처리→출력의 각 단계에 실패 시 중단·롤백 정책이 걸려 있다. 헬스체크가 실패하면 트랜잭션적 배포 단위(ReplicaSet·버전 태그) 기준으로 되돌린다.

이런 파이프라인이 만드는 효과는 수치로도 나타난다. 노드당 서비스 밀도는 워크로드 성격에 따라 다르지만 VM 대비 2~~10배까지 늘고, CI 빌드 시간은 레이어 캐시 덕분에 30~~70% 단축된다. 환경 일관성과 이식성이 늘어난 만큼 장애 원인 추적이 쉬워지고, 이미지 기반 배포는 변경 관리와 감사 추적도 강화한다.

보안은 최소 이미지에서 시작해서 런타임까지 이어진다

최소 베이스 이미지(scratch/distroless/alpine)를 쓰고 이미지 Digest를 고정하는 게 첫 단추다. 런타임은 비루트 사용자, read-only rootfs, Capabilities 제거, seccomp/AppArmor/SELinux 프로파일로 경량화하고, 리소스 한도(cpus, memory, pids)와 네트워크 분리(전용 bridge/overlay)를 함께 건다. 취약점 스캔으로 SBOM을 생성하고 Secrets 전용 스토어(KMS/Secrets Manager)와 연계하며, 상태 데이터는 볼륨이나 외부 스토리지로 분리해 백업·복구 절차를 명문화해야 한다.

다만 이 모든 조치에도 한계는 남는다. 커널을 공유하는 구조라 격리에는 원천적 한계가 있어 고보안 워크로드는 VM 샌드박스를 병행해야 한다. OverlayFS는 쓰기 성능에 제약이 있어 고IO 워크로드는 바인드 마운트나 로컬 볼륨 설계가 따로 필요하고, 장기 실행 상태풀 워크로드는 오케스트레이터와 스토리지 클래스 전략을 별도로 세워야 한다.