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

4개월 동안 우리의 문서 페이지는 Perplexity에서 전혀 순위에 오르지 못했습니다. 심지어 Perplexity가 인용한 출처들보다 우리가 문자 그대로 더 잘 답변하는 질문들에 대해서도 말이죠. 그러다 저는 문서를 Google처럼 다루는 것을 그만두었습니다. 6주 이내에 멀티 에이전트 라우팅 (multi-agent routing)에 관한 페이지가 "how to route between Groq and Claude"라는 질문에 대한 답변에서 번호가 매겨진 인용구로 나타나기 시작했습니다. 이는 제가 어떤 편법을 써서가 아니라, 언어 모델 (language model)이 추측 없이 페이지에서 사실을 추출할 수 있도록 페이지 구조를 재구성했기 때문입니다.

그 차이가 핵심입니다. 검색 엔진 (Search engines)은 문서를 순위 매깁니다. 생성 엔진 (Generative engines)은 주장 (claims)을 추출하고 그 출처를 밝힙니다. 만약 당신의 페이지에 추출 가능하고 출처를 밝힐 수 있는 주장 (claims)이 포함되어 있지 않다면, 당신은 인용되지 않습니다. 대신 링크 없이 허공 속으로 의역되어 사라질 뿐입니다. 실제로 효과가 있었던 것과 그렇지 않았던 것들을 정리해 드립니다.

사고 모델: 당신은 순위 결정 단계가 아니라 추출 단계에 맞춰 글을 쓰고 있는 것입니다

Perplexity나 검색 기능이 포함된 ChatGPT (ChatGPT-with-search)가 질문에 답변할 때는, 검색 단계 (retrieval pass)가 있고 그 다음에 합성 단계 (synthesis pass)가 있습니다. 합성 모델 (synthesis model)은 검색된 몇 개의 청크 (chunks)를 읽고 어떤 문장이 인용할 가치가 있는지, 어떤 출처가 각주를 달 자격이 있는지를 결정합니다. 생성 엔진 최적화 (Generative engine optimization)는 그 합성 단계에서 당신의 문장이 가장 쉬운 선택지가 되도록 만드는 실무입니다.

제가 겪었던 실패 사례: 저는 인간을 설득하는 인간처럼 글을 썼습니다. 긴 서론, "이 포스트에서는 ~을 탐구할 것입니다", 주장 (claims)이 나오기 전의 배경 설명 같은 것들 말이죠. 제 페이지를 청킹 (chunking)하는 합성 모델은 어떠한 사실적 정보 (factual payload)가 나오기도 전에 400 토큰 분량의 서론을 읽어야 했습니다. 경쟁 출처인 어떤 빈약한 SEO 농장 (SEO farm)은 "Groq는 Llama 3.3 70B를 초당 약 280 토큰으로 실행합니다."라고 바로 시작했습니다. 어떤 문장이 인용되었을지 맞춰보세요.

그래서 제가 가장 먼저 변경한 것은 주장 밀도(claim density)였습니다. 이제 모든 섹션은 문맥에서 분리되더라도 독립적으로 생존할 수 있는, 반증 가능하고 자기 완결적인 문장으로 시작합니다. "설정에 따라 성능이 달라질 수 있습니다"와 같은 문장은 인용할 수 없습니다. 대신 다음과 같이 작성합니다: "Oracle Ampere A1 인스턴스에서 Groq 라우팅을 사용한 저희 Telegram 에이전트의 중앙값 왕복 시간(round-trip)은 1.9초였으며, Claude Sonnet을 사용했을 때는 4.3초였습니다." 이 문장은 인용으로서 기능합니다. 주어, 숫자, 그리고 조건이 포함되어 있기 때문입니다.

개발자들이 건너뛰지만 건너뛰어서는 안 되는 부분: 구조화된 데이터 (Structured data)

흔히들 "생성형 엔진 최적화 (Generative Engine Optimization) 구조화된 데이터 인용"이라는 문구를 사용하지만, 대부분의 사람들은 이 유행어 단계에서 멈춥니다. 구체적인 버전은 다음과 같습니다: 크롤러(crawler)에게 귀하의 페이지가 어떤 종류의 것인지, 누가 작성했는지, 그리고 어떤 사실적 주장(factual claims)을 하는지를 알려주는 기계 판독 가능 마크업(machine-readable markup)입니다.

