[Cloud] Podman vs Docker: Rootless 컨테이너 보안 및 활용 가이드

Podman vs Docker: Rootless 컨테이너 보안 및 활용 가이드

인프라 엔지니어의 고민: 더 안전한 컨테이너 운영을 찾아서

안녕하세요, 13년차 서버실 지킴이입니다. 요즘 인프라 엔지니어라면 컨테이너(Container) 기술을 빼놓고 이야기하기 어렵죠. 저도 처음엔 도커(Docker)가 세상에 나왔을 때, '와, 이거 진짜 물건이다!' 하면서 열광했던 기억이 납니다. 개발 환경부터 운영 환경까지 컨테이너 덕분에 정말 많은 게 편리해졌거든요. 그런데 말입니다, 편리함 뒤에는 늘 그림자가 따르기 마련이더라고요. 특히 보안(Security) 측면에서는 늘 마음 한편이 불안했어요.

도커 데몬(Docker daemon)이 항상 루트(root) 권한으로 실행된다는 점, 그리고 컨테이너 탈출(Container Escape) 같은 잠재적인 보안 위협들은 저를 계속해서 고민하게 만들었죠. 홈랩(Home Lab)에서 다양한 서비스를 돌리면서 '어떻게 하면 좀 더 안전하게 컨테이너를 운영할 수 있을까?' 하는 고민은 저만의 숙제는 아닐 겁니다. 혹시 여러분도 이런 고민 해보신 적 있으신가요? 이 지점에서 제가 눈여겨보게 된 것이 바로 Podman(팟맨)입니다.

오늘 글에서는 컨테이너 보안의 새로운 대안으로 떠오른 Podman과 우리가 오랫동안 써왔던 Docker를 비교하고, 특히 Rootless 컨테이너(Rootless Container) 개념을 중심으로 Podman의 장점과 활용법을 자세히 알려드리려고 합니다. 제가 직접 삽질해가며 얻은 경험들을 바탕으로, 여러분의 컨테이너 운영에 도움이 될 만한 실질적인 팁들을 공유해볼게요! 💡

Podman과 Docker의 아키텍처 비교. Podman은 데몬 없이 사용자 프로세스로 실행되어 보안 이점을 가집니다.

Rootless 컨테이너란 무엇인가?

쉽게 말해, Rootless 컨테이너는 루트(root) 권한 없이, 일반 사용자(non-root user) 권한으로 실행되는 컨테이너를 말합니다. 기존 도커는 도커 데몬(Docker Daemon)이 호스트(Host) 시스템에서 루트 권한으로 실행되고, 이 데몬이 컨테이너를 관리하는 구조였죠. 이게 왜 문제가 되냐면, 만약 컨테이너에 보안 취약점이 있어서 외부 공격자가 컨테이너를 탈출(Escape)하는 데 성공하면, 호스트 시스템의 루트 권한까지 획득할 수 있는 심각한 상황이 발생할 수 있기 때문입니다. ⚠️

Podman은 태생부터 이런 보안 문제를 염두에 두고 설계되었어요. Podman은 도커와 달리 데몬(Daemon)이 없거든요. 즉, 백그라운드에서 항상 루트 권한으로 돌아가는 프로세스가 없다는 뜻입니다. Podman 명령어를 실행하면, 해당 명령어는 일반 사용자 권한으로 컨테이너를 생성하고 관리하게 됩니다. 처음 이걸 알았을 땐 '아, 이거다!' 싶었거든요. 이렇게 되면 컨테이너를 탈출하더라도 일반 사용자 권한까지만 접근할 수 있으니, 호스트 시스템의 피해를 최소화할 수 있습니다. 보안적인 측면에서 봤을 때 정말 큰 이점이라고 할 수 있어요.

Podman vs Docker: 핵심 차이점 비교

Podman과 Docker는 컨테이너를 관리하는 도구라는 공통점이 있지만, 내부적으로는 꽤 많은 차이가 있습니다. 제가 직접 써보면서 느낀 주요 차이점들을 표로 정리해봤어요.

