Portainer가 방향을 바꾼다: Docker 컨테이너 관리를 위한 대안을 벌써 찾아야 할까?

Portainer는 많은 홈랩에서 거의 고정 멤버나 다름없습니다. NAS, Raspberry Pi, 미니 PC 또는 Proxmox VM에 설치하면 5분 뒤에는 Docker 컨테이너를 실행하고, 중지하고, 업데이트하고, 모니터링할 수 있는 웹 인터페이스가 생깁니다.

홈 오토메이션에서는 무척 편리합니다. Home Assistant는 컨테이너로 아주 잘 실행되고, 주변에는 Mosquitto, Zigbee2MQTT, Node-RED, ESPHome, Frigate, InfluxDB, Grafana, AdGuard Home, Nginx Proxy Manager 등이 함께 있는 경우가 많습니다. 목록은 금세 길어집니다.

2026년 9월 11일, Portainer는 방향 전환을 발표했습니다. 버전 3.0은 Kubernetes를 우선으로 설계하고, Community Edition은 2.x 브랜치에 머물게 됩니다.

내일 아침 당장 Portainer를 삭제해야 할까요? 아닙니다. 하지만 이웃집 정원에 무엇이 자라고 있는지 살펴볼 좋은 시점입니다.

Portainer 3.0: Kubernetes로 방향 전환

Portainer의 CEO인 Neil Cresswell이 블로그 게시물에서 새로운 전략을 자세히 설명했습니다. 단순히 버전 번호만 바꾸는 이야기가 아닙니다.

8월에 출시된 Portainer 2.45 LTS가 2.x 브랜치의 마지막 버전입니다. 3.x는 Kubernetes를 우선순위로 두고 개발됩니다.

개발사는 그 이유를 꽤 솔직하게 설명합니다. Docker와 Kubernetes의 격차가 너무 커져서, Docker, Podman, Swarm, Kubernetes용 기능을 모두 하나의 코드베이스에서 병행 개발하는 것은 더 이상 지속할 수 없다는 것입니다. 기업 고객들은 보안 정책, 관측 가능성, GitOps, AI 워크로드 실행 기능 등을 요구합니다. 이 모든 것은 Docker에는 없는 Kubernetes 고유의 메커니즘(network policies, admission controllers)에 기반합니다.

Portainer-Run, Portainer-IDP, Portainer-Command, Portainer-Operations, Portainer-AiGrid 등 이 생태계를 중심으로 여러 제품이 준비 중입니다. 이름만 봐도 방향이 확실히 드러납니다.

미니 PC에서 Zigbee2MQTT와 몇 가지 서비스를 실행하려는 사람에게는 원래의 필요와 거리가 꽤 멉니다.

그렇다고 Portainer CE가 사라지는 것은 아닙니다

발표 이후 나온 기사 중에는 지나치게 불안감을 조성하는 제목도 있었습니다. 그러니 분명히 짚고 넘어가겠습니다. Portainer는 Docker를 포기하지 않으며, Community Edition을 하루아침에 중단하지도 않습니다.

CE는 2.x 브랜치에 남아 보안 패치와 버그 수정을 계속 받습니다. Portainer는 Docker API에 대응되는 기능이 3.x에 추가되면 이를 2.x에도 백포트하겠다고 약속했습니다. 2.45 LTS는 2027년 5월까지 유지 관리됩니다.

현재 서버에서 Portainer CE가 잘 작동하고 있다면 서두를 필요는 없습니다.

다만 Portainer CE 3.0은 출시되지 않습니다. 3.x를 무료로 이용하려면 최대 3개 노드까지 Business Edition을 무료로 제공하는 « 3 Nodes Free » 프로그램을 이용해야 합니다. Docker, Swarm, Podman 환경도 계속 관리할 수 있지만 인터페이스에서 우선순위가 낮아지고, 새로운 기능은 Kubernetes 쪽에 먼저, 어쩌면 그쪽에만 추가될 것입니다.

지금은 차이가 크지 않아 보입니다. 하지만 2~3년 뒤에는 훨씬 뚜렷해질 거라고 생각합니다.

홈 오토메이션에 왜 중요한가

홈랩에서 Kubernetes는 대부분의 경우 지나치게 복잡합니다.

Home Assistant, Mosquitto, Zigbee2MQTT, Node-RED, Frigate와 모니터링 도구 두세 개를 실행하는 일반적인 서버를 생각해 보세요. Docker Compose면 충분합니다. 애플리케이션마다 파일 하나씩 두고, 데이터를 볼륨에 저장하고, 모든 것을 백업하거나 다시 구성할 명령어 몇 개만 있으면 됩니다.

