Design Zillow 대규모 부동산 및 매물 관리 - '시공간 인덱싱'과 '실시간 동기화'

단순한 부동산 게시판을 넘어, Geospatial 인덱싱(S2/H3)부터 대규모 팬아웃(Fan-out) 알림과 로컬 우선(Local-first) 아키텍처까지.

Zillow 는 “거대한 글로벌 시공간(Geospatial) 인덱싱 엔진이자, 실시간 데이터 정합성 보장 플랫폼”에 가깝습니다. 사용자가 지도상에서 화면을 이리저리 이동할 때마다, 시스템은 수천만 개의 부동산 데이터 중 해당 화면 좌표 내에 존재하는 매물을 수십 밀리초(ms) 이내에 찾아내 렌더링해야 합니다.

“위도/경도 기반의 대규모 공간 데이터를 RDB가 아닌 어떤 인덱싱 알고리즘(Quadtree, Uber H3)으로 관리해야 검색 병목이 없을지”

“동일한 매물에 대해 수만 명의 사용자가 보고 있는 상황에서, 집값 변동이나 계약 완료 상태를 어떻게 데이터 유실 없이 실시간으로 전파할 것인가?”

“질로우의 가치 예측 모델(Zestimate)이 백엔드 파이프라인과 어떻게 결합하여 실시간 가격 변동 이력을 관리할 것인가?”

Zillow 같은 대규모 부동산 서비스 설계는 “공간 데이터 처리(Geospatial Query)”와 “대규모 읽기 최적화(Read-Heavy System)” 역량을 훈련하기 좋은 문제이기에 이 컨텐츠를 제작했습니다.

• 질로우의 ‘시공간(Geospatial) 매물 검색 아키텍처’를 데이터베이스로 어떻게 모델링할까?

• 사용자가 지도를 드래그하고 확대, 축소할 때 발생하는 수만 QPS의 지도 기반 쿼리 병목을 어떻게 해결할까?

• 매물 가격 변동이나 상태 변화(판매 중 → 계약 완료) 정보를 수백만 명의 관심 사용자에게 어떻게 실시간 알림으로 유실 없이 전파할까?

• 집 한 채당 수십 장씩 존재하는 고화질 부동산 이미지와 메타데이터를 글로벌 사용자에게 최저 지연 시간(Low Latency)으로 서빙하는 구조는 무엇일까?

• Zillow 의 자체 자산 가치 평가 엔진(Zestimate)의 대량 배치/스트리밍 연산 결과를 실시간 서비스 레이어에 어떻게 안정적으로 반영할까?

---

Functional Requirements - 기능적 요구사항

• 사용자는 화면 지도 상의 경계 상자(Bounding Box, 위도와 경도 범위) 내에 있는 매물을 검색하고, 가격, 방 개수, 매물 종류 등으로 필터링할 수 있어야 합니다.

• 매물의 고화질 사진 리스트, 가치 변동 이력(Zestimate History), 주변 학군 및 편의시설 등의 상세 데이터를 제공해야 합니다.

• 중개인이나 집주인이 새로운 매물을 등록하거나, 가격 변경, 매각 완료 등 매물의 상태를 실시간으로 업데이트할 수 있어야 합니다.

• 사용자가 특정 지역이나 필터 조건을 저장하면, 해당 조건에 맞는 새로운 매물이 등록되거나 가격이 변동되었을 때 실시간 푸시 알림 및 이메일을 발송해야 합니다.

Non-Functional Requirements - 비기능적 요구사항

• Low Latency (Read-Heavy)

  • 사용자가 지도를 이동하거나 확대/축소할 때 매물 마커가 화면에 렌더링되는 시간은 수백 밀리초(ms) 이내여야 합니다. (Read와 Write의 비율이 100:1 이상인 Read-Heavy 시스템)

• High Availability 및 확장성 (Scalability)

  • 특정 핫플레이스 지역이나 출퇴근 시간대에 트래픽이 폭발하더라도 시스템이 중단 없이 매끄럽게 동작해야 합니다.

• Consistency

  • 집값 변동이나 매물 상태(판매 중 또는 계약 완료)가 너무 오랫동안 구버전으로 캐시에 남아있어 허위 매물로 노출되는 상황을 최소화해야 합니다. (Eventual Consistency 최종 일관성 보장 및 적절한 Cache Invalidation 전략 필요)

Scope 정리

In Scope

• 시공간 데이터 모델링 및 지오 인덱싱(Geospatial Indexing) 구조 설계

• 지도 경계면(Bounding Box) 내 대규모 매물 검색 최적화 및 필터링 파이프라인

• Read-Heavy 트래픽 처리를 위한 다층 캐시(Multi-level Cache) 및 CDN 아키텍처

• 실시간 매물 상태 변동 전파 및 대규모 알림 팬아웃(Fan-out) 시스템

Out of Scope

• 3D 가상 투어(Virtual Tour) 영상 스트리밍 처리 기술의 상세 구현

• 부동산 중개인과의 실시간 채팅/통화 연결 시스템 내부 상세

• 매물 계약 진행 시 필요한 금융 및 전자결제/대출(Mortgage) 심사 시스템

가정하는 규모

• DAU (Daily Active Users)

  • 3,000만 명

• Concurrent Users (Peak)

  • 500만 명

• Total Registered Properties (총 매물 수): 1억 5,000만 건 (미국 전체 주택 기준 가정)

• Peak QPS

  • Page & Map Read (조회/검색)

    • 수만 ~ 수십만 QPS (사용자의 지도 이동 및 필터 조작이 매우 잦음)

  • Property Write/Update (등록/수정)

    • 수천 QPS (상대적으로 Read에 비해 빈도가 낮음)

