Google+ is the social backbone
O'Reilly Radar의 필진인 Edd Dumbill이 "Social Backbone"이라는 새로운 개념을 제시함으로써 "Google+가 Facebook을 대체할 것이다 또는 대체하지 못할 것이다"는 틀에서 갑론을박식으로 진행되었던 구글 플러스 논쟁에 새로운 화두를 제시하고 있다 (2011년 7월 19일).
이 아티클의 핵심주장은 대충 다음과 같다. 1) 이메일이 개방적인 표준을 채택함으로써 이질적인 시스템간 상호호환성이 보장됨에 따라 시공간을 초월하여 공유와 Collaboration이 가능해 지고, 그 위에서 동작하는 다양한 오픈 에코 시스템들이 발전한 것처럼 Google +가 개방을 통해 지금까지 인터넷에 존재하지 않았던 Social Layer의 상품화를 초래할 것이고, 여기에서 많은 어플리케이션이 상호 호환되는 구조로 발전할 것이다. 2) Facebook은 친구관계의 형성이 폐쇄적인 구조이고, 컨텐츠별로 URI가 없고, Facebook의 Social Layer를 사용하면 Facebook 플랫폼에 종속되는 구조이기 때문에 소셜 백본이 될 수 없는 반면 Google은 웹의 개방에 적극적이고, Data Ownership이 완전히 User에게 있고, 구글+ 비회원에게 이메일로도 포스트를 전달할 수 있고, 서클은 상호 호환성이 보장되는 구조이기 때문에 Social Backbone으로 발전할 수 있다는 것이다.
이 아티클을 다 읽고 나면 당장 이 사람이 주장하는 "Social Backbone이 멀까?"라는 의문을 제기하게 된다. Edd Dumbill은 Social Backbone의 요구사항으로 1) Identity 2) Sharing 3) Notification 4) Annotation 5) Communication 등 5가지를 제시하는데, 이것들은 비록 상호 호환되지 않기는 하지만 이미 Google+뿐만 아니라 Facebook, Window Live 같은 메신저에서도 이미 맹아적인 형태로 실재한다.
개방이라는 관점에서 봤을 때 Facebook은 "OAuth 인증체계"와 "Social Plug-In"을 통해 이미 자신의 플랫폼을 3rd Party에게 거의 완전히 개방함으로써 사람과 사람뿐만 아니라 사람과 웹 페이지에 의해 Representation되는 현실세계의 Object들까지 Facebook의 Social Graph로 이미 Integration시키고 있다. 실제로 수십만개의 웹사이트들이 Facebook의 Open Platform을 통해 자신의 서비스를 제공할 수 있게 됨에 따라 Facebook 자체가 3rd Party에게 개발환경을 제공하는 Web OS로서의 지위를 획득하게 된 것이다. 이런 관점에서 만약 Social Backbone이 존재하게 된다면, Google + 보다는 Facebook이 더 유리하다고 보는 것이 더 현실적이지 않을까 ?
필자는 Facebook의 Social Layer를 활용할 수록 Facebook 플랫폼에 대한 종속이 심해지는 구조이기 때문에 Facebook은 Social Backbone이 될 수 었다고 주장하는데, 개방형 표준의 추구를 통해 Google+가 Facebook을 이기고 Social Backbone의 자리를 탈환한다면 필자의 생각처럼 Google+가 모든 어플리케이션이 상호 호환되는 중립적인 플랫폼처럼 동작하게 될까 ? 즉 구글 +가 Social Backbone으로 동작하기 위해서는 Social Network 시장의 독점적인 지배력을 바탕으로 다른 SNS와 상호 호환 - 구글+와 Facebook, Twitter 등 Social Software간 버디목록이 공유되고, 상호간 포스트와 댓글이 호환되는 구조 - 을 강제할 수 있고, 상호호환이 보장되는 개방적인 에코시스템하에서 다른 3rd Party들도 다양한 App.들을 개발할 수 있어야 가능할 것 같은데, 이는 현실적으로 볼 때 Facebook과 꼭 마찬가지로 결국 Google 플랫폼에 대한 사업자와 User의 종속성을 심화시키는 것 아닌가? ? 더 솔직히 말하면 Google+가 Facebook을 흉내내는 것이 불과한 것 아닌가 ?
어쨋든 이런 의문을 뒤로 하고 필자가 Google+가 인터넷에 Social Layer를 추가함으로써 "Social Backbone"으로 발전할 것이라는 개념을 제시한 것은 신선하고 흥미롭기까지 하기 때문에 보다 정확한 이해를 위하여 "Social Backbone"에 관한 필자의 아이디어를 나름 번역/오역/의역해 보고자 한다.
Google+의 런칭으로 웹에 근본적인 변화가 시작되었다. 이 변화로 인해 (개인 데이타가 저장되어 있는) 격납고가 파괴되고, User들에게 권력이 이양되며, 새로운 소프트웨어의 개발과 사람간 협력이 보다 높은 단계로 발전할 수 있는 기회가 창출될 것이다.
Social Feature들은 만연해 있고, 네트워크로 연결된 서비스와 우리의 인터액션에 근본적이다. 어플리케이션 간 협업 (collaboration from within applications)은 오늘날 웹에서 검색을 통해 답을 구하듯이 자연스럽게 될 것이다.
It's Not Just About Google vs. Facebook
Facebook의 경쟁자로서 Google+에 관심의 초점이 모아지고 있지만, 문제를 이런 맥락에서 접근하는 것은 근시안적이다. Google+ 런칭의 결과는 훨씬 더 광범위하고 흥미로우며 의심의 여지 없이 논쟁적이다.
Google+는 웹 전체의 소셜백본으로 신속하게 성장하고 있는 씨앗이고 모든 소셜 그라프를 궁극적으로 통합시키는 촉매제이다 (the rapidly growing seed of a web-wide social backbone and the catalyst for the ultimate uniting of the social graph). 구글측에서취하게 될 모든 조치는 개방성을 강화함으로써 Social Layer의 상품화를 초래하게 될 것이다(All it will take in Google's part is a step of openness to bring about such a commoditization of the social layer). 이러한 개방성이야말로 평등주의적일 뿐만 아니라 Facebook에 대응하기 위한 가장 효과적인 경쟁전략(the most effective competitive measure)이기도 하다.
웹 검색이 웹에 있는 문서들을 사람들과 연결시키 듯이 소셜백본은 전체 웹에서 발생하는 일거수 일투족까지 추적하여 사람들의 서로 직접 연결시킨다 (the social backbone connects people to each other directly, across the full span of web-wide activity). 비록 웹의 사용이 User들에게는 보이지 않는다 하더라도 의심을 제거하기 위해 나는 "Web"에 네트워크에 연결된 폰과 태블릿 애플리케이션도 포함시키고자 한다.
검색의 도입으로 사람들은 도메인 네임과 URL을 기억할 필요가 없게 되었다. 검색은 컨텐트를 찾는데 우월한 방식이다. Google+가 Social Backbone으로 자리잡게 되면 Sharing과 Notification 같은 일반적 서비스는 말할 것도 없고, 우리들은 더이상 이메일 주소를 관리하고 부산하게 친구맺기를 하고(laborious friending) 퍼미션을 허용하는 행위(permission- granting activity) 등을 할 필요가 없게 된다.
Google+는 일개 회사의 서비스에 불과하지만, 그로 인해 인터넷을 위한 Social Layer의 상품화가 시작되었다고 선언할 수 있는 근거들이 존재한다 (herald it as the start of commidity social layer for the internet). Google은 Google+를 가두리 양식장 (Walled Garden)이 아니라 웹의 일부로 만들기로 결정했다. 지금부터 구글이 개방성과 상호 호환성을 존중하는 성향(an inclination to openness and interoperation)이 있다는 것을 설명하고자 한다.
It's time for the social layer to become a commodity
소셜 네트워크의 시대가 시작된지 이제 몇년이 지났다. 소셜 그래프를 장악하고 그것을 활용하고자 하는 경쟁에서 많은 회사들의 성공과 실패가 반복되었다. 좋은 의도를 가지고 밑바닥에서부터 시작한 많은 시도가 있었다. 대부분 비업무적인 어플리케이션에 제한되어 있긴 하지만 Facebook이 사회적 주목의 지배자(dominant owner of social attention)가 되면서 이 게임에서 최종 승리했다.
소셜 소프트웨어에서 이러한 활동은 무엇을 의미하는가 ? 분명히 컴퓨터 유저들인 우리들에게소셜 피쳐는 중요하다. 우리는 친구들을 찾아내고 공유하고 만나기를 좋아하지만 반드시 친구와만 그런 것은 아니다. 우리는 직장동료와 가족, 잠재적 고객, 재미있는 유명인들과도 교류하고 싶어한다.
현재 우리에게 이러한 그룹들은 고착화되어 있다(siloed). 우리는 특정 그룹에서 친밀도가 다른 사람들과 여러가지 컨텍스트에 직면해서 상황에 적합하게 특정 시스템을 선택적으로 사용하게 된다. 게임을 하거나 친구 및 가족과 연락할 때는 Facebook을 사용하고, 고객이나 채용담당자, 제품 판매자와 연락할 때는 Linkedin을 사용한다. 친구와 유명인용으로는 트위터, 전문가 커뮤니티용으로는 Instagram, Flickr, Yammer, 기업용으로는 Saleforce Chatter를 사용한다.
이러한 상황은 표준화되기 이전의 이메일의 잔재와 비슷하다. 즉, 서로 다른 체계에 의해 반쯤밖에 호환되지 않고 자기끼리만 통하는 가두리 양식장 (Differing semi-interoperable system, many as walled garden). 이들 SNS의 사업 계획 자체가 소셜 그라프를 어떻게 "소유"할 것이냐라는 관점에 뿌리를 두고 있다 (Business plasn predicated on somehow "owning" the social graph). 소셜 소프트웨어는 폐쇄적인 세계를 가정하는 시스템들로 가득 차 있고(The Social software scene is filled with systems that assume a closed world), 비즈니스로서 쉽게 관리하는데 초점을 맞추고 있으나, 궁극적으로는 고객의 현실적 필요에는 부합하지 않는 불편한 인터페이스의 제공으로 귀결된다.
이에 반해 상호호환되는 이메일 시스템은 광범위한 혜택을 창출해 냈고, 공식적이든 비공식적이든 많은 에코시스템이 그 위에서 번성하게 되었다(many ecosystems to emerge on top of it). 이메일은 아이디어를 신속하게 확산시키고 협업과 커뮤니티의 형성을 촉진시키는 등 사람들간 거리와 시간을 단축시켰다. 예를 들어 이메일이 없는 Open Source 혁명을 상상하기는렵다.
만약 Social Layer가 표준화되어 모든 어플리케이션에 적용될 수 있다면(When the social layer becomes a standard facility), 다양성과 생산성, 창의력의 기회가 증강된 세계로 우리를 인도하게 될 것이다. 그러나 현재의 SNS는 우리가 이메일 이전에 시공간적 제약으로 인해 수고했던 만큼은 아니지만 데이타 사일로의 국경에 의해 제한되고 있다. 우리의 정보는 다른 이들에 의해 소유되고 있기 때문에 우리 것을 기꺼이 공유할 수 없으며 협업은 어플리케이션의 제한에 의해 대부분이 속박되어 있다 (Our information is owned by others, we cannot readily share what is ours, and collaboration is still mostly boxed by confines of applications ability).
소셜 백본이 구축되면 다양성이 신장될 것이다. Social Network를 편리하게 활용할 수 있게 됨에 따라(ready availability of social network) 큰 공을 들이지 않고 커뮤니티를 형성할 수 있고, 중앙 컨트롤 센터의 불허 또는 검열 등의 리스크도 없기 때문에 다양한 관심사를 공유하는 커뮤니티들이 생성될 것이다.
이메일 상호 호환성의 효과는 커뮤니케이션이 활성화에 그치지 않았다. 이메일간 상호호환성은 문서 포맷의 표준화와 풍부한 협업의 촉매제가 되었다. 소셜 백본이 도입되면 Permission, Identity, Sharing을 핸들링하기가 훨씬 쉬워지긴 하겠지만 어플리케이션간 상호호환성 보장을 위한 자연스러운 압력으로 작용하게 될 것이다(naturally exert pressure for further interoperation between applications). 일단 그들의 identity가 모든 application에 거쳐 통합된다면 (One their idientity is united across applications, 하나의 idientity로 여러개의 어플리케이션을 사용할 수 있게 된다면), User들은 자신들의 데이타가 자유롭게 흘러다닐 수 있기를 기대할 것이다. (동일한 identity로 하나의 어플리케이션에서 축적된 데이타를 쉽게 다른 어플리케이션으로 옮기는 것이 가능하다는 의미인 것 같음, Data Portability)
실제로 이러한 상호호환성을 보장하려는 움직임은 이미 벌어지고 있다. 우리는 트위터, 페이스북, 구글의 인증 메카니즘(sign-on mechanism)을 활용하여 웹사이트와 게임을 사용하고 있으며, 소셜 소프트웨어와 클라우드 기반의 identity, 전자지갑 서비스를 서로 연결하고 혼합시켜 사용하고자 한다 (federate and intermingle social software, cloud based identity, and wallet services).
What a Social Backbone Would Do !
User 입장에서 볼 때 소셜 백본이 우리에게 무슨 일을 해줄 수 있을까 ? 여기서 핵심은 컴퓨터가 우리에게 더 나은 서비스를 제공하게 된다는 점이다 (The point is to help computers serve us better, 역주 : 소셜 백본의 도입효과가 너무 추상적이지 않나?). 우리는 문서와 정보뿐만 아니라 특정 그룹의 사람들이 연관되어 있는 컨텍스트에서 자연스럽게 일할 수 있게 된다. 다른 사람들과 함께 일할 때 커뮤니케이션 bandwidth가 더 높고 빠를 수록 좋다.(역주 : 글쓴이는 직장에서 주로 일하는 상황을 가정하여 소셜백본의 효과에 대해 얘기하고 있다. 그래서 상호 호환성이 보장되는 구조로 이메일이 표준화됨에 따라 원격지에 떨어져 있는 많은 사람들과의 Collaboration이 가능해 졌다는 것을 사례로 들고 있으며, 소셜 백본을 통해 여러 그룹들이 함께 일하는 상황에 적용해서 "Social Backbone의 효과"에 대해 얘기한다. 이 사람 얘기를 듣다 보면, 동일한 identity로 여러 개의 Application을 사용하면서 상호호환성과 mashup이 가능해 진다는 SDP가 생각난다)
직장에서 collaboration이 이루어지는 상황을 예로 들어보자. 오늘날 그룹웨어 솔루션은 폐쇄적인 세계이다. 그룹웨어 솔루션들이 특별히 유연한 소셜 모델 또는 다양한 어플리케이션이나 컨텐트를 충분히 리치하게 아우르는 것은 비현실적이기 때문에 프로세스들의 제한적인 셋트들만을 지원한다. 소셜 백본이 도입되면 개별적인 어플리케이션들로부터 그룹웨어를 해방시키게 된다 (Social Backbone could make groupware out of every applications). 미래에는 우리가 포토샵, 아이무비, 엑셀 같은 문서작업을 하면 소셜 백본을 통해 다른 사람에게 반복해서 전화한 것과 같은 효과가 자동으로 발생되거나 "헤이 ! 이거 어때?"라고 말할 수 있게 된다 (For the future Photoshop, iMovie and Excel, it adds equivalent power of calling someone over and saying "Hey, What about this?")
※ 역주 : Edd Dumbill이 예로 들고 있는 회사는 아마도 클라우스에 모든 문서파일이 자동으로저장되고 있을 것 같고, Document Application들이 Social Backbone에서 정의하고 있는 표준화된 Feed API를 Call할 수 있게 되어 있어서, 내가 문서작업을 하고 저장할 때 누구랑 공유할 것인지 조직도 상의 그룹을 선택하면 자동으로 해당 그룹에 속한 사람들에게 실시간 Feed 또는 Notification이 날라가게 되는 구조일 것 같다. 그런데 이런 식으로 Collaboration이 이루어 지게 된다면, 현재 Exchange Server 기반의 Outlook에서 LDAP에 저장된 조직도를 불러와서 이메일을 통해 공유하는 것이랑 별루 다르지 않을 것 같긴 하다.
이번에는 당신이 자주 접촉하는 사람들에 대해 얘기해 보자. 당신이 지금 여러 사람과 함께 중요한 일을 하고 있다. 예컨데 애들이 함께 노는 와중에 당신이 학부모회 모금 활동을 위해 Jane과 함께 일하고 있다고 가정해 보자. 당신은 우선 Jane을 "PTA and Playdates" 써클에 끌어다 놓고, PTA 써클에 있는 부모들에게 포스트를 보낸다. 그리고 캘린더에서 약속이 없는 날로 Playdates 약속을 잡는다 (calendar's free/busy info into Playdates).
이제 당신이 필요한 정보를 공유한다. 다음 주 목요일 당신은 학교에서 Jane을 만나서 play dates와 다가오는 학부모 모임을 화제로 자연스럽게 대화를 나눈다. 당신이 Jane을 폰주소록에 추가하니 당신이 작성중인 레터의 링크가 생성되어 있고, 어떤 사람들은 서로 시간이 나는 날로 변경을 제안했다(소셜 백본의 어떤 가치를 보여 주기 위해 이런 시나리오를 설정했는지 이해하기 어렵다. 아마도 Facebook과 달리 구글 써클을 통해 학부모들끼리 학부모 모임 날짜를 언제로 할 것인지에 관한 정보를 공유할 수 있다는 것을 설명하는 것 같다).
컴퓨터 시스템들에게 우리가 알고 있는 사람을 가르쳐 주면, 컴퓨터 시스템들은 우리가 무엇을 알아야 할 필요가 있는지 언제 알아야 하는지도 더 잘 예측해 줄 것이다. 나는 (소셜 백본이 도입으로 그룹별 정보공유의) 편의성이 얼마나 개선될 수 있는지에 초점을 맞춰 이런 예로 들었다. 일단 플랫폼이 개방되면 플랫폼의 창시자들이 상상해 왔던 것 이상을 훨씬 뛰어 넘는 창의적인 결과가 성취된다는 것을 컴퓨팅의 역사는 종종 보여주고 있다.
소셜 백본은 Social Software를 민주화한다. 개발자들은 가두리 양식장의 제약으로 부터 자유로와 지고, 당신의 친구들, 동료들과 무엇을 할 것인지에 대한 통제력을 바로 당신, User들에게 돌려준다.
소셜 백본은 어떤 서비스를 제공하는가? 우리는 오늘날 웹과 소셜 소프트웨어 어플리케이션이 제공하는 서비스들로부터 다음과 같은 것들을 추출해 낼 수 있다.
Identity - 당신을 User로서 인증(authenticating)하고, 당신에 관한 정보를 저장
Notification - User들에게 컨텐트의 변화 또는 친구의 컨텐트의 변화에 관해 알려 줌
Communication - 시스템 멤버들 간 직접적인 상호작용
이러한 기능들이 새로운 요구사항들은 아니지만, 이들 각각은 기존 시스템에 의해 서로 다른 방식으로 수용되고 있다. 구글과 아마존은 합리적인 수준에서 보장해 주는 identity broker로 동작하고 있다. 신뢰도가 구글 아마존보다 덜하긴 하지만 Facebook과 Twitter도 마찬가지 이다.
대부분의 웹서비스 호스트는 비록 편집 보다는 Read 권한에 초점을 맞추기는 하지만 컨텐트의 공유를 지원한다. 이메일에서 시작해서 RSS로 종결된 notification은 Facebook의 근본적인 기능일 뿐만 아니라 트위터의 매우 중요한 기능이 되었다 (Notification originated in email, graduated through RSS, and is now a major part of Twitter significance, as well as fundamental feature of Facebook). Annotation은 과거 하이퍼링크로 처리되었는데 웹만큼이나 오래되었지만, 블로깅, Disqus, Twitter와 Facebook에 의해 가장 유용하게 구현되었다. User들간 커뮤니케이션은 Multi-User Operating System만큼이나 오래되었지만 오늘날 Facebook의 챗과 Instant Messaging에 의해 가장 효과적으로 구현되었으며, 임시로 생성되는 그룹들도 쉽게 형성될 수 있다.
불행이도 이런 Social Facilities에 대한 오늘날의 답변은 그것이 구현되는 방식에 의해 제한되고 있다. 그중 Facebook이 가장 포괄적인 Social Features를 제공하고(Facebook provides the most rounded complement of social features) 있으므로 왜 Facebook은 인터넷을 위한 Social Backbone을 제공할 수 없느냐라는 합리적인 질문을 던지게 된다.
Facebook의 최대 단점은 그것이 폐쇄적인 플랫폼이라는데 있다. Facebook은 웹이 되기를 원하지 않는다. Facebook은 웹의 시티즌들을 자신의 왕국에 끌어 들이는데 집착하여 웹에서 그런 방식으로 서비스를 제공하기 때문에 Facebook으로 권력이 집중되는 결과를 낳았다는 점에는 의심의 여지가 없다. Facebook에서 컨텐트 아이템들은 독립적인 URI가 존재하지 않기 때문에 그 본성상 보다 넓은 웹의 일부로 통합될 수가 없다 (Content items in Facebook do not have a URI, so by definition can never be part of the broader web). 당신이 Facebook의 Social Layer를 사용하고 싶다면, 당신은 - Web의 일부가 아니라 - Facebook 플랫폼의 일부로서 종속되어야만 한다.
※ 역주 : 전세계 수십만개의 웹사이트와 모바일 Application들이 1) OAuth 기반의 Facebook의 "회원가입/인증" 체계를 활용하여 신규가입자를 모집/학보하고 있으며, 2) "Like"나 "Activity Feed" 등 Social Plug-in을 설치해서 Facebook을 통해 자신의 서비스를 홍보/마케팅하고 3) Open Graph API를 통해 Facebook User들의 개인정보나 친구 List 등 3rd Party가 서비스 제공에 필요한 정보를 불러와서 사용하고 있다. 즉, Facebook이 웹의 일부가 된다기 보다는 Facebook이 제공하는 API를 사용하게 될 경우 3rd Party Web 또는 App.들이 Facebook의 클라이언트로 종속되게 된다는 점에서 거꾸로 Facebook으로 나머지 웹을 통합하는 방식으로 "Social Layer"가 활용되고 있다.
여기에다 대칭적인 Facebook의 친구관계 형성 모델도 추가적인 이슈로 제기된다. 이런 모델은 실제 생활과 잘 맞지 않는다. "친구"라는 용어 조차도 웹 전체에 적용될 수 있는 소셜 백본에 필요한 뉘앙스와는 거리가 멀다 (Even the term "friend" doesn't allow for the nuance that a capable web-wide social backbone needs).
나의 논점은 Facebook이나 Google+냐는 틀에서 제기되고 있는 문제에 대한 결론이라기 보다는 Facebook이 글로벌 소셜 백본의 Needs를 충족시키지 못하고 있다는 점을 강조하는 것이다.
그렇다면 왜 Google+는 소셜 백본이 시작되는 기원이 될 수 있는가? 답변은 외의로 간단한데 Google+야말로 광범위한 User Base와 소셜 모델을 충분히 유연하게 결합시킨 최초의 시스템이고, 구글은 소셜 그래프의 백타적인 소유권이 자신들의 비즈니스에 본질적으로 중요하지 않은 회사이기 때문이다.
구글은 또한 Google+를 소셜 백본으로 자가발전시킬 수 있는 힘을 가진 회사이다. 즉 Google+를 자신들의 웹 어플리케이션들에 통합시키면, 자신의 컨셉을 강력하게 전파시킬 수 있게 될 것이다.
그럼에도 불구하고 하나의 회사가 모든 사람들의 identity를 관리할 수 있는 권력을 가져서는 안된다. 효과적이고 안전한 소셜 백본이 되기 위해서는 네트워크 효과는 유지하는 동시에 경쟁과 선택이 보장되어야 한다. 이메일의 상호 호환성은 한가지 시스템의 지배력이 아니라 커뮤니케이션의 표준에 의하여 창조되었다.
웹 전체에 영향을 미치기 위해서 Google+는 아직까지는 부족한 개방성과 상호 호환성을 더욱 많이 혹보해야 한다. 조만간 출시될 Google+ API가 어떤 기능들을 제공하는지를 살펴보면, 통제와 상호 호환성에 관한 구글의 태도가 어떤 것인지를 우리는 잘 알게 될 것이다.
구글이 개방적이고 상호 호환성있는 소셜 백본을 지지하고 있다는 실체적인 증거를 좀 더 나열해 보면
구글은 자신의 비즈니스에 결정적으로 중요하기 때문에 웹의 개방을 주도적으로 지지해 왔다 (역주 : 폐쇄적인 웹이 많아진다면 검색엔진이 접근이 어려울 것이므로).
런칭 초기부터 상호 호환성을 보장하려는 경향 : 공개된 컨텐트 아이템들은 URI를 가지고 있고 연락처에 등록된 사람들중 Google+ 미사용자들에게 이메일로 전달할 수 있는 대비책도 가지고 있다.
구글은 데이타해방전선(Data Liberation Front)의 선두에 선 나팔수로서 User들에게 구글에 축적되어 있는 자신의 데이타에 대한 완벽한 접근을 보장하는데 헌신하고 있다.
구글은 OAuth, OpenID, OpenSocial, PubsubHubbub 등 소셜 백본의 중요한 이슈들을 다루는 초기의 기술들을 창조하고 지원하는데 적극적으로 참여해 왔다.
구글은 상호 호환되는 시스템들간의 Federation에 개방적인 태도를 보여주고 있다. 이러한 태도는 Google+ 써클 모델의 개발자인 Joseph Shmarr에 의해 극명하게 드러난다. 사그러들 운명의 Google Wave 또한 federation을 통합시킨 바 있다.
최대한 개방적인 시스템을 유지하는 것이야 말로 구글이 1) "세상의 정보를 조직화"하라는 자신의 미션을 수행하고 2) 연관성이 높은 광고를 타게팅하는 자신의 비즈니스를 수행하는데 가장 유리하다.
Toward the Social Backbone
컴퓨터는 우리에게 Serve해야 하며, 우리에게 표현수단을 제공해야 한다.
표현적이며 상호 호환되는 공통의 소셜 백본이 생긴다면, User뿐만 아니라 소프트웨어 개발자들에게도 큰 도움이 될 것이다. 정보의 격납고와 친구와 사람 관리라는 반복되는 수고로부터 해방되어(Liberated from information silos and repeat labour of curating friends and acquaintance), 우리는 보다 자유롭게 협업할 수 있게 될 것이다. 어플리케이션들은 추상적인 "user"들이 아니라 개인으로서 우리에게 더 좋은 서비스를 제공하게 될 것이다.
우리는 소셜 백본으로 가는 길에서 Privac 이슈를 주의깊게 다루어야 한다. 사용성이 좋은 시스템을 제공하는 것과 Collaboration 및 Sharing에 관한 우리의 모델을 충분히 충족시키는 시스템 간에는 심각한 Trade-Off가 존재하고 있다.
수많은 장애에도 불구하고 Google+는 차세대 소셜 소프트웨어의 약속을 반영하고 있다. 겉핧기식 혁신에 불과했던 과거의 실패로부터 교훈을 얻고, 고객 Needs에 더 깊게 천착하고 있기 때문에 그것은 이미 성공했다고 할 수 있다(Incorporating learnings from previous failures, a smattering of innovation and close attention to user need, it is already a success).
조금만 더 개방적인 조치를 취하면 Google+ 프로덕트를 소셜 백본의 시작으로 만들 수 있다. 이러한 조치를 취함으로써 Google은 검색과 마찬가지로 휴머니티에 기여하게 될 것이다.
그런데 글을 읽으면서 이질적인 시스템간 상호호환성이 보장됨으로써 Social Backbone이 만들어지려면, 그리고 소셜 소프트웨어가 이메일처럼 서로 다른 시스템간 상호 호환될려면 어떻게 되어야 할까라는 질문을 해본다. 트위터 사용자 A는 150명의 팔로워를 가지고 있고 또 다른 Social Networking 시스템 Google+의 사용자 B는 200명의 팔로워를 가지고 있다고 가정하고 다음과 같은 질문을 해 본다.
1. A가 트위터에 로그인하여 Google+ 사용자인 B와 친구관계의 형성이 가능한가 ?
트위터 User A와 Google+ User B가 친구맺기와 관련하여 공통된 프로토콜을 사용한다면, A가 B를 Following할 수 있을 것이다.
1단계 : A는 트위터에서 본인의 주소록에 저장되어 있는 B의 이메일 주소나 이름 등으로 검색한다.
2단계 : A가 트위터에서 요청한 검색 Quary는 Social Networking System들이 제공하는 표준화된 검색 Interface를 통해 각각의 DB의 회원정보를 뒤져서 적합한 검색의 결과값이 제공되면(Thumanil/이름/자기소개/서비스명 등으로 표시되는 결과 List), User A는 그중에 하나 즉 Google+에 등록되어 있는 B를 선택하고 Following 버튼을 클릭한다.
3단계 : 트위터는 B가 자신에게 속한 도메인이 아니기 때문에 SIP Redirect Server 또는 이메일의 DNS 시스템과 유사한 시스템을 통해 Google+에 A가 B를 following 했다는 정보를 던져 준다.
4단계 : 그러면 Google+는 A에게 twitter user라는 tag를 달아서 B의 follower list에 등록하고 B에게 "User A가 트위터에서 당신을 Follow했다."는 것을 Notify해 준다. 이때 Google + User B에게 Twitter User A가 누구인지 Thumbnail 사진과 이름 등이 표시되고 User B가 클릭하면 User A의 트위터 프로필 페이지로 이동할 수도 있어야 한다.
5단계 : Google+의 User B 역시 동일한 방식으로 트위터 User A를 Follow하면 Google+는 User B의 Following List에 트위터 User A를 추가한다.
6단계 : 트위터 User A에게 동일한 방식으로 Google+ User B가 자신을 Following했다는 것이 Noti.되면, User A의 트위터 Following List에 Google+ User B가 추가된다.
이리하여 트위터 User A와 Google+ User B는 상호 소통이 가능한 Mutually Following 관계가 성립된다.
2. 텍스트/포토/동영상/Link 등 상호 포스트가 어떻게 공유될까 ?
User A가 트위터의 what's happening에서 텍스트, 포토, 동영상 등을 포스트하면 트위터 자체 Follower들뿐만 아니라 User A를 Follow하고 있는 Google+ User B에게도 Feed가 발생해야 한다.
물론 이런 Text, 포토, 동영상, Link 등은 독립된 URI를 가지는 object로 생성되어야 하고, 각각의 Object에 달려있는 코멘트들과 함께 하나의 Thread를 유지하는 독립된 페이지로 만들어 져야 한다.
그리고 User B가 Google+에서 User A가 트위터에서 올린 포스트에 코멘트를 달면, 이 코멘트가 User A에게 Notify되어야 한다 (그런데 twitter의 경우 코멘트의 형식이 @id reply 형식으로 Google+나 Facebook과 다르기 때문에 자신의 형식에 맞게 Google+에서 User B가 단 댓글이 relpy로 변경되어 수신될 것이다)
User A 역시 본인이 트위터에 날린 original 포스트에 달린 Google+ User B의 코멘트에 실시간 응답이 가능해야 한다.
일단 서로 다른 Social Networking 시스템간 "친구추가" 및 "상호 포스트" 교환 2가지 시나리오만 생각해 봐도 표준화되어야 할 것들이 무척 많다.
1. 각 Social Networking 서비스의 회원정보에 상호 접근할 수 있는 표준화된 검색 API
User의 이름이나 이메일 주소로 개별 Service들의 회원DB에 상호 접근할 수 있는 API
검색 결과값 Page를 구성하기 위한 표준 Format (Thumbnail/이름/서비스명 : Twitter, Facebook, Google+, Linkedin 등/회원 profile url)
일단 여기에서 부터 정보검색의 결과로 회원정보가 어디까지 공개되느냐하는 Privacy Issue, 상호 회원 DB에 접근할 수 있는 표준화된 Gateway 시스템 (즉, 이메일에서 DNS에 등록된 도메인 주소를 통해 수신자를 찾아 가듯이 이 Gateway를 통해 특정 도메인의 Social Network 서비스의 User를 찾을 수 있어야 함)의 구축, 그리고 해당 서비스 내에 SNS 검색을 지원하는 U/I를 별도로 제공해야 하는 등 많은 이슈가 발생한다.
2. Following Request & Notification
검색 결과 Page에서 "홍길동"이 여러명 존재할 수 있는데 이 중에 자신이 찾는 사람을 찾아서 Follow 버튼을 클릭하면 Twitter User A는 Google+ User B를 Follow할 수 있어야 하는데,
이것은 Facebook의 Like, Twitter의 Follow Button 등 3rd Party에게 공개되어 있는 기존 Social Network 서비스에서 관계를 맺기 위한 API를 활용할 것이냐 또는 공통의 규약을 만들 것이냐는 이슈가 존재할 수 있다.
Google+의 경우 상대적으로 후발 주자이므로 Twitter나 Facebook에서 제공하는 API와의 상호 호환성을 고려하여 Follow API가 설계될 가능성이 높다.
Facebook의 경우 "Open Graph Tag"가 삽입된 3rd Party의 페이지를 Facebook의 User가 Like하면 해당 웹페이지와 이 User의 프로파일간 Direct Connection이 맺어지고 이 웹페이지에서 update된 정보가 Facebook User에게 자동으로 Feed되는 구조가 이미 존재한다. 그러나 이것은 사람과의 관계가 아니라 Web Page에 의해 representation되는 실제 사물과 관련된 것이고, 친구관계의 형성은 초대하고 승인하는 구조이므로 다른 도메인의 사용자가 Facebook의 User를 Follow한다고 해서 Facebook 입장에서 아직 친구관계가 형성된 것은 아니기 때문에 Facebook의 User의 Update된 내용이 다른 도메인 친구에게 자동으로 Feed되지는 않을 것이다. 따라서 Facebook 입장에서 Twitter나 Google+ User가 Facebook User를 Follow했다는 것을 해당 User에게 "초대 알림" 형태로 Notify되고, 이 User가 승인을 해야만 할 것이다.반대로 Google+와 Twitter User 입장에서는 Facebook User와는 Mutually Following 관계가 성립해야만 상호 소통할 수 있는 구조가 마련되는 셈이다.
어떻게 해서든 Facebook, Google+, Twitter간 Follow 버튼을 통해 친구관계가 형성될 경우, 다른 Social Network Service의 User가 자신의 User를 Following했다는 것을 Notify해 주는 것은 큰 문제가 없을 것이다.
3. Communication : Post, Feed, Comment의 상호호환
서로 다른 Domain User간 일방적인 Following 또는 Mutually Following을 통해 친구관계가 성립되면, 특정 도메인에서 User가 포스트를 올리면 이 User의 Follower List를 조회한 후 이 중 다른 Domain User에게 속한 Follower들을 찾아서 1번)에서 지적한 Gateway를 통해 Feed를 요청하게 된다.
그러면 이 GateWay를 통해 Follower들이 속한 서비스 도메인에 Feed를 요청한다.
이것 또한 앞서 지적한 Like, Follow Button과 같이 해당 서비스별로 3rd Party Site에서 자신의 Site로 글을 Post할 수 있는 API가 이미 존재하므로 이것을 해당 사이트 들이 상호 호출해서 사용할지 또는 별도의 표준화된 API를 사용하게 될지는 확실하지 않지만 기존 SNS의 Post API는 해당 서비스의 인증을 받은 가입자만이 사용할 수 있으므로 아마도 후자가 되어야 할 것이다.
즉, Facebook은 사용하지 않는 Google+ User A가 포스트한 글이 마치 이메일을 보낸 것처럼 Facebook의 친구인 User B에게 자동으로 Feed되어야 하는데, Google+입장에서는 User B가 자신의 회원이 아니므로 별도의 표준화된 Gateway에 Facebook User B에게 Feed를 요청하면, 해당 Gateway에서 Facebook의 Feed API를 호출해서 사용하게 될 것 같다.
User A가 Google+에서 올린 Post가 Facebook의 User B에게 성공적으로 Feed가 발생했을 경우, User B가 User A의 포스트에 Comment를 달면 이것이 실시간으로 User A의 Googl+ 페이지로 와야하고 반대도 마찬가지이다.
Facebook의 Comment API는 3rd Party Site에서 Facebook User가 Facebook의 인증을 받은 후 코멘트 API를 호출해서 댓글을 작성하면 실시간으로 Facebook의 User및 이 User의 친구들에게 코멘트 Feed가 발생하게 되어 있다.
현재 Facebook의 회원인증을 받은 사람들만 코멘트 Feed가 발생하는 구조를 Google+나 Twitter와 호환될 수 있는 구조로 만들어야만 한다.
어앴든 저자는 Google+ 1) 후발사업자로서 기존 강자들과 호환이 가능한 구조로 이러한 API를 설계할 가능성이 높고 2) Search Engine의 효율적인 사용을 가능하게 하기 위해 개방적인 구조로 시스템이 최적화될 가능성이 높기 때문에 향후 Social Backbone을 주도할 것이라고 보는 것이다.
