💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

프롤로그 — 왜 다시 도커 대체를 이야기하는가

2021년 8월 31일. Docker Inc.는 "Docker Subscription Service Agreement"를 발표하며 Docker Desktop을 직원 250명 이상 또는 매출 1,000만 달러 이상의 회사에서 상용 용도로 쓰려면 유료 구독이 필요하다고 못박았다. 이 한 줄의 약관 변경이 컨테이너 도구 생태계를 통째로 흔들었다. 그전까지 "도커 = 컨테이너"였지만, 그 후로는 "도커 = Docker Inc.의 한 제품"이라는 사실이 분명해졌다.

그로부터 5년이 지난 2026년 5월, 풍경은 완전히 바뀌었다.

- **Podman Desktop**이 Red Hat의 본격 지원 아래 1.20대에 진입했다. 데몬리스(daemonless) 아키텍처와 루트리스(rootless) 컨테이너로 차별화한다.

- **OrbStack**이 맥에서 사실상의 표준이 되었다. 상용 도구지만 메모리 점유는 도커 대비 1/3 수준, 시작 시간은 2초 이내다.

- **Finch**가 AWS가 내놓은 오픈소스 통합 번들이다. Lima + containerd + nerdctl + BuildKit이 한 패키지에 들어 있다.

- **Colima**가 무료를 원하는 사람들의 기본 선택지다. Lima 기반에 Homebrew로 설치 가능하다.

- **Rancher Desktop**이 SUSE의 인수 이후에도 쿠버네티스 사용자에게 가장 친화적인 옵션이다.

- **Apple Container Framework**가 2025년 WWDC에서 발표되며 macOS 자체가 컨테이너 런타임을 품기 시작했다. 2026년 5월 현재 macOS 15.4부터 정식 지원.

- 그리고 그 아래에서 **containerd**가 진짜 산업 표준이 되었다. CNCF Graduated 프로젝트로, Kubernetes의 기본 런타임이고, 위의 모든 도구가 어떤 식으로든 containerd를 부른다.

이 글은 위 7개 도구를 같은 축으로 비교한다. 각 도구의 내부 구조, 성능 특성, 장단점, 그리고 어떤 팀에 어떤 도구가 맞는지를 정직하게 따져본다. 가격·기능 수치는 2026년 5월 기준이며, 6개월 뒤 바뀌어도 구조적 차이를 보는 프레임은 유효해야 한다.

> 도커는 사라지지 않는다. 다만 **도커는 이제 여러 선택지 중 하나**다. 우리는 "도커 vs 다른 것들"의 시대에서 "내 팀에 맞는 컨테이너 도구"의 시대로 넘어왔다.

1장 · 도커 아키텍처 다이어그램으로 본 컨테이너의 진짜 구성 요소

"도커 대체"라는 말을 쓰려면, 먼저 도커가 무엇을 하는지 5개 컴포넌트로 분해해야 한다. 같은 일을 하는 다른 도구를 골라야 비로소 "대체"가 된다.

**컴포넌트 1 · 컨테이너 런타임(Container Runtime)**

컨테이너를 실제로 실행하는 저수준 코드. 리눅스 네임스페이스·cgroup·capabilities를 다룬다. 도커는 내부적으로 containerd를 부르고, containerd는 다시 runc를 부른다. 1) **runc** — OCI 표준 참조 구현, Go로 작성. 2) **crun** — Red Hat의 C 구현, 더 빠르고 작다. 3) **kata-containers** — VM 기반 격리.

**컴포넌트 2 · 런타임 데몬(Runtime Daemon)**

런타임을 호출하는 장기 실행 프로세스. 도커는 dockerd, 그 아래에 containerd가 또 있다. Podman은 데몬 없이 직접 실행하는 게 시그니처 차이다. nerdctl은 containerd를 직접 부른다.

**컴포넌트 3 · CLI / 클라이언트(CLI / Client)**

사용자가 입력하는 명령어. `docker`, `podman`, `nerdctl`, `finch`, `crictl` 등. 대부분 도커 CLI와 호환되는 명령 인터페이스를 제공한다 — `run`, `build`, `pull`, `push`, `ps`, `images`, `exec`, `logs`.

**컴포넌트 4 · 이미지 빌더(Image Builder)**

Dockerfile을 OCI 이미지로 변환. 1) **classic builder** — 도커의 옛 빌더, 단일 스레드. 2) **BuildKit** — 도커의 현재 빌더, 병렬 빌드, 캐시 마운트, 시크릿 마운트 지원. 3) **Buildah** — Red Hat, 데몬리스, 셸 스크립트로 빌드 가능. 4) **kaniko** — 구글, 클러스터 안에서 도는 빌더.

**컴포넌트 5 · VM 레이어(VM Layer, macOS/Windows 한정)**

