All of Software

2012년 10월 29일 월요일

절대 코딩하지 마라

"코딩은 늦게 할수록 프로젝트가 빨리 끝난다."

대부분의 개발자들은 이 말을 제대로 이해하지 못한다. 그래서 프로젝트 일정이 촉박하면 무조건 코딩부터 시작하곤 한다. 코딩을 빨리 시작하면 프로젝트가 빨리 끝날 것으로 믿곤 한다. 말은 그렇게 하지 않더라도 일정이 부족하면 문서 작성할 시간도 없고 무조건 코딩부터 시작한다.

물론 프로젝트에 따라서 대충해도 되는 경우가 많다. 그런 프로젝트를 예로 들어서 모든 프로젝트에 확대 적용하지는 말자. 즉, 개집은 어떻게 만들어도 다 되는 것이다.

코딩 시작은 빨리 시작할수록 재작업은 급속히 늘어난다. 코딩을 최대한 뒤로 늦춤으로써 재작업 가능성을 낮춘다. 물론 스펙이 완전히 끝나야 코딩을 시작할 수 있는 것은 아니다. 스펙을 합리적으로 작성하는 요령 중 하나가 미리 확정할 수 있는 라이브러리나 Sub system들은 인터페이스를 미리 확정하고 코딩을 먼저 시작할 수 있다.

보통 프로젝트에서 분석을 해보면 코딩부터 할 수 없다는 것을 알게 된다. 코딩부터 시작하는 경우는 무엇을 개발할지도 모르고 코딩을 시작하는 것이다. 그렇게 미리 작성된 코드는 스펙이 정해지면 버리고 다시 짜야 하는 경우가 많다. 아키텍처에 요구사항이 제대로 반영되지 않는다. 그럼에도 미리 코딩을 해 놓으면 코드를 버리기가 아까워서 그냥 사용하게 된다. 그러다보면 아키텍처는 엉망이 된다.

개발자들은 자신이 작성한 코드를 살리기 위해서 요구사항을 거부하기도 하고 코드에 꼼수를 부리기도 한다.

가끔은 코딩만하기에도 정말 일정이 부족한 프로젝트들이 있다. 이런 경우도 코딩부터 한다고 프로젝트가 빨리 끝나는 것은 아니다. 무모한 시도를 하는 것이다. 스펙을 작성할 시간도 없는 프로젝트는 안하는 것이 낫다. 그렇다고 회사에서 프로젝트를 거부할 수는 없다. 최대한 빨리 스펙을 써서 합리적으로 가능한 일정와 범위를 제시하는 것이 더 좋은 방법이다.

일정이 촉박하다고 매번 코딩부터 시작하면 10년을 개발해도 별로 나아지는 것이 없을 것이다.

2012년 10월 25일 목요일

스타트업에서 SW 개발에 꼭 필요한 시스템

소프트웨어를 개발하는데 꼭 필요한 시스템들이 있다. 이것을 기반시스템, 영어로는 Infrastructure system이라고 한다. 기반 시스템은 수십 가지 종류가 있지만 회사 규모나 성격에 따라 꼭 필요한 것이 다르다. 꼭 필요한 기반시스템을 사용하지 않거나 규모에 맞지 않게 많이 사용하는 것 모두 문제다. 그리고 제대로 사용해야 효과를 극대화할 수 있다.

회사 규모가 크면 좀더 많은 기반시스템을 사용할 필요가 있지만 스타트업에서는 꼭 필요한 몇 가지만 있으면 된다. 그럼 스타트업에서 꼭 사용해야할 기반 시스템에는 어떠한 것들이 있는지 알아보자.

1. 소스코드관리시스템

필요성: ★★★★★

2012년 10월 23일 화요일

한국에서 외국인 개발자가 일하기 어려운 이유

소프트웨어 회사의 경영자는 항상 개발자 수급을 고민한다. 우수한 인재를 싸게 쓰고 싶지만 좋은 개발자를 찾기도 어렵고 인건비가 여간 비싼 것이 아니라고 생각한다. 물론 개발자 입장에서는 많지 않지만 경영자는 반대 입장이다.

그러다 보면 저렴하고 우수한 외국인 개발자를 쓰고 싶은 욕구가 생겨난다. 중국이나 인도 개발자들은 평균적으로 인건비가 국내 개발자보다 저렴하고 실력도 뛰어나다. 그래서 실제로 많은 회사들은 외국인 개발자 채용이나 현지 개발센터를 설립하는 일들을 그동안 많이 해왔다.

