PIVOT LABS테크

구조화 데이터(JSON-LD)로 AI가 인용하는 페이지 만들기

리치 결과는 저물고, 구조화 데이터의 가치는 "AI·검색이 읽는 사실"로 옮겨갔다. JSON-LD로 엔티티(@graph·@id·sameAs)를 연결해 AI가 인용하는 페이지를 만드는 실무 가이드.

요약

구조화 데이터(structured data) 는 페이지의 의미를 기계가 읽을 수 있게 표기하는 방법이다. 사람이 보는 화면은 그대로 두고, "이 문장은 회사명, 이 숫자는 가격, 이 블록은 질문과 답"이라는 사실의 라벨을 함께 붙인다.
표준 어휘는 Schema.org, 권장 형식은 JSON-LD(<script type="application/ld+json">)다. 마이크로데이터·RDFa와 달리 마크업이 콘텐츠와 분리돼 있어 관리가 쉽다.
가치가 이동했다. 과거엔 검색 결과의 "리치 결과(별점·FAQ 아코디언 등)"가 목적이었지만, FAQ·HowTo 리치 결과는 이제 표시되지 않는다. 대신 구조화 데이터는 검색·AI 답변 엔진이 페이지의 사실을 정확히 이해하는 근거로서 더 중요해졌다.
핵심은 "낱개 표기"가 아니라 "엔티티 연결"이다. 회사·저자·글을 각각의 엔티티로 정의하고 서로 참조하면, 검색·AI가 브랜드를 하나의 엔티티로 인식해 인용 정확도가 올라간다.
한 번 넣고 끝이 아니다. 값이 화면·다른 페이지와 어긋나면 오히려 신뢰를 깎는다. 작성 기준과 페이지 간 싱크가 완성도를 가른다.
SEO 순위 스위치가 아니다. Google은 구조화 데이터가 순위를 직접 올리지 않는다고 밝혔다. 이해·표시를 돕는 보완재이며, 특정 인용·순위를 보장하지 않는다.

이 글의 리치 결과 지원 현황·정책은 시점에 따라 바뀐다. 도입 전 각 항목을 Google 검색 구조화 데이터 문서와 Schema.org에서 최신본으로 확인한다.

1. 서론 — 리치 결과에서 "AI가 읽는 팩트"로

1.1 무엇이 달라졌나

구조화 데이터의 초기 동기는 리치 결과였다. FAQ 아코디언, How-to 단계, 별점 같은 요소를 검색 결과에 얹어 클릭률을 높이는 것이다. 그런데 Google은 이 표시를 단계적으로 줄였다.

How-to 리치 결과: 2023년 Google이 표시를 중단해 현재 검색 결과에 나타나지 않는다.
FAQ 리치 결과: 2023년 권위 있는 정부·보건 사이트로 제한된 뒤, 일반 사이트에서는 사실상 표시되지 않는다.
그 밖에도 여러 유형이 단계적으로 표시 중단됐다. 현재 지원 목록은 Google 검색 갤러리에서 확인한다(자주 바뀐다).

중요한 것은 이 변화가 "표시(display)"의 변화이지 순위(ranking)의 변화가 아니라는 점이다. Google은 리치 결과 중단이 순위에 영향을 주지 않는다고 밝혔다. 그리고 스키마 타입 자체는 여전히 유효하며, 검색·AI 시스템이 이를 파싱한다.

1.2 구조화 데이터의 진짜 가치

리치 결과가 사라져도 구조화 데이터를 계속 쓰는 이유는, 그 본질이 "기계가 읽는 사실" 이기 때문이다. 페이지를 사람이 보는 텍스트가 아니라 엔티티(회사·제품·글쓴이)와 관계(가격·발행일·저자) 로 명시하면, 검색 엔진과 AI 답변 엔진이 내용을 오해 없이 추출한다.

AI 검색 시대에 이 성격은 더 중요해졌다. AI가 답할 때 인용할 근거를 명확한 사실 형태로 제공하는 것은, PIVOT이 말하는 GEO(생성형 엔진 최적화) 의 기술적 토대 중 하나다.

2. JSON-LD 기본

2.1 JSON-LD란

JSON-LD(JSON for Linked Data) 는 JSON 문법으로 Schema.org 어휘를 표기하는 형식이다. Google이 권장하는 형식이며, HTML 마크업 사이에 값을 끼워 넣는 마이크로데이터와 달리 콘텐츠와 분리된 하나의 스크립트 블록으로 관리한다.

