Dokploy vs Coolify: 메모리 오버헤드와 Docker Swarm 운영 제약 비교

클라우드 인프라 비용을 절감하기 위해 셀프 호스팅 PaaS를 고려할 때, 현재 가장 주목받는 선택지는 Coolify v4와 Dokploy입니다. 두 도구는 언뜻 비슷해 보이지만, 대기 상태의 메모리 점유율부터 Docker Swarm 기반의 클러스터링 확장 방식까지 아키텍처 설계와 운영 방향성에서 뚜렷한 차이를 보입니다. 단순히 보기 좋은 UI를 넘어 빌드 파이프라인의 자원 병목, 백업 안정성, 그리고 SSL 인증서 공유 방식 같은 실제 프로덕션 운영 관점의 핵심 제약과 대안을 비교해 봅니다.

메모리 오버헤드와 Nixpacks 빌드 파이프라인의 차이

자원 효율성 관점에서 Dokploy는 Coolify v4보다 훨씬 가볍습니다. 대기 상태에서 Coolify v4는 풍부한 템플릿과 백엔드 구조 때문에 약 750MB에서 1.2GB의 RAM을 점유하는 반면, Dokploy는 약 350MB에서 500MB의 메모리만 소비합니다. 이 차이 덕분에 Dokploy는 2GB 내외의 저사양 VPS 환경에서 더 많은 자원을 실제 서비스에 양보할 수 있습니다.

하지만 코드를 빌드하는 과정에서는 두 플랫폼 모두 심각한 자원 병목을 겪게 됩니다. 기본 빌드 엔진으로 사용하는 닉스팩스(Nixpacks)는 Dockerfile 없이 소스 코드를 자동으로 빌드해 주어 편리하지만, Node.js나 Next.js 컴파일 단계에서 RAM 사용량이 순간적으로 3GB에서 4GB까지 치솟습니다. 이 순간적인 스파이크 때문에 스왑 메모리 설정이 없는 저사양 단일 서버는 빌드 도중 아예 먹통이 되는 현상이 발생합니다.

Dokploy는 이 문제를 해결하기 위해 전용 빌드 서버 파이프라인을 지원합니다. 메인 패널이 구동되는 저사양 프로덕션 서버에서 직접 빌드하지 않고, 고사양의 독립된 빌드 서버에서 빌드를 수행한 뒤 최종 컴파일된 이미지를 Docker Hub나 GitHub Container Registry 같은 외부 레지스트리에 푸시하는 방식입니다. 이후 프로덕션 서버는 빌드가 완료된 가벼운 이미지를 내려받아 실행만 하므로, 빌드 프로세스로 인한 운영 서버의 다운타임을 완벽히 방지할 수 있습니다.

Docker Swarm 네이티브 클러스터링과 데이터 동기화의 제약

두 플랫폼은 멀티 서버를 확장하고 관리하는 아키텍처 관점에서 근본적인 노선을 달리합니다. Dokploy는 설계 단계부터 Docker Swarm을 완전히 네이티브로 채택하여 가상 서버를 매니저와 워커 노드로 구성된 실제 클러스터로 묶어냅니다. 반면 Coolify는 중앙 집중식 대시보드가 에이전트 없이 SSH 연결을 통해 독립된 원격 서버들을 개별 제어하는 구조입니다. 이 때문에 Coolify에는 여러 서버를 하나로 묶는 네이티브 클러스터링이나 노드 간 컨테이너 자동 이동 같은 기능이 기본적으로 존재하지 않습니다.

이러한 아키텍처 차이는 무중단 배포 메커니즘에서 명확히 드러납니다. Dokploy는 Docker Swarm의 롤링 업데이트 기능을 그대로 활용해, 컨테이너 헬스체크와 연동하여 신규 버전을 먼저 시작하고 검증 후 기존 버전을 내리는 롤백 제어를 엔진 수준에서 네이티브로 처리합니다. 반면 Coolify는 단일 노드 내부에서 자체 오케스트레이션 코드로 두 컨테이너를 동시에 실행하고 역방향 프록시 경로를 전환하는 방식으로 무중단 배포를 구현합니다.

하지만 Dokploy의 네이티브 Swarm 기반 아키텍처에는 현실적인 제약도 따릅니다. NFS 같은 네트워크 공유 스토리지 인프라를 별도로 구축하지 않으면 노드 간에 영구 볼륨 데이터가 공유되지 않아 데이터베이스 같은 상태 저장형 서비스를 멀티 노드로 유연하게 복제하기 어렵습니다. 또한 Dokploy 웹 UI 대시보드가 설치 호스트에 강하게 결합되어 있어 해당 호스트가 무조건 Swarm 매니저 역할을 맡아야 하므로, 완전히 격리된 별도의 Swarm 클러스터를 원격 제어판 형태로 관리하는 것은 불가능합니다.

Traefik CE 역방향 프록시와 와일드카드 SSL 인증서 공유 문제

Docker Swarm 환경에서 멀티 노드 클러스터를 설계할 때 가장 먼저 마주치는 걸림돌 중 하나는 SSL 인증서의 공유 문제입니다. Coolify와 Dokploy 모두 동적 라우팅과 Let's Encrypt 인증서 자동 발급을 위해 Traefik을 기본 역방향 프록시로 사용하지만, 이를 다루는 방식과 제약 조건에는 큰 차이가 있습니다.

