Google Maps 매장 데이터 중복 제거: Place ID는 영구적인 사업체 식별자가 아닙니다

Google Maps 매장 데이터의 중복을 제거하려면 매장 이름이 일치하는지 확인하거나 한 엔터티가 항상 하나의 Place ID를 유지한다고 가정하는 것만으로는 부족합니다. Google은 같은 위치에 서로 다른 ID가 있을 수 있고 ID가 시간이 지나며 바뀔 수 있다고 밝히고 있습니다. 장기적으로 관리하는 매장 목록이라면 자체 내부 사업체 식별자를 유지하고 이를 외부 위치 식별자와 매핑해 관리하는 편이 더 안전합니다.

이 문제는 Stack Overflow 질문 https://stackoverflow.com/questions/29751398/geocoding-google-maps-api-return-different-place-id 에서 다뤄졌습니다. Sergey Kuznetsov는 위치 ID 하나로 쿼리했는데 다른 ID가 담긴 응답을 받았습니다. 예전 답변은 문제를 파악하는 데 도움이 되지만, 예전 ID가 영구히 유효하다는 근거는 되지 않습니다. 이 글은 2026년 기준 공식 문서를 바탕으로 합니다.

이 글은 엔터티 식별과 데이터 품질에 초점을 맞춥니다. 대량 매장 스크래핑을 다루는 글이 아니며, EveryInfra에 자동 병합 기능이 있다고 주장하는 글도 아닙니다. 여기서 설명하는 기록 방식은 주로 자체 매장 레코드와 처리 권한이 있는 데이터를 위한 것입니다.

Place ID는 바뀌지만 그래도 보존할 가치가 있는 이유

Google Place ID 문서에 따르면 ID는 위치를 식별하지만, 같은 위치에 ID가 여러 개 있을 수 있고 ID가 바뀔 수도 있습니다. 문서는 저장한 지 12개월이 넘은 ID를 갱신하도록 권장하며, 오래된 ID는 NOT_FOUND를 반환할 수 있다고 설명합니다. EveryInfra의 Google Maps 장소 검색 API는 각 결과에 place_id를 반환합니다. 이 값은 이 글에서 설명하는 대로 비즈니스 키가 아니라 외부 식별자로 보관하십시오.

그렇다고 Place ID가 쓸모없다는 뜻은 아닙니다. 오히려 “커피숍”이나 “중앙점” 같은 일반적인 이름보다 더 나은 외부 객체 식별자입니다. 핵심은 외부 식별자가 모든 비즈니스 의미를 직접 떠안지 않게 하는 것입니다.

예를 들어 체인점이 길모퉁이에서 바로 옆 쇼핑몰로 옮겼다면, 비즈니스 입장에서는 여전히 같은 영업 지점이지만 위치는 바뀐 것입니다. 반대로 브랜드명이 같은 두 지점이라도 사업과 위치가 다르다면 병합해서는 안 됩니다. 중복 제거 규칙을 정하기 전에 테이블이 “브랜드”, “영업 지점”, “물리적 위치” 중 무엇을 기록하는지 정의하십시오.

이 세 계층을 하나의 store_id로 합치면 처음에는 시간이 절약되지만, 시간이 지나면서 매장 수, 리뷰 귀속, 과거 추세에 오류가 생깁니다. 외부 ID 변경이 신규 매장 개점으로 잘못 기록될 수 있고, 이름 정규화 때문에 서로 다른 두 지점이 하나의 행으로 합쳐질 수 있습니다.

사업체 마스터 레코드를 먼저 만들고 외부 식별자 매핑 관리하기

자체 매장 데이터에서는 서드파티 플랫폼에 의존하지 않는 내부 식별자를 비즈니스 객체에 부여하십시오. 외부 플랫폼, 위치 ID, 확인 시각, 유효 기간은 매핑 레코드에 저장합니다. 이름과 주소 같은 설명 필드는 출처별로 허용된 사용 및 저장 범위를 지켜 관리합니다.

