2026년 Docker vs Podman: 아무도 안 알려주는 완전 비교 & 마이그레이션 가이드

컨테이너 업계에 재밌는 일이 벌어지고 있어요. 컨테이너화라는 개념 자체를 만든 Docker가 조용히 자리를 내주고 있거든요. 화려한 스타트업한테가 아니라, 대부분의 개발자가 써본 적도 없는 오픈소스 Podman한테요.

숫자를 보면 바로 체감돼요. Podman GitHub 스타가 2026년 초에 30,000 돌파. Red Hat·SUSE·Canonical은 배포판에 기본 탑재. Kubernetes가 1.24에서 Docker 런타임을 빼버린 이후로 "우리 컨테이너 스택, 이대로 괜찮나?" 하는 팀이 급격히 늘었고요. 거기다 Docker Desktop 라이선스 변경으로 "다들 공짜로 쓰던 도구"가 "직원 250명 넘거나 매출 $10M 넘으면 월$24/시트"가 되어버렸어요.

근데 비교 글 대부분이 핵심을 놓쳐요. Podman이 Docker보다 "낫냐"가 아니에요. 내 워크플로우, 팀 규모, 보안 요건, 배포 환경을 놓고 봤을 때 어느 쪽이 실질적으로 더 맞느냐 — 그 판단이 중요해요.

이 글에서는 아키텍처 차이를 제대로 파고, 실제 마이그레이션 시나리오를 검증하고, 의미 있는 것만 벤치마크하고, 구체적인 판단 기준을 정리할 거예요. 두루뭉술한 결론 없어요. 바로 가볼게요.

아키텍처: 설계 철학부터 다르다

Docker와 Podman의 가장 큰 차이는 아키텍처에 있어요. 뒤에 나올 모든 차이가 여기서 갈려요.

Docker는 데몬이 항상 떠 있다

Docker는 dockerd라는 백그라운드 데몬이 상주하는 클라이언트-서버 구조예요.

┌─────────────┐     ┌──────────────┐     ┌───────────────┐
│ docker CLI  │────▶│   dockerd    │────▶│  containerd   │
│  (클라이언트) │     │   (데몬)     │     │   (런타임)    │
└─────────────┘     └──────────────┘     └───────────────┘
                          │
                    root로 실행
                    항상 대기 중
                    모든 컨테이너 관리

docker run nginx 치면 CLI가 데몬한테 요청 보내고, 데몬이 이미지 pull하고, 컨테이너 만들고, 라이프사이클 전체를 관리해요. 기본적으로 root 권한으로 떠 있고, 시스템의 모든 컨테이너를 이 데몬 하나가 관리해요.

이 구조의 장점은 분명해요.

• 한 곳에서 관리: 하나의 프로세스가 전체 컨테이너 상태를 파악
• 터미널 닫아도 OK: 백그라운드에서 컨테이너가 계속 돌아감
• 생태계가 기대함: Docker Compose, Swarm, 수천 개 도구가 데몬 소켓을 전제로 만들어짐

대가도 확실해요.

• 공격 표면이 넓다: 데몬이 root. 뚫리면 호스트 전체를 내줌
• 단일 장애점: dockerd 죽으면 전부 같이 죽음
• 놀고 있어도 먹는다: 아무 컨테이너 안 돌려도 메모리·CPU를 잡아먹음

Podman은 데몬이 없다

Podman은 접근이 완전히 달라요. 데몬 자체가 없어요.

┌─────────────┐     ┌───────────────┐
│ podman CLI  │────▶│    conmon     │
│   (직접)     │     │ (컨테이너별   │
└─────────────┘     │   모니터)     │
                    └───────────────┘
                          │
                    일반 사용자 권한
                    fork-exec 방식
                    컨테이너마다 독립

podman run nginx 치면 Podman이 conmon(경량 모니터)을 통해 컨테이너 프로세스를 직접 fork해요. 상주 데몬 없어요. 각 컨테이너가 내 계정 아래 독립 프로세스로 돌아가요.