경우에 따라서는 인건비 이슈가 아닐 수도 있다. 외국인 개발자를 활용하는 것이 국내 개발자에게 들어가는 비용보다 더 많이 들어가기도 한다. 그럼에도 불구하고 개발 인력 수급 문제 해결과 조직의 Global 문화 흡수 등 여러가지 이유로 외국인 개발자 활용 전략을 추진해 왔다.

나름 성과를 내고 있는 회사도 있으나 대부분은 실망이 큰 것이 사실이다. S사 같은 경우는 그룹차원에서 현지 개발자를 채용하여 각 계열사로 정책적으로 외국인 개발자를 배치하고 있으나 경영진의 바람과 외국인 개발자와 같이 일하는 국내 개발자와 평가는 차이가 꽤 크다. 뛰어난 개발자를 데려다가 단순 코더로 전락 시키기도 하고 문화적인 충돌로 인해서 거의 활용을 못하는 경우가 허다하다.

그럼 미국 실리콘밸리에서 일하는 인도, 중국 개발자들도 똑같은 상황일까? 전혀 그렇지 않다. 유독 우리나라에서 외국인 개발자들과 같이 제대로 일을 못하는 이유는 언어 장벽외에도 여러가지가 있다. 이것을 잘 생각해 보면 바로 우리들이 가지고 있는 문제를 고스란히 보여주기도 한다.

우리는 왜 외국인 개발자와 제대로 같이 일을 하지 못할까?

1. 언어의 장벽

요즘은 영어를 잘하는 직원들이 많지만 소프트웨어 개발자들 중에는 영어를 잘하는 비율이 좀 낮은 것 같다. 생활영어 정도를 할 줄 안다고 해도 외국인 개발자와 회의나 리뷰를 제대로 하기 어렵다. 대화가 가능해도 훨씬 많은 노력을 들여야 하기 때문에 부담이 커진다. 특히 인도 영어는 더욱 알아 듣기 힘들다.

2. 문서

외국인 개발자와 같이 일하려면 문서를 기반으로 일해야 한다. 대부분은 프로세스, 스펙 등에 익숙하기 때문에 우리나라와 같이 대충 말로 때우거나 지시하는 환경에 익숙하지 않다. 의사 소통도 쉽지 않은데 매번 말로 지시하고 확인하는 일이 쉽지 않다.

3. 번역

외국인 개발자와 같이 일하려면 문서를 영어로 작성해야 한다. 모든 문서를 영어로 작성하면 우리나라 개발자가들이 힘들기 때문에 영어로만 작성하기도 어렵다. 한국어로 작성하고 영어로 번역을 해도 보통 어려운 일이 아니다. 최신 문서를 유지하기도 어렵고 싱크가 맞지 않는다. 보통 일이 아니다. 스펙을 제대로 작성했으면 한번만 번역을 하면 되는데 스펙을 제대로 작성하는 경우도 많지 않고 쉽게 바뀌는 일이 흔하기 때문에 매번 번역에 어려움이 있다.

4. 문화

외국인 개발자들이 한국에서 개발을 하면 문화적인 충격이 만만치 않다. 회사와 가정이 똑같이 소중한 외국인 개발자에게 무조건적인 헌신을 요구하는 경우가 많은데 상당히 어려움을 겪는다. 특히 야근 강요와 무리한 일정 요구는 많은 트러블을 일으킨다. 가끔은 후진국 사람이라고 무시하는 경향도 있다.

5. 전문가

우리나라 개발환경은 전문가가 제대로 일하기 어려운 환경이다. 보안 전문가를 데려다가 제대로 활용하지 못하기도 한다. 전문가들이 우리나라에 오면 그냥 똑같은 개발자가 되는 경우가 흔하다. 전문가가 제대로 역할을 하려면 스펙도 제대로 작성되어야 하고 합리적인 개발문화가 있어야 한다.

결론

이러한 현상은 외국에 외주를 줄 때도 비슷하다. 외국에 외주를 주거나 개발센터 설립등이 쉽지 않은 이유이다. 스펙을 제대로 작성하고 수평적인 조직구조 등 제대로된 개발문화를 가지고만 있다면 이 또한 해결될 수 있다.

2012년 10월 18일 목요일

스타트업을 위한 조직론

스타트업의 젊은 경영자 중에는 관리 경험이 부족하여 조직관리에 취약한 사람이 많다. 반대로 관리 경험이 많거나 특히 조직관리가 아주 철저한 대기업 출신들은 종종 스타트업에 걸맞지 않은 부담스런 관리 기법을 적용하여 효율성을 떨어뜨리곤 한다.

