AI 답변 엔진은 당신의 @graph를 실제로 어떻게 해상하는가

스키마 검증기는 문법을 봅니다. JSON-LD가 잘 형성되어 있는지 알려주죠. AI 엔진이 그걸로 무엇을 하는지는 알려주지 않아요.

지난 1년간 RankLabs로 같은 @graph 페이로드를 다섯 AI 엔진에 돌리며 어디서 갈라지는지 봐 왔습니다. 차이는 미묘하지 않아요. 어떤 엔진은 엔티티를 공격적으로 머지합니다. 어떤 엔진은 분리해요. 한 엔진은 sameAs 체인을 완전히 무시합니다. 다른 한 엔진은 세 홉 깊이까지 따라가요. 팀이 AI 엔진 최적화를 다섯이 아니라 하나로 다루면, 두 엔진을 돕고 세 엔진을 해치는 작업을 출시하게 됩니다.

이게 그 필드 가이드입니다.

왜 @graph 형태가 처음부터 중요한가

엔티티별 별도 JSON-LD 블록과 단일 통합 @graph 사이의 선택은 화장이 아닙니다. AI 엔진은 엔티티를 추출한 뒤, @id를 공유하거나 sameAs로 연결된 엔티티를 머지하는 해상 단계를 돌려요. 별도 블록이면 머지가 블록별로 일어나거나(또는 실패하거나) 합니다. @graph면 모든 참조가 명시적으로 @id에 묶이기 때문에 문서 전체에서 머지가 일어나요.

구체적으로: 한 스크립트 태그에서 Organization을 발행하고 두 번째 스크립트 태그에서 Product가 그걸 참조한다면, 일부 엔진은 두 개의 연결되지 않은 문서로 다루고 머지를 거부합니다. 같은 페이로드가 단일 @graph라면 참조가 로컬이라 깔끔하게 해상되고요.

제가 테스트한 모든 엔진은 통합된 @graph를 선호합니다. 어느 곳도 페널티를 주지 않아요. 일방적인 선택이에요.

ChatGPT: 공격적 머지, @id에 엄격

OpenAI의 웹 페처(그리고 거기서 파생된 ChatGPT 브라우즈 도구)는 @id가 일치할 때 엔티티를 공격적으로 머지합니다. Organization이 안정적인 @id를 갖고 있고 모든 Product, Article, BreadcrumbList에서 일관되게 참조한다면, ChatGPT는 사이트 전체를 하나의 지식 단위로 접고 쿼리 유형 전반에서 자신 있게 인용해요.

@id가 흔들리면 (페이지-URL-as-id가 가장 흔한 형태의 이 버그입니다. 커머스 진단 카탈로그의 1번 버그 참조) ChatGPT는 모든 참조를 별도의 조직으로 다룹니다. 이름 매치만으로는 머지하지 않아요. 결과: 당신을 언급해야 할 쿼리들이 안정적인 @id를 가진 경쟁사를 인용합니다.

측정한 것: 일관된 @id 구조를 가진 브랜드는 콘텐츠는 같지만 @id가 불안정한 브랜드보다 관련 쿼리에서 40~70% 더 인용됩니다. 변수는 @id 구조이지, 콘텐츠 품질이 아니에요.

실용적 규칙: 스키마를 한 줄도 쓰기 전에 @id 컨벤션을 정하고, 절대 어기지 마세요. 브랜드 엔티티에는 https://yoursite.com/#organization. 상품에는 https://yoursite.com/products/{slug}#product. 문서화하세요. CI에서 강제하세요.

Perplexity: sameAs를 따라가고 인용을 무겁게 가중치

Perplexity는 어느 엔진보다 sameAs 체인을 강하게 따라갑니다. Organization의 sameAs에 Wikidata, Wikipedia, 검증된 소셜 프로필이 포함되어 있다면, Perplexity는 그걸 신뢰 시그널로 다루며 답변을 구성할 때 당신을 더 높게 가중치합니다.

sameAs가 비어 있거나 죽은 URL을 가리키면 Perplexity는 당신의 가중치를 깎아요. 다른 변경 없이 Wikidata sameAs 참조를 추가하는 것만으로 같은 쿼리에서 인용되지 않던 브랜드가 인용되는 걸 봤습니다.

Perplexity의 또 다른 특이점: 명시적 URL 출처와 함께 인용해요. Perplexity의 인용 점유율은 출처 없이 요약하는 엔진들보다 깨끗한 시그널입니다. AEO 진척도를 벤치마크할 거라면 Perplexity가 가장 먼저 추적할 엔진이에요.

실용적 규칙: 모든 주요 엔티티(Organization, 개인 브랜드라면 Person, 주력 Product 라인)는 정규 외부 식별자를 가리키는 sameAs 배열을 갖게 하세요. Wikidata 먼저, Wikipedia 두 번째, 공식 소셜 세 번째.

