AI 검색 최적화 발주 전, 공급업체가 입증해야 할 것

AI 검색 최적화에 예산을 투입하기 전에 공급업체가 어떤 시스템에 영향을 주려는지, 무엇을 변경할지, 추가 지출을 정당화할 근거가 무엇인지 밝히도록 하세요. 파일을 납품하거나 감사 점수를 높이면 작업이 완료되었다는 점은 확인할 수 있습니다. 검색 노출이 좋아졌는지, 유용한 방문이 늘었는지, 적격 문의가 생겼는지를 보여 주려면 별도의 근거가 필요합니다.

제안에 llms.txt, AI 전용 마크업, 또는 GEO(생성형 엔진 최적화)라고 설명하는 정기 서비스가 포함되어 있다면 이 구분이 중요합니다. 제안된 변경마다 평가할 수 있는 목적이 있어야 합니다.

대상 시스템과 기대 결과부터 확인하세요

Google Search와 공개 개발자 문서를 참고하는 에이전트는 서로 다른 대상입니다. 한쪽을 위해 한 변경은 해당 용도에 맞는 근거로 평가해야 합니다.

2026년 7월 10일에 업데이트된 Google의 생성형 AI 최적화 가이드는 llms.txt가 Google Search의 노출이나 순위에 영향을 주지 않는다고 설명합니다. 이 가이드는 Google Search의 생성형 기능을 다룹니다. Google은 색인 대상 자격과 실제 색인 생성 또는 게재 보장도 구분합니다. 공급업체가 llms.txt를 Google 순위 요건이라고 제안한다면 해당 주장을 바로잡고, 제안의 다른 작업에는 어떤 근거 있는 목적이 있는지 설명하도록 하세요.

이 파일에는 별도의 용도가 있을 수 있습니다. Jeremy Howard의 llms.txt 제안은 에이전트용 안내와 연결된 문서를 설명합니다. 현재 v2 제안은 2026년 8월 10일에 수정되었습니다. 에이전트 문서 실험의 출발점이 될 수는 있지만, 서비스 제공업체가 따라야 할 의무 정책을 정하거나 검색 성과 향상을 입증하지는 않습니다.

감사 도구가 실제로 확인하는 내용을 파악하세요

도구의 기준을 알면 점수를 유용하게 해석할 수 있습니다. 2026년 5월 5일에 업데이트된 Chrome Lighthouse의 llms.txt 감사는 에이전트 브라우징을 대상으로 합니다. 서버 오류를 표시하며, 파일이 없어 404를 반환하면 파일이 선택 사항이므로 N/A로 판정합니다.

이 검사는 기존 파일의 기술 문제를 찾는 데 도움이 됩니다. 잠재 고객이 사용하는 에이전트가 파일을 읽거나 활용하는지, 파일을 추가하면 Google 순위가 오르는지는 보여 주지 않습니다. 이 결과를 추가 작업의 근거로 삼기 전에 대상 시스템과 고객 업무가 어떻게 연결되는지 공급업체에 설명을 요청하세요.

연구 결과는 그 한계 안에서 활용하세요

2026년 6월 15일에 발표된 Ahrefs 연구는 Ahrefs Web Analytics를 이용해 도메인 137,210개의 5월 요청을 조사했습니다. llms.txt 파일을 가져온 사례가 많지 않았다고 보고했습니다. 채택에 대한 가정을 검토할 때 참고할 수 있는 근거지만 몇 가지 한계가 있습니다. 고객 표본은 기술 및 SEO에 익숙한 쪽으로 치우쳐 있고, 요청은 응답, 채널, 사용자 에이전트를 기준으로 분류했습니다. 파일에 오류 내용이 있는지는 확인했지만 사양을 충족하는지 명시적으로 검증하지는 않았습니다.

관찰 기간은 8월의 v2 개정 이전입니다. 따라서 개정안을 평가하거나 10월 상황을 확정할 수 없습니다. 인용이나 전환의 인과적 개선도 측정하지 않았습니다. 요청 데이터는 제한된 범위의 관찰 결과이며, 귀사의 결과를 예측하지 않습니다.

간단한 제안 기록을 요청하세요

작업을 승인하기 전에 검토 시 참고할 수 있도록 다음 사항을 기록해 두세요.

• 대상과 과업: 어떤 검색 제품 또는 에이전트, 어떤 사용자층, 어떤 과업에 도움이 되어야 하나요?
• 산출물과 책임: 어떤 페이지, 파일, 설정을 변경하나요? 무엇을 인계하며 누가 정확한 상태를 유지하나요? 확인된 문제의 수정과 실험적 작업을 구분하세요.
• 근거: 현재의 서비스 제공업체 지침이나 재현 가능한 관찰 중 어떤 자료가 변경 사항과 대상을 연결하나요? 출처와 불확실성을 포함하세요.
• 기준선과 관찰: 현재 상태, 확인할 가치가 있는 변화, 사용 가능한 측정 방법, 검토 날짜를 기록하세요. 접근 권한이나 보고의 공백도 밝혀야 합니다.
• 검토 결정: 어떤 결과가 작업의 지속, 변경, 중단을 뒷받침하나요? 정기 비용이 있다면 관찰 결과에 따라 취할 다음 조치를 명시하세요.

측정 항목은 서로 구분하세요. 가져오기가 있었다고 해서 에이전트가 내용을 읽거나 사용했거나, 학습에 반영했거나, 귀사를 인용했거나, 사람의 방문을 유도했거나, 문의를 만들었다는 뜻은 아닙니다. 인용이 클릭으로 이어지지 않을 수 있고 방문이 문의로 이어지지 않을 수 있습니다. 보고 데이터를 구할 수 없다면 결과는 0이 아니라 알 수 없음입니다. 납품 후 개선이 관찰되더라도 그 변경이 원인이라고 판단하려면 신중해야 합니다.

완료 확인과 추가 예산 집행을 따로 판단하세요

두 가지 가상 제안을 살펴보겠습니다. 일반 기업이 llms.txt를 Google Search 순위 요건으로 제안받았습니다. 구매자는 Google 지침에 맞춰 제안을 수정하도록 요청한 뒤, 근거가 있는 수정이나 다른 작업을 각각 평가할 수 있습니다. 파일을 설치하면 해당 산출물의 완료는 확인할 수 있지만 순위 주장이 타당해지는 것은 아닙니다.

공개 개발자 문서를 보유한 기업이라면 다른 질문을 검토하게 됩니다. 지정된 에이전트가 특정 과업에 필요한 최신 지침을 찾아 정확히 활용할 수 있을까요? 문서를 변경하기 전과 후의 동작을 비교하는 소규모 선택적 실험을 할 수 있습니다. 범위를 넓히기 전에 과업, 유지관리 담당자, 검토 시점, 중단 조건을 합의하세요. 관찰 결과가 정해진 범위 안에서 유용한 작업을 뒷받침할 때만 계속하되, 원인에 관한 불확실성은 인정해야 합니다.

합의한 결함이 해결되면 수정 작업은 완료된 것입니다. 다음 실험이나 정기 계약을 뒷받침하는 근거가 있는지는 별도로 판단하세요. 고객층, 현재 사이트, 제안된 작업을 논의하고 싶다면 서비스 안내에서 시작할 수 있습니다.