사용자 위치 정보 분석을 위한 라이프로그 수집 인터페이스 및 시각화 시스템 개발

2.1 RESTful 기반 인터페이스

Kim et al. [8]은 여러 디바이스에서 생성하는 센서 데이터들의 데이터 형식과 전달 방식이 달라 발생하는 문제점을 해결하였다. 이를 위하여 REST 방식으로 제공하는 RSM(RESTful Sensor Middleware) 시스템 개발을 통해 여러 센서 데이터들을 분석, 변환 및 전달하였다. 그러나 실제로 데이터를 수신할 때 문제점이 발생한다. 여러 센서들 중 원하는 센서의 데이터만 수신하거나 특정 기간 동안의 데이터를 수신할 수 없다. 이러한 문제점 때문에 사용자가 원하는 유형의 데이터를 제공받지 못한다.

Kim et al. [9]은 실내 공기 오염이 이산화탄소, 미세먼지 및 휘발성 유기화합물에서 영향을 많이 받는다고 판단하였고, 이를 측정하여 데이터를 송수신하는 웹서버와 오염정보를 확인하는 애플리케이션을 제안하였다. 웹서버는 일정 간격으로 센서 디바이스의 센서 데이터를 받아와 저장하거나 저장된 데이터를 애플리케이션에 제공하는 두 가지 인터페이스가 있다. 그러나 이는 시스템 간의 데이터 송수신만을 제공하였다. 사용자가 직접 데이터를 확인하기 위해서는 해당 연구의 애플리케이션을 필수적으로 사용해야하고, 직접 데이터를 활용하기 위한 인터페이스는 제안되지 않았다.

Bianchi et al.[10]은 위해 약물 사건을 해결하기 위하여 기존 전자 처방전의 의약품 처방 오류를 문제점으로 지적하였다. 이를 해결하기 위해 안전한 약물 관리, 처방 및 등록 서비스를 위한 RESTful API 기반의 웹 시스템 PHARMA를 개발하였다.

기존 연구에서는 라이프로그를 송수신하기 위하여 특정 디바이스 혹은 플랫폼에서 제공하는 인터페이스를 사용한다. 그러나 이는 사용자의 요구에 맞게 원하는 유형의 데이터와 특정 기간 동안의 데이터를 수신하는 인터페이스를 제공하지 않는다.

2.2 라이프로그 분석 및 시각화 연구

Kim et al.[11]은 위치 정보 수집의 용이함에 따라 EM(Expectation Maximization) 군집화를 통해 최적의 이동패턴 모델을 찾아내고 각 군집들은 이동 패턴의 중심점, 평균, 머문 시간 등을 나타낸다. 하지만 군집화 결과를 시각화하여 보일 때 지도위에 점과 선으로만 나타내어 각 군집이 포함하는 여러 정보를 사용자에게 다각적으로 보여주지 않는다.

Cha et al.[12]은 스마트폰의 GPS 정보를 수집하여 일상 경로 검출 및 이탈 판단 알고리즘을 적용시켰다. 이를 통해 실시간으로 일상 경로 이탈 여부를 판단한다. 하지만 일상 경로의 이탈 여부를 시각화하여 보여줄 때 단편적인 이동 경로만 보여주며 다양한 위치 정보를 시각화하여 보여주지 않는다.

Hwang et al.[13]은 사용자의 모바일 기기에서 수집한 GPS, 날씨 정보, 프로필, 음악 파일 등의 여러 문맥을 분석한다. 분석 결과는 시각화되고 라이프 브라우저를 통해 개개인의 일상생활을 효과적으로 보여준다.

기존 연구에서는 위치 정보 분석 결과를 보여주기 위해 각각 다른 시각화 도구를 사용한다. 그러나 이는 사용자가 원하는 시각화 방식을 유형화하기 힘들다. 따라서 사용자들의 요구사항을 분석하고 시각화 요소를 판단하는 과정이 필요하다.

3.1 요구사항 정의

