"고쳤다"가 끝이 아닌 이유
수정 작업을 마치고 완료로 표시합니다. 그런데 검색 결과는 그대로입니다. 이런 일이 왜 생길까요.
수정이 화면에 도달하기까지 여러 단계를 거치기 때문입니다. 그중 하나만 어긋나도 공개 페이지는 예전 그대로입니다.
반영되지 않는 흔한 경우
캐시가 남아 있다 CDN이나 서버 캐시에 예전 응답이 남아 있으면, 원본을 고쳐도 방문자와 크롤러에게는 옛 내용이 나갑니다. 캐시 수명이 길수록 오래갑니다.
스테이징에만 적용됐다 개발 환경에서 확인하고 완료로 표시했는데 운영 배포가 빠진 경우입니다. 확인은 분명히 했으니 담당자는 고쳤다고 믿습니다.
다음 배포에서 되돌아갔다 설정 파일을 직접 고쳤는데 그 파일이 배포 때마다 덮어써지는 경우입니다. 며칠은 정상이다가 배포 후 원래대로 돌아갑니다. 이게 가장 발견하기 어렵습니다.
일부 페이지만 적용됐다 템플릿이 여러 개인데 하나만 고친 경우입니다. 확인한 페이지는 정상이고 나머지는 그대로입니다.
확인 방법은 하나
공개된 페이지를 다시 받아서 값을 보는 것입니다.
관리 화면의 설정값을 보는 것으로는 부족합니다. 설정은 맞는데 출력이 다른 경우가 위의 사례들입니다. 실제 응답을 봐야 합니다.
같은 이유로 브라우저 화면만 보는 것도 충분하지 않습니다. 응답 헤더나 meta 태그는 화면에 나타나지 않습니다.
재발을 추적해야 하는 이유
한 번 확인하고 끝내면 "다음 배포에서 되돌아갔다"를 놓칩니다.
해결로 확인된 문제가 나중에 다시 나타나면 신규가 아니라 재발로 구분하는 편이 좋습니다. 신규 문제와 재발 문제는 대응이 다르기 때문입니다.
- 신규 → 왜 생겼는지 파악하고 고칩니다
- 재발 → 왜 되돌아갔는지를 봐야 합니다. 대개 배포 과정이나 설정 관리에 원인이 있습니다
재발을 신규로 처리하면 같은 문제를 반복해서 고치면서 근본 원인을 못 찾습니다.
검색 결과에 반영되는 시점은 별개
여기서 구분할 것이 있습니다.
- 수정이 페이지에 반영됐는가 — 재수집으로 바로 확인 가능
- 검색 결과에 반영됐는가 — 검색엔진이 다시 방문한 뒤
앞쪽은 우리가 확인하고 통제할 수 있습니다. 뒤쪽은 시간이 걸리고 우리가 정할 수 없습니다.
작업의 완료 기준은 앞쪽으로 잡는 편이 현실적입니다. 뒤쪽을 기준으로 삼으면 언제 끝났는지 알 수 없습니다.