일정 때문에 끝까지 듣지는 못했지만 공유할 만한 사항이라 생각해서 정리합니다.

핀테크 업체들중에서 흔히 잘 나간다고 인식되는 업체에서 발표자가 나와서 마인드셋, 사고방식 어떻게 해야 빠르게 만들어 낼 수 있는지에 관해서 설명했습니다. UX 에 관한 발표라고 알고 있었지만 실제로 들어보면 벤쳐 정신에 대한 강의에 더 가깝더군요. (적어도 토스 디자이너 분은 그랬습니다.)

토스 디자이너


  • 돈 떨어지기 전에 시장에서 통하는 제품을 빠르게 만들자.
     스타트업은 돈이 떨어지면 그냥 끝이기 때문에 길게 생각하면서 만들 여유가 없다고 합니다. 빠르게 자주 만들면서 목표에 다가가는지 항상 체크하면서 개발하자. (본인 생각으로는 린 스타트업 정신과 일맥상통합니다)
  • 빠른 실행을 위한 마인드셋 
    '그거 안 넣으면 망해? 망하면 그거 때문이야?' 정말 처절하게 핵심만 남기기 위한 사고방식이라고 생각합니다. 의사결정자들을 거치면 거칠수록 늘어나는 기능 때문에 일정이 계속 늘어나는 경우 때문에 만들어 진 사고방식이라고 봅니다.
  • 가혹하게 줄여야 MVP (Minimum viable product) 다.
     '토스 초기에는 이체를 신청하면 대표가 공인 인증서로 송금을 했다.' 라는 식의 처절한 MVP 를 말한다. 실제 이랬는지…
  • 제품 개발의 목표는 '완성'이 아니라 '가설 검증'이다. 
    스프린트의 목표를 '이러면 이러할 것이다' 라는 가설을 세우고 그것을 검증하기 위해서 일정 계획을 세워야 한다는 것이다.
  • 데이타 수집과 분석은 절대 타협하지 않습니다. 
    다른 모든 것을 희생하더라도 데이타 수집과 분석은 상당한 공을 들여야 합니다.
  • 퍼널 리포트 (Funnel reports)를 만들어야 한다. 
    토스는 이메일 인증때문에 수 많은 사람들이 빠져나갔다는 것을 데이타 기반으로 알아냄, 퍼널 분석만으로 충분하다. (깔때기 분석)


내가 있는 곳이 구글 캠퍼스인 관계로 (구글 안다님 ㅋㅋ) 구글 관련 세미나를 종종 들을 때가 있다. 2년전부터 운영하는 광고 플랫폼에 관한 세미나라서 들어봄. 그래서 정리함 

뭔가 새로운 것을 들으면 정리해보는 습관을 들여야 나중에 편하다는 것을 깨달아서


구글 UAC 앱 마케팅 오피스아워

UAC 란?

Universal App Campaign , 구글의 통합형 광고 지원시스템이라고 볼 수 있다.

기존의 광고 체계

  • 플레이스토어내의 광고
  • 구글 검색내의 광고
  • 앱 내부의 광고
  • 쥐메일(Gmail) 의 광고
  • 유튜브의 광고

UAC 광고 플랫폼

전반적으로 페북의 광고 플랫폼을 많이 카피했다는 생각을 지울 수 없다. 아니면 통합 광고 플랫폼이 보통 저런 형식이던지.

  • 광고 소재
  • 타겟 지역
  • KPI
  • 입찰 단가
  • 예산

UAC 의 특징?

  • 유니버셜 앱 캠페인 + 머신러닝이 포함 된 형태 사람이 한 행동을 분석해서 그 사람과 비슷한 사람을 찾아서 정보를 기반으로 하여 광고 캠페인은 진행함 일반적인 알고리즘이긴 하다. 대표적인 추천 알고리즘
  • 2년전에 런칭, 알게된 클라이언트들이 모두 사용하고 있다고 한다. (확인할 길은 없다)
  • 이제 UAC 만 사용할 수 있다. 다른 개별 개별의 인벤토리(쥐메일이나 유튜브 등을 이리 말하는 것 같다)용 광고는 사용 못함
  • 통합형 광고이지만 개별 개별의 인벤토리 광고 단가보다 싸다. 최대 60% 까지 쌈 (1/3 가격)
  • 기존 캠페인의 생성은 10/15 까지 가능이고, 지금 운영되는 모든 단독 캠페인은 11/14 까지만 운영 가능하다. 이제 UAC 만 가능하다.

