Docker Desktop, 아직도 쓰세요? 2026년 컨테이너 런타임 완벽 비교 가이드

1. 문제 상황: Docker Desktop이 내 Mac을 잡아먹고 있다

16GB MacBook에서 개발 중이었습니다. 프로젝트 빌드를 돌리려는데 터미널이 멈추고, 브라우저 탭이 하나둘 죽어가기 시작했습니다.

범인을 찾기 위해 top을 열었습니다:

top -l 1 -o MEM -n 5 | tail -6

결과는 충격적이었습니다:

PID    COMMAND              MEM
23082  com.apple.Virtua     8086M   ← Docker Desktop VM
80225  cmux                 1619M
404    WindowServer         604M

com.apple.Virtualization이 8GB를 차지하고 있었습니다. 16GB 중 절반이 Docker Desktop의 Linux VM에 고정 할당되어 있었던 겁니다. 컨테이너를 하나도 안 돌리고 있는데도요.

이건 Docker Desktop의 고질적인 문제입니다. macOS에서 Linux 컨테이너를 돌리려면 VM이 필요한데, Docker Desktop은 이 VM에 메모리를 고정 할당합니다. 사용하든 안 하든 OS에 돌려주지 않습니다.

Docker Desktop 메모리 구조:
┌─────────────────────────────────┐
│          macOS Host             │
│  ┌───────────────────────────┐  │
│  │   Linux VM (고정 8GB)      │  │
│  │  ┌─────┐ ┌─────┐         │  │
│  │  │ 컨테│ │ 컨테│  빈 공간  │  │
│  │  │ 이너│ │ 이너│ (반환 안됨)│  │
│  │  └─────┘ └─────┘         │  │
│  └───────────────────────────┘  │
│  남은 메모리: 8GB               │
└─────────────────────────────────┘

그리고 또 하나 — Docker Desktop은 유료입니다. 2024년 말 가격 인상 이후, 팀 플랜 기준 $15~16/user/월입니다. 250명 이상 기업은 의무 구독이고요.

이 시점에서 저는 질문을 던졌습니다: "Docker Desktop 말고 다른 선택지가 있지 않나?"

있었습니다. 그것도 여러 개.

2. 대안 총정리: 5가지 컨테이너 런타임 비교

2026년 현재, macOS에서 사용 가능한 Docker Desktop 대안은 다섯 가지입니다:

하나씩 살펴보겠습니다.

3. OrbStack — "Docker Desktop을 그냥 바꿔 끼우세요"

왜 OrbStack인가

OrbStack의 핵심 가치는 한 문장으로 요약됩니다: Docker Desktop의 모든 명령어가 그대로 작동하면서, 메모리는 1/10만 쓴다.

설치는 한 줄입니다:

brew install --cask orbstack

설치 후 Docker Desktop을 종료하면 끝입니다. docker, docker compose 명령어가 OrbStack 엔진으로 자동 전환됩니다.

# 전환 확인
docker info | head -3
# Client:
#  Version:    28.5.2
#  Context:    orbstack     ← OrbStack으로 전환됨

메모리 비교: 실측

제가 직접 측정한 결과입니다:

Docker Desktop (유휴 상태):
  com.apple.Virtualization    8,086 MB  ← VM 고정 할당

OrbStack (유휴 상태):
  OrbStack Helper               634 MB  ← 동적 할당

차이: 8,086MB → 634MB (87% 감소)

OrbStack이 이렇게 적게 쓸 수 있는 이유는 동적 메모리 관리 때문입니다. 컨테이너가 메모리를 요청하면 할당하고, 해제하면 OS에 돌려줍니다. Docker Desktop의 VM은 한번 잡으면 안 놓습니다.

OrbStack 메모리 구조:
┌─────────────────────────────────┐
│          macOS Host             │
│  ┌──────────┐                   │
│  │ OrbStack │ ← 필요한 만큼만   │
│  │ ┌─────┐  │                   │
│  │ │컨테 │  │   OS에 반환된      │
│  │ │이너 │  │   메모리 공간      │
│  │ └─────┘  │                   │
│  └──────────┘                   │
│  남은 메모리: 15GB+             │
└─────────────────────────────────┘

성능 벤치마크

