두 사용자가 같은 계정명을 동시에 가입할 때 사전 중복 조회가 모두 통과하는 이유와 DB 고유 제약 처리 방법은 무엇인가요?

사전 중복 조회와 삽입 사이에 다른 요청이 들어올 수 있으므로, 두 요청이 모두 ‘없음’을 읽고 같은 계정명을 삽입하는 것은 정상적인 경쟁 결과입니다. 애플리케이션의 SELECT는 사용자를 위한 빠른 안내일 뿐 최종 유일성 보장이 아닙니다. 계정명이 절대 유일해야 한다면 DB에 고유 제약 또는 고유 인덱스를 만들고, 실제 삽입·갱신 시 제약이 판정한 한 건만 성공시키겠습니다.

유일성의 의미를 DB와 맞춥니다

‘같은 이름’의 정의부터 정합니다. 대소문자 무시 여부, 앞뒤 공백, Unicode 정규화, 로케일별 비교, 테넌트 범위, 탈퇴 계정 재사용 여부가 애플리케이션과 DB에서 같아야 합니다. 표시용 display_name과 비교용 정규화 키를 분리하고 비교용 키에 고유 제약을 둘 수 있습니다. PostgreSQL의 collation·expression/partial index, SQL Server의 collation·filtered index, MySQL의 collation·generated column 등 표현 방법과 NULL·삭제 행 동작이 다르므로 엔진별로 확인합니다.

동시 요청에서 DB는 하나의 제약 검사를 직렬화해 한 요청은 성공하고 다른 요청은 고유 위반으로 실패시키거나, 엔진·격리·삽입 형태에 따라 대기 후 충돌을 반환합니다. 오류 코드를 문자열로 비교하지 말고 드라이버의 분류와 제약 이름을 확인해 정상적인 충돌 경로로 처리하겠습니다. 사전 조회가 통과했더라도 삽입 결과가 최종 판정입니다.

충돌, 재시도, 관련 변경을 구분합니다

고유 오류가 났다고 무조건 기존 계정으로 성공 처리하면 다른 사용자의 이름 충돌을 계정 연결이나 데이터 노출로 바꿀 수 있습니다. 동일한 논리 요청의 재시도인지, 실제로 다른 사용자가 먼저 차지했는지 요청 ID·인증 주체·멱등 기록으로 구분합니다. 회원 행과 프로필·환영 이벤트를 하나의 트랜잭션으로 만들었다면 고유 오류 시 관련 변경도 함께 롤백되거나, outbox에 기록된 상태가 무엇인지 확인해야 합니다.

소프트 삭제에서 삭제된 이름의 재사용을 허용할지 정하고, 허용한다면 활성 행에만 유일성을 적용하는 부분/필터 인덱스나 엔진이 지원하는 대체 모델을 사용합니다. 여러 지역에서 같은 이름을 동시에 생성하는 구조는 지역별 DB 고유 제약만으로 전역 유일성을 만들 수 없으므로 단일 권위 저장소, 예약 서비스, 충돌 조정 중 하나가 필요합니다. 테스트는 동일 키의 동시 삽입, 대소문자·공백 변형, 재시도와 장애, 테넌트 경계를 실행해 정확히 한 건만 성공하고 실패 요청이 부수 효과를 남기지 않는지 확인하겠습니다.

고유 제약을 추가하는 작업 자체도 기존 중복을 먼저 정리해야 하며, 정리 기준이 업무적으로 승인되어야 합니다. 중복을 임의로 삭제하면 주문·결제·로그인 연결이 끊길 수 있으므로 대표 행 선택과 참조 이전을 먼저 처리합니다. 제약 생성 중 기존 쓰기와의 잠금·검증 비용을 엔진별로 확인하고, 온라인 생성이 가능한 경우에도 실패 시 재개·롤백 절차를 둡니다. 테스트는 오류 메시지가 아니라 최종 데이터와 부수 효과를 기준으로 판단하겠습니다.