AI 엔진을 위한 Schema 마크업: 효과가 탁월한 타입들

목차

2026년 5월 업데이트.

TL;DR: FAQPage와 HowTo schema는 AI 엔진이 이를 미리 답변된 질문과 단계별 절차로 파싱하기 때문에 시간당 GEO 인용 리프트가 가장 높습니다. Article/BlogPosting은 저자 신뢰성을 신호합니다. Person과 Organization은 엔티티 그래프를 고정하여 모델이 당신을 다른 사람과 혼동하지 않도록 합니다. 모호한 타입은 무시하세요 — 2026년에는 지표를 움직이지 않습니다.

[운영자 노트] 나는 내 사이트와 클라이언트 사이트에서 정기적으로 schema 감사를 수행합니다. AI 엔진이 실제로 사용하는 타입과 그냥 아무 역할도 하지 않는 타입 사이의 격차는 대부분의 가이드가 인정하는 것보다 훨씬 큽니다.

AI 엔진이 Google과 다르게 schema를 읽는 이유

전통적인 Google 크롤러는 schema를 주로 리치 결과를 위해 사용합니다 — SERP의 별점 평가와 FAQ 드롭다운. 이것은 렌더링 문제입니다. schema는 기능 요건을 충족하거나 충족하지 않습니다.

AI 엔진 — ChatGPT, Perplexity, Gemini, Claude — 은 schema를 다르게 사용합니다. SERP를 렌더링하는 것이 아닙니다. 페이지를 분석하여 이산적이고 인용 가능한 사실을 추출합니다. Schema 마크업은 지름길입니다. 텍스트 블록의 의미를 추론하는 대신 모델은 @type 필드를 읽고 알 수 있습니다: “이것은 질문-답변 쌍이다”, 또는 “이것은 구조화된 절차다”, 또는 “이것은 저자다”.

이것이 어떤 타입이 중요한지를 바꿉니다. 콘텐츠를 깔끔하고 추출 가능한 단위로 직렬화하는 타입이 승리합니다. 주로 Google이 리치 결과를 표시하는 데 도움이 되는 타입은 GEO 맥락에서 가치가 낮습니다.

AI 훈련 데이터와 실시간 검색을 지원하는 크롤러(Common Crawl, Bing 인덱스, Google 크롤)는 모두 JSON-LD를 처리합니다. 마크업이 유효하고 의미적으로 정확하면 수집됩니다. 가짜 FAQ나 불일치 타입으로 채워져 있으면 모델은 불신하거나 무시하도록 학습합니다.

Article과 BlogPosting: 저자 앵커

게시하는 모든 게시물에는 Article 또는 BlogPosting schema가 있어야 합니다. 화려하지는 않지만 기초적입니다.

GEO에서 가장 중요한 두 필드는 author와 dateModified입니다. AI 엔진은 인용을 표시할지 결정할 때 신선도와 명명된 저자를 가중합니다. 선언된 저자 없이 2년 된 게시일을 가진 페이지는 명명된 전문가와 최근 업데이트를 가진 페이지와 경쟁에서 불리합니다.

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "AI 엔진을 위한 Schema 마크업: 효과가 탁월한 타입들",
  "author": {
    "@type": "Person",
    "name": "Alejandro Rioja",
    "url": "https://alejandrorioja.com/about/"
  },
  "datePublished": "2026-05-31",
  "dateModified": "2026-05-31",
  "publisher": {
    "@type": "Organization",
    "name": "Alejandro Rioja",
    "url": "https://alejandrorioja.com"
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://alejandrorioja.com/blog/schema-markup-for-ai-engines-the-types-that-punch-above-their-weight/"
  }
}

dateModified를 정확하게 유지하세요. 모든 페이지에 가짜 “오늘 업데이트” 날짜를 붙인 사이트를 봤습니다 — 모델은 패턴을 감지하고 할인합니다. 실제로 콘텐츠를 업데이트할 때만 날짜를 업데이트하세요.

FAQPage: 시간당 최고 GEO 리프트

지금 당장 모든 정보 페이지에 추가할 schema 타입을 하나 선택해야 한다면 FAQPage입니다. 이유는 구조적입니다: AI 엔진은 이미 질문에 답하길 원합니다. FAQPage는 단일 노드에 레이블이 붙은 질문과 레이블이 붙은 답변을 제공합니다. 추론이 필요 없습니다.

리프트는 추천 스니펫에도 나타나지만 GEO 효과는 더 신뢰할 수 있습니다. 사용자가 Perplexity에 FAQ 항목 중 하나와 일치하는 질문을 하면 모델은 이미 인용 형식으로 지정했기 때문에 거의 그대로 답변을 인용할 수 있습니다.