그럼 스타트업은 어떤 조직관리가 적합할까?

일반 기업에 적합한 조직관리 기법은 소프트웨어 회사와 맞지 않는다. 특히 작은 조직에는 적합하지 않다. 반대로 취미생활 하듯 조직을 관리하면 평생 구멍가게를 못 벗어난다. 전혀 준비가 안된 상태에서 비즈니스가 잘되면 조직은 커지고 회사가 급속도로 비효율적으로 변하게 마련이다. 비즈니스는 잘 되는데 이런 문제로 어려워진 회사를 많이들 알고 있을 것이다.

일반적인 소프트웨어 조직도 마찬가지지만 효율적인 소프트웨어 개발을 위해서는 특히 스타트업이라면 외형적인 조직관리는 Zero에 가까워야 한다. 대신에 몇 가지 필요한 요소가 있다.

첫째 기반시스템 활용

소프트웨어 회사에 필수적인 기반 시스템 두 가지는 SCM(소스코드관리시스템)과 ITS(이슈트랙시스템 또는 버그관리시스템)이다. 추가로 Wiki를 쓰기도 한다. 일반관리를 제외한 거의 모든 관리 부담은 기반시스템이 다 흡수를 한다.

이를 통해 별도 지시, 보고서 작성, 보고에 들어가는 품을 대폭 줄일 수 있다. 잘만 활용하면 10분의 1까지 줄일 수 있다. One-man 컴퍼니라면 시스템 대신 공책이나 엑셀을 쓰기도 하는데 회사가 커지면 문제가 된다. 혼자 일해도 기반시스템을 활용하는 것이 더 효율적이다. 시스템을 구축하는 비용과 관리부담을 걱정하곤 하는데 호스팅을 이용하면 된다.

Atlassian에서는 이슈트랙시스템인 Jira를 10명까지는 한 달에 만원이면 이용할 수 있다. Git나 Murcurial을 5명까지는 무료로 10명이면 한 달에 만원으로 무제한 용량을 사용할 수 있다. Wiki도 마찬가지다. Github를 이용할 수도 있다. 여기에 관한 자세한 내용은 추후 다시 다루겠다.

회사가 웬만큼 성장할 때까지는 이런 저렴한 호스팅을 사용하는 것이 효과적이다. 추후에 Migration도 문제없다. 보안문제를 걱정하곤 하는데 이는 기우이다.

둘째 문서다.

흔히 혼자서 또는 2,3명이 개발을 하면 문서가 필요 없다고 생각한다. 이는 사실이 아니다. 문서를 잘 작성하지 못하거나 제대로 작성해본 경험이 없거나 작성하기 싫어서 대는 핑계일 뿐이다. 문서를 작성하면서 개발을 하는 것이 더 빠르고 효율적이다.

좀더 정확하게 말하면 상황에 맞게 적절하게 작성해야 한다. 스펙을 작성할 때도 정말 간단하게 적을 수도 있고 Unit test가 일부를 대신하기도 하고 설계는 종이에 해도 된다. 또한 상당부분을 기반시스템이 보완하므로 정작 필요한 문서 양은 많지 않다. 조직이 적다고 변변한 문서도 없이 개발을 한다면 그 자체로 비효율적이고 조직이 커질수록 커뮤니케이션 비용이 급속도로 늘어나고 커뮤니케이션 오류로 인한 재작업 비용이 크게 증가한다.

셋째 역할구분이다.

스타트업에서는 개발자 한 명이 많은 역할을 한다. 기본적으로 기획, 분석/설계, 구현, 테스트, 디자인(종종), 기술영업, 기술지원 등 이루 말할 수 없는 많은 일을 한다. 그렇게 준비 없이 회사가 성장하면 개발자 인원수는 몇십배로 늘었는데 하는 일을 별반 다르지 않은 경우가 허다하다. 디자인과 테스트를 분리하기도 하지만 제대로 분리가 안되고 나머지 일들은 그대로 수행하는 경우가 많다.

이유는 개발자의 역할을 정확하게 정의를 하지 못해서 발생한다. 많은 경영자들은 이 모든 일들이 개발자가 원래 해야 할 일이라고 착각한다. 이를 방지하려면 조직의 전문성에 대한 이해가 먼저 필요하다.

혼자 일을 해도 기획, 개발, 테스트를 구분해서 일해야 한다. 필요한 문서도 만들어야 한다. 혼자 일해도 그렇게 일하는 것이 더 효율적이다. 그러다가 회사가 커지면 개발자만 N배로 늘리는 것이 아니고 적절한 비율로 전문적인 역할을 분리하고 프로세스를 만들어나가면 된다. 전문적인 조직으로 분리하는 순서와 비율은 회사마다 다르지만 보통의 순서는 테스트, UI디자인, 마케팅, 기술지원, 기술영업 등이다.

