포드맨은 정말 새로운 도커인가? 실무자가 본 진짜 차이점

2026년 4월 24일|Platform Decision|10분 읽기

컨테이너 도구의 변화, 그리고 선택의 고민

요즘 컨테이너 관련 커뮤니티를 보다 보니 포드맨(Podman)에 대한 언급이 부�쩍 늘었습니다. "도커의 대안", "더 안전한 컨테이너 엔진" 같은 표현들이 눈에 띄더라고요. 과연 포드맨이 도커를 대체할 새로운 표준이 될까요?

직접 써보고 비교해본 결과, 단순히 '새로운 도커'라고 부르기엔 근본적인 차이가 있었습니다. 어떤 상황에서 무엇을 선택해야 할지, 실무 관점에서 정리해봤습니다.

도커의 지배와 새로운 접근법의 등장

도커는 컨테이너화를 대중화한 일등공신입니다. Dockerfile로 이미지를 빌드하고, Docker Engine으로 실행하는 방식은 이제 개발자들에게 너무나 익숙하죠.

하지만 도커의 아키텍처를 들여다보면 한 가지 특징이 있습니다. 클라이언트-서버 구조를 사용한다는 점입니다.

[Docker CLI] → [Docker Daemon] → [containerd] → [컨테이너]
                (dockerd)        (런타임)

이 구조에서 도커 데몬은 보통 root 권한으로 실행됩니다. 편리하지만, 보안 관점에서는 우려스러운 부분이죠. 데몬이 공격받으면 시스템 전체가 위험해질 수 있거든요.

컨테이너 생태계가 성숙하면서, 특히 쿠버네티스와 OCI 표준이 자리 잡으면서 "더 안전하고 유연한 방법은 없을까?"라는 고민이 생겨났습니다. 바로 여기서 포드맨이 주목받기 시작했습니다.

포드맨의 다른 접근법: 데몬이 없다는 것

**포드맨(Podman)**은 Pod Manager의 줄임말로, Red Hat에서 개발한 컨테이너 엔진입니다. 가장 큰 특징은 데몬리스(daemonless) 아키텍처입니다.

[Podman CLI] → [OCI 런타임(runc)] → [컨테이너]

포드맨은 백그라운드 데몬이 없습니다. 명령어를 실행하면 직접 OCI 런타임과 상호작용하고, 작업이 끝나면 프로세스가 종료됩니다. 이런 설계가 가져오는 장점들이 있습니다:

리소스 효율성: 유휴 상태일 때 메모리나 CPU를 점유하는 백그라운드 프로세스가 없습니다.

보안 강화: 공격 대상이 될 수 있는 중앙집중식 데몬이 존재하지 않습니다. 각 명령어는 실행한 사용자의 권한으로만 동작하죠.

루트리스 컨테이너: 일반 사용자 권한으로도 컨테이너를 실행할 수 있습니다. 이는 보안상 상당한 이점입니다.

# 일반 사용자로 컨테이너 실행
podman run --rm -it alpine sh

위 명령어는 sudo 없이도 실행되며, 컨테이너도 해당 사용자의 권한으로만 동작합니다.

핵심 차이점들 살펴보기

실제 사용해보면서 느낀 주요 차이점들을 정리해봤습니다.

아키텍처: 데몬 vs 데몬리스

구분	Docker	Podman
구조	클라이언트-서버 (데몬 필요)	직접 실행 (데몬 없음)
프로세스	dockerd가 항상 실행	명령어 실행 시에만 프로세스 생성
권한	보통 root 데몬 필요	사용자 권한으로 실행 가능

보안: 루트 vs 루트리스

도커는 기본적으로 컨테이너가 내부에서 root 권한으로 실행됩니다. 데몬 자체도 root로 돌아가는 경우가 많죠. 포드맨은 루트리스 컨테이너를 네이티브로 지원합니다. 컨테이너가 탈출하더라도 일반 사용자 권한 밖으로는 나갈 수 없어서, 시스템 전체가 위험해지는 상황을 방지할 수 있습니다.