뭐가 좋냐면——

• root 필요 없음: 기본적으로 내 UID로 돌아감
• 하나 죽어도 다른 건 멀쩡: 장애가 전파 안 됨
• 안 쓰면 아무것도 안 돌아감: 유휴 리소스 소비 0
• systemd랑 바로 붙음: 컨테이너를 systemd 서비스로 관리 가능

물론 트레이드오프도 있어요.

• 중앙 관리가 없음: 세션 단위로 관리 (Podman DB가 영속성은 처리)
• 로그아웃하면 꺼짐: 유지하려면 podman generate systemd나 --restart 플래그 필요
• Docker 전용 도구와의 호환: /var/run/docker.sock 기대하는 도구는 소켓 경로 바꿔줘야 함

보안: 사실 이게 제일 중요한 이야기

"루트리스 컨테이너" — 버즈워드처럼 들리지만, 구체적으로 뭘 막아주는지 알면 생각이 바뀌어요.

Docker의 root 문제

Docker 데몬은 기본이 root예요. -v /host/path:/container/path로 볼륨 마운트하면 컨테이너 프로세스가 호스트 파일을 root 권한으로 읽고 쓸 수 있거든요. user namespace, seccomp, AppArmor 같은 방어책이 있긴 한데, 전부 opt-in이고 실제로 켜놓는 팀은 소수예요.

얼마나 위험한지 보면——

# root 데몬 환경에서의 컨테이너 탈출
docker run -v /:/host --privileged alpine chroot /host
# → 호스트 파일시스템 전체에 root 접근 가능

Docker 20.10부터 루트리스 모드가 있긴 한데, 직접 설정해야 해요.

# 루트리스 모드 설정
dockerd-rootless-setuptool.sh install

# 확인
docker info | grep "Root Dir"
# ~/.local/share/docker 아래 경로가 나오면 OK

현실적으로 대부분의 Docker 환경은 데몬을 root로 돌려요. 기본값이 그렇고, 튜토리얼도 루트리스를 안 다루니까요.

Podman은 처음부터 루트리스

Podman은 아무 설정 없이 루트리스예요. 그냥 돼요.

# 설정 없이 바로 실행
podman run -d nginx

# 내 유저 권한으로 돌아가는지 확인
podman top -l user
# root 아니라 내 UID가 나옴

내부적으로 Linux user namespace를 써서, 컨테이너의 UID를 호스트의 비특권 UID에 매핑해요.

# 컨테이너 안에서 nginx는 root(UID 0)라고 생각하지만
# 호스트에서는 실제로 내 유저(예: UID 1000)로 돌아감
podman unshare cat /proc/self/uid_map

# 출력:
#          0       1000          1
#          1     100000      65536

컨테이너 탈출이 성공해도 공격자가 얻는 건 내 일반 유저 권한뿐이에요. root는 못 건드려요.

보안 비교 정리

항목	Docker (기본)	Docker (루트리스)	Podman
데몬 실행 권한	root	일반 유저	데몬 없음
호스트에서의 컨테이너 UID	root	매핑됨	매핑됨
특권 소켓	/var/run/docker.sock (root 소유)	$XDG_RUNTIME_DIR/docker.sock	없음
기본 Capability	넓은 범위	축소	최소한
SELinux/AppArmor	선택 사항	선택 사항	기본 활성
Seccomp 프로필	기본 프로필	기본 프로필	더 엄격한 기본값
데몬 침해 시 피해	root 권한 탈취	유저 권한 범위	해당 없음

SOC 2, PCI-DSS, HIPAA 같은 컴플라이언스 대상 팀이라면, Podman 쪽이 감사 대응이 훨씬 수월해요.

CLI 호환성: alias docker=podman은 얼마나 통하나

Podman이 영리했던 건, Docker CLI와 거의 100% 호환되는 인터페이스를 만든 거예요.

# 셸 설정에 추가
alias docker=podman