컨테이너는 리눅스 커널 기능에 의존하므로, macOS와 Windows에서는 리눅스 VM이 필요하다. 1) **Hyperkit / VZ** — 도커 데스크탑의 옛/새 백엔드. 2) **Lima** — Colima, Finch, Rancher Desktop이 모두 의존. 3) **WSL2** — 윈도우. 4) **Apple Virtualization Framework** — OrbStack의 핵심.

이 5개 컴포넌트를 서로 다르게 조합한 것이 곧 "도커 대체 도구들"이다. 표로 정리하면:

| 도구 | 런타임 | 데몬 | CLI | 빌더 | VM 레이어 |

| --- | --- | --- | --- | --- | --- |

핵심은 **containerd가 거의 모든 곳에 있다**는 것이다. 컨테이너 런타임 전쟁은 사실상 끝났고, containerd가 이겼다. 위 도구들의 차이는 그 위에 무엇을 얹느냐의 차이다.

2장 · containerd / runc / CRI-O — 하부 런타임의 진짜 표준

containerd는 2017년 Docker에서 분리되어 CNCF에 기증된 프로젝트다. 2019년 Graduated 단계에 들었고, 2026년 현재 Kubernetes 1.30 이후 디폴트 런타임이며, AWS Fargate · GKE · AKS · EKS · IBM Cloud · DigitalOcean Kubernetes의 기본이다.

**containerd가 하는 일**

이미지를 pull/push하고, OCI 이미지를 풀어서 컨테이너 번들을 만들고, runc를 호출해 컨테이너를 실행하고, 컨테이너의 라이프사이클(start/stop/kill/delete)을 관리한다. 네임스페이스와 cgroup의 설정은 runc에 위임한다.

**왜 도커보다 가벼운가**

도커는 `dockerd` 위에서 다시 `containerd`를 부르는 2단 구조다. containerd만 따로 쓰면 한 단계가 줄고, dockerd가 가진 빌드·네트워크·볼륨 오케스트레이션 기능(많은 사람이 안 쓰는)이 빠진다. 메모리 점유가 작아지고, 시작 시간이 빨라진다.

**runc vs crun**

runc는 Go로 작성됐고 표준이다. crun은 Red Hat이 C로 새로 쓴 것이고 더 빠르다 — 컨테이너 시작이 약 2배 빠르다는 벤치마크가 일관되게 나온다. 메모리도 적게 쓴다. Podman은 디폴트로 crun을 쓴다. containerd도 `runtimeclass`를 통해 crun으로 바꿀 수 있다.

**CRI-O는 어디에 쓰는가**

CRI-O는 Kubernetes를 위한 최소 런타임이다. CRI(Container Runtime Interface)만 구현하고 다른 기능은 없다. Red Hat OpenShift가 디폴트로 쓴다. 개발자 데스크탑에서는 잘 안 쓴다 — 이 글 범위에서는 "Kubernetes 노드용"으로만 알아두면 된다.

containerd를 직접 다루는 명령어는 `ctr`인데, 사람이 쓰기엔 거칠다. 그래서 두 가지 사용자 친화적 CLI가 등장한다 — `nerdctl`(도커 CLI 호환)과 Kubernetes에서 쓰는 `crictl`(CRI 전용).

containerd 자체 CLI

sudo ctr image pull docker.io/library/nginx:latest

sudo ctr container create docker.io/library/nginx:latest mynginx

sudo ctr task start mynginx

nerdctl로 같은 작업 (훨씬 쉬움)

nerdctl run -d --name mynginx -p 8080:80 nginx:latest

containerd가 표준이라는 사실은 도구 선택에 함의가 크다. **위 도구 대부분이 같은 containerd를 부른다**. 그러므로 도구 사이의 진짜 차이는 (a) CLI 친숙도, (b) VM 레이어 성능, (c) 부가 기능(쿠버네티스, GUI, 빌더 통합)에 있다.

3장 · Podman + Buildah + Skopeo — Red Hat의 데몬리스 스택

Podman은 Red Hat이 2018년 출시한 도커 대체다. "Pod Manager"의 약자이며, 본래는 쿠버네티스 Pod을 로컬에서 실행하는 도구로 시작했다. 2026년 현재 5.5 버전대로, RHEL · Fedora · CentOS Stream의 기본 컨테이너 도구다.

**Podman의 시그니처 — 데몬리스**

도커는 dockerd가 항상 떠 있어야 한다. 컨테이너가 없어도 데몬은 메모리를 먹고 systemd 서비스로 살아 있다. Podman은 다르다. `podman run`을 입력하면 그 순간 fork된 프로세스가 컨테이너를 띄우고, 컨테이너가 끝나면 같이 죽는다. 데몬 없음. 백그라운드 서비스 없음.

도커 — 데몬이 미리 떠 있어야 함

