개발자들이 모두 앱등이냐고? 쿠키가 9%를 고집하게된 이유

바야흐로 ‘모바일 먼저’의 시대다. 국내 모바일 페너트레이션이 60%를 넘어 70%를 보고 있는 상황에, 이제 앱이 왜 필요한가요?는 그냥 혼나는 질문에 해당한다. 그래서 우리 팀에서 Cooki 의 모바일 앱을 만들자고 했을 때 던졌던 질문은 어느 OS부터 가나요? 부터였다.

당시에 내린 답은 ‘모르겠다, 함께 고민해보자’였고 우린 열심히 공부를 했다. 그리고 2개월 뒤, 소셜 큐레이션 매거진 ‘쿠키’는 앱스토어에 첫 데뷰를 했다. 이번 글은 왜 우리가 2,700만 안드로이드 사용자 대신 270만 국내 iOS 사용자들에게 먼저 손을 내밀기로 결정했으며 그 사이에 있었던 배경되는 고민들을 좀 정리하여 공유해보려고 한다:

우리나라에서 사용되는 스마트폰의 경우 90%가 안드로이드 OS기반으로,
조사 국가중 가장 높다라는 icrossing 분석 자료.

서비스 개발사로써 사용하게될 유저 퍼소나에 대한 고민이 가장 먼저였는데, 국내 iOS/안드로이드 사용자들은 극적으로 다른 퍼소나를 갖고 있었다:

1) 누가 사용하는가?

소셜에 친숙하고, 모바일로 콘텐트를 소비하는데에 익숙한 20-30대는 iOS, 반대로 10대와 4-50대는 안드로이드 진영에 분포되어있는 것을 볼 수 있다. 사실 어떤 서비스이던지 20-30는 매우 매력적인 데모이긴 하다. 쿠키 역시 초반 물관리를 위해 젊은 지성인 층을 타겟으로 하고 있다.

2) 왜 스마트폰을 구매하는가? 어떤 목적으로 활용하는가?

iOS 사용자는 App 활용도와 디자인을, Android 사용자는 단말기 가격과 요금제을 중시한다는 조사자료. 아직 모바일 앱의 경험에 익숙치 않고, 스토어 계정을 만드는 것부터 교육해야하는 사용자들은 일단 제외 대상이었다.

3) 새로운 앱을 발견하는데 적극적인가? 가치를 느낄경우 지갑을 여는가?

특히 탐험적으로 새로운 앱을 찾고, 설치해보는 것에 비교적 더 적극적인 iOS 사용자들이 트랙레코드 없이 새로운 서비스 개념을 들고 데뷰하는 우리 입장에서 매력적으로 느껴졌다. 또한 유료앱 구매 경험이 많고, 소프트웨어에 지갑을 더 잘 여는 iOS의 유저야 말로, ‘가치 있는 콘텐트에, 칩(가상화폐)을 던져 창작자를 후원한다’는 비전을 가진 쿠키 서비스의 초기 유저로써 알맞는 퍼소나라고 생각했다.

이밖에도 자원이 한정적인 스타트업 개발사로써의 고민도 하지 않을 수 없었는데:

개발 속도와 유지보수 문제, 어느 기기까지 지원할 것이며 어떤 OS버전까지 지원 할 것인지. 웹버전을 병행해야하는 서비스로써 확실한 니즈가 파악 안된 앱을 파편화되어있기로 유명한 안드로이드 OS에 출시하는 것에 대한 부담이 컸다.

안드로이드의 파편화 문제를 보여주는 좋은 예, 기기별 화면 사이즈.
진한 색일 수록 많이 사용되는 화면 사이즈.

마지막으로 고민했던 부분은 실험으로써 적합한 플랫폼인가?라는 질문이었다. 사실 리뷰되는 속도, 즉 주어진 시간에 빌드를 잦게 릴리즈하고 시장 반응을 확인하여 실험 사이클을 돌아볼 수 있는 마켓은 구글 플레이였으나 위에 나열한 이유들 때문에라도 iOS를 결국 선택하게 되었는데, 내부에서는 그냥 쿨하게  오히려 시장 점유율 10% 미만의 소수 유저에게 테스트를 해볼 수 있다라는 말도 안되는 패기를 부리기도 (..)

결과는 아직 성공적인 런칭을 확단 할 수 있을 시기는 아니지만, 앱스토어 첫 날 쿠키는 뉴스 카테고리에서 강자 플립보드를 누르며 1위를 탈환했고, 하루 칩(가상화폐) 전송량에서는 사용자 1명 당 0.87칩(1칩은 약 100원의 화폐가치를 갖고 있다)을 다른 콘텐트에 지불하는 등 감사한 안착률을 보이고 있다.

마치며:

앱등이들은 아직 건재하다. 이들은 여전히 얼리어답터이고, 유행을 찾고 만들어내며, 자신이 사랑하는 브랜드를 위해 기꺼이 지갑을 여는 낭만인들이다. 오랫동안 미뤄져왔던 아이폰5의 출시와 더불어 오히려 국내에서 앱스토어 플랫폼은 기피의 대상이 아닌 새로운 BM을 통한 프리미엄 마켓으로 공략해야 한다고 생각한다.

물론 쿠키는 안드로이드로도 나온다.

자료 출처: 닐슨 코리아, incrossing, 엠브레인트렌드모니터, 마케팅 인사이트, 모비즌 블로그

개발 회사답게 문제에 접근하라고?

김상훈 기자님이 쓰신 글, <카카오와 페이스북이 지루함과 싸우는 법>을 통해 “혁신 주도형 조직”에 대한 멋진 두 개발회사의 사례를 보며 고민고민열매 (..)

부분 인용하자면:

카카오는 물론이고 요즘 잘 나가는 첨단 기술 기업들은 모두 직원들의 지루함과 싸운다. 페이스북과 구글 같은 기업들도 직원들을 지루하게 만들지 않기 위해 ‘해커톤’을 통해 새로운 제품 아이디어를 찾는다. 팀은 최소화한다. 10명 이상의 팀 같은 건 죄악으로 여겨진다. 팀원은 늘 손가락으로 셀 수 있어야 한다. 그렇게 작은 팀이어야 자기 스스로 컨트롤한다는 느낌을 가질 수 있기 때문이다. “위에서 시켰다”는 이유로 큰 팀에서 수직적 의사결정 구조 속에 일하는 건 스스로를 세계 최고의 천재라고 믿는 이런 사람들에게는 포로수용소에서 강제 노역에 동원된 느낌을 갖게 할 수밖에 없다.

