원하는 공개 상태를 담은 요청서
AI검색최적화 기술 작업은 원하는 공개 상태와 개발자가 설명할 변경사항, 수정 후 제출할 확인 자료를 나눈 요청서로 전달합니다. 요청서에는 확인만으로 보장할 수 없는 결과도 구분하여 적고, 막연한 AI 노출 개선을 완료 조건으로 삼지 않습니다.
이미 정한 작업이라도 개발자가 무엇을 변경하고 운영자가 어떤 자료로 완료를 판단할지 연결되지 않으면 요청이 모호해집니다. 운영자는 대상 페이지의 이름과 위치를 기재하고, 수정 뒤 허용하려는 접근과 유지해야 할 제한을 설명합니다. 개발자에게는 그 상태를 만드는 변경과 함께 영향을 받는 기능을 설명해 달라고 요청합니다.
공개 상태는 검색에 나오기를 바란다는 희망보다 구체적이어야 합니다. 운영자는 공개할 본문, 로그인 없이 접근할 범위, 계속 비공개로 유지할 내용을 정합니다. 개발자가 내용을 임의로 공개하거나 접근 제한을 해제하지 않도록 유지 조건도 같은 요청에 포함합니다.
운영자의 결정과 개발자의 설명
다음 항목은 운영자가 기술 작업 요청서에 사용할 수 있는 구성입니다. 빈칸을 개발자의 추측에 맡기지 않고, 운영자가 결정할 내용과 개발자가 설명할 내용을 나누어 작성합니다. 확정하지 못한 사항은 승인 전 해결할 질문으로 표시합니다.
| 요청서 항목 | 운영자가 적을 내용 | 개발자에게 받을 설명 |
|---|---|---|
| 목표 공개 상태 | 공개할 본문과 유지할 접근 제한 | 목표 상태를 만드는 변경 방식 |
| 변경 대상 | 이미 정한 작업과 대상 페이지 | 변경할 설정·코드와 적용 범위 |
| 보존 조건 | 유지할 기능과 공개하면 안 되는 정보 | 예상 영향과 문제가 생겼을 때의 복구 방법 |
| 완료 보고 | 완료 판단에 사용할 자료와 수신 담당자 | 검사 대상·결과와 남은 제한사항 |
구글 검색 센터는 전문가에게 사이트 변경사항을 공유받고 권장 내용과 이유를 설명받도록 안내합니다. 운영자는 이를 작업 협의에 적용해 변경 전 설명과 수정 후 보고를 요청서의 별도 항목으로 만듭니다. 설명을 받았다는 사실과 해당 변경을 승인했다는 사실도 따로 기록합니다.
완료 조건을 정하는 판단 기준
완료 조건은 개발자가 실행할 수 있고 운영자가 자료로 판정할 수 있는 문장으로 작성합니다. 구글의 기술 요구사항은 크롤러 접근, 정상적인 페이지 응답, 색인 생성 가능한 콘텐츠를 제시하지만, 이를 충족해도 색인을 보장하지 않습니다. 요청서에는 해당 작업으로 충족하려는 조건을 적고 검색 서비스가 결정하는 결과는 제외합니다.
판정 문장에 ‘개선’이나 ‘최적화’만 있으면 무엇을 제출해야 하는지 다시 질문해야 합니다. 운영자는 어떤 대상에서 어떤 상태를 입증할지 명시하고, 개발자에게 그 조건을 검사할 수 있는지 답변을 받습니다. 검사할 수 없는 조건이 있다면 승인 전에 이유와 대체 자료를 협의합니다.
합의부터 완료 보고까지의 순서
운영자는 원하는 공개 상태를 먼저 합의한 뒤 변경 설명을 받고, 수정이 끝나면 제출 자료를 검토합니다. 요청서의 항목을 채웠다는 이유만으로 바로 적용하지 않고, 개발자의 답변에서 승인할 내용을 확정합니다. 다음 순서는 이미 결정한 기술 작업을 실행 요청으로 전환할 때 사용합니다.
- 운영자는 대상 목록과 공개할 본문, 유지할 제한, 현재 문제를 보여 주는 자료를 전달합니다. 개발자는 요청의 의미가 불명확하거나 서로 충돌하는 조건을 질문합니다.
- 개발자는 변경할 내용과 이유, 함께 영향을 받는 기능을 설명합니다. 운영자는 보존 조건과 충돌하는 변경을 조정하고 적용할 내용을 승인합니다.
- 개발자는 승인한 변경을 적용한 뒤 검사 대상과 결과를 제출합니다. 운영자는 합의한 완료 조건에 대조하고 누락된 자료나 미해결 사항을 회신합니다.
운영자가 준비할 자료에는 현재 설정을 추측한 설명보다 실제 문제가 드러나는 화면이나 기존 보고서를 포함합니다. 원인을 아직 확정하지 못했다면 발생한 현상과 개발자에게 묻는 내용을 따로 기재합니다. 콘텐츠 문구나 접근 권한을 결정할 담당자도 지정해 기술 담당자가 사업상 결정을 대신하지 않도록 합니다.
완료 확인 자료의 읽는 범위
완료 보고에는 검사 이름만 기재하지 않고 대상 페이지, 검사 시점, 결과, 공유할 자료를 포함하도록 요청합니다. 구글의 주소 검사 도구에서는 색인에 저장된 정보와 현재 페이지를 시험한 결과가 서로 다른 상태를 다룹니다. 개발자는 어떤 상태를 검사했는지 표시하고 운영자는 자료의 의미에 맞춰 완료 여부를 판단합니다.
| 완료 확인 자료 | 확인할 수 있는 내용 | 확정할 수 없는 결과 |
|---|---|---|
| 변경 내역과 적용 기록 | 합의한 변경의 적용 대상과 내용 | 검색 서비스의 반영 여부 |
| 주소 검사 실시간 결과 | 현재 페이지에서 시험한 항목의 상태 | 모든 문제의 해결과 색인 생성 |
| 색인에 저장된 검사 정보 | 구글이 최근 색인한 버전의 상태 | 현재 서비스 중인 페이지의 상태 |
| 리치 결과 테스트 자료 | 시험한 코드의 검사 결과와 미리보기 | 실제 검색 표시와 AI 답변 인용 |
구글은 리치 결과 테스트 결과를 공유할 수 있으며, 결과 열람에 권한이 필요하지 않다고 안내합니다. 공유 자료를 전달하기 전에 운영자는 열람 대상과 포함된 내용을 정합니다. 결과 화면만으로 작업 내용을 알기 어렵다면 개발자에게 변경 내역과 연결한 설명을 함께 받습니다.
완료 판정을 남기는 기록 방식
완료 기록은 요청한 조건과 제출된 증거가 연결되는 형태로 남깁니다. 운영자는 각 작업에 대해 승인한 변경, 실제 적용 내용, 판정에 사용한 자료를 같은 항목에 기재합니다. 개발자의 설명과 검사 결과가 어긋나면 어느 자료가 어떤 상태를 뜻하는지 먼저 질문합니다.
검사 시점이 수정 전인지 수정 후인지 불명확한 자료는 완료 근거로 채택하지 않습니다. 개발자는 적용 시점과 검사 시점을 함께 제시하고, 수정 후 다시 실행하지 않은 검사가 있으면 그 사유를 설명합니다. 운영자는 검사하지 않은 항목을 정상으로 간주하지 않고 미확인 상태로 기록합니다.
공통 설정을 변경한 작업에서는 보고서에 나온 페이지와 실제 영향을 받는 페이지가 다를 수 있습니다. 개발자에게 공통 설정의 적용 범위를 설명받고, 요청한 대상이 제출 자료에 포함되어 있는지 대조합니다. 일부 자료로 전체 적용을 주장한다면 그 판단을 뒷받침하는 설명을 추가로 요구합니다.
기술 완료와 검색 결과의 별도 기록
기술 완료 여부는 합의한 작업 조건으로 판정하고, 검색 반영이나 AI 인용은 별도의 관측 기록으로 관리합니다. 구글은 주소가 등록되어 있다는 상태만으로 실제 검색결과 표시를 보장할 수 없다고 설명합니다. 완료 보고서에 검색 표시를 기재한다면 기술 검사의 결과와 섞지 않고 관측한 사실로 표시합니다.
개발자가 제출한 자료에 남은 제한사항이 있다면 운영자는 완료된 항목과 미완료 항목을 따로 기록합니다. 요청서에 포함되지 않았던 새 문제가 발견된 경우에는 기존 작업의 불이행인지 추가 협의가 필요한 문제인지 가립니다. 이를 정하지 않은 채 전체 작업을 성공 또는 실패로 처리하지 않습니다.
AI 인용 자료가 없다면 보고서에는 인용 여부를 판단하지 않았다고 기재합니다. 기술 검사를 통과했다는 문장에서 인용 가능성이 높아졌다는 결론을 덧붙이지 않습니다. 운영자는 개발자의 제출 의무가 끝난 부분과 이후 관측할 결과를 각각 담당자에게 전달합니다.
승인 뒤 달라진 작업의 처리 기준
개발 중 발견한 사정으로 구현 방식이 달라질 때는 운영자에게 다시 승인을 받을 조건을 정합니다. 공개 범위가 넓어지거나 유지하기로 한 기능이 달라지는 변경은 적용 전에 이유와 영향을 설명하도록 요청합니다. 내부 구현만 달라지고 합의한 상태와 보존 조건이 유지된다면 완료 보고에 차이를 남기는 방식으로 협의할 수 있습니다.
운영자는 변경 요청을 받을 사람과 승인 기록을 남길 위치를 지정합니다. 여러 담당자가 서로 다른 답을 전달하면 개발자에게 마지막으로 승인한 내용을 정리해 회신합니다. 작업 중 대화에서 나온 의견과 최종 승인 내용을 혼동하지 않도록 변경 이유, 승인 내용, 적용 여부를 연결해 기록합니다.
자주 묻는 질문
개발자에게 요청할 때 화면 캡처만 전달해도 됩니까?
화면 캡처는 현상을 전달하는 보조 자료로 사용할 수 있습니다. 캡처만으로는 발생 조건을 알기 어려우므로 접근한 페이지, 당시 로그인 상태, 수행한 동작을 함께 기재합니다. 재현되지 않는 문제라면 발생할 때마다 같은 형식으로 정보를 남겨 전달합니다.
요청서에서 개발자가 사용할 도구까지 지정해야 합니까?
운영자가 특정 도구의 결과를 받아야 할 사정이 있을 때는 그 이유를 명시합니다. 그렇지 않으면 입증할 상태를 정하고 개발자에게 적절한 검사 방법을 제시하도록 요청할 수 있습니다. 도구 선택으로 자료를 읽는 방식이나 접근 권한이 달라지는지도 협의합니다.
완료 보고를 받는 담당자가 퇴사하면 어떻게 인계합니까?
후임 담당자에게 최종 승인 요청서와 완료 판정 기록을 함께 전달합니다. 진행 중인 항목은 개발자에게 다음 회신을 보낼 사람을 알리고, 미결 질문을 인계 목록에 포함합니다. 개인 대화에만 남은 승인 내용은 회사가 관리하는 기록으로 정리합니다.
구두로 승인한 작업도 요청서에 남겨야 합니까?
구두 승인 뒤에는 승인한 내용을 문서로 정리해 개발자에게 전달하는 편이 좋습니다. 전달할 때 새 요구를 섞지 않고 합의한 내용이 정확한지 답변을 받습니다. 서로 기억하는 내용이 다르면 적용을 진행하기 전에 합의 문장을 확정합니다.
다른 회사의 요청서 양식을 그대로 사용해도 됩니까?
양식의 항목은 참고할 수 있지만 대상과 완료 조건은 운영 중인 사이트에 맞게 작성합니다. 출처를 알 수 없는 기술 지시가 포함되어 있다면 개발자에게 적용 이유를 설명받습니다. 해당 사이트에 필요하지 않은 항목은 의무 작업처럼 전달하지 않습니다.
