3. User ID
정보의 주변을 감싸고 있는 세가지 요소중 마지막 UserID에 대한 이야기입니다. 이번 정의를 마지막으로 다음 포스트에서는 이 세가지 요소('정보'까지 네가지 요소)들이 어떻게 어우러져서 서비스를 만들어내고 집단지성과 같은 효과를 이끌어낼 수 있을지를 살펴보도록 하겠습니다.
Activity Log가 '정보'를 중심으로 생성되는 Log라면 User ID는 사용자(User)를 중심으로 생성되는 Log입니다. 즉, 특정 사용자가 어떤 정보들을 어떻게, 왜, 어디서, 언제, 무엇을 통해 사용하였는가에 주목하는 것이 User ID 입니다. Activity Log가 정보의 History를 의미한다면 User ID는 사용자의 History를 보여준다고 할 수 있겠군요. 하지만 Log라는 단어를 붙이지 않는 것은 개인정보침해와 같은 민감한 이슈에서 조금이라도 비켜보려는 의지 때문입니다.
정보의 History를 특정 개인을 중심으로 정렬할 수 있다면 그리고 그 결과를 그 개인이 사용한 정보의 History와 연관지어 분석할 수 있다면 보다 맞춤형 정보를 사용자에게 제공할 수 있을 것입니다. 구글이 하고 있는 것 처럼 이메일을 주고 받을때 광고를 붙여서 보여주는 것도 가능해지겠죠. 아니 가능한 것을 넘어 이메일을 주고 받는 사람들이 관심을 가질만한 주제와 연관성 높은 광고를 제시할 수 도 있을 겁니다.
사실 User ID 단독으로는 기껏해야(이것 만으로도 대단하지만) 보다 정밀한 타겟 마케팅이 가능하다는 의미 정도만을 부여할 수 있을 것입니다. 하지만 앞서 설명한 메타정보와 Activity Log와 그 힘을 합친다면 UCC와 함께 웹2.0의 주요한 이슈로 떠오르고 있는 '개인화 서비스'의 실현이 가능해질 것이라 생각됩니다.
'개인화 서비스'를 제공한다는 것을 '자동화'라는 것에 초점을 둔다면 현재의 개인화 포탈이나 서비스들은 '개인에게 서비스나 컨텐츠 선택의 권리를 주는 서비스' 정도로 의미를 축소할 수 도 있을 것 같습니다. (물론 그 정도로도 훌륭한 서비스입니다.) 진정한 의미에서 개인화 서비스는 사용자의 어떤 액션 없이도 Login을 통한 User ID를 근거로 자동으로 맞춤형 서비스를 제공해주는 것이라 볼 수 있습니다. 과거 서비스들은 이러한 개인화를 실현하기 위해 가입시 사용자에게 과도한 정보의 입력을 강요해왔습니다. 주민등록번호를 비롯하여 취미, 직업, 사는곳, 출신학교 등 도데체 어디에 쓰이는지 알 수 없는 정보들의 입력을 강요하는 것과 더불어 기초적인 서비스 이용조차 LogIn을 강요함으로써 서비스의 사용을 오히려 막는 부작용을 가져온게 사실입니다. 웹2.0 컨셉의 사이트들이 자연스레 받아들여지는 지금은 IP를 활용한 Auto LogIn이 자연스러운 개념이지만 불과 몇년전만해도 Auto Login은 매우 낯선 기술이었습니다.
잠시 Auto LogIn에 대해 이야기하자면
Auto LogIn은 앞서 말씀드린 Activity Log나 User ID를 얻을 수 있는 매우 좋은 수단입니다. 사용자는 무의식중에 자신의 발자취를 고스란히 운영자에게 넘겨주고 있죠. 하지만 Log In이라는 행위가 빠져있으므로 사용자 입장에선 별 거부감 없는, 오히려 편리한 서비스로 받아들여집니다. 물론 Auto LogIn의 바닥에는 '이 사이트에는 오픈되면 안되는 내 개인정보는 존재하지 않는다'는 가정이나 '내가 사용하는 PC는 보안상 안전하다(나만 쓸수 있다)'라는 가정이 깔려있어야 합니다. 정보를 검색하기 위해 잠깐 들린 PC방에서의 서비스 이용으로 그 PC에서 Auto LogIn된다고 생각해 보십시요. 얼마나 끔찍한 일이 벌어질 수 있을까요?
물론 웹2.0의 개념에 충실한 사이트나 서비스들은 이런 Auto LogIn의 보안상 위험을 잘 피해가고 있습니다. Auto LogIn을 성립시키는 알고리즘이야 언급할 필요도 없이 많은 고민을 했을 것이 분명하고 그 보다는 LogIn 되어도 개인에게 피해가 갈 정보는 아예 가입당시 요구하지 않습니다. 한 개인의 유니크한 신상정보를 얻는 것 보다 Auto LogIn을 통해 사용자와 그 사용자가 사용하는 정보의 연관관계와 Log에 관련된 DB를 쌓아 나가는 것이 훨씬 가치있다는 것을 잘 알고 있죠. 그러므로 '가입은 간편하게, LogIn은 자동으로'라는 모토를 유지하려 더욱 애쓰고 있는 것 같습니다. 반면에 그렇지 못하고 아직도 가입자에게 입력을 강요함으로써 정보를 얻으려는 서비스들, 그리고 그렇게 얻은 정보로 개인화 서비스를 제공하겠다는 서비스들은...진정 어릭석다 하지 않을 수 없습니다.
가입시 이메일 인증을 쓰는 것은 이제 deFact Standards로 자리잡은지 오래입니다. 중복 가입을 막으면서 간편한 가입 시스템을 유지하는 아주 좋은 방법이죠. 하지만 중복 가입 여부를 판단할 수 있는 기준이 되는 이메일을 어떻게 중복되지 않게 가입하게 할 것인가라는 재귀적 의문에 빠지지 않을 수 없습니다. 구글은...얍삽하게도 '추천'을 통한 G메일 가입이라는 방법을 생각해 낸 것 같습니다. 즉, 다른 이메일 서비스 회사들이 사용자들에게 욕(?)먹어가며 획득해 놓은 Unique 가입자 Data를 '추천'이라는 시스템으로 공짜로 사용해 버린거죠. 내가 욕 먹어가며 중복 가입을 방지할 필요는 없다...'나만 악하지 않으면 된다'는 구글의 사훈과 잘 어울리는 발상인 것 같습니다.
다시 User ID 이야기로 돌아와서
진정한 의미의 개인화 서비스는 Activity Log와 User ID의 조합으로 성립될 수 있을 것 같습니다. 지금 서비스에 접속한 User ID에 대한 DB를 가지고 있고 내가 제공해 줄 수 있는 정보의 Activity Log들과 User ID에 붙어 있는 History를 비교함으로써 사용자가 원하는 서비스에 보다 가까운 서비스를 제공해 줄 수 있겠죠. 이런 통계적인 분석이 실효성을 거두기 위해선 보다 많은, 더 많은 Activity Log와 User ID가 쌓여야 합니다. 더 많은 사용자들이 써야지 더 많은 Activity Log와 User ID가 쌓일 것이고 그러면 서비스는 더 좋아지고, 다시 더 많은 사람들이 쓰고 또 Log가 쌓이고...즉, 제공하는 서비스가 (팀 오라일리가 말한 웹2.0 서비스가 갖추어야 할 조건처럼) 사용자들이 쓰면 쓸 수록 좋아지는 서비스의 구조를 가지는 것이 가능해 질 것 같습니다.
문제는 어떻게 더 많은 사람들이 쓰게 하느냐...라는 명제입니다. 우선 당연한 이야기지만 서비스가 좋아야 하겠죠. 하지만 내가 제공하는 서비스는 더 많은 사람들이 써야지 좋아집니다. 지금은 많은 사람들이 쓰지 않아 좋은 서비스가 아니지만 일단 많은 사람들이 쓰면 좋아질게 분명합니다. 어떻게 사람들을 쓰게 만들어야 할까요? 서비스가 폭발적으로 좋아지는 네트워크 효과를 일으키게 하기전까지 어떤 유인책으로 사람들을 모아야 할까요. 일일이 사용자들에게 왜 쓰면 쓸수록 서비스가 좋아지는가를 설명하며 다닐 수는 없는 노릇입니다.
분명 메타정보, Activity Log, User ID는 정보의 주위를 감싸고 있는 중요한 요소이며 더욱 많은 메타정보와 Activity Log 그리고 User ID를 얻을 수록 더 좋은 서비스를 제공할 수 있음은 분명합니다. 하지만 세가지 요소들은 단독으로선 큰 의미를 부여하기가 힘들며 각 요소들이 가치를 지니기 위해선 다수의 관련 DB를 확보하는 것이 중요다는 것 역시 사실입니다. 그 답을 얻는 가장 쉬운 방법은 성공한 선각자들의 서비스를 분석해 보는 것이므로 다음 포스트에서는 성공한 서비스들이 '정보의 주변을 돌고 있는 세가지 요소들을 어떻게 효율적으로 모으고 분석해 낼 수 있었는가'에 대해 고민해 보도록 하겠습니다. (사실 고민할 능력이 될지 의문스럽습니다 ;;)
이올린에 북마크하기
이올린에 추천하기
