지울 때가 된 것과 지우면 안 되는 것

한 줄 요약

보존기간이 지난 개인정보는 지체 없이 지워야 하지만, 분쟁이나 감독기관 요구로 보존 명령이 걸린 건은 기간이 지나도 지우면 안 된다. 두 규칙이 부딪히는 자리를 판정 가능한 데이터로 만들어 두는 것이 이 일의 전부다.

왜 이게 필요했나

개인정보는 지우지 않아도 사고고 잘못 지워도 사고다. 지우지 않으면 [개인정보 보호법 제21조](https://www.law.go.kr/%EB%B2%95%EB%A0%B9/%EA%B0%9C%EC%9D%B8%EC%A0%95%EB%B3%B4%20%EB%B3%B4%ED%98%B8%EB%B2%95/%EC%A0%9C21%EC%A1%B0)가 말하는 "보유기간이 지나면 지체 없이 파기" 를 어긴 것이 되고, 반대로 분쟁 중인 청구의 자료를 지워 버리면 회사가 자기 주장을 증명할 수단을 잃는다. 실제 사고는 대개 후자 쪽이 조용히 일어난다. 배치가 밤새 돌면서 "기간이 지났다" 는 이유만으로 조정 중인 건의 서류를 지워 버리고, 아무도 다음 달 조정 기일까지 그 사실을 모른다.

여기에 판정을 어렵게 만드는 요소가 하나 더 있다. 기산일이다. 보험의 소멸시효는 [상법 제662조](https://www.law.go.kr/%EB%B2%95%EB%A0%B9/%EC%83%81%EB%B2%95/%EC%A0%9C662%EC%A1%B0)가 정하는데, 요지는 보험금청구권과 보험료·적립금 반환청구권은 3년, 보험료청구권은 2년이다. 그런데 "3년" 이 언제부터의 3년인지는 데이터에 자동으로 적혀 있지 않다. 사고일인가, 청구 종결일인가, 계약 종료일인가. 시스템마다 다른 날을 기산일로 잡고 있으면 같은 건이 어느 쪽에서는 파기 대상이고 어느 쪽에서는 아직 보존 대상이다.

어떻게 동작하나

설계는 네 가지를 데이터로 두는 데서 출발한다.

1. 보존기간 표. 대상 종류마다 기산일 이름과 연수, 그리고 근거를 적는다. 근거를 같은 줄에 두는 이유는, 나중에 "왜 5년인가" 를 묻는 사람이 반드시 나타나기 때문이다. 법정 시효에서 오는 값과 사내 규정에서 오는 값을 섞어 두면 규정이 바뀔 때 무엇을 고쳐야 하는지 알 수 없다.
2. 기산일. 계약이면 계약일과 종료일이, 청구면 사고일과 종결일이 후보다. 아직 끝나지 않은 건은 기산일이 없다 — 시효가 시작되지 않은 것이라, 이런 건을 "날짜가 비어 있으니 아주 옛날" 로 처리하면 진행 중인 청구의 자료가 통째로 지워진다.
3. 보존 명령(legal hold). 분쟁·수사·감독기관 요구처럼 기간과 무관하게 보존해야 하는 사유를 건 단위로 건다. 파기 판정은 항상 "기간이 지났는가" 다음에 "명령이 걸려 있는가" 순서로 한다.
4. 파기 증적. 무엇을 언제 어떤 규칙으로 지웠는지 남긴다. 지운 것은 다시 보여 줄 수 없으니, 지웠다는 사실 자체가 유일한 증거가 된다.

날짜 계산은 생각보다 함정이 많다. 파이썬 [datetime](https://docs.python.org/3/library/datetime.html)에는 "몇 년 뒤" 를 구하는 연산이 없다. timedelta 는 일·초 단위라서 days=365*3 으로 계산하면 윤년이 낀 구간에서 하루씩 밀린다. 그래서 연 단위 가감은 date.replace(year=...) 로 하고, 2월 29일처럼 그 해에 없는 날은 규칙을 명시해 처리한다. SQLite 로 계산할 때도 [날짜·시각 함수](https://www.sqlite.org/lang_datefunc.html)의 date(x, '+3 years') 는 존재하지 않는 날짜를 다음 달로 넘겨 정규화하므로, 어느 쪽으로 처리했는지를 문서에 적어야 두 시스템의 숫자가 맞는다.

기간 판정 ──▶ 보존 명령 제외 ──▶ 예행(dry-run) ──▶ 실제 파기 ──▶ 증적 ──▶ 남은 사본

현장에서 만나는 모습

가장 자주 보는 사고는 기산일을 옮긴 것이다. 옛 규정이 "계약일로부터 5년" 이었고 새 규정이 "계약 종료일로부터 5년" 인데, 배치가 옛 계산식을 그대로 쓰고 있었다. 10년짜리 계약이라면 두 값이 10년 차이가 나서, 아직 보존해야 할 자료가 수천 건 지워진다. 이 사고는 지워진 다음에만 드러난다.

두 번째는 예행과 실제를 같은 코드로 돌리는 것이다. 플래그 하나로 갈라 놓으면 언젠가 그 플래그가 잘못 들어간다. 계획을 파일로 내고, 실행은 그 파일을 읽어 다시 판정한 뒤에만 지우게 만들면 사람이 중간에 확인할 자리가 생긴다.

세 번째는 파기했다고 믿는 것이다. 표의 행을 지웠는데 첨부 파일은 그대로 남아 있거나, 운영 DB 에서는 지웠는데 어제 받은 백업에는 그대로 들어 있다. 백업까지 즉시 지우는 것은 대개 불가능하니, 최소한 어디에 무엇이 남아 있는지 목록으로 드러내고 그 목록의 처리 일정을 따로 관리해야 한다. 목록이 없으면 "지웠다" 는 보고는 사실이 아니다.

실무에서 진짜 중요한 것

• 규칙은 데이터로. 기산일 이름·연수·근거를 표에 두면 다시 계산해 볼 수 있다. 코드에 숨으면 아무도 검증하지 못한다.
• 판정 순서를 고정한다. 기간 → 보존 명령 → 예행 → 실행. 순서를 바꾸면 지우면 안 되는 것이 지워진다.
• 끝나지 않은 건은 기산일이 없다. 빈 날짜를 0 이나 아주 옛날로 채우지 않는다.
• 지운 사실을 남긴다. 증적이 없으면 파기했다는 것도 증명할 수 없다.
• 남은 사본을 세어 둔다. 백업·반출 파일·분석용 사본까지 목록에 넣는다.

다음 실습에서 할 것

계약 120건과 청구 240건, 보존기간 표와 보존 명령이 든 스냅샷을 만들고, 기산일을 바꾸면 파기 대상이 몇 건이나 늘어나는지 직접 셉니다. 기간이 지난 건을 뽑아 보존 명령이 걸린 건을 빼고, 예행 계획을 파일로 낸 뒤 그 계획을 읽어 실제로 지웁니다. 마지막에는 파기 증적을 내고, 남은 파일에서 지워진 사람의 연락처가 정말 읽히지 않는지 확인하고, 백업에 남은 사본을 목록으로 드러냅니다.