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

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

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

1. 소스코드관리시스템

필요성: ★★★★★

추천 형태: 호스팅

추천 서비스: Bitbucket, Github

추천 시스템: Git, SVN

소스코드관리시스템이 없이 소프트웨어를 개발한다는 것은 상식적으로는 도저히 불가능하다. 자체적으로 구축하는 것도 가능하지만 호스팅을 권장한다. 소스코드관리시스템을 직접 구축하여 운영하려면 하드웨어 구매 비용, 관리 비용 등 만만치 않은 비용이 들어간다. 하지만 호스팅을 이용할 경우 그 수십 분의 일의 비용으로 해결할 수 있다.

호스팅으로 SVN을 이용할 경우 네트워크 속도가 느릴 경우 불편함이 있지만 DVCS(분산버전관리시스템)인 Git를 사용할 경우 문제가 많이 해결된다. Git는 SVN 사용자가 쉽게 사용할 수 있도록 거의 비슷한 명령어 체계도 갖고 있다. 요즘은 Git도 편리한 GUI Client가 많아 SVN만큼 편하게 쓸 수 있다.Git는 기능이 너무 많아 어려워하는 개발자들도 있는데 SVN을 사용하던 방식과 거의 유사하게 사용할 수도 있으므로 시도해보기 바란다.

Git 호스팅 서비스인 Bitbucket.org를 이용하면 5명까지는 무료로 10명은 월 $10, 100명은 월 $100를 내면 된다. 100명 정도까지는 호스팅을 이용하는 것이 훨씬 비용적으로 유리하다고 할 수 있다.

2. 이슈관리시스템 (버그추적시스템)

필요성: ★★★★★

추천 형태: 호스팅

추천 서비스: Atlassian Jira OnDemand

추천 시스템: Jira, Redmine

요즘은 소스코드관리시스템을 아예 사용하지 않는 소프트웨어 회사가 거의 없지만 의외로 아직 이슈관리시스템을 사용하지 않는 회사는 많다. 엑셀이나 위키를 이용하거나 Email로 처리하는 회사도 있다. 그렇게 해서는 방대한 소프트웨어 개발 이슈를 효과적으로 처리할 수도 없고 많은 커뮤니케이션 비용이 들어간다. 수십 년 동안 진화를 거듭해온 이슈관리시스템들은 제대로 사용하기만 해도 회사 개발문화가 상당히 성숙하게 바뀔 수 있다. 아직 이슈관리시스템을 사용하고 있지 않다면 당장 도입하기 바란다.

과거에는 Trac, Mantis 등이 많이 사용되었다. 여전히 좋은 시스템들이지만 모든 것을 비교해보면 요즘은 Jira와 Redmine을 추천한다. 이슈관리시스템도 비용적인 측면에서 호스팅을 권장하고 Atlassian의 Jira OnDemand을 추천한다. 10명까지는 월 $10, 25명은 월 $100면 된다. OnDemand 스타트업을 위한 저렴한 비용을 제시하고 있다. 회사가 커지면 나중에 직접 구축하고 그 동안 쌓아 놓은 데이터는 마이그레이션이 가능하다.

3. 빌드시스템

필요성: ★★★☆☆

추천 형태: 자체 구축

추천 시스템: 자동화된 빌드 스크립트 자체 제작, Jenkins (구 Hudson)

위에서부터 점점 내려올수록 사용하고 있는 비율이 줄어든다. 빌드시스템은 소프트웨어 개발에 꼭 필요한 시스템이다. 많은 회사가 개발자 PC에서 Eclipse나 Visual Studio의 IDE창에서 버튼을 눌러 빌드한 소프트웨어를 그냥 출시하곤 한다. 소프트웨어 개발에서 개발자 PC는 “더러운 환경”이라고 지칭한다. 테스트를 하거나 출시를 위한 소프트웨어는 깨끗한 빌드 전용 “빌드시스템”에서 빌드해야 한다. 또 자동화된 빌드 스크립트를 제작해서 One-step으로 모든 빌드가 끝나야 한다.

적어도 하루에 한번은 자동으로 빌드를 실행하여 소스코드가 항상 빌드가 가능한 상태로도 유지해야 한다. 이를 Daily Build라고 부른다. 소수가 개발하면 이런 것 신경 안 써도 어쨌든 개발이 되기 때문에 소홀하기 쉽다. 하지만 “더러운 환경”에서 대충 개발하는 것은 대단히 위험한 일이고 Daily Build를 하지 않는 것은 협업의 기본을 모르는 행위다. 빌드시스템은 자체적으로 구축해야 한다면 Daily build나 CI(지속적인 통합)을 위해 Jenkins등의 CI툴을 이용하면 좋다.

4. Wiki

필요성: ★★☆☆☆

추천 형태: 호스팅

추천 시스템: Confluence OnDemand

꼭 사용해야 하는 시스템도 아니고 특별히 추천을 하고 싶은 서비스도 없지만 Atlassian의 호스팅 서비스를 이용하면 연동이 쉬운 같은 서비스를 이용하는 것이 좋겠다. 비용도 Jira OnDemand와 같다.