혼자 일해도 역할이 잘 구분되면 부족한 부분을 외주로 돌릴 수도 있다. 한두명이 일한다고 역할을 섞어서 일하면 다른 사람이 효과적으로 도와주기도 어려워진다.

지금까지 얘기한 방식은 스타트업에도 해당하지만 일반적인 소프트웨어 회사도 별반 다르지 않다. 처음부터 이런 조직관리를 준비해야 회사가 커져도 효율성을 계속 유지할 수 있다. 일반적인 회사는 인원이 20명, 50명, 100명, 300명을 넘어갈 때 큰 위기를 한번씩 맞는다.

관리 패러다임이 바뀌고 이때마다 여러 가지 관리기법을 추가한다. 이러한 방법은 소프트웨어 회사에는 잘 적용되지 않는다. 오히려 일반적인 회사의 관리 패러다임을 소프트웨어 회사에 적용하면 효율이 더 떨어진다. 소프트웨어 회사에는 소프트웨어 회사에 알맞은 관리가 필요하다.

이글은 Tech it에 기고한 글입니다.

2012년 10월 15일 월요일

생각은 쉽게 바뀌지 않는다.

많은 회사에서 경영자, 개발자들이 소프웨어를 좀더 효과적으로 개발하기 위해서 다양한 시도를 한다.

문서를 작성하고 소스코드를 관리하고 이슈를 관리하고 프로젝트 관리 기법을 도입한다. 이런 외형적인 시도를 해도 생각은 쉽게 바뀌지 않는다. 특히 경영자들의 마인드가 잘 바뀌지 않는다. 소프트웨어 개발을 제대로 이해하지 못했기 때문이다.

실리콘 밸리와 우리나라에서 소프트웨어를 개발할 때 가장 큰 차이를 보이는 것이 있다.

스펙을 바꾸는 것이 얼마나 큰 일인지에 대한 생각이다. 실리콘밸리에서는 스펙을 바꾸는 일이 개발팀에 엄청나게 큰 부담을 주고 일정과 비용이 영향을 주는지 경영진을 비롯한 모든 직원들이 알고 있기 때문에 스펙을 쉽게 바꾸려고 하지 않는다. 그렇기 때문에 스펙을 작성할 때 철저히 리뷰를 한다. 리뷰를 소홀히 하다가 나중에 빠진 거나 잘못된 것을 바꾸기가 쉽지 않기 때문이다. 그래서 스펙이 제대로 적히고 잘 검토가 되고 프로젝트에서 매우 중요한 역할을 한다.

그런데 우리나라에서는 스펙을 바꾸는 것이 얼마나 큰일인지 잘 인식하지 못한다. 경영자뿐만 아니라 개발자도 그런 경우가 많다. 어차피 주먹구구식으로 개발하기 때문에 스펙 변경을 대수롭지 않게 생각하거나 자포자기식 개발자도 많다. 그래서 스펙을 작성하기 않기도 하거나 대충 작성하다 마는 경우가 많다.

교육을 하고 설득을 하고 귀가 아프도록 얘기를 해도 피부로 느끼기 전에는 생각이 잘 바뀌지 않는다. 이는 방법론에 따라서 다른 얘기는 아니다. 이미 스펙이 결정된 후에는 어떠한 방법론에서도 스펙 변경은 큰 일이다.

물론 스펙 변경이 불가능한 것이 아니다. 비용 증가를 감수하고도 변경해야 할 이유가 있으면 합리적이고 적절한 절치를 통해서 변경해야 한다.

보통의 경영진은 프로젝트 진행 도중에 이런 저런 요구를 하고 싶게 마련이다. 프로젝트에 관여해서 영향력을 행사하고 싶은 욕구가 있는 경우도 있다. 이럴 때 요구사항을 잘 받아주는 개발자가 우리나라에서는 더 높은 평가를 받곤하지만 회사 전체적으로는 손해가 되는 일이다. 정말 급한 요구사항이 아니라면 다음 버전으로 미루면 되는 일이다.

소프트웨어 개발에서 스펙을 함부로 바꾸면 안된다는 것만 깨달으면 소프트웨어 공학의 80%는 터득한 것이다. 거의 대부분의 다른 문화는 다 여기서 파생된다. 안타까운 것은 외워서 되는 것이 아니라는 것이다.

2012년 10월 12일 금요일

