AI가 '이 병원 평 좋아요'라고 답하게 만드는 법 — AggregateRating 스키마의 합법적 활용
환자가 AI에게 '평 좋은 병원'을 물을 때, AI는 병원의 실력이 아니라 '읽을 수 있는 평판 데이터'를 근거로 답한다. 실제 존재하는 리뷰를 AggregateRating 구조화 데이터로 정리해, 의료법과 검색엔진 정책을 지키면서 AI 인용 후보가 되는 실무 전 과정을 다룬다.
환자가 스마트폰에 대고 '○○동 임플란트 평 좋은 치과'라고 물으면, AI는 몇 초 만에 병원 두세 곳을 이름과 함께 읊어 준다. 그 목록에 늘 옆 건물 병원만 오르고 우리 병원은 빠져 있다면, 실력이 부족해서가 아니라 AI가 우리 병원의 평판을 '읽을 수 있는 형태'로 갖고 있지 못한 경우가 대부분이다. 이 글은 실제로 존재하는 좋은 리뷰를, 법이 허용하는 범위 안에서 AI가 근거로 인용할 수 있게 정리하는 방법을 다룬다.

많은 원장님이 '우리 병원은 후기도 좋고 별점도 높은데 왜 AI가 몰라줄까'라고 답답해한다. 핵심은 여기에 있다. 사람은 리뷰 화면을 눈으로 읽고 '평이 좋구나' 하고 이해하지만, AI는 화면의 별 그림을 감정으로 느끼지 못한다. AI에게 평판이란 오직 기계가 해석 가능한 데이터로 존재할 때만 '근거'가 된다. 사람에게 보여주는 리뷰와 AI에게 읽히는 리뷰는 전혀 다른 언어인 셈이다. 그 번역기 역할을 하는 것이 바로 이번 주제인 구조화 데이터, 그중에서도 평점을 요약해 주는 AggregateRating이다.
'평 좋은 병원'을 물었을 때, AI는 무엇을 근거로 답하나
먼저 짚어야 할 개념이 AEO다. AEO(Answer Engine Optimization, 답변 엔진 최적화)란 챗GPT·Perplexity·네이버 AI·구글 AI 요약처럼 '검색 결과 목록'이 아니라 '완성된 답변 한 문단'을 내놓는 엔진에게, 우리 병원이 그 답변의 재료로 선택되도록 콘텐츠와 데이터를 정리하는 작업을 말한다. 과거 SEO가 '검색 1페이지에 뜨는 법'이었다면, AEO는 'AI가 직접 우리 병원 이름을 말하게 하는 법'이다.
AI가 '평이 좋은 병원'이라는 판단을 내릴 때 참고하는 신호는 크게 세 갈래다. 첫째는 여러 리뷰 텍스트에 반복적으로 나타나는 긍정적 표현의 밀도, 둘째는 각 플랫폼에 쌓인 평점과 리뷰 개수, 셋째는 그 병원이 어떤 곳인지 명확히 선언된 공식 정보다. 문제는 이 신호들이 대개 흩어져 있고, 별점은 이미지나 위젯 안에 갇혀 있어 AI가 숫자로 집어내기 어렵다는 점이다.
그래서 필요한 것이 '정리된 요약'이다. 사람에게 '우리 병원 평점은 5점 만점에 4.8이고 후기는 320건입니다'라고 말로 알려주듯, AI에게도 그 사실을 기계가 읽는 문법으로 한 번 더 적어 주는 것. 이 역할을 표준 규격으로 해내는 것이 AggregateRating이다.
AggregateRating이란 — AI에게 건네는 '평점 요약표'