UAC 의 종류

UAC 인스톨

  • 가격이 싸다.
  • 충성도가 높지 않은 대량의 사용자를 유입시키고 싶을때 쓰는 옵션

UAC 액션

  • 사용자의 행동 행동을 분석해서 알맞은 광고를 진행
  • 가격이 비쌈
  • 대신 광고 대상 사용자의 리텐션이 높고, 퀄리티 (진행자의 표현)가 높다.

UAC 인스톨 어드밴스

  • UAC 인스톨과 UAC 액션의 중간 포지션
  • 가격도 중간 사용자의 리텐션과 퀄리티도 중간

UAC 밸류

  • 아직 런칭 전이다.

UAC 의 유의점

테스트가 좀 까다롭다. 최적화를 위해서는 사용자들도 '노력'을 많이 해야 하고, 구글의 베스트 프랙티스를 꼭 따라줘야 한다. (강하게 권고함)

사용자가 해야 할일

  • 본인들의 앱 환경을 데이타 기반으로 이해하는게 중요함.
  • 이를 위해서 분석툴 설치가 필수
  • 3rd 파티툴인 애드브릭스 (무료), 코차바(유료) 추천
  • 자사(구글)의 파이어베이스 추천 , 구글 어날리틱스는 웹에 특화되어 있다고 함
  • 결론적으로 파이어베이스 추천하는 것임


클라우드 서비스의 종류

클라우드 서비스를 이용해서 자체 서비스를 개발하는 것은 이제 흔한 일이 됐습니다. 저는 처음 클라우드가 만들어졌을 때 대체 이걸 어떻게 상용화 할까? 라고 생각했지만 무엇인가를 팔고 이윤을 남기기 위한 인간의 욕망을 무시하면 안된다는 것을 잘 알게 됐습니다.

그렇다면 클라우드의 종류인 IaaS (Infrastructure-as-a-Service) 와 PaaS (Platform-as-a-Service) 와 SaaS (Software-as-a-Service) 는 어떻게 차이가 있는가?


(출처: blog.msdn.microsoft.com)




위 그림에서 가장 쉽게 이야기 해주고 있습니다. IaaS 는 Host에 주안을 두는 것이고, PaaS 는 build 에 주안점, SaaS 는 consume 입니다. 이보다 더 자세하고 명확하게 알아보기 위해서는 다음 그림에서 확실히 소개하고 있습니다.


(출처: blog.msdn.microsoft.com)




위 그림이 가장 클라우드의 핵심입니다.

Packaged Software

이 경우는 보통 IDC (Internet Data Center) 에 직접 서버를 두고 관리를 하는 경우에 해당합니다. 관리해야 할 내용이 많습니다. 네트워크도 설정해야 하고, 저장소 크기도 상태 확인해 가면서 키워야 하고 서버도 직접 관리 등등 모든것을 직접 관리해야 합니다. 보통 이런 경우에 전문적으로 관리하는 SE (System Engineer) 가 필요한 경우가 많습니다. 조그만 회사에서는 서버 개발자가 전부 관리를 해야 합니다.

클라우드 서비스 전의 IT 회사는 대부분 이런 형태의 서버군을 배포환경으로 구성해야 했습니다.

IaaS

이 경우에는 IDC 에서 해야할 일이 전부 사라진 경우입니다. 그 일과 함께 SE 가 해야할 일도 하드웨어 사이드의 일이 전부 사라집니다. 나쁘게 말하자면 개발자가 어느정도 서버 (보통은 리눅스)의 관리를 할 줄 알게 된다면 SE 가 전혀 필요 없는 경우가 생깁니다.

서버의 인스턴스를 마우스 클릭질 몇번으로 생성하고 내가 필요한 어플리케이션을 서버에 올려서 바로 배포가 가능합니다. 배포를 염두에 뒀을 때 하드웨어 적으로 고려할 사항이 극도적으로 적어졌습니다.

PaaS

이 경우는 IaaS 보다 더 극단적으로 쉬워진 경우입니다. 배포 세팅에 대한 고려도 거의 안합니다. 쉽게 말하면 서버가 구동하기 위한 실행 로직 (흔히들 말하길 Business Logic)만 신경쓰면 됩니다. 이쯤 되면 SE 는 필요하지 않습니다. 개발자는 개발 로직만 만들어서 PaaS 에 올리면 나머지는 클라우드가 알아서 확장이나 상태를 관리하기 쉽게 해줍니다.

SaaS

