상세

• 직장인들의 출퇴근 소요시간 및 거리를 고려한 매물 추천 서비스
• 학교 주변 원룸을 찾던 경험에서 시작하여 학교 혹은 직장과 가까운 매물을 보다 쉽게 찾을 수 있도록 개발
• 추가적으로 주변에 마트나 공원이 있으면 좋겠다는 의견도 포함하여 주변 시설도 고려

역할

• 크롤링으로 데이터 수집, 전처리
• MariaDB를 활용하여 DB 구성
• FastAPI를 활용하여 백엔드 구성
• 점수 기반으로한 추천 모델 구성
• OpenCV, CNN로 구성원 수와 연령대를 구분하는 모델 구성

경험

• 개발자 도구를 통해 서버와 통신하는 API url을 수집
  • 네이버 부동산은 다른 웹페이지와 구성이 달라 BeautifulSoup이나 Selenium로 데이터를 확인이 힘듦
    • API url을 수집하여 url의 규칙(좌표, 주택형태…)을 찾고 크롤링을 진행

• 데이터 인출하고 점수를 부여하는 과정에서 시간을 단축

  • 매물마다 좌표값이 달라 모든 좌표로 처리하기엔 계산이 많음
    • 역과 역 간의 시간에 대한 전체 경우의 수를 미리 계산하여 subway 테이블로 저장
    • 매물 마다 좌표값이 달라 인근 시설을 찾는 과정에서 계산이 너무 많이 발생
      • 이름이 같고 좌표값이 멀지 않은 매물을 단지로 묶어 danzi 테이블로 저장
      • 단지의 좌표와 시설의 좌표를 계산하여 danzi-location 테이블로 저장
  • 데이터를 하나씩 인출하며 처리하였는데 시간이 1분 가까이 걸림

    • 해당하는 데이터를 미리 SQL 문으로 필터링한 후 인출하였을 때, 5초 이내로 줄임

      ---

• 매물 추천에 대한 기준을 정함

  • 사용자의 피드백을 받는 기능을 만들기에 인력적으로나 시간적으로 어려움이 많음
    • 매물과 역 간의 거리, 직장과 역 간의 거리, 두 역 간의 시간에 점수를 부여하여 점수가 높은 매물을 추천
    • 가족 구성원에 따라 인근 시설, 층 수에 점수를 부여하여 거리 뿐 아니라 매물의 특성도 고려하도록 함

• 중간에 포기하지 않고 끝까지 개발해냄
  • A 팀원에게 역할을 주었으나, 다음 주에 하차하여 그 역할이 공석이 됨
  • 위와 같은 과정이 세 번 반복되어 진행이 안 됨
    • 남은 팀원과 서로 할 수 있는 역할을 나누고 진행
    • 본래 계획보다 축소하여 베이스라인을 먼저 개발한 후 점차 기능을 추가하는 방향으로 진행

향후 계획

• 명함이 없거나 건강보험료는 업로드하기 꺼려짐
  • 직장의 위치와 자산은 직접 입력할 수 있도록 선택권을 부여