실제로 작동하는 FAQ schema를 위해 내가 따르는 규칙:

1. 각 질문은 실제 사용자가 표현하는 방식을 반영해야 합니다 — 마케터로서 표현하는 방식이 아닙니다.
2. 각 답변은 자체 완결적이어야 합니다. 기사를 읽은 후에만 의미가 있는 답변은 인용되지 않습니다.
3. 페이지당 3~6개의 질문이 최적점입니다. 10개의 약한 질문으로 채우면 도움보다 해가 됩니다.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "AI 엔진은 어떤 schema 타입을 우선시하나요?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "AI 엔진은 FAQPage, HowTo, Article/BlogPosting, Person, Organization을 우선시합니다. 이 타입들은 콘텐츠를 깔끔하고 추출 가능한 단위로 직렬화하여 모델이 산문을 분석하지 않고도 직접 인용할 수 있습니다."
      }
    },
    {
      "@type": "Question",
      "name": "2026년에도 schema 마크업이 SEO에 도움이 되나요?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "네. Schema 마크업은 전통적인 크롤러(리치 결과용)와 AI 크롤러(인용 추출용) 모두에 도움이 됩니다. FAQPage와 HowTo는 구현 시간당 가장 높은 수익을 제공합니다."
      }
    },
    {
      "@type": "Question",
      "name": "페이지당 몇 개의 FAQ 항목을 포함해야 하나요?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "자체 완결적인 질문-답변 쌍 3~6개가 최적점입니다. 6개를 초과하면 품질이 희석되고, 3개 미만이면 인용 표면적이 줄어듭니다."
      }
    }
  ]
}

HowTo: AI 엔진이 좋아하는 절차

HowTo schema는 활용이 부족합니다. 대부분의 사람들은 레시피 스타일 콘텐츠에 구현하고 그곳에서 멈춥니다. 하지만 설정 가이드, 감사, 프레임워크 등 모든 절차적 콘텐츠가 후보입니다.

GEO에서 체급 이상의 성과를 내는 이유: AI 엔진은 “어떻게 하면…” 쿼리에 단계를 나열하여 정기적으로 응답합니다. 페이지에 명명된 단계가 있는 HowTo schema가 있으면 모델은 구조를 거의 정확하게 재현할 수 있습니다. 요약하는 것이 아니라 절차를 인용하는 것입니다.

{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "블로그 게시물에 FAQPage Schema 추가하는 방법",
  "step": [
    {
      "@type": "HowToStep",
      "position": 1,
      "name": "3~6개의 실제 사용자 질문 식별",
      "text": "Google Search Console 쿼리, Reddit 스레드, 고객 이메일에서 질문을 추출합니다. 각 질문은 마케터 언어가 아닌 자연어를 반영해야 합니다."
    },
    {
      "@type": "HowToStep",
      "position": 2,
      "name": "자체 완결적 답변 작성",
      "text": "각 답변은 독립적으로 의미가 있어야 합니다 — '위에서 언급했듯이'나 '3절 참조' 같은 참조 없이. 답변당 40~120단어를 목표로 합니다."
    },
    {
      "@type": "HowToStep",
      "position": 3,
      "name": "페이지 head 또는 body에 JSON-LD 블록 추가",
      "text": "<script type='application/ld+json'> 태그에 FAQPage JSON-LD를 붙여넣습니다. 게시 전 Google's Rich Results Test와 Schema.org Validator로 유효성을 검사합니다."
    }
  ]
}

실용적인 참고: HowToStep 텍스트를 짧고 스캔하기 쉽게 유지하세요. AI 엔진은 단계 텍스트를 대략 문장 수준의 세분성으로 발췌합니다. 단계 필드에 400단어 에세이는 대부분 무시됩니다.

Person과 Organization: 엔티티 명확화

이것이 실제 문제를 예방하는 화려하지 않은 타입입니다. AI 엔진은 엔티티 그래프 — 사람과 조직이 누구인지에 대한 내부 맵 — 을 유지합니다. Person schema가 없거나 일관성이 없으면 모델이 이름을 공유하는 다른 사람과 혼동하거나 단순히 알 수 없는 엔티티로 레이블을 붙이고 콘텐츠를 우선순위를 낮출 수 있습니다.

About 페이지와 저자 페이지의 Person schema는 세 가지를 합니다:

1. 정규 이름과 URL을 선언합니다
2. sameAs를 통해 소셜 프로필에 링크합니다(엔티티 앵커 역할)
3. knowsAbout을 통해 전문성을 연결합니다

