VM과 컨테이너

서비스를 서버에 올리는 방식은 물리 서버 → 가상 머신(VM) → 컨테이너로 발전해 왔다. 한 서버에 여러 프로그램을 올리면 OS·라이브러리 버전이 충돌하고 포트가 겹치며, 피하려고 서버를 늘리면 자원이 남는다. 컨테이너는 실행 환경 전체를 이미지 하나로 묶어 어느 서버에서든 같은 방식으로 돌게 한다. 컨테이너는 가볍고 빠르게 늘리고 줄일 수 있어, MSA·오토 스케일링과 함께 쓰이는 현재의 기본 배포 단위가 되었다.

VM vs 컨테이너

크기와 시작 속도는 대략적인 규모이며, 이미지와 하이퍼바이저에 따라 크게 달라진다.

• 가상화로 보면 VM은 하드웨어를 가상화하는 하이퍼바이저 기반 가상화, 컨테이너는 커널 하나를 여러 격리 공간으로 나누는 운영체제 수준 가상화다. Docker는 후자에 속한다. Docker가 널리 채택된 이유는 격리 자체보다 이미지라는 배포 형식에 있다. 실행 환경을 통째로 담은 이미지를 레지스트리로 주고받아 「내 컴퓨터에서는 되는데」 문제를 없애고, 수 초 만에 뜨며, 같은 서버에 더 많이 올려 비용을 줄인다.
• 강한 격리가 필요할 때(믿을 수 없는 코드 실행, 보안 경계가 중요한 개발 환경)는 여전히 VM을 쓴다. 같은 커널을 쓰는 컨테이너끼리의 간섭을 막는 방법은 Docker 컨테이너 운영에 있다. 컨테이너가 커널을 공유하며 무엇으로 격리하는지(네임스페이스·cgroups)와 하이퍼바이저의 원리는 가상화와 하이퍼바이저에 있다.
• VM을 쓰는 가장 큰 이유는 서버 통합(server consolidation)이다. 대부분의 OS·앱은 물리 서버 자원의 일부만 쓰므로, 한 대에 여러 가상 서버를 올려 장비 사용률을 높이고 서버 구입을 줄인다. 하이퍼바이저(VMM)가 CPU·메모리·저장소를 풀로 보고 VM에 나눠 주며, VM은 수요에 따라 다른 호스트로 옮길 수도 있다. 격리돼 있어 새 앱 시험용이나 한 가지 용도 전용 환경으로도 쓴다.
• 컨테이너는 책임을 나눈다. 개발자는 앱 로직과 의존성을 이미지에 담는 데 집중하고, 운영은 그 이미지를 배포·관리하는 데 집중한다. 어디서나 같은 이미지가 돌아 이식성이 좋고, 환경 차이를 신경 쓰지 않아 개발 속도가 빨라진다.
• 실무에서는 둘을 함께 쓴다. 클라우드 VM(예: AWS EC2) 위에 여러 컨테이너를 올리는 식이다.

흔한 오해와 도입 전제

도입 전에 갖출 것은 최소 권한 접근(키 로그인, 방화벽), 복구해 본 오프사이트 백업, 자동화된 구성·배포, 핵심 서비스 모니터링이다. 이것 없이 컨테이너부터 올리면 운영 위험만 커진다. 도입의 이득은 이식성(환경 차이를 설정 변수 몇 개로 줄임)과 반복성(이미지·컨테이너를 빨리 만들어 CI/CD에 유리)이다.

Docker

컨테이너를 직접 다루기는 어려우니 만들고 관리해 주는 도구가 Docker다. Dockerfile(설계도)을 빌드해 이미지를 만들고, 이미지를 실행한 것이 컨테이너다. 작성법은 Dockerfile 작성과 컨테이너의 PID 1, 여러 컨테이너를 묶어 띄우는 방법은 Docker Compose: 여러 컨테이너 묶어 띄우기에 있다.

핵심 개념

구조: 클라이언트, 데몬, 레지스트리

