Docker와 Podman: 비슷한 시작 속도, 다른 유휴 메모리

리눅스 개발 PC에서 기존 Compose 파일과 도구를 계속 쓰는 일이 중요하다면 Docker가 편하다. 사용자별 권한 분리, systemd 서비스 운영, 컨테이너가 없을 때의 상주 메모리가 더 중요하다면 Podman이 유리하다. 같은 장비의 제한된 측정에서는 두 엔진의 컨테이너 시작 시간이 비슷했지만, Docker 쪽에는 유휴 데몬의 메모리 사용량이 남았다.

이 차이는 Podman이 모든 작업에서 더 빠르다는 뜻이 아니다. 비교 대상은 루트 권한으로 실행한 Docker Engine과 일반 사용자 권한으로 실행한 Podman이며, 시작 시간에는 이미지 다운로드가 포함되지 않았다. 엔진을 고르거나 이전할 때는 짧은 실행 시간 차이보다 권한 설정, 실행 중인 서비스의 자원 사용량, Compose 작업을 옮기는 비용을 먼저 따져야 한다.

같은 장비에서는 시작 시간이 가까웠다

Botmonster의 단일 장비 측정은 Linux Mint 22.3에서 Docker Engine 29.5를 루트 권한으로, Podman 4.9.3을 루트리스로 실행했다. 미리 내려받은 Alpine 이미지로 짧은 명령을 20회 반복했을 때 평균 시작 시간은 Docker 352ms, Podman 342ms였다. 두 결과의 변동 폭을 고려하면 이 조건에서 어느 한쪽의 시작 속도가 뚜렷하게 앞섰다고 보기 어렵다.

컨테이너가 없는 상태에서 막 재시작한 Docker의 dockerd와 containerd는 합계 144MB를 사용했다. Podman에는 이에 대응하는 상주 엔진 데몬이 없어, 실행할 컨테이너가 없는 시간에는 그 항목의 메모리 사용량이 없다. 다만 이 수치는 빈 호스트에서 잰 데몬의 사용량이다. 웹 서버나 데이터베이스가 계속 실행되는 환경의 총 메모리 차이로 바꿔 읽을 수는 없다.

실행 중인 컨테이너까지 보면 계산이 달라진다. 같은 측정에서 Podman의 루트리스 pasta 네트워크 프로세스는 컨테이너마다 약 29MB를 사용했다. 작은 서버에서 컨테이너를 여러 개 상시 운영한다면 Docker의 유휴 데몬 사용량만 빼서 절감분으로 잡기보다, 컨테이너와 네트워크 프로세스를 포함한 전체 사용량을 비교해야 한다.

데몬과 루트리스는 별개의 선택 기준이다

Podman 공식 명령 문서는 Podman을 데몬 없이 동작하는 컨테이너 엔진으로 설명하며, 대부분의 명령을 일반 사용자도 실행할 수 있다고 명시한다. 명령을 실행한 계정이 자신의 컨테이너와 이미지를 관리하는 방식은 여러 계정이 한 리눅스 호스트를 공유할 때 경계를 잡기 쉽다. 필요한 서비스는 루트 권한으로 실행할 수도 있으므로 Podman이라는 이름만으로 모든 컨테이너가 루트리스라고 가정해서는 안 된다.

Docker는 클라이언트가 데몬에 요청을 보내는 구조이고, 일반적인 시스템 데몬은 루트 권한으로 실행된다. 그러나 Docker의 루트리스 모드 문서에 따르면 이 모드에서는 데몬과 컨테이너를 모두 일반 사용자의 사용자 네임스페이스 안에서 실행한다. 컨테이너의 사용자 ID만 재매핑하고 데몬은 루트로 남겨 두는 userns-remap과도 다른 설정이다.

따라서 권한 비교는 제품 이름보다 실제 구성을 기준으로 해야 한다. Docker의 루트리스 모드는 별도 설정과 클라이언트 연결 확인이 필요하고, Podman도 서비스에 필요한 호스트 파일 접근과 사용자 ID 매핑을 맞춰야 한다. 이미 루트리스 Docker가 안정적으로 운영 중이라면 루트리스 기능 하나만을 이유로 엔진을 옮길 근거는 약하다.

공유 서버에서는 각 계정이 어떤 컨테이너 저장소와 소켓에 접근하는지가 중요하다. Podman의 사용자별 실행 모델은 계정마다 독립적으로 서비스를 맡기는 운영과 잘 맞지만, 같은 이미지를 여러 사용자가 각각 보관하면 디스크 사용량이 늘 수 있다. 어느 쪽이든 바인드 마운트한 데이터 디렉터리의 소유권과 쓰기 권한은 컨테이너 안의 사용자 표시만 보고 판단할 수 없다.

네트워크 결과는 엔진만의 성적표가 아니다

앞선 단일 장비 측정에서는 공개 포트의 다운로드 경로에서 루트리스 Podman의 pasta 구성이 루트 권한 Docker의 브리지 구성보다 높고 안정적인 처리량을 보였다. 업로드 경로에서는 그만큼 큰 차이가 나타나지 않았다. 같은 장비를 사용했어도 엔진과 함께 권한 모델 및 네트워크 방식이 바뀌었으므로, 이 결과를 모든 Docker와 Podman 구성의 속도 순위로 일반화할 수 없다.

