챗GPT에게 우리 병원은 '존재하지 않는다' — AI가 인용하는 병원의 숨은 조건, MedicalOrganization 스키마
환자가 AI에게 '이 동네 잘하는 병원'을 물을 때 우리 병원이 답변에서 빠지는 이유는 실력이 아니라, AI가 병원 정보를 '읽지 못하기' 때문인 경우가 많습니다. 그 해석의 열쇠가 MedicalOrganization 구조화 데이터입니다. 이 글은 스키마가 AI 인용의 기본기인 이유와, 원장이 오늘 당장 적용할 수 있는 단계를 정리합니다.
환자가 챗GPT나 AI 검색창에 '○○동에서 임플란트 잘하는 치과'를 물었을 때, 우리 병원 대신 옆 건물 병원만 답변에 등장하는 경험을 해본 원장이 적지 않습니다. 이 격차는 진료 실력의 차이가 아니라, AI가 우리 병원 정보를 '기계가 읽을 수 있는 형태'로 제공받지 못한 데서 오는 경우가 많습니다. 이 글은 그 근본 원인인 구조화 데이터(스키마), 특히 의료기관용 MedicalOrganization 스키마가 왜 AI 인용의 출발점인지, 그리고 원장이 오늘 당장 무엇을 어떻게 적용해야 하는지를 다룹니다.

AI는 우리 병원을 '못 읽을' 뿐, 무시하는 게 아니다
먼저 개념부터 정리하겠습니다. AEO는 'Answer Engine Optimization'의 약자로, 우리말로 옮기면 '답변 엔진 최적화'입니다. 과거의 검색이 사용자에게 링크 10개를 나열해 주는 방식이었다면, 지금의 AI 검색은 여러 출처를 읽고 종합해 '하나의 답변'을 만들어 줍니다. 문제는 이 답변에 인용되는 병원과 인용되지 않는 병원이 뚜렷이 갈린다는 점입니다. 인용되지 않으면, 환자 입장에서 그 병원은 사실상 존재하지 않는 것과 같습니다.
많은 원장이 오해하는 지점이 여기 있습니다. '우리 홈페이지도 있고, 블로그도 열심히 쓰는데 왜 AI는 우리를 모를까'라는 물음입니다. 핵심은, 사람의 눈과 기계의 눈이 다르다는 데 있습니다. 홈페이지에 '평일 오전 9시부터 오후 6시까지 진료합니다'라고 예쁘게 써 두어도, AI는 이 문장이 '진료시간'인지, '점심시간'인지, '이벤트 문구'인지 100% 확신하지 못합니다. 사람은 문맥으로 읽지만, 기계는 추측해야 하고, 추측에는 늘 오류와 누락이 따릅니다.
그래서 AI는 정보가 애매한 병원보다, 정보가 '명확하게 라벨링된' 병원을 더 신뢰하고 우선 인용하는 경향을 보입니다. 진료과목·주소·진료시간·전화번호가 기계가 오해할 여지 없이 딱 떨어지게 제공된 병원은, AI가 '이 정보는 확실하다'고 판단해 답변에 올리기 쉽습니다. 반대로 디자인은 화려하지만 정보 구조가 흐린 사이트는, 사람 눈엔 멋져 보여도 기계 눈엔 '읽기 어려운 병원'이 됩니다.
현장의 비유로 바꿔 보겠습니다. 아무리 실력 좋은 의사여도, 진료의뢰서에 병명·소견·처방이 정리돼 있지 않으면 다음 의료진이 판단하기 어렵습니다. 구조화 데이터는 AI에게 건네는 '정돈된 진료의뢰서'와 같습니다. 실력이 없어서가 아니라, 실력을 전달할 서식이 비어 있었던 것입니다.
구조화 데이터란 무엇인가 — 병원 정보를 기계의 언어로 번역하기

