GitOps 도입을 위한 Argo CD와 쿠버네티스 연동 실전 가이드

Argo CD와 쿠버네티스를 활용한 GitOps 도입 경험을 공유합니다. 실제 적용 사례와 함께 CI/CD 파이프라인 구축 노하우를 상세히 안내합니다.

수많은 애플리케이션을 안정적으로 배포하고 관리하는 일, 늘 고민이셨죠? 특히 쿠버네티스 환경에서 복잡한 배포 과정을 효율적으로 자동화하는 것은 많은 개발팀의 숙제입니다. 저 역시 처음에는 스크립트와 수동 배포의 늪에서 헤매기도 했습니다. 하지만 GitOps 패러다임을 만나고, 특히 Argo CD를 도입하면서 이 모든 고민이 한결 가벼워졌습니다.

이 글에서는 제가 직접 GitOps를 도입하기 위해 Argo CD와 쿠버네티스를 연동했던 경험을 공유하고자 합니다. 단순히 개념 설명에 그치지 않고, 실제로 적용해 본 결과 얻게 된 노하우와 마주했던 문제들, 그리고 그 해결책까지 상세히 다룰 예정입니다. 이 가이드가 여러분의 GitOps 도입 여정에 실질적인 도움이 되기를 바랍니다.

📑 목차

• GitOps, 왜 도입해야 할까요? 기존 CI/CD 방식의 한계
• 기존 CI/CD 방식의 한계
• GitOps가 제시하는 새로운 패러다임
• Argo CD, GitOps 구현의 핵심 도구
• Argo CD는 무엇이며, 왜 선택했나
• Pull-based 방식의 이해
• 쿠버네티스 환경에 Argo CD 설치 및 기본 설정
• 필수 전제 조건 확인
• Argo CD 설치 명령어 및 초기 접속
• 첫 번째 애플리케이션 배포: Argo CD로 GitHub 레포 연동하기
• Git 레포지토리 연결
• Application 리소스 정의 및 배포
• Sync 정책 이해 및 활용
• 실제 운영에서 마주친 난관과 해결책
• Git 레포지토리 구조 설계의 중요성
• 네트워크 및 권한 문제 해결
• 헬름(Helm) 차트와의 연동 전략
• Argo CD 고급 기능 활용: 프로젝트, RBAC, Sync 훅
• 멀티테넌시를 위한 프로젝트 관리
• 역할 기반 접근 제어 (RBAC) 설정
• 배포 전후 작업 자동화 (Sync 훅)
• GitOps 도입, 그 후: 얻게 된 이점과 고려사항
• GitOps가 가져온 변화
• 성공적인 도입을 위한 조언

GitOps, 왜 도입해야 할까요? 기존 CI/CD 방식의 한계

클라우드 네이티브 환경으로 전환하면서 CI/CD(지속적 통합/지속적 배포) 파이프라인의 중요성은 더욱 커졌습니다. 하지만 기존의 푸시(Push) 기반 CI/CD 방식은 몇 가지 고질적인 문제점을 안고 있었습니다.

기존 CI/CD 방식의 한계

• 운영 환경과의 불일치(Configuration Drift): 개발자가 직접 스크립트를 통해 쿠버네티스 클러스터에 배포하다 보면, Git 저장소의 코드와 실제 클러스터의 상태가 달라지는 '환경 불일치'가 자주 발생합니다. 문제가 생겼을 때 원인을 파악하기 어렵고, 롤백도 복잡해집니다.
• 수동 개입 및 오류 가능성: 배포 과정에 수동적인 개입이 많아질수록 휴먼 에러의 가능성이 커집니다. 특히 복잡한 마이크로서비스 아키텍처에서는 작은 실수 하나가 전체 서비스에 치명적인 영향을 줄 수 있습니다.
• 보안 및 감사(Audit)의 어려움: 누가, 언제, 무엇을 배포했는지 추적하기 어렵습니다. 보안 사고 발생 시 감사 로그를 확보하기 어렵고, 책임 소재를 명확히 하기도 힘듭니다.
• 운영 복잡도 증가: 배포 스크립트가 점점 복잡해지고, 각 환경별로 달라지는 설정들을 관리하는 것이 큰 부담으로 다가옵니다.

