AEO

의료법 안에서 병원 FAQ 스키마로 AI 답변에 노출되기

병원·의원 홈페이지의 진료 안내 질문을 FAQPage 구조화 데이터로 정리해 구글 AI Overview와 답변박스에 인용될 확률을 높이는 방법. 의료법 제56조가 금지하는 표현을 피하는 질문 선별 기준과 answer-first 답변 설계, 화면·스키마 일치 원칙을 다룹니다.

2026-09-03·웨비스튜디오

#병원 홈페이지#FAQ 구조화 데이터#AEO#JSON-LD#의료광고 규제#AI 검색 노출

핵심 요약

병원 FAQ를 AI 답변에 노출시키려면 진료과목 범위, 준비물, 예약·접수 절차, 진료시간, 초진 안내처럼 개인 상태 판단이 아닌 운영 사실 질문만 골라 FAQPage JSON-LD로 구조화합니다. 각 답변은 첫 문장 안에서 결론이 끝나는 answer-first 형태로 쓰고, 화면에 보이는 텍스트와 스키마 문장을 정확히 일치시킵니다. 치료효과 단정, 후기, 전후 비교, 할인·이벤트는 화면과 스키마 어디에도 넣지 않습니다.

핵심 판단

질문의 안전 여부는 '환자 개인 상태에 대한 판단인가, 병원의 운영 사실인가'라는 한 줄 기준으로 대부분 가려낼 수 있습니다.
AI는 페이지를 통째로 요약하지 않고 답변 단위를 잘라내므로, 첫 문장 안에서 결론이 끝나는 answer-first 답변이 발췌 확률을 높입니다.
화면에 보이지 않는 내용을 스키마에만 넣는 구성은 정책 위반이며, 실시간 페치 경로에서는 인용되지도 않으므로 실익이 없습니다.
지역·진료분야 페이지를 늘릴 때는 공통 템플릿을 쓰되 데이터·canonical·JSON-LD를 페이지마다 고유하게 유지해야 얇은 중복 페이지를 피할 수 있습니다.
Review와 AggregateRating은 범용 SEO에서 흔히 권장되지만 의료기관 사이트에서는 기본적으로 사용하지 않습니다.
구조화 데이터는 기계의 이해 확률을 높이는 장치일 뿐 순위나 인용, 내원을 보장하지 않으므로 파싱 성공, 질의 성격, 행동 순으로 4~6주에 걸쳐 판단합니다.

환자가 병원을 찾기 전 검색창에 넣는 문장은 대부분 질문 형태다. "위내시경 전날 뭐 먹으면 안 되나요", "토요일은 몇 시까지 접수하나요", "처음 가는데 뭘 챙겨가야 하나요" 같은 것들이다. 이 질문들의 답은 대개 이미 병원 홈페이지 어딘가에 적혀 있다. 문제는 그 답이 병원 소개 문단 한가운데 섞여 있어서, 사람은 읽어내지만 기계는 잘라내지 못한다는 것이다.

구글 AI Overview와 답변박스는 페이지 전체를 통째로 요약하지 않는다. 질문에 대응하는 답변 단위를 페이지에서 잘라내 인용한다. 잘라낼 경계가 명확한 페이지가 선택되고, 경계가 흐린 페이지는 건너뛴다. FAQPage 구조화 데이터는 그 경계를 문서 안에서 명시적으로 선언하는 가장 값싼 수단이다. 디자인을 갈아엎지 않고도 붙일 수 있고, 이미 있는 정보를 재배치하는 작업에 가깝다.

다만 병원은 여기서 한 겹을 더 생각해야 한다. FAQ는 말투가 자유로운 영역이라 규제를 밟기 쉽다. "이 시술 받으면 좋아지나요"라는 질문에 "네, 대부분 호전됩니다"라고 답하는 순간 그것은 치료효과를 단정한 의료광고가 된다. 자체 홈페이지는 사전심의 대상이 아니지만, 의료법 제56조의 금지 규정은 그대로 적용되고 자율심의기구의 사후 모니터링 대상이다. 심의를 받지 않는다는 말은 검열이 없다는 뜻이지, 위반이 면제된다는 뜻이 아니다.

