여행·로컬 비즈니스의 AEO — 지역 쿼리에서 답변되기

금요일 저녁, 낯선 동네에서 "이 근처 분위기 좋은 카페 추천해줘"라고 묻는 사람은 더 이상 파란 링크 열 개를 받지 않는다. 챗봇은 곧장 가게 두세 곳을 호명하고, 왜 그곳인지까지 한 문단으로 정리해 내놓는다. "제주 2박3일 묵을 호텔 비교해줘"도 마찬가지다. 답은 이미 좁혀져 도착한다. 문제는 그 답에 누가 호명되느냐다. 로컬 AEO(Answer Engine Optimization) 는 이 호명 경쟁에서 내 업체를 답변의 근거로 만드는 일이다.

현장에서 보면 로컬 업체들이 가장 자주 하는 착각이 있다. "우리는 별점도 높고 손님도 많은데 왜 AI가 우리를 안 불러주지?" 별점이 높은 것과 AI가 그 별점을 읽을 수 있게 정리해둔 것은 전혀 다른 문제다. 로컬 AEO의 거의 모든 작업이 이 간극을 메우는 데 들어간다.

"근처·추천·비교"는 서로 다른 질문이다

여행·로컬 쿼리를 한 덩어리로 묶어 보면 답이 안 나온다. 같은 카페를 두고도 묻는 방식에 따라 AI가 들여다보는 데가 완전히 달라지기 때문이다.

추천은 평판 싸움이다. 비교는 속성을 나란히 줄 세울 수 있느냐의 싸움이고, 근처는 위치와 "지금 문 열었나"가 전부다. 흔한 실패는 한 유형만 챙기는 것이다. 리뷰는 잔뜩 쌓아놨는데 영업시간을 구조화해두지 않은 식당은 추천 쿼리엔 걸려도 "지금 문 연" 쿼리에선 통째로 빠진다. 한 페이지가 세 질문 모두에 답할 재료를 갖춰야 한다.

같은 가게라는 걸 먼저 증명하라

나머지 모든 작업은 한 가지 전제 위에 선다. AI가 "이 가게가 그 가게가 맞다"고 확신해야 한다는 것. 확신이 안 서면 별점이든 리뷰든 인용 자체가 일어나지 않는다. 그 확신의 재료가 NAP, 상호(Name)·주소(Address)·전화(Phone)의 일관성이다.

여기서 로컬 업체 대부분이 발목 잡힌다. 이사를 했는데 옛 주소가 어느 디렉터리엔 그대로 남아 있다. 지점명을 "○○점"이라 적은 데가 있고 "○○지점"이라 적은 데가 있다. 예약 플랫폼엔 대표번호, 지도엔 매장 직통번호가 걸려 있다. 사람 눈엔 같은 가게지만, AI는 이걸 두 곳으로 의심하거나 어느 쪽을 믿어야 할지 몰라 그냥 인용을 미룬다. 화려한 콘텐츠를 더 만들 때가 아니라, 자사 사이트·지도 등록정보·예약 플랫폼·지역 디렉터리에 흩어진 NAP를 한 글자까지 같은 형태로 맞출 때다. 이 정리가 끝나기 전에는 그 위에 무엇을 쌓아도 새는 바닥에 물 붓는 격이다.

사실을 기계가 떼어 갈 수 있게 적어라

엔티티가 정리됐다면 다음은 영업시간·위치·가격대·메뉴 같은 사실을 schema.org ↗의 LocalBusiness로 명시하는 단계다.^[1] 식당이면 Restaurant, 숙소면 Hotel, 명소면 TouristAttraction 같은 하위 유형을 쓴다. 좌표(geo), 영업시간(openingHours), 가격대(priceRange), 평점(aggregateRating)을 마크업해두면 AI가 이 값들을 오해 없이 떼어내 답변에 그대로 끼워 넣는다. 비교 쿼리에서 표가 만들어지는 것도 결국 이 속성들이 정리돼 있을 때다.

다만 흔히 빠지는 함정이 있다. 스키마에만 숫자를 채우고 정작 본문엔 안 적는 것. 구글은 구조화 데이터로 표시한 내용이 화면에 실제로 보여야 한다 ↗고 못 박는다.^[2] 영업시간과 가격은 사람이 읽는 본문에도 텍스트로 같이 둬야 한다. 본문을 답변 단위로 끊는 법은 AI 인용 가능한 콘텐츠 구조에서, 스키마를 어디까지 채울지는 AEO를 위한 구조화 데이터 스키마에서 더 깊이 다룬다.

여행 정보는 상해버린다 — 최신성이 신뢰를 가른다

추천·비교 쿼리에서 리뷰는 가장 무거운 신호 축에 든다. 양과 평점뿐 아니라 얼마나 최근 것이냐가 함께 작동한다. 리뷰가 6개월째 멈춰 있는 가게를 AI는 미묘하게 피한다. "이 집 아직 하나?"라는 의심이 깔리기 때문이다.

최신성은 여행 버티컬의 가장 큰 약점이자, 동시에 작은 업체가 비집고 들어갈 틈이다. 영업시간·가격·휴무·시즌 메뉴는 계절마다 바뀌는데, 낡은 정보가 그대로 박제돼 있으면 AI는 그 페이지 전체를 신뢰에서 깎는다. 그래서 변하는 것(운영·요금)과 변하지 않는 것(가는 법, 주변 볼거리)을 처음부터 분리해 관리하는 편이 낫다. 변하는 쪽만 정기적으로 손보고, 고칠 때마다 페이지의 dateModified를 실제 수정 시점으로 반영하면 갱신 부담은 줄고 최신성 신호는 또렷해진다. GEO 연구도 인용·통계·출처를 갖춘 콘텐츠의 가시성이 크게 향상 ↗된다고 보고하는데, 로컬에서 그 "출처"의 정체는 다름 아닌 오늘 기준으로 맞는 운영정보다.^[4] 이용안내성 질문은 FAQ 구조화 데이터 ↗로 묶어, "주차 되나요" "예약 필요한가요" 같은 근처·안내 쿼리에 페이지가 직접 답하게 만든다.^[3]

이 메커니즘은 구글 AI 개요에서도 똑같이 돈다. 그래서 AI 개요 최적화와 한 묶음으로 굴리면 검색과 챗봇 양쪽 노출이 같이 올라간다.

그래서, 무엇부터

거창한 콘텐츠 캠페인이 아니다. 순서가 핵심이다. 먼저 NAP를 모든 채널에서 한 형태로 맞춰 "같은 가게"임을 증명하고, 그 위에 LocalBusiness 스키마로 영업시간·위치·가격을 기계가 읽게 박는다. 그다음 진성 리뷰를 꾸준히 받고 운영정보를 제때 갱신해 페이지를 살아 있는 상태로 유지한다. 쿼리 유형(추천·비교·근처)은 이 토대 위에서 자연히 갈라져 답해진다. 브랜드 인지도가 약한 작은 가게일수록 이 기본기만으로 동네 단위 답변에 이름을 올릴 자리가 생긴다. 큰 이름이 없는 곳에 오히려 더 유리한 게임이다.