GitOps가 제시하는 새로운 패러다임

이러한 한계들을 극복하기 위해 등장한 것이 바로 GitOps입니다. GitOps는 간단히 말해, '모든 운영 환경의 상태를 Git 저장소에 선언적으로 관리하고, Git 저장소의 변경 사항만이 실제 환경에 적용되도록 하는 운영 방식'입니다.

핵심 원칙은 다음과 같습니다.

• 선언적(Declarative): 시스템의 최종 상태를 Git에 선언적인 형태로 정의합니다. (예: 쿠버네티스 YAML, 헬름 차트)
• 버전 관리(Version-controlled): 모든 변경 사항은 Git에 커밋되어 버전 관리되며, 필요시 쉽게 롤백할 수 있습니다.
• 자동화(Automated): Git에 변경 사항이 푸시되면 자동으로 감지하여 실제 환경에 동기화합니다.
• 감사 가능(Auditable): Git 커밋 로그를 통해 모든 변경 이력을 추적할 수 있습니다.

GitOps를 도입하면 운영 환경의 신뢰성, 안정성, 가시성이 크게 향상됩니다. 마치 소프트웨어 개발처럼 인프라를 코드(IaC)로 관리하고, 배포 프로세스를 표준화할 수 있습니다. 저희 팀은 이 점에 큰 매력을 느껴 GitOps 도입을 결정했고, 그 핵심 도구로 Argo CD를 선택했습니다.

Argo CD, GitOps 구현의 핵심 도구

GitOps를 구현하기 위한 다양한 도구들이 있지만, 쿠버네티스 환경에서는 Argo CD가 가장 강력하고 널리 사용되는 도구 중 하나입니다. 실제로 사용해보니 그 명성을 실감할 수 있었습니다.

Argo CD는 무엇이며, 왜 선택했나

Argo CD는 쿠버네티스에 특화된 선언적(Declarative) GitOps 지속적 배포 도구입니다. 애플리케이션의 정의, 구성, 환경을 Git 저장소에 보관하고, Argo CD가 이 Git 저장소의 상태를 지속적으로 모니터링하여 쿠버네티스 클러스터의 실제 상태와 동기화합니다. 저희 팀이 Argo CD를 선택한 주된 이유는 다음과 같습니다.

• 쿠버네티스 네이티브: 쿠버네티스 API를 적극적으로 활용하며, CRD(Custom Resource Definition)를 통해 GitOps 워크플로우를 유연하게 정의할 수 있습니다.
• Pull-based 방식: 기존 CI/CD 도구처럼 클러스터에 명령을 '푸시'하는 방식이 아니라, Argo CD가 Git 저장소의 변경 사항을 '풀(Pull)'하여 클러스터에 '동기화'합니다. 이 방식은 보안 측면에서 유리하며, 클러스터의 의도된 상태를 유지하는 데 탁월합니다.
• 강력한 웹 UI: 배포된 애플리케이션의 상태, 동기화 여부, 로그 등을 한눈에 확인할 수 있는 직관적인 웹 UI를 제공합니다. 이는 운영 가시성을 크게 높여주었습니다.
• 자동 동기화 및 드리프트 감지: Git 저장소와 클러스터 간의 상태 불일치(Drift)를 자동으로 감지하고, 설정에 따라 자동으로 동기화하거나 알림을 보낼 수 있습니다.
• 다양한 배포 전략 지원: 헬름(Helm), Kustomize, 일반 YAML 등 다양한 배포 도구와 연동이 가능합니다.

Pull-based 방식의 이해

Argo CD의 핵심은 Pull-based 방식입니다. 기존 CI/CD 파이프라인은 Jenkins나 GitLab CI 같은 도구가 빌드 후 직접 `kubectl apply` 명령을 통해 쿠버네티스 클러스터에 변경 사항을 '푸시'했습니다. 이 방식은 CI/CD 도구가 클러스터에 대한 높은 권한을 가져야 하고, 네트워크 방화벽 설정도 복잡해질 수 있습니다.

