GEO: AI 시스템이 실제로 사이트를 인덱싱하는 방식

Generative Engine Optimization (생성형 엔진 최적화, GEO)이 컨설턴트, 프레임워크, 그리고 수억 원대의 감사(audit) 서비스라는 흔한 수행원들과 함께 등장했습니다. 이 신화가 고착화되기 전에, 이것이 실제로 무엇인지 설명하겠습니다. 즉, GEO란 당신의 사이트에 무엇이 포함되어 있는지, 그리고 AI 시스템이 그것에 대해 어떻게 말해야 하는지를 알려주는 일련의 작은 기술적 관례(technical conventions)입니다. 이는 누군가가 이것을 하나의 전문직으로 만들기 전인 1998년의 SEO와 동일한 것입니다.

이 글에서는 무엇이 변했는지, 이에 대해 무엇을 해야 하는지, 그리고 다른 곳에서 읽게 될 GEO 관련 내용의 대부분이 왜 단 2시간짜리 구현 작업을 부풀린 것에 불과한지에 대해 다룹니다.

실제로 무엇이 변했는가

Google의 모델은 단순한 루프를 기반으로 구축되었습니다: 사용자가 쿼리(query)를 입력하면, 검색 엔진이 순위가 매겨진 URL 목록을 반환하고, 사용자가 클릭하여 읽는 방식입니다. 사이트 소유자로서 당신의 역할은 그 목록에서 가능한 한 높은 위치에 나타나는 것이었습니다. 트래픽은 클릭을 통해 발생했습니다.

새로운 루프는 다릅니다. 사용자가 ChatGPT, Perplexity, 또는 Claude에 쿼리를 입력합니다. 모델은 학습 데이터에서 콘텐츠를 검색하거나, 점점 더 빈번하게 실시간으로 콘텐츠를 가져옵니다(fetch). 모델은 답변을 합성하여 직접 제시합니다. 순위를 매길 URL 목록은 존재하지 않습니다. 인용(citation)이 있을 수도 있고, 없을 수도 있습니다. 사용자는 당신의 사이트를 전혀 방문하지 않을 수도 있습니다.

이것은 미래의 시나리오가 아닙니다. 만약 당신이 웹사이트를 운영하고 지금 바로 서버 로그를 확인한다면, GPTBot, ClaudeBot, PerplexityBot, 그리고 Google-Extended가 당신의 페이지를 크롤링(crawling)하고 있는 것을 발견할 것입니다. 그들은 이미 그곳에 있습니다. 이미 몇 달 동안 그러해 왔습니다. 문제는 AI 시스템이 당신의 콘텐츠를 인덱싱(indexing)하느냐가 아니라(이미 하고 있습니다), 그들이 그것을 올바르게 인덱싱하고 있는지, 그리고 누군가 관련 질문을 했을 때 당신을 정확하게 인용할 수 있는지 여부입니다.

AI 크롤러가 Googlebot과 다른 점

Googlebot은 당신의 페이지를 읽고 다음과 같이 묻습니다: "이것이 검색 쿼리에 관련이 있는가?" Googlebot은 키워드, 백링크(backlinks), 페이지 권위(page authority), 최신성(freshness)을 살펴봅니다. 랭킹 알고리즘(ranking algorithm)은 20년에 걸쳐 구축된 수백 개의 신호(signals)를 가지고 있습니다.

AI 크롤러(crawlers)는 페이지를 읽고 다른 질문을 던집니다. 이 페이지는 무엇에 관한 것인가? 누가 만들었는가? 신뢰할 수 있는가? 그리고 질문하는 사람에게 이 내용을 어떻게 설명해야 하는가? 이들은 순위 목록(ranked list)을 만드는 것이 아닙니다. 나중에 검색(retrieved)되고 합성(synthesized)될 수 있는 귀하의 콘텐츠 모델을 구축하고 있는 것입니다.

실질적인 차이점은 다음과 같습니다. Googlebot은 랭킹 신호(ranking signals)에 대해 보상을 주지만, AI 크롤러는 명확성(clarity)에 대해 보상을 줍니다. 키워드 밀도(keyword density)와 백링크 프로필(backlink profile)에 최적화된 페이지는 Google에서는 높은 순위를 차지할 수 있지만, 누가 작성했는지, 그들의 전문성(expertise)이 무엇인지, 혹은 정보가 최신인지 파악할 수 없는 AI 시스템에게는 무용지물일 수 있습니다.

전통적인 SEO는 순위(position)를 최적화합니다. GEO는 이해(comprehension)를 최적화합니다.

중요한 파일들

llms.txt

