당면 과제
팀에서 매물 제품을 출시합니다. 3주 동안은 잘 작동합니다. 그러다 Zillow가 DOM을 변경하고, Rightmove가 봇 검사를 강화하면 단 하루 주말 만에 6개 소스 중 4개에서 스크래퍼가 작동을 멈춥니다.
부동산 데이터 집계에는 가격 모니터링이나 SERP 추적과는 다른 특수한 문제가 있습니다. 깔끔한 API 하나에서 구조화된 데이터를 가져오는 것이 아닙니다. 서로 다른 안티 봇 스택, 레이아웃, 지리적 위치, 업데이트 주기를 사용하는 포털의 매물 정보를 연결해야 합니다. 미국의 Zillow, MLS 기반 데이터를 위한 Redfin, 영국의 Rightmove, 호주의 realestate.com.au, 독일의 Immobilienscout24 등 모든 포털이 각각 하나의 엔지니어링 프로젝트입니다.
Scrapfly의 2026년 연구에 따르면 주요 부동산 포털은 연결 수준의 서명을 검사하여 브라우저급 핸드셰이크와 일치하지 않는 클라이언트를 거부합니다. 해당 Rightmove 가이드는 몇 달마다 구조가 바뀌는 JavaScript 변수에 포함된 JSON을 다룹니다. Redfin은 부동산 데이터를 수십 개의 DOM 노드에 분산시키므로, 레이아웃이 한 번만 바뀌어도 필드의 절반이 누락될 수 있습니다. 또한 지역 포털은 방문자의 국가에 따라 다른 콘텐츠를 제공하므로, 미국 기반 스크래퍼는 realestate.com.au에서 유용한 정보를 얻을 수 없습니다.
결과적으로 매물 데이터의 최신성이 조용히 저하됩니다. 자산의 3분의 1이 48시간 내에 오래된 데이터가 됩니다. 사용자는 지난주 가격을 보게 됩니다. 영업 팀에 불만이 접수되고, 포털 레이아웃 변경이 주로 주말에 발생하기 때문에 월요일에는 지원 티켓이 급증합니다.
접근 방식
대규모 매물 집계는 스크래핑 문제가 아닙니다. 스크래핑으로 위장한 안정성 문제입니다. 스크래퍼가 계속 중단되는 이유에서는 일반적인 사례를 다룹니다. 부동산은 이 문제의 모든 부분을 증폭시킵니다.
이 문제를 잘 처리하는 플랫폼은 네 가지 요소가 함께 작동해야 합니다. 첫째, 실제 브라우저와 일치하는 request 서명(단순한 브라우저 형태의 User-Agent 문자열이 아닌, Zillow 및 Rightmove가 봇과 사람을 구분하는 데 사용하는 실제 통신 수준의 세부 정보)입니다. 둘째, 독일 집계 서비스가 Immobilienscout24에 미국 데이터센터 트래픽을 보내면서 유용한 response를 기대할 수는 없으므로 모든 타겟 시장의 위치가 정확한 주거용 IP가 필요합니다. 셋째, Zillow에서 작동하는 전략이 realestate.com.au에서는 실패하므로 호스트별 proxy 라우팅이 필요합니다. 넷째, 모든 것을 클라이언트 측으로 푸시하는 포털을 위한 폴백으로서의 브라우저 렌더링입니다.
FourA의 proxy 제품을 통한 Rightmove에 대한 샘플 request는 다음과 같습니다.
curl -X POST https://api.foura.ai/api/proxy/ \
-H "x-api-key: YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{
"maxTries": 5,
"timeout_ms": 45000,
"request": {
"method": "GET",
"url": "https://www.rightmove.co.uk/properties/123456",
"unblocker": true,
"followRedirects": 5,
"validate": {
"status": {"accept": [200]},
"data": {"fail": ["blocked", "access denied"]}
}
}
}'
unblocker 플래그는 일치하는 통신 수준 서명과 함께 전체 브라우저 header 세트를 삽입합니다. maxTries: 5은 성공할 때까지 최대 5개의 IP를 교체하도록 proxy 관리자에게 지시합니다. 검증 규칙은 매물 데이터 대신 소프트 차단 페이지를 반환하는 200 response와 같은 조용한 차단을 잡아냅니다. 따라서 성공률은 HTTP 상태가 주장하는 것이 아니라 실제로 작동한 결과를 반영합니다.
JavaScript를 통해 모든 것을 제공하는 포털(가장 대표적인 예가 Redfin)은 실제 브라우저 렌더링이 필요합니다. 당사의 브라우저 제품은 첫 번째 연결에서 차단되는 가벼운 에뮬레이터가 아닌 전체 브라우저 인스턴스를 통해 이를 처리합니다. 2026년에 봇 탐지는 행동 기반으로 진화했으며, 실제 브라우저가 아닌 것은 점점 더 쉽게 노출됩니다.
결과
부동산 집계 서비스가 맞춤형 스크래핑 스택에서 API 우선 접근 방식으로 전환하면 어떤 일이 발생할까요? 실제 운영에서 나타나는 패턴은 다음과 같습니다(업계 벤치마크를 기반으로 한 예시 시나리오).
- 매물 최신성이 활성 시장의 경우 "48시간 내 업데이트"에서 "2시간 내 업데이트"로 개선됩니다.
- 스크래퍼 유지보수에 소요되는 엔지니어링 시간이 70% 감소합니다. 전담 팀 대신 한 명의 엔지니어가 교대로 담당합니다.
- 인프라의 비례적인 증가 없이 포털 커버리지가 6개 사이트에서 20개 이상으로 확장됩니다.
- 검증 규칙이 소프트 차단을 포착하면 보호된 포털에서 숨겨진 차단율이 3% 미만으로 떨어집니다.
당사 플랫폼을 사용하는 팀에서 볼 수 있는 한 가지 패턴은 안정성 계층이 공유되면 새로운 시장을 추가하는 것이 스프린트가 아닌 구성 변경이 된다는 것입니다. "왜 또 중단되었을까"에서 "다음에는 어떤 포털을 추가해야 할까"로 질문의 초점이 바뀝니다.
솔직한 한계점: 로그인 세션이 필요한 부동산 포털(일부 MLS 시스템, 특정 에이전트 전용 보기)은 request 인프라 위에 계정 관리가 필요합니다. 이는 당사가 해결하지 않는 별개의 문제이며, 해결 방법을 설명하지 않은 채 이를 해결할 수 있다고 말하는 사람을 신뢰해서는 안 됩니다.
핵심 요약
부동산은 오래된 데이터가 단순한 골칫거리가 아닌 몇 안 되는 산업 중 하나입니다. 오래된 데이터는 제품의 실패를 의미합니다. 패션 사이트에서 일주일 지난 가격은 가벼운 실수에 불과합니다. 하지만 인기 있는 시장에서 일주일 지난 매물은 사용자가 화요일에 이미 팔린 집에 대해 방금 문의했다는 것을 의미합니다.
하지만 이 분야에서 성공하는 팀은 소스가 가장 많은 팀이 아닙니다. 새로운 포털을 추가할 때마다 동일한 proxy와 안티 봇 시스템을 반복해서 재구축하지 않는 팀입니다. 해당 계층이 공유되면 데이터 품질, 최신성 SLA, 포털 간 중복 제거, 가격 동향 분석 등 흥미로운 작업이 시작됩니다. 그것이 바로 제품입니다. 그 바탕에 있는 모든 것은 그저 잘 작동해야 합니다.