Docker는 클라이언트-서버 구조다. 터미널에서 치는 docker 명령은 클라이언트일 뿐이고, 실제 일은 호스트의 데몬(dockerd) 이 API 요청을 받아 한다. 데몬은 이미지 빌드, 컨테이너 생성, 네트워크·볼륨 관리, 레지스트리와의 통신을 맡는다.

클라이언트와 데몬은 REST API로 통신한다. 기본 통로는 유닉스 소켓 /var/run/docker.sock이고, 원격 데몬은 TLS로 보호한 TCP(2376)나 SSH(DOCKER_HOST=ssh://user@host)로 연결한다. docker context로 여러 데몬을 바꿔 가며 쓴다. 인증 없는 TCP(2375)를 열면 누구나 호스트 root를 얻으므로 열지 않는다. 같은 이유로 docker 그룹에 사용자를 넣는 것은 sudo 없는 root 권한을 주는 것과 같다.

macOS·Windows에는 리눅스 커널이 없으므로 경량 리눅스 VM 안에서 데몬이 돌고, 호스트의 CLI가 그 데몬에 붙는다. Docker Desktop이 이 VM과 포트 포워딩·파일 공유를 감춰 준다. 그래도 「포트와 바인드 마운트 경로는 데몬이 도는 머신 기준」이라는 원리는 그대로라, 원격 데몬이나 VM 위 컨테이너에서는 호스트 → VM → 컨테이너로 포워딩이 두 번 걸리고 마운트할 수 있는 경로도 공유된 디렉터리로 한정된다. 과거에는 boot2docker(Tiny Core Linux VM, 2014) → Docker Toolbox·docker-machine(2015) → Docker for Mac/Windows(2016) 순으로 바뀌었고, boot2docker 시절엔 localhost 대신 VM IP(boot2docker ip)로 접속해야 했다. 그 시절 GUI였던 Kitematic과 Toolbox는 보관 처리됐고, 지금은 Docker Desktop 외에 OrbStack, Colima, Rancher Desktop, Podman Desktop이 같은 구조를 쓴다.

flowchart LR
  subgraph client["Docker 클라이언트"]
    c1["docker build"]
    c2["docker pull"]
    c3["docker run"]
  end
  subgraph host["Docker 호스트"]
    dd["dockerd (데몬)"]
    dd --> img["이미지"]
    dd --> ctr["컨테이너"]
    dd --> net["네트워크"]
    dd --> vol["볼륨"]
  end
  subgraph reg["레지스트리"]
    hub["Docker Hub"]
    priv["비공개 레지스트리"]
  end
  client -->|"REST API"| host
  host <-->|"pull/push"| reg

docker run nginx 한 줄은 다음 순서로 실행된다.

1. 로컬에 이미지가 없으면 레지스트리에서 pull한다.
2. 이미지로 새 컨테이너를 만든다.
3. 이미지의 읽기 전용 층 위에 컨테이너용 읽기·쓰기 층을 얹는다.
4. 네트워크 인터페이스를 만들어 기본 네트워크(bridge)에 연결하고 IP를 준다.
5. 컨테이너를 시작해 지정한 명령을 실행한다.

런타임 계층: dockerd, containerd, runc

데몬은 컨테이너를 직접 만들지 않고 아래 계층에 맡긴다.

flowchart TB
  cli["docker CLI"] -->|"REST"| dd["dockerd<br/>(빌드, 네트워크, 볼륨, API)"]
  dd -->|"gRPC"| ctd["containerd<br/>(이미지 받기·저장, 컨테이너 수명 관리)"]
  ctd --> shim["containerd-shim<br/>(컨테이너마다 하나, runc가 끝난 뒤 남아 입출력·종료 코드 관리)"]
  shim --> runc["runc<br/>(네임스페이스·cgroups를 만들고 프로세스를 실행한 뒤 종료)"]
  runc --> proc["컨테이너 프로세스"]

OCI(Open Container Initiative) 는 컨테이너 형식이 특정 회사에 묶이지 않도록 2015년 Docker 등이 리눅스 재단 아래 만든 표준 단체다. 세 가지 명세를 정한다.

Docker는 OCI 이미지를 만들고 OCI 런타임(runc)으로 실행하는 도구 중 하나다. 그래서 Docker로 빌드한 이미지는 Podman, containerd, CRI-O, 쿠버네티스 어디서나 돈다. Docker 29부터는 새로 설치하면 이미지 저장도 containerd가 맡는다.

Docker와 쿠버네티스

둘은 경쟁이 아니라 앞뒤 단계다. 개발자는 Docker로 이미지를 빌드해 레지스트리에 올리고, 쿠버네티스는 그 이미지를 받아 클러스터에 띄운다(쿠버네티스 구조와 핵심 개념).

오케스트레이션과 오토 스케일링

관리할 컨테이너가 많아지면 사람이 일일이 배치·재시작·네트워크 연결을 할 수 없다. Docker가 서버 한 대의 컨테이너를 관리한다면, 오케스트레이션 도구는 Docker가 깔린 여러 서버를 묶어 배포, 장애 시 재시작, 서비스 디스커버리를 자동으로 관리한다. 대표적으로 Kubernetes, Docker Swarm, AWS ECS가 있다.

오토 스케일링도 오케스트레이션의 일이다. 트래픽에 맞춰 실행 단위를 자동으로 늘리고 줄이는데, 두 수준이 있다.

쿠버네티스의 HPA·VPA·Cluster Autoscaler가 동작하는 원리는 쿠버네티스 스케줄링과 자원 관리에 있다.

Docker Swarm과 쿠버네티스

지금의 Swarm은 Docker 1.12(2016)에 엔진에 들어간 swarm 모드(SwarmKit)다. 과거의 클래식 Swarm(2015)은 Docker API를 그대로 흉내 내는 프록시라 docker -H tcp://swarm:port로 클러스터를 엔진 하나처럼 다뤘고, 노드 목록은 외부 디스커버리(etcd·Consul·ZooKeeper)에 뒀다. 스케줄링은 필터(라벨 제약, 헬스, 포트 충돌)로 후보를 거른 뒤 전략(binpack: 꽉 채우기, spread: 고르게, random)으로 골랐다. 이 「거르고 고른다」 구조는 쿠버네티스 스케줄러의 필터·점수 단계와 같다. 클래식 Swarm 저장소는 2020년 보관 처리됐다.

docker swarm init --advertise-addr 10.0.0.1                 # 매니저. 상태는 Raft로 /var/lib/docker/swarm에
docker swarm join --token <토큰> 10.0.0.1:2377               # 워커 합류
docker service create --name web -p 8080:80 --replicas 3 nginx:1.27
docker service update --update-parallelism 1 --image nginx:1.28 web   # 롤링 업데이트
docker service create --constraint 'node.role == manager' ...       # 배치 제약
docker stack deploy -c compose.yaml shop                     # Compose 파일을 클러스터에 배포

• -p로 공개한 포트는 인그레스 라우팅 메시라서 어느 노드 IP로 들어와도 해당 서비스의 태스크로 분산된다.
• overlay 네트워크 안에서 서비스 이름(web)은 가상 IP 하나로, tasks.web은 태스크 IP 목록으로 풀린다.
• 이미지에 HEALTHCHECK가 있으면 헬스 체크를 통과한 태스크만 트래픽을 받아, 롤링 업데이트가 끊김 없이 이어진다.
• docker secret create로 만든 비밀은 붙인 서비스의 컨테이너에만 /run/secrets/<이름> 파일로 들어간다.

AWS ECS로 보는 오케스트레이션 용어

오케스트레이터마다 이름은 달라도 개념은 비슷하다. ECS의 용어로 보면 다음과 같다.

태스크 정의(JSON)에서 cpu는 1024가 vCPU 1개인 단위, memory는 MiB다. essential: true인 컨테이너가 죽으면 태스크 전체가 멈춘다. 네트워크 모드는 태스크마다 ENI(VPC IP)를 주는 awsvpc가 기본 선택지이고 Fargate는 이것만 쓴다. 옛 links·volumesFrom은 bridge 모드에서만 쓰는 레거시다.

태스크를 직접 실행하면 죽어도 다시 뜨지 않는다. 웹 서버처럼 계속 떠 있어야 하는 것은 서비스로 띄운다. 스케줄러가 어느 호스트에 놓을지 정하므로 어떤 호스트에서 돌아도 되게 만든다(로컬 디스크·고정 IP에 기대지 않는다). 이미지는 ECR 같은 비공개 레지스트리에 두고 IAM으로 권한을 준다.

쿠버네티스는 구글이 사내 클러스터 관리 시스템 Borg를 운영한 경험을 바탕으로 2014년 오픈 소스로 공개했다. 이듬해 중립 재단 CNCF에 기증되면서 여러 기업이 기여했고, 기술보다 이 중립성과 거대한 생태계 덕분에 Swarm·Mesos를 제치고 표준이 됐다.

Apache Mesos는 UC 버클리에서 나온 클러스터 자원 관리자로, 여러 서버의 CPU·메모리·디스크를 하나의 자원 풀로 묶는 「데이터센터 커널」을 표방했다. 마스터는 ZooKeeper로 리더를 뽑아 이중화하고, 에이전트가 보고한 자원을 프레임워크(컨테이너용 Marathon, Hadoop·Spark 등)에 제안하면 프레임워크가 그 안에서 작업을 배치하는 2단계 스케줄링을 썼다. 배치·빅데이터 작업을 대량으로 돌리는 데 강했지만 범용 서비스 배포에서 쿠버네티스에 밀렸고, 2025년 은퇴해 Apache Attic으로 옮겨졌다. Mesos의 마스터는 에이전트가 보고한 자원(예: 4 CPU, 4GB)을 프레임워크에 제안(offer) 하고, 프레임워크가 그 자원으로 돌릴 작업을 골라 돌려보내면 마스터가 에이전트에 넘겼다. 중앙 스케줄러가 필터·점수로 바로 노드를 고르는 쿠버네티스와 대비되는 설계다. Mesos를 상용화한 Mesosphere는 2019년 D2iQ로 이름을 바꾸고 쿠버네티스로 옮겨 갔다. Docker의 인프라 관리 도구 Infrakit(뒤에 DeployKit)는 원하는 인프라 상태를 JSON으로 선언하면 인스턴스·그룹·플레이버 플러그인이 실제 상태를 계속 맞추는 조정 루프 도구였고, 이 역시 2018년 보관 처리됐다. 같은 조정 루프는 지금 쿠버네티스 컨트롤러와 Cluster API, 클라우드 오토 스케일링 그룹이 맡는다. Swarm은 Docker 엔진의 swarm 모드로 남아 있다.

MSA와의 관계

MSA는 기능을 독립적으로 배포 가능한 서비스들로 쪼갠 구조라서, 서비스마다 컨테이너로 포장해 따로 배포·확장하기에 알맞다.

MSA의 구성 요소와 도입 시 주의점은 웹 확장성의 구성 요소의 「확장의 세 축」에 정리했다.

핵심 정리

• VM은 OS째로, 컨테이너는 앱 단위로 격리한다. 컨테이너가 훨씬 가볍고 빠르다.
• docker CLI → dockerd → containerd → runc 순으로 일을 넘기고, 이미지·런타임·배포 형식은 OCI 표준이라 어느 런타임에서나 돈다.
• Docker는 실행 환경을 이미지로 통째로 포장해 어디서나 같은 환경을 띄우게 한다.
• 컨테이너가 많아지면 오케스트레이션 도구가 배치·재시작·오토 스케일링을 맡는다. 사실상 표준은 쿠버네티스다.

관련 노트: 가상화와 하이퍼바이저, 운영체제 개요(커널의 구조), CI/CD, 스타트업 인프라 선택 원칙, 쿠버네티스 위 웹 서비스의 요청 경로와 구성 요소, Dockerfile 작성, Docker Compose, Docker 네트워크와 볼륨, Docker 컨테이너 운영, 쿠버네티스 구조와 핵심 개념