지루한 단순 반복 업무가 이들에게도 있지 않겠느냐고 되물을 수 있다. 페이스북에선 “자동화될 수 없는 단순반복작업은 없다”고 주장한다. 그리고 엔지니어들의 과제는 크게 두 가지다.

1. 스스로 정말 하고 싶은 일을 하기,
2. 스스로 하기 싫은 일은 기계가 하도록 만들기.

두 가지 가운데 하나라도 못하면 회사를 떠나야 한다. 그러니까 하고 싶은 일을 맘껏 할 수 있다는 것은 하기 싫은 일을 자동화시킬 수 있을만큼 똑똑해야 한다는 뜻이기도 하다. 그리고 하기 싫은 일을 그냥 좋은 마음으로 기꺼이 받아들이는 식으로도 살아남을 수 없다. 객관적으로 지루한 일은 주관을 바꿔 순응할 게 아니라 객관적 기술로 해결해야만 한다.

이 글을 읽고 난 뒤에 생각난 이야기 두 개.

1. 구글이 사내 보안 문제에 접근하는 방법:

시스템관리, 특히 사내 보안쪽을 담당해보신 분들과 사내 보안의 문제에 대해서 대화를 나눠보면 보안망이 뚫려서 정보를 털리는 ‘외부요인’에 의한 해킹보다, 내부 직원의 부주의로 일어나는 ‘소셜 해킹’의 빈번도와 위험성이 훨씬 크다는 얘기를 종종 듣는다.

아마 구글도 당연히 비슷한 문제를 고민했을 것 같다. 갑작스레 커지는 기업, 그리고 보안처리해야 하는 데이터들. 여기서 구글러들은 본인들만의 방법으로 문제에 접근한다. 이름하여 ‘얼음/땡’ 놀이:

누구든 사무실에서 이동을 하다가 화면잠금(screen-lock)이 걸려있지 않은 동료 PC를 발견하면, 그 자리에서 PC를 잠궈버릴 수 있는 인트라 페이지를 띄운다. 그리곤 몰래 도망간다. /긔엽긔/ 자리에 돌아온 PC주인은 망신을 당하며 관리자 액세스를 받아 PC를 풀어야 하고, 심지어 가장 많은 ‘얼음’을 당한 구글러들은 랭킹보드에 올라가는 ‘명예‘를 얻는다고.

2. 페이스북이 웹사이트 번역 문제에 접근하는 방법:

우리 Zoyi 팀에서 페이스북을 방문했던 당시, i18n(internationalization:서비스 국제화) 관련 질문을 했었다. 당시 우리 회사는 일본에 진출을 하는 문제를 갖고 있었는데, 인력 1명을 손 떨며 힘들게 뽑던 스타트업이자 동시에 여러국가로 빠르게 진출하고 싶었던 욕심많은 스타트업에게는 i18n이 항상 고민이었다. 우리 고민을 끝까지 들은 페이스북 개발자 D모 군은 말 없이 자신의 화면을 가리키며 페이스북이 어떻게 i18n 문제를 해결하는지 보여주었는데: 관련 글 참조(영어)

그 화면에는 영어로된 페북 페이지와 함께, 각 문장 옆에 언어별로 사용자들의 입력을 받을 수 있는 기능과 Voting에 의해 번역 퀄리티를 정할 수 있는 번역 플랫폼이 구현되어있었다. 그리곤 이렇게 말했다.

“우린 언어별로 i18n 스페셜리스트를 고용하는 대신, i18n에 관심있는 개발자 2명을 투입해서 플랫폼을 만들었습니다. 이게 페이스북이 i18n 문제를 해결하는 방법입니다. 우린 이게 스마트하게 개발하는 방법이라고 믿습니다.”

페이스북에서 제공하는 번역 플랫폼. 다른 사용자들이 번역한 문장에 투표를 할 수 있고, 가장 높은 표를 얻은 번역이 선택된다.

두 회사의 문제 접근 방법을 관통하는 원칙은 간단하다:

사람의 일은 사람에게, 기계의 일은 기계에게.
(단, 사람은 기계에게 일을 시킬 줄 알아야하며, 스스로의 일을 만들 수 있어야 한다는 대전제)

어떻게 보면 너무 당연하고, 이성적인 얘기인데 왜 못하고 있을까? 왜 우리는 항상 자동화 시켜야 할 문제를 사람으로 때우고 있으며, 설계적 결함을 노가다성 코드로 채우게 되는 걸까? 우린 왜 스마트한 사람이면서도 스마트하게 일하지 않는 걸까? 그 뒤로 쉬지 않고 고민했던 문제다. 어떻게 하면 작은 규모의 (20명 미만) 스타트업 환경에서도 이런 철학을 가지고 문제에 접근 할 수 있을까?

사실 답이 존재하지 않는 문제인 듯 하다. 어떻게 개발 회사답게 문제에 접근한다는 건가.
생각해보면 삽질 속에 효과를 보게된/보고있는 지침들이 있었다. 지침인지 현상인지 구분 조차 애매한 모습들.
정리해본다면 다음과 같다:

문제를 재정의 하기

문제를 발견했다면, 냅다 달려들어서 풀 생각부터 하는 것이 공돌이들의 습관이라지만 스마트하게 접근하기 위해서는 오히려 먼저 문제 자체를 재정의 하는데 투자 할 필요가 있다. 무엇이 문제인가? 누구의 문제인가? 진짜 문제인것 맞나?
사실 말이야 쉽지, 많은 ‘습’을 필요로 하는 방법인 것 같다. 위 질문 셋을 반복해서 떠올렸을 때 도움을 얻을 수 있었다.

