배포 실패를 유발한 Liquibase checksum 검증을 복구한다

[NaMinhyeok]

배경

Railway production 배포가 두 단계에서 깨지고 있었습니다.

• 최신 배포는 Gradle wrapper가 gradle-9.4.0-bin.zip을 받는 중 10초 read timeout으로 build 단계에서 실패했습니다.
• 그 직전 배포들은 Spring Boot 기동 중 Liquibase validation에서 13-room-game-cleanup changeset checksum 불일치로 종료되어 /actuator/health가 끝까지 healthy가 되지 못했습니다.

Supabase production DB의 production.databasechangelog에는 13-room-game-cleanup이 이미 9:ab793f9c89fa3ff8af0afacad5e1391f checksum으로 실행된 기록이 있었습니다. 이후 같은 changeset SQL이 수정되면서 현재 코드의 checksum과 production DB의 저장 checksum이 달라진 것이 healthcheck 실패의 직접 원인이었습니다.

변경 사항

• 13-room-game-cleanup changeset에 production DB에 이미 기록된 checksum을 validCheckSum으로 명시했습니다.
• 기존 SQL의 COALESCE(player_rows.position, '') 변경은 유지했습니다. fresh DB나 레거시 데이터 검증에서 null position을 더 안전하게 처리하는 의도는 보존하고, 이미 운영에 적용된 checksum만 허용하는 방식입니다.
• Gradle wrapper의 networkTimeout을 10초에서 120초로 늘려 Railway build 환경의 일시적인 distribution 다운로드 지연에 덜 취약하게 했습니다.
• production에 기록된 checksum이 계속 유효하게 유지되는지 검증하는 회귀 테스트를 추가했습니다.

AS-IS

• production DB에는 old checksum이 저장되어 있는데 코드의 changeset checksum은 달라져 Liquibase validation이 실패했습니다.
• Railway build에서 Gradle distribution 다운로드가 10초 이상 지연되면 앱 실행 전 build 단계에서 실패했습니다.

TO-BE

• Liquibase가 production DB에 저장된 old checksum을 유효한 checksum으로 인정해 부팅 validation을 통과할 수 있습니다.
• fresh DB는 현재 changeset SQL을 그대로 실행하므로 null position 보정 동작을 유지합니다.
• Gradle wrapper 다운로드 지연으로 인한 build 실패 가능성을 줄입니다.

검증

• ./gradlew test --tests com.naminhyeok.fantazzk.LiquibaseChecksumTest
• ./gradlew check
• ./gradlew integrationTest

리뷰 포인트

• 이미 production에 적용된 changeset을 원복하지 않고 validCheckSum으로 이전 checksum을 허용하는 방향이 맞는지 봐주세요.
• Gradle wrapper timeout을 120초로 늘린 값이 Railway build 환경에서 충분한지 봐주세요.