회원 탈퇴 데이터의 보관·분리·복구 설계

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

탈퇴 회원의 주문을 설계할 때 첫 질문은 테이블 이름을 archived_order로 바꿀지 여부가 아니다. 보관해야 할 데이터를 어디에 둘 것인가다. 운영 주문 옆에 같은 스키마의 테이블 하나를 더 두는 것으로는 대체로 부족했다. 적용 지침에 따라 별도 스키마를 쓰기도 했지만, 다뤄진 회사 대부분은 DBMS 자체를 분리했다.

보관할 주문을 분리된 저장소로 옮긴다

보관 DB에는 같은 역할의 테이블을 두고 적용되는 보관 정책에 따라 남겨야 하는 기록을 운영 DB에서 옮길 수 있다. 이관은 탈퇴 처리와 동시에 할 수도 있고 나중에 배치로 할 수도 있다. 어떤 방식을 쓸지는 서비스의 탈퇴 흐름에 맞춰 정한다.

필요한 분리 수준은 회사가 받아야 하는 심사와 정책에 따라 달라진다. 물리 DB를 하나 더 운영하면 비용이 들지만 탈퇴 회원 쪽 트래픽이 적어 더 작은 장비를 쓸 수 있다는 경험도 소개한다. 개발자가 법률·보안 전문가가 아니라면 담당 전문가나 실제 심사 기관이 해석한 최신 가이드를 따르는 편이 안전하다.

탈퇴해도 주문 업무는 끝나지 않는다

더 어려운 문제는 업무 흐름에서 나온다. 배송 중 주문이 있으면 많은 서비스가 거래가 끝날 때까지 탈퇴를 막았다. 탈퇴 뒤 상품 하자를 발견해 고객지원으로 취소나 교환을 요청할 수도 있고, 리콜이 생기면 이미 떠난 고객에게 연락해야 할 수도 있다. 서비스에 따라 재가입 때 구매·결제 내역을 복구하기도 한다.

정책이 달라지면 얼마 동안 어떤 데이터를 연결 가능한 상태로 둘지도 달라진다. 암호화한 식별자와 서로 다른 만료 기간이 예로 나오지만 정확한 기준은 경우마다 다르다. 모든 연결 정보를 없애면 복구는 불가능해지고, 연결을 남기려면 허용된 목적과 삭제 시점이 먼저 정해져야 한다.

세부 기준은 현재 지침에서 가져온다

탈퇴 설계를 기억에 남은 보관 기간 하나로 결정할 수 없는 이유다. 개인정보, 결제 기록, 재가입, 리콜, 과거 휴면회원 규칙은 서로 다르게 다뤄질 수 있고 기준도 바뀐다. 적용할 지침을 먼저 확정한 뒤 그에 맞는 분리, 암호화, 운영 처리와 만료 삭제를 구현해야 한다. 데이터베이스 구조가 정책을 발명하는 것이 아니라 정책을 따라간다.