세계적인 엘리베이터 제조회사인 오티스는 초창기에 고객들로부터 엘리베이터 속도가 느리다는 소리를 자주 들었다. 회사에도 이 문제는 상당한 골칫거리였다. 엘리베이터 속도를 개선하는 데는 시간과 기술 그리고 돈이 많이 들어가기 때문이었다. 풀기 힘들 것 같던 이 문제를 한 엘리베이터 관리인이 간단히 해결했다.
그가 제시한 해결책은 엘리베이터 안에 거울을 붙이는 것. 그 제안에 따라 거울을 설치했더니 고객 불만이 크게 줄어들었다. 고객들이 거울을 보느라 엘리베이터가 느리다는 사실을 알아채지 못한 덕분이었다. 즉 해결해야 하는 문제의 대상은 느린 엘리베이터가 아닌 불만을 가진 고객들이었던 것이다.
-대체 뭐가 문제야? : 문제 해결에 관한 창의적 사고를 길러주는 6가지 질문 중.

품질을 정량화 시키기

뻔하지만 투자하지 않는 부분 = 높은 품질의 코드 > 유지보수 불필요 > 재밌는 일을 찾아서 할 수 있는 행복한 개발자(?)
품질 정량화라해서 스타트업 입장에서 (TDD같은)부담스럽고, 거창한 것이 아니라 작은 디테일을 정량화 시키고, 끊임없이 피드백을 주어야 품질을 위한 노력들이 지속된다는 것을 배웠다. 커밋 컨벤션에 대한 체크라던지, 코드 리뷰 시 살벌한 Verify 라던지, 심지어 해결된 버그에 대한 내/외적 인정 하나 하나가 전체 서비스를 내가 만들어간다라는 주인의식과 함께  반대로 함부로 커밋하면 안된다는 경각심을 준다는 것을 잠시라도 잊지말자.

성장과 혁신의 역학을 설계하기

‘혁신 주도형 개발조직’이라는 키워드에는 현실과 동떨어질 수 밖에 없는 문제가 있다.
바로 현실에서는 항상 A급 동료들과 일하는 상황이 아니라는 것. 특히 개발자 구인난에 시달리는 작은 스타트업일 경우 더 그렇다. 고로 우리는 성장의 역학을 만들고, 조직이 상향 평준화 되는 선순환 구조를 설계해야만 한다. 새로운 것을 배우고 공유하는 장터인 테크토크, 아이디어를 발산하고 협업과 제약 수용을 배우는 해카톤 등. 회사가 새로운 실험(이라고 쓰고 실패라고 읽는다)을 두려워 할 필요가 없는 세이프존으로 느껴지게 하는 것이 핵심이라는 것을 배웠다.

Innovation(혁신)이 일어나기 위해서 필요한 4가지 배경요소: fail fast(빠른 실패), fail early(이른 실패), fail often(잦은 실패), fail cheap(값싼 실패) 을 위해서는 Fail Safe(안전한 실패)라는 환경이 꼭 뒷받쳐줘야 한다는 것을 배웠다.

모든 직원을 개발자로 만들기

최근 우리 회사에서 가장 핫한 키워드는 Rails 와 R. 거듭되는 해카톤을 통해 개발을 배워보고 싶다는 욕구가(항상 제안되는 아이디어에 비해 개발력이 부족하다보니) 전사적으로 퍼짐과 동시에  테크토크를 통해 기본적인 튜토리얼이 제공되면서 세일즈, C/S, 운영 등 비개발 스킬군들의 동료들이 하나 같이 개발을 배울 수 있는 환경이 점차 제공되고 있다. 당장 개발에 투입시킨다기보다는 Regression Test (회귀테스트) Case 를 공동 작성하고 환경별로 나누어서 맡는 등 점진적으로 부족한 개발군으로 가치를 더하고 있다.

개발팀, 우리는 오늘 알파 테스트를 시작했습니다.

마라톤을 준비하는 방법 via Runners World magazine

뛰어난 마라톤 선수를 만드는 훈련 방법들:
템포, 스피드, 근력, 스트레칭, 정신 훈련 등.
그 중에서 가장 필수적인 훈련, 천천히 오래 달리기.

천천히 오래 달리기를 훈련하는 방법:
-최대로 달릴수 있는 속도의 70%로 달리되 주기를 가질 것 

 

 

사랑하는 쿠키 개발팀,

우리는 오늘 알파 테스트를 시작했습니다.

마감제출의 피로감과 그 해방감을 맛보고 있는 분도,
동시에 폭풍같은 버그/피드백들을 보면서 좌절감을 느끼는 분
‘할게 너무 많아서, 뭘 해야 할지 모르겠어’의 느낌으로 대략 멍한 상태로 있는 분 등.

모두 다양한 기분으로 알파 첫 날 밤을 만끽하고 계시리라 믿습니다.

쿠키가 내 이름을 걸고 만든 첫 서비스형 프로젝트인 분들도 있죠?
먼저 여러분의 이력서에 멋진 한 줄을 박으신 것을 진심으로 축하합니다
하지만 축하와 동시에 이제 시작이라는 긴장감을 드리고 싶습니다.

이미 느끼고 계시겠지만 웹 서비스 개발은 출시와 동시에 라이브 개발이 시작됩니다
그래서 웹 서비스 개발을 일컬어 스프린트가 아닌 마라톤이라고들 합니다.

우리는 이제 마라톤에 대비해야 합니다.

앞으로 클로즈베타, 그리고 오픈베타까지
쿠키가 성장함에 따라 늘어나게 될 ‘일반 유저’들은 불친절하고, 인내심도 없을 확률이 높습니다

팀 동료들과 지인들처럼 버그나 서비스 장애, 기능 부족 등을 이해해주고, 알려주기보다는
“뭐 이래?”하고 껍데기만 맛보고 실망한 뒤, 그 시간에 다른 재미있는 것을 찾아 떠날 확률이 높습니다.

우리의 호흡을 기다려주지 않는 유저들과의 게임에서 주도권을 붙들기 위해서 우리는 ‘꾸준한 빌드 릴리즈: Keep Shipping’ 를 해야 합니다. 왜냐면 이 마라톤의 승자는, 스타트를 누가 멋지게 끊었는가가 아닌 결승점에 누가 먼저 도착했는가로 결정되기 때문입니다.