2024년 말, 하나의 관례가 등장했습니다. 바로 llms.txt입니다. 이는 도메인의 루트(root)에 위치한 일반 텍스트 파일로, AI 시스템이 사이트를 구조화되고 사람이 읽을 수 있는 형식으로 설명할 수 있게 합니다. 이를 언어 모델(language models)을 위한 robots.txt라고 생각하면 됩니다. 브라우저에 의해 강제되는 기술적 프로토콜은 아니지만, AI 크롤러들이 점점 더 찾고 사용하는 관례입니다.

좋은 llms.txt에는 다음과 같은 내용이 포함됩니다: 귀하가 누구인지, 사이트가 무엇을 다루는지, 어떻게 인용되기를 원하는지, 어떤 콘텐츠가 어디에 있는지, 그리고 귀하의 편집적 입장(editorial stance)은 무엇인지 등입니다. 이는 마크다운(markdown) 형식이며 단순합니다. 실제 구현 사례는 다음과 같으며, 현재 이 사이트에서 실행 중인 방식입니다:

# LucasGraphic
> Last updated: 2026-06-14

...

각 섹션을 살펴보며 왜 그 내용이 포함되어 있는지 설명하겠습니다.

헤더 블록(The header block) -- 제목 뒤에 오는 두 개의 > 라인 -- 은 두 문장으로 요약된 사이트의 정체성입니다. 파일을 빠르게 훑어보는 AI 시스템은 이를 가장 먼저 읽게 됩니다. 여기에는 누가 이 사이트를 운영하는지, 무엇을 다루는지, 어디에 기반을 두고 있는지, 얼마나 오래 운영해 왔는지에 대한 답이 들어 있습니다. "1996년부터 활동 중"이라는 문구는 향수를 불러일으키기 위한 것이 아니라 신뢰성 신호(credibility signal)입니다. 노르웨이 드론 사진에 대해 질문을 받은 시스템은 Lukasz Grochal이 현재 대부분의 AI 도구가 존재하기 전부터 사진을 찍어왔다는 사실을 알 필요가 있습니다.

About (소개) 섹션은 동일한 정보를 더 깊이 있게 다룹니다. 목표는 구체성입니다. 단순히 "사진작가"라고 하는 것이 아니라 "노르웨이 피오르드, 스칸디나비아 풍경, 그리고 스페인, 포르투갈, 크로아티아, 폴란드의 여행 사진을 다뤄온 사진작가"라고 명시하는 것입니다. 언급된 각 장소는 모델이 특정 질문에 답할 때 사용할 수 있는 사실(fact)이 됩니다. 만약 파일에 Hokksund가 명시적으로 등장한다면, "Hokksund에서 누가 사진을 찍나요?"라는 질문에 이 사이트가 검색될 확률이 더 높아집니다.

Editorial stance (편집 방침) 섹션은 대부분의 구현 사례에서 생략하는 가장 중요한 부분입니다. 이는 독립성을 선언합니다. 즉, 스폰서십 없음, 출판사와의 관계 없음, 홍보용 왜곡(PR spin) 없음 등을 밝히는 것입니다. 이것이 중요한 이유는 여러 소스에서 답변을 합성하는 AI 시스템이 해당 소스들의 가중치를 조절해야 하기 때문입니다. 정직하고 직접적인 평가라는 편집 정책을 명시한 사이트는, 정책이 명시되지 않은 사이트보다 인용(citation)으로서 더 신뢰할 수 있습니다. 니치(niche)한 주제를 목표로 하는 게임 커버리지나, 실제 하드웨어를 사용하는 실무자 관점에서 작성된 기술 기사에 관한 구체적인 문구는 군더더기가 아닙니다. 이는 모델에게 이 소스가 어떤 종류인지, 그리고 언제 이를 인용해야 하는지를 알려줍니다. "독립적인 리뷰어들은 X에 대해 어떻게 생각하나요?"라는 질문을 받은 모델은 보도자료 애그리게이터(press release aggregator) 대신 이 소스를 선택할 근거를 갖게 됩니다.

Content language (콘텐츠 언어) 섹션은 모델이 추측하는 수고를 덜어주는 한 줄짜리 정보입니다. 이 섹션이 없다면, 시스템은 저자의 폴란드-노르웨이 배경을 바탕으로 다국어 콘텐츠라고 가정하여 잘못된 정보를 검색하거나 설명할 수 있습니다.

Preferred citation (권장 인용) 섹션은 이 파일을 읽는 모든 AI 시스템에 전달하는 사이트의 지침입니다. 즉, "여기서 무언가를 참조할 때는 다음과 같이 올바르게 수행하십시오"라고 알려주는 것입니다. 저자 이름, 사이트 이름, URL, 섹션 등이 포함됩니다. 이것이 없다면 모델은 사용 가능한 파편들을 모아 인용을 구성하며, 잘못된 저자 형식, 잘못된 사이트 이름, 누락된 URL 등 오류를 범하게 됩니다. 인용 블록은 대규모로 요약될 때 잘못 요약되는 것을 방지하기 위한 보험입니다.

