회원탈퇴 생명주기와 관계 데이터 처리 계획

상태 분리와 취소#

탈퇴는 Auth, 프로필, 공동 채팅, 신고·분쟁, 로그·백업과 외부 처리자를 항목별로 처리해야 한다. 다른 법령상 보존 대상은 별도로 관리하므로 클릭과 완료를 한 transaction으로 합칠 수 없다. ^[2]

반복 요청은 이중 클릭, 응답 유실 재시도, 두 탭·기기와 API replay에서 발생한다. DB는 반복 요청을 거부해 최초 시각을 보존한다. UX는 오류 대신 기존 상태와 최초 시각을 반환하는 idempotent 응답으로 개선한다.

취소는 법적 필수가 아니다. 삭제 job 시작 전까지만 허용하고 시작 뒤에는 재가입 정책을 적용한다. 취소해도 이미 철회된 마케팅 동의는 복구하지 않는다.

탈퇴 후 재가입#

• 요청 단계에서 취소하면 같은 계정을 유지한다.
• 완료 계정은 active로 되돌리지 않는다.
• Auth 삭제 뒤 같은 이메일·소셜 계정으로 가입하면 새 UUID·프로필·온보딩·동의를 만든다.
• 이전 채팅·참여·평가·동의를 새 계정에 자동 연결하지 않는다.
• 제재 우회 방지가 필요하면 별도 비공개 식별자, 근거와 만료일을 정한다. 옛 프로필 전체는 보존하지 않는다.
• 현재는 Auth hard delete가 없어 완료 이메일의 즉시 재가입은 지원되지 않는다. ^[3]

관계 데이터 처리#

현재 chat_rooms.created_by, chat_room_members.user_id, messages.sender_id는 profile 삭제에 cascade된다. 생성자 삭제가 방·멤버십·메시지 전체를 지우지 않도록 소유권 이전 또는 nullable 처리, 발신자 tombstone과 회귀 테스트가 선행돼야 한다.

동의 변경 직렬화#

두 탭이 동의와 철회를 동시에 보내면 현재값과 이벤트 순서가 엇갈릴 수 있다. now()도 transaction 시작 시각이라 실제 확정 순서를 보장하지 않는다.

현재는 사용자·동의 종류별 advisory lock 뒤 clock_timestamp()와 event identity를 기록한다. 다른 회원은 막지 않는다. 탈퇴 요청도 같은 lock으로 마케팅 철회와 상태 변경을 한 transaction에서 처리한다. ^[5]

Trigger 전용 함수 권한#

handle_new_auth_user()와 add_chat_room_owner()는 사용자·채팅방 insert 뒤 DB가 자동 호출하는 trigger 함수다. API가 직접 호출할 기능이 아니다.

public schema의 SECURITY DEFINER 함수에 기본 EXECUTE가 남으면 PostgREST RPC 후보가 될 수 있다. trigger 밖 호출이 실패하더라도 향후 변경 시 우회 경로가 되므로 public, anon, authenticated 권한을 제거했다. DB trigger는 소유자 권한으로 계속 동작한다.

결정과 실행 계획#

1. 취소: 수동 운영은 요청 상태에서 허용하고, 자동화 뒤에는 삭제 job queued까지만 허용한다. running부터는 취소하지 않으며 고정 유예기간은 두지 않는다.
2. 재가입: 완료 계정은 복구하지 않는다. Auth 삭제 뒤 새 UUID·프로필·온보딩·동의로 가입하고 옛 관계를 연결하지 않는다.
3. 공동 데이터: 메시지는 탈퇴한 회원으로 비식별화해 식사 종료 후 30일까지 표시하고 90일에 삭제한다.
4. 안전 데이터: 신고 메시지는 사건 저장소로 분리해 종료 후 1년 보존한다. 임시 제재 식별자는 종료 후 90일, 중대한 제재는 1년 뒤 필요성을 재검토한다.
5. hard delete 전: 호스트 식사 취소·공지, 공동 데이터 FK·tombstone과 삭제 job migration을 완료한다.
6. 반복 요청: 오류 대신 기존 상태와 최초 요청 시각을 반환한다.

경쟁 서비스 비교와 선택 근거: 탈퇴 정책 경쟁 서비스 비교와 오프테이블 기획안

관련 기준: 계정 데이터 기준 · 계정 데이터 감사 계획 · 안전·운영