[Git·GitOps 24] Git·CI/CD·GitOps 운영 흐름 완성하기: 장애별 판단과 복구

명령을 많이 외워도 장애가 생긴 위치를 구분하지 못하면 같은 작업을 반복하게 됩니다. 푸시 실패는 Git 서버 연결을, CI 실패는 실행 환경과 테스트를, 배포 실패는 선언과 실제 상태를 봐야 해요. 마지막 편에서는 앞에서 만든 구성의 경계를 하나의 운영 흐름으로 연결합니다.

앞의 두 실습은 역할이 다릅니다. Python 저장소는 Git과 CI를, nginx 배포 저장소는 Kubernetes 조정을 학습하는 예제입니다. 실제 앱으로 확장할 때에는 CI가 만든 이미지를 레지스트리에 보관하고, 확인한 digest를 배포 저장소의 PR로 보내는 연결을 추가합니다.

Git·GitOps 전체 연재 · 24 / 24

이 글의 목차

사람이 변경하고 자동화가 검사하는 경로

개발자 브랜치 → PR 리뷰 → main
                         ↓
                   CI 테스트·빌드
                         ↓
               레지스트리의 고정 digest
                         ↓
              배포 설정 PR → 환경 승인
                         ↓
           Argo CD 비교·동기화 → 상태 관찰

CI가 배포 저장소에 변경을 제안할 때도 별도 봇 계정과 최소 권한을 사용합니다. main에 무조건 직접 쓰는 토큰보다 제한된 브랜치와 리뷰 경로가 변경 이유를 확인하기 쉽습니다. CI 결과물을 신뢰하는 기준과 앱의 건강 상태를 판단하는 기준도 분리합니다.

증상부터 담당 구간을 좁힌다

증상	확인할 구간	첫 확인
push 인증 거절	PC → Git 서버	URL·사용자·키·저장소 권한
CI checkout 실패	runner → Git 서버	실행 노드·known_hosts·읽기 키
테스트 실패	코드와 빌드 환경	해당 커밋·도구 버전·실패 테스트
ComparisonError	Argo CD → 저장소·렌더링	인증·브랜치·경로·YAML
OutOfSync 유지	동기화 정책	자동화 여부·프로젝트 권한·이벤트
ImagePullBackOff	노드 → 레지스트리	이미지 경로·digest·인증·네트워크

OutOfSync는 차이가 있다는 상태이고 Healthy는 리소스 건강 상태입니다. Synced여도 앱이 정상이라고 단정할 수 없고, Healthy여도 Git과 차이가 있을 수 있습니다. 두 상태와 실제 사용자 요청을 함께 봅니다.

Git만 보관하면 복구되지 않는 것들

로컬 이력을 이동하거나 추가 사본을 만들 때 git bundle을 사용할 수 있습니다. Git 객체와 참조를 묶어 오프라인 전달할 수 있지만, Gitea DB와 LFS 객체, 이슈 첨부파일, 비밀 저장소를 대체하지 않습니다.

cd ~/git-lab/gitops-demo
git bundle create ../gitops-demo.bundle --all
git bundle verify ../gitops-demo.bundle
git clone ../gitops-demo.bundle ../gitops-demo-recovery
git -C ../gitops-demo-recovery fsck --full

bundle 복원 저장소에서 필요한 브랜치와 태그가 있는지 확인합니다. 미추적 파일과 커밋하지 않은 작업은 별도로 보관합니다. 서버 전체는 16편의 DB·파일·설정 복원으로 시험하고, 클러스터의 데이터는 스토리지·DB 백업 절차로 다룹니다.

긴급 변경은 재개 조건까지 기록한다

운영 중 수동 수정이 필요하면 영향을 받는 Application과 자동 조정 정책을 확인합니다. 승인된 범위에서 자동화를 잠시 멈췄다면 중단 시각, 실제 조치, Git에 반영한 커밋, 정상 확인과 재개 담당자를 남깁니다. 자동화가 다시 켜질 때 어느 상태가 적용될지 설명할 수 있어야 합니다.

코드의 문제는 PR과 revert로, 결과물 문제는 검증된 이전 digest로, 데이터 손상은 데이터 복구 계획으로 대응합니다. 무조건 reset --hard, 강제 푸시, 전체 재설치를 실행하면 원인과 복구 자료를 함께 잃을 수 있습니다.

운영 기록에는 네 가지 식별자를 남긴다

배포마다 소스 커밋, CI 실행, 결과물 digest, 배포 설정 커밋을 연결합니다. 여기에 승인과 배포 결과를 덧붙이면 장애 시 코드와 설정 중 어디가 바뀌었는지 추적하기 좋아요. 이 정보에 실제 비밀번호나 토큰을 포함하지 않습니다.

처음 사용하는 팀이라면 작은 서비스 하나, 개발 namespace 하나에서 시작해 보세요. 변경 검토, 테스트 실패, 잘못된 설정의 revert, 서버 복원까지 한 번씩 실행한 뒤 운영 범위를 넓히는 편이 판단 근거를 남기기 쉽습니다. 도구가 늘어나는 속도보다 복구 경로를 이해하는 속도를 기준으로 진행합니다.

오프라인 이력 보관은 git bundle, Argo CD의 상태 개념은 Core Concepts, 서비스 복구는 Gitea Backup and Restore에서 확인할 수 있습니다.

이전 글 · [Git·GitOps 23] 비밀 값 관리: Secret의 base64와 SOPS·age 암호화 · 연재 목록과 예제 파일