2026년 AI/ML 워크로드를 위한 Docker vs Podman: 기술적 비교

이 글은 매일 프로덕션 환경에서 GPU 컨테이너를 운영하는 사람의 솔직한 비교입니다. Docker와 Podman 모두 훌륭한 컨테이너 런타임 (Container Runtime)입니다. 하지만 2026년 AI/ML 인프라 측면에서, 만약 여러분이 추론 서비스 (Inference Services), 학습 파이프라인 (Training Pipelines), 또는 에이전트형 AI 워크플로우 (Agentic AI Workflows)를 구축하고 있다면 Docker가 중요한 부분에서 앞서 나가고 있습니다.

저는 keda-gpu-scaler (KEDA를 위한 GPU 오토스케일링), otel-gpu-receiver (OpenTelemetry를 위한 GPU 관측성), 그리고 Volcano에 GPU NUMA 토폴로지 스케줄링을 기여했습니다. 이 모든 것은 Docker 컨테이너에서 실행됩니다. 그 이유는 다음과 같습니다.

1. Docker Model Runner — Podman에는 대응되는 기능이 없음

Docker Model Runner를 사용하면 동일한 CLI 및 레지스트리 인프라를 사용하여 컨테이너와 함께 LLM을 가져오고(Pull), 실행하고, 관리할 수 있습니다:

# 이미지를 가져오는 것과 동일하게 모델을 가져옵니다
docker model pull ai/llama3.2:1B-Q8_0

...

이는 통합된 워크플로우입니다. 애플리케이션을 위한 컨테이너, AI를 위한 모델, 동일한 CLI, 동일한 라이프사이클 관리 (Lifecycle Management). OpenAI 호환 API를 지원하므로 로컬 개발 (Model Runner)과 프로덕션 (자체 호스팅 vLLM 또는 클라우드 API) 사이에서 코드를 변경할 필요가 없습니다.

Podman에는 이에 상응하는 기능이 없습니다. AI 애플리케이션을 구축한다면 Podman과 별개로 Ollama, llama.cpp 또는 다른 추론 런타임 (Inference Runtime)을 설치하고 관리해야 합니다. 두 개의 도구, 두 개의 라이프사이클, 두 세트의 설정이 필요하게 됩니다.

승자: Docker

2. GPU 패스스루 (GPU Passthrough) UX

두 런타임 모두 NVIDIA Container Toolkit을 지원합니다. 기능 자체는 대등합니다. 하지만 사용자 경험 (UX)은 다릅니다.

Docker

docker run --gpus all nvidia/cuda:12.4-base nvidia-smi

플래그 하나면 충분합니다. nvidia-container-toolkit을 설치한 후 바로 작동합니다. Linux 상의 Docker Desktop과 WSL2는 GPU 패스스루 설정을 자동으로 처리합니다.

Podman

podman run \
  --device nvidia.com/gpu=all \
  --security-opt=label=disable \
...

CDI (Container Device Interface) 설정이 필요합니다. --security-opt=label=disable 옵션이 필요한 이유는 루트리스 (rootless) 모드에서 SELinux가 기본적으로 GPU 장치 접근을 차단하기 때문입니다. 루트리스 (rootless) GPU 지원에는 추가적인 예외 상황이 존재합니다. 즉, CDI 장치 노드를 비특권 사용자 (unprivileged user)가 읽을 수 있어야 하며, 이를 위해서는 추가적인 시스템 설정이 필요합니다.

특정 GPU를 노출하고자 하는 멀티 GPU (multi-GPU) 설정의 경우:

Docker:

docker run --gpus '"device=0,2"' my-training-image

Podman:

podman run --device nvidia.com/gpu=0 --device nvidia.com/gpu=2 \
  --security-opt=label=disable my-training-image

두 방식 모두 작동합니다. Docker의 구문 (syntax)이 더 간결하며, GPU 특정 사용 사례에 대해 더 잘 문서화되어 있습니다.

승자: Docker (UX), 무승부 (원시 기능 측면)

3. Docker Scout — 통합 공급망 보안 (Integrated Supply Chain Security)

Docker Scout는 Docker CLI에 내장되어 있습니다:

# 취약점 스캔
docker scout cves my-gpu-image:latest

...

Scout는 Docker Official Images 및 Docker Hardened Images에 대한 퍼스트 파티 (first-party) 출처 (provenance) 데이터를 보유하고 있습니다. Scout는 소스(source) → 빌드(build) → 이미지(image)로 이어지는 전체 의존성 체인 (dependency chain)을 파악합니다. 이는 GPU 이미지에서 매우 중요한데, 의존성 트리 (dependency trees)가 매우 깊기 때문입니다 (OS → CUDA → cuDNN → Python → PyTorch → vLLM). 따라서 CVE (Common Vulnerabilities and Exposures)가 이 체인의 어느 곳에나 숨어 있을 수 있습니다.

