Podman, crun

 

 

 

Podman, Docker Desktop, Rancher Desktop은 각각의 핵심 아키텍처에 따라 개발 언어와 메모리 사용 패턴이 크게 다릅니다. [1, 2]

윈도우 환경(WSL2 기반)을 기준으로 세 솔루션의 개발 언어와 메모리 사용률을 명쾌하게 비교해 드리겠습니다.

---

1. 한눈에 보는 비교 표

항목Podman (및 Podman Desktop)Docker DesktopRancher Desktop

코어 엔진 개발 언어	Go (Golang)	Go (Golang)	Go (Golang) (containerd/dockerd 기반)
GUI 대시보드 언어	TypeScript + Svelte (Electron 기반)	TypeScript + React (Electron 기반)	TypeScript + Vue.js (Electron 기반)
아키텍처 방식	데몬리스 (Daemon-less)	데몬형 (Central Daemon)	데몬형 또는 containerd 선택 가능
대기 상태 메모리 (유휴)	최저 (약 0 ~ 50MB) 엔진 자체 상시 구동 없음	보통 (약 150 ~ 200MB) dockerd 데몬 상시 대기	최고 (약 1.5GB ~ 2GB+) K3s 쿠버네티스 기본 구동
컨테이너 실행 시 메모리	매우 경량 (-20% 절감) 프로세스로 직접 실행	표준	무거움 쿠버네티스 관리 오버헤드

---

2. 세부 특징 분석

🛠️ 개발 언어 (Development Language)

• 코어 컨테이너 엔진: 세 프로그램 모두 리눅스 컨테이너의 표준을 다루기 때문에, 구글이 개발한 시스템 프로그래밍 언어인 Go (Golang)로 작성되었습니다. Go 언어 자체는 C/C++만큼 빠르고 메모리를 효율적으로 쓰는 컴파일 언어입니다.
• 사용자 화면 (GUI App): 사용자가 마우스로 제어하는 데시보드 프로그램은 세 도구 모두 웹 기술 기반의 Electron 아키텍처(TypeScript)를 공유합니다. 따라서 화면을 띄워두는 것만으로도 약간의 기본 메모리(약 100~200MB)가 추가 소비됩니다.

🧠 메모리 사용률 (Memory Usage)

• Podman (가장 경량 🟢):
  • 왜 가벼운가? 도커와 달리 백그라운드에서 항상 켜져 있는 '중앙 데몬 프로세스(dockerd)'가 없습니다.
  • 효율성: 컨테이너를 실행할 때만 해당 프로그램이 일반 프로세스로 실행되므로, 아무것도 안 띄운 대기(Idle) 상태에서는 메모리를 거의 먹지 않습니다 (0MB에 수렴). 도커 대비 컨테이너당 메모리 소모가 15~20%가량 적습니다. [1, 2, 3, 4, 5]
• Docker Desktop (표준 🟡):
  • 왜 무거운가? 컨테이너를 하나도 실행하지 않더라도 백그라운드에서 클라이언트 요청을 대기하는 dockerd라는 거대한 데몬이 항상 켜져 있습니다.
  • 효율성: 대기 상태에서 기본적으로 140~180MB의 메모리를 항상 차지합니다. 컨테이너를 늘릴 때마다 메모리 사용량이 선형적으로 증가합니다. [1, 2, 3]
• Rancher Desktop (무거움 🔴):
  • 왜 무거운가? 일반 도커 컨테이너 환경뿐만 아니라, 로컬에 K3s라는 초경량 쿠버네티스(Kubernetes) 클러스터를 기본적으로 함께 구성하여 구동하기 때문입니다.
  • 효율성: 쿠버네티스 시스템을 유지하기 위한 자체 컨테이너들이 내부적으로 이미 수십 개가 돌아가므로, 아무것도 하지 않아도 최소 1.5GB ~ 2GB 이상의 RAM을 소모합니다. 노트북이나 저사양 PC에서는 상당히 부담스러울 수 있습니다. [1, 2]

---

💡 최종 요약 및 추천

• 컴퓨터 사양이 낮고 메모리를 아끼고 싶다면: 무조건 Podman이 정답입니다. 데몬리스 구조 덕분에 윈도우 자원을 가장 적게 먹습니다. [1, 2]
• 쿠버네티스(K8s) 환경을 로컬에서 테스트해야 한다면: 메모리를 많이 먹더라도 Rancher Desktop이 가장 편리합니다. [1, 2]

 

 