sudo systemctl start docker

docker run -d nginx

Podman — 데몬 없이 직접 실행

podman run -d nginx

컨테이너가 종료되면 관리 프로세스도 자연스럽게 종료된다.

**왜 데몬리스가 중요한가**

세 가지 이유다. 1) **보안** — dockerd는 root로 도는 거대한 공격 표면이다. dockerd 권한이 곧 root다. Podman은 fork 모델이라 root가 필요 없다. 2) **루트리스(rootless) 컨테이너** — 일반 사용자 권한으로 컨테이너를 띄울 수 있다. user namespace를 써서 컨테이너 안의 root가 호스트의 일반 사용자로 매핑된다. 3) **systemd 통합** — 컨테이너 하나가 곧 systemd 유닛이다. `podman generate systemd`로 자동 생성된다.

**Buildah — 이미지 빌더**

Podman은 빌드를 직접 하지 않는다. 빌드는 Buildah가 한다. Buildah의 장점은 두 가지다. 1) **Dockerfile 없이 셸 스크립트로 빌드** — `buildah from`, `buildah run`, `buildah copy`, `buildah commit`을 조합해 절차적 빌드를 할 수 있다. CI 파이프라인에서 강력하다. 2) **루트리스 빌드** — root 없이 이미지를 만들 수 있다. 보안 환경에서 결정적.

Buildah로 셸 스크립트 빌드

container=$(buildah from alpine:3.20)

buildah run $container -- apk add --no-cache python3

buildah copy $container app.py /app/

buildah config --cmd 'python3 /app/app.py' $container

buildah commit $container myapp:1.0

**Skopeo — 이미지 운반**

Skopeo는 이미지 레지스트리 사이를 옮기는 도구다. 컨테이너 실행은 하지 않고, **이미지 자체만 다룬다**. 1) 레지스트리 사이 복사 — `skopeo copy docker://docker.io/nginx:latest docker://my-registry.com/nginx:latest`. 2) 이미지 인스펙트 — pull 없이 매니페스트만 본다. 3) 서명 검증 — Sigstore/Cosign 통합. CI에서 "이미지를 가져오지 않고 검사만" 하는 시나리오에서 표준이다.

**Podman Desktop**

2022년 Red Hat이 출시한 GUI. 2026년 현재 1.20 버전대로, Docker Desktop과 거의 동일한 사용성을 제공한다. Windows · macOS · Linux. Kubernetes 통합(Kind/Minikube), 컨테이너 마이그레이션 마법사, AI Lab(로컬 LLM) 같은 부가 기능. **무료**이며 오픈소스다(Apache 2.0).

**Podman의 약점**

1) 도커와 100% 호환은 아니다. 일부 도커 Compose 옵션이나 네트워크 모드가 다르게 동작한다. `podman-compose`나 별도 도커 호환 소켓이 필요하다. 2) macOS/Windows에서는 결국 VM이 필요하다 — 데몬리스의 이점이 호스트 OS에서는 줄어든다. 3) `docker-compose` 같은 도구가 도커 소켓을 기대할 때 호환 레이어를 끼워야 한다.

4장 · nerdctl — containerd를 Docker CLI처럼

nerdctl는 containerd 프로젝트의 공식 자매 도구다. 이름은 "containerd를 위한 nerdy CLI"의 줄임말. 2026년 현재 2.x 버전대로, containerd만 깔려 있으면 도커 명령을 거의 그대로 쓸 수 있게 해 준다.

**왜 nerdctl이 필요한가**

containerd 자체의 `ctr`은 너무 저수준이다. `ctr image pull` → `ctr container create` → `ctr task start`의 3단계를 거쳐야 한다. nerdctl은 도커 CLI와 거의 같은 명령으로 같은 일을 한다.

도커

docker run -d -p 8080:80 --name web nginx:latest

nerdctl — 거의 동일

nerdctl run -d -p 8080:80 --name web nginx:latest

도커 Compose 호환

nerdctl compose up -d

**nerdctl의 강점 — 도커가 못 하는 것**

1) **이미지 lazy pull** — `nerdctl run --snapshotter=stargz`로 이미지를 다운로드 끝나기 전에 컨테이너가 뜬다. 큰 이미지에서 시작 시간을 극적으로 줄인다. 2) **이미지 암호화** — `nerdctl image encrypt`로 이미지 레이어를 암호화한다. 3) **Rootless** — Podman만큼 깔끔하게 루트리스를 지원한다. 4) **P2P 이미지 분산** — IPFS 통합, eStargz 형식 등 실험적 기능들.

**nerdctl이 쓰이는 곳**

1) **Lima/Colima/Finch/Rancher Desktop의 디폴트 CLI**. 2) **Kubernetes 노드에서 디버깅** — `crictl`이 너무 거칠 때. 3) **containerd만 깐 서버에서 직접 컨테이너 운영**할 때.

