OMA 동향

OMA(Open Mobile Alliance)는 모바일 분야의 응용서비스 및 관련된 기술에 관한 규격을 제정하는 민간표준단체로서 지난 2002년에 노키아가 주도하에 많은 글로벌 이동통신사, 단말 제조사, 솔루션 벤더들이 참여하여 결성되었다. 조직이 결성된 후 초기 몇 년간 다양한 아이템을 중심으로 매우 활발하게 표준화 작업이 이루어졌으나, 지난 2008-2009년의 금융위기와 최근 시장의 중심이 웹으로 옮겨가면서 약간의 슬럼프를 겪고 있는 현실이다. 이는 그동안 표준화의 중심에 있었던 주요 Work Item들이 종료되고 참여업체나 시장의 관심을 끌만한 대체 Work Item이 많이 나오지 않고 있는 것이 주요한 원인이라 하겠다. 본 포스팅에서는 OMA에 관한 간단한 소개와 함께 지금 다뤄지고 있는 주요 Work Item에 대해 정리하고자 한다.

1. 개요

OMA는 주로 모바일 응용서비스에 관련된 기술 규격을 제정하는 표준단체로서 3GPP나 W3C, IETF와 같은 다른 국제 표준단체와 함께 모바일 분야에서 가장 유력한 민간 표준 단체 가운데 하나이다. 3GPP가 IMS를 중심으로 네트웍의 접근 및 제어계층에 대한 기술을 주로 표준화하고, IETF가 프로토콜과 같은 low level 기술의 syntax와 semantics에 관한 기술에 촛점을 맞추고 있으며, W3C가 웹기술의 표준화에 주력을 하고 있는 것 처럼 OMA를 포함한 국제 표준 단체들은 가급적 서로 겹치지 않는 각자의 영역을 구축하고 또 한편으로는 서로 긴밀히 협력하면서 표준화 활동을 전개하고 있다. 다음 그림은 각 표준 단체간의 분야별 포지셔닝을 보여준다.

현재 OMA에 가입해 있는 멤버회사들은 전체 152개 업체로 멤버쉽 등급에 따라 Sponsor Membership 11개 업체, Full Membership 52개 업체, Associate Membership 41개 업체, Supporter Membership 48개 업체로 되어 있다. (자세한 회사명은 요기에서 확인)

OMA 활동을 위해서는 Associate레벨 이상의 멤버쉽을 구입해야 하는데 그 비용은 다음과 같다.

• Sponsor membership : $85,000 USD
• Full membership: $39,000 USD
• Associate membership: $9,000 USD
• Supporter membership: $600 USD

각 멤버쉽에 따라 서로 다른 권한이 주어진다. 정기회의에 참여해 단순 기고 활동 정도의 활동을 전개하기 위해서는 Associate 멤버쉽으로도 충분하지만, OMA 의장단 활동과 같은 보다 적극적인 활동을 위해서는 그 이상의 멤버쉽이 요구된다(세부사항은 membership rights matrix 확인). 또한, OMA 정기회의에 참여하기 위해서는 멤버쉽을 위한 비용외에 별도의 등록비($500 USD)가 필요하다. OMA 정기회의는 1년에 5회 개최되고 있다.

OMA의 조직 체계는 BOD(Borad Of Director)를 최상위로 하여 TP(Technical Plenary), Committee, BoF 그리고 각 Work Group이 존재한다. 각 working group은 그 산하에 work item별로 다시 여러개의 Sub working group을 둘 수 있다.

그림에서 파란색으로 칠해진 working group은 horizontal working group으로 어느 특정한 work item에 국한되지 않고 모든 work item과 관련되어 있는 곳이다. 예를 들어, 하나의 work item이 승인되어 표준 작업에 들어가게 되면 REQ에서 해당 work item에 대한 요구사항 표준을 작성하고, ARC에서 이를 받아 Architecture 표준 작업을 하게 된다. Architecture 단계가 종료되면 각 working group(오렌지색)에서 technical specification(TS)에 대한 표준을 진행하고 해당 표준이 마무리될 시점에서 REL와 IOP와 함께 해당 Enabler의 release package와 inter-operability test에 관한 표준 작업을 진행한다. 물론, 일반적인 프로젝트 진행에서와 마찬가지로 Enabler가 technical specification 단계라 하더라도 RD(Requirement Document)나 AD(Architecture)에 대한 수정은 이루어질 수 있다. 그림에 나와 있는 각 working group에 대한 대략적인 내용은 다음과 같다(자세한 내용은 OMA포털의 Working Groups and Committees를 참조).