우리 이 마라톤의 승자로 기억됩시다.
그러기 위해 버닝은 적게 하고, 충분히 쉬어주시길 권장합니다

알파 동안 풀 에너지의 70%로 달리도록 훈련합시다.
120%를 뽑아내야 하는 순간은, 예고도 없이 찾아오니까요.

충분한 수면과 운동 그리고 건강한 식사, 그리고 취미 생활 등 컨디션 조절을 위해 노력해주세요.

우리 팀의 생산성을 담당하는 PM으로써 부탁드립니다.

건강한 컨디션이 가져다 주는 집중력은 절대 절제와 노력 없이는 얻을 수 없고,
결국 뛰어난 결과로 말해준다고 믿습니다.

사랑합니다.

2012년 7월 13일, 폴

% 약 3개월 전, 소셜광고회사로만 알려져있던 애드바이미는  “좋은 콘텐트에 Like 누르듯 손 쉽게 후원금을 줄 수 있다면, 어떨까?” 라는 아이디어 하나로 신규 서비스를 시작하게 됩니다. 그리고 알파 동안 자그마치 13번의 릴리즈를 거친 Coo.ki 가 드디어 오픈 베타의 문을 열었습니다. 새로운 서비스 http://coo.ki 와 더불어 새로운 회사 이름 (Zoyi, Inc) 을 갖게된 저희 모습, 많은 관심과 응원 부탁드립니다 =D

왜 당신의 스타트업은 개발자들에게 인기가 없는가?

%Note: Mike Greenfield의 블로그 글 “Why developers aren’t interested in your startup“을 저작자에게 허락을 받고 번역한 내용입니다. 사실 급조한 발번역이고, 중간중간 스킵한게 많아 역자 표기는 안하셔도 되나 퍼가실 때는 최대한 트랙백이 되도록 퍼가주시고, 원래 저작자 표기는 꼭 해주시길 바랍니다.

Why Developers Aren’t Interested In Your Startup

 

제가 (엄마들의 웹 커뮤니티인) Circle of Moms 라는 스타트업을 처음 런칭했을때, 저는 처음으로 스타급 시니어 백엔드 개발자를 고용하게 되었습니다. 브라이언은 완벽했죠, 코딩 실력은 속도와 스케일러블 양쪽으로 잘 밸런싱되어있었고, 스타트업 세계에서 파운더로써 그리고 직원으로써 일한 경험도 있었어요. 특히 그가 믿고, 실행하는 업무 윤리관(work ethics)은 팀의 문화를 잘 잡아주었습니다. 수 년간 브라이언은 (엉망이었던) 기존 설계를 다시 잡고, 핵심 기능들을 개발하고, 끈기있게 젊은 동료들을 멘토링해주었습니다. 브라이언을 고용한 일은 제가 Circle of Moms 사업을 하면서 내린 결정중 가장 잘 한 일이었죠.

그리고 저는 지난 3년 동안 브라이언 2를 찾아다녔습니다. 하지만 일어나지 않았죠. 원인은 다양했습니다: 팀과 핏이 맞지 않거나, 우리의 비전에 흥미를 보이지 않거나, 우리가 줄 수 없는 대기업 수준의 연봉을 요구하거나 했죠. 이 과정 속에 강한 팀이 얼마나 회사의 성공에 중요한 역할을 하는지 깨닫게 되었습니다. 어떻게 보면 브라이언이라는 사람을 만나게 된게 큰 행운이었죠. 브라이언이 쌍둥이 동생이 있었으면 얼마나 좋았을까 항상 생각했습니다.

개발자의 풀이 한정되어있는 요즘, 하이어링은 제품 판매의 문제로 인식해야 합니다. 인력은 공급에 한계가 있으며, 제품(하이어링 패키지)을 판매하지 못하는 스타트업들은 결국 성장하지 못하는거죠.

오늘날 테크회사들은 3곳에서 자신을 알려야한다고 생각합니다.

1. 사용자/고객
2. 투자자
3. 개발자

1, 2번에 대한 책과 경험담은 쉽게 찾을 수 있지만 3번에 대해서는 아직도 부족하다는 것을 느낍니다. (사실 거의 없다고 봐야죠) 저는 이 블로그를 통해, 왜 개발자에게 어필하는 것이 이렇게 어려웠는지 차근차근 돌아보려고 합니다.

지난 몇 개월동안 AngelList Talent 는 (역자 주: 앤젤리스트는 스타트업과 투자자를 이어주는 매칭 플랫폼이고, 최근 들어 Talent라는 서비스를 오픈해서 스타트업과 구직희망자를 매칭시켜주기 시작했습니다) 스타트업 구직을 위한 마켓플레이스로 큰 성장을 이뤘습니다. (저는 Angel List의 자문위원임을 먼저 밝힙니다) 여기서는 사람을 구하고 기업을 찾는 행위가 좀 다릅니다. 한쪽이 관심을 표시하면, 다른 한 쪽에 노티가 뜨고 양쪽이 모두 관심을 표기해야 소개가 이루어지죠. 이러한 접근은 명백한 정보로 이루어진 투명하고 많은 데이터 SET을 얻게 해줍니다. 어떤 회사가 개발자들의 관심을 얻고 있는지, 또 반대로 어떤 스타개발자(혹은 스킬셋)가 회사들의 관심을 받고 있는지 말이죠. (저같은 데이터geek 에게는 정말 흥분되는 일입니다)

먼저 AngelList 에서 최고로 관심을 받고 있는 톱 10개의 스타트업을 공개합니다:

• Quora
• Pocket
• Path
• Pulse
• Instameet
• ClassDojo
• Ark
• Rally
• Locu
• Clever

