AI로 스키마 마크업 자동 생성하고 검증하는 법

결론부터 말하면 이렇다. 챗GPT·클로드 같은 범용 AI 도구에 프롬프트를 넣는 것만으로 JSON-LD 스키마 마크업을 충분히 빠르게 만들 수 있다. 다만 AI가 만든 코드를 검증 없이 그대로 사이트에 붙여 넣으면 필수 속성 누락이나 잘못된 타입 중첩 같은 오류가 섞여 들어갈 위험이 크다. 스키마 마크업 자체를 처음부터 공부하지 않아도, 올바른 프롬프트 작성법과 발행 전 검증 절차 두 가지만 제대로 갖추면 실무에서 충분히 안전하게 쓸 수 있다.

지금까지 이루웹 블로그에서는 FAQPage, LocalBusiness, 리뷰, 브레드크럼처럼 개별 스키마 타입을 하나씩 다뤄 왔다. 이번 글은 각도를 바꿔, "그 스키마를 AI로 어떻게 직접 생성하는지"와 "생성된 코드를 어떻게 검증하는지"에 집중한다.

이 글에서 먼저 챙겨 갈 핵심만 추리면 이렇다.

• AI로 JSON-LD를 생성하는 것 자체는 문제없는 정상적인 작업 방식이다. 다만 검증은 필수다.
• 타입마다 프롬프트에 꼭 넣어야 하는 정보가 다르다(FAQPage, LocalBusiness, Product, Article 기준 템플릿 제공).
• AI가 가장 자주 저지르는 실수는 필수 속성 누락, 잘못된 타입 중첩, 없는 값 지어내기(할루시네이션) 세 가지다.
• 검증 도구는 구글 리치 결과 테스트와 schema.org 검증기, 용도가 다르므로 둘 다 알아야 한다.
• 2026년 5월 FAQ 리치 결과가 완전히 사라졌다는 사실은 FAQPage 스키마를 쓰는 방식 자체에도 영향을 준다.
• 발행 전 자가 점검 체크리스트로 실수를 사전에 걸러낼 수 있다.

AI로 JSON-LD 스키마 마크업을 생성해도 되나요?

그렇다. 구글은 구조화 데이터를 어떤 도구로 작성했는지를 따지지 않는다. 손으로 직접 타이핑했든, 플러그인이 자동 생성했든, AI에게 프롬프트로 시켰든 결과물인 JSON-LD 코드가 schema.org 문법을 지키고 페이지 내용과 실제로 일치하기만 하면 된다. 구글 서치 센트럴의 구조화 데이터 일반 가이드라인도 생성 방식이 아니라 콘텐츠의 정확성과 문법 유효성을 기준으로 삼는다.

문제는 AI가 "그럴듯하게" 코드를 써 준다는 점이다. 문법은 맞는데 내용이 틀린 경우가 특히 많다. 예를 들어 영업시간을 묻지 않았는데도 AI가 "09:00–18:00"처럼 임의의 값을 채워 넣거나, 실제로는 없는 평점 데이터를 그럴듯한 숫자로 만들어 내는 식이다. 이런 할루시네이션은 코드만 봐서는 구분되지 않는다는 점이 가장 큰 함정이다.

AI는 "문법적으로 틀리지 않은 코드"를 잘 만든다. 하지만 "우리 가게의 실제 정보"는 모른다. 이 둘을 구분하지 못하면 검증을 건너뛰게 된다.

나쁜 예: "우리 치과 스키마 마크업 만들어 줘"라고만 입력하고, AI가 채워 넣은 가상의 평점·리뷰 수를 확인 없이 그대로 발행한다. 좋은 예: 실제 주소·전화번호·영업시간·실제 확보한 리뷰 평점을 프롬프트에 직접 적어 주고, AI에게는 "이 정보만으로 JSON-LD를 만들어 달라"고 요청한다.

