보안 우려와 데몬리스 아키텍처로 주목받는 컨테이너 기술, 개발자가 Docker에서 Podman으로 전환하는 이유

[한국정보기술신문] 컨테이너 기술 분야에서 Docker의 대안으로 주목받고 있는 Podman이 개발자들 사이에서 빠르게 확산되고 있다. 한 개발자는 최근 기술 블로그를 통해 "6개월간 Podman을 프로덕션 환경에서 사용한 결과 훨씬 안정적이고 안전한 환경을 구축할 수 있었다"고 전환 경험을 공유했다. Docker가 지속적으로 백그라운드에서 실행되는 dockerd 데몬에 의존하는 구조인 반면, Podman은 데몬 없이 직접 컨테이너를 실행하는 방식을 채택하고 있어 보안과 안정성 면에서 우위를 점하고 있다는 평가다.

보안 취약점 증가로 대안 모색 급증

Docker 생태계에서 발생한 일련의 보안 사고들이 개발자들의 우려를 자극하고 있다. 2019년부터 2024년까지 CVE-2019-5736, CVE-2022-0847, CVE-2024-21626 등 주요 보안 취약점들이 지속적으로 발견되면서 Docker 데몬의 루트 권한 실행 방식에 대한 근본적인 의문이 제기되고 있다. 특히 2024년에는 Docker API를 노린 암호화폐 채굴 공격과 Docker 스웜 봇넷 캠페인이 실제로 발생하면서 보안에 대한 우려가 현실화됐다. 이러한 상황에서 Podman의 데몬리스 아키텍처는 단일 장애점을 제거하고 공격 표면을 크게 줄일 수 있는 해결책으로 인식되고 있다.

Podman의 가장 큰 장점으로 꼽히는 것은 루트리스(rootless) 컨테이너 실행 기능이다. 기존 Docker가 루트 권한으로 데몬을 실행하는 것과 달리, Podman은 일반 사용자 권한으로 컨테이너를 실행할 수 있어 보안 위험을 현저히 줄인다. 컨테이너 내부에서 루트 권한을 획득하더라도 호스트 시스템에서는 여전히 비특권 사용자로 동작하기 때문에 시스템 전체가 위험에 노출될 가능성이 크게 감소한다. Red Hat에서 개발한 Podman은 처음부터 이러한 보안 모델을 염두에 두고 설계되어 별도의 복잡한 설정 없이도 안전한 컨테이너 환경을 제공한다.

Kubernetes 네이티브 지원으로 클라우드 준비성 확보

클라우드 네이티브 개발 환경에서 Podman은 Kubernetes와의 긴밀한 통합을 제공한다는 점에서 경쟁우위를 확보하고 있다. Podman은 포드(pod) 개념을 네이티브로 지원하여 여러 컨테이너를 하나의 단위로 관리할 수 있으며, 'podman generate kube' 명령어를 통해 로컬 개발 환경에서 작성한 포드를 Kubernetes YAML 파일로 직접 변환할 수 있다. 이러한 기능은 개발자들이 로컬 환경과 프로덕션 환경 사이의 차이를 최소화하고 일관된 개발 워크플로우를 유지할 수 있도록 돕는다. 특히 k3s와 같은 경량 Kubernetes 도구 없이도 멀티 컨테이너 애플리케이션을 프로토타이핑할 수 있어 개발 효율성이 크게 향상된다.

리눅스 서버 환경에서 Podman의 또 다른 강점은 systemd와의 자연스러운 통합이다. 'podman generate systemd' 명령어를 통해 컨테이너를 표준 시스템 서비스로 변환할 수 있어 부팅 시 자동 시작, 장애 시 자동 재시작, 리소스 제한 등의 기능을 별도의 프로세스 관리자 없이도 활용할 수 있다. 이는 Docker Compose나 Docker Swarm과 같은 추가 도구에 의존하지 않고도 컨테이너를 프로덕션 환경에서 안정적으로 운영할 수 있음을 의미한다. 또한 systemctl 명령어를 통한 표준적인 서비스 관리가 가능해 시스템 관리자들에게 친숙한 운영 환경을 제공한다.

Podman으로의 전환을 고려하는 개발자들이 가장 우려하는 부분은 기존 워크플로우의 변경이지만, 실제로는 이러한 우려가 크지 않은 것으로 나타났다. Podman은 Docker CLI와 거의 완벽한 호환성을 제공하여 'docker' 명령어를 'podman'으로 단순히 치환하는 것만으로도 대부분의 작업이 가능하다. 기존 Dockerfile도 수정 없이 그대로 사용할 수 있으며, Docker Compose 파일도 podman-compose를 통해 실행할 수 있다. 일부 개발자들은 셸에서 'alias docker=podman' 설정을 통해 기존 명령어를 그대로 사용하면서도 Podman의 이점을 누리고 있다고 보고했다.

FastAPI 마이그레이션 사례로 검증된 실용성

실제 프로덕션 환경에서의 전환 사례를 통해 Podman의 실용성이 입증되고 있다. Python FastAPI 애플리케이션의 경우 기존 Dockerfile을 수정 없이 그대로 사용하여 'podman build -t my-fastapi-app:latest .' 명령어로 이미지를 빌드할 수 있다. 컨테이너 실행 역시 'podman run -d -p 8000:8000 --name my-fastapi-container my-fastapi-app:latest' 와 같이 Docker와 동일한 방식으로 진행된다. 다만 Podman이 기본적으로 루트리스 모드로 실행되어 1024번 이하의 특권 포트에 직접 바인딩할 수 없다는 점은 오히려 리버스 프록시를 사용하는 더 나은 아키텍처로 유도한다는 평가를 받고 있다.

2025년 현재 컨테이너 기술 시장에서 Docker는 여전히 압도적인 점유율을 보이고 있지만, Podman의 성장세는 주목할 만하다. 특히 보안이 중요한 엔터프라이즈 환경과 클라우드 네이티브 개발에서 Podman 채택이 늘어나고 있다. Red Hat을 비롯한 주요 리눅스 배포판에서 Podman을 기본 컨테이너 도구로 채택하는 추세도 이러한 변화를 가속화하고 있다. 업계 전문가들은 앞으로 더 많은 개발 도구들이 Docker와 Podman 모두를 지원하게 될 것이며, 특히 보안과 Kubernetes 통합이 중요한 프로젝트에서는 Podman이 더욱 선호될 것이라고 전망하고 있다. 다만 Docker의 강력한 생태계와 기존 사용자 기반을 고려할 때 단기간 내 완전한 대체는 어려울 것으로 보인다는 분석도 나오고 있다.

한국정보기술신문 클라우드분과 이준호 기자 news@kitpa.org