Podman 6.0 — slirp4netns·CNI·cgroups v1 제거, macOS 기본 프로바이더는 libkrun

들어가며 — 27개월 만의 메이저, 그리고 조용히 바뀐 소속
제거 목록부터 — 업그레이드 전에 내 환경 확인
macOS — 기본 프로바이더가 libkrun으로
pasta 단독 시대 — 그리고 Pesto라는 실험
Quadlet — .app 파일에서 서브디렉터리로
Docker 호환성 개선 = 스크립트 동작 변화
CVE-2026-57231 — 5.8.3 이하라면 이것만으로도 올릴 이유
그래서 언제 올리나
마치며
참고 자료

들어가며 — 27개월 만의 메이저, 그리고 조용히 바뀐 소속

Podman 6.0.0이 2026년 6월 24일에 나왔습니다. 5.0.0이 2024년 3월 19일이었으니 27개월 만의 메이저입니다. 뒤이어 7월 8일에 6.0.1과 — 같은 날 — 5.8 브랜치의 5.8.5가 함께 나왔습니다. 구세대 브랜치가 메이저 직후에도 패치를 받고 있다는 사실 자체가 이 글 후반부의 "언제 올리나" 판단에 중요한 재료가 됩니다.

버전 숫자보다 먼저 눈에 띄는 건 저장소 주소입니다. 릴리스 노트의 이슈 링크가 전부 github.com/podman-container-tools/podman을 가리킵니다. Podman은 Buildah, Skopeo 등과 함께 "Podman Container Tools"라는 이름으로 2025년 1월 21일 CNCF 샌드박스에 승인됐고(CNCF 프로젝트 페이지, Red Hat 발표), 6.0에서 GitHub 조직 이동이 실제로 반영됐습니다. Go 임포트 경로도 github.com/containers/podman/v5에서 go.podman.io/podman/v6으로 바뀌었습니다. 라이브러리로 Podman을 임포트하는 프로젝트라면 이것만으로도 마이그레이션 작업입니다.

이 블로그에서 Docker에서 Podman으로 전환하는 이야기는 이미 다뤘습니다. 그 글이 "Podman은 5.x 세대"라고 쓴 지 열흘도 되지 않아 6.0이 나온 셈이라, 이번 글은 그 후속입니다 — 6.0에서 무엇이 제거되고, 데스크톱(특히 macOS)에서 무엇이 바뀌는지, 릴리스 노트 원문 기준으로만 봅니다. 컨테이너 이미지 레이어 쪽 최신 흐름은 containerd의 EROFS 네이티브 레이어 글에서 따로 다뤘고, 이 글은 런타임과 데스크톱 레이어에 집중합니다.

제거 목록부터 — 업그레이드 전에 내 환경 확인

6.0은 기능 추가보다 제거가 주인공인 릴리스입니다. 릴리스 노트의 Breaking Changes를 그대로 옮기면:

slirp4netns rootless 네트워크 스택 제거 — pasta만 남습니다. 전용 옵션이던 --network-cmd-path도 함께 삭제.
CNI 네트워킹 제거 — Netavark만 지원.
iptables 지원 제거 — nftables 필요.
cgroups v1 시스템 지원 제거 — cgroups v2 필수.
BoltDB 데이터베이스 지원 제거 — 기존 BoltDB 사용자는 6.0 첫 실행 시 SQLite로 자동 마이그레이션을 시도.
Intel Mac 지원 제거.
Windows 10 지원 제거.

여기에 동반 스택 요구사항이 붙습니다. 6.0.0은 Buildah v1.44.0, Skopeo v1.23, Netavark·Aardvark v2.0.0과 함께 써야 하고, 설정 파일 파싱 로직이 전면 재작성되어 별도의 설계 문서가 나왔습니다. 배포판 패키지로 쓰는 사람은 배포판이 이 조합을 맞춰 주지만, 직접 빌드하거나 일부만 올려 쓰는 사람은 버전 조합을 확인해야 합니다.

