수백 개 웹사이트에서 딜러 위치를 자동 추적하는 방법

딜러 위치 정보는 보통 한 곳에 가지런히 모여 있지 않습니다. 어떤 제조사는 정리된 디렉터리를 제공하고, 어떤 곳은 인터랙티브 지도를 쓰며, 또 어떤 곳은 우편번호 검색을 요구하고, 또 다른 곳은 딜러 상세 정보를 개별 프로필 페이지 뒤에 숨겨 둡니다.

수백 개의 웹사이트를 관리해야 하는 규모가 되면, 이 일은 더 이상 “주소 몇 개 긁어오기” 수준이 아닙니다. 진짜 목표는 비즈니스 질문에 답해 주는 믿을 만한 딜러 마스터를 만드는 것입니다.

• 유통은 어디에서 확대되거나 축소되고 있는가?
• 어떤 지역에 커버리지 공백이 있는가?
• 어떤 딜러가 추가, 이전, 삭제되었는가?
• 어떤 매장이 특정 제품군이나 서비스를 취급하는가?
• 새로 발견된 딜러는 어떤 CRM 담당자에게 배정되어야 하는가?
• 경쟁사의 채널 포트폴리오는 시간이 지나며 어떻게 변하는가?

실제 아키텍처는 생각보다 단순합니다. 소스를 찾아내고, 로케이터 패턴을 분류하고, 하나의 표준 스키마로 추출한 뒤, 원본 근거를 보존하고, 중복을 정리하고, 의미 있는 변화를 감지해 알맞은 팀으로 전달하면 됩니다.

목표 시스템

프로덕션용 딜러 추적 워크플로는 6개 계층으로 구성됩니다.

1. 소스 레지스트리: 웹사이트, 로케이터 URL, 국가, 담당자, 패턴, 일정, 마지막 실행 상태를 관리합니다.
2. 발견: 디렉터리 페이지, 사이트맵, API, 검색 폼, 상세 URL을 반복적으로 찾아내는 방식입니다.
3. 추출: 서로 다른 레이아웃에서 같은 의미 필드를 수집하는 브라우저 또는 API 작업입니다.
4. 정규화: 원본 값을 잃지 않으면서 주소, 전화번호, 국가, 카테고리, 상태 라벨을 일관되게 맞춥니다.
5. 엔티티 및 변경 계층: 표준 딜러 식별자, 브랜드 소속, 최초/최종 관찰 시점, 확인된 추가 또는 삭제를 관리합니다.
6. 활성화: 알림, CRM 라우팅, 커버리지 분석, 대시보드, 검토 큐로 연결합니다.

웹사이트에서 바로 CRM으로 넣는 방식부터 시작하면, 대부분 일회성 스크립트와 중복 레코드만 쌓인 불안정한 구조가 됩니다. 수백 개 사이트를 운영 가능하게 만드는 핵심은 레지스트리와 표준 모델입니다.

1단계: 표준 딜러 스키마 정의하기

첫 번째 웹사이트가 아니라, 최종 결과부터 설계하세요. 유용한 최소 스키마는 다음과 같습니다.

그룹	필드
소스 근거	source_domain, source_locator_url, source_dealer_url, source_dealer_id
식별 정보	dealer_name_raw, dealer_name_normalized, brand, manufacturer
주소	street_address, address_locality, address_region, postal_code, address_country
연락처	phone_raw, phone_normalized, website
위치	latitude, longitude
상업적 속성	services, products, categories, authorized_status_raw
관측 정보	observed_at, first_seen, last_seen, record_status
변경 관리	source_hash, change_hash, parser_version

Schema.org의 PostalAddress는 거리 주소, 지역, 주/도, 우편번호, 국가를 정리할 때 유용한 명명 기준을 제공합니다. 정규화된 데이터에는 ISO 2자리 국가 코드를 쓰는 것이 좋고, 원본에서 표기한 국가는 그대로 보관하세요.

원본 값과 정규화 값을 나란히 유지하세요. 사이트에 St. John's, NL처럼 표시되어 있고, 정규화 계층이 이를 표준화된 주/도와 전화 코드로 바꾸더라도 두 버전 모두 검토용으로 남겨 두어야 합니다.

2단계: 소스 레지스트리 구축하기

소스 레지스트리는 운영의 제어판입니다. 각 웹사이트를 한 줄씩 등록하고 다음 항목을 포함하세요.

