소셜 네트웍 서비스: Alone Together

언제부턴가 페이스북이나 트위터와 같은 소셜서비스에 매료되어 한참을 사용하던 중 문득 궁금해진 것들이 있었다. 소셜 네트웍 서비스를 통해 보여지는 사람들은 실제의 그들의 모습과 얼마나 닮아 있을까? 온라인에서 만난 우리들은 서로를 어디까지 신뢰할 수 있을까? 오프라인 삶 속에 존재할 사람들의 다면적 인격을 그들의 온라인 캐틱터는 얼마나 반영하고 있을까? 그들간의 거리는 얼마나 될까?

Alone Together를 통해 개인적으로는 이러한 몇 가지의 물음에 대한 약간의 힌트를 얻을 수 있었다. 사실 Alone Together는 기술의 진보에 따라 인간의 행동양식이 어떻게 변화하고 있는가를 여러가지 실험을 통해 논증하고 객관화 한다. Alone Together의 저자, Sherry Turkle는 이러한 기술의 진보에 따른 인간의 행동양식의 변화가 우리가 그동안 지켜왔던 소중한 가치들을 잃어버리는 방향으로 이루어지고 있음을 꼬집고, 기술의 발전이 인류가 지키고 있는 소중한 가치들을 강화하는 쪽으로 사용되어야 함을 역설하고 있다. 

오프라인의 다면적 자아와 온라인의 정제된 자아

Alone Together에서는 사용자가 온라인을 통해 본인이 원하는 실제의 모습을 구현하고 있다고 한다. 온라인에서는 내가 원하는 형태의 모습을 만들어낼 수 있다. 새로운 글을 올렸을 때, 아바타의 모습을 바꿨을 때, 사진을 올렸을 때 주변에서 보이는 반응에 따라 좀 더 많이 주목받을 수 있고 인기를 끌 수 있도록 노력한다. 사용자에 따라서는 좀 더 이지적인 모습으로, 또는 재미있고 유머러스한 모습으로, 또는 프로페셔널한 모습으로 밖으로 비춰질 수 있기를 원한다. 오프라인에서 잘 안되는 것들을 온라인을 통해 '성취'함으로서 일종의 대리만족을 느끼는 면도 있을 것이다. 온라인에서는 오프라인과는 달리 실시간적 대응이 필요없고 따라서 누군가에 대한 본인의 반응을 충분히 고민하고 정제할 시간적 여유가 있기 때문에 그러한 목적의식적 '치장'이 가능한 것이다. 이러한 이유로 우리는 점점 비실시간적이면서 통제가 가능한 온라인 삶의 매력에 빠져들게 되는 것인지도 모른다. 

SNS 사용자들은 그 목적에 따라 다양한 형태로 자신의 모습을 디자인한다. 어떤 사람들은 친목을 목적으로 가까운 지인들만을 대상으로 개인의 정보를 공유하고 어떤 사람들은 애초부터 Personal Branding을 목적으로 최대한 많은 사람들을 끌어들인다. 그들은 각자의 목적에 따라 나름의 온라인 에티켓을 준수하며 컨텐츠를 공유한다.  

SNS와 같은 온라인 도구를 통해 만나는 사람들이 나에 대해 어떤 이미지를 가지고 있을까는 일상생활에서 다른 사람들에게 보여지는 나의 모습을 궁금해하는 것 만큼이나 개인적인 관심사일 것이다. 하지만, 사람들로 북적거리는 주말 오후 강남거리를 아무리 잘 차려입고 걸어다녀도 아무도 내게 눈길 한 번 주지 않는 것 만큼이나 온라인에서도 보통사람들의 존재란 단지 끝없이 올라가는 타임라인 가운데 단 한 줄 만큼 정도의 무게일 뿐이다. 일상에서의 스타는 온라인에도 스타다. 일상에서의 보통사람은 온라인에서도 보통사람일 뿐이다. 대부분은 그렇다는 것이다. 

그럼에도 불구하고 우리는 여전히 온라인의 자아를 예쁘고 단아하게 때로는 섹시하게 치장함을 멈추지 않는다. 우리는 주목받고 싶어한다. 우리는 공감 받고 싶어한다. 오프라인의 삶은 그렇게 온라인의 자아에 투영되고 있다. 

감성적 연결의 다변화

Alone Together에서 저자는 사람들이 로봇을 통해 상처를 치유할 수 있는 가능성이 있음을 실험을 통해 밝히고있다. 이 가능성을 바탕으로 인공지능을 탑재한 로봇이 다양하게 출시되고 있으며, 그 기술 자체도 진화에 진화를 거듭하고 있다. 때때로 이러한 종류의 로봇은 인간의 관점에서 더 이상 무감정 무감각의 로봇이 아닌, 고양이나 개와 같은 살아있는 개체처럼 인지되고 있다. 로봇이 사실은 하드웨어와 소프트웨어의 조합일 뿐이라는 사실은 그런 로봇을 필요로 하는 사람들에겐 중요하지 않다. 그들은 어쨌든 로봇을 통해 마음의 위안을 얻을 수 있는 것이다.

저자는 이런 현상을 통해 인간이 기술의 발전과 함께 정작 중요한 가치를 잃어가고 있는 것이 아닌지에 대한 물음을 던진다. 그러나, 그런 현상의 옳고 그름을 떠나 어쩌면 사람이 행복을 느끼는 기준은 그 대상이 실제인지 허구인지와는 관계없는 것인지도 모른다. 도우미 로봇은 인간의 말을 인식하고 적절하게 대응하도록 설계되었으며 인간과는 달리 화를 내거나 귀찮아하지 않는다. 사람은 헌신적인 로봇과 일정기간 교류함으로써 점차 로봇에 대해 감성적 연결고리를 맺게 된다. 적절하게 프로그래밍된, 제한된 언어만을 구사할 수 있을 뿐인 도우미 로봇에게 연민의 정을 느끼게 될 때 그들은 더 이상 로봇이 아닌 것이다. 

SNS와 같은 온라인의 삶에서는 어떨까. 우리는 우리가 올린 글에 대해 다른 사람이 반응할 때 만족감을 느낀다. 누군가가 나의 트윗을 리트윗하거나 나의 글을 like하거나 공유할 때 우리는 서로 '연결'되어 있음을 느낀다. 누군가가 나의 존재를 '인식'하고 있다는 느낌. 그것은 나의 '실존'을 타인을 통해 확인하는 과정이다. 왠지 어느 정도 오프라인의 그것과 닮아 있는 것 같다. 하지만, SNS를 이용하면서부터 어쩌면 우리는 더이상 관계유지를 위해 시간을 내어 장소를 이동하고 얼굴을 맞대지 않아도 되는지도 모른다. 우리는 always-on network을 통해 공간을 뛰어넘어 서로 연결되어 있으며 그 연결을 통해 원하는 때에 원하는 만큼 흔적을 남기기만 하면 되는 것이다. 예전처럼 서로 얼굴을 맞대거나 전화를 통해 음성을 들었을 때만 감성적 연결을 만들 수 있는 것이 아닌 것이다.

아직 해결되지 않은 문제: 신뢰

SNS를 통해 가지는 감성적 연결이 오프라인에서도 이어질까. 온라인에서 느끼는 친밀감 만큼이나 우리는 오프라인에서도 가까울까. 온라인을 통해 느끼는 누군가에 대한 신뢰가 여전히 오프라인에서도 유효할까. 오프라인의 관계에서만큼이나 온라인 관계에서도 상호침투(reciprosity)가 가능할까. 

트위터는 사용자간 "Follwing"의 관계를 기반으로 한다. 사용자는 유명 연예인이나 관심분야의 유명인이 tweet하는 얘기를 들을 수 있고 그 얘기들에 실시간으로 반응한다. 문득 Reply나 멘션을 통해 그들과 1:1의 메세지를 주고 받기라도 하면 마치 그들이 자신의 일상안으로 들어와 있는 듯한 착각이 들기도 한다. 페이스북도 마찬가지 맥락에 있다. 사용자들은 페이스북에서 서로 간에 Friends를 맺고 그들간 올리는 컨텐츠를 서로 공유하며 그렇게 공유된 컨텐츠에 반응함으로써 서로의 존재를 확인한다.

이 책의 저자인 Sherry Turkle는 자신의 TED 강연에서 이렇게 SNS가 제공하는 약한 연결을 통해 사람들은 감성적 연결고리를 유지하면서 동시에 자신을 보호할 수 있는 공간을 확보하고 싶어한다고 한다. 사람들은 친구들과 까페에서 커피를 마시면서 스마트폰으로 페이스북을 하고 트위터를 통해 멀리 떨어져 있는 사람과 소통한다는 것이다. 그러니 이것은 아이러니다. 함께 있지만 혼자 있는 것이다(Alone Together).

사람들은 SNS를 통해 관계를 유지한다. 그리고 그 SNS를 통해 연결된 감성적 연결고리가 그들의 네트웍이라고 믿고 있다. 맞지만 틀린 얘기다. Sherry Turkle 의 지적대로 그런 연결고리는 "mere connection"일 뿐, 그 연결이 서로 간의 신뢰를 보장해 주지는 않는다는 것이다.

트위터나 페이스북에서 알게 된 사람과 직접 1:1로 만나본 적이 있는가? 그렇게 알게된 사람으로부터 직접 1:1 연락을 받아 본 적이 있는가? 이럴 때 우리의 반응은 어떨까? 또한 그들의 반응은 어떨까? 늘 그렇듯, 처음 만나는 사람들에 대해 우리는 '경계'하게 될 것이다. 그들이 나의 '적'이 될지 '동지'가 될지를 탐색하는 것은 인류가 생긴이래 가장 오래된 인간의 본능이니까. 내가 올리는 Like나 공유의 횟수가 오프라인에서 나와 그들간의 신뢰적 관계를 보장해 주지는 않는다는 것이다. SNS에 아무리 많은 친구가 있고 SNS를 통해 아무리 많은 활동을 한다 해도, 여전히 우리는 온라인과 오프라인간의 높은 벽을 무너뜨리지는 못하고 있다.

페이스북의 전세계 사용자는 2013년 말 현재 12.5억으로 알려져 있고, 아주 최근 10대 사용자의 유출이 있다고는 하지만 여전히 가장 넓은 충성도 높은 사용자층을 가지고 있다. 트위터는 active user 관련 논란이 있긴 하지만, 역시 대안 미디어로서의 입지를 이미 굳히고 있다. 스마트폰 기반의 서비스들이 소셜 그래프를 통해 사용자의 충성도를 제고하고 전환비용을 높이려는 노력은 이제 상식처럼 여겨지고 있다. 이러한 다양한 서비스의 다양한 소셜 그래프위에 크라우드 소싱이나 P2P 공유 경제와 같은 새로운 패러다임들이 등장하고 있고 소셜 그래프를 이용해 특정 사용자에 대한 신뢰도를 측정하려는 노력도 함께 이루어지고 있다.


맺음말

다양한 SNS의 진화로 더 많은 사람들과 더 많은 것들을 다양한 형태로 공유할 수 있게 된 지금, 이제는 좀 더 본질적인 물음을 던져볼 시기인 것 같다.

나의 소셜 그래프에 있는 사람들을 나는  어디까지 신뢰할 수 있을까? 나는 한 번도 만나보지 못한 그들과 진심으로 마음을 열고 대화를 나눌 수 있을까? 낯선 사람을 잠재적인 '적'이 아닌 잠재적인 '동지'로 인지할 수 있을까?

지금까지 각 개인의 정신적 역량에 기대어 왔던 이러한 관계의 문제를 기술적 진보가 해결해 줄 수는 없을까?

Red Mouse 

D2D(Device to Device) 통신

스마트폰을 비롯한 다양한 connected device가 봇물처럼 쏟아지고 있는 가운데 이들 디바이스를 통한 사용자의 데이타 사용량 또한 급증하고 있다. 이동 통신사들은 이러한 데이타 트래픽의 폭증을 제어해야 할 필요성을 절감하고 있는 실정이고, 사용자들의 입장에서는 원활하지 못한 데이타 서비스에 대한 불만을 토로하고 있다. 이러한 가운데, D2D 기술은 데이타 네트웍의 부담을 줄여주면서 네트웍 접속에 대한 사용자 경험을 획기적으로 개선시켜 줄 것으로 기대되고 있다. 이번 포스팅은 D2D 기술에 대해 개략적인 내용을 특히, WiFi Direct 중심으로 다루고자 한다.