• ARC(Architecture): OMA의 전체 architecture와 각 enabler의 architecture가 조화를 이룰 수 있도록 각 working group에서의 architecture 작업에 대한 조언을 해주고 architecture 문서를 검수함.
• REQ(Requirement): OMA 내의 각 enabler간 상호운용성과 가용성을 유지하기 위해 요구사항 관련 조언을 하거나 문서를 검수함.
• REL(Release and Planning Management): OMA의 각 enabler를 release하기 위한 절차 및 관련 내용을 정의하고 이에 근거하여 각 enabler에 대한 산출물을 관리.
• IOP(Interoperability) OMA내의 각 enabler가 end-to-end 서비스를 제공할 수 있기 위해 그리고 각 enabler간의 상호운용성을 보장하기 위한 테스트 절차 및 이와 관련된 내용을 정의함.
• BCAST(Broadcasting): 모바일 방송 서비스 관련 기술
• CD(Contents Delivery): 정보(컨텐츠)를 단말로 전송하기 위한 Push/Pull 기술
• COM(Communication): Communication 서비스(i.e., IP 메세징, 주소록, Presence, Email, 등) 관련 기술
• DM(Device Management): 모바일 단말 및 응용 서비스 관리를 위한 기술
• DRM(Digital Rights Management): 모바일 단말에서 컨텐츠 및 단말의 생명주기 관리를 위한 서비스 레벨의 기술
• LOC(Location): LBS 기반 서비스 제공을 위한 관련 기술

2. 주요 Work Item

OMA에서 다루고 있는 모든 work item을 나열하기엔 너무 많아, 본 포스팅에서는 개인적인 판단에 주요 work item이라고 생각하는 것들만 언급하였다. 아래에 언급된 work item외에 다른 모든 work item을 확인하고자 하는 경우 OMA 포탈의 Current OMA Work Program을 확인하기 바란다.

RC-APIs
OMA ARC working group에서 작업중인 work item으로 2010년 12월에 시작하여 RD와 TS를 동시에 작업중에 있으며 2012년 7월에 종료 예정이다.

RC-APIs는 GSMA RCS에서 표준작업 중인 RCS 시스템이 외부와 연동할 수 있기 위해 필요한 Open API를 정의한다. 이는 특히, think client를 수용하기 위해 RCS의 UNI/LongTail APIs의 요구사항을 수용하였다. HTTP REST 기반으로 이루어져 있으며 3rd-party 서비스 사용자가 RCS 사용자와 동일한 사용자 경험을 가질 수 있도록 하는 기능에 촛점을 맞추고 있다. 이밖에 3rd-party 서비스 및 사용자에 대한 인증 시 oAuth를 고려하도록 하고 있으며 데이타 보안 측면에서 MSISDN과 같은 사용자의 ID가 노출되지 않도록 하는 기능을 포함하고 있다. (RCS-e 관련 세부 내용은 GSMA RCS-e v1.1 참조)

RC-APIs의 use case를 살펴보면 3rd-party 서비스에서 단순히 RCS의 기능을 사용하는 것 외에 기업 사용자를 고려한 광고 플랫폼이나 부가서비스를 제공하는 채널로의 진화를 OpenAPI의 개념에 포함시키고 있음을 짐작할 수 있다.

CAB APIs
OMA ARC에서 작업중인 RC-APIs는 RCS NAB(Network Address Book)의 기능을 수용하고 있다. RCS의 NAB는 CAB과 비교하면 주소록의 저장/복원/조회 정도의 단순한 기능만을 제공하고 있기 때문에 RC-APIs에서는 CAB이 가지는 다양한 기능을 외부로 표현하는 데에 한계를 가진다. 이러한 이유로, ARC에서는 CAB의 OpenAPI를 별개의 표준작업으로 진행하고 있다. CAB APIs는 2011년 1월 시작하여 2012년 8월에 종료될 예정이다.

참고로 CAB APIs가 포함하는 기능은 다음과 같다.

• 주소록 및 PCC(Personal Contact Card) 관리
• 주소록 및 PCC 변경 통보
• 주소록 및 PCC 검색(non-CAB 포함)
• PCC에 대한 Contact View 관리
• PCC 접근 권한 관리
• vCard 포맷 지원
• non-CAB 서비스로부터의 주소록 Import
• 주소록 및 PCC 공유
• Contact 상태 관리
• 주소록 동기화
• Non-CAB 서비스에 대한 주소록 동기화

REST APIs