AI 생성 방식이 특히 빛을 발하는 경우는 반복적으로 비슷한 구조를 가진 페이지가 많을 때다. 예를 들어 전국에 매장이 10곳 있는 프랜차이즈라면, 지점별 LocalBusiness 스키마 10개를 손으로 하나씩 작성하기보다 공통 템플릿을 AI에게 먼저 만들게 한 뒤, 지점마다 달라지는 주소·전화번호·영업시간만 바꿔 넣도록 요청하는 방식이 훨씬 빠르다. 반대로 단 하나뿐인 페이지, 혹은 법적·의학적으로 민감한 정보가 들어가는 페이지라면 AI가 만든 초안을 사람이 한 줄씩 검토하는 과정에 더 많은 시간을 들이는 것이 안전하다.

어떤 AI 도구로 스키마를 만들 수 있나요?

별도의 전용 툴이 없어도, 범용 대화형 AI(챗GPT, 클로드, 제미나이 등)에 텍스트로 요청하는 것만으로 충분하다. 전용 스키마 생성기 플러그인도 있지만, 범용 AI 쪽이 우리 상황에 맞춰 설명을 바꿔 가며 대화형으로 수정할 수 있다는 장점이 있다.

실무에서는 보통 이런 순서로 진행한다. 먼저 어떤 페이지에 어떤 타입의 스키마가 필요한지 정한다(예: 서비스 소개 페이지라면 LocalBusiness, 블로그 글이라면 Article). 그다음 그 타입에 필요한 정보를 프롬프트에 구체적으로 나열하고, AI에게 JSON-LD 형식으로만 출력해 달라고 요청한다. 마지막으로 결과물을 검증 도구에 넣어 확인한다.

여러 클라이언트 사이트를 동시에 관리하는 에이전시나 프리랜서 입장에서는 이 방식의 효율이 특히 크다. 사이트마다 schema.org 문서를 새로 찾아보지 않고도, 정보만 바꿔서 같은 프롬프트 구조를 반복 사용할 수 있기 때문이다. 다만 클라이언트마다 업종과 요구 사항이 다르므로, 프롬프트 템플릿은 공통으로 두되 검증 단계는 사이트마다 빠짐없이 거치는 것이 원칙이다.

나쁜 예: "SEO 스키마 좀 만들어 줘"처럼 막연하게 요청해, 어떤 타입이 필요한지 AI가 추측하게 만든다. 좋은 예: "이 페이지는 지역 기반 서비스업 소개 페이지이고, LocalBusiness 타입으로 JSON-LD를 만들어 줘. 아래 정보만 사용하고 내가 안 준 정보는 비워 둬"처럼 타입과 범위를 먼저 지정한다.

여기서 중요한 원칙이 하나 있다. AI에게 "모르는 값은 지어내지 말고 비워 두거나 물어봐 달라"고 매번 명시적으로 지시하는 것이다. 이 한 문장을 프롬프트 끝에 붙이는 것만으로 할루시네이션으로 인한 사고가 눈에 띄게 줄어든다.

프롬프트의 정확도를 높이는 방법 중 하나는 페이지의 실제 본문 텍스트를 통째로 함께 붙여넣는 것이다. "아래는 우리 페이지에 실제로 쓰여 있는 본문이다. 이 내용에 없는 정보는 스키마에 넣지 말아 달라"고 지시하면, AI가 페이지 밖의 정보를 끌어와 지어내는 경우가 크게 줄어든다.

또 한 가지 효과적인 방법은 검증 도구가 보여준 오류 메시지를 그대로 AI에게 다시 전달하는 것이다. 예를 들어 리치 결과 테스트가 "acceptedAnswer.text 속성이 없습니다"라는 경고를 띄웠다면, 그 문구를 그대로 복사해 "이 오류가 나는데 고쳐 달라"고 요청하면 대부분 한 번에 해결된다. 이렇게 생성과 검증, 오류 피드백과 재생성을 한두 차례 반복하는 루틴을 들이면, 처음부터 완벽한 프롬프트를 쓰려고 애쓰지 않아도 결과물의 품질이 빠르게 올라간다.

타입별 프롬프트는 어떻게 써야 하나요?

타입마다 프롬프트에 반드시 넣어야 하는 정보가 다르다. 자주 쓰는 네 가지 타입을 기준으로 실전 템플릿을 정리했다.

