홈페이지에서 내려받은 파일의 생성일이 최근인데 내용은 오래됐거나, 최신 보고서인데 운영체제에는 과거 날짜로 보이는 일이 있다. 파일 생성일은 복사와 변환 과정에서 바뀔 수 있어 콘텐츠의 최초 작성일이나 마지막 검토일과 같지 않다. 이용자가 버전을 판단하게 하려면 기술 메타데이터와 편집 날짜를 구분하고 공개 화면에는 의미 있는 기준일을 선택해야 한다.
날짜마다 뜻을 분명히 이름 붙이기
초안 작성일, 내용 검토일, 최종 수정일, PDF 변환일, 서버 업로드일을 별도 필드로 관리한다. 공개 페이지에서 하나만 보여준다면 문서 성격에 맞춰 ‘내용 기준일’ 또는 ‘최종 수정일’처럼 의미를 적는다. 운영체제의 생성일을 근거 없이 편집 날짜로 사용하지 않는다. 외부에서 받은 파일은 작성자가 제공한 버전 정보와 내부 확인 날짜를 함께 기록한다. 시간대가 다른 시스템을 거칠 때 날짜가 하루 앞뒤로 달라질 수 있으므로 저장 기준과 표시 시간대를 정한다.
변환·복사 때 바뀌는 메타데이터 점검
문서 형식을 바꾸거나 압축을 풀고 다시 묶으면 파일 시스템 날짜가 새로 생성될 수 있다. 자동 배포가 매번 모든 파일의 시간을 갱신하는지, 내용이 달라진 항목만 바뀌는지 확인한다. PDF 속성의 생성 도구와 작성자 필드에 내부 정보가 불필요하게 남지 않았는지도 살핀다. 문서 안쪽의 표지 날짜, 파일명 날짜, 다운로드 화면 날짜가 서로 다르면 무엇이 최신인지 정해 통일한다. 단순 맞춤법 수정과 정책 변경을 같은 수준의 개정으로 보이지 않게 변경 요약을 보완할 수 있다.
이용자가 최신본을 확인할 경로 제공하기
다운로드 링크 옆에 파일 버전, 최종 검토일, 변경된 핵심 항목을 표시한다. 같은 이름으로 파일을 교체하면 캐시에 이전본이 남을 수 있으므로 버전 식별 방식과 캐시 갱신을 시험한다. 보관이 필요한 과거본은 최신본과 분리하고 현재 문서로 이동할 링크를 둔다. 게시 뒤 실제 파일을 내려받아 속성과 내용 날짜를 대조한다. 생성일 관리는 새 문서처럼 보이게 만드는 장치가 아니라 이용자가 어느 시점의 정보를 읽고 있는지 확인하게 하는 투명성의 문제다.
‘날짜마다 뜻을 분명히 이름 붙이기’ 검토를 인계할 때 남길 네 가지
‘날짜마다 뜻을 분명히 이름 붙이기’를 다른 담당자에게 넘길 때는 결과 파일만 전달하지 않고 수정 이유, 사용한 기준, 확인하지 못한 부분, 다음 점검 시점을 함께 남깁니다. 특히 ‘변환·복사 때 바뀌는 메타데이터 점검’의 문구가 승인됐는지와 ‘이용자가 최신본을 확인할 경로 제공하기’의 링크가 실제 공개 주소에서 작동하는지를 분리해서 기록해야 합니다. ‘홈페이지 파일의 생성일과 수정일을 구분해 표시하기’의 표현을 다시 바꾸려는 사람은 먼저 이 기록에서 기존 결정의 근거를 확인하고, 상황이 달라진 항목만 새 자료로 교체합니다. 이 네 가지가 있으면 담당자가 바뀌어도 ‘날짜마다 뜻을 분명히 이름 붙이기’의 결론을 임의로 넓히거나 ‘변환·복사 때 바뀌는 메타데이터 점검’의 검토를 완료로 오인하는 위험을 줄일 수 있습니다.