[수요 조사] 컨테이너(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. 만약 이런 툴이 있다면 가장 기대되는 기능이나 반대로 가장 우려되는 점(예: 에이전트 자체의 리소스나 관리 부담)은 무엇인지 궁금합니다.

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

6 Likes

기획이 완벽했던 탓일까… 조용히 뷰는 올라가는데 의견이 없군요 :thinking:

개인적으로 답변이 궁금한 1인…!

안녕하세요. 저는 중앙 AWX를 통해 Ansible로 각종 데이터베이스들을 VM에 프로비저닝하고 있습니다.

  • AWX에서 주기적(Schedule)로 Dry-Run을 통해 상태 체크
  • changed가 감지되면 실제 배포 실행

1. 저는 Pull/Push 방식은 크게 연연하지는 않을 것 같고, Desired/Actual 상태를 잘 감지할 수 있는지가 주요 관심사입니다.

Ansible은 여러 기본/커뮤니티 모듈들이 있고 changed_when/failed_when 등을 통해 상태 감지를 세밀하게 조정할 수 있습니다.

히스토리도 잘 축적되어 있어서 최근에는 LLM을 통해 멀티 샤드 ClickHouse 플레이북을 빠르게 작성할 수 있었습니다.

그럼에도 Ansible은 ssh 기반이라서, 스텝 서버 구성에 신경써야 하는 단점이 있습니다.

2. ssh가 아닌 https/gRPC 기반을 통해 초기 구성 및 보안 부담을 줄일 수 있다면 좋을 것 같습니다.

또한 상태 감지와 리컨사일 로직을 작성하는 데 있어서, Ansible이나 k8s Operator 패턴 수준의 유연성을 제공할 수 있다면 좋겠습니다!

1 Like