Podman vs Docker: 홈랩 환경에서의 성능 및 관리 비교

안녕하세요, 13년차의 서버실 주인장입니다. 제 홈랩 이야기를 풀어놓는 곳이죠. 오늘은 많은 분들이 궁금해하실 만한 주제, 바로 Podman(팟맨)과 Docker(도커)에 대해 이야기해보려고 합니다. 저도 처음 인프라 엔지니어 일을 시작할 때부터 Docker를 줄곧 써왔고, 사실 컨테이너 하면 Docker가 거의 대명사처럼 쓰였잖아요? 근데 요즘 들어 Podman이 심상치 않다는 이야기를 많이 듣게 되더라고요. 특히나 개인적인 홈랩 환경에서는 어떤 선택이 더 좋을지 직접 비교해보고 싶어서, 제 홈랩 서버에 둘 다 설치해서 며칠간 굴려봤습니다. 삽질도 좀 했고요. ㅎㅎ

컨테이너 기술은 이제 선택이 아닌 필수가 되었죠. 마이크로서비스 아키텍처(MSA)부터 CI/CD 파이프라인, 심지어 IoT 디바이스까지, 어디든 컨테이너가 쓰이지 않는 곳이 없습니다. 홈랩에서도 마찬가지예요. 웹서버, 데이터베이스, 각종 모니터링 툴까지 컨테이너로 띄워두면 관리도 편하고 자원도 효율적으로 쓸 수 있거든요. 하지만 두 가지 주요 컨테이너 런타임(Container Runtime), Podman과 Docker 중에서 어떤 것을 선택해야 할지 고민하는 분들이 많으실 겁니다. 저도 그랬거든요.

Podman과 Docker의 핵심 아키텍처 차이를 시각적으로 비교한 다이어그램입니다. 데몬 유무, rootless 모드 지원 여부 등에 초점을 맞춥니다.

Podman과 Docker, 뭐가 다른가요?

쉽게 말해, 둘 다 컨테이너를 만들고 실행하는 도구죠. 하지만 내부적으로 작동하는 방식에는 꽤 큰 차이가 있어요. 제가 직접 써보면서 느낀 핵심적인 차이점들을 짚어볼게요.

• Docker (도커): 컨테이너 기술의 사실상 표준이 되었죠. 데몬(Daemon) 기반으로 작동합니다. 즉, dockerd라는 백그라운드 프로세스가 항상 떠 있어서 클라이언트의 명령을 받고 컨테이너를 관리하는 형태예요. 이 데몬이 모든 컨테이너 작업을 총괄하고, API를 통해 명령을 주고받는 클라이언트-서버 아키텍처(Client-Server Architecture)죠.
• Podman (팟맨): Red Hat에서 주도적으로 개발한 컨테이너 런타임입니다. 가장 큰 특징은 데몬리스(Daemonless)라는 점이에요. 백그라운드 데몬 없이 필요한 시점에만 프로세스가 실행되고, 컨테이너를 직접 생성하고 관리합니다. 그리고 루트리스(Rootless) 모드를 기본적으로 지원해서, 일반 사용자 계정으로도 컨테이너를 실행할 수 있다는 게 강력한 장점이거든요.

더 자세한 차이점을 표로 정리해볼게요.

홈랩에서 Podman과 Docker 직접 설치하고 써보기

제 홈랩 서버는 Ubuntu 22.04 LTS를 사용하고 있습니다. 일반적으로 많이 쓰시는 환경이라 이 기준으로 설명드릴게요.

1. Docker 설치 및 기본 사용

Docker는 워낙 유명하니 설치는 비교적 간단합니다. 공식 문서에 따라 진행하면 되죠.

# 기존 Docker 버전 제거 (선택 사항)
sudo apt-get remove docker docker-engine docker.io containerd runc

# 필수 패키지 설치
sudo apt-get update
sudo apt-get install ca-certificates curl gnupg lsb-release

# Docker 공식 GPG 키 추가
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

# Docker APT 저장소 설정
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Docker Engine 설치
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin

# 사용자 계정을 docker 그룹에 추가 (sudo 없이 docker 명령어 사용)
sudo usermod -aG docker $USER
newgrp docker # 변경사항 즉시 적용

