엎코닿

프로젝트 개요

기술개발 과제

국문 : 생활 활동 반경을 고려한 주거 지역 추천 애플리케이션

영문 : Applications for Recommending Residence Considering The Radius of Living Activities

과제 팀명

엎코닿(UpKoDah, 엎어지면 코 닿을)

지도교수

황혜수 교수님

개발기간

2020년 9월 ~ 2020년 12월 (총 4개월)

구성원 소개

서울시립대학교 컴퓨터과학부 2015XXX0** 정*훈(팀장)

서울시립대학교 컴퓨터과학부 2014XXX0** 정*준

서울시립대학교 컴퓨터과학부 2014XXX0** 최*환

서울시립대학교 신소재공학과 2015XXX0** 김*현

서론

개발 과제의 개요

개발 과제 요약

본 애플리케이션은 통근·통학을 위한 주거지 선정 시, 사용자의 삶의 질 향상을 기대한다.
사용자가 목표지점을 선택하면 버스 · 지하철을 이용한 통근 · 통학 시간 및 수단, 주거지 주변의 근린생활시설 유무를 분석하여 사용자에게 적합한 주거지를 추천한다.

개발 과제의 배경

• 2015년 인구주택 총조사에 따르면, 12세 이상 인구의 통근율은 53.4%에 달하며, 통근·통학 인구 중 거주지 시군구 외로 통근·통학하는 인구의 비율은 34.2%에 달한다. 매일 많은 인구가 집과 직장, 혹은 집과 학교를 오고 가게 되면서 많은 시간을 길에서 소비하게 되고, 또 지역에 따라서는 심한 교통체증으로 인해 고통을 당하기도 한다. 따라서 통근과 통학 양상은 이들의 삶의 질에 직접적으로 영향을 미치게 된다.

• 기존 기술과의 비교 : ‘직방’

1. 전·월세, 보증금, 구조, 층수 등의 옵션
2. 편의시설 관련 정보 없음
3. 주거지 주변 교통 정보 제공

• 기존 기술과의 비교 : ‘다방’

1. 전·월세, 보증금, 기타 옵션
2. 주변의 편의시설 정보 제공
3. 주변 교통 관련 정보 없음

• 기존 기술과의 비교 : ‘네이버 부동산’

1. 편의시설 정보를 지도상에 표시하여 매물을 동시에 표시
2. 특정 지역을 선택하면 예상 도착 시간대별 부동산 매물 표시

• 기존 부동산 정보 애플리케이션은 지도상에서 특정 지역의 거래가, 옵션 등에 따라 필터링한 주거지의 목록을 제시하고, 한 주거지의 상세정보를 선택할 때 편의시설 등의 정보를 제공한다.

• 기존 부동산 정보 애플리케이션은 목표지점에 도달하는 데 드는 시간에 따라서 이웃한 지역구의 부동산 정보를 보여주는 데 그친다. 또 이동 시 발생하는 시간 비용이 아닌 육체적, 경제적 비용은 고려하지 않는 경향이 있다. 본 애플리케이션은 통근·통학 시 대중교통의 환승 횟수와 시간을 고려한 주거지를 제안함으로써 사용자 편의를 제공하고자 한다.

개발 과제의 목표 및 내용

• 이번 과제의 목표는 주거 예정인 지역이 아니라, 사용자가 직장이나 학교 등 활동 반경을 검색하면, 편의시설 등 근린환경을 고려하여 적절한 주거 지역을 찾아주는 애플리케이션을 개발하는 것이다.

• 시나리오 (직장인 예시)

1. 주거 제안 앱은 네트워크 환경을 체크 후 지도가 나와 있는 기본 페이지를 보여준다.

2. 사용자는 지도에서 직장 위치를 등록하고, 원하는 이동 시간을 입력한다.

3. 주거 제안 API에 위치와 시간을 담아 request한다.

4. 주거 제안 API 서버는 공공 데이터에서 해당 위치로부터 원하는 이동 시간 안에 도달할 수 있는 지역을 찾아 후보 지역 리스트로 만든다.

5. 주거 제안 API 서버는 후보 지역 리스트에서 각 지역의 주변 편의시설 등의 요소들을 고려하여 주거하기에 적합한지 판별 후 적합할 시 주거 지역 리스트에 넣는다.

6. 주거 제안 API 서버는 주거 지역 리스트를 JSON 포맷으로 response한다.

7. 주거 제안 앱은 사용자에게 주거 지역 리스트를 보여준다.

