오류 수정과 재발 예방의 판단 기준
기술 문제의 재발을 줄이려면 오류를 고치는 데서 끝내지 않고, 콘텐츠 접근·렌더링 제한을 설계 조건에 반영해야 합니다. 수집 차단이나 색인 제외 설정이 다시 들어가지 않도록 변경 책임과 확인 기준을 묶는 예방 장치도 마련해야 합니다. 수정 완료의 판단은 현재 오류가 사라졌는지를 다루고, 예방 설계의 판단은 같은 변경이 반복될 때 정상 조건을 유지할 수 있는지를 다룹니다.
운영자는 재발한 오류 이름보다 그 오류를 다시 만든 변경 조건을 먼저 정리해야 합니다. 설정을 복원하면 당장 문제가 사라져도, 다음 페이지 개편이나 공통 설정 적용에서 같은 조건이 돌아올 수 있습니다. 개발 담당에게는 어떤 변경이 어느 설정에 영향을 주었는지, 그 설정이 다른 페이지에도 적용되는지 설명해 달라고 요청합니다. 원인이 확정되지 않았다면 추정과 실제 변경 기록을 따로 기재합니다.
| 재발을 일으킨 변경 조건 | 유지할 정상 조건 | 운영상 예방 규칙 | 변경 책임 |
|---|---|---|---|
| 공통 설정에 수집 차단 재적용 | 공개 대상의 수집 허용 | 차단 변경 시 적용 범위 기록 | 설정 변경자와 공개 범위 승인자 |
| 공개 페이지에 색인 제외 설정 잔류 | 공개 목적에 맞는 색인 허용 상태 | 공개 전 제외 사유와 해제 여부 대조 | 배포 담당과 콘텐츠 운영자 |
| 페이지 개편으로 필수 콘텐츠 접근 제한 | 필수 콘텐츠의 접근·렌더링 조건 유지 | 구현 변경 시 기존 조건의 유지 근거 제출 | 개발 담당과 페이지 기획 담당 |
| 오류 수정 설정이 이후 변경에서 소실 | 수정된 설정의 적용 상태 유지 | 공통 설정 변경 요청에 기존 수정 내역 첨부 | 공통 설정 관리 담당 |
표의 예방 규칙과 책임 배치는 사이트 운영을 위한 제안이며, 구글이 정한 업무 분담 방식은 아닙니다. 운영자는 실제 변경 권한을 가진 사람을 책임자로 지정하고, 승인자가 판단할 자료까지 요청 내용에 포함합니다. 이름만 등록하고 변경 범위나 제출 자료를 정하지 않으면 다음 작업자가 무엇을 유지해야 하는지 알기 어렵습니다.
페이지 설계에 반영할 기술 조건
구글 검색 센터는 구글 검색이 자바스크립트를 실행하더라도 크롤러의 콘텐츠 접근과 렌더링에 관한 제한을 페이지 설계에서 고려해야 한다고 설명합니다. 개발 담당에게는 현재 구현을 유지하라는 요청보다, 필수 콘텐츠를 전달하는 조건을 변경 후에도 유지해 달라고 요청하는 편이 구체적입니다. 구현 방법을 변경할 수는 있지만 정상으로 인정한 조건까지 함께 없어져서는 안 됩니다.
공개 범위는 운영자가 정하고, 이를 충족하는 기술 조건은 개발 담당과 문서로 정리합니다. 공개하려는 콘텐츠가 어떤 접근 조건을 전제로 하는지, 렌더링에 필요한 리소스가 무엇인지 기재합니다. 정상 조건에는 관측 자료의 종류도 연결하여 다음 변경자가 이전 판단의 근거를 찾을 수 있게 합니다. 공개 목적을 변경할 때에는 기술 설정만 수정하지 말고 정상 조건 문서도 함께 갱신합니다.
변경 조건부터 관측까지의 실행 순서
마케팅 담당자는 개발 담당에게 오류를 다시 수정해 달라는 요청과 재발 조건을 제거해 달라는 요청을 따로 전달합니다. 전자는 현재 상태를 복구하는 작업이고, 후자는 이후 변경에 적용할 규칙을 정하는 작업입니다. 재발 조건을 설명할 때에는 문제 발생 전후의 설정 자료와 이전 수정 기록을 함께 준비합니다.
- 재발을 일으킨 변경 조건을 정리합니다. 설정 변경 내역, 적용 범위, 이전 수정 사유를 모아 문제와 연결된 변경을 개발 담당에게 가려 달라고 요청합니다.
- 유지할 접근·렌더링 조건을 정합니다. 콘텐츠 운영자는 공개 목적을 설명하고, 개발 담당은 그 목적을 유지하는 데 필요한 조건과 판단 자료를 기재합니다.
- 변경 책임과 예방 규칙을 연결합니다. 설정을 변경할 사람, 공개 범위를 승인할 사람, 변경 후 자료를 제출할 사람을 명시하고 작업 요청에 포함합니다.
- 관측 결과로 규칙을 보완합니다. 다시 발견된 문제가 기존 규칙의 누락인지, 규칙을 적용하지 않은 결과인지 가린 뒤 보완 요청을 전달합니다.
요청 문장은 개발 담당이 작업 범위를 정할 수 있을 만큼 구체적이어야 합니다. “다시 차단되지 않게 해 주세요” 대신 “공통 설정을 변경할 때 공개 대상에 영향을 주는 항목과 유지 근거를 함께 제출해 주세요”라고 요청합니다. 렌더링 방식 변경에는 “기존 정상 조건을 충족하는 자료와 충족하지 못하는 조건을 나누어 전달해 주세요”라는 문장을 사용할 수 있습니다.
예방 규칙과 준비 자료의 연결
준비 자료는 작업 완료를 주장하는 문서보다 예방 규칙의 적용 여부를 판단할 수 있는 자료여야 합니다. 운영자는 개발 담당의 설명과 실제 설정 기록을 같은 변경 건에 연결합니다. 아래 표는 관측 결과에 따라 업무 규칙을 보완하기 위한 기록 구성안입니다.
| 예방 규칙 | 확인할 자료 | 다시 발견된 문제 | 규칙 보완 요청 |
|---|---|---|---|
| 차단 변경의 적용 범위 기록 | 변경 전후 설정과 적용 대상 | 공개 대상까지 차단됨 | 공개 범위 승인 항목 추가 |
| 공개 전 색인 제외 사유 대조 | 태그·헤더 상태와 공개 요청 기록 | 불필요한 제외 설정 잔류 | 제외 사유 해소 자료 제출 |
| 구현 변경 시 정상 조건 유지 | 렌더링 자료와 리소스 변경 내역 | 필수 콘텐츠 전달 조건 누락 | 영향받는 조건을 변경 요청에 기재 |
| 공통 설정 변경에 수정 내역 첨부 | 이전 수정 기록과 현재 적용 설정 | 기존 수정 내용 소실 | 수정 항목의 반영 여부 기록 |
자료가 없다는 사실만으로 규칙을 지키지 않았다고 단정하지는 않습니다. 기록 누락과 설정 오류를 따로 처리하고, 자료를 제출할 책임이 비어 있다면 해당 업무를 배정합니다. 규칙을 준수했는데도 같은 문제가 발생했다면 담당자에게 재교육만 요청하기보다 규칙이 다루지 못한 변경 조건을 추가해야 합니다.
수집 차단과 색인 제외의 혼동
수집을 막는 설정과 색인을 제외하는 설정을 같은 예방 항목으로 처리하면 변경 목적을 잘못 판단할 수 있습니다. 구글은 robots.txt로 수집을 차단해도 페이지 주소가 검색결과에 남을 수 있다고 설명합니다. 색인을 제외하려는 경우에는 구글이 페이지를 수집할 수 있는 상태에서 noindex를 사용하도록 안내합니다.
운영자는 두 설정에 서로 다른 변경 사유를 요구하는 규칙을 제안할 수 있습니다. 공개 대상의 접근을 유지하려는 작업인지, 특정 콘텐츠를 색인 대상에서 제외하려는 작업인지 요청서에 기재합니다. “검색 차단”처럼 목적과 설정을 함께 설명하지 않는 표현만으로 승인하면 개발 담당이 다른 조치를 선택할 수 있습니다. 승인자는 요청 목적과 실제 변경 항목이 일치하는지를 판단합니다.
이전에 제거했던 차단 설정이 다시 발견되어도 곧바로 같은 원인의 재발로 처리하지는 않습니다. 공개 목적이 달라진 것인지, 공통 설정이 다시 적용된 것인지 먼저 가려야 합니다. 의도된 제외라면 예외 사유와 적용 범위를 남기고, 의도하지 않은 변경이라면 앞에서 정한 기준에 따라 예방 규칙의 누락을 기록합니다.
관측 자료의 한계와 규칙 보완
구글 검색 센터는 클라이언트 측 분석만으로 구글봇과 웹 렌더링 서비스의 활동을 빠짐없이 표현하기 어렵다고 설명합니다. 필수 콘텐츠에 기여하지 않는 일부 리소스는 가져오지 않을 수 있기 때문입니다. 따라서 분석 기록에 활동이 없다는 이유만으로 접근 조건이 유지되지 않았다고 판정하면 예방 규칙을 잘못 수정할 수 있습니다.
구글은 관련 활동을 관측하는 자료로 서치 콘솔의 크롤링 통계 보고서를 안내합니다. 렌더링 문제 조사에는 리치 결과 테스트나 URL 검사 도구에서 얻는 리소스와 렌더링된 문서 등의 자료를 활용할 수 있다고 설명합니다. 운영 기록에는 자료마다 판단할 수 있는 범위를 기재하고, 활동 관측과 현재 설정의 근거를 서로 대체하지 않도록 합니다.
URL 검사 도구의 실시간 테스트도 모든 색인 문제를 찾아내지는 못합니다. 구글 기술 요구사항을 충족한 상태 역시 색인 생성을 보장하지 않습니다. 운영자는 관측 결과를 변경 조건과 연결해 규칙을 보완하되, 검색결과에 나타나지 않았다는 사실만으로 이전 기술 오류가 재발했다고 단정하지 않습니다.
자주 묻는 질문
개발 담당자가 바뀌면 예방 규칙도 새로 만들어야 합니까?
담당자가 바뀌었다는 이유만으로 기존 규칙을 폐기할 필요는 없습니다. 후임자가 실제 변경 권한을 넘겨받았는지와 기록에 접근할 수 있는지를 먼저 정리합니다. 현재 업무 방식에서 수행할 수 없는 항목이 있다면 담당자를 재지정하거나 제출 자료를 조정하고, 기술적 사유 없이 규칙을 삭제하지 않습니다.
원인이 확정되지 않은 문제에도 예방 규칙을 정할 수 있습니까?
원인 확정 전에는 잠정 규칙으로 관리할 수 있습니다. 의심하는 변경 조건과 아직 확보하지 못한 근거를 함께 기재하여 추정을 확정 사실로 처리하지 않습니다. 개발 담당에게는 원인이 입증되거나 배제될 때 잠정 규칙을 유지할지 종료할지도 판단해 달라고 요청합니다.
긴급 복구 때 예방 규칙을 생략해도 괜찮습니까?
복구가 급하다면 규칙을 완성하는 작업을 분리할 수 있지만, 생략한 항목을 기록 없이 처리해서는 안 됩니다. 복구 요청에 미완료 항목과 후속 판단 책임을 남깁니다. 변경을 되돌린 뒤 예방 작업이 남아 있다는 사실을 운영자와 개발 담당이 같은 기록에서 읽을 수 있어야 합니다.
외부 서비스가 만든 오류에도 변경 책임을 지정해야 합니까?
외부 서비스의 내부 오류를 직접 수정할 책임과 사이트에서 대응을 결정할 책임은 다릅니다. 운영자는 서비스 업체에 전달할 자료를 모으는 사람과 사이트 적용 여부를 결정할 사람을 지정할 수 있습니다. 업체의 답변을 기다리는 상태와 사이트에서 처리할 수 있는 조치를 나누어 기록합니다.
예방 규칙이 많아지면 모두 그대로 유지해야 합니까?
현재 구현과 관계없는 규칙까지 무조건 유지할 필요는 없습니다. 개발 담당에게 규칙이 전제로 삼은 기능이나 설정이 아직 존재하는지 설명해 달라고 요청합니다. 삭제할 때에는 적용 대상이 없어졌는지, 다른 규칙이 같은 조건을 관리하는지 근거를 남겨 이후 작업자가 삭제 사유를 이해할 수 있게 합니다.