본문 바로가기
IT/Cloud

[DevOps] Argo CD vs Spinnaker: CI/CD 파이프라인 구축 비교 분석

by 수누다 2026. 7. 20.
반응형

[DevOps] Argo CD vs Spinnaker: CI/CD 파이프라인 구축 비교 분석

제가 현업이랑 홈랩에서 이것저것 굴려보면서 느낀 게 하나 있습니다. Argo CD Spinnaker 비교는 단순히 "어느 툴이 더 좋냐"의 문제가 아니더라고요. 팀이 Kubernetes를 어디까지 표준으로 쓰고 있는지, 배포 승인을 얼마나 엄격하게 가져가는지, 그리고 운영자가 원하는 가시성(visibility)이 어느 정도인지에 따라 답이 꽤 달라집니다. CI/CD 파이프라인을 처음 설계할 때 이 부분을 대충 잡고 들어가면, 나중에 배포 흐름이 꼬여서 삽질 좀 하게 됩니다 ㅎㅎ

특히 지속적 배포(Continuous Delivery)를 도입하려는 팀이라면 더 그렇습니다. 처음엔 저도 "둘 다 배포 툴 아닌가?" 싶었는데, 실제로 써보니까 운영 철학이 꽤 다르더라고요. 오늘은 클라우드 네이티브 환경에서 Argo CD와 Spinnaker를 어떻게 봐야 하는지, 어디서 갈리는지, 실전에서는 어떻게 접근하면 되는지를 경험 섞어서 정리해보겠습니다.

Argo CD Spinnaker 비교 아키텍처 다이어그램

Argo CD의 GitOps 흐름과 Spinnaker의 파이프라인 중심 배포 흐름을 한 장으로 비교하는 개요 이미지입니다.

1. 왜 Argo CD vs Spinnaker 비교가 중요한가

배포 자동화는 이제 선택이 아니라 기본이죠. 그런데 자동화라고 다 같은 자동화가 아닙니다. 어떤 팀은 Git 저장소만 바꾸면 자동 반영되는 구조가 편하고, 어떤 팀은 승인 단계, 카나리 배포(일부 트래픽만 먼저 보내는 배포), 멀티 클라우드 전략이 더 중요하거든요.

여기서 중요한 포인트가 있습니다. Argo CD는 GitOps(Git을 단일 진실 원본으로 삼는 운영 방식)에 굉장히 강한 도구이고, Spinnaker는 복잡한 배포 파이프라인과 멀티 클라우드 전달 흐름에 강한 플랫폼이라는 점입니다. 이 차이를 모르고 고르면, 도입 초반엔 쉬워 보여도 운영이 무거워지거나 반대로 필요한 통제가 안 붙는 상황이 생깁니다.

  • Git 변경 기반 자동 동기화가 중요하다면 Argo CD 쪽이 잘 맞습니다.
  • 복수 환경 승인, 배포 전략, 외부 시스템 연동이 많다면 Spinnaker가 더 자연스럽습니다.
  • Kubernetes 중심인지, 여러 배포 타깃이 섞여 있는지도 판단 기준입니다.

2. 개념부터 쉽게: Argo CD와 Spinnaker는 어떻게 다를까

2-1. Argo CD: 선언형 배포와 GitOps 중심

쉽게 말해 Argo CD는 "클러스터 상태는 Git에 적어둔 그대로여야 한다"는 철학으로 움직입니다. Git 저장소 안의 YAML 매니페스트(manifest, 리소스 정의 파일)나 Helm 차트(Chart, 쿠버네티스 패키지)를 보고, 실제 클러스터 상태와 비교한 뒤 차이가 있으면 맞춰주는 방식이죠.

제가 직접 해보니 이 방식의 장점은 정말 명확했습니다. 배포 이력이 Git 커밋으로 남고, 누가 뭘 바꿨는지 추적하기가 편합니다. 드리프트(drift, 선언한 상태와 실제 상태가 어긋나는 현상)도 눈에 잘 보이고요. 대신 애플리케이션 전달 과정 전체를 설계하는 엔진이라기보다는, Kubernetes 배포 상태를 Git 기준으로 맞추는 데 최적화된 도구에 가깝습니다.

2-2. Spinnaker: 파이프라인 오케스트레이션 중심

Spinnaker는 접근이 조금 다릅니다. 이쪽은 "어떤 조건에서 어떤 순서로 배포를 진행할지"를 세밀하게 다루는 데 강합니다. 예를 들면 빌드 완료 후 테스트 실행, 승인, 스테이징 배포, 카나리 분석, 운영 반영 같은 흐름을 하나의 파이프라인으로 묶는 식이죠.