**약점**

도커 CLI와 90%는 호환되지만 10%는 다르게 동작한다. `--platform`의 처리, 일부 `--volume` 옵션, 네트워크 드라이버 디테일. Compose 호환은 `nerdctl compose`로 구현됐지만 도커 Compose의 모든 옵션을 다 지원하진 않는다.

5장 · Lima / Colima — Mac 위 리눅스 VM의 시작점

Lima는 "Linux on Mac"이다. 일본의 LINE Corporation에서 시작해 지금은 CNCF Sandbox 프로젝트다. 2026년 현재 1.0대를 넘어 안정화됐고, macOS에서 리눅스 VM을 띄우는 사실상의 기준이 되었다.

**Lima의 정체성**

Lima 자체는 컨테이너 런타임이 아니다. **macOS에서 리눅스 VM을 띄워 주고**, 그 안에서 컨테이너 런타임이 돌게 해 주는 것이 전부다. 기본 백엔드는 QEMU(x86) 또는 Apple Virtualization Framework(arm64). VM 안에는 자동으로 containerd + nerdctl이 깔린다.

Lima 설치 및 디폴트 VM 시작

brew install lima

limactl start

VM 안에서 nerdctl 사용

lima nerdctl run -d -p 8080:80 nginx

**Lima의 강점**

1) **선언적 설정** — VM 사양을 YAML로 정의. `cpus: 4`, `memory: 8GiB`, `mounts: [~/projects]` 같은 식. 2) **여러 VM 동시 운영** — k8s 클러스터용 VM과 컨테이너 개발용 VM을 분리 가능. 3) **포트 포워딩 자동화** — VM 안의 포트를 호스트에 자동으로 노출.

**Colima의 정체성**

Colima는 "Containers on Lima"의 줄임말이다. Lima를 한 줄 명령으로 쓰게 해 주는 래퍼다. 2026년 현재 0.8대 버전. **개발자 데스크탑용 Lima의 사용자 경험을 도커 데스크탑 수준으로 끌어올린 것**이 핵심이다.

Colima로 한 번에 시작

brew install colima docker

colima start --cpu 4 --memory 8

도커 CLI를 그대로 사용 — Colima가 도커 호환 소켓을 노출

docker ps

docker run -d nginx

**Colima vs Lima 직접 사용**

Lima는 "VM 도구"이고 Colima는 "Docker Desktop 대체 도구"라는 게 사용자 인식의 차이다. Colima는 자동으로 도커 소켓 호환을 제공하고, k3s 옵션으로 쿠버네티스를 한 번에 띄울 수 있다.

k3s 옵션으로 쿠버네티스 함께 시작

colima start --kubernetes --cpu 4 --memory 8

kubectl이 자동으로 컨텍스트를 잡는다

kubectl get nodes

**Colima의 강점**

1) **완전 무료** — MIT 라이선스. 회사 규모와 무관. 2) **도커 호환** — 도커 CLI를 그대로 쓰면서 백엔드만 컨테이너d로 교체. 3) **k3s 통합** — 한 명령으로 쿠버네티스. 4) **여러 프로파일** — `colima start -p work`, `colima start -p personal`처럼 컨텍스트 분리.

**Colima의 약점**

1) GUI 없음 — 터미널에서만. 2) macOS 첫 시작에서 VM 부팅에 10~20초. OrbStack의 2초와 대비된다. 3) 파일 시스템 공유 성능이 보통(virtiofs/sshfs 기반). 큰 모노레포에서는 체감이 있다. 4) Windows 미지원(Lima는 윈도우 미지원).

6장 · OrbStack — 상용이지만 빠르고 가볍다

OrbStack은 2023년 출시된 상용 도커 데스크탑 대체다. 만든 사람은 한 명(Danny Lin), 회사 이름도 OrbStack. macOS 전용. 2026년 현재 1.10 버전대다. **유료 상용 소프트웨어**지만 개인 사용은 무료, 기업은 사용자당 월 8달러 수준.

**왜 사람들이 OrbStack을 좋아하는가**

세 가지다. 1) **빠르다** — 시작 2초. 도커 데스크탑의 30~60초와 비교가 안 된다. 2) **가볍다** — 메모리 점유가 도커 데스크탑의 1/3 수준. M2 Air에서도 압박이 없다. 3) **매끄럽다** — 파일 시스템 공유가 거의 네이티브 속도. virtiofs 위에 자체 최적화 레이어.

**기술적으로 뭐가 다른가**

OrbStack은 (a) Apple Virtualization Framework를 적극적으로 활용하고, (b) Linux 커널을 자체적으로 패치해 macOS와의 파일 시스템 공유를 최적화하고, (c) Rosetta 2를 통한 x86 컨테이너 실행을 1급으로 지원한다. M1/M2/M3 맥에서 amd64 이미지를 거의 ARM 네이티브 수준으로 돌린다.

