[ ZDNET 컬럼 #1 ]

1. 모바일 검색이 필요한 상황들

며칠 전 오랜만에 지인을 강남역 근처에서 만났었다. 조용히 저녁 식사 겸 반주 한잔을 가볍게 할 만한 곳을 찾을려고 했는 데 마땅히 적당한 곳을 찾을 수 없었다. 다행히도 만난 지인이 워낙 모바일 서비스를 즐기는 분이라 바로 휴대하고 있는 무선 디바이스를 통해 포탈 서비스의 맛집을 검색하여 몇 곳을 찾을 수 있었다. 아마 실생활에서 이렇게 모바일 검색 서비스를 이용하는 분들이 있을 것으로 생각한다. 그런데 문제는 이렇게 검색을 해서 찾은 음식점이 기대했던 것과는 너무 달리 음식맛도 , 서비스도 별로 였다는 것이다. 분명 추천글에는 후회하지 않을 것이라는 글들이 많았는데 결과는 정반대였다. 흔히들 말하는 것처럼 낚인 것이다. 적어도 우리 입장에서는. 대충 자리를 정리하고 다른 곳으로 옮길 수 밖에 없었다.

사실 곰곰히 생각해 보면 포탈 서비스에서 제공하는 맛집이 추천 음식점들에 대한 정보와 추천글 등을 곧이곧대로 믿기는 어렵다. 뿐만 아니라 쇼핑몰에서 제공하는 상품의 상품평도 있는 그대로 믿기 어렵다. 어떤 정보가 실제 믿을 만한 정보일까? 일반적으로 사람들은 맛집을 찾거나 영화를 고르거나 할 때 비슷한 취향과 성향을 갖는 주변의 지인들이 추천하는 정보는 믿는다.  이처럼 앞선 상황에서 무선 포탈 검색 보다는 지인에게 전화를 걸거나 지인을 통한 검색이 가능하다면 이를 통해 얻는 방법이 훨씬 성공율이 높았을 것이다.

이처럼 실생활에서 모바일 검색은 즉시 의사결정을 하거나 상황판단을 하는 상황에서 아주 요긴하게 사용될 수 있다. 이와 같은 모바일 검색은 기존 데스크탑 기반의 검색과는 다른 특징을 갖는다. 기존의 데스크탑에서 이용하는 웹 검색은 주로 특정 문제 해결에 필요한 정보를 검색하여 취득하는 데 유용하다. 이에 반해 모바일 검색은 실제 생활상에서 일어나는 의사결정상에 있어 필요한 신뢰할 만한  정보를 실시간에 제공받고 이를 활용하는 데 유용하다. 가령, 음식점이나 여행지를 추천받거나 영화를 선택하거나 선물을 고르는 상황에서 모바일 검색은 아주 유용하다.

2. 기존의 모바일 검색 서비스들

2.1 기존 검색 서비스의 모바일화

모바일 시장이 확산되면서 이러한 모바일 검색 서비스에도 큰 변화가 예상되고 있다. 먼저 기존의 몇몇 모바일 검색 서비스를 살펴보자.  다음은 기존의 포탈 검색 서비스를 모바일 폰을 통해 접속하고 이용할 수 있게 해주는 서비스들이다. 이들 서비스는 기존 웹 검색의 모바일 서비스 버전이며 검색 후 이에 대한 결과를 모바일 디바이스에 최적화된 형태로 제공해 준다.

사용자 삽입 이미지


-  Google Mobile
Yahoo Mobile
네이버 모바일 검색
다음 모바일 검색 




2.2  전문가에 의한 모바일 검색

기존의 구글이나 네이버처럼 웹 상에서 정보를 수집하여 검색을 제공하는 것이 아니라  전문가가 사용자가 요청한 질문의 답변을 핸드폰 등에 직접 제공해 주는 모바일 검색 서비스이다. 사용자의 요청들에 대한 답변을 전문가가 검색을 하여 가장 최적화된 답을 제공해주기 때문에 기존 검색에 비해 보다 정제되고 검수된 답변을 제공받을 수 있다.

542542.com
미국과 캐나다에서 만 서비스되고 있고 하나의 질문당 0.99$를 받는 유료서비스이다. 질문을 보내면 자체 보유한 데이타베이스와 실제 고용된 전문가(에이전트)가 모바일 폰으로 해당 답변을 보내준다.

사용자 삽입 이미지


ChaCha
무료 서비스로 SMS나 전화, 그리고 웹상에서 질문을 하면 전문가들이 해당 답변을 SMS나 음성으로 전달해 주는 서비스이다.

사용자 삽입 이미지

2.3 실시간 검색 서비스의 태동

지금까지의 모바일 검색은 기존의 검색 서비스를 모바일 디바이스를 통해 손쉽게 활용하는 데 중점을 두었다. 이러다 보니 모바일 검색을 통해 신뢰할 만한 정보를 실시간에 제공하지 못하고 단순히 웹 상의 정보를 모바일 디바이스에서 조회하는 수준의 데이타만을 제공하는 수준에 머물러 있었다.

그러나 최근 들어 구글이나 네이버처럼 웹 상에서 정보를 수집하고 이를 색인한 후  검색을 제공하는 기존 방식과 달리 실시간에 검색을 제공하는 서비스가 선을 보이고 있다. 실제 다음 서비스는 실시간 마이크로블러깅 서비스인 트위터의 정보를 실시간에 검색해 서비스이다. 실제,  다음 서비스에서 특정 키워드로 검색을 한 후 해당 결과를 모니터링 하면 사람들이 특정 검색어를 중심으로 어떤 이야기와 정보들을 교환하는 지 실시간에 파악할 수 있다.

- 트위터 검색 서비스

검색 후 결과 페이지 상에서 실시간에 추가된 내용을 동적으로 추가해 조회할 수 있다.  
사용자 삽입 이미지

- Crowdeye  , 실시간 트위터 검색엔진
MS에서 검색 서비스를 개발하던 전직 임원인 Ken Mos가 개발한 트워터 기반 실시간 검색엔진이다. 검색 결과를 시간축으로 정렬한 후 조회 건수를 함께 보여주고 있다.

사용자 삽입 이미지

3. 미래는 실시간 쇼셜 검색이다.

트위터 검색은 실시간에 사람들이 업로드한 데이타를 검색하여 관련된 결과를 파악할 수는 있지만 아쉽게도 해당 데이타가 신뢰할 만한 데이타인지는 파악할 수 없다. 왜냐하면 데이타를 생성한 사람들이 신뢰할 수는 사람이라 판단할 수 없기 때문이다. 온라인이든 오프라인이든 신뢰라는 것은 바로 사람과 사람간의 관계에서 기인한다. 그런데 현재 트위터 검색은 실시간에 정보를 검색할 수 있지만 해당 결과가 내가 신뢰할 만한 사람이 생성한 필요한 정보인지 구별할 수 없다.

또한 검색 페이지의 랭킹 알고리즘이 현재는 최신 시간 순서이기 때문에 해당 결과의 내용에 기반하여 필요한 결과를 찾기가 어렵다. 따라서 현재 트위터 실시간 검색의 수준은 검색을 통해 특정 정보를 얻기 보다는 관련 주제들에 대해사람들의 성향을 파악하는 데 더 유용하다고 말할 수 있다.

궁극적으로 모바일 검색 서비스는 모바일 디바이스의 특성상 일상생활에서 필요한 정보를 사용자에게 즉시에 제공하기 위해 "실시간(Realtime)" , 그리고 신뢰성있는 검색 결과 제공을 위한 "사회성(Social)" 이라는 특징을 잘 포함해야 한다.

한번의 검색에 수백 만 개에서 수천 만 개의 결과가 나오는 기존의 검색 서비스는 모바일 환경에 유용하지 않다.
모바일 환경에 적합한 검색 서비스는 나와 연결되어 있는 믿을 만한 사람으로 부터 실시간에 필요한 정보를 검색하거나 추천받는 것이다. 이를 위해서는 사회적 관계(Social)에 기반한 새로운 검색 결과에 대한 랭킹 알고리즘이 필요하다. 

가령, 나와 사회적으로 연결되어 있는 사람(Follower 또는 Friend)들이나 가장 질문에 정확한 답을 할 만한 사람에게 실시간으로 질문을 한 후 해당 결과를 수집하고 이를 실시간에 분류하는 것같은 방식의 검색도 가능하다. 또한 내용에 기반하여 전문가들로 사회적 관계를 구성하고 해당 네트웍을 통해 지식을 공유하고 검색한는 모델도 가능할 것이다.

실시간 쇼셜 검색 서비스가 어떻게 발전할 지 확신할 수는 없다. 하지만 현재 구글이나 네이버 등에서 제공하는 기계적 검색 방식이 모바일 환경에 적합하지 않은 것은 분명하다.  또한 일상 생활속에서 필요한 정보를 모바일 디바이스를 통해 실시간으로 신뢰할 만한 사람에게 얻게 되는 서비스야 말로 가장 유익한 쇼셜 서비스 중 하나이다 라고 말할 수 있다.


Posted by 박재현
,

스마트폰을 통한 모바일 환경이 일상화 되면서 웹 클라우드와 모바일 디바이스간의 동기화는 아주 중요한 기본 서비스로 자리잡고 있습니다. 가령, RIM의 블랙베리는 Push Mail을 앞세워 비지니스 맨들의 문화를 바꾸면서 이 분야의 강자로 자리잡았습니다. 이러한 Push Mail의 구현 방법중 하나가 바로 씽크 기술을 이용하는 것 입니다. 간략히 모바일 클라우드와 동기화 서비스의 현황에 대해 정리해 봅니다. ( 참고로 아래 그림들은 테크런치에 올라온 싱크 솔루션에 대한 비교 자료에서 발췌한 것 입니다. 해당 자료는 실제 오픈소스  씽크 솔루션과 플랫폼 제공업체인 Funambol에서 작성한 자료입니다. )


1. 동기화 대상

아래 그림은 모바일 클라우드와 모바일 디바이스간의 동기화 대상을 정리한 것 입니다. 전체적으로는 사진과 주소록, 전자우편,소셜 네트웍,일정 데이타가 현재 주요한 동기화 대상임을 알 수 있습니다. Apple MobileMe와 Funambol, MS Myphone,Nokia OVI,Plam Synergy 에서 이들 데이타를 동기화해주고 있습니다. 아마 다른 서비스들도 조만간 이들 데이타의 동기화를 모두 제공할 것입니다.
 
사용자 삽입 이미지

개인적으로는 앞선 데이타 타입들 외에 사용자 정의 데이타(User defined data type)에 대한 동기화의 지원 여부가 중요한 경쟁요소가 될 것이로 보입니다. 현재 모바일 플랫폼의 개발 환경이 개방화되면서 개발자들이 자발적으로 많은 어플리케이션을 개발하고 있습니다. 또한 핸드폰 뿐만 아니라 디자탈 액자, TV 등 다양한 디바이스간 동기화가 필요하기 때문에 보다 어플리케이션에서 사용자가 정의한 데이타에 대한 동기화 지원이 아주 중요해 질 것으로 보입니다.

사용자 정의 데이타외에 또 하나 중요한 동기화 대상은 외부 서비스 데이타(External service data type)에 대한 동기화입니다. 다음은 현재 각 동기화 서비스서 지원하는 외부 쇼셜 서비스의 대상이다. 현재 플리커와 페이스북에 대한 동기화를 주로 지원하고 있습니다. 그러나 현재 이들 서비스외에 Twitter나 Friendfeed같은 실시간 마이크로블러깅 등 모바일 분야의 Killer Application 들에 대한 지원이 주요한 경쟁력으로 부각되고 있습니다.

사용자 삽입 이미지

2. 비용

대부분의 서비스가 무상으로 제공되고 있음을 알 수 있습니다.  아마 기본 서비스는 무상으로 제공되겠지만 백업이나 기타 다른 디바이스로의 Restore 등 기타 부가 기능을 제공한 프리미엄 버전이 동시에 제공될 것입니다.

사용자 삽입 이미지

3. 동기화 방법

단순히 모바이 디바이스상의 데이타를 웹상의 모바일 클라우드로 백업을 하는 개념의 동기화하면 그 구현은 단순할 것입니다. 그러나 양방향으로 실시간에 이들 데이타를 동기화하기 위해서는 많은 고민이 필요합니다. 특히, 모바일 디바이스는 장비 특징상 대기 시간이 길수록 밧데리가 빨리 소모하며, 고정 IP가 아니라 수시로 IP가 변경되는  특징들 때문에 보다 스마트한 구조를 필요로 합니다. 일반적으로는 기존의 SyncML을 사용하거나 블렉베리 처럼 자체 개발한 표준 방법을 사용하여 개발합니다.

사용자 삽입 이미지

- 자체 개발한 미들웨어와 프로토콜 사용
현재  Push Mail을 가장 먼저 서비스한 RIM의 블랙베리는 기존의 메일 서버와 블랙베리 디바이스 간에 자체 개발한 미들웨어와 프로토콜을 사용하여 기존 메일 서버를 모니터링한 후 새로운 메일을 가져와서 블랙베리 디바이스에 Push를 합니다. 이 때 사용하는 프로토콜은 자체 개발한 것 입니다.  
 
- 기존 표준 방법의 확장 모델
기존의 대표적인 디바이스상의 동기화 방법은 SyncML을 이용하는 것입니다. 따라서 많은 동기화 서비스들은 HTTP(S) 프로토콜과 SyncML에 기반하여 개발합니다. 메일의 경우에는 IMAP IDLE(RFC2177) 커멘트를 사용하여 동기화를 하기도 합니다. IMAP IDLE 커멘트는 디바이스가 메일을 받을 수 있는 상태라는 것을 알려주는 커맨트입니다.

아래 그림은 MS에서 구현한 Direct Push 란 Push mail 모델입니다. Exchange server 2007에 구현되어 있는 이 방법은 Device가 Long-standing https로 동기화를 요청하면 이에 따라 사용자의 메일 박스의 상태를 점검하여 새로운 메일을 Device에 HTTP 프로토콜을 통해 SyncML로 Push를 해 줍니다.

사용자 삽입 이미지

모바일 디바이스를 이용하다 보면 간혹 디바이스를 잃어버리거나 다른 디바이스로 변경을 할 경우가 종종 발생합니다. 이 때, 가장 필요했으면 하는 기능이 바로 기존의 정보를 백업하거나 해당 정보를 다른 디바이스로 쉽게 옮기는 것입니다. 이처럼 모바일 환경이 일반화되면서 모바일 디바이스와 웹 클라우즈, 모바일 디바이스간 동기화는 아주 중요한 기본 서비스로 자리 잡을 것 입니다. 또한 외부 쇼셜 서비스를 비롯하여 새롭게 개발되는 모바일 웹 어플리케이션에서 동기화 기능은 필수적인 기능이 될 것 입니다. 


Posted by 박재현
,

사용자 삽입 이미지
최근에는 여러 이슈들이 있는 것 같습니다. 오라클의 선 인수, 한컴의 공개 매각 진행 , IBM의 클라우드 사업에 대한 본격적 참여, 안드로이드 1.5 등등... 특히, 제가 과거 한컴 씽크프리의 CTO를 했던 전력때문인지 여러 곳에서 한컴 인수에 대한 의견을 많이들 묻고 합니다. 물론 대답하기가 당연히 곤란하기에 그냥 웃고 말았습니다. ^-^

하여간 어차피 중요한 것은 대세가 아닐 까 싶습니다. 이미 우리가 살고 있는 이 세상은 웹이란 거대한 흐름에 의해서 많은 변화를 가져오고 있기 때문입니다. 이러한 거래한 흐름을 한 단어로 표현한다면 연결(Link)라고 표현할 수 있습니다. 웹의 링크에 대한 과학적이자 철학적 분석은 바라바시의 링크 라는 책을 참조하시면 좋을 것 같습니다. 바라바시는 웹 상에서 노드와 노트간의 연결에 대해 많은 이해를 도와주고 있습니다.  결국 웹은 모든 것을 빨아드리며 연결시켜 나가고 있습니다. 아마 이것을 더욱 가속화하는 것이 바로 스마트폰 같은 모바일 디바이스(이하 디바이스)일 것 입니다.

이렇듯 디바이스와 웹간의 상호연결성은 계속해서 확장될 것이며 디바이스는 보다 많은 서비스를 웹과의 상호작용을 통해 제공할 것이며 궁극적으로는 디바이스 자신 또한 웹 컨텐트를 생성해 내는 노드가 될 것 입니다. 실제 이미 안드로이드 OS는 웹 서버처럼 서비스를 감지하고 제공할 수 있는 모델을 제공하고 있으며 이러한 기능들을 통해 디바이스가 서로 상호작용하게 될 것입니다.

이러한 환경에서는 웹상의 노드에 위치하고 있는 서비스간의 데이타 동기화가 중요한 부분으로 대두됩니다. 가령, 중앙의 웹에 자신의 데이타와 프로그램을 모두 올려놓고 디바이스를 통해 필요한 데이타와 프로그램을 부분적으로 이용하고 동기화시키는 것이 필요합니다. 마찬가지로 집에 있는 PC 에서도 동일한 데이타와 프로그램이 필요해집니다.

다소 미흡하지만 이러한 동기화에 대한 기능 명세에 대한 표준화가 있습니다. 바로 OMA DS 표준 또는 Sync ML 입니다. 이 표준은 디바이스간 데이타 동기화에 대한 표준으로 Sync ML 과 6가지 동기화 모델을 제시하고 있습니다. - Fast Sync , Slow Sync , One way Sync from Server , One way Sync from Client , ㅊ , Refresh Sync from Server.

간략히 보면 Fast Sync가 client가 server에게 변경된 데이타만을 동기화하도록 요청하는 데 반해 Slow Sync는 모든 데이타를 동기화한다는 면에서 다릅니다. 또한  One way Sync from Server는 서버가 클라이언트에게 변경된 데이타에 대한 동기화를 요청합니다. 반대로 One way Sync from Client는 클라이언트가 서버에게 동기화를 요청합니다. 마지막으로 Referesh Sync from Server는 서버가 클라이언트에게 모든 데이타의 동기화를 요청하고 반대로 One way Sync from Client는 클라이언트가 모든 데이타의 동기화를 서버에 요청합니다.

실제 OMA DS 표준은 디바이스와 다른 디바이스간의 2 Way 방식의 동기화만을 명시하고 있다는 점에서 제약을 가지고 있습니다. 다시 말해, 실제 수 십대에서 수 백대의 디바이스상에서 다양한 서비스들이 데이타를 동기화하기 어렵습니다. 이를 위해서는 약간의 확장이 필요합니다. ^-^

이러한 동기화 기능을 이용하기 위해서는 기본적으로 Device에 OMA DS 모듈이 탑재되거나 OMA DS 서버에서 제공하는 OpenAPI를 디바이스에서 이용해야 합니다. 실제 디바이스 분야에서는 이미 OMA DS나 독자 싱크 방법을 사용하여 오래전 부터 디바이스상의 데이타를 동기화하는 기능들을 지원하고 있습니다. 가령,  심비안 , 블랙베리 , 안드로이드(현재 개발중) 등은 OMA DS를 사용하고 있으며 MS Windows CE의 ActiveSync를 사용하여 디바이스상의 데이타를 동기화하고 있습니다.

디바이스간의 2 Way 기능을 인트라넷까지 확장하여 기업의 리거시 데이타를 쉽게 모바일 웹으로 개발하기 위한 프레임웍으로 최근 오라클에 팔린 선은  GlassFish Mobile Framework 1.0을 릴리이즈 하였습니다. 이 플랫폼에는 서버측의 GlassFish와 JavaME상의 디바이스 응용 프로그램을 SyncML을 통해 동기화시켜 주는 서비스를 제공해 주고 있습니다. 특히, 재미난 기능으로는 Device상에서 Rest기반의 API를 호출할 수 있게 해주는 JerseyME 라이브러리를 내장하고 있습니다. 디바이스상의 개발자들은 JersyME를 사용하여 Rest API를 직접 호출하여 사용할 수 있습니다. 또한 JerseyME는 Device상에서 Cache 기능을 제공하기 때문에 서버와 연결이 되지 않은 오프라인 상태에서도  디비이스 응용 프로그램을 구동시킬 수 있는 기능을 제공하고 있습니다.

모바일 디바이스의 성장과 더불어 웹 노드간의 동기화는 보다 중요한 요소로 자리잡을 것 입니다. 조만간 국내에서도 멋진 플랫폼이 나올 예정이니 한번 기대해보세요. ^-^

Posted by 박재현
,

사용자 삽입 이미지
안드로이드 1.5의 프리뷰 버전이 릴리이즈되었습니다. 

http://developer.android.com/sdk/preview/


1.5에서는 UI의 전면적인 개선과 더불어 단말상의 반응 속도 및 화면 전환 속도 등 반응 속도를 개선하고 홈스크린 위젯, 가상 키보드가 추가되었습니다. 최근의 터치 인터페이스 등 모바일 디바이스의 인터페이스 트렌드를 반영하여 MID , Netbook 등 다양한 모바일 디바이스 개발시 미려한 UI 개발이 가능하게 되었습니다.  안드로이드 1.5의 주요한 기능들은 다음 링크를 참조하세요.

http://developer.android.com/sdk/preview/features.html


이들 주요 기능 중 구글의 주요한 전략으로 웹과 연동되는 주요한 기능들에 대해 좀 정리해 보고자 합니다. 특히, 웹과 연동되는 API를 통해 보다 상상력이 풍부한 어플을 개발할 수 있기 때문에 디바이스 개발 플랫폼과 웹 플랫폼간의 연동은 아주 중요하다고 생각합니다. 특히, 디바이스상에서 처리할 수 없는 기능들은 더욱 그러합니다.

- 음성인식 프레임웍
- LocationManager
- 구글 어플리케이션 연동
   Presence : Contacts, SMS, MMS, GMail, Email 어플리케이션에서 구글 톡의 Presence 정보 보기 API
   Gmail 메세지의 아카이브, 삭제, 레이블 같은 배치 작업
   유튜브 비디오 업로드 API 
   피카사 사진 업로드 API

아마 위와 같이 구글 웹 플랫폼을 보다 효과적으로 활용하는 API들이 제공될 것으로 생각합니다. 기존의 다른 SDK와 차별화하며 상상력이 풍부한 어플을 개발하는 데 있어 웹 만큼 신선한 재료가 없기 때문입니다.

또한 안드로이드 1.5는 애플의 아이폰SDK, 심비안 등과의 SDK 경쟁에서 한발 나가가겠다는 구글의 의도가 였보입니다.


2008년 12월 5일 SDK1.0 릴리이즈2가 발표된 이후에 불과 4달만에 1.5가 발표되었으니 그 속도가 기존의 심비안과 애플의 아이폰SDK보다 빠릅니다.아마 오픈소스 개발 방법론의 파워 아닌가 싶습니다. 열심히 다운로드 받고 있는 데 이모저모 테스트를 좀 해 봐야 겠네요. SDK가 159M인데 애플SDK에 비하면 감사하네요.^-^



Posted by 박재현
,

최근에 애플은 아이폰 SDK 3.0을 소개를 했습니다. 각각의 기능들을 다른 SDK들과 비교한 자료가 눈에 띠어 공유해 봅니다. - http://i.gizmodo.com/5173865/giz-explains-what-makes-the-five-smartphone-platforms-different. 표를 통해 각 SDK간의 주요 차이를 일목요연하게 정리해 볼 수 있을 것 같습니다.

사용자 삽입 이미지

기능 위주의 비교와 더불어 현재 각 SDK들은 놀라운 속도로 기능과 성능을 업그레이드하고 있습니다. 가히 전쟁이라 할 수 있습니다. 아래 일정은 최근 심비안에서 발표한 2009년 이후의 Release 일정입니다.

사용자 삽입 이미지

2010년까지 3번의 Major Release가 잡혀있는 걸 보면 상당한 변환가 기대됩니다. 또한 기존 심비안 개발자에게 안정적인 일정을 미리 제공함으로써 커뮤니티 개발자의 동요를 막는 효과가 있을 것 입니다. 이처럼 현재 모바일 SDK는 전쟁에 있어 기능의 차별화 더불어 속도는 가장 중요한 경쟁력인 것 같습니다. 이런 걸 디지탈 사시미전략이라고 하죠...^-^  - 디지탈 사시미 전략과 소프트웨어 개발


Posted by 박재현
,