Schema JSON-LD — 코드를 몰라도 만드는 구조화 데이터

구조화 데이터(스키마)는 무엇이고 AI 검색에 왜 필요한가요?

구조화 데이터(스키마)는 웹페이지 내용을 검색엔진과 AI가 이해하도록 정한 형식으로 옮겨 적은 이름표이며, 이 페이지가 무엇에 관한 것인지 기계가 오해 없이 읽게 돕는 신호입니다. 대부분은 코드를 몰라도 도구로 만듭니다.

사람은 페이지를 보면 제목이 무엇이고 누가 썼는지 한눈에 압니다. 기계는 그렇지 않아, 화면의 글자만으로는 어떤 줄이 저자 이름이고 어떤 숫자가 발행일인지 구분하기 어렵습니다. 구조화 데이터는 저자는 이것, 발행일은 이것이라고 항목마다 이름표를 붙여, 사람이 읽는 내용을 기계가 읽는 데이터로 겹쳐 두는 장치입니다.

이 이름표의 단어는 schema.org라는 공통 어휘를 따릅니다. schema.org는 주요 검색엔진들이 2011년부터 함께 만들어 온 표준 단어집으로, 저자는 author, 회사는 Organization처럼 항목마다 정해진 이름이 있습니다.

그 단어를 페이지에 적는 형식 가운데 Google이 권장하는 방식이 JSON-LD입니다(Google 검색 센터). JSON-LD는 본문과 떨어진 별도 블록에 정보를 모아 두는 형식이라, 글을 건드리지 않고 이름표만 따로 관리할 수 있습니다.

이렇게 이름표를 붙이면 두 가지에서 도움이 됩니다. 첫째는 리치 결과로, 검색 결과에 별점이나 접었다 펴는 FAQ, 사이트 경로 같은 표현이 붙는 것을 말하며 구조화 데이터가 그 근거가 됩니다. 둘째는 의미 전달로, 답변엔진이 이 페이지가 누구의 어떤 글인지 파악할 때 구조화된 이름표를 참고합니다.

다만 스키마를 만능으로 오해하면 안 됩니다. Google은 생성형 AI 검색에 구조화 데이터가 필수는 아니며 추가할 특별한 마크업도 없다고 밝혔습니다(Google 검색 센터). 스키마는 없는 신뢰나 순위를 만드는 마법이 아니라, 이미 페이지에 있는 정보의 의미를 기계에 정확히 전달하는 보조 신호입니다.

앞의 E-E-A-T 품질 향상에서 저자·출처·조직 같은 신뢰 신호를 페이지에 심는 일을 다뤘습니다. 구조화 데이터는 그 신호에 기계가 읽을 이름표를 겹쳐 붙이는 다음 단계로, 저자 바이오를 Person으로 회사 정보를 Organization으로 표시하면 사람이 보는 신뢰 신호와 기계가 읽는 신뢰 신호가 같은 내용으로 포개집니다.

코드를 몰라도 스키마를 만들 수 있나요?

만들 수 있습니다. 오늘날 대부분의 구조화 데이터는 코드를 한 줄도 쓰지 않고 만들 수 있으며, 도구가 내 입력을 JSON-LD 코드로 대신 옮겨 주기 때문입니다. 스키마가 개발자만의 영역이라는 생각은 이제 사실과 다릅니다.

원리는 간단합니다. 예전에는 사람이 직접 중괄호와 따옴표를 쳐 가며 이름표를 손으로 적었지만, 지금은 플러그인이나 생성 도구에 제목·저자·날짜 같은 값을 입력하면 도구가 그 값을 정해진 형식의 코드로 조립해 줍니다. 명함을 짤 때 인쇄 판을 직접 만들지 않고 양식에 이름과 직함만 넣으면 되는 것과 비슷합니다.

그래서 비개발자에게 진짜 어려운 부분은 코드 문법이 아니라 판단입니다. 이 페이지에 어떤 타입의 이름표가 맞는지, 어떤 정보를 표시하고 어떤 것은 표시하면 안 되는지를 정하는 일이 핵심입니다. 코드는 도구가 처리하고, 사람은 무엇을 언제 표시할지 결정하면 됩니다.

이 글이 코드를 거의 다루지 않는 이유가 여기 있습니다. 실제로 복사해 붙여 쓰는 JSON-LD 코드 전문과 삽입 방법은 실무 편인 JSON-LD 스키마·llms.txt 실전 설정법에서 따로 제공하며, 이 글은 그 앞 단계인 개념과 도구, 타입을 고르는 판단에 집중합니다.

코드 없이 스키마를 만드는 방법에는 어떤 것이 있나요?