저는 주요 페이지에 JSON-LD를 통해 세 가지 schema.org 타입을 추가했습니다:

• TechArticle (기술 기사): author (저자), datePublished (발행일), dateModified (수정일)를 포함하여, 엔진이 이것이 관리되는 타임스탬프를 가진 기술적 콘텐츠임을 알 수 있게 합니다.
• Person (인물): 저자 식별을 위해 사용하며, sameAs를 통해 저의 실제 프로필을 가리킴으로써 모델이 웹 전반에서 "Elena Revicheva"를 일관된 정체성으로 식별(resolve)할 수 있게 합니다.
• FAQPage (FAQ 페이지): 명시적인 Question (질문) / acceptedAnswer (채택된 답변) 쌍을 포함합니다. 이는 생성형 엔진이 Q&A를 추출하고자 하는 방식과 거의 1:1로 매칭되기 때문입니다.

저희 라우팅 페이지에 최종적으로 적용된 FAQ 블록은 다음과 같습니다:

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

마크업만으로 인용이 발생했을까요? 아닙니다. 하지만 마크업이 있는 페이지는 그것이 없는 동일한 콘텐츠보다 더 빠르고 더 자주 수집되었습니다. 제 분석은 이렇습니다: 구조화된 데이터가 순위를 높여주는 것이 아니라, 귀하가 무엇을 주장하고 있는지, 그리고 누가 그 주장을 하는지에 대한 엔진의 불확실성(uncertainty)을 줄여주는 것입니다. 불확실성이 바로 인용을 가로막는 요소입니다. 모델은 깔끔하게 출처를 밝힐 수 있는 소스를 인용하는 것을 선호합니다.

한 가지 주의할 점은 수치로 명확히 말할 수 있는 부분입니다: 스키마 (schema)는 필요조건일 뿐, 충분조건은 아닙니다. 우리는 동일한 JSON-LD를 가진 두 개의 페이지를 가지고 있었습니다. 밀도 높은 수치적 주장 (numeric claims)이 포함된 페이지는 인용되었지만, 모호한 산문 (vague prose)으로 작성된 페이지는 인용되지 않았습니다. 마크업 (Markup)은 인용 가능한 콘텐츠를 증폭시킬 뿐, 없는 콘텐츠를 만들어낼 수는 없습니다.

저자 신호 (Authorship signals): 모델은 도메인이 아니라 사람을 신뢰해야 합니다

Google의 E-E-A-T는 모호합니다. 생성형 버전은 더 기계적입니다: 엔진이 이 주장을 다른 곳에서도 일관된 내용을 말해온, 일관성 있는 실제 저자와 연결할 수 있는가? 만약 그렇다면, 그 주장은 합성 (synthesis) 과정에서 더 큰 비중을 갖게 됩니다.

제가 구체적으로 실행한 사항은 다음과 같습니다:

1. 모든 기술 페이지에 실제 정체성이 담긴 실제 약력 (bio)을 기재했습니다. "AIdeazz 팀"이 아니라, 링크된 포트폴리오가 있는 실명 저자를 명시했습니다. 모델은 집합 명사 (collective nouns)보다 개체명 (named entities)을 더 잘 식별합니다.
2. sameAs 링크가 제가 실제로 발행하는 모든 곳을 가리키도록 하여 엔티티 그래프 (entity graph)가 연결되도록 했습니다. 제 이름이 멀티 에이전트 라우팅 (multi-agent routing)에 대해 호환되는 내용을 담은 세 곳의 장소에 등장하면, 엔진은 네 번째 언급을 더 신뢰할 수 있는 것으로 취급합니다.
3. 익명의 "최종 가이드 (ultimate guide)" 페이지 발행을 중단했습니다. 그런 페이지들은 인용이 전혀 되지 않았습니다. 이름 없는 텍스트의 벽이 주장하는 것보다, 이름 있는 전문가가 같은 말을 했을 때 모델이 그 주장을 익명의 텍스트에 귀속시킬 이유는 없습니다.