**기능 — 도커 호환 + 쿠버네티스 + 리눅스 머신**

1) **도커 호환** — 도커 CLI 그대로. 도커 데스크탑의 Compose, 볼륨, 네트워크 다 동작. 2) **쿠버네티스** — 한 토글로 켜고 끈다. K3s 기반. 3) **리눅스 머신** — 컨테이너 외에 본격 리눅스 VM을 호스팅. Ubuntu, Fedora, Debian, Arch, NixOS 등 한 줄로 시작.

도커 명령을 그대로 사용

docker run -d nginx

리눅스 VM 시작

orb create ubuntu my-vm

orb -m my-vm # VM 안으로 들어감

**OrbStack의 약점**

1) **클로즈드 소스 + 상용**. 엔터프라이즈 도입은 정책에 걸릴 수 있다. 2) **macOS 전용**. Linux/Windows 사용자는 못 쓴다. 3) **회사 1인 의존**. Danny가 떠나면 미래가 흔들린다(2026년 현재 팀 확장 중이라는 발표는 있다). 4) 가격이 사용자당 월 8달러, Docker Desktop Business와 비슷한 수준이지만 도커보다는 살짝 싸다.

**언제 OrbStack을 고르는가**

1) macOS 개발자고 무료 옵션의 속도가 답답할 때. 2) 회사가 도커 데스크탑 라이선스를 살 거면 OrbStack도 같은 가격대니까. 3) 로컬에서 진짜 무거운 컨테이너 워크로드를 돌릴 때(영상 처리, ML 추론 등).

7장 · Finch — AWS의 오픈소스 통합 패키지

Finch는 2022년 AWS가 출시한 오픈소스 컨테이너 도구다. 이름은 갈라파고스의 핀치 새에서 따 왔다(다윈, 진화, 다양성). 2026년 현재 1.5 버전대.

**Finch의 정체성**

Finch는 새로운 컨테이너 런타임이 아니다. **기존 오픈소스 도구들을 하나의 패키지로 묶은 것**이다. 그 안에는: 1) Lima — VM 레이어, 2) containerd — 런타임, 3) nerdctl — CLI, 4) BuildKit — 빌더, 5) Soci-snapshotter — lazy pull 지원. AWS가 직접 통합 테스트하고 패키징한다.

설치 — Homebrew 또는 공식 .pkg

brew install --cask finch

finch vm init

finch vm start

명령은 nerdctl과 거의 동일

finch run -d -p 8080:80 nginx

finch compose up -d

finch build -t myapp .

**Finch의 강점**

1) **완전 무료 + 오픈소스(Apache 2.0)**. 회사 규모 무관, 라이선스 걱정 없음. 2) **AWS 통합** — ECR 인증, AWS Fargate 호환 이미지 빌드 등에서 매끄럽다. 3) **선큐레이트된 스택** — Lima + containerd + nerdctl + BuildKit이 검증된 조합으로 묶여 있다. 4) **macOS · Windows · Linux** 모두 지원.

**Finch의 약점**

1) **GUI 없음**. 도커 데스크탑/OrbStack의 GUI에 익숙하면 답답하다(2026년 5월 현재 Finch Desktop이 베타 단계로 개발 중). 2) **VM 시작이 Lima만큼 느림** — 첫 시작에 10~20초. 3) **쿠버네티스 통합이 약함** — Rancher Desktop이나 Colima만큼 매끄럽지 않다. k8s를 쓰려면 Kind나 Minikube를 별도로 깔아야 한다.

**언제 Finch를 고르는가**

1) AWS 생태계에서 일하고, ECR/Fargate가 주 타깃일 때. 2) Colima보다 더 "공식 지원" 느낌의 무료 도구를 원할 때. 3) 회사 정책상 클로즈드 도구(OrbStack)나 도커 라이선스를 사기 싫을 때. 4) Linux/Windows 사용자.

8장 · Rancher Desktop — 쿠버네티스 사용자에 최적

Rancher Desktop은 SUSE(2020년 Rancher Labs 인수)가 만든 오픈소스 도커 데스크탑 대체다. 2026년 현재 1.18 버전대. **쿠버네티스 친화**가 시그니처다.

**Rancher Desktop의 시그니처**

켜자마자 k3s 쿠버네티스 클러스터가 같이 뜬다. `kubectl`이 자동으로 컨텍스트를 잡는다. 쿠버네티스 버전도 GUI에서 한 클릭으로 선택할 수 있다. 1.28, 1.29, 1.30 등 어떤 버전이든 즉시 전환.

**컨테이너 엔진 선택**