개발도 필요없는 이미 만들어진 서비스를 이용하는 경우입니다. SE 뿐만 아니라 개발자도 필요없습니다.

어떤 플랫폼이 좋았는가?

사실 이야기 하고 싶은 것은 이 주제였습니다.

만들어야 하는 사이트는 웹 소설 플랫폼이였습니다. 개발 기간을 짧게 잡고 있었기 때문에 주요 개발 언어로는 Python 을 선택했고, 웹프레임워크로는 Django 를 선택했습니다. 대략 개발에만 집중해야 하는 기간이 4개월 정도 였기 때문에 Java 언어 기반으로 하기에는 시간적 부담이 느껴졌습니다.

기본이 OpenMarket 플랫폼이기 때문에 필요한 부분이


  • CP (Contents Provider) 사이트 영역
  • Customer 영역
  • 결제 부분
  • 정산 부분


이 필요합니다. 보통 플랫폼 개발은 개발자도 많이 투입하고 개발이 오래 걸리지만 사이트의 특성상 빠르게 개발하고 빨리 오픈하고 계속해서 고쳐 나가는 방법을 정했습니다.

개발 플랫폼을 정하는 것이 개발 초기의 가장 핵심적인 결정 사항이였기 때문에 여러모로 고심을 하다가 구글 앱 엔진 으로 선택했습니다. 이를 결정한 이유는 위에서도 언급이 있지만 배포나 시스템 설정등을 고려하지 않고 개발에 집중하고 싶었기 때문입니다. 왜 레진 코믹스는 구글 앱 엔진을 선택했나 라는 슬라이드도 보고, 아는 지인도 레진 코믹스에서 개발자로 있어서 자문도 구할 수 있었기에 흔쾌히 결정을 했습니다.


PaaS(Platform as a Service)인 구글 앱 엔진은 일단 신경 쓸게 별로 없습니다. 앱 엔진용 SDK 를 받아서 그걸 이용해서 코딩을 하고 베포와 운영은 아주 쉽습니다. 다만 앱 엔진용 SDK 를 공부하고 익숙해져야 하는 단점이 존재했습니다. 빠르게 프로토타입을 만들때는 정말 좋을꺼라고 생각을 하지만 뭔가 대용량의 시스템을 만들어 갈때는 앱 엔진에 맞춰서 개발해야 하는 점이 부담이 되고 잘못됐을 때 바로잡을 레퍼런스가 부족하다는 단점도 큽니다. 개발자들은 구글 앱엔진용 SDK 가 별로라고 원성이 자자했습니다. 그리고 무엇보다 한국에 IDC 가 없기 때문에 무지하게 느렸습니다. 처음부터 멤캐쉬를 고려하고 개발을 시작해야 한다는 문제입니다. (실제로 레진 코믹스도 느린 속도때문에 고생했었나 봅니다). 그러나 무엇보다 좋은 점은 검색 엔진을 구글것을 쓸 수 있다는 점이 장점이였습니다.


초기의 개발은 문제 없이 진행됐습니다. Google App Engine - Django Skeleton 을 이용해서 장고(Django)를 이용한 서비스를 쉽게 '구글 앱 엔진'에 올릴 수가 있었습니다. 하지만 파일 업로드 기능부터 문제가 발생하기 시작했습니다. 일반적으로는 전혀 문제가 안되는 기능인데 구글 앱 엔진을 이용하면 문제가 되는 현상입니다.


결국 최종적으로 사이트가 완성이 되고 최초 공개가 됐을 때 사이트가 너무 느리다는게 문제로 작용했습니다. 웹이나 앱 서버등이 데이타를 가져오는 데 걸리는 시간이 너무 걸리는 것입니다. 너무 느려서 슬쩍 레진 코믹스 개발자에게 너무 느린게 아닌가. 자문을 했더니 뭐 보통 그정도 속도인데? 이런 반응을 보이는 것입니다. 아니 이 느린 환경에서 개발을 이뤄내고 회사를 그 정도 크기 까지 키운 레진 코믹스의 개발자들이 너무 대단스러워 보이는 것입니다. 그래서 마구 칭찬을 했더니 '니네는 투자도 받았다면서? 그냥 AWS 로 개발하는게 낫지 않겠어?' 라고 하더군요. 그래서 바로 IaaS (Infrastructure as a Service) 인 AWS 로 개발 플랫폼을 바로 바꿨습니다.


