Zillow 스크래퍼 GitHub: 2026년에 작동하는 것과 망가지는 것

지금 "zillow scraper github"를 검색하면 가 나와요. 꽤 가능성 있어 보이죠. 그런데 는 1년 넘게 업데이트되지 않았다는 걸 알게 되면 얘기가 달라져요.

저는 이 저장소들을 오래 살펴보고, 실제 Zillow 페이지에서도 테스트해 봤고, 개발자들이 이번엔 뭐가 또 망가졌는지 한탄하는 GitHub 이슈와 Reddit 스레드도 꼼꼼히 읽어봤어요. 패턴은 늘 비슷해요. 처음엔 잘 돌아가서 별점을 많이 받다가, Zillow가 DOM을 바꾸고 봇 방지 장치를 강화하거나 내부 API 엔드포인트를 폐기하면 조용히 무너져요. Reddit의 한 답답한 개발자는 이렇게 정리했어요. “스크래핑 프로젝트는 페이지나 API가 바뀔 때마다 계속 유지보수해야 해요.” 이 글은 제가 처음 Zillow 스크래퍼 저장소를 클론하기 전에 미리 읽었으면 좋았을 리뷰예요. 2026년 기준으로 실제로 무엇이 돌아가고, 무엇이 왜 깨지는지, 그리고 GitHub의 복잡한 탐색을 건너뛰고 같은 도구를 쓰는 편이 언제 더 합리적인지 솔직하게 정리했어요.

Zillow 스크래퍼 GitHub 프로젝트란 무엇이고, 누가 필요할까요?

“Zillow 스크래퍼”는 Zillow 웹사이트에서 가격, 주소, 침실 수, 욕실 수, 평방피트, Zestimate, 매물 상태, 시장 체류 일수 같은 부동산 매물 데이터를 자동으로 수집하는 스크립트나 도구를 뜻해요. 때로는 가격 이력이나 세금 기록처럼 더 깊은 상세 페이지 데이터도 가져오죠. 사람들은 무료이고, 오픈소스이며, 원하는 대로 수정할 수 있다는 이유로 GitHub를 찾는 경우가 많아요. 저장소를 포크해서 필드를 조정하고, 결과를 자기 파이프라인에 연결하는 식이죠. 이론상으로는 정말 좋은 조합이에요.

사용자층도 꽤 뚜렷해요.

• 부동산 투자자는 우편번호 구역별로 기회를 찾기 위해 가격 하락, Zestimate 격차, 시장 체류 일수를 확인해요
• 중개인은 잠재 고객 리스트를 만들기 위해 매물 URL, 에이전트 연락처, 매물 상태 변화를 필요로 해요
• 시장 조사자와 분석가는 주소, 평방피트당 가격, 실제 매각가와 매물가, 재고 수를 구조화된 형태로 뽑아내요
• 운영팀은 일정 간격으로 시장 전반의 가격이나 재고를 모니터링해요

공통점은 하나예요. 모두가 일회성 복붙이 아니라 구조화되고 반복 가능한 데이터를 원한다는 점이에요. 그래서 스크래핑이 매력적이죠. 동시에 저장소가 멈췄을 때 유지보수 부담이 엄청 커지는 이유이기도 하고요.

2026 Zillow 스크래퍼 GitHub 저장소 감사: 실제로 아직 작동하는 것은?

저는 GitHub에서 가장 별점이 많고 가장 많이 포크된 Zillow 스크래퍼 저장소를 찾고, 마지막 커밋 날짜를 확인하고, 공개 이슈를 읽고, 실제 Zillow 페이지에서 직접 테스트해 봤어요. 기준은 단순해요. 2026년 4월 기준으로 Zillow 검색 결과나 상세 페이지에서 정확한 매물 데이터를 반환하면 “작동”으로 봐요. 실행은 되지만 데이터가 불완전하거나 몇 페이지 뒤에 차단되면 “부분 작동”. 아예 실패하거나 유지 관리자가 죽었다고 명시하면 “고장”이에요.

냉정한 현실은 이렇습니다. 12~18개월 전에는 유망해 보였던 저장소의 대부분이 조용히 망가졌어요.

선별 비교 표: 상위 Zillow 스크래퍼 GitHub 저장소

패턴은 분명해요. GitHub 생태계에는 아직 살아 있는 코드가 있긴 하지만, 눈에 잘 띄는 저장소의 대부분은 튜토리얼이거나, 역사적 흔적이거나, 프록시에 의존하는 워크플로의 얇은 래퍼에 불과해요.