FAQPage: 질문과 답변 쌍을 그대로 프롬프트에 붙여 넣고 "이 질문-답변 쌍만으로 FAQPage 타입 JSON-LD를 만들어 줘. 질문이나 답변 문구를 바꾸지 말고 그대로 써 줘"라고 요청한다. 질문 문구를 AI가 다듬지 못하게 막는 것이 핵심인데, 실제 페이지에 노출된 질문과 스키마 속 질문이 토씨 하나까지 일치해야 하기 때문이다. 다만 뒤에서 다시 다루겠지만, 2026년부터는 FAQ 리치 결과 자체가 노출되지 않으므로 이 타입을 새로 추가할 때는 리치 결과를 기대하기보다 콘텐츠 이해를 돕는 보조 수단 정도로 접근하는 것이 현실적이다.

LocalBusiness: 상호명, 정확한 주소(도로명 포함), 전화번호, 영업시간, 업종(음식점·병원·미용실 등 세부 업종)을 모두 적어 준다. "영업시간은 요일별로 다르니 openingHoursSpecification 배열로 만들어 줘"처럼 구조까지 지정하면 결과물의 완성도가 높아진다.

Product: 상품명, 가격, 통화, 재고 상태(품절인지 판매 중인지), 브랜드명을 적어 준다. 리뷰나 평점이 실제로 있다면 그 수치를, 없다면 "리뷰 데이터는 없으니 aggregateRating은 넣지 말아 달라"고 명시한다.

Article·BlogPosting: 제목, 대표 이미지 URL, 발행일, 수정일, 작성자명을 적어 준다. "본문 요약은 지어내지 말고 내가 주는 요약 문장을 그대로 description에 써 달라"처럼 요약문 왜곡을 막는 지시를 덧붙이는 것이 좋다.

타입	프롬프트에 꼭 넣을 정보	흔히 빠뜨리는 것
FAQPage	질문·답변 원문 그대로	페이지 노출 문구와의 일치 여부
LocalBusiness	주소, 전화번호, 세부 업종, 영업시간	요일별 영업시간 구조
Product	가격, 통화, 재고 상태, 브랜드	실제 리뷰 유무 명시
Article	발행일, 수정일, 작성자, 대표 이미지	요약문 임의 생성 방지 지시

나쁜 예: 네 가지 타입 모두에 "스키마 마크업 만들어 줘"라는 동일한 프롬프트를 사용한다. 좋은 예: 타입별로 꼭 필요한 정보 목록을 미리 메모해 두고, 그 정보를 채워서 프롬프트를 보낸다.

실제로 LocalBusiness 타입에는 아래와 같은 프롬프트를 쓰면 된다.

프롬프트 예시: "다음 정보로 LocalBusiness 타입 JSON-LD를 만들어 줘. 업종은 미용실이고 상호명은 '이루헤어 강남점', 주소는 서울 강남구 테헤란로 123, 전화번호는 02-1234-5678, 영업시간은 평일 10시부터 20시까지이고 월요일은 휴무야. 내가 안 준 정보(평점, 가격대 등)는 절대 넣지 말아 줘."

이렇게 요청하면 아래와 비슷한 형태의 결과물을 받을 수 있다(실제 응답은 속성 순서나 들여쓰기가 다를 수 있다).

{
  "@context": "https://schema.org",
  "@type": "HairSalon",
  "name": "이루헤어 강남점",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "테헤란로 123",
    "addressLocality": "강남구",
    "addressRegion": "서울",
    "addressCountry": "KR"
  },
  "telephone": "02-1234-5678",
  "openingHoursSpecification": [
    { "@type": "OpeningHoursSpecification", "dayOfWeek": ["Tuesday","Wednesday","Thursday","Friday"], "opens": "10:00", "closes": "20:00" }
  ]
}

여기서 흔히 나오는 실수가 하나 있다. 휴무일인 월요일을 아예 빼는 대신 "opens":"00:00","closes":"00:00"처럼 채워 넣는 것이다. 완전히 쉬는 요일은 openingHoursSpecification 배열 자체에서 빼는 것이 맞는 표기법이다. 이런 세부 규칙까지는 AI가 매번 정확히 지키지 못하므로, 결과물을 받은 뒤 휴무일 표기 방식만큼은 꼭 따로 확인하는 것이 좋다.

AI가 생성한 JSON-LD, 그대로 쓰면 왜 위험한가요?

