개발자의 주말을 지켜주는 수호신, ArgoCD와 GitOps의 세계로 오신 것을 환영합니다
안녕하세요, 치열한 배포 전선에서 고군분투하는 엔지니어 여러분. 오늘도 터미널의 검은 화면 속에서 kubectl apply와 씨름하며 하루를 보내셨나요? 15년 동안 인프라와 백엔드 개발을 오가며 수많은 밤을 지새운 저에게도, 쿠버네티스 배포는 언제나 긴장되는 순간이었습니다. 금요일 오후 5시, 퇴근을 앞두고 배포 버튼을 눌렀는데 프로덕션 환경이 멈춰버린 경험, 혹시 있으신가요? 로컬에서는 완벽하게 돌아가던 코드가 운영 서버에만 가면 알 수 없는 이유로 터지고, 누가 언제 어떤 설정을 바꿨는지 몰라 수만 줄의 로그를 뒤지느라 식은땀을 흘렸던 기억 말입니다.
솔직히 고백하자면, 저도 GitOps라는 개념을 처음 접했을 때는 "아니, 젠킨스(Jenkins)에서 스크립트 돌리면 되지, 굳이 또 복잡한 도구를 써야 해?"라고 반문했습니다. 하지만 프로젝트 규모가 커지고 마이크로서비스가 50개를 넘어가는 순간, 깨달았습니다. 사람이 수동으로, 혹은 파편화된 스크립트로 배포하는 방식은 언제 터질지 모르는 시한폭탄과 같다는 것을요. ArgoCD는 단순한 배포 도구가 아닙니다. 우리의 인프라를 '코드로 정의된 상태(Git)'와 '실제 운영 중인 상태(Cluster)'를 끊임없이 비교하고 일치시키는, 아주 깐깐하고 든든한 지휘자입니다.
오늘 저는 여러분과 함께 이 ArgoCD를 바닥부터 설치하고, 깃허브와 연동하여 진정한 자동화를 구축하는 과정을 아주 깊이 있게 다뤄보려고 합니다. 단순히 설치 매뉴얼을 읊는 것이 아니라, 수많은 시행착오 끝에 얻은 'Sync 불일치(OutOfSync)' 해결 전략과 프로덕션 레벨의 운영 노하우를 아낌없이 털어놓겠습니다. 준비되셨나요? 그럼 시작해봅시다.
GitOps의 철학: 왜 우리는 ArgoCD를 선택해야 하는가?
ArgoCD 설치법을 이야기하기 전에, 도대체 왜 이걸 써야 하는지 '원리'를 확실히 짚고 넘어가야 합니다. 단순히 유행이라서 쓰는 기술은 금방 대체되지만, 철학을 이해하고 도입한 기술은 10년을 갑니다. 이는 도구의 사용법을 넘어 팀의 일하는 방식(Culture)을 바꾸는 문제입니다.
🛠️ 명령형(Imperative) vs 선언형(Declarative)의 차이
전통적인 배포 방식은 명령형이었습니다. "A 서버에 접속해서, B 파일을 복사하고, C 서비스를 재시작해"라고 명령을 내리는 식이죠. 마치 요리사에게 "양파를 썰고, 불을 켜고, 3분간 볶으세요"라고 하나하나 지시하는 것과 같습니다. 이 방식의 치명적인 단점은 중간에 하나라도 실패하거나, 누군가 몰래 설정을 바꾸면 전체 상태를 알 수 없게 된다는 점입니다. 스크립트가 100줄이라면, 그중 50번째 줄에서 에러가 났을 때 시스템이 어떤 상태인지 파악하기란 불가능에 가깝습니다.
반면 ArgoCD가 지향하는 선언형(GitOps) 방식은 다릅니다. 우리는 Git이라는 악보에 "이 시스템은 이런 상태여야 해(Desired State)"라고 적어두기만 하면 됩니다. 그러면 ArgoCD라는 지휘자가 현재 오케스트라(쿠버네티스)의 상태(Live State)를 보고, 악보와 다른 부분이 있다면 알아서 조율합니다. "지금 바이올린 소리가 작아요, 키우세요!"라고 지시하는 것이죠. 우리는 '어떻게(How)' 할지를 고민하지 않고, '무엇(What)'이 되어야 하는지만 정의하면 됩니다.
💡 핵심 원리: ArgoCD는 쿠버네티스 클러스터 내부에 설치되어, 끊임없이 Git 리포지토리(Desired State)와 현재 클러스터 상태(Live State)를 비교(Diff)합니다. 이 두 상태가 다르면 'OutOfSync'라고 판단하고, 이를 일치시키는 'Sync' 작업을 수행합니다. 이것이 GitOps의 본질입니다.
📉 실제 현장에서 겪은 Before & After 시나리오
제가 예전에 금융권 차세대 프로젝트를 진행할 때였습니다. 당시에는 젠킨스를 통해 kubectl 명령어를 파이프라인에서 직접 날리는 방식으로 배포를 했습니다. 이 방식이 어떤 재앙을 불러왔는지 생생하게 비교해 드립니다.
Before (ArgoCD 도입 전):
어느 날 새벽 2시, 장애가 발생했습니다. 누군가 급하게 핫픽스를 한다고 운영 서버의 ConfigMap을 kubectl edit으로 직접 수정해버린 것이 화근이었습니다. Git에는 예전 설정이 남아있었고, 다음 정기 배포 때 CI 파이프라인이 이 수동 변경 사항을 덮어씌워버리면서 대형 장애로 이어졌습니다. "누가 바꿨어?"라는 고성이 오갔고, 원인을 찾는 데만 4시간이 걸렸습니다. 배포 한 번 하려면 운영팀 승인을 받고 30분씩 기다려야 했습니다.
After (ArgoCD 도입 후):
모든 변경 사항은 반드시 Git을 통해야만 했습니다. 누군가 급해서 클러스터 설정을 직접 바꾸더라도, ArgoCD가 3분 안에 이를 감지하고 "Git과 상태가 다릅니다! 원복하겠습니다"라며 자동으로 Git에 정의된 상태로 되돌려버립니다(Self-Healing). 덕분에 '구성 불일치(Configuration Drift)'라는 유령에서 완전히 해방되었습니다. 배포 시간은 30분에서 5분으로 단축되었고, 롤백은 버튼 하나로 10초 만에 가능해졌습니다. 무엇보다 주말 새벽에 전화를 받는 일이 사라졌습니다.
ArgoCD 아키텍처 깊게 파헤치기: 어떻게 동작하는가?
설치하기 전에 내부 구조를 알면 트러블슈팅이 훨씬 쉬워집니다. ArgoCD는 마법 상자가 아닙니다. 크게 세 가지 핵심 컴포넌트가 유기적으로 맞물려 돌아가는 정교한 시스템입니다.
🧩 주요 컴포넌트 3총사
- API Server: ArgoCD의 얼굴입니다. 웹 UI와 CLI, 그리고 CI/CD 시스템에서의 gRPC/REST 요청을 처리하는 관문입니다. 인증(AuthN)과 인가(AuthZ)도 여기서 담당합니다.
- Repository Server: 이게 아주 중요합니다. Git 리포지토리의 내용을 로컬로 복제(Clone)하고, 캐싱하며, Helm이나 Kustomize 같은 템플릿 도구를 실행하여 순수한 쿠버네티스 매니페스트(YAML)를 생성하는 역할을 합니다. 메모리를 꽤 많이 사용하는 녀석이라, 리포지토리가 많아지면 가장 먼저 자원을 늘려줘야 하는 곳입니다.
- Application Controller: ArgoCD의 심장입니다. 현재 클러스터의 상태를 감시하고, Repo Server가 만들어준 매니페스트와 비교하여 차이점을 찾아내는 역할을 합니다. 사용자가 정의한 Sync 정책에 따라 실제로 리소스를 생성하거나 수정하는 주체입니다.
이 세 가지 외에도 빠른 처리를 위해 매니페스트를 캐싱하는 Redis가 포함됩니다. 만약 Sync가 느리다면 Repo Server의 성능을 의심해야 하고, 상태 반영이 안 된다면 Controller의 로그를 봐야 하며, 로그인이나 화면 로딩이 느리다면 Redis나 API Server를 점검해야 합니다.
📋 단계별 실행 가이드: ArgoCD 설치부터 접속까지
자, 이제 이론은 충분하니 손을 더럽혀볼 시간입니다. 단순히 명령어를 복사-붙여넣기 하는 수준을 넘어, 각 단계가 무엇을 의미하는지 상세히 설명하겠습니다. 이 가이드는 쿠버네티스 1.24+ 버전을 기준으로 합니다.
1단계: 전용 네임스페이스 생성 및 자원 격리
가장 먼저 ArgoCD가 살 집을 지어야 합니다. 쿠버네티스 클러스터에 argocd라는 이름의 네임스페이스를 생성합니다. 이는 관리의 용이성과 보안 격리를 위해 필수적입니다. 단순히 생성만 하는 게 아니라, 이 네임스페이스에는 리소스 쿼터(Resource Quota)를 적절히 설정하여 ArgoCD가 오작동하더라도 클러스터 전체 자원을 독점하지 않도록 하는 것이 프로의 팁입니다.
2단계: 공식 매니페스트 적용 (HA vs Non-HA)
ArgoCD 프로젝트 팀에서 제공하는 공식 설치 YAML 파일이 있습니다. 여기서 중요한 선택을 해야 합니다.
- 개발/테스트 환경:
install.yaml을 사용합니다. 컴포넌트가 하나씩만 뜹니다.
- 운영(Production) 환경: 반드시
ha/install.yaml을 사용해야 합니다. 이는 주요 컴포넌트를 다중화(Replicas)하여 고가용성을 보장합니다. 배포 도구가 죽어서 배포를 못 하는 상황만큼 아이러니한 일은 없으니까요.
3단계: CLI 도구 설치 및 환경 변수 설정
댓글
댓글 쓰기