@context: 어휘 출처(보통 https://schema.org).
@type: 대상의 종류(Organization, Article 등).
나머지 키: 해당 타입의 속성(property).

2.2 어디에 넣나

<script type="application/ld+json"> 안에 넣는다. <head>·본문 어디든 되고, 페이지당 여러 개를 둘 수 있다.

HTML

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "PIVOT CREATIVE",
  "url": "https://pivot-inc.com",
  "logo": "https://pivot-inc.com/logo.png"
}
</script>

2.3 Schema.org 어휘

타입과 속성의 표준 사전이 Schema.org 다. 각 타입 문서에서 사용할 수 있는 속성, 필수/권장 여부, 예시를 확인한다. Google이 리치 결과로 지원하는 타입은 별도로 검색 갤러리에 정리돼 있다.

3. 핵심 스키마 타입

무엇을 마크업할지는 페이지의 성격이 정한다. 아래는 대부분의 사이트에 공통으로 쓰이는 것부터 정리했다.

타입	언제 쓰나	현재 리치 결과
`Organization`	사이트 전역(회사 신원)	지식 패널 등
`WebSite`	사이트 전역(사이트명·검색)	사이트명·검색창
`BreadcrumbList`	모든 하위 페이지	경로 표시
`Article`	블로그·뉴스·가이드 글	기사 표시
`FAQPage`	질문·답변 블록	표시 중단(파싱은 유효)
`Product`·`Review`·`AggregateRating`	상품·후기	상품·별점 표시
`LocalBusiness`	오프라인 지점	지역 정보

3.1 Organization / WebSite — 사이트 신원

사이트 전역에 한 번 선언해 "이 사이트는 누구인가"를 기계에 알린다. AI가 브랜드를 하나의 엔티티로 인식하는 출발점이다.

JSON

{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "PIVOT CREATIVE",
  "url": "https://pivot-inc.com"
}

3.2 Article / BreadcrumbList — 콘텐츠 글

가이드·아티클 페이지에는 Article 로 제목·저자·발행일을 명시한다. 발행일·수정일은 최신성 신호로도 쓰인다.

JSON

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "구조화 데이터(JSON-LD)",
  "author": { "@type": "Organization", "name": "PIVOT CREATIVE" },
  "datePublished": "2026-09-16",
  "dateModified": "2026-09-16"
}

3.3 FAQPage — 리치 결과는 사라졌지만 여전히 유효

FAQ 리치 결과 표시는 중단됐지만, FAQPage 스키마는 질문–답변을 명확한 쌍으로 제공한다. AI 답변 엔진이 Q&A 구조를 추출하기 좋은 형태이므로, 실제로 페이지에 보이는 FAQ가 있다면 계속 마크업할 가치가 있다.

JSON

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "GEO란 무엇인가요?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "생성형 AI가 답변할 때 브랜드가 출처로 인용되도록 최적화하는 것입니다."
    }
  }]
}

단, FAQPage 는 페이지에 실제로 보이는 FAQ 에만 쓴다. 화면에 없는 질문을 마크업만으로 채우는 것은 정책 위반이다.

3.4 Product·Review·LocalBusiness — 해당 시

상품 페이지는 Product+Offer+AggregateRating, 지점 페이지는 LocalBusiness 를 쓴다. 별점·후기는 실제 후기가 있을 때만 마크업한다.

4. 엔티티로 연결하기 — 지식 그래프 관점

여기서부터가 "표기"와 "설계"를 가른다. 검색·AI는 페이지를 낱개 문서가 아니라 엔티티(회사·저자·글) 사이의 관계 그래프로 이해한다. 같은 엔티티를 여러 번 다르게 적으면 그래프가 흐려지고, 한 번 정의해 재참조하면 또렷해진다.

4.1 @graph 로 한 페이지의 엔티티를 묶기

한 페이지에는 보통 여러 엔티티가 있다(회사 + 사이트 + 글). 이들을 흩어진 스크립트로 두지 말고 @graph 배열 하나로 묶어 관계를 드러낸다.

JSON

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization", "@id": "https://pivot-inc.com/#org",
      "name": "PIVOT CREATIVE", "url": "https://pivot-inc.com",
      "sameAs": ["https://www.linkedin.com/company/pivot-creative"] },
    { "@type": "WebSite", "@id": "https://pivot-inc.com/#site",
      "url": "https://pivot-inc.com", "publisher": { "@id": "https://pivot-inc.com/#org" } },
    { "@type": "Article", "@id": "https://pivot-inc.com/labs/json-ld#article",
      "headline": "구조화 데이터(JSON-LD)",
      "author": { "@id": "https://pivot-inc.com/#org" },
      "isPartOf": { "@id": "https://pivot-inc.com/#site" },
      "datePublished": "2026-09-16" }
  ]
}

