Docker Desktop 대안 비교 2026: OrbStack·Rancher·Podman 선택 가이드

어느 날 법무팀에서 온 메일 한 통

"우리 회사, Docker Desktop 유료 라이선스 대상인지 확인 부탁드립니다."

국내 개발팀 리드가 가장 곤란해하는 메일 중 하나입니다. Docker 구독 약관상 Docker Desktop은 직원 250명 미만이면서 연매출 1,000만 달러 미만인 소규모 사업자와 개인·교육·비상업 오픈소스 용도에는 무료이고, 그 밖의 조직이 업무에 쓰려면 Pro·Team·Business 중 하나의 유료 구독이 필요합니다(2026-10 확인). Docker Desktop license agreement 계열사 합산처럼 해석이 필요한 부분은 약관 원문과 법무 검토로 판정하세요. 이 글의 금액은 2026-10 기준 공개 가격으로 계산 방법을 보여 주는 예시이며 환율·세금·할인은 반영하지 않았습니다.

문제는 "그럼 무료 대안 쓰죠"가 생각보다 간단하지 않다는 점입니다. Testcontainers를 쓰는 통합 테스트가 깨지고, /var/run/docker.sock을 하드코딩한 사내 스크립트가 멈추고, macOS에서 node_modules 볼륨 마운트 성능이 체감으로 달라집니다. 라이선스비 몇 백만 원을 아끼려다 개발자 20명의 하루를 태우면 손익이 뒤집힙니다.

이 글은 다음 5가지 질문에 답합니다.

1. 우리 팀 조건에서 어떤 도구를 골라야 하는가 (30초 판정표)
2. 실제로 돈이 얼마나 절약되는가 (팀 규모별 TCO 계산식)
3. 성능·호환성은 어디까지 감수해야 하는가 (9개 항목 비교)
4. 어떤 명령으로 옮기는가 (마이그레이션 런북)
5. 오히려 Docker Desktop을 유지해야 하는 경우는 언제인가

30초 선택 판정표: 결론부터 봅니다

아래 트리를 위에서부터 따라가세요.

Q1. 우리 조직이 Docker Desktop 유료 라이선스 적용 대상인가?
    (직원 250명 이상 또는 연매출 1,000만 달러 이상이면 대상 — 약관 원문 확인)
 ├─ NO  → 그대로 무료 사용. 이 글의 나머지는 "성능 튜닝 참고용"으로만 보세요.
 └─ YES → Q2로

Q2. 팀의 주력 OS는?
 ├─ macOS (Apple Silicon) → Q3으로  (OrbStack 유력)
 ├─ macOS (Intel)         → Q3으로  (OrbStack 이점 축소, Rancher 경쟁력 상승)
 └─ Windows + WSL2        → Q3으로  (OrbStack 제외, Rancher/Podman 2파전)

Q3. 로컬에 쿠버네티스 클러스터가 상시 필요한가?
 ├─ YES → 결론 B (Rancher Desktop)
 └─ NO  → Q4로

Q4. 회사 정책상 해외 상용 SaaS 구독 결제가 가능한가?
 ├─ YES → 결론 A (OrbStack)
 └─ NO  → 결론 C (Podman Desktop)

결론 한 줄 근거

보조 선택지: GUI가 필요 없다면 colima

CLI만 쓰고 GUI 대시보드가 전혀 필요 없는 팀이라면 colima가 가장 가벼운 답입니다. Homebrew로 설치하고 colima start면 끝이며, docker CLI와 그대로 붙습니다.

brew install colima docker docker-compose
colima start --cpu 4 --memory 8 --vm-type vz --mount-type virtiofs
docker context use colima
docker run --rm hello-world

정상 결과: Hello from Docker! 문구가 출력됩니다. 실패하면 colima status로 VM이 Running인지 먼저 확인하세요. --vm-type vz는 macOS 13 이상의 Apple Virtualization.framework를 씁니다. 또 colima는 기본적으로 홈 디렉터리(/Users/$USER)만 VM에 마운트하므로, 그 밖의 경로를 바인드 마운트하면 오류 없이 빈 디렉터리가 보입니다. 이때는 ~/.colima/default/colima.yaml의 mounts에 경로를 추가하고 colima restart합니다. colima FAQ 단점은 GUI 부재, 문제 발생 시 로그를 직접 파야 한다는 점, 그리고 팀원 중 비-CLI 사용자가 있으면 지원 부담이 커진다는 점입니다.

