챗GPT가 옆 병원만 추천하는 진짜 이유 — 우리 홈페이지에 없는 ‘기계용 명함’, MedicalOrganization 스키마

병원이 챗GPT·제미나이 같은 AI 답변에 등장하려면, AI가 읽을 수 있는 형식으로 병원 정보를 정리한 구조화 데이터, 그중에서도 의료기관 전용 유형인 MedicalOrganization 스키마가 홈페이지에 있어야 합니다. 이 글은 스키마가 없을 때 병원이 어떻게 AI 답변에서 누락되는지, 어떤 항목을 어떤 순서로 적용해야 하는지를 원장과 마케팅 담당자가 오늘 바로 실행할 수 있는 단계로 설명합니다.

요즘 원장들이 가장 많이 묻는 질문이 있습니다. 환자가 챗GPT에 ‘○○동에서 임플란트 잘하는 치과’라고 물으면 왜 바로 옆 건물 치과만 이름이 나오느냐는 것입니다. 홈페이지는 몇 년 전 수천만 원을 들여 새로 만들었고, 네이버 블로그도 꾸준히 올리고, 플레이스 리뷰도 나쁘지 않습니다. 그런데 AI는 우리 병원을 마치 존재하지 않는 것처럼 건너뜁니다. 더 억울한 경우도 있습니다. AI가 우리 병원을 언급하기는 하는데, 이미 바뀐 옛 진료시간을 안내하거나, 퇴사한 의료진 이름을 대표 원장처럼 소개하는 것입니다.

원인은 대개 홍보량이 아닙니다. AI는 사람처럼 홈페이지를 ‘보지’ 않습니다. 배너 이미지에 큼직하게 적힌 병원명과 진료시간을 AI는 신뢰할 수 있는 정보로 읽지 못합니다. AI가 확신을 갖고 우리 병원을 답변에 넣으려면, 기계가 오해 없이 읽는 표준 형식으로 ‘이 페이지의 주체는 의료기관이고, 이름·주소·진료과목·진료시간은 이것이다’라고 적어 두어야 합니다. 그것이 구조화 데이터이고, 의료기관에 맞는 유형이 MedicalOrganization 스키마입니다. 이 글은 그 개념부터 적용 절차, 흔한 실수까지를 순서대로 다룹니다.

AI는 홈페이지를 ‘보는’ 것이 아니라 ‘해석’한다

먼저 용어를 정리하겠습니다. 구조화 데이터(structured data)란 웹페이지 안에 사람 눈에는 보이지 않지만 기계가 읽도록 만든 정보 꾸러미입니다. 스키마(schema.org)는 구글·마이크로소프트 등이 함께 만든 공용 어휘집으로, ‘병원’, ‘주소’, ‘진료시간’ 같은 개념을 전 세계 검색엔진이 같은 단어로 이해하게 해 줍니다. JSON-LD는 그 어휘를 페이지에 적어 넣는 작성 방식 중 가장 권장되는 형식으로, 화면에 보이는 본문과 분리된 스크립트 블록 하나로 들어갑니다. 그리고 AEO(Answer Engine Optimization, 답변엔진 최적화)는 검색 결과 목록 어딘가에 뜨는 것을 넘어 AI가 내놓는 ‘답변 문장’ 자체에 우리 병원이 들어가게 만드는 작업입니다.

왜 이것이 중요할까요. AI는 불확실한 정보를 다룰 때 틀린 답을 하기보다 ‘언급하지 않는’ 쪽을 택하는 경향이 있습니다. 홈페이지에서 병원의 정체를 확신하지 못하면 그 병원은 답변 후보에서 조용히 제외됩니다. 반대로 지금 대부분의 동네 병·의원 홈페이지에는 이 정보가 비어 있거나 틀려 있습니다. 먼저 정확히 적어 둔 병원이 같은 지역, 같은 진료과 안에서 상대적으로 유리한 위치를 차지하는 구조입니다.