• 도메인과 브랜드
• 국가 또는 시장
• 추정 로케이터 URL
• 로케이터 패턴 유형
• 선호 크롤링 방식
• 파서 또는 템플릿 버전
• 실행 주기
• 업무 담당자
• 마지막 시도, 성공, 빈 결과, 실패 실행
• 검색 입력값이나 상호작용 요구사항에 대한 메모

모든 로케이터를 완전히 파악할 때까지 기다리지 마세요. 먼저 레지스트리를 만들고, 파일럿이 진행되면서 분류를 개선해 나가면 됩니다.

로케이터 소스를 찾는 방법

다음을 확인하세요.

• “딜러 찾기”, “구매처”, “매장 찾기” 같은 메인 메뉴 및 푸터 링크
• /sitemap.xml 및 사이트맵 인덱스
• 사이트 내부 검색
• site:brand.example dealer locator 같은 검색 엔진 쿼리
• 페이지 소스와 내장 구조화 데이터
• 로케이터 검색 시 발생하는 네트워크 요청
• PDF 또는 유통 문서 같은 대체 자료

Sitemaps protocol은 각 사이트맵 항목에 <loc> URL이 있어야 하며, 사이트맵 인덱스도 지원합니다. 사이트맵은 발견을 빠르게 해 주지만, 모든 동적 로케이터 결과가 포함된다고 보장하지는 않습니다. 또한 <lastmod> 값만으로 딜러 정보가 최신이라고 판단해서는 안 됩니다.

3단계: 확장 전에 각 로케이터를 분류하기

대부분의 딜러 웹사이트는 몇 가지 패턴 유형으로 나뉩니다.

1. 정적 HTML 목록 또는 표 — 가장 쉬운 경우로, 레코드가 페이지 소스에 그대로 들어 있습니다.
2. 페이지네이션이 있는 디렉터리 또는 무한 스크롤 — 레코드가 반복되지만 이동이 필요합니다.
3. 상세 링크가 있는 지도 카드 — 요약 카드에 서브페이지 보강이 필요합니다.
4. 검색 폼 — 사용자가 국가, 주, 도시, 우편번호를 입력해야 합니다.
5. 임베디드 JSON 또는 네트워크 응답 — 페이지는 구조화 데이터를 감싼 시각적 외피에 가깝습니다.
6. 얇은 목록 + 딜러 상세 페이지 — 목록은 식별 정보만 담고, 주소와 서비스는 하위 페이지에 있습니다.
7. PDF 또는 문서형 디렉터리 — 추출과 변경 검토를 문서 전용 경로로 처리해야 합니다.

모든 사이트를 하나의 범용 스크래퍼로 처리하려고 하면 잘 되지 않습니다. 확장 가능한 방식은 패턴 유형마다 재사용 가능한 워크플로 하나를 만들고, 각 소스에는 설정만 적용하는 것입니다.

4단계: Thunderbit로 브라우저 워크플로 파일럿 실행하기

Thunderbit은 대규모 자동화에 투자하기 전에 대표 사이트에서 스키마를 검증하는 데 유용합니다.

파일럿 절차

1. 대표 딜러 디렉터리를 Chrome에서 엽니다.
2. Thunderbit를 실행하고 AI Suggest Fields를 사용합니다.
3. 제안된 필드명을 표준 스키마에 맞게 바꿉니다.
4. 정규화 또는 분류를 위한 Field AI Prompts를 추가합니다. 예를 들어 보이는 국가명을 ISO 코드로 매핑하거나, 서비스를 승인된 카테고리 집합으로 분류합니다.
5. 목록 페이지에는 페이지네이션 또는 무한 스크롤 처리를 켭니다.
6. 개별 딜러 페이지에 전화번호, 웹사이트, 서비스, 소스 ID가 있으면 서브페이지 스크래핑을 사용합니다.
7. 샘플을 Sheets 또는 Excel로 내보낸 뒤, 모든 소스 URL을 검증합니다.

브라우저 모드는 로케이터가 상호작용, 로그인 세션, 또는 단순 요청으로는 재현되지 않는 렌더링을 필요로 할 때 특히 유용합니다. 조직이 접근 권한을 가진 소스와 계정만 사용하세요.

가장 쉬운 사이트가 아니라 대표 사이트를 고르세요

첫 파일럿에는 주요 패턴, 지역, 페이지 기술을 아우르는 20개 사이트를 포함해야 합니다. 파일럿 소스가 모두 단순한 정적 표라면, 첫 지도 기반 로케이터가 등장하는 순간 워크플로는 무너집니다.

각 패턴 유형마다 최소한 다음을 검증하세요.

