가입과 프로필 갱신을 UPSERT 하나로 합치려 합니다. 고유 충돌이 나면 기존 행을 바꾸는 것이 항상 안전한가요?

UPSERT는 고유 충돌에 대한 원자적인 삽입·갱신 선택을 표현하지만 충돌한 기존 행을 수정해도 되는지는 별도 정책입니다. 다른 사용자가 이미 쓴 계정명을 새 요청의 프로필로 덮으면 인가 결함이 됩니다.

동작 원리와 전제

충돌 기준이 이메일인지 내부 ID인지, 삭제된 행을 포함하는지와 정규화 규칙을 정합니다. 같은 논리 요청의 반복이면 기존 결과를 반환할 수 있지만 새로운 사용자의 충돌은 정상 거절이어야 합니다. 엔진별 ON CONFLICT·ON DUPLICATE KEY·MERGE의 잠금·반환·동시성 계약을 같다고 가정하지 않습니다.

선택과 실패 처리

갱신 부분에 버전이나 허용 상태 조건이 필요할 수 있습니다. 수량을 더하는 UPSERT는 같은 이벤트를 다시 받으면 또 증가하므로 그 자체로 멱등하지 않습니다. 어떤 컬럼은 최초 생성 시에만 설정해야 하고 다른 컬럼은 입력 null이 기존 값을 지워도 되는지 구분합니다.

구체적인 사례와 검증

프로필 생성에 쓰는 UPSERT와 포인트 누적에 쓰는 UPSERT는 재실행 의미가 다릅니다. 같은 절대 닉네임을 저장하는 동작은 결과가 같을 수 있지만 points=points+10은 반복할 때마다 효과가 늘어납니다. 요청 ID 원장과 함께 처리하지 않으면 단일 SQL이어도 중복 지급이 생깁니다. 또 고유 제약이 여러 개면 충돌한 키가 원래 의도한 대상 식별자인지 확인해야 합니다. 이메일 충돌을 내부 회원 ID 충돌처럼 취급해 다른 계정을 업데이트하면 안 됩니다. 실제 엔진에서 동시 삽입·조건부 갱신의 반환 행과 잠금을 관찰하고 삽입됐는지, 갱신됐는지, 조건이 맞지 않아 아무것도 안 했는지를 명확히 처리합니다.

경쟁 삽입·복수 고유 제약·부분 갱신·재시도와 권한 경계를 시험합니다. 삽입인지 갱신인지 반환값의 의미를 확인하고 관련 outbox가 두 번 생기지 않는지 봅니다. SQL 문장 하나라는 이유로 업무상 중복과 소유권 판단을 생략하지 않겠습니다.