OrbStack은 메모리만 적게 쓰는 게 아닙니다:

OrbStack의 한계

• macOS 전용 — Windows/Linux 팀원과 동일 환경 불가
• 상업용 유료 — 개인은 무료, 상업용은 $8/user/월 (연간 $96, 최대 5대 기기)
• 벤더 종속 — 오픈소스가 아니므로 서비스 종료 리스크

상세 라이센스 조건:

• 프리랜서, 영리/비영리 법인, 정부기관은 라이센스 필요
• 개인이라도 OrbStack 사용과 관련된 연 수입이 $10,000을 초과하면 라이센스 필요
• 설치 시 30일 Pro 체험판 자동 시작
• Docker Desktop($16/user/월)의 절반 가격

실무 팁: Docker Compose 프로젝트 마이그레이션

기존 Docker Compose 프로젝트를 OrbStack으로 옮길 때 주의점이 있습니다. 대부분은 그냥 동작하지만, .env 파일 로딩 방식에서 차이가 날 수 있습니다.

제가 겪은 사례입니다. Plane(프로젝트 관리 도구)을 Docker Compose로 셀프호스팅할 때, 설정 파일이 plane.env라는 이름이었습니다. Docker Compose는 기본적으로 .env만 자동 로드하므로:

# plane.env → .env 심볼릭 링크 생성
ln -s plane.env .env

# 이후 docker compose up -d 정상 동작
docker compose up -d

이런 종류의 문제는 Docker Desktop에서도 동일하게 발생하지만, 런타임 전환 시점에 발견되는 경우가 많습니다.

4. Colima — "무료이고 가볍고 터미널이면 충분해요"

Colima는 Lima VM 위에서 Docker/containerd를 실행하는 CLI 전용 도구입니다. GUI가 없고, 설정 파일로 관리합니다.

설치와 실행

# 설치
brew install colima docker

# 기본 시작
colima start

# Apple Silicon 최적 설정 (권장)
colima start \
  --cpu 4 \
  --memory 8 \
  --disk 60 \
  --vm-type vz \
  --vz-rosetta \
  --mount-type virtiofs

# Docker 명령어 그대로 사용
docker ps
docker compose up -d

각 옵션의 의미:

• --vm-type vz — macOS 13+ Virtualization.framework 사용 (QEMU 대신)
• --vz-rosetta — x86_64 이미지를 Apple Silicon에서 Rosetta로 실행
• --mount-type virtiofs — 파일 공유 성능 2~3배 향상 (gRPC-FUSE 대비)

Colima의 장점

• 완전 무료 — Apache 2.0 라이센스, 상업용도 포함
• 가벼움 — 유휴 시 ~400MB
• 설정 투명 — ~/.colima/default/colima.yaml에서 모든 설정 관리

# ~/.colima/default/colima.yaml
cpu: 4
memory: 8
disk: 60
runtime: docker        # 또는 containerd
vmType: vz             # macOS 13+ 네이티브 가상화
mountType: virtiofs    # 파일 공유 성능 최상
rosetta: true          # x86_64 이미지 지원
network:
  address: true        # 고정 IP 할당

파일 I/O 성능 (2026 기준)

virtiofs + vz 조합 기준:

• 읽기: 네이티브 파일시스템의 70~90%
• 쓰기: 네이티브의 60~80%
• gRPC-FUSE 대비 2~3배 빠름

Colima의 한계

• GUI 없음 — 시각적 컨테이너 관리를 원하면 불편
• 파일 마운트 성능 — virtiofs를 써도 OrbStack(2~10x 빠름)보다는 느림
• 수동 시작 — colima start를 매번 실행해야 함

# 자동 시작 설정 (launchd)
brew services start colima

5. Podman Desktop — "데몬 없이, 루트 없이"

Podman은 Docker와 완전히 다른 아키텍처를 가집니다. 중앙 데몬이 없습니다.

Docker 아키텍처:
  사용자 → Docker CLI → Docker Daemon (root) → 컨테이너들
                            ↑ 단일 장애점

Podman 아키텍처:
  사용자 → Podman CLI → 컨테이너 (fork/exec)
                         ↑ 데몬 없음, 각 컨테이너가 독립 프로세스

설치와 사용