{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Alejandro Rioja",
  "url": "https://alejandrorioja.com/about/",
  "sameAs": [
    "https://www.linkedin.com/in/alejandrioja/",
    "https://twitter.com/alejandrorioja",
    "https://github.com/alejandrorioja"
  ],
  "knowsAbout": [
    "AI agents",
    "Generative Engine Optimization",
    "SEO",
    "growth marketing"
  ],
  "jobTitle": "Founder",
  "worksFor": {
    "@type": "Organization",
    "name": "Alejandro Rioja",
    "url": "https://alejandrorioja.com"
  }
}

Organization schema는 홈페이지에 있어야 합니다. 여기서 sameAs 링크는 특히 중요합니다 — 모델이 웹사이트, LinkedIn 페이지, Crunchbase 프로필이 모두 같은 엔티티임을 확인할 수 있게 합니다.

BreadcrumbList: 내비게이션 컨텍스트 신호

BreadcrumbList는 콘텐츠 신호가 아닌 UX 편의성처럼 보이기 때문에 자주 건너뜁니다. 실수입니다.

AI 엔진은 브레드크럼을 사용하여 콘텐츠가 사이트 분류 체계에서 어디에 있는지 이해합니다. /blog/seo/ 안에 있는 “schema 마크업”에 관한 게시물은 독립 페이지와 다르게 맥락화됩니다. 그 계층 구조는 모델이 콘텐츠를 정확하게 분류하는 데 도움이 되어 어떤 쿼리에 표시될지에 영향을 미칩니다.

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "홈",
      "item": "https://alejandrorioja.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "블로그",
      "item": "https://alejandrorioja.com/blog/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "AI 엔진을 위한 Schema 마크업",
      "item": "https://alejandrorioja.com/blog/schema-markup-for-ai-engines-the-types-that-punch-above-their-weight/"
    }
  ]
}

이것은 대부분의 사이트가 단일 템플릿 편집으로 추가할 수 있는 10분 구현입니다. CMS 레이아웃에 추가하면 모든 페이지가 자동으로 받습니다.

2026년에 건너뛰는 타입

GEO를 위해 시간을 투자하지 않는 schema 타입의 비완전 목록:

• Product — e-커머스에 관련되며, 정보 사이트에는 해당 없음
• Event — 이벤트 비즈니스에 유용(Pickleland에서 사용), 다른 곳에서는 무관
• Recipe — 틈새
• JobPosting — 구인 게시판인 경우에만
• Review/AggregateRating — Google은 아직 리치 결과에 사용하지만 AI 엔진은 자체 보고된 평점에 회의적
• SpeakableSpecification — 음성에 이론적으로 흥미롭지만 대부분의 AI 엔진이 실제로 지원하지 않음

패턴: 타입이 실제 콘텐츠를 이산적이고 인용 가능한 단위로 직렬화하지 않으면 GEO 지표를 움직이지 않습니다. 모델이 깔끔하게 추출할 수 있는 구조화된 데이터로 이미 말하고 있는 것을 재포맷하는 타입을 고수하세요.

게시 전 schema 유효성 검사

항상 사용하는 두 가지 도구:

1. Google’s Rich Results Test — search.google.com/test/rich-results. Google의 리치 결과 기능 적격성을 확인하고 구문 오류를 발견합니다.
2. Schema.org Validator — validator.schema.org. Google 도구보다 더 허용적; Google이 무시하는 구조적 문제를 발견합니다.

내가 사용하는 워크플로우: 페이지에 추가하기 전에 JSON-LD를 유효성 검사기에 붙여넣습니다. 오류를 수정합니다. 그런 다음 페이지에 추가하고 라이브 URL에서 Rich Results Test를 실행합니다. 이렇게 하면 몇 달 동안 발견되지 않은 채 남아있는 깨진 마크업 게시를 방지합니다.

일반적인 실수: 여러 @type 블록을 별도의 <script> 태그에 넣는 것은 잘 작동하지만, 단일 블록 내에 관련 없는 타입을 중첩하면 유효성 검사 실패가 발생합니다. 각 타입을 자체 script 태그에 유지하세요.

운영자의 결론

FAQPage와 HowTo는 내가 게시하는 모든 정보 페이지에 추가하는 두 가지 타입입니다. 잘 작성하는 데 20~40분이 걸리고 AI 엔진이 직접 사용할 수 있는 구조화된 인용 표면적을 만듭니다. Article/BlogPosting, Person, Organization, BreadcrumbList는 기본 요건 — 한 번 템플릿에 통합하고 잊어버리세요. 이 다섯 가지를 마스터하기 전까지 나머지는 모두 노이즈입니다.