• 깔끔한 예시 1개
• 규모가 큰 예시 1개
• 동적이거나 불규칙한 예시 1개
• 딜러 상세 페이지가 있는 사이트 1개
• 필드가 적거나 선택적인 사이트 1개

5단계: Batch Extract API로 안정적인 소스 확장하기

반복 가능한 공개 페이지는 수동 브라우저 작업에서 Thunderbit Web Scraper API로 옮기세요.

Batch Extract endpoint은 하나의 JSON Schema로 최대 50개의 URL을 한 번에 처리합니다. 작업 ID를 반환하고, URL을 병렬로 처리하며, URL별 오류를 지원하고, 웹훅 알림을 보낼 수 있으며, none, basic, full 같은 renderMode 옵션을 제공합니다.

배치 설계

• 동일한 의미 출력 스키마를 공유하는 URL끼리 묶습니다.
• 배치 크기는 50개 URL 제한 이하로 유지합니다.
• 데이터를 안정적으로 보여 주는 가장 가벼운 렌더링 모드를 선택합니다.
• 작업 ID와 파서 버전을 실행 기록과 함께 저장합니다.
• 배치 전체 상태만이 아니라 URL별 성공, 빈 결과, 오류 상태를 기록합니다.
• 실패한 URL만 재시도합니다.
• 정규화 전에 원본 추출 값과 소스 링크를 보존합니다.

필드의 비즈니스 의미가 일관되기만 하면, 디자인이 다른 웹사이트도 하나의 스키마로 다룰 수 있습니다. 이것이 정적 디렉터리와 지도 카드 로케이터가 같은 딜러 마스터로 들어가게 만드는 핵심입니다.

6단계: 근거를 지우지 않고 정규화하기

정규화는 레코드를 비교 가능하게 만듭니다. 하지만 감사 불가능하게 만들어서는 안 됩니다.

권장 변환은 다음과 같습니다.

• 공백과 문장부호 정리
• dealer_name_raw를 유지하면서 대소문자 표준화
• 국가 정보가 명시된 전화번호 파싱
• 국가명과 지역명을 승인된 코드로 매핑
• 주소 구성 요소를 일관되게 분리하거나 결합
• URL 정리 및 필요한 경우 추적 파라미터 제거
• 자유 입력 서비스명을 통제된 카테고리로 매핑하되, 원문 표현은 유지

소스의 인증 라벨을 덮어쓰지 마세요. 어떤 제조사는 “Authorized Dealer”, 다른 곳은 “Certified Reseller”라고 부를 수 있습니다. 정확한 문구는 그대로 저장하고, 필요하면 별도 필드에 정규화된 카테고리를 추가하세요.

7단계: 브랜드와 소스를 넘나들며 딜러를 식별하기

딜러 이름만으로는 충분하지 않습니다. “Smith Auto”, “Smith Automotive”, “Smith Auto LLC”는 하나의 사업체일 수도, 인접한 도시의 서로 다른 세 사업체일 수도 있습니다.

다음과 같은 복합 후보 키를 사용하세요.

정규화된 이름 + 우편번호 + 전화번호

또는 좌표가 있으면,

정규화된 이름 + 지리적 거리 + 번지수

그다음 증거를 점수화합니다.

• 완전 일치 또는 거의 일치하는 정규화 이름
• 같은 전화번호
• 같은 우편번호
• 유사한 거리 주소
• 작은 반경 내 좌표
• 일치하는 웹사이트 도메인

레코드를 바로 합치지 말고, 소스에서 표준 엔티티로 연결되는 매핑 테이블을 만드세요. 여러 제조사가 같은 물리적 딜러를 가리키더라도, 브랜드 소속, 서비스, 상태 라벨은 각각 따로 유지할 수 있습니다.

8단계: 의미 있는 변화를 감지하기

모든 실행은 덮어쓰기보다 관측으로 취급해야 합니다.

다음을 저장하세요.

• 현재 실행 시점의 observed_at
• 소스 레코드가 처음 등장한 시점의 first_seen
• 가장 최근 성공 관찰 시점의 last_seen
• 원본 레코드의 소스 해시
• 정규화된 비즈니스 필드의 변경 해시

유용한 변경 유형은 다음과 같습니다.

• 딜러 추가
• 딜러 누락
• 이름, 주소, 전화번호, 웹사이트 변경
• 승인 상태 변경
• 서비스 또는 제품 카테고리 변경
• 위치 이동
• 소스 페이지 실패 또는 레이아웃 변경