“작동”, “고장”, “부분 작동”의 의미

이 라벨들은 별점보다 훨씬 중요하니까 정확히 짚고 갈게요.

• 작동: 테스트 시점 기준으로 Zillow 검색 페이지나 상세 페이지에서 정확한 매물 데이터를 성공적으로 반환하며, 유지 관리자가 프로젝트 종료를 알리지 않은 상태
• 부분 작동: 실행은 되지만 데이터가 불완전하거나, 몇 페이지 뒤 차단되거나, 특정 페이지 유형에서만 작동함 — 보통 프록시 인프라와 지속적인 조정이 필요함
• 고장: 데이터를 반환하지 못하거나 오류를 내거나, 유지 관리자 또는 커뮤니티가 명시적으로 비기능 상태라고 표시함

별점 170개에 “고장” 상태인 저장소가, 별점 10개지만 실제 데이터를 돌려주는 저장소보다 나을 이유는 없어요. 인기와 품질은 같은 말이 아니거든요.

Zillow 스크래퍼 GitHub 프로젝트가 깨지는 이유: 5가지 흔한 실패 모드

Zillow 스크래퍼가 왜 깨지는지 이해하면, 어떤 README보다 더 많은 시간을 아낄 수 있어요. 왜 깨지는지 알면, 더 견고한 스크래퍼를 만들거나 아니면 유지보수 비용이 감당할 만한 수준이 아닌지 판단할 수 있죠.

1. DOM 재구성(Zillow의 React 프런트엔드)

Zillow의 프런트엔드는 React 기반이고 변경이 잦아요. 클래스명, 컴포넌트 구조, 데이터 속성이 예고 없이 바뀌죠. 오늘 div.list-card-price를 타깃으로 하던 스크래퍼가 내일은 그 클래스가 사라진 걸 발견할 수 있어요. 에도 Zillow에서는 “페이지마다 클래스명이 다르다”라고 나와요.

결과는 이렇습니다. 스크립트는 돌아가는데 빈 필드만 반환하고, 일주일 동안 공란만 수집한 뒤에야 알아차리게 돼요.

2. 내부 API와 GraphQL 엔드포인트 변경

더 영리한 저장소들은 HTML을 아예 우회하고 Zillow의 내부 GraphQL 또는 REST API를 직접 호출해요. 예를 들어 는 Zillow의 내부 API를 사용하고, 결과 제한을 피하려고 지도 범위를 재귀적으로 나눠요. 꽤 똑똑한 설계지만, Zillow는 이런 엔드포인트를 주기적으로 재구성해요. 그러면 스크래퍼는 404를 내거나 오류 메시지 없이 빈 JSON만 돌려줘요.

이건 좀 더 미묘한 형태의 고장이에요. 코드는 멀쩡해요. 대상이 옮겨간 거죠.

3. 봇 방지 및 CAPTCHA 강화

Zillow는 봇 탐지를 계속 강화해 왔어요. 2026년 4월 제가 직접 테스트했을 때도, 일반 requests.get() 호출로 zillow.com과 zillow.com/homes/Chicago,-IL_rb/에 접속하면 이 돌아왔어요 — Chrome처럼 보이는 user-agent와 Accept-Language 헤더를 써도 마찬가지였죠. 커뮤니티 보고도 비슷해요. 한 사용자는 역공학한 API 흐름이 약 후에 403을 반환하기 시작했다고 했어요.

소규모에서는 잘 작동하던 스크래퍼가 규모를 키우면 갑자기 실패할 수 있어요. 우편번호 3개 구역에서 200개 매물을 추적하려는 상황이라면 꽤 난감하죠.

4. 프리미엄 데이터 주변의 로그인 장벽

Zestimate 세부 정보, 세금 기록, 일부 가격 이력 같은 특정 데이터는 인증 뒤에 숨겨져 있어요. 오픈소스 스크래퍼는 로그인 흐름을 처리하지 못하는 경우가 많아서 이런 필드는 비어 돌아와요. 가격 이력이나 세금 평가액이 핵심인 사용 사례라면 곧바로 이 장벽을 만나게 돼요.

5. 의존성 부패와 방치된 저장소

에는 No module named 'unicodecsv' 같은 설치 문제가 있어요. 는 드라이버와 GIS 의존성 수동 설치의 고통을 문서화해 놨어요. Python 라이브러리 업데이트는 호환성을 깨뜨려요. 6개월 넘게 업데이트되지 않은 저장소는 Zillow의 봇 방지 장치에 닿기도 전에 새 환경에서 설치 실패하는 경우가 많아요.

