"Void*capstone;"의 두 판 사이의 차이

2020년 6월 29일 (월) 10:47 판

프로젝트 개요

기술개발 과제

국문 : 고홈

영문 : GoHome

과제 팀명

void* capstone;

지도교수

정형구 교수님

개발기간

2020년 3월 ~ 2020년 6월 (총 4개월)

구성원 소개

서울시립대학교 컴퓨터과학부 20159200** 김*호(팀장)

서울시립대학교 컴퓨터과학부 20155400** 강*성

서울시립대학교 컴퓨터과학부 20159200** 이*엽

서울시립대학교 컴퓨터과학부 20155400** 최*웅

서울시립대학교 컴퓨터과학부 20159200** 홍*표

서론

개발 과제의 개요

개발 과제 요약

GoHome은 심야 귀가 서비스로, 사용자에게 귀가경로 안내, 위치 공유 등의 서비스를 제공한다. 2020년 5월 현재, Google Maps, 네이버 지도, 카카오맵, 티맵 등 시중의 인기 지도 서비스는 따릉이와 연계되지 않으며 도보 경로를 제공하지 못하는 것도 있다. GoHome은 이 문제를 해결하고, 나아가 AR 도보 안내를 구현하여 길찾기 서비스에서 AR의 활용성을 확인한다.

개발 과제의 배경

◇ 배경

시중에 다양한 지도 어플리케이션이 존재하지만, 심야 귀가 인구를 집중 타겟으로 한 것은 찾아보기 어렵다. 또한 심야 귀가자는 주로 택시를 이용하여 비용 부담이 크다. 귀가 시 N버스(서울시 심야 버스)를 이용하는 방법이 있지만, 배차 간격이 길고 노선 수가 적으며 일부 정류장에만 정차하는 한계로 인해 이용하기 쉽지 않다. 이러한 상황을 해결하기 위해, N버스, 따릉이(서울시 공공자전거), 도보를 모두 고려한 귀가 경로를 제공하는 서비스가 필요하다.

◇ 효과

GoHome은 귀가자의 현 위치에서 자택까지의 적절한 경로를 탐색하여 제공한다. 또한 도보 경로에서는 AR(Augmented Reality)을 활용한 길 안내를 제공하여 보다 편하고 효과적인 경로 안내를 제공한다. 심야 귀가자의 안심 귀가를 위해 가족 및 지인에게 현 위치를 실시간 공유할 수 있는 서비스 또한 제공한다. 마지막으로 지하철 및 버스의 막차 시간을 볼 수 있도록 하여 사용자의 귀가 편의를 제공한다. 사용자들은 심야 시간에 편하고 빠르게 귀가할 수 있다. 또한 따릉이와 N버스의 접근성을 높여 심야 시간 대중교통 이용자가 증가할 것이다.

개발 과제의 목표 및 내용

◇ 대중교통 및 따릉이를 이용한 경로 탐색 - 사용자가 빠르고 편하게 집에 가는 경로를 찾을 수 있도록 한다. - 대중교통은 지하철과 버스, 야간 버스를 포함하고, 따릉이와 연계한 경로 탐색을 제공한다. - 지하철과 버스가 끊긴 시간엔 N버스(서울시 심야 버스), 따릉이, 도보를 이용해 귀가할 수 있도록 경로를 제공한다. - 따릉이 대여소에 잔여 자전거가 있는지 실시간으로 파악하여 이용 가능한 최적 경로를 찾는다.

◇ 막차 시간 알리미 - 지하철과 버스 시간표를 활용하여 막차 시간을 계산하여 알려준다. - 사용자가 대중교통 막차 시간을 놓치지 않도록 몇 분 전에 알림을 보낸다.

◇ AR 길 찾기 - 사용자가 밤 중에 길을 잃지 않게 AR로 도보 경로 안내를 돕는다. - 길 찾기 결과와 사용자의 현재 위치, 이동 방향을 이용해 AR 화면에 이동할 방향을 표시한다. - AR 화면과 지도를 함께 표시하여 사용자가 현 위치를 파악하기 쉽도록 한다.

