TL;DR: AI 어시스턴트는 그럴듯하지만 틀린 주소를 만들어냅니다. 체인 호텔은 약 6%, 독립 바캉스 렌털은 38% 수준이에요. 해법은 모델을 고치는 게 아닙니다. Schema.org Place 마크업, 검증된 좌표, 정규 외부 식별자로 명확한 ground truth 하나를 공개하고, 해당 비즈니스가 노출되는 모든 플랫폼에서 그 정보를 일관되게 유지하세요.
포르투의 3성급 호텔 주소를 ChatGPT에게 물어보면 도로명, 번지, 우편번호를 아마 답해줄 겁니다. 답은 꽤 자신 있게 들려요. 대형 체인이라면 보통 맞을 거고요. 그런데 두 블록 건너 있는 독립 부티크 호텔이라면, 답이 틀릴 확률이 무시 못 할 수준입니다.
이건 드문 엣지 케이스가 아니에요. 언어 모델이 텍스트를 생성하는 방식에서 나오는 예측 가능한 결과물이고, 특정 위치에서 발견되는 게 비즈니스의 핵심인 사람에겐 직접적인 영향이 있어요.
위치 환각이 작동하는 방식
언어 모델은 주소 데이터베이스를 저장하지 않습니다. 토큰에 대한 통계적 분포를 저장할 뿐이에요. 주소를 물어보면 그 도시의 그 업종에 어울려 보이는 토큰 시퀀스를 예측합니다.
훈련 데이터에 실제 주소가 여러 번, 일관되게, 권위 있는 소스들에서 등장했다면 예측은 올바른 문자열로 수렴합니다. 주소가 드물게 나왔거나, 값이 제각각이거나, 아예 없다면 모델은 보간합니다. 동네에 어울리는 도로, 그 구획에 맞는 번지, 지역 패턴에 맞는 우편번호를 고르는 거죠.
출력은 문법적으로 올바르고, 지리적으로 그럴듯하고, 종종 완전히 틀렸습니다.
샘플 감사: 쿼리 유형별 환각률
2026년 4월에 주요 AI 어시스턴트 3개에 500개의 위치 쿼리를 돌렸습니다. 각 쿼리는 특정 장소의 주소를 물어보는 것이었고, 답변은 MapAtlas GeoEnrich에 등록된 검증 주소와 대조했어요.
아래 표는 최소 하나 이상의 실질적 주소 오류(도로명 오류, 번지 오류, 우편번호 오류, 도시 오류)를 포함한 응답의 비율입니다. 이 샘플에 한정된 방향성 수치예요.
| 쿼리 유형 | ChatGPT | Perplexity | Gemini |
|---|---|---|---|
| 체인 호텔 | 6% | 4% | 7% |
| 독립 부티크 호텔 | 19% | 14% | 22% |
| 베케이션 렌탈 | 38% | 29% | 41% |
| 독립 레스토랑 | 24% | 18% | 27% |
| 랜드마크 또는 관광지 | 9% | 5% | 8% |
출처: MapAtlas 샘플 감사, 2026년 4월, n=500 쿼리.
두 가지 패턴이 눈에 띕니다. 첫째, 웹상의 흔적이 드물고 일관성이 없을수록 환각률이 올라갑니다. 별도 자체 홈페이지 없이 단일 리스팅 플랫폼에만 있는 경우가 많은 베케이션 렌탈이 가장 큰 타격을 입어요. 둘째, Perplexity는 꾸준히 환각이 적은 편인데, 파라메트릭 메모리보다는 실시간 소스에 답변을 더 많이 붙잡아두는 검색 레이어 덕분일 가능성이 큽니다.
구체적 예시
2026년 4월에 돌린 쿼리: 「포르투의 Casa do Vale 게스트하우스 주소가 뭐야?」
주요 어시스턴트의 환각 답변:
Casa do Vale은 Rua de Santa Catarina 142, 4000-442 Porto, Portugal에 있습니다.
숙소 자체 기록과 MapAtlas Geocoding으로 검증된 답변:
Casa do Vale, Rua do Vale 38, 4200-512 Porto, Portugal.
도로도, 우편번호도, 심지어 도시의 반대편이에요. 환각 주소는 실제 게스트하우스에서 3km 떨어진 쇼핑 지구로 손님을 보냅니다. 이 오류는 랜덤이 아니에요. Rua de Santa Catarina는 포르투에서 가장 유명한 상업 거리이고, 포르투 숙소 관련 쿼리의 훈련 데이터에 잔뜩 등장합니다. 모델이 그 도시에 대한 가장 강한 통계적 사전 확률로 떨어진 거죠.
구조화 데이터가 결과를 바꾸는 이유
잘 구성된 Place 또는 LodgingBusiness JSON-LD 블록이 있는 리스팅 페이지는, 모델에게 지어내는 대신 추출할 수 있는 뭔가를 줍니다.
{
"@context": "https://schema.org",
"@type": "LodgingBusiness",
"name": "Casa do Vale",
"address": {
"@type": "PostalAddress",
"streetAddress": "Rua do Vale 38",
"postalCode": "4200-512",
"addressLocality": "Porto",
"addressCountry": "PT"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 41.1621,
"longitude": -8.5937
},
"identifier": {
"@type": "PropertyValue",
"propertyID": "wikidata",
"value": "Q00000000"
}
}
이 블록에서 환각 감소에 중요한 특성은 세 가지입니다.
- 구조화된 필드. 모델이 문장을 파싱할 필요가 없어요. 도로명, 우편번호, 도시, 국가가 별도의 키로 분리되어 있습니다.
- 주소와 일치하는 좌표. 크롤러는 위도와 경도가 우편번호 폴리곤 안에 들어가는지 검증할 수 있어요. 안 맞으면 데이터가 낮은 신뢰도로 플래그됩니다.
- 안정적인 외부 식별자. Wikidata나 Google Place ID는 리스팅을 정규 엔티티에 연결합니다. 모델은 훈련 데이터 빈도에 의존하는 대신 권위 있는 소스 기준으로 주소를 검증할 수 있어요.
이 세 조건이 맞으면 생성이 추출로 바뀌고, 환각 답변 확률이 급격히 떨어집니다.
NAP 일관성 레이어
리스팅 페이지의 schema는 필요조건이지 충분조건은 아니에요. AI 시스템은 주소를 다른 공개 소스, 그러니까 Google Business Profile, OpenStreetMap, Yelp, Tripadvisor, 예약 플랫폼, 오픈 웹과 교차 검증합니다. 값이 서로 안 맞으면 신뢰도가 떨어지고, 모델은 얼버무리거나 생성하는 쪽으로 기울어요.
그래서 플랫폼 간 Name, Address, Phone(NAP) 일관성이 단일 시그널보다 인용 여부를 더 강하게 예측합니다. schema는 완벽하지만 Google Business Profile에 주소가 어긋나 있는 리스팅은 여전히 성과가 안 좋아요. 메커니즘은 AI 검색을 위한 NAP 일관성에서 다룹니다.
환각 위험을 줄이는 현실적인 방법
감사에서 가장 효과가 컸던 건 다음 네 가지입니다.
1. 주소와 함께 검증된 좌표를 게시한다. 글로 쓴 주소는 문자열이지만 좌표는 검증 가능한 사실입니다. MapAtlas Geocoding은 원시 주소를 대규모로 정확한 위경도로 변환하고, 깔끔하게 매칭되지 않는 입력을 플래그해줍니다.
2. 위치 사실을 JSON-LD로 감싼다. Place, LodgingBusiness, Hotel, Restaurant, LocalBusiness 타입은 모두 address, geo, identifier 필드를 받습니다. 빠진 필드가 바로 모델이 추측을 시작하는 지점이에요.
3. 정규 식별자로 연결한다. Wikidata QID나 Google Place ID로 리스팅을 연결하면 AI 시스템에 중복 제거용 기본 키를 주는 셈입니다.
4. 주변 컨텍스트로 보강한다. 환각은 주소 필드에만 국한되지 않아요. 모델은 근처 랜드마크, 교통편, 도보 시간도 지어냅니다. MapAtlas GeoEnrich가 만드는 검증된 근접 데이터는 이런 주장들도 고정시켜줘요. 위치 특화 FAQ가 이 데이터를 드러내기 좋은 표면입니다.
환각 주소의 비즈니스 비용
AI 어시스턴트가 내놓는 틀린 주소는 모델만 민망하게 만드는 게 아닙니다. 실제 손님을 엉뚱한 곳으로 보내요. 하류 영향이 쌓입니다.
- 취소된 예약, 또는 더 나쁜 노쇼.
- 엉뚱한 위치를 언급한 부정적인 리뷰. 그게 다음 세대 모델의 훈련 데이터가 됩니다.
- 리스팅의 향후 인용 신뢰도 저하. 공개 웹에 모순된 시그널이 이미 생겨버렸기 때문이에요.
이 비대칭이 중요합니다. 환각 주소는 리스팅 자체가 잘못이 없어도 리스팅을 망가뜨려요. 해법은 모델을 직접 고치는 게 아니라(그건 불가능합니다), 모델이 굳이 생성할 이유가 없을 만큼 정답을 명확하게 만들어두는 겁니다.
내 노출 정도 확인하기
무료 MapAtlas AEO Checker는 주소 schema, 좌표 존재 여부, NAP 일관성, 외부 식별자를 포함한 29개의 구조화 시그널을 기준으로 리스팅을 평가합니다. 이 항목들을 통과하는 리스팅은 AI 답변에서 잘못 표시될 가능성이 현저히 낮아요. 실패하는 건 모델이 추측할 수밖에 없는 것들입니다.
위치 환각은 어느 한 어시스턴트만의 특이 현상이 아니에요. 같은 비즈니스가 수십 개 소스에서 조금씩 다른 주소로 등장하는 오픈 웹으로 훈련한 결과로 나오는 예측 가능한 현상입니다. 해법은 AI 시스템이 추출할 수 있는 형식으로 하나의 정답을 게시하고, 그 비즈니스가 표현되는 다른 모든 곳에서 그걸 일관되게 유지하는 거예요.
관련 글:
자주 묻는 질문
AI 주소 환각이 뭔가요?
AI 주소 환각은, 대규모 언어 모델이 그럴듯해 보이는 구체적인 도로명 주소, 우편번호, 좌표를 내놓지만 실제 설명 대상인 비즈니스, 랜드마크, 숙소의 위치와 일치하지 않는 상황을 말합니다. 단순한 반올림 오차가 아니라 존재하지 않는 주소, 다른 장소에 속한 주소, 실제 도로명에 엉뚱한 도시를 붙인 주소를 모델이 합성해낸 것입니다. 리스팅 입장에서 이건 꽤 치명적인데, 사용자가 답이 지어낸 것이라는 걸 깨닫기 전에 이미 잘못된 장소로 이동해버릴 수 있기 때문이에요.
AI 어시스턴트는 왜 주소를 환각하나요?
언어 모델은 사실을 조회하는 게 아니라 다음에 올 확률이 가장 높은 토큰을 예측해서 텍스트를 생성합니다. 주소가 웹에서 많이 안 보이거나, 출처마다 값이 다르거나, 크롤링이 막혀 있으면 모델은 통계적으로 그럴듯한 문자열로 빈칸을 채워 넣습니다. 그 도시에 있을 법한 도로명, 그 지역 패턴에 맞는 우편번호, 흔해 보이는 번지 같은 식으로요. 정답의 기준이 되는 구조화된 소스가 없으면, 모델은 기억한 사실과 생성한 내용을 구분할 장치가 없습니다.
실제로 위치 환각은 얼마나 자주 일어나나요?
2026년 4월 MapAtlas 샘플 감사에서 호텔, 베케이션 렌탈, 레스토랑, 랜드마크에 걸친 500개 위치 쿼리를 돌렸을 때, 주소 단위 환각률은 인지도 높은 체인 호텔에서 약 6%, 독립 베케이션 렌탈에서 38%까지 나왔습니다. 일반적인 랜드마크 쿼리는 가장 낮았고, 롱테일 리스팅 쿼리가 가장 나빴어요. 수치는 모델, 언어, 원본 데이터의 신선도에 따라 달라지는 방향성 지표지만 패턴은 일정합니다. 숙소가 노출한 구조화 데이터가 적을수록 모델은 더 많이 지어냅니다.
Schema.org 구조화 데이터가 환각을 줄이나요?
네, 데이터가 검증되어 있고 여러 출처에서 일관적일 때 그렇습니다. 정확한 지오 좌표, 검증된 우편 주소, Wikidata나 Google Place ID 같은 권위 있는 식별자에 대한 상호 참조를 담은 Place 또는 LodgingBusiness JSON-LD 블록을 게시하면, 모델이 추출해서 인용할 수 있는 정답 앵커가 생깁니다. 좌표와 글로 적힌 주소가 어긋나는 등 schema가 불일치하면 오히려 신뢰도를 떨어뜨리는 경향이 있어요.
내 리스팅의 환각 위험을 어떻게 점검하나요?
리스팅 URL을 mapatlas.eu/ai-seo-checker의 무료 MapAtlas AEO Checker에 넣어보세요. 이 체커는 AI 시스템이 위치 사실을 고정할 때 쓰는 29가지 구조화 시그널을 평가합니다. 지오 좌표, Place schema, 플랫폼 간 NAP 일관성, 주변 컨텍스트 필드의 존재 여부 같은 것들이요. 이런 시그널이 빠진 페이지는 모델이 추출 대신 추측해야 하니 환각 위험 점수가 높게 나옵니다.
