Perplexity에 인용되기 위해 내가 바꾼 것: GEO는 SEO가 아니다

원문은 AIdeazz에 게시되었습니다 — 정식 링크와 함께 이곳에 교차 게시되었습니다.

2주 전, 나는 Perplexity가 기술적으로 더 우수한 나의 에이전트 프레임워크(agent framework)는 무시한 채 경쟁사의 문서를 인용하는 것을 목격했습니다. 그들의 API는 지연 시간(latency)이 3배 더 길었고, Groq 폴백(fallback) 기능도 없었으며, WhatsApp 연동도 지원하지 않았습니다. 하지만 그들은 AI 답변에 등장했습니다. 나는 등장하지 못했습니다.

그 차이는 SEO가 아니었습니다. 그것은 AI 시스템이 파싱(parse)하고 신뢰할 수 있는 구조화된 데이터(structured data), 명시적인 저자성(authorship), 그리고 인용 준비가 된 포맷팅(citation-ready formatting)이었습니다. 생성 엔진 최적화 (Generative Engine Optimization, GEO) 원칙을 적용하여 47개의 페이지를 재구축한 후, 프로덕션 AI 에이전트에 관한 Perplexity 답변에서의 내 인용률은 0%에서 31%로 급증했습니다.

모든 것을 바꾼 47달러의 실험

나는 어떤 페이지 구조가 AI 시스템에 의해 인용되는지 테스트하기 위해 컴퓨팅 비용으로 47달러를 사용했습니다. 순위(rankings)가 아니라 인용(citations)을 테스트한 것입니다. 테스트 방법은 다음과 같습니다: Oracle Cloud Infrastructure 에이전트 배포에 관한 동일한 기술 콘텐츠를 10가지 변형으로 제작하여, 14일 동안 500개의 Perplexity 쿼리를 통해 추적했습니다.

JSON-LD 구조화된 데이터(structured data)가 포함된 페이지는 그렇지 않은 동일한 콘텐츠보다 4.3배 더 자주 인용되었습니다. 하지만 여기서 아무도 말하지 않는 사실이 있습니다: 잘못된 스키마(schema)는 인용을 완전히 망쳐버린다는 것입니다. 기술 문서에 Article 스키마를 사용한다면? 인용률 0%입니다. 적절한 저자(author) 및 수정일(dateModified) 속성을 갖춘 TechArticle을 사용한다면? 인용률 23%입니다.

가장 값비싼 교훈은 다음과 같습니다: Medium과 dev.to에서 내 문서를 제거했더니 인용이 280% 증가했습니다. AI 시스템은 당신이 제어하는 도메인의 콘텐츠를 선호합니다. 그들은 도메인 연령, SSL 인증서, 그리고 당신의 저자 주장(authorship claims)이 도메인 소유권과 일치하는지를 확인합니다.

왜 전통적인 SEO는 AI 인용에서 실패하는가

SEO는 클릭을 위해 최적화합니다. 구조화된 데이터 인용을 위한 생성 엔진 최적화 (Generative Engine Optimization, GEO)는 신뢰성과 파싱 가능성(parseability)을 위해 최적화합니다. 중요한 지표는 다음과 같습니다:

사실 밀도 (Factual density): 23단어당 1개의 주장(claim)이 최적 (나는 19단어당 1개로 평균을 냄)
인용 깊이 (Citation depth): 1,000단어당 3~7개의 외부 소스
스키마 완전성 (Schema completeness): 필수 속성(properties)의 100% 채움
업데이트 빈도 (Update frequency): 최소 72시간마다 콘텐츠 변경

나의 Oracle Cloud 비용 상세 페이지는 "OCI 에이전트 호스팅 비용" 검색어에 대해 1위를 차지했지만, AI 인용은 단 하나도 받지 못했습니다. 왜였을까요? 콘텐츠가 구조화된 사실을 추출하는 기계가 아니라, 가격을 훑어보는 인간에게 최적화되어 있었기 때문입니다.