도커나 팟맨처럼 대중적으로 쓰이는 상위 레벨의 '컨테이너 엔진' 전체가 처음부터 끝까지 C/C++로만 작성된 윈도우용 프로그램은 사실상 없습니다. [1]

그 이유는 전 세계 컨테이너 생태계 표준이 구글의 Go(Golang) 언어로 완전히 굳어졌기 때문입니다. 하지만 완전히 방법이 없는 것은 아닙니다. 컨테이너를 실제로 구동하는 핵심 밑바닥 계층(런타임)이나 특수한 대안 기술로 눈을 돌리면 C/C++ 기반의 매우 강력하고 가벼운 솔루션들을 찾을 수 있습니다.

---

1. Podman 내부의 핵심 엔진을 C로 바꾸기: crun (가장 현실적인 방법)

컨테이너 시스템은 크게 사용자 명령을 받는 엔진(Engine)과 실제로 리눅스 커널을 조작해 격리 공간을 만드는 최하단 런타임(Runtime)으로 나뉩니다. [1]

• 기존 방식: 도커와 팟맨은 기본적으로 Go 언어로 만든 runc라는 최하단 런타임을 사용합니다.
• C 언어 대안: 레드햇(RedHat) 주도로 개발된 crun은 100% C 언어로 작성된 OCI 컨테이너 런타임입니다. [1]
• 윈도우에서 쓰는 법: 앞서 추천해 드린 팟맨(Podman)은 설정에서 최하단 엔진을 runc 대신 crun으로 아주 쉽게 바꿀 수 있습니다.
  • 효율성 극대화: Go 기반의 runc에 비해 C로 만든 crun은 메모리를 최대 10배 적게 먹고, 컨테이너 실행 속도가 체감될 정도로 빠릅니다. 가벼운 시스템을 원하신다면 "Podman + crun 엔진 조합"이 현재 세계에서 가장 완성도 높은 C 언어 기반 컨테이너 환경입니다. [1]

2. C로 작성된 정통 리눅스 컨테이너: LXC / LXD

도커가 세상에 나오기 전, 도커의 모태가 되었던 기술입니다. [1]

• 특징: 100% C 언어로 작성된 정통 컨테이너 기술입니다. 도커처럼 앱 하나만 띄우는 것이 아니라, 컨테이너 내부에 가상머신(VM)처럼 완전한 리눅스 운영체제 환경을 가볍게 구축할 때 씁니다. [1, 2]
• 윈도우 지원: 윈도우 WSL2 환경 내부에 LXC를 설치해 사용할 수 있습니다. Go 언어 기반인 도커 패밀리에 비해 시스템 자원을 매우 적고 정밀하게 소모하는 장점이 있습니다.

3. 마이크로소프트의 C++ 기반 컨테이너 런타임: hcsshim

만약 리눅스 컨테이너가 아니라 "윈도우 프로세스 자체를 도커처럼 격리"하는 윈도우 네이티브 컨테이너(Windows Container) 기술을 뜻하신다면 이야기가 다릅니다.

• 특징: 마이크로소프트가 오픈소스로 공개한 hcsshim은 윈도우 호스트 위에서 컨테이너를 띄우기 위한 핵심 백엔드 구동부이며, C++로 작성되었습니다. 다만 이는 일반 사용자가 직접 다루기보다는 도커 데스크톱 등이 윈도우 내부 기능을 호출할 때 쓰는 브릿지 역할을 합니다.

---

💡 왜 컨테이너 세상은 Go(Golang)가 지배했을까요?

C/C++이 성능과 메모리 면에서 가장 뛰어난 것은 사실이지만, 컨테이너 엔진은 수많은 네트워크 통신(API), 파일 시스템 다운로드, 수만 개의 동시성 프로세스 제어를 끊임없이 처리해야 합니다.
Go 언어는 C 언어만큼 빠르면서도 네트워크 처리와 멀티스레딩(Goroutine) 개발 생산성이 압도적으로 좋아 도커, 쿠버네티스 등 전 세계 모든 컨테이너 표준 언어로 자리 잡게 되었습니다. [1, 2]

 

