[GitOps]🧐 조정(Reconciliation)이란 무엇인가요?

안녕하세요! GitOps 시리즈의 네 번째 시간입니다. 오늘은 GitOps 운영의 핵심 메커니즘이자, 많은 엔지니어분들이 고민하시는 '조정(Reconciliation) 모델'에 대해 깊이 있게 다뤄보려고 합니다.

GitOps를 구현할 때 가장 먼저 맞닥뜨리는 선택지인 풀(Pull) 방식과 푸시(Push) 방식의 차이를 10분 동안 완벽하게 마스터해 볼까요? 🚀

본론으로 들어가기 전, '조정'이라는 단어의 의미를 짚어봅시다. GitOps에서 조정이란 'Git에 저장된 희망 상태(Desired State)'와 '실제 환경의 현재 상태(Actual State)'를 비교하고, 차이가 있다면 이를 일치시키는 일련의 과정을 말합니다.

이 과정을 누가 주도하느냐에 따라 Push와 Pull로 나뉩니다. ⚖️

---

1. 푸시(Push) 방식: 전통적인 강력함 💨

푸시 방식은 우리가 흔히 사용하는 Jenkins, GitHub Actions, GitLab CI와 같은 전통적인 CI/CD 도구들이 사용하는 방식입니다.

✅ 작동 원리

1. 개발자가 소스 코드를 Git에 커밋합니다.
2. CI 파이프라인이 트리거되어 빌드 및 테스트를 수행합니다.
3. 파이프라인의 마지막 단계에서 운영 환경(예: Kubernetes 클러스터)에 직접 명령을 내려 업데이트를 수행합니다. (예: kubectl apply -f ...)

👍 장점

• 익숙함: 기존의 많은 CI 툴이 이 방식을 따르므로 학습 곡선이 낮습니다.
• 유연성: 클러스터 외부에서 제어하므로, 특정 클러스터에 종속되지 않고 다양한 명령을 자유롭게 실행할 수 있습니다.

👎 단점 및 한계

• 보안 취약성: CI 도구가 운영 환경의 관리자 권한(Kubeconfig 등)을 가지고 있어야 합니다. 만약 CI 툴이 해킹당하면 운영 서버 전체가 위험해집니다.
• 상태 불일치(Drift) 감지 불가: CI 툴은 '명령을 보내는 것'으로 임무가 끝납니다. 누군가 나중에 서버 설정을 수동으로 바꿔도 CI 툴은 이를 알 수 없습니다.

---

2. 풀(Pull) 방식: GitOps의 진정한 정수 ⚓

풀 방식은 GitOps의 창시자들이 권장하는 모델로, Argo CD나 Flux 같은 전용 도구가 이 방식을 사용합니다.

✅ 작동 원리

1. 운영 환경(Kubernetes 클러스터 등) 내부에 **'GitOps 오퍼레이터(에이전트)'**를 설치합니다.
2. 이 오퍼레이터는 주기적으로 Git 저장소를 살핍니다(Polling).
3. Git에 변경 사항이 생기면, 오퍼레이터가 이를 스스로 '끌어와서(Pull)' 자신의 상태를 업데이트합니다.

👍 장점

• 강력한 보안: 운영 환경의 인증 정보가 클러스터 외부로 나가지 않습니다. 외부에서는 내부를 볼 수 없고, 내부에서만 밖(Git)을 봅니다.
• 자동 복구(Self-healing): 누군가 수동으로 설정을 변경하면, 내부에 상주하는 오퍼레이터가 이를 즉시 감지하고 Git 상태로 되돌려 놓습니다.
• 신뢰성: 배포 과정이 네트워크 상태나 CI 툴의 일시적 오류에 덜 민감합니다.

👎 단점 및 한계

• 구현 복잡도: 클러스터마다 오퍼레이터를 관리해야 하므로 초기 설정이 다소 복잡할 수 있습니다.
• 가시성: 배포 과정이 클러스터 내부에서 일어나므로, 외부 CI 대시보드에서 배포 진행 상황을 실시간으로 확인하려면 추가적인 설정이 필요합니다.

---

📊 한눈에 비교하는 Push vs Pull

비교 항목	푸시(Push) 방식	풀(Pull) 방식
주체	외부 CI 도구 (GitHub Actions 등)	내부 오퍼레이터 (Argo CD 등)
보안	인증 정보가 외부에 노출됨	인증 정보가 내부에서 관리됨
상태 유지	명령 전달 후 종료 (일회성)	지속적인 감시 및 조정 (연속성)
자가 치유	불가능 (다시 실행해야 함)	가능 (자동 복구)
주요 도구	Jenkins, GitLab CI, CircleCI	Argo CD, Flux CD

---

🤔 어떤 방식을 선택해야 할까요?

결론부터 말씀드리면, 보안과 운영의 안정성이 중요하다면 'Pull 방식'을 강력히 추천합니다.

• 이런 경우엔 Push: 소규모 프로젝트이거나, 쿠버네티스가 아닌 환경에 배포해야 할 때, 또는 기존 CI 파이프라인을 크게 바꾸기 어려운 환경일 때 적합합니다.
• 이런 경우엔 Pull: 쿠버네티스 기반의 클라우드 네이티브 환경이거나, 다수의 환경(Dev/Prod)을 안전하고 일관되게 관리해야 하는 기업용 시스템에 적합합니다.

---

🏁 마무리하며

GitOps의 꽃은 결국 'Pull 방식의 지속적 조정'에 있습니다. 수동 개입 없이 시스템이 스스로 최신 상태를 유지하고 장애를 복구하는 모습은 모든 운영자의 꿈이죠. ✨

오늘 살펴본 두 방식의 차이를 명확히 이해하신다면, 여러분의 팀에 최적화된 배포 전략을 세우는 데 큰 도움이 될 것입니다.