OMA TP의 "One API - One WID" 정책에 따라 ParleyREST 1.0과 2.0으로부터 API들을 각 WID별로 세분화 하기로 하였다. 이에 따라 2011년 5월부터 각 WID별 REST기반 API 표준작업이 진행중이며 이는 2012년 3월까지로 예정되어 있다. 여기에 포함되는 각 WID는 다음과 같다.

Party 1.0, 2.0으로부터 분리된 WID	RC API로부터 분리된 WID
Short Messaging Multimedia Messagin Payment Terminal Location Device Capabilities Terminal Status Third Party call Call Notification Audio Call Presence Address List Management	Chat Notification Channel File Transfer Image Share Video Share

CPNS 1.1

OMA CD working group내에서 진행중이며 현재 CPNS 1.0을 마무리하고 CPNS 1.1에 대한 RD를 작성중에 있다. CPNS(Converged Personal Network Service)는 CPNS gateway의 역할을 하는 CPNS 모바일 단말을 통해 네트웍 상에서 제공되는 서비스를 네트웍 기능이 없는 제2, 제3의 단말로 제공하기 위한 서비스 및 관련 기술이다.

CPNS 1.1은 2011년 7월에 시작하여 2012년 9월까지로 예정되어 있다. CPNS 1.1은 Non-CPNS 단말 지원 기능과 ETSI M2M 단말 연동 기능, 그룹 서비스 및 위치기반 서비스를 포함한다. 각 항목에 대한 세부사항은 다음과 같다.

Non-CPNS Device proxy Support	ETSI M2M 연동
UPnP, DLNA 단말 지원 PNE/PN GW 기능 추가	ETSI M2M G/W와 CPNS G/W간 기능 맵핑 ETSI M2M I/F와 CPNS G/W I/F 맵핑 ETSI M2M 서비스 프로파일과 CPNS 서비스 프로파일 맵핑
Enhanced Service Group	Location-incorporated Zone based Service
Service 그룹 관리 예) 특정 그룹원 및 단말특성에 따른 서비스 관리 기능	위치기반 서비스 지원

CAB 1.1, S-CAB 1.0
CAB 1.1과 S-CAB1.0은 모두 OMA COM working group 산하에서 표준작업이 진행중이며 두 work item은 비슷한 요구사항을 공유하고 있지만, architecture 및 technical specification 관점에서 다른 접근 방법을 택하고 있다. CAB 에 관한 자세한 내용은 OMA CAB(Converged Address Book) 소개를 확인하기 바란다.

EVVM 1.0
EVVM(Enhanced Visual Voice Mail)은 OMTP라는 다른 표준화 단체에서 작업중이던 VVM 1.0을 OMA에서 가져와 작업중인 것으로 VVM 1.0 보다 많은 기능을 포함하고 있다. Email이 활성화되어 있는 국가인 미국회사들을 중심으로 표준작업이 이루어지고 있으며 주요 기능은 다음과 같다.

• 착신  call-id 기반의 prompting(예: 인사메세지)
• 시간에 따른 클라이언트 동작 설정
• 첨부 이미지 렌더링
• 서비스 활성/비활성화에 대한 망 요청 처리
• Email to Fax
• Voice Mail to MMS 등

지금까지 위에서 언급된 work item은 주로 OMA의 COM working group에서 다뤄지고 있는 것으로서, 다른 working group에서는 이밖에도 많은 work item들이 논의되고 있다. 

3. 맺음말

이제 OMA가 발족한 지 10년이 되어가고 있다. 개인적으로는 2007년 부터 겨우 4-5년 정도. 그것도 full time이 아닌 part time으로 참여했던지라 아직은 부족함이 많은 표준화 전문가(?)의 입장에서 보자면, 표준화라는 것도 결국 시장의 부침과 밀접하게 관련이 있어 보인다. 피처폰 중심에서 스마트폰 중심으로 시장의 트렌드가 넘어가고, 이동통신사 중심에서 단말 제조사와 웹서비스 제공자로 시장의 주도권이 넘어가면서 한때 이동통신사 중심의 생태계에서 그들 중심으로 뭉쳤던 표준화시장에도 거센 변화의 바람이 불고 있다.

그림에서 보듯이 최근 들어 OMA에 참여하는 인력과 회사의 수가 2008년 대비 30%정도 감소하였다. OMA가 표준화 시장에서 모바일 응용 서비스라는 확고한 자리를 가지고 있기 때문에 조직을 폐쇄하거나 하는 일은 없겠지만, 적어도 많은 업체의 공감을 불러 일으킬 수 있는 신규 work item의 부재에 대해서 그리고 OMA의 여전히 이동통신사 중심의 분위기에 대해서는 BoD에서도 문제의식을 가지고 있는 것으로 보인다.

