챗GPT는 왜 옆 병원만 추천할까 — AI에게 '보이지 않는 병원'을 만드는 MedicalOrganization 스키마의 부재
환자가 AI에게 병원을 물으면 옆 병원만 뜨는 이유는 실력이 아니라 데이터 구조에 있다. 의료기관 구조화 데이터인 MedicalOrganization 스키마가 왜 AI 인용의 출발점인지, 병원장이 오늘 당장 지시할 수 있는 적용 5단계와 흔한 실수까지 정리했다.
AI 검색 시대에 병원이 챗GPT·제미나이 같은 인공지능의 답변에 인용되려면, 홈페이지에 MedicalOrganization 구조화 데이터(스키마)를 갖추는 것이 출발점이다. 스키마는 병원의 명칭·주소·진료과목·진료시간을 AI가 오해 없이 읽도록 표준 형식으로 정리한 '기계를 위한 병원 소개서'이며, 이것이 없으면 아무리 잘 만든 홈페이지도 AI에게는 흐릿한 문서 더미로 남는다. 이 글은 왜 스키마가 AI 인용의 기본기인지, 그리고 병원장이 오늘 당장 무엇을 지시해야 하는지를 단계별로 정리한다.

진료를 마친 늦은 저녁, 원장이 스마트폰을 꺼내 챗GPT에 물어본다. '○○동에서 임플란트 상담 잘하는 치과 알려줘.' 화면에 세 곳이 뜬다. 개원한 지 2년 된 옆 건물 치과는 있는데, 십수 년 이 자리를 지켜온 우리 병원은 없다. 실력의 문제도, 장비의 문제도 아니다. 대부분의 경우 원인은 훨씬 건조한 곳에 있다. AI가 우리 병원의 정보를 '읽을 수 있는 형태'로 만난 적이 한 번도 없다는 것이다.
AI는 홈페이지를 '보지' 않는다 — 구조화 데이터라는 언어
사람은 홈페이지를 눈으로 본다. 세련된 배너, 원장 사진, 상단에 크게 박힌 전화번호를 보고 '좋은 병원 같다'고 느낀다. 그러나 AI는 홈페이지를 보는 것이 아니라 코드와 텍스트를 읽는다. 배너 이미지 안에 그려 넣은 전화번호, 이미지 파일로 올린 진료시간표, 팝업 속 오시는 길 안내는 AI에게 사실상 존재하지 않는 정보다. 사람 눈에 가장 잘 보이는 정보가 AI에게는 가장 안 보이는 정보인 경우가 많다.
구조화 데이터란 이 간극을 메우는 표준 언어다. 전 세계 검색엔진과 AI가 함께 쓰는 schema.org라는 공용 사전의 어휘로, 홈페이지 코드 안에 '이 문자열은 병원 이름이다', '이것은 주소이고, 이것은 진료시간이다'라고 라벨을 붙여주는 작업이다. 서류 봉투마다 내용물 라벨을 붙여 캐비닛에 정리하는 일과 같다. 라벨이 없으면 급한 사람(AI)은 봉투를 일일이 뜯어보지 않고 라벨이 붙은 옆 캐비닛부터 연다.
이것이 최근 자주 언급되는 AEO(Answer Engine Optimization), 즉 'AI 답변 최적화'의 기술적 기초다. 키워드 순위를 다투던 기존 검색 최적화와 달리, AEO는 AI가 답변을 조립할 때 우리 병원을 정확한 재료로 집어 들게 만드는 작업이며, 그 첫 단추가 구조화 데이터다. '홈페이지를 예쁘게 리뉴얼했으니 됐다'는 판단이 가장 흔한 착각인 이유가 여기에 있다. 디자인 리뉴얼과 데이터 구조화는 전혀 다른 공정이다.
MedicalOrganization 스키마 — AI에게 건네는 병원의 공식 신분증

