맥락#
기존 계정 모델은 가입·최근 로그인과 이메일 확인을 Supabase Auth에 보유했고, 공개 profile에는 표시 이름·온보딩만, 비공개 영역에는 관리자 권한·이용정지만 두었다. 회원탈퇴 생명주기와 마케팅 선택 동의는 없었다. 프로젝트 오너는 보편적인 계정 운영 기능의 감사와 단계적 개선을 요구했다. [1]
결정#
인증 원본#
가입 일시, 이메일 확인과 최근 로그인은 auth.users에서 파생해 사용자·관리자 화면에 표시한다. 같은 값을 공개 profile에 복제하지 않는다.
탈퇴 생명주기#
private.account_lifecycle를 단일 진실 공급원으로 둔다.- 상태는
active,withdrawal_requested,withdrawn으로 제한한다. - 회원탈퇴 요청과 실제 삭제 완료를 같은 상태로 합치지 않는다.
- 사용자는 마이페이지에서 요청과 취소를 수행한다.
withdrawn은 공통 활성 계정 RPC와 제품 RLS에서 fail-closed로 차단한다.withdrawal_requested는 사용자가 요청을 취소할 수 있도록 계정 설정 접근을 유지한다.- hard delete와 익명화는 보존 대상·만료일·백업·로그·외부 처리자 경계를 확정한 뒤 별도 migration과 작업으로 연다. [2]
마케팅 선택 동의#
- 기본값은 미동의다.
private.user_consents에 현재 상태,private.user_consent_events에 변경 이력을 기록한다.- 수집 항목은 상태, 시각, 서버 고정 안내 버전과 채널이다.
- 필수 서비스 이용과 분리하고 마이페이지에서 언제든 철회한다. [2]
- 탈퇴 요청 transaction에서 활성 마케팅 동의를 철회하고 이벤트를 추가하며, 요청을 취소하기 전에는 다시 동의할 수 없다.
- 동시 변경은 사용자별 advisory lock으로 직렬화하고 이벤트 identity를 확정 순서로 사용한다.
- 광고 메일 실제 발송은 수신거부·표시·처리 결과 통지·2년 확인을 구현하기 전에는 열지 않는다. [3]
관리자 가시성#
관리자 목록·상세 RPC에 아래 운영 필드만 추가한다.
- 이메일 확인 일시
- 탈퇴 상태와 요청 일시
- 마케팅 수신 상태와 변경 일시
관리자는 현재 단계에서 탈퇴 완료나 동의를 대리 변경하지 않는다.
제외와 후속#
- 결제 거래기록 보존기간을 모든 계정 데이터에 일괄 적용하지 않는다. [4]
- 필수 약관·개인정보 처리 근거는 실제 문구와 법적 근거를 확정한 뒤 버전별로 수집한다.
- 마지막 제품 활동은 로그인 시간과 별도 이벤트로 정의한다.
- 로그인 기기·IP 이력은 보안 가치와 추가 개인정보 수집을 비교한 뒤 결정한다.
- consent event의 hard delete 이후 보존·익명화 기간은 삭제 파이프라인 결정에서 함께 확정한다.
반증·재검토 조건#
- 법률 검토가 현재 동의·철회 또는 보존 모델의 변경을 요구한다.
- 결제·환불·분쟁 기능이 도입돼 별도 거래기록 보존이 필요해진다.
- 자동 탈퇴 완료를 운영할 삭제·익명화 runbook과 복구 계획이 마련된다.
- 마케팅 이메일 발송을 실제로 시작한다.
세부 감사와 단계별 계획: 사용자 계정 데이터 감사와 개선 계획
탈퇴 취소·재가입·공동 데이터 처리와 DB 보안 용어 설명: 회원탈퇴 생명주기와 관계 데이터 처리 계획
경쟁 서비스 비교와 오프테이블 운영안: 탈퇴 정책 경쟁 서비스 비교와 오프테이블 기획안