◇ 빠른 길 찾기 - 앱을 실행하는 즉시 사용자의 집으로 가는 가장 빠른 경로를 알려준다.

개발과제의 기대효과

기술적 기대효과

◇ Micro Service Architecture를 통한 효율적인 개발 수행

Micro Service Architecture를 통해 연관성 낮은 서비스를 서로 분리함으로써 테스트 시간을 단축하고 유연하게 개발할 수 있다. 본 프로그램 개발에서는 로그인 서버를 Django, 로직 서버를 Node.js로 구분하여 효율적인 구현을 실현한다.

◇ AR(Augmented Reality)의 지도 분야 활용 가능성 검증

AR은 다양한 분야에서의 활용 가능성을 가진 신기술이다. 이러한 AR이 실제로 지도 분야에서 효율적으로 활용될 수 있는지 검증하고, AR에 대한 경험 및 미래의 증강 현실 사회에 대한 대비를 수행한다.

◇ 경로 탐색 알고리즘의 실제 적용 및 효율성 재고

따릉이, N Bus를 포함한 경로를 효율적으로 탐색하는 경로 탐색 알고리즘을 활용하여 사용자가 최단 시간으로 원하는 목표 지점에 도달할 수 있도록 구현한다. 이를 통해서 경로 탐색 알고리즘이 실제 길을 찾는 과정에서도 성공적으로 수행되는지 관찰하고, 효율성을 검증한다.

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

◇ N버스, 따릉이를 포함한 경로 탐색을 통한 심야 귀가 시간 단축

기존의 심야 귀가 인원들은 N버스와 택시를 통해 귀가하였다. 하지만 이들은 각각 정거장의 부족한 개수, 긴 배차 간격과 부담스러운 요금으로 귀가 인원들에게 부담으로 다가갔다. 따라서 따릉이와 N버스를 결합한 경로를 제공함으로써 사용자의 귀가 시간 단축을 기대할 수 있다.

◇ 야간 따릉이 사용량 증가

서울시 공공자전거 서비스 따릉이는 연도를 거듭할수록 이용량이 증가하고 있다. 하지만 이용량이 출퇴근 시간에 많이 몰려 심야 이용량은 상대적으로 낮다. 심야 귀가 시 따릉이를 적절하게 이용하여 사용량 증가를 기대할 수 있다.

◇ 따릉이의 대중교통화

주간에는 버스 정류장의 수와 버스 노선 수가 많기 때문에, 따릉이와 대중교통을 연계하여 이동하는 경우가 별로 없다. 하지만 야간에는 따릉이를 이용하여 이동 시간을 크게 줄일 수 있다. 따릉이와 대중교통을 연계하여 따릉이의 인식을 대중교통으로 전환하고, 이를 통해 환승 서비스 또한 기대할 수 있다.

기술개발 일정 및 추진체계

개발 일정

월별 목표

3월: 계획수립
4월: 프로그램 개발
5월: 프로토타입 완성
6월: 테스트 및 피드백

핵심기술별 목표

경로탐색
- API Data 요청: 3월 ~ 4월
- 따릉이/도보 경로 탐색 구현: 4월 ~ 5월
- N버스 포함 경로 탐색 구현: 5월 ~ 6월
- 효율적인 경로 탐색 구현: 3월 ~ 6월
AR 길 안내
- AR 이미지 구현: 3월
- 원하는 방향 및 위치에 AR 구현: 4월 ~ 5월
- 효율적인 AR 이미지 구현: 3월 ~ 6월
MSA
- 각 서버 구현: 3월 ~ 4월
- 서버 간 통신 구현: 4월 ~ 5월
- 서버 - 클라이언트 통신 구현: 5월 ~ 6월

구성원 및 추진체계

내용

설계

설계사양

제품의 요구사항