안전한 질문과 금지 질문을 가르는 기준 한 줄

유형을 통째로 외우는 것보다 판단 기준 하나를 쥐는 편이 실무에서 빠르다. 기준은 이것이다. 이 답변이 환자 개인의 상태에 대한 판단인가, 아니면 우리 병원의 운영 사실인가.

운영 사실은 검증 가능하고 환자마다 달라지지 않는다. 반면 임상 판단은 진료 없이 말하는 순간 그 자체로 원격 진단이거나 효과 단정이 된다. 이 한 줄로 대부분의 질문이 갈린다.

유형	질문 예시	판단 근거
진료과목 범위	이비인후과에서는 어떤 증상을 보나요	안전. 법정 진료과목이 일반적으로 다루는 범위 서술
준비물	위내시경 전 금식은 몇 시간인가요	안전. 원내 안내 기준을 그대로 옮김
예약·접수 절차	예약 없이 방문해도 접수되나요	안전. 운영 사실
진료시간	점심시간과 토요일 진료시간은 언제인가요	안전. 운영 사실
초진 안내	처음 방문할 때 챙길 서류가 있나요	안전. 신분증, 진료의뢰서, 복용 중인 약 목록 등
치료효과	이 치료 받으면 낫나요	금지. 치료효과를 오인하게 하는 표현
시술 권유	제 경우엔 어떤 시술이 좋을까요	금지. 특정 시술 유인 및 개인별 판단
진단	이런 증상이면 무슨 병인가요	금지. 비대면 진단
사회적 증명	다른 환자들은 만족했나요	금지. 치료경험담 유도
가격 유인	지금 예약하면 할인되나요	금지. 비급여 할인·이벤트

경계에 걸치는 질문은 주어를 바꿔 살린다. "이 검사 받으면 조기 발견되나요"는 금지지만, "이 검사는 어떤 목적으로 시행하나요"는 검사의 일반적 목적을 서술하는 안전한 질문이다. 주어가 '환자 개인의 결과'에서 '검사·과목의 성격'으로 옮겨가면 대부분 통과한다.

표기에도 같은 원칙이 적용된다. '전문'과 '특화'는 전문병원 지정이나 법정 전문과목 같은 법적 근거가 있을 때만 쓴다. 근거가 없으면 '중점진료'로 적는다. 진료과목명은 임의로 조합하지 말고 법정 과목 그대로 쓴다. FAQ 답변 안에서도 예외가 없다.

answer-first: 첫 문장 안에서 답을 끝낸다

FAQ 답변의 첫 문장이 곧 발췌 후보다. 배경 설명으로 시작하는 답변은 잘라낼 지점이 없어서 통째로 버려진다.

고쳐 쓰기 전

저희 병원은 환자분들의 편의를 최우선으로 생각하여 다양한 진료 시간대를 운영하고 있으며, 바쁜 직장인분들을 위해 토요일에도 진료를 시행하고 있습니다.

고쳐 쓴 뒤

토요일 진료는 오전 9시부터 오후 1시까지이며 접수는 낮 12시 30분에 마감합니다. 일요일과 공휴일은 휴진입니다.

두 번째 문장은 그 자체로 완결된 답이다. 문장 안에 숫자와 조건이 들어 있어서, 페이지 밖으로 떼어놓아도 의미가 유지된다. 발췌 가능성을 높이는 실무 규칙은 다음과 같다.

첫 문장 40~60자 안에 결론을 끝낸다. 부연은 두 번째 문장부터.
시간, 횟수, 금액 구간, 요일 같은 구체값을 문장 안에 넣는다. "빠른 시일 내"가 아니라 "영업일 기준 1~2일".
한 질문에 한 주제만 담는다. 두 가지를 묻는 질문은 두 개로 쪼갠다.
답변 길이는 2~4문장, 300자 안쪽으로 유지한다. 길면 어느 부분이 답인지 모델이 결정하지 못한다.
마케팅 수식어를 뺀다. "최고의", "국내 유일", "완벽한" 같은 최상급은 의료법상 금지이면서 동시에 발췌 품질도 떨어뜨린다. 규제와 기계 가독성이 같은 방향을 가리키는 드문 경우다.