schema.org에는 수백 가지 유형이 있지만, 의료기관을 위해 마련된 것이 MedicalOrganization이다. 그 아래에 치과를 뜻하는 Dentist, 병원을 뜻하는 Hospital, 의원급을 포괄하는 MedicalClinic 같은 세부 유형이 있어, 우리 기관의 성격에 맞는 유형을 골라 선언할 수 있다. 일반 회사용 스키마가 아니라 의료기관 전용 유형을 쓰는 순간, AI는 이곳이 '진료를 보는 곳'임을 구조적으로 인식한다.
왜 이것이 인용의 기본인가. AI는 답변을 만들 때 문서를 통째로 외우는 것이 아니라, 세상의 정보를 개체(entity) 단위로 정리해 조합한다. '○○동', '치과', '야간 진료' 같은 조건이 붙은 질문에 답하려면, 우리 병원이 지역·진료과목·운영시간이라는 속성을 가진 하나의 뚜렷한 개체로 등록되어 있어야 후보군에 오른다. MedicalOrganization 스키마는 그 개체 등록 서류, 말하자면 AI 세계에 제출하는 병원의 공식 신분증이다.
일반화된 예시를 들면 이렇다. 같은 상권의 두 치과 중 A는 홈페이지에 스키마 없이 이미지 중심으로 정보를 올렸고, B는 명칭·주소·진료시간·진료과목을 구조화 데이터로 선언했다. 환자가 AI에게 '이 근처 토요일 진료하는 치과'를 물으면, AI가 토요일 진료 여부를 확인할 수 있는 쪽은 B뿐이다. A가 실제로 토요일에 진료해도 답변에는 B만 남는다. 진료의 질과 무관하게, 읽히는 병원과 읽히지 않는 병원의 격차가 벌어지는 구조다.
없을 때 잃는 것, 갖췄을 때 얻는 것
손실부터 보자. 기존 검색에서 순위가 밀리면 2페이지에라도 존재했지만, AI 답변은 보통 두세 곳만 언급하고 끝난다. 후보군에 들지 못하면 '순위 하락'이 아니라 '존재의 삭제'다. 더 나쁜 경우도 있다. AI가 오래된 블로그나 낡은 등록 정보에서 이전하기 전 주소, 바뀌기 전 전화번호를 긁어와 잘못 안내하는 것이다. 공식 홈페이지에 정돈된 구조화 데이터가 없으면, AI는 부정확한 제3자 정보로 우리 병원을 설명하게 된다.
반대로 기회의 크기도 분명하다. 지금 시점에 의료기관 스키마를 제대로 갖춘 병원은 아직 소수에 머무는 것이 일반적이다. 검색 광고처럼 예산 경쟁이 붙은 시장이 아니라, 먼저 정확히 해두는 쪽이 조용히 우위를 가져가는 영역이라는 뜻이다. 특히 '지역명+진료과목+조건'이 붙는 질문일수록 구조화된 정보의 유무가 후보 선정을 좌우한다.
한 가지는 정직하게 말해두어야 한다. 스키마를 넣는다고 AI가 우리 병원을 반드시, 즉시 추천하는 것은 아니다. 스키마는 순위 보장 장치가 아니라 자격 요건에 가깝다. 다만 자격 요건을 갖추지 않은 채 콘텐츠나 광고에 쓰는 비용은, 지원서 없이 면접장 앞을 서성이는 일과 같다.
무엇을 채워야 하나 — 병원 스키마의 필수·권장 항목

스키마는 항목을 많이 넣는 것보다 정확하게 넣는 것이 중요하다. 의료기관이라면 다음 항목이 뼈대가 된다.
- name·alternateName: 의료기관 정식 명칭과 환자들이 실제 부르는 이름(약칭)을 함께 선언한다.
- address·geo: 도로명 주소를 표준 형식으로 나누어 넣고, 좌표를 함께 제공하면 '근처' 질문에 대응할 수 있다.
- telephone·url: 대표번호와 공식 홈페이지 주소. 홈페이지 화면에 적힌 번호와 한 자리도 달라선 안 된다.
- openingHoursSpecification: 요일별 진료시간과 점심시간, 야간·토요일 진료 여부. 조건형 질문에서 가장 자주 참조되는 항목이다.
- medicalSpecialty: 진료과목. 우리 병원이 어떤 질문의 후보가 될지를 결정한다.
- sameAs: 네이버 플레이스, 공식 블로그, 유튜브 등 공식 채널 주소. AI가 여러 출처를 교차 확인할 때 '같은 병원'임을 잇는 다리 역할을 한다.
- physician·image·logo: 대표 의료진 정보와 로고. 의료진은 별도의 Physician 유형으로 이름·전문과목을 선언할 수 있다.
주의점이 있다. 진료 서비스 항목에는 시술의 효과나 우수성 같은 홍보 문구가 아니라 서비스 명칭만 사실대로 적는다. 스키마는 광고판이 아니라 사실 기재란이며, 과장이 들어가는 순간 신뢰 데이터가 오염된다. 또 하나, 진료시간은 실제 운영과 다르면 없느니만 못하다. 휴진일 변경이 생기면 스키마도 함께 고치는 운영 원칙이 필요하다.
오늘 시작하는 적용 5단계 로드맵
원장이 코드를 직접 짤 필요는 없다. 필요한 것은 정확한 진단과 정확한 지시다. 순서는 다음과 같다.
- 현재 상태 진단: 홈페이지에서 마우스 오른쪽 버튼으로 '페이지 소스 보기'를 열고 ld+json이라는 문자열을 검색한다. 없다면 스키마가 없는 것이다. 구글의 리치 결과 테스트나 schema.org 검증 도구에 홈페이지 주소를 넣으면 더 정확히 확인된다.
- 공식 정보 시트 확정: 정식 명칭, 도로명 주소, 대표번호, 요일별 진료시간, 진료과목, 공식 채널 주소를 한 장으로 정리한다. 이 시트가 홈페이지·네이버 플레이스·스키마가 모두 따라야 할 단일 기준이 된다.
- JSON-LD 작성: 스키마를 담는 표준 형식인 JSON-LD로, 우리 기관에 맞는 세부 유형(치과의원이면 Dentist 등)을 선택해 위 항목을 작성한다. 제작 업체나 대행사에 정보 시트를 주고 맡기면 되는 공정이다.
- 삽입과 배포: 작성된 코드를 홈페이지의 head 영역에 넣는다. 업체에는 '메인 페이지에 MedicalOrganization 유형의 JSON-LD 구조화 데이터를 삽입해 달라'고 그대로 요청하면 된다.
- 검증과 유지: 배포 후 검증 도구로 오류 여부를 다시 확인하고, 이후 진료시간·전화번호가 바뀔 때마다 스키마를 함께 갱신한다. 최소 분기 1회 점검을 달력에 고정해 두는 것이 좋다.
이 다섯 단계 중 원장이 직접 해야 하는 것은 1번과 2번뿐이다. 나머지는 지시와 확인의 문제이며, 통상 대규모 예산이 드는 작업도 아니다.
병원들이 가장 자주 저지르는 실수 6가지