현 위치에서 목적지까지 최적 경로를 얻는다.
AR(Augmented Reality)을 통한 경로 안내를 사용한다.
사용자 정보를 변경한다.
지인과 위치공유 기능을 사용한다.
버스, 지하철 등 대중교통 막차를 안내한다.
현재 위치를 지도에 표시한다.
주변 숙박업소를 검색한다.
맞춤형 안내 서비스를 사용한다.
Client Application의 로딩시간은 2초를 넘기지 않는다.
Client Application의 UI/UX가 통일감을 준다.
Client Application의 색상이 통일감을 준다.

사용자 요구사항 만족을 위한 기능 정의 및 기능별 정량목표

Client Application와 Gateway Server 간 통신
- 응답 시간: 1초 미만
Gateway Server와 Server 간 통신
- 응답 시간: 1초 미만
따릉이/N버스를 포함하는 경로 탐색
- 경로 탐색 시간: 5초 미만
- 경로 정확도(시간 오차): 경쟁 서비스 대비 110% 미만의 최적 경로 소요시간
AR로 도보 경로 표시
- 정확도: 실제와 미만의 오차로 정확한 방향/위치 표현
Client Application에서 페이지를 로드
- 시간: 각 1초 이내 (통신 시간 제외)
내 위치 공유
- 시간: 5초마다 위치 갱신

설계 사양

내용

개념설계안

따릉이를 포함하는 경로 탐색 알고리즘

출발지 주변의 따릉이 대여소와 도착지 주변의 따릉이 정류장을 1:1 선택하고, 직선 경로에 대한 소요 시간을 어림한다. 이때, 대여소 간 소요시간은 캐시된 것을 사용할 수 있다.
어림한 소요 시간이 적은 순으로 실제 경로 및 소요 시간을 구한다. 이때 Tmap의 도보 경로 탐색 API를 사용한다. 실제 소요 시간은 어림한 시간보다 반드시 더 길다. 따라서 한 경로에 대한 실제 소요 시간을 얻을 때마다, 그보다 더 긴 어림한 소요 시간을 가진 경로는 API를 통해 실제 경로를 탐색하지 않는다.
(그림)
위 그림은 모든 경로를 어림한 소요 시간이 짧은 순으로 정렬한 것이다. 어림한 소요 시간이 2200, 2300인 경로는 그보다 짧은 시간의 실제 소요 시간을 가지는 경로가 존재하므로 탐색 대상에서 제외된다.
모든 경로에 대한 탐색이 끝나면, 실제 소요 시간이 가장 짧은 경로 몇 가지를 최종 반환한다. 실제 경로 탐색이 이루어진 모든 경우에 대해 대여소 간 소요 시간을 캐시한다.

N버스를 포함하는 경로 탐색 알고리즘

출발지 주변의 따릉이 정류장과 도착지 주변의 N버스 정류장을 1:1 선택하고, 직선 경로에 대한 소요 시간을 어림한다. 이때, 정류장 간 소요시간은 캐시된 것을 사용할 수 있다.
어림한 소요 시간이 적은 순으로 실제 경로 및 소요 시간을 구한다. 이때 버스 정류장 간 구간은 TOPIS 엔진을 호출하여 구하고, 나머지 구간은 <따릉이를 포함하는 경로 탐색 알고리즘>을 사용한다. 실제 소요 시간은 어림한 시간보다 반드시 더 길다. 따라서 한 경로에 대한 실제 소요 시간을 얻을 때마다, 그보다 더 긴 어림한 소요 시간을 가진 경로는 API를 통해 실제 경로를 탐색하지 않는다.
모든 경로에 대한 탐색이 끝나면, 실제 소요 시간이 가장 짧은 경로 몇 가지를 최종 반환한다. 실제 경로 탐색이 이루어진 모든 경우에 대해 정류장 간 소요 시간을 캐시한다.

도보 이동과정에서의 안정적인 AR 이미지 표시