4.2 @id 로 엔티티를 서로 참조

위 예시의 핵심은 @id 다. 엔티티마다 고유 URI(#org, #site, #article)를 부여하고, 다른 곳에서는 { "@id": "…#org" } 로 가리키기만 한다.

근거: 회사 정보를 글마다 반복해 적으면 값이 어긋나기 쉽다. @id 로 한 번 정의하고 참조하면 단일 출처가 되어 모순이 없고, 기계가 "이 글의 저자 = 그 회사"를 명시적으로 잇는다.
방향성: #org·#site 같은 사이트 공통 엔티티는 전역에서 한 번 정의하고, 각 페이지는 참조로 연결한다.

4.3 sameAs·저자·발행자 — "누가 말했나"를 고정

AI·검색은 출처의 신뢰도를 따진다. 콘텐츠를 신뢰할 수 있는 엔티티에 묶는 것이 인용 관점에서 특히 중요하다.

sameAs: 우리 엔티티를 외부의 권위 있는 프로필(LinkedIn·Wikidata·공식 SNS 등)에 연결해 "이 브랜드가 그 브랜드"임을 못 박는다(엔티티 명확화).
author·publisher: 글이 누가 쓰고 누가 발행했는지를 엔티티로 명시한다. 익명 문서보다 신뢰 신호가 강하다.
방향성: 회사·대표 저자·주요 서비스는 sameAs 로 외부 신뢰 출처에 연결하고, 모든 콘텐츠에 author/publisher 를 붙여 책임 주체를 고정한다.

5. 페이지에 넣기 — 정적 HTML에서 자동화까지

마크업을 "어떻게 심느냐"는 규모에 따라 다르다. 원리는 하나다. 값은 한 곳에서 만들고, 화면에 보이는 것과 같아야 한다.

5.1 정적 페이지 — script 한 줄

페이지 수가 적으면 <script type="application/ld+json"> 를 직접 넣는 것으로 충분하다. 문법은 Schema.org Markup Validator 로 검증한다.

5.2 값은 한 곳에서 — 단일 소스 헬퍼

페이지가 늘면 손으로 반복 작성하는 순간 값이 어긋난다. 타입별 객체를 만드는 작은 헬퍼로 모아, 제목·날짜·URL이 한 소스에서 나오게 한다.

// 프레임워크와 무관한 순수 함수 — 값의 단일 소스
export const articleLd = (a: { title: string; date: string; url: string }) => ({
  '@context': 'https://schema.org',
  '@type': 'Article',
  '@id': `${a.url}#article`,
  headline: a.title,
  author: { '@id': 'https://pivot-inc.com/#org' },
  datePublished: a.date,
});

5.3 프레임워크에서 자동 주입 (예: Next.js)

서버 렌더링 프레임워크에서는 위 헬퍼가 만든 객체를 JSON.stringify 해 스크립트로 출력한다. 아래는 Next.js(App Router) 예시이며, 다른 프레임워크도 "서버에서 문자열로 출력"이라는 원리는 같다.

TSX

// 서버에서 렌더 — 헬퍼가 만든 객체를 문자열로 출력
export default function Page() {
  const jsonLd = articleLd({ title: '구조화 데이터(JSON-LD)', date: '2026-09-16', url: 'https://pivot-inc.com/labs/json-ld' });
  // '<'(특히 </script>) 이스케이프 — 값에 외부·사용자 입력이 섞여도 스크립트가 깨지지 않게
  const json = JSON.stringify(jsonLd).replace(/</g, '\\u003c');
  return (
    <>
      <script type="application/ld+json" dangerouslySetInnerHTML={{ __html: json }} />
      {/* 본문 */}
    </>
  );
}

JSON.stringify 결과에 </script> 같은 < 가 들어가면 스크립트 태그가 조기 종료돼 마크업이 깨지거나 XSS로 이어질 수 있다. 값에 본문·사용자 입력이 섞인다면 위처럼 < 를 < 로 치환해 출력한다.

6. 작성 기준·거버넌스

구조화 데이터의 신뢰는 "보이는 것·다른 페이지와 값이 같다" 에서 나온다. 여기가 무너지면 마크업이 오히려 마이너스다.

6.1 작성 기준 — 정확·최소·최신

정확(보이는 것과 일치): 페이지에 실제로 보이는 내용만 마크업한다. 화면 텍스트와 JSON-LD 값이 같아야 한다. 숨긴 콘텐츠·없는 FAQ·거짓 별점은 정책 위반이며 수동 조치(manual action) 대상이 될 수 있다.
최소(과잉 마크업 지양): 페이지 목적에 맞는 타입만 쓴다. 관련 없는 타입을 욱여넣으면 관리 부담과 오류만 는다.
최신(dateModified): 내용이 바뀌면 dateModified 를 갱신한다. 최신성 신호이자 싱크의 일부다.
필수 속성 우선: 각 타입의 필수/권장 속성을 먼저 채우고(검색 갤러리 기준), 나머지는 가치 있을 때만 추가한다.

6.2 페이지 간 싱크 — 공통 엔티티는 한 곳에서

가장 흔한 사고는 같은 정보가 여러 곳에서 어긋나는 것이다. 회사명·로고·URL·저자 같은 공통 엔티티가 수십 페이지에 하드코딩돼 있으면, 하나를 바꿀 때 나머지가 옛 값으로 남아 엔티티가 둘로 갈린다(그래프 오염).

공통 엔티티는 전역 한 곳에서 생성: Organization·WebSite 는 공용 컴포넌트/헬퍼에서 만들고, 모든 페이지가 @id 로 참조한다. 페이지는 고유 값(제목·발행일)만 채운다.
화면과 스키마를 같은 출처에서: 제목·가격·설명 등은 화면 표시와 JSON-LD가 같은 변수/CMS 필드에서 파생되게 한다. "화면만 고치고 스키마는 안 고침"을 구조적으로 막는다.
전역 변경은 단일 소스만: 도메인 이전, 로고 교체 같은 변경은 한 곳만 고치면 전 페이지에 반영되도록 설계한다.

6.3 검증 도구

Google Rich Results Test: 페이지/코드가 어떤 리치 결과 자격을 갖는지 확인. → https://search.google.com/test/rich-results
Schema.org Markup Validator: 리치 결과와 무관하게 스키마 문법·구조 자체를 검증. → https://validator.schema.org/
Google Search Console: 배포 후 실제 색인에서의 인식·오류·적용 범위를 모니터링(향상된 표시 리포트).

7. AI 인용 관점 (GEO)

구조화 데이터가 AI 답변에 미치는 영향은 플랫폼마다 다르며, 아직 확정된 공식 수치는 없다. 현재까지 알려진 것은 이렇다.

Google(AI Overviews 포함): 구글은 구조화 데이터를 명시적으로 권장한다. 검색과 AI 답변이 같은 이해 시스템을 공유하므로, 정확한 스키마는 사실 추출의 근거가 된다.
일부 LLM(ChatGPT·Perplexity 등): JSON-LD를 구조로 파싱하기보다 보이는 텍스트 위주로 읽는다는 통제 실험 관찰도 있다. 즉 구조화 데이터만으로는 부족하고, 본문 자체가 명확하고 인용 가능한 형태여야 한다.
결론: 구조화 데이터는 "AI 인용 스위치"가 아니라 기계가 사실을 오해 없이 읽게 하는 토대다. 명확한 본문 + 정확한 스키마 + 엔티티 연결 + 최신성·권위 신호가 함께 갈 때 인용 가능성이 높아진다. 어떤 도구도 특정 인용을 보장하지 않는다(best-effort).

8. 구조화 데이터와 SEO — 역할 구분과 선택

많은 팀이 구조화 데이터를 "순위를 올리는 스위치"로 오해한다. 역할을 정확히 나눠야 투자 우선순위가 선다.

직접 순위 요소가 아니다: Google은 구조화 데이터가 순위를 직접 올리지 않는다고 밝혔다. 그것은 이해와 표시(리치 결과·엔티티 인식) 를 돕는다. 순위는 콘텐츠 품질·연관성·경험 신호가 결정한다.
역할이 겹쳐 보이는 것들의 구분:

요소	주 역할	스키마와의 관계
시맨틱 HTML(`h1`·`article` 등)	문서 구조	스키마의 토대 — 먼저 갖춘다
메타 태그(`title`·`description`)	검색 스니펫	별개 역할 — 둘 다 필요
Open Graph·Twitter Card	SNS 공유 미리보기	목적이 다름 — 중복 아님
JSON-LD 스키마	기계가 읽는 사실·리치결과·AI	위를 대체하지 않고 보완

선택 기준(우선순위):
- 콘텐츠·시맨틱 HTML 이 먼저다. 부실한 페이지에 스키마만 얹어도 효과가 없다.
- 그 위에 정확한 스키마로 사실을 명시한다.
- 같은 정보(제목·설명)를 메타·OG·스키마가 각각 가질 때는 한 소스에서 파생해 어긋남을 막는다.
AI/GEO 관점의 차이: 전통 SEO의 목표가 "링크 클릭"이라면, AI 인용의 목표는 "답변에 사실로 채택"이다. 그래서 명확한 문장·엔티티·최신성이 링크 지표보다 더 중요해질 수 있다.

9. 흔한 실수와 안티패턴

흔한 실수 / 안티패턴	문제	개선
화면만 수정하고 JSON-LD는 방치	값 불일치 → 무시·신뢰 하락	화면·스키마를 한 소스에서 파생
회사 정보를 페이지마다 하드코딩	값 어긋남·엔티티 분리	`@id`+공통 헬퍼로 단일 정의
구조화 데이터로 순위 오를 거라 기대	우선순위 왜곡	이해·표시 보조임을 이해, 콘텐츠 우선
리치 결과만 노리고 마크업	표시 중단 시 무의미	기계가 읽는 사실 관점으로 설계
안 보이는 콘텐츠·없는 FAQ 마크업	정책 위반·수동 조치	화면에 보이는 것만 표기
거짓 별점·후기	신뢰 훼손·제재	실제 데이터만
관련 없는 타입 남발	관리 부담·오류	페이지 목적에 맞는 타입만
스키마만 믿고 본문 방치	LLM엔 텍스트가 우선	본문을 명확·인용가능하게

실행 체크리스트

사이트 전역에 Organization·WebSite 를 한 번 선언했다
글/상품/지점 등 페이지 성격에 맞는 타입을 골랐다
공통 엔티티를 @id 로 정의하고 @graph·참조로 연결했다
sameAs·author·publisher 로 출처 주체를 고정했다
화면 표시와 JSON-LD가 같은 출처에서 나온다(페이지 간 싱크)
내용 변경 시 dateModified 를 갱신한다
시맨틱 HTML·콘텐츠를 먼저 갖추고 그 위에 스키마를 얹었다
Google Rich Results Test + Schema.org Validator 로 검증했다
Google Search Console 로 배포 후 인식/오류를 모니터링한다

참고 자료 (공식·표준 문서)

아래는 작성 시점 기준의 공식·표준 문서다. 구조화 데이터의 리치 결과 지원 범위는 자주 바뀌니 각 문서의 최신본을 확인한다.

Google 검색 — 구조화 데이터

구조화 데이터 개요developers.google.com/search/docs/appearance/structured-data/intro-structured-data 지원 기능 갤러리developers.google.com/search/docs/appearance/structured-data/search-gallery Google Rich Results Testsearch.google.com/test/rich-results Google Search Consolesearch.google.com/search-console/about HowTo·FAQ 리치 결과 변경 공지developers.google.com/search/blog/2023/08/howto-faq-changes

표준·검증

Schema.orgschema.org/Schema.org — Organization 타입schema.org/Organization Schema.org Markup Validatorvalidator.schema.org/

구현(Next.js)

Next.js — JSON-LD 가이드nextjs.org/docs/app/guides/json-ld

목록으로

구조화 데이터(JSON-LD)로 AI가 인용하는 페이지 만들기

요약

1. 서론 — 리치 결과에서 "AI가 읽는 팩트"로

1.1 무엇이 달라졌나

1.2 구조화 데이터의 진짜 가치

2. JSON-LD 기본

2.1 JSON-LD란

2.2 어디에 넣나

2.3 Schema.org 어휘

3. 핵심 스키마 타입

3.1 Organization / WebSite — 사이트 신원

3.2 Article / BreadcrumbList — 콘텐츠 글

3.3 FAQPage — 리치 결과는 사라졌지만 여전히 유효

3.4 Product·Review·LocalBusiness — 해당 시

4. 엔티티로 연결하기 — 지식 그래프 관점

4.1 @graph 로 한 페이지의 엔티티를 묶기

4.2 @id 로 엔티티를 서로 참조

4.3 sameAs·저자·발행자 — "누가 말했나"를 고정

5. 페이지에 넣기 — 정적 HTML에서 자동화까지

5.1 정적 페이지 — script 한 줄

5.2 값은 한 곳에서 — 단일 소스 헬퍼

5.3 프레임워크에서 자동 주입 (예: Next.js)

6. 작성 기준·거버넌스

6.1 작성 기준 — 정확·최소·최신

6.2 페이지 간 싱크 — 공통 엔티티는 한 곳에서

6.3 검증 도구

7. AI 인용 관점 (GEO)

8. 구조화 데이터와 SEO — 역할 구분과 선택

9. 흔한 실수와 안티패턴

실행 체크리스트

참고 자료 (공식·표준 문서)

프로젝트가있으신가요?

프로젝트가
있으신가요?