D2D 기술은 네트웍을 거치지 않고 서로 다른 기기간의 통신을 지원하는 기술로 UPnP(Universal Plug and Play)와 DPWS(Device Profile for Web Services), WiFi Direct와 같은 기술이 이에 속한다. UPnP의 경우 홈네트워크를 위한 표준 프로토콜로 주로 TV, 오디오, PC, 냉장고와 같은 주로 가전 제품간의 연동 기능을 제공한다. 사용자는 UPnP기술을 장착한 하나의 Display 장치에서 다른 장치에 있는 컨텐츠 목록을 확인할 수 있고 해당 컨텐츠를 가져와 확인할 수도 있는데(자세한 내용은 여기 참조), 예를 들어, 랩탑에 저장되어 있는 고화질의 컨텐츠를 네트웍 접속 없이 직접 TV로 전송해 큰 화면으로 감상할 수 있는 기능이 그것이다. UPnP 기술은 가전 제품간의 호환성을 제공하기위해 Sony가 주도하여 설립한 DLNA(Digital Living Network Alliance)에서 공식 규격으로 채택되었고, 지금은 D2D 분야에서 각광받는 기술 가운데 하나로 자리매김하고 있다. 이에 더해 최근에는 WiFi Direct 호환기능을 제공하고 있다고 한다.(DLNA의 기술을 적용한 제품의 목록은 여기에서 확인) 

  

DPWS 역시 UPnP와 동일한 기능을 제공하지만 단말에 설치된 웹 기반 서비스를 대상으로 한다는 점에서 차이가 있다. DPWS는 웹 서비스가 어디에서 구동되는가에 따라 hosted device와 hosting device로 구분하는데, 클라이언트가 되는 단말이 hosting device에 있는 웹 서비스에 접속해서 해당 서비스를 제공받는 구조이다. 2009년 6월, OASIS에서 WS-Discovery 1.1, SOAP-over-UDP 1.1과 함께 DPWS 1.1 규격이 채택되었다. 

WiFi Direct(기술명: WiFi P2P) 기술은 IEEE 802.11n을 기반으로 확장되었으며 현재는 IEEE에서 802.15 PAC(Peer Aware Communication)으로 분리되었다. 기존의 WiFi 단말기가 고정된 AP(Access Point)에 접속하여 네트워크 서비스를 제공받았다면, WiFi Direct 기술은 단말기 안에 AP를 구현(SoftAP)함으로써 무선 AP가 없이도 언제 어디서든, 이동하면서도 WiFi 기술을 이용한 기기간 통신이 가능하도록 하였다는 데에 큰 의미가 있다. WiFi Direct는 IEEE 802.11n를 기반으로 하고 있으므로, 기존 802.11n을 지원하는 WiFi 기능을 장착한 단말이라면 펌웨어 업그레이드를 통해 WiFi Direct로 전환할 수 있다. 또한, 역호환성이 지원되므로, 서로 연결을 하는 두 단말 가운데 하나만 WiFi Direct를 지원하더라도 동작이 가능하다. 두 단말간 보안 알고리즘은 WPA2를 사용한다. WiFi Alliance에서는 지난 2009년 WiFi Direct를 공식 규격으로 채택한 이후 2010년 부터 제품에 대한 인증 프로그램을 제공하고 있다.

IEEE 802.15는 Bluetooth나 Zigbee같은 WPAN(Wireless Personal Area Network) 기술을 표준화하는 곳으로 기존에 연구해오던 PSC(Personal Service Communication)를 폐기하고, 이를 발전시켜 PAC(Peer Aware Communication) 표준 제정을 진행하기로 결의하였다. 이를 위해  2011년 11월 SG5(PAC)가 새롭게 생겼으며, 2012년 3월 정식 Task Force로 출범할 예정이다. 현재는 전세계에서 인텔, 소니를 포함한 18개 업체가 참여하고 있으며 국내에서는 ETRI와 삼성, LGE가 참여중이다.

한편 여러 칩셋 제조사들은 이전부터 자사의 D2D 솔루션들을 제공해 왔다. 인텔은 Wireless Display라는 상품명으로 D2D 기술이 내장된 칩셋을 제공해 왔으며, 이 기술은 NetGear의 Push2TV에 적용되었다. Qualcomm의 경우 2011 MWC에서 1Km내에 있는 단말간 통신이 가능한 P2P 기반 근거리 무선 통신 기술인 FlashLinQ를 공개했으며 한국의 SKT와 공동으로 상용화 실험을 진행했다. WiFi Direct의 경우 무선랜용 무면허 주파수 대역을 사용하는 반면에 FlashLinQ는 이통사에 할당된 면허 주파수를 사용한다는 점에서 차이가 있다. 이밖에, Direct Connect 라는 솔루션을 보유한 Atheros가 있다.

WiFi Direct는 다른 근거리 무선 통신 기술인 ZigBee나 Bluetooth, NFC 등과도 비교대상이 되는데, 특히 Bluetooth와는 어느 정도 경쟁 관계를 가지게 될 것으로 보인다. 최근 Bluetooth는 3.0으로 업그레이드 하면서 적용 반경을 어느 정도 확장했으나, 그럼에도 불구하고 아직까지는 속도나 거리측면에서 WiFi Direct가 경쟁 우위를 점하고 있는 것으로 보인다.

삼성 Galaxy S2와 LG Optimus Black, Motorola Xoom은 WiFi Direct 기술을 적용해 출시되었으며, 애플에서도 iOS기반 단말에 IP네트웍 상에서 컴퓨터 및 주변기기, 서비스를 자동으로 찾아주는 네트워킹 기술인 Bonjour 서비스를 제공하고 있다.

단말간 직접 통신 서비스 기술인 WiFi Direct의 쓰임새는 매우 다양하다. 쇼핑몰이나 상점은 인접 위치에 있는 잠재적인 고객을 대상으로 광고나 쿠폰을 전송함으로써 프로모션을 진행할 수도 있고, 스타벅스 같은 매장안에 들어와 있는 고객들을 대상으로 간단한 게임을 제공할 수도 있다. 인접 거리에 있는 친구간 위치를 전송한다거나 서로 모르는 사람간의 프로필을 매칭해주는 소셜 데이팅에 활용될 수도 있다. 또한, 홈네트워크에서 가전 제품 기기간 통신은 다양한 부가 서비스를 창출할 수 있을 것이며, 위의 Push2TV 동영상에서도 보았듯이 N-Screen의 실현도 가능하다. 오피스에서 사람들을 대상으로 프리젠테이션을 진행할 때, 프로젝터와 단말기를 WiFi로 연결하여 활용할 수도 있다. 이 모든 서비스가 네트웍을 거치지 않고 기기간 직접 통신을 통해 이루어진다는 점에서 네트웍 트래픽을 획기적으로 감소시킬 수 있는 기술이기도 하다.

향후, 기기간 직접통신을 위한 WiFi Direct를 적용하는 단말은 지속적으로 증가하게 될 것이다. 사용자들이 이 기능을 적극적으로 활용할 수 있도록 하기 위해서는 무엇보다도 자신의 단말에 이러한 기능이 있는지 조차도 모르는 일반 사용자가 해당 기능을 인지할 수 있도록 WiFi Direct 기반의 다양한 서비스 들이 나올 수 있어야 한다. 특히, 홈네트워크에서의 기기간 통신 기능을 활용한 서비스는 사용자에게 가장 다가가기 쉬운 Use case가 아닐까 싶다. 이와 동시에, AP 접속 절차와 관련된 설정과 인증 측면에서 사용자의 개입을 최소화 할 필요가 있다. Bluetooth에 비해 경쟁 열위에 있는 단말의 배터리 소모량도 역시 시급히 해결해야 할 문제로 보인다. 

WiFi Direct를 활용하면 사용자는 데이타 사용을 최소화하면서 원하는 서비스의 사용을 극대화 할 수 있기 때문에, 네트웍 부하를 해결해야 하는 이동 통신사 입장에서는 단기적으로 이득을 지 모르겠으나, 장기적인 관점에서는 수익에 부정적인 영향을 줄 수도 있을 것으로 보인다. 또한, 이러한 이동 통신사의 입장을 고려해야 하는 단말 제조사가 적극적으로 WiFi Direct를 도입하고 이를 활성화 하려는 노력을 기울이게 될지 역시 의문으로 남는다. 이러한 상황은 위에서 언급한 WiFi Direct 기반의 인접 서비스(Proximity service)의 조기 활성화에도 걸림돌로 작용할 것으로 생각된다.

표준화 활동에 관한 소고

처음 OMA(Open Mobile Alliance)라고 하는 표준단체에서 활동을 시작한 것이 2007년도 쯤이고 작년말에 활동을 종료했으니, 표준화 활동에 나름 발을 들여놓은 지 5년 정도 된 것 같다. 짧다면 짧고 길다면 긴 시간들이었지만, 이제 표준화 활동을 접는다는 생각을 하니 시원함 보다는 아쉬움이 더 남는다. 그러나, 5년간을 풀타임으로 전력투구할 상황은 안되었지만, 나름 주어진 상황에서 최선을 다했기에 후회는 남지 않는다. 개인적으로 많은 좋은 경험을 할 수 있었고 많은 것을 배울 수 있는 기회였기에 이마저도 감사하게 생각해야 하지 않을까 싶다. 나름대로 도전이었고 내 삶의 마일스톤이 됐던 국제표준화 활동을 일단락하는 시점에서, 그동안 생각해봤던 몇가지를 기술하는 데에 이번 포스팅을 할애하고자 한다.

어디까지가 표준화 활동일까?

간혹 표준화 활동에 대해 잘 모르시는 분들이 3GPP나 OMA같은 사이트를 통해 표준문서를 읽고 분석하는 것 자체가 표준화 활동이라고 착각하시는 분들이 계신듯 하다. 하지만 그것은 그저 표준 규격에 대한 모니터링이나 서베이일 뿐 실제로 표준화 활동이라고 부를 수는 없을 것 같다. 내가 아는 한 표준화 활동은 자사가 가지고 있는 기술을 국제적으로 인정받는 표준으로 만들거나 남들이 만들어 놓은 기술을 빠르게 습득하기 위한 과정의 하나이다. 이러한 활동이 중요한 이유는 자사의 기술을 국제 기술 표준 시장에서 공공연하게 인정받음으로서 향후 해당 기술을 적용할 수 있는 잠재적 시장을 확대하고자 하는 측면이 있다. 지구상의 어느 나라 어느 지역에서만 사용하는 기술이 아닌, 국제적으로 인정된 기술을 보유하고 있다는 것은 해당 기술을 채택하고 있는 국가의 시장에 용이 하게 진입할 수 있음을 의미한다. 한편, 이와 함께 병행해야 하는 아주 중요한 활동은 IPR 활동이다. 자사의 기술을 국제적으로 인정받는 기술로 만듦과 동시에 해당 기술에 대한 지적 권리를 획득해 놓는 것은 전쟁터에서 창과 방패로 무장하는 것과 같다. 이렇게 표준화 활동은 기술 규격에 대한 단순한 모니터링 차원 이상으로 해당 표준 단체에 참여해서 다른 국가 및 기업들과 어깨를 나란히 하면서 적극적으로 기고 활동을 벌이는 것을 말한다.

국제 표준화 활동을 하기 위해서는 꼭 영어를 잘 해야 한다?

