스타트업 가이드2015.09.08 14:04

스타트업의 개발 환경은 조직과 환경의 특성상 일반 개발 조직과 많이 다르다. 보다 민첩해야하고 자기주도적이여야 하며 낭비를 최소화 해야 한다. 이런 부분에서 개발팀에서 많이 하게 되는 공통적인 실수들을 많이 보게 되는데 미리 알아두면 좋을 5가지 전략을 공유해 본다.


1. Trend와 Right Tech를 구분하는 것


개발팀을 꾸릴때 가장 먼저 하게 되는 것이 어떤 기술 스택을 이용해서 개발을 해야 되는지 고민하는 경우가 많다. 손에 잘 맞는 도구가 있을 것이고 한번 잡아보고 싶은 도구도 있을 것이다. 손에 맞든 맞지 않든 좋은 트렌디한 기술들은 개발자들을 영입할 때 좋은 당근이 당연하기 때문에 달콤하다. 하지만 이때 과도한 기술 트렌드의 유혹을 이기지 못하고 여러 트렌디한 기술들을 무차별하게 도입한 뒤에 예상치 못한 문제들에 대응하게 되는 것을 많이 보게 된다. 왜냐하면 그 기술 트렌드에서 부각되지 않은 단점들을 많이 생각해보지 못한 경우 때문에 그렇다.


대부분의 테크 트렌드는 기존의 개발문제나 기술문제를 해결하고 더 좋은 퍼포먼스를 제공한다. 하지만 여기서 생각해볼 부분이 그 기술문제를 해결하는 방법이 기존의 어떤것을 포기하고 장점을 취하는 즉, 트레이드 오프의 형태로 대안을 찾아 간다는 부분이다. 예를 들어, 요즘 많이 사용하는 flask라던가 node.js와 같은 마이크로 웹 프레임워크 같은 것들은 빠른 성능을 제공하는 대신 안정성은 개발자들의 몫으로 돌리는 것과 같은 이야기다.


즉, 이런 형태의 기술 트렌드들은 대부분 더 좋은 퍼포먼스와 해결점에만 초점을 맞출 뿐 그것을 통해서 잃게 되는 단점 부분에 대해서는 초점을 맞추지 않고 있다. 때문에 개발자들이 그 기술의 명과 암을 정확하게 읽어내기 어려운 부분이 있다.


다른 예를 들어 보자면 RDB 대신 NOSQL을 선택한 경우이다. 빠른 엑세스 속도를 제공하는 대신에 안정성 부분과 데이터들끼리의 릴레이션 관리에 대해서는 개발자들이 해야하는 일들이 더 늘어날 수 있다. 그리고 만약 데이터의 관계 구조가 복잡하다면 Json을 이용한 쿼리문 작성은 어마어마하게 늘어날 수 있다는 것을 감안해야 한다.

즉, 어떤 새로운 기술을 도입하기 전에 이 기술이 어떤문제를 해결하였고 반면에 어떤 부분을 희생하게 되었는지 단점을 중심으로 먼저 살펴보아야 한다. 
어떤 부분에서 장점이 될 수 있고 어떤 단점이 있을지를 명확하게 분석해서 접근하는 노력이 필요하다는 이야기다. 


이렇게 트레이드오프 형태의 기술들이라면 어느정도 보안하면서 여차저차 끌고갈 수는 있다. 물론, 안정성에서는 많은 시행착오를 거칠 것이라고 하더라도 말이다. 하지만 더 큰 리스크는 전혀 새로운 형태의 기술 트렌드를 따르는 것이다. 예를들어 HTML5를 통하여 하이브리드 앱을 만든다거나 메신저와 같은 하이테크 앱을 개발하는데 있어서 티타늄이나 자마린 같은 도구를 쓴다거나와 같은 결정이다.

이런 형태의 기술들은 다시 돌이키기 어려운 결과를 가져오게 된다. 페이스북이 모바일 앱에서 고전했던 흑역사도 너무 이른 타이밍에 HTML5를 도입하여 하이브리드 앱을 만든 것에 있었다. 페이스북이 네이티브 앱을 발표하면서 모바일 매출의 증가속도가 2배나 늘어나는 것을 볼 수 있었다. 말은 그럴싸하겠지만 어떤 제품을 개발하는데 있어서 지름길은 존재하지 않는다. 단지 타협이 존재할 뿐이다. 우리의 기술 목표와 잘 부합하느냐에 따라서 더 필요한 강점을 찾을 수 있는 기술을 선정하고 또 그 기술의 단점을 어떻게 매울 수 있을지를 구분해 낼 수 있는 안목을 기르거나 많은 사람들을 만나서 그 경험을 들을 필요가 있다. 

[HTML5로 개발되었던 페이스북 하이브리드 앱]


여기서 할 수 있는 질문이 리서치를 해보니 적합한 도구 같은데 내가 사용하기에는 낯선 도구라면 어떻게 해야할까? 일텐데, 이것은 개인 역량에 달렸다. 보통 senior 레벨의 개발자들이라면 도구를 바꾸는데 있어서 큰 거부감이 없을 것이지만 개인의 역량에 따라서 시간이 많이 걸릴수도 있고 어려울수도 있다. 필자의 주관은 뛰어난 개발자들로 꾸려진 팀이라면 낯선 도구의 거부감이나 두려움은 많지 않다고 생각한다.



2. 로드맵보다는 사람이 중요하다.


팀이 꾸려지기 전에 로드맵을 만드는 것은 굉장히 신중하게 생각해봐야 할 문제이다. 잘못된 선택을 할 수 있는 리스크가 커지기 때문이다. 만약 그 전에 로드맵을 만들어도 적절한 사람을 찾지 못할 경우에 대한 로드맵도 따로 준비하는 것이 중요하다. 예를 들어 개발 로드맵이 확정된 상황에서는 대부분 개발팀을 뽑아야 할 데드라인이 형성된다. 하지만 그 데드라인은 결국 원했던 사람이 아닌 그저 그랬던 멤버와도 타협을 야기하게 된다.


여기서 최악의 경우가 발생할 수 있는데 그렇게 뽑은 사람의 퍼포먼스가 생각보다 나오지 않아서 다시금 채용을 하게 되는 경우이다. 스타트업에서는 팀을 최소화 하여 원하는 퍼포먼스를 정확한 방향으로 끌고가야 한다. 하지만 팀이 늘어나게 되면 그만큼 버틸 수 있는 맺집이 약해지게 되고 더불어 의사결정이 더딜 수 있고 마지막으로 관리라는 보이지 않는 리소스가 추가되게 된다. 즉, 사람을 뽑음으로서 그 사람의 100% 리소스를 쓰는것과 더불어 그 사람과 커뮤니케이션하고 관리를 하기 위한 한 사람의 10-30%의 리소스를 포기해야 되는 것이다. 주니어 레벨일수록 관리자의 리소스를 더 많이 필요하기 때문에 시니어 레벨에서도 충분히 할 수 있는 일이라면 최대한 시니어 레벨을 뽑는것이 좋다.


그럼 어떻게 내가 원하는 사람을 효율적으로 영입할 수 있을까? 초기 단계의 스타트업에서는 발품을 파는 수밖에 없다. 사람을 물어물어 어떻게든 좋은 사람을 수소문해내고 찾아가서 비전을 보여주고 원하는 것을 제시해야 한다. 초기 단계라면 아이디어와 팀원을 보게 된다. 적어도 내가 믿고 따를 리더나 동업자들이 적어도 같은 수준이 되냐라는 것이다. 그들이 생각한 아이디어에 호응을 얻어서 조인하는 경우는 많지 않다. 그 대상이 되는 정확한 고객이거나 같은 비지니스 도메인에 있으면서 자기가 생각했던 불편함들과 일치할 확률이 극히 드물기 때문이다. 만약 구인광고를 하게 되면 아이디어와 제품과 더불어 어떤 사람들이 모여있는지 어필해줄 필요가 있다.


스타트업 프로토타입이 만들어 지고 A/B 시리즈를 받아서 팀을 확충해야 하는 경우라면 좋은 기술스택과 회사의 비전 그리고 개발자들이 좋아할만한 혜택들을 얹어서 홍보를 한다면 채용은 조금 수월해진다. 이때 좋은 사람을 찾아야 하는데 아마 좋은 기술력과 팀에 잘 녹아들 수 있는 인성을 가진 사람이 원하는 인재일 것이다. 그 사람이 스킬풀한지에 대한 고민은 기술에 대한 열정과 코딩테스트를 통해서 충분히 고민해볼 수 있기 때문에 어렵지 않다. 하지만 인성은 같이 일해본 경험이 없다면 고민이 될 수 밖에 없다. 이것을 검증하기 위해서 많은 기업들이 내부추천제도를 통해서만 채용하는 경우도 있고 어떤 회사는 면접에서 악역을 만들어서 어떻게 반응하는지 보는 경우도 있다. 


필자가 해외에서 개발팀을 꾸렸을 때는 인성부분을 크게 걱정하지 않아도 됐다. 외국에서는 일하기 전에 경력이든 신입이든 프로베이션 기간을 가지는 것이 일반화 되어 있기 때문이다. 보통 프로베이션 기간 동안에는 채용 후보자의 인성과 팀원들과 어울리는 모습을 2달 정도 지켜보게 된다. 그리고 그 기간 이후에 본인도 원하고 회사가 원한다면 그때 정식으로 같이 일을 하는 옵션으로 진행하게 된다. 


국내에서는 이 기간을 수습기간이라는 제도로 오해하게 되면서 많은 사람들이 꺼려하는 경우가 있기는 하다. 그래도 국내의 여러 스타트업들에서 많이 도입하고 있는 것으로 알고 있다. 만약 후보자가 정말 이 회사에 뜻이 있고 자신의 인성이 떳떳하다면 솔직히 이 기간을 망설일 이유가 없을 것이다. 더군다나 안정을 원하는 사람이라면 스타트업을 선택하는 이유가 없기 때문에 크게 걱정하지 않고 도입해보는 것을 추천한다.