변경하는데 1주일 정도 걸리더군요. 아직 실제로 서비스 하는 중이 아니였지만 실제로 운영중이였다고 하더라도 그리 오래걸리진 않았을 것이라고 생각됩니다. 사실 편하게 바꿀 수 있었던 이유중의 한가지는 팀원중의 한명이 리눅스(Linux)를 설치하고 그 안에서 서비스 배포의 경험이 많았던 사람이라서. 마우스 클릭질 몇 번으로 서버가 생기고 그 안에서 배포하는 걸 쉽게 할 수 있었기 때문입니다. 구글 검색이 문제 였는데 이것은 엘라스틱서치 에 한글 자소분석기를 붙인것을 Docker 로 만들어서 배포한 걸 이용해서 2분도 안되서 설치해서 적용했습니다. 물론 검색 API 같은것은 따로 만들어 줘야 했지만 말입니다.


결론적으로 우리 회사는 AWS 를 이용한 IaaS 를 이용하는 것이 여러모로 편했습니다. 서버 이해도가 높은 개발자들이 있어서 더욱 그러했던것 같습니다. 만약 구글 앱 엔진이 그리 속도가 느리지만 않았다면 (구조적인 문제입니다. IDC 가 미국 중부나 심지어 동부에 있으니..) 계속 썼을 수도 있으나 만약 쓴다고 해도 아예 처음부터 멤캐쉬(memcache)를 이용한 방식의 아키텍쳐를 구성해야 했을 것입니다. (이 부분은 다시 잘 정리해야 할듯)


어떤 플랫폼을 쓰느냐에 대해서 정답이 없을 듯 합니다. 다만 조금이라도 복잡한 기능을 구현하려고 한다면 자유도가 높은 IaaS 를 추천합니다.






안드로이드 개발을 위해서 구글이 내놓은 새로운 개발툴 입니다. 최근에 이클립스가 maven 지원이 더딘것 때문에 사용자를 늘려가던 (유료인데도 불구하고!!) IntelliJ 기반입니다. 물론 구글이 내놓아서 공짜랍니다. 크기는 무려 700메가 정도군요, 기가단위가 아니라서 가벼운게냐..


조금 더 만져보니 이게 프로젝트가 비쥬얼 스튜디오 마냥 한번에 하나의 프로젝트만 열게 되어 있군요. 그래서 여러개를 한꺼번에 오픈하는 방식인 ADT 보다 가볍다는 소리를 듣는군요. 


자세한 설명과 다운로드는 바로 http://developer.android.com/sdk/installing/studio.html 에서 다운받을 수가 있습니다. 


지금까지 ADT 를 잘 사용했는데 왜 이걸 또 배워야 하느냐고 물으실 수가 있습니다. 저는 구글의 대변인은 아니지만 ㅎㅎ 이게 비록 베타인데도 웨어러블 (Wearable) 앱 만드는데 최적화가 되어 있습니다. (추천한다고 여기 저기 쓰여져 있습니다) 그리고 메이븐도 사용할 수가 있습니다. 자세한 것은 위의 주소에 가면 설명이 되어 있지만 따로 가져와 본다면 




제가 하는 영역과 관련되서 딱 하나의 불만은 NDK 가 지원 안된다는 점이지만 뭐 급할 것은 없겠지요. 받아서 설치하시고 나면 


바로 테마를 Default 에서 취향에 맞춰서 Darcula (드라큘라가 아니다? -ㅅ- ) 바꿔주셔도 좋습니다. 테마가 두개 밖에 없으니 알아서 골라주세용 


아 그리고 에디터를 이용할때 사용하는데 전혀 거부감이 없었습니다. 그 말인즉슨 에디터가 기본으로 이맥스(Emacs) 키 바인딩을 지원한다는 것이겠지요. 이것 또한 아주 마음에 드는 부분이였습니다. 


Mint 를 사용하다보면 오른쪽 상단에 있는 "(금) 17:09" 이렇게 시간이 쓰여져 있는 것을 보셨을 것입니다. 그것을 살짝 눌러보면 달력과 일정이 쭈르륵 나옵니다. 여기에 표시가 나오는 것을 보니 어딘가(?) 에서 설정해 주면 편하게 일정이 나올 것 같은 분위깁니다. 그래서 아래쪽에 있는 "달력 열기" 버튼을 클릭해 주면 에볼루션이 설치가 안되어 있다고 에러 메시지가 발생할 것입니다. 감히!! 데비안 패키지를 어떻게 보고!!

$ sudo apt-get install evolution


