AEO를 위한 구조화 데이터·스키마 가이드

AI가 한 페이지를 읽을 때 마주하는 첫 번째 문제는 의미의 모호함이다. 화면의 "삼성"이 회사인지 제품인지, "2026-06-04"가 발행일인지 수정일인지, 굵게 처리된 문장이 질문인지 답인지를 본문 텍스트만으로는 확정하기 어렵다. 구조화 데이터(structured data)는 이 모호함을 없앤다. 페이지의 엔티티·속성·관계를 기계가 읽는 형식으로 명시적으로 선언해, AI가 "이것은 Article이고, 저자는 누구이며, 이 블록은 질문-답변이다"라고 확정적으로 이해하게 만든다. 이 글은 AEO 관점에서 schema.org 마크업이 AI 인용에 주는 영향과 적용법을 정리한다.

구조화 데이터가 AI 이해에 작동하는 원리

구조화 데이터는 schema.org ↗가 정의한 공통 어휘로 페이지의 의미를 기술하는 코드다.^[3] 사람은 문맥과 시각적 배치로 "이 부분은 가격, 저건 저자"라고 추론하지만, 기계는 그 추론을 보장받지 못한다. 마크업은 그 추론을 추론이 아닌 선언으로 바꾼다.

여기서 원인-영향-행동의 사슬이 분명해진다. 원인은 AI가 페이지의 의미를 명시적 신호 없이는 확정하기 어렵다는 점이다. 영향은, 의미가 모호한 페이지일수록 AI가 잘못 해석하거나 인용 단위를 제대로 떼어내지 못한다는 것이다. 행동은 명확하다. 핵심 엔티티와 단위를 schema.org 타입으로 마크업해 기계가 읽을 신호를 본문과 정렬하는 것이다.

구글 구조화 데이터 개요 ↗는 이 신호를 읽는 방식으로 JSON-LD를 권장한다.^[1] JSON-LD는 본문 HTML과 분리된 <script type="application/ld+json"> 블록에 의미 정보를 담는 형식이라, 화면 콘텐츠를 건드리지 않고도 마크업을 관리할 수 있다. 다만 구조화 데이터는 본문 구조를 대체하지 않는다. 추출 가능한 콘텐츠 구조가 먼저 갖춰진 위에 얹는 보조 신호라는 점이 중요하다.

AEO에 효용이 큰 핵심 스키마 타입

모든 타입을 다 적용할 필요는 없다. AEO 관점에서 효용이 큰 네 가지를 우선한다.

Article은 글의 저자·발행일·수정일을 명시해 AI가 출처의 신선도와 권위를 판단하게 한다. FAQPage는 질문-답변 쌍을 명시적 단위로 드러내, 본문의 Q&A 구조와 정렬될 때 추출 가능성을 높인다. 단 구글 FAQ 마크업 가이드 ↗는 화면에 실제로 보이는 Q&A만 마크업하도록 요구한다.^[2]

Organization은 발행 주체가 누구인지를 선언한다. AI가 출처의 정체성을 식별하고 권위를 가늠할 때 발행 주체 정보는 핵심 단서이며, Organization 스키마 ↗의 sameAs 속성으로 공식 웹사이트·SNS 채널을 연결하면 엔티티 식별이 명확해진다.^[4] 이 엔티티 신호를 더 깊이 다루는 방법은 엔티티·지식그래프 최적화에서 이어 볼 수 있다. Product는 커머스 페이지에서 제품명·가격·평점 같은 속성을 명시해 비교형 질의에 대응한다.

JSON-LD 적용 예시

아래는 한 글에 Article과 발행 Organization을 함께 선언한 최소 예시다.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "AEO를 위한 구조화 데이터·스키마 가이드",
  "datePublished": "2026-06-04",
  "dateModified": "2026-06-04",
  "author": { "@type": "Organization", "name": "WikiAP Editorial" },
  "publisher": {
    "@type": "Organization",
    "name": "WikiAP",
    "sameAs": ["https://example.com"]
  }
}

FAQPage는 본문의 질문-답변을 그대로 옮긴다. 값이 화면 텍스트와 다르면 안 된다.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "구조화 데이터를 넣으면 AI 인용이 보장되나요?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "보장되지 않습니다. 인용 여부는 본문의 관련성·정확성·구조에 더 크게 좌우됩니다."
    }
  }]
}

두 예시의 공통 규칙은 하나다. 마크업 값은 본문에 실제로 존재하는 텍스트와 일치해야 한다. 화면에 없는 내용을 스키마에만 넣으면 구글 가이드라인 위반이며, 본문과 어긋난 값은 신뢰 신호를 오히려 깎는다.

스키마가 인용을 보장하지 않는 이유

구조화 데이터를 둘러싼 가장 흔한 오해는 "스키마만 넣으면 AI가 인용한다"는 기대다. 실제로는 그렇지 않다. 마크업은 의미를 명시할 뿐, 콘텐츠의 관련성·정확성·깊이를 만들어 주지 않는다.

GEO 논문(Aggarwal et al., 2024) ↗이 가시성 향상 요인으로 짚은 것은 인용·통계·출처 같은 본문 내부의 근거 밀도였다.^[5] 즉 가시성을 끌어올리는 핵심은 본문이고, 구조화 데이터는 잘 쓰인 본문의 의미를 기계에 또렷이 전달하는 역할에 가깝다. 따라서 적용 순서는 분명하다. 먼저 추출 가능한 본문 구조를 갖추고, 그 위에 Article·FAQPage·Organization·Product를 정렬해 얹은 뒤, 구글 리치 결과 테스트나 스키마 검증 도구로 오류를 확인한다. 마크업과 본문이 어긋나지 않는지 점검하는 것이 마지막이자 가장 중요한 단계다.

정리

구조화 데이터는 AI가 페이지의 의미를 모호함 없이 읽게 하는 명시적 신호다. JSON-LD로 구현하며, AEO에서는 Article(신선도·저자), FAQPage(질문-답변 단위), Organization(발행 주체·엔티티), Product(제품 속성)가 효용이 크다. 다만 스키마는 본문 구조를 대체하지 않는 보조 장치이고, 화면에 없는 내용을 마크업하면 가이드라인 위반이 된다. 마크업 값은 본문의 실제 텍스트와 일치해야 하며, 정확성과 자기완결성이 깨지면 신뢰 신호로서의 효력을 잃는다. 결국 효과적인 스키마 적용은 잘 쓰인 본문 위에 그 의미를 또렷이 선언하는 일이다.