[2026 최신] 스키마 마크업을 통한 구조화 데이터 구현 방법 완벽 가이드 | 테라그로스

스키마 마크업, 왜 2026년에 다시 꺼내는 이야기냐면

솔직히 말하면, 스키마 마크업은 2020년대 초반에 한 번 유행이 지나갔던 주제다. 그땐 “JSON-LD만 박으면 리치 결과 뜬다”는 식의 단순한 가이드가 넘쳐났고, 실제로 그랬다. 근데 2024년 구글 헬프풀 콘텐츠 업데이트 이후로 스키마 생태계 자체가 완전히 뒤집혔다. HowTo 스키마 폐지(2023.09), FAQ 스키마 제한(2023.08), SpecialAnnouncement 폐지(2025.07)를 거치면서 “뭐든 박아넣으면 좋다”는 시대는 끝났다.

2026년 기준으로 이야기하자면, 이제 스키마는 두 가지 맥락에서 다시 중요해졌다. 첫째는 구글 AI Overviews와 Search Generative Experience에서 인용될 entity 기반 구조화 데이터 요구, 둘째는 ChatGPT Search·Perplexity 같은 생성형 검색엔진이 JSON-LD를 직접 크롤링해서 답변 출처로 쓴다는 점이다. 과거에는 리치 스니펫을 위한 장식이었다면 지금은 LLM에게 “이 페이지가 무엇에 관한 것인지”를 정확히 전달하는 커뮤니케이션 레이어로 바뀌었다.

우리 팀이 최근 6개월간 클라이언트 페이지에 스키마를 전면 재작업하면서 느낀 건, 스키마 작성 난이도는 떨어졌는데 전략 난이도가 올라갔다는 거다. 뭘 마킹하느냐보다 뭘 빼느냐가 중요해졌다.

2026년 기준, 반드시 알아야 할 스키마 현행 정책

본격적으로 구현 방법을 다루기 전에 이것부터 정리하고 가자. 블로그를 돌아다니다 보면 아직도 폐지된 스키마를 추천하는 글들이 널렸는데, 그런 걸 그대로 따라 했다가는 검색 트래픽 손해 본다.

현재 사용 금지 또는 제한된 스키마

HowTo 스키마는 2023년 9월부로 구글 리치 결과에서 완전히 빠졌다. 지금 박아봐야 리치 스니펫 안 뜨고, 오히려 페이지 용량만 늘어난다. FAQPage 스키마는 2023년 8월부터 정부·의료 도메인 외에는 리치 결과로 표시되지 않는다. 단, 주의할 건 FAQPage 스키마 자체를 금지하는 건 아니다. AI Overviews가 구조화된 Q&A를 인용할 때 여전히 참조 소스로 쓰이기 때문에, 일반 도메인도 FAQ 스키마는 유지하는 게 좋다. 리치 결과가 안 뜰 뿐이다.

SpecialAnnouncement는 2025년 7월에 공식 폐지됐다. 코로나 시기 긴급 공지용으로 만들어진 스키마라 이제 쓸 일 없다.

2026년 현재 효과가 입증된 스키마

대행사 현장에서 실제로 측정해보면, 임팩트 순서는 대략 이렇다. Product(전자상거래), Article·NewsArticle(콘텐츠), LocalBusiness(지역 비즈니스), Organization(브랜드 권위), Recipe(요식업), Event(공연·세미나), Course(교육). 반대로 Review·AggregateRating은 2023년 이후 가이드라인이 빡빡해져서 자체 페이지 리뷰만 마킹 가능하다. 외부에서 끌어온 리뷰 점수를 얹으면 매뉴얼 액션 위험이 있다.

JSON-LD vs Microdata vs RDFa – 뭘 써야 하나

2026년 결론부터 말하면 JSON-LD 하나만 쓰면 된다. 구글이 공식적으로 JSON-LD를 권장하고, 업계 표준도 이쪽으로 수렴한 지 오래다. Microdata(HTML 인라인 속성)와 RDFa는 레거시 사이트 유지보수할 때나 만날 뿐, 새로 구축하는 페이지에 쓸 이유가 없다.

한 가지 주의점은 @context 값이다. 아직도 “http://schema.org”로 적는 가이드가 검색되는데 이건 틀렸다. 2026년 현재 모든 스키마는 “https://schema.org” (HTTPS) 로 써야 한다. 구글 크롤러가 HTTP 버전도 파싱하긴 하지만, validator에서 경고 뜨고 생성형 검색엔진 일부는 아예 무시한다.