본 논문은 사용자의 위치 데이터를 포함한 라이프로그를 수집, 제공 및 모니터링을 위한 시스템을 구축하는 것을 목표로 한다. 앞서 기술한 바와 같이, 기존의 연구들은 다음과 같은 두 가지 문제를 지니는데, (1) 데이터 제공 인터페이스가 디바이스 및 플랫폼에 종속되어 사용자는 원하는 유형 및 품질의 데이터를 받지 못한다는 것과 (2) 데이터 수집 및 모니터링 시 사용자가 원하는 시각화 도구를 유형화 및 일반화하여 개발하기 어렵다는 것이다.

첫 번째 문제는 RESTful API를 이용한 웹 인터페이스를 통해 해결하고자 한다. 이를 위하여 디바이스 및 플랫폼에서 제공해주는 고정된 유형의 데이터가 아닌, 다양한 유형의 데이터를 제공해 줄 수 있도록 요구사항을 정의해야 한다.

두 번째 문제의 경우, 일반화된 시각화 도구 개발을 위한 개발 방법론 적용보다는 목표로 하는 시스템의 시각화 도구 개발을 위한 명확한 요구사항 분석 및 설계를 통해서 해결하고자 한다. 예를 들어, 기존의 시스템 및 플랫폼들이 현재 수집중인 라이프로그의 현황 및 요약 정보들만을 제공해준다면, 제안 시스템은 사용자 위치 정보를 시각화하기 위하여 사용자 이동 패턴의 유사도 분석을 통한 그룹화, 행동 분류, 이동 패턴 분석 결과 및 사용자 위치 데이터 분포도 등과 같은 다양한 시각화 도구를 설계해야 한다. 이러한 시각화 도구들은 사용자 위치 정보를 다양한 관점으로 원하는 분석 결과를 보여줄 수 있다.

표 1은 설계상의 이슈와 요구사항이며 각 요구사항의 필요성은 다음과 같다.

Table 1.

Issues and requirements for design

(1) 웹 기반의 라이프로그 송수신 : 사용자는 라이프로그를 송수신할 때, 디바이스 및 플랫폼으로부터 독립적으로 송수신해야 한다. 이를 위해 RESTful API를 이용한 웹 인터페이스가 필요하다. 따라서 데이터 송수신 인터페이스는 URI를 통하여 사용자에게 데이터 수집 및 제공을 요청받으며 그 결과를 JSON 형식으로 반환해야 한다.

(2) 라이프로그의 종류별 데이터 수신 : 사용자는 라이프로그를 종류별로 수신하여 분석에 필요한 데이터 유형들만 활용할 필요가 있다. 따라서 서버는 URI를 통해 사용자로부터 원하는 데이터의 종류를 요청받을 수 있도록 설계되어야 한다.

(3) 라이프로그의 시간대별 데이터 수신 : 사용자는 라이프로그를 시간대 별로 수신하여 특정 날짜혹은 기간 동안 수집된 데이터를 활용할 필요가 있다. 따라서 서버는 URI를 통해 사용자로부터 원하는 시간대를 요청받을 수 있도록 설계되어야 한다.

(4) 라이프로그의 사용자별 데이터 수신 : 사용자는 원하는 사용자의 라이프로그를 수신하여 분석할 필요가 있다. 따라서 서버는 URI를 통해 특정 사용자를 요청받을 수 있도록 설계되어야 한다.

(5) 실시간 라이프로그 수집 현황 : 사용자는 수집된 라이프로그를 실시간으로 확인할 수 있어야 한다. 따라서 라이프로그 수집 현황의 확인이 최소한의 지연 시간을 지니도록 시스템을 설계해야 한다.

(6) 시간대별 수집 현황 분석 결과 : 현재까지 수집된 라이프로그를 시간대별로 분석한 결과를 확인할 수 있도록 시각화 도구를 설계해야 한다.

(7) 데이터 종류별 수집 현황 분석 결과 : 라이프로그를 종류별로 분석한 결과를 확인할 수 있도록 시각화 도구를 설계해야 한다.

(8) 사용자별 수집 현황 분석 결과 : 라이프로그를 사용자별로 분석한 결과를 확인할 수 있도록 시각화 도구를 설계해야 한다.