# Docker 서비스 확인
systemctl status docker

# Nginx 컨테이너 실행 예시
docker run -d --name my-nginx -p 8080:80 nginx:latest
docker ps

설치 후에는 docker run, docker ps 같은 명령어로 컨테이너를 쉽게 관리할 수 있어요. 익숙한 명령어들이죠? docker-compose도 플러그인 형태로 같이 설치되니 멀티 컨테이너 환경 구성에도 편리합니다.

2. Podman 설치 및 기본 사용 (그리고 Rootless!)

Podman도 Ubuntu에서는 APT 저장소를 통해 쉽게 설치할 수 있어요.

# Podman 설치
sudo apt-get update
sudo apt-get install podman

# Podman 버전 확인
podman --version

# Nginx 컨테이너 실행 예시 (루트리스 모드)
podman run -d --name my-nginx-podman -p 8081:80 nginx:latest
podman ps

# Podman 서비스 활성화 (원격 API나 systemd 통합을 위해)
# 이 명령은 rootless 모드에서 사용자별 systemd 서비스를 활성화합니다.
systemctl --user enable --now podman.socket

# Docker CLI처럼 원격으로 Podman 데몬에 연결하는 방법 (선택 사항)
# DOCKER_HOST 환경 변수를 설정하면 docker CLI 명령어를 podman에 연결할 수 있습니다.
# export DOCKER_HOST=unix:///run/user/$(id -u)/podman/podman.sock
# docker ps # 이제 podman 컨테이너를 보여줍니다 (docker CLI 사용)

루트리스 모드(Rootless Mode)가 Podman의 가장 큰 매력 중 하나라고 했잖아요? 위 예시처럼 그냥 podman run을 실행하면 기본적으로 현재 사용자 계정의 권한으로 컨테이너가 실행돼요. 이게 진짜 편하더라고요. 보안 측면에서도 훨씬 안전하고요. 만약 컨테이너에서 어떤 취약점이 발견되더라도, 호스트 시스템의 루트 권한을 직접적으로 탈취하기가 훨씬 어려워지거든요.

Podman으로 rootless 컨테이너를 실행하고 터미널에서 확인하는 화면입니다. user namespace가 잘 설정되었음을 보여줍니다.

3. 멀티 컨테이너 오케스트레이션: Docker Compose vs Podman Play Kube

여러 컨테이너를 함께 띄워야 할 때 Docker Compose(도커 컴포즈)는 정말 유용해요. 하나의 docker-compose.yaml 파일로 서비스들을 정의하고 한 번에 관리할 수 있죠. Podman에서는 비슷한 역할을 하는 podman-compose라는 툴도 있지만, 저는 podman play kube를 주로 사용해봤습니다. YAML 파일을 Kubernetes(쿠버네티스) 형식으로 작성해서 Podman으로 실행하는 방식인데, 미래를 생각하면 이쪽이 더 좋겠다 싶더라고요.

# docker-compose.yaml 예시
version: '3.8'
services:
  web:
    image: nginx:latest
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
  db:
    image: postgres:13
    environment:
      POSTGRES_DB: mydb
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password

# Docker Compose 실행
docker-compose up -d

# Podman Play Kube를 위한 YAML 파일 (Kubernetes Pod 정의)
# web-pod.yaml 예시
apiVersion: v1
kind: Pod
metadata:
  name: my-web-pod
spec:
  containers:
    - name: nginx-container
      image: nginx:latest
      ports:
        - containerPort: 80
          hostPort: 8082 # Podman에서는 hostPort를 명시해야 외부 노출
    - name: postgres-container
      image: postgres:13
      env:
        - name: POSTGRES_DB
          value: mydb
        - name: POSTGRES_USER
          value: user
        - name: POSTGRES_PASSWORD
          value: password

# Podman Play Kube 실행
podman play kube web-pod.yaml
podman ps -a

podman play kube는 Kubernetes의 Pod(파드) 개념을 Podman 환경에서 그대로 사용할 수 있게 해줍니다. 나중에 Kubernetes로 전환할 계획이 있다면, 미리 익숙해질 수 있는 좋은 기회가 되죠.

⚠️ 삽질 경험: Podman rootless 모드와 포트 바인딩