처음엔 이게 뭔가 싶었는데, 실제로 써보니까 대규모 환경이나 규정이 많은 조직에서 왜 Spinnaker를 선호하는지 이해가 되더라고요. 반면 구성 요소가 많고 운영 복잡도도 꽤 있습니다. 작은 팀이 가볍게 시작하기엔 다소 무겁다고 느낄 수 있습니다.

2-3. 핵심 차이 한눈에 보기

항목 Argo CD Spinnaker
핵심 철학 GitOps 기반 선언형 동기화 파이프라인 기반 지속적 배포
주요 타깃 Kubernetes 중심 멀티 클라우드 및 다양한 배포 전략
운영 복잡도 상대적으로 단순 상대적으로 높음
강점 상태 일치, 변경 추적, Git 연동 승인 흐름, 카나리, 복합 파이프라인
적합한 팀 플랫폼 표준이 Kubernetes인 팀 배포 정책과 절차가 복잡한 팀

3. 어떤 팀에 어떤 도구가 맞는가

이 부분은 제가 후배들한테도 자주 이야기하는데요, 도구를 고를 때 기능 목록보다 운영 모델을 먼저 봐야 합니다.

  • Argo CD가 잘 맞는 경우: Git 기반 운영을 표준화하고 싶을 때, Kubernetes 리소스가 배포의 중심일 때, 운영 단순성이 중요할 때
  • Spinnaker가 잘 맞는 경우: 승인 단계가 많을 때, 여러 클라우드나 배포 전략을 함께 다룰 때, 파이프라인 오케스트레이션이 핵심일 때
  • 둘을 함께 보는 경우: CI는 다른 툴에서 처리하고, CD만 역할 분리해서 설계할 때

사실 Argo CD Spinnaker 비교에서 제일 많이 놓치는 지점이 여기입니다. 둘은 완전히 같은 문제를 푸는 경쟁 제품이라기보다, 겹치는 영역이 있으면서도 중심축이 다른 도구라고 보는 게 더 정확합니다.

4. 실전 구현: Argo CD로 GitOps형 CI/CD 파이프라인 구성

먼저 Argo CD 쪽부터 보겠습니다. 홈랩에서 테스트할 때 저는 보통 "애플리케이션 매니페스트를 Git에 넣고, Argo CD가 자동 동기화하게 만드는 흐름"으로 검증합니다. 이 구조는 이해도 쉽고, 실무 전환도 빠르거든요.

4-1. Argo CD 설치

  1. 전용 네임스페이스(namespace, Kubernetes 논리 분리 공간)를 만듭니다.
  2. 공식 설치 매니페스트를 적용합니다.
  3. 초기 관리자 비밀번호를 확인하고 UI에 접속합니다.
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
kubectl get pods -n argocd
kubectl port-forward svc/argocd-server -n argocd 8080:443

여기서 저는 처음에 포트포워딩(port-forwarding, 로컬 포트를 클러스터 서비스에 연결)만 열어놓고 왜 접속이 불안정하지 싶었는데, 로컬 브라우저 인증서 경고를 그냥 넘기지 않아서 그런 경우가 있더라고요. 사소한데 은근 많이 막힙니다.

4-2. Git 저장소에 애플리케이션 매니페스트 준비

Argo CD의 핵심은 Git이기 때문에, 배포 대상 매니페스트가 먼저 있어야 합니다. 가장 단순한 Deployment(디플로이먼트, 파드 복제와 롤링 업데이트 관리)와 Service(서비스, 네트워크 노출 객체) 예시는 아래처럼 둘 수 있습니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-nginx
  namespace: demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: demo-nginx
  template:
    metadata:
      labels:
        app: demo-nginx
    spec:
      containers:
        - name: nginx
          image: nginx:stable
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: demo-nginx
  namespace: demo
spec:
  selector:
    app: demo-nginx
  ports:
    - port: 80
      targetPort: 80

4-3. Argo CD Application 리소스 생성

이제 Argo CD에 "어느 Git 저장소의 어느 경로를 어느 클러스터 네임스페이스에 반영할지" 알려주면 됩니다. 이 리소스가 사실상 배포 선언문 역할을 합니다.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: demo-nginx
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/example-org/example-manifests.git
    targetRevision: main
    path: apps/demo-nginx
  destination:
    server: https://kubernetes.default.svc
    namespace: demo
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
kubectl apply -f application.yaml
kubectl get applications -n argocd
Argo CD Spinnaker 비교 중 Argo CD 동기화 설정 화면