비유하자면 명함입니다. 사람에게 주는 명함은 디자인과 종이 질감이 중요하지만, 기계에게 주는 명함은 칸이 정해진 서식입니다. 지금까지 병원들은 사람용 명함(홈페이지 디자인)에만 투자했고, 기계용 명함은 아예 만들지 않았습니다. AI 검색 시대에는 두 번째 명함이 없으면 첫 번째 명함을 보여줄 기회조차 얻지 못합니다.

MedicalOrganization — 일반 가게가 아니라 ‘의료기관’으로 분류되는 이유

스키마에는 계층이 있습니다. 가장 넓은 조직(Organization) 아래 동네 상점(LocalBusiness)이 있고, 의료기관을 위한 별도 유형이 MedicalOrganization입니다. 그 아래로 병원급(Hospital), 의원급(MedicalClinic), 치과(Dentist), 의사 개인(Physician) 같은 하위 유형이 갈라집니다. 홈페이지 제작사가 흔히 넣어 주는 것은 가장 넓은 Organization이나 LocalBusiness입니다. 틀린 것은 아니지만, AI 입장에서는 ‘여기가 식당인지 세탁소인지 내과인지’를 스키마만으로는 알 수 없는 상태입니다.

의료 전용 유형을 써야 하는 이유는 담을 수 있는 칸이 다르기 때문입니다. 진료과목(medicalSpecialty), 제공 서비스(availableService), 신규 환자 접수 여부(isAcceptingNewPatients) 같은 속성은 일반 상점 유형에는 없습니다. 환자가 AI에게 ‘○○동 소아과 중 토요일 진료하는 곳’을 물을 때, AI는 ‘소아과’라는 진료과목 정보와 ‘토요일’ 진료시간 정보를 구조적으로 가진 병원을 우선 후보로 삼을 수 있습니다. 그 칸이 비어 있으면 본문 어딘가에서 추측해야 하고, 추측은 곧 누락으로 이어집니다.

실행은 단순합니다. 우리 병원에 맞는 하위 유형 하나를 고르는 것부터 시작합니다. 의원급은 MedicalClinic, 치과는 Dentist, 병원급은 Hospital, 원장 개인 소개 페이지는 Physician을 씁니다. 흔한 실수는 제작사 템플릿이 모든 고객 사이트에 똑같은 유형을 일괄 삽입하는 경우입니다. 심한 경우 다른 병원 이름이 그대로 남아 있기도 합니다. 일반화된 예를 들면, ‘강남 ○○내과’ 홈페이지가 LocalBusiness로만 표시되어 있다면 AI는 그곳이 내과라는 명시적 근거를 스키마에서 얻지 못합니다. 본문에 ‘내과’라는 단어가 수십 번 나와도 ‘이 기관의 진료과목은 내과다’라는 선언과는 무게가 다릅니다.

우리 병원이 AI 답변에서 빠지는 다섯 가지 진단 포인트

스키마를 넣기 전에 왜 빠지는지부터 확인해야 합니다. 현장에서 반복적으로 보이는 원인은 다섯 가지로 압축됩니다.

1. 스키마가 아예 없다. 가장 흔합니다. 홈페이지는 멀쩡해 보여도 기계용 명함이 존재하지 않는 상태입니다.
2. 있지만 유형이 틀리다. Organization이나 WebSite 유형만 있고 의료기관 정보가 없습니다. ‘사이트가 있다’는 사실만 알릴 뿐 ‘무슨 병원인지’는 말하지 않습니다.
3. 홈페이지·네이버 플레이스·구글 비즈니스 프로필 정보가 서로 다르다. 병원명 띄어쓰기, 주소 표기, 전화번호가 플랫폼마다 제각각이면 AI는 같은 기관인지 확신하지 못합니다. 이름·주소·전화를 묶어 NAP라고 부르는데, 이 셋의 일치가 신뢰의 기본입니다.
4. 핵심 정보가 이미지나 PDF에만 있다. 진료시간표를 이미지로, 의료진 소개를 PDF로 올린 경우입니다. 기계가 읽을 수 없는 자리에 가장 중요한 정보가 숨어 있는 셈입니다.
5. 페이지 자체를 수집하지 못한다. 수집 차단 설정, 로그인 뒤에 숨은 페이지, 스크립트로만 그려지는 본문은 AI 수집기가 비어 있는 페이지로 인식할 수 있습니다.

