Nerd's Life

구글 플러스의 써클 기능이 처음에는 페이스북 그룹과 조금 다를 뿐이라고 생각했는데, 쓰다보니 뭐랄까, 기시감 같은 느낌이 들었다. 원인을 곰곰 따져보다 문득, 딜리셔스 서비스가 떠올랐다.
소셜 북마크 서비스인 딜리셔스의 혁신 중의 하나는, '태그'의 도입이었다. 북마크를 사전에 정의된 카테고리(폴더)에 맞춰 넣는 것이 아니라, '컨텍스트'에 따라 여러 태그를 붙이는 방식은, 단순하고 유연한 편의성을 제공했다.

마찬가지로, 써클은 '컨텍스트'에 따른 단순하면서도 유연한 정보 전달을 가능케 한다.

블로그, 트위터, 페이스북의 본질은, 정보를 공유한다는 것이다. 제목 유무, 글자 수 제약, 데이터 형식 등 조금씩 차이는 있지만, 본질은 같다. 정보의 전달과 공유.
서비스 제공자는 서비스 특성에 맞는 적절한 '템플릿'을 제공한다. 블로그의 카테고리 및 공개 설정, 트위터의 트윗/RT/DM, 페이스북의 피드/그룹/페이지 등이 그 예다.

많은 경우, 어떤 글을 어느 '템플릿'에 올릴지는 특별히 고민하지 않는다. 서비스 제공자가 최선을 다해 자사 서비스에 적합한 '컨텍스트'에 필요한 '템플릿'을 만들어 두기 때문이다.

하지만 때때로, 이 '템플릿'은 북마크에서의 폴더와 같이 유연성이 부족하고 애매할 때가 있다.
회사 생활을 푸념하고 위로를 받고 싶다고 하자. 페이스북에 올리자니 상사나 부모님이 볼까 저어된다. 트위터에 올리자니 사장님한테 RT가 될 것 같다. 그렇다고 평소 지식을 공유하는 블로그에 올릴 수도 없는 노릇이다.

서비스 제공자는 이런 '템플릿'을 다양하게 가져가고 싶은 유혹이 들겠지만, 서비스가 복잡해지면 그 또한 문제다. 싸이월드의 미니홈피가 C2,블로그,페이퍼,C로그 등 수많은 템플릿으로 분화했던 전례를 생각하면 정말이지..

여기에 써클의 묘미가 있다. 글쓴이는 정보를 공유할 대상(써클)을 사전에 정의해놓고, 정보의 '컨텍스트'에 따라 적절한 써클을 택해서 보여주기만 하면 된다. '템플릿'은 페이스북의 그것과 거의 흡사한 텍스트 창에 다양한 레벨의 공개설정을 부여한 형태로 제공된다. 써클을 만들기 위해 상대의 허락을 받을 필요도, 배타적으로 지정할 필요도 없다. 전적으로 글쓴이가 정한다. 트위터의 개방성과 확산을 원하면 public로 정의하고, 페이스북으로 쓰고 싶으면 서클을 잘 정의해서 쓰면 된다. 블로그의 공개설정은 기본이다.
중요한 건 이런 유연함이 여러 기능을 우겨넣어 복잡도를 늘리는 형태가 아닌, 써클이라는 우아한 방법으로 실현됐다는 것. 

딜리셔스는 예전의 명성을 잃었으되 태깅은 수많은 SNS와 클라우드 서비스에 전수된 것과 마찬가지로, 구글 플러스도 웨이브의 전철을 밟을 지도 모르지만 써클의 정보 공유 방식은 널리 활용될 수 있을 듯하다.

인재 곡선 (The Curve of Talent)

일반적인 비즈니스 서적에서도 마찬가지지만, 오로지 지식만을 투입해서 프로덕트를 만드는 IT에서는 특히나 인적 자원에 대한 논의가 많다.

근데 이런 '인재'에 대한 논의를 보고 있노라면 가슴 한켠에 찝찝한 느낌이 있다. 내가 A급 인재가 아니라서 그런 것일 수도 있는데..
주된 원인은 이런 논의가 미국의 실리콘 밸리, 확대하면 미국의 기업을 기준으로 진행되기 때문에, 한국의 노동자가 현장에서 겪는 현실과 괴리감이 크다는 데 있다.

한국은 이런 개인적 능력을 중심으로 스타트업 성공의 원동력으로 삼기에는 장벽이 너무나 많다. 작은 시장까지 뻗쳐있는 대기업의 손길, 현격한 임금 격차, 인맥과 자금력의 압도적인 영향력...

따라서 이러한 논의는, 대기업-스타트업의 구도가 아닌 재벌-중소기업의 구도를 염두에 두고 진행되어야 한다. 물론 성공한 스타트업도 많이 있고, 앞으로도 계속 성공 신화는 씌어지겠지만, 성공 확률과 리스크를 실리콘밸리의 그것과 동일선상에서 평가해서는 안된다는 뜻이다.

프로젝트 관리를 적지 않은 기간동안 해왔지만, 책에 나오는 우아한 방법론을 적용하는 것은 쉽지 않았다. 정말 어렵다. 왜냐하면 대부분의 프로젝트는 프로젝트의 규모와 가치에 따라 정해지지 않기 때문이다. 일정은 인사평가 시점을 기준으로 정해지고, 예산은 조직간 힘의 균형에 따라 할당된다. 품질은 이 두가지 사회적 요인에 따른 종속변수에 불과하다.

그래서, 어쩌면 한국의 스타트업은 인력 관리보다는 인맥관리가 훨씬 더 중요할 것 같다.