마지막으로 똑똑한 싸가지 때문에 고생하고 있는 스타트업이 있다고 한다면 필자가 생각하는 방법은 한가지 밖에 없다. 우정으로 그를 설득시키거나 뜻을 전달하는 방법밖에 없다. 논리적으로 누군가를 설득한다는 것은 한국 사람들에게는 많이 어렵다. 토론문화 없이 주입식 교육으로 자라왔고, 토론이 맞는 것을 같이 찾는 과정이라기 보다는 서로 자신의 논리가 맞다고 서로 주장하는 시간으로의 인식이 아직도 팽배하기 때문이다. 


더군다가 스타트업에서는 데이터나 숫자가 아닌 개인의 역량과 판단 지표로 결정을 내려야 하는 경우가 많은데 이 인사이트가 모두를 만족시킬 수는 없다. 이 때 만약 똑똑한 싸가지와 방향이 다르다면 불만을 토로하며 분위기와 사기를 저해하는 경우가 많다. 이런 불만이 있을것 같은 상황을 항상 주시하다가 우정으로 먼저 다가가서 그를 설득시켜야 한다는 것이 그들을 다루는데 핵심이다.








3. 핵심기술 외에는 관대해져라.


애자일의 한 개발방법론으로 스타트업에서 많이 채용하고 있는 철학 중에 하나가 바로 린(Lean) 개발 방법론이다. 이 린 방법론의 핵심은 원래 만들려고 했던것에서 1/3만 만들라고 이야기 하고 있다. 대부분의 제품은 사용자의 피드백을 받으면 그 모양이 변하기 마련이다. 그 변화를 통해서 많은 기술들이 낭비를 거듭하게 되는데 결국 그 낭비를 최소화 하기 위해서 생각한 핵심 기능만 제대로 만들어서 피드백을 받아 보자는 것이다.


핵심만 만들자는 것이 말은 쉽지만 개발자들에게는 어려운 숙제이다. 개발자들은 자신이 원하는 제품의 퀄리티와 완성도를 높이기 위한 관습이 그들도 모르게 베여있다. 때문에 작은 기능에도 완벽함을 추구하려고 할 것이다. 지금 고치지 않아도 되는 옵션 정도의 기능도 개발자들은 볼때마다 눈에 거슬려서 때로는 일의 우선순위가 그들은 다르게 생각할 수도 있다. 이 것을 조율하기 위해서는 개발자들에게 Lean 방법론에 대한 공감을 같이 얻어내는 것이 중요하다.


스타트업에서 TDD를 적용해야 하냐는 토론들을 많이 보고는 한다. 필자의 견해는 스타트업이 기술로서 완벽을 추구해야 하는 시기는 적어도 A/B 시리즈 투자를 받고 기술을 통해서 비지니스의 퍼포먼스를 내줘야 하는 시기라고 생각한다. 초기에는 완벽하게 1개의 제품을 만드는 것보다는 2-3개의 제품을 MVP로 만들어서 시장의 반응을 살펴 보는 것이 중요하기 때문이다. 때문에 100%의 테스트 커버리지를 스타트업 초기 단계에 작성하는 것은 바람직하지 않다. 단, 비지니스를 이루는 핵심 기술에 대해서는 시간을 투자하는 것이 맞다. 다시 말하자면, 핵심 기술이라고 생각하는 영역에 대해서는 TDD를 도입하고 자동 테스트를 만들어 두는 것이 나쁘지 않다는 것이다.


추가적으로 스타트업이 무게를 두어야 할 곳은 Front-end보다는 Back-end(서버사이드)라고 말하고 싶다. 스타트업의 핵심멤버는 반드시 백엔드 사이드를 잡고 있어야 한다. 멤버가 없어서 외주를 줘야 한다면 front-end까지는 가능할 수 있다. 프론트엔드는 자주 바뀔 수 있는 영역이다. 하지만 서버 사이드는 한번 설계하면 바꾸기가 비교적 수월하지 않고 아키텍쳐 확장에도 많은 영향을 주게 된다. 때문에 핵심 개발 멤버를 모집하려면 서버사이드 멤버가 1순위가 되어야 한다.






4. 사용자 중심의 언어로 커뮤니케이션 하라.


스타트업에서 가장 중요한 요소는 커뮤니케이션이다. 하지만 개발팀이 존재할 경우에 간혹 기획팀과 개발팀 사이에서 커뮤니케이션 문제로 제대로 호흡을 맞추지 못하는 경우를 많이 보게된다. 최악의 경우는 서로 사이가 안좋아지기까지 하는 경우이다. 개발팀은 팀내에서 개발 용어로 커뮤니케이션을 하는 것이 아닌 누구나 다 알 수 있는 공용어를 써야 한다. 


조금더 구체적인 예를들어 보자면 만약 업무의 진행상황을 볼 수 있는 보드가 있다면 이 보드에는 "DB설계", "서버셋팅" 등과 같은 개발 용어를 이용하기 보다는 기능 위주의 "feature1", "feature2"와 같은 용어가 있어야 한다는 것이다. 이런 공용어들을 통해서 개발팀 뿐만 아니라 모든 멤버가 업무의 우선순위를 정하고 팀의 진척을 파악하고 적당한 타이밍에 데모를 요청해볼 수 있는 척도를 알 수 있기 때문이다.


스타트업은 많은 시간 리서치에 시간을 투자하기가 어렵다보니 비지니스의 정확한 숫자와 데이터를 기반으로 일을 진행하기가 어렵다. 때문에 그들의 인사이트로 제품을 개발해 나가는 경우가 불가피 한데 이런 이유 때문에 방향이 충분히 틀릴 수 있고 제품의 로드맵은 언제든 즉시 수정이 가능해야 한다. 이때 이런 작업을 원할하게 도와주는 것이 사용자(고객) 중심 언어의 소통이며 팀원들끼리의 퀄리티 높은 커뮤니케이션이다. 여기서 퀄리티 높은 커뮤니케이션은 얼굴을 보면서 바로 옆에서 할 수 있는 대화이다. 이런 일들을 메일이나 내부 툴 혹은 메신저를 통해서 하는 것은 질과 민첩성을 떨어뜨리게 된다. 때문에 스타트업의 개발팀이라면 독립된 공간에서 원하는 시간에 일하기 보다는 어느정도 시간을 맞추어 다같이 한곳에 모여서 일하는 것이 가장 효율적이다라고 정의할 수 있다. 



5. 애자일의 함정에 빠지지 말아라.