반면, Argo CD는 클러스터 내부에 설치되어 Git 저장소를 주기적으로 '풀'하여 변경 사항을 감지합니다. 그리고 클러스터의 현재 상태와 Git 저장소의 의도된 상태를 비교하여 불일치가 발생하면 이를 동기화합니다. 아래 표를 통해 두 방식의 차이를 명확히 이해할 수 있습니다.

특징	Push-based CI/CD (예: Jenkins)	Pull-based GitOps (예: Argo CD)
배포 주체	외부 CI/CD 서버	클러스터 내부의 GitOps 에이전트 (Argo CD)
보안 모델	CI/CD 서버가 클러스터에 접근 권한 필요	클러스터 내부 에이전트가 Git에만 접근 (읽기 전용)
환경 불일치 감지	수동 확인 또는 추가 모니터링 도구 필요	Argo CD가 지속적으로 감지 및 보고/자동 동기화
가시성	CI/CD 로그에 의존, 클러스터 상태 파악 어려움	Argo CD UI를 통해 실시간 클러스터 상태 확인 용이
롤백 용이성	복잡하고 오류 발생 가능성 높음	Git 커밋 롤백만으로 간단하게 처리

쿠버네티스 환경에 Argo CD 설치 및 기본 설정

본격적으로 Argo CD를 쿠버네티스 클러스터에 설치하고 기본 설정을 해보겠습니다. 저는 EKS 클러스터를 사용했지만, 다른 어떤 쿠버네티스 클러스터에서도 동일하게 적용 가능합니다. 실제 운영 환경에서는 Helm 차트를 이용하는 것이 일반적이지만, 여기서는 가장 기본적인 YAML 파일을 이용한 설치를 기준으로 설명합니다.

필수 전제 조건 확인

설치를 시작하기 전에 다음 사항들을 준비해야 합니다.

• 작동하는 쿠버네티스 클러스터: `kubectl` 명령어를 통해 접근 가능한 클러스터가 필요합니다.
• `kubectl` CLI 도구: 클러스터에 명령을 보내기 위한 도구입니다.
• `argocd` CLI 도구 (선택 사항): 웹 UI뿐만 아니라 CLI를 통해서도 Argo CD를 관리할 수 있습니다. (설치 후 진행)

Argo CD 설치 명령어 및 초기 접속

설치는 매우 간단합니다. Argo CD는 자체적인 네임스페이스에 설치되는 것을 권장합니다.

# 1. argocd 네임스페이스 생성
kubectl create namespace argocd

# 2. Argo CD 설치 매니페스트 적용 (stable 버전 사용)
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# 3. 모든 Pod이 준비될 때까지 기다림
kubectl get po -n argocd -w

설치가 완료되면, Argo CD 서버에 접근해야 합니다. 외부에서 접근하기 위해 `kubectl port-forward`를 사용합니다. 실제 운영 환경에서는 Ingress나 LoadBalancer를 통해 서비스 노출하는 것이 일반적입니다.

# Argo CD 서버에 로컬 포트 포워딩 (8080 포트로 접근)
kubectl port-forward svc/argocd-server -n argocd 8080:443

이제 웹 브라우저에서 `https://localhost:8080`에 접속하면 Argo CD 로그인 화면을 볼 수 있습니다. 초기 사용자 이름은 `admin`이며, 초기 비밀번호는 다음 명령어로 얻을 수 있습니다.

# 초기 관리자 비밀번호 얻기
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo

로그인 후에는 반드시 비밀번호를 변경하는 것을 잊지 마세요. 웹 UI에서 `Settings > Users` 메뉴로 이동하여 `admin` 계정의 비밀번호를 변경할 수 있습니다. 저는 주로 CLI로 변경했습니다.

# Argo CD CLI 설치 (macOS 예시)
brew install argocd

# Argo CD 서버에 로그인 (admin 계정으로)
argocd login localhost:8080

# 비밀번호 변경
argocd account update-password

여기까지 완료했다면, Argo CD의 기본적인 설치와 접속이 성공적으로 이루어진 것입니다.