국제 표준화 활동을 하면 아무래도 영어가 많이 늘겠다거나 잘 해야 한다거나 하는 사람들을 자주 보았다. 하지만 모두 틀린말이다. 지난 5년간 OMA에서 영어를 잘하지 못하는 사람을 많이 봐 왔고 그렇다고 해서 그들이 표준화 활동을 하는 데에 어떤 심각한 장애가 있다고 생각을 해보지 않았기 때문이다. 물론, 영어는 중요하다. 영어를 잘하면 자신의 의사를 보다 설득력있게 전달할 수 있고 다른 사람의 공격으로 부터 자신의 기고를 보다 효율적으로 방어할 수 있다. 하지만 영어 실력은 필요조건일 뿐 충분조건은 아니다. 기고가 채택될 것인가 말것인가에 대한 기준은 해당 기고의 내용에 의해서 좌우될 뿐 기고자의 영어실력과의 상관관계는 거의 없다고 본다. 다만, 표준 단체에 따라 그 분위기가 다르고 스케쥴 관리 방식이 상이하여 다른 곳에서도 같다고 말할 수는 없겠다. 어느 정도의 영어 실력은 필요하겠지만, 반드시 네이티브 스피커와 같은 유창한 영어실력이 있어야 하는 것은 아니다. 국제 표준화 활동을 하는 데 있어서 영어 실력보다 중요한 것은 성실함과 꾸준함이다. 참고로, 국제 표준화 활동 자체가 영어를 잘 하도록 해 주지는 않지만, 영어를 제1 언어로 사용하지 않는 개인에게 영어 공부를 위한 동기부여는 될 수 있겠다.

표준 채택이 사실은 정치에 의해 좌우된다고 하던데?

그렇기도 하고 아니기도 하다. 표준화 활동에 참여하는 사람들은 모두 자신의 기업을 대표하기 때문에 해당 기고자가 작성한 기고는 당연히 자기가 속한 기업의 이익을 대변한다. 표준 전문가가 작성한 기고에 대한 채택여부는 해당 기고의 내용이 얼마나 논리적이고 적합한 지가 가장 중요하겠지만, 그 외에 해당 기고자가 속한 회사의 네임밸류 또는 영향력과도 관계된다. 예를 들어, OMA의 경우 이동 통신사의 영향력이 매우 강한데, 이는 OMA의 구성원들이 모두 이동 통신사를 중심으로한 비즈니스 생태계에 엮여 있는 기업들이다 보니 자연스럽게 생겨난 현상일 것이다. OMA 자체가 하나의 기고를 채택하는 데에 있어서 만장일치제를 권장하고는 있으나 해당 기고의 내용이 매우 민감한 사안인 경우엔 의견차이를 좁히지 못하는 경우가 있다. 이럴땐 결국 투표까지 가게 되는데, 이때 투표권을 행사할 수 있는 기업들간에 보이지 않는 '표 끌어오기' 전쟁이 시작된다. 투표권을 행사해야하는 가)안과 나)안에 대해 잘 모르는 사람들을 내 편으로 만드는 과정에서 해당 기업의 영향력은 무시할 수 없는 요소가 된다.

표준화 활동하면 좋은 점은?

국제 표준화 활동을 하다보면 외국을 비교적 자주 나가게 된다. 많은 사람들이 이 점을 매우 부러워하게 되며 처음 표준화 활동을 시작할 때 나를 설레게 했던 이유 가운 데 하나이기도 하다. 문제는 막상 어느 나라 어느 도시의 어느 장소(일반적으로는 호텔)에 모여서 회의를 시작하면 여기가 어느 나라인지 종종 잊어버린다는 사실이다. 그도 그럴 것이, 아침 8시 30분에 회의를 시작하여 오후 6시에 끝나니(OMA기준), 사실은 저녁 먹을 때 빼고는 하루 종일 밖을 나갈 일이 없는 것이다. 또한, 어느 나라를 가든 묶는 호텔은 대부분은 브랜드 호텔이다 보니 웬만하면 똑같이 생겼다. 외국을 많이 돌아다니며 많은 것을 '구경'할 수 있을 거라는 환상은 짧으면 6개월, 오래가도 1년이면 모두 깨진다. 다만, 하루 일과를 끝내고 호텔 근처에서 맥주한잔 기울이는 소소한 재미가 있을 뿐이다. 하지만, 이마저도 친한 사람을 만들어놓지 않으면 할 수 없는 '놀이(?)'이다. 모든 표준화 회의가 끝난 이후, 비행기 시간까지 반나절에서 하루정도의 시간이 남을 수 있는데, 이 시간을 잘만 활용하면 그나마 '외국'이라는 존재감을 느낄 만한 활동의 기회는 얻을 수 있겠다.

이것보다 개인적으로 표준화 활동의 좋은 점이라고 생각하는 점은 세상의 넓음을 실감한다는 것이다. 이름만 들어도 알만한 외국의 유수한 글로벌 업체들과 어깨를 나란히 하고 서로 제출한 기고를 가지고 니가 옳으니 내가 옳으니 갑론을박 할 수 있다는 것. 그들이 나의 의견에 귀를 귀울이고 자기의 의견을 공유하고, 때로는 함께 힘을 합쳐서 기고를 채택하고 표준을 만들어가는 그 일련의 과정들을 통해 한국이 아닌 그 밖에 너무나 넓은 세계가 있었음을 실감하게 된다. 내 생각엔 이러한 경험과 깨달음만으로도 개인에겐 큰 수확이라 생각한다. 세상을 바라보는 눈을 크게 뜰 수 있도록 해 주기 때문이다.

개인적으로 또 하나 배운 것은 서로 다른 의견을 하나로 만들어가는 민주적 절차와 이것을 가능하게 하는 커뮤니케이션 스킬이다. 나의 의견이 언제든 틀릴 수 있다는 열린 마인드와 다른 사람의 의견을 청취하는 능력 그리고 그들의 의견을 받아들일 수 있는 여유. 첨예한 사안에 대한 일시적 후퇴 또는 갈등 회피 전략. 형형색색의 협상전략. 이 모든 커뮤니케이션 스킬을 한 자리에서 볼 수 있다. 

표준화 활동에 적합한 인재상

누군가가 표준화 활동에 가장 적합한 인재는 어떤 사람이냐고 묻는다면, '안 보이는 데서도 성실히 일하는 사람'이라고 단정하여 말할 수 있을 것 같다. 표준화 회의가 개최되는 장소가 대부분 접근성을 고려하여 시내 중심가이다 보니 주변으로부터의 유혹이 많을 수 밖에 없다. 일반적으로 크고 작은 쇼핑몰부터 시작해서 관광지가 멀지 않은 곳에 위치해 있는 경우가 많다. 한편, 표준화 회의를 주최하는 측에서는 어느 인원이 해당 회의에 참석을 하는지 하지 않는지를 확인하지 않는다. 그야말로 개인의 자율성이 최대로 보장되는 것이다. 기업 차원에서 조직적으로 다수의 인원을 파견하는 경우 어느 정도 나름의 규율이 작동하겠지만, 그렇지 않은 경우, 표준화 활동에 참여하는 인재가 책임감이 부족하거나 적응을 잘 못하는 경우 겉으로 돌 수 밖에 없고, 호텔 밖에는 이러한 사람들을 받아줄 곳이 너무 많다는 것이다. 극단적으로 얘기하면 일주일 내내 한 두 번만 회의에 참석하고 나머지를 모두 관광하는 사람도 생기는 것이다. 더군다나 한국사람이라면 대부분의 사람에게 존재할 언어장벽을 넘어서야 하는 과제가 덤으로 존재하기 때문에 남들 놀 때 같이 놀면 그 사람은 영원히 표준화 활동에서 두각을 나타내지 못할 것이다. 내가 봤던 대부분의 한국인은 회의가 끝난 이후에도 나름대로 치열하게 필요한 사람들을 만나거나 내일 발표할 자신의 기고를 다듬거나 또는 새로운 기고를 준비하면서 자기가 맡은 임무에 충실하려는 사람들이었다. 이러한 맥락에서, 쇼핑이나 음주 가무를 필요이상으로 즐기는 사람과 집중력이 떨어지는 사람은 표준화 활동에서 모랄 해저드가 발생할 가능성이 큰 분들이라고 할 수 있다.

이 밖에 표준화 전문가에게 요구되는 중요한 능력은 커뮤니케이션 스킬이다. 단순히 영어를 잘 하는 것을 의미하는 것이 아니라, 자신과 이해관계가 대립되는 당사자를 먼저 이해하고 그들을 설득하는 능력을 말한다. 감정적으로 치달을 수 있는 의견대립의 상황에서도 냉정을 잃지 않고 합리적인 판단을 내릴 수 있는 능력은 표준화 활동 과정에서도 훈련될 수도 있겠지만, 기왕에 그런 능력을 가지고 있다면 조기에 좀 더 탁월한 표준화 활동을 펼칠 수 있지 않을까 싶다.

지금까지 국제 표준화 활동에 대한 짧은 경험을 OMA를 중심으로 두서 없이 적어보았다. IEEE나 W3C, 3GPP, ITU-T는 각각 나름의 방식대로 운영을 하고 있고 그 분위기도 제 각각 다르다고 한다. 하지만, 큰 맥락에서는 위에 언급된 내용들과 큰 차이는 없지 않을까 생각해 본다. 국제 표준화 활동을 시작하게 되면 외국 출장이 잦기 때문에 주변으로부터 시기와 질투를 한 몸에 받게 된다. 표준화 조직이 잘 갖추어져 있는 삼성이나 LG같은 곳을 제외하면, 대부분 그러할 것이다. 그러한 시기와 질투를 하는 사람들에게 표준화 전문가가 할 수 있는 최대한의 방어는 실적으로 보여주는 것이다. 표준화 조직이 갖추어져 있지 않은 기업은 표준화 전문가의 활동을 강제할 수 있을 만한 체계가 없는 경우가 대부분이기 때문에, 그러한 강제성은 기업의 표준화 활동을 담당하고 있는 인력이 스스로 만들어나가는 수 밖에 없다. 스스로를 강제하고 스스로 실적 목표를 세우고 다녀와서는 보고를 통해 자신의 표준화 활동의 성과를 증명할 수 있어야 한다. 표준 조직에서 일어나고 있는 일들을 실시간으로 관련 담당자와 공유하는 것도 잊어서는 안된다. 표준화 활동이 당장의 매출을 올리는 실적과는 무관하기 때문에 내부 고객을 설득하는 것이 매우 어려운 건 사실이지만, 장기적 관점에서 핵심기술을 보유하고 있는 기업과 개인에게 긍정적인 영향을 줄 수 있는 활동인 것 만은 확실하다고 생각된다. 우리나라는 아직 표준화 활동에 대한 인식이 매우 낮아 몇몇 대기업을 빼놓고는 적극적으로 활동에 참여하고 있는 회사는 찾아보기 힘든게 현실이다. 앞으로, OMA든 W3C든 3GPP든 핵심기술을 보유하고 있는 우리나라 중소기업이 능동적으로 IPR활동과 표준화 활동을 해 나갈 수 있으면 하는 바램이다. 나 역시, 앞으로 어느 단체에서든 표준화 활동을 다시 지속해 나갈 수 있는 기회가 있으면 하는 바램이 있다.

-- Red Mouse

커뮤니케이션 서비스의 진화와 전망

커뮤니케이션 서비스는 인류의 문명이 생겨난 이후로 단 한번도 킬러 애플리케이션의 자리를 내어 준 적이 없을 정도로 그것은 과거에도 그랬던 것 처럼 미래에도 기술의 발전과 함께 꾸준히 사람과 사람을 이어주는 소통의 도구로 자리매김 하게 될 것이다. 최근 몇 년간 스마트폰의 출시와 함께 스마트폰에 설치되어 사용자의 생활을 보다 편리하고 유의미하게 만들어 주는 응용서비스가 폭발적으로 증가하는 그 한 가운데에도 역시 다양한 커뮤니케이션 서비스가 자리를 지키고 있어왔다. 이번 포스팅에서는 그동안 시장에서 큰 반향을 불러일으켰던 몇 가지 대표적인 커뮤니케이션 서비스를 리뷰하면서 커뮤니케이션 서비스의 몇 가지 흐름을 짚어보고자 한다. 그리고 이러한 내용을 근거로 향후 커뮤니케이션 서비스가 어떻게 진화하게 될 것인지에 관한 고민까지 함께 나누어보고자 한다.

1. 커뮤니케이션 서비스 진영

현재 커뮤니케이션 서비스를 제공하는 진영은 크게 네 가지로 구분할 수 있다. 우선은 3rd-party 서비스 제공자이다. 이들은 스마트폰의 폭발과 함께 등장한 사업자들로, 사용자들의 스마트폰 사용이 증가함에 따라 기존 사업자들이 제공하던 인터넷망을 이용하여 자유롭게 서비스를 제공하는 사업자들이다. 

