환자는 AI에게 묻는데, 왜 우리 병원만 답변에 없을까 — MedicalOrganization 스키마의 진실

환자가 챗GPT나 AI 검색에 '○○동 잘하는 병원'을 물으면, AI는 아무 병원이나 답하지 않습니다. 홈페이지에 '기계가 읽는 신원 정보'가 정리된 곳을 우선 인용합니다. 그 정보의 표준 형식이 바로 MedicalOrganization 스키마이며, 이 글은 왜 이것이 AI 인용의 기본 조건인지, 그리고 원장이 오늘 당장 무엇을 어떻게 채워야 하는지를 단계별로 설명합니다.

실제 상황을 그려 보겠습니다. 우리 병원은 진료도 꼼꼼하고, 후기도 나쁘지 않고, 홈페이지도 있습니다. 그런데 인근 주민이 AI에게 "우리 동네에서 임플란트 잘하는 치과 추천해줘"라고 물으면, 답변에는 옆 건물 병원과 두 블록 떨어진 병원만 뜹니다. 원장 입장에서는 억울합니다. "우리가 그 병원보다 못한 게 뭐지?" 문제는 실력이 아닙니다. AI가 우리 병원의 정보를 '구조적으로 이해하지 못했을' 뿐입니다. 사람 눈에는 멀쩡히 보이는 홈페이지가, 기계 눈에는 신원 미상의 문서로 남아 있는 것입니다.

AI는 '어떤 병원'을 인용할지 어떻게 결정하는가

사람은 홈페이지를 보면 "아, 강남에 있는 내과구나, 야간진료도 하는구나"를 한눈에 파악합니다. 하지만 AI는 문장을 읽되, 그 문장이 '병원 이름'인지 '진료과목'인지 '주소'인지를 사람처럼 직관으로 알지 못합니다. 그래서 AI와 검색엔진은 웹페이지 뒤에 숨겨 넣은 별도의 '정보 꼬리표'를 함께 읽습니다. 이 꼬리표가 구조화 데이터(Structured Data), 즉 '이 항목은 병원명, 이 항목은 전화번호'라고 기계가 오해 없이 알아보도록 표준 형식으로 정리한 데이터입니다.

AI가 답변에 특정 병원을 인용하려면 최소한 세 가지를 확신해야 합니다. 첫째, 이곳이 '실재하는 의료기관'이 맞는가. 둘째, 어디에 있고 어떤 진료를 하는가. 셋째, 이 정보가 여기저기서 일관되게 확인되는가. 구조화 데이터는 이 세 가지 확신을 기계가 직접 얻도록 돕는 가장 빠른 통로입니다. 반대로 이 데이터가 없으면, AI는 우리 병원을 '내용은 그럴듯하지만 신원이 불확실한 문서'로 분류하고, 확신이 서는 경쟁 병원을 대신 인용합니다.

여기서 핵심을 짚겠습니다. AI 답변에 인용되는 것은 '가장 좋은 병원'이 아니라 'AI가 가장 자신 있게 설명할 수 있는 병원'입니다. 실력과 인용은 별개의 문제이며, 구조화 데이터는 그 간극을 메우는 작업입니다.

MedicalOrganization 스키마란 정확히 무엇인가

스키마(Schema)는 앞서 말한 '정보 꼬리표'를 붙이는 국제 표준 규격입니다. 전 세계 검색엔진과 AI가 공통으로 참조하는 사전(schema.org)이 있고, 그 안에 의료기관 전용 항목이 바로 MedicalOrganization입니다. 병원·의원·치과·한의원처럼 '의료를 제공하는 조직'임을 기계에 명시적으로 선언하는 이름표라고 이해하면 됩니다.

이 스키마 안에는 병원의 신원을 이루는 항목들이 정해진 이름으로 들어갑니다. 대표적으로 기관명(name), 주소(address), 전화번호(telephone), 진료시간(openingHours), 홈페이지 주소(url), 지도상 좌표(geo), 진료과목이나 전문 분야(medicalSpecialty), 대표 이미지(logo·image) 등입니다. 사람에게는 홈페이지 하단에 적힌 흔한 정보지만, 이것을 '스키마 형식'으로 감싸 두면 AI는 추측 없이 정확히 읽어냅니다.

