데이터베이스 직접 수정 전 안전한 검증

데이터베이스를 직접 손대는 것만큼 무서운 작업은 없다. 특히 혼자 운영하는 서비스라면 더더욱. 한 번의 잘못된 DELETE 명령이 데이터를 날려버릴 수 있기 때문에, 항상 백업을 먼저 확인하고 단계별로 진행해야 한다.

백업부터 확인하기

실제 수정 작업을 시작하기 전에 백업이 정상인지 반드시 확인하자. 많은 사람들이 이 단계를 건너뛰고 나중에 후회한다.

ls -lh /path/to/backups/

백업 파일의 수정 시간이 최근인지, 파일 크기가 합리적인지 확인해야 한다. 만약 백업이 며칠 전 것이라면 그 이후의 데이터는 복구 불가능하다는 뜻이다.

마이그레이션 상태 점검

Prisma를 쓴다면 마이그레이션 상태를 먼저 봐야 한다:

npx prisma migrate status
npx prisma validate

이미 적용된 마이그레이션과 미적용 마이그레이션을 명확히 파악하면, 데이터 구조의 변화가 있었는지 알 수 있다. 스키마가 이미 변경되었다면 직접 쿼리를 짜기 전에 그 변화를 고려해야 한다.

환경 차이 인식

로컬에서 테스트한 쿼리도 운영 환경에서는 다르게 작동할 수 있다. 데이터 양이 훨씬 많을 수도 있고, 인덱스가 다르게 설정되어 있을 수도 있다. 따라서 운영 DB에서는 항상 트랜잭션을 사용해야 한다:

BEGIN;
UPDATE users SET is_active = false WHERE id = 123;
-- 결과를 확인한 후
COMMIT; -- 또는 ROLLBACK;

확인 기록 남기기

수정 전후로 상태를 기록해두면 나중에 무엇이 바뀌었는지 명확하게 알 수 있다. 영향받는 행의 개수, 변경된 값의 예시, 수정 시간 등을 간단하게라도 남겨두자.

최종 검증

1. 실제로 변경되어야 할 데이터인지 한 번 더 확인한다.
2. 수정 후 영향받은 기능이 제대로 작동하는지 확인한다. (예: 사용자가 로그인할 수 없게 되는 것은 아닌지)
3. 공개 서비스의 화면과 데이터가 일치하는지 본다.

한 번에 여러 설정을 바꾸거나 여러 테이블을 수정하지 말자. 하나씩 천천히 진행하면 문제가 나더라도 원인을 찾기가 훨씬 쉽다.