DB 유니크 제약 조건 변경할 때 피해야 할 실수

DB 스키마에 유니크(unique) 제약을 추가하면 기존 데이터가 제약을 위반할 수 있다. 그래서 스키마 변경 전에 현재 데이터가 제약 조건을 만족하는지 확인하고, 변경 후에도 의도한 대로 작동하는지 검증해야 한다.

제약 조건이 필요한 이유 파악하기

Unique 제약을 추가하는 이유를 명확히 한다. 이메일 주소 중복 방지? 세션 토큰 고유성 보장? 목적이 명확하면 제약이 올바른지 판단하기 쉽다.

기존 데이터 검증

제약을 추가하기 전에 기존 데이터가 이미 해당 조건을 만족하는지 확인한다.

npx prisma validate
npx prisma migrate status

# 직접 쿼리로 중복 확인
SELECT email, COUNT(*) FROM users GROUP BY email HAVING COUNT(*) > 1;

마이그레이션 작성과 검증

Prisma 스키마에 제약을 정의하고 마이그레이션 파일을 생성한다. 생성된 SQL이 의도한 대로인지 반드시 검토한다.

• 확인할 것: 스키마 정의, 생성된 마이그레이션 SQL, 제약 이름
• 비교 기준: 정상 마이그레이션과의 차이
• 기록할 것: 마이그레이션 파일명, 실행 결과, 에러 메시지

테스트 환경에서 먼저 시도

로컬 DB에서 마이그레이션을 실행해보고 제약이 제대로 작동하는지 확인한다. 이후 운영 서버에 적용한다.

npx prisma migrate dev --name add_unique_email

데이터 일관성 확인

제약을 추가한 후 쿼리와 응답이 기대한 대로 작동하는지 확인한다. 특히 중복 데이터를 입력했을 때 적절한 에러가 반환되는지 테스트한다.

1. 재현 조건: 제약을 위반하는 데이터 입력
2. 예상 결과: 데이터베이스 에러 발생
3. 실제 결과: 애플리케이션에서 받는 에러 메시지

완료 기준

한 번에 하나의 제약만 추가하고, 각 단계마다 검증하는 방식으로 진행해야 문제 추적이 간단하다. 여러 제약을 동시에 변경하면 어느 것이 문제인지 알기 어렵다.