왜 우리 팀은 Argo Rollouts를 선택했나 — Flagger와 1년 비교 후기

 

출발점: 우리 환경

• ArgoCD 이미 운영 중 (2년 차)
• Istio 1.24, ambient mode는 일부 네임스페이스만
• 마이크로서비스 약 80개, 일주일 배포 횟수 평균 120건
• 옵저버빌리티는 Prometheus + Thanos + Grafana 조합

이 시점에서 Flux CD를 쓰고 있었다면 Flagger를 골랐을 가능성이 높다. 두 도구 모두 기술적으로 충분하지만, 같은 진영의 도구를 모으는 게 운영 단순도 측면에서 유리하다는 게 1년 후 더 분명해졌다.

매니페스트 마이그레이션 비용

Flagger의 가장 강력한 매력은 "기존 Deployment를 그대로 두고 Canary CR만 추가하면 된다"는 점이다. 처음 PoC 할 때 이게 정말 좋았다. 30분 만에 한 서비스가 카나리 배포로 전환됐다. 반면 Argo Rollouts는 Deployment를 Rollout CR로 바꿔야 한다. 즉, 80개 서비스를 다 마이그레이션해야 한다는 뜻이다.

근데 실제로 운영하다 보니 그 "마이그레이션 비용"은 일회성이다. 한 번 Rollout으로 바꿔두면 그 다음부터는 차이가 없다. 그리고 우리는 Helm chart 템플릿을 공통으로 관리하고 있어서, 차트 한 곳만 고치면 됐다. 결국 80개 서비스 전환에 2주 정도 걸렸다.

# 우리가 쓰는 Rollout 템플릿의 핵심 부분
apiVersion: argoproj.io/v1alpha1
kind: Rollout
spec:
  strategy:
    canary:
      canaryService: my-app-canary
      stableService: my-app-stable
      trafficRouting:
        istio:
          virtualService:
            name: my-app-vs
            routes:
            - primary
      steps:
      - setWeight: 5
      - pause: { duration: 2m }
      - analysis:
          templates:
          - templateName: success-rate
          args:
          - name: service-name
            value: my-app-canary
      - setWeight: 20
      - pause: { duration: 5m }
      - setWeight: 50
      - pause: { duration: 10m }

명시적인 step 정의가 처음엔 장황해 보였는데, 일반 개발자에게 "지금 이 배포가 어디까지 진행됐나"를 설명하기에는 압도적으로 명확하다. Flagger의 자동 진행은 한 줄짜리 설정으로 "이 분석 기준만 만족하면 알아서 진행해"라고 위임하는 거라서, 디버깅할 때 "왜 지금 멈췄지?" 같은 질문이 종종 나왔다.

분석 메트릭과 promotion gate

두 도구 모두 Prometheus 기반 분석을 잘 지원한다. 우리가 갈렸던 지점은 "수동 승인 게이트"였다.

Argo Rollouts는 pause: {} (duration 없음)을 넣으면 사람이 kubectl argo rollouts promote 칠 때까지 무한 대기다. 우리 팀은 신규 결제 도메인 배포에서 PM 승인을 받는 흐름이 있어서 이걸 자주 쓴다. Flagger에서도 webhook으로 외부 승인 시스템을 부를 수는 있지만, 흐름이 좀 더 복잡하다.

또 하나는 step별로 다른 분석 템플릿을 적용할 수 있다는 점. 5% 단계에서는 에러율만 보고, 20% 단계에서는 P99 레이턴시까지 보고, 50% 단계에서는 비즈니스 메트릭(주문 성공률 등)까지 본다. Flagger도 못 하는 건 아닌데, 우리 케이스에서는 Rollouts의 step별 명시적 정의가 더 깔끔했다.

UI의 가치

이건 처음에는 부차적이라고 생각했다. CLI랑 Grafana만 있으면 충분하다고. 1년 지나고 보니, Argo Rollouts UI(ArgoCD 플러그인으로 통합)가 비개발자 동료들이 배포 상태를 이해하는 데 결정적이었다. PM이 "지금 카나리 어디까지 갔어요?" 묻기 전에 본인이 직접 화면 보고 확인한다. 이 작은 UX가 운영 부담을 꽤 줄여줬다.

Flagger도 Grafana 대시보드 템플릿을 제공하긴 하지만, "실시간 배포 진행 상태"를 한 화면에서 보여주는 전용 UI는 없다.

Flagger가 더 나았을 법한 케이스

솔직히 모든 면에서 Rollouts가 우월하다는 건 아니다. 다음 경우에는 Flagger를 고려할 만하다:

• Flux CD를 메인으로 쓰는 팀
• Deployment 매니페스트를 외부 도구(예: Crossplane, Operator)가 자동 생성해서 우리가 손댈 수 없는 환경
• 카나리 분석 로직이 단순하고, 사람 개입 없이 끝까지 자동으로 가는 워크플로우가 80% 이상

특히 두 번째 케이스. 작년에 우리 팀 일부 서비스가 외부 Operator가 Deployment를 관리하던 시기가 있었는데, 거기는 Flagger를 임시로 썼다. Rollout CR로 바꾸려면 Operator 자체를 고쳐야 했기 때문이다.

운영 1년의 숫자

대략 이런 효과가 있었다:

• 카나리 배포 도입 전 prod 롤백 빈도: 주당 평균 4-5건
• 도입 후 6개월 시점: 주당 평균 1-2건
• 도입 후 12개월 시점: 주당 1건 미만 (대부분 카나리 단계에서 자동 abort)

물론 이게 다 Rollouts 덕분은 아니다. SLO 기반 알람, 자동화된 회귀 테스트, 코드 리뷰 문화 등 여러 개선이 동시에 진행됐다. 다만 카나리 분석에서 "5% 단계에서 에러율 0.5% 초과 시 자동 abort"가 실제로 trigger된 사례가 1년에 20건 가까이 됐다. 이 20건이 prod로 전부 갔으면 어땠을지를 생각하면 도구 선택이 헛돈은 아니었다.

정리

다시 처음으로 돌아가서, 결정 요인을 순서대로 적자면:

1. ArgoCD를 이미 쓰고 있음 → 같은 진영 도구 선호
2. 명시적 step 정의 + UI가 비개발자 커뮤니케이션에 유리
3. 수동 승인 게이트가 자주 필요한 도메인 존재
4. 매니페스트 마이그레이션 비용은 일회성이며, 우리는 감당 가능

이게 다른 팀에 그대로 적용될지는 모르겠다. Flux + Linkerd 환경이라면 Flagger가 훨씬 자연스러울 거다. 결국 카나리 도구는 기술 비교만으로 결정되지 않고, 주변 스택이 결정해버리는 경우가 많다는 게 1년의 교훈이다.

혹시 비슷한 결정을 앞두고 있는 분 있으면, 두 개 다 깔아서 한 달만 병행해보길 권한다. 문서로만 비교하면 절대 안 보이는 운영 디테일들이 그때 다 드러난다.