구조화 데이터(스키마)란, 웹페이지에 사람 눈에는 보이지 않지만 기계는 읽을 수 있는 '정보 꼬리표'를 붙여 두는 기술입니다. 예를 들어 '강남치과'라는 글자 옆에, 사람 눈에 안 보이는 형태로 '이것은=병원이름'이라는 꼬리표를 함께 심어 두는 것입니다. AI는 이 꼬리표를 읽고 '아, 이 텍스트는 병원 이름이구나'라고 오해 없이 이해합니다.
이 꼬리표를 심는 표준 방식이 JSON-LD입니다. JSON-LD는 'JSON 형식으로 표현한 연결 데이터'라는 뜻으로, 홈페이지 코드 안에 정보를 목록 형태로 정리해 넣는 작은 코드 조각이라고 이해하면 충분합니다. 원장이 이 코드를 직접 손으로 작성할 필요는 없습니다. 다만 '우리 사이트에 이런 것이 들어가 있어야 한다'는 사실을 아는 것과 모르는 것은, 제작 업체에 요청할 때 하늘과 땅 차이를 만듭니다.
스키마에는 수백 가지 유형이 있습니다. 일반 기업이라면 Organization(조직), 식당이라면 Restaurant처럼 업종별로 맞는 유형이 있고, 의료기관을 위해 별도로 마련된 유형이 바로 MedicalOrganization(의료기관), 그리고 그 하위의 Hospital·Dentist·Physician 등입니다. 병원이 일반 Organization 스키마만 써도 되긴 하지만, 의료기관 전용 유형을 쓰면 AI에게 '우리는 일반 회사가 아니라 의료기관'이라는 사실을 한 단계 더 정확히 전달할 수 있습니다.
여기서 중요한 원칙 하나. 구조화 데이터는 '거짓말 도구'가 아닙니다. 페이지에 실제로 보이는 정보와 일치해야 합니다. 화면엔 '오후 6시 마감'이라 써 놓고 스키마엔 '오후 9시'라고 넣으면, AI는 이 불일치를 신뢰도 훼손으로 받아들일 수 있습니다. 스키마는 없는 정보를 지어내는 게 아니라, 이미 있는 정보를 기계가 오해 없이 읽도록 '번역'하는 작업임을 잊지 말아야 합니다.
MedicalOrganization 스키마, 무엇을 담아야 하나
그렇다면 의료기관 스키마에는 구체적으로 어떤 정보를 담아야 할까요. 완벽하게 채운다는 강박보다, '환자가 병원을 고를 때 확인하는 정보'를 기계에게도 명확히 전달한다는 관점으로 접근하면 됩니다. 다음은 우선순위가 높은 핵심 항목들입니다.
- 병원 이름(name): 간판·사업자등록·네이버 지도 등 모든 채널에서 동일한 정식 명칭으로 통일합니다.
- 주소(address): 시·구·동·도로명·건물층까지. 지도 등록 정보와 한 글자도 어긋나지 않게 맞춥니다.
- 전화번호(telephone): 대표번호를 정확히. 여러 번호가 있다면 대표번호를 기준으로 통일합니다.
- 진료시간(openingHours): 요일별 진료·휴진·점심시간을 구분해 넣습니다. 애매한 '탄력 운영' 표현은 지양합니다.
- 진료과목·전문 분야(medicalSpecialty): 치과·정형외과·피부과 등 진료 영역을 표준 용어로 명시합니다.
- 지리 좌표(geo): 위도·경도. '○○동 근처'같은 지역 질문에 답할 때 AI가 위치를 판별하는 근거가 됩니다.
- 웹사이트·소셜 채널(url·sameAs): 공식 홈페이지, 네이버 플레이스, 인스타그램 등 공식 채널을 서로 연결해 '동일 기관'임을 증명합니다.
이 중에서도 실무적으로 가장 큰 영향을 주는 것은 이름·주소·전화번호, 이른바 NAP(Name·Address·Phone)의 일관성입니다. AI는 여러 출처에서 같은 병원 정보를 발견했을 때, 그 정보들이 서로 일치하면 '신뢰할 수 있는 실재하는 기관'으로 판단합니다. 반대로 홈페이지·지도·블로그마다 상호나 주소가 조금씩 다르면, AI는 이들을 같은 병원으로 확신하지 못하고 인용을 주저합니다.
여기에 더해 sameAs 항목은 종종 과소평가됩니다. 이는 '이 홈페이지의 병원과, 저 네이버 플레이스의 병원과, 그 인스타그램 계정이 모두 같은 곳'이라고 AI에게 알려 주는 연결고리입니다. 흩어진 채널을 하나로 묶어 주면, AI 입장에서 우리 병원은 '여기저기 흔적이 일관되게 남아 있는, 실체가 분명한 기관'이 됩니다.
왜 스키마가 AI 인용의 '기본기'인가 — 잃는 것과 얻는 것

