"엎코닿"의 두 판 사이의 차이

2020년 12월 11일 (금) 00:22 판

프로젝트 개요

기술개발 과제

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

영문 : 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. 주거 제안 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 서버, 길찾기 및 추천 알고리즘을 구동하는 서버 등이 있다.

개발 일정

내용

구성원 및 추진체계

내용

설계

설계사양

제품의 요구사항

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

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 의 최소 그리드를 사용한다.

상세설계 내용

내용

결과 및 평가

완료 작품의 소개

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

메인 화면

지도 페이지

지도-클러스터 뷰

매물 리스트

상세정보 페이지

편의시설 뷰

완료작품의 평가

내용

향후계획

차후 구현할 내용

UX 분석을 통한 검색 조건 추가

검색 조건에 가격대 검색이나 선호 대중교통 선택 등, 여러 옵션을 적용 가능하도록 한다. 다만, 이를 추가하려면 전세나 월세에 따라 입력 방식을 다르게 해야하며, 적절한 UI 선택을 위한 의논이 필요할 것으로 보인다.

목적지 다중 선택을 고려

목적지를 여러 위치를 골랐을 때도 여러 목적지에 가장 최적인 매물을 찾아낼 수 있는 기능에 대해서 초기에 논의된 바가 있다. 이 기능을 구현하려면 매물의 수가 지나치게 줄어드는 것을 방지하기 위해 단일 대중교통 위주의 현재 알고리즘의 수정이 필요하여 가능하다면 차후에 구현하는 것으로 하였다. 기존 알고리즘을 이용할 경우, 지정된 각 목적지 주변에 지나는 대중교통이 동시에 지나는 매물을 찾아야 하는데, 이 방법을 사용하면 실제 검색되는 매물 수는 매우 적거나, 특정 대중교통 인프라가 좋은 지역으로 쏠릴 가능성이 있어, 환승 횟수를 고려한 다양한 검색 방법이 필요할 것이다.

매물 관리자 페이지 제작

현재 매물을 관리하기 위한 관리자 페이지가 없어 초기에 샘플 매물을 작성할 때도 상당한 어려움이 있었다. 실질적으로 데이터 입력 역시 비전문 사용자가 진행하게 되기 때문에, 매물을 등록할 수 있는 페이지 작성, 그리고 등록된 매물을 관리할 수 있는 페이지 작성이 필요하다.

검색 범위 전국범위 확대

초기 계획은 검색 범위를 전국으로 확대하는 것이었다. 이를 구현하려면 전국범위의 대중교통의 노선 상세정보(소요 시간, 정류장 목록 및 위치)를 가지고 있어야 한다. 하지만, 서울시 이외에는 공공 데이터 중에 대중교통의 상세 노선 정보를 얻을 수 있는 API가 존재하지 않았다. 그 대안으로 ODSay 대중교통 API 같은 API가 제시되었으나, 실제 API 호출 횟수를 고려했을 때, 무료 사용 횟수가 적고, 확장 비용이 월 300만 원이므로 사용 여건이 되지 않았다. 차후 개발하게 된다면, 이러한 문제를 해결해야 할 것으로 본다.

@@ 191번째 줄: / 191번째 줄: @@
 [[파일:App08_facility.png]]<br>
 '''편의시설 뷰'''<br><br>
-====포스터====
-내용
 ===관련사업비 내역서===