Coolify vs Dokploy: 2026년 실전 비교

최근 클라우드 비용을 절감하기 위해 가상 사설 서버(VPS)에 직접 배포 환경을 구축하려는 개발자가 늘고 있습니다. 대표적인 오픈소스 PaaS 선택지인 쿨리파이(Coolify)와 독플로이(Dokploy)는 편리한 사용자 경험을 제공하지만, 내부 아키텍처와 리소스 관리 방식은 완전히 다릅니다. 특히 소형 서버 환경에서는 대기 상태 메모리 점유율, 빌드 파이프라인 분리 여부, 백업 안정성 같은 실전 제약 조건이 서비스의 생존을 결정합니다. 제한된 예산 속에서 최선의 인프라를 선택할 수 있도록, 두 플랫폼의 아키텍처와 구체적인 기술적 제약 조건을 비교해 보겠습니다.

대기 상태 메모리 비교: 750MB의 쿨리파이 vs 350MB의 독플로이

서버 리소스가 제한된 환경에서 플랫폼 자체의 대기 상태 메모리 점유율은 애플리케이션 배포 가용성을 결정하는 핵심 요인입니다. NextGrowth.ai와 Cherry Servers의 벤치마크 데이터에 따르면, 라라벨 백엔드와 백그라운드 큐 워커를 구동하는 쿨리파이 v4는 아무런 워크로드가 없는 상태에서도 약 750MB에서 1.2GB의 메모리를 기본으로 점유합니다.

반면 타입스크립트 기반으로 설계된 독플로이는 약 350MB 수준의 메모리만 점유하여 쿨리파이의 절반 이하에 불과한 오버헤드를 유지합니다. 특히 쿨리파이에서 메트릭 모니터링이나 원격 분석 데이터 수집 기능을 활성화하면 리소스 점유율이 추가로 상승하기 때문에, 2GB RAM 내외의 저스펙 VPS 인프라에서는 실제 실행할 서비스 메모리를 더 넉넉하게 확보할 수 있는 독플로이가 실질적인 해답이 될 수 있습니다.

닉스팩스 빌드 병목 해결: 독플로이의 전용 빌드 서버 아키텍처

두 플랫폼 모두 소스 코드의 언어를 자동으로 감지해 도커 이미지를 빌드해 주는 닉스팩스(Nixpacks) 엔진을 기본으로 사용합니다. 개발자가 직접 도커파일을 작성할 필요가 없어 편리하지만, 저스펙 서버를 운영할 때는 배포 마다 큰 리스크를 감수해야 합니다. 닉스팩스 빌드는 일시적으로 CPU와 메모리를 극도로 많이 소모하기 때문에, 2GB RAM 수준의 소형 서버에서는 컴파일 도중 서버가 완전히 먹통이 되는 고질적인 문제가 발생합니다.

독플로이는 이 빌드 병목을 해결하기 위해 '전용 빌드 서버' 아키텍처를 네이티브로 지원합니다. 운영 서버가 아닌 별도의 고성능 빌드 서버에서 소스 코드를 빌드하고, 완성된 이미지를 도커 허브나 GHCR 같은 외부 컨테이너 레지스트리에 푸시합니다. 이후 실제 서비스를 구동하는 가벼운 운영 서버는 빌드된 이미지를 당겨와 실행하기만 하면 됩니다. 빌드 도중 발생하는 과부하로부터 운영 환경을 완벽히 격리하는 구조입니다.

반면 쿨리파이는 여전히 배포 대상 로컬 서버 내에서 빌드 파이프라인을 구동하고 제어하는 방식을 사용합니다. 이 때문에 자원이 제한된 서버 환경에서 대규모 빌드를 실행하면 성능 저하나 컨테이너 중단 현상이 발생하기 쉽습니다. 제한된 예산으로 실전 서비스를 안정적으로 운영하려는 풀스택 개발자에게는 빌드 단계를 별도 서버로 완전히 오프로딩할 수 있는 독플로이의 설계가 확실한 해결책이 될 수 있습니다.

