부동산 데이터 수집이란 포털과 데이터베이스에서 부동산에 대한 구조화된 정보를 추출하는 것을 의미한다: 가격, 상태, 크기, 위치, 중개인, 그리고 이러한 항목들이 각각 변경된 날짜. 기술적인 어려움은 이 데이터를 보유한 포털들이 이를 핵심 자산으로 취급하고 그에 맞춰 방어한다는 점이다.
이 때문에 프록시 선택이 중요해진다. 이 가이드는 무엇을 수집해야 하는지, 주요 포털에서 차단당하지 않고 어떻게 수집하는지, 그리고 실제로 효과가 있는 요청 속도와 갱신 주기를 다룬다.
필요한 설정
공개 목록 페이지의 경우 로테이팅 레지덴셜 프록시가 필요하다. 주요 포털들은 다른 무엇보다 먼저 데이터센터 주소 범위를 분류하는 상용 안티봇 시스템을 운영하기 때문에, 데이터센터 프록시는 속도와 무관하게 첫 요청부터 실패한다.
대부분의 MLS 접근을 포함해 로그인이 필요한 대상의 경우 ISP 프록시가 필요하다. 세션이 유지되어야 하는데, 주소가 바뀌면 세션이 무효화되기 때문이다.
나머지는 모두 요청 속도 관리의 문제이며, 이는 여기서 프록시 선택보다 더 중요하다.
수집해야 할 항목
| 항목 | 중요한 이유 | 갱신 주기 |
|---|---|---|
| 목록 ID 및 URL | 나머지 모든 것이 결합되는 키 | 1회 |
| 가격 및 가격 이력 | 거의 모든 분석에서 핵심 신호 | 매일 |
| 상태 (활성, 보류, 판매완료, 철회) | 시장 유동성의 원천 | 매일 |
| 등록일 및 갱신일 | 시장 체류일수, 핵심 건전성 지표 | 매일 |
| 주소, 좌표, 우편번호 | 지리적 집계 | 1회 |
| 침실, 욕실, 바닥 면적, 부지 크기 | 가격을 비교 가능하게 정규화 | 1회 |
| 부동산 유형 및 건축 연도 | 세분화 | 1회 |
| 중개인 및 중개회사 | 시장 점유율 분석, 개인정보이므로 주의해서 취급 | 1회 |
| 설명 및 특징 | 텍스트 분석, 편의시설 추출 | 매주 |
| 사진 수 및 URL | 목록 품질 신호 | 매주 |
변하는 항목과 변하지 않는 항목을 구분하는 것이 수집량을 관리 가능하게 유지하는 핵심이다. 가격과 상태는 매일 확인해야 한다. 바닥 면적은 변하지 않으므로, 이를 매일 다시 수집하면 대역폭만 불필요하게 늘어난다.
MLS 데이터베이스 모니터링
MLS 데이터는 가장 풍부한 출처이면서 가장 제한적이다. 이는 공개 웹사이트가 아니다: 접근 권한은 계약에 따라 면허를 가진 참여자에게 부여되며, 공인된 경로는 스크래퍼가 아니라 데이터 피드다.
- RESO Web API는 현대적인 표준으로, JSON을 반환하는 구조화된 API이며, 증분 동기화를 지원해 마지막 폴링 이후 변경된 레코드만 요청할 수 있다. MLS 접근 권한이 있다면 이것이 올바른 통합 방식이다.
- RETS는 더 오래된 피드 표준으로, 일부 지역에서 여전히 사용 중이지만 위 표준으로 대체되어가고 있다.
- 전체가 아니라 증분으로 폴링하라. 마지막 타임스탬프 이후의 변경 사항만 요청하라. 대형 MLS의 전체 갱신은 방대하고 불필요하다.
- 라이선스를 준수하라. MLS 계약은 표시, 보관, 재배포를 규율한다. 이를 위반하면 접근 권한 자체가 위태로워지며, 이는 어떤 데이터셋보다 큰 손실이다.
여기서는 프록시가 공개 포털에 비해 덜 중요한데, 인증된 참여자로 활동하기 때문이다. 프록시가 도움이 되는 부분은 안정성이다: ISP 프록시는 통합에 고정된 하나의 주소를 제공하며, 이는 접근 권한이 등록된 주소와 연결되어 있을 때 중요하다.
주요 포털에서 데이터 수집하기
공개 포털은 프록시가 실제로 작동하는 곳이다. 각 포털마다 동작 방식이 다르다.
Zillow
강력한 안티봇 보호와 공격적인 속도 제한이 있다. 검색 결과 페이지는 각 목록을 개별 방문하지 않고도 대부분의 요약 항목을 담고 있어 효율적인 진입점이다.
- 프록시: 로테이팅 레지덴셜, 미국 지역 타겟팅.
- 속도: 보수적으로. 주소당 3~5초에 1회 요청.
- 주의사항: 지도 기반 검색은 HTML이 아닌 내부 엔드포인트를 통해 데이터를 반환하는데, 이는 더 효율적이지만 더 엄격하게 감시된다.
Redfin
Zillow보다 다소 관대하고, 구조가 더 잘 정리되어 있다. 데이터는 종종 HTML 파싱이 필요 없이 내장된 JSON 형태로 제공된다.
- 프록시: 로테이팅 레지덴셜, 미국.
- 속도: 주소당 2~3초에 1회 요청.
- 주의사항: 시장에 따라 커버리지가 다르므로, 목록이 없다고 해서 존재하지 않는다는 증거는 아니다.
Realtor.com
직접적인 MLS 신디케이션이므로 데이터가 시의적절하며, 보호 수준은 중간이다.
- 프록시: 로테이팅 레지덴셜, 미국.
- 속도: 주소당 2~4초에 1회 요청.
Rightmove와 Zoopla
영국의 양대 주요 포털이다. 둘 다 스스로를 방어하며, Rightmove가 더 엄격하다.
- 프록시: 로테이팅 레지덴셜, 영국 지역 타겟팅. 영국 이외의 주소는 다른 결과를 보거나 아예 결과를 보지 못한다.
- 속도: 주소당 3~5초에 1회 요청.
- 주의사항: 두 포털 모두 서로 다른 중개인을 통해 동일한 부동산을 등록하므로, 목록 ID가 아니라 주소를 기준으로 중복 제거해야 한다.
요청 속도, 로테이션, 동시성
수집이 살아남을지 여부를 결정하는 가장 큰 요인은 속도다. 차단당한 대부분의 사람들은 프록시로 탐지된 것이 아니라 서두르는 것으로 탐지된 것이다.
- 주소당 속도: 포털에서는 2~5초에 1회 요청. 필요해 보이는 것보다 느리며, 이 때문에 동시성이 존재한다.
- 속도가 아니라 동시성: 더 빠르게 수집하려면 간격을 줄이기보다 주소를 추가하라. 3초에 1회 요청하는 주소 10개를 동시에 사용하면 전체적으로 초당 약 3회 요청이 되며, 이는 약 1시간 안에 10,000개의 목록을 처리할 수 있다.
- 로테이션: 독립적인 목록 페이지를 탐색할 때는 요청마다 로테이션한다. 커서를 포함한 검색을 페이지네이션할 때는 스티키 세션을 사용하며, 페이지네이션을 마칠 때까지만 유지한다.
- 지터를 추가하라. 정확히 3.0초 간격의 요청은 특징적인 신호가 된다. 2초에서 5초 사이로 변화를 주어라.
- 대상 시장의 시간대 기준으로 비수기 시간에 수집하라. 기본 트래픽이 낮으면 요청이 전체에서 차지하는 비중이 줄어들고, 속도 제한도 대체로 더 느슨해진다.
차단이 시작될 때
- 응답을 확인하라. 429는 속도 제한을 의미하며 속도를 줄이라는 뜻이다. 챌린지 페이지는 속도가 아니라 핑거프린트가 문제라는 뜻이다.
- 먼저 속도를 절반으로 줄여라. 가장 저렴한 해결책이며 대체로 올바른 해결책이다.
- 헤더와 핑거프린트를 확인하라. 다른 내용이 거의 없는 요청에 단순한
User-Agent만 있으면 명백한 봇 신호다. - 차단된 상태로 재시도하지 마라. 지수 백오프를 사용하라. 약한 속도 제한을 계속 두드리면 해당 주소에 대한 영구 차단으로 이어진다.
- 대상을 재고하라. 재시도 비용이 데이터가 제공하는 가치보다 크다면, Web Scraping API가 렌더링과 챌린지를 대신 처리해준다. 단가는 더 높지만 유지보수 부담은 훨씬 낮다.
갱신 주기
- 매일: 신규 목록, 상태 변경, 가격 변경. 거의 모든 분석적 가치가 여기에 있다.
- 매주: 설명, 사진, 중개인 정보. 목록이 게시된 이후에는 거의 변하지 않는다.
- 1회: 주소, 좌표, 크기, 부동산 유형. 구조적 사실들.
이런 방식으로 일정을 나누면 매일 모든 것을 다시 수집하는 것에 비해 대개 대역폭을 절반 이상 절감할 수 있으며, 신호 손실도 없다.
결론
부동산 데이터 수집은 기술적인 문제라기보다는 대부분 규율의 문제다. 포털이 데이터센터 주소를 한눈에 분류하기 때문에 레지덴셜 프록시를 사용하고, 주소당 요청 속도는 느리게 유지하면서 대신 동시성을 추가하며, 각 항목이 실제로 얼마나 자주 변하는지에 따라 갱신 일정을 나누어라.
스크래핑 전반의 메커니즘에 대해서는 웹 스크래핑 프록시를, 상업적 응용에 대해서는 가격 정보 분석을, 법적 근거에 대해서는 프록시 및 스크래핑 합법성을 참고하라. Shifter의 레지덴셜 프록시는 이러한 포털이 요구하는 지역 타겟팅을 지원하며, 요금은 가격 페이지에서 확인할 수 있다.