(9) 사용자 유사도 분석을 통한 그룹 생성 결과 : 다양한 서비스를 사용자에게 맞춤형으로 제공해 주기 위하여 사용자들의 이동 패턴을 이용한 그룹 생성이 필요하다. 사용자 이동 패턴의 유사도 분석을 통하여 사용자들의 그룹을 생성하고 이를 확인할 수 있는 시각화 도구를 설계해야 한다.

(10) 사용자 행동 분류와 이동 패턴 분석 결과 : 사용자는 걷기, 뛰기, 서있기, 운전하기 등과 같은 다양한 행동을 취하며 이동한다. 사용자들의 이동 방식에 따른 행동을 분류하고 이동 패턴에 따른 결과를 확인할 수 있는 시각화 도구를 설계해야 한다.

(11) 사용자 위치 데이터 분포도 : 사용자의 이동 패턴을 지도상에 표기하여 직관적인 패턴 분석이 가능하도록 할 필요가 있다. 따라서 사용자들의 이동 데이터를 지도상에 표기하여 경로의 사용 및 유사성 등을 확인할 수 있도록 시각화 도구를 설계해야 한다.

3.2 제안 시스템 구조

앞서 정의한 요구사항 분석을 토대로 설계한 라이프로그 시스템은 기존 데이터 송수신, 데이터 수집 현황 시각화 및 사용자 위치 정보 시각화 이슈를 해결할 수 있어야 한다. 따라서 제안 시스템은 사용자에게 RESTful API를 이용한 웹 인터페이스와 라이프로그를 다각적으로 시각화한다.

그림 1은 본 논문에서 제안하는 라이프로그 시스템의 전체 구조를 보여준다. 제안 시스템은 사용자, 데이터 수집부, 서버 및 데이터베이스로 나뉜다. 먼저 라이프로그는 웨어러블 디바이스의 심박 센서, GPS 센서 및 3축 가속도 센서를 통해 매 5초마다 수집된다. 수집된 라이프로그는 RESTful API 기반 웹 인터페이스를 통해 서버 데이터베이스에 저장된다.

Fig. 1.

Lifelog collection architecture

또한, 사용자는 서버 데이터베이스의 라이프로그를 웹 인터페이스를 통해 제공받는다. 데이터 시각화는 서버 데이터베이스의 라이프로그를 이용하여 데이터 수집 현황과 사용자 위치 정보를 보여준다.

3.3 RESTful API를 이용한 웹 인터페이스 설계

그림 2는 라이프로그를 송수신할 때의 프로세스를 보여준다. 먼저 사용자가 웹 인터페이스를 통해 URI(Uniform Resource Identifier) 형식으로 데이터 송신 및 수신 요청을 하면, 서버는 URI에 포함된 인자들을 기반으로 질의문을 작성해 데이터베이스에 전달한다. 전달받은 질의문은 데이터베이스에서 실행되고 결과 값은 서버와 웹 인터페이스를 통해 JSON 형식의 확인 메시지로 사용자에게 전달된다.

Fig. 2.

Sequence diagram of lifelog transmission

표 2는 요구사항 1~4를 해결하기 위하여 RESTful API를 통해 설계된 분류 기준별 URI 양식과 예제이다. 모든 기능은 RESTful API의 GET 메소드를 사용해 구현한다. URI를 HTTP를 통하여 서버로 전달하면, 서버는 URI 내의 인자들을 읽은 후 질의문을 작성하여 데이터베이스에 전달한다.

Table 2.

Design of RESTful API for receiving lifelog

전달받은 질의문의 실행 결과 값은 웹 화면에 JSON 형식으로 제공된다. 또한 데이터 종류, 사용자 및 시간 기준의 URI 양식은 서로 조합하여 사용 가능하다. 또한 데이터 종류의 URI 양식에서 중 ‘datatype’으로는 ‘3dacc’, ‘HR’, ‘GPS’ 등이 사용 가능하며 이는 각각 3축 가속도, 심박수, 위치 정보를 의미한다.

