생성형 엔진 최적화 (GEO): AI로부터 인용되기 위해 개발자가 알아야 할 것

지난 1년 동안 제품을 출시했다면, 분석 도구에서 이상한 점을 발견했을 것입니다. 바로 chat.openai.com, perplexity.ai, 또는 gemini.google.com으로부터 유입되는 추천 트래픽 (referral traffic)입니다. 때로는 아주 적게, 때로는 놀라울 정도로 많이 들어오기도 합니다.

이것은 SEO 트래픽이 아닙니다. 이것은 GEO 트래픽입니다. 즉, AI 엔진이 생성된 답변에서 귀하의 콘텐츠를 인용함으로써 발생하는 방문입니다.

저는 echloe에서 마케팅 플로우를 구축하며 몇 달 동안 이 부분을 깊이 파고들었는데, 이 사고 모델 (mental model)은 SEO와는 진정으로 다릅니다. 기록해 둘 가치가 있습니다.

SEO vs GEO: 빠른 재구성

전통적인 SEO는 순위 (ranking) 문제입니다:

• 목표: 상위 10개의 블루 링크 (blue links) 내에 순위 진입
• 성공 단위: 순위 + 클릭률 (CTR)
• 최적화 대상: 쿼리 (query) → 페이지 (page)

GEO는 인용 (citation) 문제입니다:

• 목표: LLM이 답변을 합성할 때 인용하는 소스가 되는 것
• 성공 단위: 생성된 응답 내에서 (종종 링크와 함께) 언급되는 것
• 최적화 대상: 주제/엔티티 (topic/entity) → 모델의 학습 및 검색 파이프라인 (training and retrieval pipeline)

귀하는 경쟁사보다 높은 순위를 차지하려는 것이 아닙니다. LLM이 답변을 구성할 때 가져갈 수 있는 *가장 유용하고 가장 신뢰할 수 있는 텍스트 조각 (chunk)*이 되려고 노력하는 것입니다.

이 차이점은 콘텐츠를 작성하고 구조화하는 방식의 모든 것을 변화시킵니다.

AI 엔진이 실제로 소스를 선택하는 방식

공개된 알고리즘 문서는 없지만, ChatGPT Search, Perplexity, Gemini, Claude 전반에 걸친 패턴은 대략 다음과 같습니다:

1. 쿼리 이해 (Query understanding) — 사용자의 질문을 하위 주장 (sub-claims)으로 분해합니다.
2. 검색 (Retrieval) — 후보 문서들을 가져옵니다 (웹 검색, 벡터 DB, 내부 인덱스).
3. 재순위화 (Re-ranking) — 관련성 + 권위 (relevance + authority)를 기준으로 조각(chunks)들의 점수를 매깁니다.
4. 합성 (Synthesis) — 2~7개의 소스를 인용하며 답변을 생성합니다.

따라서 귀하의 콘텐츠는 세 가지 필터를 통과해야 합니다: 검색 가능해야 하고 (retrievable), 재순위화 가능해야 하며 (re-rankable), 인용 가능해야 (quotable) 합니다.

실제로 효과를 보는 전략들

1. 추출 가능한 조각 (extractable chunks) 단위로 작성하기

LLM(Large Language Models)은 하나의 질문에 완벽하게 답하는 독립적인 단락을 선호합니다. 서론의 미사여구로 채워진 12개 섹션의 리스트 형식 글(listicle)은? 쓸모없습니다. 각 H2 태그가 명확한 질문이고, 첫 2~3문장이 그에 대해 확정적인 답을 제공하는 페이지는? 금광과 같습니다.

나쁜 예:

"빠르게 변화하는 오늘날의 컨테이너 세계에서, 많은 개발자들이 도구 간의 차이점에 대해 궁금해합니다..."

좋은 예:

"Docker Compose는 단일 호스트에서 멀티 컨테이너 앱을 실행합니다. Kubernetes는 클러스터 전반에 걸쳐 컨테이너를 오케스트레이션(orchestration)합니다. 로컬 개발에는 Compose를 사용하고, 프로덕션 규모에는 Kubernetes를 사용하세요."

두 번째 버전은 인용하기 좋습니다(quotable). LLM이 이를 그대로 가져갈 수 있습니다.

2. 구조화된 데이터(structured data) 추가하기 — 네, 정말입니다

Schema.org 마크업이 제2의 전성기를 맞이하고 있습니다. Common Crawl로 학습된 모델들은 이를 흡수하며, 검색 시스템(retrieval systems)은 이를 메타데이터로 사용합니다.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
...

author, citation, 그리고 about 필드는 특히 유용합니다. 이 필드들은 엔진이 전문성과 주제 관련성(topical relevance)을 검증하는 데 도움을 줍니다.

3. 다양한 플랫폼에 존재하기

이것은 거대한 사고방식의 전환입니다. 여러분의 도메인만으로는 충분하지 않습니다.

LLM은 다음으로부터 정보를 합성합니다:

• Wikipedia (매우 높은 가중치)
• Reddit 및 Stack Overflow
• GitHub README 및 토론(discussions)
• YouTube 스크립트(transcripts)
• Substack/Medium/Dev.to (반가워요 👋)
• 산업별 특화 포럼

만약 여러분의 프로젝트가 yourdomain.com에만 존재한다면, 검색 표면(retrieval surface)의 절반에서는 보이지 않는 존재가 됩니다. 명확한 언어로 작성된 README, 몇 가지 사려 깊은 Reddit 답변, Stack Overflow에서의 존재감 — 이들이 복리로 작용합니다.

이것이 바로 우리가 echloe를 지금과 같은 방식으로 구축한 이유 중 하나입니다. 이 서비스는 AI 엔진 전반에서 여러분의 브랜드가 어디에서 인용되는지 추적하고, 플랫폼 간 발자국(cross-platform footprint)의 공백을 드러내 줍니다. 왜냐하면 "최고의 [여러분의 카테고리] 도구"를 찾기 위해 ChatGPT, Perplexity, Gemini를 일일이 수동으로 대조하는 작업은 금방 지치기 때문입니다.

4. 엔티티 권위(entity authority) 구축하기

LLMs는 키워드가 아닌 엔티티 (entities) 단위로 사고합니다. "Stripe"는 엔티티입니다. "결제 처리 API (payment processing API)"는 토픽 (topic)입니다. 모델은 해당 토픽에 관한 쿼리 (queries)를 자신이 그 토픽과 연관 짓고 있는 엔티티들로 매핑합니다.

모델이 인식하는 엔티티가 되려면 다음과 같이 해야 합니다:

• 정당한 자격 요건을 갖추었다면 Wikipedia 또는 Wikidata 항목을 생성하세요.
• 모든 곳에서 일관된 명칭을 사용하세요 (여러 사이트에서 "Acme", "Acme Inc.", "Acme.io"를 혼용하지 마세요).
• 동시 출현 (co-occurrence)을 구축하세요: 해당 분야의 잘 알려진 엔티티들과 함께 언급되도록 하세요.

간단한 확인 방법 — 어떤 LLM에서든 다음 프롬프트 (prompt)를 시도해 보세요:

[귀하의 카테고리]를 위한 상위 5개 도구를 나열해줘.
각 도구에 대해 한 문장으로 설명을 제공해줘.

만약 목록에 귀하가 없다면, 모델이 아직 귀하에 대한 강력한 엔티티 연관성 (entity association)을 가지고 있지 않다는 뜻입니다. 그것이 바로 메워야 할 격차입니다.

5. 에러를 모니터링하듯 인용 (citations)을 모니터링하세요

관측 가능성 (observability) 없이 제품을 출시하지는 않을 것입니다. 여기서도 마찬가지입니다. 간단한 모니터링 루프 (monitoring loop)는 다음과 같습니다:

import openai
...