이러면 바로 설치가 됐을 것입니다. 그리고 아까와 같이 '달력 열기'를 클릭하면 에볼루션 (Evolution) 어플이 실행됩니다. 에볼루션에 관한 설정은 쉽게 알아볼 수가 있을테니 여기서 구글 캘린더랑 연동하는 법을 알아보기로 하겠습니다.

에볼루션에서 '새로 만들기' 옆에 있는 '아래로 향한 화살표'(보통 콤보 버튼이라고 합니다)   버튼을 클릭해서 '달력' 메뉴를 선택합니다. 그러면 다음과 같이 나오는데





'종류'를 '구글' 로 선택하시고 '사용자이름' 을 gmail 아이디로 적어 줍니다.

이렇게 하고 '적용' 하시면 동기화 끝입니다. 에볼루션에서 일정을 적어주면 바로 바로  오른쪽 상단 태스크바에 적용이 되며, 안드로이드 폰에도 바로 적용이 됩니다.

참고로 에볼루션 버젼은



입니다. 예전 버젼에서는 구글-캘린더가 읽기 전용으로만 동작했습니다.


진짜 편리한 '크롬 확장'을 소개합니다. 바로 '구글 사전' 인데요. 이걸 설치하면 영문 문서 볼때 괴로움을 많이 없애 줍니다.



제가 올린 그림 처럼 세팅을 해두면요.

모르는 단어가 나왔을 때 그 단어를 '더블클릭' 하면 단어의 뜻이 나오고요.

모르는 문장이 있을 때 Command (전 맥이라) 키를 누른 상태에서 문장을 선택하면 (긁으세요!!) 문장의 해석이 나옵니다.

이 '구글 사전' 은  'Chrome Web Store' 에서 설치가 가능합니다. 

 
사람들하고 이야기 하다보면 요즘 스마트폰을 끼고 일어나는 기업들에 관한 이야기가 많습니다. 그것이 요즘 IT 계의 화두 이기도 하기 때문일텐데요. 항상 중심에는 구글과 애플이 있습니다. 그리고 요즘 찬밥이라 불리는 어도비가 있고 또 아마존이 있습니다. 이런 기업들에 대한 제 사견을 밝혀보도록 하겠습니다. 철저한 저의 사견입니다. ㅋㅋ

기업은 사람이 지배하고 운영합니다. 그래서 기업을 사람과 동일시하게 보는 경향들이 있는데요, 꼭 기업들 마치 사람처럼 감정적으로 사이가 안좋아져서 전략들이나 제휴가 결정된다고 생각하는 경향입니다. 물론 CEO 의 의견이 가장 많이 반영되기 때문에 마치 기업이 한사람 인냥 행동하는 것처럼 보일 수도 있을 것입니다. 그러나 아무리 결단이 감정에 의해 지배 된다고 하지만 기업가들은 그런 류로 생각하라고 만들어진 사람들이 아닙니다. 기업가들은 철저하게 '가치' 위주로 판단을 하고 결정을 한다고 보시면 됩니다.

이런 전제를 하고 기업들관의 관계를 보면

아마존 vs 애플

"애플이 아이패드를 내놨기 때문에 퀸들이 타격을 받을 것이다. 그래서 아마존하고 애플하고 적대적인 경향이 있다."  - 지인의 말

그럴리가요.. 물론 퀸들 사업부 책임자는 애플이 미울수도 있을 것입니다. 하지만 아마존은 아이패드 때문에 팔릴 E-Book 들을 생각하면 잠이 안올 지경일껄여? 여전히 퀸들을 좋아하는 사용자 그룹도 있기 때문에, 아이패드의 등장은 E-Book 리더 시장의 세분화 입니다. 그래서 아이패드가 많이 팔리면 팔릴수록 아마존의 매출이 올라갈 가능성이 더욱 높아질 것입니다. 더구나 아이패드에 자극을 받아 퀸들 다음 버젼이 쌔끈하게 나오지 말란 법 없지 않겠습니까?

애플 vs 구글, 어도비

요즘 애플하고 어도비의 신경전이 장난 아니죠, 애플이 플래쉬 도트좀 깨진다고 어도비를 미워 할까요? 구글이 안드로이드를 만들었 기 때문에 미워할까요?

애플의 사업방향은 예나 지금이나 '기기 판매' 였습니다. OSX 라던지 iTunes 라던지 Apps 는 그것을 도와주는 옵션이였습니다. 다만 애플의 특성상 애플은 '폐쇄형'으로 모든것을 가지고 가는 것을 주 전략으로 행하는 기업이라는 점입니다. 다만 Apps 의 놀라울 만한 성장이 관심을 끌었을 수는 있었을 것입니다.

