main-logo

검색엔진과 AI가 우리 페이지를 더 정확히 이해하도록 돕는 방법

프론트엔드 개발자가 알아야 할 SEO/GEO 네 번째 이야기, 구조화 데이터 실전 가이드: JSON-LD로 검색엔진과 AI에게 맥락 전달하기

profile
zurang23
2026년 05월 17일 · 0 분 소요

들어가며

이번 편을 준비하면서 꽤 의미 있는 문서가 하나 나왔어요. 2026년 5월 15일, Google Search Central에서 "Optimizing your website for generative AI features on Google Search"라는 공식 가이드를 발행했어요.

이 문서에서 Google이 명확히 한 핵심 메시지가 있어요.

"AEO"나 "GEO"라는 용어가 온라인에서 사용되고 있지만, Google Search의 관점에서 AI 검색 최적화는 검색 경험 최적화이며, 따라서 여전히 SEO다.

이건 이 시리즈에서 계속 얘기해온 방향과 맞닿아 있어요. SEO가 죽고 GEO가 대체한다는 게 아니라, GEO는 SEO의 확장이라는 거예요. SEO 없이는 GEO도 없어요. Google의 AI 기능(AI Overviews, AI Mode)은 기존 검색 인덱스에서 페이지를 가져와서(RAG) 응답을 생성하거든요. 인덱싱되지 않으면 AI 노출도 없어요.

그래서 이번 편에서 다루는 구조화 데이터도 같은 맥락에서 봐야 해요. 구조화 데이터는 AI 검색에 필수가 아니에요 — Google도 이번 가이드에서 그렇게 말했어요. 하지만 SEO 전체 전략의 일부로서 리치 결과를 얻고, 검색엔진과 AI가 페이지를 더 정확히 이해하도록 돕는 데는 확실히 가치가 있어요.

 

 

JSON-LD란 무엇인가

구조화 데이터의 세 가지 형식

구조화 데이터를 마크업하는 형식은 세 가지가 있어요 — JSON-LD, Microdata, RDFa. 이 중에서 Google이 공식적으로 권장하는 형식은 JSON-LD예요.

JSON-LD가 권장되는 이유는 명확해요. HTML 구조와 완전히 분리된 <script> 태그 안에 넣기 때문에, 기존 HTML을 건드리지 않고도 구조화 데이터를 추가할 수 있어요. Microdata나 RDFa는 HTML 속성에 직접 마크업을 섞어야 해서 유지보수가 어렵고 오류가 생기기 쉽거든요. 

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "SEO 가이드",
  "author": { "@type": "Person", "name": "GEONIQ" }
}
</script>

 

구조화 데이터의 역할을 정확히 이해하기

구조화 데이터에 대해 먼저 정확히 짚고 갈 게 있어요.

검색 순위를 직접 올려주지 않아요. Google이 여러 차례 확인한 사실이에요. 구조화 데이터의 역할은 검색 결과에 리치 결과(별점, 가격, 이미지, 빵부스러기 등)를 표시할 수 있게 해주는 거예요. 리치 결과가 표시되면 클릭률(CTR)이 올라가고, 그게 간접적으로 SEO에 도움이 되는 구조예요. Nestlé의 사례에 따르면, 리치 결과로 표시된 페이지가 일반 결과 대비 82% 높은 클릭률을 기록했어요(Google Search Central 사례 연구).

AI 검색에 필수는 아니에요. Google의 최신 가이드에서 명시한 내용이에요 — "Structured data isn't required for generative AI search... However, it's a good idea to continue using it as part of your overall SEO strategy." 구조화 데이터를 넣었다고 AI Overviews에 더 잘 나오는 건 아니지만, SEO 전반의 퀄리티를 높이는 데 도움이 되고, 그게 결국 AI 노출의 기반이 되는 거예요.

그렇다고 안 해도 되는 건 아니에요. 구조화 데이터는 검색엔진에게 "이 페이지에 뭐가 있는지"를 가장 명확하게 전달하는 방법이에요. 리치 결과를 통한 CTR 향상은 여전히 강력한 SEO 수단이고, 잘 구조화된 데이터는 AI가 페이지의 사실 관계를 파악하는 데도 참고할 수 있어요.

정리하면: 구조화 데이터는 SEO의 도구이고, 좋은 SEO가 곧 AI 검색의 기반이에요. "AI를 위한 특별한 마크업"이 아니라, "검색 전체를 위한 기본기"로 접근하는 게 맞아요.

 