대규모 마스터 데이터 시스템을 구축해야 한다는 뜻은 아닙니다. 소규모 팀이라면 목록 두 개로 시작할 수 있습니다. 하나는 관리하는 매장을, 다른 하나는 각 매장의 현재 외부 식별자를 추적합니다. ID가 바뀌면 비즈니스 이력 전체를 다시 만들지 말고 매핑 관계를 업데이트하십시오.

핵심은 변경 사유를 남기는 것입니다. 새 ID가 같은 위치에 속한다고 수동으로 확인한 경우와 공식 매장 이전 링크가 있는 경우는 서로 다릅니다. 두 경우 모두 기존 레코드와 새 레코드를 연결해야 할 수 있지만, 시스템이 이를 단순한 “중복 데이터 삭제” 이벤트로 처리해서는 안 됩니다.

매핑은 되돌릴 수도 있어야 합니다. 두 매장을 잘못 병합했다면 덮어쓴 테이블을 보고 추측하는 대신 그 근거를 추적하고, 소속을 복원하고, 영향을 받은 집계를 다시 계산할 수 있어야 합니다. 이렇게 하면 플랫폼 텍스트를 모두 복사해 두지 않아도 허용된 식별자와 작업 로그를 보존할 수 있습니다.

매장 이름과 거리는 병합 후보일 뿐 최종 병합 기준이 아닙니다

실제 매장과 무관한 가상의 예를 들어 보겠습니다. 한 브랜드가 같은 쇼핑센터 1층과 4층에서 매장 두 곳을 운영하며, 두 매장은 브랜드명과 기본 주소가 같고 좌표도 가깝습니다. 이름이 같고 거리가 가깝다는 이유로 자동 병합하면 영업 지점 수가 실제보다 적게 집계되고 리뷰가 잘못 귀속됩니다.

같은 매장의 영어 이름과 현지어 이름도 또 다른 예입니다. 이름이 다르다고 해서 자동으로 별개의 매장이 되는 것은 아닙니다. 출처의 위치 식별자, 자체 매장 데이터, 기타 검증된 출처를 함께 고려해 판단해야 합니다. 언어 간 이름 매칭은 후보를 찾는 데 도움이 되지만 최종 결론을 좌우해서는 안 됩니다.

결정을 세 단계로 나누는 것을 권장합니다. 증거가 확실하면 매핑을 확정하고, 증거가 상충하면 병합을 명시적으로 거부하고, 이름이나 위치가 비슷하기만 하면 검토 대기열로 보냅니다. 판단 보류 상태는 시스템 오류가 아니라, 의심스러운 매칭이 데이터를 영구적으로 오염시키지 않도록 막는 데 필요한 단계입니다.

후보 규칙은 상황에 맞게 조정해야 합니다. 공항 카운터, 쇼핑몰, 가두점은 공간 관계가 서로 다르며, 모든 도시와 매장 형태에 적용되는 단일 거리 임곗값은 없습니다. 임곗값을 팀의 경험에 근거해 정했다면 Google 권장 사항이라고 하지 말고 내부 규칙으로 문서화하십시오.

ID 만료, 영구 폐업, 매장 이전은 서로 다른 이벤트입니다

NOT_FOUND만으로는 매장이 폐업했다고 증명할 수 없습니다. Google의 ID 문서는 오래된 ID, 데이터베이스 업데이트 같은 경우를 나열하므로, 영업 상태를 확인하기 전에 식별자를 갱신해야 하는지부터 확인하십시오. 쿼리 실패를 월간 폐업 수에 바로 집계해서는 안 됩니다.

Place Details (New)는 businessStatus를 제공하며, 매장 이전에 해당하는 결과는 movedPlace와 movedPlaceId로 새 위치를 가리킨다고 설명합니다. 구현 전에 요청 필드, 권한, 과금 범위를 확인하십시오. 이는 Google의 필드이며 다른 데이터 API에서도 제공된다는 보장은 없습니다.