개인적으로는 짧은 기간이나마 몸을 담고 있는 회사이외의 또 하나의 조직이기도 하기에, OMA가 당면한 문제를 지혜롭게 극복하고 모바일 응용 서비스 분야에서 insight를 가진 표준화 조직으로 거듭날 수 있기를 바란다.


-- Red Mouse

OMA CAB 정기회의: 2011년 11월 6일-11일

지난 11월 7일부터 5일간 중국 북경에서 OMA(Open Mobile Alliance) 정기회의가 개최되었다. 이번 정기회의에는 이통사와 솔루션 업체, 단말 제조업체를 포함하여 전 세계 51개 업체에서 184명이 참여하였다. 이번 포스팅은 OMA 분과 가운데 COM(Communication) WG 내의 CAB(Converged Address Book) SWG(Sub WG)의 동향과 이슈에 대해서 정리해 보고자 한다.

현재 CAB 분과에서는 기존의 CAB 1.0 architecture 기반위에 최근에 시장에서 이슈가 되고 있는 몇가지 기능들을 추가하여 표준화가 이루어지고 있는 CAB 1.1과 CAB 1.0의 요구사항과 함께 CAB 1.1과 마찬가지로 몇 가지 기능들을 추가하면서 architecture 관점에서 다르게 접근하고 있는 S-CAB으로 나뉘어 표준화가 진행되고 있다. 한편, 기존 CAB 1.0에 대한 Maintenance는 이 두 개의 WI(Work Item)과는 별개의 SWG으로 구분되어 진행되고 있다.

S-CAB 1.0 


지난 주에 있었던 S-CAB SWG 정기회의에서는 주소록 데이타의 merge process에 대한 기술적 이슈가 제기되었다. CAB 1.0과는 달리 CAB 1.1과 S-CAB 1.0에서는 외부의 3rd-party 서비스와 SNS에 대한 연동기능이 추가되어 CAB 사용자는 CAB 서비스에 존재하는 프로파일 정보(PCC)를 외부 노드로 전송(Export)하거나 외부 노드에 존재하는 자신의 프로파일정보를 CAB으로 받아올(Import) 수 있게 되었다. 이러한 데이타의 교환은 사용자의 프로파일정보에 국한되지 않고 사용자 주소록 상의 contact information으로 그 대상이 확장될 수 있다. 이러한 연동 과정을 통해, 외부 노드로 부터 유입된 데이타가 사용자의 주소록에 이미 저장되어 있는 데이타와 중복될 수 있는 가능성이 존재한다. 예를 들어, contact information에  10개의 필드가 존재하는 경우 인입된 데이타와 주소록에 이미 저장되어 있는 데이타의 10개의 필드값이 모두 일치하지 않는 한, 시스템의 입장에서 이 두 데이타가 동일한 사람임을 자동으로 인지할 수 없으므로, 사용자의 CAB 주소록에는 동일한 contact의 서로 다른 두 값이 서로 다른 레코드로 존재하는 것이다.

이는 곧 기술적으로는 외부의 갱신된 XML 데이타의 내용과 CAB 에 저장된 사용자의 데이타의 불일치가 발생하는 경우 사용자가 이를 인지하고 UI 상호작용을 통해 유효한 데이타를 선택할 수 있는 절차가 있어야 함을 의미한다. 동시에 사용자에 의해 'confirmed' 된 데이타나 'updated'된 내용을 별도로 표시함으로써 CAB Client가 이를 인지할 수 있도록 해야 한다. 이와 같은 내용을 반영하기 위해 곧 Contact Card 관련 XML schema에 대한 변경작업이 있을 것이라 예상된다.

주소록 데이타의 Merge-Update에 관련된 이슈는 아직 CAB 1.1에서는 제기되지 않았으나, CAB 1.1이 S-CAB 1.0 과 거의 동일한 요구사항을 가지고 있으므로 조만간 CAB 1.1에서도 유사한 논의가 있을 것이라 생각된다.

CAB 1.1

Subscription Invitation
CAB 1.1에서의 가장 큰 이슈는 다음의 요구사항에 대한 해결책을 모색하는 과정에서 발생되었다.

CAB-SUBS-002: The CAB Enabler SHALL allow a CAB User to invite other CAB users to subscribe to his/her Published Contact Card information based on service provider's policy.