검증 없이 발행하면 세 가지 유형의 오류가 섞여 들어갈 가능성이 높기 때문이다. 첫째는 필수 속성 누락, 둘째는 잘못된 타입 중첩, 셋째는 없는 값을 그럴듯하게 지어내는 할루시네이션이다.

필수 속성 누락은 가장 흔한 실수다. 예를 들어 FAQPage를 만들 때 acceptedAnswer 안에 반드시 들어가야 하는 text 속성을 빠뜨리거나, Product에서 offers나 review, aggregateRating 중 아무것도 넣지 않는 식이다. AI는 겉보기에 완성된 코드를 내놓기 때문에, 직접 한 줄씩 대조하지 않으면 빠진 속성을 눈치채기 어렵다.

잘못된 타입 중첩은 두 번째로 흔하다. Organization 안에 들어가야 할 address 속성에 문자열을 그냥 넣거나, PostalAddress 타입으로 감싸야 할 자리를 생략하는 경우다. 또 리뷰 스키마에서 itemReviewed 안에 또 다른 Review를 중첩시키는 것처럼, schema.org 문법상 허용되지 않는 구조를 만들어 내기도 한다.

할루시네이션은 가장 위험하다. 평점을 물어보지 않았는데도 "4.8점, 리뷰 320개"처럼 구체적인 숫자를 임의로 만들어 내거나, 영업시간을 모른다고 했는데도 일반적인 값을 채워 넣는 식이다. 이렇게 만들어진 허위 정보가 그대로 발행되면 실제와 다른 정보를 검색 결과에 노출하는 셈이 되고, 사용자 신뢰를 해칠 뿐 아니라 구글의 스팸 정책(허위·오해 소지 콘텐츠)에도 저촉될 수 있다.

나쁜 예: "리뷰 평점 스키마도 넣어 줘"라는 요청에 AI가 임의의 4.9점을 만들어 냈는데, 그대로 발행한다. 좋은 예: 실제 리뷰 평점과 리뷰 수를 직접 제공하고, 없는 항목은 아예 스키마에서 제외하도록 요청한다.

코드로 보면 차이는 이렇다. 같은 "리뷰 스키마도 넣어 줘"라는 요청이라도, 실제 데이터 없이 받은 나쁜 예는 다음과 같은 형태로 나온다.

"aggregateRating": {
  "@type": "AggregateRating",
  "ratingValue": "4.9",
  "reviewCount": "320"
}

실제로는 리뷰를 20건밖에 모으지 못한 가게였는데도, AI가 그럴듯한 숫자를 채워 넣은 사례다. 실제 데이터를 프롬프트에 직접 제공하고 받은 좋은 예는 다음과 같다.

"aggregateRating": {
  "@type": "AggregateRating",
  "ratingValue": "4.6",
  "reviewCount": "20"
}

두 코드 모두 문법적으로는 완벽하다. 차이는 오직 숫자가 진짜인가 아닌가뿐이고, 이 차이는 검증 도구가 아니라 사람이 원본 데이터와 대조해야만 걸러낼 수 있다.

AI가 만든 숫자·날짜·평점은 전부 의심하고 원본 데이터와 하나씩 대조하는 습관이 가장 중요한 안전장치다.

생성된 코드는 어떻게 검증하나요?

결론은 구글 리치 결과 테스트와 schema.org 검증기, 두 도구를 역할에 맞게 함께 써야 한다는 것이다. 두 도구는 목적이 다르다.

구글 리치 결과 테스트(search.google.com/test/rich-results)는 구글이 직접 제공하는 도구로, 내 스키마가 구글이 지원하는 리치 결과 형태로 실제 노출될 자격이 있는지를 확인해 준다. URL을 입력하거나 코드를 붙여 넣으면 어떤 리치 결과 후보가 감지됐는지, 필수 속성이 빠졌는지, 경고 수준의 권장 속성이 빠졌는지까지 구분해서 알려준다. 예전에 있던 구조화 데이터 테스트 도구(Structured Data Testing Tool)는 2020년에 이미 지원이 종료됐으므로, 지금은 리치 결과 테스트 하나로 통합해서 쓰면 된다.