Jira를 이용해도 상당히 많은 정보가 공유되지만, Wiki는 흩어져 있는 지식과 정보를 한군데로 모으는데 효과적이다. 하지만 Wiki는 결국 Tool이기 때문에 문서를 대신 작성해주지는 않는다. 그렇다고 Wiki를 사용하기 위해서 강제로 문서화를 시도하다가는 Wiki가 방치되기 십상이다.

스펙도 작성할 능력이 좀 되고 문서화에 거부감이 없다면 Wiki를 도입하는 것도 괜찮다. 모든 문서를 Wiki가 대신할 수 없지만 많은 지식을 체계적으로 정리할 수 있는데는 유용하다. 훌륭한 회사 자산도 될 수 있고 효율적인 소프트웨어 개발에 많은 도움을 준다.

5. 프로젝트관리시스템

필요성: ☆☆☆☆☆

추천 시스템: 시스템보다는 엑셀 파일 이용

시스템을 잘못 사용하면 배보다 배꼽이 더 큰 경우다. 좋은 프로젝트관리시스템이 많기는 하지만 대부분 스타트업이 사용하기 무거운 제품들이다. 프로젝트가 지연되는 것은 프로젝트관리시스템을 사용하지 않아서가 아니다. 스펙을 제대로 작성하지 않아서 지연되는 경우가 대부분이다. 스펙이 잘 작성되어야 개발범위가 명확해지고 상세한 개발일정 수립이 가능하다.

일 단위의 개발일정이 수립되면 엑셀에 작성을 해서 관리해도 충분하다. 오히려 웬만한 프로젝트관리시스템들보다 엑셀이 더 편리하다. 회사가 좀더 커져서 수많은 프로젝트와 인력을 동시에 관리해야 할 때 프로젝트관리시스템 도입을 검토해보는 것이 좋겠다.

기반시스템은 도입하는 것보다 제대로 사용하는 것이 더 중요하다. 각 기반시스템을 사용하는데 꼭 지켜야 할 규칙을 몇 가지 제시한다.

소스코드관리시스템

1. 회사의 모든 소스코드 및 개발문서는 빠짐없이 등록해야 한다.

2. 커밋 메시지 규칙, 리뷰 규칙 등 회사의 규칙을 모든 직원이 철저히 따라야 한다.

3. 공식적인 빌드는 항상 Tag(베이스라인)를 남겨야 한다.

4. 협업을 위한 코딩 습관을 가져야 한다. 즉, 머지(Merge)가 원활하게 되게 해야 한다. 소스트리를 견고하게 가져가야 하며 개발자가 함부로 파일의 이름을 바꾸거나 이동하면 안 된다. 소스코드 내에서도 함수를 이리 저리 옮기면 안 된다. 이외에도 지켜야 할 수많은 습관들이 있는데 협업을 하면서 차츰 익히면 된다.

이슈관리시스템

1. 전 직원이 모든 이슈를 이슈관리시스템에 직접 등록해야 한다. 대리 등록은 사양한다.

2. Email, 구두, 전화, 메신저 등 다른 경로를 통한 요청은 없애나가야 한다.

3. 스스로 능동적으로 이슈관리시스템을 모니터링 해야 한다. 사장이라도 필요한 정보는 보고를 요청하지 말고 이슈관리시스템을 통해서 확인하면 된다.

4. 모든 이슈는 전 직원에 오픈한다.

지금까지 스타트업에 필요한 기반시스템과 기본적인 사용규칙에 대해서 설명했다. 기반시스템을 사용하는 것만으로 회사 역량이 세계적인 수준이 되는 것은 아니다. 그야말로 기초 중에 기초일 뿐이다. 하지만 그러한 기초도 안되어 있다면 엄청나게 비효율적으로 개발을 하고 있는 것이다.

기반시스템은 일단 경험을 해보고 제대로 사용하기 시작하면 절대로 과거로 돌아가지 못한다. 때때로 과거에는 이런 좋은 시스템도 없이 왜 그렇게 고생을 했을까 회상하기도 한다. 물론 그때는 비효율적이라는 것을 몰랐었다.

소프트웨어 회사라면 이런 기본적인 것을 잘 갖춰야 진정한 역량인 분석, 설계 등의 역량을 향상시킬 수 있다. 아직 기반시스템을 제대로 갖추고 있지 않은 회사는 저렴한 호스팅 서비스부터 당장 갖추기 바란다. 시작이 반이다. 제대로 사용하기는 어렵지만 차츰 실력이 붙을 것이다. 혹시 어려움이 있거나 궁금한 것이 있다면 나에게 문의하기 바란다.

이글은 Techit에 기고한 글입니다.

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

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

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

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

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

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

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

1. 언어의 장벽

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

2. 문서

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

3. 번역

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

4. 문화

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

5. 전문가

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

결론 

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

스타트업을 위한 조직론

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

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

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