Git 저장소 경로, 대상 네임스페이스, 자동 동기화 옵션이 설정된 Argo CD Application 화면을 보여주는 위치입니다.

여기서 prune은 Git에서 제거된 리소스를 클러스터에서도 정리하는 옵션이고, selfHeal은 누군가 클러스터에서 수동 변경해도 Git 기준으로 다시 되돌리는 기능입니다. 이거 진짜 편하더라고요. 운영자가 많아질수록 체감됩니다.

5. 실전 구현: Spinnaker로 파이프라인 중심 배포 설계

이번엔 Spinnaker 관점입니다. Spinnaker는 단순히 매니페스트를 맞추는 느낌보다, 배포 절차를 단계적으로 묶는 쪽에 가깝습니다. 그래서 예시도 "배포 흐름 설계" 관점으로 보는 게 이해가 쉽습니다.

5-1. 추천 파이프라인 흐름

  1. CI 도구에서 이미지 빌드 및 레지스트리 푸시
  2. Spinnaker가 새 이미지 태그 감지
  3. 스테이징 환경 배포
  4. 수동 승인(Manual Judgment)
  5. 운영 환경 반영

Spinnaker의 장점은 바로 이 지점입니다. 예를 들어 조직 정책상 운영 배포 전에 승인 절차가 꼭 필요하다면, Argo CD만으로는 별도 설계가 필요했던 부분을 Spinnaker는 비교적 자연스럽게 파이프라인에 녹일 수 있습니다.

5-2. 파이프라인 단계 예시

단계 설명 운영 포인트
Trigger 이미지 변경 또는 이벤트 감지 CI와 연결 구조를 명확히 해야 함
Deploy to Staging 스테이징 환경 우선 배포 운영과 최대한 동일한 조건 유지
Manual Judgment 사람 승인 후 다음 단계 진행 승인 기준을 문서화해야 혼선이 적음
Deploy to Prod 운영 환경 반영 롤백 기준과 모니터링 연동 중요

실제로 써보니까 Spinnaker는 "배포 파이프라인을 플랫폼 차원에서 관리하고 싶다"는 팀에 꽤 매력적입니다. 대신 구성요소가 많아서 관리 비용이 올라갑니다. 작은 팀이면 이 장점이 부담으로 바뀌기도 하더라고요.

6. ⚠️ 주의사항과 트러블슈팅: 제가 실제로 많이 부딪힌 포인트

6-1. Argo CD에서 자주 겪는 문제

  • 드리프트 오해: 운영자가 클러스터에서 급한 수정 후 Git 반영을 빼먹으면 Argo CD가 다시 덮어씁니다.
  • 권한 문제: 네임스페이스 생성이나 특정 리소스 적용 시 RBAC(Role-Based Access Control, 역할 기반 권한 제어) 때문에 막히는 경우가 많습니다.
  • Helm 값 충돌: values 파일과 환경별 override가 섞이면 실제 반영값 추적이 어려워집니다.

저도 처음엔 selfHeal이 멋져 보여서 다 켜놨었는데, 운영자가 수동 조치한 내용을 바로 되돌려버려서 당황한 적이 있습니다. 그래서 지금은 긴급 변경은 Git에 먼저 반영이라는 팀 규칙을 꼭 같이 둡니다.

6-2. Spinnaker에서 자주 겪는 문제

  • 구성 복잡도: 서비스 수와 설정 포인트가 많아 초반 진입장벽이 있습니다.
  • 파이프라인 관리 비용: 애플리케이션이 늘어나면 표준화하지 않은 파이프라인이 금방 복잡해집니다.
  • 운영 관찰성 확보: 어느 단계에서 실패했는지 추적하려면 로그와 모니터링 체계를 같이 잡아야 합니다.

근데 여기서 중요한 포인트! Spinnaker 자체가 나쁘다는 뜻이 아니라, 요구사항보다 플랫폼이 더 커지면 운영 피로도가 급격히 올라간다는 이야기입니다. 특히 팀 규모가 작을수록요.

Argo CD Spinnaker 비교를 위한 배포 파이프라인 승인 흐름 이미지

스테이징 배포, 수동 승인, 운영 반영으로 이어지는 Spinnaker 스타일의 파이프라인 흐름을 설명하는 이미지입니다.

7. 검증과 결과: 어떤 선택이 더 현실적이었나

