컨테이너 없이 개발하는 시대는 끝났습니다. 하지만 2026년, 컨테이너 런타임 선택지는 더 이상 Docker 독점이 아닙니다. Red Hat이 밀어붙이는 Podman이 엔터프라이즈 시장 점유율 23%를 달성하며 진지한 대안으로 자리잡았고, Docker는 Engine v28과 AI Agent 통합으로 반격하고 있습니다. 데몬 vs 데몬리스, 루트 vs 루트리스 — 2026년 기준 어떤 걸 선택해야 할까요?
한눈에 보는 Docker vs Podman 2026
| 항목 | Docker (Engine v28) | Podman (v5.x) |
|---|---|---|
| 아키텍처 | 클라이언트-서버 (데몬) | 데몬리스 ✅ |
| 루트 권한 | 기본 root (rootless 옵션) | 기본 rootless ✅ |
| 컨테이너 시작 시간 | ~1.2초 / 100MB | ~0.8초 / 85MB ✅ |
| 유휴 메모리 | 데몬 상주 (~100MB+) | 0MB (데몬 없음) ✅ |
| OCI 호환 | ✅ | ✅ |
| Pod 네이티브 지원 | ❌ | ✅ (K8s Pod 개념) |
| Compose 지원 | ✅ 네이티브 (v2.32+) | ✅ podman-compose / docker-compose 호환 |
| Desktop GUI | Docker Desktop (유료 조건) | Podman Desktop (완전 무료) ✅ |
| 라이선스 비용 | 250인+ 기업 유료 ($9~$24/월) | 완전 무료 (Apache 2.0) ✅ |
| 커뮤니티/에코시스템 | ✅ 압도적 (59% 점유율) | 빠르게 성장 (23% 엔터프라이즈) |
| Kubernetes 통합 | Docker Desktop K8s | 네이티브 Pod + YAML 생성 ✅ |
아키텍처 — 데몬 vs 데몬리스
Docker와 Podman의 가장 근본적인 차이는 아키텍처에 있습니다. 이 차이가 보안, 성능, 안정성 전반에 걸친 특성을 결정합니다.
Docker: 중앙 집중형 데몬
Docker는 dockerd라는 백그라운드 데몬이 모든 컨테이너 작업을 관리합니다. CLI에서 명령을 보내면 데몬이 받아서 실행하는 클라이언트-서버 구조입니다. 이 구조 덕분에 이미지 캐싱과 레이어 관리가 효율적이지만, 데몬 하나가 죽으면 모든 컨테이너가 영향받는 단일 장애점(SPOF)이 됩니다.
Podman: 분산형 데몬리스
Podman은 데몬이 없습니다. 각 컨테이너가 사용자 세션의 자식 프로세스로 직접 실행됩니다. 중앙 서비스가 없으니 하나의 컨테이너 실패가 다른 컨테이너에 영향을 주지 않고, 공격 대상이 되는 특권 소켓도 존재하지 않습니다. systemd와의 통합도 자연스러워서, Quadlet 기능으로 컨테이너를 systemd 서비스로 직접 관리할 수 있습니다.
보안 — 루트리스가 기본인 시대
컨테이너 보안에서 가장 중요한 질문은 "누가 컨테이너를 실행하는가"입니다.
Docker의 보안 모델
Docker 데몬은 전통적으로 root 권한으로 실행됩니다. Docker v20부터 rootless 모드를 지원하지만, 기본값이 아니라 별도 설정이 필요합니다. root 데몬이 실행 중이라는 것은 컨테이너 탈출(container escape) 공격 시 호스트 전체가 위험해질 수 있다는 뜻입니다.
Podman의 보안 모델
Podman은 기본값이 rootless입니다. 일반 사용자 권한으로 컨테이너를 실행하므로, 컨테이너가 탈출하더라도 일반 사용자 권한만 얻게 됩니다. 권한 상승(privilege escalation) 공격의 전체 범주를 원천 차단합니다. Podman Desktop v1.22(2025년 10월)부터는 macOS/Windows에서 rootless와 rootful 모드를 자유롭게 전환할 수 있어 유연성도 확보했습니다.
성능 벤치마크 2026
| 항목 | Docker (v28) | Podman (v5.x) |
|---|---|---|
| 콜드 스타트 | ~1.2초 | ~0.8초 ✅ |
| 웜 스타트 (데몬 캐싱) | ✅ 빠름 (~150ms) | ~180ms |
| 유휴 메모리 사용 | ~100MB+ (데몬) | 0MB ✅ |
| 100+ 컨테이너 스케일링 | 보통 (데몬 병목) | ✅ 우수 (분산) |
| 이미지 빌드 속도 | ✅ BuildKit v0.20 | Buildah (호환) |
| macOS 파일 공유 | ✅ virtiofs (98% 속도 향상) | virtiofs 지원 |
정리하면, 콜드 스타트와 메모리 효율은 Podman이 우세하고, 웜 스타트와 이미지 빌드 속도는 Docker가 근소하게 앞섭니다. Docker의 데몬은 이미지 레이어 캐싱에서 이점이 있지만, 유휴 상태에서도 메모리를 점유한다는 트레이드오프가 있습니다. 대규모 워크로드(100+ 컨테이너)에서는 데몬 없는 Podman이 병목 없이 더 안정적으로 스케일링됩니다.
Kubernetes 통합
Docker와 Kubernetes
Kubernetes 1.24부터 dockershim이 제거되면서, Docker는 더 이상 K8s의 직접적인 런타임이 아닙니다. Docker Desktop에 내장된 K8s 클러스터로 로컬 개발은 가능하지만, Docker 자체가 K8s와 직접 연동되는 구조는 아닙니다.
Podman과 Kubernetes
Podman은 K8s의 핵심 개념인 Pod를 네이티브로 지원합니다. podman generate kube 명령으로 실행 중인 Pod에서 K8s YAML 매니페스트를 자동 생성할 수 있고, 반대로 podman play kube로 K8s YAML을 로컬에서 바로 실행할 수 있습니다. 로컬 개발 환경과 K8s 프로덕션 환경 사이의 갭을 최소화하는 강력한 워크플로우입니다.
Compose 호환성
Docker Compose는 멀티 컨테이너 앱 정의의 사실상 표준입니다. Podman은 이를 두 가지 방식으로 지원합니다.
- podman-compose: Python 기반 독립 도구로 docker-compose.yml을 그대로 실행
- docker-compose 직접 사용: Podman의 Docker 호환 REST API 소켓을 통해 기존 docker-compose CLI를 그대로 사용 가능
대부분의 docker-compose.yml 파일이 수정 없이 Podman에서 동작하지만, 일부 Docker 전용 네트워킹 기능이나 볼륨 플러그인은 호환되지 않을 수 있습니다. Podman 5.x에서는 Docker API 호환성이 크게 개선되어, 기존 Compose 워크플로우의 마이그레이션이 훨씬 수월해졌습니다.
라이선스 & 비용
| 플랜 | Docker Desktop | Podman Desktop |
|---|---|---|
| 개인/소규모 팀 | 무료 (250인 미만) | 무료 |
| Pro | $9/월 | 무료 |
| Team | $15/월/사용자 | 무료 |
| Business (250인+) | $24/월/사용자 | 무료 ✅ |
| 연간 비용 (50명 팀) | $9,000~$14,400 | $0 ✅ |
250인 이상 기업이라면 Docker Desktop은 반드시 유료 구독이 필요합니다. 50명 개발팀 기준으로 연간 $9,000~$14,400의 비용 차이가 발생합니다. Podman Desktop은 Apache 2.0 라이선스로 어떤 환경에서든 완전히 무료입니다. 이 비용 차이는 특히 스타트업과 중소기업에게 결정적인 요소가 될 수 있습니다.
CLI 비교 — 거의 동일한 명령어
Podman은 Docker CLI와의 호환성을 최우선으로 설계했습니다. 대부분의 명령어가 docker를 podman으로 바꾸기만 하면 동작합니다.
▸ Docker
$ docker build -t myapp:latest .
$ docker run -d -p 8080:80 --name web myapp:latest
$ docker ps
$ docker-compose up -d▸ Podman
$ podman build -t myapp:latest .
$ podman run -d -p 8080:80 --name web myapp:latest
$ podman ps
$ podman-compose up -d▸ Podman 전용 — K8s YAML 생성
# 실행 중인 Pod에서 K8s 매니페스트 자동 생성
$ podman generate kube web > deployment.yaml
# K8s YAML을 로컬에서 바로 실행
$ podman play kube deployment.yaml
# systemd 서비스로 컨테이너 관리 (Quadlet)
$ podman generate systemd --new --name webalias docker=podman 한 줄이면 기존 Docker 워크플로우를 그대로 Podman에서 사용할 수 있습니다. OCI 이미지 호환성 덕분에, 어떤 런타임으로 빌드한 이미지든 다른 런타임에서 그대로 실행됩니다.
상황별 추천
| 상황 | 추천 | 이유 |
|---|---|---|
| 컨테이너 입문자 | Docker | 압도적인 학습 자료, 커뮤니티, 튜토리얼 |
| 보안 중시 환경 | Podman | 기본 rootless + 데몬리스로 공격 표면 최소화 |
| macOS/Windows 로컬 개발 | Docker | Docker Desktop의 성숙한 GUI와 통합 경험 |
| 250인+ 엔터프라이즈 | Podman | 라이선스 비용 절감 + RHEL 네이티브 지원 |
| Kubernetes 네이티브 워크플로우 | Podman | Pod 네이티브 + K8s YAML 직접 생성/실행 |
| CI/CD 파이프라인 | Podman | 데몬 없이 가볍게 실행, rootless로 보안 강화 |
| Docker Compose 중심 프로젝트 | Docker | 네이티브 Compose 지원, 100% 호환 보장 |
| AI/ML 워크로드 | Docker | NVIDIA Container Toolkit 성숙도 + AI Agent 통합 |
최종 결론
2026년 기준, Docker와 Podman은 더 이상 "어느 게 더 좋냐"의 문제가 아닙니다. Docker는 에코시스템과 개발자 경험(DX)의 왕이고, Podman은 보안과 비용 효율의 왕입니다.
개인 개발자나 소규모 팀이라면 Docker로 시작해도 전혀 문제없습니다. 하지만 250인 이상 기업, 보안 규정이 엄격한 환경, 또는 Kubernetes 네이티브 워크플로우가 필요하다면 Podman이 확실히 합리적인 선택입니다. OCI 호환성 덕분에 두 런타임 사이의 마이그레이션은 거의 마찰 없이 가능하니, 현재 필요에 맞는 도구로 시작하고 요구사항이 바뀌면 전환하면 됩니다.
가장 좋은 소식은, 어떤 걸 선택하든 당신의 컨테이너 이미지는 양쪽 모두에서 완벽하게 동작한다는 것입니다.
댓글
댓글 쓰기