AggregateRating은 schema.org라는 국제 표준의 한 항목이다. schema.org는 구글·마이크로소프트 등이 함께 만든 '웹페이지 내용을 기계에게 설명하는 공통 사전'으로, 여기서 나온 데이터를 흔히 구조화 데이터(스키마)라고 부른다. 페이지 안에 사람 눈에는 안 보이지만 기계는 읽는 작은 메모를 심어 두는 것이라 이해하면 쉽다.
AggregateRating은 그중 '여러 개의 개별 평가를 하나로 합산한 평균 평점'을 담는 항목이다. 핵심 값은 세 가지다.
- ratingValue: 평균 평점(예: 4.8)
- reviewCount 또는 ratingCount: 그 평균을 만든 후기·평가의 개수(예: 320)
- bestRating: 만점 기준(예: 5)
이 요약표는 보통 JSON-LD라는 형식으로 페이지에 삽입된다. JSON-LD는 사람이 보는 본문과 분리된 채, 화면 뒤에서 '이 병원의 이름은 무엇이고, 평균 평점은 얼마이며, 후기는 몇 건'이라는 사실을 기계에게 또박또박 불러 주는 카드라고 보면 된다. 눈에 보이는 리뷰 화면은 그대로 두고, 그 아래에 AI용 자막을 하나 더 깔아 주는 셈이다.
여기서 반드시 기억할 원칙 하나. AggregateRating은 페이지에 실제로 존재하는, 검증 가능한 평점만 담아야 한다. 화면에는 후기가 하나도 없는데 데이터에만 '평점 4.9'를 적어 넣는 것은 구글 정책 위반이자 조작이며, 적발 시 병원 페이지 전체가 검색·AI 노출에서 불이익을 받는다. 구조화 데이터는 없는 평판을 지어내는 도구가 아니라, 이미 있는 평판을 기계가 읽게 번역하는 도구다.
지금 방치하면 잃는 것, 지금 정리하면 얻는 것
손실 프레임부터 냉정하게 보자. 환자의 병원 탐색은 점점 '검색해서 여러 곳을 비교'하는 방식에서 'AI에게 물어보고 추천받은 한두 곳만 확인'하는 방식으로 이동하고 있다. 이 변화의 무서운 점은, AI가 처음부터 우리 병원을 답변에 넣지 않으면 환자는 우리 병원의 존재 자체를 인지할 기회조차 잃는다는 것이다. 예전에는 검색 2페이지에라도 있었지만, AI 답변에는 '2페이지'가 없다. 언급되거나, 안 되거나 둘 중 하나다.
실력 좋고 후기 좋은 병원일수록 이 손실이 더 뼈아프다. 애써 쌓은 훌륭한 평판이 '기계가 못 읽는 형태'로만 존재하는 탓에, 평판이 약한 옆 병원이 데이터 정리를 먼저 해 두었다는 이유만으로 AI 답변을 가져가는 역전이 실제로 일어난다. 좋은 진료가 좋은 노출로 이어지지 않는 구조적 손해다.
기회 프레임은 그 반대다. 아직 대다수 병원이 리뷰를 구조화 데이터로 정리하지 않는다. 즉 지금은 먼저 정리하는 병원이 유리한 초기 시장이다. 후기가 아주 많지 않더라도, 정직하고 명확하게 정리된 평점 데이터를 가진 병원은 AI가 '근거를 댈 수 있는 병원'으로 우선 고려한다. AI는 확신할 수 있는 근거가 있는 대상을 답변에 넣기를 선호하기 때문이다.
별점이 검색결과에 안 뜨는 진짜 이유 — 자가 리뷰의 함정
여기서 가장 많은 원장님이 오해하는 지점을 짚겠다. '스키마만 넣으면 구글 검색결과에 우리 별점이 노란 별로 뜨겠지'라고 기대하는 경우가 많은데, 병원 같은 사업자 페이지에서는 대체로 그렇지 않다.
구글은 몇 해 전부터 사업자가 자기 웹사이트에서 스스로 수집·게시한 리뷰(자가 리뷰, self-serving review)에는 검색결과의 별점 리치 스니펫(노란 별 표시)을 원칙적으로 부여하지 않는다. 병원이 자기 홈페이지에 '우리 평점 4.9'라고 스키마를 넣는다고 해서 구글 검색에 별이 그려지지는 않는다는 뜻이다. 이 사실을 모르고 '별이 안 뜨니 실패했다'고 판단해 작업을 접는 병원이 적지 않다.
그러나 목표를 정확히 잡으면 이야기가 달라진다. 우리의 목표는 '구글 검색결과에 별 그리기'가 아니라 'AI가 우리 평판을 이해하고 답변의 근거로 삼게 하기'다. 챗GPT나 Perplexity 같은 AI는 페이지의 구조화 데이터를 맥락 신호로 폭넓게 참고하며, 구글의 리치 스니펫 표시 정책과는 판단 기준이 다르다. 즉 별이 눈에 안 보여도, 잘 정리된 데이터는 AI가 병원을 이해하는 데 분명히 기여한다.
흔한 실수를 정리하면 이렇다.
- 화면에 없는 평점을 데이터에만 넣는 조작 — 정책 위반, 페널티 위험
- '별이 안 떠서 소용없다'는 성급한 중단 — 목표를 리치 스니펫으로만 좁힌 오해
- 제3자 플랫폼의 평점을 출처 표기 없이 우리 것처럼 옮겨 적기 — 신뢰·저작권 문제
- 후기 원문 없이 숫자만 심기 — AI가 검증할 근거가 없어 오히려 신뢰도 하락
의료법이라는 선 — 어디까지가 합법인가