# 설치
brew install --cask podman-desktop

# Podman machine 초기화 (macOS에서는 VM 필요)
podman machine init
podman machine start

# Docker 호환 명령어
podman run -d nginx
podman ps
podman compose up -d    # podman-compose 별도 설치 필요할 수 있음

Docker CLI와의 호환성

Podman은 docker 명령어를 그대로 사용할 수 있도록 alias를 제공합니다:

# docker 명령어로 podman 사용
alias docker=podman

# 또는 podman-docker 패키지 설치
brew install podman-docker

하지만 Docker Compose와의 호환성은 완벽하지 않습니다. 특히 복잡한 네트워킹이나 볼륨 설정에서 차이가 발생할 수 있습니다.

# Docker Compose → Podman Compose
# 대부분 동작하지만, 네트워크 DNS 해석에서 차이 발생 가능
podman compose up -d

# 서비스 간 통신이 안 되면:
# - Pod 기반 네트워킹 확인
# - 또는 --network host 사용

Podman의 장점

• 보안 — 루트리스 실행이 기본, 데몬 없어서 공격 표면 최소
• 완전 무료 — Apache 2.0, 상업용 무제한
• Kubernetes 네이티브 — Pod 개념을 직접 지원, K8s YAML 생성 가능

# Podman → Kubernetes YAML 자동 생성
podman generate kube my-container > deployment.yaml

• 빠른 시작 — 데몬 오버헤드 없이 컨테이너 시작이 최대 30% 빠름

최근 업데이트 (v1.22, 2025.10)

Podman Desktop v1.22부터 macOS에서 rootless/rootful 모드 전환이 GUI에서 가능해졌습니다. 기존에는 machine 재생성이 필요했던 작업이 클릭 한 번으로 가능합니다.

# 모드 확인
podman machine inspect --format '{{.Rootful}}'

# rootless → rootful 전환 (특정 포트 바인딩 필요 시)
podman machine set --rootful

Podman의 한계

• Docker Compose 호환성 — 복잡한 compose 파일에서 미묘한 차이 발생 (특히 네트워크 DNS)
• macOS 파일 마운트 — I/O 집약적 워크로드에서 5~10% 느림
• 생태계 — Docker Hub 14M+ 이미지와의 호환은 되지만, 도구 통합(CI/CD 등)에서 추가 설정 필요

6. Rancher Desktop — "Kubernetes가 주인공"

Rancher Desktop은 Kubernetes 로컬 개발에 초점을 맞춘 도구입니다. Docker 실행도 가능하지만, K8s가 핵심입니다.

# 설치
brew install --cask rancher

# 시작 시 K8s 버전 선택 가능
# containerd 또는 dockerd 선택

Rancher Desktop의 특징

• Kubernetes 버전을 UI에서 선택 가능 (1.28, 1.29, 1.30 등)
• containerd와 dockerd 런타임 전환 가능
• nerdctl(containerd 호환 CLI) 또는 docker CLI 사용
• 완전 무료 — SUSE 지원 오픈소스

최근 개선 (2026)

• macOS 기본값이 VZ + virtiofs로 전환 — QEMU가 기본이던 시절보다 성능 대폭 향상
• Helm 4.0 내장
• 볼륨 관리 UI 추가 (목록 조회/삭제)
• rdctl reset 명령 추가 (factory-reset보다 세밀한 제어)

# Rancher Desktop 기본 도구들
docker ps          # dockerd 런타임 사용 시
nerdctl ps         # containerd 런타임 사용 시
kubectl get pods   # K8s 클러스터 관리
helm list          # v4.0 내장

누구에게 적합한가

• K8s 매니페스트를 로컬에서 테스트하는 DevOps 엔지니어
• Helm 차트를 개발/디버깅하는 팀
• 프로덕션 K8s와 동일한 로컬 환경이 필요한 경우

단순히 docker compose up으로 개발하는 용도라면 오버킬입니다.

7. Apple Container — "예상보다 빠르게 다가오는 네이티브"

2025년 WWDC에서 Apple이 발표한 네이티브 컨테이너 런타임입니다. Swift로 작성되었고, Apple Silicon에 최적화되어 있습니다. 그리고 생각보다 훨씬 빠르게 발전하고 있습니다.