# 이제 Docker 쓰는 것처럼 하면 됨
docker pull nginx
docker run -d -p 8080:80 nginx
docker ps
docker build -t myapp .
docker push myregistry/myapp

그대로 되는 것

• docker run / build / pull / push
• docker ps / logs / exec
• docker images / rmi
• docker network create/ls/rm
• docker volume create/ls/rm

안 되는 것

Docker Compose — Podman에서는 podman-compose가 있고, 호환 소켓으로 Docker Compose v2도 연결 가능해요.

# 방법 1: podman-compose (Python, 가벼움)
pip install podman-compose
podman-compose up -d

# 방법 2: Podman 호환 소켓 → Docker Compose v2 연결
systemctl --user enable --now podman.socket
export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/podman/podman.sock
docker compose up -d

Docker Swarm — Podman에 대응 기능 없어요. 아직 Swarm 쓰는 팀(요즘 드물긴 하지만)한테는 완전한 블로커예요.

Docker-in-Docker (DinD) — CI/CD에서 자주 쓰이는 패턴인데, Podman에서는 다르게 접근해요.

# Docker 방식 — privileged 필요
docker run --privileged -v /var/run/docker.sock:/var/run/docker.sock docker

# Podman 방식 — 루트리스, privileged 불필요
podman run --security-opt label=disable \
  -v $XDG_RUNTIME_DIR/podman/podman.sock:/var/run/docker.sock \
  docker

Docker Desktop 고유 기능 — GUI, 내장 Kubernetes, Extensions Marketplace, Dev Environments는 Podman Desktop이 부분적으로 커버하지만 기능적으로 동등하진 않아요.

Kubernetes 연동: Podman의 가장 큰 강점

Docker가 구조적으로 따라잡기 어려운, Podman의 진짜 차별점이에요.

네이티브 Pod 지원

Podman은 Kubernetes Pod와 같은 개념 — 네트워크 네임스페이스를 공유하는 컨테이너 묶음 — 을 1급 시민으로 지원해요.

# Pod 만들기
podman pod create --name webapp -p 8080:80

# 컨테이너 추가
podman run -d --pod webapp --name frontend nginx
podman run -d --pod webapp --name api node:20-slim

# 두 컨테이너가 localhost를 공유
# frontend에서 localhost:3000으로 API 접근 가능

Kubernetes가 컨테이너를 묶는 방식과 정확히 같아요. Docker에는 이런 개념이 아예 없어서, 컨테이너마다 별도 네트워크 네임스페이스가 할당돼요.

Kubernetes YAML 바로 뽑기

돌아가는 Pod에서 Kubernetes용 YAML을 바로 생성할 수 있어요.

# 실행 중인 Pod에서 YAML 뽑기
podman generate kube webapp > webapp.yaml
cat webapp.yaml

# Podman이 생성한 YAML
apiVersion: v1
kind: Pod
metadata:
  name: webapp
spec:
  containers:
    - name: frontend
      image: docker.io/library/nginx:latest
      ports:
        - containerPort: 80
          hostPort: 8080
    - name: api
      image: docker.io/library/node:20-slim

거꾸로도 돼요.

# Kubernetes YAML을 로컬에서 실행
podman play kube webapp.yaml

# 내리기
podman play kube webapp.yaml --down

이 podman play kube 워크플로우가 쓸모 있는 상황은 많아요.

• 프로덕션 Kubernetes와 똑같은 구조로 로컬 개발
• 풀 클러스터 없이 매니페스트 동작 확인
• Docker Compose에서 Kubernetes로 점진적으로 넘어가기

Docker의 Kubernetes 접근은 간접적

Docker 쪽에서 Kubernetes를 쓰려면 좀 돌아가야 해요.

# Docker Desktop에 내장 K8s 클러스터가 있긴 하지만
# 경량 Pod가 아니라 풀 K8s를 통째로 띄우는 구조

# Docker Compose → K8s 변환은 외부 도구가 필요
kompose convert -f docker-compose.yaml
# → 나온 YAML은 대체로 손으로 많이 고쳐야 씀

