Docker Desktop이 또 멈췄다면, 맥 개발자를 위한 진짜 대안들

"Docker Desktop 업데이트했더니 아예 안 켜져요." 주변 개발자 모임에서 이런 이야기를 너무 자주 듣습니다. macOS에서 Docker를 쓰는 개발자라면 한 번쯤은 Docker Desktop이 멈추거나, 맥북 팬이 미친 듯이 돌아가거나, 메모리를 4GB 이상 잡아먹고 놓아주지 않는 경험을 해봤을 겁니다. 저도 강의 중에 Docker Desktop이 응답 없음 상태가 되어 당황한 적이 있습니다. 수강생 앞에서 "잠깐만요, Docker가 좀..." 하면서 Activity Monitor를 여는 상황은 정말 피하고 싶습니다.

문제는 이게 개인적인 불운이 아니라는 점입니다. Docker 공식 GitHub 저장소의 이슈 목록을 보면, macOS에서 Docker Desktop의 안정성 문제는 구조적이고 반복적입니다. 2025년에도 커널 패닉으로 맥이 강제 재부팅되는 이슈가 올라왔고, 4.41.x 버전 업데이트 후 GUI가 아예 실행되지 않는 버그가 보고되었습니다. 여기에 2021년부터 시작된 기업 대상 유료화 정책까지 겹치면서, "Docker Desktop 말고 다른 건 없나?"라는 질문은 이제 macOS 개발 환경의 단골 주제가 되었습니다.

좋은 소식은 대안이 꽤 많다는 것입니다. 그리고 일부는 Docker Desktop보다 훨씬 가볍고 빠릅니다. 이 기사에서는 Docker Desktop의 구체적인 문제점을 짚은 뒤, Colima, OrbStack, Rancher Desktop, Podman 네 가지 대안을 직접 설치부터 docker-compose 실행까지 실전 중심으로 비교합니다. 어떤 상황에서 어떤 도구를 골라야 하는지도 다룹니다.

다음 그림은 macOS에서 Docker가 동작하는 구조와 네 가지 대안이 각각 어떤 가상화 레이어를 사용하는지를 보여줍니다.

macOS는 Linux 커널이 없으므로, Docker 컨테이너를 실행하려면 반드시 Linux 가상 머신이 필요합니다. Docker Desktop이든 Colima든 OrbStack이든, 이 VM 레이어를 어떻게 구현하느냐가 성능과 안정성의 핵심입니다. 각 도구가 선택한 가상화 방식의 차이를 이해하면, 아래에서 다룰 문제점과 대안 비교가 훨씬 명확해집니다.

Docker Desktop, 대체 뭐가 문제인가

Docker Desktop의 문제는 안정성, 자원 사용량, 라이선스 정책으로 나뉩니다.

안정성 문제: 버그가 아니라 구조적 한계

Docker Desktop의 macOS 이슈 트래커인 docker/for-mac 저장소를 보면, 단순한 버그 수준을 넘어서는 심각한 결함이 반복적으로 보고되고 있습니다.

가장 심각한 사례부터 봅시다. 이슈 #7664에 따르면 macOS 15.4.1과 Apple Silicon M1 조합에서 Docker Desktop 4.41 이상을 실행하면 커널 패닉이 발생하여 맥이 강제 재부팅되는 문제가 보고되었습니다. 컨테이너 하나 올리려다 운영체제 자체가 뻗어버리는 셈입니다. 이건 앱이 멈추는 수준이 아니라 시스템 전체가 다운되는 심각한 결함입니다.

이슈 #7671에 따르면 4.41.x 업데이트 이후 Docker Desktop GUI가 아예 실행되지 않거나, 실행되더라도 극도로 느려지는 버그가 보고되었습니다. 4.41.0에서 처음 보고되었고, 4.41.2에서도 해결되지 않았습니다. 업데이트를 했더니 오히려 못 쓰게 된 것입니다. 이 이슈에는 "다운그레이드하니까 해결됐다"는 댓글이 여러 개 달려 있습니다. 소프트웨어 업데이트가 다운그레이드를 유발하는 상황은 정상이 아닙니다.

