보고서를 받고도 안 바뀌는 이유
진단을 돌리면 문제 목록이 나옵니다. 그런데 몇 주 뒤에 보면 그대로인 경우가 많습니다. 담당자가 게을러서가 아니라, 대개 움직이기에 정보가 부족해서입니다.
"제목 태그가 없습니다"라는 항목을 받았다고 해봅시다. 담당자는 이런 질문에 부딪힙니다.
- 어느 페이지 얘기인가
- 지금 뭐라고 돼 있길래 없다는 건가
- 어디를 고쳐야 하나 (관리 화면? 템플릿? 서버?)
- 고치면 뭐라고 넣어야 하나
- 고친 뒤 어떻게 확인하나
이 다섯 가지가 채워지지 않으면 항목은 목록에 남습니다.
문제를 작업으로 바꾸는 것
같은 항목이라도 이렇게 오면 다릅니다.
| 필요한 것 | 예시 |
|---|---|
| 대상 | /products/abc 외 12개 URL |
| 발견값 | 응답 HTML에 <title> 없음 |
| 위치 | 상품 상세 템플릿의 head 영역 |
| 방법 | 상품명과 카테고리를 조합해 출력 |
| 검증 | 해당 URL을 다시 수집해 title이 채워졌는지 확인 |
이제 담당자는 무엇을 할지 압니다. 판단할 것이 남지 않았습니다.
위치를 아는 것이 절반이다
수정 위치는 사이트가 쓰는 플랫폼에 따라 다릅니다.
- 콘텐츠 관리 화면에서 고치는 것 (제목, 설명, 본문)
- 테마·템플릿을 고쳐야 하는 것 (구조, 반복되는 요소)
- 서버 설정이 필요한 것 (리디렉션, 응답 헤더)
같은 "제목 없음"이라도 워드프레스면 편집 화면에서, 직접 개발한 사이트면 템플릿에서 고칩니다. 플랫폼을 모르면 안내가 뭉뚱그려집니다.
그래서 진단할 때 사이트가 쓰는 플랫폼을 함께 감지해 두면, 안내를 그 플랫폼에 맞춰 줄 수 있습니다. 감지가 확실하지 않으면 확정된 것처럼 쓰지 않고 추정 상태로 구분해 표기하는 편이 안전합니다.
상태로 관리하기
작업으로 바꾼 뒤에는 상태가 필요합니다. 지금 무엇이 손을 기다리고 무엇이 검증을 기다리는지 목록에서 보여야 합니다.
- 조치 필요 → 확인 완료 → 수정 중 → 수정 완료·재검증 대기 → 해결 확인
중간의 수정 완료·재검증 대기가 중요합니다. "고쳤다"와 "고쳐진 것이 확인됐다"는 다르기 때문입니다. 이 둘을 구분하지 않으면 반영되지 않은 수정이 완료로 잡힙니다.
우선순위
모든 문제를 한 번에 고칠 수는 없습니다. 순서를 정할 때는 영향 범위를 봅니다.
색인을 막는 문제 한 건은 이미지 대체문구 누락 열 건보다 급합니다. 전체 점수 같은 하나의 숫자로는 이 차이가 보이지 않으므로, 영역과 영향도를 나눠서 보는 편이 낫습니다.
예외 처리
모든 지적을 고쳐야 하는 것은 아닙니다. 의도해서 그렇게 둔 경우가 있습니다.
이럴 때 항목을 그냥 무시하면 다음 진단에서 또 올라옵니다. 사유를 적어 예외로 표시하면 목록에서 빠지되 기록은 남습니다. 나중에 담당자가 바뀌어도 왜 그렇게 뒀는지 알 수 있습니다.