# macOS 15 Sequoia에서도 기본 동작 가능
# macOS 26 Tahoe에서 전체 기능 지원
# 현재 v0.11.0 (2026.03.31) — 월 1회 릴리스 페이스

container run ubuntu

아키텍처의 차이

Docker Desktop과 Apple Container의 근본적인 차이는 VM 공유 방식입니다:

Docker Desktop:
  하나의 큰 VM ─── 컨테이너 A
                 ├── 컨테이너 B
                 └── 컨테이너 C

Apple Container:
  마이크로 VM A ─── 컨테이너 A
  마이크로 VM B ─── 컨테이너 B
  마이크로 VM C ─── 컨테이너 C

컨테이너마다 독립된 경량 VM을 사용하므로 격리가 완벽합니다. 하나의 컨테이너 VM이 죽어도 다른 컨테이너에 영향이 없습니다.

발전 속도: 월 1회 릴리스

Apple Container는 2024년 10월 첫 릴리스 이후 약 6개월 만에 11번의 릴리스를 쏟아냈습니다. 주요 마일스톤:

6개월 전에는 "Dockerfile도 못 빌드한다"였지만, 지금은 볼륨, 네트워킹, 포트포워딩, Dockerfile 빌드가 모두 동작합니다.

현재 남은 갭 (v0.11 기준)

• Docker Compose 미지원 — 커뮤니티 프로젝트 Container-Compose가 대안
• Apple Silicon 전용 — Intel Mac 미지원
• 1.0 미달 — 마이너 버전 간 breaking change 가능

전망

이 릴리스 속도면 2026년 하반기~2027년 초에 1.0 도달이 현실적입니다. Docker Compose 호환이 공식 지원되는 시점이 실무 전환의 티핑 포인트가 될 것입니다. Apple이 macOS 26에서 Containerization 프레임워크를 OS 레벨로 내장하는 만큼, 장기적으로는 Mac에서 가장 자연스러운 선택이 될 가능성이 높습니다.

[2026-06 업데이트] Apple Container는 이후 v1.0.0에 도달했습니다. 다만 네이티브 Docker Compose 지원은 여전히 비공식입니다.

8. 핵심 비교 테이블

성능 비교

기능 비교

가격 비교 (2026년 4월 기준)

핵심 포인트:

• Docker Desktop은 250명 이상 기업에서는 유료 라이센스 필수
• OrbStack은 Docker Desktop Team($16) 대비 50% 저렴
• 나머지 4개는 상업용도 완전 무료

9. 상황별 추천

"나는 Mac 개발자고, Docker Compose를 매일 쓴다"

→ OrbStack

가장 마찰이 적습니다. brew install --cask orbstack 한 줄이면 끝이고, 기존 Docker Compose 프로젝트가 수정 없이 동작합니다. 메모리와 성능 차이는 체감됩니다.

"무료가 최우선이고, 터미널이 편하다"

→ Colima

GUI가 필요 없고 docker와 docker compose만 쓴다면 Colima가 최선입니다. 완전 무료이고 메모리도 적게 먹습니다.

"보안이 중요하고, 프로덕션 K8s와 맞춰야 한다"

→ Podman Desktop

루트리스 실행과 데몬리스 아키텍처가 필요하다면 Podman이 유일한 선택입니다. 특히 Red Hat/OpenShift 인프라를 쓰는 조직이라면 자연스럽게 맞습니다.

"로컬에서 K8s 클러스터를 돌려야 한다"

→ Rancher Desktop

K8s 버전을 자유롭게 전환하면서 Helm 차트를 테스트해야 한다면 Rancher Desktop이 가장 적합합니다.

"Mac에서 가장 네이티브한 경험을 원한다"

→ Apple Container (Compose 지원 시점부터)

v0.11 시점에서 Dockerfile 빌드, 볼륨, 포트포워딩이 모두 동작합니다. 단일 컨테이너 개발이라면 지금도 쓸 수 있고, 멀티 서비스 프로젝트는 공식 Compose 지원(1.0 예상)을 기다리는 게 현실적입니다. macOS 26 + Apple Silicon 조합에서 가장 가볍고 빠른 런타임이 될 강력한 후보입니다.