메모리 문제: 먹기만 하고 돌려주지 않는다

이슈 #6120에 따르면 Docker Desktop이 Virtualization.framework를 사용할 때 메모리를 해제하지 않는 문제가 있습니다. 재현 방법은 단순합니다. 컨테이너 안에서 1GB짜리 파일을 생성하면 Docker 프로세스의 메모리 사용량이 1GB 늘어납니다. 그런데 그 파일을 삭제하고 컨테이너를 종료해도 메모리는 돌아오지 않습니다. Docker Desktop을 완전히 종료했다 다시 시작해야 메모리가 해제됩니다.

Docker 공식 문서의 Known Issues 페이지에서도 이 문제를 인정하고 있습니다. macOS의 Activity Monitor가 Docker의 메모리 사용량을 실제의 두 배로 표시하는 버그까지 공식 문서에 기재되어 있을 정도입니다. 실제 사용량도 문제인데, 표시되는 수치마저 정확하지 않습니다. 개발자 입장에서는 답답할 수밖에 없습니다.

일반적으로 Docker Desktop을 유휴 상태로 띄워만 놓아도 메모리를 2GB 이상 점유합니다. 컨테이너를 여러 개 돌리는 개발 환경에서는 3~4GB를 넘기는 경우도 흔합니다. 메모리 16GB 맥북에서 Docker가 4GB를 잡고 있으면 IDE와 브라우저를 동시에 쓰기가 빡빡해집니다.

라이선스 정책: 무료가 아닙니다

2021년 8월, Docker는 라이선스 정책을 변경했습니다. 직원 250명 이상이거나 연 매출 1000만 달러 이상인 기업은 Docker Desktop 유료 구독이 필수가 되었습니다. 2022년 10월에는 가격을 추가 인상하여 Team 플랜은 연간 84달러에서 108달러로, Business 플랜은 252달러에서 288달러로 올렸습니다.

개인 개발자나 소규모 팀에게는 여전히 무료이지만, 중견 기업 이상에서는 무시할 수 없는 비용입니다. 개발자 100명이 Business 플랜을 쓰면 연간 28,800달러, 약 3,800만 원입니다. 이 돈이면 다른 개발 도구에 투자하겠다는 기업이 늘고 있고, 실제로 이 라이선스 정책 변경이 많은 이들이 대안을 찾게 된 결정적인 계기가 되곤 합니다.

대안 1: Colima - 무료 오픈소스의 정석

Colima는 "Containers in Lima"의 줄임말로, Lima 프로젝트 위에서 동작하는 macOS용 컨테이너 런타임입니다. MIT 라이선스의 완전 무료 오픈소스이고, CLI 기반으로 동작합니다. GUI가 없다는 점이 단점처럼 느껴질 수 있지만, 터미널 중심으로 작업하는 개발자에게는 오히려 장점입니다. 백그라운드에서 자원을 갉아먹는 무거운 Electron 앱이 없다는 점도 큰 장점입니다.

설치와 시작

Homebrew로 설치합니다.

복사
brew install colima docker docker-compose

주의할 점은 colima 단독 설치만으로는 부족하다는 것입니다. docker CLI와 docker-compose 플러그인도 함께 설치해야 합니다. Colima는 Docker 데몬을 제공하지만, 클라이언트 도구는 별도로 필요합니다. Docker Desktop을 사용하던 환경이라면 이미 docker CLI가 있겠지만, Docker Desktop을 완전히 제거한 뒤라면 이 패키지들이 없을 수 있으니 확인해보세요.

설치가 끝나면 Colima를 시작합니다.

복사
colima start

기본 설정으로 시작하면 CPU 2코어, 메모리 2GB, 디스크 60GB의 가상 머신이 생성됩니다. 이 기본값을 변경하고 싶다면 옵션을 줄 수 있습니다.

복사
colima start --cpu 4 --memory 8 --disk 100

또는 설정 파일을 직접 편집하는 방법도 있습니다.

복사
colima start --edit

