Perplexity에서 AIdeazz가 인용되게 만든 방법: 회의적인 빌더들을 위한 GEO

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

Perplexity는 제가 이유를 알기도 전에 제 페이지를 세 번 인용했는데, 그중 처음 두 번은 잘못된 주장들이었습니다. 한 답변은 제가 포스트에서 실패(failure) 사례로 설명했던 멀티 에이전트 라우팅 패턴(multi-agent routing pattern)을 AIdeazz의 기능으로 돌렸습니다. 모델이 해결책(workaround) 문장만 가져오고, 그 주변의 "이것이 운영 환경에서 문제를 일으켰다"라는 맥락을 누락시킨 것입니다. 그때부터 저는 생성 엔진 최적화(Generative Engine Optimization, GEO)를 마케팅 업무로 취급하는 것을 멈추고, API 계약(API contract)에 부여하는 것과 동일한 엄격함을 가진 데이터 모델링(data-modeling) 문제로 다루기 시작했습니다.

만약 당신이 무언가를 출시한 경험이 있는 개발자이고 AI의 과장된 홍보(hype)에 거부감을 느낀다면, 솔직한 프레임워크를 다음과 같이 제시하겠습니다: GEO는 새로운 어휘를 사용한 SEO가 아닙니다. SEO는 사용자가 직접 종합(synthesis)을 수행하는 10개의 파란색 링크 순위 목록을 최적화합니다. 반면 GEO는 사용자를 대신하여 종합을 수행하고, 당신의 이름이 압축 과정에서 살아남을지 결정하는 기계를 최적화합니다. 성공의 단위는 "순위(ranked position)"에서 "모델이 당신을 정확하게 인용하고 출처를 밝혔는가"로 바뀌었습니다. 이 두 가지는 서로 다른 입력값(inputs)을 요구합니다.

아무도 명확하게 말하지 않는 기계적 차이

검색 엔진(search engine)은 당신의 페이지를 인덱싱(index)하고 순위를 매깁니다. 생성 엔진(generative engine)은 청크(chunks)를 검색(retrieve)하여 LLM에 전달하고, LLM은 당신의 이름을 언급할 수도 있고 하지 않을 수도 있는 문단을 작성합니다. 이 파이프라인(pipeline)에서는 전통적인 검색에서는 일어나지 않는 세 가지 일이 발생합니다:

청킹(Chunking)은 문맥을 파괴합니다. 검색(Retrieval) 과정에서 페이지는 200~800 토큰 크기의 파편으로 분할됩니다. 만약 당신의 주장과 그에 대한 제한 조건(qualifier)이 서로 다른 청크에 나뉘어 있다면, 모델은 한쪽 정보만 얻게 됩니다. 저의 Perplexity 오인용 사례는 "지연 시간에 민감한 호출은 Groq로 라우팅합니다"라는 문장은 깔끔한 청크로 살아남았지만, "...하지만 이로 인해 상태 비동기화(state desync)가 발생하여 나중에 되돌렸습니다"라는 문장은 600 토큰 떨어진 다른 문단에 위치했기 때문에 발생했습니다.
모델은 인용 앵커(citation anchor)를 필요로 합니다. Perplexity, ChatGPT 검색, 그리고 웹 접속 기능이 있는 Claude는 명확한 출처와 연결된 개별적인 사실적 진술을 인용하는 것을 선호합니다. 추출 가능한 사실이 없는 모호한 산문은 요약은 될지언정 출처가 명시되지는 않습니다. 출처가 명시되지 않는다는 것은 링크도, 추천도, 권위 신호(authority signal)도 없음을 의미합니다.
저자성(Authorship)은 장식이 아니라 신호입니다. 두 소스가 동일한 주장을 할 때, 검색 엔진은 구조화된 저자성을 갖추고 이전에 확인된 도메인에 대한 기록이 있는 쪽으로 기울어집니다. 여기서 대부분의 기술 창업자들이 기회를 놓칩니다. 그들은 자신이 통제할 수 없는 플랫폼에 훌륭한 스레드를 게시하고, 정작 인용은 플랫폼이 가져가게 됩니다.

