구조화된 데이터의 현실: LLM 시대의 스키마와 의미론적 SEO
핵심
구조화된 데이터(structured data) 마크업과 Schema.org 어휘는 다른 것이다. 구조화된 데이터는 정보 조직 방식이고, Schema.org는 그 의미를 표현하기 위한 어휘 세트다. 업계의 혼란은 주로 Google의 잘못이 아니라, SEO 전문가들이 원본 문서와 사용 사례를 직접 읽지 않으려는 습관에서 비롯됐다.
구조화된 데이터 vs. Schema.org: 개념의 차이
-
구조화된 데이터의 범위: 엑셀 파일, 테이블, 그리고 마크업 형태의 구조화된 데이터를 모두 포함하는 광범위한 용어
- 마크업은 RDFa, Microdata, JSON-LD 같은 문법(syntax)으로 표현됨
- 문법 자체는 의미를 담지 않음
-
Schema.org의 역할: 데이터에 의미를 부여하는 어휘
- "이 데이터는 사람에 관한 것이고, 이름은 ~이고, 도시는 ~이다" 같은 의미를 기계가 읽을 수 있도록 표현
- 기술적으로 정확한 용어는 '의미론적 메타데이터(semantic metadata)'이지만, 검색 엔진이 일반인 이해를 돕기 위해 '구조화된 데이터'라는 마케팅 용어를 만듦
업계 오해의 원인: Google이 아닌 SEO 커뮤니티
-
Google의 문서화 수준: Google은 검색에 중요한 부분에 집중하며, 어떤 게시자보다도 구조화된 데이터 관련 기술 지침과 설명이 많음
- 15년 전 문서가 완벽하지는 않았지만 지속적으로 진화함
-
SEO 업계의 문제점
- 원본 출처(Schema.org GitHub, W3C 명세)를 읽지 않고 2차 정보에만 의존
- Schema.org에 왜 특정 용어가 추가됐는지, 어떤 사용 사례를 염두에 두고 만들었는지 조사하지 않음
- 10년 이상 전 추가되었으나 실제로 사용되지 않은 용어까지 모두 사용해야 한다고 주장
-
Web Almanac 통계: 상위 50개 클래스만으로 모든 마크업의 약 85%를 차지하며, 이 중 90%는 Google의 리치 스니펫(rich snippet) 기능 때문에만 존재함
- Google의 권장사항과 리치 결과 기능을 제외하면 거의 모든 마크업이 사라짐
FAQPage 감가상각: NLP의 진화
-
NLP는 마크업 없이도 FAQ를 추출 가능
- 질문-답변 패턴은 매우 단순하고 명확하기 때문에 2016년 후반부터 NLP가 마크업 도움 없이 추출 가능
- Google은 FAQPage 마크업이 도입되기 훨씬 전부터 FAQ 페이지 기반 답변을 잘 제공했음
-
FAQPage의 부작용: 웹사이트 운영자들이 좋은 제품 설명을 작성하는 대신 FAQ를 대충 추가하는 '게으른' 관행을 조장
- 2023년 Google이 정부 및 의료 사이트를 제외한 모든 사이트에서 FAQPage를 폐지한 이유
LLM은 구조화된 데이터를 필요로 하지 않음
-
LLM의 특성: 자연 언어(natural language)를 처리하도록 설계됨
- 구조화된 데이터 마크업은 RDF 기반 시스템(삼중항 기반 데이터베이스)을 위해 만들어짐
- 구조화된 데이터와 LLM은 근본적으로 다른 유형의 '기계'
-
미래의 가능성: 에이전트(agent)가 지식 그래프를 탐색할 수 있도록 하는 표준이 개발되고 있음
- GS1, Google 인력, WordLift의 Andrea Volpini 등이 W3C 워크숍(2024년 8월~9월)에서 논의 중
- 지식 그래프 + 에이전트 + LLM 결합 시 오류율 약 80% 감소 가능(실험 결과)
- 하지만 아직 표준화되지 않았음
에이전트 최적화: 아직 이르다
-
현재 권장 사항: 자금이 충분하지 않다면 에이전트 최적화를 피할 것
- 어떤 LLM이 향후 몇 년 생존할지 불명확
- WebMCP, UCP, ACP 같은 표준은 아직 제안 단계일 뿐 확정되지 않음
-
우선순위: 소규모 전자상거래 또는 지역 사업체의 경우
- Shopify 같은 플랫폼에서 안정적으로 Google·Bing과 연동
- Google 비즈니스 프로필을 제대로 설정하고 활용하는 것이 ROI 측면에서 중요
- 표준이 안정화될 때까지 대기하는 것이 현명함
내부 지식 그래프의 실제 가치
-
비즈니스 효과: 검색 가시성 외에 직접적인 수익 창출
- 국제 조직의 인사 데이터베이스: 15,000명 규모 조직에서 올바른 담당자 찾기 자동화
- 콜센터 시스템과의 연동: 전화 기록을 지식 그래프로 변환하여 FAQ를 실시간 업데이트하고 수동 작업 제거
-
LLM이 접근성을 높임
- 과거: 개발자들이 SPARQL 쿼리(RDF의 MySQL 같은 언어)를 수동으로 작성
- 현재: LLM이 자연 언어를 SPARQL 쿼리로 변환하여 그래프 엔지니어 부재 상황을 보완
- 소규모 팀도 LLM 활용으로 복잡한 기술 인프라 없이 지식 그래프 활용 가능
신뢰도와 E-E-A-T 평가: Schema.org 마크업의 한계
-
신뢰는 단일 페이지에서 구축되지 않음
- 검색 엔진은 수집된 웹 전체 정보(집계된 데이터)를 기반으로 신뢰 평가
- 저자 자신의 주장이 신뢰 체인의 마지막 요소
- 웹상의 정보와 도메인 홈페이지 정보가 일치하면 확인 계층 역할: 정보 정확도에 수학적 신뢰 추가
-
마크업의 역할은 제한적
- 신뢰도를 구축하려면 구조적으로 좋은 HTML(semantic HTML)이 중요
- Markdown으로 변환 가능한 시맨틱 HTML은 여러 알고리즘/스크립트가 해석 가능
- SEO 감사에 접근성이 거의 포함되지 않으며, 포함되어도 기술적 수정(alt 텍스트)에만 집중
-
엔티티 최적화의 진화
- 2013~2014년: 구조화된 데이터로 모호한 페이지 구분 (Google 엔지니어도 실험 중)
- 2016~2017년부터: Google NLP 정확도가 85% 이상으로 진전되며 마크업의 ROI 하락
- 현재: 명확한 제품 설명과 자연스러운 문장이 마크업보다 중요
접근성 작성: 저평가된 SEO 요소
-
SEO와 접근성의 분리: 접근성은 대부분의 SEO 감사에 포함되지 않으며, 포함되어도 기술적 측면에만 집중
- 더 중요한 영역: 읽기 쉬운 콘텐츠 작성 (다양한 IQ 수준, 비모국어 사용자 대상)
- 정보 전달을 유지하면서도 간결성 확보
-
의미론적 HTML의 중요성
- 제목이 굵은 텍스트가 아닌 제목 태그(H2, H3)여야 함
- 국제 SEO와 로컬라이제이션 관점에서 접근성 쓰기는 이미 일반적 관행
Schema.org의 미래: 초기화의 가능성
-
Schema.org의 설계 배경: LLM이 존재하지 않던 검색 시대를 위해 설계
- 약 2/3(75% 정도)는 Schema.org 초기 버전(0.9)에서 상정됨
- 각 검색 엔진 대표 1~2명이 미래를 예측하여 용어 추가했으나, 실제로는 2/3가 사용되지 않음
-
예상되는 변화
- Schema.org가 완전히 사라질 가능성은 낮지만, 에이전트 웹에 맞춘 새로운 어휘가 등장할 가능성 높음
- 더 집중된 초점: 내부 목적이 아니라 검색 엔진·LLM이 선호하는 자연 언어 기반 접근
- 특정 사용 사례에 맞춘 마크업: 현재는 Google의 Merchant Center 정렬 작업 중
-
에이전트 웹의 다음 영역
- 현재: 쇼핑(Google이 Merchant Center 마크업 동기화 중)
- 곧: 여행(travel), 음식(food), 의류 등
- Google의 레시피 실험 지속 중, 음식 제공 서비스·메뉴도 영역 확대 중
-
엔티티 동음이의어 해소의 중요성
- 자연 언어 알고리즘도 같은 이름의 다른 엔티티(A와 B)를 구분 못할 수 있음
- sameAs 같은 기본 속성이 여전히 중요: 명확한 자연 언어 표현에 보충 역할
구조화된 데이터 관련 핵심 개념
| 개념 | 설명 | |------|------| | 의미론적 메타데이터 | 구조화된 데이터 마크업의 기술적 정확한 이름 | | RDF(Resource Description Framework) | 삼중항(주어-술어-목적어) 기반의 데이터 표현 | | 지식 그래프 | RDF 기반 데이터베이스(테이블과 달리 다차원 관계 표현 가능) | | SPARQL | RDF 쿼리 언어(MySQL에 해당) | | E-E-A-T | 경험(Experience), 전문성(Expertise), 신뢰도(Authoritativeness), 신뢰성(Trustworthiness) | | 리치 스니펫/리치 결과 | Google 검색 결과에 시각적으로 강조된 정보(별점, 가격, 이벤트 등) | | 에이전트 | LLM 기반 자동 작업 시스템(지식 그래프 탐색 가능) |
핵심 메시지
- 과도한 마크업은 피할 것: '스키마 요정의 마법(schema fairy dust)'처럼 마크업만으로 신뢰도·시각성 향상을 기대하는 것은 환상
- 원본 출처 읽기 필수: Schema.org GitHub, W3C 명세, Google의 기술 문서를 직접 읽고 사용 사례를 이해할 것
- 내부 지식 그래프가 먼저: 검색 가시성보다 비즈니스 프로세스 개선, 데이터 일관성, 운영 효율화가 마크업 투자의 우선순위
- 자연 언어와 시맨틱 HTML이 핵심: 구조화된 데이터보다 명확한 쓰기, 접근성 있는 콘텐츠, 좋은 의미론적 HTML이 검색과 LLM 모두에 더 중요
- 표준 안정화까지 대기: WebMCP, UCP, ACP 같은 에이전트 표준은 아직 제안 단계이므로, 충분한 자금이 없다면 기다릴 것