스타트업과 궁합이 맞는 개발자

소프트웨어 스타트업의 두 가지 필수 요소를 꼽으라면 좋은 아이디어와 뛰어난 개발자이다.

개발자가 스스로 창업을 하기도 하지만 좋은 아이디어를 가지고 개발자 파트너를 물색하기도 하고 본인이 개발자라고 하더라도 추가로 개발자 파트너를 찾기도 한다. 좋은 개발자는 스타트업의 성공의 중요한 열쇠이지만 구하기 쉽지 않다. 또한, 어떠한 개발자가 스타트업에 꼭 필요한 개발자인지 판단하기 어렵다. 실력이 뛰어나 보이지만 막상 일을 그르치는 개발자도 있다.

만약 스타트업을 위해서 개발자 파트너를 찾고 있다면 어떤 조건이 필요한지 알아보자. 물론 일반적인 소프트웨어 회사에서 개발자를 선택하는 방법과 같은 조건도 있지만 사뭇 다른 요소도 있다.

1.특정 분야 유경험자?

개발자 채용이나 파트너 선택에서 흔히 하는 실수 중 하나가 특정 분야 유경험자의 가치를 너무 높게 보는 것이다.

물론 해당 분야의 경험이 풍부하다면 바로 실무에 투입되어서 일할 수 있는 장점이 있다. 스타트업이 아니고 이미 성숙된 회사라면 대부분 기존 제품 개발과정에서 변변한 기록도 없고 뒤죽박죽이라서 해당 분야에 경험이 풍부한 사람이 아니면 제대로 일할 수 없는 경우가 대부분이다. 그렇지 않은 경우도 있지만 드물다. 또한 개발자들이 많이 들어왔다 나갔다 하므로 무조건 당장 써먹을 수 있는 개발자를 선호한다.

하지만 스타트업이라면 얘기가 좀 다르다. 우선, 개발자 파트너를 특정 분야 유경험자로 한정 지으면 범위가 너무 좁아진다. 소프트웨어에는 수천 가지의 Domain이 있는데 그렇게 범위를 좁히면 좋은 개발자를 구하기 힘들어진다.

오랜 기간 한 분야에만 종사하고 있는 개발자들 중에는 의외로 소프트웨어 개발 능력은 형편 없는 경우가 매우 많다. 대신 Domain 지식만 풍부해서 해당 분야에서 조금만 벗어나도 별 쓸모가 없어지곤 한다. 특히 스타트업은 아직 개발해야 할 분야가 고정 되지 않았기 때문에 특정 분야 유경험자만 찾다가는 골치덩어리 개발자를 떠안게 될지도 모른다.

특정 분야 유경험자보다는 무조건 뛰어난 개발자를 골라야 한다. 분석, 설계, 구현 능력이 뛰어난 개발자가 분야가 바뀌어도 빠른 시간 내에 실력을 발휘할 수 있다. 처음에는 유경험자보다 약간 느릴 수 있지만 역전되는 것은 순식간이다.

실리콘밸리를 보더라도 개발자들이 특정 분야에 국한하지 않고 어떠한 소프트웨어 회사라도 마음대로 옮겨 다닐 수 있는 이유이다.

실리콘밸리에서 개발자를 채용할 때 특정 분야 유경험자보다는 문제 해결 능력이 뛰어난 개발자를 뽑는 것이 그 이유이다. 심지어는 사용하고 있는 개발 언어의 경험을 보지 않는 경우도 있다.

물론, 특정 분야 유경험자가 꼭 필요한 분야도 있기는 하지만 이는 일반적인 케이스가 아니므로 여기서는 언급하지 않는다.

2. 경험이 많은 개발자?

흔히 경험이 많은 개발자가 실력이 뛰어날 것으로 생각하는데 우리나라에서는 통하지 않는다. 물론 경험 많은 개발자 중에서 뛰어난 개발자가 꽤 있는 것은 사실이지만 기대하고 있는 것만큼 많지가 않다.

그 이유는 우리나라 개발 환경이라는 것이 막노동판과 비슷해서 초급 때 벽돌 100장 쌓던 사람이 고참이 되면 200장 쌓을 수 있는 식이다. 공사판 10년 경험이면 멋진 빌딩을 설계할 수 있을 것으로 기대하는 것과는 거리가 멀다. 제대로 된 분석, 설계 경험이 부족하고 개발문화라는 것이 너무 척박해서 오랫동안 개발을 한다고 해서 실력이 많이 향상되지 않는다. 단지, 숙달되고 능숙해지며 해당 분야의 지식이 주로 쌓인다. 여전히 분석, 설계 역량은 미천하고 개발문화는 잘 모르는 경우가 허다하다.

