Docker 대신 Podman을 쓰게 된 이유 - 차이점부터 실전 전환기까지

홈랩에 개인 포털 앱을 올리면서 이미지를 빌드해야 하는데, 사설 레지스트리를 따로 두지 않고 로컬에서 빌드해서 바로 k3s에 올리는 구조로 가고 싶었습니다. Docker로도 못할 건 없었지만, 이것저것 찾아보다가 결국 Podman으로 정착했는데요. 처음엔 "그냥 Docker 명령어 이름만 바꾼 거 아니야?" 싶었는데, 막상 며칠 써보니 데몬 구조나 권한 모델 자체가 달라서 실제 운영 방식에도 꽤 영향을 주더라고요. 오늘은 Docker와 Podman이 실질적으로 어떻게 다른지, 그리고 제가 겪었던 삽질 포인트까지 포함해서 정리해봅니다.

Podman이 뭔가요?

Podman은 Red Hat이 만들고 지금은 CNCF 생태계 주변에서 널리 쓰이는 컨테이너 엔진입니다. OCI(Open Container Initiative) 표준을 따르기 때문에 Docker로 빌드한 이미지를 그대로 실행할 수 있고, 명령어 체계도 docker run, docker build, docker ps와 거의 동일하게 podman으로 대체해서 쓸 수 있습니다. 실제로 많은 사람들이 alias docker=podman만 걸어두고 기존 스크립트를 거의 그대로 씁니다.

Docker와 실질적으로 뭐가 다른가

이름만 다르고 내부는 같은 줄 알았는데, 아키텍처 자체가 다릅니다. 제가 실제로 체감한 차이는 이렇습니다.

docker Docker는 데몬 기반입니다. dockerd라는 백그라운드 데몬이 상시 떠 있고, docker 명령은 그 데몬에 소켓으로 요청을 보내는 클라이언트일 뿐입니다. 데몬이 죽으면 컨테이너 관리 자체가 안 됩니다.

podman Podman은 데몬이 없습니다(daemonless). podman run을 실행하면 그 프로세스가 직접 컨테이너를 fork/exec으로 띄우고, 각 컨테이너는 독립적인 프로세스로 존재합니다. 그래서 백그라운드에 상시 떠 있는 프로세스 하나가 죽는다고 전체 컨테이너가 흔들리는 상황 자체가 없습니다. 단일 노드 홈랩처럼 리소스가 빠듯한 환경에서는 이 데몬 하나 안 떠 있는 것도 은근히 체감되는 차이였습니다.

rootless가 기본값입니다. Docker도 rootless 모드를 지원하긴 하지만 별도 설정이 필요한 반면, Podman은 일반 사용자로 그냥 podman run을 실행하면 자동으로 root 권한 없이 컨테이너가 뜹니다. 컨테이너 탈출 공격을 당해도 호스트에서 얻을 수 있는 권한이 그 사용자 권한으로 제한된다는 점에서 보안상 이점이 큽니다.

pod 쿠버네티스 Pod 개념을 네이티브로 지원합니다. podman pod create로 여러 컨테이너를 하나의 네트워크 네임스페이스에 묶을 수 있고, podman play kube로 쿠버네티스 매니페스트를 그대로 로컬에서 실행해볼 수도 있습니다.

systemd systemd 연동이 자연스럽습니다. podman generate systemd 한 줄이면 지금 떠 있는 컨테이너를 systemd 유닛 파일로 뽑아낼 수 있어서, 서버 재부팅 후에도 자동으로 컨테이너가 뜨게 만드는 작업이 훨씬 간단합니다.

직접 구축해보기 - Rocky/RHEL 계열에 Podman 설치 및 실전 사용

제가 쓰는 서버가 Rocky Linux 기반이라 그 기준으로 정리합니다. Fedora/RHEL/CentOS 계열은 거의 동일하게 적용됩니다.

1. 설치

sudo dnf install -y podman
podman --version

별도 데몬을 켜거나 서비스를 활성화할 필요가 없습니다. 설치하자마자 바로 podman run이 됩니다.

2. 이미지 빌드와 실행 - Docker와 명령어 체계는 거의 동일

podman build -t myapp:latest .
podman run -d --name myapp -p 8080:8080 myapp:latest
podman ps

Dockerfile도 수정 없이 그대로 씁니다. 사실상 docker를 podman으로 바꿔 치기만 하면 대부분의 빌드/실행 스크립트는 그대로 동작합니다.

3. 사설 레지스트리 없이 k3s에 배포하기 (제가 실제로 쓰는 방식)