스키마 구현 실전 – Article 스키마 완전판

가장 많이 쓰는 Article 스키마부터 뜯어보자. 우리 팀이 실제 클라이언트 페이지에 배포하는 템플릿을 약간 가공해서 공유한다.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "제목은 110자 이내, 본문 H1과 반드시 동일",
  "image": [
    "https://example.com/16x9.jpg",
    "https://example.com/4x3.jpg",
    "https://example.com/1x1.jpg"
  ],
  "datePublished": "2026-04-24T10:00:00+09:00",
  "dateModified": "2026-04-24T10:00:00+09:00",
  "author": {
    "@type": "Organization",
    "name": "테라그로스",
    "url": "https://terg.kr"
  },
  "publisher": {
    "@type": "Organization",
    "name": "테라그로스",
    "logo": {
      "@type": "ImageObject",
      "url": "https://terg.kr/logo.png"
    }
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://terg.kr/blog/schema-guide"
  }
}
</script>

자주 빠뜨리는 필수 필드

image 필드를 보면 URL을 3개 넣었다. 구글 공식 문서에서 권장하는 16:9, 4:3, 1:1 비율을 각각 제공하라는 거다. 하나만 넣어도 작동하긴 하지만, AI Overviews 썸네일 노출 빈도가 확실히 떨어진다. 테스트해본 결과 3개 비율 제공 시 리치 결과 노출률이 1.4배 정도 올라갔다.

author를 Person으로 할지 Organization으로 할지 헷갈린다면, 대행사 운영 블로그는 Organization이 정석이다. 개인 실명 저자를 박으면 E-E-A-T에 유리할 것 같지만, 오히려 해당 인물이 이직·퇴사할 경우 유지보수 부담만 커진다. 조직 단위 권위로 잡고, 개별 글은 author 하위에 Person을 선택적으로 중첩하는 방식을 권한다.

dateModified가 생각보다 중요한 이유

2024년 이후 구글은 콘텐츠 신선도 시그널을 꽤 중요하게 본다. dateModified를 주기적으로 갱신하는 페이지가 그렇지 않은 페이지보다 평균 순위가 유의미하게 높다. 단, 아무 수정도 없이 날짜만 바꾸면 구글이 감지한다. 실제로 본문 일부를 업데이트하면서 같이 갱신해야 한다.

Product 스키마 – 이커머스 CTR 끌어올리는 핵심

이커머스 클라이언트들한테는 Product 스키마가 단연 1순위다. 가격, 재고, 리뷰가 검색 결과에 바로 표시되니까 CTR 차이가 즉시 드러난다. 근데 여기서 2026년 기준으로 주의해야 할 변화가 있다.

merchant listing 필수 요건 강화

2024년 말부터 구글은 Product 스키마에 hasMerchantReturnPolicy와 shippingDetails 필수화를 단계적으로 밀어붙였고, 2026년 현재는 거의 의무 수준이다. 이 두 필드가 빠지면 리치 결과에서 가격·리뷰 별점이 표시되지 않는다.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "상품명",
  "image": "https://example.com/photo.jpg",
  "description": "상품 설명",
  "sku": "0446310786",
  "brand": {
    "@type": "Brand",
    "name": "브랜드명"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/product",
    "priceCurrency": "KRW",
    "price": "49000",
    "availability": "https://schema.org/InStock",
    "shippingDetails": {
      "@type": "OfferShippingDetails",
      "shippingRate": {
        "@type": "MonetaryAmount",
        "value": "3000",
        "currency": "KRW"
      },
      "shippingDestination": {
        "@type": "DefinedRegion",
        "addressCountry": "KR"
      }
    },
    "hasMerchantReturnPolicy": {
      "@type": "MerchantReturnPolicy",
      "applicableCountry": "KR",
      "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
      "merchantReturnDays": 7,
      "returnMethod": "https://schema.org/ReturnByMail",
      "returnFees": "https://schema.org/FreeReturn"
    }
  }
}

실제로 지난 분기 이커머스 클라이언트 한 곳에서 이 두 필드를 추가한 뒤 Product 리치 결과 노출이 3주 만에 회복된 사례가 있다. 2023년 이전에 만든 템플릿 쓰는 사이트라면 지금 당장 점검해봐야 한다.

LocalBusiness와 Organization – 브랜드 권위 구조화