스타트업에는 차리라 경험이 적더라도 두뇌가 뛰어난 개발자가 필요하다. 경험이 너무 많은 것보다 경험은 적당하지만 머리가 좋은 개발자가 다양한 도전에서 뛰어난 결과물을 만들어낸다.

또한 경험이 너무 많으면 수많은 잘못된 문화와 관행에 너무 젖어서 스타트업에서 필요한 혁신을 해내지 못한다. 정말 뛰어난 두뇌를 가지고 있다면 경력이 1,2년이라도 전혀 문제가 되지 않는다. 기존 조직의 개발 문화에서는 별로 배울 것이 없기 때문이다. 기존 환경에서 배운 것이 적은 개발자들이 새로운 스타트업에서 더 좋은 개발문화를 정착할 가능성이 더 높다. 기존에 잘못된 관행에 젖어 있는 수많은 개발자들은 이를 부정하고 화를 낼 수도 있지만 그것이 곧 반증이다.

3. 빨리 개발하는 개발자?

스타트업은 다양한 시도와 빠른 전략이 매우 필요하다. 그래서 빨리 개발을 하는 개발자를 선호하지만 빨리 개발하는 개발자보다는 확실하게 마무리를 잘 해내는 개발자가 더 필요하다. 이는 개발자의 성향과 관련이 있다.

어떤 개발자는 첫 번째 프로토타입은 매우 빨리 만들어내지만 마무리를 제대로 못하는 개발자가 있고 약간은 느려 보이지만 착실하게 개발을 해서 꼼꼼하게 마무리를 하여 제품을 제대로 만들어 내는 개발자가 있다. 이러한 성향은 쉽게 바뀌는 것이 아니므로 일당백을 해야 하는 스타트업에서는 확실하게 마무리를 잘하는 개발자가 더 필요하다. 그렇게 개발하는 것이 최종적으로는 더 빠르다.

같이 일을 해본 경험이 있다면 이러한 개발자를 가려낼 수 있을 것이다.

4. 개성이 강한 개발자?

스타트업에서는 개발자의 실력보다 더 필요한 것이 과연 얼마나 뜻을 하나로 모아서 나아갈 수 있는가 이다. 이 또한 개발자의 성향과 관련이 있다. 회사의 정책이나 비전에 적극적으로 따르는 개발자가 있는가 하면 부정적이고 따로 행동하는 개발자가 있다. 회사의 정책과 비전을 따르지 않는 개발자는 실력이 아무리 뛰어나도 스타트업의 파트너로는 적당하지 않다. 실력만 보고 동참을 시켰다가 두고두고 고생을 하게 될 것이다.

개발자 하나하나가 영향력이 매우 큰 스타트업에서는 특히 중요한 조건이다.

5. 개인 시간이 소중해?

스타트업에서 꼭 필요한 것 중 하나가 멤버들의 헌신이다. 일반 회사에서 항상 야근을 강요하는 그런 헌신이 아니다. 회사에 시간과 노력과 위험부담을 같이 투자한 파트너들로서 미래의 결실을 공유하고자 하는 것이므로 헌신은 매우 필요하다. 따라서 헌신할 수 없는 개발자는 고려하지 않는 것이 좋다.

나이, 가정, 주변 환경이 헌신을 가로막는 경우도 고려를 해야 한다. 가장 중요한 것은 정신적으로 얼마나 헌신을 할 자세가 되어 있는가 이다. 이는 하루 아침에 판단할 수는 없고 스타트업의 중요한 개발자 파트너 구하기 위한 것이라면 꾸준히 관찰을 해야 알 수 있는 요소이다.

아이디어가 스타트업의 중요 요소이듯이 좋은 개발자도 꼭 필요한데 겉모습만 보고 대충 채용을 했다가는 차라리 시작을 안 하느니만 못한 경우가 많다. 몇 년 후에 창업을 생각하고 있다면 주변의 개발자 중에서 위 다섯 가지 조건이 맞는 개발자를 꾸준히 물색해둬야 한다. 그리고 친하게 지내라. 그 중에 한 두명이 당신의 스타트업 파트너가 될 것이다.

이 글은 Tech it에 기고한 글입니다.

2012년 9월 27일 목요일

스타트업의 착각들

필자는 많은 스타트업을 만날 기회가 있고 가끔은 스타트업 파운더가 우리 회사를 찾아와서 도움을 요청하기도 한다. 처음 만나면 먼저 회사의 전략이 무엇인지 물어보는데 여러가지 일이 벌어진다.