Claude: 보수적 머지, 구조에 민감

Anthropic의 파서는 다섯 엔진 중 가장 보수적입니다. @id로 명시적으로 묶이지 않은 엔티티는 머지하지 않아요. 구조도 더 문자 그대로 읽습니다: Article 엔티티의 author가 정규 Person으로의 @id 참조 대신 중첩된 Person 객체로 설정되어 있다면, Claude는 그 저자를 Organization에서 참조한 사람과 다른 사람으로 다룹니다.

해법은 ChatGPT 케이스와 같지만(언제나 참조, 절대 중첩 금지) Claude는 같은 버그에 더 가혹하게 벌점을 매겨요.

Claude는 description 필드도 무겁게 가중치합니다. 주요 Person과 Organization 엔티티의 좋은 description은 Claude가 당신을 요약할 때 당신을 어떻게 특징화할지에 실제로 영향을 줘요. 엉성한 description은 답변에 글자 그대로 박힙니다, 때로는 몇 년 동안.

실용적 규칙: description 필드를 헤드라인처럼 쓰세요. 헤드라인이 맞아요.

Gemini: 구글의 기존 시그널에 가중치

Gemini는 구글의 더 넓은 인프라 안에 앉아 있어서, 구글이 십수 년간 쌓은 크롤링 기록, 링크 그래프, 엔티티 연관 관계에 접근합니다. 결과: Gemini는 스키마 버그에 가장 관대하고 더 넓은 토픽 권위에 가장 가차 없어요.

완벽한 JSON-LD를 출시해도 구글이 이 사이트에 대한 기존 토픽 평가가 쿼리와 맞지 않으면 Gemini는 인용하지 않습니다. 반대로 평범한 JSON-LD를 출시해도 구글이 그 토픽에 대해 이미 신뢰한다면 인용될 수 있어요.

Gemini는 스키마가 필요하지만 충분하지 않은 엔진이에요. 다른 엔진들보다 콘텐츠 깊이와 권위가 더 중요합니다.

실용적 규칙: 스키마 작업 범위에서 Gemini는 후순위로 미루세요. 마지막에 고치세요. 콘텐츠 먼저 고치세요.

Google AI Overviews: 구조화 데이터 우선, 인용에 인색

AI Overviews는 일반 검색을 굴리는 같은 크롤에서 추출하지만, @graph 추출에 무겁게 가중치를 두며 풍부하고 잘 형성된 구조화 데이터를 가진 사이트를 인용하길 선호합니다. 단점은 출처가 분명히 드러나지 않은 채 요약하는 경우가 많아서, Perplexity보다 어트리뷰션 추적이 어렵다는 거예요.

AI Overviews를 가장 세게 때리는 버그 패턴은 JS 렌더링 스키마 문제입니다 (카탈로그의 8번 버그). Googlebot은 색인을 위해 JS를 렌더링하지만, AI Overviews 추출 파이프라인은 많은 경우 초기 HTML 응답을 읽어요. 하이드레이션 후에만 존재하는 스키마는 일반 구글 검색이 페이지를 잘 랭크해도 AI Overviews 경로에는 보이지 않습니다. 여러 협업에서 팀이 Search Console이 유효하다고 보고하니까 스키마가 괜찮다고 생각했던 케이스를 봤어요.

실용적 규칙: 초기 응답에서 스키마를 서버 사이드로 발행하세요. 항상.

협업 범위 책정에 시사하는 것

다섯 엔진은 호환되지 않습니다. ChatGPT를 돕는 작업(안정적 @id)은 Perplexity를 돕는 작업(sameAs 체인)과 다르고, 그건 또 Google AI Overviews를 돕는 작업(서버 사이드 렌더링)과 다릅니다. 유용한 Sprint 범위는 슬라이드에서 가장 인상적인 수정이 아니라, 가장 이기고 싶은 엔진별 우선순위로 작업을 정렬해요.

Sprint 범위를 잡을 때는 브랜드가 가장 많이 차지하고 싶은 쿼리를 어느 엔진이 끌고 가는지 묻습니다. 그러면 아키텍처 결정과 템플릿별 구현이 그 엔진들이 가장 민감한 스키마 패턴을 우선시해요. 검증기 스위트가 그 규칙을 인코딩합니다.

어느 엔진이 중요한지 모른다면, Audit이 답하는 질문이에요. RankLabs가 우선 쿼리를 다섯 엔진 모두에 돌리고 누가 당신을 인용하는지, 누가 경쟁사를 인용하는지, 구조적 격차가 어디인지 보고합니다. 그 베이스라인 없이는 추측하는 것뿐입니다.

엔진들은 마법이 아니에요. 각자 규칙이 있어요. 규칙을 존중하는 스키마 작업은 이깁니다. 그러지 않는 작업은 안 이깁니다.