즉, 이 기능은 Subscription Invitation 기능으로서 CAB 사용자가 다른 CAB 사용자로 하여금 자신의 PCC를 Subscription하도록 '초대'하는 기능으로써, 요청 메세지의 전달 방향 측면에서 Contact Subscription과 개념적인 측면에서 매우 다르다. 트위터로 표현하자면, Contact Subscription은 다른 사용자를 'follow'하는 것이고, Subscription Invitation은 다른 사용자로 하여금 나를 'follow'하도록 초대하는 기능이라 할 수 있겠다.

삼성의 경우 이 요구사항을 구현하기 위해 위해 기존 CAB 1.0에서 이미 정의되었던 절차인 Contact Subscription 절차를 재사용(SIP SUBSCRIBE사용)하자는 제안서를 제출했으나, Contact Subscription과 Subscription Invitation은 그 개념이 정반대인 관계로 SIP SUBSCRIBE를 사용하는 것이 적절하지 못한 재사용이라는 이유로 기각되었다. 또한, SIP SUBSCRIBE 자체로 Contact Subscription과 Subscription Invitation을 구분하기가 모호하다는 점도 지적되었다.

이와는 다른 솔루션으로 RIM에서 제출한 다른 제안서에서는 CAB 1.0의 Contact Added 절차와 매우 유사한 절차(SIP MESSAGE 사용)를 제안하고 분과 내에서 광범위하게 동의를 얻었으나 결국 삼성의 반대로 채택이 무산되고, 두 개의 솔루션을 놓고 e-Vote를 가지기로 하였다.

분과내에서 실행한 straw poll의 결과가 참여한 업체들간의 RIM의 솔루션이 5:1로 우세했던 것으로 미루어, 2주 후에 있을 e-Vote에서는 후자가 채택될 것으로 예상된다.

Direct Interface

CAB 1.1의 Client 와 Server간 새로운 Interface(CAB-2)가 제안되었다. 이는 CAB XDMS내의 Feature Handler App Usage를 사용하여 Client 와 Server간 Operation을 전송하는 것과는 별개로 Feature Handler내에 정의되어 있는 Operation을 HTTP를 이용해 Client와 Server간 직접 전달하자는 내용을제안한다. 이에 해당하는 Operation으로는 Contact Share, Import non-CAB AB data, Import External Profile이 있다.

개인적으로는 CAB 이 XDMS에 너무 의존적으로 설계되어 있어 매우 빈번하게 발생할 것으로 예상되는 Document 의 Read/Write process에 의해 시스템의 효율성이 떨어질 것을 우려하고 있기때문에 CAB-2 인터페이스의 제안은 타당해 보였다. 그러나, 삼성에서 동일한 기능을 위한 두 개의 인터페이스는를 정의하는 것에 대해 강한 반대의사를 표명하여 채택되지는 못했다. 이에 관한 기술적인 논의는 Open issue로 남게 되어 향후 계속 논의가 이루어질 것으로 보인다.

지금까지 지난 주에 CAB 분과(CAB 1.1, S-CAB 1.0)에서 있었던 주요 기술적 이슈에 대해서 알아봤다. CAB 1.1은 원래의 일정이 지연되어 5개월 정도 TP(Technical Plenary)에 slip request를 하였고 이에 따라 릴리즈 패키지 승인 목표 날짜가 내년 9월로 연기되었다.

이번 정기 미팅에 참여한 업체는 CAB 분과와 S-CAB분과를 포함하여 다음과 같다.

• Operator: China Mobile, Orange, Forapolis, Telefonica SA
• Solution Vendor: Ericsson, Alcatel-Lucent, Hansol, ZTE, Huawei, NEC
• Handset: LGE, RIM, Samsung

다음 OMA 정기회의는 2012년 2월 8일부터 일주일간 하와이에서 개최될 예정이다.


-- Red Mouse

OMA CAB(Converged Address Book) 소개

기존의 단말 주소록은 사용자 입장에서 단말에 저장되어 있고 다른 사람과 공유되거나 노출될 가능성이 거의 없는 폐쇄된 정보였다. 다만, 단말을 분실하거나 또는 단말을 교체하는 경우를 고려하여 네트웍 어딘가에 백업이라는 개념으로 주소록 정보를 저장해 놓고 나중에 다운로드하는 형태의 서비스는 제공되고 있었다. 대다수의 이동통신사와 많은 WSP(Web Service Provider)는 사용자가 자신의 주소록을 웹 서비스 계정에 백업하고 웹상에서 직접 편집하여 다시 동기화 시키는 등의 서비스를 제공해 왔다. 그 가운데서 Plaxo 같은 서비스는 일찌감치 사용자의 주소록 그 자체를 타겟팅하여 사용자가 자신의 주소록을 쉽게 백업하고 편집할 수 있게 해주는 웹 서비스를 제공해 왔다.