윈도우(WSL2) 환경에서 팟맨(Podman)의 하위 런타임을 Go 기반(runc)에서 C 기반(crun)으로 교체하는 방법은 매우 직관적입니다. [1]

윈도우 터미널(PowerShell 또는 CMD)을 열고 아래의 순서대로 따라 하시면 아주 가볍고 빠른 C 언어 기반 컨테이너 환경을 구축할 수 있습니다.

---

1단계: Podman WSL 가상머신 접속하기

윈도우용 Podman은 내부적으로 podman-machine-default라는 이름의 WSL2 리눅스 환경 위에서 작동합니다. 수정 작업을 위해 먼저 이 가상머신 내부로 진입해야 합니다. [1, 2]

윈도우 PowerShell을 열고 아래 명령어를 입력합니다.

powershell

podman machine ssh

코드를 사용할 때는 주의가 필요합니다.

 

접속이 완료되면 프롬프트가 리눅스 쉘 환경(fedora$ 또는 root@...)으로 변경됩니다.

2단계: crun 설치 여부 확인하기

최신 Podman 버전들은 대부분 crun을 내장하고 있거나 우선순위로 두지만, 가상머신 내부에 crun 바이너리가 실제로 존재하는지 확실히 확인합니다. 리눅스 쉘에서 아래 명령어를 칩니다. [1]

bash

which crun

코드를 사용할 때는 주의가 필요합니다.

 

• 만약 /usr/bin/crun 같은 경로가 출력된다면 이미 설치되어 있으므로 3단계로 넘어가면 됩니다.
• 만약 아무것도 나오지 않는다면 가상머신의 패키지 매니저(대개 Fedora 기반이므로 dnf 사용)로 설치해 줍니다. [1]
  bash

  sudo dnf install -y crun
  

  코드를 사용할 때는 주의가 필요합니다.

   

3단계: 설정 파일 수정을 통해 crun 영구 적용하기

Podman의 전체 엔진 설정을 담당하는 containers.conf 파일을 수정하여 런타임을 완전히 crun으로 고정합니다. [1, 2]

1. 설정을 바꿀 수 있도록 텍스트 편집기(nano)로 설정 파일을 엽니다.
   bash

   sudo nano /etc/containers/containers.conf
   

   코드를 사용할 때는 주의가 필요합니다.

    
2. 키보드 방향키를 내려 [engine] 섹션을 찾습니다.
3. [engine] 아래에 있는 runtime = "runc" 부분을 찾아 다음과 같이 crun으로 수정합니다.
   ini

   [engine]
   runtime = "crun"
   

   코드를 사용할 때는 주의가 필요합니다.

    
   (만약 앞에 # 주석 기호가 붙어있다면 주석을 지워주셔야 활성화됩니다.)
4. Ctrl + O (저장) ➡️ Enter ➡️ Ctrl + X (종료)를 눌러 편집기를 빠져나옵니다.
5. exit를 입력하여 WSL 리눅스 환경에서 빠져나와 다시 윈도우 PowerShell로 돌아옵니다. [1, 2]

4단계: Podman 재시작 및 적용 확인

설정을 완벽하게 반영하기 위해 윈도우에서 작동 중인 Podman 가상머신을 껐다 켭니다.

powershell

podman machine stop
podman machine start

코드를 사용할 때는 주의가 필요합니다.

 

이제 변경이 성공적으로 이루어졌는지 팟맨 정보를 조회해 봅니다.

powershell

podman info | Select-String "OCIRuntime" -Context 0,5

코드를 사용할 때는 주의가 필요합니다.

 

출력 결과 중 name: crun으로 명시되어 있고, 최하단 경로가 crun을 가리키고 있다면 이제부터 모든 컨테이너가 가볍고 빠른 C 언어 런타임 위에서 돌아가게 됩니다!

---

💡 임시로 테스트해보고 싶다면?

전체 설정을 바꾸기 전에 특정 컨테이너 하나만 crun으로 돌려보고 싶다면, 컨테이너를 실행할 때 --runtime 옵션을 붙여서 실행해 볼 수도 있습니다. [1, 2]

powershell

podman run --runtime crun -d -p 8080:80 nginx

코드를 사용할 때는 주의가 필요합니다.

 

설정 도중 오류 메시지가 나타나거나 가상머신 접속에 문제가 생기신다면, 에러 내용을 말씀해 주세요. 즉시 해결해 드리겠습니다!