Coolify는 웹 UI에서 Cloudflare나 Route53 등의 API 토큰을 입력해 DNS-01 챌린지 기반의 와일드카드 SSL 인증서를 간편하게 설정할 수 있도록 돕습니다. 반면 Dokploy는 아직 웹 UI를 통한 와일드카드 인증서 자동 발급을 기본적으로 지원하지 않습니다. Dokploy에서 와일드카드 서브도메인을 운영하려면 사용자가 직접 'Web Server > Traefik > Environment Variables' 메뉴에 CF_DNS_API_TOKEN 같은 DNS API 변수를 입력하고, 서비스의 컴포즈 블록에 HostRegexp와 같은 Traefik 사용자 지정 동적 라우팅 라벨을 수동으로 추가해야 합니다.

더 근본적인 문제는 멀티 매니저 노드로 구성된 Docker Swarm 클러스터 환경에서 발생합니다. 무료인 Traefik 커뮤니티 에디션(CE)은 인증서 데이터를 여러 노드가 동시에 공유하는 분산 ACME 기능을 지원하지 않습니다. 여러 노드에서 동시에 acme.json 파일에 접근해 인증서를 갱신하려고 하면 파일 잠금 충돌이 일어나 인증서 발급이 실패합니다.

엔지니어는 이 아키텍처적 한계를 우회하기 위해 다음 두 가지 방법 중 하나를 선택해야 합니다. 첫째, Traefik 서비스를 단 하나의 매니저 노드에만 실행되도록 배치 제약을 걸어 수동으로 고정하는 방법입니다. 둘째, 외부에서 발급한 와일드카드 인증서를 Dokploy UI를 통해 직접 업로드하는 방법입니다. 이 방식을 사용하면 Dokploy가 업로드된 인증서 파일을 Docker Secrets 시스템에 등록하며, 이는 Swarm의 암호화된 Raft 로그를 통해 클러스터 전체 노드로 안전하게 복제되어 공유됩니다. 최근에는 이러한 Traefik CE의 제약을 극복하기 위해 Dokploy 커뮤니티에서 Caddy 프록시 연동을 도입하려는 움직임도 활발히 진행 중입니다.

데이터베이스 백업 기능과 연동 안정성 분석

셀프 호스팅 인프라를 운영할 때 데이터베이스 백업의 안정성은 서비스의 생존과 직결됩니다. Dokploy는 전체 시스템 상태가 담긴 /etc/dokploy 디렉토리와 내부 PostgreSQL 데이터를 단일 압축 파일로 묶어 S3나 Cloudflare R2로 자동 전송하는 빌트인 크론 시스템을 지원합니다. 개별 데이터베이스 인스턴스 전용 백업뿐만 아니라 raw 볼륨 백업까지 깔끔하게 처리해주어 백업 파이프라인 구성이 직관적입니다.

반면 Coolify v4는 pg_dump나 mysqldump 기반의 백업 옵션을 상세히 제공하지만, v4.1.2 릴리스를 기준으로 운영 환경에서 치명적일 수 있는 치명적인 버그가 발견되어 주의가 필요합니다. 대표적으로 설정에서 S3 스토리지 엔드포인트를 삭제할 때, 기존 백업 작업과의 연동 참조가 정상적으로 정리되지 않는 결함이 존재합니다. 이 경우 백업 파이프라인이 에러 메시지나 실패 알림을 전혀 보내지 않고 조용히 누락되는 현상이 발생하여 백업 누수를 유발할 위험이 있습니다.

또한 Coolify에서 Supabase Storage를 S3 백업 대상으로 연동할 때 호환성 이슈가 보고되고 있습니다. Supabase API URL 특유의 중첩된 리소스 경로 구조 때문에, 백업을 전송하는 내장 MinIO 클라이언트가 이를 정상 파싱하지 못하고 'mc: Invalid URL' 에러를 뿜으며 동작을 멈춥니다. 따라서 S3 호환 스토리지를 백업 거점으로 삼고자 하는 개발자라면 실제 프로덕션 환경에 적용하기 전에 이러한 연동 결함을 반드시 사전 검증해야 합니다.

인프라 목적에 맞는 PaaS 최종 선택 기준

결론적으로 셀프 호스팅 PaaS 선택은 구축하려는 인프라 아키텍처와 자원 예산에 따라 명확히 갈립니다. 단일 VPS 환경에서 풍부한 원클릭 템플릿을 활성하고 UI 상에서 간편하게 와일드카드 SSL 인증서를 발급받아 빠르게 서비스를 론칭하고 싶다면 Coolify v4가 가장 직관적인 도구입니다. 반면 1GB에서 2GB 내외의 저사양 서버를 효율적으로 사용하면서 Docker Swarm 기반의 다중 노드 확장과 무중단 롤링 업데이트 체계를 견고하게 구축하고 싶다면 경량화된 자원 설계가 강점인 Dokploy가 훨씬 정밀한 엔지니어링 선택지가 될 것입니다. 각 플랫폼이 가진 빌드 제약과 프록시 구성의 한계를 미리 인지하고, 안정적인 백업 파이프라인과 함께 프로덕션 환경을 설계해 보시기 바랍니다.

참고 링크