따라서 생성형 엔진 최적화(GEO)의 핵심은 구조화된 데이터, 인용, 그리고 본인이 소유한 도메인에 구축된 지속 가능한 페이지입니다. 아래의 모든 내용은 제가 유료 배포 없이, 멀티 에이전트 스택(multi-agent stack)을 사용하여 Oracle Cloud에서 실행되는 AIdeazz를 위해 이를 어떻게 구현했는지에 대한 내용입니다.

검색을 위해서는 산문보다 구조화된 사실이 유리합니다

가장 영향력이 큰 단 한 가지 변화: 저는 모든 핵심적인 주장(load-bearing claim)이 청크 수준에서 자급자족(self-contained)할 수 있도록 기술 페이지를 다시 작성했습니다. 실질적으로는 다음과 같습니다:

각 주장(claim)은 동일한 문장 내에서 또는 바로 다음 문장에서 자체적인 한정어(qualifier)를 동반합니다. 단순히 "속도를 위해 Groq를 사용합니다"라고 하는 것이 아니라, "Telegram 에이전트 호출을 2초 미만의 SLA(Service Level Agreement) 내에서 Groq의 Llama 3.3 70B로 라우팅합니다. 도구 사용(tool-use)의 신뢰성이 필요한 호출은 약 1.8초의 지연 시간(latency) 증가를 감수하고 Claude Sonnet으로 보냅니다"와 같이 작성합니다.
숫자는 세 단락 아래에 있는 차트가 아니라 문장 내(inline)에 존재해야 합니다. 차트는 텍스트 청커(text chunker)에게 보이지 않습니다.
schema.org 필드에 실제 주장 텍스트를 미러링한 FAQPage 및 TechArticle JSON-LD를 추가하여, 구조화된 레이어(structured layer)가 산문 레이어(prose layer)를 강화하도록 했습니다.

제 에이전트 페이지 중 하나에 적용된 스키마는 다음과 같습니다:

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

JSON-LD가 Perplexity가 당신을 인용하게 직접적으로 만드나요? 증명할 수는 없습니다. 그들은 자신들의 검색(retrieval) 가중치를 공개하지 않기 때문입니다. 하지만 이는 측정 가능한 두 가지 효과를 냅니다. Google의 AI Overviews가 연결할 수 있는 깔끔한 엔티티(entity)를 제공하며, 실제로 JSON-LD를 추가한 지 5주 이내에 제 Search Console에 AI Overviews를 통한 유입이 나타났습니다. 또한, 이는 저자가 누구인지, 무엇을 알고 있는지, 그리고 해당 주장이 마지막으로 검증된 시점이 언제인지를 당신이 명시하도록 강제합니다. 이는 생성 엔진(generative engines)이 JSON을 읽든 가시적인 텍스트를 읽든 상관없이 보상하는 메타데이터와 정확히 일치합니다.

저자성 신호(Authorship signals): 개발자들이 건너뛰는 부분

대부분의 기술 창업자들은 저자명(byline)을 나중에 생각할 부수적인 것으로 취급합니다. 하지만 생성 엔진은 그렇지 않습니다. "해당 제품을 실제로 구축하고 있음이 입증된 사람"의 주장은 익명의 콘텐츠 페이지에서 나오는 동일한 주장보다 더 큰 무게를 갖습니다.

제가 구체적으로 수행한 작업은 다음과 같습니다:

모든 페이지가 저자 → /portfolio로 연결되도록 하고, 포트폴리오 페이지는 실제 결과물(실제로 메시지를 보낼 수 있는 Telegram 봇, WhatsApp 에이전트, GitHub 등)로 다시 연결되도록 했습니다. 저자와 작업 증명(proof of work) 사이의 양방향 링크(Bidirectional links)는 검색 엔진이 식별할 수 있는 엔티티(entity)를 형성합니다.
콘텐츠를 통합했습니다. 이전에는 제 글이 Medium, Substack, dev.to 등에 흩어져 있었습니다. 인용이 발생할 때마다 해당 플랫폼들이 언급되었습니다. 저는 모든 기술 포스트의 정식 버전(canonical version)을 aideazz.xyz로 옮겼고, 다른 곳에는 제 도메인을 가리키는 rel="canonical"이 포함된 포인터 스텁(pointer-stubs)만 남겨두었습니다. 두 달 이내에 Perplexity의 인용 출처가 "medium.com/@..."에서 제 개인 도메인으로 바뀌었습니다.
Person 스키마(schema) 내의 sameAs를 사용하여 GitHub, LinkedIn, 그리고 실제 작동 중인 에이전트들을 연결했습니다. 이것이 검색 엔진이 "에이전트를 만드는 Elena"를 다른 모든 Elena와 구별(disambiguate)하는 방식입니다.