GUI 옵션 하나로 컨테이너 엔진을 바꿀 수 있다. 1) **containerd + nerdctl** — 기본. 2) **dockerd + docker** — 도커 CLI 그대로 쓰고 싶다면.

nerdctl 모드일 때

nerdctl run -d nginx

dockerd 모드로 바꾸면 도커 CLI를 그대로

docker run -d nginx

쿠버네티스가 항상 같이 떠 있음

kubectl get pods --all-namespaces

**Rancher Desktop의 강점**

1) **무료 + 오픈소스(Apache 2.0)**. 회사 규모 무관. 2) **쿠버네티스 통합** — k3s, kubectl, Helm이 함께 깔린다. 3) **컨테이너 엔진 선택지** — containerd와 dockerd 사이 전환 가능. 4) **macOS · Windows · Linux** 모두 지원.

**Rancher Desktop의 약점**

1) **무겁다** — Lima 기반 + k3s가 항상 떠 있어서 메모리 8GB는 기본으로 쓴다. M2 Air에서는 부담. 2) **시작 시간** — k3s까지 부팅하면 30초 이상. 3) **k8s를 쓰지 않는다면 과잉 스펙**. 단순 컨테이너 개발만 한다면 Colima나 Finch가 더 가볍다.

**언제 Rancher Desktop을 고르는가**

1) 쿠버네티스 개발이 메인일 때. 2) k8s 버전 전환을 자주 해야 할 때(여러 클라이언트의 다른 버전). 3) Rancher/SUSE 생태계와 일관성이 필요할 때. 4) GUI를 원하지만 OrbStack의 비용이 부담스러울 때.

9장 · Podman Desktop 심층 — 그래픽 인터페이스의 데몬리스

Podman 자체는 4장에서 다뤘다. 이 챕터는 **Podman Desktop**, 즉 그래픽 인터페이스 측면에 집중한다. 2026년 현재 1.20대 버전.

**Podman Desktop이 하는 일**

1) Podman 머신(Lima 또는 WSL2 기반 VM)을 GUI로 관리. 2) 컨테이너 · 이미지 · 볼륨 · 네트워크 시각화. 3) Compose 파일 실행. 4) **AI Lab** — 로컬에서 LLM(Llama, Mistral 등)을 컨테이너로 띄우고 OpenAI 호환 API로 접속. 5) **Kubernetes** — Kind/Minikube 통합. 6) **Docker Desktop Extension 호환** — 일부 도커 데스크탑 확장이 Podman Desktop에서도 동작.

**Podman의 진화 — 2026년 시점**

1) **Quadlet** — Podman 컨테이너를 systemd 유닛으로 선언적으로 정의. Kubernetes YAML과 비슷한 느낌의 systemd-네이티브 컨테이너 오케스트레이션. 2) **Podman AI Lab** — 1.20에서 본격적으로 들어왔다. 모델 선택, 양자화, 추론 컨테이너 한 번에. 3) **Kubernetes Play** — `podman play kube` 명령으로 Pod YAML을 직접 실행.

Podman으로 Pod YAML을 직접 실행

podman play kube my-pod.yaml

거꾸로, 실행 중인 컨테이너에서 Pod YAML 생성

podman generate kube my-container > my-pod.yaml

**Podman Desktop이 도커 데스크탑을 진짜로 대체하는가**

- 단순 컨테이너 개발 — 거의 대체 가능.

- Compose — 호환 레이어 있지만 일부 옵션은 다름.

- 회사 정책상 데몬리스/루트리스가 요구되는 환경 — 더 우월하다.

- 윈도우 — WSL2 위에서 잘 돌지만 도커 데스크탑보다 설정이 살짝 복잡.

- macOS — Apple Hypervisor 기반 머신을 자동으로 띄움. OrbStack만큼 빠르진 않다.

10장 · Apple Container Framework — Mac 네이티브 컨테이너의 의미

2025년 6월 WWDC에서 애플이 발표한 새 프레임워크다. 정식 명칭은 "Container Framework", 패키지명 `Apple.ContainerKit`. 2026년 5월 현재 macOS 15.4 이상에서 정식 지원, 명령어는 `container`.

**Apple Container의 정체성**

애플의 시각: "macOS에서 리눅스 컨테이너를 돌리는 데 별도의 VM 매니저가 왜 필요한가? 우리가 직접 만들겠다." Virtualization.framework 위에 OCI 호환 컨테이너 런타임을 얹은 것이다. **컨테이너당 마이크로 VM**을 띄운다 — 각 컨테이너가 자기만의 Linux 커널을 받는다.

설치 — macOS 15.4+에서는 기본 포함

container --version

이미지 풀 / 런 — 도커와 비슷한 인터페이스

container image pull docker.io/library/nginx:latest

container run -d -p 8080:80 nginx:latest

container ps

**Apple Container의 시그니처**