첫 번째 애플리케이션 배포: Argo CD로 GitHub 레포 연동하기

이제 Argo CD를 사용하여 Git 저장소의 애플리케이션을 쿠버네티스 클러스터에 배포해볼 차례입니다. 가장 기본적인 예제를 통해 Git 레포지토리 연동부터 Application 리소스 정의, 그리고 동기화 정책까지 알아보겠습니다.

Git 레포지토리 연결

Argo CD가 애플리케이션 매니페스트를 가져올 Git 저장소를 등록해야 합니다. 저는 테스트용으로 GitHub의 퍼블릭 저장소를 사용했습니다. 프라이빗 저장소의 경우 SSH 키나 토큰을 추가로 설정해야 합니다.

# Git 저장소 등록 (예시: 퍼블릭 저장소)
argocd repo add https://github.com/argoproj/argocd-example-apps.git

# 등록된 저장소 확인
argocd repo list

웹 UI의 `Settings > Repositories` 메뉴에서도 직접 추가할 수 있습니다. 등록이 완료되면 Argo CD는 해당 저장소를 모니터링할 준비가 됩니다.

Application 리소스 정의 및 배포

Argo CD에서 애플리케이션을 배포하려면 `Application`이라는 쿠버네티스 리소스를 정의해야 합니다. 이 리소스는 어떤 Git 저장소의 어떤 경로에 있는 매니페스트를, 어느 쿠버네티스 클러스터의 어떤 네임스페이스에 배포할 것인지를 선언합니다.

간단한 Nginx 애플리케이션을 배포하는 예시 `Application` YAML 파일을 만들어보겠습니다. 이 파일은 Argo CD가 설치된 네임스페이스에 배포되어야 합니다.

# app.yaml 파일 내용
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook-app
  namespace: argocd # Argo CD가 설치된 네임스페이스
spec:
  project: default # Argo CD 프로젝트 (기본값: default)
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps.git # 등록한 Git 저장소 URL
    targetRevision: HEAD # Git 브랜치 또는 태그 (HEAD는 master/main 브랜치)
    path: guestbook # Git 저장소 내 애플리케이션 매니페스트 경로
  destination:
    server: https://kubernetes.default.svc # 애플리케이션을 배포할 쿠버네티스 클러스터 (자체 클러스터)
    namespace: guestbook # 애플리케이션이 배포될 네임스페이스

  syncPolicy: # 동기화 정책
    automated: # 자동 동기화 설정
      prune: true # Git에 없는 리소스 삭제
      selfHeal: true # 클러스터 상태가 Git과 다르면 자동으로 복구
    syncOptions:
    - CreateNamespace=true # 대상 네임스페이스가 없으면 생성

위 파일을 `app.yaml`로 저장하고, 다음 명령어로 클러스터에 적용합니다.

kubectl apply -f app.yaml -n argocd

명령어를 실행하면 Argo CD가 `guestbook-app`이라는 Application 리소스를 인식하고, 지정된 Git 저장소의 `guestbook` 경로에 있는 매니페스트를 가져와 `guestbook` 네임스페이스에 배포하기 시작합니다. 웹 UI에서 `guestbook-app`이라는 애플리케이션이 생성되고, `Sync` 상태가 `Synced`로, `Health` 상태가 `Healthy`로 바뀌는 것을 확인할 수 있습니다. 직접 GitOps의 강력함을 경험하는 순간입니다!

Sync 정책 이해 및 활용

`syncPolicy`는 Argo CD의 핵심 기능 중 하나입니다. 위 예시에서는 `automated` 동기화를 설정했습니다.

• `automated.prune: true`: Git 저장소에서 제거된 리소스는 클러스터에서도 자동으로 삭제됩니다.
• `automated.selfHeal: true`: 만약 누군가 클러스터에서 수동으로 리소스를 변경하거나 삭제하면, Argo CD가 이를 감지하여 Git 저장소의 상태로 자동으로 되돌립니다. 이것이 바로 GitOps가 지향하는 '드리프트 방지'의 핵심입니다.
• `syncOptions: - CreateNamespace=true`: 배포 대상 네임스페이스가 존재하지 않을 경우 자동으로 생성해줍니다.