이 명령을 실행하면 에디터가 열리면서 YAML 형식의 설정 파일을 수정할 수 있습니다. 여기서 꼭 바꿔야 할 설정이 하나 있습니다. Apple Silicon 맥이라면 가상 머신 타입과 마운트 방식을 다음과 같이 바꾸는 게 좋습니다.

복사
vmType: vz
mountType: virtiofs

vz는 Apple의 Virtualization.framework를 사용하는 옵션이고, virtiofs는 파일 공유 프로토콜입니다. 기본값인 QEMU + 9p 조합보다 파일 I/O 성능이 크게 향상됩니다. 특히 node_modules처럼 작은 파일이 수천 개인 디렉토리를 다루는 프론트엔드 프로젝트에서 체감 차이가 큽니다.

Colima가 시작되면 Docker 컨텍스트를 확인합니다.

복사
docker context ls

Colima가 자동으로 colima 컨텍스트를 생성하고 활성화했는지 확인합니다. 만약 Docker Desktop 컨텍스트가 남아 있다면 수동으로 전환합니다.

복사
docker context use colima

docker-compose 사용

Colima에서 docker-compose를 사용하는 방법은 Docker Desktop과 완전히 동일합니다. Colima를 쓰는 가장 큰 이유이기도 합니다. 기존 docker-compose.yml 파일을 한 글자도 수정할 필요가 없거든요.

복사
# docker-compose.yml
services:
  web:
    image: nginx:alpine
    ports:
      - "8080:80"
    volumes:
      - ./html:/usr/share/nginx/html

  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: mypassword
      POSTGRES_DB: myapp
    ports:
      - "5432:5432"
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

복사
docker compose up -d
docker compose ps
docker compose logs -f web
docker compose down

docker compose(공백)와 docker-compose(하이픈) 두 가지 형태 모두 동작합니다. docker compose는 Docker CLI의 플러그인 형태이고, docker-compose는 독립 실행 파일입니다. brew로 docker-compose를 설치하면 두 형태 모두 사용할 수 있습니다.

위 예제는 기본적인 구성이므로, 실무에서 자주 쓰는 좀 더 현실적인 예제도 확인해보겠습니다. healthcheck와 depends_on condition을 사용하여 DB가 준비된 후에 백엔드가 시작되는 패턴입니다. 마이그레이션을 결정할 때 이런 구성이 제대로 돌아가는지가 관건입니다.

복사
# docker-compose.yml (healthcheck + depends_on 패턴)
services:
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: mypassword
      POSTGRES_DB: myapp
    ports:
      - "5432:5432"
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5

  backend:
    image: node:20-alpine
    working_dir: /app
    volumes:
      - ./backend:/app
    ports:
      - "3000:3000"
    depends_on:
      db:
        condition: service_healthy
    environment:
      DATABASE_URL: postgres://postgres:mypassword@db:5432/myapp
    command: ["node", "server.js"]

  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s
      timeout: 3s
      retries: 5

volumes:
  pgdata:

이 구성에서 backend 서비스는 db의 healthcheck가 통과할 때까지 시작되지 않습니다. Colima에서 이 패턴은 Docker Desktop과 동일하게 동작합니다. OrbStack, Rancher Desktop(dockerd 모드)에서도 마찬가지입니다. 다만 podman-compose에서는 depends_on의 condition 옵션이 제대로 안 돌 수 있으니, Podman 환경이라면 미리 테스트해봐야 합니다.

Docker Desktop에서 마이그레이션할 때 주의사항

Docker Desktop에서 Colima로 옮길 때 하나 주의할 점이 있습니다. ~/.docker/config.json 파일에서 credStore 또는 credsStore 항목을 확인해야 합니다. Docker Desktop은 macOS 키체인을 사용하여 레지스트리 인증 정보를 저장하는데, Colima 환경에서는 이 설정이 에러를 유발할 수 있습니다.

복사
# ~/.docker/config.json에서 credsStore 항목을 제거하거나 비워줍니다
cat ~/.docker/config.json

"credsStore": "desktop" 또는 "credsStore": "osxkeychain" 항목이 있으면 해당 줄을 삭제합니다. 그래야 docker login이나 프라이빗 레지스트리 접근 시 문제가 생기지 않습니다.