1-2년 전만 해도, 톱에 있던 회사들이 Zynga, Google, Branch Out 등이었다는 것을 감안할때 위 리스트는 꽤 새롭습니다. 특히 Pocket 의 경우 (저는 Pocket의 투자자임을 밝힙니다) 제가 봐도 왜 저 리스트에 올라가 있는지 의아스러울 정도입니다. 리스트 가장 위에 있는 회사들과 아래에 있는 회사들의 차이는 매우 큽니다. 그럼 도대체 뭐가 그 차이를 만들게 되는 걸까요? 왜 어떤 회사는 개발자들이 모두 가고 싶은 회사가 되고, 어떤 회사는 아닌 것일까요?

흔히 중요할거야라고 생각되는 것중에 별로 큰 영향을 주지 않았던 요소들이 있었습니다:

기술 공동 창업자의 여부 (공동창업자 중에 개발자가 있는지 없는지는 개발자들에게 회사가 인기가 있는지 없는지 여부에 영향을 별로 주지 않았습니다) 그리고 놀랍게도, 지분의 제공 여부 역시 큰 영향을 미치지 않았습니다. (단, 회사의 사이즈에 따른 반영은 하지 않았습니다)

반대로 큰 영향을 끼치는 요인들은 4가지가 있었습니다:

산업-Industry

회사가 어떤 산업에 속해있는지가 좋은 개발자들을 얻는데 큰 영향을 미치는 것으로 나타났습니다. 특히 교육 관련 분야와 생산성 관련 제품을 만드는 회사라면 구인을 하는데 어려움이 없었고 페이먼트, 엔터테인먼트, 광고, 게임 등의 산업이 가장 가장 구인이 힘든 것으로 나타났습니다.

투자자의 질-Investor Quality

좋은 투자자가 성공을 보장해주지는 않지만, 큰 도움을 준다는 것으로 나타났습니다.

 

창업자의 질-Founder Quality

트랙레코드가 없는 첫 창업 뉴비보다 Path, Quora 처럼 (파운더들이 페이스북 초기 직원들) 창업자의 트랙레코드가 좋은 회사들이 개발자들에게 인기가 좋은 것으로 나타났습니다.

 

연봉-Salary

역시 높은 연봉을 제시하는 경우, 인기가 낮은 집단에 포함되어있는 경우가 드물다는 조사결과가 나타났습니다. (약 7%) 평균 집군보다 높은 연봉을 제시하는 경우, 인기 집군에 속해 있을 경우가 최대 5배 높았습니다.

 

물론 위의 4가지가 모든 것을 설명한다고 볼 수는 없습니다. 4가지 요소만을 조합해서 평가를 내린다면 Quora는 1위가 아닌 6위쯤에 위치해 있어야 정상이죠. 그래서 뭐가 모델에서 빠진걸까요? 받쳐줄 정량적인 데이터는 없지만 제 생각에는 이렇습니다:

회사 명성/평판

특히 많은 개발자들 스스로 직접 사용하는 Quora의 경우, 스스로 더 설명할 필요가 없겠죠.

잘 쓰여진 프로필

명쾌하고 큰 비전, 그리고 호기심을 불러일으키는 회사 소개가 있다면 큰 도움이 되는 것 같습니다. 10위권에 들법했던 LaunchRock의 경우 Quora에 비하면 유명하지 않죠. 하지만 이들의 하이어링 페이지를 보면 자신감있게 회사의 문화를 소개하면서 호기심을 불러일으킬만한 요소들을 곳곳에서 보여주고 있습니다.

사회에 중요한, 커다란 문제를 해결하고자 하는가?

개발자들은 뭔가 유익하고 사회적으로 가치있는 것을 만드는 것을 좋아합니다.

 

마치며 – 최고의 회사들은 멋진 제품을 만듭니다. 잘 알리고, 매력적인 가격에 제공하죠.

같은 원리가 개발자에게 어필하기에도 통하는 것을 잊으면 안됩니다. 제품 (존재하는 팀, 문화, 사업적인 목표, 개인에게 제공되는 기회들)이 한가운데에 있습니다. 하지만 마케팅 즉, 회사의 비전을 명확하게 표현하는 것과 알맞은 가격 (연봉)을 역시 포함해야 합니다.

어느 개발회사의 평범한 구인글.jpg

%2012.9.28일 기준으로 업데이트 되었습니다. We’re Hiring!

제 페이스북 지인분들, 트위터 친구분들, 그리고 이 블로그를 구독하시는 모든 분들께 부탁드립니다.

지금 당장 눈을 감고 한 사람을 떠올려주세요.

• 바로 그 사람, 예전에 함께 했던 프로젝트에서 다른 개발자들이 실력 좋다고 칭찬하던 그 사람.
• 비개발자들의 말을 유일하게 알아듣는 듯했던, 그래서 소개팅 해주면 이성의 말을 잘 들어줄 것 같았던 그 사람.
• 혹시라도 서비스에 문제 생기면 모두가 하나같이 찾던 그 사람.
• 책상 위에는 온갖 개발 서적과 함께 드문드문 인문학 서적도 보여서 의외네?라는 생각이 들던 그 사람.
• 책상에 꼭 둘씩 앉아서 일하는데 이상하게 한 사람만 키보드를 치고 있던게 신기했던 그 사람.

떠오르셨나요?

그럼 지금 당장 그 사람에게 메시지를 날려주세요. (추천인께는 또 추천하고 싶을 정도의 선물을 챙겨드립니다)

애드바이미 사람 뽑는대!