Article — 블로그와 뉴스 페이지의 기본

블로그 글이나 뉴스 기사를 작성한다면, Article 스키마가 가장 기본이에요. Google은 이 스키마를 통해 검색 결과에 큰 이미지, 헤드라인, 작성자 정보를 표시할 수 있어요.

필수 속성과 권장 속성

Google이 요구하는 필수 속성은 headline, datePublished, author예요. image는 필수는 아니지만, 리치 결과에 큰 이미지로 표시되려면 포함하는 게 좋아요.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "프론트엔드 개발자를 위한 SEO 가이드",
  "image": "https://example.com/images/seo-guide.jpg",
  "datePublished": "2026-05-01",
  "dateModified": "2026-05-15",
  "author": {
    "@type": "Person",
    "name": "GEONIQ",
    "url": "https://geoniq.ai"
  },
  "publisher": {
    "@type": "Organization",
    "name": "pxd XE Group",
    "logo": {
      "@type": "ImageObject",
      "url": "https://tech.pxd.co.kr/_next/image?url=%2Fimages%2Fxegroup_tech_logo_light.png&w=1080&q=50"
    }
  },
  "description": "프론트엔드 개발자가 알아야 할 SEO와 GEO의 핵심 요소를 정리합니다."
}
</script>
 

실무 포인트

headline은 110자 이내 — Google 리치 결과 표시 제한 때문에 110자를 넘으면 잘릴 수 있어요.

dateModified는 반드시 넣기 — 3편에서 다뤘던 콘텐츠 최신성과 직접 연결되는 부분이에요.

author.url을 포함하기 — Google의 E-E-A-T(경험, 전문성, 권위성, 신뢰성) 관점에서, 저자가 누구인지 확인할 수 있는 URL을 포함하는 게 좋아요.

Next.js에서 구현하기

Next.js App Router 기반이라면 페이지 컴포넌트에서 JSON-LD를 직접 삽입할 수 있어요.

// app/posts/[slug]/page.tsx
export default function PostPage({ params }: { params: { slug: string } }) {
  const post = getPost(params.slug);
  
  const jsonLd = {
    '@context': 'https://schema.org',
    '@type': 'Article',
    headline: post.title,
    image: post.thumbnail,
    datePublished: post.createdAt,
    dateModified: post.updatedAt,
    author: {
      '@type': 'Person',
      name: post.author.name,
      url: post.author.url,
    },
  };

  return (
    <>
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd) }}
      />
      <article>
        <h1>{post.title}</h1>
        {/* 본문 */}
      </article>
    </>
  );
}
 

구조화 데이터에 포함된 정보가 실제 페이지에 보이는 내용과 일치해야 해요. 페이지에 없는 정보를 JSON-LD에만 넣으면 Google 가이드라인 위반이에요.

 

Product — 이커머스와 상품 페이지

상품을 판매하는 페이지라면 Product 스키마가 핵심이에요. 가격, 재고 상태, 별점이 검색 결과에 직접 표시될 수 있어요.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "무선 키보드 MK-200",
  "image": "https://example.com/images/mk200.jpg",
  "description": "블루투스 5.0 지원, 충전식 무선 키보드",
  "brand": { "@type": "Brand", "name": "TechBrand" },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/products/mk200",
    "priceCurrency": "KRW",
    "price": "89000",
    "availability": "https://schema.org/InStock",
    "priceValidUntil": "2026-12-31"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.5",
    "reviewCount": "127"
  }
}
</script>

offers는 필수 — 가격 정보가 없으면 Product 리치 결과가 표시되지 않아요.

aggregateRating — 별점이 검색 결과에 보이면 CTR이 크게 올라가요. 다만 실제 리뷰 데이터를 기반으로 해야 해요.

참고로 Google의 AI 가이드에서는 이커머스 사이트의 경우 구조화 데이터와 함께 Merchant Center 피드와 Google Business Profile도 정비하라고 권장하고 있어요. AI 응답에 상품 정보가 포함될 수 있는데, 이런 피드 데이터가 그 원천이 되거든요.

 

BreadcrumbList — 사이트 계층 구조 전달

BreadcrumbList는 페이지가 사이트 구조 안에서 어디에 위치하는지를 알려주는 스키마예요. 검색 결과에서 URL 대신 "홈 > 카테고리 > 하위 카테고리" 형태의 빵부스러기 경로가 표시돼요.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "홈", "item": "https://example.com" },
    { "@type": "ListItem", "position": 2, "name": "블로그", "item": "https://example.com/blog" },
    { "@type": "ListItem", "position": 3, "name": "SEO 가이드" }
  ]
}
</script>
 