현장에서 반복해 관찰되는 실패 유형은 놀랄 만큼 비슷하다.
- 이미지 속 정보: 진료시간표·전화번호를 디자인 이미지로만 올려 AI가 읽을 텍스트가 없는 경우.
- 표기 불일치: 스키마의 전화번호와 화면의 전화번호, 네이버 플레이스의 주소가 서로 다른 경우. AI는 불일치하는 정보를 신뢰하지 않는다.
- 일반 유형 사용: 의료 세부 유형 대신 일반 Organization만 선언해, 진료기관이라는 정체성이 전달되지 않는 경우.
- 설치 후 방치: 확장 이전, 진료시간 변경, 대표번호 변경이 스키마에 반영되지 않아 오히려 오답의 근거가 되는 경우.
- 홍보 문구 혼입: '최고의', '통증 없는' 같은 표현을 스키마에 넣는 경우. 사실 데이터로서의 가치가 무너지고 의료광고 규정 측면의 부담도 커진다.
- 메인 한 페이지로 종료: 진료과목별 페이지, 의료진 페이지, 자주 묻는 질문 페이지로 확장하지 않아 절반의 효과에 그치는 경우.
여섯 가지 모두 기술 난도의 문제가 아니라 관리 원칙의 문제다. 단일 정보 시트를 기준으로 삼는 습관 하나로 대부분 예방된다.
스키마는 뼈대일 뿐 — 콘텐츠·일관성과의 삼각 구조
스키마가 신분증이라면, AI가 최종적으로 인용을 결정할 때는 평판과 이력도 함께 본다. 즉 구조화 데이터(뼈대), 환자의 실제 질문에 답하는 콘텐츠(살), 그리고 홈페이지·지도·공식 채널에 걸친 정보 일관성(혈관)이 삼각형을 이룰 때 인용 확률이 올라간다. AI는 한 출처만 믿지 않고 여러 출처를 교차 확인하기 때문이다.
그래서 다음 확장은 자연스럽다. 자주 묻는 질문 페이지에는 FAQPage 스키마를 붙여 질문과 답 자체를 구조화하고, 의료진 소개는 Physician 유형으로 경력을 사실 위주로 정리한다. 콘텐츠는 '○○ 시술 최저가' 같은 광고형 문장이 아니라, 환자가 AI에게 실제로 묻는 문장에 답하는 형태로 쓴다. 신분증을 갖춘 병원이 좋은 답변 재료까지 쌓으면, AI 입장에서 인용하지 않을 이유가 줄어든다.
무엇부터 할 것인가 — 원장을 위한 실행 체크리스트
우선순위는 명확하다. 이번 주 안에 진단, 다음 주 안에 정보 시트와 지시. 이 두 걸음이 전체의 절반이다.
- 챗GPT 등 AI에 '지역명+진료과목'으로 우리 병원을 직접 물어보고 현재 답변을 기록한다.
- 홈페이지 소스에서 ld+json 존재 여부를 확인하거나 검증 도구를 돌린다.
- 병원 공식 정보 시트 한 장을 확정하고, 홈페이지·플레이스 표기와 대조한다.
- 제작 업체에 MedicalOrganization(또는 세부 유형) JSON-LD 삽입을 요청하고, 배포 후 검증 결과를 보고받는다.
- 분기 1회 스키마 점검 일정을 고정한다.
가장 확실한 첫걸음은 지금 우리 병원이 AI에게 어떻게 읽히고 있는지 객관적으로 확인하는 것이다. 어디서부터 손대야 할지 판단이 서지 않는다면, AI메디랩의 무료 AI 검색 진단으로 우리 병원의 구조화 데이터 상태와 AI 답변 노출 현황을 점검해 보는 것도 부담 없는 출발점이 된다. 순서만 알면, 나머지는 지시와 확인의 문제다.
자주 묻는 질문
스키마를 넣으면 바로 AI 답변에 우리 병원이 나오나요?
즉시 보장되지는 않습니다. 스키마는 순위 보장 장치가 아니라 AI가 병원 정보를 정확히 읽고 후보로 검토할 수 있게 하는 자격 요건에 가깝습니다. AI 서비스가 웹 정보를 다시 수집하고 반영하기까지 시간이 걸리며, 콘텐츠와 정보 일관성이 함께 갖춰질 때 인용 가능성이 올라갑니다. 다만 스키마 없이 다른 마케팅에 비용을 쓰는 것은 기초 없이 층을 올리는 것과 같아, 순서상 가장 먼저 할 일입니다.
우리 홈페이지에 스키마가 이미 있는지 어떻게 확인하나요?
두 가지 방법이 있습니다. 첫째, 홈페이지에서 마우스 오른쪽 버튼으로 '페이지 소스 보기'를 연 뒤 ld+json이라는 문자열을 검색해 보는 것입니다. 둘째, 구글 리치 결과 테스트나 schema.org 검증 도구에 홈페이지 주소를 입력하면 어떤 구조화 데이터가 있고 오류가 없는지 확인할 수 있습니다. 있더라도 일반 Organization 유형만 선언된 경우가 많으니, 의료기관 유형인지까지 확인하는 것이 좋습니다.
코딩을 전혀 모르는데 원장이 직접 할 수 있는 일인가요?
직접 코드를 작성할 필요는 없습니다. 원장이 해야 할 일은 병원 정식 명칭, 주소, 전화번호, 요일별 진료시간, 진료과목, 공식 채널 주소를 한 장의 정보 시트로 확정하는 것입니다. 그 시트를 홈페이지 제작 업체나 대행사에 전달하며 'MedicalOrganization 유형의 JSON-LD 구조화 데이터를 삽입해 달라'고 요청하면 됩니다. 배포 후에는 검증 도구 결과를 보고받아 오류 여부만 확인하면 충분합니다.
MedicalOrganization과 LocalBusiness 중 어떤 유형을 써야 하나요?
의료기관이라면 의료 전용 유형을 쓰는 것이 원칙입니다. schema.org에는 치과를 위한 Dentist, 병원을 위한 Hospital, 의원급을 위한 MedicalClinic 등 세부 유형이 있으며, 이들은 지역 사업장의 속성과 의료기관의 속성을 함께 가집니다. 일반 LocalBusiness만 쓰면 위치 정보는 전달되지만 진료기관이라는 정체성과 진료과목 정보가 약해집니다. 우리 기관 성격에 가장 가까운 세부 유형을 고르고, 애매하면 MedicalClinic을 기준으로 삼는 것이 무난합니다.
스키마에 시술 효과나 환자 후기를 넣어도 되나요?
권하지 않습니다. 스키마는 광고 문구가 아니라 사실 정보를 기재하는 영역이어서, 효과를 단정하는 표현이나 후기성 문구가 들어가면 데이터로서의 신뢰가 훼손되고 의료광고 규정 측면의 부담도 커질 수 있습니다. 진료 서비스 항목에는 서비스 명칭만 사실대로 적고, 병원의 강점은 별도의 콘텐츠에서 규정에 맞게 풀어내는 것이 안전합니다. 스키마는 정확할수록 강력하고, 과장이 섞이는 순간 가치가 떨어집니다.
네이버 검색이나 플레이스에도 스키마가 효과가 있나요?
구조화 데이터는 특정 회사의 기술이 아니라 전 세계 검색엔진과 AI가 함께 쓰는 공용 표준이므로, 특정 플랫폼에만 국한된 작업이 아닙니다. 다만 네이버 플레이스는 자체 등록 정보의 비중이 크기 때문에, 플레이스 정보를 정확히 관리하는 일과 홈페이지 스키마를 갖추는 일을 병행해야 합니다. 중요한 것은 홈페이지·스키마·플레이스·공식 채널의 명칭, 주소, 전화번호가 완전히 일치하도록 하나의 기준 시트로 관리하는 것입니다. 이 일관성이 모든 플랫폼에서 신뢰의 근거가 됩니다.
이 칼럼이 도움이 됐다면 공유해 주세요
원장님·마케팅 담당자에게 링크 한 번이면 됩니다.