최근 들어 iPad와 Galaxy Tab을 비롯한 다양한 형태의 테블릿들이 쏟아지면서 한 개 이상의 단말을 사용하게 되는 사용자가 차츰 생겨나기 시작했고 테블릿이 문자나 전화통화와 같은 커뮤니케이션 용도로도 사용될 수 있게 됨에 따라 사용자 사이에 멀티디바이스 환경이 차츰 자연스러운 현상으로 자리잡아가게 되었다. 그리고 아직은 초기시장이고 그 개념을 잡아가고 있는 스마트 TV의 등장은 이러한 현상을 가속화 시키게 될 것이다. 애플의 경우 자사에서 제공하는 iCloud 기능을 이용해 사용자가 소유한 iPhone, Mac, iPad와 같은 자사의 제품들 간의 데이타를 포함한 환경이 동일할 수 있도록 동기화 기능을 제공하고 있다.

멀티디바이스에 대한 사용자의 요구와는 별도로 다양한 형태의 소셜서비스의 등장과 함께 '공유'라는 개념이 새삼스럽게 사용자들간의 공감을 얻고 있다. 사람과 사람간의 개인정보를 공유하고 경우에 따라 주소록 정보 까지도 공유할 수 있다는 것에 대한 저항감이 점차 감소하게 되는 것이다. 페이스북이나 트위터 같은 대표적인 소셜 서비스는 내가 친구를 맺거나 팔로우하는 상대방의 프로필 정보를 상대방이 공유한 정도 만큼 조회할 수 있다. 또한, 사용자 간에 컨텐츠를 공유할 수 있게 되고 그동안 매우 사적인 영역이라고 간주되어 왔던 위치정보까지도 사용자 스스로 공개하기도 한다. 국내에서 2000만의 사용자를 거느리고 있는 카카오톡은 다른 카카오톡 사용자에게 나의 주소록에 등록되어 있는 누군가를 추천할 수 있는 기능을 제공한다.

앞으로 단말주소록은 공유(소셜)와 멀티디바이스라는 서비스 진화에 있어서의 큰 패러다임을 반영하면서 진화하게 될 것이다. 지난 2009-2010년 시기에 우후죽순 처럼 시장에 나오기 시작했던 소셜 주소록 어플리케이션 들은 이러한 움직임을 반영한다. 당시 대부분의 소셜 주소록은 기존의 단말 주소록을 중심으로 페이스북이나 트위터를 연동하여 페이스북 친구와 트위터 팔로워등을 통합하려하거나 그 가운데 삼성의 소셜허브와 같은 서비스는 페이스북이나 트위터의 타임라인을 직접 모바일 단말로 끌어서 사용자에게 보여주려는 시도를 보여왔다. 이유야 어찌됐건 아쉽게도 그들 가운데 뚜렷하게 시장을 장악한 소셜 주소록 서비스는 아직은 없어보인다. 하지만, 페이스북이 웹을 기반으로 하나의 플랫품이 되어 가고 있듯이 모바일 기반의 개인화 플랫폼에 대한 니즈는 여전히 살아있다고 믿고 있다. 단말 주소록은 사용자가 모바일 단말 상에서 실행하는 모든 커뮤니케이션의 시발점으로 모바일 단말에서 개인화된 플랫폼으로 진화할 수 있는 가장 큰 잠재력을 가지고 있기 때문이다.

이러한 관점에서 대략 2007년부터 지금까지 진행되고 있는 OMA(Open Mobile Alliance)의 CAB(Converged Address Book) 표준을 간과할 수는 없을 것 같다. OMA CAB은 1.0을 마무리하고 현재는 CAB 1.1과 S-CAB(Simplified CAB) 1.0에 대한 표준화를 진행하고 있다. S-CAB 1.0은 CAB 1.1과 동일한 요구사항을 가지고 있으나 다른 architecture를 이용해 표준화를 구현중에 있다.

이번 포스팅은 이 가운데 OMA CAB1.0의 주요 기능과 CAB 1.1에서 새롭게 포함된 주요 기능들을 기술해 보고자 한다. 참고로, 각각의 기능들에 이해를 돕고자 필요한 경우 페이스북의 유사한 기능과 비교하여 기술하였다.

1. PCC(Personal Contact Card) 및 Contact View: 접근권한 관리

OMA CAB은 PCC(Personal Contact Card)라는 개념을 제공한다. PCC는 페이스북으로 하면 개인 프로파일 정보로서 대략 다음과 같이 구성된다.

