부동산 팀은 스크래핑 인프라를 직접 운영하고 싶어하지 않는다. 그들이 알고 싶은 것은 어디서 공급이 늘어나고 있는지, 어디서 가격이 인하되고 있는지, 비교 대상 매물이 얼마에 호가되고 있는지, 그리고 매물이 얼마나 오래 남아있는지다. 수집 계층은 이를 위한 수단이며, 많은 팀에게 web scraping API는 브라우저 자동화와 프록시 운영 인력을 따로 두지 않고 이를 얻을 수 있는 가장 직접적인 방법이다.
무엇을 수집하고 수집 후 어떻게 모델링할지는 이 블로그의 다른 글에서 다룬다: 평가금액, 임대료, 모기지 데이터, 실시간 주택 시장 데이터 피드, 그리고 여러 포털에 걸친 매물 통합. 이 글은 수집 계층 자체에 관한 것이다. 왜 부동산 포털이 팀들을 API로 이끄는지, API가 부동산 페이지에 어떻게 대응되는지, 그리고 비용 구조가 어떻게 작동하는지를 다룬다.
부동산 포털 수집이 까다로운 이유
부동산 사이트는 네 가지 특성 때문에 대부분의 사이트보다 다루기 어렵다.
지도와 스크롤을 위해 만들어졌지, 페이지를 위해 만들어진 것이 아니다. 검색 결과는 지도가 움직이거나 목록이 스크롤될 때 JavaScript를 통해 로드되므로, 일반 HTTP 요청은 흔히 빈 껍데기만 반환한다.
결과는 페이지네이션되며 커서 기반이다. 1페이지에서 2페이지로 이동하는 것은 흔히 서버 측 상태에 의존하므로, 단순한 페이지 단위 요청 방식은 깨진다.
지역화되어 있다. 포털은 국가별로, 때로는 지역별로 서비스를 제공하므로, 보이는 내용은 요청이 어디서 오는 것처럼 보이는지에 달려 있다.
방어되어 있다. 가치가 높고 자주 갱신되는 매물은 자동화된 트래픽을 유인하며, 포털은 이에 상응하는 방어 조치를 취한다.
이 네 가지를 자체적으로 처리하려면 헤드리스 브라우저, 프록시 관리, 재시도 로직, 핑거프린트 조정이 필요하다. web scraping API는 이를 하나의 요청으로 묶어준다.
API가 부동산 페이지에 대응되는 방식
Shifter Web Scraping API를 사용하면 각 포털 문제에 직접적인 제어 수단이 대응된다.
지도와 목록 뷰. render_js=1은 추가 크레딧 비용 없이 헤드리스 Chrome에서 페이지를 실행하며, wait_for_css는 매물 카드가 실제로 렌더링될 때까지 캡처를 보류한다. JavaScript 지침으로 캡처 전에 스크롤하거나 “더 보기” 컨트롤을 클릭할 수 있다. JavaScript 렌더링을 참고하라.
결과 카드. list 타입의 extract_rules는 페이지의 모든 매물 카드를 매물마다 하나씩 JSON 객체로 반환하며, 당신 쪽에서 HTML 파서가 필요하지 않다.
페이지네이션. session_id는 요청 전체에 걸쳐 쿠키, 브라우저 상태, 업스트림 IP를 유지하므로 커서 기반 결과 집합을 순서대로 순회할 수 있다. 세션은 10분간 유휴 상태면 만료되며, 세션이 유지되는 동안 국가는 동일하게 유지되어야 한다. 세션과 프록시를 참고하라.
지역화. country는 요청마다 ISO alpha-2 코드를 받는다. 전역 지오로케이션과 premium_proxy=1을 통한 레지덴셜 풀은 Growth 플랜 이상에서 사용 가능하다.
증거 확보. screenshot=1은 렌더링된 페이지를 캡처하며, 매물의 특정 시점 상태, 가격 인하나 철회 여부가 중요할 때 유용하다.
긴 렌더링. webhook=<URL>은 연결을 열어둔 채로 대기하는 대신 응답이 준비되면 지정한 엔드포인트로 전달한다.
한 시장에 대한 검색 결과 요청은 다음과 같이 보인다:
curl "https://scrape.shifter.io/v1?api_key=YOUR_API_KEY\
&url=https%3A%2F%2Fportal.example.com%2Fsearch%3Fcity%3Dlyon\
&render_js=1&wait_for_css=.listing-card\
&country=fr&premium_proxy=1&session_id=lyon-walk-03\
&extract_rules=%7B%22listings%22%3A%7B%22selector%22%3A%22.listing-card%22%2C%22type%22%3A%22list%22%2C%22item%22%3A%7B%22price%22%3A%7B%22selector%22%3A%22.price%22%2C%22output%22%3A%22text%22%7D%2C%22area%22%3A%7B%22selector%22%3A%22.area%22%2C%22output%22%3A%22text%22%7D%2C%22link%22%3A%7B%22selector%22%3A%22a%22%2C%22output%22%3A%22%40href%22%7D%7D%7D%7D"대상 URL은 자체 쿼리 문자열을 담고 있기 때문에 URL 인코딩되어 있으며, 그렇지 않으면 API 요청의 파라미터로 잘못 해석될 수 있다. 응답은 listings 배열을 담은 하나의 JSON 객체다. 선택자가 아무것도 찾지 못한 필드는 null로 반환되며, 이는 아래에서 다루는 모니터링에서 중요하다.
팀별 활용 방식
인수 및 투자 팀은 목표 하위 시장에서 새로운 공급과 가격 인하를 지켜보며, 인하 시점을 협상 신호로 활용한다. 이들이 필요로 하는 것은 정의된 특정 지역 집합에 대한 다음날 이벤트 감지이며, 전국 단위 크롤링이 아니다.
중개업체는 지역별로 경쟁사 대비 자사 매물 점유율과 경쟁 매물이 얼마나 빨리 움직이는지를 추적한다. 이는 중개업체 수준에서 유지해야 한다. 매물에 담긴 중개인 연락처는 개인 데이터이며, 분석에 필요한 경우는 드물다.
PropTech 제품은 자사 사용자를 위해 비교 매물과 매물 피드를 구축한다. 여기서 API는 정규화 파이프라인의 하나의 입력이며, 필드 정의는 포털과 국가마다 다르다.
임대 사업자는 하위 시장에서의 호가 임대료와 인센티브를 모니터링한다. 인센티브는 가격 필드가 아니라 설명 텍스트에 담겨 있는 경우가 많으므로, 추출 규칙은 헤드라인 임대료뿐 아니라 설명도 캡처해야 한다.
대출기관과 보험사는 노출이 있는 지역의 시장 상황을 추적한다. 그 경계는 공개된 시장 데이터이며, 개별 차입자나 거주자 정보는 절대 포함하지 않는다.
비용 구조: 크레딧을 중심으로 설계하기
크레딧 1개는 요청이 무엇을 반환하든 성공한 요청 1개를 구매한다. 렌더링, 추출 규칙, 스크린샷, API 자체의 재시도가 모두 포함되며, 실패한 요청이나 대상 오류에는 비용이 청구되지 않는다.
이는 부동산에 있어 직접적인 설계상의 결과를 낳는다. 매물 카드 40개를 반환하는 검색 결과 페이지는 매물 1개를 반환하는 상세 페이지와 동일하게 단 하나의 크레딧이 든다. 따라서 효율적인 패턴은 카드가 필요한 필드, 가격, 면적, 방 수, 링크를 담고 있는 곳에서는 결과 페이지에서 수집하고, 매물이 새것이거나 카드가 변경된 경우에만 상세 페이지를 가져오는 것이다.
활성 매물이 수천 건인 시장의 경우, 이 차이는 크레딧 측면에서 흔히 한 자릿수 이상의 차이를 만든다. 동일한 비용으로 결과 페이지를 더 자주 다시 방문할 수 있어 데이터 최신성도 개선된다.
두 가지 비용 관련 지침을 더 소개한다. 각 시장이 움직이는 속도에 맞는 주기로 갱신하라. 대부분의 매물 화면에는 하루 단위 갱신으로 충분하다. 그리고 깔끔하게 파싱된 행 대비 소비된 크레딧을 계속 지켜보라. 선택자가 깨져도 성공했지만 쓸모없는 응답마다 여전히 크레딧이 소비되기 때문이다.
소리 없는 파손을 모니터링하라
포털은 리디자인되며, 변경된 선택자는 요청을 실패시키지 않는다. 대신 null을 반환하고, 요청은 성공하고, 크레딧은 소비된다.
이동 창(rolling window) 기준으로 필드별, 포털별, 국가별 null 비율을 추적하고, 기준치에서 급증하면 알림을 설정하라. 추출 규칙에 버전을 매겨 수정 사항을 추적할 수 있게 하고, 파싱 전에 원본 응답을 저장해서 재수집 비용을 들이지 않고 수정된 규칙을 재실행할 수 있게 하라. 적재 방식은 web scraping API 데이터를 SQL로 옮기기에 나와 있다.
API가 적합한 수집 계층인 경우와 그렇지 않은 경우
API를 선택하라 렌더링과 안티봇 대응이 주된 부담일 때, 팀이 소규모이거나 인프라보다 데이터 중심일 때, 그리고 예측 가능한 성공 기반 과금이 최저 단위 비용보다 중요한 경우.
자체 관리형 프록시를 선택하라 완전히 커스텀한 브라우저 흐름이 필요하거나, 스택을 직접 소유하는 것이 더 저렴한 규모로 운영하거나, 이미 스크래핑 엔지니어를 보유하고 있는 경우. 프록시 기반 접근법은 부동산 데이터를 위한 프록시에서 다룬다.
라이선스 피드를 우선 선택하라 해당 시장에 존재한다면 어디든. 커버리지와 필드 품질이 보통 더 우수하고 약관도 명확하다. 라이선스가 제공하지 않는 부분에 대해서만 수집을 활용하라.
올바르게 유지하기
각 포털의 약관을 준수하고 요청량을 적절히 유지하라. 소유자, 중개인, 거주자 정보는 기본적으로 개인 데이터로 취급하고, 분석에 필요하지 않은 경우 수집 단계에서 제거하라. 스크린샷은 매물이 무엇을 보여주었는지에 대한 증거로만 사용하고, 재게시용 자료로 사용하지 마라. 더 넓은 틀은 레지덴셜 프록시와 GDPR 준수에 있다.
FAQ
부동산 포털에 JavaScript 렌더링이 필요한가요?
대부분의 현대적인 포털에서는 필요하다. 매물 결과가 초기 페이지 로드 이후에 로드되기 때문이다. 정적 요청과 동일한 크레딧이 소비되므로, 결과가 클라이언트 측에서 렌더링되는 경우 이를 활성화하지 않을 이유가 거의 없다.
하나의 API로 여러 국가의 포털을 다룰 수 있나요?
가능하다. 요청마다 country를 설정하고 시장별로 세션을 두면 된다. 전역 지오로케이션에는 Growth 플랜 이상이 필요하다.
페이지네이션된 검색 결과를 안정적으로 순회하려면 어떻게 해야 하나요?
검색마다 session_id를 사용하고, 그 안에서 국가를 일정하게 유지하고, 순회를 계속 진행하라. 세션은 10분간 유휴 상태면 만료된다.
상세 페이지를 스크래핑하는 것이 결과 페이지를 스크래핑하는 것보다 저렴한가요?
결과 페이지가 더 저렴하다. 매물 카드가 필요한 필드를 담고 있는 곳이라면 어디든 해당된다. 크레딧 1개로 여러 매물을 반환받을 수 있고, 상세 페이지는 새 매물이나 변경된 매물에만 사용하면 된다.
결론
대부분의 부동산 팀에게 시장 인텔리전스의 어려운 부분은 무엇을 측정할지 결정하는 것이 아니다. 지도, 스크롤, 인간 방문자를 위해 만들어진 포털에서 신뢰할 수 있는 데이터를 뽑아내는 것이다. web scraping API는 렌더링, 페이지네이션, 지역화, 재시도를 요청 파라미터로 전환하며, 데이터가 도착했을 때만 과금한다.
결과 페이지에서 먼저 수집하고, 시장별 세션으로 검색을 순회하고, 소리 없는 파손을 감지하기 위해 null 비율을 지켜보고, 라이선스 피드가 존재하는 곳이라면 그것을 우선 활용해서 크레딧을 중심으로 설계하라. 제품은 Web Scraping API 페이지에 있고, 요금제는 가격 페이지에, 더 넓은 활용 사례는 부동산 페이지에 있다.