내 환경이 제거 대상에 걸리는지는 업그레이드 전에 이렇게 확인할 수 있습니다.

# 네트워크 백엔드가 cni면 6.0에서 동작하지 않는다 (netavark여야 함)
podman info --format '{{.Host.NetworkBackend}}'

# rootless 네트워킹이 slirp4netns로 고정돼 있는지 — containers.conf 확인
grep -r "slirp4netns" ~/.config/containers/ /etc/containers/ 2>/dev/null

# DB 백엔드 — boltdb면 6.0 첫 실행 때 sqlite 마이그레이션이 일어난다
podman info --format '{{.Host.DatabaseBackend}}'

# cgroups 버전 — v1이면 호스트부터 바꿔야 한다
podman info --format '{{.Host.CgroupsVersion}}'

BoltDB → SQLite는 자동 마이그레이션이 있다지만, "자동"이라는 단어를 믿고 백업 없이 메이저를 올리는 건 다른 문제입니다. 컨테이너를 정리하고 올리는 쪽이 마음 편합니다.

macOS — 기본 프로바이더가 libkrun으로

macOS 이야기의 배경을 먼저 깔면: 5.0(2024-03)에서 QEMU 프로바이더가 제거되고 Apple 네이티브 하이퍼바이저 기반 applehv(내부적으로 vfkit + Virtualization.framework)가 기본이 됐고, 5.2(2024-08)에서 libkrun 백엔드가 추가됐습니다. 당시 릴리스 노트가 명시한 libkrun의 장점은 GPU를 VM에 마운트해 작업을 가속할 수 있다는 것이었고, 기본값은 applehv로 유지됐습니다.

6.0이 그 기본값을 뒤집었습니다. 릴리스 노트 원문: "The default podman machine provider on Macs has been changed to libkrun." 로컬 LLM 추론처럼 VM 안에서 GPU를 쓰고 싶은 수요가 커진 상황과 무관하지 않은 선택으로 보입니다(추정이 아니라 5.2 노트가 밝힌 libkrun의 존재 이유가 GPU 마운트입니다).

실무적으로 중요한 것들:

기존 VM은 그대로입니다. 바뀌는 건 새로 만드는 VM의 기본 프로바이더입니다. 6.0부터는 모든 podman machine 명령이 현재 설정과 무관하게 모든 프로바이더의 VM을 다룰 수 있게 되어, applehv VM과 libkrun VM을 섞어 쓰는 상황이 오히려 다루기 쉬워졌습니다.
계속 applehv를 원하면 podman machine init --provider applehv로 명시하면 됩니다. 이 옵션 자체가 6.0 신규입니다.
Intel Mac은 6.0에서 지원이 제거됐으므로 이 논의 자체가 해당 없습니다 — 5.8.x에 머물러야 합니다.

그리고 정직하게 봐야 할 부분. libkrun이 기본이 될 만큼 성숙했느냐에 대해선 근거가 엇갈립니다. 6.0.1과 5.8.5가 같은 날 고친 버그는 "호스트의 포트 스캔 프로세스가 libkrun VM에 의도치 않게 셧다운 명령을 보내 VM이 주기적으로 꺼지는" 문제였습니다 — 기본값 승격 2주 만에 나온 첫 패치가 이것이었다는 뜻입니다. 또 2025년 12월의 한 discussion에서는 강의 환경에서 libkrun 사용 시 바인드 마운트 권한 문제(보고자 자체 집계로 수강생의 약 4분의 1이 호스트 디렉터리 권한을 777로 풀어야 마운트가 동작)가 보고됐고, applehv에서는 재현되지 않았다고 합니다. 개별 사용자 보고이므로 일반화할 수는 없지만, -v 바인드 마운트 중심으로 일하는 사람이라면 기본값을 따라가기 전에 자기 워크플로로 확인해 볼 이유는 됩니다.