가격·약관 확인일: 2026-10. 가격·버전·라이선스 조건은 바뀌므로 적용 전 공식 문서를 다시 확인하세요.

돈 계산: 5인·20인·50인 TCO 비교

무료 도구의 진짜 비용은 공수입니다. 아래 계산은 다음 식을 씁니다.

상용 도구 연간 비용 = 1인당 월 단가 × 개발자 수 × 12 + 전환 시간 × 개발자 수 × 시급
오픈소스 연간 비용 = (초기 세팅 시간 + 연간 트러블슈팅 시간) × 개발자 수 × 시급

가정값(모두 예시입니다):

• 개발자 시급: 60,000원 (연봉 환산 기준의 대략적 가정)
• 환율: 1달러 = 1,400원
• Docker Desktop: 회사에서 여러 명이 쓰면 Team(연 결제 1인당 월 $15, 최대 100명) 또는 Business(1인당 월 $24)가 현실적입니다. Pro($9)는 1인 구독입니다. 아래 표는 Team $15 ≈ 21,000원으로 계산합니다. Docker pricing
• OrbStack: 상업적 사용은 Pro 1인당 월 $8(연 $96) ≈ 11,000원 OrbStack pricing. 상용 도구라도 설치·검증 시간이 들므로 전환 시간 1인당 1시간을 넣습니다. 연간 트러블슈팅은 현재 쓰는 Docker Desktop과 비슷하다고 보고 0으로 둡니다.
• 오픈소스 초기 세팅: 1인당 3시간, 연간 트러블슈팅: 1인당 6시간 → 총 9시간

5인 팀

20인 팀

50인 팀

Docker Business($24)로 계산하면 50인 기준 연 20,160,000원입니다. 단가는 2026-10 공개 가격, 공수는 가정값입니다.

이 표를 어떻게 읽어야 하나

숫자만 보면 "무료 도구가 더 비싸다"는 역설이 나옵니다. 하지만 여기엔 중요한 조건이 붙습니다.

• 공수는 1회성 성격이 강합니다. 초기 3시간은 첫해만 발생하고, 사내 표준 설치 스크립트를 만들어 배포하면 1인당 20분으로 줄어듭니다. 그러면 50인 팀 2년차 비용은 (0.33h + 6h) × 50 × 60,000 ≈ 1,900만 원이 아니라, 트러블슈팅 시간을 절반으로 줄였을 때 3h × 50 × 60,000 = 900만 원 수준까지 내려갑니다.
• 반대로 라이선스비는 매년 그대로 나갑니다. 2년차부터의 손익분기는 다음 식으로 바로 계산할 수 있습니다. 손익분기 연간 트러블슈팅 시간(1인) = 1인당 월 단가 × 12 ÷ 시급 Team 기준 21,000 × 12 ÷ 60,000 = 4.2시간입니다. 오픈소스 전환 후 1인당 연간 트러블슈팅이 4.2시간보다 적으면 2년차부터 오픈소스가 싸고, 많으면 계속 비쌉니다. Business 기준이면 33,600 × 12 ÷ 60,000 ≈ 6.7시간입니다.
• 가정한 공수 시간이 현실과 다르면 결론이 뒤집힙니다. 팀에 컨테이너 숙련자가 있으면 트러블슈팅 시간이 1~2시간으로 떨어지고, 반대로 Testcontainers·복잡한 compose 스택을 쓰면 20시간을 넘길 수도 있습니다.

핵심 결론: 무료가 항상 싸지 않습니다. 표를 그대로 베끼지 말고, 위 계산식에 여러분 팀의 실제 시급과 예상 공수를 넣어 다시 계산하세요. 비용 비교 방법론 자체는 GitHub Actions vs GitLab CI 요금 비교: 3개 시나리오 실전 계산에서 다룬 접근과 동일합니다.

성능·사용성 9개 항목 비교

