— 복잡한 마이크로서비스, Git으로 일관되게 통제하라
“CI/CD의 끝은 GitOps다.
특히, MSA에서는 배포보다 통제가 더 중요하다.”
1. 🎯 GitOps란 무엇인가?
**GitOps(Git Operations)**는 말 그대로 Git 저장소를 중심으로 운영 및 배포를 자동화하는 DevOps 실천 전략입니다.
단순히 ‘코드 관리’가 아닌, 전체 클러스터 상태를 Git에서 선언하고 Git을 통해 시스템을 제어하는 방식이죠.
🔑 핵심 개념
| 구성요소 | 설명 |
|---|
| Git | 모든 애플리케이션 배포 설정(Helm, YAML 등)을 정의하고 추적하는 소스 |
| 자동화 툴 | ArgoCD, Flux → Git 상태를 Kubernetes에 자동으로 반영 |
| 실행 주체 | Push → Pull 전략의 전환 (배포를 명령하지 않고, Git 상태에 따라 실행됨) |
| 불변성 원칙 | Git에 정의된 상태 외의 클러스터 변경은 ‘드리프트’로 감지 및 복구 |
2. 🤯 MSA 운영의 복잡성 — GitOps가 필요한 이유
마이크로서비스 환경은 다음과 같은 운영 복잡성을 동반합니다.
| 문제 | 내용 |
|---|
| 서비스 수 증가 | 수십~수백 개 서비스의 독립 배포 |
| 환경별 구성 다양성 | dev / staging / prod 환경의 차별화 |
| 빠른 릴리즈 주기 | 하루 수십 번의 서비스 단위 릴리즈 |
| 변경 이력 불명확 | 수동 변경으로 인해 설정 추적 불가 |
| 운영자 간 협업 어려움 | 배포 책임 주체 혼란, 승인·롤백 체계 미비 |
→ 이러한 문제를 GitOps가 해결해줍니다.
**”코드와 설정을 한 저장소에 모아, 선언형으로 통제하고, 자동화로 반영”**하는 방식.
3. 🛠️ GitOps 전략 구성 요소
| 구성요소 | 도구/기술 | 역할 |
|---|
| Git 저장소 | GitHub, GitLab | 애플리케이션의 배포 상태 정의 |
| 선언형 설정 | Helm, Kustomize, YAML | 클러스터의 모든 리소스를 Git에 선언 |
| GitOps 엔진 | ArgoCD, FluxCD | Git 상태와 클러스터 상태를 동기화 |
| 인증/인가 | OIDC, RBAC, GitHub Teams | 배포 권한 관리 |
| 검증/승인 | PR + 리뷰 + GitOps Sync | 배포 전 코드 승인 흐름 적용 |
4. 🧭 GitOps 전략 설계 예시 (MSA 기준)
📂 Git 저장소 구조 예시
├── apps/
│ ├── auth-service/
│ │ ├── base/
│ │ ├── overlays/
│ │ │ ├── dev/
│ │ │ ├── staging/
│ │ │ └── prod/
│ ├── order-service/
│ └── payment-service/
├── infra/
│ ├── cert-manager/
│ ├── ingress-nginx/
│ └── monitoring/
- 서비스 단위
Helm Chart 또는 Kustomize 디렉토리 구성
- 환경별로
overlays 구조화
🔄 GitOps 동기화 방식
| 방식 | 설명 |
|---|
| Pull-based (ArgoCD) | Git 상태를 감시하고 클러스터에 자동 반영 |
| Manual Sync | PR 리뷰/승인 → ArgoCD에서 수동 Sync 버튼 |
| 자동 Rollback | Git과 불일치 상태 감지 시 이전 상태 복구 |
5. 🧩 ArgoCD를 활용한 GitOps 예시
✅ ArgoCD 구성도
[Git Repo] ←(watch)─ [ArgoCD Controller] ─→ [Kubernetes Cluster]
↑ ↑
(pull request) (apply)
- Git에 설정 푸시 → ArgoCD가 해당 변경 감지 → 클러스터 반영
- UI 대시보드 또는 CLI 통해 Rollback, Sync 제어 가능
- RBAC, SSO, Notification 시스템 연동
6. 🛡️ 보안과 정책 통제
🎯 보안 강화 방법
| 항목 | 전략 |
|---|
| 접근 통제 | GitOps를 통해 배포 권한을 Git PR 승인 체계로 전환 |
| 감사 추적 | Git commit log 자체가 변경 이력 및 감사 로그 |
| 드리프트 탐지 | 클러스터 상태와 Git 상태가 다르면 알림 또는 복구 |
| PR 승인 정책 | DevSecOps 보안 규칙 내장 (e.g. OPA Gatekeeper) |
7. 🧪 GitOps 운영 팁 (MSA 프로젝트 기준)
| 항목 | 베스트 프랙티스 |
|---|
| 서비스 수가 많을 때 | 폴더 구조를 서비스 기준으로 일관되게 유지 |
| 환경 격리 | 환경별 Git Branch 또는 Directory 사용 |
| Helm vs Kustomize | Helm은 파라미터화에 유리, Kustomize는 단순 오버레이에 유리 |
| 비밀 관리 | Sealed Secrets, External Secrets, HashiCorp Vault 연동 |
| 릴리즈 제어 | Git Tag + Sync Window 설정 (배포 시간 제어) |
8. 🧱 GitOps vs 기존 방식 비교
| 항목 | 기존 방식 | GitOps |
|---|
| 배포 방식 | CLI 또는 스크립트 직접 실행 | Git에 설정 → 자동 반영 |
| 이력 관리 | 수동 로그, 추적 어려움 | Git 커밋 로그로 변경 추적 |
| 권한 관리 | kubectl 권한에 의존 | Git PR 승인자로 통제 가능 |
| 에러 복구 | 수동 Rollback | Git 기준 자동 Rollback |
| 보안 | 실시간 배포 권한 필요 | Git 권한 + 인증 연동으로 제어 |
✅ 마무리: MSA를 통제하는 최고의 전략, GitOps
GitOps는 단순한 배포 자동화가 아닙니다.
서비스 분산이 곧 통제의 분산으로 이어지는 마이크로서비스 환경에서, 통합된 제어의 중심축이 됩니다.
“분산된 MSA를 하나의 Git 저장소로 통제하라.
그것이 진정한 DevOps의 완성이다.”