한 가지 더, Docker Desktop에서 쓰던 기존 이미지와 볼륨 데이터는 자동으로 이전되지 않습니다. Docker Desktop과 Colima는 각각 별도의 가상 머신을 사용하기 때문에, Docker Desktop에서 pull해놓은 이미지는 Colima에서 다시 pull해야 합니다. 자주 사용하는 이미지가 많다면 마이그레이션 전에 docker save로 이미지를 파일로 내보내고, Colima 시작 후 docker load로 가져오는 방법이 있습니다.

복사
# Docker Desktop 환경에서 이미지 내보내기
docker save myapp:latest -o myapp.tar
docker save postgres:16 nginx:alpine -o base-images.tar

# Colima 시작 후 이미지 가져오기
docker load -i myapp.tar
docker load -i base-images.tar

볼륨 데이터도 마찬가지입니다. Docker 볼륨에 저장된 데이터베이스 파일 등은 Docker Desktop의 가상 머신 내부에 존재합니다. 중요한 데이터가 볼륨에 있다면 마이그레이션 전에 docker cp나 볼륨 백업 컨테이너를 사용하여 호스트로 추출해두어야 합니다. docker-compose에서 bind mount(./data:/var/lib/data 형태)를 사용하고 있었다면 데이터가 호스트 파일시스템에 있으므로 별도 작업이 필요 없습니다. 이 차이를 모르면 마이그레이션 후 데이터가 사라진 것처럼 보일 수 있으니 주의해야 합니다.

Colima의 자원 사용량

Colima의 유휴 시 메모리 사용량은 약 400MB 수준입니다. Docker Desktop의 2GB 이상과 비교하면 5분의 1 수준입니다. 시작 시간은 상황에 따라 다릅니다. 최초로 가상 머신을 생성하는 colima start는 30초 이상 걸릴 수 있지만, 이미 생성된 VM을 다시 시작할 때는 20~30초 수준으로 Docker Desktop과 비슷합니다. 한번 시작한 뒤에는 백그라운드에서 조용히 동작하므로 시작 시간이 큰 문제는 아닙니다.

단점은 명확합니다. GUI가 없습니다. 컨테이너 상태를 시각적으로 확인하려면 docker ps를 써야 합니다. 그리고 간혹 macOS 업데이트 후 가상 머신이 깨지는 경우가 있는데, 이때는 colima delete로 가상 머신을 삭제하고 다시 시작하면 됩니다. 볼륨 데이터는 사라지므로 중요한 데이터는 반드시 외부에 백업해두어야 합니다.

대안 2: OrbStack - 속도와 편의성의 양립

OrbStack은 macOS 전용 Docker 런타임입니다. 2023년에 등장했고, 빠르면서도 쓰기 편한 Docker 환경을 지향합니다. 개인 비상업적 사용은 무료이고, 상업적 사용은 월 8달러입니다. Docker Desktop의 Business 플랜 월 24달러와 비교하면 3분의 1 수준입니다.

설치와 시작

복사
brew install orbstack

또는 orbstack.dev에서 dmg 파일을 다운로드하여 설치할 수 있습니다. 설치 후 OrbStack을 실행하면 Docker 환경이 자동으로 구성됩니다. Docker Desktop과 달리 별도의 Docker CLI 설치가 필요 없습니다. OrbStack이 docker 명령어를 직접 제공합니다.

OrbStack의 시작 시간은 약 2초입니다. 이건 체감이 됩니다. Docker Desktop이 20~30초 걸리는 것과 비교하면 거의 즉시 시작되는 느낌입니다. 노트북을 열고 바로 docker run을 칠 수 있다는 것은 작업 흐름에서 큰 차이를 만듭니다.

docker-compose 사용

OrbStack은 Docker CLI와 호환되므로, docker-compose도 수정 없이 그대로 쓸 수 있습니다.

복사
# 기존 프로젝트에서 그대로 실행
docker compose up -d

# OrbStack은 docker compose와 docker-compose 모두 지원
docker-compose up -d

