현재 글에서 사용하지 않는 파일이 보이면 정리하고 싶어진다. 하지만 이전 문서와 백업이 그 원본을 필요로 한다면 무엇을 먼저 확인해야 할까.
앞선 패키지 교체에서는 미참조 파일의 공개 검토를 해제하고 보관했다. 이번에는 그 판단을 현재·이력·백업 참조를 나누는 합성 DB 모델로 더 구체적으로 풀었다.
현재 화면에서 안 쓰는 것과 쓸 곳이 없는 것
current 참조를 없앴다고 history와 backup 참조까지 사라지는 것은 아니다. 예제는 세 종류의 관계를 별도로 센다. 현재 문서에서 연결을 해제해도 이력과 백업에 두 관계가 남아 있으면 retain으로 분류한다. 화면에서 보이지 않는다는 이유로 원본을 정리 대상으로 만들지 않으려는 선택이다.
이 목록은 모델이 추적한 참조 범위만 안다. 다른 시스템이나 내려받은 문서가 같은 파일을 필요로 할 수도 있다. 따라서 참조 수가 0이라고 파일 사용이 세상에 하나도 없다고 주장하지 않는다. 실제 운영에서는 어느 보관·조회 경로가 기준 목록에 포함되는지 먼저 정하고 누락될 수 있는 경계를 확인해야 한다.
검토 해제와 삭제는 다른 행동이다
원래 사이트에서 공개하지 않은 이전 패키지는 검토를 해제했고 공개 접근이 막혔는지 확인했다. 파일 원본을 바로 지우지는 않았다. 잘못 참조된 경우와 과거 작업의 근거를 다시 살필 수 있게 남겨 둔 것이다. 이 실제 기록에는 회사 고객 자료가 없으며 이번 글에서도 내부 원본이나 비밀값을 공개하지 않는다.
새 합성 모듈은 current 참조가 있는 자원의 검토를 끄는 행동을 거절한다. 검토를 내리는 동안 현재 문서가 갑자기 사용할 수 없는 상태가 되지 않도록 한 작은 정책이다. 실제 서비스의 공개 내리기 방식은 다를 수 있다. 이 예제의 결정과 기존 사이트의 동작을 같은 기능으로 단정하지 않고 무엇을 보호하는지 설명한다.
정리 함수 대신 검토 목록을 만들었다
resource_preview는 참조가 없으면 manual_review_only라는 처분 후보를 반환한다. 모든 결과의 deleted는 false다. 실제 삭제 API도 없다. 번호가 붙은 결과를 받았다는 이유로 파일을 자동으로 지우는 단계까지 연결하지 않았다. 무엇이 남고 어떤 확인이 필요한지 운영자가 읽어 볼 수 있는 목록이 이 모듈의 결과다.
자동 정리를 설계한다면 보관 기간, 과거 버전의 참조, 실패한 업로드, 복구 사본과 법적·업무 보관 조건을 별도로 정해야 한다. 이 글은 특정 기간을 권하거나 실제 삭제 정책을 대신하지 않는다. 파일을 줄이는 이익과 되돌릴 수 있는 근거를 잃는 영향을 함께 판단할 수 있도록 입력과 결과를 나눠 두었다.
회사의 경계를 넘어서 참조를 세지 않는다
파일 지문이 같더라도 다른 회사의 자원은 별도 메타데이터다. 정리 목록도 해당 회사 범위에서만 읽는다. 다른 회사가 같은 파일을 쓰고 있다는 사실을 한 운영자에게 알려 주지 않는 것이 기본 전제다. 다만 이 코드의 회사 값은 합성 신뢰 문맥이며 실제 로그인이나 관리 권한은 별도로 확인해야 한다.
현재 링크 추가는 검토된 자원에만 허용하고 문서·참조 종류 조합이 같으면 중복 행을 만들지 않는다. 이런 작은 조건이 참조 수의 의미를 지킨다. 실제 저장소에서 파일 바이트가 존재하는지나 물리적으로 지워졌는지를 확인하는 기능은 없으므로 메타데이터의 정리 후보를 저장소 검증 완료라고 부르지 않는다.
먼저 보호되는 사례부터 검사했다
독립 테스트는 현재 연결을 없앤 뒤 이력·백업 참조가 남아 보호되는지 확인한다. 모든 참조를 해제한 경우에도 결과가 수동 검토 후보이고 삭제되지 않았는지 대조한다. 같은 연결을 반복해 수가 늘지 않는지, 현재 참조가 있는데 검토를 끄려 하면 거절되는지도 별도 검사다. 좋은 정리 결과는 지울 항목만 찾는 것이 아니라 남길 이유를 놓치지 않는 데서 시작한다.
기록 뷰어에서 보호되는 목록과 참조가 없는 목록을 비교할 수 있다. 실제 로컬 합성 실행 결과이며 운영 파일 삭제나 실브라우저 검수가 아니다. 나는 즉시 지우는 기능보다 잘못 정리했을 때 무엇을 잃는지 읽을 수 있는 단계가 먼저라고 보았다. 공유 코드는 자신의 보관 정책을 추가하기 전 그 경계를 확인하는 출발점이다.