같은 파일을 두고 갈린 구글의 상반된 입장

생성형 AI가 검색의 일부를 대체하면서 GEO(Generative Engine Optimization)라는 말이 빠르게 퍼졌어요. 

그 흐름에서 자주 언급되는 파일이 llms.txt입니다. 사이트 루트에 두고 사이트의 목적과 주요 페이지, 핵심 콘텐츠를 마크다운으로 정리해 LLM이 이해하기 쉽게 만들자는 아이디어예요.

그런데 구글 안에서 이 파일을 다루는 방식이 갈렸어요. 구글 서치 센트럴의 생성형 AI 최적화 가이드는 검색과 생성형 AI 검색 기능에 노출되기 위해 llms.txt 같은 별도 파일이나 특별한 마크업을 만들 필요가 없다고 안내해요. 크롤러가 파일을 발견하고 색인할 수는 있지만 특별하게 처리하지는 않는다는 설명도 함께 붙어 있고요.

반면 크롬은 라이트하우스에 '에이전트형 브라우징(Agentic Browsing)'이라는 진단 카테고리를 추가하면서 llms.txt 검사를 넣었습니다. 파일이 없으면 에이전트가 사이트의 상위 구조와 주요 콘텐츠를 이해하기 위해 더 많은 크롤링을 해야 할 수 있다는 이유예요. 다만 이 검사는 SEO Audit이 아닌 별도 영역이고, 파일이 없어 404가 발생해도 실패가 아니라 N/A로 처리됩니다.

Google Search와 Lighthouse의 llms.txt 비교

· 목적 : 검색은 검색·AI 검색 노출, 라이트하우스는 AI 에이전트의 브라우징 준비 상태 점검

· 적용 영역 : 검색은 SEO·AI Search, 라이트하우스는 Agentic Browsing

· llms.txt 필요성 : 검색은 불필요, 라이트하우스는 권장 가능한 선택 사항

· 검색 순위 영향 : 양쪽 모두 없음

· 파일 부재 시 : 검색은 영향 없음, 라이트하우스는 N/A 처리

· 주요 대상 : 검색은 검색엔진과 사용자, 라이트하우스는 AI 에이전트와 개발자

검색과 에이전틱 웹

기존 검색 환경은 콘텐츠 발행에서 크롤러, 색인, 검색 노출, 사용자로 이어지는 흐름이었어요. 여기서는 콘텐츠 품질과 크롤링 가능성, 내부 링크, 구조화 데이터 같은 요소가 중요했죠.

에이전틱 웹에서는 흐름이 하나 더 붙습니다. AI 에이전트가 사이트를 방문하고, 구조를 파악하고, 인터페이스를 이해하고, 실제 행동을 수행하는 단계예요. 에이전트가 사용자 대신 객실을 조회하거나 상품을 비교하고 폼을 채워 예약까지 진행하는 상황을 떠올리면 됩니다. 

이 환경에서는 검색되는 것만으로 충분하지 않아요. 크롬이 WebMCP나 접근성 트리, 레이아웃 안정성을 같은 카테고리에서 함께 평가하는 이유입니다.

마케터가 가져갈 시사점 세 가지

1. 사용 목적 정확히 구분하기 : "구글이 llms.txt를 SEO 요소로 인정했다"는 표현은 아직 사실이 아니에요. 다만, AI 와 관련해서는 새로운 규칙으로 편입 되었기 때문에, AEO, GEO 마케팅을 위해서는 고려하는 편이 좋아요. 

2. 목적으로 우선순위 나누기 : 검색 순위가 목적이면 우선순위가 낮고, AI 답변 노출이 목적이면 사이트 구조와 콘텐츠라는 기본기가 먼저입니다. 에이전트 대비라면 난도가 낮은 실험으로 접근할 수 있어요.

3. 파일보다 지식 기반 : AI가 특정 기업을 추천하려면 서비스 범위, 비용 구조, 고객 사례, 비교 기준, FAQ처럼 판단에 필요한 근거가 사이트 안에 있어야 해요. 스키마 마크업도 마크다운도 WebMCP도 지식을 전달하는 레이어일 뿐, 지식 자체를 만들지는 못합니다.

SEO에서 robots.txt와 유사한 전처를 밟는게 아닌가 하는 이야기도 들려 오는데요. 실제, robot.txt는 1994년 제안 된 뒤 2022년 RFC 9309로 표준화되기까지 28년이 걸렸어요. 새로운 관행은 공식 인정보다 훨씬 먼저 등장하고, 오랜 실사용을 거친 뒤에야 표준이 됩니다. 

llms.txt가 그 길을 갈지, 다른 방식에 밀릴지는 아직 알 수 없어요. 지금 확실한 건 웹을 이용하는 주체에 AI 에이전트라는 세 번째 사용자가 더해지고 있다는 사실입니다.