해결 과제
개발 팀이 매물 정보 서비스를 출시합니다. 3주 동안은 잘 작동합니다. 그러다 Zillow가 DOM을 변경하고, Rightmove가 TLS 검사를 강화하면, 단 한 번의 주말 사이에 6개 소스 중 4개에서 스크래퍼가 작동을 멈춥니다.
부동산 데이터 애그리게이션에는 가격 모니터링이나 SERP 트래킹에는 없는 고유한 문제가 있습니다. 깔끔한 단 하나의 API에서 정형 데이터를 가져오는 것이 아니기 때문입니다. 서로 다른 안티봇 스택, 레이아웃, 지역적 제한, 업데이트 주기를 사용하는 여러 포털의 매물 정보를 직접 짜깁기해야 합니다. 미국의 Zillow, MLS 기반 데이터를 제공하는 Redfin, 영국의 Rightmove, 호주의 realestate.com.au, 독일의 Immobilienscout24 등이 그렇습니다. 모든 포털이 저마다 하나의 독립된 엔지니어링 프로젝트가 됩니다.
Scrapfly의 2026년 연구에 따르면, 주요 부동산 포털들은 TLS 지문을 검사하여 브라우저 수준의 핸드셰이크를 모방하지 않는 클라이언트를 차단합니다. 그들의 Rightmove 가이드에서는 몇 달마다 구조가 바뀌는 JSON embedded in JavaScript variables를 다루는 방법을 설명합니다. Redfin은 매물 데이터를 수십 개의 DOM 노드에 분산시켜 놓기 때문에, 레이아웃이 조금만 바뀌어도 한 번에 필드의 절반이 누락될 수 있습니다. 또한 지역 포털은 방문자의 국가에 따라 다른 콘텐츠를 제공하므로, 미국 기반의 스크래퍼는 realestate.com.au에서 유용한 정보를 전혀 얻지 못합니다.
그 결과 매물 데이터의 최신성이 소리 없이 저하됩니다. 매물의 3분의 1이 48시간 이내에 오래된 데이터가 됩니다. 사용자는 지난주 가격을 보게 됩니다. 영업 팀은 불만을 접수하기 시작하고, 포털 레이아웃이 주로 주말에 변경되기 때문에 월요일마다 지원 티켓이 급증합니다.
해결 방법
대규모로 매물 데이터를 수집 및 통합하는 것은 단순한 스크래핑 문제가 아닙니다. 스크래핑의 탈을 쓴 신뢰성 문제입니다. 스크래퍼가 계속 고장 나는 이유에서 일반적인 경우를 다루었지만, 부동산 분야는 이 모든 문제를 극대화합니다.
이를 제대로 처리하려면 플랫폼에 네 가지 요소가 유기적으로 결합되어야 합니다. 첫째, 실제 브라우저와 일치하는 TLS 지문이 필요합니다. 단순히 브라우저 형태의 User-Agent 문자열뿐만 아니라, Zillow와 Rightmove가 봇과 인간을 구분하는 데 사용하는 실제 암호화 순서(cipher order) 및 ClientHello 확장이 일치해야 합니다. 둘째, 각 타겟 시장에 맞는 지리적으로 정확한 주거용 IP가 필요합니다. 독일의 애그리게이터가 Immobilienscout24에 미국 데이터센터 트래픽을 보내면서 유용한 응답을 기대할 수는 없기 때문입니다. 셋째, 호스트별 proxy 라우팅이 필요합니다. Zillow에서 작동하는 전략이 realestate.com.au에서는 실패하기 때문입니다. 넷째, 모든 것을 클라이언트 사이드에서 처리하는 포털을 위한 폴백(fallback)으로서 브라우저 렌더링이 필요합니다.
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 플래그는 일치하는 TLS 지문과 함께 전체 브라우저 header 세트를 주입합니다. maxTries: 5는 proxy 매니저에게 성공할 때까지 최대 5개의 IP를 순환하도록 지시합니다. 검증 규칙은 매물 데이터 대신 소프트 차단(soft-block) 페이지를 반환하는 200 response와 같은 '소리 없는 차단'을 잡아냅니다. 따라서 성공률은 HTTP 상태 코드가 주장하는 값이 아니라 실제로 성공한 요청을 반영하게 됩니다.
모든 것을 JavaScript를 통해 제공하는 포털(Redfin이 대표적인 예입니다)은 실제 브라우저 렌더링이 필요합니다. FourA의 Browser 제품은 첫 번째 핸드셰이크에서 바로 차단되는 가벼운 에뮬레이터가 아닌, 실제 Chromium 인스턴스로 이러한 포털을 처리합니다. 봇 탐지 기술이 행동 기반으로 진화한 2026년 현재, 실제 브라우저가 아닌 도구들은 점점 더 쉽게 발각됩니다.
결과
부동산 애그리게이터가 자체 구축한 스크래핑 스택에서 API 우선 방식으로 전환하면 어떤 일이 일어날까요? 실제 운영 사례에서 관찰되는 패턴은 다음과 같습니다(업계 벤치마크에 기반한 예시 시나리오).
- 매물 최신성: 활성 시장 기준 '48시간 이내 업데이트'에서 '2시간 이내 업데이트'로 개선
- 엔지니어링 시간: 스크래퍼 유지보수에 소요되는 시간이 70% 감소합니다. 전담 팀 대신 1명의 엔지니어가 교대로 담당할 수 있습니다
- 포털 커버리지: 인프라의 비례적인 증가 없이 대상 사이트가 6개에서 20개 이상으로 확장됩니다
- 소리 없는 차단율: 검증 규칙이 소프트 차단을 잡아내기 시작하면서, 보안이 적용된 포털에서의 차단율이 3% 미만으로 떨어집니다
FourA 플랫폼을 사용하는 팀들에서 발견되는 한 가지 패턴은, 신뢰성 레이어가 공유되고 나면 새로운 시장을 추가하는 일이 스프린트 과제가 아니라 단순한 설정 변경이 된다는 점입니다. 흥미로운 질문은 이제 "이게 왜 또 고장 났지?"에서 "다음에는 어떤 포털을 추가할까?"로 바뀝니다.
솔직한 한계점도 있습니다. 로그인 세션이 필요한 부동산 포털(일부 MLS 시스템, 특정 중개인 전용 화면 등)은 request 인프라 외에도 계정 관리가 필요합니다. 이는 FourA가 해결하지 않는 별개의 문제이며, 어떻게 해결하는지 설명하지 않으면서 해결할 수 있다고 말하는 곳이 있다면 신뢰하지 않는 것이 좋습니다.
핵심 요약
부동산은 오래된 데이터가 단순히 성가신 수준을 넘어 제품의 실패로 이어지는 몇 안 되는 산업 중 하나입니다. 패션 사이트에서 일주일 전 가격을 보여주는 것은 가벼운 해프닝에 불과합니다. 하지만 매매가 활발한 시장에서 일주일 전 매물 정보를 보여준다는 것은, 사용자가 이미 지난 화요일에 팔린 집을 문의하게 된다는 것을 의미합니다.
그러나 이 경쟁에서 승리하는 팀은 가장 많은 소스를 가진 팀이 아닙니다. 새로운 포털을 추가할 때마다 매번 동일한 proxy 및 안티봇 배관 작업을 반복하지 않는 팀입니다. 이 레이어가 공유되고 나면 데이터 품질, 최신성 SLA, 포털 간 중복 제거, 가격 트렌드 분석 등 진짜 흥미로운 작업이 시작됩니다. 이것이 바로 제품의 본질입니다. 그 아래의 모든 인프라는 그저 알아서 잘 작동해야 합니다.