대부분은 파운더들이 자신들의 전략을 제대로 설명하지 못한다. 한참을 들어도 무슨 말인지 잘 이해가 안 되는 경우가 많고 이해가 살짝 되도 “이거 되겠는데”라는 생각이 바로 안 든다. 이런 경우는 제대로 된 전략이 없거나 좋은 전략이 있는데 설명을 잘 못하는 경우이다. 두 가지 다 문제이기는 마찬가지다.

자신의 분야에서만 통용되는 전문용어를 섞어가면서 기승전결 없이 마구 설명하면 대부분의 사람들이 이해하지 못하고 호응을 끌어낼 수 없다. 회사의 전략을 제대로 설득할 수 있는 것은 매우 중요하다. 이 통해 투자를 유치하고 파트너와 비즈니스를 도모한다. 직원을 뽑을 때도 회사의 전략과 비전을 보여주고 뽑는다.

“30초 엘리베이터 스피치”라는 것이 있다.

엘리베이터를 타고 사무실에 올라 가면서 30초 동안 사장에게 자신의 제안 내용을 설명해서 OK를 얻어내는 것이다. 그러기 위해서는 장황하게 설명해서는 안 된다. 30초 동안 핵심 내용을 간결하게 사장님이 알 수 있는 용어로 설득력 있게 설명하는 것이 “30초 엘리베이터 스피치”다.

회사의 전략은 “30초 엘리베이터 스피치”와 같이 설명할 수 있어야 한다. 스타트업이라면 모든 직원이 자기 회사의 전략을 제대로 설명할 수 있어야 한다. 지금 당장 친구에게 전략을 설명해보자. “오! 이거 끝내주는데”라는 반응이 오나 보자. 그렇지 않다면 전략이 신통치 않거나 설명을 제대로 못한 것이다.

그럼 본론으로 돌아와서 스타트업들이 가지고 있는 착각에는 무엇이 있는지 알아보자.

1. 세계 최초

많은 스타트업들은 자신들이 세계 최초라고 주장하고 그렇게 믿고 있다. 우리나라에서는 세계 최초라는 말을 너무 많이 들어서 이제는 식상할 정도이다. 세계 최초가 매우 중요한 경우도 있지만 대부분은 중요하지 않다. 세계 최초보다는 고객이 원하는 것을 주는 것이 더 중요하다. 성공한 대부분의 스타트업들은 세계 최초가 아님에도 크게 성공을 했다.

세계 최초라고 주장을 할 때 사실은 세계 최초가 아니거나 세계 최초라고 해도 별 의미가 없는 경우가 99%이다.

첫 번째 경우는 세계 최초가 아니고 “내가 생각하기에는 세계 최초”이다. 전세계에서 무슨 일이 벌어지는 다 알 수 없기 때문에 우물 안에서 세계 최초인 것이다. 둘째 세계 최초라고 해도 고객이 원하지 않거나 별로 가치가 없는 경우에는 적당한 비즈니스 전략이 아니다.

세계 최초를 쫓을 것이 아니라 들으면 무릎을 딱 치게 만드는 고객이 필요를 충족시켜 주는 전략이 되어야 한다.

2. 아무나 못 만든다.

우리 소프트웨어는 워낙 기술이 어려워서 다른 회사는 흉내내지 못하다고 말하는 경우를 종종 본다. 이런 경우 경영자가 개발자들에게 속고 있는 경우가 많다. 진짜 어려운 기술인 경우는 그리 많지 않다.

스타트업이 접근하기 쉬운 전략은 정말 어려운 기술이 아니라 대기업은 손대기 힘든 작은 시장이다. 요즘은 조금 바뀌었지만 Global 기업이나 대기업들은 메이저 시장이 아니면 웬만하면 뛰어들지 않는다. 그런 니치마켓에는 스타트업이 아이디어를 가지고 공략할 수 있는 타깃이 많이 있고, 지역별로 특수한 시장을 공략하는 것도 좋은 전략이다. 이미 성장한 메이저 시장은 큰 자본이 아니면 공략하기 어렵다.

스타트업이 니치마켓이라고 공략한 시장이 전세계를 주도하는 커다란 시장으로 성장하는 사례를 우리는 많이 봐왔다. 스타트업이라면 틈새를 잘 노려야 한다.

두 가지를 합쳐서 좋은 전략도 있다. 기술은 적당히 어려운데 시장이 작아서 메이저 업체들이 뛰어들지 않은 경우 경쟁대상 업체들 중에는 독보적인 기술을 보유할 수는 있다. 이것은 매우 좋은 전략 중 하나이지만 시장이 성장하면 메이저 업체들의 먹이가 될 수 있으므로 항상 대비를 해야 한다.