지역 비즈니스와 B2B 기업들한테는 LocalBusiness 또는 Organization 스키마가 기본이다. 근데 이걸 그냥 찍어만 두면 효과가 없다. 핵심은 sameAs 속성을 통한 엔티티 연결이다.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "테라그로스",
  "url": "https://terg.kr",
  "logo": "https://terg.kr/logo.png",
  "sameAs": [
    "https://www.linkedin.com/company/teragrowth",
    "https://www.youtube.com/@teragrowth",
    "https://business.google.com/terg"
  ],
  "contactPoint": {
    "@type": "ContactPoint",
    "telephone": "+82-2-xxxx-xxxx",
    "contactType": "customer service",
    "areaServed": "KR",
    "availableLanguage": ["Korean", "English"]
  }
}

sameAs가 2026년에 더 중요해진 이유

구글 Knowledge Graph와 AI Overviews는 엔티티 단위로 신뢰도를 평가한다. sameAs로 링크드인, 위키피디아, 링크드 전문 데이터 소스(링크드 오픈 데이터 등)를 연결하면 동일 엔티티로 인식한다. 우리가 지난 몇 달간 B2B 클라이언트 브랜드 검색 결과에 knowledge panel을 띄운 케이스는 전부 sameAs를 촘촘히 깔아둔 경우였다.

반대로 sameAs 없이 홀로 서 있는 Organization 스키마는 2026년 기준으로 거의 무가치하다. 구글이 “너희 누군지 모르겠다”고 판단해버리면 끝이다.

스키마 검증과 모니터링 – 배포가 끝이 아니다

배포했으면 끝이냐. 전혀 아니다. 스키마는 한 번 깔아두고 잊어버리면 3개월 안에 반드시 문제가 생긴다. CMS 업데이트, 템플릿 변경, 플러그인 충돌로 무너지는 경우가 정말 많다.

검증 도구 3단 체계

우리 팀이 쓰는 체크 루틴은 이렇다.

1단계 – Schema Markup Validator (validator.schema.org). schema.org 공식 검증기로, 문법 오류를 잡아낸다. 구글 리치 결과 여부와 무관하게 스키마 자체가 유효한지 확인하는 용도다.

2단계 – Google Rich Results Test (search.google.com/test/rich-results). 구글 리치 결과 적격 여부를 실제 크롤러 기준으로 테스트한다. 1단계는 통과하는데 2단계에서 경고가 뜨는 경우가 종종 있다. 대부분 image 비율이나 필수 필드 누락 문제다.

3단계 – Google Search Console 향상 보고서. 배포 후 3~7일 후부터 GSC에서 실제 색인된 구조화 데이터 상태를 볼 수 있다. “유효”, “경고 포함 유효”, “오류”로 분류되는데, 경고도 무시하지 말고 뜯어봐야 한다. 경고가 누적되면 어느 순간 유효 → 오류로 넘어간다.

정기 모니터링 체크리스트

월 1회 정도 이 항목들을 점검해주는 게 좋다. CMS 업데이트 직후, 플러그인 추가·제거 직후, 테마 변경 직후는 무조건 즉시 검증해야 한다. 실제로 한 클라이언트 사이트에서 WordPress 플러그인 하나 업데이트 했다가 전체 페이지 스키마가 깨진 적이 있었다. 2주 동안 몰랐고, 그 사이 Product 리치 결과가 전부 사라졌다.

자주 묻는 질문

마지막으로 – 스키마는 기술이 아니라 커뮤니케이션이다

2020년대 초반까지 스키마는 “구글 크롤러가 읽을 수 있도록 HTML을 포맷팅하는 기술”이었다. 지금은 다르다. 검색엔진, LLM, 생성형 AI가 전부 JSON-LD를 커뮤니케이션 레이어로 쓴다. 이 페이지가 무엇에 관한 것인지, 누가 만들었는지, 어떤 엔티티와 연결돼 있는지를 구조화해서 전달하는 수단이다.

그래서 스키마 작업은 콘텐츠 전략과 분리될 수 없다. 뭘 마킹할지 결정하는 과정이 곧 “이 사이트가 어떤 주제에 권위를 갖고 있는지”를 정의하는 작업이다. 우리가 클라이언트 작업할 때 스키마 세션에 생각보다 많은 시간을 쓰는 이유도 이거다. 근데 이 얘기까지 들어가면 글이 너무 길어지니까 다음 글에서 다루기로 하자.