들어가며

스터디 팀에서 사이드 프로젝트를 시작하면서 두 가지 목표가 있었습니다.

1. GitOps 학습: 요즘 많이 언급되는 GitOps를 직접 구축해보고 싶었습니다
2. 효율적인 인프라 운영: 본업 외 시간을 쪼개서 개발하다 보니, 인프라 관리에 시간 쓰기가 아깝더라고요

학습도 하면서 실제로 쓸 수 있는 환경을 만들자는 생각으로 GitOps 도입을 결정했습니다.

소규모 팀의 현실

문제 상황

• 개발자 1~3명이 백엔드, 프론트, 인프라 모두 담당
• 배포할 때마다 SSH 접속 → 수동 작업 → 확인 반복
• “저번에 서버 설정 어떻게 했더라?” 기억에 의존
• 장애 발생 시 롤백 방법을 매번 고민
• 새 팀원 온보딩 시 인프라 설명에 시간 소모

원하는 것

• git push 하면 알아서 배포
• 설정 변경 이력이 자동으로 남음
• 문제 생기면 git revert로 롤백
• README와 코드만 보면 인프라 파악 가능

GitOps란?

GitOps는 Git을 Single Source of Truth로 사용하는 운영 방식입니다.

핵심 원칙:

• 선언적 정의: “어떻게”가 아닌 “무엇을” 원하는지 정의
• Git이 진실의 원천: 모든 설정이 Git에 존재
• 자동 동기화: Git 상태 = 클러스터 상태

왜 GitOps가 소규모 팀에 적합한가?

1. 운영 부담 최소화

# Before: 배포할 때마다 수동 작업
ssh production-server
cd /app
git pull
docker-compose down
docker-compose up -d
docker logs -f app  # 잘 떴나 확인...

# After: Git push가 곧 배포
git push origin main  # 끝. ArgoCD가 알아서 처리

2. 자동 문서화

인프라 설정이 코드로 존재하므로 별도 문서가 필요 없습니다.

• “Traefik 설정 어디있어?” → helm/traefik/values.yaml
• “환경변수 뭐 넣었지?” → apps/my-app/values.yaml
• “언제 이거 바꿨지?” → git log

3. 안전한 롤백

장애 상황에서 당황하지 않아도 됩니다.

# 이전 버전으로 롤백
git revert HEAD
git push

# ArgoCD가 자동으로 이전 상태로 복구

4. 재현 가능한 환경

클러스터가 날아가도 Git 저장소만 있으면 복구됩니다.

# 새 클러스터에서 전체 인프라 복구
helmfile sync

5. 온보딩 시간 단축

새 팀원이 와도 Git 저장소 구조만 파악하면 됩니다. 구전되는 암묵지가 아닌, 코드화된 인프라가 있으니까요.

6. 빠른 실험 환경

스터디 팀에서 새로운 기술을 실험하고 검증하기 좋습니다. GitOps 환경에서는:

• 새 서비스 추가? Helm 차트 하나 추가하고 git push
• A/B 테스트용 환경? 브랜치 따서 배포
• 실험 실패? git revert로 즉시 원복

인프라 구축에 시간 쓰지 않고, 학습과 실험에 집중할 수 있습니다.

GitOps 구현 시 고려사항

GitOps는 방법론이기 때문에 정해진 도구가 없습니다. 각자 익숙한 도구를 사용하면 됩니다. 다만 구현 시 고려해야 할 전략들이 있습니다.

저장소 전략

최소 2개 이상의 Git 저장소를 사용하는 것이 권장됩니다. 저는 다음과 같이 구성했습니다.

저장소를 분리하면:

• 관심사 분리: 앱 배포와 인프라 관리가 독립적
• 변경 영향 최소화: 인프라 수정이 앱 CI를 트리거하지 않음
• 권한 분리: 인프라 저장소는 더 엄격하게 관리 가능

배포 흐름

앱 소스코드 저장소는 별도로 존재하고, CI가 끝나면 manifest repo에 PR을 생성하는 구조입니다.

1. App Repo에 코드 push
2. GitHub Actions가 이미지 빌드 후 Docker Hub에 push
3. GitHub Actions가 manifest repo에 image tag 업데이트 PR 생성
4. PR merge 시 ArgoCD가 변경 감지
5. ArgoCD가 클러스터에 sync

배포 전략: Push vs Pull

GitOps에서는 두 가지 배포 전략이 있습니다.

Push Type

• CI/CD 파이프라인이 클러스터에 직접 배포
• 파이프라인이 클러스터 접근 권한 필요
• 예: GitHub Actions + kubectl

Pull Type (권장)

• 클러스터 내부의 Operator가 Git 저장소를 감시
• 변경 감지 시 자동으로 동기화
• 외부에서 클러스터 접근 불필요 → 보안상 유리
• 예: ArgoCD, Flux

이 시리즈에서는 Pull Type + ArgoCD 조합을 사용합니다.

전체 아키텍처

이 시리즈에서 구축할 아키텍처입니다.

기술 스택

왜 DigitalOcean인가?

AWS나 GCP도 고려했지만, 소규모 팀에게 DigitalOcean이 더 적합했습니다.

비용과 복잡도를 줄이고, 그 시간에 비즈니스 로직을 개발하는 게 목표였습니다.

시리즈 구성

0. 왜 GitOps인가? (현재 글)
1. Kubernetes 클러스터와 Traefik - Ingress 설정
2. ExternalDNS - DNS 레코드 자동화
3. SOPS + age - 시크릿 암호화
4. ArgoCD - GitOps 배포 파이프라인

다음 글

다음 글에서는 DigitalOcean에서 Kubernetes 클러스터를 생성하고, Traefik을 Ingress Controller로 설치합니다.

참고 자료

• GitOps 공식 사이트
• DigitalOcean Kubernetes 가격