FAQPage JSON-LD를 붙이는 방법

웨비스튜디오는 모든 구조화 데이터를 하나의 @graph로 묶어 페이지당 스크립트 태그 하나로 출력한다. 문서와 FAQ가 같은 @id를 참조하게 만들어야 두 엔티티가 별개 문서로 오인되지 않는다.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "MedicalWebPage",
      "@id": "https://example.co.kr/faq#webpage",
      "url": "https://example.co.kr/faq",
      "name": "진료 안내 자주 묻는 질문"
    },
    {
      "@type": "FAQPage",
      "@id": "https://example.co.kr/faq#faq",
      "mainEntityOfPage": { "@id": "https://example.co.kr/faq#webpage" },
      "mainEntity": [
        {
          "@type": "Question",
          "name": "토요일 진료시간은 어떻게 되나요?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "토요일 진료는 오전 9시부터 오후 1시까지이며 접수는 낮 12시 30분에 마감합니다. 일요일과 공휴일은 휴진입니다."
          }
        }
      ]
    }
  ]
}

출력 단계에서는 직렬화를 직접 하지 않고 공통 유틸을 거친다. 우리 코드베이스의 serializeJsonLd는 문자열 안의 <를 \u003c로 치환한다. 답변 텍스트에 < 문자가 섞였을 때 스크립트 태그가 조기에 닫히면서 JSON-LD 전체가 깨지는 사고를 막기 위한 것이다. 사소해 보이지만, 구조화 데이터가 조용히 무효화되는 사고의 상당수가 이 지점에서 난다.

<script
  type="application/ld+json"
  dangerouslySetInnerHTML={{ __html: serializeJsonLd(schemaGraph) }}
/>

acceptedAnswer.text에는 HTML 태그를 넣지 않는다. 순수 텍스트로 두면 발췌 시 그대로 쓰이지만, 태그가 섞이면 정제 과정에서 문장이 잘려나갈 수 있다.

AI가 답을 추출하는 경로를 역산하기

구조화 데이터를 붙였는데 아무 일도 안 일어난다고 느끼는 이유는 대개 경로를 하나만 보기 때문이다. 실제로는 세 갈래가 동시에 작동한다.

검색 인덱스 경유 — 크롤러가 페이지를 수집하고, 스키마는 문서 안의 어느 문장이 어느 질문에 대응하는지 알려주는 힌트로 쓰인다. 스키마가 없어도 발췌는 되지만 있으면 경계가 명확해진다.
실시간 페치 — 대화형 어시스턴트가 답변 도중 URL을 직접 읽는다. 이때는 렌더링된 본문 텍스트가 근거가 된다. 화면에 없고 스키마에만 있는 문장은 근거로 잡히지 않는다.
카탈로그 경유 — 기계 판독용 목록을 통해 어떤 URL이 무엇을 다루는지 미리 파악한다.

세 번째를 위해 우리는 /llms.txt를 정적 라우트로 운영하고, 발행된 글마다 URL·제목·요약 한 줄을 카탈로그에 넣는다. /rss.xml과 런타임 /sitemap.xml도 함께 유지한다. 병원 사이트라면 진료 안내 FAQ 페이지와 진료과목 페이지가 이 카탈로그에 반드시 들어가야 한다.

여기서 핵심은 2번이다. 스키마는 화면 내용을 설명하는 것이지 대체하는 것이 아니다.

화면 텍스트와 스키마는 반드시 일치시킨다

구글 구조화 데이터 정책은 사용자에게 보이지 않는 내용을 마크업하는 것을 명시적으로 금지한다. 스팸 판정 위험도 있지만, 그 이전에 실무적으로 무용하다. 실시간 페치 경로에서는 화면 텍스트만 읽히기 때문에 스키마에만 숨긴 답변은 어차피 인용되지 않는다.