점검은 어렵지 않습니다. 구글의 리치 결과 테스트나 스키마 검증 도구에 홈페이지 주소를 넣으면 몇 분 안에 스키마 유무와 유형, 오류가 표시됩니다. 결과 화면을 캡처해 두면 이후 개선 전후를 비교하는 기준이 됩니다. 이 단계에서 ‘감지된 항목 없음’이 나온다면 그것이 우리 병원이 AI 답변에서 빠지는 첫 번째 이유일 가능성이 큽니다.

반드시 채워야 할 핵심 속성 — 적어도 이 열 가지

MedicalOrganization 계열 스키마에 넣을 수 있는 속성은 수십 개지만, 전부 채울 필요는 없습니다. AI 답변에서 실제로 작동하는 항목부터 정확하게 채우는 것이 우선입니다.

• name·alternateName: 정식 병원명과 영문명, 환자들이 부르는 약칭. 플레이스·프로필과 글자 단위로 같아야 합니다.
• url·telephone: 대표 주소와 대표 전화. 전화번호는 한 가지 형식으로 통일합니다.
• address: 한 줄 문자열이 아니라 시·구·도로명·우편번호로 구조를 나눈 주소(PostalAddress) 형식으로 넣습니다.
• geo·hasMap: 위도·경도와 지도 링크. ‘근처’ 질문에 대응하는 근거가 됩니다.
• openingHoursSpecification: 요일별 진료시간과 점심시간, 휴진일. ‘토요일 진료’, ‘야간 진료’ 질문에 가장 직접적으로 작동합니다.
• medicalSpecialty: 진료과목. 표준 값 목록에서 고릅니다.
• image·logo: 실제로 열리는 이미지 주소. 깨진 링크는 신뢰를 깎습니다.
• sameAs: 네이버 플레이스, 구글 비즈니스 프로필, 유튜브, 블로그 주소. ‘이 모든 곳이 같은 기관이다’라고 연결하는 고리입니다.
• isAcceptingNewPatients: 신규 환자 접수 여부. 간단하지만 비어 있는 병원이 대부분입니다.
• founder·employee(Physician): 대표 원장과 의료진을 사람 유형으로 연결합니다. AI가 ‘사람과 기관’을 묶어 이해하게 됩니다.

여기서 주의할 점이 있습니다. 스키마는 광고 문구가 아니라 사실 선언입니다. 진료과목과 제공 서비스는 실제 운영 범위 그대로 적어야 하고, ‘최고’, ‘완치’, ‘부작용 없음’ 같은 표현은 스키마에도 넣지 않습니다. 검색엔진 가이드라인 위반일 뿐 아니라 의료광고 규제 관점에서도 위험합니다. 흔한 실수는 주소를 한 줄로 뭉쳐 넣기, 전화번호를 페이지마다 다른 형식으로 적기, 진료시간을 ‘문의 바람’으로 처리하기입니다. 세 가지 모두 AI에게는 ‘확인 불가’로 읽힙니다.

오늘 당장 적용하는 6단계 실행 절차

개념을 이해했다면 실행은 아래 순서로 진행합니다. 대부분 제작사나 내부 담당자에게 요청하는 일이고, 원장이 직접 해야 하는 것은 정보 원본을 확정하는 2단계입니다.

1. 현황 진단: 검증 도구에 홈페이지 주소를 넣고 결과를 캡처합니다. 메인 페이지뿐 아니라 진료안내·의료진 페이지도 각각 확인합니다.
2. 정보 원본 확정: 병원명, 주소, 전화, 요일별 진료시간, 진료과목, 현재 재직 의료진 명단을 문서 하나에 정리합니다. 이 문서를 네이버 플레이스·구글 비즈니스 프로필과 대조해 글자 단위로 일치시킵니다. 이 문서가 앞으로 모든 채널의 단일 기준이 됩니다.
3. 유형 선택과 JSON-LD 작성: 우리 병원에 맞는 하위 유형을 골라 2단계 정보로 JSON-LD를 작성하고 페이지 헤드 영역에 삽입합니다. 생성 도구를 써도 되지만, 결과물은 반드시 검증 도구로 다시 확인합니다.
4. 의료진 페이지에 Physician 연결: 원장과 의료진 각각에 이름, 전문과목, 소속 기관을 연결합니다. 사실로 확인되는 경력만 넣습니다.
5. 검증과 색인 요청: 리치 결과 테스트를 통과한 뒤 구글 서치콘솔과 네이버 서치어드바이저에서 해당 페이지의 색인을 요청합니다. 넣기만 하고 요청하지 않으면 반영이 늦어집니다.
6. 변경 관리 루틴: 진료시간이나 의료진이 바뀌면 스키마도 같은 날 수정합니다. 월 1회 검증 도구로 재점검하는 일정을 캘린더에 고정합니다.