코드 없이 스키마를 만드는 길은 크게 네 가지입니다. SEO 플러그인의 자동 생성, 웹 기반 스키마 생성기, AI에게 생성 요청, 그리고 전용 스키마 플러그인이나 CMS 기능입니다. 지금 쓰는 환경에 따라 맞는 방법이 갈립니다.

가장 손이 덜 가는 쪽은 SEO 플러그인입니다. 워드프레스를 쓴다면 RankMath나 Yoast SEO 같은 플러그인이 글을 발행할 때 제목·저자·발행일 같은 기본 정보를 알아서 스키마로 만들어 붙입니다. GEOMKT도 이런 플러그인으로 기본 스키마가 자동 생성되고 있습니다.

웹 스키마 생성기는 워드프레스가 아니거나 특정 타입만 손볼 때 편합니다. 도구에 값을 채워 넣으면 JSON-LD를 뽑아 주고, 그 결과를 페이지에 붙이면 됩니다. AI에게 콘텐츠를 주고 스키마를 만들어 달라고 하는 방법도 초안에는 빠르지만, 뒤에서 설명하듯 반드시 검증을 거쳐야 합니다.

어떤 스키마 타입을 언제 써야 하나요?

스키마 타입은 페이지의 정체와 그 페이지에 실제로 담긴 요소에 맞춰 고릅니다. 블로그 글에는 글을 설명하는 타입을, 회사 소개에는 조직을 설명하는 타입을 쓰며, 한 페이지에 여러 타입을 겹쳐 붙일 수도 있습니다.

한 페이지가 하나의 타입만 갖는 것은 아닙니다. 예를 들어 이 블로그 글 한 편에는 글 자체를 설명하는 BlogPosting, 저자를 설명하는 Person, 사이트 경로를 나타내는 BreadcrumbList가 함께 붙습니다. 이렇게 겹쳐 붙인 이름표들을 하나로 묶는 방식이 있는데, 그 코드 구조는 실무 편에서 다룹니다.

주의할 타입은 조건이 붙은 것들입니다. FAQPage는 페이지에 실제 질문과 답변 블록이 있을 때만 쓰며, 섹션별 작성 전략과 FAQ의 힘에서 만들어 둔 FAQ 블록이 있어야 이름표를 붙일 자격이 생깁니다. HowTo도 번호가 매겨진 단계 안내가 본문에 있을 때만 씁니다.

Person과 Organization은 E-E-A-T 품질 향상에서 채워 둔 저자·조직 정보에 이름표를 붙이는 타입입니다. 페이지에 실제로 있는 요소에만 맞는 타입을 고르는 것이 타입 선택의 핵심입니다.

비개발자가 스키마를 만드는 단계는 어떻게 되나요?

비개발자가 스키마를 만드는 흐름은 다섯 단계로 정리됩니다. 페이지 유형을 정하고, 맞는 타입을 고르고, 도구로 생성하고, 페이지에 넣고, 검증하는 순서입니다. 이 순서대로 밟으면 코드를 몰라도 스키마 하나를 완성할 수 있습니다.

1. 페이지 유형을 정합니다. 지금 만드는 페이지가 블로그 글인지, 회사 소개인지, 실제 질문과 답변이 있는지를 먼저 확인합니다. 유형이 정해져야 어떤 이름표가 맞는지 판단할 수 있습니다.
2. 맞는 스키마 타입을 고릅니다. 앞의 타입 표를 보고 페이지에 실제로 있는 요소만 골라 적습니다. 블로그 글이면 BlogPosting과 Person, 경로가 있으면 BreadcrumbList를 더합니다.
3. 도구로 생성합니다. 워드프레스면 SEO 플러그인 설정에서 값을 채우고, 아니면 웹 생성기에 입력하거나 AI에게 콘텐츠를 주고 생성을 요청합니다. 이 단계에서 코드가 만들어집니다.
4. 페이지에 넣습니다. 플러그인은 자동으로 페이지에 삽입하고, 생성기로 뽑은 코드는 페이지 머리 영역에 넣어야 합니다. 이 삽입 방법의 실제 코드는 실전 설정법에서 다룹니다.
5. 검증 도구로 확인합니다. 넣은 스키마에 빠진 값이나 오류가 없는지 도구로 점검합니다. 검증까지 마쳐야 한 편의 스키마가 완성됩니다.

이 다섯 단계에서 사람이 판단하는 곳은 1번과 2번입니다. 페이지가 무엇이고 어떤 요소가 실제로 있는지만 정하면 3번부터는 도구가 처리하므로, 스키마 작업의 성패는 코드 실력이 아니라 앞의 판단에서 갈립니다.