이 주제에서 가장 중요하고, 가장 자주 간과되는 부분이 국내 의료법이다. 우리나라 의료법은 의료광고에서 치료경험담(치료 효과를 암시하는 환자 후기)의 활용과, 객관적 근거 없는 비교·과장 광고를 엄격히 제한한다. '이 시술 받고 완전히 나았어요' 같은 효과 서술형 후기를 병원이 광고 목적으로 전면에 내세우는 것은 위험하다는 뜻이다. 리뷰를 다룰 때는 이 선을 먼저 그어야 한다.
그렇다면 AggregateRating은 어떻게 합법 범위에서 쓰는가. 핵심은 '치료 효과 주장'이 아니라 '서비스 경험에 대한 정직한 집계 사실'로 다루는 것이다. 아래 원칙을 지키면 위험을 크게 낮출 수 있다.
- 효과가 아니라 경험을 담는다. '완치·최고 효과' 같은 치료 결과 표현은 데이터에서도 배제하고, 친절·대기시간·설명 만족도 등 서비스 경험 중심의 평점만 다룬다.
- 실제·검증 가능한 평점만 쓴다. 숫자를 부풀리거나 만들어 내지 않는다. 근거가 되는 후기가 페이지나 연결된 출처에 실제로 존재해야 한다.
- 출처를 투명하게 밝힌다. 제3자 플랫폼 집계라면 어느 플랫폼의 평가인지 드러내고, 자체 설문이라면 그 성격을 명시한다.
- 과장·비교를 피한다. '지역 1위' 같은 순위 단정은 객관적 근거가 없으면 쓰지 않는다.
중요한 점은, 의료광고 규정은 지역·시기·매체에 따라 해석이 달라질 수 있고, 사전심의 대상이 되는 경우도 있다는 것이다. 실제 문구와 게시 방식은 반드시 의료광고 사전심의·법률 자문 등 정식 절차로 확인하기를 권한다. 이 칼럼은 검색·마케팅 관점의 원칙을 안내할 뿐, 개별 사안의 적법성을 보증하지 않는다.
실전 5단계 — 리뷰를 AI가 읽는 데이터로 바꾸기