대표적으로 카카오톡이 이에 속한다. 3rd-party 사업자 가운데 카카오톡은 가장 많은 가입자수를 확보한 서비스로 국내의 경우 스마트폰을 소지한 사용자는 대부분 카카오톡을 다운로드 받았다고 할 수 있을 정도로 선전하고 있다. 현재 2,500만명의 가입자를 확보하고 있으며, 대표적인 기능은 1:1 및 그룹채팅, 연락처 기반 자동/수동 친구 등록, 멀티미디어 채팅 정도이다. 다른 커뮤니케이션 서비스와 기능적인 면에서 큰 차이가 없음에도 이렇게 선전을 하고 있는 것은 다름 아닌 단순한 UI/UX로 사용자들의 마음을 사로잡고, 스마트폰 보급 초기 시장을 공략하여 시장 선점에 성공할 수 있었기 때문이다. 최근 카카오톡이 새롭게 내놓은 서비스 가운데 하나가 플러스 친구이다. 플러스 친구는 카카오톡의 기업 사용자라고 할 수 있는데, 일반 기업이나 아이돌을 내세운 프로모션 업체 들이 카카오톡에 등록하면 그 이름을 일반 사용자들에게 노출시켜주고 사용자가 해당 기업을 카카오톡 친구로 등록하면 앞으로 그 기업이 프로모션 하는 내용을 카카오톡 메세지로 받아볼 수 있는 서비스이다. 사용자는 플러스친구로 부터 받은 카카오톡 메세지를 나의 다른 카카오톡 친구에게 추천할 수 있다. 마치 트위터의 팔로우나 리트윗 개념을 연상케 한다. 플러스친구는 카카오톡과 같은 3rd-party 사업자들이 치열하게 고민하고 있는 가능한 수익모델의 한 예를 실현했다는 데에 큰 의미가 있다. 현재까지 등록되어 있는 카카오톡의 플러스 친구는 30개 업체이고 그 숫자가 꾸준히 증가하고 있으며, 플러스 친구를 카카오톡 친구로 등록하여 사용하고 있는 사용자는 지난 11월 현재 650만명에 이르고 있다. 한편, 카카오톡은 최근 카카오링크 2.0을 공개했는데, 이는 카카오톡이 제공하는 OpenAPI로서, 다른 응용앱 서비스 제공자가 카카오링크 2.0을 이용하여 자기가 제공하는 컨텐츠를 카카오톡 안으로 보낼 수 있는 기능을 제공한다. 예를 들어, 뉴스앱 개발자가 카카오링크를 자신의 앱안에 설치하면 사용자가 해당 뉴스앱을 읽다가 발견한 재미있는 기사를 카카오톡 친구에게 보내고자 할 때 카카오링크를 이용하여 전송할 수 있는 것이다. 이것은 마치 페이스북의 Like와 같은 기능이라고 볼 수 있다. 

커뮤니케이션 서비스의 두 번째 진영은 제조사 진영이다. 단말 제조사가 이동 통신사를 배제하고 독립적인 커뮤니케이션 서비스를 직접 제공하는 사례는 아직 애플외에는 찾아보기 힘들지만, 애플의 iMessage는 지난 1-20년간 이동 통신사에 종속적이라고만 생각했던 단말 제조사의 위상을 다시 한번 생각하게 만들었다. 애플의 움직임에 고무되어 삼성은 나름의 독자적인 커뮤니케이션 서비스인 ChatOn을 출시해 놓고는 있으나 현실적으로 iMessage처럼 단말의 Native application으로 넣지는 못하는 상황이다. 당분간은 여전히 이동 통신사와의 관계를 무시하지는 못할 것이라고 생각된다. 애플 iMessage는 iOS5에 탑재되어 기존의 단말의 메시징 클라이언트를 대체했다. 사용자의 ID로 Email과 단말번호를 모두 이용할 수 있으며, 1:1 및 그룹 채팅을 제공한다. 착신확인을 지원하고 멀티미디어 컨텐츠를 전송할 수 있으며 복수단말을 지원한다. 착신 단말이 iMessage를 지원하지 않는 경우는 기존과 마찬가지로 SMS/MMS로 전송된다. iMessage의 가장 놀라운 점은 여전히 그 단순성에 있다. 기존 메세징 클라이언트와 사용자 경험이 완전히 똑같기 때문에 사용자의 입장에서는 아무런 거부감 없이 레가시 메시징에서 IP메세징으로 옮겨갈 수 있었다. 사실 사용자는 전달 수단이 뭐든 관심이 없을 것이고 다만, 아무리 문자를 보내도 정액제에 딸려오는 무료 문자 메세지의 숫자가 줄어들 지 않는 것에 환호할 것이다.

삼성의 ChatOn은 지난 10월 전세계 121개국, 62개 언어로 서비스를 시작했다. 별도의 가입절차 없이 기존 단말번호로 이용할 수 있으며, 1:1 및 그룹채팅, 멀티미디어를 지원한다. 애니메이션 메세지(사진+손글씨+배경음악)를 전송할 수 있으며, 사용자의 상태정보 및 친밀도를 표시해준다. 또한, 다른 사용자가 올린 사진 및 동영상에 댓글을 달 수 있는 기능을 제공한다. 삼성의 ChatOn은 메세징 서비스 외에 SNS-like한 기능들을 덧붙여 소셜 커뮤니케이션 서비스로의 진화를 모색하고 있는 것으로 보인다.

커뮤니케이션 서비스의 세번째 진영은 웹 서비스 제공자이다. 대표적으로 페이스북과 구글이 이에 해당한다. 얼마전 페이스북은 페이스북 전용 메신저를 출시했고 이어서 HTC와 제휴하여 페이스북 전용폰을 위한 준비에 착수했다고 알려진 바 있다. 페이스북은 전 세계적으로 8.5억이나 되는 막강한 가입자수를 기반으로 페이스북 친구간의 커뮤니케이션 서비스를 제공하고 있다. 페이스북 메신저는 페이스북에서 메세징 기능만을 별도로 분리하여 만든 서비스로 이동 통신사와 제휴하여 단말 번호를 인증하고 페이스북과 연동한다. 피처폰에서도 사용 가능하며 1:1 및 그룹 채팅 기능을 제공한다. 또한, 사용자의 위치와 지도를 공유할 수 있다. 구글의 경우 구글톡을 지속적으로 진화시키고 있다. 구글톡은 IM과 그룹콜, VoIP를 지원하며 지메일과 연동한다. 또한, 상태정보를 제공하고 구글 플러스와 연동할 수 있다. 구글톡과는 별개로 구글 행아웃은 비디오 콜 기능을 지원하는 데 현재로서는 북미지역에서만 이용할 수 있다. 국내에는 다음의 마이피플과 얼마전 출시된 네이버의 라인이 대표적이다.

커뮤니케이션의 마지막 진영은 커뮤니케이션 시장의 전통의 강자인 이동 통신사이다. 이동 통신사는 스마트폰의 급속한 보급으로 때 아닌 시련을 겪고 있는 가장 큰 피해자라고 알려져있다. 3rd-party 사업자와 웹서비스 사업자, 그리고 단말 제조사까지 각자의 커뮤니케이션 서비스를 제공함에 따라 그동안 이동 통신사의 가장 큰 수익원이었던 커뮤니케이션 사업의 기반을 잠식당하고 있기 때문이다. 조금 늦은 감이 있지만, GSMA RCS에서는 글로벌 이동 통신사를 주축으로 하여 time to market에 맞는 커뮤니케이션 서비스를 내놓기 위해 고군분투하고 있다. 현재까지 RCS-e 1.2까지 규격이 나와있으며 국내의 경우 내년 1Q에 이동 통신 3사 연동이 가능한 서비스로 제공될 예정이다. 우선은 다운로드 형태의 애플리케이션으로 제공될 것으로 알려져 있고, 향후 사용자의 반응에 따라 native app으로 제공될 것으로 생각된다(RCS-e에 관한 자세한 내용은 여기 참조). 이동 통신사의 경우, 카카오톡이나 마이피플과 같은 커뮤니케이션 시장의 새로운 강자와의 경쟁에서 고객 주도권을 확보해야 하는 절박함에 처해있고 동시에 향후 도래할 LTE 환경에 대비한 새로운 커뮤니케이션 서비스 전략이 필요한 시점이다.

2. 커뮤니케이션 서비스 진화

지금까지 살펴본 바와 같이 이동 통신의 커뮤니케이션 서비스 진영은 중국의 춘추전국시대를 연상케 할 정도로, 하루 하루 그 앞을 내다볼 수 없을 정도로 치열한 전장터가 되어 가고 있다. 이러한 다양한 커뮤니케이션 서비스들을 조망하면서 큰 그림을 그려보면 서비스의 진화를 다음과 같이 네가지의 단계로 구분해 볼 수 있으며 이를 통해 향후 커뮤니케이션 서비스들이 어떻게 진화해갈 지를 짐작해 볼 수 있다고 본다.

1단계: 안정적인 커뮤니케이션 서비스의 제공

카카오톡이나 마이피플이 처음 출시되었을 때 사용자들의 가장 큰 불만은 서비스의 불안정성이었다. VoIP의 품질은 그렇다 치고, 문자가 너무 늦게 도착한다거나 아주 간혹 보낸 문자가 손실되는 것과 같은 오류로 기존 이동통신사가 제공했던 안정적이고 빠른 서비스를 사용해왔던 사용자들로부터 일정정도의 불만이 제기된 것이다. 다행이도 이러한 불안정성은 빠르게 극복되었고 사용자들을 붙잡아 두는 데 성공할 수 있게 되었다. 커뮤니케이션 서비스에서 사용자들이 가장 중요하게 생각하는 것은 어떤 화려하고 다양한 기능이 아닌 안정성이다. 이러한 안정성을 기반으로 단순하고 직관적인 UI/UX를 제공하는 것도 사용자에게 다가가는 매우 중요한 요소라고 알려져 있다. 

2단계: 사용자 간의 관계망 형성

모바일 및 IT산업 분야에서 오픈 그래프라고 불리우는 사용자 간의 관계망을 형성하고 이에 대한 정보를 분석하는 것은 이제는 매우 상식적인 일이 되었다. 사용자 간의 관계망은 향후 정보나 컨텐츠가 흘러다니는 통로가 될 것이고 이를 활용하는 것은 서비스 제공자가 커뮤니케이션 서비스를 기반으로 하는 수익모델을 세우는 데 매우 결정적인 역할을 하게 될 것이다. 이런 측면에서 모바일 주소록의 역할은 향후 매우 확대될 것이다. 페이스북이나 트위터가 페이스북 친구관계나 팔로윙/팔로워 관계를 활용하여 정보 전달 채널을 생성하듯이 모바일에서는 주소록의 컨택트 정보가 그 역할을 대신하게 될 것이다. 커뮤니케이션 서비스의 소셜화의 중심에는 주소록이 위치해 있다.

3단계: 부가서비스 창출

모바일 주소록을 중심으로 한 오픈 그래프를 생성한 후 그 기반위에 다양한 부가서비스를 창출할 수 있다. 카카오톡의 플러스 친구가 가장 대표적인 예라고 할 수 있다. 오픈 그래프외에 OpenAPI는 커뮤니케이션 기반의 수익모델을 가능하게 하는 또 하나의 장치이다. 다수의 기업 및 개인 서비스 사업자가 OpenAPI를 통해 커뮤니케이션 서비스가 제공하는 기능이나 정보를 이용함으로써 커뮤니케이션 서비스를 기반으로 하는 하나의 비즈니스 생태계가 만들어지는 것이다. 웹 기반 서비스 제공자인 페이스북을 기반으로 형성된 생태계와 유사한 생태계가 모바일 단말 기반의 커뮤니케이션 서비스를 기반으로 생겨날 수 있는 것이다. 이러한 이유로, 많은 커뮤니케이션 서비스 사업자들의 경쟁은 어떤 기능을 넣을 것인가에서 어떻게 플랫폼으로 진화할 것인가로 이동하고 있다. 이제는 기능 경쟁이 아니라 플랫폼 경쟁에서 살아남아야 한다. 누가 먼저 유의미한 오픈 그래프를 확보하는가가 가장 큰 숙제로 남아있다. 이러한 측면에서 보면 카카오톡이 아직 까지는 가장 유리한 고지에 서 있다고 봐야 할 것이다.

