컨테이너를 배우다 보면 "요즘은 Podman을 쓴다"는 말을 듣게 됩니다. 그런데 Podman 명령어를 보면 podman run, podman build... Docker와 거의 똑같습니다. 그러면 둘은 뭐가 다르고 왜 갈아타는 걸까요. 겉모습(CLI)은 거의 같지만 속을 굴리는 구조가 다릅니다. 핵심 차이는 "중앙 데몬이 있느냐"입니다.
데몬 — 가장 큰 구조 차이
Docker는 dockerd라는 백그라운드 데몬이 항상 떠 있고, docker 명령은 그 데몬에게 일을 시킵니다. 모든 컨테이너가 이 데몬의 자식으로 돌아갑니다. 데몬이 죽으면 관리가 끊기고, 데몬이 보통 root 권한으로 돌기에 공격 표면이 됩니다.
Podman은 데몬이 없습니다(daemonless). podman run을 치면 그 명령이 컨테이너 프로세스를 직접 띄우고 끝납니다. 각 컨테이너가 독립 프로세스라, 중앙 한 점이 무너지면 전부 영향받는 구조가 아닙니다.
한눈에 보는 비교
| 항목 | Docker | Podman |
|---|---|---|
| 아키텍처 | 중앙 데몬(dockerd) | 데몬 없음 |
| 기본 권한 | root 데몬 | rootless 기본 지원 |
| systemd 연동 | 제한적 | 네이티브(quadlet) |
| Pod 개념 | 없음(compose로 대체) | 내장(podman pod) |
| 명령어 | docker ... | podman ...(거의 동일) |
명령어는 사실상 호환
Podman은 의도적으로 Docker CLI를 그대로 흉내 냈습니다. 그래서 옮겨가도 손에 익은 명령이 거의 그대로 동작합니다.
# Docker
docker run -d -p 8080:80 nginx
docker ps
# Podman — 단어만 바뀜
podman run -d -p 8080:80 nginx
podman ps
심지어 alias docker=podman으로 별칭을 걸어 기존 스크립트를 거의 수정 없이 쓰기도 합니다. Dockerfile도 그대로 podman build로 빌드됩니다.
보안 — rootless가 핵심 명분
Podman이 주목받는 가장 큰 이유는 rootless 컨테이너가 기본이라는 점입니다. 일반 사용자 권한으로 컨테이너를 띄우므로, 컨테이너가 뚫려도 host의 root로 바로 번지지 않습니다. Docker도 rootless 모드를 지원하지만 별도 설정이 필요하고 기본값이 아닙니다.
언제 무엇을 쓰나
팀 전체가 Docker Desktop과 docker compose에 익숙하고 생태계 자료가 풍부한 환경이라면 Docker가 여전히 가장 마찰이 적습니다. 반면 RHEL·Fedora 계열 서버이거나, root 데몬을 없애고 싶거나, 컨테이너를 systemd 서비스로 깔끔하게 관리하고 싶다면 Podman이 잘 맞습니다. 컨테이너가 < 3개인 단순 개발 환경에선 사실 어느 쪽이든 차이를 못 느끼고, 차이는 보안·운영 규모가 커질수록 또렷해집니다.
다만 docker compose에 해당하는 부분은 Podman에서 podman-compose나 Kubernetes YAML(podman play kube)로 처리해야 해서, 여기서 약간의 전환 비용이 생깁니다.
요점 정리
- 가장 큰 차이는 데몬 유무 — Docker는 중앙 데몬, Podman은 daemonless.
- 명령어는 거의 동일해
docker를podman으로 바꾸면 대체로 동작한다. - Podman은 rootless가 기본이라 보안·멀티테넌트 서버에 유리하다.
- compose 워크플로가 핵심이면 Docker, root 제거·systemd 통합이 목표면 Podman.
데몬 구조와 rootless 차이를 직접 명령으로 확인하며 컨테이너 기초를 다지는 실습은 도커 트랙에서 할 수 있습니다 — 회원가입 없이 무료로.