병원 홈페이지 글을 고쳤다면, 최종본만 남기지 말고 변경 이유를 기록합니다

병원 홈페이지 문장을 고친 뒤 최종 원고만 남기면 왜 바뀌었는지, 어느 근거를 썼는지, 누가 승인했는지 다시 확인하기 어렵습니다. 반대로 저장할 때마다 모든 파일을 수동 복사하면 중요한 변경이 사소한 기록 사이에 묻힙니다. 변경 단위, 이유, 승인, 운영 반영을 하나의 이력으로 연결해야 합니다.

먼저 수정 단위를 식별합니다

원고 ID와 공개 URL, 변경 전 버전, 작업 시작 시각을 기록합니다. 제목만 고쳤는지, 의료 설명과 수치를 바꿨는지 범위를 구분합니다. 여러 페이지의 공통 문구를 수정했다면 각 URL과 공통 템플릿 변경을 따로 표시합니다.

WordPress 공식 문서는 글의 리비전이 저장된 변경을 비교하고 이전 상태를 복원하는 데 쓰인다고 설명합니다. WordPress 리비전 안내 실제 사이트의 저장 정책과 보관 수는 설정에 따라 다를 수 있으므로 기능이 있다는 이유만으로 모든 이력이 영구 보존된다고 가정하지 않습니다.

가정으로 한 글을 6번 저장했지만 실질 변경이 출처 교체 1건과 수치 수정 1건이라면 저장 버전은 6개, 보고할 변경은 2건입니다. 둘을 같은 개수로 부르지 않습니다.

무엇을 왜 바꿨는지 짧게 남깁니다

변경 이유는 '수정함'이 아니라 공식 근거 변경, 오탈자, 독자 질문 보완, 내부 링크 교체처럼 구체적으로 적습니다. 근거가 있는 변경은 확인한 출처와 날짜를 연결합니다. 담당자의 표현 선호와 사실 오류 수정을 구분하면 재검토 범위를 정하기 쉽습니다.

변경 전후의 핵심 문장을 함께 남기되 개인정보가 든 초안이나 상담 내용을 이력에 무분별하게 복사하지 않습니다. 이미지 안의 수치나 캡션이 달라졌다면 파일 버전과 대체 텍스트도 변경 범위에 포함합니다.

긴 원고 전체를 매번 승인받기보다 변경 요약과 영향 구간을 제공할 수 있습니다. 다만 치료 설명처럼 주변 문맥까지 영향을 받는 변경은 해당 문단 전체를 다시 검토합니다.

승인한 버전과 발행한 버전을 대조합니다

승인 기록에는 담당자, 검토 항목, 승인 시각, 대상 버전을 적습니다. 승인 뒤 누군가 원고를 다시 고쳤다면 기존 승인으로 발행하지 않습니다. 긴급 수정은 사후 승인을 포함한 별도 절차와 책임자를 정합니다.

배포 뒤 실제 HTTPS 페이지에서 수정 문장, 이미지, 링크, 표시 날짜와 canonical을 확인합니다. 편집 화면의 버전 번호와 운영 배포 ID를 연결하면 캐시나 잘못된 배포를 조사할 수 있습니다.

되돌리기가 필요할 때는 본문만 복원하지 말고 그 버전에 맞는 이미지와 링크, 메타 정보도 확인합니다. 복원 작업 자체도 새 변경 이력으로 남깁니다.

보관 기간과 접근 권한을 정합니다

모든 자동 저장을 같은 기간 보관할 필요는 없지만 실질 변경과 승인 증거를 언제까지 유지할지 기준이 필요합니다. 퇴사자 계정이나 외부 대행사의 개인 저장소에만 이력이 남지 않도록 조직이 접근 가능한 위치를 정합니다.

완료 보고에는 변경 건수, 보류, 승인 상태, 운영 확인 결과를 적습니다. 저장 횟수를 콘텐츠 개선 횟수나 신규 발행 수로 부풀리지 않습니다.

출처 확인일: 2026-10-26. 저장 횟수와 변경 수는 설명용 가정입니다. 구체적인 의료·개인정보 기록 보존 기간은 조직의 책임자와 별도로 검토해야 합니다.