schema.org 검증기(validator.schema.org)는 구글과 무관하게 schema.org 문법 자체가 올바른지만 순수하게 확인해 주는 커뮤니티 도구다. 구글이 지원하지 않는 타입(예: 구글 리치 결과로는 안 뜨지만 다른 검색엔진이나 AI 크롤러가 참고할 수 있는 타입)까지 폭넓게 검증할 수 있다는 점이 장점이다. 구글 리치 결과 테스트를 통과했다고 해서 schema.org 문법이 완벽하다는 뜻은 아니고, 반대도 마찬가지이므로 두 도구를 상호 보완적으로 쓰는 것이 안전하다.

도구	확인하는 것	통과해도 보장 안 되는 것
구글 리치 결과 테스트	구글 리치 결과 자격 여부	schema.org 문법 전체의 완전성
schema.org 검증기	schema.org 문법 유효성	구글이 실제로 리치 결과를 노출할지 여부

여기서 중요한 사실 하나를 짚어야 한다. 2026년 5월 7일부로 구글 검색에서 FAQ 리치 결과가 완전히 사라졌다. 2023년부터 일부 공공·의료기관 사이트로 축소되던 흐름이 이번에 전면 종료로 이어진 것이다. 같은 해 6월에는 서치 콘솔의 FAQ 보고 기능과 리치 결과 테스트의 FAQ 지원도 함께 빠질 예정이고, 8월에는 API 지원도 끝난다. 다만 FAQPage 자체는 지금도 schema.org상 유효한 타입이고, 이미 넣어 둔 마크업을 당장 걷어낼 필요는 없다. 구글이 공식적으로 밝히지는 않았지만, 질문-답변 형태의 구조화 데이터가 AI 검색이 콘텐츠를 파싱하는 데는 여전히 도움이 될 수 있다는 분석도 있다. FAQPage를 다른 각도로 더 깊이 알고 싶다면 FAQ 스키마, 리치 결과는 사라졌는데 지금도 써야 할까에서 자세히 다뤘다.

나쁜 예: 리치 결과 테스트만 통과하면 끝이라고 생각하고 schema.org 검증기는 아예 거치지 않는다. 좋은 예: 두 도구에 모두 넣어 보고, 두 결과에서 공통으로 지적된 오류부터 우선 수정한다.

AI로 만든 스키마, GEO에도 도움이 되나요?

결론부터 말하면, 스키마 마크업 자체가 AI 검색 노출 순위를 직접 끌어올린다는 증거는 아직 약하다. 다만 이름·주소·가격·영업시간처럼 명확한 사실 정보를 구조화해 두면, AI가 콘텐츠를 요약하거나 인용할 때 오해 없이 정확하게 인식하는 데는 도움이 된다는 분석이 많다.

여기서 핵심은 AI로 스키마를 빨리 만드는 작업과, AI 검색에 실제로 인용되는 작업이 완전히 같은 과제는 아니라는 점이다. AI 검색 인용과의 상관관계를 조사한 여러 자료를 보면 브랜드 언급량이나 콘텐츠의 사실 밀도가 스키마 유무보다 더 큰 변수로 꼽히는 경우가 많다. 그렇다고 스키마가 무의미하다는 뜻은 아니다. 정확한 구조화 데이터는 AI가 콘텐츠를 잘못 해석할 가능성을 낮춰 주는 최소한의 안전장치 역할을 한다고 보는 것이 현실적이다.

나쁜 예: 스키마 마크업만 넣으면 AI 검색에 바로 인용될 것이라 기대하고 콘텐츠 품질은 신경 쓰지 않는다. 좋은 예: 스키마는 정확성을 보장하는 기본기로 챙기고, 실제 인용을 늘리는 작업은 콘텐츠의 사실 밀도와 브랜드 언급 확장에 더 집중한다.

업종별로 어떻게 다르게 적용하나요?

같은 AI 프롬프트 방식이라도 업종에 따라 체크해야 할 포인트가 달라진다.