OrbStack의 공식 문서에서도 "Docker Desktop에서 OrbStack으로 전환할 때 코드나 설정 파일을 수정할 필요가 없다"고 명시하고 있습니다. 기존 Dockerfile이든 docker-compose.yml이든 .env든 그대로 쓰면 됩니다.

편리한 기능이 하나 있습니다. OrbStack은 컨테이너에 자동으로 .orb.local 도메인을 붙여줍니다. 도메인은 컨테이너 이름을 기반으로 생성됩니다. docker run --name nginx로 실행하면 nginx.orb.local로 접근할 수 있습니다. docker-compose로 올린 서비스라면 프로젝트명-서비스명.orb.local 형식이 됩니다. 예를 들어 myapp 디렉토리에서 docker compose up으로 web 서비스를 올리면 myapp-web-1.orb.local로 접근합니다. DNS 설정은 OrbStack이 알아서 처리하니 /etc/hosts를 수동으로 편집하거나 포트 번호를 외울 필요가 없습니다.

성능 벤치마크

성능을 수치로 확인해봅시다. 2025년 Paolo Mainardi의 독립 벤치마크에서 bind mount 성능을 테스트한 결과입니다.

VirtioFS 도입 이전에는 bind mount가 네이티브 대비 5~6배 느렸지만, 현재는 3배 수준으로 개선되었습니다. 그 중에서도 OrbStack이 4.22초로 가장 빠릅니다.

메모리 사용량도 적습니다. OrbStack 측은 Docker Desktop 대비 60% 적은 메모리를 사용한다고 밝히고 있습니다. 유휴 시 약 500MB 수준입니다. 그런데 OrbStack이 진짜 다른 점은 동적 메모리 관리입니다. OrbStack 공식 블로그의 "We fixed container memory usage on macOS" 글에 따르면, Docker Desktop이 해결하지 못한 메모리 미반환 문제를 OrbStack은 자체 구현으로 해결했습니다. 컨테이너가 메모리를 사용한 뒤 해제하면, 점유했던 메모리가 실제로 macOS로 반환됩니다. Docker Desktop에서는 이것이 안 되어서 앞서 다룬 이슈 #6120이 발생한 것입니다.

OrbStack의 단점

OrbStack은 macOS 전용입니다. 팀에서 macOS와 Linux 개발 환경을 혼용한다면 OrbStack은 macOS 개발자만 사용할 수 있습니다. 그리고 상업적 사용은 유료입니다. 개인 프로젝트나 학습 목적이라면 무료로 충분하지만, 회사에서 업무용으로 쓴다면 월 8달러를 지불해야 합니다.

또 하나, OrbStack은 오픈소스가 아닙니다. 클로즈드 소스 상용 제품이므로, 오픈소스를 선호하는 조직에서는 선택지에서 제외될 수 있습니다. 하지만 Docker Desktop도 오픈소스가 아닌 것은 마찬가지이므로, Docker Desktop에서 OrbStack으로 옮기는 것이라면 이 점은 문제가 되지 않습니다.

대안 3: Rancher Desktop - Kubernetes가 필요한 팀을 위해

Rancher Desktop은 SUSE가 관리하는 오픈소스 프로젝트로, Apache License 2.0을 따릅니다. 완전 무료입니다. Rancher Desktop은 Docker와 Kubernetes를 한꺼번에 제공합니다. 컨테이너 런타임으로 dockerd(moby) 또는 containerd를 선택할 수 있고, 로컬 Kubernetes 클러스터를 원클릭으로 생성할 수 있습니다.

설치와 시작

복사
brew install --cask rancher

또는 rancherdesktop.io에서 설치 파일을 다운로드합니다. Colima와 달리 별도로 docker CLI나 docker-compose를 설치할 필요가 없습니다. Rancher Desktop은 dockerd 모드를 선택하면 자체 PATH에 docker CLI를 등록하여 제공합니다. 다만 이 점이 주의사항이기도 합니다. 이미 Colima나 Docker Desktop이 설치되어 있다면 docker 명령어의 PATH 충돌이 발생할 수 있으므로, which docker로 어떤 docker가 실행되는지 확인해야 합니다.

