성훈이네- Product Manager & Data Miner 의 일상

요즘들어, 성공적인 앱개발 전략이나 서비스 성공비결(?) 등에 대한 강의의뢰가 들어오기도 하고, 주변에서는 구상중인 서비스 컨셉에 대한 평가의견을 물어보기도 하십니다.

아임IN이나 푸딩이 비교적 좋은 평가를 받고 있는 것은 사실이지만, 그렇다고, 제가 무슨 비결을 알고 있지도 않고, 다른 분이 고민해서 낸 아이디어에 의견을 드릴만큼혜안을 가지고 있지도 못해서,그런 부탁을 받으면 고민이 많습니다.

몇 개월 전부터 저 스스로 자문해보았습니다. 과연 좋은 서비스란 무엇이며, 어떻게 만들어야 하는 것일까?

다소 경험적이고 부분적인 답이지만 결론부터 말씀드리면, 저와 동료들이 서비스를 만드는데, 무슨 특별한 방법이 있었던 것은 아니고, 함께 공유해왔던 ‘가치’는 있었던 것 같습니다.

그래서 오늘은 2~3개월쯤 전에 팀에서 토론했던 ‘내가 만들고 싶은 ‘가치’, 그것을 위하여!’ 라는 내용의 자문과 답변을 공유하고 싶습니다.

흔히, 서비스를 만들다보면, 초기 기획때의 마음가짐과는 달리,기능적인 면에 매달리고 있는 자신을 발견할 때가 많습니다.

좋은 서비스는 ‘기능’이 아니라 ‘가치’가 변하지 않아야 하고, 이 ‘가치’가 서비스에 녹아 있어야하고, 만드는 사람모두가 공유하고 있어야 한다는 게 토론의 시발점이었습니다.

내가 만들고 싶은 ‘가치’, 그것을 위하여!

2011. 11. 04. 소셜네트워크팀 모두가 함께

Q1. 고객에게 주고 싶은 서비스의 ‘가치’는 무엇인가?

1) 늘 새로운 경험과 재미를 제공하여 고객의 ‘습관’으로 정착되는 서비스.
2) 자신의 일상 기록하고 자아 투영할 수 있는 서비스
3) 타인과 공감/공유하는 서비스
4) 타인/세상과 커뮤니케이션하고 교류할 수 있는 서비스
5) 세상을 보는 다른 눈(인사이트)을 제공하는 서비스

Q2. ‘가치’를 ‘현실’로 만들기 위해 꼭 해야하는 것은?

1) 기본에 충실하고, 명확한 컨셉과 사용 편의성에 중점 둬야 한다.
2) 고객에 대한 깊은 이해와 대중적인 요소들에 민감해야 한다.
3) 절제되고 질리지 않는 디자인을 추구해야 한다.
4) 서비스 안정성을 유지해야 한다.
5) 기술 향상으로 더 나은 퍼포먼스를 제공해야 한다.
6) 구성원들간의 원활한 커뮤니케이션으로 기민하게 진행해야 한다.

Q3. ‘가치’를 ‘현실’로 만들기 위해 하지 말아야 하는 것은?

1) 욕심 부리지 않고, 군더더기 넣지 말자.
2) 외부 의견에 굴복하거나, 흔들리지 말자.
3) 고객 ‘만족한다’는 안일한 생각말고, 자신과 타협하거나 포기하지 말자.
4) 행동없이 생각만해서도 안되고, 일에만 매달리지도 말자.
5) 무리한 개발 일정으로 진행하지 말자.
6) 추구하는 가치 보다 돈을 앞세우지 말자.
7) 건강을 해치지 말자.

새해가 되었습니다. 더 많은 일과, 더 큰 도약을 고민해봅니다.

하지만, 어떤일을 하던, 우리가 함께 정했던 '가치'와 그 가치를 이루기위해 반드시 해야 할 일, 그리고 하지 말아야 할일을 살피는 것이,우리가 하는 일의 시작점이 될 수 있기를 다시금 다짐해봅니다.

새해 복 많이 받으십시오.

오랜만의 포스팅 제목이 다소낚시성이라 걱정이 되는군요. 서두에 밝히면 이 글은 사실 ‘어떤 버튼이 더 좋다’를 말하기보다는 소셜네트워크 서비스에서 버튼이 가지는 의미를 곱씹어보고자 하는 데 있습니다.