• 성명/별명
• 주소정보
• 위치정보
• 연락정보: 전화번호, SIP URI
• 생일, 기념일
• 성별
• 언어
• 홈페이지
• 취미, 관심사
• 경력정보
• 기타

CAB 사용자는 누구나 자신의 PCC를 작성할 수 있고 또한 외부에 공개할 수 있다. PCC를 외부에 공개할 때는 Contact View라는 개념의 filter를 쓰게 되는데 이는 사용자가 자신의 PCC의 어떤 정보를 얼만큼 누구에게 공개할 것인가라는 것을 결정할 수 있게 해준다. 곧 페이스북의 프라이버시 정책에 해당하는 것으로 네가지 경우의 수(Friends, Friends of Friends, Public, My Own)만을 제공하는 페이스북 보다는 훨씬 더 많은 경우의 수를 만들어 낼 수 있다는 것이 특징이다. PCC의 개념을 도시하면 다음과 같다.

Contact View 라는 filter를 거쳐 다른 CAB 사용자에게 공개된 PCC를 Published Contact Card라 한다. 즉, Published Contact Card는 맞춤형 명함 같은 것이라 생각해도 무방하겠다.

2. Contact Subscription : 개인 프로필 공유
CAB 사용자는 다른 CAB 사용자의 PCC를 조회(Subscription)할 것을 요청할 수 있다. PCC 조회 요청은 상대 CAB 사용자가 이를 수락하거나 거부함(reactive authorization)으로써 완성된다. PCC 조회 요청을 수신한 사용자는 상대방이 자신의 PCC를 열람할 때 노출할 정보의 양을 Contact View라는 프라이버시 정책을 이용해 제어한다.

이러한 과정은 페이스북에서 친구를 맺는 과정과 동일하다. 친구를 맺은 두 사용자는 서로의 프로필 정보를 조회할 수 있으며, 어느 누군가의 프로필 정보가 변경되면 해당 사용자와 친구를 맺고 있는 다른 사용자에게 그 변경 사실이 통보된다. CAB에서 이렇게 통보된 정보는 수신자의 사용자 환경 설정에 따라 수신자의 단말에 자동으로 또는 수동으로 저장된다. 상대 CAB 사용자의 변경된 프로필 정보가 자동으로 적용되도록 설정을 한 CAB 사용자라면 해당 CAB 사용자의 주소록에서 '친구' 관계를 맺고 있는 다른 CAB 사용자의 프로필 정보는 항상 최신정보라고 할 수 있다. 이 기능은 기존 단말 주소록에서 일일이 사용자가 주소록 정보를 입력하고 저장했던 방식에 비해 매우 사용자에게 유용한 기능이 될 것이라고 생각된다. 예를 들어, 더이상 사용자는 자신의 단말 주소록에 있는 상대방의 전화번호를 수동으로 입력하거나 해당 정보가 오래되어 아직도 유효한 지에 관한 걱정을 하지 않아도 될 것이기 때문이다.

3. CAB capability 정보
CAB 사용자의 단말 주소록에 저장되어 있는 특정 대상이 CAB 사용자가 되었을 때, 이 사실이 CAB 사용자에게 통보될 수 있어야 한다. 이는 CAB 사용자가 자신의 단말 주소록 상의 리스트에서 CAB 사용자와 일반 사용자를 구분할 수 있음을 의미한다. 이는 CAB 사용자가 단말 주소록의 특정 상대방에게 CAB 서비스에서 제공하는 기능을 사용할 수 있는지의 여부를 알수 있게 해주는 것이기도 하다.

4. 복수 단말 지원(동기화)
CAB은 네트웍에 존재하는 사용자의 주소록으로서 CAB 사용자는 언제나 자신의 단말 주소록을 네트웍에 업로드하고 다운로드할 수 있다. 이는 사용자가 복수 단말을 가지는 경우, 해당 복수 단말간의 동일한 주소록 환경을 구현할 수 있음을 의미한다. 각 단말의 CAB 클라이언트와 CAB 서버간의 주소록 동기화는 사용자의 설정에 따라 주기적으로 자동 또는 수동으로 수행된다.

