🏛️ GitOps의 4가지 핵심 원칙 (The 4 Principles)

안녕하세요! GitOps 시리즈의 세 번째 시간입니다. 앞서 GitOps의 정의와 활용 사례를 살펴보았는데요. 오늘은 그 내실을 다지는 시간으로, GitOps를 지탱하는 4가지 절대 원칙과 이를 실제 현업에 적용할 때 마주하는 현실적인 이야기를 깊이 있게 다뤄보겠습니다.

단순한 이론을 넘어 실무자의 시선으로 상세히 가이드해 드릴게요! 🚀

GitOps 작업 방식이 일반적인 CI/CD와 다른 점은 바로 이 '원칙'에 있습니다. OpenGitOps 프로젝트에서 정의한 표준 원칙을 하나씩 뜯어볼까요?

1. 선언적 상태 정의 (Declarative) 📜

모든 시스템 상태는 선언적(Declarative)이어야 합니다.

• 명령형(Imperative): "서버에 접속해서 nginx 설치하고 80번 포트 열어줘." (과정 중심)
• 선언적(Declarative): "이 시스템의 최종 상태는 'nginx가 설치되어 있고 80번 포트가 열린 상태'여야 해." (결과 중심)
• 이유: 선언적 방식은 재현이 가능하고, 시스템이 스스로 무엇을 해야 할지 판단할 수 있게 합니다. 주로 YAML이나 JSON 파일로 작성됩니다.

2. 버전 관리 및 불변성 (Versioned and Immutable) 🔄

모든 선언된 상태는 Git과 같은 버전 관리 시스템에 저장되어야 합니다.

• 이유: 누가, 언제, 왜 변경했는지 이력이 남기 때문입니다. 또한, '불변성'은 한 번 배포된 코드는 수정되지 않으며, 변경이 필요하면 새로운 버전을 만들어 다시 배포한다는 뜻입니다. 장애 발생 시 가장 확실한 해결책인 'Rollback(되돌리기)'을 가능하게 하는 핵심입니다.

3. 자동 동기화 (Pulled Automatically) 🤖

Git에 저장된 '희망 상태(Desired State)'가 실제 운영 환경에 자동으로 반영되어야 합니다.

• 이유: 사람이 수동으로 명령어를 입력해 배포하는 순간, Git의 내용과 실제 서버 상태가 달라질 위험이 생깁니다. 소프트웨어(에이전트)가 이 역할을 대신 수행하여 인적 오류를 차단합니다.

4. 지속적 조정 (Continuous Reconciliation) ⚖️

시스템은 'Git의 상태'와 '실제 환경의 상태'가 일치하는지 실시간으로 감시해야 합니다.

• 핵심 개념: 만약 누군가 실수로 운영 서버의 설정을 수동으로 바꿨다면(Configuration Drift), GitOps 도구는 이를 감지하고 다시 Git에 적힌 대로 원복시킵니다. 이를 'Self-healing(자가 치유)'이라고 부릅니다.

---

🛠️ GitOps의 실제: 구현 시 고려해야 할 현실적 문제

이론은 아름답지만, 실제 적용에는 몇 가지 높은 산이 있습니다. 실무에서 반드시 마주하게 될 이슈들을 정리해 드립니다.

1. Git 저장소 전략 (Repository Strategy) 📂

애플리케이션 소스 코드와 배포용 YAML 파일을 어디에 둘 것인가의 문제입니다.

• Mono Repo: 코드와 인프라 설정을 한 곳에 둡니다. 관리는 편하지만, CI 빌드가 돌 때마다 배포 기록이 섞여 관리가 복잡해질 수 있습니다.
• Separate Repo (권장): 코드 저장소와 환경 설정(Config) 저장소를 분리합니다. 보안 관리와 배포 이력 관리가 훨씬 깔끔해집니다.

2. 시크릿 관리 (Secret Management) 🔑

Git의 대원칙은 "모든 것을 저장한다"이지만, 비밀번호나 API 키를 그대로 올릴 순 없습니다.

• 해결책: * Sealed Secrets: 암호화된 상태로 Git에 올리고 클러스터 내부에서만 복호화합니다.
  • External Secrets Operator: AWS Secrets Manager나 HashiCorp Vault 같은 외부 저장소의 값을 가져와 연결합니다.

3. CI와 CD의 분리 ✂️

GitOps에서는 CI와 CD를 엄격히 구분하는 경향이 있습니다.

• CI (Build): 코드를 테스트하고 이미지를 빌드하여 레지스트리에 푸시합니다. (GitHub Actions, Jenkins 등)
• CD (Deploy): 이미지 태그가 업데이트된 YAML을 보고 운영 환경에 반영합니다. (Argo CD, Flux 등)
• 실제 흐름: 개발자가 코드를 머지하면 CI가 이미지를 만들고, 자동으로 설정 저장소의 이미지 버전을 업데이트(Commit)합니다. 그러면 CD 도구가 이를 감지해 배포를 완료합니다.

---

📈 GitOps 도입 후 변화되는 워크플로우

GitOps가 정착되면 개발팀의 하루는 이렇게 바뀝니다.

1. 개발: 로컬에서 기능을 개발합니다. 💻
2. PR 요청: 인프라 변경이 필요하면 YAML 파일을 수정해 PR을 올립니다. 📑
3. 리뷰 및 승인: 동료들과 운영팀이 코드 리뷰를 통해 변경 사항을 검증합니다. ✅
4. 머지: PR이 승인되어 메인 브랜치에 합쳐집니다. 🤝
5. 자동 배포: Argo CD가 이를 감지하고 실시간으로 운영 환경을 업데이트합니다. 🚀
6. 모니터링: 대시보드에서 초록색 불(Synced)이 들어오는 것을 확인하고 편안하게 퇴근합니다. ☕

---

🏁 마치며: GitOps는 '신뢰'의 기술입니다

GitOps의 진정한 가치는 "운영 환경이 내가 Git에 쓴 내용과 100% 일치한다"는 믿음을 주는 데 있습니다. 이 신뢰가 쌓이면 배포에 대한 공포가 사라지고, 팀은 더 빠르게 혁신할 수 있습니다.

오늘 살펴본 4가지 원칙을 가슴에 새기고, 여러분의 프로젝트에 하나씩 녹여내 보시기 바랍니다.