Podman에는 내장된 스캐닝 기능이 없습니다. 대신 Trivy, Grype 또는 Snyk을 별도의 도구로 사용해야 합니다. 이들은 훌륭한 스캐너들이지만, 컨테이너 CLI에 통합되어 있지 않으며 Docker 이미지 출처에 대한 퍼스트 파티 (first-party) 지식을 가지고 있지 않습니다.

CI 파이프라인 (CI pipelines)의 경우, Docker Scout는 심각한 CVE 발생 시 빌드를 실패 처리할 수 있는 GitHub Action을 제공합니다:

- name: Docker Scout scan
  uses: docker/scout-action@v1
  with:
...

승자: Docker

4. Docker Extensions 생태계

Docker Desktop은 커뮤니티에서 제작한 도구들이 포함된 확장 프로그램 마켓플레이스(extensions marketplace)를 보유하고 있습니다. 저는 NVIDIA GPU 메트릭(utilization, memory, temperature, power draw per device)을 Docker Desktop에서 직접 실시간으로 보여주는 GPU Dashboard extension을 직접 제작했습니다. 터미널이나 nvidia-smi가 필요 없습니다.

Podman Desktop도 플러그인 시스템을 갖추고 있으며 성장 중입니다. 하지만 Docker의 마켓플레이스가 더 규모가 크고 더 활발하게 홍보되고 있습니다. 만약 GPU/AI 워크플로우를 위한 개발자 도구를 구축하고 있다면, Docker Extensions가 더 많은 사용자에게 도달할 수 있습니다.

확장 프로그램 개발 경험 또한 Docker가 더 성숙해 있습니다. SDK, 문서화, 그리고 예시 확장 프로그램들이 더 앞서 나가 있습니다.

승자: Docker

5. AI 에이전트를 위한 Docker 샌드박스 (Docker Sandboxes)

Docker Sandboxes는 코드를 실행하거나, API를 호출하거나, 파일을 수정하는 LLM과 같은 에이전트형 AI (agentic AI) 워크로드를 위해 특수 제작된 격리 환경을 제공합니다:

services:
  ai-agent:
    image: my-agent:latest
...

이는 신뢰할 수 없는 LLM 생성 코드를 안전하게 실행해야 하는 특정 유스케이스를 위해 설계되었습니다. 파일 시스템 격리(Filesystem isolation), 네트워크 송신 규칙(network egress rules), 리소스 제한(resource limits), 휘발성 실행(ephemeral execution) 등이 모두 하나의 설정 안에 포함됩니다.

Podman의 방식은 사용자 네임스페이스(user namespaces)를 통한 기본 루트리스(rootless-by-default) 방식으로, 강력한 범용 격리를 제공합니다. 하지만 에이전트 전용 샌드박스 추상화는 존재하지 않습니다. 루트리스 모드, --network=none 및 수동 iptables 규칙, cgroups 제한, 그리고 tmpfs 마운트의 조합을 통해 동일한 기능을 구축해야 합니다. 가능은 하지만, 즉시 사용 가능한(turnkey) 형태는 아닙니다.

승자: Docker (AI 에이전트 유스케이스 기준)

6. GPU 개발을 위한 Docker Compose

Docker Compose와 Podman Compose 모두 GPU 워크로드를 처리하지만, Docker Compose가 더 성숙한 GPU 지원을 제공합니다:

# Docker Compose — 네이티브 GPU 지원
services:
  inference:
...

Podman Compose는 CDI를 통해 GPU 장치를 지원하지만, 구문(syntax)이 다르고 멀티 GPU 구성에 대한 문서화가 부족합니다. 또한 Docker Compose는 Docker Desktop의 리소스 관리와 통합되어 있어, 어떤 서비스가 어떤 GPU를 사용하고 있는지 확인할 수 있는 GUI를 제공합니다.

승자: Docker

7. Podman이 승리하는 지점

Podman이 진정으로 더 나은 부분이 어디인지 인정하지 않는다면 정직한 비교가 아닐 것입니다:

기본적으로 제공되는 Rootless (비루트 권한)

Podman은 기본적으로 권한이 없는 사용자(unprivileged user)로서 컨테이너를 실행합니다. 루트(root) 권한으로 실행되는 데몬(daemon)이 없습니다. 이는 멀티 테넌트(multi-tenant) 시스템과 Docker 데몬의 루트 액세스가 컴플라이언스(compliance) 문제가 되는 환경에서 의미 있는 보안상의 이점을 제공합니다.