AR 이미지는 평면을 인식하여 그 위에 노드를 생성한 뒤 구현할 수 있다. 이렇게 구현된 AR 화살표는 사용자가 진행해야 하는 방향으로 회전되어야 하는데, 다음과 같은 방법으로 회전이 진행된다.
1. 먼저 사용자의 기기가 향하는 화면으로 이미지가 생성된다. 기기 내의 센서 정보를 통하여 정북방향 기준으로의 각도를 얻어온다.
2. 얻어온 센서를 기준으로 반대 방향으로 이미지를 회전시킨다. 회전이 완료되면 화살표 이미지는 정북방향을 향하게 된다.
3. 현재 사용자의 위치와 목표 위치 간 방위각을 계산한다. 계산된 방향만큼 정방향으로 이미지를 회전시킨다. 이미지는 사용자가 진행해야 하는 방향을 가리키게 된다.

이론적 계산 및 시뮬레이션

AR 도보 안내의 이론적 과정 및 시뮬레이션

AR 도보 안내는 경로 탐색을 통해 도출된 (위도, 경도)로 이루어져 있는 경로 포인트 정보를 활용하여 사용자에게 AR 이미지를 출력한다. 그 과정은 다음과 같다.

평면 인식
- 3D 모델을 기기 내 화면에 출력하기 위해서는 모델을 위한 평면을 인식해야 한다. ARCore를 이용하여 모델을 출력할 수 있는 평면을 탐색한다. 화면의 색상을 통해 평면을 인식하는 특성으로 인해 흰색 평면은 잘 인식하지 못한다. [그림 1]과 같이 흰 점의 집합으로 평면을 인식하여 화면에 출력한다.
노드 및 모델링 객체 생성
- 인식한 평면 위에 3D모델을 생성할 수 있는 노드를 새롭게 생성한다. 3D 모델링 파일을 Sceneform을 통해 기존 obj 모델링 파일을 활용할 수 있는 .sfa 및 .sfb 파일로 변환한 뒤 ModelRenderable 객체에 담는다.
노드 회전 및 AR 이미지 출력
- 노드를 사용자가 이동해야 하는 방향으로 회전시킨다. 회전 방법은 다음과 같다. 사용자가 이동해야 하는 방향을 계산하기 위해 방위각 개념을 이용하였다. 현재 위치 및 목표 위치의 위도, 경도 값을 받아와 라디안 값으로 변환한 후, sin 및 cos 및 acos 함수를 이용하여 라디안 거리를 계산하였다. 계산된 거리를 바탕으로 이를 라디안 각도로 변환한 뒤 다시 방위각으로 변환했다. 변환 공식은 다음과 같다.
- (변환공식 이미지)
- 사용자가 향하고 있는 방향 계산을 위해서 안드로이드 기기의 가속도 센서 및 자기장 센서를 이용했다. 두 센서를 통해 회전의 정보를 담고 있는 Azimuth, Pitch, Poll 값을 받아 온 뒤 Azimuth 값을 통해 평면에서 사용자가 향하는 방향을 계산했다.
- 두 값을 기준으로 이미지가 회전해야 하는 각도를 계산하였다. 먼저 현재 사용자가 향한 각도만큼 역으로 회전시켜 북쪽을 바라보게 한 뒤, 목표 방위각만큼 다시 정 방향으로 회전시키는 형식으로 이미지의 각도를 설정했다. 예를 들어 정북 방향이 0도라고 할 때 사용자가 현재 보는 방향이 270도이고 목표 방향이 45도라면, -270도를 회전시켜 0도로 정북 방향으로 만든 뒤 다시 +45도를 회전시켜 이미지가 목표 방향으로 회전할 수 있도록 했다. [그림 2]와 [그림 3]과 같이 북쪽 및 원하는 각도로 정상적으로 AR 이미지가 회전하고, 각도 오차는 ±정도로 크지 않게 나타남을 알 수 있다.
- 회전된 노드를 기준으로 모델링 객체를 통해 AR 이미지를 출력한다. 이 과정을 반복하며 지속적으로 AR 이미지를 갱신한다.

상세설계 내용

기능 구현을 위한 세부기술 선택사항 (디자인)

시스템 구성