제가 여러 환경에서 비교해보니 결과는 꽤 분명했습니다. Kubernetes가 배포 표준이고, Git 중심 운영 문화를 만들고 싶다면 Argo CD가 훨씬 빠르게 자리 잡습니다. 반대로 배포 절차가 길고 승인, 검증, 단계별 제어가 중요하다면 Spinnaker가 더 잘 맞습니다.

검증할 때는 보통 아래 항목을 봤습니다.

  1. Git 변경 후 실제 반영까지 흐름이 단순한가
  2. 실패했을 때 원인 추적이 쉬운가
  3. 롤백(rollback, 이전 정상 상태로 되돌리기)이 명확한가
  4. 운영자 수가 늘어도 관리 규칙이 유지되는가

Argo CD는 상태 비교가 직관적이라 운영 중 안심이 되더라고요. 반면 Spinnaker는 파이프라인 단계가 많을수록 통제력은 좋지만, 초반 설계 퀄리티가 정말 중요했습니다. 이건 진짜 경험 차이입니다.

kubectl get applications -n argocd
kubectl get pods -n demo
kubectl rollout status deployment/demo-nginx -n demo

위 명령으로 Argo CD 애플리케이션 상태, 실제 파드 상태, 롤아웃 완료 여부를 확인할 수 있습니다. 지속적 배포 환경에서는 "배포했다"보다 "원하는 상태로 수렴했는가"를 보는 게 더 중요하거든요.

Argo CD Spinnaker 비교 결과를 보여주는 배포 검증 대시보드

애플리케이션이 Synced, Healthy 상태인지와 실제 배포 결과를 함께 보여주는 검증용 이미지 자리입니다.

8. Argo CD vs Spinnaker 최종 정리

질문 추천
우리는 Kubernetes 중심으로 단순하고 강한 CD가 필요한가? Argo CD
GitOps 운영 모델을 팀 표준으로 만들고 싶은가? Argo CD
승인, 카나리, 복합 배포 절차가 핵심인가? Spinnaker
멀티 환경과 복잡한 전달 흐름을 한 플랫폼에서 통제하고 싶은가? Spinnaker

짧게 정리하면 이렇습니다. Argo CD는 "원하는 상태를 Git에 적고 맞춰나가는 도구"이고, Spinnaker는 "배포 절차를 정교하게 설계하고 흘려보내는 플랫폼"입니다. 둘 다 훌륭하지만, 잘 맞는 환경이 다릅니다.

혹시 이런 경험 있으신가요? 배포 자동화를 시작했는데, CI/CD 파이프라인이 오히려 더 복잡해져서 손이 더 많이 가는 상황이요. 저도 처음엔 헷갈렸는데, 결국 답은 기능 수보다 운영 방식에 있었습니다.

Argo CD Spinnaker 비교 선택 기준 요약 인포그래픽

팀 규모, Kubernetes 의존도, 승인 절차 복잡도에 따라 어떤 도구가 맞는지 요약한 비교 인포그래픽입니다.

9. 마무리: 지금 시작한다면 저는 이렇게 고릅니다

만약 지금 새로 시작하는 팀이고, 이미 Kubernetes를 기본 플랫폼으로 쓰고 있다면 저는 Argo CD부터 검토할 것 같습니다. 이유는 분명합니다. 도입 속도가 빠르고, GitOps 문화를 만들기 좋고, 운영 단순성도 꽤 좋거든요.

반대로 조직 규모가 크고, 배포 승인과 전달 절차가 중요한 팀이라면 Spinnaker 쪽이 더 설득력 있습니다. 다만 이 경우엔 플랫폼 운영 책임까지 함께 고려해야 합니다. 단순히 배포 기능만 보고 들어가면 나중에 힘들 수 있습니다.

다음 글에서는 Argo CD 기반으로 CI와 CD를 분리해서 운영하는 패턴, 예를 들어 GitHub Actions 같은 CI 도구와 연결하는 방식도 다뤄볼 예정입니다. 이전 글에서 다뤘던 Kubernetes 배포 기본 흐름과 함께 보시면 더 이해가 잘 되실 겁니다.

자주 묻는 질문

Argo CD가 CI까지 대체하나요?

보통은 아닙니다. Argo CD는 CD에 더 가깝고, 빌드와 테스트는 별도 CI 도구가 맡는 경우가 많습니다.

Spinnaker는 Kubernetes 환경에서만 쓰나요?

아닙니다. 다만 이 글에서는 클라우드 네이티브와 Kubernetes 중심 관점에서 설명했습니다.

둘 중 하나만 꼭 골라야 하나요?

반드시 그렇진 않습니다. 팀 구조와 기존 플랫폼에 따라 역할을 나눠 설계하는 경우도 있습니다.

반응형