스키마를 남용하면 안 되는 이유는 무엇인가요?

스키마는 페이지에 실제로 있는 요소만 표시해야 하며, 없는 것을 꾸며 넣으면 안 됩니다. Google은 구조화 데이터가 페이지에서 사용자에게 보이는 콘텐츠를 대표해야 하고, 숨겨져 있거나 존재하지 않는 정보를 마크업해서는 안 된다고 명시합니다(Google 검색 센터 구조화 데이터 일반 가이드라인). 이를 어기면 리치 결과에서 제외되거나 수동 조치를 받을 수 있습니다.

가장 흔한 남용은 없는 요소에 이름표를 붙이는 것입니다. 질문과 답변이 없는 글에 FAQPage를 붙이거나, 단계 안내가 없는 글에 HowTo를 붙이거나, 실제 후기가 없는데 별점 스키마를 붙이는 경우가 여기에 해당합니다. 검색 결과를 더 눈에 띄게 하려는 욕심이 오히려 정책 위반으로 돌아옵니다.

원칙은 앞서 다룬 신뢰 이야기와 같습니다. E-E-A-T 품질 향상에서 구조화 데이터는 없는 신뢰를 만들지 못하고 있는 신호에 이름표를 붙일 뿐이라고 했습니다. 스키마 전체가 이 성격을 갖습니다. 페이지에 진짜로 있는 것을 정확히 표시하는 이름표이지, 없는 것을 만들어 내는 도구가 아닙니다.

자동 생성 플러그인도 확인이 필요합니다. 페이지 성격과 맞지 않는 타입을 붙이거나 없는 요소를 스키마에 넣는 경우가 있어, 도구가 만든 스키마라도 페이지 내용과 일치하는지 한 번은 사람이 대조하는 편이 안전합니다.

만든 스키마가 제대로 작동하는지 어떻게 확인하나요?

만든 스키마는 무료 검증 도구로 코드를 읽지 못해도 오류를 확인할 수 있습니다. 대표적으로 Google 리치 결과 테스트와 schema.org의 Schema Markup Validator가 있으며, 페이지 주소나 코드를 넣으면 무엇이 잘못됐는지 짚어 줍니다.

Google 리치 결과 테스트(Rich Results Test)는 이 페이지가 어떤 리치 결과 자격을 갖췄는지, 스키마에 오류나 경고가 있는지 보여 줍니다. schema.org의 Schema Markup Validator는 형식과 구조에 문법 오류가 없는지 점검합니다. 두 도구 모두 결과를 항목별로 알려 주므로, 어떤 값이 빠졌는지 코드를 몰라도 이해할 수 있습니다.

결과를 읽는 요령은 오류와 경고를 구분하는 것입니다. 오류(error)는 스키마가 인식되지 않게 하는 문제이므로 반드시 고쳐야 하고, 경고(warning)는 있으면 더 좋은 선택 항목이라 상황에 따라 채우면 됩니다. 발행한 뒤에는 Google Search Console의 향상 리포트에서 실제 색인된 페이지의 스키마 상태와 오류를 이어서 추적할 수 있습니다.

특히 AI에게 만들어 달라고 한 스키마는 검증이 더 중요합니다. AI는 없는 정보를 그럴듯하게 채우거나 필드 이름을 틀리게 쓰기도 하므로, 생성된 코드를 그대로 믿지 말고 검증 도구를 통과하는지, 페이지 실제 내용과 맞는지 반드시 대조해야 합니다.

스키마를 코드 없이 시작하려면 무엇부터 하나요?

워드프레스를 쓰고 있다면 이미 깔린 SEO 플러그인부터 확인하는 것이 가장 빠른 시작입니다. RankMath나 Yoast 같은 플러그인이 켜져 있으면 기본 스키마가 이미 생성되고 있을 수 있으므로, 새로 만들기 전에 지금 무엇이 나가고 있는지부터 보는 편이 좋습니다.

시작 순서는 플러그인이 붙이는 스키마 확인, 저자·조직 정보 채우기, 페이지별 필요한 타입 추가, 검증 도구 점검의 흐름입니다. 새 코드를 짜는 일 없이 있는 정보를 제자리에 채우는 작업에 가깝습니다.

GEOMKT의 사례도 이 순서를 밟는 중입니다. 자사 사이트는 RankMath류 플러그인으로 Organization·Article·BreadcrumbList·Person 같은 기본 스키마가 자동 생성되고 있지만, 직접 진단하는 과정에서 FAQPage나 대표 이미지, 언어 표시 같은 채울 여지를 발견해 우선순위를 잡아 보완하고 있습니다. 완성된 상태가 아니라 부족한 곳을 짚어 채워 가는 진행형입니다.