Micro-Service Architecture
- MSA(Micro-Service Architecture)는 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 나눠 만드는 아키텍쳐이다. 개발, 빌드, 테스트 시간을 단축할 수 있으며 본 프로젝트에서처럼 여러 개의 서버를 서로 다른 언어, 프레임워크로 사용할 수 있다는 점에서 유연성이 굉장히 높다. 또한, scaling하기에도 용이하기 때문에 트래픽이 높은 서버에 적합하다.

MongoDB
- MongoDB는 NoSQL의 일종으로 key-value 형태의 BJSON으로 데이터를 저장한다. NoSQL은 ‘Not Only SQL’로서 기존에 RDBMS와 다르게 SQL을 활용하지 않는 다른 방식의 저장기술이다. 단순하고 대량의 데이터를 다루기 용이하기 때문에 빅데이터가 떠오르면서 함께 급부상하고 있다. 또한, 스키마가 존재하지 않기 때문에 필드의 추가 및 제거가 매우 쉬워져 개발의 진입장벽이 낮다는 장점이 있다.

통신 및 인증

RESTful API
- REST란 ‘Representational State Transfer’의 약자로, 자원을 URI로 표시하여 해당 자원의 상태를 주고 받는 것을 의미한다. REST API는 설계규칙이 존재하는데, 이를 통해 언어나 플랫폼에 종속되지 않는 인터페이스를 만들 수 있다. 설계규칙은 공식기관에서 발표하는 방식이 아닌 개발자들이 비공식적으로 의견을 제시하기 때문에 명확한 정의가 존재하지 않는다. 하지만 일반적인 규칙은 다음과 같다.
1. URI는 자원을 표현하는 데 중점을 두기 때문에, 동사보다는 명사를 사용한다.
2. 자원에 대한 행위는 HTTP METHOD로 표현한다.
3. 슬래시(/)는 계층 관계를 나타내는 데 사용되고 마지막에는 사용하지 않는다.
4. 대문자와 언더바(_)를 사용하지않고 소문자와 하이픈(-)을 사용하여 나타낸다.
JWT
- 클라이언트의 인증을 위해 token 인증 방식을 사용하였다. 그중에서도 JWT를 사용하였는데 payload에 자주 참조되지만 보안 문제가 없는 데이터를 저장함으로써 서버와 DB의 트래픽을 낮추었다. JWT를 비롯한 토큰 인증 방식은 악성 클라이언트로부터 토큰 탈취 위험이 있으므로 access token과 refresh token을 사용하여 보안을 강화했다.
Retrofit2
- Android 클라이언트에서 서버와 HTTP 통신을 위해 Retrofit2 라이브러리를 사용하였다. Retrofit2는 type-safe HTTP 클라이언트이다. REST API를 위한 자신만의 코드를 작성하는 것은 시간이 오래 걸리는 작업이지만, Retrofit2를 이용하면 connection, caching, retry, threading, response parsing, error handling 등 많은 기능을 훨씬 더 빠르고 안전하게 구현할 수 있다.

앱 개발 및 AR

Fragment Layout
- Client Application 개발에서 Intent를 사용하여 Activity를 전환하면 끊김 현상이 발생하였다. 더 부드러운 화면 전환을 위해 Fragment Layout을 사용하였다. Fragment를 상속하여 각 View를 구현했고, 한 Activity 내에서 화면 전환할 수 있도록 하였다.

ARCore 및 Sceneform
- ARCore는 증강 현실 애플리케이션을 빌드 할 수 있도록 Google에서 개발한 소프트웨어 개발 키트이다. Sceneform은 ARCore 내에서 지원하는 라이브러리이며, 3D UI에 대한 개발을 지원한다. 안드로이드 스튜디오, 유니티, 언리얼 엔진 등에서 구현 가능하며 안드로이드 스튜디오 기반의 구현을 진행하였다.