자동 동기화를 사용하지 않고 수동으로 동기화하려면 `automated` 섹션을 제거하거나 `automated: false`로 설정할 수 있습니다. 이 경우 Git 변경 사항이 감지되면 웹 UI나 CLI를 통해 수동으로 `Sync` 버튼을 눌러야 합니다.

실제 운영에서 마주친 난관과 해결책

이론적으로는 완벽해 보이는 GitOps도 실제 운영 환경에 적용해보면 예상치 못한 난관에 부딪히기 마련입니다. 저희 팀이 겪었던 몇 가지 문제점과 그 해결책을 공유합니다.

Git 레포지토리 구조 설계의 중요성

가장 먼저 고민했던 부분은 Git 레포지토리 구조였습니다. 모노레포(Monorepo)와 멀티레포(Multirepo) 중 어떤 방식을 택할 것인가였습니다.

• 모노레포 (단일 저장소): 모든 애플리케이션 및 인프라 코드를 하나의 Git 저장소에 관리합니다.
  • 장점: 모든 구성이 한곳에 있어 일관성 유지 용이, 변경 사항 추적 편리.
  • 단점: 저장소 규모가 커지면 관리 복잡, 특정 팀의 변경이 전체 파이프라인에 영향 줄 위험.
• 멀티레포 (다중 저장소): 각 애플리케이션이나 서비스별로 별도의 Git 저장소를 가집니다.
  • 장점: 독립적인 관리, 팀별 자율성 보장, 특정 서비스의 변경이 다른 서비스에 미치는 영향 최소화.
  • 단점: 여러 저장소를 오가며 관리해야 하는 불편함, 일관된 정책 적용 어려움.

저희는 초기에는 모노레포를 고려했으나, 결국에는 멀티레포 전략을 선택했습니다. 이유는 각 마이크로서비스 팀의 독립성과 변경 사항의 격리 때문이었습니다. 대신, Argo CD Application 리소스를 담는 별도의 '환경 레포지토리'를 두어 각 서비스 레포지토리와 연결하는 방식을 채택했습니다. 예를 들어, `infra-gitops` 레포지토리에 각 환경(dev, staging, prod)별 `Application` YAML 파일을 관리하고, 이 `Application` 리소스들이 실제 서비스 코드 레포지토리(`service-a-repo`, `service-b-repo` 등)를 바라보도록 구성했습니다. 이 방식은 각 서비스 팀이 자신들의 배포 매니페스트를 직접 관리하면서도, Argo CD를 통한 중앙 집중식 관리가 가능하게 해주었습니다.

네트워크 및 권한 문제 해결

Argo CD가 Git 저장소와 쿠버네티스 클러스터에 접근하는 과정에서 네트워크 및 권한 문제가 발생할 수 있습니다.

• Git 저장소 접근 권한: 프라이빗 Git 저장소를 사용하는 경우, Argo CD가 해당 저장소에 접근할 수 있는 SSH 키 또는 HTTPS 자격 증명(토큰)을 등록해야 합니다. 저는 주로 SSH 키를 `Secret`으로 생성하여 Argo CD에 등록했습니다.

  
  # SSH 키를 Secret으로 생성 (예시)
  kubectl create secret generic argocd-ssh-secret \
    --namespace argocd \
    --from-file=sshPrivateKey=/path/to/your/ssh_key \
    --type=Opaque
  
  # Argo CD에 저장소 추가 시 Secret 연결
  argocd repo add git@github.com:your-org/your-private-repo.git --ssh-private-key-path /path/to/your/ssh_key
      

