환자가 챗GPT에 물으면 옆 병원만 뜨는 진짜 이유 — AI는 우리 병원을 '읽지 못하고' 있다: MedicalOrganization 스키마의 모든 것

AI 검색 시대에 병원이 챗GPT·제미나이 같은 답변형 AI에 인용되려면, 홈페이지에 MedicalOrganization 스키마(의료기관 구조화 데이터)를 갖추는 것이 출발점이다. 스키마는 병원의 이름·위치·진료과목·진료시간 같은 핵심 정보를 AI가 오해 없이 읽을 수 있도록 국제 표준 형식으로 정리한 코드다. 이 글은 왜 이 코드가 AI 인용의 기본기인지, 병원이 어떤 순서로 적용해야 하는지를 실무 단계별로 정리한다.

한 원장이 저녁에 챗GPT를 열고 환자 입장에서 물어봤다고 하자. '○○동에서 임플란트 상담 잘해주는 치과 알려줘.' 화면에는 옆 건물 치과가 이름과 위치, 진료 특징까지 정돈된 문장으로 소개된다. 우리 병원은 언급조차 없다. 개원은 우리가 먼저 했고, 포털 광고비도 우리가 더 쓴다. 그런데 왜 AI는 옆 병원만 아는 것처럼 답할까.

이 장면의 원인은 대개 실력도, 광고 예산도 아니다. 'AI가 읽을 수 있는 형태로 우리 병원 정보가 존재하는가'라는, 눈에 보이지 않는 기술적 기본기에서 갈린다. 그 기본기의 첫 번째 항목이 바로 의료기관 스키마다.

AI는 우리 병원 홈페이지를 사람처럼 '보지' 않는다

환자는 홈페이지를 눈으로 본다. 예쁜 배너, 원장 인사말 이미지, 팝업 속 진료시간 안내까지 한눈에 들어온다. 그러나 AI는 홈페이지를 '본다'기보다 '읽는다'. 웹페이지의 글자 데이터를 수집해 해석할 뿐, 이미지 안에 그려진 글씨나 팝업 속 안내문은 사실상 존재하지 않는 정보로 취급되는 경우가 많다.

여기서 손실이 시작된다. 진료시간을 이미지 배너로만 올려둔 병원은, AI 입장에서는 '진료시간을 알 수 없는 병원'이다. 야간 진료를 하는지, 토요일에 여는지 확인할 수 없으니 '토요일에 진료하는 ○○동 병원'이라는 질문의 답변 후보에서 조용히 빠진다. 환자는 거절당한 적도 없이, 우리 병원의 존재를 모른 채 다른 곳으로 간다.

반대로 기회의 크기도 여기서 나온다. 아직 많은 병원이 홈페이지를 '사람 눈'에만 맞춰 만들어 두었다. AI가 읽을 수 있는 형태로 정보를 정리해 두는 것만으로도, 같은 지역 안에서 '확인 가능한 정보가 있는 병원'이라는 위치를 선점할 수 있다. 비유하자면, 모두가 명함 없이 악수만 하고 다니는 모임에서 혼자 명함을 준비해 간 것과 같다.

스키마란 무엇인가 — AI에게 건네는 '표준 서식 명함'

스키마(Schema)는 검색엔진과 AI가 함께 쓰기로 약속한 정보 표기 규격이다. 국제적으로 schema.org라는 공통 사전이 있고, 여기에 '병원', '의사', '진료과목', '주소' 같은 항목이 미리 정의되어 있다. 이 규격에 맞춰 홈페이지 코드 안에 정보를 적어 두는 것을 '구조화 데이터를 넣는다'고 말한다.

병원 실무에 익숙한 비유로 말하면, 스키마는 보험 청구 서식과 같다. 진료 내용을 아무리 자세히 적어도 정해진 서식이 아니면 심사 단계에서 읽히지 않듯이, 병원 정보도 표준 서식에 담겨야 기계가 항목별로 정확히 이해한다. '연세'가 병원 이름인지 나이를 뜻하는지, '9시'가 오전인지 오후인지를 서식이 대신 확정해 주는 셈이다.

이것이 AEO(Answer Engine Optimization, 답변엔진최적화)의 출발점이다. AEO는 검색 결과 목록에서 순위를 올리는 기존 SEO(검색엔진최적화)와 달리, AI가 생성하는 '답변 문장' 안에 우리 병원이 인용되도록 만드는 작업이다. 답변에 인용되려면 먼저 AI가 우리 병원을 정확한 사실 단위로 이해하고 있어야 하고, 그 이해의 재료가 구조화 데이터다.