4단계: 비즈니스 생태계의 형성

앞에서 언급한 오픈 그래프와 OpenAPI는 비즈니스 생태계를 구성하는 데에 가장 핵심적인 요소이다. 오픈 그래프와 더불어 결재 서비스나 위치정보 서비스와 같은 부가서비스 제공에 핵심이 되는 인프라를 구축하는 것도 매우 중요하다. 커뮤니케이션 서비스 기반위에 올라갈 부가서비스를 제공하는 사업자가 기업이 아닌 일반 개인일 수도 있기 때문에, 그 개개인들이 확보할 수 없는 인프라를 커뮤니케이션 서비스 제공자가 제공해 줄 수 있어야 진정한 플랫폼 사업자라고 할 수 있을 것이다. 이러한 관점에서 보면, 아마도 전통의 강자인 이동 통신사가 가장 유리하다고 볼 수도 있겠다. 이와 더불어 빼 놓을 수 없는 것은 데이타 마이닝이다. 오픈 그래프와 OpenAPI를 통해 교환되는 수많은 정보를 분석하고 그 결과를 토대로 보다 개인화되고 효율적인 서비스를 제공할 수 있다. 이렇게 커뮤니케이션 서비스 기반위에 레고를 쌓듯이 인프라와 서비스를 하나하나 쌓아감으로써, 그리고 그런 인프라가 궁극적으로는 서비스를 제공하고자 하는 기업 또는 각 개인에게 공개되고 이용될 수 있을 때 비로소 강력한 비즈니스 생태계가 만들어질 것이다.

3. 마치며

지금 까지 살펴본 바를 근거로, 카카오톡을 제외한 대부분의 커뮤니케이션 서비스는 1 또는 2단계에 머물러 있다고 볼 수 있다. 지금까지는 카카오톡이 지배적인 위치에 있기는 하지만, 조만간 출시될 RCS-e 서비스나 잔쯕 몸을 도사리고 있는 단말 제조사의 반격도 만만치 않을 것이라 생각된다. 

모두에 언급한 바와 같이 커뮤니케이션은 인류가 존재하는 한 소멸되지 않을 서비스로 앞으로 커뮤니케이션 서비스가 단순한 의사소통을 위한 서비스가 아닌, 커뮤케이션 서비스를 통해 사람과 사람을 맺어주는 관계 그물망이 더욱 촘촘해 질 수 있게 하는 그런 서비스가 되었으면 좋겠다. 그 관계 그물망 안에서 서로에게 위안 받고 위로 하고, 기대면서 살아가는 사람사는 그대로가 IT기술을 기반으로 구현될 수 있으면 좋겠다는 생각이다. 아마도 사용자가 얻게 될 가치나 혜택을 우선 생각하는 것이, 좋은 비즈니스 모델이나 건전한 생태계를 만드는 첫 걸음이어야 하지 않을까 한다.

-- Red Mouse

RCS-e v1.1과 v1.2 주요 차이점 소개

지난 4월 GSMA RCS-e 1.1이 나온 이후로 7개월만인 11월 RCS-e 1.2가 발행되었다. RCS-e 1.2의 경우 기능이나 서비스 측면에서 차이는 없으나, 다만 메세지를 처리하는 흐름에 영향을 줄 만한 요소 몇 가지가 있어 소개하고자 한다. 참고로, RCS-e 1.1과 RCS-e 1.2의 차이점에 대해서는 RCS-e 1.2의 ANNEX D. "Scope and summary of changes with respect to the previous version"에 정리되어 있다. 대부분은 RCS-e 1.1에서 언급은 되었으나 자세하 정의되지 않은 내용을 좀 더 상세화하는 내용에 해당하는 데 이 부분들은 본 포스팅에서는 제외되었다.

1. RLS 방식을 이용한 capability discovery 제거

RCS-e에서는 단말의 초기 등록 과정에서 RCS-e Client는 EAB의 각 contact에 대해 capability discovery 절차를 수행한다. RCS-e 1.1에서는 단말의 PRESENCE DISCOVERY가 1인 경우(단말이 presence기능을 이용한 capability discovery를 지원함을 의미), capability discovery 수행의 결과로 RCS-e 사용자라고 규명된 contact의 list(rcs list)를 Presence XDMS에 업로드 하고, 향후 서비스 과정에서 contact의 capability discovery를 수행하게 되는 경우 Presence의 RLS 방식을 이용한다. Presence의 RLS 방식에 의해 단말은 한 개의 Subscription/Notification 트랜젝션으로 RCS-e 사용자에 해당하면서 presence를 지원하는 contact들의 실시간 service capability를 알 수 있다. 

반면 RCS-e 1.2에서는 이와 같은 RLS 방식이 삭제되었다. RLS 방식을 사용하지 않으므로 RCS-e Client는 초기 등록 과정에서 rcs list를 Presence XDMS에 업로드 하지 않으며 실시간 service capability를 알아야 하는 경우 anonymous fetch 기능을 이용해야 한다. 물론, Presence XDMS에서도 rcs list를 저장하는 기능은 제공되지 않는다.

RLS 기능이 RCS-e 1.2에 들어오면서 사라진 이유에 대해 몇 가지의 추론이 가능하겠으나, 개인적으로는 지금 단계에서 RLS를 사용하는 것에 대한 장점이 실제로는 크게 없었을 것 같다는 생각이 든다. RLS기능은 RCS-e 가입자 이면서 Presence 기능을 이용한 capability discovery를 지원하는 사용자가 많으면 많을 수록 트래픽을 절감할 수 있는 구조인데, 서비스 런치 후 초기 단계에서 서비스 가입자가 아직 많지 않을 것이기에, Presence의 복잡한 RLS기능을 굳이 구현해야 하는 가에 대한 문제제기가 있었을 수도 있겠다. 즉, 비용 효율적이지 않다는 것이다. 또 한편으로는 단말 및 서버에서의 복잡성의 증가를 그 이유로 들 수 있겠다. 단말의 contact list에서 RCS-e 가입자를 추리고 RCS-e 가입자 가운데 presence를 지원하는 contact를 추려서 해당 리스트를 SIP SUBSCRIBE의 body에 resource list의 형태로 encoding하여 전송해야 하는 과정이 필요하고, 서버에서도 back-end subscription을 처리할 수 있어야 한다. Back-end subscription 처리를 위한 트랜젝션 및 타이머의 관리, 단말로 Notification을 전송할 때 고려해야 하는 presence 데이타의 크기, Presence 정보를 제 때에 가져오지 못했을 경우의 데이타의 불일치 상황 등 고려해야 할 것들이 상당히 많아 지는 것이다. 이러한 복잡성은 다시 비용효율성이라는 이슈와 연관되어 있다.

2. 형상 데이타 추가

RCS-e 1.2에서는 다음의 두 개의 형상 데이타가 추가되었다.

DEVICE ID

단말에서 gruu 사용 시 기존에 IMEI 대신 UUID를 사용했던 것을 RCS-e 1.2에서는 DEVICE ID의 값에 따라 설정할 수 있게 되었다. 즉, DEVICE ID가 0인 경우 IMEI를 사용하고, 1인 경우 UUID를 사용한다.

IM START SESSION

착신 단말에서 응답 메세지를 전송하는 시점에 대해 기존에는 착신자가 응답 메세지를 작성하는 시점에 200 OK를 전송했으나 RCS-e 1.2에서는 IM START SESSION의 설정에 따라 시점을 달리 할 수 있게 되었다.  즉, 착신 메세지(SIP INVITE)에 대한 200OK를 전송하는 시점은 IM START SESSION이 '0'인 경우, Pop Up 창 터치 시, '1'인 경우 응답 메세지 작성 시, '2'인 경우 응답 메세지 작성을 완료하고 'send'버튼 터치시.로 정의된다.

3. End user confirmation

서비스 제공자가 종단 사용자의 답이 필요한 질의를 하게 되는 경우 SIP MESSAGE의 Contact Type을 application/end-user-confirmation-request+xml로 설정하여 전송한다. 착신 사용자는 SIP MESSAGE의 xml body를 통해 서비스 제공자가 필요로 하는 정보를 분석하고 그에 대한 답을 응답 메세지에 실어 서비스 제공자에게 전송한다. RCS-e1.1 의 경우 서비스 제공자로 전송되는 응답은 수신된 SIP MESSAGE에 대한 200 OK를 사용하거나 새로운 SIP MESSAGE를 사용하여 전송될 수 있었다. 그러나, RCS-e 1.2에서는 200 OK에 의한 응답 전송이 아닌 새로운 SIP MESSAGE만을 사용하도록 하고 있다. 서비스 제공자가 착신 Client의 동작을 제어하기 위해 사용되는 것이 'type' 파라미터인데, RCS-e 1.1과 RCS-e 1.2에서 다음과 같이 변경되었다.

	RCS-e 1.1	RCS-e 1.2
type	Volatile: 응답 메시지를 200 OK응답에 전송. 응답을 전송하기 전에 time out이 나는 경우, 해당 메시지를 폐기	Volatile: 응답 메시지를 새로운 SIP MESSAGE응답에 전송. 응답을 전송하기 전에 time out이 나는 경우, 해당 메시지를 폐기
	Persistent: 응답 메시지를 새로운 SIP MESSAGE로 전송. 메시지 time out 없음.	동일

종단 사용자에 대한 질의 메세지는 서비스 제공자가 종단 사용자의 identity를 확인하거나 서비스 약관등의 변경 사항에 대한 동의를 구하는 데에 매우 유용한 기능이다.

RCS-e 1.1에서 서비스 제공자가 type=volatile 로 설정하여 SIP MESSAGE를 전송했는데, 착신 사용자가 이에 대한 응답을 하지 않는 경우 해당 SIP MESSAGE에 대한 200 OK 응답이 발신측으로 전송되지 않기 때문에 불완전한 트랜젝션이 발생할 가능성이 있다. 이것은 물론, time out이 발생하여 다른 호처리에 영향을 미치지는 않지만, 효율적이지 않다는 의미이다. 또한 SIP MESSAGE를 전송하는 중간 노드가 Proxy가 아닌 B2BUA로 동작하도록 설계되어 있는 경우, 200 OK에 포함된 착신 사용자의 응답 메세지가 발신측까지 전달될 수 없으므로, 이 변경사항은 RCS-e 1.1에 대한 bug fix라고 볼 수 있다.

4. Initiating and Answering a Chat
RCS-e에서는 발신 Client가 SIP INVITE 전송 시 그 body에 사용자 메세지를 포함하도록 정의되어 있다. 원래 RCS-e 기술의 기반이 되고 있는 OMA SIMPLE IM에서는 SIP INVITE에 SDP 나 그룹 채팅을 위한 resource list외의 다른 정보가 실리지 않는 것을 감안하면 SIP INVITE의 body에 사용자 메세지를 담는 것은 RCS-e 고유의 방식이라 할 수 있겠다.

RCS-e의 SIP INVITE를 수신한 착신 단말은 해당 메세지의 body를 decoding하여 착신 사용자에게 보여주고 착신자가 답 메세지를 작성한다거나 하는 임의의 동작을 수행하는 경우 200 OK를 발신측으로 전송하여 MSRP 세션을 맺도록 하고 있다. RCS-e 1.1에서는 RCS-e 의 방식과 다른 경우, 즉 SIP INVITE의 body에 발신 사용자의 메세지가 실리지 않는 OMA SIMPLE IM 방식의 SIP INVITE 처리를 고려하지 않고 있으나, RCS-e 1.2로 오면서 이점에 대한 고려가 추가되었다. 즉, RCS-e Client는 수신된 SIP INVITE의 body에 사용자 메세지가 실리지 않아도 처리할 수 있어야 한다는 것이고, 이 경우 해당 메세지는 대화내역에 포함되지 않는다(SIP INVITE에 사용자 메세지가 없으니 대화내역으로 저장되지 않는 것은 당연해 보인다).

RCS-e 가 GSMA에서 고안한 새로운 방식의 IM 서비스를 제공하고는 있으나, SIP INVITE에 포함되는 feature tag도 같은 값(i.e., +g.oma.sip-im)으로 사용하는 마당에 기존 SIMPLE IM 기반 메세징 서비스와의 호환을 고려하지 않을 수 없었던 것으로 보인다.