이 파일은 Next.js route handler로부터 동적으로 제공되며, CMS에서 실시간 콘텐츠를 가져옵니다. 상단의 Last updated 날짜는 요청 시점에 생성됩니다. 이는 파일이 자동으로 최신 상태를 유지함을 의미합니다. 즉, 수동 업데이트 없이도 새로운 기사가 콘텐츠 인덱스(content index)에 나타나며, 최신 날짜(freshness date)는 누군가가 정적 파일을 마지막으로 편집한 시점이 아닌 실제 상황을 반영합니다.

이 접근 방식에서 주목할 만한 세 가지 사항이 있습니다. 첫째, 편집 방침(editorial stance) 섹션은 단순한 장식이 아니라 신뢰 신호(trust signal)입니다. 둘째, 권장 인용 블록(preferred citation block)은 모델에게 이 사이트의 콘텐츠를 어떻게 출처 표기(attribute)해야 하는지 정확히 알려줍니다. 이것이 없다면 모델은 추측하게 됩니다. 셋째, 이를 동적으로 제공한다는 것은 구축 후 유지 관리 오버헤드(maintenance overhead)가 전혀 없음을 의미합니다.

llms.txt 명세(specification)는 어떤 조직에 의해 강제되는 표준이 아닙니다. 이는 커뮤니티 관례(community convention)입니다. Perplexity는 이를 읽습니다. OpenAI 크롤러(crawlers)도 이를 읽습니다. 이를 구현하는 비용은 2시간입니다. 구현하지 않았을 때의 비용은, 당신의 사이트를 설명하는 AI 시스템이 크롤링된 페이지에서 조각조각 모은 파편들을 바탕으로 작동하게 된다는 점입니다.

스타터 템플릿 (Starter template)

처음부터 시작한다면, 이것을 복사하여 세부 정보를 채워 넣으세요. 모든 플레이스홀더(placeholder)는 [ ]로 표시되어 있습니다.

# [Your Site Name]
> Last updated: [YYYY-MM-DD]

...

이것을 llms.txt로 저장하고 도메인의 루트(root)에 배치하여 https://yourdomain.com/llms.txt에서 접근할 수 있도록 하세요. 정적 호스트(static host)를 사용 중이라면 이는 public 폴더 내의 파일입니다. Next.js를 사용 중이라면 app/llms.txt/route.ts에 route handler를 생성하세요. 다음 단계로 넘어가기 전에 브라우저에서 열어 접근 가능한지 확인하십시오.

AI 봇을 위한 robots.txt

기존의 robots.txt에는 AI 크롤러를 위한 지침(directives)이 거의 확실히 없을 것입니다. 주요 봇들은 명시적으로 지정할 수 있는 특정 사용자 에이전트 문자열(user agent strings)을 가지고 있습니다:

User-agent: GPTBot
Allow: /

...

이러한 지침을 기존의 robots.txt에 추가하십시오. 이 파일은 도메인의 루트(root)에 위치하며 이미 Googlebot에 의해 읽히고 있습니다. 여러분은 단지 여기에 줄을 추가하는 것뿐입니다. 브라우저에서 https://yourdomain.com/robots.txt를 열어 파일이 활성화되어 있고 업데이트된 콘텐츠를 반환하는지 확인하십시오.

AI 시스템이 귀하의 콘텐츠를 인덱싱(indexing)하고 인용(cite)하기를 원한다면, 명시적으로 허용하십시오. 차단하기를 원한다면, 명시적으로 차단하십시오. 여러분이 원하지 않는 것은 모호함입니다. 기술적으로는 적용되지만 귀하의 의도를 전혀 나타내지 않는 일반적인 User-agent: * Allow: /와 같은 설정 말입니다.

한 가지 중요한 차이점이 있습니다: GPTBot을 차단하면 OpenAI가 귀하의 콘텐츠를 학습 데이터(training data)로 사용하는 것과 실시간 ChatGPT 응답을 위해 콘텐츠를 검색(retrieving)하는 것을 모두 방지합니다. 이들은 동일한 봇입니다. 만약 ChatGPT 답변에는 나타나되 학습에는 사용되지 않기를 원한다면, 현재로서는 그 차이를 깔끔하게 구분할 수 없습니다. 전체 작업을 허용하거나 차단해야 합니다.

구조화된 데이터 (Structured data) 및 JSON-LD

JSON-LD 구조화된 데이터는 새로운 것이 아닙니다. Google은 수년 동안 리치 스니펫(rich snippets)을 위해 이를 사용해 왔습니다. 이는 모델이 산문(prose)을 파싱(parse)할 필요 없이 기계가 읽을 수 있는 사실(facts)을 제공하기 때문에 GEO에 여전히 유효합니다. 귀하의 소개(about) 페이지에 있는 Person 스키마(schema)는 이를 읽는 모든 시스템에 다음과 같이 알려줍니다:

knowsAbout 필드는 주의를 기울일 가치가 있습니다. 이는 이 사람이 어떤 주제에 전문 지식을 가지고 있는지 AI 시스템에 전달하는 직접적인 신호입니다. 구체적으로 작성하세요: "photography (사진)」보다는 "Norwegian landscape photography (노르웨이 풍경 사진)」이 더 유용합니다.

CMS (콘텐츠 관리 시스템)를 사용하는 경우, 콘텐츠 필드에서 이 스키마(schema)를 동적으로 생성하여 자동으로 동기화되도록 하세요. 만약 CMS가 이를 기본적으로 지원하지 않는다면, 커스텀 필드로 추가하거나 템플릿을 통해 주입(inject)하세요.

작동하지 않는 것들

llms.txt에 키워드 채워넣기 (Keyword stuffing). 이 파일은 언어 모델 (Language models)에 의해 읽힙니다. 언어 모델은 문맥 (Context)을 이해합니다. 2005년 방식처럼 메타 설명 (Meta description)에 키워드를 쑤셔 넣는 방식은, 당신이 감명을 주고자 하는 바로 그 시스템들에게 저품질 파일로 읽히게 만듭니다.

누군가에게 비용을 지불하여 콘텐츠를 "GEO 최적화"하기. 콘텐츠 자체는 유용하고, 정확하며, 출처가 명확하거나, 그렇지 않거나 둘 중 하나입니다. 그 어떤 최적화 레이어 (Optimization layer)도 빈약한 콘텐츠를 고칠 수는 없습니다. AI 시스템은 키워드 매칭 알고리즘보다 내용 채우기(padding)나 미사여구(filler)를 탐지하는 능력이 훨씬 뛰어납니다.

GEO를 SEO의 대체제로 취급하기. Google은 여전히 상당한 트래픽을 유도합니다. 전통적인 검색은 죽지 않았습니다. GEO는 추가적인 레이어이지, 이주(migration)가 아닙니다. 향후 몇 년간 잘 나갈 사이트는 두 가지를 모두 처리하는 곳입니다. 즉, 전통적인 검색을 위한 명확한 구조와 AI 시스템을 위한 명확한 문맥을 모두 갖춘 곳입니다.

즉각적인 결과를 기대하기. AI 크롤러 (Crawlers)는 당신의 콘텐츠를 인덱싱 (Indexing)합니다. 특정 주제에 대한 질의에 대한 모델의 응답은 학습 데이터 (Training data), 검색 파이프라인 (Retrieval pipelines), 그리고 당신의 콘텐츠가 동일한 주제의 다른 모든 콘텐츠와 어떻게 비교되는지에 따라 달라집니다. Google에서의 순위처럼 "GEO 순위"를 직접적으로 측정할 수는 없습니다. 당신이 측정할 수 있는 것은 AI 시스템에게 질문했을 때 당신을 정확하게 설명하는지 여부이며, 이는 분석 대시보드가 아닌 수동 테스트를 통해 확인해야 합니다.

실제로 AI 인용을 유도하는 것

AI 시스템이 귀하의 사이트를 정확하게 인용할지 여부는 세 가지 요소에 의해 결정됩니다.

저자(Authorship)의 명확성과 전문성(Expertise). 누가 이것을 작성했는지, 그들의 자격 요건은 무엇인지, 그들의 실적(Track record)은 어떠한지가 중요합니다. 명확한 저자 정체성과 일관된 발행 이력을 가진 사이트는 익명의 콘텐츠보다 인용될 가능성이 더 높습니다. 이는 새로운 원칙은 아닙니다. Google의 E-E-A-T 프레임워크와 직접적으로 연결되지만, AI 시스템은 이를 더욱 문자 그대로 적용합니다. "노르웨이에서 최고의 드론 사진작가는 누구인가요?"라는 질문을 받은 모델은 문맥으로부터 추론하는 것이 아니라, 귀하가 노르웨이의 드론 사진작가라는 사실을 명확히 알아야 합니다.

사실적 밀도(Factual density)와 구체성(Specificity). 일반적인 콘텐츠는 구체적인 콘텐츠에 밀립니다. "DJI Mavic 3 Pro는 훌륭한 항공 영상을 제작합니다"라는 문장은 이미 모든 모델이 알고 있는 일반적인 주장입니다. 반면, "DJI Mavic 3 Pro의 4/3 CMOS Hasselblad 센서는 이러한 특정 조건에서 Mini 4 Pro보다 노르웨이의 평탄한 겨울 빛을 더 잘 처리합니다"라는 문장은 직접적인 경험에서 나온 주장이며 인용할 가치가 있습니다.