환자는 AI에게 묻는데, 왜 우리 병원만 없을까 — MedicalOrganization 스키마 적용 7단계

환자가 AI 챗봇에 '○○동에서 임플란트 잘하는 치과'라고 물으면, AI는 열 개의 링크를 나열하는 대신 두세 곳의 이름을 문장 속에 넣어 답합니다. 이때 선택의 기준은 병원의 실력도, 지난달 광고비도 아닙니다. AI가 그 병원의 정보를 '오해 없이 확인할 수 있는가'입니다. MedicalOrganization 스키마는 병원의 이름·주소·진료과목·운영시간 같은 사실을 기계가 읽을 수 있는 표준 문법으로 표시해 두는 장치이며, AI 답변에 인용되기 위한 가장 기본적인 신원 증명입니다.

많은 원장님이 비슷한 경험을 합니다. 홈페이지는 깔끔하게 리뉴얼했고, 블로그도 꾸준히 쓰고, 후기도 나쁘지 않습니다. 그런데 직접 챗GPT나 제미나이에 우리 동네 진료과목을 물어보면 답변에는 길 건너 병원만 등장합니다. 심지어 그 병원은 우리보다 규모도 작고 홈페이지도 촌스럽습니다. 원장님은 자연스럽게 결론을 내립니다. '광고를 더 태워야 하나 보다.' 그러나 대부분의 경우, 문제는 지출이 아니라 정보의 형식입니다.

이 글은 그 형식의 정체를 밝히고, 우리 병원 홈페이지에 무엇을 어떤 순서로 심어야 하는지를 다룹니다. 개발 지식이 없어도 담당자에게 정확히 지시할 수 있을 만큼 구체적으로 설명하겠습니다.

AI는 우리 홈페이지를 '읽지' 않는다, '확인'한다

사람은 홈페이지에 들어와 분위기를 느낍니다. 사진이 세련됐는지, 원장 인사말이 진솔한지, 인테리어가 깨끗한지를 종합해 신뢰를 만듭니다. AI는 그렇게 하지 않습니다. AI가 하는 일은 훨씬 건조합니다. '이 병원의 정식 명칭은 무엇인가, 주소는 어디인가, 어떤 진료를 하는가, 지금 문을 여는가.' 이 질문들에 대해 서로 어긋나지 않는 답을 여러 곳에서 반복적으로 확인할 수 있을 때에야 AI는 그 병원을 답변에 올립니다.

여기서 AEO라는 말이 등장합니다. AEO(Answer Engine Optimization, 답변 엔진 최적화)는 검색 결과의 순위를 올리는 일이 아니라, AI가 만들어내는 답변 문장 안에 우리 병원이 언급되도록 준비하는 일입니다. 순위 경쟁이 '줄 서기'라면, AEO는 '면접장에 들어갈 자격을 갖추는 일'에 가깝습니다. 신원이 불분명한 지원자는 아무리 실력이 좋아도 면접장에 들어가지 못합니다.

여기서 손실은 조용히 발생합니다. 검색 광고는 클릭이 없으면 비용도 없지만, AI 답변에서 빠지는 일은 지표에 남지 않습니다. 환자는 AI에게 물어보고, 추천받은 세 곳 중 한 곳에 전화하고, 우리 병원 홈페이지는 방문조차 하지 않습니다. 유입이 줄었다는 사실만 보일 뿐 이유는 보이지 않습니다. 반대로 기회 쪽에서 보면, 아직 대부분의 병원이 이 준비를 하지 않았습니다. 지금 갖추는 병원은 경쟁이 거의 없는 구간에서 자리를 선점합니다.

한 가지 오해를 먼저 풀겠습니다. 구조화 데이터를 심는다고 해서 AI가 우리 병원을 '좋은 병원'이라고 판단하지는 않습니다. 이것은 평판을 만드는 작업이 아니라, 평판이 우리 병원에 제대로 귀속되도록 이름표를 다는 작업입니다. 이름표 없이 쌓인 평판은 다른 병원의 것으로 오해되거나, 아무의 것도 되지 못합니다.

구조화 데이터란 무엇인가 — 간판과 진료 안내판의 차이

구조화 데이터(structured data)는 웹페이지에 담긴 사실을 기계가 이해할 수 있는 형식으로 별도 표기해 두는 것을 말합니다. 사람이 보는 화면은 그대로 두고, 페이지 뒤편에 '이 글자는 병원 이름입니다', '이 숫자는 대표 전화입니다', '이 시간은 토요일 진료시간입니다'라고 꼬리표를 붙여 두는 방식입니다. 이 꼬리표의 국제 표준 어휘집이 schema.org이고, 그 안에 의료기관을 위해 마련된 항목이 MedicalOrganization입니다.

비유하자면 이렇습니다. 병원 외벽의 큰 간판은 사람을 위한 것입니다. 멀리서도 눈에 띄고 예쁘면 됩니다. 반면 출입구 옆의 진료 안내판은 정해진 양식이 있습니다. 진료과목, 진료시간, 휴진일, 대표자명이 정해진 자리에 정해진 형식으로 적혀 있습니다. 처음 온 사람도 어디를 봐야 할지 압니다. 구조화 데이터는 웹의 진료 안내판입니다. AI는 간판의 폰트를 감상하지 않고, 안내판의 항목을 읽습니다.

기술적으로는 JSON-LD라는 형식을 씁니다. 이름은 낯설지만 실체는 단순합니다. 홈페이지 소스 안에 사람 눈에는 보이지 않는 짧은 텍스트 블록을 하나 넣는 것이고, 디자인·레이아웃·속도에 영향을 주지 않습니다. 개발자에게 '메인 페이지 head 영역에 MedicalOrganization JSON-LD를 추가해 달라'고 하면 통하는 표현입니다. 워드프레스나 국내 병원 홈페이지 솔루션을 쓰고 있다면 대부분 코드 삽입 영역이 이미 마련돼 있습니다.

여기서 흔한 실수 하나. 플러그인을 설치하고 체크박스만 켜 두면 스키마가 자동으로 완성된다고 생각하는 경우입니다. 자동 생성된 스키마는 보통 '조직(Organization)' 수준의 일반 정보만 담고, 의료기관 특유의 항목은 비어 있습니다. 껍데기만 있고 내용이 없는 안내판인 셈입니다.

MedicalOrganization — 병원을 위해 따로 마련된 자리

schema.org에는 조직을 나타내는 일반 타입 Organization이 있고, 그 아래에 의료기관을 위한 MedicalOrganization이 있습니다. 그리고 다시 그 아래로 Dentist(치과), Physician(의원·전문의), Hospital(병원), MedicalClinic(클리닉) 같은 세부 타입이 놓입니다. 이 계층을 정확히 고르는 것이 첫 번째 실무 판단입니다. 치과가 스스로를 그냥 'Organization'으로 표기하면, AI 입장에서 그곳은 '어떤 사업체'일 뿐 '치과'가 아닙니다.

왜 이 구분이 중요한가. 환자의 질문은 언제나 진료과목과 지역이 결합된 형태로 들어옵니다. '역삼동 치과', '아이 데리고 갈 만한 소아과', '주말에 하는 정형외과'. AI가 이 질문에 답하려면 후보군을 '치과인 곳', '소아과인 곳'으로 먼저 좁혀야 합니다. 세부 타입이 없는 병원은 이 첫 번째 필터에서 조용히 탈락합니다. 홈페이지 본문에 '치과'라는 단어가 백 번 나와도, 기계가 확신할 수 있는 선언이 없으면 후보 목록에 남지 못합니다.

실제로 채워야 할 핵심 항목은 많지 않습니다. 다음을 우선순위대로 준비하십시오.

1. @type — Dentist, Physician, MedicalClinic 등 가장 구체적인 세부 타입 하나
2. name — 간판·사업자등록증·건강보험심사평가원 등록 명칭과 글자 하나까지 동일한 정식 명칭
3. address — 도로명 주소를 시/구/동/건물번호/우편번호로 쪼개어 기입
4. telephone — 국가번호를 포함한 형식(+82-2-...)으로 통일
5. openingHoursSpecification — 요일별 시작·종료 시각, 점심시간, 휴진일을 각각 분리
6. medicalSpecialty 및 availableService — 진료과목과 제공 진료 항목
7. url, sameAs — 공식 홈페이지와 네이버 플레이스·구글 비즈니스 프로필·공식 SNS 주소
8. geo — 위도·경도 좌표(지역 질의 대응력이 눈에 띄게 달라집니다)

주의할 점은 과장 금지입니다. 스키마는 마케팅 문구를 담는 곳이 아니라 사실을 담는 곳입니다. name 항목에 '강남 최고의 ○○치과'처럼 수식어를 넣거나, 실제로 하지 않는 진료를 medicalSpecialty에 나열하면 신뢰 신호가 오히려 훼손됩니다. 검증 가능한 사실만 넣는다는 원칙을 지키십시오.

1단계 — 우리 병원의 '사실 목록'부터 확정한다

코드를 건드리기 전에 해야 할 일이 있습니다. 종이 한 장에 우리 병원의 사실을 적어 내려가는 일입니다. 놀랍게도 대부분의 병원이 이 단계에서 무너집니다. 홈페이지에는 '○○치과의원', 네이버에는 '○○치과', 간판에는 '○○ 덴탈클리닉', 명함에는 옛 전화번호가 적혀 있습니다. 사람은 이것이 같은 병원임을 압니다. AI는 모릅니다.

AI가 정보를 신뢰하는 방식은 '교차 확인'입니다. 여러 출처에서 같은 사실이 반복되면 확신도가 올라가고, 어긋나면 확신도가 내려갑니다. 확신도가 일정 수준을 넘지 못하면 AI는 그 병원을 언급하지 않습니다. 틀린 답을 하느니 언급하지 않는 쪽이 안전하기 때문입니다. 이름 표기 하나가 흔들리는 병원은, 실력과 무관하게 '불확실한 대상'으로 분류됩니다.

다음 체크리스트로 사실 목록을 확정하십시오.

• 정식 명칭 하나를 결정한다(가능하면 사업자등록증·요양기관 등록 명칭 기준)
• 홈페이지 푸터, 네이버 플레이스, 구글 비즈니스 프로필, 카카오맵, 블로그 프로필, SNS 소개란의 명칭을 전부 그 하나로 통일한다
• 대표 전화는 하나로 정하고, 이벤트용 다른 번호는 스키마에 넣지 않는다
• 주소는 도로명 주소 기준으로 통일한다(지번 주소 병기는 본문에만)
• 진료시간·점심시간·휴진일을 실제 운영과 일치시킨다
• 변경 이력(이전 상호, 이전 주소)이 있다면 흩어진 옛 정보를 찾아 정리한다

이 작업은 하루면 끝나지만 효과는 오래갑니다. 반대로 이 단계를 건너뛰고 스키마부터 심으면, 서로 모순된 사실 두 벌을 AI에게 동시에 제출하는 셈이 됩니다. 확신도는 더 떨어집니다.

2단계 — 심고, 검증하고, 살아 있게 유지한다

사실 목록이 확정되면 이제 심을 차례입니다. 순서는 다음과 같습니다.

1. 메인 페이지에 MedicalOrganization JSON-LD를 배치한다. 병원 전체를 대표하는 신원 정보이므로 홈에 두는 것이 원칙입니다.
2. 진료과목 페이지에는 해당 진료 정보를 별도로 표기한다. 임플란트 소개 페이지에는 그 진료에 대한 설명을, 의료진 소개 페이지에는 Physician 정보를 연결합니다.
3. 구글 리치 결과 테스트와 schema.org 검증 도구로 문법 오류를 확인한다. 오탈자 하나로 전체 블록이 무시되는 일이 흔합니다.
4. 구글 서치 콘솔에서 색인 상태와 구조화 데이터 인식 여부를 확인한다. 심었다는 사실과 인식됐다는 사실은 다릅니다.
5. 변경 관리 주체를 정한다. 진료시간이 바뀌었는데 스키마만 옛 정보로 남아 있으면, 그때부터 스키마는 자산이 아니라 부채입니다.

다섯 번째 항목이 실무에서 가장 자주 무너지는 지점입니다. 스키마는 한 번 심고 끝나는 시공물이 아니라, 진료시간처럼 계속 갱신되는 살아 있는 정보입니다. 여름 휴진, 진료과목 추가, 의료진 변경이 있을 때 '홈페이지 수정 목록'에 스키마 항목을 반드시 포함시키십시오. 담당자가 바뀌어도 유지되도록, 수정 절차를 문서로 남겨 두는 편이 안전합니다.

흔한 실수 하나 더. 스키마를 넣었으니 AI에 곧 뜰 것이라 기대하는 경우입니다. 구조화 데이터는 입장권이지 당첨권이 아닙니다. 검색엔진이 재수집하고, 여러 출처의 정보가 일치하는지 확인되는 데에는 시간이 걸립니다. 일반적으로 수 주에서 수개월의 관찰 구간을 잡고, 그동안 다른 축을 함께 다져야 합니다.

스키마만으로는 부족하다 — AI가 교차 검증하는 세 축

구조화 데이터는 필요조건이지 충분조건이 아닙니다. AI가 병원을 답변에 올릴 때 실제로 대조하는 축은 크게 셋입니다. 세 축이 서로를 뒷받침할 때 확신도가 임계점을 넘습니다.

첫째, 신원의 일관성(Identity). 앞서 다룬 이름·주소·전화의 일치입니다. 스키마가 이 축의 중심이고, 지도 서비스와 각종 디렉터리가 이를 보강합니다.

둘째, 전문성의 근거(Expertise). AI는 '누가 쓴 글인가'를 봅니다. 의료진 소개 페이지에 전문의 자격, 학회 활동, 진료 경력이 구체적으로 정리돼 있고, 블로그 글마다 작성한 의료진이 연결돼 있는 병원과, 익명의 마케팅 대행사 글만 쌓인 병원은 다르게 취급됩니다. 저자 정보를 의료진에 연결하는 작업은 스키마 다음으로 투자 대비 효과가 큰 영역입니다.

셋째, 질문에 대한 직접적인 답(Answerability). AI는 인용하기 좋은 문장을 선호합니다. '토요일에도 진료하나요?'라는 질문에 대해, 페이지 어딘가에 '토요일은 오전 9시부터 오후 1시까지 진료합니다'라는 완결된 한 문장이 있는 병원이 유리합니다. 표와 이미지 안에만 시간표가 들어 있으면 인용될 문장이 없습니다. 자주 묻는 질문을 페이지 하단에 질문·답변 형태로 정리하고, 각 답변을 두세 문장의 완결형으로 쓰는 습관이 여기에 해당합니다.

세 축은 서로를 끌어올립니다. 신원이 명확하면 전문성이 우리 병원에 귀속되고, 전문성이 확인되면 우리 문장이 인용될 가치를 얻습니다. 반대로 신원이 흔들리면 나머지 둘의 성과가 다른 곳으로 새어 나갑니다. 스키마부터 손대야 하는 이유가 여기 있습니다.

병원장이 가장 자주 저지르는 다섯 가지 실수

현장에서 반복적으로 목격되는 유형입니다. 일반화된 예시이지만, 하나쯤은 우리 병원 이야기일 가능성이 높습니다.

실수 1. 홈페이지 리뉴얼과 함께 스키마가 사라진다. 새 홈페이지를 만들면서 이전 사이트에 있던 구조화 데이터가 통째로 빠지는 경우입니다. 디자인 계약서에 '기존 구조화 데이터 이전 및 검증'을 한 줄 넣어 두면 예방됩니다.

실수 2. 진료시간을 이미지로만 표시한다. 예쁜 시간표 이미지는 사람에게만 읽힙니다. 이미지와 함께 텍스트 시간표를, 그리고 스키마의 openingHoursSpecification을 반드시 함께 두십시오. 셋은 서로 대체재가 아니라 보완재입니다.

실수 3. 네이버 플레이스와 홈페이지 정보가 다르다. 특히 이전·확장 이후 옛 주소가 어딘가에 남아 있는 경우가 많습니다. AI는 두 정보를 모두 발견하고, 둘 중 무엇이 맞는지 판단하지 못한 채 확신도를 낮춥니다.

실수 4. 스키마에 마케팅 문구를 넣는다. '1등', '최고', '무통' 같은 표현은 사실 항목이 아닙니다. 의료광고 심의 기준과도 충돌할 수 있고, 기계 신뢰도 측면에서도 이득이 없습니다. 스키마는 광고 지면이 아닙니다.

실수 5. 심어 두고 잊는다. 6개월 뒤 진료시간이 바뀌었는데 스키마는 그대로입니다. 틀린 정보를 자신 있게 선언한 병원은, 아무것도 선언하지 않은 병원보다 신뢰를 잃습니다. 분기별 점검을 캘린더에 등록하십시오.

무엇부터 할 것인가 — 2주 실행 로드맵

모든 것을 한 번에 할 필요는 없습니다. 순서가 성과를 만듭니다. 아래 순서대로만 진행해도 대부분의 병원이 기본 요건을 갖춥니다.

1. 1~3일차: 사실 목록 확정. 정식 명칭·주소·전화·진료시간을 하나로 정리한다.
2. 4~5일차: 홈페이지 푸터, 네이버 플레이스, 구글 비즈니스 프로필, 카카오맵, SNS 소개란의 표기를 전부 통일한다.
3. 6~8일차: 메인 페이지에 세부 타입이 정확한 MedicalOrganization JSON-LD를 삽입하고 검증 도구로 오류를 제거한다.
4. 9~11일차: 의료진 소개 페이지를 정비하고, 블로그·칼럼의 저자를 실제 의료진에 연결한다.
5. 12~14일차: 자주 묻는 질문 6~10개를 완결형 문장으로 작성해 주요 페이지 하단에 배치한다.
6. 이후 분기마다: 진료시간·의료진·진료과목 변경 시 스키마 동시 갱신. 점검일을 캘린더에 고정한다.

이 작업의 본질은 기술이 아니라 정리 정돈입니다. 우리 병원이 이미 갖고 있는 사실을, 기계가 오해하지 않도록 한 벌로 맞추는 일입니다. 비용은 거의 들지 않고, 대행사 없이도 상당 부분 진행할 수 있습니다. 다만 순서를 틀리면 노력이 새어 나갑니다. 신원부터, 그다음 전문성, 마지막에 답변 문장입니다.

구조화 데이터는 AI에게 잘 보이려는 기교가 아니라, 우리 병원이 누구인지 오해 없이 말하는 방법입니다. 좋은 병원이 좋은 병원으로 읽히게 하는 최소한의 장치입니다.

지금 확인해 볼 수 있는 가장 빠른 방법이 있습니다. AI 챗봇을 열고 우리 병원 이름을 그대로 입력해 보십시오. 주소와 진료시간이 정확히 나오는지, 진료과목을 제대로 인식하는지 보십시오. 답이 틀리거나 모호하다면, 그것이 바로 지금 우리 병원의 신원 상태입니다. 어디가 어긋나 있는지 스스로 확인하기 어렵다면, AI메디랩의 무료 진단으로 현재 스키마 적용 여부와 정보 불일치 지점을 점검해 보시기 바랍니다. 고쳐야 할 곳은 대개 생각보다 적고, 대개 생각보다 빨리 효과가 나타납니다.