제가 Podman을 처음 쓰면서 가장 삽질했던 부분이 바로 루트리스 모드에서의 포트 바인딩(Port Binding)이었어요. podman run -p 80:80 nginx 처럼 80번 같은 특권 포트(Privileged Port, 1024번 이하)를 바인딩하려고 하면 에러가 나더라고요. 처음엔 이게 뭔가 싶었는데, 일반 사용자 계정은 1024번 이하 포트에 바인딩할 권한이 없기 때문이었습니다.

해결책:

1. 비특권 포트 사용: 가장 간단한 방법은 8080, 8000처럼 1024번 이상의 비특권 포트(Non-privileged Port)를 사용하는 거예요. podman run -p 8080:80 nginx 이렇게요. 홈랩에서는 보통 이 방법으로 충분합니다.
2. rootful Podman 사용: 정말 특권 포트를 써야 한다면 sudo podman run -p 80:80 nginx 처럼 루트 권한으로 실행할 수도 있어요. 하지만 이는 루트리스 모드의 장점을 포기하는 것이 되니, 특별한 경우가 아니면 권장하지 않습니다.
3. sysctl 설정 (주의 필요!): 극히 드물지만, 일반 사용자도 특권 포트를 사용할 수 있도록 시스템 설정을 변경하는 방법도 있어요. sudo sysctl -w net.ipv4.ip_unprivileged_port_start=80 와 같은 명령어를 사용하는데, 보안상 매우 위험하니 절대 따라 하지 마세요. 제 삽질 경험을 공유하는 차원에서만 언급합니다.

이 외에도 Podman이 systemd와 통합되는 방식이나, SELinux(에스이리눅스)가 활성화된 환경에서는 추가적인 설정이 필요할 수 있어요. 로그를 확인할 때는 journalctl --user -xeu podman.socket 처럼 사용자별 systemd 저널을 보는 것이 도움이 됩니다.

성능 비교 및 관리 용이성

자, 그럼 가장 중요한 부분이죠. 성능과 관리 용이성은 어땠을까요? 제가 직접 여러 컨테이너를 띄워놓고 htop, sar, iostat 같은 도구들로 모니터링해봤습니다.

성능

솔직히 말하면, 제 홈랩 환경(저사양 미니 PC)에서는 Podman과 Docker 간의 드라마틱한 성능 차이를 벤치마크 수치로 딱 잘라 말하기는 어려웠어요. 하지만 체감적으로 Podman이 약간 더 가볍게 느껴지는 부분은 있었습니다. 특히 시스템 리소스가 제한적인 홈랩 환경에서는 이 작은 차이가 중요할 수 있더라고요.

• 메모리 사용량 (Memory Usage): Docker는 dockerd라는 데몬이 항상 일정량의 메모리를 점유하고 있어요. Podman은 데몬이 없으니 이 오버헤드(Overhead)가 없습니다. 여러 개의 컨테이너를 띄우지 않는다면 큰 차이가 아닐 수 있지만, 저처럼 컨테이너를 수십 개씩 띄우는 홈랩에서는 무시할 수 없는 부분입니다.
• CPU 사용량 (CPU Usage): 마찬가지로 데몬의 존재 유무가 CPU 사용량에도 영향을 미칠 수 있어요. 특히 유휴 상태(Idle State)일 때 Podman이 미세하게 더 낮은 CPU 사용률을 보였습니다.
• I/O 성능 (Disk I/O): 이 부분에서는 큰 차이를 느끼기 어려웠어요. 컨테이너 런타임보다는 기본 스토리지 드라이버나 실제 디스크 성능에 더 큰 영향을 받더라고요.

결과 해석 기준: 만약 htop에서 `dockerd` 프로세스가 지속적으로 1% 이상의 CPU를 점유하거나, `top` 명령어로 확인했을 때 `VIRT` (Virtual Memory Size) 값이 수백 MB 이상으로 높게 나온다면, 데몬으로 인한 오버헤드를 고려해볼 만해요. 홈랩처럼 리소스가 제한된 환경에서는 이런 작은 수치들이 전체 시스템 안정성에 영향을 줄 수 있거든요.