제작사에 보낼 요청 문구 예시: ‘메인 페이지 헤드에 MedicalClinic(치과는 Dentist) 유형의 JSON-LD를 넣어 주세요. 첨부한 정보 문서와 글자 단위로 동일해야 하고, 주소는 PostalAddress 구조, 진료시간은 요일별 openingHoursSpecification으로 작성해 주세요. 의료진 페이지에는 각 의료진을 Physician 유형으로 연결하고, 완료 후 리치 결과 테스트 통과 화면을 보내 주세요.’

한 가지 원칙을 지켜야 합니다. 스키마의 내용은 화면에 보이는 내용과 일치해야 합니다. 화면에는 없는 정보를 스키마에만 넣는 것은 검색엔진이 스팸으로 분류하는 대표적 패턴입니다. 진료시간을 스키마에 넣었다면 화면에도 텍스트로 보여야 합니다. 이 기회에 이미지로만 있던 진료시간표를 글자로 바꾸면 사람과 기계 모두에게 좋아집니다.

실무에서 가장 자주 보는 실수 일곱 가지

스키마를 넣었는데도 효과가 없다는 병원을 점검해 보면 대부분 아래 중 하나에 걸립니다.

• 템플릿 복사 흔적: 다른 병원 이름이나 주소가 남아 있는 경우. AI는 이를 모순된 정보로 읽습니다.
• 여러 지점을 스키마 하나에 몰아 넣기: 지점이 셋이면 지점별 페이지와 스키마를 분리하고 본원 스키마에서 각 지점을 연결해야 합니다. 일반화된 예로, 지점 세 곳 병원이 본원 주소만 넣어 두면 AI는 분원 근처 환자에게도 본원만 안내합니다.
• 진료시간 변경 미반영: 화면은 고쳤는데 스키마는 옛 값인 경우. AI가 옛 진료시간을 자신 있게 답하는 원인입니다.
• 깨진 로고·이미지 주소: 사이트 개편 때 경로가 바뀌어 404가 나는 경우가 흔합니다.
• sameAs 공란: 네이버 플레이스와 홈페이지가 같은 기관이라는 연결이 끊긴 상태입니다. 리뷰와 평점 같은 외부 신호가 우리 병원으로 모이지 않습니다.
• 퇴사 의료진 잔존: 의료진 페이지와 스키마에 이미 떠난 원장이 남아 있으면 AI가 그 이름으로 병원을 소개합니다.
• 과장 표현 삽입: 서비스 설명에 효능을 단정하는 문구를 넣는 경우. 가이드라인 위반과 의료광고 위험을 동시에 떠안습니다.

이 실수들의 공통점은 ‘한 번 넣고 끝’이라는 태도입니다. 스키마는 설치물이 아니라 관리 대상입니다. 정보가 바뀌는 순간 스키마도 바뀌어야 하며, 그래서 2단계에서 만든 정보 원본 문서와 변경 관리 루틴이 스키마 코드 자체보다 중요합니다.

스키마는 출발점 — 그 위에 무엇을 쌓아야 AI가 ‘인용’하는가

정확히 짚어야 할 것이 있습니다. MedicalOrganization 스키마는 AI에게 ‘우리가 누구인지’를 확인시키는 신원 확인 단계입니다. 신원이 확인되어야 후보에 오르지만, 실제로 답변에 인용되느냐는 그다음에 쌓는 내용이 결정합니다. 스키마를 넣는 것만으로 당장 지역 1순위가 되는 것은 아니며, 반영 기간도 경우에 따라 수주에서 수개월까지 다릅니다. 스키마의 본질은 누락과 오류를 제거해 출발선에 서는 것입니다.