관리 인터페이스의 최신 기능을 계속 쓰려고 Kubernetes 클러스터를 구축하는 건 튤립 세 송이를 심으려고 굴착기를 꺼내는 것과 비슷합니다.

Portainer도 이를 인정합니다. 3.x에서도 Docker는 지원하지만, 개발 노력은 Kubernetes에 집중될 것입니다. Kubernetes로 옮길 생각이 없다면 이런 질문이 생깁니다. Docker와 Docker Compose를 우선으로 설계한 인터페이스는 없을까요?

있습니다. 그리고 최근 몇 달 사이 여러 도구가 크게 발전했습니다.

Arcane: 지금으로서는 가장 설득력 있는 대안

2026년에 하나만 써 봐야 한다면 바로 이 도구입니다.

Arcane은 현대적인 Portainer라면 어떨지 기대할 법한 모습을 보여 줍니다. 웹 인터페이스에서 컨테이너, 이미지, 볼륨, 네트워크, Docker Compose 프로젝트를 관리할 수 있고, 에이전트를 이용해 원격 장비도 관리할 수 있습니다.

인증 방식으로는 OIDC, 패스키, 2단계 인증을 지원합니다. API와 이미지 업데이트 관리 기능도 있고, 각 이미지와 관련된 위험을 표시해 주는 취약점 스캐너도 있습니다.

개발 속도도 빠릅니다. 2.10부터 2.14까지 한 달도 안 되는 기간에 출시됐습니다. 2.14.0은 2026년 9월 26일에 나왔는데, 제가 이 글을 쓰기 며칠 전입니다. 취약점에 대한 일괄 작업, 새롭게 개편된 보안 위험 보기, 각 컨테이너의 프로세스를 보여 주는 탭이 추가됐습니다.

설치도 간단합니다. Arcane 자체가 컨테이너로 실행되고 호스트의 Docker 소켓에 접근합니다. Portainer와 마찬가지로, 소켓에 접근할 수 있다는 것은 시스템의 root 권한을 부여하는 것과 같다는 점을 기억하세요. 따라서 별도의 보안 조치 없이 인터페이스를 인터넷에 노출하지 않는 것이 좋습니다.

내일 홈랩에서 Portainer를 교체해야 한다면 가장 먼저 설치해 볼 도구가 바로 Arcane입니다.

Dockge: 무엇보다 간편함을 우선으로

Dockge도 대화에서 빠지지 않고 등장하는 이름입니다.

Uptime Kuma 개발자인 Louis Lam이 만든 도구로, 지향점은 다릅니다. Portainer의 모든 기능을 다시 만들려 하지 않고 Docker Compose에 집중합니다. 깔끔한 인터페이스에서 스택을 만들고, 수정하고, 시작하고, 중지하고, 업데이트할 수 있습니다.

제가 가장 마음에 드는 점은 compose.yaml 파일이 내부 데이터베이스의 항목으로 저장되는 게 아니라 실제 파일로 디스크에 남는다는 것입니다(기본 경로는 /opt/stacks). 어떤 편집기로든 열 수 있고, 터미널에서 익숙한 docker compose up -d 명령을 실행할 수도 있습니다.

버전 1.4부터는 다른 Dockge 인스턴스에도 연결해 여러 장비의 스택을 하나의 인터페이스에서 볼 수 있습니다.

라즈베리 Pi나 홈 오토메이션 서비스 열 개 정도를 실행하는 미니 PC에서 사용하기에 정말 편리합니다.

아쉬운 점은 개발 속도입니다. 최신 안정 버전인 1.5.0은 2025년 3월에 출시됐습니다. 그렇다고 작동하지 않는 것은 아니지만, 새로 설치해서 몇 년 동안 쓸 생각이라면 첫 번째 선택지로 삼는 데 망설임이 생깁니다.

Komodo: 홈랩에 서버가 여러 대 있을 때

홈랩 규모가 커졌다면 Komodo를 살펴볼 만합니다.

여러 서버를 배포하고 관리하도록 설계됐습니다. GPLv3 라이선스의 오픈 소스 프로젝트이며, 연결할 수 있는 장비 수에 제한이 없습니다.

Docker Compose를 관리하고 기존 스택을 가져올 수 있으며 Git 저장소에서 설정을 가져올 수도 있습니다. 따라서 Git에 스택을 정의하고 서버에 자동으로 배포한 다음, 저장소가 변경될 때마다 다시 배포할 수 있습니다. 예전 방식대로 Compose 파일을 각 장비에 직접 두고 싶다면 그것도 가능합니다.