왜 하필 MedicalOrganization인가 — 의료기관 전용 서식의 힘

schema.org에는 일반 가게용 서식(LocalBusiness)도 있지만, 의료기관 전용 서식인 MedicalOrganization과 그 하위 유형(치과 Dentist, 의원·클리닉 MedicalClinic, 의사 Physician 등)이 따로 마련되어 있다. 전용 서식을 쓰면 일반 서식에 없는 항목, 예컨대 진료 분야(medicalSpecialty), 제공 진료(availableService), 소속 의료진 정보까지 규격에 맞게 담을 수 있다.

이 차이가 중요한 이유는 두 가지다. 첫째, 정확한 매칭이다. '○○정형외과의원'처럼 비슷한 이름의 기관이 전국에 여럿일 때, 주소·전화번호·진료 분야가 서식으로 묶여 있으면 AI가 우리 병원을 다른 기관과 혼동할 가능성이 줄어든다. 둘째, 확인 가능성이다. 답변형 AI는 일반적으로 사실 확인이 가능한 출처를 선호하는 경향이 있는데, 항목별로 정리된 기관 정보는 AI가 교차 확인하기 가장 좋은 형태다.

다만 기대 수준은 정확히 잡아야 한다. 스키마는 순위를 보장하는 마법이 아니라 '출전 자격'에 가깝다. 서식을 갖췄다고 반드시 인용되는 것은 아니지만, 서식조차 없으면 인용 후보에 오르는 일 자체가 어려워진다. 기본기라는 말은 그래서 붙는다.

적용 1단계 — 코드보다 먼저, 병원 정보 인벤토리 통일

스키마 작업의 절반은 코드가 아니라 정보 정리다. 스키마에 적을 내용이 채널마다 다르면, 오히려 AI에게 혼란만 준다. 시작 전에 아래 항목을 한 문서로 정리하고, 모든 채널의 표기를 통일하라.

1. 병원 공식 명칭: 홈페이지·네이버 지도·구글 지도·블로그의 표기를 한 글자까지 통일한다('의원' 포함 여부, 띄어쓰기 포함).
2. 주소: 도로명 주소 기준으로 층·호수까지 확정한다.
3. 대표 전화번호: 마케팅용 가상번호가 여러 개라면 대표번호 하나를 기준으로 정한다.
4. 진료시간: 요일별 시간과 점심시간, 야간·공휴일 진료 여부까지 문장이 아닌 표 형태로 정리한다.
5. 진료과목과 의료진: 표방 과목, 의료진 이름과 면허 기반 직함을 정리한다.
6. 공식 URL: 홈페이지, 지도 페이지, 블로그 주소를 확정한다.

가장 흔한 실수는 표기 불일치다. 홈페이지에는 '스마일치과의원', 지도에는 '스마일 치과', 블로그에는 '○○동 스마일치과'로 흩어져 있으면, 기계는 이것이 같은 병원이라는 확신을 갖기 어렵다. 사람에게는 사소한 차이가 기계에게는 서로 다른 기관 세 곳으로 읽힐 수 있다.

적용 2단계 — JSON-LD로 작성해 홈페이지에 심는다

정보가 정리됐다면 이제 서식에 옮겨 적을 차례다. 현재 가장 널리 쓰이는 방식은 JSON-LD라는 형식이다. 홈페이지 화면 디자인은 전혀 건드리지 않고, 코드 상단(head 영역)에 정보 꾸러미를 한 덩어리 얹는 방식이라 도입 부담이 작다.

실행 순서는 다음과 같다.

1. 우리 병원에 맞는 유형을 고른다. 치과는 Dentist, 일반 의원은 MedicalClinic, 병원급은 Hospital처럼 가장 구체적인 하위 유형을 선택한다.
2. 1단계에서 정리한 인벤토리를 name(명칭), address(주소), telephone(전화), openingHoursSpecification(진료시간), medicalSpecialty(진료 분야), url(홈페이지) 항목에 대응시켜 작성한다.
3. 홈페이지를 직접 관리하지 않는다면 제작사에 이렇게 요청한다. '첨부한 병원 정보로 MedicalOrganization 유형의 JSON-LD 구조화 데이터를 만들어 전체 페이지 head에 넣어 주세요.' 이 한 문장이면 실무자는 알아듣는다.

이 단계의 핵심 주의점은 하나다. 홈페이지 화면에 없는 내용을 스키마에만 몰래 넣지 않는 것. 구조화 데이터는 화면에 보이는 정보를 기계용으로 번역한 것이어야 하며, 화면과 코드가 다르면 신뢰도에 오히려 해가 될 수 있다. 진료시간이 화면에 이미지로만 있다면, 이번 기회에 글자로도 함께 표기하는 편이 안전하다.