• 지역 기반 서비스업(미용실·음식점·병원 등): LocalBusiness가 핵심이다. 나쁜 예는 전국 체인점의 대표 영업시간을 모든 지점에 똑같이 적용하는 것이고, 좋은 예는 지점별로 실제 영업시간과 주소를 각각 따로 입력해 AI에게 지점마다 별도의 JSON-LD를 만들게 하는 것이다.
• 온라인 쇼핑몰: Product와 리뷰 스키마가 중심이다. 나쁜 예는 품절 상품에도 InStock 상태를 그대로 둔 채 발행하는 것이고, 좋은 예는 재고 연동 시스템과 맞춰 품절 시 OutOfStock으로 자동 갱신되도록 설계하는 것이다. 리뷰 집계 방식은 리뷰 스키마 마크업 완벽 가이드에서 더 자세히 다뤘다.
• 법률·의료 등 전문직: 신뢰도가 특히 중요한 업종이라 과장된 정보를 스키마에 넣지 않는 것이 원칙이다. 나쁜 예는 검증되지 않은 "국내 1위" 같은 표현을 description에 그대로 넣는 것이고, 좋은 예는 실제 자격·면허 정보와 검증 가능한 사실관계만 담는 것이다.
• 블로그·미디어형 콘텐츠: Article·BlogPosting 스키마가 중심이다. 저자·발행일 정보의 정확도가 특히 중요하다. 세부 속성은 Article·BlogPosting 스키마 가이드를 참고하면 된다.
• 학원·교육기관: Course나 EducationalOrganization 타입이 쓰인다. 나쁜 예는 이미 폐강된 과정의 정보를 스키마에 그대로 남겨 두는 것이고, 좋은 예는 개강 일정이 바뀔 때마다 스키마도 함께 갱신하는 절차를 만들어 두는 것이다.
• 부동산 중개: 매물 소개 페이지에는 가격·거래 상태 정보가 들어가는데, 이 정보는 특히 자주 바뀐다. 나쁜 예는 이미 거래가 끝난 매물 페이지에 가격 정보를 그대로 방치하는 것이고, 좋은 예는 거래 상태가 바뀔 때 스키마 갱신까지 한 프로세스로 묶어 관리하는 것이다.

업종이 다르면 "실제 정보가 있는지 없는지"의 기준도 달라진다. 프롬프트를 복사해서 돌려 쓰기보다, 업종별로 꼭 확인해야 할 항목을 따로 메모해 두는 편이 안전하다.

지역 기반 업종에서 LocalBusiness 전체 구조를 더 깊게 알고 싶다면 LocalBusiness 스키마 마크업 완벽 가이드에서 전체 속성을 정리해 두었다.

AI가 자주 저지르는 실수는 무엇인가요?

지금까지 다룬 내용을 포함해, 실무에서 반복적으로 나타나는 AI 생성 스키마의 실수를 정리하면 다음과 같다.

• 날짜 형식 오류: datePublished에 "2026년 9월 30일"처럼 한글 날짜를 그대로 넣는다. ISO 8601 형식(2026-09-30)으로 바꿔야 한다. AI는 프롬프트에 날짜를 한글로 적어 주면 변환하지 않고 그대로 옮기는 경우가 많으므로, 처음부터 "YYYY-MM-DD 형식으로 써 달라"고 지정해 두는 것이 안전하다.
• URL 불일치: 스키마 속 이미지·페이지 URL이 실제 페이지의 주소와 다르다. 특히 www 유무, http와 https 혼용에서 자주 발생한다. 실제 배포 주소를 복사해서 그대로 프롬프트에 붙여 주면 이런 사소한 불일치를 줄일 수 있다.
• 중복 스키마 삽입: 같은 타입의 JSON-LD 블록을 한 페이지에 두 번 넣는다. 기존에 수동으로 넣어 둔 스키마가 있는지 확인하지 않고 AI가 만든 코드를 추가해 발생하는 경우가 많다. 삽입 전에 반드시 페이지 소스에서 기존 application/ld+json 블록이 있는지 먼저 검색해 보는 습관이 필요하다.
• 빈 배열·빈 문자열 방치: 정보가 없는 속성을 아예 빼지 않고 빈 값("")으로 채운 채 발행한다. 구글은 빈 값을 속성이 없는 것과 다르게 해석할 수 있어, 아예 그 속성을 제거하는 것이 안전하다.
• 페이지 내용과의 불일치: 스키마에는 "무료 배송"이라고 적혀 있는데, 실제 페이지 어디에도 그 문구가 없다. 구조화 데이터는 페이지에 실제로 보이는 정보와 일치해야 한다는 원칙을 어기는 대표적인 사례다.
• 지원 중단된 타입을 그대로 쓰는 것: schema.org 자체에는 남아 있지만 구글이 더 이상 리치 결과로 지원하지 않는 타입을, AI가 과거 학습 데이터를 근거로 그대로 추천하는 경우가 있다. 특정 타입이 지금도 리치 결과 대상인지는 프롬프트에 묻기보다 검증 도구로 직접 확인하는 편이 정확하다.

