ArgoCD vs Flux, 1년씩 써보고 우리 팀이 고른 것

GitOps 도구 고민은 의외로 끝나지 않는다. 작년 이맘때 우리 팀은 ArgoCD를 쓰고 있었는데, 어쩌다보니 한 분기를 Flux로 갈아엎고 돌렸다가 결국 다시 ArgoCD로 돌아왔다. 비교 글은 인터넷에 차고 넘치지만, 둘 다 운영 환경에서 한 사이클씩 굴려본 입장에서 쓸 만한 글은 의외로 적었다. 그래서 정리해본다.

전제부터 깔자. 우리 팀은 EKS 클러스터 7개(prod 3, staging 2, dev 2), 약 220개 마이크로서비스, 배포는 하루 평균 60건쯤이다. 큰 조직은 아니지만 작지도 않다. 이 규모에서 우리가 겪은 차이를 적는다.

왜 갈아탔다가 다시 돌아왔나

원래 ArgoCD 2.10대를 1년 정도 잘 쓰고 있었다. 그런데 ApplicationSet generator 설정이 점점 비대해지고, 멀티 클러스터 부트스트랩이 깔끔하지 않다는 불만이 누적됐다. 마침 Flux 2.6쯤 나오면서 "이거 진짜 토킷처럼 모듈러하다"는 평이 많아져서 한번 옮겨봤다.

3개월쯤 운영해봤다. 결론부터 말하면, Flux 자체는 좋다. 문제는 우리 팀이었다.

Flux는 철학이 분명하다. Kustomize, Helm Controller, Image Update Automation, Notification Controller 같은 컴포넌트를 따로따로 조립하는 구조다. 토킷 철학이라고 부른다. 각 컨트롤러가 독립 CRD로 동작하니 책임 분리가 깨끗하다.

근데 우리 팀 신규 입사자가 "내 서비스가 왜 배포 안 되나요"라고 물었을 때, 답을 찾으려면 flux get kustomizations, flux get sources, flux get helmreleases, 거기에 kubectl로 각 CR 상태까지 따로 봐야 한다. UI가 없으니 CLI 의존도가 커진다. Weave GitOps 같은 서드파티 대시보드가 있긴 한데, 우리가 써본 시점 기준으론 ArgoCD UI만큼 매끈하지 않았다.

반면 ArgoCD는 처음부터 끝까지 한 화면에서 본다. 신규 입사자가 와서 30분이면 "내 서비스 상태"를 찾는다. 우리 팀처럼 옆에서 도와줄 시니어가 항상 붙어있지 못한 환경에서는 이 차이가 크다.

리소스 사용량은 솔직히 Flux 승

이건 Flux를 변호하고 싶다. Flux가 가볍다. 초기 sync 시점 기준으로 ArgoCD가 대략 두 배쯤 CPU/메모리를 쓴다. 안정 상태에서는 격차가 줄지만 여전히 의미 있는 차이다.

우리가 측정해본 수치:

항목	ArgoCD 3.2	Flux 2.6
컨트롤러 메모리 (정상)	1.8GB	750MB
초기 sync 피크 CPU	1.4 core	0.6 core
220 Application 부트스트랩 시간	8분 30초	4분 50초

작은 클러스터, 비용에 민감한 환경이면 Flux가 충분히 매력적이다. 우리가 다시 ArgoCD로 돌아온 이유에 "비용"은 들어가지 않았다.

ApplicationSet vs Kustomization generator

이게 결정타였다. 멀티 클러스터, 멀티 환경에서 같은 앱을 약간씩 다르게 배포해야 하는 패턴.

ArgoCD ApplicationSet의 generator는 처음엔 헷갈리지만 익숙해지면 강력하다. List, Cluster, Git, Matrix, Merge generator를 조합해서 "prod 클러스터 3개에 같은 앱을, 단 도메인은 다르게" 같은 요구를 한 manifest로 푼다.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: api-gateway
spec:
  generators:
  - matrix:
      generators:
      - clusters:
          selector:
            matchLabels:
              env: prod
      - list:
          elements:
          - region: ap-northeast-2
          - region: us-east-1
  template:
    metadata:
      name: '{{name}}-{{region}}-gateway'
    spec:
      project: platform
      source:
        repoURL: https://github.com/our-org/manifests
        targetRevision: HEAD
        path: 'gateways/{{region}}'
        helm:
          values: |
            cluster: {{name}}
            region: {{region}}
      destination:
        server: '{{server}}'
        namespace: gateway

