「zillow scraper github」로 검색하면 저장소 409개가 떠요. 골라 쓰면 되겠다 싶죠. 그런데 그중 264개가 1년 넘게 손도 안 댄 상태라는 걸 알면 분위기가 달라져요.
이 저장소들을 한참 들여다보고, 실제 Zillow 페이지에 직접 돌려보기도 했어요. 이번엔 또 뭐가 깨졌다고 개발자들이 토로하는 GitHub 이슈와 Reddit 글도 죽 읽었고요. 패턴이 거의 똑같아요. 처음엔 잘 돌아가 별을 잔뜩 받죠. 그러다 Zillow가 DOM을 손보거나 봇 차단을 조이거나 내부 API를 닫으면 조용히 죽어요. Reddit의 한 개발자는 이렇게 정리하더라고요. 「스크래핑 프로젝트는 페이지나 API가 바뀔 때마다 계속 손봐줘야 해요.」 제가 첫 Zillow 스크래퍼를 클론하기 전에 누가 미리 보여줬으면 했던 리뷰예요. 2026년 기준 뭐가 진짜 돌아가고 뭐가 왜 깨지는지, 그리고 GitHub의 수많은 저장소를 건너뛰고 Thunderbit 같은 도구로 가는 게 언제 더 나은지 솔직하게 적었어요.
Zillow 스크래퍼 GitHub 프로젝트란 무엇이고, 누가 필요할까요?
「Zillow 스크래퍼」는 Zillow에서 매물 데이터를 자동으로 긁는 스크립트나 도구예요. 가격, 주소, 침실·욕실 수, 평방피트, Zestimate, 매물 상태, 시장 체류 일수 같은 거죠. 가격 이력이나 세금 기록처럼 상세 페이지 깊숙한 데이터까지 가져오기도 해요. GitHub를 찾는 이유는 분명해요. 공짜고, 오픈소스고, 마음대로 고칠 수 있으니까요. 저장소를 포크해 필드를 손보고, 결과를 자기 파이프라인에 꽂으면 되죠. 머릿속에선 완벽한 그림이에요.
쓰는 사람들도 꽤 또렷해요.
- 부동산 투자자는 우편번호별로 기회를 찾아요. 가격 하락, Zestimate 격차, 시장 체류 일수를 봐요
- 중개인은 매물 URL, 에이전트 연락처, 상태 변화를 모아 잠재 고객 리스트를 만들어요
- 시장 조사자와 분석가는 주소, 평방피트당 가격, 실제 매각가와 매물가, 재고 수를 구조화해서 뽑아요
- 운영팀은 일정한 간격으로 시장 전반의 가격과 재고를 지켜봐요
공통점은 딱 하나예요. 한 번 복붙하고 끝나는 게 아니라, 구조화되고 반복 가능한 데이터를 원한다는 거죠. 스크래핑이 매력적인 이유이자, 저장소가 멈추는 순간 유지보수 부담이 확 커지는 이유이기도 해요.
2026 Zillow 스크래퍼 GitHub 저장소 감사: 실제로 아직 작동하는 것은?
별 많고 포크 많은 Zillow 스크래퍼를 GitHub에서 추려, 마지막 커밋 날짜를 확인하고, 공개 이슈를 읽고, 실제 Zillow 페이지에 직접 돌려봤어요. 기준은 단순해요. 2026년 4월 기준 검색 결과나 상세 페이지에서 정확한 매물 데이터를 돌려주면 「작동」. 실행은 되는데 데이터가 빠지거나 몇 페이지 만에 막히면 「부분 작동」. 아예 안 되거나 유지 관리자가 죽었다고 못 박으면 「고장」이고요.
냉정하게 말하면 이래요. 12~18개월 전엔 유망해 보이던 저장소 대부분이 소리 없이 무너졌어요.
선별 비교 표: 상위 Zillow 스크래퍼 GitHub 저장소
| 저장소 | 언어 | 별점 | 마지막 푸시 | 방식 | 2026 상태 | 핵심 한계 |
|---|---|---|---|---|---|---|
| johnbalvin/pyzill | Python | 96 | 2025-08-28 | Zillow 검색/상세 추출 + 프록시 지원 | 부분 작동 | README에 “회전형 주거용 프록시를 사용하라”라고 적혀 있어요. 이슈에는 Cloudflare 차단, proxyrack을 통한 403, 프록시를 써도 CAPTCHA가 뜬다는 내용이 있어요. |
| johnbalvin/gozillow | Go | 10 | 2025-02-23 | 부동산 URL/ID 및 검색 메서드를 제공하는 Go 라이브러리 | 부분 작동 | pyzill과 같은 유지관리자지만 채택률이 낮고 공개 이슈도 적어요. 신뢰도는 더 낮아요. |
| cermak-petr/actor-zillow-api-scraper | JavaScript | 59 | 2022-05-04 | 내부 Zillow API 재귀 호출을 사용하는 호스팅 액터 | 부분 작동(위험) | 결과 제한을 우회하려고 지도 범위를 재귀적으로 분할하는 똑똑한 설계예요. 하지만 GitHub 저장소는 2022년 이후 푸시가 없어요. 이슈 제목 중 하나는 “이거 아직 작동하나요?”예요. |
| ChrisMuir/Zillow | Python | 170 | 2019-06-09 | Selenium | 고장 | README에 명시돼 있어요: “2019년 기준으로 이 코드는 더 이상 대부분의 사용자에게 작동하지 않는다.” Zillow는 웹드라이버를 감지하고 끝없는 CAPTCHA를 보여줘요. |
| scrapehero/zillow_real_estate | Python | 152 | 2018-02-26 | requests + lxml | 고장 | 이슈에는 “빈 데이터셋을 반환함”, “.csv 파일에 출력이 없음”, “이 저장소 아직 업데이트되나요?” 같은 내용이 있어요. |
| faithfulalabi/Zillow_Scraper | Python/notebook | 30 | 2021-07-02 | 하드코딩된 Selenium | 고장 | 텍사스주 알링턴 렌트에 맞춰진 교육용 프로젝트예요. 범용 스크래퍼가 아니에요. |
| eswan18/zillow_scraper | Python | 10 | 2021-04-10 | 스크래퍼 + 처리 파이프라인 | 고장 | 저장소가 보관 처리돼 있어요. |
| Thunderbit | 노코드(Chrome 확장 프로그램) | N/A | 지속적으로 업데이트 | AI가 페이지 구조를 읽고 사전 제작된 Zillow 템플릿 사용 | 작동 | 유지할 GitHub 저장소가 없어요. Zillow가 레이아웃을 바꿔도 AI가 적응해요. 무료 플랜도 있어요. |
그림이 또렷해요. GitHub 생태계에 살아 있는 코드가 아예 없는 건 아니에요. 다만 눈에 띄는 저장소 대부분은 튜토리얼이거나, 옛날 흔적이거나, 프록시 워크플로 위에 얇게 씌운 껍데기일 뿐이에요.
「작동」, 「고장」, 「부분 작동」의 의미
이 라벨이 별점보다 훨씬 중요하니까 정확히 짚고 갈게요.
- 작동: 테스트 시점 기준으로 Zillow 검색 페이지나 상세 페이지에서 정확한 매물 데이터를 성공적으로 반환하며, 유지 관리자가 프로젝트 종료를 알리지 않은 상태
- 부분 작동: 실행은 되지만 데이터가 불완전하거나, 몇 페이지 뒤 차단되거나, 특정 페이지 유형에서만 작동함 — 보통 프록시 인프라와 지속적인 조정이 필요함
- 고장: 데이터를 반환하지 못하거나 오류를 내거나, 유지 관리자 또는 커뮤니티가 명시적으로 비기능 상태라고 표시함
별 170개짜리 「고장」 저장소가, 별 10개라도 실제 데이터를 돌려주는 저장소보다 나을 이유는 없어요. 인기와 품질은 다른 얘기니까요.
Zillow 스크래퍼 GitHub 프로젝트가 깨지는 이유: 5가지 흔한 실패 모드
Zillow 스크래퍼가 왜 깨지는지 알면 어떤 README보다 시간을 아껴요. 원인을 알아야 더 단단하게 만들든, 유지보수 비용이 감당 안 되는지 판단하든 하니까요.
1. DOM 재구성(Zillow의 React 프런트엔드)
Zillow 프런트엔드는 React 기반이고 자주 바뀌어요. 클래스명, 컴포넌트 구조, 데이터 속성이 예고 없이 갈아엎혀요. 오늘 div.list-card-price를 노리던 스크래퍼가 내일은 그 클래스가 통째로 사라진 걸 보게 되죠. Stack Overflow 답변에도 Zillow는 「페이지마다 클래스명이 다르다」라고 나와요.
결과가 고약해요. 스크립트는 멀쩡히 돌아가는데 빈 필드만 채워요. 일주일 내내 공란만 쌓이고 나서야 알아차리죠.
2. 내부 API와 GraphQL 엔드포인트 변경
좀 더 영리한 저장소는 HTML을 아예 건너뛰고 Zillow 내부 GraphQL이나 REST API를 직접 때려요. 예를 들어 actor-zillow-api-scraper는 내부 API를 쓰면서, 결과 제한을 피하려고 지도 범위를 재귀적으로 쪼개요. 영리한 설계죠. 하지만 Zillow는 이 엔드포인트를 주기적으로 갈아엎어요. 그러면 스크래퍼는 404를 내거나, 오류 한 줄 없이 빈 JSON만 돌려줘요.
이건 좀 더 까다로운 고장이에요. 코드는 멀쩡해요. 과녁이 옮겨간 거죠.
3. 봇 방지 및 CAPTCHA 강화
Zillow는 봇 탐지를 계속 조여왔어요. 2026년 4월 제가 직접 돌려봤을 때도, 평범한 requests.get()으로 zillow.com이나 zillow.com/homes/Chicago,-IL_rb/에 붙으면 CloudFront에서 403이 돌아왔어요. Chrome처럼 꾸민 user-agent에 Accept-Language 헤더까지 붙여도 똑같았죠. 커뮤니티 얘기도 비슷해요. 어떤 사용자는 역공학한 API 흐름이 요청 약 100번 뒤부터 403을 뱉기 시작했다고 했어요.
소규모에선 잘 돌던 스크래퍼가 규모를 키우는 순간 무너질 수 있어요. 우편번호 3개에서 매물 200개를 추적하려는 상황이면 꽤 곤란하죠.
4. 프리미엄 데이터 주변의 로그인 장벽
Zestimate 세부 정보, 세금 기록, 일부 가격 이력은 인증 뒤에 숨어 있어요. 오픈소스 스크래퍼는 로그인 흐름을 못 다루는 경우가 많아서, 이런 필드는 빈 채로 돌아와요. 가격 이력이나 세금 평가액이 핵심인 작업이면 곧장 이 벽을 만나요.
5. 의존성 부패와 방치된 저장소
scrapehero 저장소 이슈에는 No module named 'unicodecsv' 같은 설치 문제가 있어요. eswan18 저장소는 드라이버와 GIS 의존성을 손으로 깔다 겪는 고생을 문서로 남겨놨고요. Python 라이브러리가 업데이트되면 호환성이 깨져요. 반년 넘게 손 안 댄 저장소는 Zillow 봇 차단에 닿기도 전에, 새 환경에서 설치부터 실패하는 경우가 많아요.
2026년 Zillow 봇 방지: 실제로 상대해야 하는 것
「프록시 돌리고 헤더만 바꾸면 돼요」는 2022년엔 어느 정도 맞는 말이었어요. 2026년엔 아니에요.
IP 차단을 넘어: TLS 지문과 JS 챌린지
Zillow는 IP만 막지 않아요. 커뮤니티 보고에 따르면 Zillow는 Cloudflare 뒤에 있고, 단순 속도 제한을 넘어서는 지문 인식과 봇 탐지를 써요. TLS 지문 인식은 클라이언트가 서버와 처음 연결할 때 주고받는 신호를 보고 브라우저가 아닌 클라이언트를 골라내요. 새 프록시를 써도 TLS 서명이 진짜 Chrome과 안 맞으면 스크래퍼가 그대로 들통나요.
JavaScript 챌린지도 또 다른 관문이에요. JS를 끝까지 안 돌리거나, 자동화 흔적(navigator.webdriver = true 같은 것)을 흘리는 헤드리스 브라우저는 잡혀요.
검색 페이지 vs. 부동산 상세 페이지: 방어 수준이 다르다
Zillow 페이지가 다 똑같이 보호되는 건 아니에요. Apify의 부동산 스키마는 상세 페이지를 건너뛰는 「Fast Mode」와 더 풍부한 데이터를 담는 느린 「Full Mode」를 딱 갈라놔요. Thunderbit의 Zillow 가이드도 초기 목록 수집과, 상세 페이지를 채우는 「하위 페이지 스크래핑」을 따로 설명해요.
실무로 옮기면 이래요. 검색 결과에선 잘 되다가, 개별 매물 페이지에서 막혀요. 가치 높은 데이터일수록 더 자주 긁히니까, Zillow가 거기를 훨씬 세게 지키거든요.
HTTP 전용을 고집하는 개발자들: 왜 브라우저 자동화를 피할까요?
Selenium, Playwright, Puppeteer 없이 HTTP만 쓰려는 개발자가 꽤 있어요. 이유는 현실적이에요. 브라우저 자동화는 느리고, 자원을 많이 먹고, 대규모로 굴리기도 어렵거든요.
솔직하게 평가하면 이래요. 2026년엔 정교한 헤더·지문 관리 없이 순수 HTTP만으로 Zillow를 상대하기가 점점 더 빡세져요. 커뮤니티 증거는 Zillow 같은 대상에선 브라우저 렌더링이 예외가 아니라 기본값이 되어간다는 쪽을 가리켜요.
Zillow용 구체적인 차단 회피 베스트 프랙티스
직접 만들 거라면, 실제로 먹히는 것과 안 먹히는 것을 이렇게 갈라볼 수 있어요.
- 요청 속도를 무작위로 조절해서 사람처럼 굴기. 고정 딜레이 말고, 세션처럼 들쭉날쭉한 간격을 쓰기
- 헤더를 현실적으로 구성하기.
Accept-Language,Sec-CH-UA계열, 올바른 referer 체인까지. 단, 현실적인 헤더는 필요조건이지 충분조건은 아니에요 - 세션 회전하기. 같은 프록시·쿠키 조합을 수백 번 우려먹지 않기
- 브라우저 렌더링으로 갈아탈 시점 파악하기. HTTP 전용이 50번 요청 만에 403을 내면, 이미 진 싸움이에요
2026년 Zillow를 한 방에 뚫어주는 마법의 헤더 묶음이 있다는 글은 믿지 마세요.
Thunderbit의 클라우드 스크래핑은 이 전부를 알아서 처리해요. 미국·유럽·아시아 인프라를 돌려쓰고, 렌더링과 봇 방지를 관리해서, 사용자는 복잡한 프록시 설정을 통째로 건너뛰어요. 핵심은 운영 부담을 누가 지느냐예요.
Zillow 스크래퍼 GitHub 설정을 미래에도 버티게 만드는 베스트 프랙티스
GitHub/직접 구축을 고른 분들을 위해, 몇 달 버티는 스크래퍼와 며칠 만에 죽는 스크래퍼를 가르는 습관을 정리할게요.
취약한 클래스명에서 셀렉터를 분리하세요
저장소가 Zillow의 자동 생성 CSS 클래스명에 의존한다면, 그건 경고등이에요. 그런 이름은 자주, 어떤 경우엔 매주 바뀌어요. 대신 이렇게 하세요.
aria-label,data-*속성, 또는 근처 제목 텍스트를 기준으로 요소를 찾기- 가능하면 텍스트 콘텐츠 기반 셀렉터 쓰기
- Zillow가 페이지 소스에 구조화된 데이터를 심어둘 땐, HTML 파싱보다 JSON 추출을 먼저
자동 상태 점검을 추가하세요
Zillow 스크래핑은 일회성 스크립트가 아니라 운영 모니터링처럼 다뤄야 해요. 크론 잡이나 GitHub Actions를 걸어서 이렇게 하세요.
- 매일 알려진 매물 하나에 스크래퍼 돌리기
- 출력 스키마 검증(예상 필드가 다 있고 비어 있지 않은지 확인)
- 출력이 이상하거나 비면 알림 보내기
이러면 고장을 몇 주가 아니라 24시간 안에 잡아내요.
의존성 버전을 고정하고 가상환경을 사용하세요
Python이든 Node든 의존성은 항상 특정 버전에 못 박으세요. 가상환경이나 Docker 컨테이너를 쓰고요. 이번 감사에서 본 옛 저장소들이 설치 부패가 얼마나 빨리 오는지 잘 보여줘요. Zillow 봇 차단에 닿기도 전에, 먼저 무너지는 건 대개 의존성이에요.
스크래핑량은 보수적으로 유지하세요
그 요청 약 100회 한계가 칼같은 숫자는 아니에요. 다만 테스트에선 멀쩡하던 스크래퍼가 규모에 따라 달라진다는, 믿을 만한 경고예요. 요청을 여러 세션에 흩뿌리세요. 무작위 지연을 쓰고요. 한 번에 매물 1만 개를 긁으려 들지 마세요.
직접 구축이 그만한 가치가 없는 순간을 알아차리세요
스크래퍼 손보는 데 데이터 분석보다 더 많은 시간을 쓰고 있다면, 셈이 이미 뒤집힌 거예요. 실패가 아니라, 관리형 솔루션을 떠올려야 한다는 신호예요.
Zillow 스크래퍼 GitHub(DIY) vs. 노코드 도구: 솔직한 의사결정 매트릭스
「zillow scraper github」를 찾는 사람은 크게 둘로 갈려요. 코드를 손에 쥐고 싶은 개발자, 그리고 그냥 스프레드시트에 데이터만 들어오면 되는 부동산 실무자예요. 둘 다 말이 돼요. 실제 트레이드오프가 어떻게 갈리는지 봐요.
나란히 비교 표
| 기준 | GitHub 스크래퍼(Python) | 노코드 도구(예: Thunderbit) |
|---|---|---|
| 설정 시간 | 30~120분(환경, 의존성, 프록시) | 약 2분(확장 프로그램 설치, 스크래핑 클릭) |
| 유지보수 | 지속적 — Zillow가 바뀌면 깨짐 | 없음 — AI가 페이지 레이아웃에 자동 적응 |
| 봇 방지 처리 | 수동(프록시, 헤더, 지연) | 내장(클라우드 스크래핑, 회전형 인프라) |
| 데이터 필드 | 직접 코딩한 만큼 커스텀 | AI 제안 또는 템플릿 기반 |
| 내보내기 옵션 | 코드로 CSV/JSON | Excel, Google Sheets, Airtable, Notion — 무료 |
| 비용 | 무료(코드) + 프록시 비용(주거용 $3.50~$8/GB) | 무료 플랜 제공, 이후 크레딧 기반 |
| 커스터마이징 한계 | 무제한(코드 소유) | 높음(필드 AI 프롬프트, 하위 페이지 스크래핑) 하지만 한계는 있음 |
프록시 비용의 현실 점검
프록시 비용을 넣는 순간 「무료 저장소」라는 말은 힘이 쭉 빠져요. 지금 공개된 주거용 프록시 가격은 이래요.
| 제공업체 | 가격(2026년 4월 기준) |
|---|---|
| Webshare | 1GB 기준 $3.50/GB, 대용량 번들일수록 더 낮음 |
| Decodo | 사용량 기반 약 $3.50/GB |
| Bright Data | 명목상 $8/GB, 현재 프로모션 시 $4/GB |
| Oxylabs | 시작가 $8/GB |
주거용 프록시는 대략 GB당 $3.50~$8(약 4,800원~1만 1천 원)이에요. 저장소 자체는 공짜라도, 프록시까지 붙인 Zillow 워크플로는 대개 공짜가 아니에요.
GitHub 저장소를 선택해야 할 때
- 코드를 짜고 손보는 일 자체가 즐거울 때
- 아주 구체적인 커스터마이징이 필요할 때(맞춤 데이터 변환, 독자적인 파이프라인 연동)
- 고장 대응을 감당할 시간과 기술이 있을 때
- 프록시 인프라를 직접 굴릴 마음이 있을 때
Thunderbit을 선택해야 할 때
- 설정도 유지보수도 없이 오늘 당장 믿을 만한 데이터가 필요할 때
- 개발자가 아니라 부동산 중개인, 투자자, 운영팀일 때
- Google Sheets, Airtable, Notion으로 바로 내보내기를 코드 없이 하고 싶을 때
- 추가 설정 없이 하위 페이지 스크래핑으로 매물 데이터를 더 채우고 싶을 때
- 쉬운 말로 설명하는 예약 스크래핑이 필요할 때
단계별: GitHub 없이 Thunderbit로 Zillow 스크래핑하는 방법
노코드 경로는 GitHub 설정 과정과는 완전히 다른 세상이에요.
1단계: Thunderbit Chrome 확장 프로그램 설치하기
Chrome 웹 스토어에서 Thunderbit을 설치하고 가입하세요. 무료 플랜이 있어요.
2단계: Zillow로 이동해 Thunderbit 열기
아무 Zillow 검색 결과 페이지나 들어가 보세요. 특정 우편번호 매물 목록 같은 거요. 브라우저 툴바에서 Thunderbit 아이콘을 클릭하세요.
3단계: Zillow 즉시 스크래퍼 템플릿을 사용하거나 AI로 필드 제안받기
Thunderbit에는 사전 제작된 Zillow 템플릿이 있어요. 설정 없이 한 번 클릭이면 끝이에요. 주소, 가격, 침실·욕실 수, 평방피트, 에이전트 이름, 에이전트 전화번호, 매물 URL 같은 표준 필드를 다뤄요.
아니면 「AI로 필드 제안」을 누르세요. AI가 페이지를 읽고 열을 제안해요. 제 경험상 Zestimate까지 포함해 필드 20개 이상을 잡아내는 경우가 많아요.
4단계: 스크래핑을 클릭하고 결과 검토하기
「스크래핑」을 클릭하세요. 페이지네이션, 봇 방지, 데이터 구조화를 Thunderbit이 알아서 처리해요. 구조화된 결과 표가 나와요. 403도 없고, 빈 필드도 없고, 프록시 설정도 필요 없어요.
5단계: 하위 페이지 데이터로 보강하기(선택 사항)
「하위 페이지 스크래핑」을 누르면 Thunderbit이 매물마다 상세 페이지를 돌며 가격 이력, 세금 기록, 토지 면적, 학교 평점 같은 필드를 가져와요. GitHub 방식이라면 자체 셀렉터 로직에 봇 방지 처리까지 얹은 두 번째 스크래핑을 따로 짜야 해요. 여기선 클릭 한 번이면 끝나고요.
6단계: 데이터를 무료로 내보내기
Excel, Google Sheets, Airtable, Notion으로 무료로 내보낼 수 있어요. 원하면 CSV나 JSON으로 다운로드해도 되고요. 내보내기 코드를 따로 짤 필요가 없어요.
보통 환경 설정으로 시작해 403 오류 해결로 끝나는 GitHub 여정과는 정말 다르죠.
CSV에서 인사이트로: Zillow 데이터를 실제로 어떻게 활용할까요?
대부분의 가이드는 「여기 CSV요」에서 끝나요. 데이터만 던져주고, 정작 그걸로 뭘 해야 하는지는 안 알려주는 셈이죠.
스크래핑은 1단계예요. 나머지는 이래요.
1단계: 스크래핑 — 매물 데이터 수집
검색 결과의 핵심 필드: 가격, 침실 수, 욕실 수, 평방피트, 주소, Zestimate, 매물 상태, 시장 체류 일수, 매물 URL.
2단계: 보강 — 하위 페이지 스크래핑으로 상세 페이지 데이터 가져오기
상세 페이지의 추가 필드: 가격 이력, 세금 기록, 토지 면적, HOA 회비, 학교 평점, 에이전트 연락처. Thunderbit의 하위 페이지 스크래핑은 이걸 한 번에 처리해요. GitHub 방식이라면 자체 셀렉터와 봇 방지 로직을 갖춘 별도 스크래핑 단계가 필요하고요.
3단계: 내보내기 — 원하는 플랫폼으로 전달하기
- Google Sheets: 빠른 분석과 공유용
- Airtable: 미니 CRM 또는 딜 추적기용
- Notion: 팀 대시보드용
- CSV/JSON: 커스텀 파이프라인용
4단계: 모니터링 — 정기 스크래핑 예약하기
여러 포럼 스레드에서 아직 안 풀린 숙제로 꼽는 부분이에요. 오늘 데이터만 필요한 게 아니잖아요. 가격 하락, 상태 변화(active → pending → sold), 새 매물 등장까지 잡아야 하니까요.
Thunderbit의 예약 스크래퍼는 「매주 화요일과 금요일 오전 8시」처럼 자연어로 간격을 말하면 돼요. GitHub 방식이라면 크론 잡을 짜고, 인증 유지 문제를 다루고, 실패 복구까지 직접 챙겨야 하죠.
5단계: 실행 — 거래 기회를 필터링하고 아웃리치 워크플로에 연결하기
여기서 데이터가 의사결정으로 바뀌어요.
- 투자자용: 30일 내 5% 이상 가격 하락, 시장 체류 90일 초과, Zestimate보다 낮은 가격을 필터링
- 중개인용: 구매자 기준에 맞는 새 매물, 만료·철회된 매물을 잠재 고객 발굴용으로 표시
- 연구자용: 평방피트당 가격 추세, 실제 매각가 대비 매물가 비율, 재고 회전 속도 계산
실제 사례: 3개 우편번호에서 200개 매물을 추적하는 투자자
사용 사례별로 데이터 필드가 이렇게 매핑돼요.
| 데이터 필드 | 투자 | 중개인 리드 | 시장 조사 |
|---|---|---|---|
| 가격 | ✅ 핵심 | ✅ | ✅ |
| Zestimate | ✅ 핵심(격차 분석) | ✅ | |
| 가격 이력 | ✅ 핵심(추세 감지) | ✅ | |
| 시장 체류 일수 | ✅ 핵심(동기 신호) | ✅ | ✅ |
| 세금 평가액 | ✅(가치 교차 검증) | ✅ | |
| 매물 상태 | ✅ | ✅ 핵심 | ✅ |
| 등록일 | ✅ | ✅ | |
| 에이전트 이름/전화번호 | ✅ 핵심 | ||
| 평방피트당 가격 | ✅ | ✅ 핵심 | |
| 실제 매각가 대비 매물가 | ✅ 핵심 |
투자자는 우편번호 3개를 매주 스크래핑하도록 걸어두고, Google Sheets로 내보낸 뒤, 가격 하락과 체류 일수 이상치를 조건부 서식으로 띄워요. 중개인은 Airtable로 내보내 잠재 고객 파이프라인을 짜고, 연구자는 스프레드시트에서 추세를 분석하고요. 스크래핑 단계는 똑같은데, 워크플로는 셋으로 갈려요.
Zillow 스크래핑의 법적·윤리적 고려사항
짧지만 빼면 안 되는 부분이에요.
Zillow의 이용약관은 스크린 스크래핑, 크롤러, 스파이더, CAPTCHA 유사 보호 우회를 포함한 자동 조회를 대놓고 금지해요. Zillow의 robots.txt도 /api/, /homes/, 쿼리 상태 URL 같은 넓은 경로를 막아두고요.
그렇다고 미국 웹 스크래핑 법을 「스크래핑은 다 불법」으로 뭉뚱그릴 순 없어요. 공개 데이터 스크래핑에선 hiQ 대 LinkedIn 계열 판례가 CFAA 측면에서 중요해요. Haynes Boone의 2026년 4월 최신 요약은 제9순회법원이 공개 회원 프로필 스크래핑을 막으려는 LinkedIn의 시도를 또 기각했다고 설명해요. 그렇다고 그게 별도의 계약, 개인정보, 우회 금지 논리를 지워주는 건 아니고, Zillow의 ToS를 무의미하게 만들지도 않아요. 한국이라면 개인정보보호법(PIPA)까지 함께 봐야 하고요.
정리하면 이래요.
- 공개 페이지 스크래핑은 사이트 소유자가 말하는 것보다 CFAA 측면에서 더 강한 논리를 가질 수 있어요
- 하지만 Zillow는 여전히 계약상 이를 금지해요
- 기술적 장벽(CAPTCHA, 속도 제한)을 우회하면 법적 위험이 더 커져요
- 상업적이거나 대규모 사용이라면 법률 자문을 받으세요
- 법적 환경과 무관하게, 스크래핑은 책임감 있게: 속도 제한을 존중하고, 서버를 과부하 주지 말고, 개인정보를 스팸에 쓰지 마세요
Zillow 워크플로에 맞는 도구 고르기
2026년 Zillow 스크래퍼 GitHub 환경은 겉보기보다 훨씬 얕아요. 눈에 띄는 저장소 대부분은 낡았거나, 약하거나, 죽었어요. 새 저장소 일부, 특히 pyzill은 아직 돌아가지만, 프록시와 봇 방지 유지보수가 계속 따라붙어요.
진짜 선택은 오픈소스냐 폐쇄형이냐가 아니에요. 통제권이냐 운영 부담이냐의 문제예요.
- 완전한 통제권을 원하고 스크래퍼 손보는 게 즐겁다면 GitHub 저장소는 강력해요. 단, 프록시 관리, 셀렉터 업데이트, 상태 점검에 쓸 시간을 따로 빼두세요.
- 오늘 바로, 유지보수 없이 믿을 만한 데이터가 필요하다면 Thunderbit의 Zillow 템플릿으로 검색 결과에서 스프레드시트까지 몇 분이면 가요. AI가 매번 페이지 구조를 새로 읽으니까, 잘 깨지는 하드코딩 셀렉터에 안 매여요.
둘 다 정당한 선택이에요.
최악은 따로 있어요. GitHub 스크래퍼를 몇 시간 들여 세팅해놨더니, 알고 보니 지난달에 이미 깨졌고 아무도 README를 안 고쳐놨더라는 상황이죠.
노코드 경로를 직접 보고 싶으면 Thunderbit 무료 플랜을 써보세요. 클릭 두 번이면 Zillow 매물을 긁어, 팀이 이미 쓰는 플랫폼으로 내보낼 수 있어요. 과정부터 보고 싶으면 Thunderbit YouTube 채널에 안내 영상이 있고요.
Zillow 스크래핑용 Thunderbit 체험하기 Get Started Free
자주 묻는 질문
2026년에 GitHub에서 작동하는 Zillow 스크래퍼가 있나요?
몇몇 저장소는 부분적으로 돌아가요. 특히 johnbalvin/pyzill은 아직 데이터를 돌려주지만, 회전형 주거용 프록시와 꾸준한 조정이 필요해요. 별이 가장 많은 저장소들(별 170개 ChrisMuir/Zillow, 별 152개 scrapehero/zillow_real_estate 포함)은 Zillow의 봇 방지 변화와 DOM 업데이트 탓에 대부분 죽었어요. 현재 상태는 위의 감사 표를 보세요.
Zillow가 GitHub 스크래퍼를 감지하고 차단할 수 있나요?
네. Zillow는 IP 차단, TLS 지문 인식, JavaScript 챌린지, CAPTCHA, 속도 제한을 다 써요. 테스트에선 Chrome처럼 꾸민 헤더를 단 단순 HTTP 요청조차 CloudFront에서 403을 받았어요. 제대로 된 회피 조치 없이 — 주거용 프록시, 현실적인 헤더, 브라우저 렌더링 없이 — GitHub 스크래퍼를 돌리면 보통 요청 100번 안에 막혀요.
Zillow에서 어떤 데이터를 스크래핑할 수 있나요?
흔한 필드는 가격, 주소, 침실 수, 욕실 수, 평방피트, Zestimate, 매물 상태, 시장 체류 일수, 매물 URL, 에이전트 연락처예요. 상세 페이지 스크래핑을 쓰면 가격 이력, 세금 기록, 토지 면적, HOA 회비, 학교 평점도 얻어요. 정확한 필드는 스크래퍼 성능과, 검색 결과를 보느냐 개별 매물 페이지를 보느냐에 따라 달라져요.
Zillow 스크래핑은 합법인가요?
단순하지 않아요. 공개 데이터 스크래핑은 hiQ 대 LinkedIn 계열 판례 이후 법적 근거가 더 단단해졌지만, Zillow 이용약관은 자동 접근을 대놓고 금지해요. CAPTCHA나 속도 제한 같은 기술적 장벽을 우회하면 법적 위험이 더 붙고요. 개인 연구 목적이면 위험이 대체로 낮아요. 상업적이거나 대규모 사용이라면 법률 전문가와 상의하세요. 어느 경우든 책임감 있게 스크래핑하세요.
Thunderbit은 어떻게 Zillow를 깨지지 않게 스크래핑하나요?
Thunderbit은 실행할 때마다 AI로 페이지 구조를 새로 읽어요. Zillow가 프런트엔드를 바꿀 때 깨지는 하드코딩 CSS 셀렉터나 XPath에 안 기대요. 또 한 번 클릭으로 뽑아주는 사전 제작 Zillow 즉시 스크래퍼 템플릿도 있어요. 클라우드 스크래핑은 회전형 인프라로 봇 방지를 자동 처리하니까, 사용자가 프록시를 깔거나 브라우저 렌더링을 직접 관리할 필요가 없어요. Zillow가 레이아웃을 바꾸면 AI가 적응해요. 저장소 업데이트는 필요 없고요.
더 알아보기
