인사 데이터 보존 기간 정리: 남길 것과 지울 것

인사 데이터 보존은 얼마나 오래 두는지의 문제가 아니라 무엇을 어떤 목적으로 두는지의 문제입니다. 채용과 재직, 퇴직, 탈락이라는 단계마다 데이터의 성격이 달라지고 그에 따라 다루는 방식도 달라집니다. 이 글에서는 데이터를 종류별로 나눠 보고, 삭제가 왜 어려운지, 그리고 시험 환경에서 무엇을 지켜야 하는지 정리합니다. 구체적인 기간은 나라와 조직마다 다르므로 여기서는 숫자를 다루지 않습니다.

인사 데이터는 얼마나 보관해야 하나요?

이 질문에 하나의 답은 없습니다. 보존 기간과 삭제 시점은 적용되는 법과 조직의 정책, 그리고 데이터를 모은 목적에 따라 달라집니다. 그래서 서비스가 정해야 할 것은 기간 자체가 아니라 기간을 어디에 두고 어떻게 적용할지입니다.

실무에서는 값을 코드에 박아 두지 않고 정책으로 분리하는 방식이 흔합니다. 어떤 종류의 데이터를 언제까지 두는지를 한곳에서 정하고, 화면과 배치 작업이 그 정책을 읽어 동작하게 만듭니다. 정책이 바뀌면 값만 고치면 되고, 어느 데이터에 어떤 규칙이 적용됐는지 추적할 수 있습니다.

여기서 한 가지 원칙이 있습니다. 목적이 사라진 데이터는 남겨 두는 것 자체가 비용과 위험입니다. 수집한 이유가 끝났는데도 보관하고 있다면, 그것은 자산이 아니라 부채입니다.

삭제가 생각보다 어려운 이유는 무엇인가요?

삭제 버튼은 쉽게 만들 수 있지만, 실제로 사라지게 하는 일은 어렵습니다. 같은 값이 여러 곳에 복제되어 있기 때문입니다.

• 백업과 스냅샷
• 접근 로그와 변경 이력
• 내려받은 내보내기 파일
• 분석용으로 복사된 저장소
• 캐시와 검색 색인
• 화면 캡처와 교육 자료

이 가운데 하나라도 빠지면 삭제는 끝나지 않습니다. 그래서 삭제 요청을 처리할 때는 어느 저장소까지 확인했는지 기록하는 편이 좋습니다. 또한 이름과 연락처만 지우는 것으로는 익명이 되지 않습니다. 남은 조합만으로도 사람을 다시 알아볼 수 있는 경우가 많습니다.

종류별로 다루는 방식이 어떻게 다른가요?

표에서 보이듯 같은 사람의 데이터가 여러 목적에 걸쳐 있습니다. 목적별로 나눠 두면 어느 부분을 언제 정리할지 판단하기 쉬워집니다.

탈락한 지원자의 자료는 어떻게 다루나요?

채용 과정에서 남는 자료는 대부분 탈락자에게서 나옵니다. 이력서, 자기소개, 면접 기록, 평가 의견이 그것입니다. 이 중 상당수는 채용이 끝나는 순간 목적이 사라집니다.

그래서 실무에서는 두 갈래로 나누는 편이 흔합니다. 앞으로 다시 연락할 의사가 있는 자료와 그렇지 않은 자료입니다. 전자는 동의를 근거로 따로 보관하고, 후자는 정리 대상으로 표시해 둡니다. 중요한 것은 아무 표시 없이 쌓아 두지 않는 것입니다. 표시가 없으면 나중에 어느 것이 살아 있는 자료인지 판단할 수 없습니다.

면접 평가와 메모는 특히 조심해야 합니다. 주관적인 표현이 그대로 남아 있으면 나중에 그 사람에 대한 판단 근거로 재사용되고, 원래 목적과 무관한 곳에서 문제가 됩니다.

시험 환경에 실제 인사 데이터를 두면 왜 안 되나요?

