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