이 밖에 RCS-e 1.2에서는 SIP INVITE에 대한 200 OK를 전송하는 시점을 IM START SESSION이라는 새로운 파라미터로 정의하고 있다.IM SESSION START 파라미터에 관해서는 위에 기술했으니 여기서는 생략한다. 다만, 참고로 IM START SESSION이 '2'인 경우 RCS-e Client는 해당 메세지를 버퍼에 잠시 저장해 놓았다가 세션 신호처리가 완료된 후 전송하게 된다.


5. 기타
이 밖에 그룹 채팅에서 RCS-e 1.1의 경우 실시간 capability discovery 절차를 수행하지 않으나, RCS-e 1.2에서는 capability discovery 절차를 수행하고 있다. 또한, 그룹 채팅을 위한 SIP INVITE 전달 시 RCS-e 1.1에서는 중간 노드가 모두 B2BUA로 동작하고 있으나, RCS-e 1.2의 경우 Proxy로 동작한다. 이는 기존 OMA SIMPLE IM에서 그룹 채팅을 위한 SIP INVITE를 Proxy로 처리하고 있기 때문에 이와의 호환을 고려한 것으로 보인다.

이상에서 살펴본 바와 같인 RCS-e 1.2는 RCS-e 1.1과 서비스 측면에서의 차이점은 없으나, 좀 더 현실적으로 time to market을 고려한 것으로 보인다(이동 통신사들이 얼마나 마음이 급할 지 가늠해 볼 수 있겠다). 복잡성을 유발할 수 있는 내용은 과감히 제거되었고 반면에 RCS-e Client나 서비스를 제어할 수 있는 방법은 좀 더 세분화되었다. 한편, OMA SIMPLE IM을 고려한 내용들이 다수 들어가 있는 것으로 보아, 나름대로 시장진입에 대한 고민이 있었던 것으로 보인다.

국내의 경우 2012년 1Q에 RCS-e 서비스가 이동 통신 3사에서 모두 동시에 제공될 것으로 보인다. 그러나, 이번엔 단말의 native client가 아닌 3rd-party application 형태로 제공될 예정이라 기존 카카오톡이나 요즘 뜨고 있는 틱톡등과 얼마나 경쟁할 수 있을지는 미지수다. 어쩌면 아마도 일종의 프로토타입 성격이 강하지 않을까 하는 생각이다. 처음부터 native client로 단말에 심어 서비스를 제공하는 위험을 부담하기 보다는 고객들의 반응을 우선 확인하고 좀 더 보완하여 궁극적으로는 애플의 iMessage 처럼 native client로 제공될 수 있을 것 같다.


References

[1] GSMA RCS-e v1.1, "RCS_e_Advanced_Comms_specification_v1_1_final", Apr.08.2011

[2] GSMA RCS-e v1.2, "rcs-e_advanced_comms_specification_v1.2", Nov.26.2011

-- Red Mouse

GSMA RCS V1에서 V4. 기능별 진화

RCS는 사용자가 보다 효율적으로 개인화된 멀티미디어 커뮤니케이션 서비스를 사용할 수 있도록 하기 위한 서비스 규격으로 2008년부터 GSMA에서 RCE(Rich Communication Ecosystem)의 일환으로 그 표준 작업이 이루어지고 있다. 현재까지 Release4 까지 작업이 완료되어 있다.

RCS-e는 사용자에게 인스턴트 메세지, 비디오, 채팅, 파일 전송 서비스를 제공하는 커뮤니케이션 서비스로 2011년 2월 MWC에서 유럽의 이동 통신사인 Deutsche Telecom, Orange, Telecom Italia, Telefonica, Vodafone이 모여 규격화를 진행하기로 결의한 이후 현재까지 v1.2까지 나와있다. RCS-e 는 기존 RCS Release2를 기반으로 하고 있으며 이동 통신사 간의 상호 연동성과 eco system, time to market을 고려하면서 보다 단순한 사용자 경험을 종단 사용자에게 제공할 수 있는 방향으로 표준화되고 있다.

본 포스팅에서는 서비스 기능과 기술 측면에서 RCS-e 규격의 기반이 되고 있는 RCS 규격의 각각의 기능이 어떻게 변화되고 있는지에 관해 살펴보고자 한다. 각 기능에 대해 자세히 살펴보기 전에 다음 그림은 RCS의 각 기능들이 Release1에서 Release4로 가면서 어떻게 진화하고 있는지에 대한 맥락을 보여준다.

그림에서 RCS의 대부분의 기능은 이미 RCS R1에서 정의하고 있음을 볼 수 있다. 이후에 각각의 기능들이 복수단말 환경과 LTE 환경을 고려하면서 점차적으로 진화하며, RCS Release1에서 정의되지 않았던 새로운 기능들이 조금씩 생겨나고 있다. 커뮤니케이션 서비스가 제공되는 환경에 대한 변화를 고려하면 각 기능들의 진화방향에 대해 조금은 이해하기 편할 수도 있겠다. 다음은 각 기능들의 변화에 대한 세부적인 내용을 기술한다.

1. Configuration Provisioning

RCS 단말이 사용자에게 RCS 서비스를 제공하기 위해 필요한 형상 데이타는 서비스 초기화 과정에서 사용자의 개입 없이 자동으로 사용자의 단말로 전송된다. 형상 데이타를 전송하기 위해 RCS에서는 OMA DM기술에 정의된 절차를 따른다. 사용자가 RCS단말을 켰을 때 RCS Client는 이러한 형상 데이타를 기반으로 네트웍에 대한 단말 등록을 포함하여 사용자가 RCS 서비스를 이용할 수 있는 환경을 구성한다. 대부분의 형상 데이타는 서비스 제공자에 의해서만 수정이 가능하나 정책에 따라 일부의 형상 데이타를 사용자가 관리할 수도 있다. RCS Release1에서 정의한 사용자의 RCS 단말로 전송되는 형상 데이타는 다음과 같다.

• IMS Core/SIP setting
• XDMS/Presence/NAB/IM/File Transfer Settings
• Device Management server access settings
• RCS parameters(e.g., maximum size for File Transfer)
• BA device parameters(e.g., MSISDN)

RCS Release3에서는 RCS Release1에서 정의한 형상 데이타에 네트웍 진화에 따라 그리고 보다 풍부한 사용자 경험을 제공하기 위해 다음의 형상 데이타가 추가로 정의되었다.

• Contents Sharing(i.e., same network file storage platform and settings)
• Personalized Invitation(i.e., maximum text size for invitation)
• URL Label(<200)
• Geo-localization(i.e., minimum periodic update)
• Geo-location declarative text(i.e., maximum text size<200)
• IMS as primary device(i.e., BA Client)
• Expiration and minimum duration between location information update

R1	R2	R3	R4
RCS configurations Provisioning Mechanism	-	Additional RCS configurations	-

사용자의 정보를 외부와 공유하고 커뮤니케이션 플랫폼을 기반으로 하는 부가적인 서비스가 점차 증가함에 따라 서비스 제공자의 입장에서 또는 사용자에 입장에서 제어할 수 있어야 하는 기능들도 증가하게 될 것이다. 위치기반 서비스를 위한 위치정보가 Release3에서 포함되었듯이, N-screen이나 클라우드와 같은 통신 환경을 반영하기 위한 형상 데이타가 향후 추가될 수 있을 것으로 생각된다. 

2. EAB(Enhanced Address Book) & NAB(Network Address Book)

EAB는 기존 단말 주소록의 진화된 형태의 주소록으로서 contact의 기본 연락 정보외에 contact의 service capability(i.e., video call, image/video sharing, file transfer, chat)와 social presence information(i.e., Availability, portrait icon, free text, favorite link, Timestamp)과 같은 부가 정보를 제공한다. 사용자는 NAB로 EAB의 내용을 백업하거나 동기화할 수 있다. RCS Release1에서 정의한 주소록 관련 주요 기능은 다음과 같다.

• contact의 service capability 정보 제공
• Social Presence Information 관리 및 Social Presence Information교환을 위한 상호 인증(i.e., Accept, Ignore, Block, Not answer) 기능
• Black list
• 내부 주소록 및 외부 리소스에 대한 yellow/white page 검색
• NAB연동을 통한 주소록 백업 및 동기화
• Inbox/Outbox/Call log에 대한 통합 뷰 제공

NAB를 통해 복수 단말의 주소록을 백업하고 동기화 했던 RCS Release1의 기능은 RCS Release2에서 각 기능에 대한 세부 사항이 구체화 되었다. 다음은 RCS Release2에 추가된 NAB의 주요 기능을 나열한다.

• NAB와 EAB간의 동기화에 의한 변경 로그 관리
• NAB의 주소록 관리(i.e., contact 추가, 삭제, 변경)
• Hard Delete/Soft Delete 
• 사용자 ID 기반 service capability 및 social presence information 제공  

R1	R2
Service Capability/Social Presence  Information Black list Yellow/White page 검색 AB backup & synchronization Unified view(Inbox/Outbox/Call log)	Support of multiple devices(Converged Environment) Change log AB management(add, delete, modify) Hard delete/Soft delete

사용자의 단말이 모바일 단말과 PC, 테블릿등으로 다양해지고 있고 서로 다른 단말에서 커뮤니케이션 서비스를 다양한 형태로 이용할 수 있는 가능성이 증가함에 따라 통합된 커뮤니케이션 환경에 대한 중요성이 부각되고 있다. 초기 단순한 데이타 스토리지의 역할만을 수행했던 네트웍 기반 주소록은 향후 SNS와 같은 부가적인 서비스를 추가해가면서 진화할 것으로 예상된다. OMA에서 표준화 작업중인 통합주소록, CAB(Converged Address Book)이 그 대표적인 예라 하겠다. OMA CAB은 SNS의 대표적인 특성인 사용자 간 오픈 그래프를 생성하고 데이타를 공유하는 등의 기능을 포함하고 있다.

3. Social Presence Information

Social Presence Information은 RCS 사용자의 상태 정보로서 사용자의 mood, activity, status등이 포함되며, RCS 사용자는 자신의 Social Presence Information을 변경할 수 있다. RCS 사용자는 Social Presence Relationship을 맺고 있는 contact의 Social Presence Information을 EAB에서 확인할 수 있다. RCS에서 정의하고 있는 Social Presence Information은 다음과 같다.

• Availability: 커뮤니케이션에 대한 사용자의 willingness
• Portrait icon: 사용자의 사진 또는 아바타
• Free text: 테스트 기반 모드와 이모티콘
• Favorite Link: 사용자의 홈페이지(e.g., mobile blog)
• TimeStamp: 마지막 갱신 시간

RCS 사용자 간의 Social Presence Relationship은 페이스북의 'Friends'와 같은 개념으로 서로 간의 상호인증 절차를 거쳐 성립된다. Social Presence Relationship 요청 메세지를 수신한 RCS 사용자는 해당 요청을 Accept/Ignore/Block/Not answer 가운데 하나를 선택하여 처리할 수 있다. 두 RCS 사용자가 서로의 Social Presence Information을 확인할 수 있기 위해서는 착신 RCS 사용자가 Social Presence Relationship요청메세지를 수락(Accept)해야 한다. 한편, Social Presence Relationship을 맺고 있는 RCS 사용자는 그 관계를 해제할 수 있는데, 이렇게 Social Presence Relationship 관계가 해제된 두 RCS 사용자 간에는 더 이상 Social Presence Information을 조회할 수 없다. RCS 사용자가 자신의 EAB에서 Social Presence Relationship을 맺고 있는 상대 RCS 사용자를 삭제하는 경우에도 동일하게 처리된다.

RCS Release2에서 BA 단말을 포함한 복수 단말이 지원됨에 따라 RCS 사용자의 Social Presence Information을 확인하고자 할 때 복수 단말간의 서로 다를 수 있는 Social Presence Information값을 통합하여 고려해야 한다. 예를 들어, Chat service가 사용자의 모바일 단말(primary)에서는 지원되지 않고 BA 단말(secondary)에서만 지원되는 경우 해당 RCS 사용자의 service capability는 Chat service를 지원하는 것으로 표현되어야 한다. 이는 사용자의 Social Presence Information이 사용자의 각 단말 별로 정의되는 것이 아닌 사용자 ID 기준으로 정의됨을 의미한다.