한 가지 오해를 먼저 풀겠습니다. 스키마를 넣는다고 홈페이지 화면이 바뀌지는 않습니다. 방문자 눈에 보이는 디자인은 그대로이고, 화면 뒤에서 기계만 읽는 데이터가 추가되는 것입니다. 즉 '사람용 페이지'와 '기계용 신원증명'을 한 페이지에 함께 담는 작업이며, 대개 홈페이지 소스에 JSON-LD라는 짧은 코드 한 덩어리를 삽입하는 방식으로 처리합니다. 개발 지식이 없어도 담당 업체에 '구조화 데이터를 넣어 달라'고 요청할 수 있는 수준의 작업입니다.

스키마가 없으면 잃는 것, 있으면 얻는 것

먼저 잃는 쪽을 냉정하게 보겠습니다. 스키마가 없는 병원은 AI 답변의 '후보 명단'에서 조용히 빠집니다. 이건 순위가 낮은 것과 다릅니다. 순위 경쟁은 명단 안에서의 다툼이지만, 신원이 불확실한 병원은 아예 명단에 오르지 못합니다. 환자가 AI에게 병원을 물어보는 순간이 늘어날수록, 이 '보이지 않는 탈락'은 매달 새어 나가는 문의와 예약으로 누적됩니다. 더 뼈아픈 점은, 원장은 이 손실을 체감조차 못 한다는 것입니다. 전화가 안 오는 이유가 'AI가 우리를 몰라서'라는 걸 알 방법이 없기 때문입니다.

반대로 얻는 쪽을 보겠습니다. 스키마가 제대로 갖춰지면 AI는 우리 병원을 '설명하기 쉬운 대상'으로 인식합니다. 위치·진료과목·진료시간을 확신하므로, "○○동에서 야간진료 되는 소아과" 같은 구체적 질문에 우리 병원을 자신 있게 끼워 넣습니다. 지역·진료과목·특수 조건이 맞물린 질문일수록 후보군은 좁아지고, 신원이 명확한 병원이 인용될 확률은 급격히 올라갑니다. 즉 스키마는 '검색이 좋아지는 옵션'이 아니라 'AI 답변에 등장하기 위한 입장권'에 가깝습니다.

우리 병원 스키마, 필드별로 이렇게 채운다

실무로 들어가겠습니다. 담당 업체나 실무자가 무엇을 채워야 하는지 항목별로 정리했습니다.

1. 기관 유형과 이름: 'MedicalOrganization' 또는 세부 유형(치과는 Dentist 등)을 지정하고, 이름은 간판·사업자등록·지도에 쓰는 명칭과 글자 하나까지 똑같이 맞춥니다.
2. 주소와 좌표: 도로명 주소를 정확히 넣고, 가능하면 지도 좌표(위도·경도)까지 넣습니다. 지역 질문에 걸리려면 위치 정보의 정확도가 결정적입니다.
3. 전화번호: 실제 예약을 받는 대표번호 하나로 통일합니다. 여러 번호가 뒤섞이면 신뢰 신호가 약해집니다.
4. 진료시간: 요일별 시간을 명시하고, 점심시간·야간·주말·공휴일 진료 여부까지 반영합니다. '야간진료' 같은 조건 질문에서 이 항목이 인용을 가릅니다.
5. 진료과목·전문 분야: 실제 제공하는 진료만 구체적으로 기재합니다. 없는 진료를 넣는 것은 오히려 신뢰를 깎습니다.
6. 홈페이지·대표 이미지: 공식 url과 로고·대표 이미지를 연결해 '이 웹사이트가 곧 이 기관'임을 명확히 묶습니다.

흔한 실수 하나. 스키마에 적은 정보와 화면에 실제로 보이는 정보가 어긋나면 안 됩니다. 예를 들어 화면에는 '연중무휴'라 써 놓고 스키마에는 주말 휴무로 넣으면, 기계는 이 페이지의 신뢰도 자체를 낮게 봅니다. 스키마는 '화면에 없는 정보를 몰래 넣는 도구'가 아니라 '화면의 사실을 기계어로 번역하는 도구'라는 원칙을 지켜야 합니다.