1) **컨테이너당 마이크로 VM** — 컨테이너 사이 커널 격리가 강하다. kata-containers와 유사한 보안 특성. 2) **시작 시간 1초 이내** — Virtualization.framework의 최적화. 3) **Mac 하드웨어 직접 접근** — Neural Engine, GPU 같은 가속기를 컨테이너에 노출. 4) **OCI 호환** — 도커 허브 이미지를 그대로 풀 수 있다.

**약점 — 2026년 5월 시점**

1) **macOS 15.4+ 전용** — 이전 버전 macOS, Linux, Windows에서는 못 쓴다. 2) **생태계 미성숙** — Compose, Buildah, Skopeo 같은 주변 도구와의 통합이 아직. 3) **이미지 빌드** — BuildKit 호환은 되지만 일부 멀티스테이지 빌드에서 이슈 보고. 4) **쿠버네티스** — k3s/minikube와의 통합은 베타.

**Apple Container의 의미**

애플이 컨테이너를 OS 1급 시민으로 끌어들였다는 것 자체가 크다. iOS/iPadOS로의 확장 가능성, Xcode와의 통합(시뮬레이터 + 컨테이너의 통합 디버깅), 보안 모델의 일관성. 5년 후에는 macOS 컨테이너 사용자의 다수가 Apple Container를 기본으로 쓸 가능성이 충분하다. 다만 **2026년 5월 시점에서는 아직 실험적**이고, OrbStack/Colima/Finch만큼 성숙하지 않았다.

11장 · 우리 팀은 무엇을 골라야 하나 — 의사결정 트리

위 7개 도구를 같은 축에 펼쳐 놓으면 표는 이렇다. 가격 · OS 지원 · 라이선스 · 데몬 유무 · 쿠버네티스 통합을 한눈에 본다.

| 도구 | 가격 | OS | 라이선스 | 데몬 | k8s |

| --- | --- | --- | --- | --- | --- |

| Podman Desktop | 무료 | Mac/Win/Linux | Apache 2.0 | 없음 | 통합 |

| Colima | 무료 | Mac/Linux | MIT | 없음 | k3s 옵션 |

| Finch | 무료 | Mac/Win/Linux | Apache 2.0 | 없음 | 별도 |

| Apple Container | 무료 | Mac만 (15.4+) | Apple | 없음 | 베타 |

**시나리오 1 — 1인 맥 개발자, 무료 원함**

첫 후보: **Colima**. 가볍고, MIT, 도커 CLI 그대로. 두 번째 후보: **Finch**. AWS 생태계라면 더 매끄럽다. macOS 15.4+에서 실험적으로 쓰고 싶다면 **Apple Container**.

**시나리오 2 — 1인 맥 개발자, 속도가 중요**

첫 후보: **OrbStack**. 시작 2초, 메모리 가벼움. 개인은 무료다. 두 번째 후보: **Apple Container**(macOS 15.4+).

**시나리오 3 — 회사, 50인 이상, 라이선스 정리 필요**

첫 후보: **Podman Desktop**. 무료, 오픈소스, 엔터프라이즈 사용 가능. 두 번째: **Finch** 또는 **Rancher Desktop**. 도커 데스크탑 라이선스를 살 거라면 **OrbStack**도 같은 가격대지만 macOS 전용이라는 제약.

**시나리오 4 — 쿠버네티스 학습 / 개발**

첫 후보: **Rancher Desktop**. k3s 통합, k8s 버전 전환, kubectl/Helm 같이 깔린다. 두 번째: **Colima --kubernetes**, **OrbStack**의 k8s 토글.

**시나리오 5 — CI 환경, root 권한 제약, 보안 중시**

첫 후보: **Podman + Buildah**. 데몬리스, 루트리스, systemd 통합. 두 번째: **nerdctl + BuildKit**(루트리스 모드).

**시나리오 6 — Windows 개발자**

첫 후보: **Podman Desktop** 또는 **Rancher Desktop**. 둘 다 WSL2 기반. **Docker Desktop**의 유료 라이선스를 피하고 싶을 때. OrbStack과 Apple Container는 불가.

**시나리오 7 — 진짜 무거운 워크로드(영상/ML/대용량 데이터)**

첫 후보: **OrbStack**(Mac) 또는 **Podman 네이티브**(Linux 직접). VM 오버헤드를 최소화. Apple Container도 후보.

**시나리오 8 — 회사의 표준화, 한 도구로 통일하고 싶음**

첫 후보: **Podman Desktop** 또는 **Rancher Desktop**. 세 OS 모두 지원, 오픈소스. 두 번째: **Finch**. AWS 친화면 강점.

**의사결정 체크리스트**

1. **회사 규모와 라이선스** — Docker Desktop의 250명/1,000만 달러 임계를 넘는가? 넘으면 무료 옵션 또는 OrbStack/Finch.

