탈퇴 기능을 견적서에 넣으면 거의 매번 같은 자리에서 멈춥니다. 개발자는 회원 테이블에서 행 하나를 지우면 끝이라고 보고, 운영팀은 지난 주문을 못 찾으면 환불과 세금계산서 처리가 막힌다고 말합니다.

둘 다 맞는 말이어서 회의로는 결론이 나지 않습니다. 다행히 이 문제는 취향으로 정하는 영역이 아닙니다. 무엇을 지우고 무엇을 남길지는 법에 숫자로 적혀 있고, 그 숫자가 항목마다 다른 것이 함정입니다.

원칙은 파기이고 예외는 다른 법령뿐입니다

개인정보 보호법 제21조 제1항은 보유기간이 지났거나 처리 목적을 달성해 개인정보가 불필요해지면 지체 없이 파기하라고 정합니다. 회원 탈퇴는 처리 목적이 사라진 가장 전형적인 상황입니다. 기본값은 삭제입니다.

같은 항의 단서는 예외를 딱 하나만 둡니다. 다른 법령에 따라 보존해야 하는 경우입니다. '나중에 분쟁이 생길까 봐', '통계로 쓰려고', '재가입하면 보여주려고' 같은 사내 사정은 여기에 들어가지 않습니다.

남기려면 어느 법 몇 조가 남기라고 했는지 댈 수 있어야 합니다. 못 대면 지워야 합니다.

제21조 제1항을 위반해 파기 등 필요한 조치를 하지 않으면 제75조 제2항 제4호에 따라 3천만원 이하의 과태료 대상이 됩니다.

전자상거래법은 기록 종류마다 기간을 따로 정해 두었습니다

전자상거래법 시행령 제6조 제1항은 사업자가 보존할 거래기록과 그 기간을 네 가지로 나눕니다. 2026년 7월 21일 시행 조문 기준입니다.

보존 대상 기록기간
표시·광고에 관한 기록6개월
계약 또는 청약철회 등에 관한 기록5년
대금결제 및 재화등의 공급에 관한 기록5년
소비자의 불만 또는 분쟁처리에 관한 기록3년

여기서 중요한 것은 주문 하나가 통째로 5년이 아니라는 점입니다. 한 번의 구매에서 생긴 기록이 6개월, 3년, 5년으로 흩어집니다.

같은 주문 화면 안에서도 지워야 하는 시점이 갈립니다

구매 과정에 남는 기록을 떼어 보면 이렇습니다. 구매 시점에 노출된 가격과 쿠폰 표기는 표시·광고 기록이라 6개월, 주문서와 청약철회 처리는 5년, 결제 승인과 배송 완료는 5년, 1:1 문의와 반품 분쟁 이력은 3년입니다.

그래서 주문 관련 데이터를 한 테이블에 몰아 둔 구조에서는 이 기준을 지킬 수 없습니다. 기간이 다른 항목이 같은 행에 묶여 있으면 6개월짜리를 5년 보관하게 되고, 그 초과 보관 자체가 제21조 제1항 위반입니다.

남길 것은 거래기록이고 지울 것은 회원정보입니다

전자상거래법 제6조 제2항은 보존할 수 있는 개인정보를 성명·주소·전자우편주소 등 거래의 주체를 식별할 수 있는 정보로 한정합니다. 회원 정보를 전부 남겨도 된다는 근거가 아닙니다.

따라서 다음 항목은 보존 예외에 들어가지 않습니다. 탈퇴 처리 시점에 파기 대상으로 잡으세요.

  • 비밀번호 해시, 소셜 로그인 연동 토큰, 접속 기록
  • 마케팅 수신 동의 이력과 광고 식별자
  • 생년월일, 성별처럼 가입 단계에서 받은 선택 항목
  • 장바구니, 관심상품, 최근 본 상품, 추천인 코드

플래그 컬럼 하나는 분리 보관이 아닙니다

제21조 제3항은 단서에 따라 보존하는 개인정보를 다른 개인정보와 분리해 저장·관리하라고 요구합니다. 위반하면 제75조 제4항 제2호에 따라 1천만원 이하의 과태료 대상입니다.

전자상거래법 시행령 제6조 제2항 제3호는 더 구체적입니다. 개인정보 이용 동의를 철회한 소비자의 거래기록과 개인정보는 철회하지 않은 소비자의 것과 분리해 보존해야 합니다.