‘좋아요’나 하트와 같은 관심 버튼은 이미 stumble upon 외에도 이미 다음뷰, 믹시, 네이버 블로그등의 서비스에서도 활용되어왔던 기능입니다.

stumble upon 의 좋아요!

mixsh의mixup

하지만, 소셜네트워크 서비스에서 이러한 기능들이 가지는 가치는 단순히 스크랩이나 관심의 표현 같은 정보성 기능의 차원을 벗어나, 버튼 액션을 받은 사람의 입장이나 버튼 액션을 한 사람의 입장에서 모두 빠르고 가벼운 커뮤니케이션을 유도할 수 있는 도구라는 측면에서 새롭게 살펴보아야 할 것 같습니다.

‘좋아요’나 ‘하트’를 하면, 별다른 노력을 들이지 않고 상대방에게 호의를 보일 수도 있고, 넌지시 상대방에게 다가설 수 있기도 합니다. 받는 사람입장에서는 은근한 만족감에다 어떨 때는 이것을 준 사람에게 호감까지 느껴지기도 하지요.

일반적으로 ‘댓글’을 다는 것보다 ‘좋아요’ 버튼을 누르는 것이 훨씬 편리하고 접근성이 용이하다는 사실은 몇 달전 페이스북을 대상으로 한 조사결과에서도 간접적으로 입증되고 있습니다.

소셜네트워크 서비스 속의 이런 버튼들은 사용자에게 선물(이미 많은 소셜게임에서도 그 효과가 입증되었지요.)과 공감(empathy)의 역할을 합니다. 그리고, 개인적으로 저는 소셜네트워크 서비스가 사용자에게 주는 가치 중 가장 큰 것 중에 하나가 끊임 없고 가벼운 공감이라고 생각합니다.