이제 원장님이 오늘 바로 담당자에게 지시할 수 있는 실행 순서다.
- 평판 자산을 한자리에 모은다. 네이버 플레이스, 구글 비즈니스 프로필, 자체 설문 등 병원이 실제로 보유한 평점과 후기 개수를 채널별로 정리한다. 이때 출처와 수집 시점을 함께 기록한다.
- 어떤 평점을 페이지에 대표로 노출할지 정한다. 정직하게 대표할 수 있는 채널을 고르고, 효과 서술형 후기가 아니라 서비스 경험 중심 후기를 선별한다.
- 화면과 데이터를 일치시킨다. 사람 눈에 보이는 리뷰 영역(평균 평점·후기 수·후기 원문 일부)을 페이지에 먼저 만든다. 데이터는 이 '보이는 사실'을 그대로 옮긴 것이어야 한다.
- JSON-LD 형태로 AggregateRating을 삽입한다. 병원을 나타내는 항목(MedicalOrganization 등)에 ratingValue·reviewCount·bestRating을 붙여 심는다. 이 작업은 홈페이지 제작사나 마케팅 대행사에 '이 값을 스키마로 넣어 달라'고 지시하면 된다.
- 공식 정보와 연결한다. 병원명·주소·전화번호(NAP)와 진료과목 같은 기본 정보 스키마가 함께 있어야 AI가 '이 평점이 어느 병원 것인지' 확신한다. 평점만 떠 있으면 근거로서 힘이 약하다.
비유하자면, 화면의 리뷰는 손님에게 보여주는 메뉴판이고 JSON-LD는 주방과 배달앱이 함께 읽는 표준 주문서다. 둘의 내용이 어긋나면 신뢰가 깨진다. 항상 '보이는 것 = 데이터'를 원칙으로 삼아야 한다.
넣고 끝이 아니다 — 검증과 운영
스키마는 한 번 심는다고 끝나는 작업이 아니다. 심은 뒤에는 기계가 제대로 읽는지 확인해야 하고, 이후에도 관리해야 한다.
먼저 검증. 구글의 리치 결과 테스트나 스키마 검사 도구에 페이지 주소를 넣으면, 우리가 심은 데이터가 문법 오류 없이 인식되는지 바로 확인할 수 있다. 값이 비어 있거나 형식이 틀리면 AI가 그 정보를 통째로 무시하기 때문에, '심었다'가 아니라 '기계가 읽는다'까지 확인해야 진짜 완료다.
다음은 운영. 평점과 후기 개수는 계속 변한다. 6개월 전 '후기 120건'이 지금 '300건'이 되었는데 데이터는 그대로라면, 오래된 숫자가 오히려 병원을 실제보다 작아 보이게 만든다. 주기적으로(예: 분기마다) 화면과 데이터를 함께 갱신하는 루틴을 정해 두는 것이 좋다. 흔한 실수는 '한 번 넣고 방치'와 '리뷰 화면은 업데이트했는데 데이터는 안 고쳐 둘이 어긋나는 것' 두 가지다.
마지막으로, 평판 데이터의 힘은 결국 진짜 후기의 양과 질에서 나온다. 정직하게 진료 경험을 남겨 주는 환자가 늘도록 자연스럽게 안내하고(강요·대가 제공은 금지), 남겨진 후기에 성실히 응대하는 운영이 뒷받침될 때, 스키마는 비로소 AI가 믿고 인용하는 근거가 된다.
오늘부터, 어떤 순서로 시작할까
정리하면 우선순위는 명확하다. 첫째, 우리 병원이 지금 어떤 채널에 어떤 평점·후기를 실제로 보유했는지 한 장으로 파악한다. 둘째, 그 사실을 화면에 정직하게 노출하고 데이터(AggregateRating)를 화면과 일치시킨다. 셋째, 심은 데이터가 기계에 제대로 읽히는지 검증하고, 갱신 주기를 정해 관리한다. 이 셋을 하는 동안 의료법 경계는 반드시 사전심의·자문으로 확인한다.
실행 체크리스트로 요약한다.
- 보유한 평점·후기를 채널·출처·시점별로 정리했는가
- 화면에 보이는 리뷰와 심은 데이터의 숫자가 일치하는가
- 치료 효과 서술이 아니라 서비스 경험 중심으로 다뤘는가
- 평점 데이터가 병원 공식 정보(이름·주소·진료과)와 연결돼 있는가
- 검사 도구로 기계 인식을 확인하고, 갱신 주기를 정했는가
- 실제 게시 문구를 의료광고 사전심의·법률 자문으로 확인했는가
좋은 평판을 가진 병원이, 그 평판을 기계가 못 읽는다는 이유로 AI 답변에서 밀리는 일은 이제 흔한 손해가 됐다. 반대로 말하면, 정직하게 정리만 해도 앞서갈 수 있는 시기라는 뜻이다.
우리 병원이 지금 AI에게 어떻게 읽히고 있는지, 평점 데이터가 제대로 인식되는 형태인지 궁금하다면 현재 상태를 점검하는 것에서 시작하길 권한다. AI메디랩은 병원 홈페이지가 AI 검색에 어떻게 노출되는지 진단하는 무료 점검을 제공한다. 오늘 정리한 여섯 개 체크리스트를 기준으로, 우리 병원이 어느 항목에서 새고 있는지부터 확인해 보시길 바란다.
자주 묻는 질문
AggregateRating 스키마를 넣으면 구글 검색결과에 별점(노란 별)이 뜨나요?
병원 같은 사업자가 자기 홈페이지에서 스스로 수집한 리뷰에는 구글이 원칙적으로 별점 리치 스니펫을 부여하지 않습니다. 따라서 검색결과에 별이 안 뜰 수 있습니다. 다만 우리의 목표는 별 표시가 아니라 AI가 평판을 이해하고 답변 근거로 삼게 하는 것이며, 이 관점에서는 잘 정리된 데이터가 분명히 기여합니다. 별이 안 보여도 무의미한 작업이 아닙니다.
후기가 아직 많지 않은데 평점 스키마를 넣어도 될까요?
실제로 존재하는 평점과 후기 개수라면 적은 수라도 넣을 수 있습니다. 중요한 것은 숫자를 부풀리거나 없는 후기를 지어내지 않는 정직함입니다. 오히려 대다수 병원이 아직 데이터를 정리하지 않은 지금, 적은 후기라도 명확히 구조화해 두면 AI가 근거를 댈 수 있는 병원으로 먼저 고려할 수 있습니다. 이후 후기가 늘면 값을 갱신하면 됩니다.
환자 후기를 홈페이지에 올리는 것 자체가 의료법 위반 아닌가요?
의료법은 치료 효과를 암시하는 치료경험담을 광고 목적으로 활용하는 것을 엄격히 제한합니다. 따라서 '완치·최고 효과' 같은 효과 서술형 후기를 전면에 내세우는 것은 위험합니다. 반면 친절·설명·대기시간 등 서비스 경험 중심의 정직한 평가는 상대적으로 여지가 있으나, 지역과 매체에 따라 해석이 달라지고 사전심의 대상이 될 수 있습니다. 실제 게시 전 반드시 의료광고 사전심의나 법률 자문으로 확인하시길 권합니다.
네이버·구글에 쌓인 평점을 우리 홈페이지 스키마로 그대로 옮겨 적어도 되나요?
제3자 플랫폼의 평점을 출처 표기 없이 우리 것처럼 옮기는 것은 신뢰성과 저작권 측면에서 문제가 될 수 있습니다. 활용한다면 어느 플랫폼의 집계인지 투명하게 밝히고, 화면에 보이는 내용과 데이터가 일치하도록 해야 합니다. 가장 안전한 방식은 각 플랫폼은 그 플랫폼대로 관리하고, 홈페이지에는 정직하게 대표 가능한 평점만 근거와 함께 노출하는 것입니다.
이 작업은 원장이 직접 해야 하나요, 아니면 대행사에 맡기나요?
JSON-LD 삽입 같은 기술 작업은 홈페이지 제작사나 마케팅 대행사에 '이 평점 값을 AggregateRating 스키마로 넣어 달라'고 지시하면 됩니다. 다만 원장이 판단해야 할 것은 어떤 평점을 정직하게 대표로 쓸지, 의료법 경계를 어떻게 지킬지입니다. 즉 실행은 위임하되, 정직성과 적법성의 기준은 원장이 잡아야 합니다.
스키마를 한 번 넣으면 계속 유지되나요?
아닙니다. 평점과 후기 개수는 계속 변하므로 데이터를 방치하면 오래된 숫자가 병원을 실제보다 작아 보이게 만듭니다. 또 화면의 리뷰만 업데이트하고 데이터를 안 고쳐 둘이 어긋나면 신뢰가 깨집니다. 분기마다 화면과 데이터를 함께 갱신하고, 검사 도구로 기계가 제대로 읽는지 확인하는 운영 루틴을 정해 두는 것이 좋습니다.
이 칼럼이 도움이 됐다면 공유해 주세요
원장님·마케팅 담당자에게 링크 한 번이면 됩니다.