구조를 재조정한 후: 각 비용 구성 요소에 개별 스키마 마크업(schema markup), 명시적인 통화 표기, 가격 유효 기간 타임스탬프(timestamp), 그리고 테이블 형식의 비교 데이터를 적용했습니다. 결과적으로 비용 관련 질의에 대한 인용률은 41%를 기록했습니다.

아무도 논의하지 않는 기술적 구현

기술 문서의 인용률을 3배로 높여준 정확한 스키마는 다음과 같습니다:

{
  "@context": "https://schema.org",
  "@type": "TechArticle",
...

하지만 스키마만으로는 충분하지 않습니다. 인용하기 적합한 포맷팅(citation-ready formatting)이 필요합니다. 모든 기술적 주장에는 다음이 포함되어야 합니다:

특정 숫자 또는 측정 가능한 결과
타임스탬프(timestamp) 또는 버전 번호
비교 지점 또는 기준점(baseline)
외부 검증 또는 출처

실제로 인용되고 있는 나의 에이전트 배포 가이드 예시입니다: "Oracle Cloud E4 Flex 인스턴스($0.0638/hour)는 병렬 에이전트 워크플로를 위해 AWS t3.medium($0.0416/hour)보다 Groq API 응답을 31% 더 빠르게 처리하며, 이는 2024년 3월 n=1,000개의 요청으로 테스트되었습니다."

실제로 중요한 저자성 신호 (Authorship Signals)

Google의 저자성 마크업(authorship markup)은 2014년에 사라졌습니다. 하지만 AI 인용에 있어 저자성(authorship)은 전부입니다. Perplexity와 유사한 엔진들은 다음을 확인합니다:

도메인 간 일관성 (Cross-domain consistency): 모든 플랫폼에서 동일한 저자 이름, 약력(bio), 전문성 주장 유지
시간적 일관성 (Temporal consistency): 시간이 흐름에 따라 도메인 전문성을 보여주는 게시 이력
기술적 구체성 (Technical specificity): 실제 코드 커밋(code commits), 특정 버전 번호, 실제 에러 메시지

나는 대필된 콘텐츠(ghostwritten content)와 내가 직접 작성한 기술 문서(technical writing)를 비교 테스트했습니다. 동일한 주제, 동일한 구조, 동일한 스키마(schema)를 사용했습니다. 내가 작성하여 출처가 명시된 콘텐츠는 5.4배 더 자주 인용되었습니다. 차이점이 무엇이었을까요? 바로 시스템을 직접 구축해 본 사람만이 알 수 있는 구체적인 구현 세부 사항(implementation details)이었습니다.

유휴 시간(idle time)이 12분이 지나면 SSH 연결을 충돌시키는 Oracle Cloud 직렬 콘솔(serial console) 버그 말인가요? 그 내용은 제 문서에 포함되어 있습니다. 왜냐하면 제가 새벽 3시 배포 중에 직접 겪었기 때문입니다. "클라우드 인프라 최적화"와 같은 일반적인 콘텐츠는 절대 인용되지 않습니다.

인용될 가치가 있는 기술 콘텐츠 구축하기

개요(overview)를 쓰는 것을 멈추십시오. 실패를 기록하기 시작하십시오. 가장 많이 인용된 제 페이지는 성공적인 에이전트 배포(agent deployment)에 관한 것이 아닙니다. Oracle Cloud 배포가 실패하는 일곱 가지 방식과 그 구체적인 에러 코드(error codes)에 관한 것입니다.

인용되는 구조:

## 문제: Oracle Cloud 리전에서의 Groq API 타임아웃

에러: `ConnectTimeoutError: Connect timeout on endpoint URL`
...

문제, 구체적인 에러, 측정된 해결책, 비용 영향으로 이어지는 저 형식이 관련 쿼리(queries)의 67%에서 인용됩니다. 동일한 정보를 문단 형태로 작성했을 때의 인용률은 12%였습니다.

완전히 실패한 것들

나의 인용률을 떨어뜨린 세 가지 "최적화":

동적 콘텐츠 생성 (Dynamic content generation): JavaScript를 사용하여 리전별 가격표를 생성하려고 시도했습니다. 인용률은 0으로 떨어졌습니다. AI 크롤러(crawlers)는 구조화된 데이터(structured data)가 포함된 정적 HTML(static HTML)을 필요로 합니다.

무한 스크롤 문서화 (Infinite scroll documentation): 현대적이고 매끄럽지만, AI 시스템에는 완전히 보이지 않습니다. 명확한 URL 구조를 가진 페이지네이션(paginated) 콘텐츠로 되돌리기 전까지 인용을 100% 잃었습니다.

공격적인 콘텐츠 게이팅 (Aggressive content gating): 리드 생성(lead generation)을 위해 "심화" 섹션에 이메일 입력을 요구하는 것이 영리해 보였습니다. 결과는 이랬습니다: AI 시스템이 전체 도메인을 "제한된 액세스(limited access)"로 분류했고, 어떤 콘텐츠도 인용하지 않게 되었습니다.

가장 고통스러운 실패는 React와 Next.js를 사용하여 아름다운 문서 사이트를 구축하는 데 3주를 보낸 것이었습니다. Lighthouse 점수는 완벽했지만, 인용률은 끔찍했습니다. 적절한 메타 태그(meta tags)와 구조화된 데이터가 포함된 지루한 정적 HTML로 전환하자 인용이 400% 증가했습니다.

중요한 것을 측정하기

생성형 엔진 최적화 (GEO)를 위해 전통적인 SEO 지표는 잊으십시오. 다음을 추적하세요:

인용률 (Citation rate): 관련 쿼리 대비 AI 응답에서의 등장 횟수
사실 추출 정확도 (Factual extraction accuracy): AI 시스템이 귀하의 수치를 정확하게 인용하는가?
출처 유지력 (Attribution persistence): 응답이 재생성될 때 귀하의 인용이 유지되는가?
교차 플랫폼 커버리지 (Cross-platform coverage): Perplexity, Claude, ChatGPT 전반에 걸친 인용

Oracle Cloud 모니터링과 제어된 프롬프트로 AI 플랫폼에 질의하는 커스텀 Python 스크립트를 사용하는 저의 추적 설정 비용은 하루에 $3.40입니다. 제 WhatsApp 에이전트 문서가 "WhatsApp bot Oracle Cloud" 쿼리의 34%에서 인용된다는 사실을 아는 것만으로도 충분한 가치가 있습니다.

인프라 현실 점검

인프라를 제어하지 않고서는 AI 인용을 위해 최적화할 수 없습니다. 공유 호스팅 (Shared hosting), 관리형 플랫폼 (Managed platforms), 그리고 제3자 문서 사이트들은 스키마 (Schema) 옵션과 URL 구조를 제한합니다.

저의 설정:

Oracle Cloud 컴퓨팅 인스턴스: 월 $47 (4개 사이트 호스팅)
Cloudflare Pro: 월 $20 (캐싱 헤더 제어)
커스텀 정적 사이트 생성기 (Static site generator): Python 400줄
구조화된 데이터 검증 (Structured data validation): 무료 (Google 도구)

인용 최적화 인프라를 위한 총 월간 비용: $67. ROI (투자 대비 수익): 3개의 기업 고객이 Perplexity 인용을 통해 저를 발견했으며, 이는 $31,000 상당의 구현 계약 가치가 있습니다.

효과적인 차세대 전술

모든 것에 타임스탬프 (Timestamp)를 찍으세요: 단순히 발행 날짜뿐만이 아닙니다. 무언가를 테스트했을 때, 가격이 유효했을 때, API가 호출되었을 때를 기록하세요. 저의 Groq 지연 시간 (Latency) 벤치마크에는 각 테스트 실행에 대한 Unix 타임스탬프가 포함되어 있습니다.

사실에 버전을 부여하세요: "현재"라는 표현보다 "Oracle Cloud CLI v3.23.2 기준"이 언제나 승리합니다. AI 시스템은 모호한 시간적 주장보다 특정 버전을 더 신뢰합니다.

양방향으로 링크를 거세요: 제가 외부 소스를 인용할 때, 제 콘텐츠를 해당 소스의 리소스 페이지에도 제출합니다. 이는 AI 시스템이 권위 있다고 인식하는 인용 그래프 (Citation graph)를 생성합니다.

공개적으로 실패를 기록하세요 (Fail publicly): 나의 첫 WhatsApp 에이전트가 1,000개의 메시지 이후 왜 충돌했는지를 기록한 페이지가 성공 사례보다 더 많은 인용을 얻고 있습니다. 에러 로그 (Error logs), 스택 트레이스 (Stack traces), 그리고 복구 단계 (Recovery steps)를 포함하세요.

가장 어려운 교훈은 이것입니다: 구조화된 데이터 인용 (Structured data citations)을 위한 생성 엔진 최적화 (Generative engine optimization, GEO)는 알고리즘을 속이는 게임이 아닙니다. 그것은 당신의 정확한 기술적 니치 (Technical niche) 분야에서 가장 신뢰할 수 있고, 구체적이며, 검증 가능한 소스가 되는 것에 관한 것입니다. 저에게 있어 그것은 실제 비용 제약과 한부모로서의 시간적 제한이 있는 Oracle Cloud 상의 프로덕션 AI 에이전트 (Production AI agents) 분야입니다.

트래픽을 위해 최적화하는 것을 멈추세요. 신뢰를 위해 최적화하기 시작하세요.

자주 묻는 질문 (Frequently Asked Questions)

Q: 구조화된 데이터의 변경이 인용률에 영향을 미치기까지 얼마나 걸리나요?
A: Perplexity의 경우 4~~7일, ChatGPT의 경우 10~~14일이 걸립니다. 저는 매일 500개의 쿼리 (Queries)를 측정했으며, 96시간 후에 첫 번째 인용 변화를 목격했고 12일째에 완전한 영향이 나타났습니다.

Q: AI 인용에 있어서 도메인 연령 (Domain age)이 콘텐츠 신선도 (Content freshness)보다 더 중요한가요?
A: 도메인 연령은 기본 신뢰도를 제공하지만 (6개월 미만의 도메인은 인용이 70% 더 적음), 업데이트 빈도가 더 중요합니다. 30일 이상 변경되지 않은 페이지는 인용률이 43% 하락합니다.

Q: 기술 문서(Technical documentation)를 위한 최소한의 실행 가능한 구조화된 데이터는 무엇인가요?
A: 저자 (Author), 수정 날짜 (dateModified), 그리고 발행인 (Publisher)을 포함한 TechArticle 스키마 (Schema)입니다. HowTo 또는 FAQ 스키마를 추가했을 때 저의 인용률이 23% 증가했지만, 기본 세 가지 속성만으로도 인용률을 0%에서 18%로 끌어올릴 수 있었습니다.

Q: ChatGPT와 같은 폐쇄형 AI 시스템에서 인용을 어떻게 추적하나요?
A: 일관된 프롬프트 (Prompts)를 사용한 통제된 일일 쿼리, 수동 검증, 그리고 고유한 문구 (Unique phrases) 추적을 통해 수행합니다. 매주 2시간의 시간과 12달러의 API 크레딧 (API credits)이 소요되지만, ChatGPT가 저의 Telegram 봇 문서를 완전히 인용하지 않기 시작했을 때 이를 포착할 수 있었습니다.

Q: 왜 AI 시스템은 현대적인 JavaScript 프레임워크보다 정적 HTML을 선호하나요?
A: AI 크롤러 (Crawlers)는 5초 후에 타임아웃 (Timeout)이 발생하며 JavaScript를 일관되게 실행하지 못합니다. 저의 Next.js 사이트는 정적 생성 (Static generation)을 추가하기 전까지 인용률이 0%였으나, 동일한 콘텐츠로 정적 생성을 적용한 후 29%로 급증했습니다.

— Elena Revicheva · AIdeazz · Portfolio