기술 창업자들에게 불편한 부분은 이것입니다: 이는 자신의 이름을 걸어야 하며, 때로는 공개적으로 틀릴 수도 있음을 의미합니다. 가장 많이 인용된 페이지는 제가 "WhatsApp의 세션 윈도우 (session window)에 대해 제가 틀렸었습니다 — 1시간이 아니라 24시간이며, 이로 인해 우리의 전체 재참여 아키텍처 (re-engagement architecture)가 바뀌었습니다"라고 쓴 페이지였습니다. 그 문장은 구체적이고, 날짜가 명시되어 있으며, 소유권이 분명했기 때문에 답변에 인용되었습니다. 확신을 피하는 (Hedged) 콘텐츠는 합성 과정에서 보이지 않습니다.

인용 준비가 된 형식 (Citation-ready format): 검색기 (retriever)가 낚아챌 수 있도록 청크 (chunks) 단위로 작성하세요

검색 (Retrieval)은 보통 수백 토큰 정도의 청크 (chunks) 단위로 작동합니다. 만약 핵심 사실이 세 개의 단락에 걸쳐 나뉘어 있고, 숫자는 한 단락에, 조건은 다른 단락에 있다면, 검색된 청크는 불완전하며 인용되지 않을 것입니다. 자기 완결적인 청크 (Self-contained chunks)가 승리합니다.

이제 모든 기술 페이지에 적용하는 저의 체크리스트는 다음과 같습니다:

• 문단당 하나의 주장, 완전한 명시 (One claim per paragraph, fully specified). 숫자와 그 조건은 동일한 문장에 존재해야 합니다. "Oracle의 Always Free 티어는 4개의 Ampere 코어와 24GB RAM을 제공하며, 이는 Postgres 인스턴스를 포함한 우리의 전체 Telegram 에이전트 스택을 월 $0에 실행하기에 충분합니다"는 하나의 청크(chunk)로서 하나의 작업만을 수행합니다.
• 비교를 위한 표 (Tables for comparisons). 제가 Groq vs Claude vs 로컬 모델을 비교했을 때, 저는 이를 마크다운 표(markdown table)에 넣었습니다. 생성 엔진(Generative engines)은 표 형식의 데이터를 깔끔하게 추출하며 종종 이를 그대로 재현합니다. 산문(Prose) 형태의 비교는 엉망이 되기 쉽습니다.
• 명시적인 단위와 날짜 (Explicit units and dates). "최근(Recently)"은 인용할 수 없습니다. "2025년 10월 기준(As of October 2025)"은 인용 가능합니다. 지연 시간(latency) 수치를 신뢰할지 결정하는 모델은 그 수치가 오래된 것인지 여부를 중요하게 여깁니다.
• 질문 형태의 헤딩 (Question-shaped headings). 실제 쿼리(query) 문구와 일치하는 헤딩은 검색(retrieval) 시 매칭될 확률이 높습니다. "Oracle Always Free 인스턴스가 회수되지 않도록 유지하는 방법은 무엇인가요?"가 "인프라 고려 사항"보다 더 효과적입니다.

표를 활용하는 것은 과소평가되어 있습니다. 저희의 라우팅 페이지에서 실행했던 내용은 대략 다음과 같습니다:

작업 유형 (Task type)	모델 (Model)	중앙값 지연 시간 (Median latency)	1M 토큰당 비용 (Cost per 1M tokens)
짧은 구조화된 작업 (Short structured)	Groq (Llama 3.3 70B)	1.9s	~$0.59 in / $0.79 out
...

해당 표는 비용 최적화된 에이전트 스택에 관한 Perplexity의 답변에 저희를 출처로 하여 거의 그대로 등장했습니다. 같은 내용을 말하는 긴 산문 덩어리였다면 그렇게 되지 않았을 것입니다.

직접 제어하는 도메인에서의 지속 가능한 페이지 (Durable pages on domains you control)

이 지점이 제가 대부분의 GEO(Generative Engine Optimization) 조언과 의견이 다른 부분입니다. 대부분의 조언은 권위 있는 제3자 사이트에서의 언급을 쫓으라고 말합니다. 그것도 도움이 되지만, 그것은 빌린 땅입니다. 복리로 쌓이는 인용은 aideazz.xyz에서 발생합니다. 왜냐하면 인용 내용이 정확하게 유지될지, 업데이트될지, 그리고 타임스탬프가 최신 상태로 유지될지를 제가 직접 제어할 수 있기 때문입니다.