한편 Social Presence Information처리와 관련하여 RCS 사용자의 복수단말 가운데 어느 하나의 단말에서 수행한 작업의 결과는 해당 사용자의 다른 단말에도 동일하게 적용되어야 한다. 예를 들어, RCS 사용자가 임의의 다른 RCS 사용자로부터 Social Presence Information에 대한 Subscription 요청 메시지를 수신하고 이를 처리한 경우나 RCS 사용자가 다른 RCS 사용자에게 Social Presence Information 에 대한 Subscription 요청 메시지를 전송하고 그 결과로 수신한 Notification을 처리하는 경우가 이에 해당한다. 즉, RCS 사용자가 복수 단말을 가진 경우 어느 한 단말에서의 요청 처리 결과가 다른 단말에도 반영될 수 있어야 사용자는 서로 다른 단말에서 동일한 RCS 서비스를 제공받을 수 있는 것이다. 이와 동일한 맥락에서, 복수단말을 가진 RCS 사용자가 어느 한 단말에서 자신의 Social Presence Information을 변경한 경우에도 동일한 변경내용이 다른 단말에도 적용되어야 한다. 이때, 단말이 꺼져 있는 경우와 같은 예외상황에 대응하기 위해 RCS Client는 내부적으로 RCS 리스트를 관리해야 하며 이 리스트는 RCS 서버의 값과 항상 동기화가 되어있어야 한다. RCS 리스트는 사용자의 Social Presence Information의 변화를 통보 받아야 하는 대상, 즉 Social Presence Relationship을 맺고 있는 RCS 사용자의 리스트를 의미한다.

RCS Release2에서 사용자의 Permanent Presence State (i.e., Portrait icon, Free text, Favorite link, willingness)는 단말과 Presence XDMS간 연동에 의해 publication되고 service capability의 경우 직접 SIP PUBLISH를 이용해 전송하게 된다.

RCS Release2까지 RCS 사용자가 Social Presence Information에 대한 초대 메시지 전송 시, 해당 메시지를 수신한 착신 RCS Client의 EAB에 발신 RCS 사용자의 ID가 존재하지 않는 경우 발신 사용자의 MSISDN을 화면에 보여주었다. RCS Release3에서는 발신 사용자의 MSISDN이 직접 노출되는 사용자 경험을 개선하고자 발신 RCS 사용자가 Nickname을 설정할 수 있도록 하였으며, 이 경우 동일한 상황(i.e., 착신 RCS 사용자의 EAB에 발신 RCS 사용자의 contact이 존재하지 않는 경우)에서 착신 RCS Client의 화면에는 발신 사용자의 Nickname이 보여지게 된다. 또한, RCS Release3에서는 기존의 text와 기호의 나열로 표현되었던 URL대신 ‘user friendly’ label을 사용할 수 있도록 하는 기능이 추가되었다.

이밖에, RCS Release3에서는 기존에 Social Presence Information의 일부로 제공되었던 service capability가 독립된 정보로 분리되었다. 이는, 기존에 Social Presence Relationship을 맺어야만 확인할 수 있었던 contact의 service capability를 그러한 관계와 상관없이 확인할 수 있게 되었음을 의미한다. 단말에 표시되어지는 contact의 service capability를 조회하여 RCS사용자는 누구와 Social Presence Relationship을 맺을 지를 선택할 수 있다.

RCS Release3에서 사용자는 자신의 위치정보를 다른 RCS 사용자와 공유할 수 있게 되었다. RCS 사용자의 위치정보는 수동으로 텍스트를 입력하거나 또는 지도상에 표기되어 보여질 수 있고 자동으로 일정 주기마다 갱신될 수도 있다. 또한, RCS 사용자는 특정 contact와의 위치정보 공유기능을 차단할 수 있다.

R1	R2	R3	R4
Social Presence information Social Presence Relationship Service Capability	Support of multiple devices(including BA)	Nickname ‘user friendly’ label Service capability split Geo-location sharing	-

Social Presence Information은 규격에 언급된 내용외에도 서비스 제공자가 제공하는 부가서비스에 따라 매우 유연하게 사용할 수 있을 것으로 보인다. 이는 RCS 커뮤니케이션 플랫폼이 그 상위에 다양한 비즈니스 모델의 부가서비스를 수용할 수 있는 구조로 진화할 수 있고 경우에 따라 RCS Client 레벨에서 필요한 정보를 제어할 수 있음을 의미한다. 소셜 플랫폼이 사용자들간의 정보를 흘려보내주는 기반이 된다는 사실을 상기하면 향후 Social Presence Information의 확장은 당연한 변화가 될 것이다.

4. 파일 전송

파일전송을 위한 세션은 통화 세션이나 채팅 세션과는 독립적으로 동작한다. 통화 중이나 세션 중에 사용자는 파일을 전송할 수 있으며 파일 전송요청을 수신한 RCS 사용자는 해당 파일의 전송을 수락/거부할 수 있다. RCS 에서의 파일전송은 Ad-hoc 그룹을 포함할 수 있고 각 contact에 대해 한번에 하나의 파일만을 전송할 수 있도록 되어 있다. 또한, 서비스 제공자는 전송될 수 있는 파일의 크기를 제한할 수 있다. 파일전송 기술은 OMA SIMPLE IM v1.0에 정의된 절차에 따른다. 

5. Contents Sharing(Video/Image Sharing)
RCS 서비스는 Video Sharing 및 Image Sharing 기능을 제공한다. RCS Release 1에서의 Video Sharing과 Image Sharing은 각각 IR.74와 IR.79에 의해 정의되며 Video/Image Sharing을 위한 세션이 모두 음성 통화 세션에 종속된다. 즉, 음성 통화 중 Video/Image Sharing 요청을 할 수는 있으나 그 반대는 불가능하다. 음성 통화와 Video/Image Sharing을 동시에 사용하고 있을때 Video/Image Sharing 의 종료가 음성 통화에 영향을 미치지는 않으나 음성 통화를 종료하는 경우 사용 중이던 Video/Image Sharing 서비스는 종료된다.

Video/Image Sharing기능은 RCS Release2에서도 RCS Release1에서와 마찬가지로 음성 통화 세션에 대한 의존성을 가진다. 다만, RCS Release2의 경우, SIP 망에서 제공하는 고유의 forking 기능에 의한 복수단말 지원이 가능해진다. 이는 사용자가 실제로 음성통화에 사용하는 모바일 단말과 Video/Image와 같은 컨텐츠를 수신하는 단말(e.g., PC)을 달리 할 수 있음을 의미한다.

RCS Release3에서의 Video Sharing은 IR.84에 의해 구현됨으로써 RCS Release2까지 있었던 Video Sharing 세션의 음성통화 세션에 대한 의존성을 제거했다. 이는 사용자가 Video Sharing 서비스를 음성통화와는 무관하게 독립적으로 사용할 수 있게 됨을 의미한다. 그러나, RCS R3단말은 이전 버전의 RCS 단말에 대한 역호환성을 제공할 수 있어야 한다. 즉, 상대편 사용자가 RCS R1이나 RCS R2 단말 사용자인 경우, IR.74에 정의된 형태의 Video Sharing 서비스를 제공할 수 있어야 한다. 이밖에 RCS R3 Video Sharing은 다음과 같은 기능을 제공한다.

• Video Sharing 지연 처리(deferred delivery): URL이나 MMS의 형태로 전송
• 사용자의 컨텐츠 서버에 저장된 video clip을 음성통화와 함께 전송

RCS Release4에 들어와 RCS가 LTE를 지원하게 되면서 좀 더 넓은 대역을 기반으로 고화질의 Video Sharing이 가능하게 되었다. 고화질의 컨텐츠 전송 외에 Image sharing 서비스는 사용자에게 Image를 조작할 수 있는 기능을 제공하고 그 결과가 실시간으로 각 종단 단말의 화면에 반영될 수 있는 기능을 제공하고 있다(Synchronization of real-time interaction). 즉, Image Sharing 서비스 사용자는 화면상의 image를 확대/축소/스크롤하거나 image위에 임의의 그림을 그릴 수 있고 이 결과가 상대편 종단 사용자에게 실시간으로 전송됨으로써 상대편도 동일한 화면을 볼 수 있게 되는 것을 의미한다. 한편, RCS Release4에서의 video sharing은 동영상 멈춤, 재개 기능이 추가되었다. Video sharing 사용자는 단말에서 재생중인 동영상을 임의로 멈추거나 재개할 수 있으며 이러한 동작으로 인한 결과는 상대편 사용자에게 실시간으로 전송되어 상대편 역시 동일한 화면을 공유하게 된다(Synchronized pause and resume). 

R1	R2	R3	R4
IR.74 IR.79	Support of multiple  devices	IR.84(remove voice call dependency) Deferred video  sharing	High-resolution video sharing Synchronization of real-time interaction Synchronized pause and resume

RCS에 기반한 모든 서비스가 반드시 Video/Image Sharing 기능을 제공할 것으로 보이지는 않는다. 그러나, 이 기능은 향후 RCS 서비스를 기반으로 그 위에 탑재될 부가서비스에 대한 가능성을 보여주는 것이라는 정도로 의미를 부여하는 게 맞지 않을까 생각된다.

6. Enhanced Messaging

RCS 메세징 서비스는 MSISDN 기반의 서비스로 IP기반의 메세징 뿐 아니라 MMS와 SMS, Video/Voice Call, Contact Share를 모두 하나의 통합된 환경으로 제공한다. 사용자는 SMS/MMS를 동일한 UI를 통해 작성할 수 있으며(Unified Composer) 해당 내용의 길이와 미디어 타입에 따라 메세지가 SMS로 전송될 지 MMS로 전송될 지를 RCS Client가 판단하여 전송한다. 또한, RCS메세징은 대화형 기반의 서비스로서 사용자와 주고받은 모든 대화는 대화 참여자의 ID(i.e., MSISDN) 기반으로 하나의 대화 채널로 통합(Threaded View)된다.

RCS 채팅은 RCS 단말간에만 지원되며 'near real time'메세지 전송을 보장한다. RCS 채팅은 1-1과 그룹채팅을 모두 지원한다. 그룹 채팅은 ad-hoc 형태로 시작하거나 1-1 대화 세션의 확장일 수 있다. 또한, 상대 RCS 사용자가 RCS 채팅 메세지를 수신할 수 없는 경우 해당 메세지를 다른 형태의 커뮤니케이션 서비스(i.e., SMS, MMS)를 통해 전송할 수 있다. 한편, 그룹 채팅 생성자는 또 다른 참여자를 초대할 수 있으며 그룹 채팅에 참여중인 참여자는 현재 참여하고 있는 참여자의 정보를 확인하거나 참여자의 입장/퇴장에 관한 정보(Participation Information)를 실시간으로 통보 받을 수 있다. 서비스 제공자는 그룹 채팅 서비스를 활성화 하거나 비활성화 할 수 있으며 채팅 세션에서 일정 시간동안 데이타 교환이 발생하지 않는 경우 세션을 자동으로 종료하도록 시간을 설정할 수 있다. RCS 채팅을 위한 기술적 정의 및 절차는 OMA SIMPLE IM v1.0을 기반으로 하고 있다.

RCS Release2에서는 Broadband Access 단말(i.e., PC)에서 SMS를 전송할 수 있는 기능이 추가되었다. 단, BA단말의 경우 SMS 전송 외에 SMS 수신, MMS 발/수신 기능은 제공되지 않는다. 또한, BA 단말에서 전송된 SMS내역은 단말의 Threaded View에 반영되지 않는다. RCS Release2에서는 RCS 채팅요청에 대한 명시적인 수락/거부 기능은 제공되지 않는다. 즉, 사용자는 EAB에서 선택한 contact에게 전송된 메세지는 착신자에게 별도의 수락/거부를 질의하는 절차없이 착신자에게 전송된다. 대신, 착신자가 해당 메세지에 대한 응답 메세지를 전송하는 경우 이를 수락으로 간주하여 해당 채팅 세션을 생성하는 절차를 수행한다.