• 지도 API 기술은 편의시설 검색 기능과 지도 출력 기능이 원활한지에 따라 카카오 로컬 API를 채택한다.

• 교통 정보 API는 버스 노선과 지하철 노선 공공 API를 활용한다. (공공데이터포털)

• 부동산 매매 정보는 관련 API를 활용하거나 Web Crawling 기술을 활용하여 구현한다.

• 애플리케이션 동작 환경은 Android 운영체제로 하며, 애플리케이션 개발에는 Android Studio를 활용한다.

• 서버 구성은 Gcloud의 서버(GCP)를 메인 서버로 하여 Kubernetes 환경을 구축하고, 추가적인 기능을 하는 서버들을 도커 컨테이너로 디플로이하여 관리한다. 추가 서버에는 매물 데이터를 크롤링하기 위한 Python 기반 크롤링 서버, MySQL 기반 DB 서버, 길찾기 및 추천 알고리즘을 구동하는 서버 등이 있다.

관련 기술의 현황

관련 기술의 현황 및 분석(State of art)

• 전 세계적인 기술현황

내용

• 특허조사 및 특허 전략 분석

내용

• 기술 로드맵

내용

시장상황에 대한 분석

• 경쟁제품 조사 비교

내용

• 마케팅 전략 제시

내용

개발과제의 기대효과

기술적 기대효과

• 사용자가 살기 적합한 지역을 선택하기 위한 고민이 줄어든다. 기존 애플리케이션은 자신이 살고자 하는 지역을 직접 통근 및 통학 위치를 고려하고, 가격 등을 생각하며 선택해야 했지만, 이번 과제는 통근 및 통학 위치만 선택하면, 접근성이 좋은 매물이 있는 지역을 골라주게 된다. 이러한 장점은 사용자에게 좀 더 편리한 검색 환경을 제공하게 될 것이다.

경제적, 사회적 기대 및 파급효과

• 애플리케이션이 활성화된다면, 특정 지역 위주의 매물 및 가격 형성이 아닌, 수요자에 의한 가격 형성으로 어느 정도 변화를 줄 수 있을 것이다. 이는 문재인 정부의 부동산 정책의 ‘실수요자 위주’ 정책에도 부합할 것이며, 실수요와 무관한 투기과열지구 문제도 어느 정도 해결해줄 수 있을 것으로 기대할 수 있다. 물론, 부동산 시세 자체가 이미 접근성이 가격에 포함되었다고 생각할 수 있어 어느 정도의 효과가 있을지는 미지수다.

• 현재 대중교통 중, 특히 버스 노선은 별도의 수요 조사를 통해 진행되고 있다. 하지만, 이러한 방법은 수요 조사 참여자에 국한되기 때문에 분명 한계가 존재한다. 이번 과제에서 개발될 애플리케이션은 통근 위치를 지정하면, 대중교통 접근성에 따라 매물을 결정하게 되며, 여기에서 얻어지는 출발지-목적지 데이터를 수집할 수 있다면, 버스 노선에 대한 수요 조사가 가능하다. 이러한 점은 정부의 스마트시티 사업에도 부합한다고 볼 수 있다.

기술개발 일정 및 추진체계

개발 일정

내용

구성원 및 추진체계

내용

설계

설계사양

제품의 요구사항

사용자 요구사항을 조사하고, 이를 만족시키는 데 필요한 시스템 요구사항을 분석한다.

R1: 통근할 목적지에 따라 원하는 매물을 찾을 수 있으며, 목적지를 지도에서 선택할 수 있음

R2: 현재 자기 자신의 위치를 목적지로 선택할 수 있으며, 지도에서 확인할 수 있음

R3: 검색된 매물이 지하철이나 버스 등 대중교통으로 편하게 접근 가능한 위치임

R4: 도착하는 데 걸리는 시간을 설정할 수 있음

R5: 매물 주변에 있어야 하는 편의시설을 선택할 수 있음

R6: 거래 타입(월세, 전세), 그리고 방의 형태(원룸, 오피스텔 등)를 선택할 수 있음

R7: 매물을 검색하면 지도에서 구 단위, 동 단위로 매물을 묶어서 보여줌

R8: 검색 결과 매물 목록 UI를 지원

R9: 검색 결과 매물을 여러 장의 사진과 함께 보여줌

R10: 검색 결과 매물의 상세 위치 및 주변 시설을 지도를 통해 확인할 수 있음

R11: 거래자의 연락처로 연결하여줄 수 있음