운영 데이터를 복사해 오는 습관은 편하지만 대가가 큽니다. 시험 환경은 접근 통제가 느슨한 경우가 많고, 데이터는 개발자 장비와 교육 자료, 화면 캡처로 퍼집니다. 한 번 퍼진 값은 회수하기 어렵습니다.

필요한 것이 실제 값이 아니라 분포라면 합성 데이터로 충분합니다. 직무의 종류, 경력의 길이, 학력의 분포 같은 것은 실제 사람의 정보 없이도 만들 수 있습니다. 시험용 기록을 만드는 방법은 경력 프로필 테스트 데이터 만드는 법에서 다뤘고, 값의 노출 범위는 급여 통화 주기 표기 정리에서 확인할 수 있습니다.

보존 정책은 어디에 두어야 하나요?

정책은 화면 코드와 배치 작업이 함께 읽는 한 자리에 두는 편이 좋습니다. 기간을 화면에 적어 두고 배치에 따로 적어 두면, 둘이 어긋나는 순간 화면은 지워졌다고 말하는데 저장소에는 남아 있는 상태가 됩니다.

시험 환경과 운영 환경의 정책도 나눠 둡니다. 시험 환경에서는 정리 주기를 짧게 두어 삭제가 실제로 도는지 확인할 수 있고, 운영에서는 정해진 절차를 따르게 합니다. 다만 시험 환경이라도 실제 인사 기록을 넣어서는 안 됩니다. 합성 기록이면 삭제 시험도 충분히 할 수 있습니다.

개발자를 위한 메모: 보존 정책을 코드로 옮기는 법

• 데이터 종류를 먼저 정의합니다. 종류가 정해지지 않으면 정책을 붙일 자리도 없습니다.
• 모든 레코드에 생성 시점과 마지막 사용 시점을 남깁니다. 정리 대상은 이 두 값으로 판단합니다.
• 삭제는 표시 후 정리로 나눕니다. 즉시 지우면 실수를 되돌릴 수 없고, 영원히 표시만 하면 지워지지 않습니다.
• 정책을 설정으로 두고 배치가 그것을 읽게 합니다. 코드에 기간을 박으면 배포 없이는 바꿀 수 없습니다.
• 삭제 결과를 기록합니다. 언제 무엇을 지웠고 어디까지 확인했는지 남아야 합니다.
• 내보내기와 백업을 삭제 범위에 포함합니다. 이 둘을 빼면 삭제가 형식만 남습니다.
• 시험 데이터에는 실제 인사 기록을 넣지 않습니다. 이 원칙을 자동 검사로 강제하는 편이 안전합니다.
• 정리 작업 자체를 시험합니다. 지워야 할 것이 지워지고 남겨야 할 것이 남는지 확인해야 합니다.
• 정책 값을 한 자리에서만 읽게 합니다. 화면과 배치가 각자 기간을 계산하면 결과가 갈라집니다.
• 삭제 대상을 세는 지표를 남깁니다. 남은 건수만 보면 정리가 도는지 알 수 없습니다.

시험용 인사 기록이 필요하면 테스트용 경력 데이터 생성기에서 합성 기록을 만들어 쓰세요. 실제 지원자 정보를 옮기지 않고도 목록과 검색, 집계 화면을 충분히 시험할 수 있습니다. 저장소를 비우고 합성 값으로 다시 채우는 절차는 스테이징 데이터베이스 채우기에서 이어서 볼 수 있습니다.

다음 단계

지금 보관 중인 자료를 종류별로 나눠 보고, 각각의 목적이 아직 살아 있는지 확인해 보세요. 목적이 끝난 자료에 표시가 없다면 그것부터 붙이는 것이 순서입니다. 그다음 삭제 범위에 백업과 내보내기 파일이 들어 있는지 점검하고, 시험 환경에 남아 있는 실제 인사 기록이 있다면 합성 기록으로 바꿔 두세요.

시험과 시연 환경에서는 실제 인사 자료를 쓰지 마세요. 이 글의 예시는 데이터 관리 구조를 설명하기 위한 것으로, 삭제와 보존은 적용되는 법과 조직의 정책에 따라 결정해야 합니다.