특징	Podman	Docker
아키텍처 (Architecture)	데몬리스 (Daemonless): 백그라운드 데몬 없음. 사용자 프로세스로 실행.	데몬 기반 (Daemon-based): Docker 데몬이 루트 권한으로 백그라운드 실행.
루트 권한 (Root Privileges)	기본 Rootless: 일반 사용자 권한으로 컨테이너 실행.	데몬이 루트 권한으로 실행. Rootless 모드는 실험적 또는 부가 기능.
보안 (Security)	호스트 시스템에 대한 공격 표면(Attack Surface) 감소.	데몬 취약점 발생 시 호스트 시스템 전체 위험.
이미지 빌드 (Image Build)	Buildah(빌다)를 내부적으로 활용 (podman build).	Docker Build 엔진 사용 (docker build).
오케스트레이션 (Orchestration)	Kubernetes Pods(쿠버네티스 파드)와 높은 호환성. podman generate kube로 YAML 생성 가능.	Docker Swarm(도커 스웜), Docker Compose(도커 컴포즈) 지원.
명령어 호환성 (CLI Compatibility)	대부분의 docker 명령어와 유사 (podman으로 대체 가능).	표준 Docker CLI.

Podman과 Docker의 주요 특징들을 한눈에 비교한 표입니다. 특히 데몬리스 아키텍처와 Rootless 기본 지원이 Podman의 가장 큰 차이점이죠.

Podman으로 Rootless 컨테이너 실행하기

그럼 이제 Podman으로 Rootless 컨테이너를 직접 실행해보면서 그 편리함을 느껴볼 시간입니다! 제가 홈랩에서 주로 쓰는 CentOS Stream 9나 Fedora, 또는 Ubuntu 22.04 이상 환경에서는 Podman 설치가 아주 쉬워요.

1. 팟맨 설치하기

저는 CentOS Stream 9에서 진행했습니다. 여러분의 OS에 맞게 설치해주세요.

# CentOS/Fedora
sudo dnf install podman -y

# Ubuntu/Debian
sudo apt update
sudo apt install podman -y

설치가 완료되면, podman info 명령어로 잘 설치되었는지 확인해볼 수 있습니다.

podman info

여기서 중요한 건, 루트 권한 없이 실행해도 잘 동작한다는 점이에요! 🎉

2. Rootless 컨테이너 실행해보기

가장 기본적인 컨테이너 실행부터 시작해볼까요? Alpine 리눅스 컨테이너를 실행해보겠습니다.

podman run --rm -it alpine sh

컨테이너 내부에서 whoami 명령어를 실행해보면, root로 나올 거예요. '어? Rootless라면서 왜 컨테이너 안에서는 root지?' 하고 저처럼 당황하실 수 있는데, 이건 컨테이너 내부의 루트 사용자가 호스트 시스템의 일반 사용자에 매핑(mapping)되었기 때문입니다. 즉, 컨테이너 안에서는 여전히 강력한 권한을 가지지만, 호스트 시스템에는 아무런 영향을 주지 못하는 '가짜 루트'인 셈이죠.

이제 Nginx 웹 서버를 Rootless로 띄워볼까요?

podman run -d --name my-nginx -p 8080:80 nginx

잘 실행되었는지 확인하고, 웹 브라우저나 curl로 접속해보세요.

podman ps
curl localhost:8080

정상적으로 Nginx 초기 페이지가 보인다면 성공입니다! ✅

3. Podman의 파드(Pod) 기능 활용해보기

Podman은 쿠버네티스(Kubernetes)의 파드(Pod) 개념을 네이티브(Native)하게 지원합니다. 여러 컨테이너가 동일한 네트워크 네임스페이스(Network Namespace)와 저장소(Storage)를 공유해야 할 때 아주 유용하거든요. 제가 이걸 처음 써봤을 때, '홈랩에 간이 쿠버네티스를 구축한 느낌인데?' 하면서 감탄했어요. 🤭