Windows 쪽도 짚고 가면: Windows 10 지원이 제거된 대신, hyperv 프로바이더 VM의 시작·정지에 더 이상 관리자 권한이 필요 없어졌고(생성은 여전히 필요, 신규 VM에만 적용), 관리자가 호스트를 미리 준비해 주는 podman system hyperv-prep 명령이 추가됐습니다.

pasta 단독 시대 — 그리고 Pesto라는 실험

slirp4netns 제거는 갑작스러운 게 아닙니다. 5.0에서 이미 rootless 기본 네트워킹이 slirp4netns에서 pasta로 바뀌었고("for improved performance" — 5.0 릴리스 노트), 6.0은 2년 넘게 기본값이 아니던 코드를 삭제한 것입니다. 그래도 containers.conf나 스크립트에 slirp4netns가 박제된 환경은 남아 있을 테니, 위의 grep 한 줄은 돌려 볼 가치가 있습니다.

pasta 단독 시대에 알아 둘 동작 특성 하나: Podman 네트워킹 튜토리얼이 명시하듯, pasta 모드의 컨테이너들은 기본적으로 서로 격리되어 있습니다. 브리지처럼 가상 네트워크가 있는 게 아니라서, 컨테이너 간 통신은 호스트 포트 매핑을 경유하거나 같은 Pod에 넣어 네트워크 네임스페이스를 공유해야 합니다. rootless에서 컨테이너끼리 직접 통신이 필요하면 rootless netavark 브리지 네트워크를 만들어 쓰는 게 정석입니다.

그런데 rootless 브리지에는 오래된 아픔이 있습니다 — 포트 포워딩을 담당하는 rootlessport가 프록시로 끼면서 컨테이너가 보는 클라이언트 소스 IP가 실제 주소가 아니게 되는 문제입니다. 접속 로그가 전부 게이트웨이 주소로 찍혀 본 사람이라면 압니다. 6.0은 여기에 실험적 대안을 넣었습니다: containers.conf에서 아래처럼 설정하면,

[network]
rootless_port_forwarder = "pasta"

rootless 브리지 네트워크의 포트 포워딩을 rootlessport 대신 Pesto라는 도구가 pasta의 커널 레벨 포워딩으로 처리합니다. 소스 코드의 설명에 따르면 rootless 네임스페이스의 공유 pasta 인스턴스가 호스트 쪽 포워딩을 맡고, localhost 트래픽은 커널 splice로, 외부 트래픽은 TAP으로 전달하면서 소스 IP를 보존합니다 — 컨테이너가 프록시나 게이트웨이 주소가 아니라 실제 클라이언트 주소를 보게 됩니다.

기대되는 기능이지만 온도는 낮춰야 합니다. 기본값은 여전히 rootlessport이고, 릴리스 노트 스스로 "안정성이 더 확실해지면 전환을 검토하겠다"고 적었으며, pesto 바이너리를 포함한 passt 버전(passt-0^20260507.g1afd4ed 이상)이 필요합니다. 그리고 6.0.1이 벌써 Pesto의 룰 정리 버그(컨테이너 재시작·네트워크 리로드 시 규칙이 정리되지 않아 포워딩이 실패)를 고쳤습니다. 실험적이라는 딱지가 장식이 아니라는 뜻입니다. 소스 IP가 절실한 환경(fail2ban류, 접근 제어, 감사 로그)에서 옵트인으로 검증해 볼 단계이지, 프로덕션 기본값으로 쓸 단계는 아닙니다.

부록 같은 실험 하나 더: 커널 6.18 이상에서는 rootless 사용자 네임스페이스를 잡아 두기 위한 pause 프로세스를 nsfs 파일 핸들로 대체하는 기능이 들어갔습니다. drop-pause-process 환경 변수 뒤에 숨어 있는 실험 기능이지만, rootless Podman의 오랜 구조물 하나가 사라질 수 있다는 신호입니다.

Quadlet — .app 파일에서 서브디렉터리로