2026년 Zillow 봇 방지: 실제로 상대해야 하는 것

“프록시 돌리고 헤더만 바꾸면 돼요”는 2022년엔 어느 정도 맞는 조언이었어요. 2026년엔 아니에요.

IP 차단을 넘어: TLS 지문과 JS 챌린지

Zillow는 IP만 막지 않아요. 커뮤니티 보고에 따르면 Zillow는 Cloudflare 뒤에 있고, 단순한 속도 제한을 넘어서는 를 사용해요. TLS 지문 인식은 클라이언트의 “디지털 핸드셰이크”를 보고 비브라우저 클라이언트를 식별해요. 새 프록시를 써도 TLS 서명이 실제 Chrome 브라우저와 맞지 않으면 스크래퍼가 표시될 수 있어요.

JavaScript 챌린지도 또 하나의 장벽이에요. JS를 완전히 실행하지 않거나 자동화 흔적(navigator.webdriver = true 같은 것)을 노출하는 헤드리스 브라우저는 잡혀요.

검색 페이지 vs. 부동산 상세 페이지: 방어 수준이 다르다

모든 Zillow 페이지가 똑같이 보호되는 건 아니에요. 는 상세 페이지를 건너뛰는 “Fast Mode”와 더 풍부한 데이터를 포함하는 느린 “Full Mode”를 분명히 구분해요. Thunderbit의 도 초기 목록 수집과 상세 페이지를 풍부하게 만드는 “하위 페이지 스크래핑”을 따로 나눠서 설명해요.

실무적으로는 이렇습니다. 검색 결과에서는 잘 되다가, Zillow가 더 높은 가치를 가진 데이터를 더 자주 스크래핑하기 때문에 훨씬 강하게 보호하는 개별 매물 페이지에서는 실패할 수 있어요.

HTTP 전용을 고집하는 개발자들: 왜 브라우저 자동화를 피할까요?

Selenium, Playwright, Puppeteer 없이 HTTP만 쓰고 싶어 하는 개발자층이 꽤 있어요. 이유는 실용적이에요. 브라우저 자동화는 느리고, 자원을 많이 먹고, 대규모 배포도 더 어려워요.

솔직한 평가는 이렇습니다. 2026년에는 고급 헤더 관리와 지문 관리 없이 Zillow를 상대로 순수 HTTP 방식만 쓰는 게 점점 더 어려워지고 있어요. 커뮤니티의 증거는 Zillow 같은 대상에선 브라우저 렌더링이 예외가 아니라 표준이 되어 간다는 쪽을 가리켜요.

Zillow용 구체적인 차단 회피 베스트 프랙티스

직접 구축하려면, 실제로 도움이 되는 것과 그렇지 않은 것을 이렇게 구분할 수 있어요.

• 무작위화된 요청 속도 조절로 사람처럼 브라우징하기 — 고정 딜레이가 아니라 세션처럼 보이는 가변 간격 사용
• 현실적인 헤더 구성 — Accept-Language, Sec-CH-UA 계열 헤더, 올바른 referer 체인 포함 — 하지만 현실적인 헤더는 필요조건이지 충분조건은 아니에요
• 세션 회전 — 같은 프록시/쿠키 조합을 수백 번 재사용하지 않기
• 브라우저 렌더링으로 전환할 시점 파악 — HTTP 전용 방식이 50번 요청 후 403을 내면, 이미 진 싸움이에요

2026년 Zillow를 해결해 주는 마법 같은 헤더 묶음 하나가 있다는 식의 글은 믿지 마세요.

은 이 모든 걸 자동으로 처리해요 — 미국/유럽/아시아 전반의 인프라를 회전시키고, 렌더링과 봇 방지를 관리해서 사용자가 프록시 설정의 미로를 아예 건너뛰게 해줘요. 핵심은 운영 부담이 어디에 놓이느냐예요.

Zillow 스크래퍼 GitHub 설정을 미래에도 버티게 만드는 베스트 프랙티스

GitHub/직접 구축 방식을 선택하는 독자를 위해, 몇 달은 버티는 스크래퍼와 며칠 만에 깨지는 스크래퍼를 가르는 관행을 정리해 볼게요.

취약한 클래스명에서 셀렉터를 분리하세요

저장소가 Zillow의 자동 생성 CSS 클래스명에 의존한다면, 그건 경고 신호로 봐야 해요. 그런 이름은 자주 바뀌고, 어떤 경우엔 매주 바뀌기도 해요. 대신:

• aria-label, data-* 속성 또는 근처 제목 텍스트를 기준으로 요소를 찾기
• 가능하면 텍스트 콘텐츠 기반 셀렉터 사용
• Zillow가 페이지 소스에 구조화된 데이터를 제공할 때는 HTML 파싱보다 JSON 우선 추출 선호

자동 상태 점검을 추가하세요

Zillow 스크래핑을 일회성 스크립트가 아니라 운영 모니터링처럼 다뤄야 해요. 크론 잡이나 GitHub Actions를 설정해서:

1. 매일 알려진 하나의 매물에 대해 스크래퍼 실행
2. 출력 스키마 검증(예상 필드가 모두 있고 비어 있지 않은지 확인)
3. 출력이 비정상적이거나 비어 있으면 알림 전송

이렇게 하면 고장을 몇 주가 아니라 24시간 안에 잡아낼 수 있어요.

의존성 버전을 고정하고 가상환경을 사용하세요

Python이나 Node 의존성은 항상 특정 버전으로 고정하세요. 가상환경이나 Docker 컨테이너를 사용하고요. 이번 감사에서 본 오래된 저장소들은 설치 부패가 얼마나 빨리 찾아오는지 잘 보여줘요. Zillow의 봇 방지 장치에 닿기도 전에, 먼저 깨지는 건 종종 의존성이에요.

스크래핑량은 보수적으로 유지하세요

그 가 절대적인 건 아니지만, 테스트에서는 멀쩡해 보이던 스크래퍼의 행동이 규모에 따라 달라질 수 있다는 신뢰할 만한 경고예요. 요청을 여러 세션에 분산하세요. 무작위 지연을 쓰세요. 한 번에 1만 개 매물을 긁으려 하지 마세요.

직접 구축이 그만한 가치가 없는 순간을 알아차리세요

스크래퍼 유지보수에 데이터 분석보다 더 많은 시간을 쓰고 있다면, 경제성이 이미 뒤집힌 거예요. 실패가 아니라 관리형 솔루션을 고려하라는 신호예요.

Zillow 스크래퍼 GitHub(DIY) vs. 노코드 도구: 솔직한 의사결정 매트릭스

“zillow scraper github”를 찾는 사람은 크게 두 부류로 나뉘어요. 코드를 소유하고 싶은 개발자, 그리고 그냥 스프레드시트에 데이터만 있으면 되는 부동산 실무자예요. 둘 다 타당해요. 실제 트레이드오프가 어떻게 갈리는지 보죠.

나란히 비교 표

프록시 비용의 현실 점검

프록시 비용을 넣는 순간 “무료 저장소”라는 주장은 설득력이 많이 떨어져요. 현재 공개된 주거용 프록시 가격은 이렇습니다.

저장소 자체는 무료일 수 있어도, 프록시를 붙인 Zillow 워크플로는 보통 무료가 아니에요.

GitHub 저장소를 선택해야 할 때

• 코드를 작성하고 유지보수하는 일을 즐길 때
• 아주 구체적인 커스터마이징이 필요할 때(맞춤 데이터 변환, 독자적인 파이프라인 연동)
• 고장 대응을 감당할 시간과 기술이 있을 때
• 프록시 인프라를 직접 관리할 의향이 있을 때

Thunderbit을 선택해야 할 때

• 설정이나 유지보수 없이 오늘 당장 신뢰할 수 있는 데이터가 필요할 때
• 개발자가 아니라 부동산 중개인, 투자자, 운영팀일 때
• 를 코드 작성 없이 하고 싶을 때
• 추가 설정 없이 하위 페이지 스크래핑으로 매물 데이터를 더 풍부하게 만들고 싶을 때
• 평이한 언어로 설명된 예약 스크래핑이 필요할 때

단계별: GitHub 없이 Thunderbit로 Zillow 스크래핑하는 방법

노코드 경로는 GitHub 설정 과정과는 전혀 달라요.

1단계: Thunderbit Chrome 확장 프로그램 설치하기

로 가서 Thunderbit을 설치하고 가입하세요. 무료 플랜이 있어요.

2단계: Zillow로 이동해 Thunderbit 열기

어떤 Zillow 검색 결과 페이지든 들어가 보세요 — 예를 들어 특정 우편번호의 매물 목록처럼요. 브라우저 툴바에서 Thunderbit 확장 프로그램 아이콘을 클릭하세요.

3단계: Zillow 즉시 스크래퍼 템플릿을 사용하거나 AI로 필드 제안받기

