챗GPT는 왜 옆 병원만 추천할까 — AI가 우리 병원을 '읽지 못하게' 만드는 MedicalOrganization 스키마 공백

환자가 챗GPT나 네이버 AI에게 '○○동에서 잘하는 치과'를 물었을 때 우리 병원이 언급되지 않는 가장 흔한 기술적 원인은, AI가 병원 홈페이지의 정보를 '구조화된 데이터'로 읽지 못하기 때문이다. MedicalOrganization 스키마는 병원의 이름·진료과목·위치·진료시간을 AI가 오해 없이 인용할 수 있는 표준 형식으로 번역해 주는 가장 기본적인 장치다. 이 글은 스키마가 왜 AI 인용의 출발점인지, 병원 현장에서 무엇을 어떤 순서로 적용해야 하는지를 단계별로 정리한다.

이런 장면을 상상해 보자. 개원 12년 차, 홈페이지도 몇 해 전에 새로 만들었고 블로그도 꾸준히 운영해 왔다. 그런데 어느 날 지인이 '챗GPT에 물어보니 이 동네 병원으로 옆 건물 의원만 나오던데요'라고 말한다. 검색 포털에서는 상위에 뜨는 병원이 왜 AI 답변에서는 존재하지 않는 것처럼 취급될까. 광고비 문제도, 콘텐츠 양의 문제도 아닌 경우가 많다. AI가 그 병원의 정보를 '확신을 갖고 인용할 수 있는 형태'로 받아 본 적이 없기 때문이다.

AI는 홈페이지를 '보지' 않는다 — 데이터로 '이해'한다

사람은 홈페이지를 열면 로고와 사진, 메뉴 배치를 보고 몇 초 만에 '아, 정형외과구나. 역 근처네'라고 파악한다. 그러나 AI는 화면을 보는 것이 아니라 코드와 텍스트를 읽는다. 문제는 병원 홈페이지의 상당수가 상호·진료과목·주소 같은 핵심 정보를 이미지 배너나 디자인 요소 안에 넣어 두었다는 점이다. 사람 눈에는 선명하지만, 기계에게는 빈 공간이나 다름없다.

더 까다로운 지점은 '읽는 것'과 '확신하는 것'의 차이다. AI가 페이지 어딘가에서 병원 이름을 발견하더라도, 그것이 병원 상호인지, 인용된 다른 병원인지, 옛 이름인지 판단할 근거가 없으면 답변에 올리지 않는다. AI 답변은 틀리면 안 되는 자리이기 때문에, 확신이 없는 정보는 조용히 배제된다. 그 빈자리를 정보가 명확하게 정리된 경쟁 병원이 차지한다.

이것이 손실의 실체다. 진료를 못해서가 아니라, 진료 정보를 기계가 확신할 수 없는 방식으로 올려 두었기 때문에 추천 목록에서 빠진다. 반대로 보면 기회이기도 하다. 아직 국내 병·의원 중 구조화 데이터를 제대로 갖춘 곳은 많지 않아서, 기본만 갖춰도 같은 상권 안에서 '기계가 읽을 수 있는 몇 안 되는 병원'이 될 수 있다.

스키마란 무엇인가 — 기계에게 건네는 표준 명함

스키마(Schema), 정확히는 '스키마 마크업' 또는 '구조화 데이터'는 홈페이지 코드 안에 넣는 일종의 표준 명함이다. 사람에게 보이는 화면과 별도로, '이 페이지의 주체는 의료기관이고, 이름은 무엇이고, 주소와 전화번호, 진료과목은 이것이다'를 기계가 즉시 이해하는 약속된 형식으로 선언해 두는 것이다. 구글·마이크로소프트 등이 함께 만든 schema.org라는 국제 표준 어휘를 쓰기 때문에, 한 번 제대로 넣으면 검색엔진과 AI 서비스가 공통으로 읽는다.

비유하자면 이렇다. 외국 바이어와의 미팅에서 명함 없이 '우리 회사는 대충 이런 일을 합니다'라고 말로만 설명하는 회사와, 표준 양식의 명함과 회사 소개서를 건네는 회사가 있다면 누가 정확히 기록될까. 스키마는 AI라는 바이어에게 건네는 표준 양식의 명함이다. 명함이 없다고 거래가 불가능한 것은 아니지만, 상대가 우리를 잘못 기억하거나 아예 기억하지 못할 확률이 크게 올라간다.

기술적으로는 JSON-LD라는 형식이 사실상의 표준이다. 홈페이지 디자인을 전혀 건드리지 않고, 코드 상단에 별도의 데이터 블록 하나를 얹는 방식이라 기존 사이트에 부담 없이 적용할 수 있다. 개발사에 '진료 정보를 JSON-LD 형식의 스키마로 넣어 달라'고 요청하면 통하는 수준의 보편적인 작업이다.

왜 하필 MedicalOrganization인가

schema.org에는 수백 가지 유형이 있는데, 병·의원이 가장 먼저 선언해야 할 유형이 MedicalOrganization(의료기관)이다. 일반 기업을 뜻하는 Organization이나 동네 상점을 뜻하는 LocalBusiness로도 기본 정보는 전달되지만, '의료기관'이라는 정체성 자체가 빠진다. AI가 '병원을 추천해 달라'는 질문을 받았을 때 후보군을 추리는 첫 기준이 바로 이 유형 선언이라고 이해하면 된다.

의료는 AI가 가장 보수적으로 답하는 영역이다. 잘못 추천하면 이용자에게 실질적 피해가 갈 수 있어, AI는 출처가 명확하고 정체성이 검증 가능한 기관을 우선 인용하려는 경향을 보인다. MedicalOrganization 선언은 '우리는 스스로를 의료기관으로 공식 선언했고, 그에 걸맞은 정보 구조를 갖췄다'는 신호다. 이 신호가 없으면 아무리 좋은 칼럼을 쌓아도 그 콘텐츠가 '어느 의료기관의 것인지'가 기계 입장에서 흐릿하다.

또 하나의 이유는 확장성이다. MedicalOrganization을 뿌리로 두면 이후 의사 개인(Physician), 진료과목, 자주 묻는 질문(FAQPage) 같은 스키마를 가지처럼 연결할 수 있다. 뿌리 없이 가지만 심으면 각 정보가 서로 연결되지 않은 파편으로 남는다. 순서가 중요한 이유다.

오늘 적용할 핵심 속성 — 무엇을 어떤 순서로 넣나

스키마라고 해서 모든 항목을 다 채울 필요는 없다. 오히려 핵심 속성을 정확하게 채우는 것이 어설프게 많이 채우는 것보다 낫다. 병원장이 개발사나 담당자에게 지시할 때 기준으로 삼을 수 있는 우선순위는 다음과 같다.

1. name(기관명): 의료기관 개설 신고상 명칭과 간판·홈페이지 표기를 통일한다. '서울OO의원'과 'OO클리닉'이 섞여 있으면 기계는 다른 기관으로 볼 수 있다.
2. address·telephone(주소·전화): 네이버 플레이스, 구글 비즈니스 프로필에 등록된 표기와 글자 단위로 일치시킨다. 이 일치 여부가 기계가 '같은 병원'임을 확인하는 핵심 단서다.
3. url·logo·image: 공식 홈페이지 주소와 로고, 대표 이미지를 지정해 다른 사이트에 흩어진 정보와 우리 병원을 연결할 기준점을 만든다.
4. medicalSpecialty(진료 분야): 표방 가능한 진료과목 범위 안에서 명시한다. AI가 '피부과 추천'류 질문에서 후보를 거르는 1차 필터다.
5. openingHours(진료시간): 점심시간·야간·토요일 진료까지 구조화한다. '지금 문 연 병원' 같은 실용 질문에서 인용될 근거가 된다.
6. sameAs: 네이버 플레이스, 공식 블로그 등 공식 채널 주소를 연결해 '이 채널들이 전부 같은 병원'임을 선언한다.

실행 순서도 단순하다. 첫째, 위 항목의 '정답 표기'를 원내에서 하나로 확정한 문서로 만든다. 둘째, 그 문서를 기준으로 개발사에 JSON-LD 적용을 요청한다. 셋째, 홈페이지 밖 채널(플레이스·지도·포털 프로필)의 표기를 같은 정답으로 맞춘다. 이 세 단계 중 첫째가 병원장만 할 수 있는 일이고, 실제로 가장 자주 생략되는 일이다.

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

스키마를 '넣었다'는 병원 중에서도 효과를 보지 못하는 경우가 있는데, 유형이 대체로 비슷하다. 첫째는 화면과 데이터의 불일치다. 스키마에는 평일 저녁 8시까지 진료로 되어 있는데 실제로는 6시 마감이라면, 기계는 이 병원의 데이터 전체에 대한 신뢰를 낮춘다. 사람에게 한 번 틀린 명함을 준 것과 같아서, 이후 정보도 의심받는다.

둘째는 메인 페이지에만 넣고 끝내는 경우다. AI는 특정 진료 관련 질문에 답할 때 메인이 아니라 해당 주제 페이지를 근거로 삼는 경우가 많다. 기관 스키마는 사이트 전반에서 일관되게 참조되도록 설계해야 하며, 최소한 주요 안내 페이지들이 같은 기관 정보와 연결되어야 한다.

셋째는 과욕이다. 검증할 수 없는 수상 이력, 표방 범위를 넘는 진료과목, 후기 점수 같은 것을 스키마에 넣는 경우인데, 의료광고 규제 관점에서도 위험하고 데이터 신뢰 관점에서도 손해다. 스키마는 자랑하는 자리가 아니라 사실을 선언하는 자리다. 넷째는 한 번 넣고 방치하는 것이다. 진료시간 변경, 이전, 대표번호 변경이 스키마에 반영되지 않으면 오히려 오답의 출처가 된다. 분기마다 한 번, 정답 문서와 실제 데이터를 대조하는 루틴이 필요하다.

제대로 들어갔는지 확인하는 법 — 10분 검증 루틴

적용 후 검증은 외부 업체 없이도 가능하다. 구글이 무료로 제공하는 리치 결과 테스트나 schema.org 검증 도구에 홈페이지 주소를 넣으면, 스키마가 인식되는지와 오류 여부를 바로 보여준다. 개발사에 작업을 맡겼다면 '검증 도구 통과 화면'을 납품 기준으로 요구하는 것이 좋다.

더 실전적인 검증은 AI에게 직접 물어보는 것이다. 챗GPT 등 검색 연동이 되는 AI에게 우리 병원 이름을 물었을 때 주소·진료과목·진료시간을 정확히 답하는지, 지역+진료과목 질문에서 우리 병원이 후보로 등장하는지를 확인한다. 스키마 반영이 AI 답변에 나타나기까지는 수집 주기 때문에 시간이 걸리므로, 적용 직후가 아니라 몇 주 간격을 두고 같은 질문을 반복해 변화를 기록하는 것이 합리적이다.

• 리치 결과 테스트에서 오류 0건 확인
• AI에게 병원명 질문 → 주소·전화·진료시간 정답 여부 기록
• 지역+진료과목 질문 → 우리 병원 언급 여부를 월 단위로 기록
• 플레이스·지도·홈페이지 표기 일치 여부 분기별 점검

이 기록은 그 자체로 마케팅 자산이 된다. 어떤 조치 후에 어떤 질문에서 언급되기 시작했는지가 쌓이면, 감이 아니라 데이터로 다음 투자를 결정할 수 있다.

스키마는 자격증이지 합격증이 아니다 — 다음 단계

분명히 해 둘 것이 있다. MedicalOrganization 스키마를 넣는다고 AI가 곧바로 우리 병원을 추천하는 것은 아니다. 스키마는 시험으로 치면 응시 자격이다. 자격이 없으면 아예 채점 대상에서 빠지지만, 자격만으로 합격하는 것도 아니다. 합격을 가르는 것은 그 위에 쌓이는 콘텐츠와 신뢰 신호다.

스키마라는 뿌리가 자리 잡으면 확장 순서는 명확하다. 환자들이 실제로 묻는 질문에 답하는 페이지에 FAQ 스키마를 얹어 AI가 문답 단위로 인용하기 좋게 만들고, 의료진 소개에 Physician 스키마를 적용해 '누가 진료하는가'라는 신뢰 질문에 답하게 한다. 진료과목별 안내 페이지를 충실히 만들어 기관 스키마와 연결하면, '이 지역에서 이 진료를 하는 검증 가능한 기관'이라는 그림이 완성된다.

순서를 뒤집으면 효율이 급격히 떨어진다. 콘텐츠부터 쏟아붓고 스키마를 나중에 챙기는 병원은, 좋은 답안지를 응시 자격 없이 제출해 온 셈이다. 기초 공사가 먼저다.

무엇부터 할 것인가 — 이번 주 실행 체크리스트

정리하면 우선순위는 세 가지다. 첫째, 병원 정보의 '정답 표기'를 문서 하나로 확정한다(원장 결재 사항, 반나절). 둘째, 그 문서 기준으로 홈페이지에 MedicalOrganization 스키마를 JSON-LD로 적용하고 검증 도구 통과를 확인한다(개발사 요청, 통상 수일). 셋째, 플레이스·지도 등 외부 채널 표기를 정답에 맞추고, AI에게 묻는 월간 모니터링 루틴을 시작한다.

• 이번 주: 기관명·주소·전화·진료시간·진료과목 정답 문서 확정
• 다음 주: 개발사에 JSON-LD 스키마 적용 요청, 검증 화면 수령
• 이번 달: 외부 채널 표기 통일, AI 질문 테스트 1회차 기록
• 분기마다: 정보 변경 반영 여부와 AI 답변 변화 점검

다만 현재 우리 병원이 어느 단계에 있는지 — 스키마가 아예 없는지, 있는데 오류가 있는지, 표기 불일치가 발목을 잡는지 — 는 밖에서 진단해 봐야 정확히 보인다. AI메디랩의 무료 진단은 이 글에서 다룬 항목들을 실제 병원 홈페이지에 대입해 현재 상태와 우선 조치 순서를 리포트로 제공한다. 어디부터 손대야 할지 판단이 서지 않는다면, 진단 결과를 첫 번째 정답 문서로 삼는 것도 방법이다.