목차8개 항목
출처와 참고
웹액츄얼리가 번역한 앤디 피츠제럴드(Andy Fitzgerald)의 「로봇과의 대화: 음성 검색과 스마트 에이전트, 구조화된 콘텐츠 사례」(2019.06)을 바탕으로 재구성한 노트다. <data>·<time> 부분은 web.dev의 「Learn HTML」 강좌 중 「Other inline text elements」를 바탕으로 보강했다.
왜 기계가 읽는 웹인가
사람들은 웹 페이지를 직접 열지 않고도 답을 얻는다. 음성 비서에게 "그 병원 몇 시에 닫아?"라고 묻거나, 검색 결과 상단의 요약 답변·지식 패널·AI 답변을 보고 끝낸다. 이때 소프트웨어 에이전트는 페이지를 색인만 하는 것이 아니라 여러 출처의 정보를 합치고(integration) 질문 의도에 맞게 추론(inference)한다.
그래서 화면에서 보기 좋은 페이지만으로는 부족하다. 기계가 콘텐츠 덩어리와 그 관계를 이해하지 못하면 엉뚱한 정보를 정답처럼 내놓는다. 사용자가 어떤 기기·인터페이스로 콘텐츠를 만날지는 콘텐츠 제공자가 아니라 사용자가 정한다.
음성 질의는 입력 질의와 성격이 다르다. 더 길고, 누가·무엇·어디를 묻고, 대화체이고, 더 구체적이다. 구체적인 질문에 짧은 답을 주려면 그 답이 구조화되어 있어야 한다.
구조화된 콘텐츠란
구조화된 콘텐츠(structured content)는 특정 화면에 묶이지 않게 기획·작성·연결해서 어떤 인터페이스에서도 쓸 수 있는 콘텐츠다. 조리법, 상품 설명, 사용법, 의사 프로필 같은 자원을 웹 페이지 한 장이 아니라 의미 있는 덩어리와 그 관계로 만든다.
페이지 중심:
flowchart LR p1["한 장의 HTML 페이지"] --> p2["사람이 읽음"]
구조 중심:
flowchart LR s0["이름 | 진료 과목 | 주소 | 진료 시간 | 평점"] s0 --> s1["웹 페이지"] s0 --> s2["검색 결과의 지식 패널"] s0 --> s3["음성 비서의 한 문장 답"] s0 --> s4["AI 답변의 인용"]
조리법 검색 결과에 단계·사진·조리 시간이 바로 뜨는 것이 대표적인 예다. 사이트가 조리법을 덩어리로 나누고 관계를 기계가 읽게 표시했기 때문이다.
두 단계: 시맨틱 HTML과 링크드 데이터
1. 시맨틱 HTML: 요소 사이의 관계
시맨틱 HTML은 요소가 어떻게 보이는지가 아니라 무엇인지와 서로 어떤 관계인지를 표시한다.
<h1>주차위반 과태료 납부</h1>
<h2>온라인 납부</h2> <p>…</p>
<h2>우편 납부</h2> <p>…</p>
<h2>방문 납부</h2> <p>…</p>이 구조라면 에이전트는 h2 세 개를 h1에 딸린 "납부 방법"으로 읽고, "과태료 어떻게 내?"에 세 가지 방법을 바로 답할 수 있다. 같은 내용을 굵은 글씨(<strong>)와 큰 글자 스타일로만 꾸미면 사람 눈엔 같아 보여도 기계는 관계를 모른다. 한 항목만 <strong>으로 쓰면 그 항목은 답에서 빠진다.
손으로 쓰는 시맨틱 마크업은 이렇게 실수에 약하다. WYSIWYG 편집기는 이론상 시맨틱 HTML을 지원하지만 결과는 편집자 습관에 좌우된다. 그래서 CMS의 콘텐츠 모델 자체가 구조를 강제하게 만드는 것이 확실하다(제목 필드, 방법 목록 필드처럼). 마크업 원칙은 시맨틱 HTML과 문서 구조에 있다.
값 하나에도 기계용 표기를 붙일 수 있다. <time datetime="2026-10-17T19:00">토요일 저녁 7시</time>, <data value="398">9호 신발</data>처럼 사람에게 보이는 글과 기계가 읽을 값을 함께 둔다. 텍스트 요소 전반은 텍스트 의미 요소와 문자 참조에 있다.
2. 링크드 데이터: 현실 세계 개념의 의미
링크드 데이터(linked data)는 웹의 구조화된 데이터를 서로 연결하는 방법이다. 시맨틱 HTML이 "이건 제목이다"를 말한다면, 링크드 데이터는 "이건 의사이고, 이 병원 소속이며, 진료 시간은 이렇다"를 말한다.
공통 어휘는 Google·Microsoft(Bing)·Yahoo·Yandex가 함께 만든 schema.org다. 표기 방식은 마이크로데이터, RDFa, JSON-LD가 있고, Google은 JSON-LD를 권장한다. 마크업과 분리된 <script> 블록이라 관리가 쉽다.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Physician",
"name": "홍길동",
"medicalSpecialty": "Orthopedic",
"worksFor": { "@type": "Hospital", "name": "가나다병원" },
"openingHours": "Mo-Fr 09:00-17:00",
"telephone": "+82-2-000-0000"
}
</script>구조가 없을 때 생기는 일
| 상황 | 결과 |
|---|---|
| 프로필이 링크드 데이터로 표시된 의사 | 검색하면 사진·위치·진료 시간·전화번호·평점이 지식 패널로 뜨고, "몇 시에 닫아?"에 정확히 답한다 |
| 화면용 마크업만 있는 의사 | 에이전트가 정보를 합치지 못한다. 이름이 비슷하고 구조화가 잘된 다른 의사의 병원과 진료 시간을 대신 내놓는다 |
에이전트는 가장 찾기 쉬운 정보를 정답으로 추론하는 경향이 있다. 구조화하지 않은 조직은 자기 정보가 남의 정보로 대체되는 위험을 진다. 병원·정부 기관·대학처럼 정보의 정확성 자체가 목적인 조직일수록 페이지뷰보다 이 정확성이 성과 지표다.
시작하는 법
- 콘텐츠 모델링부터 한다. 어떤 콘텐츠 유형이 있고, 각각 어떤 필드와 관계를 갖는지 정한다.
- CMS가 그 모델을 강제하게 만든다. 자유 편집기 한 칸에 모든 걸 쓰게 하지 않는다.
- 템플릿에서 시맨틱 HTML과 JSON-LD를 자동으로 출력한다.
- Google의 리치 결과 테스트(Rich Results Test)와 Schema Markup Validator로 검증한다.
- 검색 엔진이 특정 리치 결과 유형을 줄이거나 없애는 일도 있다. 리치 결과는 보너스로 보고, 목표는 어떤 소비자에게도 정확한 구조다.
정보 설계자, 콘텐츠 전략가, 개발자, 경험 디자이너가 함께 해야 하는 일이다. 검색 엔진 최적화 전반은 SEO 기초에 있다.
정리
- 웹 콘텐츠의 소비자는 사람만이 아니다. 에이전트는 콘텐츠를 뽑아 합치고 추론한다.
- 구조화된 콘텐츠는 인터페이스에 묶이지 않은 의미 단위의 콘텐츠다.
- 시맨틱 HTML은 요소의 관계를, schema.org 링크드 데이터(JSON-LD)는 현실 개념의 의미를 전한다.
- 구조가 없으면 에이전트가 틀린 답을 정답처럼 낸다.
- 손 마크업보다 CMS 콘텐츠 모델이 구조를 강제하게 만든다.
관련 노트: SEO 기초, 시맨틱 HTML과 문서 구조, 텍스트 의미 요소와 문자 참조, 웹 접근성