Thunderbit에는 이 있어요. 설정할 필요 없이 한 번만 클릭하면 돼요. 이 템플릿은 주소, 가격, 침실 수, 욕실 수, 평방피트, 에이전트 이름, 에이전트 전화번호, 매물 URL 같은 표준 필드를 다뤄요.

또는 “AI로 필드 제안”을 클릭하면 AI가 페이지를 읽고 열을 제안해 줘요. 제 경험상 Zestimate를 포함해 를 감지하는 경우가 많아요.

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개 매물을 추적하는 투자자

사용 사례별로 데이터 필드가 이렇게 매핑돼요.

투자자는 3개 우편번호를 대상으로 매주 스크래핑을 설정하고, Google Sheets로 내보낸 다음, 가격 하락과 체류 일수 이상치를 조건부 서식으로 표시해요. 중개인은 Airtable로 내보내 잠재 고객 파이프라인을 만들고, 연구자는 스프레드시트에서 추세 분석을 해요. 스크래핑 단계는 같지만, 워크플로는 세 가지예요.

Zillow 스크래핑의 법적·윤리적 고려사항

짧지만 꼭 필요한 부분이에요.

은 스크린 스크래핑, 크롤러, 스파이더, CAPTCHA 유사 보호 우회 등을 포함한 자동화된 조회를 명시적으로 금지해요. Zillow의 도 /api/, /homes/, 쿼리 상태 URL 같은 넓은 경로를 금지해요.

동시에 미국 웹 스크래핑 법은 “모든 스크래핑이 불법”으로 단순화할 수 없어요. 공개 데이터 스크래핑에서는 hiQ 대 LinkedIn 계열 판례가 CFAA 관련해서 중요해요. Haynes Boone의 은 제9순회법원이 공개 회원 프로필 스크래핑을 막으려는 LinkedIn의 시도를 다시 한 번 기각했다고 설명해요. 하지만 그게 별도의 계약, 개인정보, 우회 금지 논리를 없애 주는 건 아니고, Zillow의 ToS를 무의미하게 만드는 것도 아니에요.

즉, 이런 뜻이에요.

• 공개 페이지 스크래핑은 사이트 소유자들이 말하는 것보다 CFAA 측면에서 더 강한 논리를 가질 수 있어요
• 하지만 Zillow는 여전히 계약상 이를 금지해요
• 기술적 장벽(CAPTCHA, 속도 제한)을 우회하면 법적 위험이 더 커져요
• 상업적이거나 대규모 사용 사례라면 법률 자문을 받으세요
• 법적 환경과 무관하게, 스크래핑은 책임감 있게 하세요: 속도 제한을 존중하고, 서버를 과부하시키지 말고, 개인정보를 스팸에 쓰지 마세요

Zillow 워크플로에 맞는 도구 고르기

2026년의 Zillow 스크래퍼 GitHub 환경은 겉보기보다 훨씬 얕아요. 눈에 띄는 저장소의 대부분은 낡았거나, 취약하거나, 고장났어요. 새로운 저장소 중 일부 — 특히 — 은 여전히 작동하지만, 지속적인 프록시와 봇 방지 유지보수가 필요해요.

진짜 선택은 오픈소스와 폐쇄형 소스의 대결이 아니에요. 통제권과 운영 부담의 문제예요.

• 완전한 통제권이 필요하고 스크래퍼 유지보수를 즐긴다면 GitHub 저장소는 강력해요 — 하지만 프록시 관리, 셀렉터 업데이트, 상태 점검에 시간을 배정하세요.
• 오늘 바로, 아무런 유지보수 없이 신뢰할 수 있는 데이터가 필요하다면 으로 검색 결과에서 스프레드시트까지 몇 분이면 갈 수 있어요. AI가 매번 페이지 구조를 새로 읽기 때문에, 깨지는 하드코딩 셀렉터에 의존하지 않아요.

둘 다 정당한 선택이에요.

가장 최악은 GitHub 스크래퍼를 몇 시간 동안 세팅해 놓고, 알고 보니 지난달에 이미 깨졌는데 아무도 README를 업데이트하지 않았다는 사실을 발견하는 거예요.

노코드 경로를 직접 보고 싶다면 을 써 보세요 — 약 2번의 클릭으로 Zillow 매물을 스크래핑하고, 팀이 이미 쓰고 있는 플랫폼으로 내보낼 수 있어요. 먼저 과정을 보고 싶다면 에 안내 영상이 있어요.

자주 묻는 질문

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가 레이아웃을 바꾸면 AI가 적응해요 — 저장소 업데이트가 필요 없어요.

더 알아보기