2. **주 OS** — Mac만이면 선택지가 넓다. Linux/Windows를 같이 지원해야 하면 Colima는 빠진다.

3. **쿠버네티스 비중** — 일상적으로 쓰면 Rancher Desktop 또는 Colima+k8s.

4. **GUI 필요성** — 팀원이 CLI에 익숙하지 않으면 Podman Desktop, OrbStack, Rancher Desktop.

5. **속도 vs 비용** — OrbStack은 빠르지만 회사 사용은 유료. Colima/Finch는 무료지만 시작이 느림.

6. **보안 정책** — 데몬리스/루트리스가 요구되면 Podman.

7. **장기적 베팅** — Apple Container는 5년 후 macOS 표준이 될 가능성 있음. 지금 익혀둘 가치는 있다.

12장 · 참고 / References

도구별 공식 문서와 핵심 자료다. URL은 모두 2026년 5월 기준으로 살아 있는 곳만 골랐다.

**컨테이너 표준 / 런타임**

- OCI(Open Container Initiative) 스펙: [https://opencontainers.org/](https://opencontainers.org/)

- containerd 공식: [https://containerd.io/](https://containerd.io/)

- runc 깃허브: [https://github.com/opencontainers/runc](https://github.com/opencontainers/runc)

- crun 깃허브: [https://github.com/containers/crun](https://github.com/containers/crun)

- CRI-O 공식: [https://cri-o.io/](https://cri-o.io/)

**Docker**

- Docker 공식: [https://www.docker.com/](https://www.docker.com/)

- Docker Subscription Service Agreement 발표(2021-08-31): [https://www.docker.com/blog/updating-product-subscriptions/](https://www.docker.com/blog/updating-product-subscriptions/)

- BuildKit 깃허브: [https://github.com/moby/buildkit](https://github.com/moby/buildkit)

**Podman / Buildah / Skopeo**

- Podman 공식: [https://podman.io/](https://podman.io/)

- Podman Desktop: [https://podman-desktop.io/](https://podman-desktop.io/)

- Buildah: [https://buildah.io/](https://buildah.io/)

- Skopeo 깃허브: [https://github.com/containers/skopeo](https://github.com/containers/skopeo)

- Quadlet 문서: [https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html](https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html)

**nerdctl**

- nerdctl 깃허브: [https://github.com/containerd/nerdctl](https://github.com/containerd/nerdctl)

**Lima / Colima**

- Lima 깃허브: [https://github.com/lima-vm/lima](https://github.com/lima-vm/lima)

- Colima 깃허브: [https://github.com/abiosoft/colima](https://github.com/abiosoft/colima)

**OrbStack**

- OrbStack 공식: [https://orbstack.dev/](https://orbstack.dev/)

**Finch**

- Finch 공식: [https://runfinch.com/](https://runfinch.com/)

- Finch 깃허브: [https://github.com/runfinch/finch](https://github.com/runfinch/finch)

**Rancher Desktop**

- Rancher Desktop 공식: [https://rancherdesktop.io/](https://rancherdesktop.io/)

- Rancher Desktop 깃허브: [https://github.com/rancher-sandbox/rancher-desktop](https://github.com/rancher-sandbox/rancher-desktop)

**Apple Container Framework**

- Apple Developer "Containerization" 문서: [https://developer.apple.com/documentation/virtualization](https://developer.apple.com/documentation/virtualization)

- WWDC25 세션 "Meet Container Framework": [https://developer.apple.com/videos/play/wwdc2025/](https://developer.apple.com/videos/play/wwdc2025/)

**그 외 컨테이너 빌더**

- kaniko 깃허브: [https://github.com/GoogleContainerTools/kaniko](https://github.com/GoogleContainerTools/kaniko)

- ko 깃허브: [https://github.com/ko-build/ko](https://github.com/ko-build/ko)

**닫는 글**

도커는 2013년에 컨테이너의 사용성을 열었다. 그것은 위대한 일이었다. 2021년 도커는 자기 제품의 유료화로 생태계에 균열을 만들었고, 그 균열이 5년 동안 7개의 다른 도구를 키웠다. 2026년의 결과는 명확하다. **선택지가 많아졌고, 컨테이너 사용자가 이긴다**.

내일 새 프로젝트를 시작한다면 나는 이렇게 결정한다. 1인 맥 개발이면 OrbStack(빠름) 또는 Colima(무료). 회사 규모면 Podman Desktop 또는 Rancher Desktop. AWS 위주면 Finch. 그리고 Apple Container를 일주일에 한 번씩 만져 보면서 미래를 준비한다.

5년 뒤 이 글의 표는 다시 바뀌어 있을 것이다. 그러나 "도커가 표준이 아니다, 도구 선택은 팀의 맥락이다"라는 명제는 더 이상 후퇴하지 않는다.