누락된 레코드는 먼저 missing_pending_review로 전환해야 합니다. 반복적으로 없거나 수동 검토를 거친 뒤에만 삭제를 확정하세요. 크롤링 실패, 빈 응답, 깨진 셀렉터는 딜러 폐업의 증거가 아닙니다.

9단계: 선택적 검증용으로 Google Places 추가하기

Google Places Place Details는 요청한 필드 마스크와 SKU에 따라, 안정적인 place ID, 표시명, 포맷된 주소, 좌표, 전화번호, 웹사이트, 영업 상태, 이전 장소 정보로 딜러 레코드를 보강하거나 검증할 수 있습니다.

이는 2차 신호로 사용해야 하며, 해당 위치가 제조사 딜러 프로그램에 속하는지에 대한 최종 권위로 삼아서는 안 됩니다. 그 소속 여부의 권위는 여전히 제조사 소스에 있습니다. 검증 제공자와 타임스탬프를 저장하고, 제조사의 상태를 몰래 덮어쓰지 마세요.

10단계: 패턴과 소스별로 추출 품질 측정하기

품질은 실행 단위, 패턴 단위, 도메인 단위로 추적해야 합니다.

실행별 메트릭

• 등록된 소스 URL 수
• 시도한 URL 수
• 성공, 빈 결과, 실패 URL 수
• 추출된 레코드 수
• 추가, 변경, 누락, 변경 없음 레코드 수
• 핵심 필드 완성도
• 중복 후보 수
• 검토 대기 중인 의심 삭제 건수
• 스키마 드리프트 발생 건수

샘플 검증

각 패턴 유형과 주요 실행마다 다음을 수행하세요.

1. 샘플링한 20~50개 레코드를 원본 페이지와 대조합니다.
2. 예상 URL 수와 시도/성공 수를 비교합니다.
3. 도메인별로 누락된 핵심 필드를 확인합니다.
4. 중복 클러스터와 신뢰도 낮은 엔티티 매치를 점검합니다.
5. 좌표 이상치와 국가/우편번호 불일치를 확인합니다.
6. 삭제로 보이는 샘플을 다시 검토합니다.
7. 사용한 추출기 또는 템플릿 버전을 기록합니다.

목표는 단일한 전체 “정확도” 수치를 얻는 것이 아닙니다. 어떤 패턴과 소스가 안정적이고, 어떤 필드가 약하며, 어디에 검토 자원을 써야 하는지를 아는 것입니다.

11단계: 변경 사항을 비즈니스 워크플로로 라우팅하기

변경 유형에 따라 목적지도 달라져야 합니다.

• 새 딜러: CRM 생성, 담당자 배정, 권역 배정을 위해 영업 운영팀으로 전달
• 삭제되거나 폐쇄된 위치: 계정 상태를 바꾸기 전에 검토 큐로 전달
• 주소 또는 전화번호 변경: 보강 정보를 업데이트하고, 진행 중인 기회나 서비스 커버리지를 확인
• 승인 상태 변경: 채널 관리와 고객 대응 팀에 알림
• 커버리지 공백: 권역 기획과 파트너 모집에 반영
• 경쟁사 확장: 유통 인텔리전스와 지역 전략에 반영
• 반복되는 소스 실패: 영업팀이 아니라 데이터 운영 큐로 전달

모든 알림에는 표준 딜러, 브랜드 소속, 변경 유형, 전후 값, 소스 URL, 관찰 시점, 신뢰도 또는 검토 상태가 포함되어야 합니다.

30/60/90일 롤아웃 계획

1~30일: 설계 및 검증

• 표준 스키마와 통제 카테고리를 확정합니다.
• 소스 레지스트리를 구축합니다.
• 대표 웹사이트 20개를 분류합니다.
• 3~5개 로케이터 패턴 유형을 검증합니다.
• 샘플 검증 규칙과 실행 메트릭을 정합니다.
• 소스 근거가 포함된 초기 딜러 마스터를 제공합니다.

31~60일: 확장 및 자동화

• 전체 포트폴리오로 분류를 확장합니다.
• 안정적인 공개 URL 그룹은 배치 추출로 전환합니다.
• 일정 관리, 작업 추적, 재시도 로직, 오류 대시보드를 추가합니다.
• 소스-표준 엔티티 매핑을 도입합니다.
• 검토된 추가/업데이트를 CRM 워크플로와 연결합니다.

61~90일: 변경 인텔리전스 운영화