빌더를 위한 교훈: 여러분은 이미 존재하는 가장 강력한 GEO 자산, 즉 자신의 이름이 걸린 소프트웨어를 실행하고 있다는 점을 가지고 있습니다. 여러분의 역할은 주장(claim)과 증명(proof) 사이의 연결을 기계가 읽을 수 있는 형태(machine-readable)로 만드는 것입니다. LLM은 여러분의 Telegram 봇에 메시지를 보낼 수는 없지만, 주장 옆에 위치한 "저자는 @AIdeazzBot에서 운영 중인 프로덕션 Telegram 에이전트를 관리함"이라는 문구는 읽을 수 있으며, 이러한 근접 배치(co-location)는 여러분의 버전이 인용될 확률을 높여줍니다.

직접 제어하는 도메인 위의 지속 가능한 페이지

이 부분은 "어디에나 존재하라"는 일반적인 조언에 제가 강력히 반대하는 지점입니다. 포인터(pointers)를 통해 어디에나 존재하십시오. 여러분이 소유한 것에는 정식 버전(canonical)이 되어야 합니다.

생성형 엔진(Generative engines)은 다시 크롤링하고 다시 순위를 매깁니다. 오늘 인용된 주장은 소스가 이동하거나, 플랫폼이 로봇 정책(robots policy)을 변경하거나, 플랫폼 재편 과정에서 포스트가 묻혀버리면 사라질 수 있습니다. 저는 실제로 그런 일이 일어나는 것을 목격했습니다. Perplexity가 6주 동안 인용했던 dev.to 포스트가 dev.to가 태그 페이지를 조정한 후 더 이상 나타나지 않게 되었습니다. 저는 URL 구조를 제어할 수 없었기에 이를 수정할 수 없었습니다.

aideazz.xyz에서 저는 제어할 수 있습니다:

URL 영속성 (URL permanence). 주장(claim)의 URL이 변경되지 않습니다. 주장을 업데이트할 때 경로(path)가 아닌 dateModified를 업데이트합니다.
로봇 및 크롤링 접근 권한 (Robots and crawl access). robots.txt에서 PerplexityBot, ClaudeBot, GPTBot, 그리고 Google-Extended를 명시적으로 허용합니다. 네, 맞습니다 — 저는 AI 크롤러들의 진입을 허용했습니다. 왜냐하면 크롤링이 가능하다는 것은 인용될 수 있기 위해 지불해야 하는 대가이기 때문입니다. 만약 당신의 전략이 그들을 차단하면서 동시에 인용되는 것이라면, 당신은 모순된 설계를 한 것입니다.
서버 사이드 렌더링 콘텐츠 (Server-rendered content). 이 부분이 저를 잡아챘습니다. 제 페이지 중 일부는 클라이언트 사이드 렌더링 (client-rendered) React 방식이었고, AI 크롤러들은 빈 껍데기만을 가져갔습니다. 저는 사실 관계를 담은 콘텐츠를 서버 사이드 렌더링 (server-rendered) HTML로 옮겼습니다. Oracle Cloud의 ARM 프리 티어 (free-tier) 인스턴스에서 이 작업은 4시간이 걸리는 변경이었으며, 검색 기반 추천 (retrieval-driven referrals)을 통해 나타나는 페이지 수를 대략 두 배로 늘려주었습니다.

정확한 내용을 확인하고 싶은 회의론자들을 위한 robots.txt 조각입니다:

User-agent: PerplexityBot
Allow: /

...