의료 도메인에서는 이 원칙이 규제 방어선으로도 작동한다. 화면과 스키마가 같은 문장이면, 점검 대상은 하나로 줄어든다. 두 벌을 관리하는 순간 화면은 정제되어 있는데 스키마에는 예전 문구가 남아 있는 사고가 반드시 난다.

화면 아코디언을 접어두는 것은 허용된다. 사용자가 클릭해 펼칠 수 있으면 '보이는 콘텐츠'다.
화면에 3개, 스키마에 8개를 넣는 구성은 금지다. 개수와 문장이 정확히 같아야 한다.
FAQ 원문을 CMS 데이터 한 곳에서 관리하고, 화면 컴포넌트와 JSON-LD가 같은 소스를 참조하게 만든다. 불일치를 사람의 주의력으로 막지 말고 구조로 막는다.

지역·진료분야별로 확장할 때 피할 함정

FAQ가 효과를 보이면 자연히 "지역명 + 진료과목" 조합으로 페이지를 늘리고 싶어진다. 여기서 대부분이 얇은 중복 페이지(doorway page)를 양산하고 색인에서 통째로 빠진다.

우리가 쓰는 검색의도 랜딩 팩토리는 데이터 객체 1개 + 공통 React 템플릿 구조다. 템플릿은 공유하되, 페이지마다 다음 셋을 반드시 고유하게 가진다.

요소	요구사항	실패 시 증상
데이터	페이지별 고유 본문·FAQ 문항	중복 콘텐츠 판정, 색인 제외
canonical	자기 자신을 가리키는 고유 URL	대표 URL 하나로 통합되어 나머지 소실
JSON-LD	페이지 데이터에서 생성된 고유 스키마	전 페이지 동일 스키마, 신뢰도 하락

판단 기준은 단순하다. 템플릿을 걷어냈을 때 이 페이지에만 있는 정보가 남는가. 지역명만 치환된 페이지라면 답은 '아니오'이고, 만들지 않는 편이 낫다. 분원별로 진료시간·접수 마감·주차 안내·초진 준비물이 실제로 다르다면 답은 '예'이고, 그 차이가 곧 페이지의 존재 이유이자 FAQ 문항이 된다.

기술 스택은 Next.js 15 App Router에 standalone 빌드다. 페이지가 늘어도 빌드 산출물과 배포 단위가 예측 가능하게 유지되는지, 라우트 증가가 응답 시간을 끌지 않는지는 확장 전에 확인해 둔다.

면책 문구와 넣지 않을 것들

의료 FAQ에는 답변이 일반 정보이며 개별 진료를 대체하지 않는다는 문구를 둔다. 위치는 FAQ 섹션 하단, 화면에 보이는 자리다. 개별 acceptedAnswer 안에 매번 넣으면 발췌 문장이 오염되므로 답변 본문에는 넣지 않는다.

본 안내는 일반적인 정보 제공을 목적으로 하며 개별 환자에 대한 진단이나 치료 방침을 대신하지 않습니다. 증상에 대한 판단은 내원 후 의료진의 진료를 통해 이루어집니다.

그리고 스키마에도, 화면에도 넣지 않는 항목이 있다. 이건 선택이 아니라 배제 목록이다.

환자 치료경험담, 실명·이니셜 후기, 별점, Review·AggregateRating 스키마
시술 전후 비교 사진 및 그에 준하는 서술
비급여 진료의 할인, 이벤트, 쿠폰, 경품, 기간 한정 문구
치료효과를 단정하거나 보장하는 표현, 최상급 수식어
타 의료기관과의 직접 비교 우위 주장

Review와 AggregateRating은 다른 업종에서 클릭률을 올리는 대표적인 스키마다. 그래서 범용 SEO 가이드를 그대로 따라 하다 위반하는 경우가 자주 생긴다. 의료기관 사이트에서는 이 두 타입을 아예 쓰지 않는 것을 기본값으로 둔다.

구조화 데이터는 기계가 콘텐츠를 이해할 확률을 높이는 장치일 뿐, 검색 순위나 AI 답변 인용을 보장하지 않는다. 노출이 늘어도 그것이 클릭이나 내원, 계약으로 이어진다는 보장은 없다.

배포 전 점검 체크리스트

