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

2020년 12월 19일 (토) 18:02 판

프로젝트 개요

기술개발 과제

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

영문 : 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)

• State of Art
  • 클라우드 서비스

구글이나 카카오, 네이버 등의 대형 포털을 운영하는 사이트들은 방대한 양의 데이터를 모으고, 이를 API의 형태로 제공하고 있다. 제공되는 기술은 이번 과제에서 사용할 지도 관련 기술뿐만 아니라 번역, 음성인식, OCR 기술, 메신저, 검색, 가상 서버 등 다양하다. 이들은 이러한 기술을 제한된 범위 내에서 무료로 제공하고 있으며, 각 개발사 사이트에 들어가 지정된 등록 절차를 거쳐 활용할 수 있다.

# NAVER 클라우드 OpenAPI : https://developers.naver.com/main/ # 카카오 개발자 OpenAPI : https://developers.kakao.com/ # 구글 클라우드 플랫폼 : https://console.developers.google.com/

• • 정보 공공 데이터 포털

공공 데이터 포털은 공공기관이 생성 또는 취득하여 관리하고 있는 공공데이터를 한 곳에서 제공하는 통합 창구다.(출처 : 공공데이터포털 소개) 공공 데이터 포털의 각 공공 데이터를 받는 방법은 이용 신청 후, REST API를 이용해 HTTP GET 메소드를 활용하여 JSON 형태로 반환 받은 데이터를 활용할 수 있다.

 제21조(공공데이터포털의 운영) [관련 법령 : 공공테이터의 제공 및 이용 활성화에 관한 법률]
 ① 행정안전부장관은 공공데이터의 효율적 제공을 위하여 통합제공시스템(이하 "공공데이터포털"이라 한다)을 구축·관리하고 활용을 촉진하여야 한다.
 ② 행정안전부장관은 공공기관의 장에게 공공데이터포털의 구축과 운영에 필요한 공공데이터의 연계, 제공 등의 협력을 요청할 수 있다.
   이 경우 요청을 받은 공공기관의 장은 특별한 사유가 없는 한 이에 따라야 한다.
 ③ 그 밖에 공공데이터포털의 구축·관리 및 활용촉진 등 필요한 사항은 대통령령으로 정한다.

• • 서버 상용 기술

서버 개발은 크게 서버 하드웨어 구축, 서버 운영체제 설치, 서버 프로그램 운영이라는 세 가지 방식으로 나누어진다. 이전에는 간단한 서버용 장비를 구매하여 구축하는 일이 많았으나, 과거에 비해 네트워크 속도가 비약적으로 상승하여 일부 기업에서는 서버 자원을 이용할 수 있는 환경을 제공한다. 이러한 클라우드 서버를 통해 서버 하드웨어 설계와 운영체제 설치 부담을 줄여 비용을 절약할 수 있다.

# 아마존 AWS(Amazon Web Services) : https://aws.amazon.com/ko/ # 구글 클라우드 플랫폼(GCP) : https://console.cloud.google.com/

서버 프로그램 개발을 위한 프레임워크도 많이 등장했다. 조금 더 개발자 편의를 제공하는 파이썬(Python) 등의 프로그래밍 언어가 등장하면서, 편리한 언어를 지원하는 서버 개발 프레임워크가 등장하였다. 그 중, Python이나 Go언어 기반으로 동작하는 프레임워크도 있고, 한국전자정부프레임워크로 Java 기반의 Spring이 있다.

# Flask 프레임워크 : Python 기반, 유연한 기능 확장 # Flask Web Site : https://flask.palletsprojects.com/en/1.1.x/ # DJango 프레임워크 : Python 기반, 편리한 사용성, 빠른 개발 # DJango Web Site : https://www.djangoproject.com/ # Spring 프레임워크 : Java 기반, 한국 전자정부프레임워크 표준 # Node.js : JavaScript 기반 # Gin : Go언어 기반의 서버 프레임워크

• • 모바일 애플리케이션 개발 기술