R12: 검색 결과가 5초 이내로는 나와야 함

R13: 안정적인 서비스를 위해 서버가 다운되거나 업데이트로 인해 정지하는 일이 없어야 함

설계 사양

F1: 검색 조건으로 목적지, 제한시간, 매물 유형, 방의 형태, 편의시설 필터를 입력 (입력 인터페이스)

F2: 지도에는 특정 위치를 표시할 수 있음

F3: 지도에는 특정 아이콘과 지역을 나타낼 수 있는 글자를 써서 위치와 함께 표현할 수 있음

F4: 지도의 확대 수준에 따라 구, 동, 지역 단위로 매물을 묶어서 보여줄 수 있음 (클러스터링)

F5: 지도 API를 통한 지도 UI의 구현 및 매물 정보 등의 전시

F6: 연락을 위한 휴대 단말의 전화, 문자 등 연락처로의 리디렉션 기능

F7: 사용자 자기 자신의 위치를 가져오고, 표시할 수 있음

F8: 원하는 매물은 대중교통 편의를 고려할 수 있도록 정류장 또는 역 기준으로 검색

F9: 검색될 매물은 속도를 위해 검색에 용이한 형태로 서버에 미리 저장 (캐싱)

F10: 검색 성능을 높이기 위한 third-party API에 대한 비동기 처리 기능

F11: 서버가 다운되는 일이 없도록 3개 이상의 pod를 띄우고, 로드 밸런싱을 함

F12: 서버가 업데이트를 하더라도 중단되지 않도록 멀티 서버와 무중단 배포를 구현

개념설계안

내용

이론적 계산 및 시뮬레이션

그리드 분할 크기 계산

대부분의 부동산 및 지리정보 애플리케이션은 뷰의 가독성과 응답성을 높이기 위해서 클러스터링을 이용하여 엔티티를 표현한다. 기본적으로 행정구역을 기준으로 분할하고 더 낮은 수준의 클러스터를 제공할 수 있다. 본 앱에서는 특정 좌표(서울시립대)를 기준으로 대한민국 전역을 일정 크기로 나누어 그리드 맵을 구성한다. 성인이 약 5분 걷는 거리인 400m를 단위 그리드 크기로 설정. 그리드는 기준좌표에서 시작하여 대한민국 최극단까지를 단위 크기로 나눈다. 여기서 단위 그리드 크기 400m는 좌표 변량으로 변환되어야 한다. 이 변환에 Geodesic 알고리즘 중 타원 구면체(Ellipsoid)에 대한 거리-지리좌표 변환 정리인 Vincenty’s Formulae를 사용했다.

* Vincenty’s Direct: 지리좌표, 거리, 방위각을 대입하여 다른 지점의 좌표와 방위각을 구하는 정리
* Vincenty’s Inverse: 두 지점의 좌표를 대입하여 방위각과 거리를 구하는 정리

서울시립대 좌표 37.5838657N, 127.0565884E를 기준좌표로 삼고, 400m의 거리에 대해 방위각(azimuth) 0도와 90도로 Vincenty’s Direct 계산을 한다.

azimuth = 90°일 때, 37.5838657° N, 127.0565884° E인 점에서 400m 떨어진 지점의 지리 좌표는, 37.5838656° N, 127.0611171° E이다. 위도상에서는 0.1×10-7° 정도의 차이를 보이고 경도상으로는 0.0045287의 차이가 존재한다.
azimuth = 0°일 때, 동일한 좌표에 대해서 400m 떨어진 위치의 좌표는 37.5874697° N, 127.0565884° E가 된다.
그리고 경도가 동일하며, 위도는 0.003604°의 차이를 보인다. 본 앱에서는 계산의 편의를 위해서 0.0036을 그리드의 단위값으로 설정하였다. 지구를 타원 구면체로 가정한 까닭에 위도에 대해서는 거의 일정한 값을 같지만, 위도가 달라질 때 경도에서의 좌표 차이는 꽤 달라질 수 있다. 경위도 두 방향으로 0.0036으로 설정하여, 위도로는 400m, 경도로는 320m(317.975)차이를 보인다. Google Earth에서도 본 앱의 기준에 가까운 위도 약 400m, 경도 약 320m 의 최소 그리드를 사용한다.

상세설계 내용

내용

결과 및 평가

완료 작품의 소개

프로토타입 사진 혹은 작동 장면

내용

포스터

내용

관련사업비 내역서

내용

완료작품의 평가

내용

향후계획

내용

특허 출원 내용

내용