여기에는 실질적인 트레이드오프 (tradeoff)가 존재합니다. GPTBot의 크롤링을 허용한다는 것은 OpenAI가 인용 없이 당신의 콘텐츠로 학습할 수 있음을 의미합니다. 저는 인용을 통한 이득이 학습 유출 (training leakage)보다 크다고 결정했습니다. 왜냐하면 저의 해자 (moat)는 산문(prose) 그 자체가 아니라, 그 산문이 가리키는 실행 중인 에이전트 (agents)들이기 때문입니다. 만약 당신의 해자가 텍스트 그 자체라면, 학습 크롤러를 차단하고 더 적은 인용을 받아들이십시오. 스스로에게 이 트레이드오프를 솔직하게 말하십시오. 그것이 트레이드오프가 아닌 척하지 마세요.

실제로 효과를 본 항목들, 순위별 정리

이 과정을 약 4개월간 진행한 후, 추천 트래픽 (referral traffic)과 엔진들이 AIdeazz를 어떻게 설명하는지에 대한 수동 점검을 통해 측정한 결과는 다음과 같습니다:

인라인 번호가 포함된 독립적인 사실적 주장 (Self-contained factual claims with inline numbers) — 가장 큰 단일 효과입니다. 각 청크 (chunk)가 독립적으로 존재할 수 있게 되자 오귀속 (misattribution) 문제가 사라졌습니다.
내 도메인으로의 정전적 통합 (Canonical consolidation onto my domain) — 인용 출처를 플랫폼에서 나로 옮겨왔습니다. 이를 건너뛴다면 복구 불가능한 손실이 될 수 있으므로, 초기에 수행하십시오.
서버 사이드 렌더링 콘텐츠 (Server-rendered content) + 개방형 AI 로봇 (open AI robots) — 보이지 않던 페이지들을 보이게 만들었습니다. 글쓰기와는 무관한 순수 인프라의 영역입니다.
JSON-LD 구조화 데이터 (JSON-LD structured data) — Google AI Overviews에는 측정 가능하지만, Perplexity에 대해서는 그럴듯하지만 아직 증명되지 않았습니다. 비용이 적게 들므로 실행할 가치가 있습니다.
저자-결과물 간의 양방향 링크 (Bidirectional author-to-artifact links) — 속도는 느리지만 복리 효과가 있습니다. 이는 며칠이 아닌 몇 주에 걸쳐 엔티티 (entity)를 구축했습니다.

도움이 되지 않았던 것: 키워드 밀도 (keyword density), 단순히 목적 없는 게시 빈도, 그리고 3,000단어의 서론 아래 인용 가능한 사실을 파묻어버리는 "포괄적인" 장문 페이지들입니다. 생성형 엔진 (generative engines)은 추출 가능한 정밀함 (extractable precision)에 보상을 주며, 제가 테스트할 때마다 다섯 개의 깔끔한 주장이 담긴 900단어 분량의 압축된 페이지가 4,000단어 분량의 페이지보다 매번 더 많이 인용되었습니다.

솔직한 한계

저는 여러분에게 깔끔한 인용 차트를 보여드릴 수 없습니다. 왜냐하면 이 엔진들 중 그 어떤 것도 차트를 제공하지 않기 때문입니다. Perplexity에는 Search Console이 없습니다. 저의 증거는 리퍼럴 로그 (referral logs), Perplexity와 ChatGPT가 AIdeazz를 어떻게 설명하는지에 대한 수동 점검, 그리고 오귀속 (misattribution)의 소멸입니다. 이는 방향성을 나타내는 것이지 결정론적인 것은 아닙니다. 누군가 여러분에게 "GEO 점수"를 판매하려 한다면, 그들은 자신들이 만들어낸 숫자를 팔고 있는 것입니다.

또 다른 한계는 이 지형이 불안정하다는 점입니다. 이 엔진들의 검색 (retrieval) 및 순위 지정 (ranking) 동작은 예고 없이 변경됩니다. 원칙들 — 자신의 도메인을 소유하고, 사실을 깔끔하게 기술하며, 저자성을 증명하고, 크롤링 가능성을 유지하는 것 — 은 모든 검색 시스템이 필요로 하는 것을 설명하기 때문에 지속 가능합니다. 전술은 변할 것입니다. 원칙 위에 구축하고, 전술은 일회용으로 취급하십시오.

자주 묻는 질문 (Frequently Asked Questions)