구조가 명확한 사이트라는 신뢰감을 주고, 사용자가 검색 결과에서 페이지의 맥락을 바로 파악할 수 있어요.

 

HowTo — 단계별 가이드 페이지

단계별 절차를 설명하는 콘텐츠라면 HowTo 스키마를 고려할 수 있어요.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "Next.js 프로젝트에 JSON-LD 추가하는 방법",
  "step": [
    { "@type": "HowToStep", "name": "JSON-LD 객체 생성", "text": "페이지 컴포넌트에서 구조화 데이터 객체를 정의합니다." },
    { "@type": "HowToStep", "name": "script 태그에 삽입", "text": "type='application/ld+json'으로 script 태그를 추가합니다." },
    { "@type": "HowToStep", "name": "Rich Results Test로 검증", "text": "Google의 Rich Results Test에서 정상 인식 여부를 확인합니다." }
  ]
}
</script>
 

알아둬야 할 제한 사항 — 2023년 8월 Google이 HowTo 리치 결과를 모바일에서 제거했고, 이후 데스크톱에서도 제거되어 현재는 검색 결과에 표시되지 않아요. 다만 FAQPage와 마찬가지로, 스키마 자체는 검색엔진과 AI가 콘텐츠 구조를 이해하는 데 참고할 수 있어요.

 

Organization과 WebSite — 사이트 전체를 대표하는 스키마

페이지 단위가 아니라 사이트 전체에 대한 정보를 전달하는 스키마도 있어요. 홈페이지에 한 번만 넣으면 돼요.

<!-- Organization -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "pxd XE Group",
  "url": "https://tech.pxd.co.kr",
  "logo": "https://tech.pxd.co.kr/logo.png",
  "sameAs": ["https://github.com/pxd-xe-group"]
}
</script>

<!-- WebSite (사이트링크 검색창) -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "url": "https://example.com",
  "potentialAction": {
    "@type": "SearchAction",
    "target": "https://example.com/search?q={search_term_string}",
    "query-input": "required name=search_term_string"
  }
}
</script>
 

 

FAQPage — 리치 결과는 끝났지만, AI 인용 신호로는 오히려 올라가는 중

3편에서 FAQPage 스키마를 다루면서 "리치 결과는 사실상 끝났다"고 했었는데, 2026년 5월 7일부로 공식 종료됐어요. 6월에는 Rich Results Test에서 FAQ 지원이 제거되고, 8월에는 Search Console API에서도 삭제될 예정이에요.

타임라인을 정리하면 이래요.

  • 2019년: FAQ Schema 출시
  • 2023년 8월: 정부·의료 등 고신뢰 사이트만 남기고 제거
  • 2026년 5월 7일: SERP에서 리치 결과 완전 종료
  • 2026년 6월: Rich Results Test 도구에서 FAQ 검증 제거 예정
  • 2026년 8월: Search Console 리포트 + API 지원 종료 예정

그런데 중요한 건, Schema 자체는 죽지 않았다는 거예요.

FAQPage 스키마 마크업은 여전히 유효해요. 시각적 리치 결과는 사라졌지만, AI 검색 서비스들이 Q&A를 추출할 때 FAQPage 구조화 데이터를 파싱하고 있다는 분석이 나오고 있어요. ALM Corp의 분석에 따르면, FAQPage 스키마가 있는 페이지는 AI가 Q&A를 추출할 때 유리하다는 분석이 나오고 있어요.

이건 이번 시리즈의 메시지와도 정확히 맞닿아 있어요. SEO 관점에서만 보면 "리치 결과 없으니 빼도 된다"가 되지만, GEO 관점까지 함께 보면 "AI 인용 신호로서의 가치가 오히려 올라가고 있으니 유지하는 게 맞다"가 돼요. SEO와 GEO를 따로 보면 놓치고, 같이 봐야 판단이 정확해지는 대표적인 사례예요.

실무 권장: 기존에 FAQPage 스키마를 넣어둔 사이트는 그대로 유지하세요. 새로 구현할 때도 Q&A 구조의 콘텐츠가 있다면 FAQPage 스키마를 넣는 걸 권장해요. 리치 결과를 기대하고 넣는 게 아니라, 페이지 이해와 AI 인용을 돕는 신호로 활용하는 거예요.

 

검증 도구