여기까지가 코드를 몰라도 밟을 수 있는 스키마의 전 과정입니다. 실제로 복사해 붙일 JSON-LD 코드와 삽입 방법이 필요하다면 JSON-LD 스키마·llms.txt 실전 설정법으로 이어 가면 됩니다.

다만 어떤 페이지에 어떤 타입이 비어 있는지, 자동 생성된 스키마가 실제 내용과 맞는지는 눈으로만 훑어서는 놓치기 쉽습니다. 무엇부터 채울지 정하기 어렵다면, 30분 무료 상담에서 지금 상황을 듣고 진단이 필요한지부터 말씀드립니다.

스키마가 페이지 하나하나의 내용에 이름표를 붙이는 일이라면, 사이트 전체를 AI에게 통째로 소개하는 방법은 따로 있습니다. 그 사이트 자기소개서인 llms.txt와 AI 크롤러 대응은 llms.txt와 AI 크롤러에서 이어집니다.

자주 묻는 질문 (FAQ)

Q1. 스키마를 넣으면 검색 순위가 바로 올라가나요?

아닙니다. 구조화 데이터는 검색 순위를 직접 올려 주는 요소가 아니라, 검색 결과의 표현을 풍부하게 하고 페이지의 의미를 기계에 명확히 전달하는 신호입니다.

Google도 구조화 데이터가 리치 결과 자격을 줄 수 있을 뿐 순위를 보장하지는 않는다고 밝혔습니다(Google 검색 센터). 순위 상승을 기대하기보다, 검색 결과에서 더 잘 보이고 AI가 내용을 정확히 읽도록 돕는 장치로 이해하는 편이 맞습니다.

Q2. 정말 코드를 한 줄도 안 써도 되나요?

대부분은 그렇습니다. SEO 플러그인, 웹 생성기, AI가 코드를 대신 만들어 주므로, 값을 채워 넣는 일만 하면 스키마가 생성됩니다.

다만 생성기로 뽑은 코드를 페이지 머리 영역에 넣는 마지막 단계는 환경에 따라 약간의 설정이 필요할 수 있습니다. 워드프레스 플러그인은 이 삽입까지 자동으로 하고, 직접 넣어야 하는 경우의 방법은 실전 편에서 다룹니다.

Q3. RankMath나 Yoast를 쓰면 스키마가 자동으로 들어가나요?

기본 타입은 대체로 자동으로 들어갑니다. Article이나 Organization, BreadcrumbList처럼 글이라면 공통으로 필요한 스키마는 플러그인이 발행 시 알아서 붙입니다.

다만 FAQPage나 HowTo처럼 조건이 붙는 타입은 글마다 별도 설정이 필요한 경우가 많고, 플러그인마다 지원 범위가 다릅니다. 그래서 자동에 맡기더라도 실제로 어떤 스키마가 나가는지 검증 도구로 한 번 확인하는 것이 좋습니다.

Q4. FAQ 스키마를 아무 글에나 넣어도 되나요?

안 됩니다. FAQPage는 페이지에 실제 질문과 답변이 있을 때만 붙일 수 있습니다. 질문과 답변이 없는데 FAQPage를 넣으면 Google 정책 위반이 됩니다.

없는 요소를 만들지 않는다는 원칙은 모든 타입에 적용됩니다. 단계가 없는 글에 HowTo, 후기가 없는데 별점 스키마를 붙이는 것도 같은 이유로 피해야 하며, 정책 위반은 리치 결과 제외로 이어질 수 있습니다.

Q5. AI에게 스키마를 만들어 달라고 하면 그대로 써도 되나요?

초안으로는 유용하지만 그대로 쓰는 것은 위험합니다. AI는 없는 정보를 그럴듯하게 채우거나 필드 이름을 틀리게 쓰는 경우가 있습니다.

그래서 AI가 만든 스키마는 반드시 Google 리치 결과 테스트나 검증기로 오류를 확인하고, 페이지의 실제 내용과 하나씩 대조해야 합니다. 검증을 거치지 않은 자동 생성 스키마는 잘못된 정보를 그대로 표시할 위험이 있습니다.

[참고] schema.org — 구조화 데이터 공통 어휘(검색엔진 공동 프로젝트, 2011 출범) · Google 검색 센터 — 구조화 데이터 일반 가이드라인 및 JSON-LD 권장(2025) · Google 검색 센터 — 생성형 AI 검색과 구조화 데이터 설명(2025) · GEOMKT 자사 GEO 셀프 진단(2026).

실제 적용 결과는 사이트 환경과 업종에 따라 달라질 수 있습니다.