멀티 서버 제어 방식: 중앙 집중형 SSH vs 네이티브 도커 스웜

두 플랫폼은 다중 서버를 구성하고 조율하는 아키텍처에서 가장 극명한 철학 차이를 보입니다.

독플로이는 처음부터 도커 스웜을 네이티브 엔진으로 채택했습니다. 매니저와 워커 노드로 구성된 실제 클러스터를 기반으로 컨테이너의 롤링 업데이트, 복제본 제어, 자동 복구를 네이티브로 처리합니다. 다만 대시보드 UI가 설치된 기본 호스트가 무조건 스웜 매니저 역할을 해야 하므로, 단일 패널에서 완전히 격리된 별도의 독립 스웜 클러스터를 원격 제어하는 데는 구조적 한계가 있습니다.

반면 쿨리파이는 중앙의 단일 관리 대시보드가 원격 서버들에 SSH 명령을 개별적으로 전송해 독립된 단일 도커 컨테이너들을 제어하는 방식을 취합니다. 개별 노드들을 독립적으로 관리하기에는 편리하지만, 노드 간 자동 로드 밸런싱이나 컨테이너 자동 이동 같은 진정한 의미의 클러스터링 오케스트레이션은 기본적으로 지원하지 않습니다. 쿨리파이에서도 도커 스웜 배포를 선택할 수 있으나, 버전 검증 버그 등의 이슈로 인해 여전히 불안정한 실험 단계에 가깝습니다.

다만 독플로이가 제공하는 네이티브 도커 스웜 환경 역시 완벽한 해결책은 아닙니다. 노드 장애 발생 시 컨테이너가 다른 노드로 자동 복구되더라도 영구 볼륨 데이터가 함께 따라가지는 못합니다. 이를 매끄럽게 연동하려면 네트워크 파일 시스템(NFS)이나 클라우드 공유 스토리지 같은 복잡한 외부 스토리지 솔루션을 개발자가 직접 구성해야 하는 인프라 운영 제약이 따릅니다.

SSL 인증서 복제와 프록시 제약: 트래픽과 캐디의 선택

역방향 프록시 구성과 SSL 자동화 편의성은 두 플랫폼의 실전 운영 경험을 가르는 핵심 요인입니다. 쿨리파이는 대시보드 UI에서 클라우드플레어 같은 DNS 공급자의 API 토큰만 입력하면 와일드카드 인증서를 자동으로 발급받는 DNS-01 챌린지 설정을 제공합니다. 또한 마우스 클릭 한 번으로 기본 프록시인 트래픽에서 캐디로 즉시 전환할 수 있어 까다로운 라우팅 환경도 매끄럽게 처리합니다.

반면 독플로이는 와일드카드 인증서 자동 발급을 네이티브로 지원하지 않습니다. 독플로이에서 와일드카드 서브도메인을 구성하려면 트래픽 환경 변수에 DNS API 토큰을 직접 등록하고, 컴포즈 서비스 블록마다 호스트 정규식 같은 수동 커스텀 레이블을 직접 작성해야 하는 번거로움이 있습니다.

특히 멀티 노드 도커 스웜 환경을 구축할 때 역방향 프록시 제약이 뚜렷해집니다. 독플로이가 기본 채택한 트래픽 커뮤니티 에디션은 다중 노드 환경에서 인증서 파일을 안전하게 분산 공유하는 기능을 제공하지 않아, 여러 매니저 노드에서 작동할 때 파일 잠금 충돌 문제가 발생합니다. 이를 극복하려면 트래픽 서비스를 특정 단일 노드에 강제로 고정하거나 외부에서 발급받은 인증서를 도커 시크릿을 통해 전달해야 합니다. 최근 독플로이 커뮤니티에서 이러한 복잡성을 해결하기 위해 캐디 통합 개발을 활발히 추진하는 것도 이와 같은 도커 스웜 환경의 제약 때문입니다.