물론 소셜미디어가 오히려 젊은이들의 공감하는 능력을 저하시킨 다는 연구결과도 있습니다 ( http://rhettsmith.com/2010/06/college-students-and-empathy-can-social-media-create-a-bystander-effect-that-can-inhibit-ones-compassion/ ) 만, 그 반대의 연구결과( http://blog.laptopmag.com/study-social-networking-lowers-stress-boosts-empathy) 도 있습니다.

일반적으로 사람들이 특정 신문이나 미디어를 구독하는 이유는 그 신문이 내가 하고 싶은 얘기를 대신해주기 때문이라고 합니다. 공감 한다는 것이지요. 더구나, 소셜네트워크 내에서는 이런 공감이 인터랙티브하게 일어날 뿐만 아니라 증폭되는 현상을 보이기도 합니다.

소셜네트워크 서비스입장에서는 공감을 이끌어내는데 필요한 장치와 시각적인 도구를 통해 사용자의 관심(attention)과 관계(relation)를 파악하고, 이를 기반으로 보다 정교한 개인화를 서비스를 제공하거나 비즈니스 모델을 적용할 수 도 있을 것입니다.

또 하나, 이러한 공감의 장치와 시각적인 도구가 소셜네트워크 내에서의 커뮤니케이션에서 중요한 이유는, 인터넷세대가 가지는 커뮤니케이션의 특징이 매우 축약적이라는 점, 고도의 상징성을 가진다는 점 때문일 것 입니다.

예컨데, 버카충(버스카드충전), 문상(문화상품권), 생선/생파(생일선물, 생일파티)나 요즘 유행했던뿌잉뿌잉 ლ( ╹ ◡ ╹ ლ) 과 같은 표현들 그런 현상의 증거들이 아닐까 합니다.

아시다시피, 과거 피쳐폰 시대부터현재 스마트폰 시대에이르기까지 끊임없는 스테디셀러중의 하나는 이모티콘 입니다. 2008년 황하성님과 박성복님의 논문문자메세지의 이모티콘 활용에 관한 연구를 살펴보면 이모티콘이 ‘매개된 상황에서 함께 있다는 느낌’으로 정의되는 사회적현존감(social presence) 증대에 많은 도움을 준다는 연구결과도있습니다.생김새가 가지는 상징성이나 기호학적 의미가 커뮤니케이션에서도 중요할 것 입니다.

Google+ 나 facebook의 이 기능을 제안했던 담당자들이 고민을 했던 안했던 간에, 다분히 주관적인 생각을 말씀드리면 ‘좋아요’와 함께 보여지는 thumbs up 버튼은 +1 버튼보다는 커뮤니케이션 활성화의 도구로써 가지는 상징성이나 시각적인 효과가 훨씬 뛰어난 것 같다는 게 제 생각입니다. 물론 커뮤니케이션 활성화보다 정보의 가치를 평가한다는 측면을 살펴본다면, 플러스 버튼이 더 우위에 있을 수도 있겠다 싶습니다.

연초부터 준비한 서비스가 조만간 완성될 것 같습니다. 이런 고민들이 서비스에 묻어나(참고로 버튼을 만들었다는 의미는 아닙니다. ^^) 많은 분들의 공감을 이끌어 낼 수 있기를 기원해봅니다.

로버트 맥나마라(Robert Strange McNamara, 1916~2009)는 케네디 시절에 미국의 국방장관이었고, 포드가 가문의 사람이 아닌 외부인으로써 최초로 포드회장을 역임했던 인물이며, 흔히 컴퓨터 두뇌나 지독한 계량주의자로 알려진 인물입니다. 2차대전과 한국전쟁을 지나 80년대에 이르기까지, 군사, 경영, 금융 등의 분야에 지대한 영향을 끼쳤고, 특히, 60~70년대를 살아가던 우리의 아버지 세대들은 ‘맥나마라’ 라는 이름을 대부분은 기억하고 계실 정도로 유명한 인물입니다.

로버트 맥나마라 from wikipedia

http://en.wikipedia.org/wiki/File:Robert_McNamara_official_portrait.jpg

최근 뒤늦게 Fog of war 라는 영화를 보게 되었습니다. 그가 인생을 살면서 겪은 11가지 교훈에 대한 내용인데, 상당부분은 그가 2차대전과 베트남전에서 얻은 내용들이었습니다.

영화 Fog of war 포스터 from wikipedia

http://en.wikipedia.org/wiki/File:Fog_of_war.jpg

4. Maximize efficiency 나 6. Get the data 는 서비스를 기획하는 사람들 뿐만 아니라, 디자인, 개발하는 모든 사람들이 눈여겨 볼만한 교훈들이었습니다.

흔히 알려진대로 그가 시장조사를 통해 당시 미국시장에는 존재하지 않는다고 믿었던 경제형 차량의 니즈를 발견, Falcon 이라는 경제형 모델을 출시해 포드의 수익률 개선에 크게 기여했다는 이야기, 그리고, 최초로 안전벨트를 만들어냈다는 이야기는 그렇다 치고, 공감이 가는 사례하나를 소개하고자 합니다.

바로 주변에서 일어나는 결과를 만들어낸Data를 면밀히 살펴보라는 교훈입니다.

2차대전 때 영국에서 독일로 출격하는 미국 폭격기들의 임무 중단비율이 20%였는데, 실패이유로 전자계기의 작동불량, 무전상태, 몸상태 등의 이유들이 리포팅 되었었답니다.

보고서를 받아 든 맥나마라는 올라온 보고서 결과 이전에 생성된 비행일지 등의 원천 데이터를 면밀히 분석했고, 이를 통해 임무 중단한 대부분의 조종사들이 공포심 때문에 목표물에 접근하지 않고 그냥 돌아온다는 사실을 발견했다고 합니다.

이 사실을 알게 된 커티스 르메이라는 지휘관은 매일 그 자신이 폭격하는 편대의 맨 앞에 서서 출격을 했고, 결과적으로 임무 포기율은 그 이후 현격히 줄었다는 이야기였습니다.

데이터를 세부적으로 살펴보지 않고, 표면적 결과만을 수용함으로써 나타날 수 있는 오류를 Simpson’s Paradox 라고 합니다. 이는 숫자 데이터를 분석할 때만 사용하는 말은 아닌 것 같습니다. 서비스 기획의 과정, 혹은, 사용성을 개선하거나, 직간접적으로 나타나는 장애나 부하 등의 원인을 분석함에 있어, 많은 경우 깊이있는 사실(fact)에 대한 분석 없이, 겉으로 드러나는 결과 값만을 그대로 받아들이는 경우를 많이 보곤 합니다. 더 나아가 연구자에게 유리한 사실들만을 꺼내어 드는 경우도 있습니다.

맥나마라의 계량주의를 말하고자 하는 것이 아니라, 문제나 오류의 원인을 최말단의 레벨까지 살펴보고, 숙고하는 자세를 말하려 하는 것입니다.

CSI와 같은 과학수사물을 보면 현장에서 지나쳤던 아주 작은 증거 하나가 사건의 열쇠를 쥐고 있거나, 그 증거를 얻기 위해 목숨까지 걸고 수사를 진행하는 형사들의 노력이 눈물겹기까지 한 경우를 종종 보게 됩니다. 그만큼 증거를 찾기가 어렵다는 뜻이겠지요.

컴퓨팅 파워는 엄청나게 빨라지고 있고, 또 그만큼의 데이터도 많이 생산되고, 예전 같으면 아주 소수의 사람들에게만 공유되던 고급 정보도 지천에 널린 게 요즘의 상황입니다.

그래서인지 시간이 없다는 이유로, 다른 사람이나 프로그램이 만들어놓은 결과 값만을 취하고, 정작 중요한, 그 결과를 만들어낸 인과 관계를 파헤치는 것은 등한시 하는 경우를 종종 보게 됩니다. 더 나아가서는 그런 일 자체가 매우 하찮은 일로 여겨지고 있기도 하구요.

바야흐로 데이터 스트림(data stream)의 시대, 빅 데이터(big data)의 시대입니다만, 이럴 때 일수록, 눈앞에 나타난 결과 값에 끝없이 질문을 던지고, 깊숙이 데이터와 사실에 집중하는 능력이야 말로 성공에 이르는 길이 아닐까 생각해봅니다.

‘고객들은 절대 앞에서 말을 하지 않는다. 우리의 고객들은 그 데이터를 통해 말하고 있다’는 @parkto 님 말씀이 요즘은 매일 가슴에 와 닿습니다.

최근 모바일서비스이나 웹에 적용되고 있는 상당수의 기술들에 대한 이론적 기반은 이미 꽤 오래전부터 연구되어왔던 것들이라고 합니다. 이런 이론들이 상용화되는 데는 네트웍 대역폭이나 H/W의 발전이 큰 영향을 주었으나, 대용량 데이터 처리분야에서는 누가 뭐래도 병렬처리 기술의 발전이 가장 큰 기여를 하지 않았나 생각됩니다.

한동안 애플리케이션 개발과 기획에 빠져있느라 정신이 없었는데, 몇 달전 외국어대 최대우 교수님께서, 제 페이스북에 남긴 글을 보시고는 Revolutionanalytics 의 최근 자료들을 좀 살펴보길 권하셨습니다.

R 이 꽤 오래전부터 병렬처리에 관심을 가져왔고, 이런 구조를 만들어내기에 용이한 개방형 프로그램인건 알고 있었지만, Perdue University 의 Saptarshi Guha (이분은 현재 PaloAlto Revolutionanalytics 에서 근무하고 있습니다.)가 만든 RHIPE: R and Hadoop Integrated Processing Environment 에 대한 내용을 잠시 보면서, 정말 ‘몇 년전에는 꿈도 못 꾸던 일들이 일어나고 있구나.’라는 생각이 들었습니다.

RHIPE는 한마디로 R을 자연스럽게 Mapreduce 와 연결시켜, 수백만개의 데이터를 매우 짧은 시간에 분석할 수 있도록 한 프로그램입니다. 더구나 RHIPE 를 EC2에 올려 시뮬레이션까지 한 결과를 보고나니 입이 딱 벌어지더군요.

특히, Bioinformatics 분야는 수많은 부가가치가 존재하는 영역이라 생각됩니다.

Amazone S3 Storage 에는 1000 Genome Project 를 위한 데이터가 올라가 있으며, EC2 EBS 등을 통하여 수많은 데이터들을 거의 실시간에 가변적으로 분석 가능하도록 하는 환경을 제공하고 있습니다.

어쩌면 국내 굴지의 대기업들이 클라우드와 이를 활용한 Bioinformatics 산업에 관심을 기울이는 건 당연한게 아닌가 하는 생각입니다.

여튼 우리는 꿈이 이론으로, 이론이 다시 현실로 변하고 있는 그런 하루하루를 살고 있습니다.RHIPE에 관심이 있으신 분들은 아래 팔로알토의 Facebook 본사에서 진행된 Saptarshi Guha 의 Lecture 를 살펴보시기 바랍니다.