마지막으로 하고 싶은 이야기는 애자일 개발 방법론의 함정을 조심해야 한다는 것이다. 결론부터 이야기 하자면 애자일의 스크럼은 개발팀이 5명채 되지 않은 작은 스타트업 조직에게는 적합한 도구가 아니다. 많은 스타트업들이 애자일 환경에서 일하는 것을 선호하고 많이 도입을 하려고 한다. 애자일을 도입한다의 올바른 의미가 XP, 스크럼, 린, FDD, 크리스탈등과 같은 도구를 도입하는 것이 아니다. 아쉽게도 많은 기업들이 그저 그런 practice들을 따라해보는 것을 애자일을 도입하는 것으로 오해하는 경우가 많다. 애자일을 도입한다는 것은 개발팀 모두가 애자일 메니페스토(http://www.agilemanifesto.org)에서 이야기 하고 있는 개발 철학을 받아드리고 있냐라는 것이다. 여러 방법론들은 자신의 조직구조와 특징과 특성을 분석한 뒤에 잘 맞는 방법론들을 이용하면 된다. 즉, 도구의 개념으로 보면되는 것이다.


예를 들어 스크럼 방법론의 경우 Epic과 같은 큰 카테고리를 생성하고 그 밑에 유저스토리 그리고 또 그 아래 task가 덧붙여지게 된다. 그리고 각 스토리마다 추정을 통하여 일의 크기를 결정하게 된다. 이런 많은 작업들을 유지하기 위해서 스크럼 마스터가 책임을 지고 개발팀과 더불어 업무들을 관리하는 것을 부여하게 된다. 하지만 개발자가 많아야 2-3명 되는 스타트업의 환경이라면 이런 프로세스 자체가 오히려 곤욕이고 퍼포먼스가 저해될 가능성이 높다.


애자일에서 이야기 하고 있는 것은 고객 중심적인 사고를 가지고 변화를 인정하면서 지속적으로 만들고 있는 결과 최대한 자주 확인하면서 대화해 나가는 것이 핵심이다. 개발자들은 기획문서를 찾고 그것을 만들면 끝나고 왜 기획서에는 그런 내용을 넣어두지 않았냐고 할것이 아니라 그런 것들도 계속 대화를 통해서 덧붙여 나가는 것이다.





(이 내용은 개인적으로 SKT 인사이더 인큐베이팅 프로그램에서 발표했던 "스타트업을 위한 기술전략"을 글로 옮겼습니다.)

저작자 표시
신고
Posted by 박경훈
스타트업 가이드2014.11.01 22:18


스타트업을 시작하는 대부분의 구성원을 보면 기존에 알고 있던 지인들 그리고 친구들과 함께 시작하는 경우가 많다. 처음 같은 목표를 가지고 서비스를 만들고 비즈니스를 만들어 가는 과정 속에서는 큰 문제를 느끼지 못한다. 하지만 시간이 흐르고 어느 정도 회사가 자신들의 문화를 정착해가는 과정 속에서는 역할의 불분명함으로 생기는 문제가 존재한다.


즉, 만약 그 회사를 대표하는 리더가 있다면 그 멤버들은 그의 최종 결정을 따라주는 팔로우쉽(followship)을 보여주어야 한다. 반대로 리더의 위치에 있으면 최종 결정을 만들고 확고한 신념을 보여주어야 한다. 이것이 스타트업을 넘어 기업으로 성장할 수 있는 가장 큰 역할이다.

역할을 분명히 나눈다는 것은 위아래의 수직적인 조직구조를 만든다고 오해해서는 안 된다. 역할 구분은 모든 분야에서 구성원 모두를 만족시키기 위한 의사결정을 피하기 위함이다. 스타트업에서 가장 안 좋은 결과가 모두의 의견을 수용하면서 서비스나 제품의 확실한 목표와 신념이 사라져가는 경우이다.


먼저 이런 역할적 분위기를 설정하기 위해서 필요한 것이 확실한 지분 관계이다. 가장 안 좋은 지분분배 구조는 지분을 초기 창업자들과 n분의 1로 설정한 경우인데 이러한 환경에서는 절대적인 역할 구분이 되지 않는다. 가장 좋은 지분 구조는 리더가 2-3번의 투자를 받고 약 40-50%가 남아있을 수 있는 정도이다.


두번째는 역할이 겹치지 않게 멤버를 구성해야 한다는 것이다. 예를 들어 초기 창업 멤버로 2명의 개발자가 합류했다고 가정하자. 이 경우에 누가 대표 책임자인지를 결정해야 한다. 아니면 각 전문분야를 나눠서 서로의 의사결정에 적어도 책임을 가지고 있어야 한다.

이 드라마에서 투자 유치를 약속 받고 나서 가장 먼저 했던 일이 지분구조를 조정하고 역할을 명확하게 정의하는 것이었다. 모든 초기 창업자들은 그 회사 대표 리처드의 친한 친구로서 합류했던 그 멤버를 과감하게 정리해야 한다고 이야기 하면서 갈등이 시작된다.

이 드라마에서는 그 리처드의 절친이 스스로 회사를 포기하고 굉장히 좋은 조건의 회사로 옮기면서 어떤 결정을 내려야 하는지에 대한 메시지는 던지지는 않았다. 하지만 갈등의 모습을 통해서 문제가 될 수 있는 부분을 충분히 시사해주고 있다. 때문에 어떤 사업을 시작하기 전에 한 명의 멤버를 모으는데 있어서 굉장히 신중해야 할 필요가 있는 것이다. 그럼 드라마의 몇 장면을 살펴보도록 하자.



















저작자 표시
신고
Posted by 박경훈
스타트업 가이드2014.10.25 20:03

지난 번 컬럼에서 실리콘밸리 라는 드라마를 통해서 배울 수 있는 기업 문화에 대해서 살펴 보았다. 스타트업 문화를 형성하는 부분에서 가질 수 있는 오해를 줄이기 위한 내용이었다. 이번에는 혁신과 상품에 대해서 잘못가질 수 있는 오해에 대한 이야기를 풀어보고자 한다.

사람들은 세계의 몇천 만분의 일의 확률에서 나오는 성공 스토리들을 접하면서 그들이 단순히 좋은 아이디어와 타이밍으로 그것을 평가하는 경향이 있다. 하지만 아무리 좋은 아이디어가 있더라도 그것을 비지니스에서 성공으로 이어지게 하기 위해서 보이지 않는 많은 노력들이 필요하다. 이 드라마 또한 초기에 던지고자 하는 메시지가 바로 아무리 혁신적인 제품이 있다고 하더라도 그것이 성공을 보장할 수는 없다는 것이다.

주인공 리차드(Richard)는 오디오 압축 기술에 대한 아이디어를 가지고 있는 소박하고 부끄러움이 많은 청년이었다. 그 아이디어는 초기에 인정을 받지만 회사의 목표와 비전을 세워가는 과정이 결코 간단하지 않음을 묘사하고 있다. 친구로 같이 시작한 관계를 비즈니스 입장에서 명확하게 정의해야 했을뿐더러 생각해보지도 못했던 비즈니스 플랜과 목표에 대해서 보다 깊게 고민해 봐야만 했다.

더욱이 중요한 것은 그 압축기술을 밝히기 위해서 경쟁사에서 열심히 연구하는 모습을 비추고 있다는 것이다. 무엇보다도 그 애플리케이션을 리버스 엔지니어링(Reverse Engineering)을 통해서 벗겨내려는 모습이 굉장히 인상적이었다. 즉, 아이디어나 핵심 기술이 언제나 성공을 보장하지 않는다는 것을 보여주지 않는 장면이다.

리차드만 그랬을까? 사업을 시작하는 대부분의 사람들이 좋은제품과 좋은상품을 만들면 사람들이 저절로 사람들이 줄을 서서 이용할 것이라는 기대가 있을 수도 있다. 그래서 그 기대로 오직 제품 개발에만 집중할지도 모른다. 하지만 우리가 눈에 보이는 성공스토리들만 벤치마킹 해서는 결코 성공을 이룰 수 없다. 우리는 그 성공 뒤에 있었던 적절한 요소들을 살펴봐야 한다. 그 상품 혹은 서비스를 어떻게 마케팅하고 유통하려 노력했고 또 적절한 시기에 요구도는 리소스들을 어떻게 확보하였냐는 것이다.

비즈니스에 있어서 성공은 좋은 아이디어 외에도 다음과 같은 다섯 가지 요소들이 뒷받침 되어야 한다.


구성원
- 조직의 역할이 명확하게 분배 된 구성원들이 필요하다.

목표
- 조직의 구성원들이 일할 수 있는 이유이자 회사 존재의 이유로 고객들에게 어떤 가치를 전달하게 할 수 있을지에 대한 목표이다.

문화
- 조직내의 구성원들이 목표를 수행하기 위한 행동 전략이 목표에 맞추어 잘 셋업 될 필요가 있다. 

리소스
- 구성원들의 삶을 영위할 수 있게 하고 또 비즈니스에서 필요한 자금이다. 처음 리소스가 넉넉하지 않으면 구성원들의 지구력 또한 길지 않을 것이다.

고객
- 고객은 회사 비즈니스에 기꺼이 돈을 지불할 수 있는 사람들을 말한다. 즉, 이 말은 조직의 서비스가 가치가 있다고 느끼는 사람들인 것이다.


다음 장면은 리차드가 가지고 있는 좋은 알고리즘은 하나의 상품일뿐더러 그 상품이 아닌 회사에 투자한다는 뜻을 정확하게 전달하고 있다.






저작자 표시
신고
Posted by 박경훈
스타트업 가이드2014.10.20 13:07

개인적으로 벤처스퀘어에 기고한 글입니다.


얼마전에 좋은 드라마를 찾아서 하루하루 시간 가는 줄 모르고 감상하고 있다. 무엇보다도 IT 개발자 출신으로 창업에 도전한 사람이라면 정말 큰 공감을 얻을 수 있을 것이라고 생각이 드는데. 처음 투자를 받아서 회사를 세워가는 이야기를 드라마로 그리고 있다. 2014년도 상반기에 이 드라마가 발표된 뒤로 미국 현지내에 굉장한 인기가 대단했는데 그 인기로 가상 기업 홈페이지가 만들어 지기도 했다. http://www.piedpiper.com





드라마 속의 코미디 요소들이 많아서 가볍게 볼 수 있는 요소들이 많지만 그 안에서 전하고자 하는 메세지가 스타트업으로서 한번쯤은 고민해봐야할 내용들이 많았었기에 한가지씩 정리해서 전달해 보고자 한다. 

먼저 살펴 볼 것은 자유로운 기업 문화와 그 효율에 대한 이야기를 해보고자 한다. 처음 창업을 하거나 안정적인 회사를 박차고 나와 스타트업에 참여한 많은 멤버들이 아마도 딱딱한 기업문화를 떠나 자유롭고 효율적인 문화를 기대할 것이다.

실제로 국내의 대기업이 굉장히 딱딱한 문화를 형성하게 될 수밖에 없는 것이 효율보다 조직내의 공정성과 형편성을 유지해야 된다는 철학에 근거했기 때문이다. 즉, 국민 의식이 충분하지 못했던 시기에 만들어진 체계를 기반으로 그 기업들이 지탱되어져 온 그 철학 말이다. 그런 면과 비교해 볼 때 스타트업은 신뢰를 기반으로 다양한 기업 문화를 형성해 나가는 것이 가능하다.  

하지만 처음 스타트업을 하면서 가장 많이 하게 되는 실수가 자유로운 문화를 도입한다는 것을 각 멤버들이 혹은 팀들이 자신이 하고 싶은대로 하고 싶은 것으로 종종 오해한다는 것이다. 필자도 처음 스타트업을 진행할 때 멤버들간의 문제가 있었는데 자신이 원하는 곳에서 원하는 시간에 일하겠다는 것이었다. 즉, 신뢰를 바탕으로 한다는 것에는 동의가 있었지만 개인 프로젝트가 아닌 일을 진행하는데 있어서 커뮤니케이션에 있어서 능률과 효율이 떨어지기 때문에 그 시기에 도입할수 있는 기업문화는 아니었다.

다시 정리해서 스타트업은 자유로운 기업문화를 도입할 수 있다라는 것을 이렇게 잘못 오해하는 경우가 많다. 스타트업의 특권은 원하는 문화를 자유롭게 도입하는 것이 아닌 기존에 신뢰를 바탕으로 자유로울 수 없었던 관습에서 벗어나 신로를 바탕으로한 체계와 문화들을 정립해 나가는 것에 있다.

역시 이 드라마에서도 체계와 일의 효율에 대해서 재미있게 묘사되고 있었다. 그 내용을 스틸 컷으로 살펴보도록 하자. 먼저 혼자해도 될 일을 둘 다 처리해버린 두 개발자의 커뮤니케이션 문제를 묘사하고 있다. 



두 개발자간의 커뮤니케이션 문제로 시작된 일의 비효율을 해결하기 위해서 재러드가 회사 문화를 제안한다.


그리고 그 설득으로 스크럼을 도입하게 된다.





스타트업도 그들만의 룰과 체계가 필요하다. 기존의 관슴에서 벗어나 신뢰를 바탕으로 한 자유로운 기업문화를 상상해보자. 그리고 그것을 하나하나 조율하며 적용해 나간다는 그 기업만의 문화가 형성될 수 있을 것이다.

저작자 표시
신고
Posted by 박경훈
스타트업 가이드2014.09.23 03:22

필자는 지난 5년 동안 스타트업 업계에서 활동하면서 많은 테크니컬 결정들을 내려왔고 또한 그런 결정들의 갈림길에서 고민하는 기업인들을 많이 만나왔다. 스타트업이 유지되고 또 발전해 나가는데 있어서 가장 중요한 요소는 명확한 회사의 비전과 그 회사를 형성하고 있는 문화일 것이다.


실리콘밸리의 많은 스타트업들은 자신들만의 독특한 문화를 가지고 회사를 만들어 가는 것을 많이 보게 된다. 그렇다면 그 문화를 만들어 가는데 있어서 가장 중요한 역할을 하는 것은 무엇일까? 다른 요소들보다도 그 회사가 선택한 기술 스택이 아무래도 개발 문화에 큰 영향을 주게 된다는 것은 부정하기 어렵다.

새로운 스타트업이 J2EE/Oracle, Perl, PHP, Rails, Node.js, .NET 중에 회사의 주 기술을 선택하게 되면 그 팀의 엔지니어들은 각 플랫폼 별로 다른 기대를 가지게 되고 또 다른 가치와 개념을 무의식 중에 품게 된다. 즉, 이러한 기술들 중에서 어떤 기술이 나쁘다고 우리는 이야기 할 수 없지만 그들은 다른 문화를 가지게 되는 것은 사실이다.


몇 년 전에 필자는 런던에서 열린 스타트업 기술 컨퍼런스를 참석하게 되었는데 굉장히 많은 기업들이 Node.js 기술을 이용하고 있는 것을 알게 되었다. 필자는 그들에게 왜 노드를 선택하게 되었는지 물었다. 하지만 대부분의 기업가들은 똑똑한 엔지니어들은 Node.js를 좋아하기 때문에 보다 쉽게 구인 활동을 하기 위해서 선택했다고 이야기 했다. 이 이야기는 영국의 엔지니어들은 자신의 경험을 늘리는데 있어서 회사를 많이 의존하고 있다는 이야기로 들렸다. 물론, 트랜디한 기술을 가지고 좋은 엔지니어를 섭렵할 수 있는 장점이 있다고 한들 정확한 목표를 이루기 위해서 얼만큼 적합한 기술을 선택하고 있느냐 역시 충분히 검토해봐야 할 문제이다.


각 기술별 다양성


그렇다면 지금 우리 회사의 목표와 문화를 잘 반영할 수 있는 기술은 무엇일까? 이 질문에 대한 답을 얻어가기 위해서는 현재 회사의 목표를 보다 정확하게 이해해야 한다. 그리고 그 회사의 목표가 확실하다면 보다 성공적으로 프로젝트를 수행할 수 있는 확률이 높을 것이다. 이런 이해 없이 많은 기업들이 그저 기술 스택들을 그저 카피하려고만 한다면 어떤 목표와 기대 없이 프로젝트가 진행될 수 있을 것이다.


실리콘밸리의 기술 트렌드가 오픈스택이라고 해서 스타트업을 넘어 모든 기업들이 그 트랜드를 쫓아서는 안 된다. 어떤 기술이 맞고 틀리다가 없는 것이 페이스북을 한번 살펴보면 PHP를 주 언어로 이용한다는 것인데 그렇다고 우리도 PHP를 이용해야 한다라는 논리를 주장해서는 안 되기 때문이다. 먼저 문화와 목표에 맞는 기술 스택을 정하기 이전에 필자가 가지고 있는 기술에 대한 몇 가지 뷰 들을 정리해보도록 하겠다.


PHP


- 일단 만든 결과를 빨리 보여주자고 할 때 높은 효율을 발휘한다.

– 어떤 것이든 할 수 있는 길이 있는 만큼 한계는 없다.

– 깊은 학문적인 이해가 없이도 충분히 접근가능하고 누구든지 쉽게 개발할 수 있다.

– 객체지향은 나중에 고려해 볼 대상이다.




PHP는 전세계를 거쳐 꽤 많은 업적을 쌓아 왔다. 무엇보다도 PHP를 이용하면 쉽게 웹을 개발할 수 있었다. 하지만 아마도 굉장히 많은 PHP개발자 인력풀과 커뮤니티를 가지고 있지만 소수의 좋은 개발자만이 좋은 PHP코드를 작성할 수 있다. 그래서 그만큼 많은 예제코드들이 존재하지만 좋은 코드 예제들을 찾기 어렵다. 이런 이유들 때문에 굉장히 안 좋은 예제들과 코드들이 커뮤니티에 돌아다니고 있는데 주로 잘 테스트가 안되었고 보안에 큰 문제가 있는 코드들이 많이 있다. 더불어 가끔 PHP 자체가 자연스러운 문법을 가지고 있는지 의문이 들 때가 있다.


PHP에 경험이 많은 팀들은 물론 좋은 코드 표준과 프로세스들을 가지고 있을 것이고 수준 높은 웹 페이지를 빠른 시간 내에 만들어 낼 수 있지만 역시나 개발 수준이 어느 정도 되는 소수의 팀만 그렇게 할 수 있다는 부분이 있다.


자바


- 포터블(Portability)이다.

– 객체지향적이다.

– 어떤 IDE 툴을 이용할지 선택이 필요하다.

– 쓰레드를 쉽게 이용 가능하다.

– 오픈소스지만 오라클에 팔린 뒤에 발전주기가 다소 느리다.

– 살짝 느리지만 더 안전한 개발 주기를 가지고 있다.


자바는 굉장히 좋은 옵션의 선택이 될 수 있는 언어임은 분명하다. 수년 전부터 굉장히 많은 개발자들이 자바를 하기 위해서 노력해왔다. 대부분의 자바 개발자들은 자바와 더불어 PHP, 파이썬, 루비와 같은 인터프리트 언어들을 쉽게 바꾸어 이용하는 것이 가능하고 또 개발자들이 그렇게 이용해 왔다. 오라클이 자바를 잠식한 뒤로 줄곧 자바FX와 스윙과 같은 엉뚱한 곳에만 신경을 쓰느냐 자바의 발전이 더디게 되었다. 하지만 안드로이드를 기반으로 한 구글은 자바가 자바가 자바 자체로는 절대 나쁘지 않다는 것을 보여주게 되었다. 즉, 이말은 J2EE나 Swing에 종속적이지 않은 자바 언어만으로 봤을 때 충분히 훌륭하다는 말이다.


자바를 더욱 빛내 줄 수 있는 것은 JVM(자바 버추얼 머신)의 존재와 굉장히 높은 효율을 가지는 라이브러리들의 양이 아닌가 싶다. 자바 개발자를 고용하는 것은 국내를 넘어 세계적으로도 그렇게 어렵지 않다. 일단, 많은 학생들이 학교에서 자바를 가르킨다. 하지만 실제 실리콘밸리뿐만 아니라 국내의 스타트업에서는 뛰어난 자바 개발자를 찾기 어려운 부분이 있다. 그래도 많은 스타트업들이 자바를 선택하는 이유가 있지만 그 중에서도 루비, 파이썬과 같은 최신 트랜드의 인터프리트 언어들과 환경을 같이 병행하는데 용이하다는 점에서 큰 의미가 있지 않을까 생각한다. 다시 정리하자면 자바를 이용하는 개발자들이라면 오랜 개발 경력을 가지고 잘 알려진 패턴들을 잘 이용할 수 있는 개발자들이 비교적 많이 있다는 장점이 있다. 그리고 다른 플랫폼보다 안정적인 개발 플랫폼을 제공하기 때문에 그 선택이 나쁘지 않다.


닷넷(C#/.NET)


- 대체적으로 자바보다 더 나은 엔터프라이즈 환경을 제공한다.

– 윈도우 데스크탑 애플리케이션의 개발을 위한 0순위 옵션이다.

– 자바보다 좋은 IDE를 제공한다.

– 느리지만 안전한 개발환경을 가지고 있다.

– 오픈소스화에 대한 비전이 다소 불명확하다.

필자의 백그라운드가 닷넷 기반의 경험이 많은 부분이 있어서 다소 객관적이지 못한 부분이 있을 수 있겠지만 그래도 자바에서 닷넷으로 전환한 외국의 닷넷 개발자들의 의견들을 종합해서 결론을 내려 보도록 하겠다. 먼저 C#5.0이 발표되었을 때 닷넷 개발자뿐만 아니라 다른 진영의 개발자들이 모두 감탄할 만큼 플랫폼과 그 언어의 발전 속도가 눈부셨다. 실제 C#의 설계와 시작은 자바와 비슷했지만 지금은 언어로서의 발전은 자바보다 훨씬 앞서 나가기 시작했다. 예를 들어 자바8에서 발표하지 못하고 자바9으로 미루어진 기능들이 있는데 이미 C#은 그 기능을 모두 지원하고 있다.


실제로 자바스크립트를 개발하는데 있어서 비주얼 스튜디오는 대단한 인텔리센스와 편의성을 제공한다는 것이 많은 개발자들의 의견이다. 그리고 더불어 닷넷의 가장 큰 장점은 바로 MSDN을 통한 문서화가 굉장히 잘 되어있다는 것이다. 단점을 이야기 해보자면 C# 자체가 완벽한 오픈소스가 아니라는 점과 비주얼 스튜디오와 MSDN 자체가 굉장히 비싸다. 비즈스파크를 활용한 스타트업 전략을 지원받을 수 있는 것이 아니라면 기업에서 이 라이선스 비용을 지불하기가 쉽지 않다. 그러다 보니 플랫폼의 생태계가 마이크로소프트 중심적으로 돌아가게 되는데 요즘 IT의 변화가 개방과 오픈스택을 중심으로 이루어져 나간다는 부분에서 그 문화가 다소 올드해 보인다는 느낌을 받을 수 있다.


하지만 닷넷은 엔터프라이즈 쪽의 백엔드 문화에 적합한 부분이 있는데 이 부분에 있어서는 자바보다 색깔이 진하고 더 안정적이라고 할 수 있다. 국내에서는 닷넷 개발자의 수급이 어려워서 자바를 선택하는 경우도 많지만 외국에서는 그래도 닷넷의 점유율이 자바에 결코 밀리지 않는다. 그래도 희망적인 것은 서서히 마이크로소프트도 오픈소스에 참여하고 있다는 점이고 클라우드 플랫폼 애저를 통해서 플랫폼의 통합에 대한 움직임을 보이고 있다는 것이다.


파이썬(Python)


- 한가지 분명한 목표를 채워 나가기에 적합하다.

– 코드가 깔끔하고 단순하다.

– 프로젝트의 문서화가 수월하다.

필자의 직접적인 경험보다는 프로젝트를 관리하면서 파이썬 개발자와 함께 일하면서 보고 간접 체험한 것들을 위주의 의견을 전달해 보겠다. 무엇보다도 파이썬을 선택하는 기업이나 개발자들을 보면 다른 것보다는 프로젝트의 문서화에서 높은 효율을 가져온다는 점에 큰 장점으로 볼 수 있었다. 그리고 실제로 어떤 문제를 해결하는데 있어서 만큼은 최고의 라이브러리들을 가지고 있다고 볼 수 있다.


하지만 개인적으로 닷넷과 자바와 같은 엔터프라이즈 시스템에 비해서 동적 언어에 대한 단점도 분명 존재하기 마련이다. 무엇보다도 파이썬은 인터넷 환경이 대중화되기 전에 설계된 인터프리트 언어이다 보니 멀티 쓰레드를 사용하여 동시성을 처리하는 부분에서는 어느 정도 문제가 있다. 그래도 파이썬이 매력이 있는 부분은 환경자체가 모던적이고 DB부터 서버사이드 그리고 프론트엔드의 HTML과 자바스크립까지 모든 단계를 개발해야 하는 풀스택(Full-Stack) 개발자라면 어떤 언어보다 훨씬 쉽게 개발할 수 있다는 점이다.


루비 온 레일스


- 기계중심적이 아닌 사람 중심적으로 설계되었다.

– 문법자체가 굉장히 느슨하고 유연하다.

– 테스트를 잘 지원한다.

– 굉장히 쉽게 배우고 개발할 수 있다.

– 열정적이고 다양한 커뮤니티가 존재한다.




루비 온 레일즈(Ruby on Rails)는 루비로 작성된 MVC 패턴을 이용하는 오픈 소스 웹 프레임워크이다. 특히 데이터베이스를 이용한 웹 애플리케이션을 개발할 때 반복되는 코드를 대폭 줄여주고 그만큼 개발 기간을 단축하는 것이 가능하다. 이런 빠른 생산성을 가져다 주는데 있어서 루비의 유연성 부분이 한 몫 한 부분이 존재하지만 역시나 코드 관리에 있어서 약간의 단점도 가지고 있다.


캐시를 지원하고 있기는 하지만 파이썬과 마찬가지로 동시성에 있어서는 어느 정도 제한이 존재한다. 루비온 레일스는 프레임워크 기능보다 루비라는 언어에 익숙해지는데 더 어려움을 가지는 것이 사실이다. 하지만 애자일 환경에 맞추어 보다 쉬운 테스트 환경을 구축하는 것이 가능하다. 레일스 프레임워크 자체가 최신 기술들을 스스로 갖추고 있기 때문에 가능할 수 있는 것인데 얼리 어덥터라면 분명 이 레일스 플랫폼이 더할 나위 없이 큰 장점이 될 것이다. 다시 정리하자면 루비온 레일스는 어떤 제품의 연구를 위해서가 아닌 고객 중심적으로 상품을 보다 빨리 개발하는데 목적이 있다면 굉장히 적합한 환경으로 정리해보고 싶다.


Node.js (Javascript)


- 실시간 데이터 전달에 적합하다.

– 이벤트 중심적으로 커플링을 줄일 수 있다.

– 루비/파이썬의 경험을 참고하여 작성된 프레임워크이다.

– DIY가 가능한 환경이다.



Node.js에서 Node는 웹서버를 말한다. 하지만 파이썬도 토네이도 루비는 이벤트 머신을 가지고 있었던 것처럼 그렇게 새로운 개념이 아닌 단순한 이벤트 기반의 프레임워크이다. 아무래도 Node.js의 다른 경쟁력은 아무래도 자바스크립트라는 언어가 아니었을까 생각해본다. 모든 개발자가 자바스크립트를 이용할 수 있기 때문에 백엔드와 프론트엔드 전부 자바스크립트를 이용할 수 있다는 점에서 큰 호소력을 가질 수 있는 것이다. 하지만 단지 언어 때문에 Node.js가 주목을 받게 되는 것은 아니다. 무엇보다도 굉장히 빠른 응답속도와 전달 대역폭을 지원하고 있고 쉽게 개발을 시작할 수 있다는 점에서 큰 장점이 있다고 볼 수 있다. Node.js의 장점은 앞에서 설명한 루비 온 레일스의 장점을 대부분 가지고 있다.


Node자체가 이벤트 기반의 프로그래밍이다 보니깐 디버깅과 테스트가 상대적으로 어려운 부분이 있다. 그리고 콜백 기능을 다루는데 있어서의 유지보수는 정말 어려운 부분이 있다. 아무래도 이 부분은 향후 Node에서 다른 지원이 있지 않을까 생각해본다. 정리하자면 노드는 어떤 관습을 따르는 것보다는 자신의 구조와 패턴을 만들어서 일하는 것을 좋아하는 얼리 어덥터들에게 훨씬 큰 장점이 있을 것이라고 생각해본다. 그리고 기본적인 MVC 모델로 지원하는 것보다 더 로우 단계의 레벨에서 컨트롤이 가능하기 때문에 더 깊이 있는 제어가 가능하고 프로그래밍 언어에 거부감이 없다는 점에서 높은 점수를 주고 싶다.



스타트업의 기술 선택 가이드


각 기술들을 이용하는데 있어서 어떤 것이 반드시 맞고 틀리다라는 답이 존재하지 않는다. 기술을 선택할 때 있어서 회사의 방향과 목표와 만들어 가고자 하는 문화와 얼마나 적합 하는지를 따져봐야 할 것이다. 예를 들어 한 스타트업이 아직 뚜렷한 제품의 방향이 없고 빠르게 MVP(제품의 최소기능)버전을 만들어서 계속해서 시험을 해 나가야 하는 상황이라면 빠르게 개발할 수 있는 인터프리트 언어 환경이 더 적합할 수 있다.


대체로 루비, 파이썬 그리고 Node.js가 이런 스타트업 환경에 더 좋은 생산성을 보이고 있다. 그리고 스타트업의 태생자체가 Front-end와 Back-end 모두 한 개발자를 의존하게 되는 경우가 많다는 점에서도 좋은 선택이 된다. 개발자 채용에 있어서도 리눅스 환경에서 php와 같은 웹 개발을 해본 개발자라면 손쉽게 적응할 수 있기 때문에 조금 더 유리한 것이 사실이다. 하지만 위의 스타트업에서 만들고자 하는 제품이 높은 난이도의 기술을 요구하고 있다면 반드시 서버와 기술의 흐름을 충분히 이해하고 있는 리드 개발자가 필요할 것이다. 무언가 빠르게 개발할 수 있는 것과 동시에 그 기술의 한계를 이해하고 상황에 맞는 솔루션을 제공해주어야 하는 역할이 반드시 필요하기 때문이다.


대부분 스타트업이 확장과 동시에 많은 어려움을 겪는 것이 “일단 만들고 보자”로 개발한 제품을 확장해야 되는 경우이다. 틀린 이야기는 아닌 것이 이 제품이 살아 남을지 모르는 시험 단계이기 때문에 튼튼한 품질 높은 소스 코드를 만들어내기 보다는 제품을 빨리 만드는 것이 더 중요하기 때문이다. 어찌 되었든 이런 기술적인 문제가 스타트업에 발목을 잡지 않으려면 큰 그림을 제시할 수 있는 아키텍트가 반드시 나중에라도 꼭 합류되어야 잠재적인 난항을 피할 수 있다.



다른 사례로 만약 스타트업에서 만들고자 하는 제품이 기술 난이도가 높다면 필자는 자바나 아니면 닷넷과 같은 엔터프라이즈 환경을 추천하고 싶다. 주로 이런 엔터프라이즈 환경은 어떤 제품을 빠르게 개발하는 것보다는 안전성과 제품의 설계를 중시할 때 적합하다고 할 수 있다. 즉, 스타트업이 정확한 목표가 있고 그 제품이 시험단계를 넘어서 자사의 퀄리티가 높은 질 좋은 제품으로 발전해 가야 한다면 당연히 많은 객체지향과 여러 패턴들을 녹일 수 있는 자바나 닷넷이 적합하다는 이야기이다.


자바와 닷넷 고유한 장단점을 가지고 있는데 먼저 자바는 다른 인터프린트 언어로 닷넷보다는 쉽게 병행할 수 있다는 것이다. 때문에 단단한 자사의 메인 기술을 기반을 다짐과 동시에 다양한 제품 실험을 하는 경우라면 당연히 자바가 더 좋은 선택이 될 수 있다. 반면에 닷넷은 자바보다 더 좋은 개발도구를 지원하고 언어적으로도 더 빠른 업데이트들을 지원하고 있다. 국내에서는 닷넷의 도입이 윈도우 애플리케이션을 개발하기 위한 조합으로 많이 사용되고 있는데 좋은 시너지 효과를 볼 수 있다. 그 외에도 더 안정적인 시스템을 구축함과 동시에 여러 편리한 툴들을 보너스로 사용하고 싶다면 닷넷 또한 나쁘지 않은 선택이 될 것이다.


물론, 기본적인 닷넷과 자바 기술을 가진 개발자만 가지고 다른 플랫폼 환경처럼 결과를 만드는 것이 가능하지만 엔터프라이즈 환경의 빛을 보려면 기술적인 이해와 더불어 다양한 개발방법론과 패턴들을 이해하고 도입할 수 있는 뛰어난 개발자를 찾아야 할 것이다. 하지만 그런 개발자들을 찾는 것이 생각만큼 녹록하지 않다. 닷넷의 경우라면 국내에서는 더더욱 어려울 수 있다.


글을 마치며


이렇게 해서 스타트업의 기술 선택에 대한 주관적인 생각들을 정리해 보았다. 스타트업에서 대부분의 기술정책과 방향은 CTO나 리드 개발자들로부터 내려지게 되지만 그 기술방향을 수립하기 이전에 앞서 회사의 방향과 문화를 조금 더 고려해 볼 필요가 있다. 한번 선택한 기술을 다시 돌리기 위해서는 많은 길을 돌아가야 한다는 점을 잊지 말아야 한다. 때문에 맹목적인 이유를 통한 선택이 아닌 회사의 방향과 문화 그리고 지금의 상황에 맞는 합리적인 결정을 진행할 수 있다면 좋은 건강한 기술문화를 기반으로 좋은 목표를 창출할 수 있는 회사를 이끌어 갈 수 있을 것이다.

저작자 표시
신고
Posted by 박경훈
스타트업 가이드2011.03.12 14:51
선점성의 성공 사례는 싸이월드나 카카오톡이 있다. 싸이월드는 사용자가 직접 자신의 홈피를 소개하고기 때문에 사용자가 바로 광고주체였다 카카오톡도 800만 사용자가 지금 이 프로그램의 홍보 위원으로 활동하고 있는 것이나 다름이 없다.

하지만 아무리 좋은 선점도 트렌드에 대응하지 못하면 결국 없어지게 된다. MP3 만들던 회사 “아이리버” 초창기 시장 가치는 어마어마 했다. 당시 회사의 시가 총액이 거의“8천억”이었고 또, 뒷이야기로 삼성에서 “5천억”에 인수제안도 했지만 거절했다는 후문도 있다.(그때 팔았어야..) 하지만 지금은 순자산 가치가 지금 1천억도 되지 않은 상황이다.

선점성도 시장 상황에 따라서 예외가 있을 수 있다. 인크루트는 잡코리아와 어마어마한 차이가 나는 2위의 회사였지만, 잡코리아와 거의 동등한 수준으로 올라오게 되었다. 그 이유는 인크루트의 열정도 있었지만 이 시장은 3~4등까지는 살아 남을 수 있는 시장이었기 때문이었다. 왜냐하면 인사 담당자 입장에서 한군데에만 채용광고를 내지 않는다는 특징이 있기 때문이다. 여러 신문에 광고를 내는 것처럼 상사에 보고를 진행하게 될 경우에도 여러 구인 사이트에 채용을 올렸다고 해야 했기 때문이었다. 하지만 인크루트는 어느 정도 궤도에 올라섰다고 생각해서 유료화를 진행한 덕에 결국 잡코리아와의 격차는 지금 다시 굉장히 벌어진 상황이다.

검색시장의 경우 아무리 좋은 검색 엔진을 개발했다 하더라도 후발 주자가 되기는 어렵다. 축적된 페이지의 DB의 한계가 있기 때문이다. 하지만 진입장벽이 낮은 소셜커머스 즉, 티켓몬스터는 지금 브랜드를 선점시켰다는 것 말고는 특별한 진입장벽이 없다. 때문에 미국의 그루폰이 현재 한국 서비스를 위해서 돈을 바르고 있는데 향후에 시장이 어떻게 바껴 나갈지 한번 관전해 볼만하다.
신고
Posted by 박경훈
스타트업 가이드2011.03.12 14:48

자본없이 시작해서 성공한 회사는 3%채 되지 않는다고 한다. 카카오톡이 자본이 없었다면 성공은 보장하지 못했을 것이다. 적어도 네이버 대주주였던 김범수 사장은 300대의 서버를 확보할 만큼의 자본 여력이 있었다. 만약 처음부터 광고를 삽입하여 사용자를 귀찮게 했다면 분명 다른 경쟁사들에 의해서 없어질 확률이 많았을 것이다.

참고로 카카오톡은 음성쪽지 기능은 이미 넣기로 결정이 되었고, 전화 기능은 통신사들과의 조율중에 있다고 한다.
신고
Posted by 박경훈
스타트업 가이드2011.03.12 14:44
에누리 가격비교 사이트의 경우 처음 시작했을 당시 게시판 형태로 다른 사이트드과 비교해서 정말 후진 사이트였다. 하지만 결국 끝까지 버텨 지금 사장 1위를 점유하고 있다.

그럼 어떻게 버틸 수 있었을까?

이 서비스의 유형이 수익 창출이 늦어지게 되는 서비스인 특징을 감안해보면, 에누리는 초반에 제공하는 기능 자체가 많지 않았다. 즉, 핵심기능만 제공하고 있었기 때문에 다른 사이트보다 유지보수 비용이 적었다는 것이 1위의 경쟁력을 가진 사이트로 부상할 수 있었다.
신고
Posted by 박경훈
스타트업 가이드2011.03.12 14:42
빨리 망할 서비스는 빨리 망해버려야 한다. 똑똑한 사람들은 그것을 어떻게든 살려보겠다며 계속 돈을 끌고 오거나 전략을 짜거나 하면서 질질 끌다가 오히려 파산까지 가게 되는 경우가 많다. 기술성은 좋아도 사업성이 없어서 실패하는 서비스들이 정말 많다. 처음 시장에 나와서 아니다 싶으면 최대한 빨리 빠지는 것이 좋다.
신고
Posted by 박경훈
스타트업 가이드2011.03.12 14:40
정말 영업도 잘하고, 아이디어도 톡톡 튀는 김모씨는 게임회사를 창업했다. 물론, 개발자는 아니었지만 대단한 영업력과 아이디어로 많은 자금을 투자 받았지만 결국 게임 개발이 예상일정대로 진행되지 않았다. 결국 자금난에 허덕이며 다시 한번 재투자자들을 찾고 있던 중에 한 투자회사의 대표와 인터뷰를 진행하게 되었다. 김사장은 첫 질문을 받고 실패원인을 뼈저리게 느꼈다고 한다. 그 질문은 이렇다. 

“김사장, 당신은 지금 회사에서 만들고 있는 게임 소스코드를 보면 이해할 수 있는 능력이 있는가?”
신고
Posted by 박경훈
스타트업 가이드2011.03.12 14:37


가격비교 사이트를 인수하려다 말았던 적이 있는데 그 큰 이유는 네이버가 뛰어들면 끝이겠구나 라는 생각 때문이었다. 결국 지금 네이버도 가격비교를 진행하고 있다. 참, 다행이라고 생각한다. 서비스가 살아 남으려면 네이버가 마음을 먹어도 따라 올 수 없을 만큼의 인지도를 확보해야 한다. 잡코리아는 이미 그만큼 성장을 했었기에 살아 남을 수 있었다.

신고
Posted by 박경훈
스타트업 가이드2011.03.12 14:35

지금 등장하고 있는 소셜커머스 라는 사업들은 오히려 “소셜커머스” 보다는 “Deal of the day” 이 어울리는 것 같다. 즉, "하루 특가" 판매와 같은 이름이 더 정확하다는 것이다.

요즘 왜 이렇게 “소셜커머스” 열풍이 불고 있는 것일까? 소셜커머스의 장점은 일단, 창업이 쉽고 큰 돈이 들지 않는다는 것이고 두 번째는 수익으로 바로 연결되기 때문이라고들 한다. 물론 지금이야 너무 포화 상태지만 1억만 투자하면 사이트와 거점을 확보할 수 있고 또, 한달 만에 수익을 낼 수 있다고 이야기 되고 있는 것이 바로 “소셜 커머스” 이다.
신고
Posted by 박경훈
스타트업 가이드2011.03.04 14:22

이 월간 마이크로소프트웨어 2011년 1월호 "슈퍼 개발자의 꿈" 원고로 기고했던 내용입니다.



글을 시작하기 전에 이 글은 필자의 지극히 개인적인 생각들과 주관적인 생각을 바탕으로 작성됐다는 점을 감안하고 읽어주면 좋겠다.

한국에서의 개발자

필자는 20살이라는 철없던 나이에 사회에 뛰어들어 서른 가까운 나이가 될 때까지 개발에 몰두해왔다. 다른 개발자들에 비해 대학에 진학하지 않고, 바로 일을 시작했다는 것이 조금은 이례적이라고 할 수 있겠다. 커뮤니티와 대외 활동도 많이 진행하기는 했지만 모두 개발과 관련된 일들이었다. 그래서일까. 짧지 않은 기간 동안 개발자 일을 해오며 머릿속에 갖고 있던 생각들과 목표, 그리고 미래의 방향들은 시간이 흐르면서 계속해서 변해왔다.

먼저 처음 개발 일을 시작하면서 3년차 정도가 되기까지는 그저 개발이 재미있게 느껴졌고, 배움에 대한 갈망이 컸다. 때문에 나의 미래에 대해서 구체적으로 생각해 볼 여유가 크지 않았다. 하지만 그 3년이 지나자, 그때가 돼서야 정체성에 대해서 생각해 볼 여유가 생겼다. 분명 친구들은 소위 말하는 SKY라는 타이틀을 가지고 사회에서 경쟁을 하게 될 것이 분명한데, 그에 반해 내가 가지고 있는 경력은 너무나 초라해 보였기 때문이다.

IT 프리랜서로 활동하면서 몇 년 동안 프로젝트를 진행해 본 것이 전부였던 필자는 이력서에 한줄이라도 넣을 수 있는 것들을 찾으며 수년을 보내게 됐다. 개발자 커뮤니티 운영을 시작으로 책을 쓰기도 하고, 번역을 하기도 했으며, 교육이나 세미나 행사에서 강사의 기회가 있으면 놓치지 않았다. 이러한 노력들이 결실로 다가오기 시작할 때 즈음해서 필자에게는 안정과 모험 사이에서 인생의 방향을 다시 생각해야 하는 갈림길이 다가왔다.

두가지 도전 과제 중 하나는 먼저 해외로 나가서 외국회사에 들어가 일을 해보는 것이었다. 이민을 가고 싶었던 것 보다는 글로벌 감각을 키우고 싶은 욕심이었다. 두 번째 과제는 세계 명문 대학교에서 공부를 하고 싶다는 것이었다. 공부라고 해 봤자 고3때 누구나 다 하는 수능공부와 4년 동안 온라인으로 강의를 들으며 간신히 졸업한 사이버 대학교가 고작이었다. 그래서 필자는 지난 2009년, 그 동안 모아온 돈을 털어서 영국으로 어학연수를 떠났다.

어학연수를 떠난 이유는 바로 첫 번째와 두 번째 도전에 대한 공통분모는 바로 언어의 장벽을 허물어야 한다는 것이었다. 미국이 아닌 영국을 선택한 이유는 간단하다. 남녀 비율에서 여자 비율이 높았던 곳이 영국이었기 때문이었다. 다들 영국에는 젠틀맨이 자신을 기다리고 있을 거라는 환상과 착각으로 각국의 여자들이 영국행을 택하지 않던가. 그와 비슷한 맥락이라고 할 수 있으리라.

영국과의 인연

어학연수를 가기 전까지만 하더라도 필자는 1년간 어학연수 코스를 이수하면 저절로 영어에 능숙해질 수 있을 것으로 착각했었다. 영화를 볼 때 당연히 자막 없이 볼 수 있는 정도의 어휘력이 될 줄 알았던 것이다. 하지만 1년 이라는 시간은 고작 어린 아이처럼 의사소통 정도만 가능하게 된다는 것을 알게 되었을 때 정말 수단과 방법을 가리지 않고는 시간만 낭비하게 될 것 같았다. 때문에 필자는 어떻게 하면 영어가 빨리 늘 수 있을까라는 것을 고민했고, 수단과 방법을 가리지 않고 영어를 연습했다.

영어를 하는데 있어서 가장 큰 도움을 받은 것은 매일 오후 영국인 가족이 살고 있는 이웃집에 가서 2~3시간씩 성경공부를 한 것이었다. 물론 영국에 오기 전부터 시작한 영어공부의 효과도 있었겠지만, 이 시간을 통해서 정말 빠르게 늘어나는 영어실력을 보게 됐고, 인생의 철학까지도 배울 수 있는 너무나 소중한 시간이었다. 이렇게 3개월이나 지날 즈음에 회사에 이력서를 내도 면접을 볼 수 있겠다는 자신감이 붙게 되었다.

그래서 필자는 여러 IT회사에 면접을 보게 되었고 비자문제로 정직원은 아니었지만 계약직 자리를 얻어내서 일을 시작하게 되었다. 드디어 목표했던 외국 회사의 문화를 체험해 볼 수 있는 좋은 기회가 찾아오게 된 것이다. 외국회사 문화에 대해서 하고 싶은 이야기들은 가득하지만 지면상 생략하도록 하겠다.

이렇게 시작한 영국에서의 인연은 영어뿐만 아니라 회사의 문화와 많은 인맥까지 만들 수 있었던 좋은 시간이었다. 그렇게 6개월을 근무하고 한국에 돌아오게 되었다. 그리고 다음 갈림길에서 필자는 사업을 진행할지, 대학원을 갈지 이 두 갈래 길에서 고민하다가 결국 사업을 선택하게 됐다.

당시에 지원했던 대학원과 인연이 닿지 않았던 것도 있었고 자금을 투자할 여유가 되는 동업자가 마침 다른 일 때문에 한국에 입국해 있는 상황이었다. 필자는 사업기획서를 작성해 지인을 설득했고, 동시에 당장 회사를 그만두고 사업에 바로 참여할 수 있는 주변의 개발자들을 모아서 사업을 시작하게 됐다.

이렇게 필자와 동업자들이 함께 만든 모바일 서비스는 바로 ‘AppCookr’다. 이 서비스 모델은 웹에서 사용자가 직접 앱을 개발할 수 있는 템플릿을 제공해주고 사용자 자신이 직접 만들고 싶은 앱을 원하는 대로 만들게 해준다. 그리고 배포를 요청하면 우리가 앱을 심사한 뒤에 자체적으로 개발한 자동 배포 도구를 이용해서 앱을 등록시켜주는 주는 간단한 방식으로 이뤄져있다.

수익 모델도 복잡하지 않았다. 앱을 만들기 위해서 최소 3,000만원에서 몇 억 이상의 돈을 거액을 지불해야 하는데 우리의 서비스는 템플릿이 제한되어있는 반면 500파운드(한화 약 100만원)라는 경쟁력 있는 금액을 통해서 앱을 제공해주는 방식을 선택했다.


<화면 1> 2010년 10월에 오픈한 AppCookr 서비스, 한국에도 2011년 1월에 정식 서비스 될 예정이다.

사업을 진행하기로 결정하고 난 뒤에는 비즈니스와 수익 모델에 대한 큰 그림을 그렸다. 그 뒤에는 어디서 서비스를 시작할지 정해야 했다. 하지만 고민할 것도 없이 바로 영국 시장의 문을 먼저 두드려 보기로 결정했다.

왜 영국을 먼저 타깃으로 잡았는가. 가장 큰 이유는 서비스가 해외 정서를 고려하지 않은 채 만들어지는 것을 막아보자는 데 있었다.

싸이월드도 미국에서 시작한 페이스북이나 마이스페이스보다 더 먼저 국내에서 성공한 SNS 서비스였지만 결국 세계의 벽을 넘지 못했다. 싸이월드가 해외에서 자리를 잡을 수 없었던 이유가 바로 ‘세계 정서를 고려하지 않게 설계되어 있다’는 의견이 대부분이었기 때문이다.

두 번째 이유는 한국에서는 보다 안정된 서비스를 선보이고 싶었다. 국내 시장은 확실히 준비만 되면 이 서비스는 확실히 성공할 수 있다는 자신감이 있었다. 그만큼 이미 시행착오를 거쳐서 잘 다듬어진 서비스를 오픈하고 싶었던 이유가 컸던 것이다.

세 번째 이유로 영국에는 이미 다져진 네트워크가 있었다. 마냥 황폐한 황무지가 아니었다는 점에서 망설임 없이 미국이 아닌 영국을 선택했던 것이다. 그리고 영국에서 서비스가 성공하게 되면 유럽 전역으로 서비스가 자연스럽게 확장되어 간다는 것이 거의 공식이었다. 그리고 마지막 이유는 한국에서 사업을 시작하게 되면 결코 해외로 눈을 돌리기가 결코 쉽지 않을 것이 분명했기 때문이다. 한국에서는 다른 서비스를 카피해서 새로운 서비스를 오픈하는 것이 결코 어려운 일이 아니다. 

영국의 IT와 모바일

필자가 영국을 접했을 때 여기는 분명 기회의 땅이 될 수 있다고 생각했다. 왜냐하면 한국에 비해서 IT 인프라가 너무 열악하다는 점 때문이었다. 예를 들면, 부동산과 같은 오피스를 운영하는 곳은 자체 프로그램이 아닌 엑셀을 이용하고 있을 뿐만 아니라 좋은 레스토랑에 가더라도 POS시스템을 이용하는 곳은 거의 없었다. 그래서 필자는 영국에서는 어떤 IT 사업을 하더라도 성공할 수 있겠다는 자신감을 가졌다.

하지만 영국은 하나의 서비스를 개발한다고 하더라도 정말 높은 품질로 확실하게 만드는 것이 한국과 다른 큰 차이점이다. 가장 감탄한 것이 영국 버스검색 서비스다.

국내 서울의 버스 검색 사이트는 사이트자체가 무거울 뿐더러 원하는 목적지를 찾는 UI 자체도 굉장히 복잡하다. 하지만 영국의 버스 검색 사이트는 정말 군더더기 없는 UI로 원하는 기능을 정확하게 제공해 주고 있었다. 단순히 출발지와 목적지를 검색해서 입력하게 되면 가지고 있는 경우의 수의 루트를 찾아서 보여주게 되는 것이다.


<화면 2> 영국의 버스 검색 서비스

한국은 굉장히 다양한 IT 기업들이 존재하고 있으며 그 서비스의 양도 엄청나다. 하지만 각 서비스를 이용하는데 있어서 만족도나 퀄리티는 떨어지기 마련이다. 반면에 영국 서비스는 다양하지는 않지만 제공되고 있는 서비스가 만족도가 굉장히 높고 그 퀄리티도 뛰어난 것이 큰 차이점이다.

이런 차이가 나는 이유는 간단하다. 국내는 초급개발자가 많다. 한국의 개발 팀을 살펴보면 10년차 정도 되는 개발자가 개발을 주도하고 그 아래 개발자들은 모두 2~3년차 정도 되는 초급자가 팀을 이루는 구조가 일반화 되어있다. 그러나 영국은 기본 7년이 넘어가는 고급 개발자의 비중이 높다.

이 외에도 영국에서 아이폰의 위상은 다른 나라보다 대단했다. 스마트폰 점유율을 보면 당연히 전세계 사용률처럼 노키아가 1위를 차지하고 있지만, 다른 나라보다 아이폰의 사용률이 높았다. 무엇보다도 굉장히 보수적인 영국 사람들이 그만큼 선택했다는 것에서 많은 점수를 줘야 할 것이다.

영국은 앞에서 언급했던 것처럼 IT 인프라가 좋지 못하다. 지하철 안에는 기지국이 설치되어 있지 않기 때문에 3G 인터넷은 커녕 전화를 받는 것조차 힘든 것이 사실이다. 그렇기 때문에 아이폰 앱들의 다운로드 순위가 우리나라와 상당히 다르다는 것을 느낄 수 있다. 우리나라는 주로 IT 서비스 관련 앱들은 주로 상위권을 차지하고 있는 반면 영국은 게임 앱들이 많이 차지하고 있었다. 우리나라처럼 네이트, 네이버, 다음과 같은 다양한 서비스가 존재하지 않았고 또한 좋지 못한 통신망 때문이기도 했다.

필자는 이렇게 IT 인프라가 황폐한 땅인 만큼 충분히 경쟁력이 있을 거라고 생각했다. 하지만 시간이 흐르며 들었던 의구심은 오히려 사람들이 IT에 관심이 없어서 이렇게 된 것은 아닐까라는 생각이었다. 왜냐하면 런던만 보더라도 주변에 항상 공원이 있고 그들의 여가활동은 컴퓨터와 같은 디지털이 아닌 공원에서 운동을 하거나 가족들과 쉼을 나누는 것이 그들의 문화였기 때문이다.

보수적인 영국 문화의 벽

영국서 필자는 서비스기획과 아이폰 개발 분야, 그리고 전체적인 일정관리 부분에 대해 진행했다.

서비스 목표와 비즈니스 프로세스가 어느 정도 분명했기 때문일까. 3개월 정도 지나자, 서비스에 대한 전반적인 윤곽이 나타나기 시작했다. 그리고 비로소 마케팅과 영업에 대한 고민이 시작되었다. 무엇보다도 우리 서비스를 통해서 만들어진 인지도 있는 기업의 사례들이 필요했다. 어떤 쇼케이스 없이 이 보수적인 문화가 팽배한 영국에서 신뢰를 챙겨가기가 힘들기 때문이다.

그래서 먼저 섭외할 10개의 기업들을 뽑아 리스팅했다. 리스팅 우선순위로는 이미 만든 앱이 없고, 우리 템플릿이 가지고 있는 기능을 최대한 활용할 수 있는 RSS나 트위터, 맵과 같은 데이터를 가지고 있는 기업들이 1순위였다.

다양한 사례를 만들어야 했기에 다양한 분야의 기업들을 리스팅 했다. 그 당시 대표적인 타깃 기업으로는 런던에서 가장 인기있는 맘마미아 뮤지컬 극장과 Zdnet, TechEye와 같은 영국의 IT미디어 기업들과 스코틀랜드의 에딘버러 페스티벌 등이 대표적인 예다.

우리는 이 기업들의 홈페이지에서 제공하는 RSS, 트위터, 플리커 등의 데이터들을 바탕으로 앱을 직접 제작했다. 이렇게 이미 제공하고 있는 데이터들만 있으면 자동으로 앱을 생성할 수 있기 때문에 만드는 것은 어렵지 않았다. 그것보다는 어떻게 이 기업들을 만나 승인을 받아내야 할지 고민이었다.

먼저, 기업 담당자를 찾아가기 전에 회사 메일을 통해서 제안을 하기로 결정했다. 우리가 만든 앱을 보여줄 방법이 메일로는 마땅한 방법이 없었기 때문에 선택한 방식은 결국 동영상 제작이었다. 동영상으로 동작되는 화면을 찍었고 유튜브에 업로드해 그 링크를 공유했다. 물론, 기대를 가지고 메일을 보내지는 않았다. 그 메일을 열어 볼 확률은 반도 되지 않을 것이라는 것도 예상했고, 또 열어본다 하더라도 적절한 업무 담당자에게 전달될 확률도 크지 않을 것이라고 생각했기 때문이다. 그래도 형식상 방문 전에 메일을 보내서 제안을 시도하는 것이 도리라 생각되어 진행한 일이었다.

역시 예상대로 전화가 온다거나 회신이 오지는 않았다. 이 일을 진행하는데 있어서 가장 심사숙고한 부분이 바로 영어였다. 폼나는 글귀를 이용해서 특정 기업에게 제안 메일을 보내도 쉽지 않을 터인데 어리숙한 문장을 이용한다면 당연히 신뢰가 생기지 않을 것이기 때문이었다.

예를 들면 이런 것이다. ‘제안’이라는 표현은 영어에서 무수하다. Suggestion, Offer, Proposal등 여기서 비즈니스적인 제안의 경우 당연히 Proposal을 써야 한다. 하지만 세컨드 랭귀지로 영어를 접했던 사람은 문장에 있어서 어떤 단어가 혹은 어떤 문장이 보다 포멀한지 구분하기 힘든 것이 사실이다. 그래서 현지 직원을 구하기 전까지 주변의 지인을 통해서 확인을 받아서 진행해야만 했다.

그렇게 메일을 보내고 일주일이 지나서 필자는 직접 회사에 찾아가기로 결정했다. 먼저 첫 번째 방문에서는 비즈니스 제안 문서를 만들어서 마케팅 매니저에게 전달하는 것이 첫 번째 목표였다.

물론 같이 이야기도 나누고 싶었지만 선약이 있었던 것도 아니고 불쑥 찾아가는 것이기 때문에 매니저 연락처나 이름을 알아내는 것으로 첫 번째 성과라고 생각했다. 찾아갈 회사들이 모두 런던에만 있었던 것은 아니었다. 그래서 1차적으로는 런던에 있는 회사들만 찾아가서 문서를 전달했다. 이때 방문했던 회사들은 담당자와 선약이 없었기 때문에 로비에서 직접 마케팅 매니저를 직접 연결시켜 주지 않았다. 대신 문서를 전달해 달라고 부탁을 했고 몇 군데 기업에서 매니저의 이름과 연락처를 알아내는 정도로 만족을 해야 했다.

<화면 3>  당시 쇼케이스를 위해서 찍어낸 앱들

그리고 일주일이 지났다. 이번에는 내심 작은 기대 정도는 가지고 있었지만 연락이 없었다. 그 뒤에 회사를 재 방문하기로 결정하고 이번에는 추가로 동작되는 앱의 화면을 담은 동영상을 CD로 만들어서 전달했다.

이번 2차 방문에서 역시 큰 수확은 없었지만 이번에는 맘마미아라는 뮤지컬 극단 마케팅 매니저와 미팅을 바로 할 수 있었다. 여기서 회의를 통해서 알게 된 사실이 있었다. 영국 기업들의 입장에서는 지금 우리 회사를 신뢰할 수 없다는 것이다. 왜냐하면 그 당시의 AppCookr 서비스는 베타 수준이었을 뿐더러 보여줄만한 다른 포트폴리오를 가지고 있던 회사도 아니었다. 그리고 가장 중요한 것은 영국에서 연혁이 오래된 회사도 아니었고 그저 한국에서 건너온 미지의 작은 회사였던 것이다.

그리고 돌아와서 한번 기업의 입장에서 생각을 해봤다. 내가 기업주이고 외국인 두 명이 찾아와서 앱을 무료로 만들어 주겠다고 하면, 당연히 의심부터 시작할 것이다. 더군다나 영국은 보수적인 문화로 정평이 나있는 곳이었다. 그래서 그 뒤로 방향을 조금 수정했다. 먼저 서비스를 보다 완벽하게 오픈하고 회사 홈페이지도 잘 갖추고 나서 다시 한번 제안을 넣어 보기로 한 것이다.

그렇게 또다시 한 두 달이 지나서 AppCookr 서비스의 방문자도 늘어갔고 우리 서비스로 만들어진 앱들도 늘어나기 시작했다.

입소문을 통해서 퍼져나가서 어느새 트위터의 팔로우 수도 3000명이 넘어가고 있었으며, 베타 서비스때 없었던 회사 홈페이지도 갖춰졌다. 이처럼 차츰 영국 내에서 서비스 인지도가 쌓여갈 무렵, 다시금 생각하지 못한 열매들을 거두기 시작했다. 바로 3개월 전에 방문해도 꼼짝도 안하던 기업들이 AppCookr의 신뢰가 어느정도 쌓이자 다시 제안을 넣어 달라는 연락이 온 것이었다.

영국뿐만 아니라 해외의 문화가 그렇다. ‘스피드’를 중시하는 한국 문화와는 다르게 작은 비즈니스 계약을 체결한다 하더라도 정말 신중하게 생각하고 최대한의 여유를 가지고 의사결정을 한다는 점이다.

그렇기 때문에 보수적인 마인드가 강제되기도 하고 신뢰 없이는 결코 움직일 수 없게 된다. 번외적인 이야기이지만 영국은 다른 것보다 미술로 잘 알려져 있고, 많은 학생들이 미술을 전공하러 많이 찾는 나라다. 재미있는 것은 유명한 영국의 미술가가 한국에서 인정받았던 한국인의 작품을 보고 이런 말을 했다고 한다.


“이 작품은 훌륭하지만 ‘여유’가 느껴지지 않는다”


이 말은 필자가 영국에서 사업을 진행하며 철저히 훈련받은 부분은 아무리 유리한 조건의 “딜”이 있다고 하더라도 충분히 검토해보고 진행할 수 있는 ‘여유’가 필요하다는 것을 느께게 하는 말이었다.

박경훈 hoonsbara@hotmail.com|닷넷 개발자 커뮤니티로 잘 알려진 ‘HOONS닷넷’을 8년간 운영해 왔으며, 지난 5년간 마이크로소프트의 Visual C# MVP로 활동해왔다. 10여권의 IT서적의 집필 및 번역은 물론, 기독교 극동방송에서의 라디오 진행자로 활동하기도 했다. 지금은 ‘캠든소프트’라는 벤처를 창업, 영국 내 모바일서비스를 운영 중이며, 국내에서도 모바일 서비스 런칭을 준비하고 있다.
신고
Posted by 박경훈
스타트업 가이드2011.01.29 03:46

1주차 교육 준비사항



신고
Posted by 박경훈
스타트업 가이드2010.11.19 10:30

캠든소프트 회사 웹사이트를 만들었다.
역시 디자인의 길은 멀고도 험하다는 생각과 동시에
최근 디자인 업무들만 과중되면서 한국가면 꼭 디자이너부터 구해야겠다는 강한의지가 다져지고 있다.

http://www.camdensoft.com/


신고
Posted by 박경훈