생성형 엔진 (Generative engines)은 고전적인 SEO (검색 엔진 최적화)보다 더 가혹한 방식으로 정보의 노후화 (staleness)에 페널티를 부여합니다. 모두가 더 최신 모델을 사용하고 있는데 어떤 페이지가 "Claude 3 Opus"라고 말하고 있다면, 그 페이지는 방치된 것으로 간주되며, 합성 모델 (synthesizer)은 설령 귀하의 정보가 더 상세하더라도 최신 소스를 선호합니다. 저는 이제 모델이 변경될 때, 가격이 변경될 때, 아키텍처 결정이 변경될 때와 같이 실제 주기 (cadence)에 맞춰 상위 페이지들의 dateModified와 실제 수치들을 업데이트합니다. 지속 가능한 페이지란 한 번 쓰고 마는 페이지가 아니라, 계속해서 정확하게 유지하는 페이지입니다.

구체적인 비용 현실: 이러한 페이지들을 호스팅하는 비용은 Oracle의 Always Free 티어를 사용하여 사실상 거의 들지 않습니다. 진짜 비용이 드는 부분은 정확성을 유지하기 위한 규율 (discipline)입니다. 저는 방치할 80개의 페이지보다 직접 관리할 수 있는 8개의 페이지를 갖는 쪽을 택하겠습니다. 방치된 페이지는 단순히 인용이 중단되는 것에 그치지 않습니다. 그것은 귀하의 도메인이 관리되지 않는 것처럼 보이게 만들어, 활성화된 페이지들의 순위까지 함께 떨어뜨립니다.

효과가 없었던 것들

유익한 정보를 드리기 위해, 제가 시도했지만 시간을 낭비했던 것들을 말씀드려야겠습니다.

키워드 밀도 (Keyword density). "generative engine optimization"의 변형 문구들을 채워 넣는 것은 아무런 효과가 없었습니다. 합성 모델 (Synthesis models)은 키워드를 세는 것이 아니라 의미를 추출합니다. 해당 문구는 페이지의 주제가 명확해지도록 문맥 속에서 한 번 등장하면 충분합니다. 그 이후로는 노이즈일 뿐입니다.

백링크 (Backlinks) 구걸하기. 고전적인 링크 빌딩 (link-building)은 Google 순위를 약간 높여주었지만, Perplexity에서의 존재감에는 전혀 영향을 주지 못했습니다. 생성형 엔진은 검색 엔진보다 링크 그래프 (link graphs)보다 콘텐츠 추출 가능성 (extractability)에 더 큰 가중치를 둡니다.

길고 포괄적인 가이드. 4,000단어 분량의 모든 것을 담은 페이지는 1,200단어 분량의 집중된 페이지 3개보다 인용 횟수가 적었습니다. 합성 모델은 명확하게 하나의 답변 가능한 주제를 다루는 페이지를 선호합니다. 내용이 방대해지면 청크 (chunk)당 주장 밀도 (claim density)가 희석됩니다.

빈약한 콘텐츠에 FAQ 스키마 (FAQ schema)를 사용하여 모델을 속이려는 시도. 저는 구조가 이를 보완해주길 바라며 모호한 답변이 담긴 페이지에 FAQ 마크업을 추가했습니다. 하지만 인용되지 않았습니다. 구조는 반드시 실제적이고 구체적인 답변을 감싸고 있어야 합니다.

제가 현재 실행 중인 실제 워크플로우

AIdeazz의 각 새로운 기술 페이지에 대해:

1. 해당 페이지가 답변하는 단 하나의 질문을 결정하고, 사용자가 Perplexity에 입력할 법한 방식으로 문장을 구성합니다.
2. 처음 세 문장 안에 하나의 긴밀하고, 번호가 매겨지며, 상세히 명시된 주장 (claim)으로 답변을 작성합니다.
3. 지연 시간 (latency), 비용 (cost), 에러 메시지 (error messages), 버전 문자열 (version strings)과 같은 구체적인 수치를 담은 표나 코드 블록 (code block)으로 이를 뒷받침합니다.
4. 실제 저자 정보와 sameAs가 포함된 TechArticle + Person + FAQPage JSON-LD를 추가합니다.
5. 각 단락은 하나의 주장만을 담은 독립적인 청크 (chunk)로 유지합니다.
6. 모든 수치에 날짜를 기입합니다.
7. 현실이 변하면 다시 검토하고 업데이트하며, dateModified를 정직하게 갱신합니다.