제가 공동창업한, 그리고 PM으로 섬기고 있는 스타트업에서 경력/신입 웹 엔지니어를 모십니다:
(이번에 동료가 되시는 분들은 http://adby.me 가 아닌 저희가 새롭게 준비하고 있는 서비스에 동참하시게 됩니다)

• 경력의 경우 RoR or Javascript or iOS 경험자이시고 XP 프랙티스(페어, 코드리뷰, 테스트주도개발 등)를 좋아하시는 분이면 환영합니다. 특히 TL로써 프로젝트 리드 경험이 있으시면 강력 환영합니다.
• 신입의 경우 문제풀이, 알고리즘 등 기본적인 C/S 스킬에 자신이 있는 분이시면 좋습니다.
  예를 들어 탑코더에서 랭킹 좀 되신다거나, ACM-ICPC 대회에서 수상 경력이 있으시다면 가산점이 붙습니다.

원하는 마인드셋, 해적 마인드 from TEAM ONE PIECE :

• 배움과 도전과 피드백을 통한 성장에 끝 없는 갈증을 느끼시는 분.
• 혁신을 위해 유쾌한 버닝을 할 각오가 되어있는 분. (조기축구회 아님)
• 그럼에도 불구하고 멀리가기 위해 천천히 가는, 진정 여행의 여정을 즐기는 분.

팀웍이라는게 뭐야?
그저 도와주고, 막아주고 그런걸로 되는거야?
그렇게 생각하는 녀석들도 있겠지만 말야, 나에겐 입에 발린 말이라는 생각밖에 안들어.
각자가 자신이 할 수 있는 일을 죽을 각오로 하고.
난 다했다. 다음은 네 차례다, 못하면 죽여버릴꺼야!
라고 말할 정도의 기합이 있고서야 비로써 팀웍이라는게 형성되는게 아닐까?
그렇게 생각하면 우리는 각자 한 마리 외로운 늑대들이라고 해도 괜찮지 않을까?
-원피스, 조로와 쵸파의 대화 중

약속드리는 것:

자율 근무시간, 외국기업 수준의 연봉과 두근거릴 정도의 스톡옵션, 이런건 너무 기본적이어서 자랑조차 하지 않습니다. (다들 하는거라)

진정한 성장이 무엇인지 보여드리겠습니다.

딱 1년만 저희와 함께 21개국에 돌아가는 글로벌 서비스를 설계하고, 수 백만 달러어치의 마이크로 트랜잭션을 관리하며, 동시에 분기별로 프레임워크를 갈아엎어 보시죠. 이력서에 누구도 태클 걸지 못할 다섯 줄을 박아드리겠습니다.

넓은 글로벌 시장에서 돗단배라고 무시받더라도
함께 ‘위대한 항로’를 개척해 갈 진정한 해커들의 문화로 여러분을 초대합니다. =D

recruit@adby.me

(위 이메일 주소로 간단한 이력위주의 레주메를 보내주시면 연락드리겠습니다)

자주 물으시는 질문들: (이 밖에도 회사 생활이나 채용 절차에 대해 궁금하신 점이 있으면 @CuriousPaul 로 멘션 주세요, 확인 후 답변 드리겠습니다)

• Q: 거기 광고회사 아닌가염?
• A: 아닙니다. 소셜 미디어 플랫폼 개발 회사입니다.
• Q: 경력이 좀 있는데, 스타트업에 지원하기가 부담스럽습니다. 불안정하지 않을까요?
• A: 불안정합니다. 실패하는게 두려우시다면, 지원하지 않는 것을 추천드립니다. 위에 언급한 각오라는 마인드셋 때문에 어차피 좋은 결과를 보기 어렵습니다.
• Q: 외국 회사처럼 보이던데, 스피킹 못해도 되나요?
• A: 네, 우리나라말 잘하시면 문제 없습니다. 글로벌 전략의 이유로 미국에 본사를 두었지만, 개발부서는 모두 한국어를 잘 하는 분들이니 의사소통에 문제가 전혀 없을 것으로 보입니다. (한국 오피스는 삼성역에 있습니다)

개발 회사의 문화란 어떻게 만들어지는 걸까?

며칠전 회사 내부에서 돌았던 페이스북(이하 페북)의 감동적인 엔지니어 하이어링 스토리를 읽으며 혀를 내둘렀었는데, 문득 지난 번 페이스북 놀러갔을 때 초창기 엔지니어 중 한 명이었던 D군에게 들었던 내용 중에 정말 인상 적이었던 것이 있어 끄적끄적.

먼저 위 링크의 세줄 요약 버전:

1. 페북이 초창기에 한창 하이어링에 힘겨워 할 때 저커버그가 아이디어를 냄.
2. 원하는 엔지니어의 스킬을 타게팅하고 근처 스탠포드 대학의 강의록을 분석,
   해당 강의록의 필수독서목록을 파악함.
3. 필수 도서들을 스탠포드 도서관에서 찾아, 책 사이에 페이스북 소개와 구인 메모를 꼽아놓음.
   (물론 ROI 얘기는 없음)

페북을 처음 방문했을 때 받은 느낌은 인테리어에서부터 여긴 정말 해커들의 천국이구나라는 느낌이었다. 초기 구글이 갖고 있던 엔지니어 중심의 환경인데 (약간 Hacker Dojo 같은) 조직이 커짐에도 그걸 지키려고 고투하고 있다는 인상을 받았다. 특히 만나는 엔지니어들마다 스스로 자신의 회사는 정말 개발 중심 회사고 엔지니어를 존중한다는 점에 자부심을 갖고 있다라고 말해 고민을 하게 만들었고, 이에 관해 많은 대화를 나누었다.

페이스북 본사 전경, 바닥에 HACK이라는 표어 그리고 옥상에 QR 코드를 칠해 놓은 점이 특징이다.

예로 들려줬던 스토리 중 하나가 바로 소개할 HR 담당자와의 혈투? 이야기:

한창 페북이 성장하던 초창기 시기 (아마도 더 크게 성장해야한다는 경영 전략하에) 높은 직급의 HR 담당을 모셔왔단다.  대기업에서 진두지휘하던 정말 뛰어나신 이 분이 오자마자 했던 것은 조직 개편, 출퇴근 시간 정리, 성과 관리 등 대부분 성장한 기업들이 갖고 있는 어떻게보면 너무나도 당연한 디시플린에 대한 조치들이었고, 당연히 반발은 심했다고 한다.

페북 초창기에는 정말 코딩실력 하나로만 엔지니어를 뽑았고, 그중 디시플린 문제가 심한 개발자 중에는 한 달 동안 회사에 안나오다가 하루 출근해서 다른 이들이 끙끙 앓던 문제를 다 해결해버리고 다시 사라지는 그런 관리안되는 슈퍼코더들도 꽤 많았다니 대충 상상이 간다.

2달 정도 그렇게 진통이 있다가 페북의 사내 커뮤니케이션 행사에서 개발자들이 자신들의 불만과 개발 중심 회사의 문화가 변질되어가는 것에 대해 공개적으로 문제를 제기하여 진지한 토론을 하게 되었고, 이 상황을 조용히 바라본 저커버그는  쿨하게 결정을 내렸다고 한다. (바로 다음 주에 이 분이 회사를 떠나는 것으로)

물론 해석에 따라 논란이 많을 수 있는 스토리이지만, 내가 만난 페북 엔지니어들은 이 사건을 약간 민주화 운동같은 느낌으로 기억하고 있고 아직도 자랑스럽게 여긴다는게 포인트. 즉, 개발자 중심으로 회사의 운영을 결정한다는 그들만의 조직문화가 있다는 점이다.

내가 난생 처음 스타트업을 하고, 동료들과 함께 ‘우리가 협업하는 문화’를 만들고, 실패하며 배우는 것은:

조직의 문화란 그 구성원들이 스스로 하는 성찰의 정도에 따라 만들어지고, 변화해야한다는 것이다.

일반 조직에서 문화가 새롭게 도입되는 나쁜 예를 들어 보자:

• 경영진 중 한 명이 어느 대표들 네트워킹 모임에 나가서 ‘그 쪽은 요즘 어떻게 해?’라고 물어본다.
• ‘뭐? 서로 영어 이름 부르니까 수평적이 되고, 제안들이 많아졌다고?’ 바로 이거로군! 이라고 마음속으로 결정한다.
• 주간 미팅에 모든 직원들을 불러놓고, 오늘부터 우리는 대리님, 과장님 안부르고 영어 이름 부릅니다. 영어 이름 없는 사람들은 오늘 퇴근 전까지 정하세요!라고 통보한다.
• 직원들은 왜 이런 규칙이 생기는지, 또한 어떤 여파가 있을지 시뮬레이션 하지 못한 채 다음 날부터 어색하게 서로 영어 이름을 쭈볏쭈볏 부르기 시작한다. 이 규칙은 모멘텀을 결국 넘기지 못하고 사라지거나, 혹은 경영진이 참석하는 회의에서만 영어 이름을 부르게 되는 변종 문화로 자리잡게 된다.

위와 같은 사고로 결정하는 리더십이라면 건강한 조직 문화를 만들어 내기 힘들다는 것을 배웠다.
바로 본인 자신이 문제라는 것을 인지하지 못하기 때문이다. 정작 내 입으로는 직원들이 더욱 자발적인 참여를 하길 원한다고 하면서 새로운 모델, 방법론을 발견하면 마치 폭탄 던지듯 이대로 해봐!라고 투여하는 상황에서 자발성이란 이미 제로이기 때문이다.

성공적으로 조직 문화를 개발하고 성장시키는 방법이란 사실 너무나도 어려운 주제인 것 같다.
하지만 개인적으로 도움을 크게 얻었던 지침들을 정리해보자면 다음과 같다:

1. 다른 회사의 문화를 듣고 그대로 도입해야겠다는 생각은 애초에 버리는 것이 좋다.
   왜냐면 표면으로 드러난 방법들은 그 조직의 고민과 구성원의 성숙도와 가치관을 함축하여 보여주기 때문이다. 설마 그 방법들이 지켜지더라도 진정 뿌리내린 문화가 아닌 카고이즘(Cargoism) 과 같은, 형태만 남게되는 경우를 자주 경험했다. 결국 구성원 모두가 조직의 문제들에 대해 고민하고, 해결하기 위한 규칙들을 만드는데 충분한 시간을 써야한다. 고로 가장 좋은 조직 문화는 바로 조직 문화 자체에 대한 구성원들의 진지함이다.
   

   19세기 이래로 멜라네시아 지역에서는 유럽적 상품의 대량 공급에 대한 기대를 표현하는 신앙 형태인 카고이즘이 발생했다. 이들은 자신들이 필요했던 일상 용품을 가져다 줬던 선교사, 상인들을 토속신이 보낸 사자들이라 믿고 그들이 타고 온 비행기와 사용했던 무전기들의 형상을 그대로 나무 등으로 만들어 따라하며 풍요를 비는 제사를 지냈다.

2. 한 사람의 니즈에서부터 시작하는 것이 잘못된 것은 아니다.
   기왕이면 모두가 공감할 수 있는 사건 중심의 문제로부터 시작하는 것이 바람직하지만
   “저는 우리 회사 문화가 더욱 소통이 편해지고, 건강한 비평을 하는 문화로 변했으면 좋겠어요” 와 같이
   한 명일지라도 그 욕구가 충분히 진솔하다면 많은 동료들이 공명을 해준다는 것을 자주 보았다.만약 리더 입장에서 어떻게 시작해야 할지 모르겠다면, 우리에겐 언제나 ‘질문’이라는 좋은 도구가 있다는 것을 잊지 말자. 느끼하지만 “우리가 더욱 수평적인 커뮤니케이션을 하려면 어떻게 하면 좋을까요?”와 같은 멘트들을 던질 수 있다.
3. 왼손은 거들 뿐. 그러나 왼손은 중요하다.
   조직 문화에 있어서 결정하고 실행하는 것은 결국 구성원들의 몫이다. 스스로 일깨움을 얻고,  자신들의 결정을 통해 배우고 성장하도록 하는 것이 가장 건강한 방법이다라는 점을 인정해야 한다.특히 적용도(adaptation)에 대해서 조급해 하지 말고 구성원들에 대한 신뢰와 여유를 갖고 지켜보는 것, 무엇보다 자신 스스로 행동으로써 보여주는 것 (lead by doing)이 필수적이다. 또한 결국 변화의 문제이기 때문에 적절한 시점에서의 자극과 외부 통찰, 회고 등을 할 수 있도록 버퍼 설정과 변수조절을 하는 것이 리더의 몫이다.
   

   사티어의 변화 모델: 변화가 도입되었을 때 새로운 Status Quo에 정착하기 전까지 거치게 되는 저항, 혼란 등의 과정을 설명한다.

실리콘 밸리 창업 연수 프로그램을 소개합니다.

% 연수 프로그램을 후원하고 있는 쪽에서, 사정이 생겨 마감을 앞당기기로 했다고 합니다. 요청 자료들은 27일까지 제출하시더라도 온라인 접수는 22일 (목요일) 저녁 10시까지 신청하셔야만 인정된다고 합니다. 신청하실 분들은 서두르셔야 할 것 같습니다.

 

Younoodle Korea Incubation Pilot Program 은 어떤 프로그램인가요?

[지원하러 가기] 

혹시 Younoodle 창업캠프에 대해 처음 들어보시는 분이라면, 먼저 제가 올 여름에 참석했던 Younoodle 창업가 여름캠프에 대한 estima7님의 소개글을 참고하시면 좋습니다.

제가 참석했던 프로그램을 기준으로 설명드리면 크게 세 분류로 커리큘럼이 진행되었습니다. (물론 그 사이 업그레이드가 있었을 것 같습니다)

1. 스탠포드, USF, MIT 교수님들의 직접 강연.
2. 팀 프로젝트
3. 네트워킹 및 기업탐방

아침에 일어나서 3시간 동안 강연을 듣고, 오후에는 팀 별 프로젝트를 했습니다. 그리고 저녁에는 각종 실리콘 밸리 네트워킹 행사에 참석을 했습니다. 실리콘밸리 창업가들과 열심히 네트워킹 파티를 하고 다음날에는 휴식겸 회사 탐방을 돌아다녔습니다. (구글, 트위터, 스퀘어 등) 이런식으로 3주간 진행이 되었습니다. (주말엔 주로 소개 받은 인맥들을 만나거나, 관광을 했습니다)

마지막 날에는 실제 실리콘 밸리 VC들 앞에서 작업한 팀 프로젝트를 피칭을 하면서 마무리를 지었습니다.이 과정에서 앤젤 투자자들에게 투자를 받은 팀도 있었고, 3주 만에 팀을 꾸려서 지금 회사를 차린 분들도 있습니다.

제가 종합적으로 이 프로그램을 통해 얻은 것은:

• 실리콘 밸리 스타트업에 대한 교육으로 인해, 처음 해보는 글로벌 스타트업에 대한 막연함을 해소할 수 있었고,
• 뛰어난 현역 자문위원들을 소개받고 자문 계약을 하게됨으로써 많은 인맥의 허브를 얻게 되었습니다.

언제, 어디서 하나요?

연수는 미국 실리콘밸리 (샌프란시스코 및 베이 지역)에서 진행됩니다.

10월 – 11월 사이에 3주간의 집중 교육이 진행되고, 파이널 팀에 선정되시면 PnP 같은 미국 정통 스타트업 인큐베이터에게 3개월 동안 지원을 받는 기회도 주어집니다.

지원은 어떻게 하나요?

먼저 온라인 지원을 하시고,  [지원하러 가기]  10월 14일에 국내에서 심사위원들을 대상으로 피칭을 합니다.

지원 자격은, 미국 진출을 원하시는 국내 창업자(혹은 예비 창업자)이면 누구나 지원 하실 수 있습니다.

제출 서류는 아래와 같습니다.

• 사업소개서 (국문/영문)
• 서비스 소개 PPT (국문/영문)
• 팀 소개서 (국문/영문)

왜 하나요?

본 프로그램은 한국의 창업 혹은 예비창업 팀 중, 미국 진출을 원하는 팀들에게 실리콘 밸리식 스타트업 모델을 집중 코칭하여 성공적인 글로벌 스타트업으로서의 기회를 제공하고자, 중소기업청(SMBA)과 창업 진흥원(KISED)이 함께 지원을 하는 사업입니다.

제 개인적인 의견으로는, 중기청과 창업진흥원의 올해 전략 중 하나가, 뛰어난 스타트업팀들로 하여금 글로벌 비즈니스를 하도록 지원을 한다는 것으로 알고 있는데 이러한 사업을 연속적으로 열게됨으로써 한국 스타트업들로 하여금 미국 시장에 대한 이해, 산업에 대한 시각, 인맥 등을 얻을 기회를 제공할 듯 합니다.

누가 참석하면 좋나요?

글로벌 스타트업을 계획중이신 분이라면, 매우 좋은 기회라고 생각됩니다. 특히 미국 실리콘 밸리에서 사업을 하실 분인데, 한 번도 가본적이 없다. 이런 분께는 절호의 기회입니다.

당장 돌아가는 프로토타입이 있고, 팀이 있으신 경우 바로 엔젤 펀딩으로 이어질 수 있는 기회이기 때문에 신청하시길 추천드립니다. 저희같은 경우는, 한 번 만나고 1백만 달러 수표를 써주겠다고 제안한 엔젤 분들도 있었습니다.

즉, 진짜 하실 분들께는 꼭 신청하시라고 추천드리고 싶습니다.

반대로 그냥 지식을 늘리는 정도로 배우러 가시는 분께는 비교적 큰 도움이 안될 것 같습니다. 결국엔 3주 동안 진짜로 하러 오시는 분들 사이에서 설 곳을 못 찾다가, 샌프란 관광만 하시고 돌아가게 되실 겁니다.

혹시 제가 올린 글을 읽고 지원 하신 분이 계시고, 또 도움이 필요하시다면 연락주세요. 최대한 돕겠습니다.

트위터 @CuriousPaul

Younoodle Korea Incubation Pilot Program

자주 묻는 질문들

• Q: 영어가 (..)
• A: 네. 영어가 아마도 가장 큰 관건일 듯 합니다. 리딩/리스닝 뿐만 아니라, 실제로 스피킹도 요구되기 때문입니다. 하지만 다행이도? 이번 연수자들은 전원이 한국분들이라고 하니, 생활에서의 어려움은 없으실 듯 합니다.
• Q: 가서 새로 팀을 짜는 경우도 있나요?
• A: 가능한 시나리오입니다. 하지만 기본적인 컨셉은, 제품/팀 둘 중 하나는 있어야 지원하실 수 있습니다.
• Q: 비용은 어떻게 되나요?
• A: 아직 확정이 덜 된 부분이긴 하지만, 현재까지 알려진바로는 전액 지원입니다. (용돈 정도는 챙기셔야겠죠)