PropTech 팀들은 자신들의 데이터 요구사항을 마치 평가액, 임대료, 주택담보대출 금리가 하나의 표에 속한 세 개의 열인 것처럼 “부동산 데이터”라고 뭉뚱그려 표현하는 경향이 있다. 이것들은 사실 세 가지 서로 다른 문제다. 출처가 다르고, 라이선스와 프라이버시 제약이 다르며, 무엇보다 의미하는 바가 다르다.
이것들을 하나의 데이터셋으로 취급할 때 발생하는 실패는 수집 단계의 실패가 아니다. 라벨링의 실패이며, 사용자가 여러분의 제품이 사실로 제시한 숫자에 이의를 제기하는 훨씬 나중 시점에서야 드러난다.
세 가지 데이터 유형, 세 가지 수집 현실
수집기를 작성하기 전에, 실제로 무엇을 획득하려는 것인지 명확히 해야 한다. 그 답이 방법과 주장할 수 있는 내용 모두를 결정하기 때문이다.
| 데이터 유형 | 권위 있는 출처 | 웹에서 얻을 수 있는 것 | 아닌 것 |
|---|---|---|---|
| 거래 가격 | 공적 기록: 토지대장, 등기부, 사정평가 명부 | 매매가, 이전일, 필지 속성 | 현재 시장 가치가 아님 |
| 사정 평가액 | 세무 사정평가 명부 | 과세를 위한 평가 | 시장 평가가 아님 |
| 포털 추정치 | 포털 자체 모델 | 독자적 모델의 출력값 | 감정이 아니며, 사실도 아님 |
| 호가 임대료 | 활성 매물 | 임대인이 오늘 요구하는 금액 | 임차인이 실제 지불하는 금액이 아님 |
| 성사 임대료 | 라이선스 데이터셋, 운영업체 데이터 | 공개되는 경우가 드묾 | 매물에서 도출할 수 없음 |
| 주택담보대출 금리 | 대출기관 금리 페이지, 공식 통계 시리즈 | 상품 및 등급별 공시 금리 | 특정 대출자가 실제로 받은 금리가 아님 |
PropTech 데이터에서 가장 유용한 원칙은 “관측됨”, “사정됨”, “호가됨”, “추정됨”을 별도의 열에 유지하고, 이것들이 value라는 하나의 필드로 뭉뚱그려지지 않도록 하는 것이다.
원래 사용되어야 할 출처부터 시작하라
다음 순서대로 작업하며, 상위 단계가 실제로 다루지 못하는 부분에 대해서만 하위 단계에 도달해야 한다.
공식 및 대량 출처를 먼저 사용한다. 토지대장, 사정평가 사무소, 통계기관은 종종 대량 파일이나 API를 공개한다. 이것들은 권위가 있고, 사용이 허용되며, 외부에서 재구성할 수 없는 이력을 담고 있다. 거래 가격과 필지 속성에 대해서는 이것으로 대부분 해결된다.
라이선스 피드를 두 번째로 사용한다. 중개업체 및 다중 매물 데이터는 일반적으로 라이선스 하에 이용 가능하다. 제품에 완전한 매물 커버리지와 신뢰할 수 있는 필드가 필요한 경우, 라이선스를 취득하는 것이 대안의 엔지니어링 및 법적 리스크보다 저렴하다.
공개 웹 관측은 마지막에, 앞의 두 가지가 제공하지 못하는 것들, 즉 호가 임대료와 그 혜택 조건, 실시간 재고, 공시된 대출기관 금리표, 그리고 이것들이 시장별로 어떻게 다른지를 위해 사용한다.
바로 마지막 단계로 건너뛰는 것이 이 범주에서 가장 흔하고 가장 값비싼 실수다. 매물 관련 작업은 부동산 데이터 수집을 위한 프록시에서 다룬다.
평가액: 모델을 측정값으로 제시하지 말 것
포털 추정치는 볼 수 없는 데이터로 학습된 모델의 출력값이며, 포털이 공개할 수도 있고 안 할 수도 있는 오차 분포를 가진다. 이것은 여러분 자신의 모델에서 하나의 특성으로는 유용하지만, 그 자체로 평가액은 아니다.
세 가지 규칙을 지키면 방어 가능한 상태를 유지할 수 있다. 추정치는 출처와 관측된 날짜와 함께 저장하고, 결코 단순한 숫자로 저장하지 않는다. 재라벨링하지 않는다: 추정치는 추정치일 뿐 “시장 가치”가 아니다. 그리고 여러분의 제품이 자체 평가액을 산출한다면, 함께 신뢰구간을 공개해야 한다. 신뢰구간 없이 제시된 점 추정치는 여러분이 갖고 있지 않은 정밀도로 읽히기 때문이다.
공식적인 평가에 근접한 것이라면, 수집된 데이터는 전문적인 절차의 입력값이지, 그것을 대체하는 것이 아니다.
임대료: 호가는 성사가 아니며, 혜택 조건은 텍스트 안에 있다
매물의 임대료는 호가 임대료다. 약세 시장에서는 임차인이 실제로 지불하는 금액보다 높게 나타나며, 그 격차는 혜택 조건에 존재한다. 즉 한 달 무료, 수수료 면제, 주차 공간 포함, 다른 가격의 단기 계약 등이다.
이러한 혜택 조건은 대개 구조화된 필드가 아니라 자유 텍스트 설명 안에 있다. 즉 임대료 필드만으로 구축한 호가 임대료 시리즈는 사람들이 가장 측정하고 싶어 하는 바로 그 조건에서 체계적으로 잘못될 수밖에 없다. 설명을 파싱하여 혜택 조건 관련 언어를 찾고, 이를 별도의 필드로 저장하라. 플래그와 원문 문장만 추출할 수 있더라도 마찬가지다.
두 가지 실무 사항이 더 있다. 비교 가능한 단위로 정규화하라. 보통 기간당, 침실 수당 또는 바닥 면적당 임대료가 그것이다. 혼합된 유닛 유형에 대한 중앙값은 시장만큼이나 유닛 구성 자체를 측정하는 것이기 때문이다. 그리고 유닛 단위 관측과 건물 단위 관측을 분리해서 유지하라. 하나의 유닛을 매물로 내놓은 건물이 그 가격으로 임대되는 건물을 의미하지는 않는다.
주택담보대출 데이터: 금리는 숫자가 아니라 행렬이다
공시된 대출기관 금리는 상품, 기간, 담보인정비율(LTV) 구간, 대출자 등급, 지역, 때로는 채널에 따라 달라진다. 대출기관 페이지에서 “그 금리”를 저장하는 스크레이퍼는 행렬의 셀 하나만 포착하고 축은 버린 것이다.
상품, 기간, LTV 구간, 명시된 대출자 조건, 포인트나 수수료, 그 수치가 명목 금리인지 APR인지, 대출기관이 명시한 발효일, 그리고 여러분이 관측한 날짜를 기록하라. 명목 금리와 APR의 구분이 하류에서 가장 많은 혼란을 일으키는 지점이다. 둘은 비교 가능하지 않은데도 같은 페이지에 함께 나타나기 때문이다.
중앙은행과 주택 관련 기관의 공식 통계 시리즈는 여러분의 수집을 검증할 근거가 되는 진실이다. 수집된 평균이 공시된 시리즈와 괴리될 때, 대개 변한 것은 수집 쪽이다.
타협할 수 없는 경계가 하나 있다: 공시된 금리와 조건은 수집하되, 결코 대출자 개인 단위 데이터는 수집하지 않는다. 개별 신청서, 신용 기록, 개인 재무 정보는 공개 웹 데이터가 아니며, PropTech 로드맵의 그 어떤 이유도 이를 정당화하지 않는다.
수집 계층
이러한 출처들의 두 가지 특성으로 인해 관측 지점이 방법의 일부가 된다.
대출기관 금리표와 포털 콘텐츠는 지역화되어 있어, 여러분이 보는 금리나 매물은 요청이 어디서 온 것으로 보이는지에 따라 달라진다. 그리고 특히 금리는 한 국가 내에서도 주(state)나 지역에 따라 다를 수 있어, 단일한 전국 단위 관측 지점은 소리 없이 한 지역의 금리를 시장 전체의 금리인 것처럼 보고하게 된다.
Shifter 게이트웨이를 사용하면, 관측 지점과 세션은 p.shifter.io:443에 대한 자격 증명 안에 들어간다:
customer-USERNAME-country-us-state-tx-sid-rates-tx-11-ttl-600:PASSWORDcountry-us와 state-tx는 요청을 여러분이 읽으려는 금리의 시장에 위치시키고, sid-rates-tx-11은 전체 금리표 순회 동안 하나의 exit을 유지시켜 스냅샷의 모든 셀이 하나의 세션에서 나오도록 하며, ttl-600은 그 주소를 10분간 유지한다. ttl은 sid와 함께일 때만 의미가 있다. 세션 식별자가 없으면 게이트웨이는 요청마다 회전하는데, 이는 독립적인 조회에는 맞지만 페이지네이션된 표에는 맞지 않다. 이 트레이드오프는 고정형 대 로테이팅 레지덴셜 프록시에 설명되어 있다.
정확한 지역 일치가 응답을 받는 것보다 더 중요할 때는 strict-true를 추가하라. 그러면 게이트웨이는 인근 지역을 조용히 제공하는 대신 502를 반환한다.
수집 주기는 각 시리즈가 실제로 움직이는 속도를 따라야 한다. 대출기관 금리는 일일 수집, 때로는 하루 중 여러 번의 수집을 정당화한다. 매물과 호가 임대료는 일일 단위다. 공적 기록은 자체 일정에 따라 갱신되며, 흔히 주간 또는 월간이므로, 이를 공시 속도보다 빠르게 수집하면 중복 행만 생성된다. 속도 제한과 요청 스로틀링에서 설명하는 것처럼 요청 비율을 실제 백오프와 함께 정상적으로 유지하라.
정직함을 유지시켜주는 스키마
모든 레코드는 숫자 자체와 함께 다음을 담아야 한다: 위 표에서의 관측 유형, 출처, 출처가 명시하는 발효일, 여러분이 관측한 날짜, 시장, 관측한 exit 위치, 그리고 신뢰도 또는 검증 플래그.
발효일과 관측일은 서로 다른 필드이며, 이 둘을 혼동하는 것은 실제로 발생하는 버그다. 지난 화요일에 발효된 대출기관 금리표를 오늘 수집하면, 그것은 화요일 금리다. 관측일 기준으로 구축된 지수는 여러분의 크롤러가 늦었을 때 발생하지 않은 변동을 보여줄 것이다.
관측이 어디서 언제 이루어졌는지를 기록하는 것에 대한 일반적인 논거는 관측 지점 표준을 위한 근거에 있다.
프라이버시와 컴플라이언스
부동산 데이터는 대부분의 상업용 웹 데이터보다 개인에 더 가까이 위치하며, 규칙은 관할권에 따라 크게 다르다.
일부 국가의 공적 기록은 소유주 이름을 명시하지만, 다른 국가에서는 그 정보가 제한된다. 소유주 이름, 연락처, 거주자를 식별할 수 있는 모든 것을 기본적으로 개인 데이터로 취급하고, 근거가 있는 경우에만 수집하며, 제품에 필요하지 않은 경우 수집 시점에 제거하라. 임대료 지수에는 임차인의 이름이 필요하지 않다.
각 출처의 이용약관을 준수하고, 볼륨을 비례적으로 유지하며, 라이선스가 의도된 경로일 경우 라이선스를 취득하라. 일반적인 틀은 레지덴셜 프록시와 GDPR 준수 및 AI 데이터 수집을 위한 윤리적 레지덴셜 프록시에 있다.
FAQ
제 제품에서 포털 추정치를 평가액으로 사용해도 되나요?
평가액으로는 안 된다. 특성으로서, 또는 명확히 출처가 표시된 제3자 추정치로서는 포털의 이용약관을 조건으로 가능하다. 라벨링이 중요한 부분이다.
호가 임대료가 아닌 성사 임대료는 어떻게 얻나요?
일반적으로 라이선스 데이터셋이나 운영업체 파트너십을 통해서다. 매물에는 이것이 포함되어 있지 않으며, 호가 임대료로부터 이를 추론하는 것은 모델링이므로 그렇게 명시되어야 한다.
대량 파일이 존재한다면 공적 기록을 스크레이핑할 필요가 있나요?
아니다. 대량 파일이 더 낫다: 권위가 있고, 완전하며, 허용된다. 웹은 대량으로 공개되지 않은 것에 대해서만 사용하라.
우리의 주택담보대출 금리가 공시된 전국 평균과 왜 다른가요?
대개 하나의 지역, 하나의 LTV 구간, 또는 하나의 대출자 등급만 수집하여 대표성 없는 조합에 대해 평균을 낸 것이 원인이다. 축을 기록하면 그 불일치는 대개 스스로 설명된다.
결론
평가액, 임대료, 주택담보대출 금리는 어휘만 공유할 뿐 그 외에는 공통점이 없는 세 가지 수집 문제다. 신뢰할 수 있는 PropTech 데이터를 구축하는 팀은 먼저 공식 출처와 라이선스 출처로 가고, 나머지를 위해 공개 웹을 사용하며, 관측됨, 사정됨, 호가됨, 추정됨을 발효일과 관측일 모두를 가진 별도의 라벨링된 필드로 유지한다.
각 시장을 그 시장으로부터 수집하고, 표 전체나 결과 집합에 걸쳐 세션을 일관되게 유지하며, 모델 출력값을 사실로 저장하지 마라. 이러한 관측치를 실시간 시장 시리즈로 전환하는 방법은 실시간 주택 시장 데이터 피드 구축에서 다룬다. 제품 관점은 데이터 수집을 위한 레지덴셜 프록시 페이지에, 요금은 요금 페이지에 있다.