销毁已过保存期限的个人信息

목표

보존기간 표와 보존 명령을 데이터로 두고, 기간이 지난 개인정보를 예행과 실제 파기로 나누어 지운다. 파기 증적을 남기고, 지워진 사람의 정보가 정말 읽히지 않는지, 백업에는 무엇이 남았는지까지 확인한다.

왜 중요한가

개인정보는 지우지 않아도 사고고 잘못 지워도 사고다. 보유기간이 지나면 지체 없이 파기해야 하지만, 분쟁이나 감독기관 요구로 보존 명령이 걸린 건은 기간이 지나도 지우면 안 된다. 두 규칙이 부딪히는 자리를 사람의 판단에 맡기면 매번 다르게 처리되므로, 판정을 다시 계산할 수 있는 데이터로 만들어 둔다. 특히 기산일 하나로 결과가 통째로 바뀐다. 청구의 3년을 사고일부터 세느냐 종결일부터 세느냐에 따라 아직 보존해야 할 자료가 수십 건 지워질 수 있고, 그 사고는 지워진 뒤에만 드러난다. 채점기는 여러분이 적어 낸 목록을 믿지 않는다. 계약·청구·규칙 표에서 직접 다시 계산해 대조하고, 파기 뒤에는 백업에서 되찾은 연락처가 백업 밖의 파일에 아직 남아 있는지 훑는다.

단계

1. /root/retention/gen_retention.py 를 만들어 실행해 /root/retention/ins.db 와 서류·백업을 만든다. 계약 120건, 청구 240건, 개인정보 360줄, 규칙 4줄, 보존 명령 12건이다.
2. 기산일을 옛 판 규칙으로 바꾸면 더 지워지는 건을 /root/retention/basis_gap.csv 에, 다섯 숫자를 /root/retention/basis.txt 에 적는다.
3. 기준일 현재 보존기간이 지난 건을 /root/retention/due.csv 에 적는다. 보존 명령은 아직 보지 않는다.
4. 보존 명령으로 빠지는 건을 /root/retention/hold_excluded.csv 에, 최종 대상을 /root/retention/due_final.csv 에 적는다.
5. /root/retention/purge_plan.json 에 예행 계획을 낸다. 이 단계에서는 아무것도 지우지 않는다.
6. /root/retention/purge.py 를 만들어 실행해 계획대로 지우고 purge_log 에 이력을 남긴다.
7. /root/retention/purge_evidence.json 에 파기 증적을 낸다.
8. 백업에 남은 사본을 /root/retention/backup_residual.csv 에, 보고서를 /root/retention/retention_report.md 에 쓴다.

참고

• 판정 규칙: 파기 대상은 기산일 + 보존연수 <= sys_param.asof 인 건입니다. 기산일이 비어 있는 건(아직 종결되지 않은 청구)은 대상이 아닙니다.
• 연 단위 가감은 date.replace(year=...) 로 합니다. 2월 29일은 그 해에 없으면 28일로 내립니다.
• 최종 대상은 파기 대상에서 legal_hold 에 걸린 건을 뺀 것입니다.
• 파기는 subject 표의 행 삭제 + 그 청구의 서류 파일 삭제 + purge_log 적재입니다. 백업은 건드리지 않습니다.
• purge_log 의 열은 subject_type, subject_id, rule_kind, basis_date, expiry_date, purged_at, doc_path 이고 앞 두 열이 기본키입니다. rule_kind 는 policy 또는 claim, doc_path 는 계약이면 비어 있습니다.
• 규칙 계산은 한 곳에 모아 두면 3단계부터 8단계까지 다시 쓰지 않아도 됩니다.
• 기준일 확인: sqlite3 -readonly /root/retention/ins.db "SELECT * FROM sys_param;"
• 흔한 실수: 기산일이 비어 있는 건을 아주 옛날로 처리하기, 보존 명령을 기간 판정보다 먼저 보기, 표의 행만 지우고 서류 파일을 남기기, 백업까지 지워 버리기.
• 이 실습의 사람 이름·연락처·주소는 전부 합성입니다. 보존연수 중 법정 시효가 아닌 값은 합성 사내 규정이며 본문에 그렇게 적혀 있습니다.

계약과 청구 스냅샷 만들기

/root/retention/gen_retention.py 를 만들어 실행해 /root/retention/ins.db 와 /root/retention/docs/, /root/retention/backup/2026-08-31/docs/ 를 만드세요. 계약 120건, 청구 240건, 개인정보 360줄, 규칙 4줄, 보존 명령 12건입니다.