3. 우리 개발자들은 실력이 세계 최고

자신감은 좋지만 자만심은 금물이다. 흔히 실리콘밸리 개발자보다 우리나라 개발자들이 실력은 더 뛰어나다는 주장을 하곤 한다. 하지만 이는 내가 아는 한 사실이 아니다. 우리나라 개발자들이 못한다는 것이 아니고 각 개인차일 뿐이고 어디나 잘하는 개발자가 있고 못하는 개발자들이 있다. 실리콘밸리에 뛰어난 개발자가 더 많을 가능성이 더 높기는 하다. 왜냐하면 소프트웨어 개발자는 미국에서 최고의 직업 중 하나이기 때문에 최고의 두뇌들이 선택하는 전공과 직업이다.

또한 좋은 소프트웨어 개발문화가 자리 잡고 있어서 그 속에서는 개발자가 더 잘 성장할 수 있다. 초급개발자끼리 비교하는 것은 승산이 있어도 10년, 20년 이상 경력의 개발자를 비교하면 우리가 밀릴 가능성이 매우 높다. 실제로 내가 만나본 실리콘밸리 개발자들은 분석, 설계, 코딩 능력에서 압도적인 능력을 가지고 있었다. 우리나라 개발자들도 뛰어난 개발자들이 많지만 고개를 갸우뚱하게 만드는 고참개발자도 매우 많다.

스타트업에는 우수한 개발자가 필요는 하다. 한 사람이 일당백의 역할을 해야 하기 때문이다. 그렇다고 전국구의 최고의 개발자가 꼭 필요한 것은 아니다. 고객이 원하는 것을 잘 만들어내고 마무리를 잘 할 수 있는 실력과 경험이 있으면 된다. 천재가 아니면 만들 수 없는 소프트웨어는 그리 많지 않다. 또한 회사가 성장하면 뛰어난 개발자 소수와 대부분의 괜찮은 개발자로 개발팀을 꾸리면 된다.

핵심은 천재는 아닌 개발자들과 함께 좋은 전략과 기획, 그리고 잘 쓰여진 스펙과 설계를 가지고 잘 개발할 수 있는 문화 및 프로세스를 자리잡게 하는 것이다.

4. 남들은 운이 좋아서 성공했다.

스타트업으로 시작해서 현재 Global하게 성공한 회사들을 보면 왠지 대부분 운이 좋았던 것 같다. 정말 운이 좋아서 성공할 가능성보다 잘했는데 운이 나빠서 실패할 가능성이 훨씬 높다. 아이디어, 전략, 기술력 모두 뛰어나지만 억세게 재수가 없어서 IMF를 만나서 실패하거나 Global 회사의 무료 공개 전략으로 시장 자체가 사라져 버려서 망하는 경우가 종종 있다. 중견기업 이상이 되면 이를 버틸 체력이 있지만 스트타업은 한번에 쓰러지기도 한다. 이런 천재지변은 어쩔 수 없다.

반대로 별것 없는데 지독하게 운이 좋아서 성공한 것이라고 생각했는데 그 속을 보면 대단한 노력과 실력이 있는 경우가 많다. 얼마 전 싸이(Psy)가 인터뷰에서 어떤 철학자가 말하길 “노력이 기회를 만나면 운”이라고 했다. 거의 대부분은 성공 뒤에는 노력이 있다. 스타트업은 앉아서 기회를 기다리는 것이 아니고 끊임 없이 기회를 찾아서 자신의 운으로 만나는 노력을 해야 한다.

그러기 위해서 빨리 실패를 인정하고 창의적으로 새로운 것을 받아들이고 기회를 옅보는 전략이 필요하다.

스타트업들은 번뜩이는 아이디어 또는 뛰어난 기술을 가진 대신 전략이 빈약한 경우가 매우 많다. 실리콘밸리만 하더라도 들으면 환상적인 아이디어와 뛰어난 전략의 수많은 기획서가 투자자들의 투자를 기다리고 있다. 하나하나 다 성공할 것 같은 기가 막힌 아이디어이고 전략인데 이중에 95%가 3년 안에 망한다고 한다. 스타트업의 전략을 딱 들으면 주머니에서 돈을 꺼내서 투자할 수 있을 정도로 기가 막히지 않으면 전략을 바꾸거나 전략을 설명하는 방법을 가다듬어야 한다. 그러고 나서야 5%의 터널에 진입할 준비가 된 것이다.