5. PCC 또는 주소록 공유(PCC or Contact Share)
CAB 사용자는 자신의 PCC나 자신의 단말 주소록 상의 특정 상대방정보를 다른 CAB 사용자와 공유할 수 있다. 단말 주소록의 특정 대상의 정보를 공유하는 기능은 기존 피처폰에서 SMS/MMS를 통해 제공하던 서비스와 동일하다. PCC 공유의 경우 마치 명함을 교환하는 것과 같은 맥락으로 이해를 할 수 있다. 대신, CAB 사용자는 자신의 공유할 PCC 정보를 제한하고 상대방에 따라 공개 여부를 설정할 수 있다는 것이 일반적인 '명함교환'과 다른 점이다. PCC 공유 기능은 단순한 일회성 정보 제공이라는 측면에서 PCC 조회 요청과는 구분된다.

6. 사용자 검색(Contact Search)

CAB 사용자는 동일한 CAB 서비스 도메인뿐만 아니라 외부 서비스에서도 사용자를 검색할 수 있으며 검색된 대상을 자신의 CAB 주소록에 저장할 수 있다.

7. 주소록 Import/Export
이는 오래전부터 제공되던 통상적인 주소록 백업 서비스에서 Outlook을 연동하거나 파일형태의 주소록 정보를 읽어들인다거나 하는 것과 동일한 기능이라고 볼 수 있다. 사용자는 이렇게 검색된 대상을 CAB 주소록에 저장할 수 있다.


8. CAB 1.1 추가 기능
2010년부터 시작된 CAB 1,1에 대한 표준화가 진행중에 있다. 현재까지 요구사항 단계가 완료되었으며 아키텍쳐와 기술표준(AD, TS) 작업을 동시에 진행중에 있다. 오는 12월부터는 이들 산출물에 대한 일관성 검토(Consistency Review)가 진행될 예정이다. 다음은 이미 완료된 CAB 1.1 요구사항에서 새로 추가된 기능들을 나열한다.

• 연동 포맷 확장 : vCard이외의 포맷으로 구성된 주소록 Import/export
• 다른 CAB 사용자가 자신을 단말 주소록에 포함시킨 경우 이 사실을 통보
• 단말의 CAB 주소록 관리
• CAB 주소록에서 삭제된 정보 복원
• 마지막 적용된 명령에 대한 복원(roll-back)
• Favorite Contact 관리 및 멀티디바이스 적용
• 대화 이력 동기화(자동 또는 수동)
• 특정 contact와 연관된 대화 이력 및 최근 activity 정보 조회
• CAB 사용자의 non-CAB 서비스에 저장되어 있는 컨텐츠 관련 정보 관리
• 분실단말에 대한 접근 권한 인증
• 자신의 PCC에 대한 조회요청을 할 수 있도록 상대 CAB 사용자 초대
• 다른 CAB 사용자로부터의 PCC 조회 요청(PCC Subscription) 자동 수락/거부
• 3rd-party 서비스로부터(에 대한) PCC 정보 회득 또는 제공
• 3rd-party 서비스에 저장되어 있는 CAB 사용자 자신의 PCC에 대한 조회 요청(PCC Subscription)
• 단말 주소록에 있는 상대방(contact)의 social network 정보 조회
• 단말 주소록에 등록할 새로운 CAB 사용자 추천
• 단말 주소록에 저장되어 있는 CAB 사용자간의 관계 정의(강제적 정의일 수도 있고 사용자에 의한 정의일 수도 있음)
• 단말 주소록에 저장되어 있는 CAB 사용자 간의 관계 조회
• 단말 주소록에 저장되어 있는 CAB 사용자의 social network에서의 활동 내역 조회
• CAB 사용자에 대한 서비스 추천
• CAB 사용자에 대한 Mutual connection 정보 제공
• 단말 주소록에 등록되어 있는 CAB 사용자에 대한 공개 컨텐츠 공유

CAB 1.1에 새롭게 추가된 많은 기능들은 현재 시장에서 이슈가 되고 있는 소셜 네트웍 서비스의 특징을 그대로 반영한다. 예를 들어, 페이스북의 친구추천, 서비스 추천, 페이스북 사용자와의 관계(Mutual Friends) 조회, Feeds를 통하 컨텐츠 공유, 상대방의 정보 조회, Activity 공유등과 같은 유사한 기능들이 다수 포함되어 있다.


주소록인 CAB 표준은 단순한 주소록을 넘어 소셜 네트웍 서비스로 진화하고 있다. CAB 서비스를 단말 어플리케이션으로 제공되기엔 제공하는 기능들이 너무 많아 모든 기능을 제공하기 위해서는 어쩌면 웹서비스를 함께 포함해야하지 않을까 하는 생각마저 든다. 그리고 이러한 표준을 시장에 어떠한 모습으로 풀어낼 것인가가 이동통신 서비스에서 어쩌면 향후 1-2년의 과제가 되지 않을까 생각해본다.


-- Red Mouse