먼저 파드를 생성합니다.

podman pod create --name my-web-app-pod -p 8080:80

이제 이 파드 안에 Nginx와 다른 컨테이너를 넣어보죠.

podman run -d --pod my-web-app-pod --name webserver nginx
podman run -d --pod my-web-app-pod --name data-logger alpine sleep 1h

podman pod ps 명령어로 파드와 그 안에 있는 컨테이너들을 확인할 수 있습니다.

podman pod ps

4. 이미지 빌드하기

Podman은 Dockerfile을 이용한 이미지 빌드도 완벽하게 지원합니다. docker build 대신 podman build를 사용하면 되죠. Dockerfile 예시를 하나 만들어볼게요.

# Dockerfile
FROM alpine:latest
RUN apk add --no-cache nginx
COPY ./index.html /usr/share/nginx/html/index.html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

그리고 간단한 index.html 파일도 만들어줍니다.

<!DOCTYPE html>
<html>
<head>
    <title>Hello Podman!</title>
</head>
<body>
    <h1>Welcome to my Rootless Nginx with Podman!</h1>
</body>
</html>

이제 이 두 파일이 있는 디렉토리에서 이미지를 빌드합니다.

podman build -t my-custom-nginx .

빌드된 이미지를 확인하고 실행해보세요.

podman images
podman run -d --name my-custom-web -p 8080:80 my-custom-nginx
curl localhost:8080

Podman을 이용한 이미지 빌드 과정입니다. Docker와 거의 동일한 명령어로 편리하게 이미지를 만들 수 있어요.

Podman 운영 시 주의사항

제가 Podman을 처음 접하면서 겪었던 몇 가지 '삽질'과 그 해결책을 공유합니다. 저처럼 헤매지 마시길 바라요! ㅎㅎ

1. 낮은 포트(Low Port) 바인딩 문제: Rootless 컨테이너는 기본적으로 1024번 이하의 포트(예: 80, 443)를 직접 바인딩(Binding)할 수 없습니다. 이는 보안상의 이유로 일반 사용자에게 허용되지 않는 권한이거든요. 처음 Nginx를 80번 포트에 바로 연결하려고 했을 때, '왜 안 되지?' 하면서 한참을 헤맸습니다. 😩
   해결책: 가장 쉬운 방법은 -p 8080:80처럼 1024번보다 높은 포트에 바인딩하는 것입니다. 아니면 Nginx나 Apache 같은 리버스 프록시(Reverse Proxy)를 호스트에 설정해서 80번 포트로 들어오는 트래픽을 컨테이너의 8080번 포트로 포워딩(Forwarding)하는 방법도 있어요. (sysctl net.ipv4.ip_unprivileged_port_start=80 같은 설정을 할 수도 있지만, 보안상 권장하지는 않습니다.)
2. 볼륨 마운트(Volume Mount) 권한 문제: Rootless 컨테이너에서 호스트의 특정 디렉토리를 볼륨으로 마운트할 때 권한 문제가 발생할 수 있어요. 컨테이너 내부의 UID/GID(User ID/Group ID)가 호스트 시스템의 UID/GID와 매핑되는 방식 때문에 생기는 문제인데, /etc/subuid와 /etc/subgid 파일에 정의된 보조 UID/GID 범위가 적절히 설정되어 있지 않으면 문제가 됩니다.
   해결책: 이 파일들을 수동으로 편집하거나, Podman이 자동으로 설정하도록 합니다. 대부분의 경우 Podman 설치 시 자동으로 설정되지만, 가끔 문제가 생기면 이 파일을 확인해보세요. 저도 특정 디렉토리에 로그를 남기려다가 권한 문제로 고생 좀 했어요.