측정 환경 고지

아래 표는 일반적으로 보고되는 경향과 각 도구의 아키텍처적 특성을 정리한 것입니다. 절대 수치가 아니라 상대적 경향으로 읽어야 하며, 정확한 값은 반드시 여러분의 실제 머신과 워크로드에서 직접 측정해야 합니다.

• 기준 환경 가정: macOS Apple Silicon (M계열), 메모리 16GB, VM 할당 4 vCPU / 8GB
• 워크로드 가정: Node.js 프로젝트(node_modules 수만 개 파일) 바인드 마운트, node:20-alpine 기반 이미지 빌드
• 수치는 머신 사양·디스크 상태·이미지 캐시 유무에 따라 크게 달라집니다

측정을 직접 하고 싶다면 아래처럼 최소한의 재현 스크립트를 돌리세요.

# 1) 런타임 기동 시간: 도구를 완전히 종료한 뒤, 비교할 도구의 시작 명령 한 줄만 남기고 실행
start=$(date +%s)
docker desktop start          # 또는: open -a OrbStack / colima start / podman machine start / rdctl start
until docker info >/dev/null 2>&1; do sleep 1; done
echo "ready in $(( $(date +%s) - start ))s"

# 2) 바인드 마운트 파일 I/O: 홈 디렉터리 아래에서 실행(colima 기본 마운트 범위)
mkdir -p ~/iotest && cd ~/iotest
time docker run --rm -v "$PWD":/w -w /w alpine \
  sh -c 'for i in $(seq 1 5000); do echo x > f_$i; done'
cd ~ && rm -rf ~/iotest

# 3) 빌드 시간 (캐시 없이, 같은 Dockerfile로 도구마다 비교)
time docker build --no-cache -t bench:local .

읽는 법: time은 호스트 셸에서 재므로 컨테이너 시작 시간까지 포함됩니다. 절대값보다 같은 머신에서 도구별로 3회씩 잰 중앙값을 비교하세요. 1번이 끝나지 않고 계속 기다리면 docker context ls로 현재 컨텍스트가 방금 시작한 도구를 가리키는지 확인합니다. docker desktop start는 Docker Desktop CLI가 들어 있는 버전에서만 동작합니다. Docker Desktop CLI 예전 판의 time docker info는 이미 떠 있는 데몬의 응답 시간만 재므로 기동 시간 측정이 아니었고, 컨테이너 안의 time ( ... )은 alpine의 기본 셸에서 동작하지 않아 이번에 바꿨습니다.

볼륨 마운트 방식이 성능에 미치는 영향은 Docker 볼륨 vs 바인드마운트 — 데이터 영속성 완전 가이드에서 개념부터 정리해 두었습니다.

마이그레이션 런북

1단계: 현재 상태 백업

# 이미지 목록 저장
docker images --format '{{.Repository}}:{{.Tag}}' > images.txt

# 중요한 이미지 아카이브
docker save -o backup-images.tar $(cat images.txt | grep -v '<none>' | tr '\n' ' ')

# 볼륨 백업 (볼륨명 my_data 예시)
docker run --rm -v my_data:/src -v "$PWD":/dst alpine \
  tar czf /dst/my_data.tgz -C /src .

정상 결과: backup-images.tar와 my_data.tgz 파일이 생성됩니다. tar: /src: Cannot open 오류가 나면 볼륨명이 틀린 것이므로 docker volume ls로 정확한 이름을 확인하세요.

2단계: 새 런타임 연결

# --- OrbStack / colima 계열 ---
docker context ls
docker context use orbstack        # 또는 colima
docker version                     # Server 섹션이 표시되면 성공

# --- Rancher Desktop ---
docker context use rancher-desktop
nerdctl ps                         # containerd 백엔드 사용 시

# --- Podman ---
podman machine init --cpus 4 --memory 8192
podman machine start
podman system connection list

# docker CLI를 그대로 쓰고 싶을 때: 소켓 경로를 환경변수로 지정
export DOCKER_HOST="unix://$(podman machine inspect --format '{{.ConnectionInfo.PodmanSocket.Path}}')"
docker ps                          # podman 백엔드로 응답

