콘텐츠로 이동

ArgoCD (GitOps)

배포한 결과가 "보통대로 잘 됐는지"를 확인하려면, 지금 클러스터에 실제로 떠 있는 상태와 "이래야 한다고 적은 문서"를 비교할 수 있어야 해요. ArgoCD는 바로 그 비교를 자동으로 해주는 GitOps 도구입니다. 배포 원하는 상태를 Git 레포에 코드로 두고, 클러스터가 그 코드를 항상 따라가게 해요.

누가 언제 뭘 배포했는지가 전부 레포 커밋에 남으니, 문제가 생기면 이전 커밋으로 되돌리는 것만으로도 롤백이 끝나요. 다루는 개념이 많아 보이지만, "레포가 진실이고 도구가 그걸 맞춘다"는 한 줄로 요약돼요.

이 방식은 특히 여러 서비스가 함께 돌아가는 멀티 서비스 환경에서 힘을 발휘해요. 사람이 배포 명령을 내리는 대신, 원하는 상태가 레포에 있고 도구가 항상 그 상태를 지키니까요.

핵심 개념

GitOps 원칙. "레포가 곧 시스템의 진실"이라는 운영 방식이에요. 배포할 상태를 매니페스트(또는 Helm 차트)로 선언해 레포에 두고, 도구가 그 상태와 실제 클러스터를 맞춥니다. 사람이 kubectl로 직접 손대지 않아요.

애플리케이션(Application). ArgoCD에서 배포 대상 하나를 뜻하는 단위예요. 어떤 레포·경로·대상 클러스터·네임스페이스를 동기화할지를 선언해요.

동기화(Sync). ArgoCD가 주기적으로 레포 상태를 확인하고(쿨루프 폴링), 변화가 생기면 자동으로 클러스터에 반영해요. 원격 알림(웹훅)으로 더 빠르게 트리거할 수도 있죠. 필요할 땐 자동 동기화를 끄고, 검토 후 수동으로 동기화하는 방식으로 둘 수도 있어요.

원하는 상태와 실제 상태. 애플리케이션이 항상 "레포에 적힌 상태 = 실제 클러스터 상태"를 유지합니다. 차이가 나면 OutOfSync로 표시되고, 동기화해 다시 맞춥니다.

롤백. 배포 후 문제가 생기면 레포를 이전 상태(이전 커밋/태그)로 되돌리면, ArgoCD가 클러스터를 그 상태로 다시 맞춰요. 복잡한 배포 스크립트 없이도 되돌리기가 단순해져요.

이 일련의 개념이 유기적으로 이어져요. 애플리케이션이 원하는 상태를 선언하면, 동기화가 그 상태를 맞추고, 원하는 상태와 실제 상태 비교가 항상 어긋남을 감지하죠. 그 틀 안에서 롤백도 레포 기준으로 일어납니다.

사용 사례 / 실제 적용

우리 배포 흐름의 마지막을 담당해요. GitHub Actions(또는 GitLab CI)가 이미지를 빌드·push하면, ArgoCD가 그 레포 변화를 감지해 Kubernetes 클러스터에 자동으로 반영해요. 마케팅 사이트, 위키, 백엔드 각각을 애플리케이션 단위로 관리하고, 네임스페이스별로 격리해서 운영합니다.

배포 후 서비스가 잘못 되면 이전 레포 상태로 간단히 롤백하고, 모든 변경이 커밋에 남기 때문에 감사·추적이 쉬워요. "누가 언제 배포했나"라는 질문에 레포 히스토리가 답해 주죠.

정리하면, ArgoCD는 "배포 상태를 레포로 관리하고, 클러스터가 그 상태를 따르게 하는" GitOps의 실행 담당이에요. 이 한 줄만 기억하면 나머지는 그 원칙의 구체화로 읽힙니다. 그래서 배포를 사람이 기억하는 대신, 시점과 상태를 코드에서 확인하는 운영 습관이 몸에 붙어요.

하위 챕터

더 알아보기