Q: JSON-LD 구조화 데이터 (Structured Data)를 추가하는 것이 실제로 Perplexity의 인용을 이끌어내나요, 아니면 Google만을 위한 보여주기식 행위인가요?
A: Google AI Overviews의 경우, 몇 주 이내에 Search Console에서 그 효과를 관찰할 수 있습니다. Perplexity의 경우, 그들이 schema.org를 파싱하는지 여부를 공개하지 않기 때문에 아직 증명되지 않았습니다. 그럼에도 불구하고 저는 이를 추가합니다. 왜냐하면 한 시간 정도의 비용이 들 뿐만 아니라, 가시적인 텍스트에 반드시 포함되어야 하는 저자, 주장, 검증 날짜를 명시하도록 강제하기 때문입니다. 이를 하나의 신호(Signal)가 될 수도 있는 일종의 규율(Discipline)로 취급하십시오.

Q: GPTBot과 ClaudeBot의 크롤링을 허용한다면, 아무런 보상 없이 그들의 모델을 무료로 학습시켜 주는 것 아닌가요?
A: 맞습니다. 그것이 실제 트레이드오프 (Tradeoff)이며, 다른 척하지 말아야 합니다. 저는 이를 수용합니다. 왜냐하면 저의 방어 가능한 자산 (Defensible asset)은 산문 (Prose) 그 자체가 아니라, 제 콘텐츠가 가리키는 실행 중인 에이전트 (Agents)들이기 때문입니다. 만약 텍스트 자체가 제품(독점적 연구, 유료 분석 등)이라면, 학습용 크롤러를 차단하고 인용 횟수가 줄어드는 것을 받아들여야 합니다. 당신의 해자 (Moat)가 실제로 어디에 있는지에 따라 결정하십시오.

Q: 엔진의 청커 (Chunker)에 접근할 수 없는 상황에서, 제 청크 (Chunks)들이 독립적으로 완결되어 있는지 어떻게 알 수 있나요?
A: 페이지의 300단어 정도의 조각을 다른 문맥이 없는 새로운 LLM에 붙여넣고, 당신의 주장과 그에 따른 주의 사항 (Caveat)을 말해달라고 요청해 보십시오. 만약 LLM이 그 조각만으로 한정 조건 (Qualifier)을 재구성할 수 없다면, 당신의 문맥은 여러 청크에 걸쳐 분산되어 있으며 검색 (Retrieval) 과정에서 이를 놓치게 될 것입니다. 저는 모든 핵심 문단에 대해 이 검사를 수행하며, 이를 통해 사후에 라우팅 오귀속 (Routing misattribution) 문제를 잡아낼 수 있었습니다.

Q: Medium이나 dev.to의 기존 도달 범위를 포기하면서까지 제 개인 도메인으로 통합할 가치가 있을까요?
A: 도달 범위는 유지하되, 정규 URL (Canonical)을 이동시키십시오. 전체 버전은 본인의 도메인에 게시하고, 플랫폼에는 짧은 버전이나 스텁 (Stub)을 남기되 rel="canonical"을 사용하여 본인의 사이트를 가리키도록 설정하십시오. 이렇게 하면 플랫폼의 발견 가능성 (Discovery)을 유지하면서도, 인용은 당신이 제어할 수 있는 URL로 쌓이게 됩니다. 비용은 포스트당 몇 분 정도이지만, 이점은 플랫폼의 구조 개편이 당신의 인용을 끊어버릴 수 없다는 것입니다.

Q: 잠재적 구매자가 50명 정도인 B2B 도구에게도 이것이 의미가 있을까요?
A: 광범위한 대중을 대상으로 하는 콘텐츠만큼 중요하지는 않지만, 벤더를 조사하기 위해 Perplexity를 실제로 사용하는 구매자들은 당신의 이름이나 경쟁사의 이름을 언급하는 답변을 받게 됩니다. 구매자가 50명뿐이라면, 개별적인 언급 하나하나가 매우 높은 가치를 지닙니다. 스키마 (schema), 서버 렌더링 (server rendering), 명확한 주장 (clean claims) 등 수행해야 할 작업의 비용이 충분히 저렴하기 때문에, 규모가 작더라도 "가치가 있다"고 판단되는 임계값은 낮습니다.

— Elena Revicheva · AIdeazz · Portfolio