.obj, .mtl, .sfa 파일
- AR 이미지는 2D 또는 3D로 모델링 된 이미지를 사용자의 모바일 기기 화면에 투영한다. 본 애플리케이션에서는 3D 모델을 활용했으며, 다양한 3D 모델링 파일이 존재하는 라이브러리 사이트인 구글 Poly를 이용하거나, 윈도우 기본 제공 애플리케이션인 “3D 그림판”을 활용했다. 모델링 파일은 .obj, .mtl 확장자 파일로 이루어져있으며 .obj는 3D 모델의 정보를 담고 있는 파일이고, mtl은 3D모델의 재질 정보를 담고 있다. ARCore에서는 Sceneform 라이브러리를 통해 .obj 파일을 자체적으로 활용할 수 있는 .sfa 파일로 변환하여 사용한다.

Quaternion과 Euler Angles
- AR 경로 탐색을 위해서는 사용자가 보는 방향 및 실제로 이동해야 하는 방향을 계산하여 AR 화살표를 알맞게 회전시켜 화면에 출력해야 한다. 3차원 물체의 회전에 대해서는 Euler Angles와 Quaternion의 개념이 있으며, ARCore에서는 Quaternion을 주로 사용한다. Euler Angles은 X, Y, Z 3개의 축으로 회전하는 직관적인 회전 개념이며, Quaternion은 (x,y,z,w) 의 4가지 원소를 가지며, x, y, z의 회전의 원점 벡터와 w의 회전 스칼라 값을 의미한다. Quaternion은 Euler Angles에서 나타나는 축이 겹치는 짐벌락 현상이 나타나지 않는 장점이 있다.

시스템 설계

User
- GoHome을 사용하는 사용자는 안드로이드 앱을 통해 서비스를 이용한다. 사용자는 요청에 대한 처리 결과를 확인한다.
Front End
- Android Studio와 ARCore를 사용해 작성된다. 사용자가 보는 화면을 생성하고, 발생하는 이벤트를 처리한다. 경로 안내와 함께 선택적으로 AR 안내를 제공한다. Back End 서버와 HTTP 통신을 통해 데이터를 주고받는다.
Back End
- 상호 독립적인 기능구현을 위해 Micro-Service Architecture를 적용하여 User Management Server, Logic Server, API Gateway Server로 구성된다. User Management Server는 사용자 인증, 관리를 제공한다. Logic Server는 Open API 요청을 통해 데이터를 받아와 경로 탐색 요청을 처리한다. API Gateway Server는 클라이언트-서버 통신을 중개한다.
DB
- User Management Server는 MySQL을 통해 사용자 정보를 저장하고, Logic Server는 MongoDB를 사용해 자전거/버스 정보를 저장한다.

UI

(UI-01) Login
- 로그인 화면
(UI-02) Sign Up
- 회원가입 화면
(UI-03) Address
- 주소 검색 화면
(UI-04) Map
- 지도에 현재 위치 표시
(UI-05) Drawer
- 사용자 정보, 막차 및 첫차 정보 표시
(UI-06) Search
- 경로 검색 화면
(UI-07) Route
- 경로 표시
(UI-08) Location Sharing
- 위치 공유 팝업
(UI-09) AR
- AR 경로 안내

결과 및 평가

완료 작품의 소개

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

내용

포스터

내용

완료작품의 평가

내용

향후계획

다음은 본 프로젝트에서 차후 구현할 만한 내용이다.