"HTML5는 앱 개발의 성배인가" : MS-구글-트위터의 설전

웹과 앱의 문제는 컨텐츠와 경험의 기준으로 보면 답이 나온다(고 생각한다).

1. 메일, 지도
유저가 메일이나 SNS를 쓰면서 관심을 기울이는 건, 그 안에 있는 데이터다. 사용자 경험은 일정 수준 이상으로만 만족시키면 된다. 지메일이나 구글맵스는 웹기술의 테두리 내에서 사용자 경험을 혁신했고, 이로 인해 데스크탑에서 앱을 이용하던 사용자를 끌어갈 수 있었다. 하지만 다시 말하면 사용자가 메일이나 맵을 쓰면서 기대했던 건 '딱 이정도'의 사용자 경험이었다는 말도 된다. 그 전에도 웹메일은 인기있었고, 지도 서비스도 그럭저럭 인기있었다.
한국에서 액티브엑스가 남발된 이유도, 기본적으로는 인터넷 사용자들이 폭발적으로 늘면서 데스크탑의 사용자 경험을 전이하기 원하는 수요가 있었기 때문이었다.

2. 게임
웹의 입장에서 게임은 난공불락의 요새와도 같다. 수십년간 게임은 PC의 사양을 끌어올리는 원동력이었던 만큼, 항상 하드웨어 사양을 끝까지 밀어붙이는 앱이었다. 따라서 앞으로 상당기간 웹은 게임을 절대 끌어들일 수 없을 것이다. 다만 최근의 트렌드는 캐주얼게임이나 소셜게임에 맛들인 사용자들이 늘어남에 따라 메이저 게임 개발사들이 어려움을 겪고 있기 때문에 고사양 게임 시장 자체가 축소되어 영향력은 줄어들 수 있다. 단말의 발전으로, 웹으로 돌릴 수 있는 게임의 영향력을 점차 넓어질 것이다. 그래도 아직, 당분간, 게임은 앱의 영역이다.  

3. 미디어
현재 음악이나 동영상은 앱으로 제공되는 경우가 대부분인데, HTML5에 audio/video 가 들어간 점은 시사하는 바가 크다. 음악이나 동영상을 컨텐츠와 경험의 관점에서 보면 어느쪽에 속할까? 당연히 컨텐츠다.
물론 편리한 UI가 있으면 좋기는 하겠으나, 메일이나 지도가 그랬듯 컨텐츠 자체를 소비하는 영역은 현재의 웹기술로도 충분히 소화가 가능하리라고 본다.

4. 서비스 제공자
그렇다면 서비스 제공자는  웹과 앱, 어느 쪽으로 만들어야 할까? 무책임하지만, 답은 시장 논리에 따라 그때그때 다르다는 것.
기술적으로 미디어는 웹으로도 충분할 수 있지만, 컨텐츠 제공자는 일반적으로 규모의 경제 논리로 돌아간다. 거대 미디어 사업자의 입장에서 개발비는 그리 큰 부담이 아니고 오히려 타사보다 경쟁력있는 경험을 제공하는 것이 중요하다.그렇다면 답은? 컨텐츠는 기본이고 경험으로 차별화를 내세우기 위해 앱을 개발하는 게 유리하다.

5. 결론
현재는 앱이 대세고 미래는 웹이 대세다. 그러나 앱은 죽지 않는다.

 

지하철에서 "랙션"이라는 광고를 물끄러미 보다 기시감을 느꼈다.

CEO가 슈퍼맨 복장을 하고 있는 인츠닷컴의 지하철 광고를 처음 보았을 때의 그 느낌.

요즘들어 주변에 회사를 그만두고 창업하는 이들이 부쩍 늘었다. 회사가 점점 이상해지기 때문이기도 하지만, 한편으로는 스마트폰/앱의 열풍과 소셜 커머스의 광풍이 벤처에 대한 기대감을 한껏 높였기 때문이라고 생각한다. 십년만의 일이다.

차세대 버블은 그린 IT라고 생각하고 있었는데, 생각보다 빨리 온 것일지도 모른다. 어쩌면 금융위기의 여파로 그린 IT가 주춤한 새를 메꿔주는 작은 버블일지도. 아니, 어쩌면 진정한 새로운 혁신일지도.

잘 알지도 못하는 특정 서비스를 지칭해서 미안하지만.
랙션이라는 서비스가 성공할 수도 그렇지 못할 수도 있지만.
사이트를 돌아보며, 의심스러운 부분만 보게 된다 - 모호한 컨셉. 광고는 거창하고. 광고 BM 같고. 공짜로 뿌리고. 쉐이킹의 트렌디함... 

서비스는 작게, 조용히, 알차게 시작해서 크게 키우는 게 맞다고 생각하기 때문일지 모른다.
내가 완벽하게 틀렸을지도. 스마트폰 앱 시대에 데스크탑 웹의 서비스를 떠올리는 구닥다리의 시선으로 바라보는 것일 수 있으니까.

어쨌건 중요한 건 지금. 간만에 시장은 달아오르고 있고. 이번엔 꼭 성공하길. 벤처붐 만세.

SNS 무서운 성장세... 이메일까지 위협

트위터와 페이스북의 급격한 성장을 보면, 아이폰의 한국 출시 만큼이나 변화를 실감한다.

크롬 OS는 실패할까?

삼성이 바다를 출시해서는 안되는 이유를 보다가 든 생각..

소프트웨어 개발비 산정을 위한 방법론으로 기존 LOC 나 MM 방식을 지양하고 FP 방식을 도입하려는 추세다.