포드맨은 정말 새로운 도커인가? 실무자가 본 진짜 차이점
컨테이너 도구의 변화, 그리고 선택의 고민
요즘 컨테이너 관련 커뮤니티를 보다 보면 포드맨(Podman) 언급이 부쩍 늘었습니다. "도커의 대안", "더 안전한 컨테이너 엔진" 같은 표현이 눈에 띄더라고요. 그럴 때마다 비슷한 질문이 따라옵니다. 포드맨이 도커를 대체할 새로운 표준이 될까요?
저도 처음엔 시큰둥했습니다. 또 하나의 컨테이너 도구가 정말 필요한가 싶었거든요. 도커가 손에 익었고, CI/CD 파이프라인도 이미 도커 기준으로 다 짜여 있으니까요. 그런데 직접 써보고 구조를 뜯어보니, 단순히 '새로운 도커'라고 부르기엔 출발점부터 다른 도구였습니다. 어떤 상황에서 무엇을 골라야 하는지, 실무 관점에서 정리해봤습니다.
도커의 지배, 그리고 구조가 만든 약점
도커는 컨테이너화를 대중화한 일등공신입니다. Dockerfile로 이미지를 빌드하고 Docker Engine으로 실행하는 흐름은 이제 너무 익숙하죠. 거의 표준어가 됐습니다.
그런데 도커의 아키텍처를 들여다보면 한 가지 특징이 눈에 들어옵니다. 클라이언트-서버 구조라는 점입니다.
[Docker CLI] → [Docker Daemon] → [containerd] → [컨테이너]
(dockerd) (런타임)
이 구조에서 도커 데몬은 보통 root 권한으로 실행됩니다. 편리합니다. 다만 편리함의 대가가 있죠. 데몬 하나가 모든 컨테이너의 생사를 쥐고 있고, 그 데몬이 root로 돌기 때문에 데몬이 뚫리면 호스트 전체가 같이 뚫립니다. 운영 환경에서 보안 검토를 받아본 사람이라면 이 '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
빌드와 실행을 분리한 건 단순히 도구를 쪼갠 게 아닙니다. 빌드 단계에서 굳이 실행용 데몬이나 root 권한을 끌어들이지 않겠다는 설계 의도가 깔려 있습니다.
팟(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
팟 안의 컨테이너들은 네트워크와 스토리지를 공유하니, 로컬에서 쿠버네티스와 비슷한 구조로 테스트해볼 수 있습니다. podman generate kube로 뽑은 YAML을 그대로 클러스터에 넣어보는 흐름은, 로컬과 운영의 간극을 줄이려는 시도라는 점에서 꽤 영리합니다.
CLI 호환성: 기존 워크플로우는 살린다
다행히 포드맨은 도커 CLI와 높은 호환성을 제공합니다. 손에 익은 명령어, 그러니까 일종의 근육 기억을 그대로 쓸 수 있죠.
# 별칭 설정으로 기존 명령어 그대로 사용
alias docker=podman
# 이제 기존 docker 명령어들이 그대로 작동
docker run hello-world
docker ps
docker images
전환 비용을 낮추는 이 호환성은 현실적으로 중요합니다. 아무리 구조가 좋아도 팀 전체가 명령어를 새로 배워야 한다면 도입이 막히니까요. 다만 모든 게 1:1로 맞아떨어지진 않습니다. 일부 플래그나 동작 차이는 전환할 때 직접 부딪혀보며 확인해야 합니다.
그리고 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에서는 포드맨이 기본 컨테이너 엔진입니다. OS와 결이 맞는 도구를 쓰는 셈이죠.
- 리소스 제약 환경: 서버나 임베디드처럼 데몬 오버헤드 한 톨도 아쉬운 경우.
- 쿠버네티스 개발: 로컬에서 팟 단위로 미리 테스트하고 싶은 경우.
- 권한 관리: sudo 없이 컨테이너 작업을 하고 싶은 개발 환경.
현실적인 접근법
실제 현장에서는 둘 중 하나를 고르기보다 상황에 따라 병행하는 팀이 많습니다. 로컬 개발 편의는 Docker Desktop으로 챙기고, 서버나 프로덕션은 포드맨의 보안 특성을 활용하는 식이죠. 도구를 신앙처럼 통일하는 것보다, 자리마다 맞는 걸 쓰는 게 현실적입니다.
포드맨은 도커를 그대로 갈아끼우는 '새로운 도커'가 아닙니다. 데몬을 걷어내고 권한을 분산한, 출발 철학이 다른 대안에 가깝습니다. 보안과 효율을 우선하는 환경에서는 포드맨이, 기존 워크플로우와 생태계가 자산인 곳에서는 도커가 각자 제 몫을 합니다.
같은 문제도 코드 자리에서 볼 때와 운영·컨설팅 자리에서 볼 때 답이 달라집니다. 데몬리스 구조가 멋있어 보여도, 팀이 도커 위에 쌓아둔 자산이 크다면 전환은 손해일 수 있죠. 반대로 보안 검토에서 'root 데몬'이 매번 발목을 잡는 조직이라면 포드맨이 그 마찰을 줄여줍니다. 도구는 목적에 맞춰 고르는 것. 평범하지만, 현장에서 가장 자주 잊는 원칙이기도 합니다.