# Podman v6.0.0 공개 > Clean Markdown view of GeekNews topic #31070. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=31070](https://news.hada.io/topic?id=31070) - GeekNews Markdown: [https://news.hada.io/topic/31070.md](https://news.hada.io/topic/31070.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-07-03T09:32:09+09:00 - Updated: 2026-07-03T09:32:09+09:00 - Original source: [blog.podman.io](https://blog.podman.io/2026/07/introducing-podman-v6-0-0/) - Points: 1 - Comments: 2 ## Topic Body - Podman v6.0.0은 컨테이너 관리 경험을 다듬는 메이저 릴리스로, **코어 인프라 현대화**와 보안·사용성 개선을 함께 포함함 - 네트워킹은 slirp4netns·iptables 중심에서 **Netavark·Pasta·nftables** 기반으로 이동해 유지보수 부담을 줄이고 후속 기능 확장을 준비함 - 실험 기능인 **Pesto rootless port forwarding**은 커스텀 네트워크의 rootless 컨테이너에서 올바른 source IP 보존을 지원함 - Podman Machine은 여러 VM 제공자 사용성을 개선하고, `podman machine os update`로 VM 환경을 최신 상태로 유지할 수 있게 함 - Quadlet, 설정 파일 처리, Docker API 호환성, 명령 출력도 다듬어져 다중 사용자 관리와 Docker에서의 전환이 쉬워짐 --- ### Podman v6.0.0에서 달라진 점 - 최신 릴리스는 [GitHub 릴리스 페이지](https://github.com/podman-container-tools/podman/releases/tag/v6.0.0)에서 확인할 수 있으며, 패키지 매니저에도 곧 배포될 예정임 - ## 네트워킹 현대화 - slirp4netns와 iptables에서 Netavark, Pasta, nftables 쪽으로 전환함 - 정리된 네트워킹 스택은 유지보수를 단순화하고 향후 기능 추가의 기반이 됨 - **Pesto rootless port forwarding** 실험 지원으로 커스텀 네트워크의 rootless 컨테이너에서 올바른 source IP 보존이 가능함 - ## Podman Machine 개선 - 여러 VM 제공자를 더 매끄럽게 다룰 수 있도록 사용성이 개선됨 - `podman machine os update` 명령으로 VM 환경을 최신 상태로 유지할 수 있음 - 관련 추가 개선 사항은 향후 별도 글에서 더 자세히 다룰 예정임 - ## Quadlet 확장 - REST API 지원이 추가됨 - 관련 파일 추적이 개선되어 관리가 쉬워짐 - `.volume` 유닛 기능이 확장됨 - 배포 패키징을 쉽게 하기 위한 추가 검색 경로가 포함됨 ### 설정과 Docker 호환성 - **설정 파일 처리**가 바뀌어 다중 사용자 환경을 관리하는 관리자가 더 매끄럽고 신뢰성 있게 사용할 수 있음 - 구체적인 내용은 [Podman 6 configuration file changes](https://blog.podman.io/2026/06/podman-6-configuration-file-changes/)에서 확인할 수 있음 - **Docker 호환성**도 개선됨 - Docker API 지원이 업데이트됨 - 명령 출력이 다듬어져 Docker에서 Podman으로 전환하기 쉬워짐 - 전체 변경 목록은 [Podman v6.0.0 release notes](https://github.com/podman-container-tools/podman/releases/tag/v6.0.0)에 정리되어 있음 ## Comments ### Comment 61164 - Author: click - Created: 2026-07-03T10:00:52+09:00 - Points: 1 podman compose 가 쓸만해지면 넘어갈 생각인데 대체 언제 쓸만해지는지 모르겠어요 요새 docker run 으로 직접 실행하는 건 임시 컨테이너나 테스트 실행용 뿐이라고 생각하는데, compose 지원이 좋지 않은 건 큰 약점이라고 봐요. 장황한 설정과 확실한 관리가 필요하면 그냥 k8s 쓰는 게 낫고 2026년 현대에 와서 docker나 podman의 매력은 k8s의 여러 리소스 정의 없이 간편한 yml 설정파일 하나로 하나의 앱에서 사용하는 스택을 다 정의하는 건데 k8s 호환성을 내세울거면 그냥 k3s나 minikube, microk8s 같이 로컬에서 돌아가는 가벼운 k8s 구현체를 쓰는 게 훨씬 나아요 rootless가 문제가 아니라고 생각합니다 ### Comment 61154 - Author: neo - Created: 2026-07-03T09:32:10+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48762098) - Docker가 왜 아직 Podman보다 훨씬 인기 있는지 모르겠음. 구현만 보면 **Podman**이 분명 더 낫고, 새 네트워크 기능도 반가운 개선임 - 배포가 약간 더 번거롭고 서로 떨어진 단계가 더 많다는 게 주된 이유일 듯함. 특히 **루트리스**로 가려면 더 그렇고, 사실 그렇게 해야 함 Linux 우선이 아닌 사람, 예를 들어 앱 컨테이너화를 배우는 초보 개발자에게 systemd 유닛 파일이나 kubelet 설정을 다루고, 전용 로컬 서비스 계정을 만들고, linger 활성화까지 기억해야 하는 건 Docker 설치 후 docker compose 파일 만들고 “start” 누르는 것보다 꽤 위압적임 왜 이런 접근을 택했는지는 이해하지만, 꽤 투박하고 친절하지 않음 - **fuse-overlayfs**가 Docker의 overlayfs 구성보다 눈에 띄게 느렸음. 재구성 방법이 있을 수도 있지만 최근에는 확인해보지 않음 Zig로 ghostty를 빌드할 때 Podman에서 애매한 “unknown file” 오류로 깨졌던 것 같고, 알고 보니 fuse-overlayfs가 확인하려던 일부 속성을 지원하지 않아서였음 전환하려 할 때마다 이런 임의의 작은 문제들이 계속 발목을 잡음. 단순한 용도에는 쓰고 있음 - 마지막으로 확인했을 때 **podman compose**는 docker compose와 겉모양만 비슷한 수준이었음. inotify 같은 것도 Podman 쪽에서 랜덤하게 자주 깨지는 듯함 Podman을 추천하고 싶지만, docker compose 호환성이 좋지 않고 볼륨에서 inotify가 빠지면 개발자 경험이 너무 문제됨 - 더 강한 브랜드명도 이유일 듯함. macOS에서는 **Docker Desktop**이 더 직관적이었음. 다만 최근에는 오류가 매우 잦아졌고, 파일 마운트나 네트워크 규칙 정리가 랜덤하게 실패하거나 갑자기 엄청 느려져 VM을 재시작해야 했음 macOS의 Podman은 훨씬 덜 다듬어진 느낌이고, OrbStack이 훨씬 나은 선택지임 Linux에서만 Podman을 쓰는데 거기서는 매우 빠름. 그래도 대부분 기능이 systemd와 결합해 Kubernetes를 대체하는 쪽에 맞춰진 것 같고, 정작 docker compose 지원은 불안정하며 TUI/UX도 원본보다 뒤처짐 - 사소한 이유들로 Podman을 포기했음. 하나는 Docker와 다르게 **SELinux**를 처리하기로 해서, 기본 CentOS 시스템에서 SELinux 보안 레이블을 바꾸는 작업이 필요했다는 점임. 이건 채택 불가였음 또 다른 문제는 Docker와의 작은 차이들인데, 패키징된 Docker compose가 그대로 동작하지 않을 정도였음. Docker로 바꾸면 바로 돌아가고 하루 일을 계속할 수 있는데, 그걸 디버깅하는 데 시간을 쓰고 싶지 않았음 - Docker Desktop이 또 랜덤하게 엄청난 메모리를 먹기 시작한 뒤 Podman으로 바꿨고, 정말 설치한 다음 **docker-compose.yml**을 가리키는 것만큼 쉬웠음 변경은 전혀 필요 없었고, 이제 데몬을 계속 띄워둘 필요도 없음. 훌륭한 소프트웨어임 - Docker Desktop보다 colima가 나았고, colima보다 **Orbstack**이 더 좋았음. 그러다 [https://smolmachines.com's]() smolvm 마이크로VM을 발견함 - Docker의 **AI 헛짓** 때문에 결국 선을 넘어서 Podman으로 전환을 시도했지만, 몇 가지 호환성 문제를 만났음. 몇 달 전이라 세부 내용은 기억나지 않음 그래서 Rancher Desktop을 써봤고, 이름을 자꾸 잊는 것만 빼면 그냥 잘 동작했음. 필요한 사람에게는 또 하나의 단순한 선택지임 - **Quadlet**을 정말 좋아함. 몇 년 동안 Hetzner, Ansible, SystemD, RockyLinux로 루트리스 컨테이너를 문제 없이 호스팅했고, 그 구성을 템플릿 저장소로 뽑아냈음 [1] [https://github.com/Mati365/hetzner-podman-bunjs-deploy]() - 홈 서버를 k3s에서 quadlet으로 바꿨더니 **전력 사용량이 8%** 줄었음 - Docker에서 Podman으로 옮겨본 경험이 궁금함 홈랩/자동화 구성에 compose 파일이 많아서 그게 제일 걱정됨 - 약 15개월 전에 Docker에서 Podman으로 옮겼고, 다시는 돌아가지 않을 생각임. 개인적으로 **quadlet**, 즉 systemd 통합이 정말 좋고, 일반 systemd 서비스든 컨테이너든 실행 중인 서비스 묶음을 훨씬 쉽게 모니터링하게 해줌 루트리스 실행도 아주 직관적이고, Podman은 매우 빠름. 개인적으로 docker compose가 크게 그립지는 않지만, docker compose 부재가 다른 사람에게 치명적일 수 있다는 건 이해함. Podman의 compose 플러그인은 써본 적 없음 - 홈랩에서 거대한 docker compose 파일을 **podman quadlet**으로 바꿨음. 기억상 처음 몇 개 서비스를 옮길 때는 compose 파일에 비해 quadlet 문서와 예제가 많지 않아 시간이 좀 걸렸지만, 그 뒤로는 아주 쉬웠음. 강력 추천함 유일한 문제는 검증임. quadlet 파일을 검증하는 편리한 내장 명령이 없고, systemd도 생성 실패를 경고해주지 않음. 먼저 `--dry-run`을 하거나, 전체 명령을 적당한 별칭으로 만들고, 아니면 저널에서 오류를 확인해야 함 - 몇 년 전, 5.0 이전에 옮겼고 돌아보지 않았음. compose 파일은 **quadlet** 사용을 검토할 만함 빠른 변환에는 podman-compose를 직접 쓰거나, Podman 소켓을 가리키도록 docker compose를 설정할 수 있음[0] compose 파일을 네이티브 quadlet으로 바꿔주는 podlet[1]도 있음. 단순하거나 중간 정도 복잡도의 compose 파일은 대부분 알아서 잘 처리하고 바로 동작함. 이를 라이브러리 형태로 만들어 다른 도구들이 compose 파일을 quadlet으로 투명하게 변환하게 하자는 이야기도 있어서, 앞으로 비슷한 도구가 더 나오길 기대함 systemd 유닛 파일에 조금이라도 익숙하다면 직접 Quadlet 파일을 쓰는 것도 어렵지 않음. 대부분의 `docker run` 또는 `podman run` 인자는 quadlet로 바로 대응되므로, YAML 대신 INI 형식에 익숙해지면 compose 파일을 보고 동등한 quadlet을 만들어내기 쉬움 [0] [https://www.redhat.com/en/blog/podman-docker-compose]() [1] [https://github.com/containers/podlet]() - 1~2년 전에 전부 **루트리스 Podman**으로 옮겼음. 일부 컨테이너는 예전 데이터를 읽을 때 권한 문제가 생겼는데, 다른 UID로 실행된 게 원인이었음 실제로 겪은 문제는 이게 전부였고, 루트 권한 Docker에서 루트리스 Docker로 옮겨도 같은 문제가 있었을 것임. 전혀 후회 없고 절대 돌아가지 않을 생각임 - Podman에게는 git만큼 고마움을 느낌 Podman은 성숙하고 합리적이었음. 누군가의 컨테이너가 su 권한에 의존한다면 Podman이 아니라 그 누군가를 탓함 - Podman에서 싫은 점은 **Docker 호환**인 척하지만, 나중에 물고 늘어질 작은 차이들이 있다는 것임. Docker 기반 프로젝트 사용자가 Podman으로 실행하려다가 결국 프로젝트 쪽에 와서 불평하게 됨 - 대부분의 차이는 소켓 API나 논리적 동작, 명령줄 차이에서 오지 않았음. Docker가 **루트 권한으로 실행된다**고 가정하는 반면, Podman은 기본적으로 그렇지 않다는 데서 주로 생김 그래서 Podman/Docker 비호환을 고치는 일은 대체로 그 가정을 처리하는 것임. Podman 명령에 몇 가지 플래그를 더해 컨테이너와 호스트 사이의 사용자 네임스페이스 매핑 방식을 바꾸는 식임 - Mac과 Linux에서 Podman을 3년 써왔고, 안타깝게도 이 문제는 늘 사실이었음. 끈질기게 근본 원인을 찾아 버그를 올릴 의향은 있지만, 많은 사람에게는 그냥 고장난 것처럼 보일 것임 가장 최근에는 **Netavark**가 게시된 포트에서 브로드캐스트 트래픽을 받는 동작이 Docker와 맞지 않았음 - 맞음. 이 때문에 몇 년 동안 Podman을 꺼리게 됐음. 지금은 똑똑한 아이디어가 있다고 보고, **RHEL**을 쓴다면 당연한 선택이지만, 적응이 필요하다는 점을 더 솔직히 알려야 함 특히 루트 권한 Docker에서 루트리스 Podman으로 옮기는 경우에는 더 그렇음 - 요즘 Podman은 어떤지 궁금함. macOS에서는 **OrbStack**을 쓰고 있고 훨씬 빠른 것 같음. macOS 27이 WSL과 비슷하게 마이크로VM 기반의 더 네이티브하고 성능 좋은 Linux 컨테이너를 추가하면 판도가 어떻게 될지 모르겠음 - macOS는 잘 모르겠지만, Linux에서는 내 용도에 매끄럽게 맞음. 한 가지 주의할 점은 **Podman Compose**가 기본 제공자로 docker-compose를 쓴다는 것임 podman-compose 제공자는 써보지 않았고, 이름이 Podman Compose와 헷갈리게 살짝 다름. Podman Compose는 docker-compose나 podman-compose 위의 상위 추상화임. 필요하면 Podman으로도 Docker 엔진을 통해 컨테이너를 실행할 수 있음 - 같은 질문이고 같은 상황임. MacOS에서 써봤는데, 처음 겪은 문제 하나를 이해하려고 Redhat 포럼 깊숙이 들어가야 했음. OrbStack으로 바꾸는 건 당연한 선택이었지만, 기능 관점의 명확한 트레이드오프는 있음 - **Quadlet**과 **루트리스 컨테이너**는 Docker에서 Podman으로 옮기려는 두 가지 큰 이유임 - 루트리스가 몇 년 전 Podman으로 옮긴 이유였음. 정말 매끄럽고, 이제 애매한 권한 문제나 서비스 오류를 걱정하지 않아도 됨 - Podman은 좋지만 저 회색 글자 색은 왜 그런지 모르겠음. 보기 안 좋고 **명암비 4.96:1**이라 읽기 어렵고, WCAG AAA 수준에도 못 미침 - 홈 서버를 약 2년 동안 **podman + quadlets**로 돌리고 있는데, 릴리스 노트에서 몇 가지 챙길 만한 걸 봤음 `podman quadlet list`는 v5.6.0에 추가됐고, quadlet과 그 컨테이너를 나열함 `podman system migrate --migrate-db`는 v5.8.0에 추가된 플래그임. 예전에 bolt DB 지원 중단 경고를 봤지만 sqlite로 마이그레이션하는 도구가 없었는데, 이제 생겼음. 아니면 podman 6.0.0으로 올리면 자동으로 처리됨 - Docker가 아닌 **CRI 런타임**용 이미지 빌드에 Podman을 써본 경험이 궁금함 Podman으로 이미지를 빌드하면 cri-o, Docker, 그 외 여러 런타임에서 실행될까? docker build에는 sudo가 필요해서 에이전트 기반 작업 흐름에서 귀찮아지다 보니, 루트리스 Podman으로 이미지를 빌드할지 고민 중임