Flux에서 같은 걸 하려면 Kustomization을 여러 개 만들거나, 우리는 Terraform/Pulumi에서 manifest를 생성하는 식으로 풀었다. 깨끗하긴 한데, Git 리포에 manifest 수가 클러스터 수만큼 늘어난다. 우리 팀 규모에서는 "manifest 폭증" 쪽이 더 골치 아팠다.

Drift detection — 이건 의외로 비슷하다

처음엔 ArgoCD의 OutOfSync 표시가 더 직관적이라고 생각했는데, 실제 동작은 비슷하다. 둘 다 desired state와 actual state 비교해서 reconcile한다.

차이는 "사용자에게 보여주는 방식"이다. ArgoCD는 UI에서 빨간 점으로 깜빡거리고 diff까지 눌러서 본다. Flux는 flux diff 명령으로 본다. 정보의 양은 같다. 시각화의 차이.

우리 팀은 새벽에 누가 hotfix로 kubectl edit 해놓고 PR 안 올린 케이스를 잡을 때, ArgoCD UI에서 한눈에 보이는 게 도움이 됐다. CLI를 안 켜고도 누가 뭘 건드렸는지 보인다.

Helm 통합

Helm은 양쪽 다 지원하는데 동작 방식이 다르다.

ArgoCD는 helm template을 내부적으로 돌려서 정적 manifest로 변환한 뒤 적용한다. Helm Release는 ArgoCD가 알지 못한다. helm list 했을 때 안 보인다. 이게 처음엔 좀 당황스럽지만 운영해보면 일관된 GitOps 흐름에는 더 맞다.

Flux는 HelmController가 진짜 Helm Release를 만든다. helm list -n foo 하면 정상적으로 보인다. 기존 Helm 자산이 많은 조직이면 이 호환성이 매력적이다.

# Flux HelmRelease
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: redis
spec:
  interval: 5m
  chart:
    spec:
      chart: redis
      version: "20.x"
      sourceRef:
        kind: HelmRepository
        name: bitnami
  values:
    architecture: replication
    auth:
      enabled: true

이건 정답이 없다. 우리는 Helm release 추적을 외부 시스템(Backstage)에 통합할 일이 있어서 Flux 쪽이 더 깔끔했다. 다시 ArgoCD로 돌아온 뒤에는 그냥 ArgoCD Application 메타데이터로 통일했다.

최근 업데이트는 둘 다 활발하다

올해 초 ArgoCD 3.3이 나오면서 PreDelete Hook과 Source Hydrator가 개선됐다. Source Hydrator는 manifest를 hydration 단계와 sync 단계로 분리하는 패턴인데, GitOps Promoter 같은 도구와 조합하면 "PR 머지 → 자동 promotion" 흐름이 깔끔해진다. 우리는 아직 도입 안 했지만 큰 조직이면 진지하게 볼 만하다.

Flux 2.8은 image automation과 multi-tenancy 쪽이 좋아졌다. 특히 Notification Controller가 Slack/Teams 외에 다양한 webhook을 지원하면서 알림 파이프라인이 풍부해졌다.

KubeCon에서 양쪽 다 발표가 많았고, CNCF graduated 상태도 변함없다. 도구 선택 때문에 "사라질 위험"을 걱정할 단계는 둘 다 아니다.

그래서 우리는

다시 ArgoCD다. 이유를 짧게 정리하면:

1. UI가 신규 입사자 온보딩 속도를 진짜로 바꾼다
2. ApplicationSet generator로 멀티 클러스터 매트릭스를 manifest 폭증 없이 푼다
3. Argo Workflows, Argo Rollouts와 한 생태계라 트레이싱이 쉽다

근데 이게 "ArgoCD가 더 좋다"는 결론은 아니다. 우리 팀 맥락에서 그렇다는 거다. 만약 우리가 더 작은 팀이고, 모든 사람이 CLI 친숙하고, 비용에 매우 민감했다면 Flux가 답이었을 거다. 실제로 잘 굴러가는 팀들 많이 봤다.

도구 결정할 때 "기능 매트릭스 비교"만 보지 말고 "우리 팀이 누구를 어떻게 온보딩시키나"를 같이 봐야 한다는 게 1년의 결론이다.

혹시 비슷한 고민하시는 분, 둘 다 PoC로 한 분기씩 굴려보는 거 추천한다. 문서로 읽는 것과 운영해보는 건 다르다.