systemd 유닛으로 컨테이너를 관리하는 Quadlet 쪽도 구조 변화가 있습니다. 기존에는 podman quadlet install로 설치한 Quadlet과 부속 파일을 .app 파일로 추적했는데, 6.0부터는 서브디렉터리에 배치하는 방식으로 바뀌었습니다. 릴리스 노트는 버그가 줄고 수동 관리가 쉬워질 것이라고 설명합니다 — 반대로 말하면 .app 방식에 기대던 스크립트나 문서는 수정 대상입니다.

그 외 Quadlet 변화들:

.volume 유닛에 UID·GID·Options 키 추가(생성 시 소유자와 일반 볼륨 옵션 지정).
.container 유닛에서 소스 없는 Mount 키로 익명 볼륨 마운트 가능.
배포판이 Quadlet을 패키징해 배포할 수 있도록 /usr/share/containers/systemd/users 계열 검색 경로 추가(사용자 UID별 하위 경로 포함).
podman quadlet list에 status 필터, Pod 열, ls 별칭, --noheading 추가.
Quadlet 맨페이지가 파일 타입별로 분리.

podman generate systemd가 구식이 되고 Quadlet이 정답이 된 흐름은 전환 가이드에서 다룬 그대로인데, 6.0은 그 Quadlet을 "배포판이 패키지로 뿌릴 수 있는 물건"으로 만드는 방향입니다. 컨테이너를 systemd 서비스로 배포하는 패턴이 1급 시민이 되어 가는 중이라는 신호로 읽힙니다.

Docker 호환성 개선 = 스크립트 동작 변화

6.0의 Breaking Changes 상당수는 "Docker와 같게 만들기"입니다. 호환성 개선은 반갑지만, 뒤집어 보면 기존 Podman 동작에 맞춰 둔 스크립트가 조용히 다르게 동작한다는 뜻입니다. 걸리기 쉬운 것들:

podman volume prune이 이제 Docker처럼 익명 볼륨만 지웁니다. 이전처럼 모든 미사용 볼륨을 지우려면 새 --all 옵션이 필요합니다. 지워질 목록을 미리 보는 --dry-run도 함께 추가됐습니다.
podman volume list의 다중 필터가 OR에서 AND로 바뀌었고, 여러 커맨드의 label!= 필터도 마찬가지로 AND 결합이 됐습니다. 필터를 여러 개 걸던 정리 스크립트는 결과 집합이 달라집니다.
ps·pod ps·volume ls에서 Labels 필드를 JSON 포맷으로 뽑으면 이제 JSON 맵이 아니라 쉼표로 구분된 key=value 문자열이 나옵니다(Docker 호환). 이 출력을 jq로 파싱하던 파이프라인은 깨집니다.
podman commit이 기본으로 컨테이너를 일시정지하고 커밋합니다(동시 수정 방지). 이전 동작은 --pause=false.
네트워크 격리가 기본 활성화됐고, Docker 호환 API 버전이 v1.44로 올라갔습니다.
--gpus 옵션이 AMD GPU와 호환되게 됐습니다(NVIDIA 전용이던 것의 확장).

"Docker 호환이 좋아졌다"는 문장을 읽고 넘어가면 편하지만, CI나 정리 크론잡에서 volume prune과 필터 의미가 바뀐 건 실제로 데이터가 지워지는 방식이 바뀐 것입니다. 업그레이드 후 첫 실행은 지켜보는 걸 권합니다.

CVE-2026-57231 — 5.8.3 이하라면 이것만으로도 올릴 이유

6.0.0과 함께 공개된 보안 수정이 하나 있습니다. GHSA-4hq8-gpf5-8p68(CVE-2026-57231, GitHub 심각도 high): 악의적 이미지가 조작된 Env 항목으로 호스트 환경 변수를 컨테이너 안으로 유출시킬 수 있고, 와일드카드 글롭을 쓰면 변수 이름을 모르는 채로 대량 유출이 가능했습니다. 영향 범위는 v1.8.1 이상 v5.8.3 이하 — 사실상 최근 몇 년의 모든 버전입니다. 수정은 v5.8.4(2026-06-26)와 v6.0.0에 들어갔습니다.

