JSON-LD가 구조화 데이터 표준이 된 이유
구글 검색 결과에서 별점, 조리 시간, FAQ 드롭다운이 붙은 "리치 스니펫"을 본 적이 있을 겁니다. 이걸 만드는 재료가 구조화 데이터인데, 사실 구조화 데이터를 마크업하는 방식에는 세 가지가 있었습니다. 그런데 지금은 대부분의 도구와 가이드가 JSON-LD 하나만 언급합니다. 왜 세 가지 중 하나만 살아남았는지, 그 배경을 정리했습니다.
1. 원래 존재했던 세 가지 방식
구조화 데이터를 웹페이지에 심는 방법은 역사적으로 세 가지였습니다. Microdata는 itemscope, itemtype, itemprop 같은 속성을 이미 있는 HTML 태그에 직접 끼워 넣는 방식입니다. RDFa는 W3C가 만든 표준으로 비슷하게 HTML 속성을 확장해서 씁니다. JSON-LD는 이 둘과 완전히 다른 접근으로, 본문 HTML은 건드리지 않고 <script type="application/ld+json"> 태그 하나에 데이터를 JSON 형식으로 통째로 넣습니다. 세 방식 모두 같은 스키마(schema.org 어휘)를 표현할 수 있다는 점은 동일합니다 — 차이는 순전히 "어디에, 어떻게 적느냐"입니다.
2. Microdata/RDFa가 밀려난 이유
Microdata와 RDFa는 본문 요소 하나하나에 속성을 붙여야 하므로 콘텐츠와 마크업이 완전히 뒤섞입니다. 상품명 하나를 <span itemprop="name">처럼 감싸야 하고, 필드가 늘어날수록 HTML 구조 자체가 스키마 문법에 종속됩니다. 디자이너가 마크업 구조를 살짝만 바꿔도 스키마가 깨지기 쉽고, 값이 화면에 보이지 않아야 하는 필드(예: 내부 SKU, 예약된 재고 수)를 넣으려면 CSS로 숨기는 편법을 써야 합니다. 반면 JSON-LD는 화면에 보이는 HTML과 완전히 분리되어 있어서, 디자인이 바뀌어도 스키마는 그대로 유지되고, 서버나 JavaScript로 동적 생성하기도 훨씬 쉽습니다. 이 차이 때문에 구글은 공식 문서에서 JSON-LD를 권장 형식으로 명시했고, 실무에서도 빠르게 이쪽으로 수렴했습니다. 실제로 스키마 마크업 생성기를 비롯해 대부분의 자동 생성 도구가 처음부터 JSON-LD 형식만 출력합니다.
Microdata:
<span itemprop="name">무선 이어폰</span> (본문 태그에 속성 삽입)JSON-LD:
{"@type":"Product","name":"무선 이어폰"} (본문과 분리된 별도 블록)JSON-LD 쪽이 본문 어디에 있든 상관없고, 필드 추가·삭제가 HTML 구조에 영향을 주지 않습니다.
3. 리치 스니펫과 클릭률의 관계
구조화 데이터를 올바르게 넣으면 구글이 검색 결과에 별점, 가격 범위, 조리 시간, FAQ 드롭다운 같은 추가 정보를 붙여줄 수 있습니다. 업계에서는 이런 리치 스니펫이 노출되면 일반 텍스트 결과 대비 클릭률(CTR)이 평균 20~30% 상승한다는 통계가 자주 인용됩니다. 특히 FAQ 스키마는 검색 결과에 질문·답변이 바로 펼쳐져 보이므로 체감 효과가 크고, Product 스키마의 별점·가격 표시도 눈에 띄게 클릭을 유도합니다. 다만 리치 스니펫이 뜨는 것은 마크업만으로 보장되지 않고 구글의 판단에 달려 있다는 점은 유의해야 합니다.
| 스키마 타입 | 노출되는 리치 요소 |
|---|---|
| FAQPage | 질문·답변 드롭다운 |
| Product | 별점, 가격, 재고 여부 |
| Recipe | 조리 시간, 칼로리, 별점 |
| Event | 날짜, 장소, 티켓 정보 |
| BreadcrumbList | 검색 결과 URL 대신 경로 표시 |
4. JSON-LD 안에서도 실수는 흔하다
형식을 JSON-LD로 옮겼다고 끝이 아닙니다. 모든 타입 공통으로 @context와 @type이 필수이고, Article은 headline·author·datePublished, Product는 name, FAQPage는 mainEntity, Event는 name·startDate·location이 각각 필수입니다. 값을 채워도 실제 페이지에 보이지 않는 정보(예: 실제로 존재하지 않는 리뷰 개수)를 넣으면 구글이 리치 스니펫을 아예 표시하지 않거나 스팸성 마크업으로 판단해 수동 조치 대상이 될 수 있습니다. 작성한 JSON-LD가 문법적으로 올바른지, 필수 필드가 빠지지 않았는지는 스키마 검증기나 구글 리치 결과 테스트로 반드시 확인해야 합니다.
5. 실무에서 빠르게 시작하는 방법
Article·Product·FAQ처럼 자주 쓰는 타입은 처음부터 완전한 문법을 손으로 외워 작성하기보다, FAQ 스키마 생성기나 상품 스키마 생성기, 아티클 스키마 생성기처럼 타입별 전용 도구로 채워 넣는 편이 필수 필드 누락을 줄이는 가장 빠른 방법입니다.
자주 묻는 질문
Q. Microdata나 RDFa로 만든 기존 마크업을 꼭 JSON-LD로 바꿔야 하나요?
필수는 아닙니다. 구글은 세 형식 모두 여전히 인식합니다. 다만 신규 작업이라면 유지보수가 쉬운 JSON-LD를 쓰는 것이 실무적으로 유리합니다.
Q. JSON-LD를 head가 아니라 body에 넣어도 되나요?
네, 구글은 head와 body 어디에 있어도 동일하게 인식한다고 명시합니다. 다만 관례적으로 head에 넣는 경우가 많습니다.
Q. 리치 스니펫을 넣으면 검색 순위가 올라가나요?
직접적인 순위 요인은 아닙니다. 구조화 데이터는 검색 결과의 "표시 방식"을 바꿔 클릭률을 높이는 역할이지, 랭킹 알고리즘 자체에 가점을 주지는 않습니다.
Q. 한 페이지에 여러 스키마 타입을 동시에 넣을 수 있나요?
가능합니다. <script type="application/ld+json"> 블록을 여러 개 두거나, 배열(@graph)로 묶어 한 블록에 여러 타입을 넣을 수 있습니다. 단 페이지 실제 내용과 일치하지 않는 타입을 억지로 추가하면 안 됩니다.