나쁜 예: 생성된 코드를 복사해서 바로 붙여 넣고 끝낸다. 좋은 예: 위 다섯 가지 항목을 기준으로 한 줄씩 직접 대조한 뒤 발행한다.

생성한 스키마는 사이트에 어떻게 삽입하나요?

검증까지 끝난 JSON-LD는 <script type="application/ld+json"> 태그로 감싸 페이지의 <head>나 <body> 안에 넣으면 된다. 플랫폼마다 삽입 방식이 조금씩 다르다.

Next.js처럼 직접 개발하는 사이트라면, 페이지 컴포넌트 안에서 스크립트 태그를 렌더링하는 방식으로 넣는 것이 일반적이다. 워드프레스라면 Yoast SEO나 Rank Math 같은 SEO 플러그인의 "커스텀 스키마" 입력란에 붙여 넣거나, 테마 편집기에서 직접 삽입할 수 있다. 카페24·아임웹 같은 국내 빌더형 플랫폼은 "HTML 삽입" 위젯이나 스크립트 삽입 기능을 지원하는 경우가 많으므로, 각 플랫폼의 관리자 화면에서 해당 기능을 먼저 확인하는 것이 순서다.

어떤 플랫폼이든 삽입 직후에는 반드시 실제 배포된 페이지 주소를 리치 결과 테스트에 다시 넣어 확인해야 한다. 코드 자체는 맞아도 삽입 위치가 잘못되면 구글이 아예 인식하지 못하는 경우가 있다.

넣은 뒤에 화면에 코드가 안 보인다고 당황할 필요는 없다. JSON-LD는 사용자 화면에는 전혀 표시되지 않고, 검색엔진과 크롤러만 읽는 숨은 데이터이기 때문이다. 눈에 보이지 않는다고 삭제하거나 다시 넣는 실수를 하지 않도록, 브라우저의 페이지 소스 보기 기능으로 실제로 삽입됐는지 직접 확인하는 습관을 들이면 좋다.

발행 전 체크리스트는 무엇인가요?

검증 도구를 통과했다는 것과 발행해도 안전하다는 것은 완전히 같은 말이 아니다. 아래 항목까지 함께 확인하는 것을 권한다.

1. 구글 리치 결과 테스트를 통과했는가
2. schema.org 검증기로 문법 오류가 없는지 재확인했는가
3. 스키마 속 수치·날짜·평점이 실제 데이터와 한 글자씩 일치하는가
4. 페이지에 보이지 않는 정보가 스키마에만 들어가 있지는 않은가
5. 같은 타입의 스키마가 중복 삽입되지 않았는가
6. 정보가 없는 속성은 빈 값으로 두지 않고 아예 제거했는가

이 여섯 가지를 매번 체크리스트로 돌리는 습관을 들이면, AI를 활용하면서도 오류가 섞여 발행될 위험을 크게 줄일 수 있다.

혼자 운영하는 사이트라면 작성과 검수를 한 사람이 번갈아 맡아도 충분하다. 다만 팀 단위로 콘텐츠를 다룬다면, 프롬프트를 작성해 초안을 만드는 사람과 체크리스트로 검수하는 사람을 분리하는 편이 더 안전하다. 같은 사람이 작성과 검수를 모두 맡으면 자신이 쓴 프롬프트의 전제를 그대로 믿고 넘어가기 쉽기 때문이다.

자주 묻는 질문

AI가 생성한 스키마 마크업을 그대로 써도 되나요?

검증 도구를 거치지 않고 그대로 쓰는 것은 권장하지 않는다. 구글 리치 결과 테스트와 schema.org 검증기를 모두 통과한 뒤, 수치·날짜 같은 실제 데이터가 일치하는지 한 번 더 사람이 확인하고 발행하는 것이 안전하다.

