함께 관리하되 대체하지 않는 운영
llms.txt와 사이트맵은 하나로 대체하지 않고, 검색엔진용 사이트맵을 유지하면서 필요한 경우에만 llms.txt를 별도로 관리합니다. 담당자는 페이지 변경 처리 과정에 두 파일의 확인 항목을 연결하되, 각 파일의 목적과 생성 경로를 따로 기록합니다. 함께 관리한다는 이유로 같은 도구에서 생성하거나 같은 내용을 담도록 요구할 필요는 없습니다.
구글은 사이트맵이 페이지와 파일의 관계를 검색엔진에 알리는 파일이라고 설명합니다. 또한 구글 검색은 생성형 AI 기능을 포함해 llms.txt를 사용하지 않으며, 다른 서비스나 시스템을 위해 해당 파일을 유지하는 것은 가능하다고 안내합니다. 운영자는 사이트맵의 검색엔진 안내 목적과 llms.txt를 별도로 운영하려는 목적을 각각 기재해야 합니다.
llms.txt의 필요성은 어떤 서비스나 내부 활용을 위해 관리하려는지 설명할 수 있는지로 판단합니다. 목적을 정하지 못한 상태라면 사이트맵 업무에 llms.txt 제작을 필수 단계로 추가하지 않습니다. 이미 llms.txt가 있다면 즉시 새로 만들기보다 기존 운영 목적과 유지 책임부터 정리합니다.
담당자와 생성 경로를 묶는 관리표
공통 관리표는 두 파일의 역할을 합치는 문서가 아니라, 수정 요청을 누가 처리할지 찾는 업무 자료로 사용합니다. 아래 표는 사이트맵의 생성 방식에 따라 관리 대상을 나눈 예시이며, 실제로 사용하지 않는 항목은 제외합니다. 담당자 이름과 생성 도구의 명칭은 회사의 실제 운영 정보로 채웁니다.
| 관리 대상 | 운영 목적 | 생성 경로 | 담당자 |
|---|---|---|---|
| 콘텐츠 관리 시스템의 사이트맵 | 검색엔진에 페이지와 파일 안내 | 현재 사용하는 시스템의 생성 기능 | 시스템 설정을 관리하는 담당자 |
| 별도로 생성하는 사이트맵 | 검색엔진에 사이트 정보 제공 | 사이트 소프트웨어 또는 수동 제작 과정 | 개발자 또는 파일 관리 담당자 |
| 별도로 운영하는 llms.txt | 도입 시 정한 서비스나 활용 목적 | 현재 사용하는 생성 도구 또는 편집 과정 | 내용 승인자와 공개 처리 담당자 |
생성 경로에는 파일을 편집하는 위치만 적지 말고, 편집 결과가 공개되는 과정도 함께 기재합니다. 내용 승인자와 공개 처리 담당자가 다르면 각자의 작업 범위를 명시합니다. 관리 책임자는 처리 요청을 접수하는 사람과 실제 파일을 변경하는 사람이 같은지 대조합니다.
기존 사이트맵 생성 경로의 판단
구글은 콘텐츠 관리 시스템이 검색엔진에 제공할 사이트맵을 이미 생성했을 수 있다고 설명합니다. 먼저 운영 담당자가 현재 생성 기능을 사용 중인지 확인하고, 개발자는 별도 프로그램이나 수동 작업이 개입하는지 조사합니다. 공개 파일을 내려받아 수정하기 전에 원본이 어디에서 만들어지는지부터 가려야 합니다.
자동 생성 결과를 직접 편집하면 다음 생성 과정에서 수정 내용이 유지되지 않을 수 있습니다. 개발자는 변경해야 할 대상이 생성 설정인지, 원본 데이터인지, 수동 파일인지 명시합니다. 생성 경로를 설명할 수 없다면 llms.txt와 연동하는 작업보다 기존 사이트맵의 관리 책임을 정하는 일을 먼저 진행합니다.
변경 업무에 연결하는 실행 순서
두 파일의 공동 관리는 기존 사이트맵 업무에 별도 파일의 처리 항목을 연결하는 순서로 진행합니다. 마케팅 담당자는 운영 목적과 변경 요청을 준비하고, 개발 담당자는 생성과 공개 과정을 설명합니다. 작업 책임자는 아래 순서의 결과를 하나의 변경 요청 기록에 모읍니다.
- 기존 사이트맵 생성 경로를 확인합니다. 사용 중인 시스템, 별도 생성 프로그램, 수동 관리 여부와 공개 처리 담당자를 기록합니다.
- llms.txt의 별도 운영 목적과 담당자를 지정합니다. 파일을 유지하려는 이유, 내용 승인자, 생성 도구와 공개 처리 방법을 준비합니다.
- 페이지 변경 작업에 두 파일의 처리 항목을 연결합니다. 요청자는 변경 내용을 전달하고 각 담당자는 처리 여부와 공개 결과를 기록합니다.
담당자가 준비할 자료는 현재 관리표, 페이지 변경 요청서, 생성 설정을 설명하는 자료와 공개 작업 기록입니다. 비밀번호나 접근 권한 자체를 공통 문서에 기재할 필요는 없습니다. 자료를 읽는 사람이 수정 요청의 전달 대상과 완료 보고 위치를 찾을 수 있도록 문서 이름과 관리 책임자를 명시합니다.
페이지 변경 작업별 처리 항목
변경 요청서에는 사이트맵과 llms.txt를 각각 처리하는 칸을 마련합니다. 아래 표는 작업 절차를 설계하기 위한 항목이며, 구글이 요구하는 공통 관리 형식은 아닙니다. llms.txt를 운영하지 않는 사이트는 해당 칸에 미운영 상태를 표시하고 사이트맵 작업만 진행합니다.
| 페이지 변경 작업 | 사이트맵 처리 항목 | llms.txt 처리 항목 | 반영 확인 기록 |
|---|---|---|---|
| 페이지 신규 공개 | 기존 생성 과정의 처리 대상 여부 판단 | 운영 목적에 따른 변경 필요 여부 판단 | 각 담당자의 처리 결과와 공개 상태 |
| 페이지 내용 수정 | 생성 원본이나 설정의 변경 필요 여부 판단 | 기존 안내 내용의 수정 필요 여부 판단 | 수정한 대상과 처리하지 않은 이유 |
| 페이지 이동 또는 삭제 | 기존 생성 과정의 후속 처리 수행 | 관련 안내의 후속 처리 수행 | 완료한 작업과 남은 작업 |
| 변경 작업 취소 | 이미 처리한 변경의 복원 필요 여부 판단 | 이미 공개한 수정의 복원 필요 여부 판단 | 취소 승인과 복원 결과 |
처리가 필요하지 않다는 판단도 작업 결과로 기재합니다. 빈칸으로 남기면 담당자가 판단을 끝낸 것인지 요청을 받지 못한 것인지 알기 어렵습니다. 요청자는 페이지 작업의 완료 여부와 파일 처리의 완료 여부를 따로 표시하고, 남은 작업에는 처리할 담당자를 명시합니다.
두 파일의 공개 시점이 다르면 하나의 완료 표시로 모두 처리됐다고 보고하지 않습니다. 작업 책임자는 먼저 공개한 파일과 아직 처리 중인 파일을 나누어 기록합니다. 다른 담당자에게 작업을 넘길 때에는 완료 항목과 미완료 항목을 함께 전달합니다.
공개 결과를 남기는 점검 기록
공개 후에는 편집 화면의 저장 상태만으로 변경 작업을 종료하지 않습니다. 파일 담당자는 공개된 결과에 승인한 변경이 반영됐는지 확인하고, 작업 책임자는 생성 과정에서 오류가 발생했는지 기록합니다. 주소 목록의 일치 여부를 판정하는 작업과 별개로, 요청한 수정이 실제 공개 과정까지 진행됐는지를 다루는 절차입니다.
기록에는 변경 요청의 이름, 처리한 파일, 사용한 생성 경로, 공개 결과와 처리자를 포함합니다. 작업 시점에 확보한 공개 결과와 오류 내용을 연결하면 후속 담당자가 같은 작업을 처음부터 추적하지 않아도 됩니다. 승인 문서만 있고 공개 결과가 없다면 승인 완료와 공개 완료를 별개의 상태로 남깁니다.
자동 생성 과정이 있는 경우 개발자는 다음 생성에서도 유지될 원본이나 설정을 변경했는지 기록합니다. 수동 파일을 사용하는 경우 파일 담당자는 승인한 편집본을 공개하는 과정까지 처리했는지 기재합니다. 공개 결과에 문제가 있으면 작업 책임자가 생성 단계와 공개 단계 중 어느 단계의 담당자에게 수정 요청을 전달할지 정합니다.
작업 완료와 검색 처리의 별도 판단
구글은 서치 콘솔의 사이트맵 보고서에서 사이트맵을 제출할 수 있고, 구글봇의 접근 시점과 잠재적인 처리 오류를 확인할 수 있다고 안내합니다. 사이트맵 담당자는 이 보고서에서 확보한 정보를 내부 공개 기록과 별도로 남깁니다. 파일을 공개했다는 보고와 구글이 접근했다는 정보는 서로 다른 작업 상태로 관리합니다.
구글은 사이트맵 제출이 참고 정보를 전달하는 수준이며, 다운로드나 크롤링에 사용되는 것을 보장하지 않는다고 설명합니다. 따라서 작업 책임자는 사이트맵 반영 완료를 검색 처리 완료로 기재하지 않습니다. 완료 보고에는 담당자가 직접 수행하고 확인한 작업만 담습니다.
llms.txt에도 구글 사이트맵의 제출·처리 상태를 적용하지 않습니다. 별도 활용 목적에 따라 추가 관측이 필요하다면 파일 공개 작업과 분리한 업무로 요청합니다. 공개 작업 보고서에 검색 노출이나 AI 답변 채택을 완료 조건으로 넣으면, 파일 담당자가 수행한 작업의 종료 여부를 판단하기 어려워집니다.
자주 묻는 질문
비공개 작업 환경에서도 두 파일을 수정해야 합니까?
회사에서 공개 전 시험 환경을 사용한다면 파일 변경도 해당 작업 범위에 포함할지 정합니다. 시험 환경의 결과를 공개 결과로 보고하지 않도록 기록에 환경 이름을 기재합니다. 공개 처리를 맡은 담당자는 시험 승인 이후 실제 공개 작업이 필요한지 따로 판단합니다.
긴급 수정 때 내용 승인자가 부재하면 어떻게 합니까?
운영 책임자는 긴급 작업을 승인할 대체 담당자와 승인 가능한 범위를 정합니다. 대체 담당자가 결정할 수 없는 내용은 임의로 확정하지 않고 미완료 항목으로 기록합니다. 긴급 처리가 끝난 뒤에는 원래 승인자에게 결정 내용과 남은 작업을 전달합니다.
관리표에 내부 서버 정보까지 공개해야 합니까?
공통 관리표는 내부 업무 문서로 사용할 수 있으며 외부 공개를 전제로 만들 필요는 없습니다. 외부 협업자에게 전달할 때는 맡긴 작업에 필요한 생성 경로와 연락 대상만 추려 전달합니다. 내부 서버의 상세 설정이나 인증 정보는 별도의 접근 관리 절차로 전달합니다.
사이트를 여러 개 운영하면 관리표를 합쳐도 됩니까?
통합 관리표를 사용하더라도 각 사이트의 관리 대상과 처리 책임을 식별할 수 있어야 합니다. 생성 도구가 같다는 이유만으로 서로 다른 사이트의 변경 요청을 하나의 완료 상태로 처리하지 않습니다. 운영 책임자는 사이트별 요청 기록을 찾을 수 있도록 관리표에 내부 식별명을 기재합니다.
이전 작업 기록은 새 관리표를 만들면 삭제해도 됩니까?
새 관리표를 만든 사실만으로 이전 기록을 삭제할 필요는 없습니다. 운영 책임자는 회사의 기록 보관 기준과 후속 조사에 필요한 자료를 판단해 보관 범위를 정합니다. 현재 업무에 사용하는 관리표와 과거 작업의 증빙 자료를 따로 표시하면 이전 기록이 새 수정 요청으로 오인되는 일을 줄일 수 있습니다.