설치 후 첫 실행 시 컨테이너 런타임을 선택하는 화면이 나옵니다. docker-compose를 사용하려면 반드시 dockerd(moby)를 선택해야 합니다. containerd를 선택하면 Docker CLI 호환 환경이 아니라 nerdctl 기반 환경이 구성되므로, 기존 Docker 워크플로를 그대로 쓰고 싶다면 dockerd를 선택합니다.

Kubernetes 버전도 선택할 수 있습니다. Rancher Desktop은 Kubernetes 버전을 드롭다운 메뉴에서 원클릭으로 전환하는 기능을 제공합니다. minikube나 kind에는 없는 편의 기능이죠. 1.28에서 작동하던 매니페스트가 1.30에서도 동작하는지 간단히 테스트할 수 있습니다.

docker-compose 사용

dockerd 런타임을 선택했다면 docker-compose는 그대로 동작합니다.

복사
# Rancher Desktop이 dockerd 모드일 때
docker compose up -d
docker compose ps

다만 한 가지 주의점이 있습니다. Rancher Desktop은 자체 PATH 설정을 통해 docker 명령어를 제공하는데, Docker Desktop이나 Colima의 docker CLI와 충돌할 수 있습니다. 여러 Docker 런타임을 번갈아 사용하는 환경이라면 PATH 우선순위를 확인해야 합니다.

누구에게 적합한가

Docker와 Kubernetes를 한 번에 쓰고 싶은 팀이라면 Rancher Desktop이 맞습니다. docker-compose로 로컬 개발 환경만 구성하는 용도라면 Colima나 OrbStack이 더 가볍고 빠르고요. 하지만 Kubernetes 매니페스트를 로컬에서 테스트해야 하거나, Helm 차트를 개발하고 있다면 Rancher Desktop이 가장 편한 선택입니다.

단점으로는 시작 시간이 다소 길고, Colima나 OrbStack에 비해 자원 사용량이 많은 편입니다. Kubernetes 클러스터를 함께 올리기 때문입니다. Kubernetes를 꺼놓을 수도 있긴 한데, 그렇게까지 할 거면 처음부터 Colima를 쓰는 게 낫습니다.

대안 4: Podman - 데몬 없는 컨테이너

Podman은 Red Hat이 주도하는 오픈소스 컨테이너 엔진입니다. Podman이 다른 도구와 다른 점은 데몬이 없다는 것입니다. Docker는 dockerd라는 데몬 프로세스가 백그라운드에서 항상 돌아야 하지만, Podman은 데몬 없이 각 컨테이너를 독립 프로세스로 실행합니다. 루트 권한의 데몬이 없으니 공격 표면이 줄어들고, 보안 감사에서 유리합니다.

설치와 시작

복사
brew install podman
podman machine init
podman machine start

Podman은 macOS에서 가상 머신을 사용하여 Linux 컨테이너를 실행합니다. podman machine init으로 가상 머신을 생성하고, podman machine start로 시작합니다.

Podman의 CLI는 Docker CLI와 거의 같습니다. docker run 대신 podman run을 쓰면 되고, 귀찮으면 alias를 걸면 됩니다.

복사
# ~/.zshrc에 추가
alias docker=podman

docker-compose 호환성: 여기서 이야기가 좀 복잡해집니다

Podman에서 docker-compose를 사용하는 것은 가능하지만, Colima나 OrbStack만큼 매끄럽지는 않습니다. 두 가지 방법이 있습니다.

첫 번째 방법은 podman-compose를 사용하는 것입니다.

복사
pip3 install podman-compose

podman-compose는 docker-compose.yml 파일을 읽어서 Podman 명령어로 변환해줍니다. 대부분은 잘 동작하지만, Docker Compose의 모든 기능을 지원하지는 않습니다. 네트워크 설정이나 depends_on의 condition 같은 기능에서 차이가 날 수 있습니다.