처음 아이팟 터치 1세대가 나왔을 때는 수많은 웹 어플리케이션 형태가 들끓었습니다. 제가 그런 모습을 보면서 애플의 전략은 필수 앱 몇개만 만들어서 소비자들에게 제공하고 나머지 부족한 부분들은 웹 어플리케이션을 통한 '모바일 클라우드' 형식으로 제공하는 형태로 단순하고 가벼운 스마트폰 시장을 열어가겠구나. 라는 생각이 들었습니다.



그리고 1년에서 1년 반만에 온갖 사람들이 해킹을 해서 갖가지 Apps 가 만들어지고 사람들의 지속적인 요청에 따라서 결국 애플은 SDK 공개를 결정하고 그 결과로 폭발적으로 Apps 시장이 열렸습니다.

문제가 여기서 출발합니다. 이 플랫폼을 독점하고 싶어진 것입니다. 그래서 눈을 돌리면 '모바일 클라우드'의 구글과 온갖 자유로운 어플리케이션의 온상인 플래쉬가 보입니다. 결국 그들하고는 사이가 멀어지고 그들을 아이폰에서 차단해야 그 플랫폼은 애플 소유로 독점할 수가 있겠지요.

"이런 모든것이 애플을 통하지 않고 나오게 된다는것입니다"



더 쉽게 말하면 모바일 사파리에서 플래쉬가 가능하게 바뀐다고 생각을 하면 기존의 나와 있는 온갖 플래쉬 어플리케이션과 게임들이 그대로 아이폰에서 돌아가는 구조가 되겠지요? 그리고 이런것이 돌아가는 바탕이 되는 웹 서비스들은 구글이 신나서 전부 제공할 것입니다. 그러면 독점할려고 했던 Apps 시장은 어떻게 될까요?

결국 구글이 가져가려는 '모바일 클라우드'와 어도비가 제공하는 웹상에서의 어플리케이션 기능들은 애플이 독점하고 싶은 아이폰에서의 Apps 플랫폼에 상당한 위협이 되기 때문에 견제를 안할 수가 없는 것입니다.

결론을 말하자면 얼마전에 안드로이드 2.2 가 발표가 됐습니다. 거기에는 플래쉬가 탑재 가능할 것처럼 보입니다. 어도비는 구글에 붙어서 온갖 최적화를 다 해줄 것입니다. 안드로이는 새로 개발되는 안드로이드 앱스 뿐만 아니라, 기존의 엄청난 숫자의 플래쉬 apps 까지 포함하게 됐습니다. 거기에 자신들이 생각하는 '모바일 클라우드' 까지 포함되는 일련의 제품 라인업을 갖추게 되겠지요.

벌써부터 안드로이드의 시대가 왔다 라고 떠드는 사람들도 있습니다. 그것이 정말 사실로 다가오는지는 향후 1-2년을 보면 되겠습니다.아이폰은 대단한 혁신이였습니다. 그러나 애플이 가지는 고유의 폐쇄성 때문에 Apple2 옆에 이름을 새기게 되는건 아닌지 모르겠습니다.




진짜 신기하네요..
20% 프로젝트 성공의 조건

윤석찬 (다음 R&D 센터 팀장)   2007/01/26


몇 달 전 지인 중 한 명이 갑작스럽게 전화를 하였다. 구글 본사에 취업을 하게 되어
출국장에서 제 생각이 나서 안부는 전하고 가야겠기에 연락을 했다고 한다.
그 전화를 끊고 나서 한편으로 부럽다는 생각이 들었다. 누구나 근무하고 싶은 세계 최고의
전도 유망한 좋은 회사와 창의적인 업무 환경, 미국 서부의 좋은 날씨, 그리고 가족들에게
좋은 교육 환경까지 제공할 수 있다고 생각이 들었기 때문이다.

오후에 미국에 있는 또 다른 지인과 채팅을 하면서 이런 저런 이야기를 했더니, 오히려
그는 미국 생활 이란 것이 매우 척박한 삶이라면서 나를 위로 하였다. 구글 본사는
밖에서 보는 만큼 그렇게 낭만적이지 않으며 워크 홀릭의 땅이니 너무 부러워하지 말라는
충고였다.

