대규모 부동산 매물 데이터 집계

과제

팀에서 매물 정보 서비스를 출시합니다. 처음 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가 봇과 사람을 구분하는 데 사용하는 실제 네트워크 수준의 세부 정보)가 필요합니다. 둘째, 각 타깃 시장에 맞는 정확한 지역 주거용 IP가 필요합니다. 독일 매물 수집 서비스가 Immobilienscout24에 미국 데이터센터 트래픽을 보내면서 유효한 응답을 기대할 수는 없습니다. 셋째, Zillow에서 작동하는 전략이 realestate.com.au에서는 실패하므로 호스트별 proxy 라우팅이 필요합니다. 넷째, 모든 데이터를 클라이언트 사이드에서 렌더링하는 포털을 위한 폴백 브라우저 렌더링이 필요합니다.

FourA의 Proxy 제품을 통해 Rightmove에 요청을 보내는 예시는 다음과 같습니다.

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 플래그는 일치하는 유선 수준(wire-level) 시그니처와 함께 전체 브라우저 헤더 세트를 주입합니다. maxTries: 5는 프록시 관리자에게 하나가 성공할 때까지 최대 5개의 IP를 순환하도록 지시합니다. 검증 규칙은 매물 데이터 대신 소프트 차단 페이지를 반환하는 200 응답과 같은 조용한 차단(silent blocks)을 감지합니다. 따라서 성공률은 HTTP 상태가 나타내는 값이 아닌 실제 성공 여부를 반영합니다.

모든 데이터를 JavaScript를 통해 렌더링하는 포털(Redfin이 대표적)에는 실제 브라우저 렌더링이 필요합니다. FourA의 Browser 제품은 첫 연결에서 감지되는 경량 에뮬레이터가 아닌, 완전한 브라우저 인스턴스로 이를 처리합니다. 봇 감지는 2026년에 행동 기반으로 발전했으며, 실제 브라우저가 아닌 모든 것은 점점 더 쉽게 감지됩니다.

결과

부동산 애그리게이터가 자체 구축 스크래핑 스택에서 API 우선 접근 방식으로 전환하면 어떤 일이 일어날까요? 실제 운영 전반에서 확인된 패턴은 다음과 같습니다(업계 벤치마크 기반의 예시 시나리오).

매물 최신성: 활성 시장 기준 "48시간 이내 업데이트"에서 "2시간 이내 업데이트"로 개선
스크래퍼 유지보수 엔지니어링 시간: 70% 감소. 전담 팀 대신 1명의 엔지니어가 순환 담당
포털 적용 범위: 인프라의 비례적 증가 없이 6개 사이트에서 20개 이상으로 확장
조용한 차단율: 검증 규칙이 소프트 차단을 감지한 후 보호된 포털에서 3% 미만으로 감소

FourA 플랫폼을 사용하는 팀들에서 나타나는 한 가지 패턴이 있습니다. 안정성 계층이 공유되면 새로운 시장을 추가하는 작업이 스프린트 단위 업무가 아닌 단순 설정 변경이 됩니다. 흥미로운 질문은 "왜 또 오류가 났을까"에서 "다음에는 어떤 포털을 추가해야 할까"로 바뀝니다.

솔직한 한계점도 있습니다. 로그인 세션이 필요한 부동산 포털(일부 MLS 시스템, 특정 공인중개사 전용 뷰)은 요청 인프라 외에도 계정 관리가 필요합니다. 이는 FourA가 해결하지 않는 별도의 문제이며, 구체적인 방법 설명 없이 이를 해결한다고 주장하는 곳은 신뢰하지 않는 것이 좋습니다.

핵심 요점

부동산은 오래된 데이터가 단순한 불편함에 그치지 않는 몇 안 되는 산업 중 하나입니다. 이는 제품의 실패입니다. 패션 사이트에서 일주일 전 가격이 표시되는 것은 가벼운 당혹감에 불과하지만, 과열된 시장에서 일주일 전 매물이 표시되는 것은 사용자가 화요일에 이미 팔린 매물에 대해 문의하게 됨을 의미합니다.

하지만 이 분야에서 승리하는 팀은 가장 많은 소스를 보유한 팀이 아닙니다. 새로운 포털마다 동일한 프록시 및 요청 배관 작업을 반복해서 재구축하는 일을 멈춘 팀입니다. 해당 계층이 공유되면 데이터 품질, 최신성 SLA, 크로스 포털 중복 제거, 가격 동향 분석 등 가치 있는 작업이 시작됩니다. 그것이 바로 제품입니다. 그 아래의 모든 인프라는 그저 안정적으로 작동해야 합니다.