재해 복구와 백업 신뢰성: 쿨리파이 v4.1.2 백업 버그와 독플로이의 일체형 백업

실전 운영에서 백업과 복구는 결코 타협할 수 없는 핵심 영역입니다. 이 관점에서 독플로이와 쿨리파이 v4는 백업 아키텍처의 설계와 장애 발생 시의 신뢰성 측면에서 확연한 차이를 보입니다.

독플로이 공식 문서에 따르면, 이 플랫폼은 모든 설정 정보가 담기는 경로(/etc/dokploy)와 메인 데이터베이스(dokploy-postgres)를 단일 zip 파일로 압축하여 S3 호환 저장소나 클라우드플레어 R2로 자동 업로드하는 정기 백업 메커니즘을 지원합니다. 개별 데이터베이스 독립 백업과 도커 볼륨 백업까지 크론 스케줄로 편리하게 자동화할 수 있다는 장점이 있습니다. 다만 새 서버로 전제 복구를 수행할 때는 서버 IP를 수정하고 Git 제공업체 설정을 수동으로 다시 연동해야 하는 일부 사후 작업이 필요합니다.

반면 쿨리파이는 독립적인 데이터베이스 백업 기능은 지원하지만 v4.1.2 버전을 기준으로 백업 신뢰성에 치명적인 결함이 관측됩니다. 쿨리파이 GitHub 이슈에 따르면 설정에서 특정 S3 저장소 엔드포인트를 삭제해도 기존 백업 작업에 연결된 참조가 정상적으로 정리되지 않는 문제가 있습니다. 이 상태에서 예약 백업 일정이 도래하면 대시보드에 아무런 에러 로그나 알림을 보내지 않은 채 백업이 무음 실패하게 되므로, 관리자가 인지하지 못하는 사이 백업이 장기간 누락될 위험이 있습니다.

또한 수파베이스(Supabase) 스토리지를 S3 호환 저장소 백업 대상지로 설정할 때도 장애가 발생합니다. 수파베이스 API URL 내부의 중첩 리소스 경로를 내부 MinIO 클라이언트가 정상적으로 해석하지 못해 'mc: Invalid URL' 파싱 오류를 일으키며 백업이 원천적으로 실패합니다. 따라서 프로덕션 환경에서 쿨리파이 v4.1.2를 도입할 때는 백업 저장소 연동 후 실제로 파일이 정상 업로드되는지 검증하고 실시간 모니터링을 병행해야 합니다.

나에게 맞는 셀프 호스팅 플랫폼 선택 가이드

쿨리파이와 독플로이는 라이선스 모델에서도 뚜렷한 철학 차이를 보여줍니다. 독플로이는 코어 기능을 아파치 2.0 라이선스로 배포하되 엔터프라이즈 기능은 독자적인 소스 공개 라이선스로 제한하는 오픈 코어 모델을 채택한 반면, 쿨리파이는 전체 플랫폼을 완전히 허용적인 아파치 2.0 라이선스로 유지하고 있습니다.

풍부한 마켓플레이스 템플릿 생태계와 직관적인 단일 서버 관리, 복잡한 프록시 설정 없이 DNS-01 챌린지 기반의 와일드카드 SSL 발급까지 간편하게 마쳐야 하는 환경이라면 쿨리파이가 가장 매력적인 선택입니다.

반대로 가용 리소스가 극도로 제한된 소형 VPS를 운영하거나, 처음부터 다중 노드 수준의 도커 스웜 환경에서 무중단 롤링 배포를 지향한다면 독플로이가 더 안정적인 대안입니다. 빌드 전용 서버를 완벽히 분리하고 350MB 수준의 가벼운 메모리 점유율을 활용하여 예산 제약 속에서도 인프라 가성비를 극대화할 수 있습니다.

참고 링크