[수요 조사] 컨테이너(K8s) 없이 GitOps 방식으로 바이너리를 배포하는 에이전트 툴, 수요가 있을까요?

안녕하세요.

현재 클라우드 네이티브 생태계에서는 Kubernetes와 ArgoCD 등을 활용한 GitOps 패턴이 표준처럼 자리 잡았습니다. 하지만 모든 워크로드가 컨테이너 기반인 것은 아니며, 때로는 순수 VM이나 베어메탈 환경에 직접 애플리케이션 바이너리(JAR, Node.js, Rust 실행 파일 등)를 배포해야 하는 경우가 여전히 많습니다.

기존의 SSH Push 방식(스크립트, Ansible 등)에서 벗어나, 순수 바이너리/VM 배포 환경에서도 선언적(Declarative) GitOps와 Reconciliation Loop(상태 조정 루프)를 적용할 수 있는 오픈소스 배포 툴(가칭: JejuCD)을 Rust로 개발하려고 기획 중입니다.

본격적인 개발에 앞서 커뮤니티 현업 엔지니어분들의 의견을 듣고 싶어 글을 올립니다.

핵심 아키텍처 및 기능 (기획안)

  • Manager - Worker 구조 (Pull 기반): 대상 서버에 가벼운 Rust 기반 에이전트(Worker)를 띄우고, 중앙 Manager의 REST API (혹은 grpc 를 활용) 폴링하여 상태를 가져옵니다. 타겟 서버로의 Inbound SSH 오픈이 필요 없어 보안상 유리합니다.

  • 선언적 상태 조정 (Reconciliation Loop): 주기적으로 Git에 정의된 TOML/JSON 설정(Desired State)과 현재 서버 상태(Actual State)를 비교합니다. 누군가 서버 설정을 임의로 바꾸는 드리프트(Drift)가 발생하면 자동으로 원래 상태로 복구합니다. (CI Webhook 연동 시 즉시 배포 트리거 가능)

여쭤보고 싶은 점

  1. K8s가 아닌 환경에서 배포를 관리하실 때, 이러한 Pull-base 형태의 GitOps 에이전트가 도입된다면 기존 페인포인트를 해결하는 데 유용할까요?

  2. 만약 이런 툴이 있다면 가장 기대되는 기능이나 반대로 가장 우려되는 점(예: 에이전트 자체의 리소스나 관리 부담)은 무엇인지 궁금합니다.

가벼운 피드백, 뼈 때리는 비판 모두 프로젝트 방향성을 잡는 데 큰 도움이 될 것 같습니다. 긴 글 읽어주셔서 감사합니다!

4 Likes