고객이 회원 탈퇴를 요청했다. 개발팀은 사용자 테이블의 계정을 비활성화했고 화면에서는 더 이상 보이지 않는다. 그런데 과거에 올린 파일은 객체 저장소에 남아 있고, 검색 결과에는 이름이 보이며, 운영 로그에는 이메일이 오래 남는다. ‘화면에서 사라졌다’와 ‘처리 목적에 맞게 삭제됐다’는 전혀 다른 말이다. 개인정보 삭제는 SQL 한 줄이 아니라 데이터가 복제되고 이동한 경로를 끝까지 따라가는 운영 절차다.
NIST 개인정보 프레임워크 FAQ는 데이터 검토·이전·변경·삭제를 위한 정책과 절차를 데이터 수명주기 관리의 일부로 다룬다. 이는 특정 국가의 법적 보관기간을 정해 주는 문서가 아니다. 실제 삭제 범위와 보관 예외는 서비스의 목적, 계약, 적용 법규를 별도로 검토해야 한다.
삭제 버튼을 만들기 전에 데이터 위치 지도를 만든다
한 사람의 데이터는 사용자 테이블에만 있지 않다. 문의 글, 첨부 파일, 검색 색인, 캐시, 분석 데이터, 메일 발송 내역, 외부 연동 서비스, 관리자 다운로드 파일, 백업에도 흔적이 있다. 직접 식별자뿐 아니라 고객 번호와 결합하면 사람을 다시 알아볼 수 있는 간접 식별자도 살핀다. 각 저장 위치마다 데이터 관리자, 저장 목적, 접근 권한, 보관기간, 삭제 방식, 복구 경로를 적는다.
‘삭제’를 모두 같은 의미로 쓰지 않는다. 화면 비공개, 계정 비활성화, 가명 처리, 식별자 분리, 물리적 삭제, 백업 만료는 서로 다른 상태다. 어떤 정보는 분쟁 대응이나 법정 의무 때문에 정해진 기간 동안 별도 보관해야 할 수 있다. 그 경우에도 계속 서비스 화면이나 검색에 노출할 이유는 없다. 보관 사유와 만료 시점을 기록하고, 접근 범위를 좁힌 별도 저장 영역에서 관리한다.
삭제 요청은 상태가 있는 작업으로 만든다
여러 시스템을 한 번에 트랜잭션으로 지울 수 없다면 삭제 요청 ID를 만들고 단계별 상태를 관리한다. 먼저 요청자의 권한을 확인한다. 그다음 계정 접근을 중지하고, 업무 데이터의 삭제·분리 정책을 적용하고, 파일과 색인·캐시·외부 시스템의 작업을 차례로 진행한다. 각 단계가 실패하면 재시도하거나 담당자에게 넘긴다. ‘요청 접수’와 ‘삭제 완료’를 고객에게 같은 말로 안내하면 안 된다.
삭제 순서에도 의미가 있다. 서비스에서 먼저 비공개 처리하면 외부 노출을 빠르게 줄일 수 있지만, 실제 저장소 정리는 계속되어야 한다. 검색 색인의 삭제는 비동기로 늦어질 수 있으므로 완료 확인을 받는다. 오래된 관리자 다운로드 파일이나 임시 변환 파일처럼 중앙 시스템에서 추적하기 어려운 복사본은 생성 단계부터 만료 정책을 붙여야 한다. 애초에 불필요한 복사본을 만들지 않는 것이 가장 쉬운 삭제 설계다.
분석 목적의 데이터는 개인별 원본이 필요한지 다시 묻는다. 집계 수치만으로 목적을 달성할 수 있다면 개인식별자를 계속 보관할 이유가 적다. 다만 ‘익명화’라는 이름만 붙였다고 재식별 가능성이 사라지는 것은 아니다. 어떤 열 조합이 남는지, 외부 데이터와 결합할 수 있는지 평가해야 한다. 제품 팀, 운영 팀, 보안 담당자가 함께 보관 목적과 파기 시점을 검토한다.
백업은 즉시 편집하기보다 복구 위험을 통제한다
백업 파일 안의 한 사람 데이터만 즉시 지우기 어려운 구조가 있다. 그렇다고 백업에서 데이터를 다시 서비스에 되살려도 된다는 뜻은 아니다. 백업의 접근 권한과 보관기간을 제한하고, 만료 시 삭제되도록 관리한다. 복원 시에는 기존 삭제 요청 이력을 재적용하거나, 복구본을 공개하기 전에 삭제 대상이 다시 노출되지 않았는지 검사한다. 백업은 정상 서비스가 아니므로 데이터 사용 목적과 접근을 엄격히 제한한다.
복구 훈련 때도 이 경로를 시험한다. 예전에 삭제한 계정 몇 개를 시험 대상으로 정하고, 복원 후 계정·파일·색인에 다시 나타나지 않는지 확인한다. 삭제 요청 이력 자체는 추적을 위해 일정 기간 필요할 수 있으나, 원래의 민감 데이터를 무한히 복사하는 방식은 피한다. 삭제 완료 증빙에는 요청 ID, 처리 시각, 단계별 결과, 보관 예외의 사유와 만료 예정일 등 필요한 사실만 남긴다.
실패와 이의제기를 예상해 둔다
삭제 작업 중 외부 서비스가 장애를 겪을 수 있다. 요청 전체를 ‘성공’으로 표시하지 말고 해당 위치를 미완료로 남겨 재처리한다. 반대로 보관 의무가 있는 데이터까지 자동 삭제하면 다른 문제가 생길 수 있다. 요청 유형, 데이터 종류, 보관 근거를 정책으로 분리한다. 사용자가 어떤 데이터가 언제까지 남는지 묻는다면 운영자가 시스템별 상태를 조회해 정확하게 답할 수 있어야 한다.
NIST의 데이터 처리 정의에는 수집, 사용, 기록, 공유, 보관, 처분까지 전 수명주기가 포함된다. 삭제를 별도의 마지막 기능으로 붙이기보다 처음 데이터 설계부터 만료와 처분을 고려해야 하는 이유다. 새 기능을 만들 때마다 ‘이 데이터는 어디에 복제되고 언제 없어지는가’를 설계 리뷰의 질문으로 넣는다.
삭제 설계 체크리스트
- DB 밖의 파일·색인·캐시·로그·외부 연동을 지도에 포함했는가?
- 데이터 종류별 삭제와 보관 예외를 구분했는가?
- 요청 접수·진행·완료 상태를 분리했는가?
- 실패한 저장 위치를 재처리할 수 있는가?
- 백업 만료와 복원 후 삭제 이력 재적용을 시험했는가?
- 삭제 증빙은 남기되 원본 개인정보의 중복 보관을 줄였는가?
개인정보 삭제의 품질은 ‘탈퇴 버튼이 작동한다’로 확인할 수 없다. 데이터의 위치를 알고, 예외를 설명하고, 실패를 복구하고, 되살아나지 않음을 검증하는 것이 삭제 수명주기의 끝이다.