정말 구글은 개발자들에게 낭만적인 곳인 걸까? 필자도 세 번 정도 구글을 다녀왔었지만
외견상으로는 멋진 업무 환경과 엔지니어를 위주로 하는 회사 정책 등 개발자들에게 희망을
주는 곳이라고 말할 수 있을 것이다. 그 중에도 가장 널리 알려진 20% 프로젝트 제도가 있다.
 이 방식은 현업 외에 창의적인 일을 할 수 있다는 개발자들에게 동경의 대상이 되는 제도
이다. 실제로 구글 개발자들은 개인 업무의 20%를 자신이 원하는 프로젝트에 시간을
투입할 수 있다. 일주일의 하루든지 일년에 두 달이든 그건 스스로 정할 수 있다.

구글의 독특한 문화, 20% 프로젝트
기술 기반 회사에서 개발자들에게 자신의 창의력을 발휘할 시간적 기회를 준다는 것은 매우
중요하면서도 필요한 일이다. 하지만 실천하기는 매우 어려운 일이기도 하다. 그러나 구글의
개발 방법론은 외견상으로 크게 성공을 했고, 최근에 나온 많은 혁신적인 서비스와
프로젝트들이 나오게 된 밑거름이 되었다.

어떤 구글 직원의 이야기에 따르면 구글의 20% 프로젝트는 다음과 같이 진행된다고 한다.

(중략)…만약 자기가 하려는 일이 아직 프로젝트가 돼 있지 않다면 '아이디어 마켓'에 자신의
아이디어를 올리면 된다고 했다. 이 아이디어에 일정 수 이상의 다른 직원이 좋은 아이디어라고
동의하면 '20% 프로젝트'가 된다고 설명했다…(중략)… 이 후 '20% 프로젝트'가 어느정도
성과를 거두고 더 큰 자원(서버, 네트워크, 마케팅 등)이 필요하다고 판단되면 임원에게
보고하고 정식 프로젝트로 승격되는 과정을 거친다. 정식 프로젝트로 승격되면 이
 프로젝트는 이제 '80% 프로젝트'가 된다는 것이다.

'80% 프로젝트'는 임원들의 승인을 거친 아이템으로 시장에 서비스로 출시되는 것을 염두에
두고 하는 프로젝트이다. 구글의 서비스 런칭 단계는 따라서
'아이디어 마켓'→ '20% 프로젝트' → '80% 프로젝트' → '상품화' 등으로 이어진다는
설명이다. 그는 구글의 이러한 독특한 문화를 설명하면서 "구글은 직원들간에 자유로운
정보유통과 더불어 함께 일구는 문화가 잘 구축돼 있다"며 "그런 경쟁력이 지금의 구글을
 있게 한 밑거름"이라고 분석했다…
(후략) 구글 직원이 소개하는 독특한 '구글 기업문화', 정종오 기자, 아이뉴스

참 재미있는 서비스 설계 구조라고 할 수 있다. 소위 전략, 기획을 담당하는 사업 부서 혹은
부서장의 의지에 따라 사업이 추진 되는 데, 비해 Bottom-up 방식의 민주적 의사 결정에 의해
서비스를 만든다는 것이다. 통상 일반적인 회사 체계를 가지는 곳에서는 이해가 가지 않는
 이 방식이 구글에서는 어떻게 가능한 것인가 몇 가지 살펴 보았다.

1. 시장 경쟁 지향 프로젝트 환경을 제공한다.
우선 구글은 진짜 개발자들에게 20%의 시간을 준다. 구글 코드 서비스를 담당하고 있는
 그레그 스타인(Greg Stein)에 따르면, 모든 개발자들이 접근할 수 있는 기반 플랫폼을 기초로
 하여 3~4명 단위의 소규모 프로젝트(20% 프로젝트)가 천여 개 이상 진행되고 있다고 한다.
 구글의 개발자들은 그 가운데 스스로 성공 가능성이 높은 프로젝트를 선정하고 경영자들의
 승인 아래 더 많은 사람이 프로젝트에 투입 되도록 문호를 개방 한다. 이 말은 결국 선택 받지
 못하는 프로젝트는 스스로 도태된다는 것을 의미한다.

얼핏 보기에는 프로젝트 추진에 대한 민주적 의사 결정처럼 보이지만, 실제로는 약육 강식,
 자연 도태의 환경과 비슷하다고 볼 수 있다. 창의성 높은 프로젝트가 계속 계발 되는 동시에
이 와중에서 심각하고 과도한 경쟁을 유발한다는 이야기이다.

