회원 데이터베이스를 마지막 접속일 순으로 정렬하면 3년, 5년째 아무 기록이 없는 계정이 줄줄이 나옵니다. 예전에는 이 계정들을 어떻게 할지 고민할 필요가 없었습니다. 법이 1년이라는 기준을 정해 줬기 때문입니다.
그 기준은 2023년 9월 15일에 없어졌습니다. 그날부터 휴면 기준은 서비스마다 직접 정하는 항목이 되었습니다. 그런데 사고는 기준을 새로 정하는 단계가 아니라, 바꾼 기준을 회원에게 알리는 단계에서 납니다.
1년 자동 분리보관 규정은 2023년 9월에 사라졌습니다
폐지된 조문은 옛 개인정보 보호법 제39조의6, 이름은 '개인정보의 파기에 대한 특례'였습니다. 1년간 서비스를 이용하지 않은 이용자의 개인정보는 파기하거나 다른 이용자의 정보와 분리해 저장·관리하도록 강제하던 규정입니다. 이 조문은 2023년 9월 15일 시행된 개정법에서 삭제되었습니다.
폐지 이유는 회원 의사와 상관없이 강제로 분리하거나 파기하는 방식이 오히려 개인정보 자기결정권을 제한한다는 지적이었습니다. 그래서 지금은 1년이 기준이 아니라, 법이 정해 주는 기준 자체가 없는 상태입니다.
보관 기한을 정하는 근거는 이제 제21조 하나입니다
특례가 빠져도 개인정보 보호법 제21조는 그대로 남아 있습니다. 보유기간이 지났거나 처리 목적을 달성해 그 개인정보가 불필요하게 되었을 때는 지체 없이 파기해야 한다는 조항입니다. '언제까지 갖고 있어도 되나'의 답은 이제 '필요할 때까지'입니다.
'지체 없이'는 표준 개인정보 보호지침 제10조에서 근무일 기준 5일 이내로 봅니다. 파기 방법도 시행령 제16조에 정해져 있어서, 전자적 파일은 복원이 불가능한 방법으로 영구 삭제해야 합니다. 기준일이 오면 5일 안에 실제로 지우는 절차까지 있어야 한다는 뜻입니다.
1년이 사라진 자리에 '무기한'이 들어온 것이 아닙니다. '필요 없어지면 지체 없이'가 들어왔습니다.
기한은 미접속 기간이 아니라 다른 법의 보존 의무부터 계산하세요
쇼핑몰이라면 전자상거래법 시행령 제6조가 먼저 걸립니다. 계약 또는 청약철회 기록과 대금결제·재화 공급 기록은 5년, 소비자 불만이나 분쟁처리 기록은 3년, 표시·광고 기록은 6개월을 보존해야 합니다. 마지막 주문일에서 5년이 사실상의 하한선이 됩니다.
제21조는 다른 법령에 따라 보존해야 하는 개인정보는 다른 개인정보와 분리해 저장·관리하라고 정하고 있습니다. 주문 기록은 5년 남기되 계정 정보는 따로 정리할 수 있다는 뜻입니다. 그래서 기준을 정하기 전에 '계정 정보'와 '거래 기록'을 테이블 단위로 나누는 작업이 먼저입니다.
금융이나 신용정보를 다룬다면 자율이 아닙니다. 신용정보법 제20조의2는 금융거래 등 상거래관계가 종료된 날부터 최장 5년 이내에 개인신용정보를 삭제하도록 정하고 있습니다. 수집·제공 목적이 그보다 먼저 달성됐다면 그 날부터 3개월 이내입니다.
실제 선택지는 세 갈래로 좁혀집니다
첫째는 지금의 휴면 전환을 유지하되 기간만 서비스에 맞게 늘리는 방식입니다. 둘째는 휴면 제도를 없애고 분리보관하던 정보를 원래 회원 DB로 통합하는 방식입니다. 셋째는 휴면 단계 없이 일정 기간이 지나면 바로 탈퇴 처리하고 파기하는 방식입니다.
판단 기준은 재유입 가치입니다. 1년 넘게 안 들어온 회원이 돌아오는 비율이 낮고 마케팅 활용도 없다면 셋째가 운영 부담이 가장 적습니다. 반대로 연말정산 대행이나 연 1회 예약처럼 사용 주기가 긴 서비스에서 1년 기준은 너무 짧습니다.
가장 편해 보이는 둘째가 설명이 제일 많이 필요합니다. 회원 입장에서는 격리돼 있던 내 정보가 다시 살아있는 DB로 돌아온다는 뜻이기 때문입니다.
정책을 바꾸려면 회원에게 먼저 알려야 할 항목이 정해져 있습니다
개인정보보호위원회는 2023년 12월 1일 배포한 보도참고자료에서, 사업자가 서비스 특성에 맞는 휴면정책을 자율적으로 마련하되 정보주체에게 사전 안내한 뒤 운영해야 한다고 밝혔습니다. 안내에 무엇을 넣어야 하는지도 함께 제시했습니다.
- 유효기간제 폐지로 휴면정책을 변경한다는 사실 자체
- 개인정보를 파기하는 것인지, 분리보관하던 정보를 통합하는 것인지
- 회원이 이의를 제기할 수 있는 방법
- 계속 이용과 탈퇴(파기 요청) 중에서 선택할 수 있다는 안내
'개인정보 처리방침이 변경되었습니다'라고만 쓰고 전문 링크를 거는 방식으로는 이 요건을 채우지 못합니다. 파기인지 통합인지는 링크 너머가 아니라 안내문 본문에 그대로 적혀 있어야 합니다.
안내 메일에 마케팅 문구를 섞으면 그 자체가 문제가 됩니다
같은 자료는 정책 변경 안내를 마케팅 목적으로 활용하면 개인정보 보호법과 정보통신망법 위반 소지가 있다고 못 박았습니다. 오래 안 들어온 회원 명단은 마케팅팀 입장에서 탐나는 목록이지만, 이 발송은 그 용도로 쓸 수 없습니다.
실무에서는 휴면 안내와 재방문 프로모션을 아예 다른 발송으로 쪼개는 편이 안전합니다. 한 메일에 쿠폰 배너를 하나 넣는 순간 광고성 정보 전송이 되고, 수신동의 여부를 다시 따져야 합니다. 템플릿 단계에서 갈라 두세요.
이의제기 방법은 고객센터 링크로 갈음할 수 없습니다
이의제기는 회원이 '나는 그 변경을 원하지 않는다'고 말하는 통로입니다. 파기 예정이면 계속 보관해 달라는 요청이 되고, 통합 예정이면 분리보관을 유지하거나 아예 탈퇴하겠다는 요청이 됩니다. 요청 종류마다 처리 결과가 달라야 합니다.
그래서 안내문에는 접수 창구, 접수 기한, 처리 결과를 어떻게 알려주는지 세 가지가 함께 들어가야 합니다. 기한이 빠져 있으면 회원은 이미 파기가 끝난 뒤에 문의하게 됩니다.
개발자에게 넘길 요건은 이 형태로 적으세요
정책 문장을 그대로 던지면 구현이 갈립니다. '1년 미접속'이 마지막 로그인인지, 마지막 주문인지, 앱 실행인지부터 문서에 못 박아야 합니다.
- 휴면 판정 기준 필드: 최종 로그인·최종 결제·최종 앱 실행 중 무엇인지, 여러 개면 가장 늦은 값을 쓰는지
- 판정 배치 주기와 실행 시각, 그리고 대상자 산출 결과를 남길 로그
- 사전 통지 시점: 전환이나 파기 며칠 전인지, 발송 채널과 실패 시 재시도 규칙
- 이의제기 접수 결과를 반영할 예외 플래그와 그 플래그의 유효기간
- 다른 법령상 보존 대상 데이터의 분리 저장 위치와 접근 권한
- 파기 실행 방식: 논리 삭제인지 물리 삭제인지, 백업본과 로그를 어떻게 처리하는지
여섯 번째가 특히 자주 빠집니다. 운영 DB에서 지워도 야간 백업본이나 분석용 데이터 창고에 그대로 남아 있으면 파기했다고 말하기 어렵습니다. 백업 보존 주기와 덮어쓰기 시점을 요건서에 숫자로 적어 두세요.
이럴 때는 휴면 제도를 없애지 마세요
로그인 정보 외에 민감정보나 고유식별정보를 갖고 있다면 통합은 권하지 않습니다. 유출 사고가 나면 피해 범위가 안 쓰는 회원 수만큼 그대로 커집니다. 진료·상담·자격 관련 정보는 분리보관을 유지하는 편이 낫습니다.
규모도 봐야 합니다. 5만 명 이상의 민감정보·고유식별정보를 처리하거나 100만 명 이상의 개인정보를 처리하면 제20조의2에 따라 연 1회 이상 이용내역을 통지해야 합니다. 휴면 회원을 활성 DB로 통합하면 통지 대상과 발송 비용이 함께 늘어납니다.
반대로 파기 쪽으로 너무 세게 가는 것도 위험합니다. 파기는 되돌릴 수 없어서 6개월 같은 짧은 기준을 잡으면 계절성 이용자가 통째로 사라집니다. 기준을 바꾸기 전에 실제 재방문 분포를 한 번 뽑아 보세요. 원문 문구는 개인정보보호위원회 보도참고자료에서 확인하실 수 있고, 비슷한 운영 기준 정리는 실무 가이드에 모아 두었습니다. 요건 정리와 개발이 함께 필요하시면 Codeforest로 문의하세요.
결론: 기한은 자율이지만 알리는 방법은 자율이 아닙니다
안 쓰는 회원 정보를 언제까지 갖고 있어도 되는지는 이제 법이 답해 주지 않습니다. 전자상거래법 5년, 신용정보법 최장 5년처럼 다른 법령이 정한 기한을 먼저 깔고, 그 위에 서비스의 실제 이용 주기를 얹어 기간을 정하세요. 그리고 그 기간이 지나면 근무일 기준 5일 안에 실제로 파기하는 절차까지 갖춰야 합니다.
반면 바꾼 기준을 알리는 방법은 정해져 있습니다. 파기인지 통합인지, 이의제기는 어떻게 하는지, 계속 이용과 탈퇴 중 무엇을 고를 수 있는지가 안내문에 없으면 기준을 아무리 잘 잡아도 절차 하자가 남습니다. 개발 요건서에는 판정 필드와 배치 주기, 예외 플래그, 백업 처리까지 숫자로 적어 넘기세요.