모바일 애플리케이션의 대표적인 OS는 Android와 iOS가 있다. 둘은 구동 방식에 차이가 있어 하나의 애플리케이션으로 만들기 어렵다.

# Android : Java 및 Kotlin 기반, Android OS 전용, Android Studio 활용 # iOS : Swift 기반, MacOS, iOS등 Apple사 OS 전용, XCode 활용

만약 위 두 도구 중 하나로 애플리케이션을 개발한다면, 기본적으로 한 가지의 OS에서만 모바일 애플리케이션 구동이 가능해져 각 플랫폼의 애플리케이션을 모두 개발하여야 한다는 문제가 존재한다. 이러한 문제를 해결하기 위해, 크로스플랫폼 모바일 애플리케이션 개발을 지원하는 프레임워크가 존재한다.

# React Native (https://reactnative.dev/) : JavaScript 기반의 Android, iOS 크로스플랫폼 개발 프레임워크. 방대한 양의 커뮤니티 및 인프라가 구축되어 있다. # Flutter (https://flutter.dev/) : Dart 기반의 Android, Window, iOS, LINUX 크로스플랫폼 개발 프레임워크. Android studio로 개발할 수 있다.

• 기술 로드맵
  • 지도 API의 선택

먼저, 지도를 출력하는 API는 카카오 지도 API나, 네이버 지도 API, 구글 클라우드 지도 API 등 다양한 공공 API를 활용할 수 있다. 여기에서 얻어지는 좌표(위도 및 경도)는 네이버의 Geocoding이나 카카오 로컬 API 등을 이용해 자유로운 변환이 가능하다. 조사된 것은 다음과 같다.

• • 버스 및 지하철 API의 획득

이번 과제는 지정 위치로부터 대중교통이나 도보로 제한시간 이내에 갈 수 있는 매물을 찾아내는 것이다. 도보라면 특정 위치를 기준으로 소요 거리를 지도 API의 길찾기 기능을 통해 계산할 수 있다. 하지만, 버스나 지하철의 경우에는 API로 해결할 수가 없다. 이번 과제의 핵심은 ‘버스나 지하철로 환승 없이 직통으로 갈 수 있는 매물’이다. 일반적인 대중교통 길찾기는 자가용을 이용한 길찾기나, 단순 대중교통에 대한 질의만 가능하지, 환승 여부 등을 선택한 대중교통 검색은 불가능했다.

(그림)

하지만, 특정 위치를 선택했을 때, 가까운 버스나 지하철 정류장의 위치를 얻어내는 것은 가능하다. 그렇다면, 버스나 지하철 노선 정보만 알아낼 수 있다면, 특정 정류장에서 다른 정류장까지 도달하는 시간을 계산할 수 있으므로, 과제 수행에 문제가 없어진다. 노선 정보에서 필요한 것은 노선 간 소요 시간이다. 문제는 지하철의 경우, 노선 간 소요 시간을 비교적 쉽게 얻어낼 수 있는 반면, 버스는 관련 API도 없고, 전국에 노선 수가 40만 개가 넘어 간접적으로 조사하더라도 저장할 수는 없을 것으로 보인다.

• • 부동산 매물 획득 방법

부동산 매물의 처리 방식은 직거래하거나 중개업소를 통해 매매/대여하는 방식이다. 직거래의 경우 매매계약서를 작성하는 등 불편이 있어 중개업을 통해 거래하게 되며, 이때 중개료 또는 복비를 중개업자에게 지급하게 된다. 2012년 초에, 네이버 부동산이 중개업을 대행할 수 있는 기능을 가지고 있었는데, 2013년에는 반발로 인해 매매 사업을 중단한 것으로 알려져 있다. 이에 네이버 부동산은 중개업이 아닌 ‘정보 지원 플랫폼’으로 운영되고 있다. 이 플랫폼은 중개업자들이 매물을 올리면서 중개업을 홍보하고, 그 광고료(홍보 비용)를 지불하는 방식으로 운영되고 있다.