이것은 어떤 속임수도 아닙니다. 정확하게 글을 쓰고, 기계가 당신을 왜곡하지 않고 인용할 수 있도록 구조화하는 과정입니다. 대부분의 페이지가 인용되지 않는 이유는 최적화가 잘못되어서가 아니라, 출처를 밝힐 만큼 충분히 구체적인 내용을 담고 있지 않기 때문입니다.

자주 묻는 질문 (Frequently Asked Questions)

Q: JSON-LD 구조화 데이터 (structured data)가 실제로 인용을 유도하나요, 아니면 단순히 상관관계인가요?
A: 그 자체만으로는 아닙니다. 저는 동일한 스키마 (schema)를 가진 두 페이지를 대상으로 A/B 테스트를 진행했는데, 밀도 높은 수치적 주장 (numeric claims)이 포함된 페이지만이 인용되었습니다. 제가 내린 결론은 다음과 같습니다. 구조화 데이터는 당신이 무엇을 주장하는지, 그리고 누가 주장하는지에 대한 엔진의 불확실성을 줄여줍니다. 이는 콘텐츠가 이미 추출 가능한 상태일 때, 당신을 인용하기 더 쉬운 소스로 만들어 줍니다. 즉, 구조화 데이터는 원인이 아니라 증폭기 (amplifier)입니다.

Q: 변경 사항이 Perplexity 답변에 반영되기까지 얼마나 걸리나요?
A: 저희의 경우, 구조를 재편한 시점부터 타겟 쿼리 (target query)에서 첫 번째 재현 가능한 인용이 나타나기까지 6주가 걸렸습니다. 이는 Google의 재색인 (re-indexing)보다 느린데, 콘텐츠가 크롤링 (crawled)되고, 청킹 (chunked)된 후, 해당 콘텐츠를 검색하는 쿼리의 합성 (synthesis) 과정에서 실제로 선택되어야 하기 때문입니다. 3일 만에 피드백이 오기를 기대하지 마세요. 두 달 동안 매주 추적하며 확인하시기 바랍니다.

Q: 아직 Google에서 순위가 높지 않은데도 GEO(Generative Engine Optimization)를 할 가치가 있을까요?
A: 네, 어쩌면 그럴수록 더 가치가 있습니다. 생성형 엔진(Generative engines)은 기존 검색 엔진보다 링크 권위(Link authority)보다 콘텐츠 추출 가능성(Content extractability)에 더 큰 비중을 둡니다. 따라서 모호한 산문을 사용하는 고권위 사이트보다, 날카롭고 구체적이며 잘 구조화된 답변을 제공하는 빈약한 도메인이 더 많이 인용될 수 있습니다. 저희의 경우, 동일한 키워드로 Google 3페이지에 머물러 있는 동안에도 라우팅(Routing) 관련 질의에서 인용된 사례가 있습니다.

Q: 모델 가격이나 지연 시간(Latency)처럼 시간이 지나면 쓸모없어지는 사실적 주장(Factual claims)은 어떻게 관리하나요?
A: 페이지를 단순히 배포하는 콘텐츠가 아니라, 유지 관리해야 하는 코드처럼 취급하세요. 모델, 가격, 또는 아키텍처 결정이 변경될 때마다 숫자와 dateModified를 업데이트합니다. 생성형 엔진은 최신 소스를 눈에 띄게 선호하므로, 상세하지만 오래된 페이지는 내용이 적더라도 최신인 페이지에 밀리게 됩니다. 필요한 것은 인프라가 아니라 규율(Discipline)입니다. 페이지 자체는 Oracle의 Always Free 티어에서 무료로 운영됩니다.

Q: 제3자 언급(Third-party mentions)에 먼저 투자해야 할까요, 아니면 제 자체 페이지에 먼저 투자해야 할까요?
A: 자체 페이지가 우선입니다. 고권위 사이트에서의 제3자 언급도 도움이 되지만, 그것은 빌린 땅과 같습니다. 내용을 업데이트하거나, 타임스탬프를 갱신하거나, 잘못된 숫자를 수정할 수 없기 때문입니다. 저희에게 복리 효과를 가져다준 인용들은 제가 직접 제어하는 도메인에서 발생했으며, 그곳에서 시간이 지나도 정확성을 유지할 수 있었습니다.

— Elena Revicheva · AIdeazz · Portfolio