배포 후 사용자 데이터가 사라질 때

배포 후 긴급한 버그가 발생하면 바로 이전 버전으로 롤백해야 할 때가 있다. 하지만 그 과정에서 사용자가 입력한 데이터가 사라질 수 있다. 이런 상황을 어떻게 진단하고 대응할지 정리했다.

배포 순서와 영향 범위 정리하기

문제가 생겼을 때 무엇부터 확인할지는 배포 방식에 따라 다르다. 데이터베이스도 함께 마이그레이션했는지, 아니면 코드만 배포했는지에 따라 영향 범위가 달라진다.

• 먼저 볼 값: 배포 시간, 변경 사항, 롤백 시점
• 같이 비교할 값: 배포 전 사용자 데이터, 배포 후 데이터
• 기록해둘 것: 배포 로그, 데이터베이스 마이그레이션 기록, 사용자 피드백

데이터가 실제로 사라졌는지 확인

데이터가 안 보일 수도 있고, 실제로 지워졌을 수도 있다. 데이터베이스에서 직접 조회해서 데이터가 존재하는지 확인한다.

# 데이터베이스 접속
psql -d mydb -U user

# 데이터 조회
SELECT * FROM users WHERE id = 'user_id';

# 최근 데이터 확인
SELECT * FROM audit_log ORDER BY created_at DESC LIMIT 10;

캐시 때문에 안 보이는 건 아닌지 확인

브라우저나 서버 캐시 때문에 구 데이터가 계속 표시될 수도 있다. 캐시를 무효화하고 최신 데이터를 불러온다.

# 브라우저에서
# Ctrl+Shift+Delete (또는 Cmd+Shift+Delete) 로 캐시 삭제

# 또는 서버 캐시 확인
redis-cli FLUSHALL  # 조심스럽게 사용

마이그레이션 롤백이 제대로 되었는지 확인

데이터베이스 마이그레이션이 실패했거나 부분적으로 롤백되었을 수 있다. 현재 스키마가 뭔지 확인한다.

# 현재 마이그레이션 상태 확인
db:migrate:status

# 테이블 스키마 확인
\d table_name

사용자 피드백 수집하기

여러 사용자가 같은 문제를 겪었다면, 그들의 계정이나 특정 시점의 데이터를 확인한다. 특정 사용자만 문제가 있다면 그들의 계정 설정을 살펴본다.

백업에서 데이터 복구하기

데이터가 실제로 지워졌다면, 배포 전의 백업에서 복구할 수 있다. 백업의 시간과 무결성을 확인한 다음, 안전하게 복구한다.

# 백업 목록 확인
ls -ltr backups/

# 특정 백업에서 데이터 확인
psql -d backup_db -f backup_file.sql

향후 예방 방법

같은 일이 반복되지 않도록 배포 전에 체크리스트를 만든다. 마이그레이션 테스트, 데이터 백업 확인, 롤백 계획 수립 같은 것들을 습관화한다.

배포 문제는 속도보다 안정성이 중요하다. 데이터가 사라질 가능성이 있다면, 배포 전에 충분히 검토하고 필요하면 사용자에게 공지해야 한다.