실제로 구글에서는 한해 추진된 20% 프로젝트 중 가장 뛰어났다고 생각되는 것에 백만 불을
상금으로 주는 제도도 있다고 한다. 필자가 구글에 방문할 때마다 오후 늦은 시간이었다.
 실리콘 밸리이긴 하지만 퇴근 시간이기 때문에 101번 고속도로가 체증을 일으키고 있었지만
구글은 저녁 식사 후에도 여전히 사무실 불을 밝히고 있는 몇 안 되는 곳 중에 하나다.
마치 연구에 몰두 하는 대학 캠퍼스를 연상하게 한다.

2. 똑똑한 워크홀릭이 주류여야 한다.
구글에 입사하기 위해서는 꽤 까다로운 절차를 통과해야 하는 것으로 유명 하다. 구글이
후보자를 면접 하는 중에 가장 중요하게 보는 덕목이 '자기 주도적'인 사람인가 하는 점이라고
 한다. 실제로 그 변덕스럽고 이해할 수 없는 절차를 통과한 사람은 정말 구글에 대한 열정이
 높고 자기 주도적인 사람이 아니라면 어려울 것이다. 면접 과정에서 그 치열하고 어려운 기업
 문화를 미리 느껴 볼 수 있으니까. 이런 이면에는 기업의 성장에 '무임 승차(Free Riding)하는
사람을 배제' 하는 것이 그들의 첫 번째 인재 정책이라고 할 수 있다.

특히 구글에는 아주 똑똑한(Smart) 사람이 많다. 존 버틀러의 "The Search"에 따르면, 2002년
중반 실리콘 밸리 침체기에도 구글의 성장과 독특한 천재 예찬론을 기초로 아이비 리그
출신들의 석박사급 인재를 많이 충원을 했다. 현재는 좀 완화되기는 했지만, 학교와 학
점(GPA)과 학위를 중시하는 것은 여전하다.

구글에는 소위 카스트 제도라고 불릴 정도로 똑똑한 엔지니어 위주의 인재 정책을 펴고 있다.
실력이 뛰어나고 이름 있는 공개 소프트웨어 분야의 수 많은 엔지니어들이 구글로 자리를
 옮겼다. 특히, 최근에 아이디어와 끼가 넘치는 3~4인 정도의 웹2.0 스타트업 기업들도 대거
인수하여 인재를 확충하고 있다. 이들에게 자기 성취를 할 수 있는 업무 여건 및 경쟁 환경을
도입하는 것은 불 붙은 곳에 기름을 끼얹는 것이나 다름이 없다.

3. 경영자의 절대 권력이 존재해야 한다.
구글은 성공 가도를 달리기 시작하던 2002년말, 래리 페이지와 세리게이 브린은 그들의 조직
구조를 '위계형'에서 '수평형'으로 바꾸고 80:20 프로젝트를 도입했다. 이 때 부터 상위 100개
 프로젝트 목록이라는 것이 있었다고 한다. (지금은 없어지고 사업 분야별로 각자 목록을
가지고 있지만) 페이지와 브린은 여전히 그 프로젝트 목록을 살피고 투입해야 될 프로젝트에
대한 의사 결정을 한다.

'똑똑한 워크홀릭'들이 절대 권력을 행사하는 경영자의 판단에 따라 신데렐라가 될 수 있다는
기회 때문에 이 프로젝트의 창의성과 혁신성은 더 높아지고 있다. 이런 특징은
마이크로소프트의 빌 게이츠나 오라클의 래리 엘리슨, 애플의 스티브 잡스 등 경영자이면서
오너인 회사에서는 두드러진다. 빌 게이츠는 일년에 두번 모든 직원들이 올린 보고서를 읽어
보는 씽크 위크를 가지고, 일반 사원들의 의견까지도 수렴하고 있다. 이것은 경영자이면서
오너인 사람은 똑똑하다는 가정하에 기업의 성공 가능성이 매우 높다고 할 수 있다.

많은 기업들이 구글의 20% 프로젝트에 감명을 받고 비슷한 제도를 만들어 볼까 고민한다.
하지만 대부분의 회사들이 위의 조건들을 충족하지 못할 것이다. 이런 제도를 도입 하기 전에
자신의 조직에 정말 적합한 제도인지는 한번 돌아볼 필요가 있겠다. 구글의 20% 프로젝트의
성공이 우리에게 시사해 주는 바는 엔지니어의 창의성을 담보해 주면 기술 경쟁에서
장기적으로 유리한 고지를 점할 수 있다는 점이다. 이런 원칙을 기초로 자신의 회사에 적용할
방법을 찾는 것이 좋겠다.@
 

+ Recent posts