새 버전의 앱이 변경된 DB 스키마를 요구합니다. Argo CD에서 마이그레이션과 앱 배포 순서를 어떻게 정하고, 앞 단계가 실패하면 어떻게 해야 하나요?

sync wave는 리소스를 적용하는 순서를 나누고, hook은 동기화의 특정 단계에서 Job 같은 작업을 실행하는 수단입니다. DB 스키마를 바꾼 뒤 앱을 배포해야 한다면 migration을 앱보다 먼저 실행하도록 구성할 수 있지만, 순서만 맞춘다고 호환성과 롤백이 해결되지는 않습니다. 저는 먼저 구버전과 신버전이 함께 실행되는 기간을 정의하고, 그 기간에 양쪽 코드가 읽고 쓸 수 있는 확장 방식으로 migration을 설계하겠습니다.

가장 안전한 전환은 보통 새 컬럼이나 새 테이블을 먼저 추가하고, 구버전이 깨지지 않는 형태로 데이터를 채운 뒤, 앱이 새 구조를 읽도록 바꾸고, 모든 구버전이 사라진 후에 옛 구조를 제거하는 단계입니다. 긴 백필을 하나의 동기화 hook 안에서 끝날 때까지 기다리면 Argo CD sync가 오래 걸리고 재시도 시 부하가 반복될 수 있습니다. 구조 변경과 대량 이관을 분리해 각각 완료 기준과 소유자를 두겠습니다. 이처럼 구버전과 신버전이 동시에 통과할 수 있게 만드는 전환 전략을 확장·축소 마이그레이션(expand-and-contract migration)이라고 부릅니다.

wave와 hook의 책임을 분리합니다

짧은 구조 변경 Job을 PreSync hook으로 두면 hook이 성공한 뒤 앱 리소스가 적용되도록 만들 수 있습니다. 하지만 Job의 성공 코드는 명령이 종료됐다는 뜻이지 모든 행의 백필 검증이나 새 앱의 동작 검증까지 뜻하지 않습니다. hook이 무엇을 보장하는지 명확히 하겠습니다. 예를 들어 컬럼이 존재하고 기본 제약이 적용됐는지까지만 보장한다면, 데이터 백필 완료와 읽기 전환은 별도 상태로 표시해야 합니다. sync wave는 wave 번호와 리소스 상태를 바탕으로 다음 단계를 진행하게 하는 순서 도구이고, 애플리케이션의 의미적 준비나 외부 DB의 원자성을 대신하지 않습니다.

Hook은 재실행될 수 있습니다. 네트워크 오류로 Argo CD가 실패를 확인하지 못했거나, Job은 성공했지만 상태 반영 전에 컨트롤러가 재시작할 수 있기 때문입니다. ALTER TABLE ADD COLUMN처럼 이미 적용된 상태에서도 안전하게 끝나거나, migration 버전 테이블을 조건부로 검사하고 한 번만 전진하도록 만들겠습니다. 백필은 범위별 checkpoint, 재개 가능한 cursor, 행 버전 조건을 두고, 부분 성공 뒤 다시 실행해도 중복 변환이나 잘못된 값을 만들지 않아야 합니다.

실패와 롤백의 경계를 먼저 정합니다

PreSync hook이 실패하면 새 앱을 적용하지 않고 기존 앱을 유지하는 정책이 유용합니다. 다만 hook이 이미 컬럼을 추가하거나 일부 데이터를 바꾼 뒤 실패했을 수 있습니다. 그러므로 실패 시 자동으로 DB를 역변경한다고 가정하지 않고, 부분 적용 상태를 조사해 재시도할지 수동 복구할지 결정하겠습니다. 새 앱이 이미 배포된 뒤 기능 오류가 나면 앱 이미지는 되돌릴 수 있어도 DB의 확장 변경은 그대로 남겨 구버전과 호환성을 유지하는 편이 일반적입니다. 파괴적인 컬럼 삭제나 형식 변환은 모든 읽기·쓰기 경로가 끊긴 뒤 별도 승인으로 진행합니다.

검증에서는 이미 완료된 hook의 재실행, DB 연결 단절 중단, 일부 백필 후 재개, 구버전과 신버전의 동시 쓰기, 앱 rollback을 시험하겠습니다. 관찰할 것은 sync 결과만이 아니라 hook 로그와 migration 버전, 행별 오류, 쿼리 부하, 구·신 버전 오류율입니다. 앞 단계가 실패하면 다음 wave를 막되, 이미 발생한 DB 변경의 범위와 되돌릴 수 없는 효과까지 분리해서 설명하는 것이 핵심입니다.