Git에서 리소스 정의를 삭제한 뒤 Argo CD로 동기화하려 합니다. 클러스터에서 무엇이 삭제될 수 있고, 문제가 생겨 Git을 되돌리면 어디까지 복구되나요?

Argo CD의 prune은 Git의 원하는 리소스 목록에서 사라진 객체를 클러스터에서도 삭제하는 동작입니다. 따라서 YAML 파일을 지운 것보다 영향이 큽니다. Deployment나 ConfigMap처럼 재생성 가능한 객체도 있지만, Namespace·PVC·Secret·외부 시스템을 가리키는 설정처럼 삭제가 데이터 손실이나 서비스 중단으로 이어지는 객체도 있습니다. Git을 revert하면 예전 선언을 다시 적용할 수 있을 뿐, 이미 삭제된 데이터와 외부 효과가 자동으로 되살아나는 것은 아닙니다.

먼저 삭제 이유가 의도적인 폐기인지 이름 변경인지부터 구분하겠습니다. Kubernetes 리소스의 metadata.name을 바꾸면 다른 객체를 만드는 것이므로, 추적된 옛 객체의 삭제와 새 객체의 생성으로 처리될 수 있습니다. 반면 Git 파일명만 바꾸고 객체 식별자가 같다면 같은 변경이 아닙니다. 추적 방식과 metadata 정보, 애플리케이션 경계가 달라지면 예상하지 않은 prune이 나올 수 있습니다. sync 전에 diff에서 삭제 목록을 확인하고, 영향이 큰 객체는 수동 승인을 요구하거나 보호 정책으로 자동 prune 범위에서 제외하겠습니다. 단, 삭제를 막기만 하면 사용하지 않는 리소스와 권한·비용이 계속 남으므로 누가 어떤 조건에서 정리할지도 함께 정합니다.

선언의 복구와 데이터의 복구는 다릅니다

Git을 이전 커밋으로 되돌리면 Argo CD는 예전 Deployment, Service, ConfigMap 같은 선언을 다시 만들거나 수정할 수 있습니다. 그러나 PVC가 삭제됐고 underlying volume도 reclaim 정책에 따라 제거됐다면 YAML을 되돌려도 그 안의 데이터는 돌아오지 않습니다. Secret을 폐기하거나 외부 클라우드 자원을 삭제한 경우도 마찬가지입니다. DB 스키마를 바꾼 뒤 앱 버전만 되돌리면 구버전이 새 데이터 형식을 읽지 못할 수 있고, 암호화 키를 회수한 변경은 오히려 되돌리지 않는 편이 안전할 수 있습니다. 그래서 롤백 계획에는 리소스 선언, 애플리케이션 이미지, DB 호환성, 백업 복원, 외부 자원의 되돌림 가능성을 각각 적습니다.

예를 들어 orders-pvc를 실수로 prune했다고 하겠습니다. 첫 조치는 자동 sync를 멈추고 추가 삭제를 막은 뒤, PV와 스토리지 백엔드의 상태·reclaimPolicy·스냅샷을 확인하는 것입니다. PVC YAML을 다시 적용하는 것만으로 빈 새 볼륨이 붙을 수 있으므로 기존 데이터가 어느 식별자로 남아 있는지 확인하지 않고 재생성하지 않겠습니다. 복원된 DB가 최신 주문을 어디까지 포함하는지는 RPO에 따라 검증하고, 앱이 복원 시점 이후 요청을 어떻게 다룰지도 정합니다.

삭제 순서와 rollout을 통제합니다

의존 관계가 있는 리소스를 한 번에 prune하면 Service가 먼저 사라지거나, Secret 삭제 뒤 새 Pod가 재시작되는 식의 연쇄 장애가 생길 수 있습니다. 리소스별 보호, sync wave, 수동 sync, 작은 대상 집단 적용을 조합해 영향 범위를 줄이겠습니다. 다만 Argo CD의 순서 제어는 DB 트랜잭션이나 외부 API의 보상을 제공하지 않습니다. 삭제가 일부 진행된 뒤 sync가 실패하면 이미 실행된 삭제를 별도의 복구 절차로 되돌려야 합니다.

긴급 롤백에서는 최신 Git이 다시 자동 적용하지 않도록 자동 sync를 일시 정지하거나 롤백 커밋을 명확한 기준으로 만들고, 실제 대상 revision과 배포 진행 상태를 확인합니다. 복구 성공 기준은 Git이 예전 커밋을 가리키는지가 아니라 필요한 리소스가 준비되고 데이터가 허용된 시점으로 복원되며 오류율이 정상화되는지입니다. 이처럼 선언에서 사라진 객체를 실제 클러스터에서 제거하는 정리 동작을 prune이라고 부릅니다.