그 위에 쌓을 첫 번째 층은 질문과 답 형식의 콘텐츠입니다. 환자가 실제로 묻는 것, 즉 주차 가능 여부, 초진 절차, 예약 방법, 보험 적용 범위 안내, 진료 전 준비물 같은 비의료 정보를 홈페이지에 글자로 정리하고 FAQPage 스키마로 묶습니다. AI는 질문에 답하는 도구이므로, 질문 형태로 정리된 정보를 가장 쉽게 가져다 씁니다. 두 번째 층은 의료진 소개입니다. 사실로 확인되는 학력·경력·소속 학회를 Physician 유형과 함께 텍스트로 제공하면 검색엔진이 중시하는 경험·전문성·권위·신뢰(E-E-A-T) 신호가 강화됩니다. 세 번째 층은 외부 신호의 일치입니다. 네이버 플레이스, 구글 비즈니스 프로필, 각종 디렉터리의 정보가 홈페이지 스키마와 같아야 외부의 평판이 우리 병원으로 정확히 귀속됩니다.

측정도 필요합니다. 월 1회, 환자 입장에서 AI 검색에 ‘○○동 △△과 추천’, ‘○○역 근처 토요일 진료 △△과’ 같은 질문을 실제로 던지고, 우리 병원이 등장하는지와 안내된 정보가 정확한지를 표로 기록합니다. 질문 다섯 개면 충분합니다. 등장 여부, 정보 정확성, 함께 언급된 경쟁 병원 세 칸만 적어도 개선 방향이 보입니다. 이 기록이 쌓이면 어느 항목이 비어서 빠지는지, 어느 정보가 틀려서 오답이 나오는지가 드러납니다.

무엇부터 할 것인가 — 우선순위와 체크리스트

모든 것을 한 번에 할 필요는 없습니다. 효과 대비 난이도로 순서를 정하면 다음과 같습니다. 첫째, 검증 도구로 현재 홈페이지에 스키마가 있는지, 있다면 어떤 유형인지 확인합니다. 둘째, 병원 정보 원본 문서를 만들고 네이버 플레이스·구글 비즈니스 프로필과 일치시킵니다. 셋째, 우리 병원에 맞는 MedicalOrganization 하위 유형으로 JSON-LD를 넣고 의료진을 Physician으로 연결합니다. 넷째, 색인을 요청하고 월 1회 점검 루틴을 만듭니다. 다섯째, 환자 질문 기반 FAQ 콘텐츠를 확장합니다.

• 검증 도구 결과 캡처 완료(메인·진료안내·의료진 페이지)
• 병원명·주소·전화·진료시간·진료과목·의료진 원본 문서 작성
• 네이버 플레이스·구글 비즈니스 프로필과 글자 단위 일치 확인
• 병원 유형에 맞는 하위 유형 선택(MedicalClinic·Dentist·Hospital)
• 구조화된 주소·요일별 진료시간·sameAs·로고 포함 JSON-LD 삽입
• 의료진 페이지 Physician 연결, 퇴사자 제거
• 리치 결과 테스트 통과, 서치콘솔·서치어드바이저 색인 요청
• 월 1회 AI 검색 질문 테스트와 스키마 재검증 일정 등록

위 항목 중 첫 두 가지는 오늘 안에 끝낼 수 있습니다. 어디서부터 손대야 할지 판단이 서지 않는다면 홈페이지 주소만으로 스키마 유무, 유형 적합성, 플랫폼 간 정보 불일치 항목을 점검하는 무료 진단을 활용해도 좋습니다. 진단 결과를 제작사에 그대로 전달하면 요청 문구를 따로 만들 필요 없이 바로 작업이 시작됩니다. 중요한 것은 AI가 우리 병원을 ‘확신할 수 있는 상태’로 만드는 일이며, 그 첫 단추가 기계용 명함인 MedicalOrganization 스키마입니다.