결론은, 현재 부동산 사업은 ‘정보 지원 플랫폼/서비스’와 ‘부동산 중개업’의 구조로 나뉘어 있다. 지원 서비스는 중개업소를 소개하는 방식으로 운영되고, 수익은 중개업자들이 내는 광고료로 얻는다. 이렇게 된다면, 직방이나 다방, 네이버 부동산의 주 수익이 중개업자들의 광고료가 되며, 주 수익원인 매물 정보를 공유할 이유가 없어 진다. 그렇기 때문에 실제 제공되는 API는 찾아볼 수 없었으며, 부산시대 부동산(http://landsidae.com/html_file.php?file=api.html)등의 사이트가 있으나, 대부분 폐쇄되거나, 한정적인 범위의 매물만 올라와 활용 가치가 떨어졌다.

따라서, 부동산 매물 정보를 얻기 위해서는 크롤링이나 중개업소의 자료를 받는 것이 강요될 것으로 보인다. 하지만, 크롤링 역시 활용할 수가 없다. 다음은 네이버 이용약관 중 일부다.

 네이버의 사전 허락 없이 자동화된 수단(예: 매크로 프로그램, 로봇(봇), 스파이더, 스크래퍼   등)을 이용하여 네이버 서비스 회원으로 가입을 시도 또는 가입하거나, 네이버 서비스에 로그인을 시도 또는 로그인하거나, 네이버 서비스 상에 게시물을 게재하거나, 네이버 서비스를 통해 커뮤니케이션하거나(예: 전자메일, 쪽지 등), 네이버   서비스에 게재된 회원의 아이디(ID), 게시물 등을 수집하거나, 네이버   검색 서비스에서 특정 질의어로 검색하거나 혹은 그 검색결과에서 특정 검색결과를 선택(이른바 ‘클릭’)하는 등 이용자(사람)의   실제 이용을 전제로 하는 네이버 서비스의 제공 취지에 부합하지 않는 방식으로 네이버 서비스를 이용하거나 이와 같은 네이버 서비스에 대한 어뷰징(남용) 행위를 막기 위한 네이버의 기술적 조치를 무력화하려는 일체의   행위(예: IP를 지속적으로 바꿔가며 접속하는 행위

위 약관을 고려하면, 네이버 서비스는 이용자의 실제 이용을 전제로 하므로, 로봇(크롤링)을 기본적으로 거부하고 있음을 알 수 있다. 따라서, 크롤링을 이용해 제품을 만드는 것은 일단은 불가능할 것으로 보인다.

• • 애플리케이션 개발 프레임워크 선택

개발 프레임워크 선택에서 중요한 사안 중 하나는 ‘친밀성’이다. 물론 다른 고려 사항도 있으나, 애플리케이션 개발은 사용자 입장의 프론트엔드 수준의 개발이기 때문에 선택 범위 내 프레임워크가 기능 및 기술지원이 사용하기에 문제가 없다면, 성능적인 부분보다는, 짧은 개발 기간을 고려하여 친밀성이 높은 안드로이드 스튜디오를 활용해 Android OS 지원용 애플리케이션을 개발한다. 크로스플랫폼 환경은 고려하지 않도록 한다.

하지만, 만약 이후 크로스플랫폼을 고려할 경우, Android Studio를 동일하게 활용하여 Flutter를 두 번째 선택안으로 활용할 수 있을 것으로 보인다.

• • 서버 하드웨어 구성 및 프레임워크 선택

서버의 인프라를 처음부터 구축하는 것은 프로젝트 기간과 비용을 고려했을 시 거의 불가능에 가깝다. 이에 따른 대안으로 서버 호스팅이 있다. 원래는 기존에 물리 서버에 대해 고려하여 다음과 같이 물리 서버 비용을 산정했다.

먼저, NAS나 단순 연산 서버의 경우는 위쪽 2개로도 충분히 구현 가능하나, 이번 과제는 수시로 외부 API 호출 및 성능 개선을 위한 DB 사용도 고려하고 있어 성능상으로 부족하다고 판단했다. 과제를 위한 수준으로 일반 PC나 서버용 메인보드를 구매하는 것을 고려한 것이 3안이지만, 신 제품은 예산 범위를 초과하며, 중고 제품은 구매 후 고장 발견 시, 대처가 곤란해진다는 문제가 있다. 대안인 서버 호스팅에 비해 별다른 이점이 없을 것으로 판단하여 서버 호스팅으로 결정했다.

서버 호스팅 업체의 경우 가장 대표적으로 쓰이는 GCP(Google Cloud Platform)과 AWS(Amazon Web Services) 두 업체가 있다. Kubernetes 클라우드 환경에서 Mysql와 Server API를 띄우도록 했을 시 GCP 경험이 있는 팀원이 있어 개발 기간을 단축할 수 있기 때문에 GCP 인프라를 토대로 개발한다. 서버 프레임워크 후보로는 Java의 Spring, Golang의 Gin, Javascript의 Nodejs가 있다. 서버의 주된 기능은 시간에 따른 부동산 매물을 반환하는 것이고, 사용자의 응답을 고려할 때 Golang의 동시성 지원이 큰 이점으로 작용할 것으로 보이기에 Golang의 Gin framework를 사용하여 서버를 개발한다.

시장상황에 대한 분석

• 경쟁제품 조사 비교

• 마케팅 전략 제시

내용

개발과제의 기대효과

기술적 기대효과

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

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

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

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

기술개발 일정 및 추진체계

개발 일정

구성원 및 추진체계

◇ 사용자 애플리케이션
◇ 데이터 분석: API 및 Web Crawling을 기반으로 수집한 데이터를 분석
    1) 교통 정보
    2) 근린생활시설/편의시설