• 클러스터 내부 권한: Argo CD는 클러스터 내부에서 동작하므로, 애플리케이션을 배포하기 위한 충분한 RBAC(Role-Based Access Control) 권한이 필요합니다. Argo CD는 기본적으로 `argocd-server`와 `argocd-application-controller`라는 두 가지 주요 컴포넌트를 가지며, `argocd-application-controller`가 실제 리소스 배포를 담당합니다. 이 컨트롤러에 필요한 `ClusterRole`과 `ServiceAccount`가 기본적으로 제공되지만, 특정 커스텀 리소스나 네임스페이스에 대한 추가 권한이 필요할 경우 직접 RBAC 설정을 수정해야 했습니다. 특히 `CreateNamespace` 옵션이나 특정 `CustomResourceDefinition`을 배포할 때는 추가 권한이 필수적이었습니다.

헬름(Helm) 차트와의 연동 전략

저희 팀은 대부분의 애플리케이션을 Helm 차트로 관리하고 있었습니다. Argo CD는 Helm 차트를 완벽하게 지원하며, `values.yaml` 파일을 오버라이드하거나 `values` 인라인으로 전달하는 등 다양한 방식을 제공합니다.

저희는 각 환경별로 다른 `values.yaml` 파일을 Git 레포지토리에 관리하고, Argo CD Application 리소스에서 이 파일들을 참조하도록 구성했습니다. 예를 들어:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app-dev
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/my-org/my-app-helm-chart.git
    targetRevision: main
    path: charts/my-app # 헬름 차트 경로
    helm:
      valueFiles: # 환경별 values 파일 지정
        - values-dev.yaml
      parameters: # 추가 파라미터 전달 (선택 사항)
        - name: replicaCount
          value: "2"
  destination:
    server: https://kubernetes.default.svc
    namespace: my-app-dev
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true

이 방식을 통해 개발, 스테이징, 운영 환경별로 유연하게 설정을 관리할 수 있었으며, Helm의 장점과 GitOps의 장점을 모두 취할 수 있었습니다.

Argo CD 고급 기능 활용: 프로젝트, RBAC, Sync 훅

Argo CD는 단순히 애플리케이션을 배포하는 것을 넘어, 대규모 환경에서 안정적이고 효율적인 운영을 위한 다양한 고급 기능을 제공합니다. 저희 팀은 이러한 기능들을 적극적으로 활용하여 GitOps 파이프라인을 더욱 견고하게 만들었습니다.

멀티테넌시를 위한 프로젝트 관리

여러 팀이나 서비스가 하나의 Argo CD 인스턴스를 공유해야 할 때, Argo CD 프로젝트(Project)는 필수적입니다. 프로젝트는 애플리케이션을 논리적으로 그룹화하고, 리소스 생성 권한 및 배포 대상 클러스터/네임스페이스를 제한하는 역할을 합니다. 이를 통해 멀티테넌시 환경에서 각 팀이 독립적으로 애플리케이션을 관리하면서도, 전체 시스템의 보안과 안정성을 유지할 수 있습니다.

예를 들어, `frontend-team`과 `backend-team`이라는 두 개의 프로젝트를 생성하고, 각 팀이 배포할 수 있는 네임스페이스를 제한할 수 있습니다.

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: frontend-team
  namespace: argocd
spec:
  description: Frontend Team Project
  sourceRepos:
  - https://github.com/my-org/frontend-app.git # 프론트엔드 팀의 Git 저장소
  destinations:
  - namespace: frontend-dev # 배포 허용 네임스페이스
    server: https://kubernetes.default.svc
  - namespace: frontend-prod
    server: https://kubernetes.default.svc
  clusterResourceWhitelist: # 클러스터 범위 리소스 허용 여부
  - group: '*'
    kind: '*'
  namespaceResourceWhitelist: # 네임스페이스 범위 리소스 허용 여부
  - group: '*'
    kind: '*'

이렇게 프로젝트를 정의하면, `frontend-team` 프로젝트에 속한 Argo CD Application은 오직 `frontend-dev` 또는 `frontend-prod` 네임스페이스에만 배포될 수 있습니다. 이를 통해 팀 간의 간섭을 방지하고 보안을 강화할 수 있었습니다.

역할 기반 접근 제어 (RBAC) 설정