효과를 어떻게 판단할 것인가

노출은 확률의 문제라 단기 변동으로 판단하면 잘못된 결론에 도달한다. 우리는 발행 후 최소 4~6주를 두고 다음 순서로 본다.

파싱 성공 — 리치 결과 테스트와 서치 콘솔 향상 보고서에서 오류 0건인가. 여기서 막히면 나머지는 볼 필요가 없다.
질의 매칭 — 서치 콘솔 검색어 목록에 질문형 질의가 새로 등장하는가. 노출 수보다 질의의 성격이 중요하다.
행동 — 해당 페이지에서 전화·예약 경로로 이동한 비율이 변하는가.

1번이 통과했는데 2번이 움직이지 않는다면 스키마 문제가 아니라 질문 선정 문제다. 환자가 실제로 검색하지 않는 질문을 넣은 것이다. 이때는 원내 전화 응대에서 반복되는 질문 상위 10개를 받아 적어 교체하는 편이, 스키마를 더 손보는 것보다 빠르다.

FAQ 구조화 데이터는 새 콘텐츠를 만드는 일이 아니라, 이미 매일 전화로 답하고 있는 내용을 기계가 읽을 수 있는 형태로 옮겨 적는 일이다. 규제 안에서 할 수 있는 일이 좁아 보이지만, 운영 사실만으로도 환자가 내원 전에 궁금해하는 것의 대부분은 답할 수 있다.

자주 묻는 질문

답변 내용이 병원의 운영 사실이면 넣고, 환자 개인의 상태나 치료 결과에 대한 판단이면 넣지 않습니다. 진료과목이 다루는 일반적 범위, 검사 준비물, 예약·접수 절차, 진료시간, 초진 준비 서류는 안전한 유형입니다. 반면 치료효과 단정, 특정 시술 권유, 증상에 대한 진단, 환자 만족 여부는 의료법 제56조가 금지하는 영역입니다.

네, 제한해야 합니다. 사전심의 대상이 아니라는 것은 게시 전 심의 절차를 거치지 않는다는 의미일 뿐이며, 의료법 제56조의 금지 규정은 자체 홈페이지에도 그대로 적용됩니다. 또한 자율심의기구의 사후 모니터링 대상이므로, 게시 이후에 문제가 확인될 수 있습니다.

보장되지 않습니다. 구조화 데이터는 문서 안에서 어떤 문장이 어떤 질문에 대응하는지 기계가 파악할 확률을 높이는 장치이며, 노출 여부는 질의 성격과 경쟁 문서 등 여러 요인으로 결정됩니다. 노출이 늘어도 클릭이나 내원으로 이어진다는 보장 역시 없습니다.

안 됩니다. 사용자에게 보이지 않는 내용을 마크업하는 것은 구조화 데이터 정책 위반이며 스팸으로 판정될 수 있습니다. 실무적으로도 AI가 URL을 직접 읽는 경로에서는 렌더링된 화면 텍스트가 근거가 되므로, 스키마에만 있는 답변은 인용되지 않습니다. 아코디언으로 접어두는 것은 클릭해 펼칠 수 있으므로 허용됩니다.

넣지 않습니다. 환자 치료경험담과 시술 전후 비교는 의료법상 금지 대상이며, Review나 AggregateRating 스키마는 그 내용을 구조화된 형태로 노출시키는 결과가 됩니다. 다른 업종 SEO 가이드에서 자주 권장되는 항목이라 그대로 따라 하기 쉬우니, 의료기관 사이트에서는 두 타입을 사용하지 않는 것을 기본값으로 두는 편이 안전합니다.

페이지마다 고유한 정보가 있으면 불리하지 않고, 지역명만 치환한 페이지라면 얇은 중복 페이지로 색인에서 제외될 수 있습니다. 공통 템플릿을 재사용하더라도 페이지별 데이터, 자기 자신을 가리키는 canonical, 그 데이터에서 생성된 고유 JSON-LD 세 가지는 반드시 분리해야 합니다. 판단 기준은 템플릿을 걷어냈을 때 그 페이지에만 있는 정보가 남는지 여부입니다.