◇ 데이터 가공: Web Crawling을 통한 데이터베이스 마련
◇ 서버 구축
◇ 데모 애플리케이션: 분석한 데이터를 애플리케이션 내에 시각화

• 정성훈(팀장): 데이터 분석
• 정상준: 데이터 분석, 크롤러 구현
• 최중환: 클라이언트(안드로이드) 개발
• 김유현: 크롤러 구현, 서버 환경 개발

설계

설계사양

제품의 요구사항

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

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


Google Earth 최소 그리드 크기 (위도, 경도)

그리드가 적용되는 범위에서 경도의 차이를 살펴보자면, 본 앱에서 거리가 적용되는 범위인 서울 지역에서 위도 차이에 따른 0.0036의 경도가 얼마의 거리를 나타내는지 계산해봄으로써 알 수 있다. 서울의 최남단 위도(37.698132° N)와 최북단의 위도(37.424783° N)를 각각 적용하여 거리를 계산해보면 아래와 같다.

Google Earth 서울의 그리드

서울 최북단 (37.698132° N, 127.017891° E)
경도 127.014291°E (-0.0036)에 대한 Vincenty's Inverse 계산 결과: 317.489 (m)

서울 최남단 (37.424783° N, 127.059939° E)
경도 127.056339°E (-0.0036)에 대한 Vincenty's Inverse 계산 결과: 318.651 (m)

위와 같은 결과를 볼 때, 0.5° 정도의 위도 차이를 가진 서울 내에서, 경도 차이가 적은 두 지점의 비교는 무시 가능한 차이를 보임을 알 수 있다.

상세설계 내용

내용

결과 및 평가

완료 작품의 소개

프로토타입

메인 화면

지도 페이지

지도-클러스터 뷰

매물 리스트

상세정보 페이지

편의시설 뷰

작동 설명

메인 페이지 작동 설명


지도 및 매물 리스트 페이지


상세 페이지, 편의시설 페이지

관련사업비 내역서

완료작품의 평가

내용

향후계획

차후 구현할 내용

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

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

목적지 다중 선택을 고려

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

매물 관리자 페이지 제작

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

검색 범위 전국범위 확대

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