표 여섯 개입니다. 청구의 아홉 건에 하나쯤은 종결일이 비어 있어야 하고(아직 안 끝난 건), 규칙 표에는 지금 규칙(policy·claim)과 옛 판 규칙(policy_alt·claim_alt)이 함께 들어갑니다. 서류는 청구마다 한 장씩 만들고 백업 디렉터리에 그대로 복사합니다.

기산일을 바꾸면 무엇이 달라지나

옛 판 규칙(policy_alt·claim_alt)으로는 파기 대상이지만 지금 규칙으로는 아직 아닌 건을 /root/retention/basis_gap.csv 에 subject_type,subject_id,primary_expiry,alt_expiry 로 적고, /root/retention/basis.txt 에 due_policy=, due_claim=, due_policy_alt=, due_claim_alt=, extra_under_alt= 를 적으세요.

만료일은 기산일에 연수를 더한 날입니다. timedelta(days=365*n) 을 쓰면 윤년에서 밀리니 date.replace(year=...) 를 쓰세요. 기산일이 비어 있는 건은 만료일이 없으므로 primary_expiry 칸을 빈 칸으로 둡니다.

기간이 지난 건 뽑아내기

기준일(sys_param.asof) 현재 보존기간이 지난 건을 /root/retention/due.csv 에 subject_type,subject_id,rule_kind,basis_date,expiry_date 로 subject_type·subject_id 오름차순으로 적으세요. 보존 명령은 아직 보지 않습니다.

지금 규칙은 계약이 contract_end 기준 5년, 청구가 claim_closed 기준 3년입니다. 종결일이 비어 있는 청구는 시효가 시작되지 않았으므로 대상이 아닙니다. 빈 날짜를 아주 옛날로 채우면 진행 중인 청구가 통째로 지워집니다.

보존 명령이 걸린 건 빼내기

파기 대상 중 legal_hold 에 걸린 건을 /root/retention/hold_excluded.csv 에 subject_type,subject_id,hold_id,reason 으로, 나머지 최종 대상을 /root/retention/due_final.csv 에 due.csv 와 같은 머리글로 적으세요.

보존 명령은 기간 판정 뒤에 적용합니다. 순서를 바꾸면 명령이 걸렸지만 아직 기간이 안 지난 건까지 제외 목록에 들어가 숫자가 흐려집니다. reason 은 legal_hold 표에 적힌 문구를 그대로 씁니다.

지우기 전에 계획부터 내기

/root/retention/purge_plan.json 에 mode(dry-run), executed(false), asof, counts(policy·claim·files), subjects(subject_type·subject_id·expiry_date), files(지울 서류 경로) 를 담은 예행 계획을 내세요. 이 단계에서는 아무것도 지우지 않습니다.

계획과 실행을 같은 코드의 플래그 하나로 가르면 언젠가 그 플래그가 잘못 들어갑니다. 계획을 파일로 내고 실행은 그 파일을 읽게 하면 사람이 확인할 자리가 생깁니다. 서류 경로는 청구에만 있습니다.

계획대로 실제로 지우기

/root/retention/purge.py 를 만들어 실행해 계획에 적힌 대상의 subject 행과 서류 파일을 지우고 purge_log 에 이력을 남기세요. 백업은 건드리지 않습니다.

계획 파일만 믿고 지우면, 계획을 만든 뒤에 걸린 보존 명령을 놓칩니다. 실행 직전에 판정을 한 번 더 하고 계획과 다르면 멈추세요. 표의 행과 파일은 함께 처리해야 하고, purged_at 은 날짜와 시각입니다.

파기 증적 내고 되살릴 수 없는지 확인하기

/root/retention/purge_evidence.json 에 asof, purged(policy·claim), files_removed, held_kept, pii_rows_left_for_purged, doc_files_left_for_purged, backup_copies_left 를 적으세요. 숫자는 지금 상태를 직접 세어 나온 값이어야 합니다.

증적은 문구가 아니라 셈입니다. 남아 있으면 안 되는 두 숫자(개인정보 행, 서류 파일)는 0 이어야 하고, 백업 사본 수는 0 이 아닐 것입니다. 그 차이가 8단계의 주제입니다.

백업에 남은 사본 드러내고 보고서 쓰기

지웠는데 백업에 사본이 남은 건을 /root/retention/backup_residual.csv 에 subject_type,subject_id,backup_path 로 적고, /root/retention/retention_report.md 에 ## 무엇을 지웠나, ## 기산일을 어떻게 정했나, ## 보존 명령, ## 남은 사본, ## 재발 방지 다섯 절을 쓰세요.

백업 경로는 실제로 파일이 있는 것만 적습니다. 보고서에는 파기 건수, 청구 3년의 근거 조문, 어느 날을 기산일로 삼았는지, 보존 명령으로 남긴 건수, 백업에 남은 사본 이야기를 숫자와 함께 넣으세요.