표 3은 요구사항 1을 위해 RESTful API로 설계한 URI 양식과 예제이다. 해당 기능은 표 2의 수신 기능과 마찬가지로 RESTful API의 GET 메소드를 이용해 구현한다. 표 3의 URI를 HTTP를 이용하여 서버로 요청하면 서버는 URI 내의 인자들을 읽고 질의문을 작성하여 서버 데이터베이스에 전달한다. 전달받은 질의문의 실행 결과는 JSON 형식으로 표현된다.

Table 3.

Design of RESTful API for sending lifelog

3.4 데이터 시각화 도구 설계

본 논문에서 데이터 시각화는 요구사항 5부터 요구사항 11까지를 해결한다. 이를 위해 각각의 시각화 도구가 해결하는 요구사항, 시각화 목적 및 사용한 라이브러리는 다음과 같다.

• 날짜별 라이프로그 개수 : 날짜별로 라이프로그 수집 현황을 확인할 수 있도록 라이프로그 개수를 막대 그래프로 구현한다. (요구사항 5)
• 날짜별 누적 라이프로그 개수 : 날짜별로 라이프로그의 누적 수집 현황을 확인할 수 있도록 라이프로그의 누적 개수를 선형 그래프로 구현한다. (요구사항 5)
• 요일별 라이프로그 비율 : 요일별 데이터의 수집 현황을 확인할 수 있도록 요일별 수집 비율을 파이 그래프로 구현한다. (요구사항 6)
• 시간대별 라이프로그 개수 : 시간대별 데이터 개수를 확인할 수 있도록 라이프로그 개수를 막대 그래프로 구현한다. (요구사항 6)
• 데이터 종류별 라이프로그 비율 및 개수 : 라이프로그의 종류별 데이터 개수와 비율을 확인할 수 있도록 데이터 종류의 비율을 파이 그래프로 구현한다. (요구사항 7)
• 사용자별 라이프로그 비율 : 사용자별 라이프로그 수집 현황을 확인할 수 있도록 사용자별 총 수집 비율을 막대 그래프로 구현한다. (요구사항 8)
• 사용자 유사도별 그룹 : 사용자들의 집단적인 위치 정보 분석을 위하여 사용자 이동 패턴 유사도 분석을 통한 사용자 그룹을 네트워크 그래프로 구현한다. (요구사항 9)
• 행동 분류 데이터 분포도 : 사용자의 이동 시 위치와 해당 이동의 행동 분류를 분석하기 위하여 행동 분류 분포도를 지도상에 표시한다. (요구사항 10)
• 행동 분류 데이터 개수 및 비율 : 사용자들의 행동 분류의 현황을 확인하기 위하여 행동 분류 데이터 개수 및 비율을 파이 그래프로 구현한다. (요구사항 10)
• 위치 데이터 분포도 : 사용자들의 이동 지역 분포를 확인하기 위하여 위치 데이터 분포도를 지도상에 표시한다. (요구사항 11)

4.1 구현 환경

본 논문의 구현 환경은 표 4와 같다. 라이프로그 수집을 위해 삼성전자의 스마트워치(SM-R600, SM-R770)를 사용한다. 해당 모델은 타이젠 플랫폼을 통해 자체적인 앱 개발이 가능하며 3축 가속도 센서, 심박 센서, GPS 센서를 포함하고 있다. 즉, 이는 다양한 API를 활용한 스마트워치 및 스마트폰의 애플리케이션 개발이 가능하며, 각 센서들로부터 직접 접근하여 원하는 품질의 센서 데이터를 수집하는 것이 가능하다는 것을 의미한다. 라이프로그의 수집 및 활용을 위한 데이터베이스는 Microsoft의 SQL Server 2017, 웹 인터페이스 및 시각화는 Node.js, D3.js, vis.js, Google Map API를 이용해 개발한다.

Table 4.

Implementation environment

4.2 RESTful API를 이용한 데이터 송수신

그림 3은 RESTful API를 이용해 전체 라이프로그를 수신한 결과이다. 이는 표 2의 전체 데이터 수신 URI를 적용한 예제로, 사용자는 데이터베이스로부터 전체 라이프로그를 JSON 형식으로 제공받는다.

Fig. 3.

