LBS(Location Based Service) 기반 데이터란 무엇인가요?
LBS(Location Based Service) 기반데이터란 LBS를 고객에게 제공하기 위해서 필요로 하는 데이터를 말합니다. 이 데이터는 모든 LBS의 기초가 되며 어떻게 구성되는지에 따라서 제공할 수 있는 서비스방법과 서비스 품질이 크게 좌우되게 됩니다. 따라서 노하우가 많은 회사일수록 기반데이터를 잘 구성하고 관리하며 외국의 기업들은 잘 구성된 데이터를 돈을 받고 팔기도 합니다.
LBS(Location Based Service)에서는 기반데이터를 어떻게 사용하는 건가요?
LBS는 여러가지 서비스를 제공하는데 대표적인 예로는 길찾기 서비가 존재합니다.
위의 그림에서 출발점과 도착점이 붉은색의 원으로 표시되는데 이 붉은원들을 Junction(연결지점)이라고 합니다. 그리고 Junction을 이어주는 푸른색 선은 “길”을 의미하고 이를 Network이라고 합니다.
※ SK planet에서는 Junction, Network 용어를 사용하지 않고 다른용어를 사용합니다. 이는 지리정보를 제공하는 업체마다 용어의 차이가 발생하기 때문입니다. 여기서는 외국계 지리정보를 제공하는 업체를 기준으로 보편적으로 많이 사용하는 용어를 채택하였기에 Junction과 network이란 표현을 사용하였습니다.
길찾기 서비스를 제공하려면 위의 그림에서 보듯이 최소 적어도 2가지데이터가 필요합니다. 바로 교차점을 나타내는 Junction정보가 필요하고 Junction을 연결해주는 Network 정보가 필요합니다. 하지만이 2가지 데이터만 가지고는 좋은 길안내를 할 수 없습니다. 고객에게 질 높은서비스를 제공하려면 교통정보도 반영해야하고 휴게소, 주유소등 많은 데이터를 서비스하기 좋게 갖추어 놓아야 합니다.
구글에서 제공하는 길찾기 서비스 예
위의 화면은 구글에서 제공하는 길찾기 서비스 수행 결과입니다.
이미지 하단에 보면 “지도데이터 @2013 Google, SK Planet –“ 이라는 문구를 확인할 수 있는데 구글에서 제공하는 길찾기 서비스의 지리정보가 SK Planet에서 제공했다는 걸 알 수 있습니다.
즉 구글에서는 SK Planet에서 제공받은 지리정보를 이용해 자체적인 기반데이터를 생성해서 구글 알고리즘을 통해서 길찾기 서비스를 제공하고 있다고 볼 수 있습니다.
외국업체에서 제공하는 지리정보를 활용하여 인도네시아 길찾기 서비스를 직접 구현
위의 그림은 구글에서 제공하는 "길찾기 서비스" 결과(파란색선)와 직접만든 "인도네시아 길찾기 서비스"를 수행해서 나온결과(붉은색선)를 동시에 구글지도에 표출한 것입니다.
테스트 상황은 아래와 같습니다
- 구글이 사용한 지리정보와 저희가 사용한 지리정보는 둘 다 동일회사에서 만든 데이터 입니다.
- 위의 나타난 지역은 한국이 아니라 인도네시아 입니다.
위의 길찾기결과는 서비스 알고리즘의 차이보다는 생성한 기반데이터의 영향이 큰사례입니다. 기반데이터의 하나의 팩터중 거리에 따라서 이동하는 통행시간등이 구글과 다르게 입력되어 서로다른 경로를 탐색했던 케이스입니다.
객체지향으로 인도네시아 길찾기 서비스 기반데이터 생성
글을 쓰는 현 시점까지 해외를 대상으로 LBS를 제공하는 우리나라 업체는 아직 존재하지 않았습니다. 모든 업체가 한국을 대상으로 서비스를 제공하고 있었고 관련 레퍼런스는 존재하지 않았습니다. 그러던중 SK planet사에서 넥스트리소프트사에게 글로벌 LBS 프로토타입 제안을 요청해왔고 이를 받아들여 글로벌 해외 LBS 프로토타입을 진행하게 되었습니다.
SK plane사는 한국을 대상으로 하는 기반데이터를 생성할때 C로 만든 어플리케이션을 사용하여 기반데이터를 생성하고 있었습니다. 소스를 내려받아 분석을 진행하였는데 전형적인 C로만든 절차지향의 애플리케이션이라 할 수 있었습니다.
길찾기 기반데이터 개념 도메인(SK planet의 실제 도메인과 동일하지않습니다. 이해를 돕기위해서 간략하게 표현해 보았습니다.)
길찾기의 기반데이터는 반드시 2가지 네트워크(network)정보와 연결지점(junction)정보가 필요합니다. 그리고 이러한 데이터를 서비스하기 위해서는 데이터의 분류도 중요합니다. 구글에서는 이를 타일형태로 구성하고 사용합니다. 그리고 우리가 길을가다 볼 수있는 카메라나 주유소등 관련데이터도 구성해야 합니다.
AS-IS 기반데이터 생성방법
AS-IS의 기반데이터 생성방법을 간략하게 정리해서 위의 UML로 표기해 보았습니다. 위의 UML은 실제 AS-IS를 보기 쉽도록 추상화시켜 이해하기 쉽게 표기한 것입니다. 실무는 보다 복잡하며 산출물도 상당히 많은 애플리케이션입니다. 전반적인 흐름을 나타내기에는 충분함으로 이를 깊게표기하지는 않았습니다.
위의 기반데이터 생성기는 기반데이터(지역)를 전역변수로 가지고 있습니다. 그리고 전역변수를 업데이트하는 여러개의 function들을 차례로 수행하면서 전역변수를 업데이트합니다.
위의 UML에 따르면 기반데이터 생성은 아래와 같습니다.
- 수집데이터로부터 기반데이터생성에 필요한 데이터를 추출한다.
- 1번에서 추출된 데이터를 바탕으로 전반적은 도메인데이터(derived Attribute는제외)를 구성한다.
- 1,2번을 순차적으로 수행한 후 LBS에 필요한데이터(derived Attribute)를 계산한다.
- 1,2,3번이 모두 완료되었으면 전역변수에 기반데이터가 만들어져있다. 이를 LBS에 맞도록 데이터를 최종생성한다.
전역변수를 두고 Function들을 순차적으로 호출하는 위의 AS-IS 생성기를 분석하면서 가장 힘들었던점은 위의 각각의 도메인정보(지역, 네트워크, 연결지점, 카메라등)들이 수집데이터에서 어떻게 LBS 기반데이터로 생성되는지 과정을 이해하려면 애플리케이션 전체를 이해하지않으면 알 수가 없었습니다. 예를들어 주유소정보가 어떻게 구성되는지 이해하려면 step1에서 전역변수가 어떻게 구성되었는지, step2에서 전역데이터가 어떻게 구성되었는지 전체를 이해해야 할 필요가 있었습니다.
프로토타입 기반데이터 생성기는 객체지향으로개발
프로젝트를 시작하고 기반데이터를 생성하는 애플리케이션을 만들때 객체지향적인 설계를 시도했고 Java로 구현을 하였습니다.
AS-IS step1의 산출물능 읽어오는 방법을 객체지향설계로 옮긴 예
1. 네트워크
2. junction
기반데이터는 대체로 데이터크기가 큽니다. 메가바이트 단위가 아니라 기가바이트 단위의 데이터를 다루어야하므로 모든데이터를 메모리에 올려놓고 데이터를 만드는것은 불가능합니다. 따라서 각단계마다 데이터를 저장하고 읽어오는 메커니즘이 필요했고 당시 AS-IS에는 비즈니스관련소스와 데이터관리소스들이 서로엮여 있었고 중복이 특히나 많이 발생하였습니다. 가장먼저 각 Step별로 산출물을 관리하는 공통적인 방법을 정의했고 이를 공통화시켰습니다. 위의 UML에서는 “네트워크”, “연결지점”등의 데이터를 가지고오는 방법이 동일함을 볼 수 있습니다.
기반데이터 생성방법
위의 UML은 기반데이터 생성방법 모습을 클래스다이어그램으로 나타낸 것입니다. “파란색 class”로부터 “노란색 class”로 데이터를 만들어 낸다고 이해하시면 됩니다.
위의 UML의다이어그램중 몇가지만 언급을 하도록 하겠습니다.
“기반데이터생성빌더” : 빌더는 데이터를 어떻게 만들어내는지에 초첨이 맞추어져 있습니다. 빌더는 네트워크정보, 휴게소정보, 연결지점등 데이터의 생성방법을 정의합니다.
“기반데이터 생성디렉터“ : 빌더가 How의 역할을 수행한다면 디렉터는 What의 역할을 담당합니다.
예:
- 자동차 디렉터 : 빌더에게 네트워크, 휴게소, 연결지점만 만들라고 요청
- 자전거 디렉터 : 빌더에게 네트워크, 연결지점 정보만만 들라고 요청
위의 디렉터와 빌더는 GOF에 나오는 전형적인 빌더 패턴입니다. 객체지향 설계에 능숙한 선구자들은 자신들의 경험을 바탕으로 자주 반복되는 상황이나 패턴들을 책으로 내놓았는데 GOF의 디자인패턴도 그중 하나입니다.
객체지향으로 기반데이터를 만들어본 내용들을 간략하게 정리해 보았습니다.