홈랩 환경에서 Podman과 Docker 컨테이너의 CPU, 메모리, 디스크 I/O 사용량을 비교하는 대시보드 스크린샷입니다. Prometheus, Grafana 같은 툴을 활용한 시각화를 보여줍니다.

관리 용이성

• 명령어 호환성: Podman은 Docker CLI 명령어와 거의 100% 호환돼요. docker run 대신 podman run이라고만 바꾸면 되니, 기존 Docker 사용자들이 쉽게 적응할 수 있습니다. 이게 진짜 편하더라고요.
• systemd 통합: Podman은 systemd와 아주 잘 통합돼요. 컨테이너를 systemd 서비스로 등록해서 자동으로 시작하고 관리할 수 있죠. podman generate systemd --name my-nginx-podman > ~/.config/systemd/user/my-nginx-podman.service 이런 식으로 쉽게 서비스 파일을 만들 수 있어서, 서버 재부팅 시 컨테이너를 수동으로 다시 띄울 필요가 없어집니다.
• Kubernetes 친화적: podman play kube 기능을 통해 Kubernetes YAML 파일을 직접 실행할 수 있다는 점은 향후 클라우드 환경이나 복잡한 오케스트레이션으로 넘어갈 때 큰 강점이 돼요.

그래서, 홈랩에는 어떤 컨테이너 런타임이 좋을까요?

저의 13년차 인프라 엔지니어이자 홈랩 운영자로서의 경험을 바탕으로 명확한 결론과 추천을 드려볼게요.

• Docker를 추천하는 경우:
  • 이미 Docker에 익숙하고, 복잡한 설정 변경을 원치 않는다면: 기존 Docker Compose 파일들이 많고, 커뮤니티 자료나 플러그인 생태계를 그대로 활용하고 싶다면 Docker가 여전히 좋은 선택이에요.
  • Docker Swarm(도커 스웜)을 활용한 간단한 클러스터가 필요하다면: Podman은 Swarm을 직접 지원하지 않아요.
  • 상대적으로 고사양의 서버를 사용하고 데몬 오버헤드가 크게 문제 되지 않는다면: 데몬의 안정성과 광범위한 사용 사례를 그대로 가져갈 수 있습니다.
• Podman을 추천하는 경우:
  • 보안을 최우선으로 생각하고, 루트리스 컨테이너를 선호한다면: 홈랩 환경에서 보안은 아무리 강조해도 지나치지 않아요. 루트리스 모드는 잠재적인 보안 위협을 크게 줄여줍니다.
  • 시스템 리소스가 제한적인 저사양 홈랩 서버를 운영한다면: 데몬 오버헤드가 없기 때문에 미세하게라도 자원을 더 효율적으로 사용할 수 있어요.
  • 향후 Kubernetes 환경으로 확장할 계획이 있다면: podman play kube를 통해 Kubernetes YAML 파일에 익숙해질 수 있고, Pod 개념을 미리 체험해볼 수 있습니다.
  • systemd와의 긴밀한 통합을 통해 컨테이너 자동화를 하고 싶다면: Podman의 systemd 통합은 컨테이너 관리를 한층 더 편리하게 만들어줍니다.

Podman과 Docker의 주요 장단점을 비교하고, 홈랩 환경에 적합한 선택 기준을 시각적으로 요약한 인포그래픽입니다.

개인적으로는 요즘 Podman에 손이 더 많이 갑니다. 특히 루트리스 모드와 systemd 통합이 저에게는 굉장히 매력적이더라고요. 제 홈랩 서버가 그렇게 고사양은 아니라서 리소스 효율성도 무시할 수 없고요. 물론 Docker가 가진 강력한 생태계와 안정성은 여전히 큰 장점이지만, 새로운 기술을 시도하고 실험해보는 홈랩의 재미를 생각하면 Podman은 충분히 도전해볼 가치가 있는 툴입니다.

여러분도 이 글을 통해 자신의 홈랩 환경에 맞는 컨테이너 런타임을 선택하는 데 도움이 되셨으면 좋겠어요. 다음 글에서는 Podman으로 Nginx와 Let’s Encrypt를 연동해서 HTTPS 웹서버를 구축하는 방법에 대해 더 자세히 다뤄볼 예정이니 기대해주세요! 그때 또 다른 삽질 경험담과 해결책을 공유해드리겠습니다. 🎉