RCS Release3에서는 BA Client가 primary client의 기능을 수행할 수 있도록 하였다. Primary 단말로 설정된 BA Client는 SMS, MMS를 수/발신 할 수 있으며 이들 각각에 대한 수신확인처리가 가능하다. 그룹 메세징인 경우 요청 메세지 전송 시 함께 전송되는 다른 참여자의 정보를 각 착신자가 확인할 수 있어야 한다. 다음 그림은 메세징 서비스에 관한 RCS R3의 network deployment를 도시한다.

RCS R3 Client는 SMS/MMS 발착신을 위해 RCS 서버에서 별도의 기능을 제공하지 않고  SMS-C 및 MMS-C와 직접 연동하여 전송한다. 이는 RCS Client가 EAB에 저장되어 있는 contact의 RCS 가입자 인지의 여부를 기반으로 Legacy Messaging Service를 이용할 지 RCS 메세징 서비스를 이용할 지 결정함을 의미한다. Primary client가 BA Client인 경우, BA Client를 통해 SMS를 발/수신하기 위해서는 3GPP IP-SM-GW[TS23.204, TS24.341]를 사용한다. IP-SM-GW는 SMS 메세지와 IP메세지간 메세지 변환 기능을 수행한다. BA Client를 통해 MMS를 전송하는 경우 3GPP의 [TS23.140]에 정의된 절차를 따른다.

RCS Release4에서의 메세징 서비스는 기존의 SMS/MMS가 가지고 있던 서비스적 한계를 모두 제거하면서 SMS/MMS 사용자에게도 IP메세징 서비스와 동일한 사용자 경험을 주고자 하였다. 또한, Message Storage를 제공함으로써 사용자의 복수단말에서 발/수신되는 모든 대화이력을 통합된 환경에서 제공하고 있다. RCS Release4에서의 text messaging은 모바일 단말과 BA Client를 모두 지원하며 기존 text messaging(SMS)이 가졌던 메세지 길이의 제한을 가지지 않는다. 이 경우, RCS R4 단말과 이전 버전의 단말간 text messaging 교환을 위해서 IP-SM-GW는 RCS R4단말에서 전송된 text message를 chunked message로 나누어 전송 한다. RCS R4 메세징 사용자는 그룹 contact에게 text message를 전송할 수 있다. Group text message를 수신한 사용자는 이에 대한 응답을 그룹의 모든 수신자에게 전송할 수 있다.

RCS Release4에서 새롭게 소개된 Network-based Message Storage는 사용자가 발/수신한 멀티미디어 메세지를 저장한다. 메세지 저장 시 별도의 메타 데이타를 생성해야 하며, 이 메타 데이타는 사용자가 자신의 Message Storage의 내용을 조회하거나 단말로 다운받기 위해 사용된다. 또한, 사용자는 Message Storage의 폴더체계를 원하는 형태로 관리할 수 있다. Message Storage에 저장된 메세지는 사용자의 복수 단말에 동일하게 적용될 수 있으며, 이를 통해 복수 단말을 가진 RCS 사용자에게 일관된 대화이력 뷰를 제공할 수 있다.

RCS Release4에서는 non-RCS 사용자(e.g., SMS/MMS 사용자)가 Chat 세션에 참여할 수 있다. 서비스 제공자의 정책에 따라 non-RCS 사용자는 명시적인 초대를 받고 정해진 형태의 응답 메세지를 전송함으로써 Chat 세션 요청을 수락/거부할 수 있거나 또는 자동으로 Chat 세션에 참여할 수 있다. Chat 세션에 참여한 non-RCS 사용자는 다른 RCS 사용자와 마찬가지로 모든 메세지와 참여자 정보 및 이벤트를 받아 볼 수 있으며, non-RCS 사용자의 메세지 또한 Chat 세션의 참여자 모두에게 전송된다. non-RCS 사용자는 서비스 제공자의 정책에 의해 규정된 형태의 메세지를 전송함으로써 해당 Chat 세션을 종료할 수 있다.

RCS Release4에서의 주요 커뮤니케이션 기술은 OMA CPM에 기반하며 다음은 RCS Chat 서비스를 위한 개념도를 예시한다.

R1	R2	R3	R4
Support of Legacy Messaging Unified Composer Threaded View IP-based Chat 1-1/Ad-hoc Group Chat IM Pager/Large Mode	BA Client included(only to send SMS) No Accept/Reject from a recipient IP-SM-GW interworking	BA Client being primary device BA Client being able to send/recv SMS/MMS	Large text messaging Group text messaging Message Storage Support of unified view across multiple devices. Non-RCS incorporation into RCS Chat session.

RCS의 Enhanced Messaging 기능은 초기 OMA SIMPLE IM 1.0 기술에 기반하고 있으나, RCS Release4로 오면서 OMA CPM 1.0 기술을 부분적으로 채택하고 있다. OMA CPM은 SIMPLE IM의 기능을 그대로 수용하면서 Legacy Messaging Service를 통합하여 제공하고 있다.

7. 복수 단말 환경
RCS Release1에서 모바일 단말을 중심으로 제공되는 서비스는 RCS Release2로 오면서 기존의 모바일 단말 외에 Broadband Access Client에 대한 지원도 가능하게 되었다. 이에 따라 RCS 사용자는 각 단말에서 Communication, EAB, Social Presence Information등과 같은 서비스 측면에서 동일한 서비스 환경을 제공받을 수 있게 되었따. 복수 단말 가운데 CS 접근 능력을 가지는 모바일 단말이 primary 단말이 되며 BA Client느느 secondary 단말로 동작한다. 또한, RCS 사용자의 모든 단말은 primary 단말이 가지는 하나의 MSISDN으로 묶인다.

RCS Release3으로 오면서 BA Client를 primary 단말로 선택하는 것이 가능해졌다. 이는 BA Client에서도 SMS/MMS의 발/수신을 할 수 있게 되었음을 의미한다. 이 서비스는 단말이 CS(Circuit Switched)망의 SMS-C/MMS-C를 직접 연동하거나 IMS의 IP-SM-GW와 연동함으로써 가능하다. 그러나, 이 경우 종단점이 각각 BA Client와 모바일 단말인 경우 메세지 전송 방향(또는 사용하는 메세징 서비스 종류)에 따라 네트웍 상의 루트가 상이하기 때문에(IP-SM-GW 또는 RCS-IM), 대화 내역에서 동일한 contact 대한 발/수신 대화내역의 통합이 어렵다는 단점이 있다. 이는 EAB 에서 contact의 RCS 가입 여부에 따라 RCS 서비스를 이용할 지 SMS/MMS를 사용할 지를 결정하기 때문에 발생하는 단점이기도 하다.

RCS Release4로 오면서 기존의 RCS 플랫폼에서 OMA CPM IWF를 채택함에 따라 RCS 단말은 RCS 서비스와의 단일한 인터페이스의 구현이 가능해졌다. 이에 따라 RCS Release4에서는 IP 메세지 및 Legacy 메세지의 구분 없이 통합된 대화내역의 관리가 가능해졌으며 또 한편으로 Network-based Message Storage가 제공됨에 따라 서로 다른 복수 단말간 통합된 커뮤니케이션 관리가 가능해졌다.

R1	R2	R3	R4
-	BA Client as a  secondary	BA Client as a  primary	-

커뮤니케이션 서비스를 제공하는 데 있어서의 복수 단말 환경은 향후 N-screen 단말 및 서비스의 증가와 함께 다양한 형태로 진화할 수 있을 것으로 생각된다.

8. Network Value Added Service(NVAS)
RCS Release3에서는 서비스 제공자가 Network Value Added Service를 RCS 사용자에게 제공할 수 있도록 한다. NVAS의 목적은 RCS 사용자에게 보다 풍부한 사용자 경험을 제공하기 위한 것으로 구체적으로 어떤 서비스를 제공할 지는 각 서비스 제공자가 정하도록 되어 있다. 다만, RCS Release3에서는 Contents Sharing과 Chat 서비스에서의 media processing을 통한 풍부한 사용자 경험을 제공하는 것만을 언급하고 있다.

R1	R2	R3	R4
-	-	Contents Sharing  enriched by Media  Processing Chat enriched by  Media Sharing	-

RCS 서비스가 결국은 개방형 커뮤니케이션 플랫폼으로 진화할 것임을 고려할 때 다양한 비즈니스 모델을 가진 3rd-party 서비스를 어떻게 수용할 지에 대한 고려는 향후 더욱 구체화될 것으로 보여진다. 

9. Synchronization
사용자의 주소록(EAB)은 네트웍 주소록(NAB)을 통해 백업되고 동기화 된다. RCS Relese2 이후부터 제공되는 복수 단말에서의 주소록 동기화 역시 NAB 의 동기화 기능을 이용해 제공되며, RCS 사용자는 동기화 기능을 이용해 서로 다른 복수 단말간 통합된 주소록 환경을 제공받는다. 주소록 동기화 기술은 OMA DS 1.2.1에 기반한다. 디음은 NAB의 동기화 Architecture를 도시한다.

RCS Release4에서는 동기화의 대상을 캘린더와 To do list와 같은 비주소록 컨텐츠를 포함하는 PIM으로 확장할 수 있도록 하였다. RCS 사용자는 서비스 초기화 시점에 EAB를 비롯한 컨텐츠의 동기화 기능을 이용할 지의 여부를 결정한다. 동기화 기능을 사용할 경우 사용자는 동기화 주기를 비롯한 세부적인 사항을 설정할 수 있는 방법을 제공받는다. 사용자가 초기화 시점에서 동기화 기능을 선택하지 않은 경우, RCS Client는 RCS 사용자가 단말의 PIM 데이타를 조작할 때마다 RCS Service Subscription Reminder(SSR)을 기동하여 사용자로 하여금 동기화 기능을 사용하도록 유도할 수 있다. RCS 서비스에서 동기화가 가능한 PIM 데이타는 RCS "Resource Subscription" Managed Object에 포함되며 이와 관련한 기술은 OMA DS MO에 정의되어 있다.

R1	R2	R3	R4
NAB synchronization	-	-	PIM synchronization

10. Roaming
RCS Release4에서는 Roaming 상황에서 사용자와 서비스 제공자가 PIM과 메세지 전송 기능을 제어할 수 있는 기능을 제공한다. PIM의 동기화와 관련하여 RCS Client는 사용자에게 해당 기능을 사용할 지에 대한 확인을 받아야 한다. RCS사용자는 해당 기능을 단말에서 disable시킬 수 있어야 하고 사용자가 해당 기능을 사용하는 경우 과금관련 필요한 정보를 제공할 수 있어야 한다. 메세지 전송 기능과 관련하여 RCS 사용자는 해당 메세지의 헤더 정보와 함께 Notification을 수신할 수 있고, 해당 메세지의 착신 여부를 사용자가 선택할 수 있다.

R1	R2	R3	R4
-	-	-	User confirmation to  services in Roaming  situation

결론
GSMA RCS 서비스 규격은 사용자에게 커뮤니케이션 기능을 통합된 환경에서 제공할 수 있기 위한 서비스적인 측면과 향후 가입자 기반의 오픈 플랫폼으로 진화할 수 있는 비즈니스 모델 측면에서 표준화가 이루어지고 있다. 실제로 시장에서 많은 이동 통신사들이 실제로 구현하는 서비스는 RCS-e 기반 서비스이지만 향후 RCS-e 규격이 진화하는 방향을 가늠하는 데에 지금까지 논의되어 왔던 RCS 1,2,3,4가 많은 참고가 될 것으로 보인다. 표준규격으로 바라보는 향후 커뮤니케이션 서비스의 진화 방향에 대해서는 다른 포스팅에서 다루고자 한다.


Reference
[1] GSMA RCS "R1_030_140211_rcs_rel_1_func_descp", Functional description, R1.
[2] GSMA RCS "R1_031_140211_tech_real_v2", Technical realization, R1.
[3] GSMA RCS "rcs_rel2_func_descp_2", Functional description, R2.
[4] GSMA RCS "rcs_rel2_tech_real_2", Technical realization, R2.
[5] GSMA RCS "rcs_rel3R3_020_14rcs_rel3_func_descp_v2", Functional description, R3.
[6] GSMA RCS "rcs_rel3_tech_real2", Technical realization, R3.
[7] GSMA RCS "rcs_rel4_functional_description_v1", Functional description, R4.
[8] GSMA RCS "rcs_rel4_technical_realization_v1", Technical realization, R4.


-- Red Mouse