Docker Compose와 Kubernetes는 추상화 수준이 다릅니다. Compose가 정의하는 건 "서비스", Kubernetes가 정의하는 건 "워크로드". 변환하면 반드시 정보가 빠져요. Podman의 Pod 개념이 이 갭을 네이티브로 메워주는 거예요.

Docker Compose vs Podman Compose: 현장에서의 비교

실무에서 컨테이너 하나만 돌리는 경우는 드물잖아요. Compose로 여러 개 묶어서 관리하는 게 일반적이고, 여기가 마이그레이션의 진짜 고비예요.

Docker Compose (v2)

Docker Compose v2는 성숙하고 프로덕션 실적이 충분해요.

# docker-compose.yaml
services:
  web:
    build: ./frontend
    ports:
      - "3000:3000"
    depends_on:
      - api
      - db
    environment:
      - API_URL=http://api:4000

  api:
    build: ./backend
    ports:
      - "4000:4000"
    depends_on:
      db:
        condition: service_healthy
    environment:
      - DATABASE_URL=postgresql://postgres:secret@db:5432/myapp

  db:
    image: postgres:16
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      - POSTGRES_PASSWORD=secret
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5

volumes:
  pgdata:

docker compose up -d
docker compose logs -f
docker compose down

Podman 쪽 선택지

방법 1: podman-compose (Python, 커뮤니티)

pip install podman-compose
podman-compose up -d

가볍고 심플한 게 장점. 단, Docker Compose v2 전체 기능은 커버 못 해요 (healthcheck.condition, 일부 네트워크 모드, profiles 등).

방법 2: Docker Compose v2 + Podman 소켓 (복잡한 구성이면 이쪽)

# Podman Docker 호환 소켓 시작
systemctl --user start podman.socket

# Docker CLI가 Podman으로 가게 설정
export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/podman/podman.sock

# 이제 그냥 docker compose가 동작
docker compose up -d

Podman의 Docker 호환 API를 경유하니까 완전한 호환이 돼요. 복잡한 Compose 파일 옮길 때 가장 무난한 경로예요.

방법 3: Quadlet (Podman 네이티브, systemd 통합)

# ~/.config/containers/systemd/webapp.container
[Container]
Image=docker.io/library/nginx:latest
PublishPort=8080:80
Volume=webdata:/usr/share/nginx/html

[Service]
Restart=always

[Install]
WantedBy=default.target

systemctl --user daemon-reload
systemctl --user start webapp.service

Quadlet은 컨테이너를 systemd 유닛 파일로 정의하는 Podman 고유 방식이에요. Compose보다 프로덕션 지향이지만, 기존 오케스트레이션을 다시 짜야 해요.

CI/CD 파이프라인

마이그레이션에서 가장 까다로운 부분이에요. CI 인프라 대부분이 Docker를 전제로 만들어져 있으니까요.

GitHub Actions

Docker (기본):

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build image
        run: docker build -t myapp:${{ github.sha }} .
      - name: Push to registry
        run: |
          echo ${{ secrets.REGISTRY_TOKEN }} | docker login ghcr.io -u ${{ github.actor }} --password-stdin
          docker push ghcr.io/${{ github.repository }}/myapp:${{ github.sha }}

Podman (거의 그대로 교체):

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build image
        run: podman build -t myapp:${{ github.sha }} .
      - name: Push to registry
        run: |
          podman login ghcr.io -u ${{ github.actor }} -p ${{ secrets.REGISTRY_TOKEN }}
          podman push ghcr.io/${{ github.repository }}/myapp:${{ github.sha }}

GitHub ubuntu-latest 러너에 Podman이 기본 설치되어 있어서, 정말로 명령어 이름만 바꾸면 돼요.

GitLab CI

GitLab CI는 전통적으로 DinD(Docker-in-Docker)를 쓰는데, privileged 모드가 필요해요.

Docker (privileged 필요):

build:
  image: docker:latest
  services:
    - docker:dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