10. 마이그레이션 체크리스트

Docker Desktop에서 다른 런타임으로 전환할 때 확인할 사항입니다:

OrbStack으로 전환 시

# 1. OrbStack 설치
brew install --cask orbstack

# 2. OrbStack 앱 실행 → 초기 설정 완료

# 3. Docker Desktop 종료 (메뉴바 → Quit)

# 4. 전환 확인
docker info | grep Context
# Context: orbstack

# 5. 기존 프로젝트 테스트
cd your-project
docker compose up -d
docker compose ps

Colima로 전환 시

# 1. Colima + Docker CLI 설치
brew install colima docker docker-compose

# 2. Docker Desktop 종료

# 3. Colima 시작
colima start --cpu 4 --memory 4

# 4. Docker context 설정
docker context use colima

# 5. 테스트
docker compose up -d

Podman으로 전환 시

# 1. Podman Desktop 설치
brew install --cask podman-desktop

# 2. Podman machine 초기화
podman machine init --cpus 4 --memory 4096
podman machine start

# 3. Docker 호환 alias 설정
echo 'alias docker=podman' >> ~/.zshrc
source ~/.zshrc

# 4. Docker Compose 호환 (podman-compose 설치)
pip install podman-compose

# 5. 테스트 — compose 파일 호환성 확인 필수
podman compose up -d

11. 베스트 프랙티스

Docker Desktop 대안을 사용할 때의 체크리스트입니다:

• [ ] 전환 전에 Docker Desktop의 이미지/볼륨 백업 — OrbStack은 마이그레이션을 제안하지만, 수동 백업이 안전합니다
• [ ] .env 파일 로딩 확인 — Docker Compose의 env_file 경로가 런타임마다 다르게 해석될 수 있습니다
• [ ] 포트 바인딩 테스트 — 특히 0.0.0.0 vs localhost 바인딩 차이
• [ ] 파일 마운트 성능 확인 — I/O 집약적 프로젝트(Next.js HMR 등)는 런타임별 차이가 큽니다
• [ ] CI/CD 파이프라인과 일치 — 로컬과 CI 환경의 런타임이 다르면 재현 불가능한 버그 발생
• [ ] 팀 전체 통일 — 한 팀에서 여러 런타임을 혼용하면 "내 컴에선 되는데" 문제 발생

12. FAQ

Q: OrbStack은 Docker Desktop과 100% 호환되나요?
A: docker, docker compose 명령어는 그대로 동작합니다. Docker Extensions는 지원하지 않습니다. 99%의 사용 시나리오에서 호환됩니다.

Q: Podman으로 Docker Compose 파일을 그대로 쓸 수 있나요?
A: 대부분 동작하지만, 복잡한 네트워킹(서비스 간 DNS, depends_on healthcheck 등)에서 차이가 발생할 수 있습니다. 단일 컨테이너는 문제 없고, 13개 서비스가 엮인 환경에서는 테스트가 필요합니다.

Q: Apple Container는 언제 실무에서 쓸 수 있나요?
A: 현재 v0.11.0(2026.03)으로 Dockerfile 빌드, 볼륨, 포트포워딩, Rosetta 모두 지원합니다. Docker Compose 미지원이 실무 전환의 가장 큰 걸림돌이지만, 월 1회 릴리스 속도면 2026년 하반기~2027년 초에 1.0 도달 + Compose 지원이 현실적입니다.

Q: Docker Desktop을 아예 삭제해도 괜찮나요?
A: OrbStack이나 Colima로 전환한 후에는 삭제해도 됩니다. 다만 Docker Desktop만 지원하는 Extensions를 사용 중이라면 확인이 필요합니다.

Q: 어떤 대안이 가장 안정적인가요?
A: OrbStack이 가장 안정적입니다. macOS 네이티브 앱으로 Docker Desktop과 동일한 수준의 완성도를 제공합니다. Colima는 간헐적으로 VM이 멈추는 이슈가 보고됩니다.

13. 참고 자료

• OrbStack 공식 사이트
• OrbStack 동적 메모리 블로그
• Colima GitHub
• Podman Desktop 공식 사이트
• Rancher Desktop 공식 사이트
• Apple Container GitHub
• Docker Desktop 가격 페이지