스키마를 '있으면 좋은 옵션' 정도로 여기는 원장이 많습니다. 그러나 이는 화려한 인테리어를 논하기 전에 갖춰야 할 기초 배관에 가깝습니다. 먼저 손실의 관점에서 보겠습니다. 구조화 데이터가 없으면, 아무리 좋은 콘텐츠를 써도 AI가 그것을 '누가·어디서·무슨 진료로' 말하는지 확신하지 못합니다. 그 결과, 환자가 지역·진료과목으로 병원을 물어보는 결정적 순간에 우리 병원이 후보군에서 조용히 빠집니다. 이 손실은 눈에 보이지 않기에 더 위험합니다. 광고비를 낭비한 건 청구서로 확인되지만, AI 답변에서 누락된 문의는 애초에 존재조차 인지되지 못합니다.
더 뼈아픈 것은 경쟁 구도입니다. AI 답변은 링크를 10개씩 늘어놓지 않습니다. 대개 소수의 병원만 언급합니다. 즉, 인용은 '상위 소수 독식' 구조에 가깝습니다. 옆 병원이 기본기를 갖추고 우리가 갖추지 못했다면, 그 격차는 순위 몇 계단 차이가 아니라 '언급됨 vs 언급 안 됨'이라는 단절적 차이로 나타납니다.
이제 기회의 관점입니다. 다행히 아직 많은 병·의원이 구조화 데이터를 제대로 갖추지 않았습니다. 다시 말해 지금은 '먼저 기본기를 갖춘 병원이 유리해지는' 초기 국면입니다. 인테리어 경쟁처럼 이미 포화된 영역이 아니라, 비교적 적은 노력으로 AI에게 신뢰받는 기관으로 자리 잡을 여지가 남아 있는 것입니다. 경우에 따라, 정보 구조를 정돈하는 것만으로 지역·진료과목 질문에서 인용 가능성을 높였다는 현장 사례들이 보고됩니다. 이는 일반화된 예시이며 병원마다 결과는 다를 수 있지만, 방향성은 분명합니다.
정리하면, 스키마는 화제성 콘텐츠나 광고보다 앞서 놓여야 할 토대입니다. 토대 없이 쌓은 콘텐츠는 AI에게 '주인 없는 정보'로 흩어지고, 토대 위에 쌓은 콘텐츠는 '우리 병원의 신뢰 자산'으로 축적됩니다.
오늘 당장 적용하는 5단계
개념을 이해했다면, 이제 실행입니다. 원장이 직접 코드를 짤 필요는 없지만, 아래 순서를 알고 있어야 제작·마케팅 담당자에게 정확히 지시하고 결과를 검수할 수 있습니다.
- 정보 원본부터 통일하라. 홈페이지·네이버 플레이스·구글 비즈니스·블로그에 흩어진 상호·주소·전화·진료시간을 한 문서에 모아, 서로 다른 부분을 먼저 하나로 맞춥니다. 스키마 작업보다 이 정리가 먼저입니다. 원본이 어긋나 있으면 스키마도 어긋납니다.
- MedicalOrganization 스키마를 홈페이지에 심어라. 제작 업체에 '의료기관용 구조화 데이터(JSON-LD)를 넣어 달라'고 요청하고, 앞서 정리한 핵심 항목(이름·주소·전화·진료시간·진료과목·좌표·공식 채널)을 전달합니다.
- 진료과목·시술 소개 페이지에도 세부 정보를 붙여라. 병원 대표 정보 외에, 개별 진료 페이지에도 어떤 진료를 다루는지 명확히 라벨링하면 특정 진료 질문에 대한 인용 가능성이 높아집니다.
- 검증 도구로 반드시 확인하라. 구글이 무료로 제공하는 '리치 결과 테스트(Rich Results Test)'나 스키마 검증 도구에 우리 홈페이지 주소를 넣어, 오류·경고 없이 인식되는지 눈으로 확인합니다. 심었다고 끝이 아니라, 기계가 실제로 읽는지가 핵심입니다.
- 주기적으로 최신화하라. 진료시간 변경, 이전, 휴진, 신규 진료 도입 시 스키마도 함께 갱신합니다. 낡은 정보는 오히려 신뢰를 깎습니다.
이 다섯 단계는 대단한 예산이 드는 작업이 아닙니다. 오히려 대부분은 '이미 있는 정보를 정돈하고 라벨을 다는' 일에 가깝습니다. 관건은 예산이 아니라 '이 작업의 존재를 아느냐'입니다.
현장에서 가장 흔한 실수 7가지