두 번째 방법은 기존 docker-compose CLI를 Podman 소켓과 연결하는 것입니다. 소켓 경로는 Podman 버전에 따라 다를 수 있으므로, 먼저 실제 경로를 확인합니다.

복사
# Podman 소켓 활성화
podman machine start

# 소켓 경로 확인 (Podman 버전에 따라 경로가 다릅니다)
podman machine inspect --format '{{.ConnectionInfo.PodmanSocket.Path}}'

# 확인된 경로를 DOCKER_HOST 환경변수로 지정
export DOCKER_HOST="unix://$(podman machine inspect --format '{{.ConnectionInfo.PodmanSocket.Path}}')"

# 이제 기존 docker compose 명령어 사용 가능
docker compose up -d

이 방법은 docker-compose가 Podman을 Docker 데몬인 것처럼 인식하게 만듭니다. 호환성은 더 좋지만, 소켓 경로 설정이 필요합니다. Podman 5.x 이후 기본 소켓 경로가 변경되었으므로, 위 명령어로 실제 경로를 반드시 확인해야 합니다. 고정 경로를 ~/.zshrc에 넣어두면 Podman 업데이트 시 동작하지 않을 수 있습니다.

Podman의 현실적인 한계

macOS에서 Podman을 사용할 때 알아야 할 중요한 제약이 있습니다. Apple Silicon(M1/M2/M3/M4) 맥에서 x86_64(AMD64) 이미지를 실행하면 QEMU 에뮬레이션이 필요한데, 이때 성능이 크게 떨어집니다. 한 기술 블로그의 테스트에 따르면 최대 50배까지 느려질 수 있습니다. ARM64 네이티브 이미지가 없는 오래된 컨테이너를 써야 하는 상황이라면 이 점을 반드시 고려해야 합니다.

Podman은 Red Hat 계열 기업 환경에서 진가를 발휘합니다. OpenShift 호환, rootless 컨테이너 기본 지원, SELinux 통합 등 기업 보안 요구사항에 강하거든요. 하지만 "맥에서 docker-compose를 편하게 쓰겠다"는 목적이라면, Colima나 OrbStack이 더 낫습니다.

한눈에 보는 비교표

각 도구를 한눈에 비교해봅시다.

상황별 추천 가이드

"그래서 나는 뭘 써야 하나?"에 대한 답은 상황에 따라 다릅니다. 다음 흐름도를 보면 자신에게 맞는 도구를 빠르게 판단할 수 있습니다.

비용, 성능, Kubernetes 필요 여부, 보안 요구사항이 핵심 판단 기준입니다. 무료가 중요하면 Colima 또는 Rancher Desktop, 성능이 중요하면 OrbStack, 보안 감사가 중요하면 Podman이 각각 적합합니다.

"돈 한 푼 안 쓰고, 터미널만으로 충분하다" 그러면 Colima입니다. 설치 3분, 설정 5분이면 Docker Desktop과 동일한 환경을 무료로 쓸 수 있습니다. docker-compose 호환성도 완벽합니다. 유일한 대가는 GUI가 없다는 것인데, docker ps와 docker logs로 충분한 개발자가 대부분일 겁니다.

"성능이 최우선이고, 월 8달러는 괜찮다" 그러면 OrbStack입니다. 2초 시작, 최상의 파일 I/O, 동적 메모리 관리까지. 특히 대규모 프로젝트에서 bind mount 성능이 중요한 경우, 예를 들어 React/Next.js 같은 프론트엔드 프로젝트에서 핫 리로드 속도가 느리다고 느끼는 경우, OrbStack을 쓰면 확실한 성능 차이를 체감할 수 있습니다. docker-compose 호환성도 완벽합니다.

"Kubernetes를 로컬에서 테스트해야 한다" 그러면 Rancher Desktop입니다. Kubernetes 버전 원클릭 전환은 minikube나 kind에는 없는 편의 기능입니다. 완전 무료인 것도 강점입니다. docker-compose도 dockerd 모드를 선택하면 문제없이 돌아갑니다.

