Docker가 컨테이너의 대명사로 자리잡은 지 10년이 넘었습니다. 그런데 최근 RHEL, CentOS, Rocky Linux 등 엔터프라이즈 리눅스 배포판에서 Docker 대신 Podman을 기본 채택하는 흐름이 뚜렷해지고 있습니다. 2025년 말 기준 Podman은 5.7.1 버전에 도달했고, Docker도 Engine v29와 함께 1,000개 이상의 Hardened Images를 무료 오픈소스로 공개하는 등 경쟁이 치열합니다. 과연 Podman은 Docker를 대체할 수 있을까요? 이 글에서는 두 도구의 아키텍처, 보안, 기능, 사용성을 심층 비교하고 각각 어떤 환경에 적합한지 분석합니다.
기본 개념과 탄생 배경
Docker의 등장
Docker는 2013년 dotCloud(현 Docker Inc.)에서 공개한 컨테이너 플랫폼입니다. Linux 커널의 cgroups와 namespaces 기능을 활용하여 애플리케이션을 격리된 환경에서 실행하는 기술을 대중화했습니다. Dockerfile을 통한 이미지 빌드, Docker Hub를 통한 이미지 공유, Docker Compose를 통한 멀티 컨테이너 관리 등 완성도 높은 생태계를 구축하며 컨테이너 기술의 표준이 되었습니다.
Podman의 등장
Podman은 2018년 Red Hat이 공개한 컨테이너 관리 도구입니다. “Pod Manager”의 약자로, Kubernetes의 Pod 개념을 로컬 환경에서도 사용할 수 있게 설계되었습니다. Docker의 한계로 지적되던 보안 문제와 아키텍처 제약을 해결하기 위해 만들어졌으며, RHEL 8부터 Docker를 대체하는 기본 컨테이너 도구로 채택되었습니다. 2024년 11월 Podman 5.3부터 분기별 릴리스 체계를 도입했으며, 2025년 말 현재 Podman 5.7.1과 Podman Desktop 1.24.2가 최신 안정 버전입니다.
아키텍처 비교
Docker: 데몬 기반 구조
Docker는 클라이언트-서버 아키텍처를 사용합니다. docker 명령어를 입력하면 Docker 클라이언트가 Docker 데몬(dockerd)에 요청을 보내고, 데몬이 실제 컨테이너 작업을 수행합니다.
[사용자] → [Docker CLI] → [Docker 데몬(dockerd)] → [containerd] → [runc] → [컨테이너]
이 구조의 장점은 중앙 집중식 관리가 가능하다는 것입니다. 하지만 단점도 명확합니다. 첫째, 데몬이 root 권한으로 실행되어 보안 위험이 있습니다. 둘째, 데몬이 크래시되면 모든 컨테이너에 영향을 줍니다. 셋째, 시스템 부팅 시 데몬이 먼저 시작되어야 컨테이너를 사용할 수 있습니다.
Podman: 데몬리스 구조
Podman은 데몬 없이 직접 컨테이너를 실행합니다. podman 명령어가 직접 컨테이너 런타임을 호출하여 컨테이너를 생성하고 관리합니다.
[사용자] → [Podman CLI] → [conmon] → [runc] → [컨테이너]
각 컨테이너는 독립적인 프로세스로 실행되며, conmon(container monitor)이라는 작은 프로세스가 각 컨테이너를 모니터링합니다. 데몬이 없으므로 단일 장애점이 사라지고, 하나의 컨테이너 문제가 다른 컨테이너에 영향을 주지 않습니다.
보안 비교
Root 권한 문제
Docker 데몬은 기본적으로 root 권한으로 실행됩니다. docker 그룹에 속한 사용자는 데몬을 통해 사실상 root 권한을 얻을 수 있어, 보안 관점에서 docker 그룹 멤버십은 sudo 권한과 동등하게 취급됩니다. Docker도 rootless 모드를 지원하지만 추가 설정이 필요하고 일부 기능에 제약이 있습니다.
Podman은 루트리스(rootless) 실행을 기본으로 설계되었습니다. 일반 사용자가 root 권한 없이 컨테이너를 생성하고 실행할 수 있습니다. 사용자 네임스페이스를 활용하여 컨테이너 내부에서는 root처럼 보이지만 호스트에서는 일반 사용자로 실행됩니다.
공격 표면
Docker 데몬은 REST API를 통해 통신하며, 이 소켓(/var/run/docker.sock)에 대한 접근이 곧 시스템 전체에 대한 접근으로 이어질 수 있습니다. 컨테이너에 Docker 소켓을 마운트하는 것은 매우 위험한 패턴이지만, CI/CD 파이프라인 등에서 흔히 사용됩니다.
Podman은 데몬이 없으므로 이런 공격 표면 자체가 존재하지 않습니다. 각 컨테이너가 독립적으로 실행되어 하나의 취약점이 전체 시스템으로 확산되기 어렵습니다.
SELinux 통합
RHEL 계열에서 Podman은 SELinux와 자연스럽게 통합됩니다. 컨테이너에 자동으로 적절한 SELinux 컨텍스트가 적용되어 추가적인 격리 계층을 제공합니다.
보안 비교표
| 항목 | Docker | Podman |
|---|---|---|
| 기본 실행 권한 | root | 일반 사용자 |
| 루트리스 지원 | 추가 설정 필요 | 기본 지원 |
| 데몬 공격 표면 | 있음 | 없음 |
| SELinux 통합 | 제한적 | 완전 통합 |
| 사용자 네임스페이스 | 옵션 | 기본 활성화 |
기능 비교
이미지 관리
두 도구 모두 OCI(Open Container Initiative) 표준을 준수하여 동일한 이미지를 사용할 수 있습니다. Docker Hub, Quay.io, GitHub Container Registry 등 모든 컨테이너 레지스트리와 호환됩니다.
이미지 빌드 측면에서 Docker는 내장된 빌드 기능을 제공하고, Podman은 Buildah라는 별도 도구를 사용하거나 podman build 명령으로 Buildah를 내부적으로 호출합니다.
컨테이너 실행
CLI 명령어는 거의 동일합니다. 대부분의 경우 docker를 podman으로 바꾸기만 하면 됩니다.
# Docker
docker run -d --name web -p 8080:80 nginx
docker ps
docker logs web
docker exec -it web /bin/bash
# Podman (동일한 명령어)
podman run -d --name web -p 8080:80 nginx
podman ps
podman logs web
podman exec -it web /bin/bash
alias 설정으로 완전한 호환성을 얻을 수 있습니다.
alias docker=podman
Pod 지원
Podman의 고유 기능으로 Pod를 지원합니다. Kubernetes의 Pod 개념과 유사하게 여러 컨테이너를 하나의 네트워크 네임스페이스에서 실행할 수 있습니다.
# Pod 생성
podman pod create --name mypod -p 8080:80
# Pod에 컨테이너 추가
podman run -d --pod mypod --name web nginx
podman run -d --pod mypod --name app myapp
# Pod 내 컨테이너는 localhost로 통신
이 기능은 Kubernetes 배포 전 로컬 테스트에 유용합니다.
Docker Compose 호환성
Docker는 Docker Compose를 네이티브로 지원합니다(docker compose 명령어). Podman은 podman-compose를 통해 호환성을 제공하며, 대부분의 docker-compose.yml 파일을 그대로 사용할 수 있습니다. 다만 일부 고급 기능에서 차이가 있을 수 있습니다.
systemd 통합
Podman은 systemd와의 통합이 뛰어납니다. 컨테이너를 systemd 서비스로 쉽게 변환할 수 있습니다.
# systemd 서비스 파일 자동 생성
podman generate systemd --name web --files --new
# 사용자 서비스로 등록
systemctl --user enable --now container-web
Docker도 systemd 서비스로 관리할 수 있지만, 데몬을 통해야 하므로 구조가 더 복잡합니다.
기능 비교표
| 기능 | Docker | Podman |
|---|---|---|
| OCI 이미지 호환 | 지원 | 지원 |
| CLI 호환성 | 기준 | Docker와 동일 |
| Compose | 네이티브 지원 | podman-compose |
| Pod 지원 | 미지원 | 지원 |
| systemd 통합 | 가능 | 네이티브 |
| Docker Swarm | 지원 | 미지원 |
| 이미지 빌드 | 내장 | Buildah 연동 |
성능 비교
실제 운영 환경에서 두 도구의 성능 차이는 미미합니다. 둘 다 동일한 런타임(runc)을 사용하므로 컨테이너 실행 성능은 동일합니다. 차이가 나는 부분은 컨테이너 시작 시간과 이미지 풀링 정도인데, 대부분의 워크로드에서 체감하기 어려운 수준입니다.
다만 대량의 컨테이너를 동시에 관리할 때 Docker 데몬의 중앙 집중식 관리가 오히려 효율적일 수 있습니다. Podman은 각 컨테이너가 독립적이므로 수천 개의 컨테이너 환경에서는 오버헤드가 발생할 수 있습니다.
생태계와 지원
Docker 생태계
Docker는 10년 이상의 역사를 가진 만큼 생태계가 압도적입니다. Docker Hub에는 수백만 개의 이미지가 있고, 대부분의 소프트웨어가 공식 Docker 이미지를 제공합니다. Stack Overflow, 공식 문서, 튜토리얼 등 학습 자료도 풍부합니다. Docker Desktop은 macOS와 Windows에서 GUI 기반의 편리한 개발 경험을 제공합니다.
2025년 12월 Docker는 1,000개 이상의 Docker Hardened Images(DHI)를 Apache 2.0 라이선스로 무료 공개했습니다. 이 이미지들은 기존 커뮤니티 이미지 대비 취약점을 95% 이상 줄인 보안 강화 이미지로, Debian과 Alpine 기반으로 제공됩니다. 또한 Docker Engine v29에서는 TLS/mTLS 암호화 연결, Model Context Protocol(MCP) 서버 지원 등 AI 시대에 맞는 새로운 기능들이 추가되었습니다.
Podman 생태계
Podman은 Red Hat의 전폭적인 지원을 받고 있습니다. RHEL, CentOS Stream, Rocky Linux, AlmaLinux 등에서 기본 도구로 채택되었으며, Fedora에서도 Docker보다 Podman이 권장됩니다. 문서와 커뮤니티가 빠르게 성장 중이며, Docker 호환성 덕분에 기존 Docker 문서도 대부분 활용 가능합니다.
Podman Desktop은 2025년 한 해 동안 v1.16부터 v1.24까지 꾸준히 업데이트되며 300만 다운로드를 돌파했습니다. 주요 개선사항으로는 네트워크 관리 UI, 커스터마이저블 대시보드, 루트리스/루트풀 모드 전환 기능(macOS/Windows), ARM64 Windows 네이티브 설치 지원 등이 있습니다. 또한 2025년에는 슬립포(slirp4netns)보다 2배 이상 빠른 pasta 네트워크 백엔드가 도입되어 루트리스 모드의 네트워크 성능이 크게 개선되었습니다. Visual Studio 2026 Insiders에서도 Podman 지원이 추가되어 개발자 도구 생태계가 확장되고 있습니다.
Red Hat이 Podman을 선택한 이유
Red Hat이 RHEL에서 Docker를 제외하고 Podman을 기본으로 채택한 이유는 다음과 같습니다.
첫째, 보안입니다. 엔터프라이즈 고객은 보안에 민감하며, 데몬리스/루트리스 아키텍처는 명확한 보안 이점을 제공합니다.
둘째, 라이선스 독립성입니다. Docker Inc.와의 비즈니스 관계에서 벗어나 자체 기술 스택을 확보했습니다.
셋째, OCI 표준 준수입니다. 특정 벤더에 종속되지 않는 개방형 표준을 지향합니다.
넷째, Kubernetes 친화성입니다. Pod 개념 지원, CRI-O와의 연계 등 OpenShift 생태계와의 일관성을 유지합니다.
선택 가이드
Docker를 선택해야 할 때
Docker는 다음과 같은 환경에 적합합니다. macOS나 Windows에서 개발하는 경우 Docker Desktop의 편의성이 뛰어납니다. Docker Swarm을 사용 중이거나 계획 중인 경우에도 Docker가 필요합니다. 기존 Docker 기반 CI/CD 파이프라인을 유지해야 하거나, 팀이 Docker에 익숙하고 전환 비용을 최소화하고 싶은 경우에도 Docker가 좋은 선택입니다.
Podman을 선택해야 할 때
Podman은 다음 환경에서 강점을 발휘합니다. RHEL, CentOS, Rocky Linux 등을 사용하는 환경에서는 기본 도구로 바로 사용할 수 있습니다. 보안 규정 준수가 중요한 엔터프라이즈 환경, 루트 권한 없이 컨테이너를 실행해야 하는 경우에 적합합니다. Kubernetes 배포 전 Pod를 로컬에서 테스트하거나, systemd로 컨테이너를 서비스로 관리하려는 경우에도 Podman이 유리합니다.
마이그레이션 팁
Docker에서 Podman으로 전환하려면 다음 사항을 고려하세요.
- alias docker=podman 설정으로 기존 스크립트 호환성 확보
- Docker Compose 파일은 podman-compose로 대부분 호환
- 볼륨 위치가 다를 수 있으므로 데이터 마이그레이션 계획 필요
- CI/CD 파이프라인의 Docker 명령어를 순차적으로 테스트
- 루트리스 모드에서의 네트워크/볼륨 권한 이슈 확인
결론
Docker와 Podman은 각각의 강점이 있는 훌륭한 도구입니다. Docker는 풍부한 생태계와 편의성으로 여전히 개발 환경의 강자이며, Podman은 보안과 현대적인 아키텍처로 엔터프라이즈 환경에서 입지를 넓히고 있습니다.
OCI 표준 덕분에 둘 사이의 전환은 어렵지 않습니다. 현재 환경과 요구사항을 고려하여 적절한 도구를 선택하되, 필요하다면 언제든 전환할 수 있다는 점을 기억하세요. 컨테이너 기술의 핵심은 도구가 아니라 컨테이너화된 애플리케이션 자체입니다.