Podman (privileged 불필요):

build:
  image: quay.io/podman/stable
  script:
    - podman build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - podman push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

--privileged 안 써도 된다는 건, CI에서 컨테이너 탈출 취약점을 구조적으로 차단한다는 뜻이에요. 눈에 안 띄지만 큰 차이예요.

Buildah: 이미지 빌드 전용 도구

Podman 생태계에는 이미지 빌드에 특화된 Buildah라는 도구가 있어요. docker build로는 못 하는 것들을 할 수 있어요.

# 스크래치 빌드: 베이스 이미지 없이, 공격 표면 제로
container=$(buildah from scratch)
buildah copy $container ./static-binary /app
buildah config --entrypoint '["/app"]' $container
buildah commit $container myapp:minimal
# → 패키지도 셸도 없는, 바이너리만 든 이미지 완성

# 레이어 단위로 세밀하게 제어
buildah run $container -- pip install -r requirements.txt
buildah run $container -- pip cache purge
buildah commit $container myapp:optimized

보안 요건이 까다로운 환경에서 특히 유용해요. 데몬 없이, 컨테이너 런타임 없이도 이미지를 만들 수 있으니까요.

성능: 실측치만 놓고 비교

마케팅 자료 말고, 실제로 차이 나는 부분만 봐요.

기동 시간

컨테이너 시작 (nginx, Alpine, SSD):

Docker:  ~0.8-1.2초 (데몬 이미 떠 있을 때)
Podman:  ~0.5-0.9초 (fork-exec, 데몬 오버헤드 없음)

부팅 후 첫 컨테이너:
Docker:  ~2-4초 (데몬 뜨는 시간 포함)
Podman:  ~0.5-0.9초 (띄울 데몬이 없음)

콜드 스타트에서는 Podman이 유리해요. 데몬이 이미 떠 있는 장기 운영 서버에서는 체감 차이 거의 없고요.

빌드 시간

이미지 빌드 (Node.js 멀티스테이지, 캐시 없음):

Docker BuildKit:  ~45-60초
Podman (Buildah): ~48-65초

캐시 히트 시:
Docker BuildKit:  ~3-5초
Podman (Buildah): ~3-5초

사실상 같아요. 복잡한 멀티스테이지 빌드에서 BuildKit 캐시가 약간 낫긴 한데, 차이가 10%를 넘는 경우는 드물어요.

메모리

유휴 시:

Docker 데몬:     ~50-100MB (항상 소비)
Podman:          ~0MB (아무것도 안 돌아감)

컨테이너당:
Docker:          ~5-10MB (conmon + shim)
Podman:          ~3-8MB (conmon만)

유휴 비용 0은 개발 머신이나 CI 러너에서 은근히 체감돼요. 프로덕션 서버에서 50개 넘게 돌리면 컨테이너당 오버헤드는 거의 같고요.

이미지 Pull

nginx:latest (압축 ~70MB):
Docker:   ~4-6초
Podman:   ~4-6초

대형 ML 이미지 (~5GB):
Docker:   ~45-90초
Podman:   ~45-90초

유의미한 차이 없어요. 같은 OCI 레지스트리 프로토콜 쓰니까 당연하죠.

Docker Desktop vs Podman Desktop

macOS·Windows 개발자한테는 GUI 경험도 중요하죠.

Docker Desktop

• 비용: 개인·교육·250명 미만 & 매출 $10M 미만 기업은 무료. 그 외$24/월/사용자 (Business)
• Kubernetes: 싱글 노드 클러스터 내장
• Extensions: 100개 이상 서드파티 확장
• Dev Environments: Codespaces 비슷한 원격 개발 환경
• VM 관리: macOS/Windows에서 Linux VM 자동 관리
• 리소스 제어: CPU/메모리 제한 GUI
• 볼륨: 볼륨 관리·검사 GUI

Podman Desktop