"Red Hat/OpenShift 환경이고 보안이 중요하다" 그러면 Podman입니다. 데몬리스 아키텍처와 rootless 컨테이너는 보안 감사에서 유리합니다. 다만 macOS에서 docker-compose 설정이 다른 도구들보다 번거롭다는 점은 감안해야 합니다.

"지금 Docker Desktop을 쓰고 있는데, 큰 변화 없이 문제만 해결하고 싶다" 이전 비용이 가장 낮은 건 OrbStack입니다. Docker CLI 호환, GUI 제공, 설정 파일 변경 불필요. Docker Desktop을 삭제하고 OrbStack을 깔면 기존 워크플로를 그대로 가져갈 수 있습니다. 무료가 중요하다면 Colima가 차선이고요.

마무리

Docker Desktop의 문제는 "내 맥이 이상한 건가" 싶은 개인적인 고민에서 시작하지만, GitHub 이슈 트래커를 보면 수많은 개발자가 같은 문제를 겪고 있다는 것을 알 수 있습니다. 커널 패닉, 메모리 미반환, GUI 실행 불가 같은 문제들은 개인의 환경 탓이 아니라 Docker Desktop의 구조적 한계에서 비롯됩니다.

대안은 충분하고, 각각 성격이 다릅니다. 무료로 가볍게 가려면 Colima, 속도를 우선하면 OrbStack, Kubernetes까지 필요하면 Rancher Desktop, 보안이 중요하면 Podman. "Docker Desktop이 유일한 선택"이라는 생각에서 벗어나면 됩니다.

주변 개발자들에게는 "일단 Colima부터 써보세요"라고 추천합니다. 무료이고, 설치가 간단하고, docker-compose가 그대로 돌아갑니다. 그걸로 부족하면 OrbStack을 시도해보면 됩니다. 이제 굳이 Docker Desktop만을 고집할 이유는 사라졌습니다.

한 가지 더 지켜볼 흐름이 있습니다. Apple이 WWDC 2025에서 Containerization이라는 Swift 기반 오픈소스 컨테이너 프레임워크를 공개했습니다. 아직은 Dockerfile 빌드나 볼륨 마운트도 지원하지 않는 초기 단계라 실무에서 쓸 수준은 아닙니다. 하지만 OrbStack이 이미 Apple의 Virtualization.framework를 적극 활용하고 있으니, 앞으로 이 프레임워크 위에서 기존 도구들이 돌아갈 가능성은 열려 있습니다.

---

참고 자료

• Docker Desktop Known Issues - Docker 공식 문서 (https://docs.docker.com/desktop/troubleshoot/known-issues/)
• Docker Desktop 4.41.x 시작 불가 이슈 #7671 (https://github.com/docker/for-mac/issues/7671)
• macOS 커널 패닉 이슈 #7664 (https://github.com/docker/for-mac/issues/7664)
• Docker 메모리 미반환 이슈 #6120 (https://github.com/docker/for-mac/issues/6120)
• Docker 구독 플랜 변경 공지 (https://www.docker.com/blog/updating-product-subscriptions)
• Colima GitHub 저장소 (https://github.com/abiosoft/colima)
• Colima 마이그레이션 가이드 - saghul (https://code.saghul.net/2025/02/migrating-from-docker-desktop-to-colima-2025-update/)
• OrbStack 공식 사이트 (https://orbstack.dev/)
• OrbStack 벤치마크 (https://docs.orbstack.dev/benchmarks)
• OrbStack 동적 메모리 관리 (https://orbstack.dev/blog/dynamic-memory)
• Paolo Mainardi macOS Docker 벤치마크 2025 (https://www.paolomainardi.com/posts/docker-performance-macos-2025/)
• Docker Desktop 대안 2025 비교 - fsck.sh (https://fsck.sh/en/blog/docker-desktop-alternatives-2025/)
• Podman macOS 설정 가이드 (https://magnus919.com/2025/01/setting-up-podman-on-macos-a-docker-alternative-for-local-container-development/)
• Apple Containers 기술 비교 - The New Stack (https://thenewstack.io/apple-containers-on-macos-a-technical-comparison-with-docker/)
• docker-engines-benchmark (https://github.com/nemirlev/docker-engines-benchmark)