NAP 일관성 — AI가 '진짜'로 판단하는 결정적 조건

스키마를 아무리 잘 넣어도, 한 가지가 어긋나면 힘을 잃습니다. 바로 NAP 일관성입니다. NAP는 이름(Name)·주소(Address)·전화(Phone)의 앞글자로, 이 세 가지가 홈페이지·지도·병원 정보 사이트·SNS 등 모든 곳에서 똑같아야 한다는 원칙입니다.

AI는 여러 출처에서 우리 병원 정보를 교차 확인합니다. 홈페이지 스키마에는 '3층'인데 지도에는 '4층', 어떤 곳엔 옛 전화번호가 남아 있다면, AI는 '어느 정보가 맞는지 확신할 수 없는 기관'으로 판단합니다. 확신이 없으면 인용도 없습니다. 그래서 스키마 작업과 NAP 정리는 반드시 한 세트로 진행해야 합니다.

실행 순서는 이렇습니다. 먼저 우리 병원의 '정답 정보' 한 벌(정확한 명칭·도로명 주소·대표번호·진료시간)을 문서로 확정합니다. 그다음 홈페이지, 지도 등록 정보, 병원 검색 포털, 블로그·SNS 프로필을 하나씩 열어 이 정답과 다른 부분을 모두 교정합니다. 이사·번호 변경·상호 변경 이력이 있는 병원일수록 옛 정보가 곳곳에 유령처럼 남아 있으니, 이 청소 작업이 스키마 못지않게 중요합니다.

오늘부터 5단계로 적용하기

원장이 담당자에게 지시하거나 직접 확인할 수 있도록 실행 단계를 정리했습니다.

1. 정답 정보 확정: 명칭·주소·번호·진료시간·진료과목을 한 문서로 통일합니다. 모든 작업의 기준점입니다.
2. NAP 청소: 홈페이지·지도·포털·SNS의 정보를 정답과 일치시키고, 옛 정보를 제거합니다.
3. MedicalOrganization 스키마 삽입: 홈페이지에 구조화 데이터를 넣습니다. 담당 업체에 요청하거나 홈페이지 솔루션의 관련 기능을 활용합니다.
4. 검증: 스키마가 오류 없이 인식되는지 점검 도구로 확인합니다. 넣는 것보다 '제대로 읽히는지' 확인이 더 중요합니다.
5. 주기적 갱신: 진료시간·번호·진료과목이 바뀌면 스키마와 모든 채널을 즉시 함께 수정합니다. 정보는 방치되는 순간 오답이 됩니다.

흔한 오해와 실수

마지막으로 현장에서 자주 보이는 함정을 짚겠습니다. 첫째, "스키마 한 번 넣으면 끝"이라는 오해입니다. 정보는 계속 바뀌므로 스키마도 살아 있는 자산으로 관리해야 합니다. 둘째, 없는 진료나 과장된 표현을 넣어 노출을 늘리려는 시도입니다. 사실과 다른 정보는 단기적으로도 위험하고, 장기적으로 기관 신뢰도를 떨어뜨립니다. 셋째, 스키마만 넣으면 즉시 AI 답변 1순위가 될 거라는 기대입니다. 스키마는 '입장권'이지 '우승컵'이 아닙니다. 후보 명단에 드는 기본 조건을 갖춘 뒤, 콘텐츠·후기·전문성 같은 다음 단계가 순위를 만듭니다.

정리하면, 우선순위는 명확합니다. 정답 정보 확정 → NAP 일관성 정리 → MedicalOrganization 스키마 삽입과 검증 → 주기적 갱신. 실력 있는 병원이 AI 답변에서 사라지는 일은, 대개 이 기본 한 겹을 갖추지 않아 벌어집니다. 반대로 이 한 겹만 제대로 세워도, AI가 우리 병원을 '설명할 수 있는 대상'으로 바꿔 놓습니다.

우리 병원 홈페이지가 AI 눈에 어떻게 읽히는지, 스키마와 NAP가 제대로 갖춰졌는지 궁금하다면 무료 진단으로 현재 상태를 점검해 보시길 권합니다. 어디가 비어 있는지 아는 것이 첫 단추입니다.