같은 파일을 여러 문서에 붙일 때 원본을 매번 복제해야 할까. 그렇다고 내용이 같다는 이유만으로 다른 회사의 파일까지 같은 공개 대상으로 다뤄도 될까.
나는 파일 내용의 식별과 업무의 연결을 나누는 작은 메타데이터 모델을 만들었다. 실제 파일 업로드나 객체 저장을 수행하지 않으며 합성 바이트의 지문과 참조 관계를 로컬 DB로 시험했다.
내용이 같다는 사실이 소유 범위를 지우지는 않는다
예제의 register_resource는 합성 바이트의 SHA-256과 길이를 계산한다. 같은 회사 안에 같은 지문이 있으면 기존 메타데이터 식별자를 돌려준다. 다른 회사에서는 별도의 식별자를 만든다. 내용이 같아도 다른 회사에 이미 같은 파일이 있는지 그 결과를 알려 주지 않도록 범위를 나눈 것이다.
이것은 파일 업로드를 끝냈다는 기능이 아니다. 바이트를 받아 지문과 크기만 저장하며 원본 바이트는 보관하지 않는다. 실제 저장소를 붙일 때는 객체가 완전히 저장됐는지, 해시가 서버에서 확인됐는지, 회사의 접근 정책이 무엇인지 추가로 구현해야 한다. 같은 파일을 찾았다는 메타데이터 결과를 내려받을 수 있는 원본이 있다는 보장으로 부르지 않는다.
원본 하나와 연결 여러 개를 따로 두었다
자원 메타데이터에는 내용 식별 정보가 있고 refs에는 문서와 연결한 목적이 남는다. 같은 파일을 두 문서에 붙이면 자원이 복제되는 대신 관계가 추가된다. 다만 어떤 문서의 권한을 가진 사람이 그 파일을 읽을 수 있는지는 실제 서버에서 확인해야 한다. 이번 합성 모델은 문서 ID와 회사가 신뢰할 문맥에서 들어온다고 가정한다.
기존 제작기에서는 한 원본이 여러 발주와 현장에 연결되는 업무 의미를 다뤘다. 이번에는 그 설명과 구별해 같은 내용의 식별과 회사 범위, 검토 상태를 작은 DB 제약으로 시험했다. 관계를 나누면 편리하다는 말에서 끝내지 않고 어떤 필드가 고유하고 무엇이 여러 개가 될 수 있는지 코드로 읽을 수 있게 했다.
재사용했다고 검토까지 끝난 것은 아니다
처음 등록한 메타데이터는 reviewed가 꺼져 있다. 검토하기 전에는 current·history·backup 어느 참조도 붙이지 않는다. 같은 내용을 다시 등록해 기존 ID를 돌려받아도 검토 상태가 자동으로 켜지지 않는다. 내용 중복과 공개하거나 사용해도 되는지는 별도의 판단이기 때문이다.
실제 사이트에서도 업로드 완료와 원고 참조, 공개 검토를 나눠 관리해 왔다. 이번 예제는 그 상태 전체를 복제한 서버가 아니라 독립된 작은 계약이다. 바이러스 검사나 저작권·개인정보의 자동 판단도 하지 않는다. 검토 상태가 어떤 근거를 뜻하는지 실제 조직에서 정해야 하며 체크 하나로 모든 검수가 끝났다고 설명해서는 안 된다.
문서에서 뺀 뒤에도 연결의 종류가 남는다
예제는 current와 history, backup을 서로 다른 참조 종류로 둔다. 현재 화면에서 파일을 뺐더라도 과거 문서나 백업이 같은 자원을 필요로 할 수 있다. 한 관계를 해제했다고 원본을 지우지 않는다. 같은 문서·종류의 연결을 반복해도 고유 조건 덕분에 참조가 두 개로 늘지 않는지도 검사했다.
이 구조는 실제 저장소의 수명 주기 정책을 대신하지 않는다. DB 밖의 참조나 외부 시스템의 보관은 목록에 없을 수 있다. 모든 파일 사용처를 안다고 주장하지 않고 이 모델이 추적한 범위 안에서만 관계 수를 읽는다. 내용 지문은 파일의 출처나 작성자도 증명하지 않는다는 앞선 원칙을 그대로 유지했다.
재사용 결과를 보여 주는 방법
실행 기록에는 같은 회사에서 두 번 등록해 같은 ID가 돌아온 결과와 다른 회사에서는 새 ID가 생긴 결과가 나란히 있다. 독립 테스트는 검토 전 연결 거절, 다른 회사 연결 거절과 반복 연결의 참조 수를 확인한다. 이 자료는 고정 합성 바이트로 만들어졌고 실제 회사의 파일 이름이나 도메인을 포함하지 않는다.
실무 적용은 객체 저장·서버 인증·문서 소유 범위·다운로드 경로·변경 이력과 함께 검토해야 한다. 공유 패키지는 내용과 연결을 섞지 않게 하는 메타데이터 실험이다. 나는 중복 파일을 줄인다는 표현보다 무엇을 재사용하고 어떤 관계와 검토는 새로 남겨야 하는지 설명하는 쪽이 더 도움이 된다고 보았다.