수동 배포는 위험하고, Kubernetes는 부담입니다
SSH로 접속해 파일을 올리고 서비스를 재시작하는 방식은 사람에 의존합니다. 그렇다고 Kubernetes를 도입하기에는 복잡도와 인력 부담이 큽니다.
중소기업 인프라 현실에 맞춘
경량 GitOps CD
Kubernetes까지는 필요 없지만 Git을 기준으로 배포 상태를 관리하고 싶은 조직을 위한 도구입니다. 기존 VM·EC2·물리 서버·엣지 장비에 컨테이너 오케스트레이션 없이 애플리케이션 아티팩트를 배포하고, Git에 선언된 상태로 서버를 동기화합니다.
Rust · Axum 기반 오픈소스 JejuCD(Apache 2.0)에서 출발해, CloudBro가 기업 환경에 맞게 제공합니다.
SSH로 접속해 파일을 올리고 서비스를 재시작하는 방식은 사람에 의존합니다. 그렇다고 Kubernetes를 도입하기에는 복잡도와 인력 부담이 큽니다.
Vercel·Supabase 같은 PaaS는 초기 검증에 강력하지만, 비용 통제·폐쇄망·온프레미스·보안 요구가 생기면 자체 인프라에서 안정적으로 배포할 선택지가 필요합니다.
배포 이력이 사람의 기억과 채팅 로그에 남습니다. 서버별 역할과 배포 대상이 문서화되지 않으면 장애 대응이 매번 처음부터 시작됩니다.
JejuCD는 Kubernetes의 대체재가 아니라, Kubernetes를 도입하기 전 단계 또는 Kubernetes가 과한 조직을 위한 실용적인 GitOps CD입니다.
무거운 컨테이너 런타임이나 오케스트레이터를 전제하지 않습니다. Rust 기반 경량 Agent가 각 서버에서 배포와 실행 환경 설정을 적용합니다.
배포 대상과 애플리케이션 상태는 Git에 명시적으로 선언됩니다. 앱이 원하는 environment·role·tag·node name 조건과 서버가 선언한 조건이 함께 맞을 때만 배포됩니다.
각 서버는 자신에게 해당하는 상태만 기준으로 동작합니다. 특정 서버의 설정 오류가 다른 서버로 번지는 범위를 줄입니다.
Manager가 Git의 원하는 상태(desired state)를 읽고 차이를 계산하면, 각 서버의 Agent가 자신에게 해당하는 설정만 적용합니다.
Git 저장소의 TOML 파일에 서버와 애플리케이션 상태를 선언합니다.
Manager가 Git 변경 사항을 읽고 필요한 상태 차이를 계산합니다.
각 서버의 Agent는 자신에게 해당하는 설정만 골라 적용합니다.
필요한 아티팩트를 내려받고 systemd·Nginx·런타임 설정을 안전하게 반영합니다.
앱이 원하는 배포 조건과 서버가 선언한 역할·태그가 함께 맞을 때만 배포됩니다.
SSH 접속 · 수동 업로드와 재시작
Git 커밋을 기준으로 Agent가 자동 동기화
채팅 로그와 담당자 기억에 의존
Git 히스토리에 선언 상태로 남음
어느 서버에 무엇이 올라갔는지 불분명
역할·태그로 배포 대상이 명시적으로 결정
Kubernetes 전문 인력 필요
기존 Linux · systemd 운영 방식 그대로
PaaS · 대형 클라우드 종속
보유한 VM · EC2 · 물리 서버 · 엣지 장비 활용
외부 SaaS 배포 파이프라인 사용 불가
온프레미스 · 폐쇄망 전제로 동작
Manager와 Agent 두 구성으로 동작하며, 이미 운영 중인 Linux 서버와 systemd 기반 운영 방식에 맞춰 배포합니다.
graph LR
Git Repository --(desired state)--> JejuCD Manager
JejuCD Manager --(state sync)----> JejuCD Agent
JejuCD Agent --(download)------> App Artifacts
JejuCD Agent --(apply config)--> systemd / Nginx / Runtime → ApplicationJejuCD는 현재 초기 개발 단계의 제품입니다. 제품 방향은 특정 실행 파일 형식에 한정되지 않는 "애플리케이션 아티팩트 배포"이며, 현재는 바이너리 배포가 주요 사용 사례입니다.
서버 구성을 바꾸지 않고 Agent만 설치해, 지금 운영 중인 애플리케이션 하나를 Git 선언 기준으로 옮깁니다. 배포 이력과 롤백 기준이 생기는 것만으로 운영 위험이 크게 줄어듭니다.
GitOps 운영 방식이 조직에 맞는지 먼저 확인합니다. 이후 규모가 커져 Kubernetes가 필요해지면, 이미 선언형으로 정리된 배포 기준을 그대로 옮겨갈 수 있습니다.
현재 서버 구성과 배포 절차를 함께 정리합니다. GitOps로 옮길 첫 대상을 정하는 단계입니다.
애플리케이션 하나를 TOML로 선언하고 Agent를 설치해 실제 배포와 동기화를 확인합니다.
검증된 범위를 서버와 서비스 단위로 넓힙니다. 폐쇄망 배포와 운영 정책은 함께 설계합니다.
Argo CD는 Kubernetes를 전제로 합니다. JejuCD는 Kubernetes 없이 VM·물리 서버·엣지 장비에 애플리케이션 아티팩트를 직접 배포하면서, Git 선언 상태를 기준으로 동기화하는 GitOps 방식만 가져옵니다.
대체재라기보다 Kubernetes 도입 전 단계 또는 Kubernetes가 과한 조직을 위한 도구입니다. 규모가 커지면 Kubernetes로 이동하는 경로를 막지 않습니다.
폐쇄망·온프레미스·공장·병원·금융권 하청·엣지 서버처럼 외부 클라우드 사용이 어려운 환경을 주요 대상으로 설계했습니다. 아티팩트 저장소 위치와 네트워크 경로는 도입 진단에서 함께 설계합니다.
기존 VM·EC2·물리 서버를 그대로 활용하는 것을 목표로 합니다. 이미 운영 중인 Linux 서버와 systemd 기반 방식에 맞춰 동작합니다.
현재 초기 개발 단계이며, 개발 과정과 사용자 피드백에 따라 기능과 구조가 변경될 수 있습니다. CloudBro는 이 단계의 오픈소스를 조직에 맞게 검증·도입하고, 문제가 생겼을 때 대응하는 주체를 더합니다.
두 개 이상 해당한다면, 30분 진단에서 확인할 가치가 충분합니다.
배포를 아직 SSH로 수동 처리하고 있습니다
Kubernetes는 조직 규모에 과하다고 판단됩니다
PaaS 비용과 종속을 줄여야 합니다
폐쇄망 · 온프레미스 · 엣지 환경에 배포합니다
어느 서버에 무엇이 올라갔는지 추적이 어렵습니다
배포 이력과 롤백 기준이 문서로 남지 않습니다
항목을 눌러 확인해 보세요
지금 어떤 서버에 어떤 방식으로 배포하고 있는지 알려 주시면, JejuCD로 옮겼을 때의 그림을 만들어 드립니다.