Result of received lifelogs

그림 4는 RESTful API를 이용해 타입별 라이프로그를 수신한 결과이다. 이는 표 2의 데이터 타입별 라이프로그 수신 URI를 적용한 예제로, 라이프로그를 사용자 아이디 및 날짜와 함께 입력한 데이터의 타입별로 수신한다. 데이터 타입은 ‘3dacc’, ‘HR’ 및 ‘GPS’로 나뉜다. ‘3dacc’는 ‘x’, ‘y’, ‘z’이고 ‘GPS’는 ‘lat’, ‘lon’, ‘alt’에 해당한다.

Fig. 4.

Result of received lifelogs by request of datatype

위의 구현 결과는 ‘getlist/’이하의 URI를 조합하여 사용할 수 있다. 사용자는 원하는 데이터 종류, 사용자 아이디, 날짜를 입력하면 해당 라이프로그를 JSON 형식으로 제공받는다.

4.3 데이터 시각화

본 논문에서는 구현 결과를 보여주기 위해 22명의 피험자로부터 약 2달간 수집한 DSEM-Traj2018 데이터셋을 활용한다. 그림 5는 데이터 시각화 설계에 따라 구현된 라이프로그 수집기 대시보드를 보인다. 대시보드의 1번부터 6번까지는 각각 날짜별 라이프로그 개수, 날짜별 누적 라이프로그 개수, 요일별 라이프로그 비율, 시간대별 라이프로그 개수, 데이터 종류별 라이프로그 비율 및 개수, 사용자별 라이프로그 비율에 해당한다.

Fig 5.

Lifelog collector dashboard

그림 6은 데이터 시각화 설계의 사용자 이동 패턴 유사도별 그룹화 결과를 네트워크 그래프를 통해 사용자에게 보여준다.

Fig. 6.

Group network graph by user pattern similarity

그림 7과 그림 8은 사용자의 행동 분류 분포 지도와 사용자의 행동 분류별 데이터 개수 및 비율을 각각 지도와 파이 그래프로 구현한 결과를 보인다.

Fig. 7.

Distribution map of user behavior classification

Fig. 8.

Chart of the number and ratio of user behavior classification

그림 9는 사용자의 이동 궤적의 밀도를 지도로 구현한 결과를 보인다. 이는 구글 지도의 Heatmap API를 통하여 구현한다.

Fig. 9.

Density map of user trajectories

제안 시스템은 사용자의 위치 정보를 수집하고 관리하기 위한 인터페이스를 제공하고, 해당 데이터에 대한 시각화 도구들을 제공한다. 데이터 수집하고 시각화하기 위한 기능들은 ARTIK [14]과 1upHealth[15]와 같이 기존의 데이터 플랫폼에서도 많이 사용된다. 이러한 플랫폼들 역시 RESTful API를 사용하며 수집된 데이터를 효과적으로 보여주기 위한 시각화 도구들도 제공한다. 하지만 ARTIK과 1upHealth와 같은 플랫폼들은 실제 데이터베이스 질의문과 같이 구체적인 유형과 범위의 데이터를 질의하지 못한다. 또한, 수집 데이터의 요약을 제외한 다른 데이터들에 대해서 사용자 맞춤형 시각화 도구를 제공해 주지 못한다.

제안 시스템은 기존의 플랫폼들이 다루지 못하는 유형 및 범위의 데이터를 질의하기 위한 유연한 인터페이스를 지닌다. 또한, DSEM-Traj2018 데이터셋과 이 데이터셋이 지니는 특성을 고려하고 사용자 맞춤형 시각화 도구들을 개발한다. 이러한 유연한 인터페이스 및 맞춤형 시각화 도구 제공은 명확한 요구사항 정의로 이루어질 수 있다. 그 결과, 본 논문은 총 12가지 요구사항 분석을 통하여 5가지 유형의 인터페이스 및 10가지 시각화 도구를 개발하였다. 따라서, 제안 시스템은 기존의 데이터 플랫폼들보다 더 유연한 인터페이스를 지니며, DSEM-Traj2018의 특성에 맞는 시각화 도구들을 제공한다.