3. 라이프 로그 마이닝 플랫폼
3.1. 플랫폼 소개 및 특징
스마트 디바이스들은 다양한 앱을 실행하기 위한 컴퓨팅 파워를 지니고 있으며, 가속도계나 자기장센서, GPS 센서 등이 사용자의 편 의를 위해 장착되어 있다. 하지만 휴대용 기기라는 스마트 기기의 특성상 배터리 존재에 의해 발생하는 전력 자원의 한정성과, 라이프 로그 수집을 위한 장비가 아닌 범용적인 목적의 장비이기 때문에 해당 기기로부터 라이프 로그를 수집하기 위해서는 여러 가지 제약 이 존재한다. 하지만 사용자가 거부감 없이 상시 휴대하고 다니는 기기에서 데이터를 큰 비용 없이 수집할 수 있다는 것은 큰 장점이 라고 할 수 있고, 기존에 제한된 환경에서 일부에 대해서만 수행할 수 있었던 라이프 로그의 영역을 크게 확장할 수 있다.
위와 같은 이유로 인해 라이프 로그 수집 플랫폼에 대한 연구
가 다양한 형태로 존재하여 왔다[15], [17], [27]. 이들 연구들은 특정
연구에 대한 필요에 의해 구축되었거나 디바이스의 로그를 중점적 으로 수집하는 방향으로 제시되어 왔다. 본 연구에서 제시하는 플랫 폼은 더 나아가 특정 실험이나 연구에 특화된 것이 아닌 스마트 디 바이스 로그를 수집하고 상황에 따라 질의 및 설문을 자유롭게 수 행할 수 있도록 지원하는 통합 플랫폼을 제시하고자 한다.
본 연구에서 구축한 라이프 로그 수집 플랫폼은 범용성과 기능 성 측면에서 널리 쓰이는 스마트 디바이스 플랫폼 중 하나인 안드 로이드 플랫폼을 대상으로 수집할 수 있도록 하였으며, 컨텍스트 환
경에 맞는 사용자의 피드백 (feedback) 또는 레이블링을 지원하기
위한 기능을 내장함으로써다양한 실험에서 사용될 수 있는 기초 환 경을 구축하였다. 특히 기존의 많은 라이프 로그 연구에서 이용되었 던 통제된 환경에서의 실험이 아닌 일반인을 대상으로 데이터를 수
22
집하거나 컨텍스트에 기반한 질의를 수행할 수 있도록 플랫폼화를 시도하였다.
[그림 1] 라이프 로그 수집 플랫폼의 구성
위의 [그림 1]은 제시하는 라이프 로그 수집 플랫폼을 도식화한 것이다. 위의 그림에서 확인할 수 있듯이 구성 요소로는 크게 실제 개개의 사용자의 기기에서 라이프 로그를 획득하고, 상황에 따라 질 의를 하는 역할을 수행하는 클라이언트와 클라이언트로부터 데이터 를 수집하고, 관리하며, 설정을 전달하는 서버, 그리고 수집된 데이 터를 기반으로 다양한 분석을 수행하는 것으로 나눌 수 있다.
라이프 로그 수집 플랫폼에서 클라이언트의 역할은 플랫폼에 등 록된 사용자의 디바이스에 앱 형태로 설치되어 실제로 라이프 로그 를 수집하는 역할을 수행한다. 실험 설계상 사용자와의 특별한 인터 액션이 필요하지 않을 동안은 백그라운드 (background)에서 정해진 주기로 디바이스 로그나 컨텍스트 정보를 수집하고, 관찰된 컨텍스 트 정보가 미리 정의한 인터액션을 위한 조건을 만족하였을 때 질 의 및 설문을 디스플레이에 팝업을 통해 알려 줌으로써 수행하도록
23
한다. 서버의 역할은 등록된 클라이언트를 관리하고 연구자와 디바 이스 사용자를 연결해주는 중간자 역할을 수행하며, 클라이언트로부 터 디바이스 로그와 상황 정보, 그리고 설문 정보를 전달받아 보관/ 관리 및 가공하는 역할을 수행한다. 연구자가 원하는 실험 조건에 맞는 대상들을 선별하여, 해당 실험에 대한 설정을 클라이언트에 전 달하고 이를 확인 및 감시하는 역할도 함께 수행한다. 그리고 서버 에 수집된 데이터는 연구에 적합한 형태로 가공된 후 연구자에게 제공된다. 본 연구에서는 라이프 로그 수집 플랫폼에서 수집한 데이 터를 바탕으로 중요 장소 추출과 목적지 예측, 그리고 행위 추론 연 구를 수행하였다.
[그림 2] 라이프 로그 수집 플랫폼 클라이언트 UI
24
위의 [그림 2]는 클라이언트에서 사용자가 접하는 UI이다. 앞서 설명한 바와 같이 평상시에는 백그라운드로 연구자가 설정한 환경 설정으로 디바이스 로그 및 상황 정보를 수집하고, 미리 정의한 앤 터액션 조건에 부합할 시 질의에 대한 응답을 팝업을 통해 주관식 또는 객관신의 응답을 대화창 형태의 UI로 요구한 후 그 응답을 받 는 형태를 사용한다. 클라이언트에서 수집한 데이터는 주기적으로
Wi-Fi가 가능한 시기에 자동으로 서버에 전송된다. 클라이언트의 실
제 구현은 안드로이드 기기를 대상으로 하였으며, 기기에서 제공하
는 각종 센서 정보를 수집하기 위해 MIT에서 배포한 오픈소스 센싱
수집 플랫폼인 funf 라이브러리[85]를 사용하였다.
라이프 로그 플랫폼에서 안드로이드 디바이스로부터 수집하는 데이터는 아래의 [표 1]과 같으며, 수집하는 주기는 연구자가 지정 한 설정에 따라 다르게 설정될 수 있다.
[표 1] 플랫폼에서 수집 가능한 센서 및 기기 사용 정보
센서 정보 디바이스 상태정보 Accelerometer Battery
Gravity Hardware Info Gyro Screen ON/OFF Light Wi-Fi signal strength Linear acceleration 디바이스 사용정보
Location Installed applications Magnetic field Foreground application
Orientation Running applications Pressure Call logs Proximity
Rotation vector
25
라이프 로그 플랫폼에서의 서버의 역할은 개인의 디바이스에 설 치된 클라이언트들을 관리하고, 연구의 목적에 맞는 설정 정보를 목 적에 부합하는 클라이언트에게 알려주고, 알려준 정보를 바탕으로 클라이언트에서 수집된 데이터를 전송 받아 분석이 가능한 형태의 데이터로 변환한 후 연구자들에게 전달하는 역할을 수행한다. 아래 의 [그림 3]은 클라이언트에 전달하는 설정 값의 예시이다. 설정 값
은 JSON (JavaScript Object Notation) 형태로 되어 있으며, 어떤 센서
정보를 수집할 지 여부가 “dataRequests” 항목 하에 나열되어 있고,
각 센서에서 수집할 주기(“PERIOD”)와 주기마다 수집할 시간
(“DURATION”)과 같은 센서의 수집과 관련된 정보를 설정하고, 센서
데이터의 저장 단위와 설정 버전과 같은 클라이언트 운영에 관한
정보를 설정할 수 있도록 하였다. 해당 설정은 “name” 항목의 이름
하에 “version” 항목을 통해 버전관리를 하고, “dataArchivePeriod”에
초단위로 명시된 주기에 따라 데이터를 압축하여 보관하도록 한다.
{
"name": “WM20", "version":5,
"dataArchivePeriod": 1800, "dataRequests":{
"LocationProbe": [
{ "PERIOD": 120, "DURATION": 4 } ],
"ForegroundApplicationProbe": [ { "PERIOD": 10 }
] } }
[그림 3] 라이프 로그 클라이언트 센서 설정 예시
위의 [그림 3]이 디바이스에서 수집할 수 있는 센서 정보나 상
26
황 정보에 대한 설정을 하는 부분이라면, 사용자와 인터액션을 통해 질의나 설문 등을 수행하도록 설정하는 부분이 요구되며 그 예시는
아래의 [그림 4]와 같다. “time” 안의 “type” 항목은 질의를 주기적으
로 할지, 일회성으로 할지 등의 여부를 결정하는 항목이고, “period”
는 주기를, “from”과 “expire”는 각각 질의 시작 시점과 종료 시점의
유닉스 시간을 의미한다. 아래의 예시는 행위 추론 연구에 사용한 설문의 부분으로 1시간마다 주기적으로 질의를 수행하라는 예시이 다. 질의는 설정에 따라 1회성이 되거나, 시간이 아닌 장소나 앱 사 용정보와 같은 다른 컨텍스트에 대해서도 질의를 수행할 수 있도록 한다. 이러한 질의를 하는 컨텍스트의 설정을 다양하게 지원함으로 써 질의의 조건은 상황 정보를 기반으로 하며 특정 위치에 있을 때 질의를 한다거나 인터넷 서핑을 할 때에만 질의를 수행한다는 등의 다양한 시나리오를 가능하게 지원하여 다양한 응용에 대해 활용될 수 있도록 하였다.
{"time":
[{"type":"periodic", "period":3600,
"expire":1417392000, "from":1420070400}]
}
[그림 4] 라이프 로그 클라이언트 레이블링 설정 예시
위와 같이 레이블링 설정이 정해지만 이 시점에 수행할 작업을
정의할 수 있으며 아래의 [그림 5]가 그 예시이다. “depth”는 객관식
질의의 깊이 정도를 의미하고, “main”에는 객관식 질문 내용을 지정
하고, “sub”에는 추가적인 질문 항목을 지정한다. 아래의 예시는 정해
진 상황에서 2단계의 객관식 설문을 수행하도록 정의한 것이다. 주
27
어진 컨텍스트 상황에서 아래와 같이 객관식 설문을 수행하는 것 이외에도 다양한 작업을 정의하는 것이 가능하다. 질의를 연속형으 로 수행하거나, 해당 컨텍스트와 연관된 이미지나 동영상을 이미지 나 동영상 등의 추가 정보를 제공하고 응답을 받는 등의 다양한 활 용법이 존재할 수 있다.
{
"depth": 2,
"main": ["개인유지", "일/집안일", "학습/연구", "자기개발",
"교제활동", "여가활동(컴퓨터/스마트기기)",
"여가활동(오프라인)", "기타활동", "이동"],
"개인유지": ["수면", "휴식", "집에서 식사", "외식", "미용/화장",
"청결/목욕", "음료/간식", "의료", "기타"],
…
"이동": ["이동"],
"sub": ["혼자", "가족", "친구", "연인", "동료", "기타"]
}
[그림 5] 라이프 로그 객관식 설문 설정 예시
위의 과정들을 통해 서버에 데이터가 확보되면, 연구자는 획득 한 데이터를 전달받아 설계하였던 라이프 로그 마이닝 연구를 수행 하게 된다. 플랫폼을 설계하는 과정에서 연구자와 관리자 그리고 사 용자의 역할을 분리함으로써 다양한 상황에서 실험하는 환경을 구 축할 수 있도록 시도하였다. 클라이언트를 설치한 사용자는 관리자 가 관리하고 있는 사용자 집단으로 연구자가 연구를 수행하기 위한 대상을 찾을 수 있는 풀을 제공한다. 기존의 연구에서는 개개의 연 구자가 연구의 목적에 맞는 사용자를 직접 모집하고 실험을 설계하 는 것이었다면, 제시하는 플랫폼을 통해 연구자는 실험을 설계하여 관리자에게 전달하면 이에 적절한 사용자를 플랫폼을 통해 연결하