Argo CD 자체도 RBAC(Role-Based Access Control)를 지원하여, 누가 어떤 애플리케이션을 보고, 동기화하고, 삭제할 수 있는지 세밀하게 제어할 수 있습니다. 이는 웹 UI와 CLI 모두에 적용됩니다. 저희 팀은 개발자들에게는 특정 프로젝트의 애플리케이션을 조회하고 동기화할 수 있는 권한을, 운영팀에는 모든 프로젝트의 애플리케이션을 관리할 수 있는 권한을 부여했습니다.

Argo CD의 RBAC 설정은 `argocd-rbac-cm` ConfigMap을 통해 관리됩니다. 예를 들어, `developer`라는 역할을 생성하고, 이 역할에 `my-project` 프로젝트의 애플리케이션을 조회하고 동기화할 수 있는 권한을 부여할 수 있습니다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argocd
data:
  policy.csv: |
    p, role:developer, applications, get, my-project/*, allow
    p, role:developer, applications, sync, my-project/*, allow
    g, developer-group, role:developer # AD/LDAP 연동 시 그룹 매핑

  policy.default: role:readonly # 기본 역할 설정

이렇게 설정함으로써 보안 취약점을 줄이고, 각자의 책임 범위 내에서만 작업을 수행할 수 있도록 환경을 조성했습니다.

배포 전후 작업 자동화 (Sync 훅)

애플리케이션 배포 전후에 특정 작업을 수행해야 하는 경우가 많습니다. 예를 들어, 데이터베이스 마이그레이션, 캐시 초기화, 외부 시스템 연동 알림 등입니다. Argo CD는 Sync 훅(Sync Hooks) 기능을 통해 이러한 작업을 GitOps 워크플로우에 통합할 수 있습니다.

Sync 훅은 쿠버네티스 리소스에 특정 어노테이션을 추가하여 작동합니다. 다음은 배포 전에 데이터베이스 마이그레이션 작업을 수행하는 Job의 예시입니다.

apiVersion: batch/v1
kind: Job
metadata:
  name: db-migration-job
  annotations:
    argocd.argoproj.io/hook: PreSync # PreSync 훅으로 지정
    argocd.argoproj.io/hook-delete-policy: HookSucceeded # 성공 시 삭제
  labels:
    app: my-app
spec:
  template:
    spec:
      containers:
      - name: migrator
        image: my-company/db-migration-tool:1.0
        env:
        - name: DB_HOST
          value: "my-database-svc"
      restartPolicy: Never
  backoffLimit: 4

`argocd.argoproj.io/hook: PreSync` 어노테이션을 통해 이 Job이 실제 애플리케이션 배포 전에 실행되도록 지정했습니다. 또한, `argocd.argoproj.io/hook-delete-policy: HookSucceeded`를 통해 Job이 성공적으로 완료되면 자동으로 삭제되도록 설정했습니다. 이 외에도 `Sync`, `PostSync`, `SyncFail` 등 다양한 훅 포인트가 있어 유연하게 활용할 수 있습니다.

Sync 훅을 활용하여 수동으로 진행하던 많은 배포 전후 작업들을 자동화할 수 있었고, 이는 배포 프로세스의 안정성을 크게 향상시켰습니다.

GitOps 도입, 그 후: 얻게 된 이점과 고려사항

GitOps와 Argo CD를 도입한 지 어느 정도 시간이 흘렀습니다. 실제로 적용해 본 결과, 저희 팀은 여러 면에서 긍정적인 변화를 경험했습니다.

GitOps가 가져온 변화

• 배포 안정성 및 신뢰성 향상: Git을 단일 진실의 원천(Single Source of Truth)으로 삼으면서, 환경 불일치로 인한 문제가 거의 사라졌습니다. Argo CD의 자동 동기화 및 자가 치유(Self-healing) 기능 덕분에 클러스터 상태가 항상 의도한 대로 유지되었습니다.
• 배포 속도 증가 및 자동화: Git에 코드를 푸시하는 것만으로 배포가 완료되므로, 개발팀의 배포 부담이 줄고 배포 주기가 단축되었습니다. 수동 개입이 사라지면서 배포 시간도 크게 절약되었습니다.
• 운영 가시성 확보: Argo CD 웹 UI를 통해 현재 배포된 모든 애플리케이션의 상태, 동기화 여부, Git 커밋 이력 등을 한눈에 파악할 수 있게 되었습니다. 문제 발생 시 원인 분석 시간이 대폭 줄었습니다.
• 쉬운 롤백 및 감사: Git 커밋을 되돌리는 것만으로 즉시 이전 버전으로 롤백할 수 있게 되었고, Git 로그를 통해 모든 변경 이력을 추적할 수 있어 감사(Audit) 요건을 충족하기 용이해졌습니다.
• 개발 및 운영 문화 개선: 개발팀과 운영팀이 Git이라는 공통의 언어를 통해 협업하게 되면서, 데브옵스 문화가 더욱 강화되었습니다. 인프라를 코드로 관리하는(IaC) 방식이 팀 전체에 자연스럽게 스며들었습니다.

성공적인 도입을 위한 조언

저의 경험을 바탕으로 GitOps 도입을 고려하는 분들께 몇 가지 조언을 드리고 싶습니다.

1. 점진적인 도입: 모든 애플리케이션을 한 번에 GitOps로 전환하기보다는, 작은 서비스나 개발 환경부터 시작하여 점진적으로 확대해나가는 것이 좋습니다. 저희 팀도 테스트 환경부터 시작하여 안정화된 후에 점차 운영 환경으로 확장했습니다.
2. Git 레포지토리 구조 신중하게 설계: 앞서 언급했듯이, Git 레포지토리 구조는 GitOps 운영의 기반이 됩니다. 서비스의 규모, 팀의 구조, 배포 빈도 등을 고려하여 모노레포 또는 멀티레포 전략을 신중하게 선택하고, 초기 설계를 잘 하는 것이 중요합니다.
3. Helm, Kustomize 등 구성 관리 도구 활용: 순수 YAML 파일만으로 복잡한 애플리케이션을 관리하는 것은 어렵습니다. Helm이나 Kustomize와 같은 도구를 함께 활용하여 애플리케이션 구성을 템플릿화하고 재사용성을 높이는 것이 필수적입니다.
4. RBAC 및 보안 강화: Argo CD 자체의 RBAC 기능과 쿠버네티스 RBAC를 적절히 활용하여 각 사용자와 팀의 권한을 최소한으로 제한해야 합니다. 프라이빗 Git 저장소 접근 시에는 SSH 키나 토큰 관리에 주의를 기울여야 합니다.
5. 모니터링 및 알림 체계 구축: Argo CD는 상태 불일치를 감지하지만, 이를 운영팀에게 즉시 알릴 수 있는 모니터링 및 알림 시스템(Slack, PagerDuty 등)을 연동하는 것이 중요합니다.

GitOps는 단순히 배포 도구의 변화를 넘어, 인프라 운영 방식에 대한 패러다임 전환을 의미합니다. 처음에는 학습 곡선이 존재하지만, 일단 익숙해지고 나면 그 효율성과 안정성에 놀라게 될 것입니다. Argo CD는 이 여정을 돕는 훌륭한 동반자가 되어주었습니다.

여러분도 이 글을 통해 GitOps와 Argo CD를 활용한 쿠버네티스 애플리케이션 배포 자동화에 자신감을 얻으셨기를 바랍니다. 혹시 GitOps 도입 과정에서 겪었던 어려움이나 성공 사례가 있다면 댓글로 자유롭게 공유해주세요. 함께 더 나은 클라우드 인프라 운영 방안을 모색해나갔으면 좋겠습니다.

📌 함께 읽으면 좋은 글

• [클라우드 인프라] GitOps 기반 쿠버네티스 애플리케이션 배포 및 관리: ArgoCD와 FluxCD 비교 분석
• [클라우드 인프라] 멀티 클라우드 비용 최적화 전략: 실전 인프라 운영 노하우
• [클라우드 인프라] Terraform으로 클라우드 인프라 자동화: IaC 설계 원칙과 실전 가이드

이 글이 도움이 되셨다면 공감(♥)과 댓글로 응원해 주세요!
궁금한 점이나 다루었으면 하는 주제가 있다면 댓글로 남겨주세요.