회원 테이블에 is_withdrawn 같은 컬럼을 세우고 조회 쿼리에서 거르는 방식은 저장 위치도 접근 권한도 그대로입니다. 이 구조를 분리 보존으로 보기는 어렵습니다. 테이블을 따로 두세요.

견적에는 세 가지 항목이 새로 생깁니다

탈퇴를 제대로 만들면 화면 하나가 아니라 아래 세 덩어리가 추가됩니다. 외주 견적에 이 항목이 없으면 탈퇴를 버튼 하나로 계산한 견적입니다.

  • 분리보관 테이블: 보존 대상 거래기록과 식별정보만 담는 별도 테이블을 두고, 보존 사유와 파기 예정일 컬럼을 함께 설계합니다.
  • 접근권한: 이 테이블은 일반 운영 화면에서 감추고, 분쟁 대응이나 세무 확인처럼 사유가 있을 때만 열람하도록 계정과 열람 로그를 나눕니다.
  • 자동 파기 배치: 파기 예정일이 지난 행을 주기적으로 지우고, 무엇을 몇 건 지웠는지 기록을 남깁니다.

자동 파기 배치가 가장 많이 빠집니다

보존 예외는 영구 면제가 아닙니다. 6개월, 3년, 5년이 끝나는 순간 그 데이터는 다시 지체 없이 파기해야 하는 개인정보로 돌아갑니다. 배치가 없으면 분리보관 테이블이 그대로 위반 증거가 됩니다.

파기 방법도 정해져 있습니다. 개인정보 보호법 시행령 제16조는 전자적 파일을 복원이 불가능한 방법으로 영구 삭제하고, 기술적 특성상 영구 삭제가 현저히 곤란하면 복원할 수 없도록 조치하라고 합니다. 백업과 스냅샷에 남은 사본까지 계획에 넣어야 합니다.

5년을 주문일부터 세면 세법 기준과 어긋납니다

국세기본법 제85조의3 제2항은 장부와 증거서류를 거래사실이 속하는 과세기간의 법정신고기한이 지난 날부터 5년간 보존하라고 정합니다. 역외거래는 7년입니다. 기산점이 주문일이 아닙니다.

그래서 주문일에 5년을 더해 파기 날짜를 계산한 배치는 세무 증빙을 필요한 기간보다 먼저 지웁니다. 파기 예정일은 전자상거래법 기준과 세법 기준 중 늦은 날로 잡으세요.

중개 플랫폼 판매자는 보존 범위가 다릅니다

시행령 제6조 제1항은 통신판매중개자에 대해 자신의 정보처리시스템을 통해 처리한 기록의 범위에서 보존하도록 정합니다. 결제와 배송이 열린장터 쪽에서 처리된다면 그 기록의 보존 주체도 그쪽입니다. 자사몰이 없는 사업자가 분리보관 세트를 전부 만드는 것은 과한 비용입니다.

반대로 이 기간표만으로 끝나지 않는 경우도 있습니다. 전자금융, 의료, 통신처럼 업종별 보존 의무가 따로 있는 영역은 이 글에서 다루지 않았고, 해당 법령을 별도로 확인해야 합니다.

조문 원문은 국가법령정보센터에서 확인하세요. 비슷한 설계 판단은 실무 가이드와 개발 노트에 모여 있고, 구조 설계가 필요하면 Codeforest로 문의하세요.

결론: 탈퇴는 삭제가 아니라 분리와 예약 삭제로 설계하세요

탈퇴 버튼이 할 일은 두 가지입니다. 보존 근거가 없는 회원정보는 그 자리에서 파기하고, 전자상거래법이 요구하는 거래기록과 식별정보는 권한이 분리된 테이블로 옮기는 것입니다. 플래그만 세우는 방식은 양쪽 의무를 모두 놓칩니다.

남길 기록에는 6개월, 3년, 5년이라는 서로 다른 시계가 붙습니다. 그 시계를 돌려 줄 자동 파기 배치까지가 탈퇴 기능의 범위입니다. 견적서에 분리보관 테이블, 접근권한, 파기 배치 세 줄이 없으면 아직 탈퇴 기능이 아닙니다.