구조화 데이터를 넣었으면 배포 전에 반드시 검증해야 해요.

Google Rich Results Test — 리치 결과 적격 여부를 확인하는 가장 기본적인 도구예요.

Schema.org Validator — JSON-LD 문법이 Schema.org 표준에 맞는지 확인할 수 있어요.

Google Search Console — 배포 후 실제 리치 결과 표시 여부와 오류를 모니터링할 수 있어요.

흔한 오류들

페이지에 없는 정보를 마크업한 경우 — JSON-LD에 가격이 89,000원이라고 했는데 페이지에 가격이 안 보이면 가이드라인 위반이에요.

필수 속성 누락 — Article에 author가 없거나, Product에 offers가 없으면 리치 결과가 표시되지 않아요. 부분 구현은 효과가 없어요.

JSON 문법 오류 — 쉼표 하나 빠지거나, 스마트 따옴표(" ")가 섞이는 것만으로도 전체 JSON-LD가 무시돼요.

 

정리 — 어떤 스키마를 어디에 넣을지

스키마 타입 적용 페이지 리치 결과 비고
Article 블로그, 뉴스 큰 이미지, 헤드라인, 작성자 headline 110자, dateModified 필수
Product 상품 페이지 가격, 별점, 재고 상태 Merchant Center 피드 병행 권장
BreadcrumbList 전체 페이지 URL 대신 경로 표시 사이트 구조 전달
HowTo 가이드, 튜토리얼 리치 결과 종료 스키마 자체는 AI 이해에 참고 가능
Organization 홈페이지 (1회) Knowledge Panel sameAs로 소셜 연결
WebSite 홈페이지 (1회) 사이트링크 검색창 SearchAction 포함
FAQPage Q&A 콘텐츠 페이지 리치 결과 종료 (2026.05) AI 인용 신호로 가치 상승 — 마크업 유지 권장

 

Google이 확인해준 것, 그리고 우리가 챙겨야 할 것

이번 Google 가이드가 나오면서, 시리즈에서 다뤄온 내용들의 위치가 좀 더 명확해졌어요.

Google은 AI 검색 기능이 기존 검색 인덱스를 기반으로 작동한다(RAG)고 공식 확인했어요. 그러면서 "콘텐츠를 AI용으로 별도로 재작성할 필요 없다", "청크 분할이 필요하지 않다"고 못 박았어요.

이건 "GEO를 위해 뭔가 특별한 걸 해야 한다"는 접근이 아니라, "SEO의 기본기를 제대로 하면 AI 검색에서도 자연스럽게 노출된다"는 의미예요.

다만 그렇다고 AI 검색 환경의 변화를 무시해도 된다는 건 아니에요. 사용자가 정보를 찾는 방식이 달라지고 있고, AI가 콘텐츠를 요약하고 인용하는 환경에서 "어떤 구조가 더 잘 이해되는가"를 고민하는 건 여전히 의미 있어요. GEO는 SEO를 대체하는 게 아니라, SEO 위에 쌓이는 확장이에요. SEO가 탄탄하지 않으면 GEO도 작동하지 않아요.

이 시리즈에서 다뤄온 것들 — robots.txt와 sitemap 정비, 명확한 헤딩 구조, 핵심이 앞에 오는 문단, 구조화 데이터 — 은 전부 SEO의 기본기예요. 그리고 Google이 이번에 확인해준 것처럼, 그 기본기가 곧 AI 검색의 기반이에요.

 

마치며

구조화 데이터는 "AI를 위한 특별한 마크업"이 아니에요. SEO 전략의 일부로서 리치 결과를 얻고, 검색엔진이 페이지를 더 정확히 이해하도록 돕는 도구예요. 그리고 좋은 SEO가 곧 AI 검색의 기반이라는 게 Google의 공식 입장이에요.

프론트엔드 개발자라면, Article과 BreadcrumbList부터 시작하는 걸 추천해요. 블로그나 콘텐츠 사이트에서 가장 보편적으로 쓰이고, 구현 난이도도 낮은 편이에요. 배포 전에 Rich Results Test로 검증하는 습관을 들이면 대부분의 실수는 잡을 수 있어요.

다음 편에서는 프론트엔드 개발자가 가장 익숙한 영역인 웹 성능 이야기를 해볼게요. Core Web Vitals가 검색 노출에 실제로 어떤 영향을 미치는지, LCP·INP·CLS를 챙기는 게 SEO/GEO 양쪽 모두에서 왜 중요한지 정리할 예정이에요.

 

참고 자료