푸시할 때마다 똑같은 의식이 반복됩니다. SSH로 접속하고, 저장소를 내려받고, Compose 스택을 다시 올리고, 아무것도 망가지지 않았기를 바라며, 마이그레이션을 실행했는지 기억을 더듬습니다. 이 수동 루프는 반복 가능한 배포, 무엇이 돌아가고 있는지에 대한 명확한 기록, 또는 드리프트 복구가 필요해지는 순간까지만 통합니다.
Doco CD가 그에 대한 직접적인 답 중 하나입니다. Git 저장소를 감시하다가 푸시가 일어나면 Compose 변경 사항을 적용하는 작은 Go 서비스로, 웹훅과 폴링 중 무엇을 쓸지는 여러분이 정합니다. ArgoCD와 Flux는 Kubernetes에서 같은 일을 하지만, Doco CD는 컨트롤 플레인이 필요 없기 때문에 Kubernetes를 건너뜁니다.
이 리뷰는 Doco CD가 무엇을 하고 무엇을 하지 않는지, 그리고 Komodo, Portainer의 GitOps 모드, Dokploy, 평범한 GitHub Actions + SSH 스크립트와 비교하면 어떤지를 다룹니다. 끝까지 읽으면 여러분의 환경에 맞는지, 맞지 않다면 무엇을 골라야 할지 알 수 있습니다.
요약
- Doco CD는 Compose에 특화된 아주 작은 GitOps 에이전트입니다. Git 저장소(GitHub, GitLab, Gitea, Forgejo 등)를 감시하다가 변경이 생기면 스택을 원하는 상태로 맞춥니다.
- 외부 시크릿 공급자를 기본 지원하고 SOPS 기반 암호화까지 제공한다는 점이, 배포 스크립트를 직접 만드는 것과의 결정적 차이입니다.
- README에 따르면 이 프로젝트는 스스로를 "Docker를 위한 간단한 Portainer 또는 ArgoCD 대안"으로 소개합니다. 대체로 정확한 표현입니다.
- 실제 한계는 이렇습니다. 코드 소유자가 한 명이고, 1.0 이전 버전 체계이며, 플릿 관리용 UI가 없고, 조정 상태는 다음 폴링이나 웹훅 이벤트가 와야만 다시 만들어집니다.
- Compose 호스트를 한두 대 운영하면서 UI 없이 Git을 진실의 원천으로 삼고 싶다면 이것을 고르세요. 서버가 많다면 Komodo, UI가 필요하면 Portainer, PaaS 같은 경험을 원하면 Dokploy, 정말로 호스트 하나에 서비스 하나뿐이라면 GitHub Actions + SSH가 답입니다.
Doco CD가 메우려는 빈틈
2026년에 Docker Compose를 운영하는 사람에게는 어정쩡한 중간지대가 있습니다. Argo CD와 Flux 같은 주요 GitOps 도구는 Kubernetes를 겨냥하고, Watchtower의 레지스트리 폴링 방식은 버전 관리된 Compose 상태를 적용하는 대신 이미지 변경에 반응할 뿐입니다. Watchtower의 저장소는 2025년 12월 17일에 보관 처리되었고, 현재는 프로젝트가 더 이상 유지보수되지 않는다고 안내하고 있습니다.
GitHub Actions에 SSH 배포 단계를 붙이는 방식도 잘 동작합니다. 호스트 하나에 서비스 하나라면 그게 정답입니다. 문제는 두 번째 호스트나 두 번째 스택이 생길 때, 또는 지금 어느 커밋이 배포돼 있는지 알고 싶을 때 드러납니다. 워크플로 로그는 여전히 남지만, Compose 수준의 조정도, 드리프트 복구도, 호스트가 저장소와 여전히 일치하는지 보여 주는 지속적인 화면도 없습니다.
Doco CD가 내세우는 문구는, README에 그대로 적힌 대로 "Docker를 위한 간단한 Portainer 또는 ArgoCD 대안"입니다. 바로 그 위치 설정이 핵심입니다. 작고, Compose에 특화돼 있고, Kubernetes가 없고, 유지할 UI도 없고, 돌봐야 할 중앙 컨트롤 플레인도 없습니다. K8s를 쓰지 않고 쓸 생각도 없었다면, 이것이 여러분이 찾던 부류입니다.
Doco CD는 실제로 어떻게 동작하나
Doco CD는 Docker 컨테이너 안에서 도는 단일 Go 바이너리로, Git 저장소를 감시하다가 저장소 상태가 바뀌면 Compose 변경 사항을 적용합니다. 개념은 이게 전부입니다. 재미있는 부분은 기본값과 연동에 있습니다.
트리거. 모드는 두 가지, 웹훅과 폴링입니다. 웹훅은 거의 즉시 반응하지만 외부에 포트를 열어야 하고, 현실적으로는 Doco CD 앞에 리버스 프록시를 두게 됩니다. 폴링은 주기적으로 가져오는 방식이라 약간 늦지만 인바운드 포트가 필요 없습니다. 폴링이 더 단순한 기본값이며, 공식 문서 공식 문서에 따르면 둘 다 일급 기능입니다. 호스트에 외부에서 닿을 수 있는 공개 엔드포인트가 있는지, 그리고 배포가 얼마나 빨라야 하는지를 기준으로 고르세요.
저장소별 설정. .doco-cd.yaml 파일(또는 .doco-cd.yml)은 저장소 최상위에 Compose 파일과 나란히 놓입니다. 반드시 있어야 하는 항목은 배포 이름 하나뿐입니다. 최소 설정은 다음과 같습니다:
# .doco-cd.yaml
name: my-stack
# Everything below is optional. These are the defaults.
timeout: 180 # seconds
remove_orphans: true
prune_images: true
force_recreate: false문서에 적힌 기본값은 이렇습니다. 타임아웃 180초, 고아 컨테이너 제거, 이미지 정리, 강제 재생성은 하지 않음.
자동 탐색. 자동 탐색을 켜면 Doco CD가 하위 디렉터리에서 Compose 파일을 찾아내므로, 저장소 하나에 여러 스택을 담을 수 있습니다. 또한 대시 세 개로 구분된 YAML 문서 형태로, 설정 파일 하나에 여러 배포 구성을 담는 것도 지원합니다. 정리 관련 기본값은 보수적으로 잡혀 있으니, 여기에 의존하기 전에 한 번 읽어 두는 편이 좋습니다:
| 설정 | 기본값 | 의미 |
|---|---|---|
delete | false | 앱이 작업 디렉터리에서 사라져도 오래된 배포는 그대로 남습니다. |
remove_volumes | false | 자동 탐색된 스택이 삭제돼도 볼륨은 남습니다. |
remove_images | true | 자동 탐색된 스택이 삭제되면 사용하지 않는 이미지는 제거됩니다. |
다시 말해, 여러분이 삭제를 켜기 전에는 등 뒤에서 무언가 사라지는 일이 없고, 켠 뒤에도 데이터 볼륨은 가장 마지막에야 없어집니다.
지원하는 Git 제공자. GitHub, GitLab, Gitea, Forgejo, Gogs, Azure DevOps를 지원합니다. 웹훅에서는 Azure DevOps가 예외인데, Azure Service Hooks를 지원하지 않기 때문입니다. 코드 저장 플랫폼을 직접 호스팅한다면 Gitea와 Forgejo 지원이 중요합니다.
Docker Swarm. 배포 대상으로 지원됩니다. 배포 설정 페이지 배포 설정 페이지가 명시적으로 밝히는 점은 이렇습니다. Swarm 모드의 조정은 컨테이너 재시작이나 헬스 상태를 확인하지 않으며, Swarm에서는 이미지 정리도 지원되지 않습니다. 대상이 Swarm이라면 배포는 얻지만 완전한 헬스 조정은 얻지 못합니다.
상태 조정. 기본값은 300초 창 안에서 재시작 5회 제한으로, 불안정한 헬스 체크가 무한 반복되는 것을 막기 위한 장치입니다. 같은 저장소에 다른 ref면 순차 실행, 같은 저장소에 같은 ref면 병렬 실행입니다. 마지막 항목은 눈에 잘 안 띄지만 유용합니다. 같은 ref의 배포가 여러 번 일어나도 서로 줄을 서서 기다리지 않습니다.
기본 제공되는 외부 시크릿 공급자. 평범한 배포 스크립트 대신 Doco CD를 고려할 만한 가장 강력한 이유 중 하나입니다. AWS Secrets Manager, Bitwarden Secrets Manager, Bitwarden Vault / Vaultwarden, 1Password, 1Password Connect, Infisical, OpenBao, Webhook을 지원합니다. 여기에 더해 민감한 배포 데이터를 위한 SOPS 기반 암호화도 지원합니다. 덕분에 시크릿 해석 과정을 통째로 직접 만들지 않고도, Git에 평문 env 파일을 두는 관행에서 깔끔하게 벗어날 수 있습니다.
나머지. Doco CD는 Prometheus 메트릭, 작업 스케줄링, 알림, distroless 컨테이너 이미지, 그리고 Apache-2.0 라이선스를 제공합니다. 릴리스 기록릴리스 기록에 따르면 2026년 8월 20일 기준 최신 안정 버전은 v0.109.2이고, 가장 최근 사전 배포판은 v0.110.0-rc.1입니다.
Doco CD의 역할은 "매니페스트를 적용한다"에서 끝나고, 그다음부터는 평범한 Docker입니다. Compose 자체의 로그 명령 으로 무엇이 돌아가는지 확인하게 됩니다.
시크릿에 대한 팁. 비공개 저장소에 아직 평문 env 파일이 남아 있다면, Doco CD의 외부 시크릿 공급자나 SOPS 지원을 먼저 도입하세요. 목표는 단순합니다. 평문 비밀은 Git 밖으로 빼되, 배포 시점에는 값을 그대로 가져올 수 있게 하는 것입니다.
루트 액세스, NVMe, AMD EPYC 성능을 갖춘 Linux VPS에서 개발하세요.
Linux 요금제 보기Doco CD가 부족한 지점
모든 도구에는 한계가 있고, Doco CD의 한계는 주말을 통째로 설치에 쏟아붓기 전에 알아 두는 편이 좋습니다.
단일 코드 소유자. 저장소의 CODEOWNERS 파일은 모든 경로를 kimdre에게 할당합니다. 릴리스는 여전히 자주 나오지만, 프로젝트 운영 권한은 한 사람에게 집중돼 있습니다.
1.0 이전. Doco CD는 아직 0.x 버전 체계를 쓰므로, 검증된 릴리스를 고정하고 배포 전에 업그레이드 노트를 읽으세요. 닫힌 GitHub 이슈 #851 가 그 이유를 잘 보여 줍니다. Docker v29 때문에 프로젝트는 더 이상 지원되지 않는 Docker Go 모듈에서 벗어나야 했습니다.
Doco CD 컨테이너 안에는 셸이 없습니다. 보안을 위해 Doco CD는 셸 환경을 제공하지 않고 호스트에서 임의의 스크립트도 실행하지 않습니다. 배포 전후 작업은 init 컨테이너, 사이드카, 또는 Compose 라이프사이클 훅을 거쳐야 하며, 배포 스크립트를 바로 실행하는 도구에 비하면 설정이 늘어납니다.
재시작 시 상태 소실. 조정 상태는 메모리에 있습니다. Doco CD가 재시작하면 그 상태는 다음 폴링이나 웹훅 이벤트가 와야 다시 만들어지므로, 공백의 길이는 폴링 주기나 다음 웹훅이 얼마나 빨리 도착하는지에 달려 있습니다.
플릿 관리 UI가 없습니다. 여러 호스트를 다루는 데 더 이상 호스트마다 에이전트를 둘 필요가 없습니다. v0.102.0부터 배포 구성이 원격 Docker 컨텍스트를 대상으로 삼을 수 있고, SSH 컨텍스트도 포함되며, 저장소 하나가 여러 배포 대상을 정의할 수 있습니다. 호스트마다 Doco CD 인스턴스를 하나씩 두는 방식도 여전히 유효하지만, 이제는 중앙 인스턴스 하나로 원격 Docker 호스트에 배포할 수 있습니다. 그럼에도 Doco CD에 여전히 없는 것은 Komodo가 갖춘 플릿 관리 UI와 중앙 집중식 호스트 목록입니다.
RAM과 CPU 사용량이 수치로 문서화돼 있지 않습니다. 공식 문서는 요구 사항을 "아주 작다"고만 표현할 뿐 기준 수치를 내놓지 않습니다. VPS 크기는 그 위에서 돌릴 애플리케이션에 맞춰 잡고, 운영 여유분을 남기며, Doco CD의 실제 사용량은 여러분의 환경에서 직접 확인하세요.
여러 호스트를 다룰 때의 팁. 호스트마다 별도의 Docker 컨텍스트와 배포 대상을 쓰고, SSH 접근을 제한하며, 웹훅이나 API 시크릿은 서로 다르게 유지하세요. 격리된 에이전트가 더 마음에 든다면, 호스트마다 Doco CD 인스턴스를 하나씩 두는 방식도 여전히 유효합니다.
Doco CD와 대안들 비교
제가 후보로 올릴 나머지 네 가지 도구는 모두 "Git에서 Compose를 자동 배포한다"는 같은 문제를 풀지만, 절충점이 크게 다릅니다. 결정할 문제는 이걸 할지 말지가 아닙니다. 그건 이미 정했으니까요. 결정할 문제는 어떤 형태의 도구가 여러분의 환경에 맞느냐입니다. 나란히 비교해 보겠습니다.
| 도구 | 트리거 | 멀티 호스트 모델 | 시크릿 | 웹 UI | 라이선스 |
|---|---|---|---|---|---|
| Doco CD | 웹훅 또는 폴링 | 원격 Docker 컨텍스트, 플릿 UI 없음 | 외부 공급자와 SOPS | 없음 | Apache-2.0 |
| Komodo | 웹훅과 예약 동기화 | 중앙 Core와 Periphery 에이전트 | 변수 및 시크릿 관리 | 예 | GPL-3.0 |
| Portainer (CE/BE) | 웹훅 또는 폴링 | Portainer 에이전트 | 제한적, BE에서 선택지 확대 | 예 | Zlib, BE는 상용 라이선스 |
| Dokploy | 푸시로 트리거 | 다중 서버 또는 Docker Swarm | 환경 관리 기본 제공 | 예 | Apache-2.0, 일부 독점 구성 요소 포함 |
| GitHub Actions + SSH | 푸시로 트리거 | 직접 스크립트로 만드는 만큼 | 직접 스크립트로 만드는 만큼 | 없음 | 해당 없음 |
각각에 대해 짧게 짚어 보겠습니다. 표는 형태를 보여 주고, 설명은 이유를 말해 주니까요:
Komodo. 여러 호스트를 다룰 때의 진지한 대안입니다. 중앙 Core 서비스에 호스트마다 Periphery 에이전트를 두고, 그 전부를 한 화면에서 보며, 배포뿐 아니라 Git 기반 빌드까지 하고, Docker Swarm도 지원합니다. 데이터베이스와 컨트롤 플레인을 함께 돌려야 하니 설치는 더 무겁지만, 서버가 많다면 이쪽이 올바른 형태입니다. 중앙 집중식 서버 관리가 중요하다면 Komodo가 더 잘 맞습니다.
GitOps를 켠 Portainer (CE 또는 BE). Git 동기화 위에 얹은 완전한 그래픽 UI입니다. 팀이 CD와 함께 클릭 방식의 컨테이너 관리를 원할 때 알맞은 선택입니다. 어차피 누군가는 UI에서 로그를 보고 컨테이너를 재시작할 텐데, 그렇다면 CD도 같은 자리에 두는 편이 낫습니다. 자원 소모는 Doco CD보다 큽니다. OIDC/SSO와 세분화된 RBAC은 유료인 Business Edition에 묶여 있습니다. 이에 관해서는 Portainer 대안 가이드 에서 더 넓은 Docker 관리 지형을 다룹니다.
Dokploy. PaaS 스타일입니다. 방향이 뚜렷하고, 푸시하면 자동 배포되며, 모든 기능에 웹 UI가 있고, Traefik과 깔끔한 URL 구성을 처음부터 갖춰 줍니다. Heroku 같은 느낌을 원하고 그 대가로 Compose의 날것 그대로의 유연성을 포기할 수 있는 팀에 더 잘 맞습니다. YAML 알레르기가 있다면, "git push하면 앱이 배포된다"에 이르는 가장 가벼운 길입니다.
GitHub Actions + SSH. 추가 인프라가 전혀 없습니다. 배포 작업은 이미 쓰고 있는 워크플로 안에 살고 있습니다. 워크플로 로그는 얻지만, Compose 수준의 조정도, 드리프트 복구도, 호스트 상태를 계속 보여 주는 화면도 없습니다. 직접 만들지 않는 한 말이죠. 호스트 하나에 서비스 하나라면 충분합니다. 두 번째 대상이 생기거나, SSH로 들어가지 않고도 무엇이 어디서 도는지 알고 싶어지는 순간 무너집니다. 가장 단순한 층의 독자에게는 GitHub Actions + SSH가 여전히 정답입니다.
더 최근에 등장한 stackd stackd라는 도구도 있는데, "Kubernetes 세금 없는 GitOps"라는 비슷한 표현으로 자신을 소개합니다. 이 분야가 살아 있다는 걸 알아 둘 가치는 있지만, 오늘 동전 던지기로 Doco CD 대신 이걸 고를 만한 정도는 아닙니다.
Doco CD가 맞는 선택일 때 (그리고 아닐 때)
다음과 같을 때 Doco CD를 고르세요:
- Docker Compose 호스트를 한두 대 운영하면서 Git을 진실의 원천으로 삼고 싶을 때.
- UI를 클릭하며 다니기보다 편집기에서 YAML을 고치는 쪽이 편할 때.
- 외부 시크릿 공급자 지원과 SOPS 기반 암호화를, 전체 과정을 직접 만들지 않고 얻고 싶을 때.
- 메인테이너가 한 명이고 1.0 이전이지만 활발히 개발되는 프로젝트를 감당할 수 있을 때.
Komodo. 호스트를 여러 대 관리하면서 중앙 집중식 통제가 필요하거나, 배포만이 아니라 Git 기반 빌드까지 한곳에서 처리해야 할 때 고르세요.
Portainer (CE 또는 BE). 팀이 CD와 함께 일상적인 컨테이너 운영용 UI를 원할 때, 즉 시각적인 계층 자체가 이 도구를 고려하는 진짜 이유일 때 고르세요.
Dokploy. PaaS 방식의 배포 경험을 원하고 Compose를 날것 그대로 제어할 필요가 없을 때 고르세요.
GitHub Actions + SSH. 서비스 하나, 호스트 하나이고 상태 조정이나 드리프트 복구가 필요 없다면 계속 이 방식을 쓰세요.
Watchtower 이후, Kubernetes 이전의 중간 지대에 있는 사람들에게 Doco CD는 가볍고 든든한 선택입니다. 제 판단은 이렇습니다. 새 홈랩이나 작은 SaaS라면 Git 우선에 UI 없는 운영이 맞는 동안은 Doco CD로 시작하고, 중앙 집중식 자산 목록과 권한, 서버 전반의 가시성이 요구 사항이 되는 시점에 Komodo로 옮기겠습니다.
어떤 도구를 고르든, 그 위에서 돌릴 Compose 워크로드에 맞춰 크기를 잡은 Linux VPS에서 운영하세요. Cloudzy의 Linux VPS 는 이 용도에 알맞은 자리이고, 기본으로 root 접근 권한이 딸려 옵니다. apt 씨름을 건너뛰고 싶다면 Docker를 원클릭으로 배포 하는 것도 우리 마켓플레이스에서 가능합니다.
우리 마켓플레이스에는 원클릭 이미지도 있습니다. GiteaDoco CD가 기본으로 연동하는 도구입니다. 이 밖에도 이미지가 있습니다. Komodo 그리고 Portainer그중 하나가 여러분에게 더 맞는 형태라고 판단한다면 그쪽을 쓰면 됩니다.
자주 묻는 질문
Doco CD는 프로덕션에 쓸 만한가요?
Doco CD의 위험 프로필이 여러분의 워크로드에 맞다면 프로덕션에서 써도 됩니다. 개발은 활발하지만 아직 1.0 이전 버전 체계를 쓰고, CODEOWNERS 파일은 프로젝트를 한 사람에게 지정하고 있습니다. 검증된 릴리스를 고정하고, 업그레이드는 배포 전에 시험해 보며, 중요한 인프라라면 더 넓은 거버넌스를 고려하세요.
Doco CD로 여러 호스트를 어떻게 관리하나요?
호스트마다 별도의 Docker 컨텍스트와 배포 대상을 쓰세요. Doco CD 인스턴스 하나로 SSH나 TCP를 통해 여러 원격 Docker 호스트에 배포할 수 있고, 호스트마다 인스턴스를 두는 방식은 선택 가능한 격리 모델로 남아 있습니다. 중앙 집중식 자산 목록과 권한, 서버 전반의 가시성이 필요하다면 Komodo를 고르세요.
웹훅 모드와 폴링 모드는 무엇이 다른가요?
웹훅 모드는 Git에 푸시가 들어오면 거의 즉시 배포하지만, 인터넷에서 접근 가능한 포트나 Doco CD 앞의 리버스 프록시가 필요합니다. 폴링 모드는 정해진 주기로 저장소를 확인하므로 배포가 조금 늦어지는 대신 포트를 열 필요가 없습니다. 폴링이 더 단순한 기본값이고, 웹훅은 푸시가 잦거나 빠른 피드백이 필요할 때 값어치를 합니다.
Doco CD는 Komodo와 비교하면 어떤가요?
Doco CD는 더 가볍고 UI가 없으며, 원격 Docker 컨텍스트를 통해 여러 호스트를 다룰 수 있습니다. Komodo는 중앙 Core 서비스와 Periphery 에이전트를 쓰고, 여기에 플릿 UI와 Git 기반 빌드를 더합니다. UI 없는 Compose 배포에는 Doco CD를, 중앙 집중식 서버 통제가 중요할 때는 Komodo를 고르세요.
Doco CD가 Watchtower를 대체할 수 있나요?
대부분의 Watchtower 사용자가 실제로 원했던 용도, 즉 "Git이 바뀌면 Git에 있는 것을 배포한다"라면 답은 예입니다. Doco CD가 하는 일이 바로 그것입니다. 반면 Watchtower의 문자 그대로의 방식, 즉 레지스트리를 폴링하다가 새 이미지 태그가 나오면 받아오는 방식이라면 답은 아니요입니다. Doco CD는 레지스트리가 아니라 Git이 방아쇠입니다. 장난감 수준을 넘어서는 서비스라면 Git이 방아쇠인 쪽이 더 안전하고 감사하기도 쉽습니다.
