본문 바로가기

Projects/Property

프로젝트 회고 - 1. 데이터 수집 및 전처리 (1)

반응형

분석을 위한 데이터 수집을 하기 위해 어떤 정보가 있어야 하는지 고민해보니, 크게 2가지 데이터가 필요했다.

 

1. 거래 정보:  어떤 아파트가 언제, 얼마에 거래되었는지

 

2. 아파트 정보 : 아파트가 어떤 특성을 가지고 있는지

 

 

거래 정보

데이터 수집

거래 정보는 공공데이터포털 (https://www.data.go.kr/data/15057511/openapi.do) 에서 구할 수 있었다.

기간(월 단위) 및 지역 코드 별로 조회가 가능하며, 하루 API 요청 횟수는 1,000건이다.

대한민국에 존재하는 지역 코드는 총 458개이며, 분석 대상 기간은 총 75개월이므로, 약 34,000 이상의 API 요청이 필요했다.

팀원 별로 아이디를 5개 이상 생성해서 진행하여 시간을 줄일 수 있었다.

 

데이터 구성

 

데이터 크기는 (3366785,29) 이고, 행 단위는 아파트 거래이다.

 

데이터 전처리

1. 해제여부 체크

데이터 열 중에 해제여부 라는 열이 있는데, 해당 열은 거래가 취소되었는지 여부를 나타낸다. 그래서 해제여부가 체크된 행을 먼저 삭제해주었다. (97,035개의 행 삭제)

 

2. 아파트의 법정동 및 도로명 주소 생성

추후 아파트 정보 데이터와 결합하기 위해서는 공통 키가 필요하다. 아파트 명을 사용할 시 아파트명이 같거나, 혹은 실제로 같은 아파트지만 두 데이터 파일의 표기법이 다른 경우가 존재하는 문제점이 있다. 따라서 두 테이블을 병합할 때 아파트의 주소를 사용하기로 했다. 거래 데이터 파일에 주소명이 기재되어 있지는 않지만, 지역코드, 도로명코드, 법정동코드 등의 열을 활용하여 법정동주소 및 도로명주소를 생성하였다. 2가지 주소를 다 생성한 이유는, 한쪽이 결측치인 경우가 다수 존재했기 때문이다. 법정동 및 도로명 주소가 전부 결측치인 경우는 활용하기 어렵다고 생각하여 데이터에서 삭제하였다.

 

3. 거래를 (아파트, 분기, 전용면적구간) 으로 그룹화, 거래가격의 산술평균을 대표가격을 설정

기간을 분기로 정한 이유는, 아파트 거래 특성 상 거래가 자주 일어나지 않기 때문에 단위기간을 월 혹은 그보다 짧은 단위로 설정할 시 결측치가 지나치게 많아지기 때문이다. 사실 단위기간을 분기로 설정해도 결측치가 상당히 많았고, 이를 처리한 방법은 추후 언급하겠다.

전용면적구간을 설정한 이유는, 같은 아파트 내에서도 다양한 면적이 존재하는데, 이를 하나로 보는건 옳지 않기 때문에 면적 별로 분리할 필요가 있었다. 다만, 비슷하지만 다른 면적을 굳이 분리할 필요는 없다고 생각했다.

예시로, 서울 모 아파트 단지에 존재하는 전용면적 타입은 다음과 같다.

 

59.64㎡

59.86㎡

59.95㎡

84.79㎡

84.90㎡

84.97㎡

121.63㎡

144.77㎡

 

59.64㎡, 59.86㎡, 59.95㎡는 같은 그룹으로 묶는 것이 타당하며, 84.79㎡, 84.90㎡, 84.97㎡ 또한 마찬가지이다. 전용면적 값을 그대로 사용하기 어렵기 때문에 구간화할 필요성이 있었고, 데이터 분포 및 각종 부동산 사이트들의 분류 기준 등을 참고하여 다음과 같은 기준으로 구간을 나누었다.

 

40㎡ 이상 60㎡ 미만

60㎡ 이상 75㎡ 미만

75㎡ 이상 85㎡ 미만

85㎡ 이상 103㎡ 미만

103㎡ 이상

 

4. 거래가 일어나지 않은 분기의 가격은 가장 마지막에 일어난 거래의 가격을 사용

논리적으로, 사람들은 해당 단위기간 동안 거래가 일어나지 않았다면 가장 최근 거래 가격을 참조할 것 이라고 생각했다. 다른 대안으로는 이후에 발생한 거래의 가격을 사용하거나, 혹은 이전 거래와 이후 거래의 평균가격을 사용하는 방법이 있다. 대안들이 가지고 있는 문제는, 해당 시점에서 구매자들은 미래 가격을 알 수 없다는 점과, 만약 데이터의 가장 마지막 분기가 결측치일 시 해당 방법을 사용할 수 없다는 점 이다.

최종적으로 선택한 방식 또한 가장 첫 분기가 결측치일 시 가격을 설정할 수 없다는 문제점이 있는데, 이는 분석대상기간 이전의 기간들의 데이터를 수집하는 방식으로 해결하였다.

 

 

아파트 정보

데이터 수집

각 아파트 단지의 정보는 네이버 부동산의 단지 정보를 크롤링하였다. 크롤링하는 코드는 처음에는

https://calssess.tistory.com/126 를 참조하였고, 해당 코드에서 빠진 부분 일부를 추가하였다.

 

데이터 구성

 

처음 수집한 데이터의 크기는 (193890, 40) 이고, 여기에 누락된 정보가 일부 있어 추가 수집을 진행하였다.

 

데이터 전처리

1. 사용하지 않을 열 제거

결측치가 너무 많거나, 가격 형성 요인이 아니라고 생각되는 특성들을 삭제했다.

 

2. 전용면적 구간화

거래 데이터와 동일한 기준을 적용했다.

 

3. 일부 특성 비율화

주차대수는 세대 별 주차대수, 임대세대수는 임대세대비율로 변환하였다.

 

4. 건설사 -> 메이저 건설사 인지 아닌지

어떤 건설사가 아파트를 지었는가는 아파트 가격 형성에 유의한 영향을 끼친다고 생각했다. 문제는, 대한민국에는 매우 다양한 건설사들이 존재한다는 점 이고, 모든 개별 건설사를 카테고리로 사용할 수는 없다. 이를 해결하기 위해, 소위 말하는 메이저 건설사 인지 아닌지 여부만 활용하기로 했다. 이를 위해서는 메이저 건설사를 정의할 필요가 있는데, 시공능력평가순위 및 브랜드 평판지수 등을 참고하여 10대 건설사를 선정하고, 해당 건설사의 포함여부를 값으로 사용하였다.

 

5. 일부 문자열로 구성된 열을 레이블 인코딩

 

 

 

여기까지 진행했을 때 느낀 문제점은, 현재 가지고 있는 데이터로 과연 아파트 가격이 어떻게 형성되었는지 파악할 수 있느냐 였다. 아파트의 단지 정보만 가지고는 가격을 설명하기에 너무 부족하다고 생각했다. 실제로, 비슷한 단지 정보를 가지고도 가격이 너무나도 상이한 단지들이 무수히 많이 존재했다. 단순히 아파트의 정보가 아니라, 해당 아파트가 위치한 지역의 정보가 필요하다는 점을 깨달았고, 이를 어떻게 해결할 지 고민해보았다.

 

 

반응형