회원탈퇴를 어떻게 설계할까

현재 상황

현재 프로젝트에서는 회원 탈퇴를 Soft Delete로 구성해놓았다.

그 이유는 해당 프로젝트의 핵심 기능인 '소비 심판'이 유저 간 발생하는 이벤트이다보니 아직 개발 전에 유저를 Hard Delete 했을 때 발생 가능한 이펙트를 예상할 수 없기 때문이다.

그리고 정책적으로 탈퇴한 회원 간 소비 심판을 그대로 보여줄지, 보여주지 않을지 정하지도 않았고 보여준다면 어떻게 보여줘야 할지 등의 결정이 되어있지 않다.

그래서 Soft Delete로 회원 탈퇴를 미리 방어해놓는 것이 추후 정책과 유연하게 설계를 이어갈 수 있다 생각했다.

유저 엔티티에 아래 컬럼을 추가하고, 회원탈퇴 로직을 작성했다.

@Table(uniqueConstraints = {
    @UniqueConstraint(
        name = "uk_user_provider_provider_id",
        columnNames = {"provider", "provider_id", "is_deleted"}
    )
})
@SQLRestriction("is_deleted = 0")

@SQLRestriction("is_deleted = 0")를 사용해, 기본 조회 시 탈퇴한 유저가 자동으로 제외되도록 구성했다. 이로 인해 서비스 코드에서는 '삭제 여부'를 직접 고려하지 않아도 되는 장점이 있다.

문제 상황

문제는 회원가입 -> 탈퇴 -> 회원가입 -> 탈퇴(유니크 예외💥)라는 상황이 생길 수 있다는 것이다.

원인 분석

현재 유저는 Soft Delete를 위해 is_deleted 컬럼을 두고, 조회 시에는 `@SQLRestriction("is_deleted = 0")`로 삭제되지 않은 유저만 기본 조회되도록 구성했다.

또한 재가입을 위해 유니크 제약을 (provider, provider_id, is_deleted)로 확장했다. 이 구조에서는 다음이 가능하다.
- 활성 유저: (google, 123, 0) 1개만 존재 가능
- 탈퇴 유저: (google, 123, 1) 또한 1개만 존재 가능

즉 탈퇴를 한 번 한 뒤에는 (provider, provider_id, 1) 레코드가 DB에 남아있게 되고, 다시 가입하면 (provider, provider_id, 0)이 새로 생긴다.

여기서 다시 탈퇴하면, 새로 가입한 활성 유저가 (provider, provider_id, 1)로 변경되려고 하는 순간 이미 기존에 있던 탈퇴 레코드와 유니크 충돌이 발생한다.
- 회원가입: (p, id, 0) 생성
- 탈퇴: (p, id, 1)로 변경 (OK)
- 재가입: (p, id, 0) 새로 생성 (OK)
- 재탈퇴: 새 활성 유저를 (p, id, 1)로 변경하려 함 → 기존 (p, id, 1)이 이미 존재 → 유니크 예외 💥

결국 지금 스키마는 “동일 provider/providerId에 대해 탈퇴 이력은 최대 1개만 유지”라는 제약을 만들고 있고, 서비스 플로우(재가입/재탈퇴)와 충돌한다.

---

해결 방향

처음엔 기술적인 해결 방안을 고민해보았다.

 

A) Soft delete 레코드를 “유지하지 않고” 재가입 시 기존 레코드를 복구한다.

이 방식은 같은 provider/providerId로 가입하면 신규 row를 만들지 않고, 기존 탈퇴 유저 정보를 찾아서 is_deleted=false, deleted_at=null로 되돌려 복구한다.

이러면 애초에 row가 2개가 되지 않아 (provider, provider_id, is_deleted) 유니크 충돌이 원천적으로 안 생기기에 유니크 충돌 문제를 해결할 수 있다.

하지만, “과거 계정과 완전히 다른 신규 유저” 개념을 만들기 어렵다.

B) 재가입 후 탈퇴 시 기존 탈퇴 정보를 제거한다.

만약 사용자가 탈퇴 후 재가입을 했으나, 다시 한번 탈퇴를 한다면 이전에 존재하던 탈퇴 정보를 삭제하는 방법이다. 이 경우 하나의 활성 사용자와 하나의 탈퇴 기록을 보장한다는 장점이 있다.

하지만, 앞서 말했듯이 아직 개발 전인 '소비 심판' 기능에서의 발생 가능한 이펙트를 예상할 수 없다.

C) 이력을 통해서만 탈퇴를 관리한다.

기존의 user 테이블은 “현재 상태”만 가지고, 탈퇴 이벤트는 user_withdraw_history에 insert로 남긴다. 이렇게 하면, 유저 재가입/재탈퇴가 반복되어도 유니크 제약과 충돌하지 않는다. 또한 탈퇴에 대한 이력을 따로 남기기에 유저를 추적하기도 편하다.

예시 흐름은 아래와 같다.
- 탈퇴 시: user.is_deleted=true, deleted_at=now()
- 동시에: user_withdraw_history에 (user_id, provider, provider_id, deleted_at …) insert
- 재가입 시
    - 7일 이내면 복구(다시 is_deleted=false)
    - 7일 이후면 기존 user를 삭제 후 신규 user를 생성

여기서 스스로 문제의 본질을 흐리고 있음을 깨달았다.

---

팀 정책으로 먼저 확정해야 하는 질문이다.

문제의 본질을 다시 생각해보면 이 문제는 단순히 “기술적으로 재가입이 가능하게 하자”가 아니라, 재가입 시 어떤 방식으로 애플리케이션이 동작해야 할 것인지(정책) 결정이 선행되어야 한다.

- 재가입을 허용하는가?
- 허용한다면 어느 정도의 유예 기간을 줄건가?
- 탈퇴한 사용자의 데이터를 어떻게 할건가?
- ...

생각해봐야 할 정책이 굉장히 많다. 

이러한 부분들을 고려하지 않은채 기술적인 부분으로만 해결을 하려했던 것이다.

---

결론

현재 구조에서 발생하는 “재탈퇴 유니크 예외”는 구현 실수라기보다, 탈퇴/재가입 정책을 먼저 문제의 본질로 생각하지 못해서 생긴 문제다.

따라서 팀에서 먼저 “재가입을 어떻게 정의할지(복구, 신규 등)”를 논의하는 것이 중요하다고 판단했다.

 

 

그래서 팀원들에게 논의를 요청했고, 정책적으로 정하기엔 시간이 얼마 남지않아 현재는 유저 데이터를 즉시 삭제하는 방향으로 결정되었다.

 

 

개발자는 자신도 모르게 기술적인 해결 방안에 매몰되는 경우가 많은 거 같다. 하지만, 이번 프로젝트를 하면서 문제의 본질은 언제나 코드 안에만 있지 않으며 때로는 정책을 먼저 정의하지 않으면 어떤 기술적 선택도 정답이 될 수 없다는 것을 실감하고 있다.