Komodo 2에는 Docker Swarm 관리, 로컬 계정의 2단계 인증(TOTP 또는 패스키), 여러 로그인 방식(로컬, OIDC, GitHub 등)을 하나의 계정에 연결하는 기능, 개선된 원격 터미널이 추가됐습니다. 자동화 기능은 그전부터 이미 잘 갖춰져 있었습니다.

구체적인 예를 들어 보겠습니다. 홈 오토메이션용 미니 PC, Frigate와 카메라용 두 번째 서버, 몇 가지 서비스를 실행하는 NAS, 외부의 VPS가 있다고 해 보죠. Komodo로 이 모든 것을 한곳에서 관리할 수 있습니다.

물론 Dockge보다 익숙해지는 데 시간이 더 걸립니다. 하지만 그만큼 훨씬 강력합니다.

Dockhand: 주목해 볼 신예

마지막으로 소개할 도구는 Dockhand입니다. 첫 버전은 2025년 12월에 나왔고, 놀라울 정도로 빠르게 발전하고 있습니다.

컨테이너, Compose 스택, 여러 Docker 환경, Git 저장소, 웹훅을 관리할 수 있습니다. 볼륨과 컨테이너 내부의 파일을 살펴보고, 네트워크 연결을 확인하거나 유지 관리 작업을 예약할 수도 있습니다.

특히 보안 기능이 돋보입니다. 셀프 호스팅 도구에서는 좀처럼 볼 수 없는 기능들이 있습니다. Grype와 Trivy를 사용해 이미지를 분석하고 알려진 취약점을 찾으며, 실행 중인 컨테이너를 교체하기 전에 새 이미지를 스캔할 수도 있습니다. 자동 업데이트로 인해 알려진 취약점이 가득한 이미지가 한밤중에 설치되는 일을 막기에 유용합니다.

버전 1.0.50은 2026년 9월 30일에 출시됐습니다.

다만 라이선스는 주의해서 살펴봐야 합니다. Dockhand는 Business Source License 1.1을 따릅니다. 개인 용도나 기업 내부 용도로는 무료지만, GPL이나 MIT 프로젝트처럼 자유 소프트웨어는 아닙니다. 예를 들어 호스팅 서비스로 재판매할 수 없습니다. 코드는 2029년에 Apache 2.0 라이선스로 전환될 예정입니다.

그렇다면 Portainer를 떠나야 할까요?

꼭 그렇지는 않습니다.

집의 Docker 서버에서 Portainer CE 2.45를 사용하고 있고 모든 것이 잘 작동한다면, 굳이 다 바꿀 이유는 없다고 봅니다. 해당 브랜치는 계속 유지 관리되고 수정 사항도 계속 제공될 것입니다.

하지만 이번 발표로 장기적으로 이 도구를 바라보는 제 관점이 달라졌습니다. Portainer는 Kubernetes와 기업 시장을 선택했습니다. 개발사의 관점에서 보면 충분히 이해할 수 있습니다. 다만 기술실에 미니 PC 한 대와 컨테이너 스무 개를 둔 사람에게는 그 방향이 맞지 않을 뿐입니다.

그런 사용자라면 제 생각은 이렇습니다.

• Arcane은 지금 가장 현대적이고 활발하게 개발되는 Portainer 대안입니다.
• Docker Compose를 중심으로 한 간결한 인터페이스를 원하고 개발이 더뎌진 점이 괜찮다면 Dockge도 여전히 훌륭합니다.
• 여러 서버를 관리하거나 GitOps로 전환하려는 순간 Komodo의 진가가 드러납니다.
• Dockhand는 특히 보안 기능이 매우 충실하고 계속 지켜볼 가치가 있습니다. 라이선스가 괜찮다면 말이죠.

가장 신중한 방법은 당장 아무것도 이전하지 않는 것입니다. Portainer와 함께 이 도구 중 하나를 설치해 몇 주 동안 테스트해 보세요. 모두 동일한 Docker 데몬과 통신하기 때문에 문제없이 함께 사용할 수 있습니다. Dockge의 FAQ에도 이 점이 명시돼 있습니다. 한 가지만 유의하세요. Portainer의 웹 편집기에서 만든 스택은 직접 관리할 수 있는 폴더가 아니라 Portainer의 데이터 볼륨에 저장됩니다. 이전하기 전에 Compose 파일을 꺼내 두세요.

제가 여러분이라면 이렇게 하겠습니다.

오랫동안 “Docker 관리를 위한 인터페이스는 무엇을 써야 할까?”라는 질문에는 거의 자동으로 Portainer라는 답이 나왔습니다. 2026년에는 마침내 제대로 된 선택지가 생겼고, 홈랩을 직접 꾸미는 사람들에게는 반가운 소식입니다.

여러분은 어떻게 생각하시나요?