DOCKER_HOST는 ~/.zshrc에 넣어 팀 전체에 배포하면 됩니다. 다만 컨텍스트와 환경변수를 동시에 쓰면 충돌하므로 한 가지 방식만 선택하세요.

3단계: 이미지·볼륨 복원

docker load -i backup-images.tar
docker volume create my_data
docker run --rm -v my_data:/dst -v "$PWD":/src alpine \
  tar xzf /src/my_data.tgz -C /dst

4단계: compose 실행 확인

# Podman
podman compose up -d
# Rancher Desktop (containerd 백엔드)
nerdctl compose up -d
# OrbStack / colima
docker compose up -d

자주 깨지는 5가지와 우회법

① compose 파일 문법 차이

podman compose는 내부적으로 외부 compose 구현을 호출하며, depends_on의 condition, extends, 일부 x- 확장 필드에서 동작 차이가 보고됩니다.

• 증상: unsupported key 또는 서비스 기동 순서가 뒤엉킴
• 우회: podman-compose 대신 docker-compose 바이너리 + DOCKER_HOST 조합을 쓰거나, depends_on 대신 애플리케이션 레벨 재시도 로직으로 대체

② /var/run/docker.sock 하드코딩과 Testcontainers

가장 자주 발목을 잡는 지점입니다. CI 스크립트, Testcontainers, 일부 IDE 플러그인이 소켓 경로를 고정해 두고 있습니다.

macOS에서 /var/run/docker.sock을 직접 ln -sf로 만들면 재부팅·머신 재생성 때 깨집니다. Podman 공식 설치 패키지는 이 링크를 관리하는 podman-mac-helper를 함께 설치합니다. Homebrew 등으로 설치해 링크가 없다면 한 번 실행합니다(관리자 권한 필요, 공식 패키지 경로는 /opt/podman/bin).

sudo podman-mac-helper install
podman machine stop && podman machine start
ls -l /var/run/docker.sock          # podman.sock을 가리키면 정상

Testcontainers는 공식 문서의 Podman 설정을 환경변수로 줍니다.

# macOS
export DOCKER_HOST="unix://$(podman machine inspect --format '{{.ConnectionInfo.PodmanSocket.Path}}')"
export TESTCONTAINERS_DOCKER_SOCKET_OVERRIDE=/var/run/docker.sock
# Linux rootless Podman
export DOCKER_HOST="unix://${XDG_RUNTIME_DIR}/podman/podman.sock"
export TESTCONTAINERS_RYUK_DISABLED=true

rootless Podman에서는 공식 문서대로 Ryuk(정리 컨테이너)을 꺼야 합니다. 이 경우 테스트가 끝난 컨테이너가 자동으로 정리되지 않으므로 CI에 정리 단계(예: 라벨 org.testcontainers=true 컨테이너 삭제)를 둡니다. 예전에 쓰던 ryuk.container.privileged=true는 Testcontainers for Java 1.19.0부터 필요 없습니다. Testcontainers: 지원 런타임

③ 파일 권한과 uid 매핑

rootless 환경에서는 컨테이너 내부 uid가 호스트 uid로 그대로 매핑되지 않습니다.

• 증상: 바인드 마운트한 디렉터리에 Permission denied
• 우회: --userns=keep-id 옵션 사용, 또는 Dockerfile에서 USER를 호스트 uid와 맞춤

podman run --rm --userns=keep-id -v "$PWD":/w:Z -w /w alpine touch test.txt

SELinux가 켜진 환경(주로 Linux)에서는 :Z 라벨이 필수입니다. macOS에서는 무시됩니다.

④ DNS·포트 포워딩 차이

컨테이너 간 이름 해석과 host.docker.internal 동작이 도구마다 다릅니다.

• Podman: host.containers.internal을 사용하며, --add-host=host.docker.internal:host-gateway로 별칭 추가 가능
• Rancher Desktop: 포트가 자동 노출되지 않는 설정이 있으므로 GUI의 네트워크 설정 확인

podman run --rm --add-host=host.docker.internal:host-gateway alpine \
  ping -c1 host.docker.internal

⑤ buildx 빌더 부재