챗GPT와 클로드 중 어떤 도구가 스키마 생성에 더 적합한가요?

둘 다 충분히 활용할 수 있다. 결과물의 문법적 완성도보다, 프롬프트에 실제 정보를 얼마나 구체적으로 넣었는지가 품질을 더 크게 좌우한다. 어느 도구를 쓰든 동일한 원칙(실제 정보만 입력, 모르는 값은 비우기)을 지키면 결과는 비슷하다.

스키마 마크업을 넣으면 무조건 리치 결과가 뜨나요?

아니다. 구조화 데이터를 올바르게 넣는 것은 리치 결과 노출의 필요조건이지 충분조건이 아니다. 구글은 적격 조건을 만족한 페이지 중에서도 자체 기준에 따라 선택적으로 리치 결과를 노출한다.

FAQ 스키마는 이제 아예 쓰지 말아야 하나요?

그럴 필요는 없다. 구글 검색의 FAQ 리치 결과 노출은 2026년 5월에 끝났지만, FAQPage 자체는 schema.org상 여전히 유효한 타입이다. 기존에 넣어 둔 마크업을 급하게 제거할 필요는 없고, 다만 리치 결과를 기대하고 새로 공들여 추가할 이유는 줄었다고 보는 것이 정확하다.

AI가 만든 코드에서 오류가 발견되면 어떻게 고치나요?

검증 도구가 지적한 속성명을 그대로 AI에게 다시 전달하면서 "이 속성이 빠졌다고 나온다, 추가해 달라"고 요청하면 대부분 빠르게 수정된다. 복잡한 중첩 오류라면 schema.org 공식 문서에서 해당 타입의 속성 구조를 직접 한 번 확인하는 것이 더 빠를 때도 있다.

한 페이지에 여러 타입의 스키마를 동시에 넣어도 되나요?

가능하다. 예를 들어 블로그 글이라면 Article과 BreadcrumbList를 함께 넣는 경우가 흔하다. 다만 서로 다른 <script> 블록으로 분리하거나, 같은 블록 안에 배열로 넣는 등 구조를 명확히 해야 하고, 타입끼리 내용이 모순되지 않는지 확인해야 한다.

소규모 사이트도 굳이 스키마 마크업을 신경 써야 하나요?

규모와 무관하게 의미가 있다. 리치 결과 노출뿐 아니라 검색엔진과 AI 크롤러가 페이지 내용을 더 정확하게 이해하도록 돕는 역할도 하기 때문이다. AI로 생성 비용 자체가 크게 줄었으므로, 작은 사이트라도 핵심 페이지 몇 개부터 적용해 보는 것을 권한다.

유료 스키마 생성 도구를 따로 사야 하나요?

꼭 그렇지는 않다. 챗GPT나 클로드 같은 범용 AI 도구의 무료 또는 기본 요금제만으로도 이 글에서 다룬 작업은 충분히 처리할 수 있다. 다만 수백 개 단위의 페이지를 한 번에 자동화하고 싶다면, API 연동이 가능한 유료 도구나 스크립트를 함께 고려해 볼 만하다.

AI로 스키마를 만들면 시간이 얼마나 절약되나요?

정확한 수치는 사이트마다 다르지만, 타입 구조를 몰라 매번 문서를 찾아보던 기존 방식에 비해 초안 작성 시간 자체는 체감상 크게 줄어든다. 다만 검증과 대조 작업에 들이는 시간까지 아끼려 하면 오류가 섞인 채 발행될 위험이 커지므로, 전체 소요 시간을 줄이려는 목적이라면 생성 단계보다 검증 단계를 더 꼼꼼히 챙기는 방향으로 접근하는 것이 안전하다.

AI로 스키마 마크업을 빠르게 만드는 것과, 그 결과물이 실제로 우리 사이트에 맞게 정확히 들어가는 것은 다른 문제입니다. 이루웹은 홈페이지 제작 단계에서부터 구조화 데이터 설계와 검증까지 함께 챙겨 드리고 있으니, 우리 사이트에 어떤 스키마가 필요한지부터 막막하시다면 이루웹에 상담을 요청해 주세요.