3. systemd 통합: Podman은 systemd와 아주 잘 통합됩니다. podman generate systemd 명령어를 사용하면 실행 중인 컨테이너나 파드를 systemd 서비스로 등록할 수 있는 유닛(Unit) 파일을 자동으로 생성해줍니다. 이걸 몰랐을 때는 직접 유닛 파일을 만들었는데, 나중에 이 기능을 알고 얼마나 편했는지 몰라요! 🤩

검증: Rootless 컨테이너로 더 안전한 운영

Podman으로 Rootless 컨테이너를 운영하면서 제가 가장 크게 느낀 점은 '마음의 평화'입니다. 😅 호스트 시스템에 대한 잠재적인 보안 위협이 크게 줄어들기 때문에, 훨씬 안심하고 컨테이너를 돌릴 수 있게 되었거든요. podman ps, podman inspect 같은 명령어로 컨테이너 상태를 확인해보면, 도커와 거의 동일한 방식으로 작동한다는 걸 알 수 있습니다. 단지 실행 주체가 루트가 아닌 일반 사용자라는 것만 다를 뿐이죠.

특히 ~/.local/share/containers 경로를 확인해보면, 모든 컨테이너 관련 파일들이 일반 사용자 홈 디렉토리 아래에 생성된 것을 볼 수 있어요. 이게 바로 Rootless 컨테이너의 핵심 증거입니다. 👍

Rootless 컨테이너는 호스트 시스템의 루트 권한으로부터 격리되어 보안을 강화합니다.

마무리: 언제 Podman을 써야 할까?

오늘 Podman과 Docker의 차이점, 그리고 Rootless 컨테이너의 중요성에 대해 이야기해봤습니다. Podman은 다음과 같은 상황에서 특히 강력한 대안이 될 수 있다고 생각해요.

• 보안이 최우선 고려사항일 때: 특히 다중 사용자 환경이나, 호스트 시스템의 보안을 최대한 강화하고 싶을 때 Rootless Podman은 탁월한 선택입니다.
• 쿠버네티스 환경을 준비 중일 때: Podman은 쿠버네티스 파드 개념을 네이티브하게 지원하고, podman generate kube 같은 명령어로 쉽게 YAML 파일을 생성할 수 있어 쿠버네티스 학습 및 연동에 유리합니다.
• 경량화된 컨테이너 환경이 필요할 때: 백그라운드 데몬 없이 필요한 시점에만 프로세스가 실행되므로, 리소스 효율성 측면에서도 장점이 있어요.

물론 Docker도 여전히 막강한 생태계와 성숙한 도구들을 가지고 있습니다. Docker Compose나 Docker Swarm 같은 기능은 아직 Podman보다 더 안정적이고 편리한 측면이 많죠. 따라서 어떤 도구를 선택할지는 여러분의 특정 요구사항과 환경에 따라 달라질 겁니다.

저의 13년차 경험상, '만능 도구'는 없습니다. 하지만 각 도구의 장단점을 정확히 알고 상황에 맞게 사용하는 것이 진정한 엔지니어의 자세라고 생각합니다. Podman은 컨테이너 보안과 효율성을 한 단계 끌어올릴 수 있는 정말 매력적인 도구임은 분명해요. 다음번에는 Podman Compose를 이용한 다중 컨테이너 애플리케이션 배포에 대해 더 깊이 다뤄보도록 하겠습니다. 긴 글 읽어주셔서 감사합니다! 👋

📚 함께 읽으면 좋은 글

• AWS 비용 최적화: EC2, S3, RDS 절감 전략 및 Cost Explorer 활용 가이드
• Terraform으로 AWS/GCP/Azure 멀티 클라우드 환경 구축 가이드
• GitHub Actions 자체 호스팅 러너 보안 강화: 백도어 방지 및 2026년 최신 가이드
• Docker Compose로 NAS에 앱 배포 및 관리하기: Synology, TrueNAS SCALE 가이드
• TrueNAS SCALE 앱 배포: Docker 컨테이너부터 관리까지