빌드 도구의 분리

도커는 docker build가 CLI의 일부지만, 포드맨은 buildah라는 별도 도구를 사용합니다.

# Podman에서 이미지 빌드 (내부적으로 buildah 사용)
podman build -t myapp:latest .

# 또는 buildah 직접 사용으로 더 세밀한 제어
buildah from alpine
buildah run alpine apk add curl
buildah commit alpine myapp:latest

팟(Pod) 개념의 지원

포드맨의 이름에서 알 수 있듯이, 쿠버네티스의 팟 개념을 로컬에서도 사용할 수 있습니다.

# 팟 생성
podman pod create --name webapp-pod -p 8080:80

# 팟에 컨테이너들 추가
podman run -d --pod webapp-pod --name web nginx
podman run -d --pod webapp-pod --name redis redis

# 쿠버네티스 YAML 생성도 가능
podman generate kube webapp-pod > webapp.yaml

팟 내의 컨테이너들은 네트워크와 스토리지를 공유하므로, 로컬 개발 환경에서 쿠버네티스와 유사한 테스트를 할 수 있습니다.

CLI 호환성: 기존 워크플로우 유지하기

다행히 포드맨은 도커 CLI와 높은 호환성을 제공합니다. 기존 스크립트나 근육 기억을 그대로 활용할 수 있죠.

# 별칭 설정으로 기존 명령어 그대로 사용
alias docker=podman

# 이제 기존 docker 명령어들이 그대로 작동
docker run hello-world
docker ps
docker images

다만 macOS나 Windows에서는 포드맨도 Linux VM이 필요합니다. podman machine 명령어로 관리할 수 있는데, Docker Desktop보다는 경량화된 솔루션입니다.

# macOS/Windows에서 Podman 환경 설정
podman machine init
podman machine start

어떤 상황에서 무엇을 선택할까

실제 프로젝트에서 어떤 걸 써야 할지 고민이 되죠. 상황별로 정리해봤습니다.

Docker를 선택하는 경우

기존 투자가 큰 경우: 이미 Docker 기반 CI/CD가 구축되어 있고, 팀이 익숙하다면 굳이 바꿀 필요는 없습니다.
올인원 솔루션 선호: Docker Desktop의 GUI, 이미지 스캔, 쿠버네티스 통합 등이 필요한 경우.
커뮤니티와 생태계: 아직은 도커의 서드파티 도구 지원이 더 풍부합니다.

Podman을 선택하는 경우

보안이 중요한 환경: 루트리스 컨테이너와 데몬리스 아키텍처가 제공하는 보안 이점이 필요한 경우.
Red Hat/Fedora 생태계: RHEL 8+ 및 Fedora에서는 포드맨이 기본 컨테이너 엔진입니다.
리소스 제약 환경: 서버나 임베디드 환경에서 데몬 오버헤드를 최소화하고 싶은 경우.
쿠버네티스 개발: 로컬에서 팟 개념으로 테스트하고 싶은 경우.
권한 관리: sudo 없이 컨테이너 작업을 하고 싶은 개발 환경.

현실적인 접근법

사실 많은 개발팀에서는 상황에 따라 두 도구를 병행하고 있습니다. 로컬 개발 편의성을 위해 Docker Desktop을 쓰고, 서버나 프로덕션 환경에서는 포드맨의 보안성을 활용하는 식으로요.

포드맨이 도커를 완전히 대체하는 "새로운 도커"는 아닙니다. 오히려 다른 철학과 접근법을 가진 대안적 도구라고 보는 게 맞는 것 같습니다. 보안과 효율성에 중점을 둔 환경에서는 포드맨이, 기존 워크플로우와 생태계 활용이 중요한 곳에서는 도커가 각각의 장점을 발휘하고 있거든요.

결국 도구는 목적에 맞게 선택하는 것이 가장 중요하다는 평범한 결론에 도달합니다.

#podman#docker#container#devops#security