• 비용: 무료, Apache 2.0
• Kubernetes: Kind/Minikube 연동 (내장 아님)
• Extensions: 성장 중, 아직 생태계 작음
• VM 관리: podman machine으로 자동 관리
• 리소스 제어: 기본 CPU/메모리 설정
• Pod 관리: Pod 생성·관리가 1급 시민 기능

혼자서나 소규모 팀이면 Podman Desktop으로 충분해요. Docker Desktop의 Extensions, Dev Environments, 엔터프라이즈 기능(SSO, 이미지 접근 관리, Hardened Desktop)에 의존하는 팀이라면 아직 Docker Desktop이 나아요.

마이그레이션 순서: Docker → Podman

신중하게 옮기고 싶다면 이 순서가 검증되어 있어요.

1단계: 로컬 개발 (1-2주)

# 1. 설치
# macOS:
brew install podman
podman machine init
podman machine start

# Linux (Ubuntu/Debian):
sudo apt install podman

# 2. alias 설정 (Docker도 그대로 쓸 수 있음, 비파괴적)
echo 'alias docker=podman' >> ~/.zshrc
source ~/.zshrc

# 3. 기존 작업 흐름 테스트
docker pull your-registry/your-app:latest
docker run -d -p 3000:3000 your-registry/your-app:latest

# 4. Compose 호환성 확인
systemctl --user start podman.socket
export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/podman/podman.sock
docker compose up -d

2단계: CI/CD (3-4주)

# 기존 Docker 빌드 놔두고 Podman 빌드를 병렬로 추가
# 기존 파이프라인 안 건드리면서 검증 가능
build-podman:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - name: Build with Podman
      run: |
        podman build -t myapp:${{ github.sha }} .
        podman push ghcr.io/${{ github.repository }}/myapp:${{ github.sha }}

3단계: 프로덕션 (5주+)

# 실행 중 컨테이너에서 systemd 서비스 생성
podman generate systemd --new --files --name webapp

# 설치·활성화
cp container-webapp.service ~/.config/systemd/user/
systemctl --user enable --now container-webapp.service

# Quadlet 방식이면 더 간결 (위 Quadlet 섹션 참고)

옮길 때 자주 걸리는 것

1. 볼륨 권한: 루트리스 모드에서 UID 매핑이 다름. podman unshare chown 필요할 수 있음
2. 포트 바인딩: 루트리스에서는 1024 미만 포트 직접 바인드 불가. sysctl net.ipv4.ip_unprivileged_port_start=0으로 해제
3. 네트워크 모드: --network=host가 루트리스에서 다르게 동작
4. 소켓 마운트: /var/run/docker.sock 마운트하는 도구는 Podman 소켓 경로로 바꿔야 함

판단 기준: 2026년 기준으로 정리

애매하게 안 쓸게요. 구체적으로 갈게요.

Docker 유지

• 직원 250명 미만 & 매출 $10M 미만 — Docker Desktop 무료. 생태계 혜택이 큼
• Docker Swarm 의존도 높음 — Podman에 대응하는 게 없음
• CI/CD가 Docker 전용 기능에 묶여 있음 — BuildKit 고급 캐시, Compose 풀 기능, DinD 패턴 등 바꾸기 부담이 크면
• Docker Desktop Extensions 일상적으로 씀 — 취약점 스캐닝, 로그 탐색, DB 도구 등
• 팀이 Linux 아닌 환경 — macOS/Windows에서의 Docker Desktop 경험이 필수라면

Podman 전환

• 보안 컴플라이언스 최우선 — 기본 루트리스, 데몬 없음, 최소 Capability. 구조적으로 강함
• Docker Desktop 비용이 부담 — $24/시트/월 × 100명 = 연$28,800. Podman Desktop은 무료
• Kubernetes 타겟 — 로컬과 프로덕션 환경을 맞추고 싶으면 Podman Pod + podman play kube가 정말 편함
• Linux 서버 — systemd 네이티브 컨테이너 관리(Quadlet)를 원하면
• CI에서 루트리스 빌드 필요 — privileged 없이 빌드 가능한 것 자체가 보안 개선
• 리소스 효율이 중요 — 공유 CI 러너, 개발 노트북에서 상시 데몬 비용이 아까우면