매장 이전이 일어나면 비즈니스 보고서는 최소한 두 가지를 정리해야 합니다. 영업 지점이 기존 ID를 유지하는지, 그리고 이전 전 주소와 새 주소의 데이터를 어떻게 나눌지입니다. 이전 전후 리뷰를 비교할 때는 어느 위치 객체에서 리뷰를 가져왔는지 명시하고, 기존 위치의 콘텐츠가 모두 자동으로 옮겨졌다고 가정하지 마십시오.

사업체가 그대로라도 상권, 서비스 팀, 운영 형태는 바뀔 수 있습니다. 이전 전후 데이터를 표시 없이 하나의 추세선으로 이으면 이런 변화가 가려집니다. 이벤트 주석을 남겨 두면 독자가 무엇이 바뀌었는지 이해한 뒤 어떤 지표가 여전히 비교 가능한지 판단할 수 있습니다.

Place ID를 보존할 수 있다고 모든 세부 정보를 장기 저장할 수 있는 것은 아닙니다

Places API 정책 문서는 콘텐츠 캐싱, 저장, 출처 표시에 대한 요구 사항을 설명하면서 Place ID 캐싱에 대해서는 별도의 예외를 둡니다. 식별자 저장이 허용된다고 해서 리뷰, 사진, 속성 같은 반환된 세부 정보를 무기한 복사해도 된다는 뜻은 아닙니다.

설계는 필드와 목적에 따라 구분해야 합니다. 자체 매장 마스터 레코드는 내부 운영에서 나오고, 외부 위치 매핑은 ID 저장이 허용되며, 외부 콘텐츠를 표시할 때는 업데이트, 저장, 출처 표시에 관한 각 약관을 따라야 합니다. 조건은 지역과 사용 사례에 따라 다르며, 이 글이 프로젝트별 컴플라이언스 검토를 대신하지는 않습니다.

리뷰 분석이 목적이라면 Google Maps 리뷰 API 가이드에서 리뷰 엔드포인트별 차이를 설명합니다. 수집 지점 선택과 엔터티 중복 제거는 순서대로 이어지지만 서로 다른 단계입니다. 전자는 어떤 데이터를 얻을 수 있는지를, 후자는 데이터를 어디에 귀속할지를 결정합니다.

배포 전에 엣지 케이스로 잘못된 병합 테스트하기

매장 중복 제거 규칙은 명백히 같은 레코드가 제대로 병합되는지만으로 테스트해서는 안 됩니다. 병합해서는 안 되는 사례를 테스트하고 복구 워크플로를 검증하는 편이 더 유용합니다.

자체 샘플이나 합성 샘플을 네 그룹으로 준비하십시오. 같은 브랜드의 서로 다른 지점, 이름이 여러 언어로 된 동일 위치, 폐업이 확인되지 않은 만료 ID, 새 위치 ID가 부여된 매장 이전 사례입니다. 시스템이 별개 지점을 잘못 병합하거나, 언어만으로 엔터티를 분리하거나, 쿼리 실패를 폐업으로 집계하거나, 매장 이전 이벤트를 지우지 않는지 확인합니다.

집계를 표본 점검할 때는 외부 결과 수, 고유 위치 수, 비즈니스 매장 수를 따로 명시하십시오. 이 지표들은 원래 서로 다르므로 보고서에 맞추려고 차이를 억지로 맞춰서는 안 됩니다. 멀티 플랫폼 평판 모니터링 블루프린트에서 잘못 귀속된 데이터가 비즈니스 결정에 미치는 영향을 다룹니다.

매장 데이터 관리의 주된 과제는 지금 어떤 객체를 비교하고 있는지 아는 것입니다. 외부 ID는 유효 기간 및 매핑 근거와 함께 보존하고, 검증되지 않은 매칭은 보류 상태로 두십시오. 이렇게 하면 수집 규모가 커질수록 되돌리기 어려운 잘못된 연결이 아니라 활용할 수 있는 레코드가 늘어납니다.