"이미지를 pull해서 run만 해도 호스트 환경 변수가 샌다"는 부류의 취약점은 데스크톱 사용자에게 특히 아픕니다. 셸 환경에 API 키와 토큰을 export해 두고 사는 게 개발 머신이니까요. 6.0으로 갈 계획이 없더라도, 5.8.3 이하라면 5.8.4 이상으로는 올려야 합니다.

그래서 언제 올리나

지금 올려도 되는 경우:

Apple Silicon Mac에서 새로 시작하는 경우. Homebrew는 이 글 작성 시점(2026-07-17)에 이미 6.0.1을 stable로 배포하고 있어서, brew 사용자는 사실상 이미 6.0 트랙입니다. 기존 applehv VM을 유지할지, libkrun으로 새로 만들지만 정하면 됩니다.
네트워크 백엔드가 이미 netavark + pasta이고(5.x 기본값을 그대로 써 온 경우 대부분 해당), BoltDB가 아닌 SQLite DB를 쓰고 있는 경우 — 위의 확인 명령으로 몇 초면 판별됩니다.
Docker 호환 API를 소비하는 도구(compose 등)를 쓰는 경우 — API v1.44와 호환성 수정들의 수혜를 받습니다.

기다리거나 5.8.x에 머물러야 하는 경우:

Intel Mac, Windows 10 — 선택지가 없습니다. 5.8.x가 유일한 트랙이고, 5.8.5가 6.0.1과 같은 날 나온 것을 보면 당분간 패치는 계속될 것으로 보입니다(다만 공식 지원 기간이 명시된 것은 아닙니다).
cgroups v1 호스트, CNI 네트워크 구성이 남아 있는 서버 — 호스트·네트워크 마이그레이션이 먼저입니다.
바인드 마운트 중심의 macOS 워크플로 — libkrun 기본값을 그대로 따라가기 전에 자기 워크로드로 권한 동작을 확인하거나, 당분간 --provider applehv를 명시하는 게 보수적입니다.
ps·volume 출력이나 prune 동작을 파싱·의존하는 자동화가 많은 환경 — 위 호환성 변화 목록을 먼저 감사하고 올리는 쪽이 안전합니다.

한 가지 덧붙이면, podman machine os apply가 bootc switch 기반으로 재작성된 것도 6.0의 조용한 변화입니다. machine VM의 OS 업데이트가 부팅 가능한 컨테이너 이미지 전환으로 처리된다는 뜻인데, 불변 OS 흐름이 데스크톱 VM까지 내려온 셈입니다(서버 쪽 불변 OS 이야기는 Talos 1.13 글 참조).

마치며

Podman 6.0은 새 기능으로 유혹하는 릴리스가 아니라 부채를 청산하는 릴리스입니다. slirp4netns·CNI·iptables·cgroups v1·BoltDB — 전부 수년 전에 후계자가 정해졌던 것들이고, 6.0은 그 유예 기간의 종료 선언입니다. 그 위에 CNCF 이관이라는 거버넌스 변화, macOS의 libkrun 전환이라는 데스크톱 변화, Pesto라는 rootless 네트워킹의 다음 실험이 얹혔습니다.

업그레이드 판단은 단순합니다. 위의 podman info 세 줄로 제거 목록에 걸리는지 확인하고, 걸리면 그것부터 해소하고, macOS라면 프로바이더를 의식적으로 선택하고, 자동화가 많다면 Docker 호환성 변화 목록을 감사한 뒤에 올리면 됩니다. 그리고 어느 쪽이든 5.8.3 이하에는 머물지 마십시오 — CVE-2026-57231 하나면 이유는 충분합니다.