하이브리드 (현실에서 가장 많은 패턴)

대부분의 팀은 한꺼번에 안 갈아타요. 이렇게 섞어 쓰는 게 일반적이에요.

1. Linux 서버 → Podman — 루트리스, systemd 통합, 라이선스 프리
2. 개발 머신 → Docker Desktop — GUI 완성도, Extensions, 온보딩 쉬움
3. CI/CD → Podman — privileged 불필요, GitHub 러너에 기본 설치

OCI 표준 덕분에 이미지 호환 100%라서 이런 혼용이 아무 문제 없이 돌아가요.

앞으로의 흐름

컨테이너 생태계는 "표준은 수렴, 구현은 분기"하는 단계에 들어섰어요.

OCI 표준화는 사실상 완료. 이미지·런타임·배포 스펙이 성숙했어요. Docker든 Podman이든 같은 이미지를 빌드하고 실행해요. "Docker에서 되는데 Podman에서 깨진다"는 시대는 끝났어요.

WebAssembly(Wasm) 컨테이너가 보완 기술로 떠오르고 있어요. Docker(runwasi)와 Podman(crun-wasm) 모두 기존 Linux 컨테이너 옆에서 Wasm 워크로드를 돌릴 수 있어요. 밀리초 기동, 초소량 메모리, 더 강력한 샌드박싱. Linux 컨테이너를 대체하진 않겠지만, 경량 연산 워크로드에서 점유율이 늘어갈 거예요.

루트리스 기본값이 업계 표준이 되어가고 있어요. Docker도 릴리즈마다 루트리스 모드가 다듬어지고 있고요. Podman의 설계 철학 — 루트리스 기본, 데몬 없음 기본 — 이 도구 선택과 무관하게 아키텍처 논쟁에서 이기고 있어요.

Dev Container와 컨테이너 기반 개발 환경이 계속 성숙 중이에요. Docker(Dev Containers 스펙)와 Podman(Podman Desktop 통합) 모두 지원해요. 개발 환경이 컨테이너 기반으로 가는 추세인 만큼, 런타임 선택의 무게가 더 커지고 있어요.

결론

솔직하게 — 뭘 최우선으로 두느냐에 달렸어요. 다만 2년 전보다 답이 선명해졌어요.

보안, 비용, Kubernetes 정합성이 최우선이면 2026년 기준 Podman이 더 강한 선택지예요. 기본 루트리스·데몬리스·네이티브 Pod 지원은 Docker가 뒤쫓고 있는 구조적 장점이에요.

생태계 성숙도, macOS/Windows 개발 경험, 기존 도구의 관성이 더 중요하면 Docker가 여전히 실용적 기본값이에요. 커뮤니티 규모, Desktop 완성도, 정보량(튜토리얼, Stack Overflow, CI 템플릿)에서 아직 Docker 쪽이 앞서요.

좋은 소식은, 둘 다 OCI 표준을 지키니까 벤더 락인이 없다는 거예요. Docker로 시작해서, CI는 Podman, 프로덕션도 Podman, 로컬은 Docker Desktop — 이런 혼용이 아무 문제없이 돼요. 이미지도, 레지스트리도, Dockerfile(Podman도 Dockerfile 빌드함)도 전부 공용이에요.

컨테이너 세계가 갈린 건 호환성 때문이 아니라 철학 때문이에요. 데몬 상주 vs 데몬 없음. 기본 root vs 기본 루트리스. 상용 제품 vs 커뮤니티 프로젝트. 2026년 현재, 두 철학 모두 프로덕션 품질을 내고 있어요. 트위터에서 누가 더 목소리 큰지 말고, 우리 팀의 제약과 우선순위에 맞춰 고르면 돼요.

하나 골라서 컨테이너 띄우고, 진짜 어려운 문제 — 그 안에서 돌아가는 코드 — 에 집중하세요.