자가 호스팅 서버의 트래픽도 한 가지 경로만 지나지 않는다. 외부 요청이 공개 포트로 들어오는 경우와 같은 호스트의 컨테이너끼리 통신하는 경우에는 관여하는 네트워크 경로가 다르다. 리버스 프록시를 거치는 웹 서비스라면 프록시와 애플리케이션 사이의 통신, 실제 응답 시간까지 포함해야 다운로드 처리량 수치가 운영상 의미를 갖는다.

메모리와 네트워크의 교환 관계도 있다. pasta 프로세스가 차지하는 자원은 컨테이너가 늘어날수록 유휴 데몬과 다른 방식으로 누적될 수 있다. 반대로 컨테이너가 드물게 실행되는 개발 PC나 작업 서버에서는 그 프로세스가 상시 남는 데몬과 같은 부담을 만들지 않는다. 따라서 네트워크 성능과 메모리를 하나의 ‘가벼움’이라는 평가로 합치기 어렵다.

Compose 이전 비용은 파일보다 주변 도구에 있다

Podman의 Compose 명령 문서에 따르면 podman compose는 Compose를 자체 구현하는 명령이 아니라 docker-compose나 podman-compose 같은 외부 제공자를 실행하는 래퍼다. 설치된 제공자에 따라 실제 동작이 달라지며, 두 제공자가 모두 있으면 기본적으로 docker-compose가 우선한다. 비슷한 명령 이름이 기존 Compose 프로젝트의 동일한 동작을 보장하지는 않는다.

이전할 때 확인할 부분은 YAML 문법에 그치지 않는다. 서비스 사이의 이름 확인과 네트워크, 바인드 마운트의 권한, 이미지 빌드 옵션, 컨테이너 상태를 감시하는 개발 도구까지 실제 작업 흐름에 들어간다. Docker 소켓을 직접 찾는 자동화가 있다면 이미지와 Compose 파일을 그대로 사용해도 연결 경로나 권한 설정을 바꿔야 할 수 있다.

여러 프로젝트의 실행 명령과 CI 설정이 Docker를 전제로 작성돼 있다면 이 변경 비용은 계속 발생한다. 반면 단순한 서비스 구성이고 Docker 전용 플러그인에 의존하지 않는다면 Podman으로 옮기는 범위가 작을 수 있다. 핵심은 Compose 파일이 열리는지보다 빌드, 실행, 로그 확인, 재시작까지 기존 운영 절차가 실제로 이어지는지다.

systemd 중심 서버라면 Quadlet이 차이를 만든다

Podman Quadlet 문서는 .container, .network, .volume 같은 선언 파일을 읽어 systemd 서비스 유닛을 생성하는 방식을 설명한다. 생성된 유닛은 다른 systemd 서비스처럼 시작과 중지, 의존 관계를 관리할 수 있다. 루트리스 서비스용 파일도 일반 사용자의 설정 경로에 둘 수 있어 계정별 운영 모델과 이어진다.

이 방식은 리눅스의 서비스 관리 체계를 이미 쓰는 서버에서 유용하다. 컨테이너와 일반 서비스를 같은 도구로 관리하고, 서비스 사이의 시작 순서를 systemd 의존 관계로 표현할 수 있기 때문이다. Quadlet 파일이 이미지를 받아야 한다면 서비스 시작 시간이 길어질 수 있으므로, 이미지 준비와 시작 제한 시간도 운영 구성의 일부다.

Docker도 systemd로 데몬을 관리하고 컨테이너에 재시작 정책을 적용할 수 있다. 기존 Compose 스택을 하나의 애플리케이션 묶음으로 관리하는 편이 익숙하다면 그 흐름을 유지할 이유가 있다. 반대로 각 컨테이너를 리눅스 서비스처럼 배치하고 로그와 의존 관계를 한곳에서 다루려면 Podman의 Quadlet이 더 직접적인 선택이다.

개발 PC, 공유 서버, 소형 서버의 선택은 다르다

개발 PC에서는 Docker를 우선 검토할 만하다. 팀의 Compose 명령과 CI, 개발 도구가 이미 Docker를 기준으로 맞춰져 있다면 호환성이 매일 시간을 절약한다. 권한 축소가 주된 목적이라면 먼저 Docker의 루트리스 구성이 현재 도구와 함께 작동하는지 보는 편이 엔진 전체를 옮기는 것보다 변경 범위가 작다.

여러 사용자가 계정을 나눠 쓰는 리눅스 서버에는 Podman이 잘 맞는다. 사용자별 컨테이너 관리와 데몬리스 구조를 활용하면서 Quadlet으로 각 계정의 서비스를 운영할 수 있다. 다만 공유 저장소, 백업 경로, 공개 포트처럼 호스트 자원을 함께 사용하는 부분은 계정별 접근 권한을 따로 정해야 한다.

메모리가 빠듯한 소형 서버에서 새 서비스를 구성한다면 Podman의 빈 호스트 상태와 systemd 연동이 매력적이다. 이미 복잡한 Compose 스택이 안정적으로 돌아간다면 Docker를 유지하면서 실제 서비스 실행 상태의 메모리를 살피는 편이 합리적일 수 있다. 이전 여부를 결정하는 수치는 컨테이너가 비었을 때의 데몬 사용량과 서비스가 모두 켜졌을 때의 총사용량을 구분해 봐야 한다.

함께 읽기: