ChatGPT나 Perplexity, 네이버 AI에 "우리 동네 ○○과 어디 있어?"라고 묻는 환자가 빠르게 늘고 있습니다. 문제는 AI가 대답을 만들 때 병원을 옛 명칭으로 부르거나, 개설하지 않은 진료과목을 붙이거나, 다른 의원의 전화번호를 섞어 인용하는 일이 적지 않다는 점입니다. 일반 상점이라면 약간의 오해로 끝날 일이, 의료에서는 환자 안전과 의료법 리스크로 이어집니다.
그래서 AI 검색 시대의 병원 사이트에서 중요한 것은 "노출" 그 자체가 아니라 "정확한 인용"입니다. AI는 웹에 흩어진 사실을 모아 문장을 생성하기 때문에, 사실이 구조화되어 있지 않거나 출처마다 다류면 그 불일치가 그대로 잘못된 답변이 됩니다. 이 글은 웨비스튜디오가 병원·의원 사이트를 제작하며 적용하는 GEO(Generative Engine Optimization) 설계와, AI의 인용 주체를 실측해 온 방법론을 근거로 무엇을 어떻게 판단해야 하는지 정리합니다.
검색 엔진이나 AI 답변에 노출된다고 해서 클릭, 내원, 상담 신청이 보장되는 것은 아닙니다. 이 글의 목표는 노출 극대화가 아니라, 인용되는 순간에 사실이 틀어지지 않게 만드는 설계입니다.
AI가 병원 정보를 오귀속하면 벌어지는 일
AI의 오귀속(hallucination)은 병원에서 세 가지 형태로 나타납니다. 첫째, 엔티티 혼동입니다. 같은 상권의 비슷한 이름의 의원과 명칭·위치가 뒤섞입니다. 둘째, 사실 오인용입니다. 진료시간, 진료과목, 예약 방법이 낡은 정보로 답변됩니다. 셋째, 근거 없는 서술의 귀속입니다. AI가 "이 병원은 ○○에 효과적" 같은 문장을 만들어 놓고 그 출처를 우리 사이트로 지목하는 경우입니다.
세 번째가 가장 위험합니다. 의료법 제56·57조와 시행령 제23·24조는 치료효과 단정, 최상급 수식, 환자 치료경험담·후기, 시술 전후 비교, 비급여 할인·이벤트·쿠폰·경품 제공을 내용으로 하는 광고를 금지합니다. 자체 홈페이지는 의료광고 사전심의 대상은 아니지만, 제56조의 금지 규정은 그대로 적용되고 자율심의기구의 사후 모니터링 대상입니다. 즉 AI가 그런 문장을 우리 콘텐츠에서 "읽었다"고 판단하게 만드는 소재는 처음부터 사이트에 존재해서는 안 됩니다.
판단 기준은 단순합니다. AI가 우리 병원에 대해 말할 수 있게 허용되는 것은 검증 가능한 사실뿐입니다. 의료기관 개설 명칭, 소재지, 법정 진료과목, 의료인의 면허·공인된 경력, 진료시간, 예약 방법이 전부입니다. 그 외의 서술은 인용을 유도하는 대상이 아니라 배제하는 대상입니다.
인용 가능한 사실의 경계: 의료법 프레임으로 설계하기
GEO를 의료 버티컬에 적용할 때 일반 산업과 갈라지는 지점이 여기입니다. 일반 기업은 "잘한다"는 평판을 인용시키는 것이 목표가 될 수 있지만, 병원은 평판이 아니라 사실의 정확도가 목표여야 합니다. 구조화 데이터에도 같은 기준이 적용됩니다. JSON-LD의 description에 효과를 암시하는 문구를 넣으면, 그 문구가 그대로 AI의 인용 소스가 됩니다.
표현 기준도 정해져 있습니다. "전문", "특화"는 전문병원 지정이나 법정 전문과목 표방 근거가 있을 때만 사용하고, 근거가 없으면 "중점진료"로 표기합니다. 진료과목은 스키마·본문·외부 프로필 어디에서든 법정 과목 명칭 그대로 씁니다. "○○ 클리닉" 같은 임의 명칭을 진료과목 자리에 넣으면, AI는 그것을 실제 과목으로 인용합니다.
엔티티 스키마: MedicalClinic과 sameAs
AI가 병원을 하나의 확정된 엔티티로 인식하게 만드는 1차 수단이 JSON-LD입니다. MedicalOrganization 타입을 기본으로 하되, 실제 의원급이라면 MedicalClinic을 사용해 name, address(PostalAddress), telephone, openingHours, medicalSpecialty를 명시합니다. medicalSpecialty에는 반드시 법정 진료과목을 그대로 넣습니다.
sameAs는 엔티티 해소(entity resolution)의 핵심입니다. 네이버 플레이스, 카카오맵, 건강보험심사평가원 병원정보처럼 공인되었거나 우리가 통제 가능한 프로필 URL을 묶어, "웹에 흩어진 이 병원 레코드들이 전부 같은 병원"이라는 신호를 줍니다. 반대로 통제 불가능한 제3자 게시물이나 체험단성 콘텐츠를 sameAs에 넣는 것은 엔티티를 오염시키므로 제외합니다.
구현 방식도 인용 품질에 영향을 줍니다. 웨비스튜디오에서는 모든 JSON-LD를 serializeJsonLd로 이스케이프해 <script type="application/ld+json">으로 출력합니다. 이스케이프가 누락되면 스크립트 파싱이 깨지고, 깨진 스키마는 기계가 읽지 못하거나 잘못 읽습니다. Next.js 15 App Router의 서버 렌더링 시점에 스키마를 확정하고 standalone 빌드로 배포해, 크롤러가 받는 HTML에 항상 완결된 구조화 데이터가 포함되게 합니다.
NAP 일관성: 사실의 단일 원천을 만든다
AI는 여러 출처를 교차 확인해 신뢰도를 판단합니다. 출처마다 사실이 다류면 AI는 하나를 골라 말하거나 둘을 섞습니다. 둘 다 우리가 원하는 결과가 아닙니다. NAP(Name, Address, Phone) 일관성은 그래서 순위 테크닉이 아니라 오귀속 방지 장치입니다.
| 항목 | 통일 기준 | 흔한 불일치 사례 |
|---|---|---|
| 개설 명칭 | 의료기관 개설 신고 명칭 | 옛 병원명·간판명 혼용 |
| 소재지 | 도로명 주소 표준형 | 지번/도로명 혼용, 층·호 표기 차이 |
| 전화번호 | 대표번호 단일화 | 예약용·상담용 번호의 출처별 분리 |
| 진료과목 | 법정 과목 명칭 그대로 | 임의의 클리닉 명칭을 과목처럼 표기 |
| 진료시간 | 요일별 표기 통일 | 점심시간·공휴일 표기 누락 |
운영 방식은 "단일 원천(single source of truth)" 하나로 요약됩니다. 웨비스튜디오의 검색의도 랜딩 팩토리는 병원의 사실 데이터를 데이터 객체 1개로 관리하고, 공통 React 템플릿이 이 객체에서 사이트 전 페이지의 명칭·주소·스키마를 렌더링합니다. 사실이 바뀌면 객체 하나를 고치면 되고, 수정 누락으로 인한 출처 간 불일치가 구조적으로 사라집니다. 외부 프로필(플레이스, 지도 서비스)도 같은 객체를 기준으로 맞춥니다.
/llms.txt와 기계 판독 채널
사이트 안의 사실을 AI가 찾아가는 길을 열어 두는 것도 설계 영역입니다. 웨비스튜디오가 병원 사이트에 기본으로 운영하는 채널은 세 가지입니다.
- /llms.txt: AI 크롤러를 위한 사이트 카탈로그입니다. 병원 기본정보 페이지, 진료과목 안내, 의료진 소개처럼 사실 확인에 필요한 페이지를 링크와 함께 정리합니다. 강제 표준은 아니지만, 기계에게 "무엇을 어디서 읽어야 하는지"를 알려 주는 비용 대비 효율이 좋은 장치입니다.
- /rss.xml: 콘텐츠 업데이트 신호를 기계가 구독할 수 있게 합니다.
- 런타임 /sitemap.xml: 빌드 시점이 아니라 요청 시점에 생성해, 신규 페이지가 색인 경로에서 누락되지 않게 합니다.
여기에 글마다 FAQPage 구조화 데이터를 붙입니다. "○○과 진료시간이 어떻게 되나요"처럼 환자가 실제로 AI에게 던지는 질문 형태로 답을 구조화해 두면, AI가 질의응답 단위로 인용하기 쉬워집니다. 다만 FAQ의 답변에도 동일한 의료법 기준이 적용됩니다. 효과나 경험담이 아니라 검증된 사실만 답변으로 씁니다.
얇은 페이지가 되지 않는 지역·분야별 랜딩
GEO에서 흔한 실패는 "지역 × 진료과목" 페이지를 기계적으로 찍어 내는 것입니다. 이름만 바꾼 동일 문장의 페이지 수십 개는 검색엔진에는 doorway(얇은/중복) 페이지로 판정되고, AI에게는 어느 페이지를 인용해야 할지 모르게 만드는 노이즈입니다.
웨비스튜디오의 판단 기준은 이렇습니다. 랜딩 팩토리로 지역·분야별 페이지 N개를 자동 생성하되, 각 페이지는 고유 데이터, 고유 canonical, 고유 JSON-LD를 가져야 합니다. 템플릿은 공유하되 내용은 공유하지 않습니다. 검증 방법은 단순합니다. 페이지 하나를 떼어 놓고 읽었을 때, 그 지역에서 그 진료를 찾는 환자의 실제 질문에 답이 되는가. 답이 안 되면 만들지 않습니다.
실측 방법론: 무엇을 보고 판단하는가
우리는 AI 인용을 추측이 아니라 관찰로 다룹니다. 병원명+지역, 진료과목+지역처럼 환자가 실제로 던질 질의 세트를 정해 두고, ChatGPT, Perplexity, 네이버 AI에 주기적으로 동일하게 실행해 세 가지를 기록합니다. 인용 여부, 인용 주체(우리 사이트인지, 플레이스인지, 제3자 매체인지), 인용된 사실의 정확도입니다.
이 글에 성과 수치를 싣지 않는 이유도 여기 있습니다. AI 답변은 비결정적이고 모델 업데이트로 수시로 바뀌기 때문에, 특정 시점의 노출 수치는 재현 가능한 근거가 되지 못합니다. 그래서 우리가 지표로 삼는 것은 순위가 아니라 두 가지입니다. 오귀속이 발생하는가, 그리고 인용 소스가 우리가 통제 가능한 사실 원천인가입니다.
| 점검 항목 | 판단 기준 | 불합격 시 대응 |
|---|---|---|
| 인용 주체 | 통제 가능한 자체 사이트·공인 프로필인가 | sameAs 정비, 제3자 오정보 정정 요청 |
| 명칭·소재지 정확도 | 개설 신고 명칭·표준 주소와 일치하는가 | 단일 데이터 원천에서 교정 후 전 채널 동기화 |
| 진료과목 표기 | 법정 과목 그대로 인용되는가 | 스키마·본문·프로필의 표기 통일 |
| 금지 표현 노출 | 효과 단정·후기성 문장이 인용에 섞이는가 | 해당 문구가 된 소스 콘텐츠 제거 |
정리하면 병원 GEO의 출발점은 "더 많이 인용되기"가 아니라 "틀리지 않게 인용되기"입니다. 검증된 사실을 단일 원천에서 구조화하고, sameAs와 NAP 일관성으로 엔티티를 확정하고, /llms.txt·sitemap·FAQPage로 기계가 읽는 길을 열어 두는 것. 그 다음에야 노출을 논할 수 있습니다.