데몬리스 아키텍처 (Daemonless Architecture)

백그라운드 데몬이 없다는 것은 공격 표면(attack surface)이 작아지고 단일 장애점(single point of failure)이 없음을 의미합니다. Podman 컨테이너가 충돌하더라도 다른 컨테이너에 영향을 주지 않습니다. 반면 Docker 데몬이 충돌하면 모든 것이 중단됩니다.

Systemd 통합

podman generate systemd --new --name my-gpu-service

적절한 systemd 서비스 파일을 생성합니다. GPU 컨테이너를 init 시스템에 의해 관리하고자 하는 비-Kubernetes(non-Kubernetes) 배포 환경에서 우아한 해결책이 됩니다.

Pod 시맨틱스 (Pod Semantics)

podman pod create --name ml-pod
podman run --pod ml-pod --gpus all inference-server
podman run --pod ml-pod metrics-sidecar

podman pod는 Kubernetes의 Pod 개념을 직접적으로 반영합니다. Pod 내의 컨테이너들은 네트워크 및 IPC 네임스페이스(namespaces)를 공유합니다. 로컬에서 Kubernetes Pod 구성을 프로토타이핑하고 있다면 Podman이 더 자연스럽습니다.

RHEL/CentOS 생태계

Red Hat 환경에서 작업하고 있다면 Podman은 네이티브 컨테이너 런타임(container runtime)입니다. 이는 지원되고, 패치되며, RHEL 보안 스택(SELinux, FIPS)과 통합되어 있습니다. RHEL에서 Docker를 사용하는 것도 가능하지만, 권장되는 경로(paved path)는 아닙니다.

Kubernetes YAML 지원

podman play kube deployment.yaml

Podman으로 Kubernetes YAML을 직접 실행할 수 있습니다. 클러스터 없이 매니페스트(manifests)를 테스트할 때 유용합니다. Docker에는 docker compose가 있지만, CLI에서 네이티브한 Kubernetes YAML 지원은 없습니다.

8. 프로덕션 런타임 문제

이 비교의 대부분이 놓치고 있는 사실이 있습니다: 프로덕션(production) 환경에서 Docker나 Podman 모두 여러분의 컨테이너 런타임이 아닙니다.

Kubernetes는 containerd 또는 CRI-O를 사용합니다. Docker와 Podman은 모두 OCI 준수 (OCI-compliant) 이미지를 생성하는 개발 도구입니다. docker build로 빌드한 이미지는 여러분의 Kubernetes 클러스터 내 containerd에서 동일하게 실행됩니다.

따라서 진짜 질문은 이것입니다: 어떤 도구가 GPU/AI 컨테이너를 위한 최상의 개발 경험을 제공하는가?

그 질문에 대해, 2026년 Docker의 답변은 포괄적입니다:

• 로컬 LLM 추론을 위한 Model Runner
• AI 에이전트 격리를 위한 Sandboxes
• 복잡한 GPU 의존성 트리에서의 공급망 보안을 위한 Scout
• 커스텀 개발 도구(GPU 모니터링)를 위한 Extensions
• 성숙한 GPU 지원을 갖춘 Compose
• 자동 GPU 패스스루 (passthrough) 기능을 갖춘 Desktop

Podman의 답변은 다음과 같습니다: 강력한 기본기(rootless, daemonless, pod semantics)를 갖추고 있으나, AI 특화 기능은 없습니다.

결론 (The Bottom Line)

기준	Docker	Podman
LLM 추론 (Model Runner)	✅ 내장됨	❌ 별도 도구 필요
...

2026년 AI/ML 개발을 위해: Docker를 선택하십시오. Model Runner, Sandboxes, Scout, 그리고 GPU UX의 이점은 미미한 차이가 아니라, AI 개발 워크플로 그 자체입니다.

보안 우선의 Linux 서버를 위해: Podman을 선택하십시오. 기본적으로 제공되는 rootless 방식과 daemonless 아키텍처는 실질적인 장점입니다.

프로덕션(production) Kubernetes를 위해: 상관없습니다. 둘 다 OCI 이미지를 생성하며, containerd가 이를 실행합니다.

여러분의 워크로드에 맞는 도구를 선택하십시오. GPU/AI 컨테이너의 경우, 2026년에는 Docker입니다.

Pavan Madduri는 W.W. Grainger, Inc.의 시니어 클라우드 플랫폼 엔지니어(Senior Cloud Platform Engineer), CNCF Golden Kubestronaut, 그리고 Oracle ACE Associate입니다. 그는 keda-gpu-scaler와 otel-gpu-receiver를 유지 관리하며, Docker와 Kubernetes 기반의 GPU 인프라 도구를 구축합니다.