• Latency

  • 지도를 조작할 때 지도 내 매물 마커 응답 속도 < 200ms

  • 상세 페이지 조회 < 100ms.

---

Core Entities

accounts (사용자 및 중개인)

서비스를 이용하는 일반 구매자(Buyer) 및 매물을 등록, 관리하는 부동산 중개인(Agent)의 계정 정보입니다. 실시간 채팅이나 금융 대출 심사 등 Out of Scope 영역의 복잡한 데이터는 철저히 제외하고, 시스템 인증 및 매물 수정 권한 검증에 필요한 최소한의 프로필만 유지합니다.

• id: UUID (글로벌 식별자)

• role: BUYER, AGENT 등의 권한 구분

• agent_license_number: 중개인인 경우 공인 자격증 번호 (일반 유저는 Null)

properties

미국 전역의 모든 주택 정보를 담고 있으며, 지리적 조회 성능을 위해 공간 데이터 인덱싱이 적용되는 테이블입니다. 중개인이 매물을 등록하고 상태를 실시간 업데이트할 수 있도록 담당자 ID 권한 필드가 포함됩니다.

• id: BIGSERIAL / UUID (분산 환경 식별자)

• region_shard_id: 지리적 거리를 기준으로 분산 샤딩(Sharding)을 하기 위한 파티션 키 (예: 주(State) 단위)

• agent_id: 이 매물을 등록하고 관리하는 중개인의 고유 ID (accounts.id 참조). 매물 상태 및 가격 업데이트 시 권한 검증의 기준이 됩니다.

• status: 현재 매물 상태 (FOR_SALE, FOR_RENT, PENDING, SOLD)

• price: 현재 리스팅 가격 (또는 최종 거래 가격)

• specifications: JSONB 형태의 페이로드 (침실 수, 욕실 수, 평방피트 면적, 건축 연도 등 유연한 스펙 확장 및 다중 필터링용)

• coordinate: GEOMETRY(Point, 4326) 위도와 경도를 하나로 묶은 시공간 데이터 (GIST 인덱스 적용)

• address_search_vector: 주소 텍스트 고속 검색을 위한 Full-text Search 벡터 데이터

• version: 데이터 정합성 유지를 위한 낙관적 락(Optimistic Locking) 버전 번호

property_media - 매물 미디어 데이터

요구사항인 “고화질 사진 리스트”를 충족하기 위한 테이블입니다. Out of Scope인 3D 가상 투어 실시간 스트리밍 인프라는 철저히 배제하고, 오직 이미지와 일반 소개 영상의 정적 스토리지 경로만 관리합니다. properties와 1:N 관계를 가집니다.

• id: BIGSERIAL

• property_id: 해당 매물의 외래키(FK)

• media_type: IMAGE, VIDEO (3D 가상 투어 스트리밍 데이터 유형은 원천 제외)

• url: S3 및 CDN(CloudFront)을 가리키는 원본 및 해상도별 썸네일 경로

• sort_order: 사용자가 상세 페이지를 열었을 때 보여줄 사진 우선순위 번호

valuation_histories - Zestimate & 가격 시계열 테이블

질로우의 비즈니스 가치인 ‘Zestimate(AI 예측 가치)’와 ‘과거 리스팅 가격 변동 추이’를 기록하는 시계열(Time-series) 데이터입니다. 수정(Update)이 발생하지 않고 시간 순서대로 삽입(Append-only)만 일어납니다.

• id: BIGSERIAL

• property_id: 해당 매물의 외래키(FK)

• event_type: LISTED (최초 등록), PRICE_DROPPED (가격 인하), ZESTIMATE_UPDATED (AI 가치 예측치 갱신), SOLD (매매 완료)

• amount: 해당 이벤트 시점의 금액/가치

• timestamp: 기록된 날짜 및 시간

saved_searches / alerts - 사용자 관심 지역 및 알림 조건

사용자가 지도상에서 특정 영역을 지정하고 필터를 걸어 “이 조건의 매물이 새로 나오면 알림을 줘”라고 저장한 데이터입니다. 대규모 푸시 및 이메일 알림 시스템의 트리거 기준이 됩니다.

• id: UUID

• user_id: 알림을 받을 사용자의 ID (accounts.id 참조)

• bounding_box: GEOMETRY(Polygon, 4326) 사용자가 지정한 지도상의 사각형/다각형 영역 정보

• filter_conditions: JSONB 형태 (예: “방 3개 이상, 50만 달러 이하”)

• last_notified_at: 마지막으로 푸시/이메일 알림이 발송된 시점

참고: 요구사항에 포함된 “주변 학군 및 편의시설 데이터”는 코어 DB의 비대화를 막기 위해 공공 데이터 외부 API(3rd Party)를 통해 지도 화면에서 실시간으로 매시업(Mash-up)하여 서빙하므로, 본 엔티티 설계에서는 영속성 테이블을 별도로 두지 않고 배제합니다.

---

API Signatures

Zillow 같은 부동산 플랫폼은 단순히 “집 목록을 보여주는 웹사이트”가 아닙니다. 겉으로는 사용자가 지도를 움직이면 매물이 뜨고, 가격이 바뀌면 알림이 오고, 관심 매물을 저장하는 서비스처럼 보입니다. 하지만 시스템 내부로 들어가면 완전히 다른 문제가 나옵니다. Zillow의 본질은 대규모 시공간 데이터 플랫폼입니다.

여기서 시공간 데이터란 단순히 위도와 경도만 의미하지 않습니다. 매물은 공간 위에 존재합니다. 동시에 시간에 따라 가격이 바뀌고, 판매 상태가 바뀌고, 사용자의 관심 조건도 계속 변합니다. 즉, Zillow는 아래 세 가지를 동시에 해결해야 합니다.