홈랩 환경이라 별도 이미지 레지스트리를 안 두고, 로컬에서 빌드한 이미지를 바로 k3s(containerd)로 밀어넣는 구조로 씁니다. Docker였다면 데몬 소켓을 공유하거나 레지스트리를 하나 띄워야 했을 텐데, Podman은 이미지를 tar로 뽑아서 containerd에 바로 import하는 식으로 처리할 수 있습니다.

podman save localhost/myapp:latest -o /tmp/myapp.tar
ctr --address /run/k3s/containerd/containerd.sock -n k8s.io images import /tmp/myapp.tar

여기서 처음에 한참 헤맸던 부분이, ctr의 기본 소켓 경로(/run/containerd/containerd.sock)를 그대로 쓰면 "연결할 수 없다"는 에러만 나온다는 점이었습니다. k3s는 자체 containerd를 내장해서 쓰기 때문에 소켓 경로가 /run/k3s/containerd/containerd.sock로 따로 존재합니다. --address 옵션으로 이 경로를 명시적으로 지정해야 합니다. 그리고 k3s Deployment에서 imagePullPolicy: Never로 설정해둬야, 이미 로컬에 올라온 이미지를 다시 외부에서 당겨오려다 실패하는 걸 막을 수 있습니다.

4. rootless 사용 시 주의할 점

일반 사용자로 실행하면 자동으로 rootless가 되는 건 좋은데, 1024번 이하의 포트는 기본적으로 바인딩이 안 됩니다. 80번 포트로 서비스를 열고 싶다면 커널 설정을 하나 바꿔줘야 합니다.

sudo sysctl net.ipv4.ip_unprivileged_port_start=80

재부팅 후에도 유지하려면 /etc/sysctl.d/ 아래에 파일로 저장해둬야 합니다. 볼륨 마운트 시 호스트 파일 소유권이 컨테이너 안 UID와 안 맞아서 권한 오류가 나는 경우도 있는데, 이럴 땐 podman unshare chown으로 사용자 네임스페이스 안에서 소유권을 맞춰주면 해결됩니다.

5. 재부팅해도 자동으로 뜨게 만들기

podman generate systemd --new --name myapp > myapp.service
sudo mv myapp.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable --now myapp.service

rootless 컨테이너라면 ~/.config/systemd/user/ 아래에 넣고 systemctl --user enable --now로 등록하면 됩니다. Docker Compose에 익숙하다면 podman-compose나 최신 버전의 podman compose 서브커맨드로 기존 docker-compose.yml을 거의 그대로 쓸 수 있는데, 일부 Compose 전용 옵션은 지원이 안 되는 경우가 있어서 복잡한 파일일수록 한 번씩은 직접 띄워서 확인해보는 걸 권장합니다.

실무 전환할 때 팁

CI 스크립트가 docker 명령어를 직접 호출하고 있다면, RHEL 계열은 podman-docker 패키지를 설치하면 docker 명령을 자동으로 podman에 연결해주는 alias가 잡혀서 스크립트 수정 없이 넘어갈 수 있습니다.
레지스트리가 없는 환경에서는 이번 글에서 쓴 save + ctr import 조합, 또는 여러 노드가 있다면 podman save | ssh 대상서버 'ctr ... import -'처럼 파이프로 바로 넘기는 방식도 유용합니다.
rootless 환경에서 볼륨 권한 문제를 겪으면 podman unshare부터 확인하세요. sudo로 무작정 권한을 풀기보다 이 방법이 더 안전합니다.
기업 환경에서 Docker Desktop 유료화 이슈로 전환을 검토 중이라면, Podman Desktop이라는 GUI 도구도 따로 있으니 CLI가 부담스러운 팀이라면 같이 살펴보는 걸 추천합니다.

마무리

결국 "명령어만 다른 Docker"가 아니라 데몬 유무, 권한 모델, systemd 연동 방식까지 꽤 다른 도구라는 걸 직접 써보면서 체감했습니다. 특히 레지스트리 없이 로컬 빌드 결과물을 바로 컨테이너 런타임에 밀어넣어야 하는 홈랩/폐쇄망 환경에서는 Podman 쪽이 확실히 손이 덜 가는 느낌이었어요. 다만 아직 일부 GUI 도구나 서드파티 통합은 Docker 생태계가 훨씬 넓기 때문에, 팀 상황에 따라 장단점을 따져보고 전환하시는 걸 추천합니다. 더 자세한 옵션은 공식 문서(podman.io)를 참고하시면 됩니다.

로그인 후 댓글을 작성할 수 있습니다.