• 변경 유형별 알림과 검토 큐를 추가합니다.
• 최초 발견, 최종 발견, 삭제 확정 기능을 도입합니다.
• 주소 신뢰도를 높이는 곳에는 선택적으로 Places 검증을 추가합니다.
• 실행 수준 서비스 목표를 정의합니다.
• 패턴 및 템플릿 성능을 매월 검토합니다.
• 각 소스 패밀리와 비즈니스 액션에 담당자를 지정합니다.

자주 발생하는 실패 패턴

웹사이트마다 스크래퍼를 하나씩 만드는 것. 이렇게 하면 유지보수 경로가 수백 개로 늘어납니다. 패턴 패밀리를 분류하고, 재사용 로직과 소스 설정을 분리하세요.

딜러 이름만으로 중복 제거하는 것. 이름은 일관성이 없고 자주 재사용됩니다. 주소, 우편번호, 전화번호, 좌표, 웹사이트 근거를 함께 사용하세요.

원본 값을 덮어쓰는 것. 소스 표현을 잃으면 정규화 오류를 감사할 수 없습니다.

빈 출력을 딜러 0개로 해석하는 것. 빈 출력은 상호작용 실패, 렌더링 변경, 차단된 요청일 수 있습니다. 크롤링 상태와 비즈니스 상태를 분리하세요.

한 번 누락됐다고 삭제를 선언하는 것. 반복 부재나 수동 확인이 필요합니다.

지도 제공자를 딜러 권위로 사용하는 것. 지도 데이터는 장소를 검증할 수는 있어도, 제조사의 승인 관계를 확정할 수는 없습니다.

패턴 품질 측정 전에 확장하는 것. 작은 추출 오류도 수백 개 사이트에 곱해지면 큰 운영 문제가 됩니다.

자주 묻는 질문

서로 다른 수백 개의 딜러 웹사이트에 하나의 스키마를 쓸 수 있나요?

네. 페이지 레이아웃은 달라도 딜러 이름, 주소, 전화번호, 웹사이트, 브랜드, 서비스, 소스 URL, 상태 같은 의미 필드는 대체로 같습니다. 서로 다른 추출 패턴으로 하나의 표준 스키마를 채우면 됩니다.

우편번호 검색이 필요한 로케이터 페이지는 어떻게 자동화하나요?

검색 폼 자체를 하나의 패턴 유형으로 취급하세요. 입력 위치의 커버리지 그리드를 정의하고, 결과 ID 또는 URL을 수집하며, 겹치는 검색 반경은 중복 제거하고, 각 결과를 만든 입력값은 디버깅용으로 보관하세요.

딜러 위치는 얼마나 자주 갱신해야 하나요?

업무 목적과 소스 특성에 맞추세요. 가치가 높은 경쟁사나 서비스 커버리지 소스는 주간 단위가 적절할 수 있고, 느리게 변하는 제조사 디렉터리는 월간 단위로도 충분할 수 있습니다. 실행 실패는 딜러 변경 주기와 별개로 운영 검토를 유발해야 합니다.

삭제된 딜러와 크롤링 실패를 어떻게 구분하나요?

소스 상태와 레코드 존재 여부를 분리해서 추적하세요. 실패하거나 빈 크롤링은 딜러의 last-seen 상태를 업데이트하지 않습니다. 성공한 실행만 부재 증거를 제공할 수 있으며, 삭제 확정에는 반복 확인이나 검토가 필요합니다.

Google Places가 웹사이트의 주소와 영업 상태를 대체해야 하나요?

아닙니다. Places는 보강 또는 검증용으로 사용하고, 타임스탬프와 제공자를 저장하며, 제조사 로케이터는 딜러 프로그램 소속 여부의 권위로 유지하세요.

자동 딜러 추적은 데이터 제품처럼 다룰 때 성공합니다. 즉, 관리되는 소스 레지스트리, 재사용 가능한 패턴 패밀리, 보존된 근거, 신중한 엔티티 해소, 비즈니스 주도 변경 워크플로가 필요합니다. 이런 아키텍처라면 20개 파일럿 사이트에서 수백 개 사이트로 커져도, 화면 개편이 올 때마다 긴급 재구축에 매달리지 않아도 됩니다.

더 알아보기

• 웹사이트를 효율적으로 크롤링하는 방법
• Thunderbit로 데이터 스크래핑 자동화하는 방법
• 효과적인 데이터 스크래핑 기법
• 데이터 스크래핑이란 무엇이며 어떻게 작동하나요?
• 웹사이트 스크래핑 방법: 초보자 가이드