내 6 노드 K3s 클러스터 는 75 개 ArgoCD 애플리케이션 을 GitOps 로 굴린다. git push 를 하면 사람 손 없이 프로덕션 까지 반영된다. 편하다. 그런데 누군가 이런 질문 을 했다:

“배포 는 편한데… 운영 안전성 에서 좀 위험 한 거 아냐?”

맞는 지적 이다. 이 글 은 그 질문 에 대한 정직한 답 — 자동배포 가 왜 위험 할 수 있고, 어떻게 안전 하게 굴리는지 를 내 실제 설정 과 함께 정리.

1. 무엇 이 위험 한가

“git push → 자동 prod” 를 아무 안전장치 없이 켜면, 다음 이 즉시 사고 로 이어진다:

  • 잘못된 커밋 이 바로 라이브 — 오타 하나, 잘못된 env 값 이 리뷰 없이 프로덕션 에 반영
  • 롤백 이 안 먹는 느낌 — selfHeal 이 켜져 있으면, 급해서 kubectl 로 손 댄 것 도 몇 초 뒤 git 상태 로 되돌려 버린다
  • prune 사고 — 자동 삭제(prune) 가 켜져 있는데 git 에서 리소스 를 지우면, 클러스터 에서도 진짜 삭제
  • 연쇄 장애 — 공통 차트 를 잘못 바꾸면 그걸 참조 하는 모든 앱 이 동시에 깨짐

실제 로 나 도 오늘 홈페이지 를 고치다 kubectl edit 한 게 몇 초 뒤 되돌아가서 당황 했다. 범인 은 selfHeal. “수동 수정 이 사라진다” 는 GitOps 의 기능 이지 버그 가 아니다 — git 이 유일한 진실 이라는 뜻.

2. 그럼 GitOps 가 나쁜가? — 아니다, 안전장치 없는 자동화 가 나쁘다

여기서 헷갈리면 안 된다. 위험한 건 GitOps 가 아니라 “리뷰·게이트 없이 auto-sync 만 켠 상태” 다. GitOps 는 오히려 안전성 을 높이는 도구다:

  • 모든 변경 이 git 에 기록 → 누가·언제·무엇 을 바꿨는지 100% 추적. git revert 로 즉시 롤백
  • 클러스터 = git → “지금 프로덕션 에 뭐가 떠 있나?” 를 코드 로 안다. 손으로 몰래 바꾼 drift 가 없음
  • 재현 가능 → 클러스터 가 통째로 날아가도 git 에서 그대로 복구

즉 GitOps 는 양날 의 칼 이다. 자동화 의 속도 를 얻는 대신, git 에 들어가는 것 을 통제 해야 한다. 통제 지점 을 git 앞단(PR) 으로 옮기는 게 핵심.

3. 안전 하게 굴리는 7 가지 장치

① PR 리뷰 를 필수 로 — main 직접 push 금지

git push → prod 에서 위험한 건 push 가 아니라 리뷰 안 된 코드 가 main 에 들어가는 것. main 브랜치 를 protected 로 걸고 PR + 승인 을 거치게 하면, “자동배포” 의 방아쇠 앞 에 사람 게이트 가 생긴다.

② 스테이징 을 먼저 통과

prod 로 가기 전 staging 환경 에 먼저 sync. 내 클러스터 도 academy-staging, settlement-staging 을 따로 둔 이유다. 스테이징 에서 깨지면 prod 는 건드리지 않는다.

③ prune 은 기본 off

리소스 자동 삭제 는 위험 하다. 내 75 개 앱 중 71 개 가 prune: false — git 에서 지워도 클러스터 에서 자동 삭제 안 함. 삭제 는 의도적으로 만.

④ selfHeal 은 이해 하고 켜기

selfHeal: true (내 경우 68/75 앱) 는 drift 를 자동 교정 — 강력 하지만 수동 hotfix 를 덮는다. 그래서 긴급 수정 도 git 을 통해서 하는 습관 이 필요. 진짜 급하면 잠깐 selfHeal 을 끄고 손 댄 뒤 git 에 반영 하고 다시 켠다.

⑤ Health check 로 나쁜 배포 를 감지

ArgoCD 는 리소스 의 health 를 본다. readiness probe 가 실패 하면 앱 이 Degraded 로 뜬다. 여기에 알림 을 붙이면 “배포 됐는데 안 뜬다” 를 바로 안다.

⑥ 이미지 태그 를 고정 (latest 금지)

latest 를 쓰면 같은 git 상태 인데 다른 이미지 가 뜰 수 있다 — GitOps 의 재현성 이 깨진다. 커밋 SHA 나 시맨틱 버전 태그 로 고정 해서, git 이 이미지 까지 결정 하게.

⑦ Sync window 로 시간 통제

새벽·주말 처럼 대응 못 하는 시간 에는 자동 sync 를 막을 수 있다. 금요일 밤 자동배포 후 아무도 안 볼 때 터지는 걸 방지.

4. 내 클러스터 의 실제 트레이드오프

숫자 로 보면 내 선택 이 드러난다:

설정 값 의미
총 ArgoCD 앱 75 전부 GitOps
자동 sync 75 / 75 수동 sync 앱 0 개 — 속도 우선
selfHeal 68 / 75 drift 자동 교정 (강한 일관성)
prune 4 / 75 만 on 자동 삭제 는 대부분 차단 (안전)

즉 나는 “자동 sync + selfHeal 로 속도·일관성 은 취하되, prune 은 막아서 삭제 사고 는 방지” 하는 쪽을 택했다. 홈랩 이라 내가 유일한 운영자 라서 PR 게이트 는 느슨 하지만, prod 서비스 가 늘면 ①②(PR·스테이징) 를 조여야 하는 지점 이 온다.

5. 한 줄 정리

GitOps 자동배포 의 위험 은 “자동” 이 아니라 “게이트 없음” 에서 온다.

  • git push → prod 자체 는 문제 가 아니다. 무엇 이 git 에 들어가는지 를 통제 하면 된다.
  • 통제 지점 을 PR 리뷰 · 스테이징 · prune off · 이미지 태그 고정 으로 옮기면, 자동화 의 속도 와 운영 안전성 을 동시에 가진다.
  • selfHeal 이 수동 수정 을 덮는 건 버그 가 아니라 “git 이 유일한 진실” 이라는 GitOps 의 약속 이다. 그 약속 을 이해 하고 쓰면 오히려 drift 없는 안전한 운영 이 된다.

편의 와 안전 은 대립 하지 않는다. 게이트 를 git 앞 으로 옮기는 것 — 그게 답 이다.