멀티 아키텍처 빌드(--platform linux/amd64,linux/arm64)를 쓰던 팀은 대체 경로가 필요합니다.

# Podman: 매니페스트 방식
podman build --platform linux/amd64 -t app:amd64 .
podman build --platform linux/arm64 -t app:arm64 .
podman manifest create app:multi
podman manifest add app:multi app:amd64
podman manifest add app:multi app:arm64
podman manifest push app:multi docker://registry.example.com/app:multi

# Rancher Desktop: buildkit 직접 사용
nerdctl build --platform=amd64,arm64 -t app:multi .

가장 안전한 대안은 멀티아키 빌드를 로컬에서 하지 않고 CI로 옮기는 것입니다. 로컬 런타임 선택과 무관해지므로 마이그레이션 리스크가 사라집니다.

"그냥 Docker Desktop 유지"가 정답인 5가지 경우

솔직하게 말하면, 아래에 해당하면 전환하지 않는 편이 낫습니다.

1. Testcontainers 기반 통합 테스트가 핵심 파이프라인인 경우 — Ryuk, 소켓 경로, 권한 문제가 겹치면 디버깅 비용이 라이선스비를 금방 넘어섭니다.
2. 엔터프라이즈 보안 스캐닝·정책 관리 기능을 이미 쓰고 있는 경우 — 이미지 취약점 스캔, 레지스트리 접근 제어 같은 관리 기능은 무료 대안에서 별도 도구로 재구성해야 합니다.
3. 비개발 직군까지 도커를 쓰는 조직 — 기획자·QA가 GUI로 컨테이너를 켜고 끄는 환경이라면, CLI 의존도가 높은 대안은 지원 요청 폭증으로 이어집니다.
4. 벤더 지원 계약이 감사 요건인 경우 — 금융·공공 프로젝트에서 "공식 벤더 지원 여부"가 체크리스트에 있으면 오픈소스 전환이 오히려 감사 리스크가 됩니다.
5. 라이선스 대상 조직 안의 소규모 팀 — 대기업 계열사의 5인 팀이라면 Team 기준 연 126만 원을 아끼려고 45시간(시급 6만 원 가정 시 270만 원)을 쓰는 셈입니다. 단독 소규모 회사는 애초에 무료 대상일 수 있으니 약관 기준부터 확인하세요.

30일 전환 체크리스트

롤백 기준(하나라도 해당하면 Docker Desktop 유지):

• 파일럿 기간 중 1인당 트러블슈팅 시간이 8시간을 초과
• CI/CD 파이프라인이 로컬 런타임 차이로 실패
• 주력 프로젝트의 개발 사이클(빌드+테스트) 시간이 30% 이상 증가

자주 묻는 질문 (FAQ)

Q1. Docker Desktop 유료 라이선스 기준은 정확히 무엇인가요? A. 2026-10 기준 약관은 직원 250명 미만이면서 연매출 1,000만 달러 미만인 사업자, 개인·교육·비상업 오픈소스 용도를 무료로 두고, 그 밖의 업무용 사용에는 Pro·Team·Business 구독을 요구합니다. Docker Desktop license agreement 자회사·계열사 합산 여부처럼 해석이 갈리는 부분은 약관 원문을 기준으로 법무·구매 부서와 함께 판정하세요.

Q2. Podman Desktop으로 바꾸면 기존 docker 명령을 다시 배워야 하나요? A. 대부분 그대로 씁니다. podman은 docker CLI와 명령 호환성이 높고, alias docker=podman 또는 DOCKER_HOST 환경변수로 기존 스크립트를 유지할 수 있습니다. 다만 rootless 특성상 권한·네트워크 동작에서 차이가 나므로, 본문의 "자주 깨지는 5가지"를 사전에 점검하세요.

Q3. OrbStack은 Windows에서도 쓸 수 있나요? A. OrbStack은 macOS 전용입니다. Windows/WSL2 환경이 섞인 팀이라면 OS별로 다른 도구를 쓰거나, Rancher Desktop·Podman Desktop처럼 크로스 플랫폼을 지원하는 쪽으로 표준을 통일하는 편이 운영 부담이 적습니다.