구조화 데이터는 병원명, 주소, 진료시간처럼 사람이 화면에서 읽는 정보를 기계가 읽을 수 있는 형식으로 한 번 더 적어두는 표기입니다. 사람은 "평일 09:30 ~ 18:30"이라는 문장을 보고 진료시간임을 알지만, 기계는 그 문장이 진료시간인지 주차 안내인지 구분하기 어렵습니다. 구조화 데이터는 그 모호함을 없애는 작업이고, 그래서 검색엔진과 AI가 병원 정보를 인용할 때 바탕이 됩니다.
왜 병원에 특히 필요한가요?
환자의 질문에는 거의 항상 지역과 시간이 붙습니다. "지금 문 연 치과", "토요일 진료하는 치과"처럼요. 이런 질문에 답하려면 기계가 병원의 위치와 진료시간을 확정적으로 알고 있어야 합니다. 본문에 글로만 적혀 있으면 읽히지 않거나 잘못 읽힐 수 있습니다.
또 하나는 일관성 문제입니다. 홈페이지, 네이버 플레이스, 블로그의 진료시간이 서로 다르면 어느 쪽도 신뢰받기 어렵습니다. 구조화 데이터는 "이 병원의 공식 정보는 이것"이라고 홈페이지에서 명시하는 기준점 역할을 합니다.
무엇부터 적용하나요?
Schema.org에는 수백 가지 유형이 있지만, 병원이 실질적으로 쓰는 것은 많지 않습니다. 아래 두 가지부터 시작하면 충분합니다.
| 유형 | 무엇을 설명하나 | 어디에 넣나 |
|---|---|---|
MedicalClinic 또는 Dentist |
병원 자체 — 이름, 주소, 전화, 진료시간, 홈페이지 주소 | 메인 페이지 또는 병원 소개 페이지 |
FAQPage |
그 페이지에 실제로 적힌 자주 묻는 질문과 답변 | FAQ가 들어 있는 진료·안내 페이지 |
Dentist는 MedicalClinic보다 구체적인 유형이라 치과라면 이쪽이 더 정확합니다. 여기에 더해 글마다 작성 주체와 작성일을 나타내는 Article, 화면의 현재 위치를 나타내는 BreadcrumbList 정도를 추가하면 기본은 갖춰집니다.
작성 예시
JSON-LD 형식으로 페이지 안에 스크립트 한 덩어리를 넣는 방식이 가장 널리 쓰입니다.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Dentist",
"name": "OO치과의원",
"url": "https://example.co.kr",
"telephone": "+82-2-000-0000",
"address": {
"@type": "PostalAddress",
"streetAddress": "OO로 00, 3층",
"addressLocality": "OO구",
"addressRegion": "서울특별시",
"addressCountry": "KR"
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "09:30",
"closes": "18:30"
},
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": "Saturday",
"opens": "09:30",
"closes": "13:00"
}
]
}
</script>
점심시간처럼 중간에 쉬는 구간이 있다면 오전과 오후를 각각의 OpeningHoursSpecification 항목으로 나눠 적습니다. 휴진일은 적지 않는 것이 아니라, 그날이 목록에 없으면 진료하지 않는 것으로 해석됩니다.
적용할 때 자주 틀리는 것
- 화면에 없는 정보를 넣는다 — 구조화 데이터는 페이지에 있는 내용을 다시 적는 것이지 추가하는 것이 아닙니다. FAQ 스키마를 넣었는데 화면에는 그 질문이 없으면 정책 위반으로 판단될 수 있습니다.
- 정보가 바뀌어도 함께 고치지 않는다 — 진료시간을 변경하면서 본문만 고치고 스키마는 그대로 두면, 기계가 읽는 값은 예전 그대로입니다. 가장 흔한 사고입니다.
- 전화번호 형식이 제각각이다 — 국가번호를 포함한 국제 표기(
+82-2-...)로 통일해두면 기계가 해석하기 쉽습니다. - 여러 지점을 한 스키마에 몰아넣는다 — 분원이 있다면 지점별로 페이지와 스키마를 나누는 편이 명확합니다.
핵심 정리: 구조화 데이터는 새로운 정보를 만드는 작업이 아니라, 이미 있는 정보를 오해 없이 전달하는 작업입니다. 화면과 스키마가 항상 같은 값을 가리키게 유지하는 것이 전부입니다.
적용했는지 어떻게 확인하나요?
- 문법 검증 — 구글의 리치 결과 테스트나 Schema.org 검증 도구에 페이지 주소를 넣으면 유형이 제대로 인식되는지, 누락된 필수 항목이 있는지 확인할 수 있습니다.
- 검색엔진 인식 확인 — Google Search Console의 향상(Enhancements) 보고서에서 검색엔진이 실제로 읽어간 구조화 데이터와 오류를 확인합니다. 반영에는 수집 주기만큼 시간이 걸립니다.
- 값 대조 — 검증 도구에 표시된 주소·전화·진료시간을 홈페이지 화면, 네이버 플레이스와 하나씩 비교합니다. 문법이 맞아도 값이 틀리면 의미가 없습니다.
세 번째가 가장 자주 생략되는데, 실제 문제는 대부분 여기서 발견됩니다.
잇클의 관점
구조화 데이터는 한 번 넣고 끝나는 설정이 아니라 정보가 바뀔 때마다 같이 따라가야 하는 관리 대상입니다. 잇클은 그래서 스키마 적용 자체보다 "누가, 언제, 어떤 기준으로 값을 맞추는가"를 먼저 정하는 편입니다.
병원·지점·의료진 정보가 채널 간에 어긋나지 않도록 한곳에서 관리하고, AI 답변에서 실제로 어떻게 읽히는지 측정하는 일은 GENRANK-OS가 다루는 영역입니다. 구조화 데이터가 AI 검색 노출과 어떻게 연결되는지는 GEO란 무엇이고, 병원이 AI 답변에 인용되려면 무엇을 준비해야 할까?에서, 서비스 구성은 GEO·AEO 마케팅에서 함께 보실 수 있습니다.
자주 묻는 질문
Q.구조화 데이터를 넣으면 검색 순위가 오르나요?+
순위를 직접 올려주는 장치로 보기는 어렵습니다. 검색엔진이 페이지의 정보를 정확히 이해하도록 돕고, 특정 형태의 검색 결과에 표시될 자격을 갖추게 하는 역할에 가깝습니다. 어떤 형태로 표시되는지는 검색엔진 정책에 따라 바뀌므로 표시 자체를 목표로 삼기보다 정보를 정확히 기술하는 데 집중하는 편이 낫습니다.
Q.홈페이지 제작 업체에 맡겨야 하나요, 직접 넣을 수 있나요?+
JSON-LD 형식은 페이지에 스크립트 한 덩어리를 추가하는 방식이라 제작 업체에 요청하면 대개 어렵지 않게 반영됩니다. 다만 진료시간이나 주소가 바뀔 때 함께 수정되어야 하므로, 누가 관리할지를 먼저 정해두는 것이 중요합니다.
Q.화면에 없는 정보를 구조화 데이터에만 넣어도 되나요?+
권장되지 않습니다. 구조화 데이터는 페이지에 실제로 있는 내용을 기계가 읽기 쉽게 다시 적는 것이 원칙입니다. 화면에 없는 내용을 표기하면 검색엔진 정책 위반으로 판단될 수 있고, 환자에게도 사실과 다른 정보가 전달될 수 있습니다.
잇클 에디터 · 주식회사 잇클
병원을 위한 AI 솔루션과 AI 마케팅을 만드는 잇클이 현장에서 얻은 인사이트를 정리합니다. 의료광고 관련 내용은 일반 정보이며, 개별 사안은 전문가 검토를 권장합니다.