AR 도보 안내 화면에서 지도 표시
- 우리의 AR 도보 안내는 Google Maps의 Live View의 국내 사용 불가에 대한 문제를 해결하고 AR 도보 안내의 실용성을 검증하고자 구상되었다. Google Maps의 Live View에서는 AR 이미지로 경로를 안내할 뿐만 아니라, 화면 하단에 지도를 함께 띄워줌으로써 더 효과적인 경로 안내를 제공한다. GoHome은 현재 AR 이미지만 표시할 뿐, 지도까지 함께 보여주지는 않는다. Live View처럼 지도를 함께 표시하려 했으나, 개발 난이도가 높아 구현하지 않았다.
외부 독립적인 버스 경로탐색 알고리즘 작성
- 현재 버스를 포함하는 경로탐색은 TOPIS의 경로탐색 엔진을 일부 활용하고 있다. 하지만 이 엔진은 공식적으로 제공되는 것이 아니라서(하지만 관련 문의 과정에서 사용을 안내받았다) 품질이 좋지 않다. 특히 요청에 대한 응답속도가 매우 상이(수십ms ~ 수만ms)하다. 따라서 버스 경로탐색 과정에서 TOPIS 의존성을 줄이거나 없앨 필요가 있다. 이를 위해 직접 N버스 데이터를 가공/연산하여 최적 경로를 빠르게 탐색하는 알고리즘을 개발해야 한다.
GPS 오차 보정
- GPS 값은 오차가 심하다. 현재는 GPS 값을 그대로 사용하고 있는데, GPS의 오차 때문에 AR 도보 안내와 위치공유 등에서 낮은 안정성을 보인다. 이를 해결하기 위해 GPS 값을 보정해야 한다. 가장 단순한 방법은 직전 GPS 값과의 평균을 사용하는 것이다. 사용자의 실제 위치가 극단적으로 빠르게 변화할 가능성은 적고, 그 속도가 버스보다 빠를 경우는 고려하지 않아도 될 수준이다. 따라서 현재 GPS 값과 이전에 측정한 GPS 값들을 바탕으로 적절한 가중치를 적용해 최종 GPS 값을 계산함으로써 GPS 오차를 보정 할 수 있을 것이다. 더 나아가 AI를 이용하여 GPS 값을 추정할 수도 있을 것이다.
버스와 지하철에 대한 막차, 첫차 알림
- 일반적으로 심야 귀가는 더 오랜 시간이 걸리기 때문에 N버스가 아닌 일반적인 대중교통을 이용할 수 있도록 막차와 첫차 알림을 지원한다.
주변 숙박업소 추천
- 심야에 여러 교통수단을 통해서도 귀가가 힘들 경우를 대비하여 주변 숙박업소에 대한 정보를 제공하고 추천한다.
HTTP/2 통신
- HTTP/2 통신은 헤더압축, 서버푸시 등을 지원한다. GoHome의 위치 공유 기능 등에 사용하면 통신량과 지연을 낮춰 통신 효율을 크게 늘릴 수 있을 것이다.
더 자세한 위치 공유 기능
- 현재 위치 공유기능은 개발 일정 조율 등의 사유로 현 위치만 공유되며 집까지의 경로는 공유되지 않는다. 이를 지원하기 위해서는 상세 경로 정보를 저장하고 효율적으로 관리해야 한다.
자동로그인 기능
- 자동로그인 기능은 프로젝트에서 개발 우선순위가 매우 낮아 결국 구현하지 않았다. 하지만 사용자 편의를 위해 필요한 사항 중 하나로, 차후 구현이 필요하다.

특허 출원 내용

내용

@@ 158번째 줄: / 158번째 줄: @@
 ===기술개발 일정 및 추진체계===
 ====개발 일정====
-내용
+월별 목표
+*3월: 계획수립
+*4월: 프로그램 개발
+*5월: 프로토타입 완성
+*6월: 테스트 및 피드백
+핵심기술별 목표
+*경로탐색
+**API Data 요청: 3월 ~ 4월
+**따릉이/도보 경로 탐색 구현: 4월 ~ 5월
+**N버스 포함 경로 탐색 구현: 5월 ~ 6월
+**효율적인 경로 탐색 구현: 3월 ~ 6월
+*AR 길 안내
+**AR 이미지 구현: 3월
+**원하는 방향 및 위치에 AR 구현: 4월 ~ 5월
+**효율적인 AR 이미지 구현: 3월 ~ 6월
+*MSA
+**각 서버 구현: 3월 ~ 4월
+**서버 간 통신 구현: 4월 ~ 5월
+**서버 - 클라이언트 통신 구현: 5월 ~ 6월
 ====구성원 및 추진체계====
 내용