적용 3단계 — 넣었다고 끝이 아니다, 검증과 유지관리

스키마는 심는 것보다 살아 있게 유지하는 것이 어렵다. 삽입 직후에는 구글이 무료로 제공하는 리치 결과 테스트나 스키마 검증 도구(Schema Markup Validator)에 홈페이지 주소를 넣어, 오류 없이 인식되는지 반드시 확인한다. 코드 한 글자 오타로 서식 전체가 무효 처리되는 일이 실제로 흔하다.

이후에는 갱신 체계를 만든다. 진료시간 변경, 의료진 합류·퇴사, 이전 개원처럼 정보가 바뀌는 순간이 스키마가 낡는 순간이다. 화면 공지는 고쳤는데 스키마는 예전 그대로라면, AI는 옛날 정보를 사실로 인용할 수 있다. 분기에 한 번, 인벤토리 문서와 실제 스키마를 대조하는 점검 일정을 잡아 두는 것을 권한다.

특히 홈페이지 리뉴얼이 최대 고비다. 새 홈페이지로 갈아타는 과정에서 기존 스키마가 통째로 사라지는 사고가 자주 일어난다. 리뉴얼 계약서나 요청사항에 '기존 구조화 데이터 이전'을 명시하는 것만으로 이 손실을 막을 수 있다.

스키마를 넣고도 효과를 못 보는 병원들의 공통점

서식을 갖췄는데도 AI 답변에서 존재감이 없는 병원들을 살펴보면 패턴이 반복된다. 다음 목록에서 우리 병원에 해당하는 것이 있는지 점검해 보라.

• 핵심 정보가 여전히 이미지 속에만 있다 — 스키마와 대조할 본문 글자가 없으면 반쪽짜리다.
• 채널별 명칭·전화번호가 제각각이다 — 서식이 아무리 정확해도 바깥 정보가 흔들리면 신뢰가 깎인다.
• 스키마에 홍보 문구를 넣었다 — 서식은 사실 기재란이다. 최상급 표현이나 효과 단정은 의료광고 규정 관점에서도 위험하고, 기계에게도 무의미하다.
• 스키마만 있고 콘텐츠가 없다 — 스키마는 명함이고, 진료 철학과 안내를 담은 본문 콘텐츠는 실력 증명이다. 명함만 있는 회사와는 거래하지 않는다.
• 넣은 뒤 한 번도 검증·갱신하지 않았다 — 낡은 서식은 없는 것보다 나쁠 수 있다.

일반화된 예시를 하나 들면, 지역에서 오래된 A의원과 개원 2년 차 B의원이 있을 때 AI가 B의원을 더 자주 언급하는 경우가 있다. 차이는 연혁이 아니라, B의원은 기계가 읽을 수 있는 정보와 글자로 된 안내 콘텐츠를 갖췄다는 데 있는 경우가 많다. AI의 세계에서 병원의 나이는 '읽히는 정보의 양과 정확성'으로 다시 계산된다.

오늘 당장 시작하는 우선순위 — 4주 실행 체크리스트

모든 것을 한 번에 하려다 아무것도 못 하는 것이 최악이다. 순서는 이렇게 잡으면 된다.

1. 1주 차: 병원 정보 인벤토리 문서를 만들고, 홈페이지·지도·블로그의 표기를 통일한다.
2. 2주 차: 이미지로만 존재하는 진료시간·오시는 길 정보를 홈페이지에 글자로도 추가한다.
3. 3주 차: 제작사에 MedicalOrganization(또는 하위 유형) JSON-LD 삽입을 요청하고, 검증 도구로 확인한다.
4. 4주 차: 분기 점검 일정을 달력에 등록하고, 다음 단계인 진료 안내 콘텐츠 정비 계획을 세운다.

그리고 시작 전에 한 가지, 현재 상태를 아는 것이 순서상 가장 먼저다. 지금 우리 병원이 AI에게 어떻게 읽히고 있는지, 스키마가 있는지 없는지, 있다면 오류는 없는지를 확인하면 위 4주 계획의 출발점이 정확해진다. AI메디랩의 무료 진단은 이 현재 상태를 항목별로 확인해 주는 도구이니, 계획을 세우기 전 점검용으로 활용하면 시행착오를 줄일 수 있다. 환자가 AI에게 묻는 시대는 이미 시작됐고, 먼저 읽히는 병원이 먼저 선택받는다.