스키마를 도입하려다 오히려 역효과를 내는 경우도 있습니다. 아래는 실무에서 반복적으로 관찰되는 실수들입니다.
- 화면 정보와 스키마 정보의 불일치. 앞서 강조했듯, 페이지에 없는 내용을 스키마에만 넣으면 신뢰가 훼손됩니다. 둘은 늘 같아야 합니다.
- 채널마다 다른 상호·주소. '강남OO치과'와 'OO치과의원'이 섞여 쓰이는 식입니다. 사람에겐 같아 보여도 기계에겐 다른 기관일 수 있습니다.
- 심어 놓고 검증하지 않음. 코드에 오타가 있으면 통째로 무시되기도 합니다. 검증 도구 확인은 선택이 아니라 필수입니다.
- 과장·허위 표현을 스키마에 담으려는 시도. 근거 없는 '최고·1위' 같은 표현은 의료광고 규정 측면에서도 위험하고, AI 신뢰 측면에서도 도움이 되지 않습니다. 각도는 정확한 정보 전달이어야 합니다.
- 디자인만 신경 쓰고 정보 구조는 방치. 이미지로만 만든 진료시간표는 사람은 읽어도 기계는 못 읽습니다. 핵심 정보는 반드시 텍스트로도 존재해야 합니다.
- 한 번 심고 방치. 이전·휴진·진료시간 변경이 반영 안 된 낡은 스키마는 환자 불만과 신뢰 하락을 동시에 부릅니다.
- 스키마만 하면 끝이라는 오해. 스키마는 기본기이지 만능이 아닙니다. 신뢰할 만한 콘텐츠, 일관된 채널 관리와 함께 갈 때 효과가 쌓입니다.
이 실수들의 공통점은 하나입니다. '기계의 눈'을 상상하지 않은 데서 온다는 점입니다. 우리 정보를 처음 보는 기계가 오해 없이 읽을 수 있는가 — 이 질문을 기준 삼으면 대부분의 실수는 예방됩니다.
무엇부터 할지 — 우선순위와 실행 체크리스트
모든 것을 한 번에 하려다 아무것도 못 하는 경우가 가장 많습니다. 우선순위는 명확합니다. 첫째, 흩어진 이름·주소·전화·진료시간(NAP) 정보를 하나로 통일하십시오. 이것만으로도 AI가 우리 병원을 '실재하는 하나의 기관'으로 인식하는 데 큰 도움이 됩니다. 둘째, 홈페이지에 MedicalOrganization 스키마를 심고 검증하십시오. 셋째, 진료 페이지 단위로 세부 정보를 확장하십시오. 순서를 지키는 것이 속도보다 중요합니다.
아래 체크리스트로 현재 상태를 스스로 점검해 보시길 권합니다.
- 홈페이지·네이버·구글·블로그의 상호가 완전히 동일한가
- 주소와 전화번호가 모든 채널에서 일치하는가
- 진료시간이 텍스트로(이미지 아님) 명확히 표기돼 있는가
- 홈페이지에 의료기관 구조화 데이터가 심겨 있는가
- 검증 도구에서 오류 없이 인식되는가
- 공식 채널들이 서로 연결(sameAs)돼 있는가
- 최근 변경 사항이 스키마에 반영돼 있는가
일곱 항목 중 '아니오'가 하나라도 있다면, 그것이 우리 병원이 AI 답변에서 빠지는 조용한 이유일 수 있습니다. 반대로 이 항목들을 채워 두는 것만으로, 경쟁 병원보다 앞서 AI에게 신뢰받는 기관이 될 가능성이 열립니다.
만약 '우리 병원은 지금 몇 개나 갖추고 있을까'가 궁금하다면, 스스로 판단하기 어려운 부분을 객관적으로 점검받아 보는 것도 방법입니다. AI메디랩은 병·의원의 구조화 데이터와 AI 인용 노출 상태를 무료로 진단해, 어디가 비어 있고 무엇부터 채워야 하는지를 원장 눈높이로 정리해 드립니다. 광고보다 먼저, 우리 병원이 기계의 눈에 어떻게 보이는지부터 확인하는 것 — 그것이 AI 시대 병원 마케팅의 가장 정직한 출발점입니다.
자주 묻는 질문
MedicalOrganization 스키마를 넣으면 바로 AI 답변에 나오나요?
스키마는 AI가 우리 병원 정보를 정확히 이해하도록 돕는 기본기이지, 즉각적인 노출을 보장하는 스위치는 아닙니다. 다만 정보가 명확히 라벨링된 병원은 그렇지 않은 병원보다 AI가 인용하기 유리한 조건을 갖추게 됩니다. 신뢰할 만한 콘텐츠, 일관된 채널 관리와 함께 갈 때 효과가 축적됩니다. 결과는 병원마다 다를 수 있습니다.
원장이 직접 코드를 작성해야 하나요?
아닙니다. 실제 코드 작업은 홈페이지 제작·관리 업체가 담당하는 것이 일반적입니다. 원장에게 필요한 것은 '의료기관용 구조화 데이터가 우리 사이트에 들어가야 한다'는 사실을 알고, 정확한 병원 정보를 전달하며, 결과를 검수하도록 요청하는 것입니다. 이 존재 자체를 아는 것과 모르는 것의 차이가 가장 큽니다.
네이버 플레이스나 구글 비즈니스 등록만으로는 부족한가요?
플레이스·비즈니스 프로필 등록은 매우 중요하지만, 그것만으로 우리 홈페이지가 기계에게 잘 읽히는 것은 아닙니다. 이상적인 것은 홈페이지의 구조화 데이터와 지도 등록 정보가 서로 일치하고 연결되는 상태입니다. 여러 채널의 상호·주소·전화가 어긋나면 AI가 같은 병원으로 확신하기 어려워, 각 채널을 통일하는 작업이 함께 필요합니다.
스키마에 '지역 1위'나 '최고 병원' 같은 표현을 넣어도 되나요?
권하지 않습니다. 근거 없는 최상급 표현은 의료광고 규정 측면에서 위험할 수 있고, AI 신뢰 측면에서도 도움이 되지 않습니다. 구조화 데이터의 목적은 과장이 아니라 정확한 사실을 기계가 오해 없이 읽도록 전달하는 것입니다. 이름·주소·진료시간·진료과목 같은 객관 정보를 정확히 채우는 데 집중하시길 권합니다.
스키마를 심은 뒤 제대로 됐는지 어떻게 확인하나요?
구글이 무료로 제공하는 '리치 결과 테스트(Rich Results Test)' 같은 검증 도구에 홈페이지 주소를 입력하면, 구조화 데이터가 오류 없이 인식되는지 확인할 수 있습니다. 코드에 오타가 있으면 통째로 무시되기도 하므로, 심는 것으로 끝내지 말고 반드시 검증 단계를 거쳐야 합니다. 화면에 보이는 정보와 스키마 정보가 일치하는지도 함께 점검하세요.
진료시간이나 주소가 바뀌면 스키마도 매번 고쳐야 하나요?
네, 그렇습니다. 이전·휴진·진료시간 변경·신규 진료 도입 등이 생기면 스키마도 함께 갱신해야 합니다. 낡고 어긋난 정보는 환자 불만을 낳을 뿐 아니라 AI가 판단하는 신뢰도까지 떨어뜨립니다. 한 번 심고 방치하기보다, 병원 정보가 바뀔 때마다 갱신하는 것을 기본 운영 절차에 포함하는 것이 좋습니다.
이 칼럼이 도움이 됐다면 공유해 주세요
원장님·마케팅 담당자에게 링크 한 번이면 됩니다.