일반적인 소프트웨어 조직도 마찬가지지만 효율적인 소프트웨어 개발을 위해서는 특히 스타트업이라면 외형적인 조직관리는 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에 기고한 글입니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.특정 분야 유경험자?

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

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

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

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

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

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

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

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

2. 경험이 많은 개발자?

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

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

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

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

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

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

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

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

4. 개성이 강한 개발자?

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

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

5. 개인 시간이 소중해?

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

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

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

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

스타트업의 착각들

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

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

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

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

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

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

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

1. 세계 최초

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

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

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

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

2. 아무나 못 만든다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

소프트웨어 개발시 일을 작게 쪼개야 하는 이유

대부분의 소프트웨어는 수명에서 수백명, 많게는 수천명이 같이 개발한다. 그래서 효과적으로 일을 나눠서 개발할 수 있어야 한다. 심지어는 혼자서 개발을 할 때도 일을 쪼개야 한다. 

왜 일은 쪼개야 하고 어떻게 쪼개야 하는것일까? 대부분의 다른 산업 분야는 일을 잘 쪼깬다. 시계하나를 개발해도 각 부품을 따로 개발해서 조립한다. 따로 개발하기 전에 이미 어떻게 연결이 되는지 인터페이스를 완벽하게 정의하고 개발한다. 그렇지 않으며 나중에 조립이 안되서 처음부터 다시 개발해야 할 수도 있다.

소프트웨어 프로젝트에서 일을 서로 어떻게 나눠서 개발을 하고 있는지 생각해보자. 

흔히 사용하는 방법이 화면 단위로 일을 나누는 것이다. 이 방법은 일을 나누기는 쉬워보이지만 문제가 많다. 나눠서 한 일이 서로 통합이 잘 안되고, 서로 중복된 개발도 많이 하게 된다. 다 개발해 놓고 서로 맞추는데 많은 시간을 소모하곤 한다.

일을 효과적으로 쪼개는 방법은 프로그램을 컴포넌트 단위로 잘 쪼개는 것이다. 컴포넌트는 특정 일을 담당하는 모듈로서 Class일 수도 있고, Class의 집합일 수도 있고, 함수의 집합일 수도 있다. 형태는 별로 중요하지 않다. 중요한 것은 컴포넌트의 외부 인터페이스가 간단하고 명료하게 잘 정의가 되면 되는 것이다.

분석/설계 과정에서 컴포넌트의 인터페이스가 잘 정의되면 많은 개발자들이 일을 나눠서 할 수 있게 된다. 10명이 개발을 하다가 시간이 부족하여 5명을 추가로 더 투입해도 큰 문제없이 개발이 가능하다.

서로 의존성이 있는 모듈들을 동시에 개발할 수 있게 된다. 특정 컴포넌트의 개발이 완료되어야 동작하는 모듈도 인터페이스가 확정되어 있으면 미리 개발을 할 수 있다. 개발 기간이 단축되는 것이다. 물론 모든 모듈이 다 개발되어야 테스트가 가능하지만 구현은 미리 해 놓을 수 있다.

또, 일부 모듈은 외주를 주는 것도 가능해진다.

이렇게 소프트웨어를 컴포넌트로 잘 나누게 되면 그 과정에서 문서화가 되고 서로 리뷰를 통해서 문제점을 발견하고 가장 뛰어난 아키텍처를 만들 수 있다. 또한 작업의 단위가 작아야 일정을 충분히 예측할 수 있다.

코딩을 시작하기 전에 이미 문서를 통해서 검증이 되고 공유가 된다. 그래야 변경이 최소화되고 가장 빠르게 소프트웨어를 개발할 수 있다.

분석 과정에서 부터 이미 주요 컴포넌트를 나누는 작업이 시작되고 외부 인터페이스를 정의하게 된다. 설계의 정도는 프로젝트마다 매우 다르지만 컴포넌트를 좀더 작게 나누고 function prototype까지 정의를 하면 설계가 완성된다. 간단한 프로젝트인 경우에는 스펙에서 정의한 컴포넌트와 인터페이스만 가지고 별도의 자세한 설계 없이 구현이 가능하다.

이렇게 일을 쪼개는 이유는 소프트웨어를 가장 빨리 개발하기 위한 것이다. 그렇지 않고 그냥 대충 일을 나눠서 서로 뭉쳐서 긴밀하게 의논해가면서 개발을 하는 것이 더 빨라 보인다고 생각하는 사람들이 매우 많다. 이 방법은 초기에 빠른 결과물을 보여주어서 초반에는 빨라 보이지만 결국 통합에서 지연되고 많은 재작업으로 시간을 소비하고 버그를 더 많이 만들어내어서 또 지연된다.

당장 코딩부터 시작하기 보다 생각을 더 많이 해서 컴포넌트를 잘 나눠 일을 쪼개서 재작업을 최소화하고 한번에 구현을 해 내는 것이 소프트웨어를 개발하는 가장 빠른 방법이다.