서버에서 unique 제약 위반 문제 해결

운영 중 unique 제약 위반 에러가 발생하면 먼저 무작정 데이터를 삭제하지 말고 현상을 파악해야 한다. 검색으로 들어온 상황이라면 같은 문제가 반복될 가능성이 높으니 원인을 정확히 파악해야 한다.

에러 로그 확인

Unique 제약 위반 에러가 발생했을 때 로그에 나타나는 정보를 수집한다.

sudo journalctl -n 80

또는 애플리케이션 로그에서:

• 어느 테이블의 어느 컬럼 조합이 중복되었는지
• 중복된 값이 정확히 무엇인지
• 언제 발생했는지

이 정보들을 기록해두면 다음 단계를 결정할 수 있다.

문제 상황 정리

현재 상황을 한 줄로 요약해본다:

• 새로운 데이터 INSERT할 때인지
• 기존 데이터 UPDATE할 때인지
• 특정 사용자에게만 발생하는지
• 모든 사용자에게 발생하는지

상황을 명확히 하면 원인의 범위가 좁혀진다.

데이터베이스에서 직접 확인

실제 테이블에서 중복 데이터가 있는지 확인한다. PostgreSQL 기준:

# 테이블 상태 확인
psql "$DATABASE_URL" -c "\d table_name;"

# 중복된 값 찾기
psql "$DATABASE_URL" -c "SELECT column_name, COUNT(*) FROM table_name GROUP BY column_name HAVING COUNT(*) > 1;"

# 구체적인 레코드 확인
psql "$DATABASE_URL" -c "SELECT * FROM table_name WHERE column_name = 'duplicate_value';"

이 결과로 정확히 어디가 문제인지 파악할 수 있다.

포트와 권한 확인

데이터베이스 연결 자체에 문제가 있을 수 있다.

# 포트 상태 확인
sudo ss -lntp | grep postgres

# 디스크 여유 확인 (unique constraint는 디스크가 찬 경우에도 발생)
df -h

# 데이터베이스 권한 확인
psql "$DATABASE_URL" -c "\du"

권한이나 환경 확인

배포 직후 발생했다면 데이터베이스 마이그레이션이 제대로 적용되지 않았을 가능성도 있다.

npx prisma migrate status
npx prisma migrate deploy

임시 해결과 근본 원인

급할 때는 한 가지 큰 실수를 피해야 한다: 데이터를 먼저 수정하지 마라. 로그에 기록해두고 애플리케이션 로직을 먼저 확인한다.

1. 원인: 같은 조건에서 왜 중복 입력이 생기는가?
2. 범위: 몇 개 레코드인가? 어느 기간에 발생했는가?
3. 대책: 중복 방지 로직을 코드에 추가하거나, 데이터베이스 레벨에서 처리할 것인가?
4. 검증: 수정 후 같은 상황이 반복되지 않는지 확인

이 순서대로 진행하면 다음 번에는 훨씬 빠르게 대응할 수 있다.