실리콘밸리 개발자 눈에 비친 한국 SW회사

얼마 전 실리콘밸리의 한 개발자 B씨를 만나서 소프트웨어 개발에 대해 많은 얘기를 나눴다. 과거에 같이 일했던 친구인데 미국에서 태어난 중국인으로 미국 대학을 나와 실리콘밸리에서 20여년간 개발자로 일을 했으며 10여년간은 몇몇 회사에서 CTO로 있었던 친구다. 

B씨는 최근에 한국 소프트웨어 회사(가칭 A사)와 많은 교류를 한 모양이다. 한국 회사에 자사 기술을 전수하기 위해서 실리콘밸리와 한국을 오가며 수개월간 한국 개발자들과 같이 개발을 해왔다고 한다. 그 과정에서 A사에 대해서 느낀 점을 필자에게 얘기를 해줬는데 A사 뿐만 아니라 우리나라 여러 회사에 공통적으로 해당하는 내용이 있어 소개할까 한다. 

B씨는 일단 처음에 A사가 어떻게 돌아가는지 파악했다.  그런데 이상한 생각이 들었다고 한다. 규모가 꽤 큰 서비스인데 시스템에 버그가 너무 많고 문제가 자주 발생한 것이다.

직원들의 야근도 너무 잦았다. 또 스크럼을 도입해 개발한다고 하는데 제대로 효과를 보는 것 같지는 않아 보였다. 그런만큼 B씨는 A사가 스크럼이든 설계든 개발 절차에 담긴 진의를 파악하지 못하고 형식만 흉내를 내는 것이 아닌가 생각이 들었다고 한다. 

이에 나는 B씨에게 “설계에서 제일 중요한 것이 무엇인가?”라고 질문했다. B씨는 “설계에서 제일 중요한 것은 콤포넌트를 잘 나누는 것”이라는 당연한 얘기를 했다.

B씨는 계속 얘기를 했다. 설계에 UML을 사용했는데 보통 UML은 필요가 없다. 우리는 대부분 칠판에 설계를 하다가 고치기를 반복한 후 사진을 찍어서 문서에 포함한다. 툴을 이용해서 다시 그리는 것은 시간 낭비다. 마지막 버전을 툴로 그리기도 하는데 정해진 툴도 없다. UML을 이용해서 쓸모도 없는 다이어그램을 잔뜩 만든 문서는 개발에 도움이 안되고 오히려 방해가 된다. 툴을 이용하면 칠판보다 고치기가 어렵고 다이어그램을 많이 그릴수록 고치는데 시간이 많이 들어가 바로 고칠 수가 없다. 또 A사 설계는 콤포넌트가 명확히 구분되어 있지 않아서 나눠서 협업하기 어려웠고 반대로 설계 내용은 너무 상세해서 오히려 비효율적이었다. 

나도 동감을 했다. 개발자가 알아서 할 부분까지 설계를 할 필요는 없다. 겉보기에는 A사의 설계서가 실리콘밸리의 한 개발자가 칠판에 끄적거린 설계서보다 멋져 보이고 전문적인 것 같지만 실전에선 훨씬 비효율적이다.  

설계를 어떻게 해야 하는지는 소프트웨어 성격에 따라 다르지만 설계 원리와 진의를 모르고 많은 다이어그램과 상세한 설계서는 식제 개발을 할때는 별로 도움이 되지 않는다. 많은 회사들이 UML 등을 이용해 완벽한 설계서를 만들려고 하는 경우가  많은데 그런 시도가 성공적이었는지 생각해볼 필요가 있다. 

B씨가 A사에 대해 또 이상하게 생각한 것은 애자일(Agile)을 적용한 방식이다. 실리콘밸리 스타트업은 거의 대부분 애자일 개발 방법론을 적용하고 있다고 보면 된다. 애자일은 특별한 것이 아니다. 과거부터 해오던 방식과 비슷하다. XP를 도입한 회사도 있고 스크럼을 쓰는 회사도 있는데 회사마다 필요한 것을 활용하고 있다. B씨 회사는 XP의 페어 프로그래밍(Pair programming)과 TDD를 사용중이다. 

과거 프로젝트에서는SRS를 썼는데 지금은 TDD로 바꿨다. 테스트는 거의 자동화 되어 있고 별도 테스터가 없어도 시스템에 버그는 거의 없다. A사의 경우 컨설팅을 받아 애자일을 적용했는데 들어보면 별로 애자일스럽지 않아 보인다. 마케팅적으로 요구사항이 신속히 바뀔 뿐인 것 같다. 

시스템이 복잡하여 야근도 잦은 것 같다. 또 개발자의 자유도도 낮아 보인다. 쓸데없는 문서도 많이 만들어야 하고 테스트도 오래 걸린다. 그러다 보니 시스템에는 항상 버그가 잔뜩 있다. 

이상한 점은 또 있다. 비싼 툴을 너무 많이 쓴다는 것이다. 그 친구는 실리콘밸리에서 주로 스타트업 에 많이 다녔는데, 한국 회사처럼 툴을 그렇게 많이 사용하지는 않았다고 한다. 지금 다니는 회사는 서브버전(Subversion)과 트랙(Trac)만 쓰고 있는데 회사를 지금 시작했다면 Git를 선택했을 것이라고 한다. 그렇다고 굳이 지금 서브버전을 Git로 바꿀 생각은 없다. 

나머지 필요한 툴은 간단한 스크립트로 만들어서 쓰고 있다. 그에 비해 A사를 비롯해서 많은 한국 회사들은 일단 툴을 많이 사용한다.  비싼 툴을 사는 경우도 상당히 많다. 회사 역량에 비해서 툴을 과도하게 사용하는 것은 그렇게 효율적이지 않다. 툴은 하나를 쓰더라도 제대로 사용해야 한다. 

그리고 A사는 직원들에게 노트북을 지급했다고 하는데 직원들이 노트북을 집에 가져가서 일을 하지 않는 점이 이상하다. 실리콘밸리에서 스타트업에 다니는 개발자들은 거의 노트북을 집에 가져가서 장소를 구분하지 않고 일을 한다. 개발자마다 다르지만 그 친구는 늦게 출근하고 일찍 퇴근하지만 노트북을 가지고 다니면서 장소에 구애 받지 않고 하루에 10시간 이상 일을 한다고 한다. 

A사는 야근도 꽤 많이 하지만 집에 가서는 일을 하지 않는 것이 이상해 보였다. 한국의 모든 개발자가 그런 것은 아니지만 재택근무가 일상화된 실리콘밸리와 한국은 좀 다른 것 같다. 

물론 한 개인이 한 회사를 보고 느낀 점을 얘기한 것이기 때문에 우리나라의 모든 회사가 그렇다는 것은 아니다. 그렇지만 B씨와 나눈 얘기들에서 생각해 볼 요소는 많다. 국내 여러 기업이 실리콘밸리의 개발문화와 개발방식을 적용하려고 노력하고 있지만 대부분 원리와 의미는 파악하지 못하고 수박 겉핧기 식으로 형식만 흉내를 내고 있다. 

설계는 하지만 설계를 왜 하는지를 잘 모르고 애자일을 적용하면서 그 원리를 모르고 남들은 어떻게 하는지 보고 흉내를 내는 것이다. 원리는 같지만 회사마다 적용하는 방식이 다르기 때문에 남들을 보고 흉내 내거나 인터넷이나 책을 보고 적용하면 이런 현상이 벌어진다. 

단순 흉내에서 벗어나려면 무엇을 하나 하더라도 그 진의를 파악하는데 노력해야 한다. 주변에서 흔히 "남들은 어떻게 하나요?", "템플릿(Template)을 가져다 주면 해볼께요.", "샘플을 보여주세요."와 같은 얘기를 한다. 남들이 만들어 놓은 설계서 샘플을 가져다가 흉내를 내면 자칫 아니 한만 못한 경우도 많다. 샘플이 득보다는 독이 되는 경우가 많다. 

샘플보다는 이걸 왜 하는지 원리를 파악하려고 노력해야 한다. 스스로 진의를 파악하기 어렵다면 주변에 멘토가 될만한 사람에게 물어보고 도움을 받는 것이 좋다.

이글은 ZDNet에 기고한 칼럼입니다.

대한민국 개발자가 불행한 이유

미국에서 과거 10년 넘게 최고의 직업에 항상 소프트웨어 개발자와 아키텍트가 자리하고 있고 미래 성장 가능성도 상당히 높게 평가하고 있는 것을 보면 격세지감을 느낀다. 10개나 100개 직업 중에 1위가 아니고 몇 만개의 직업 중에 1위라는 것은 대단한 것이다. 그러나 우리나라에서 소프트웨어 개발자는 그렇게 인기가 있는 직종이 아니다. 의사, 변호사와 비교는 고사하고 3D 직업이라는 인식도 팽배하다.

이는 단순히 소득의 차이 때문은 아닌 것 같다.

우리나라에서 소프트웨어 개발자로 일하게 되면 10년, 20년 그리고 30년 이상 소프트웨어 개발자로 계속 일할 수 있다는 희망이 잘 보이지 않는다. 왜 그럴까? 이런 환경에서 태어난 대한민국의 소프트웨어 개발자는 불행하다고 할 수 있다. 미국이라고 무조건 개발자로서 성공적인 삶을 사는 것은 아니지만 같은 조건이라면 개발자로 잘 성장할 확률이 더 높고 여건도 좋다.

이런 차이가 발생하는 이유는 타고난 재능의 차이도 아니다. 개발자들의 기술력의 차이도 아니다. 바로 환경의 차이 때문이다. 소프트웨어 산업 생태계의 차이도 크지만 각 회사, 개발팀의 개발 문화 차이가 가장 크다. 이런 개발 환경을 만든 것은 개발자 여러분은 아니고 여러분의 선배들과 회사이다.

지금 이 글을 읽고 있는 소프트웨어 개발자가 만약에 미국에서 태어나 소프트웨어 개발자로 일하고 있다면 상당히 다른 환경에서 다른 경험을 하면서 성장할 것이다.

물론 우리나라가 더 좋은 환경을 가지고 있는 것도 있고, 내세울 수 있는 것도 있지만 소프트웨어 환경에 대해서는 이 땅에서 태어나 영어 때문에 고생하는 것처럼 핸디캡이 되는 것은 사실이다.

소프트웨어 선진국은 개발 프로세스, 기반 시스템, 조직 문화, 개발 문화 측면에서 큰 차이가 있고 성장을 도와줄 선배 개발자들이 많고 롤모델(Role model)도  있다. 우리나라에도 선배 개발자들이 많이 있지만 경험의 전수가 잘 안되는 구조가 문제다. 여기서 선순환과 악순환의 차이가 발생한다.

소프트웨어 선진국에선 입사를 하면 대부분 바로  업무에 투입된다. 문서, 시스템이 잘 갖춰져 있어서 버그를 수정하는 일을 하는데 큰 어려움이 없다. 버그추적시스템을 통해서도 버그를 할당 받고, 많은 정보를 얻을 수 있다. 소스코드는 시스템을 통해서 바로 한줄 한줄의 수정된 역사를 볼 수 있고 내용을 물어보러 다니지 않아도 웬만한 버그는 수정이 가능하다. 빌드도 자동화 되어 있어서 내용을 몰라도 누구에게 물어보지 않고도 한번에 빌드가 된다. 또한 내가 고친 코드는 피어 리뷰(Peer review)를 통해서 코딩 컨벤션 준수 여부뿐만 아니라 더 좋은 기법 등을 배운다. 분석, 설계 등에도 참여하고 지속적인 피어 리뷰를 거치면서 경험이 점점 깊어지고 후배나 동료들에게 내 지식과 경험도 공유하게 된다.

이렇게 할 수 있는 핵심은 적절한 피어리뷰다. 피어리뷰가 가능한건 기반시스템이 잘 갖춰져 있기 때문이다. 또 개발에 집중할 수 있고 다른 일은 신경쓰지 않아도 되는 프로세스와 조직문화 때문이다. 10년, 20년이 되면 시니어 엔지니어가 되거나 아키텍트가 될 수 있다. 회사 내에서 다른 프로젝트로 옮겨 다니거나 이직을 해도 후배들이 이어 받아서 아무 문제없이 개발이 지속된다. 15년이 되었는데 연봉도 다른 직업의 친구들보다 훨씬 높고 만족감이 높다.  과거 같이 일하던 동료가 차린 유망한 스타트업에 스톡옵션을 받고 참여하는 기회도 잡을 수 있다.

그럼 우리나라에서 소프트웨어 개발을 시작한다면 어떨까? 좋은 회사, 나쁜 회사, 여러 가지 경우가 있지만, 그 중 일반적인 예를 하나 보자.

대학에서 소프트웨어 전공을 하고 입사를 했다. 회사에서 개발하고 있는 소프트웨어에 대한 도메인 지식이 없으면 개발에 참여 하기가 어렵다. 관련 서적을 받아서 몇 달간 공부를 하고 회사에 대한 여러 가지 교육을 받는다. 제대로 개발에 참여하려면 최소 6개월이 걸린다고 하니, 일단 바로 유지보수에 투입된다. 소프트웨어를 파악할 수 있는 자료는 소스코드 밖에 없다. 선배들에게 물어물어 소스코드를 내려 받았고 개발환경을 구축하는데도 하루가 걸렸다.

빌드가 쉽지 않아서 여러 번의 실패와 우여곡절 끝에 빌드에 성공했다. 소스코드를 보고 분석을 하다가 도저히 몰라서 선배에게 물어보려니 개발한 선배가 퇴사를 했단다. 밤을 세서 수정을 했는데 제대로 동작하고 부작용(Side effect)은  없는지 확신은 없다. 누구도 내가 작성한 코드를 리뷰해주지 않는다. 그러다가 개발한지 얼마 되지도 않았는데 실전 사이트에 투입됐다. 선배와 같이 고객을 만나서 요구사항을 듣고 커스트마이징 작업을 진행했다. 워낙 바빠서 문서작성은 꿈도 못 꾸고 코딩만 했다.

선배와 내가 아니면 회사의 누구도 우리가 한 작업의 내용을 모른다. 경험이 쌓이면서 좀더 어려운 일을 맡고 바쁜 개발일정을 소화한다. 문서도 없고, 시스템에도 정보도 없고, 피어 리뷰도 없는 것은 여전하다. 회사에서 강제로 문서를 만들라고 해서 만들기는 하지만 쓸모 없는 문서일 뿐이다.

7년쯤 일하니 회사에서 제일 개발을 잘하는 개발자가 되었다. 경영진이 능력을 인정해서 팀장도 되었다. 팀장이 되니 회의도 많고 보고서도 많이 써야 한다. 낮에는 일할 시간이 거의 없어서 직원들 퇴근 후에 개발을 하게 되었다. 그러나 보니 차츰 개발에서 손을 떼게 되었다. 다시 개발로 돌아 가려고 하지만 여건이 안 된다. 팀장을 몇 년 하다 보니 정체성이 없어지고 앞길이 막막해졌다. 이제 치킨집을 차릴 때가 되었나 보다.

이러한 선순환과 악순환의 차이를 극복하려면 개발 환경을 바꿔야 한다. 개발프로세스, 기반시스템, 개발문화, 조직문화가 바뀌어야 한다. 우리가 이를 바꿔나가지 않으면 우리 후배들도 10년, 20년 후에 똑같은 얘기를 하면서 한숨을 쉬고 있을 것이다. 이는 비단 후배들만을 위한 일은 아닐 것이다. 우리가 일할 10년, 20년 후의 소프트웨어 환경을 바꾸는 일이다.

환경을 바꾸려고 하니 무엇부터 바꾸어야 할지 막막한 경우가 많다. 물론 회사마다 다르기는 하지만 쉬운 것부터 하는 것이 좋겠다. 우선 효율적인 기반시스템을 갖추는 것이 좋다. 성숙도에는 차이가 크겠지만, 소스코드관리, 버그관리, 빌드 자동화를 갖추고 서로 연동을 시킨 뒤  소스코드를 보면 버그나 이슈가 연결되고 반대로 버그가 소스코드와도 쉽게 연결될 수 있는 환경을 만들어야 한다.  그리고 나면 피어 리뷰를 할 수 있는 환경이 조금씩 되어 간다.

거의 모든 것을 완벽하게 자동화하는 것이 바람직하다. 자질구레하게 중간중간 수동 작업이 많이 들어가면 회사가 커갈수록 비용은 점점 올라가고 비생산적인 일에 많은 노력을 들여야 한다. 또 완전 자동화된 시스템 환경이어야 공유와 효율적인 협업이 가능하다. 인터넷에서 정보를 얻어서 좋을 툴을 설치하는 것은 어렵지 않지만 제대로 구축해서 잘 사용하는 것은 몇 백배 더 어렵다. 경험을 많이 해본 선배들의 도움을 받는 것은 필수적이다.

이 정도 되어야 환경을 바꾸기 위한 마라톤의 한 발을 내디딘 것이라고 보면 된다. 그래도 시작이 반이다. 의미 있는 한발이 될 것이다.

이 글은 제가 CNet Korea에 기고한 칼럼입니다. (http://www.cnet.co.kr)

초등학생 코딩 교육을 보는 기대와 불안

“초등학교 4학년부터 재미있고 쉬운 컴퓨터 코딩 교육을 받는다면 청년이 되어 코딩에 능숙한 전문가들이 늘어날 것이고, 그 중에는 스티브잡스와 같은 인재들이 나타날 수 있을 것이다.”

미래창조과학부에서 나온 말이다. 여기에 대해 “소프트웨어 개발에 대해서 알고나 하는 소리냐?”, “스트브잡스가 코딩 잘해서 성공했냐?”라고 따지고 싶은 생각은 없다. 예들 들다 보니 스티브잡스를 그냥 갖다 붙인 것이 아닌가 생각된다. 많은 사람들이 이 정책을 비난하고 있지만 나는 기본적으로 초등학생에게 코딩 교육의 기회를 주는 것을 찬성을 한다. 하지만 찬성하는 마음 못지 않게  어떤 식으로 왜곡돼서 진행될지 매우 걱정스럽다.

나는 초등학생 코딩 교육이 코딩 전문가를 늘리기 위한 것이 아니어야 한다고 생각한다. 선천적으로 뛰어난 논리력을 타고난 아이들을 찾아내고 컴퓨터와 소프트웨어에 대한 흥미를 유발하고 아이들의 창의력을 더욱 향상 시키는 것이 목적이 아닌가 생각한다. 김연아가 어렸을 때 스케이트를 타보지 않았다면 지금의 김연아가 없듯이 코딩 교육의 기회는 소질을 타고난 아이들을 찾는데 도움이 될 것이다.

정부에서 새로운 교육정책을 들고 나오면 먼저 불안감이 든다. 그 동안 신중하지 못하고 준비가 덜 된 교육 정책으로 여러 부작용을 야기해 왔기 때문에 이번에도 또 많은 문제가 생기지 않을까 우려하는 목소리가 크다.  이 정책을 통해서 아이들에게 컴퓨터와 소프트웨어에 대한 흥미를 유발하고 창의력이나 논리력을 키우는데 집중해야 하는데, 또 시험을 통과해야 하고 목표 점수를 얻고 등급을 높이는 방법으로 빠져들어 사교육만 배를 불리고 선행교육이 판을 칠 수 있다.

충분한 시간을 두고 우리나라 초등학생에게 알맞은 교육 도구가 개발된 후에 진행해야 하는데 또 날림공사 식으로 진행될까 걱정된다.

그럼 초등학생 코딩교육의 목적에 대해서 생각해보자.

초등학교 교육은 미래에 전문적인 교육을 받기 위한 기초가 된다. 그리고 기본적으로 사회를 건강하게 만드는 기반이기도 하다. 많은 사람들이 학교 다닐 때 과학과 수학을 어렵게 공부했는데 사회에 나와서는 하나도 써먹지 않아 시간 낭비 했다고 하는데 사실은 그렇지 않다. 어렸을 때의 교육은 지식을 익히는 것뿐만 아니라 논리적인 사고와 합리적인 생각을 하게 해준다.

미분, 적분은 직접 써먹을 기회가 없을 수도 있지만 자신에게 닥친 문제를 합리적이고 논리적으로 해결할 수 있도록 해준다. 비과학과 비논리의 오류에 빠져서 돈과 시간을 낭비하는 일을 줄여준다. 우리가 지금 너무 자연스럽게 생각하고 있는 것은 어렸을 때부터 받았던 교육과 경험의 결과이다.그럼 코딩교육은 어떨까?

100년 전에는 수학, 과학 교육이 거의 필요 없이 살 수 있는 세상이었다. 그럼 30년 후에는 어떨까? SF영화에도 종종 나오기도 하지만 상상하기는 쉽지 않다. 확실한 것은 컴퓨터가 지금보다 10배, 100배는 많이 쓰이는 세상이 될 것이다. 그런 세상에 합리적으로 살아가기 위해서 기본적으로 컴퓨터에 대한 이해와 논리력이 더 필요할 것이다. 교육은 시대의 흐름을 예측하고 대비해야 한다.

많은 초등학생이 잘 준비된 코딩 교육 기회를 접한다면 미래에 많은 소프트웨어 개발자가 생겨날 수도 있을 것이다. 그런데 그렇게 쉽게 기대하기에는 현재 우리나라 소프트웨어 업계는 너무나 매력이 없다. 소프트웨어 업계는 3D 취급을 받고 있고, Dreamless를 포함해서 4D라고 하기도 한다. 이런 바닥에 뛰어난 인재가 더 많이 지원할 리가 없다. 최근 10~20년간 소프트웨어 업계의 인기는 계속 추락해왔다. 대학의 소프트웨어 관련학과도 마찬가지이다.

소프트웨어 개발 일은 툭하면 야근에 부당한 대우에 사회적 인식은 바닥을 유지하고 있다. 좀 똑똑하다는 학생 중에서 미래에 개발자가 되고 싶다는 학생은 그리 많지 않다. 대부분 의사, 변호사가 되고 싶어한다. 코딩 선행 교육이 이런 문제를 해결해주지 않는다. 이런 와중에 소프트웨어 개발의 소질을 발견한들 소프트웨어 업계로 오겠는가? 근본적인 문제는 심하게 왜곡되고 뒤틀어진 소프트웨어 개발 환경이고 이를 개선해야 한다. 소프트웨어 업계가 일할만한 곳이란 비전이 보인다면 많은 인재가 지원을 할 것이다.

스티브잡스와 같은 인재가 탄생하기를 원하고 미래에 소프트웨어 인력이 많이 필요하다면 초등학생 코딩 교육보다 먼저 소프트웨어 업계를 정상화하기 위한 제도와 지원이 필요하다.

초등학교 코딩 교육은 어른들이 배우는 것을 흉내 낼 것이 아니라 논리력과 창의력을 키우는데 집중하고 재미있게 배울 수 있는 교육 도구들을 꾸준히 개발해야 할 것이다. 섣불리 어른이 배우는 것을 비슷하게 배운다면 흥미는커녕 오히려 지겨워할지도 모른다.

초등학교 코딩 교육 정책은 제대로 준비되고 꾸준히 투자가 이루어 진다면 30년 후에 우리나라의 중요한 국가 동력의 핵심이 될 수도 있을 것이다.

이 글은 제가 CNet Korea에 기고한 칼럼입니다. (http://www.cnet.co.kr)

투명한 개발 문화의 효과

흔히 투명한 개발이 효율적이고 좋다고 한다. 그 진정한 의미를 알아보자.

투명한 개발이란 개발에 관련된 거의 모든 정보와 지식이 공유되는 것을 말하지만 추가로 내가 강조하고 싶은 것이 따로 있다.

거의 모든 결정의 과정 및 결과가 공개되고 기록되는 것이다. 이것의 효과는 꽤 대단한다. 이슈관리시스템을 이용하여 모든 정보를 공개하는 것도 좋은 방법이다. 결정해야 할 이슈들을 공개하고 결정 과정이 공개되면 근거가 부족한 일방적인 주장을 하기가 어려워진다.

일방적인 주장이라고 하면 특정부서의 입장만 밀어붙이거나 윗사람이라고 해서 일방적으로 우기는 것을 예로 들 수 있다. 영업의 입장, 회사의 비전, 개발 비용등 여러가지를 고려해야 할 결정에 영업의 입장대로만 주장하여 그렇게 결정되면 장기적으로 회사에 손해가 될 수 있다.

또, 2주는 더 걸릴 일을 추가해 놓고 일정을 전혀 손댈 수 없다고 주장을 한다면 그러한 주장이 공개된다면 상황이 좀 달라질 수도 있다. 무조건 우기기보다는 합리적인 해결책을 찾는 시늉이라도 하게 될 가능성이 높다. 그런 상황에도 독선적인 결정을 하고 그런 과정이 모든 직원들에게 공개가 되고 그런 일이 반복된다면 그런 주장을 하는 사람의 능력을 의심하게 될 것이다.

물론 이런 변화는 하루 아침에 일어나지도 않고 모든 정보가 투명하게 시스템에 기록되는 일이 쉽게 이루어지지는 않는다. 수평적인 구조와 성숙한 개발문화를 가지고 있다면 자연스로운 일이지만 그렇지 않은 조직에서의 변화는 쉽지 않고 오래 걸리는 일이다.

이럴 때는 개발팀이 주도하여 개발과정이 투명하게 공개되도록 유도를 하는 것이 좋다. 개발팀 스스로가 최대한 이슈를 등록하고 사소한 요청이나 결정사항도 이슈관리시스템을 통하고 타부서의 사용률이 저조하면 도와줘서라도 타부서 사람들도 점차 끌어들이는 것이 좋다. 경영진의 후원도 필요하지만 개발팀 스스로도 많은 노력을 해야 한다. 

우리가 흔히 모여서 회의를 통해 논의하고 결정하는 것 중 상당수는 시스템을 통해서 가능하다. 사람들이 물리적으로 모이는 것은 매우 많은 비용을 지불해야 한다. 가능하면 시스템을 이용하는 습관을 들이면 좋다. 또한 모여서 결정한 것도 시스템에 등록을 하면 좋다. 이때 최종 결정 사항외에도 그 과정과 누가 무슨 주장을 했는지 핵심적인 것을 요약해서 기록을 해주면 좋다. 이런 것이 일상화 될 때까지는 신경을 써서 노력해보자.

정보와 지식, 의논 내용 등을 기록으로 남기는 것이 습관이 들지 않으면 상당한 부담인 것이 사실이다. 하지만 모두가 어느정도 몸에 벤다면 오히려 더 시간을 절약해주고 효과적이라는 것을 알게 될 것이다.

내가 오늘 주장하거나 결정한 것이 내일 아침에 신문에 나도 나는 떳떳한가? 대부분의 정보가 공개되면 이와 비슷한 효과가 있어서 일방적인 주장이 좀 줄어 들 수 있다. 또한 한번 기록으로 남은 것은 추후 되돌아 봤을 때 언제 잘못된 결정을 했는지도 잘 알 수 있다. 말로해서 사라지거나 메일에 묻혀서 찾기 어려운 것은 그런 역할을 할 수 없다. 물론 모든 것을 기록으로 남기는 것은 불가능하지만 해보면 어디까지 남겨야 하는지 저절로 알게 된다. 걱정할 필요가 없다.

투명한 개발을 꺼려하는 개발팀도 많은 것을 알고 있다. 스펙의 많은 부분이 개발자들 머리속에 있고 뭘하나 알려고 해도 개발자에게 물어봐야 하고 온갖 정보를 숨겨서 개발자가 쥐고 있으면 그것이 곧 파워라고 생각하는 경우도 있다. 물론 단기적으로 맞는 말일 수 있으나 장기적으로는 개발자에게 오히려 손해인 경우가 많다. 회사 차원에서는 장/단기적으로 모두 손해다.

보통 개발팀은 여러가지 불합리한 것들 때문에 고생을 한다. 일방적인 요구사항 추가/변경이나 그럼에도 불구하고 무리한 일정에 많이 시달리곤 한다. 투명한 개발은 여러가지 효과가 있지만 개발팀이 조금더 합리적으로 일할 수 있게 하는 효과도 있다.

스펙을 작성하고 Wiki를 통해서 정보를 공유하는 것외에 모든 결정과정을 투명하게 공개하는 것을 통해서 좀더 효율적인 개발 문화에 한발짝 다가가보자.

소프트웨어공학은 실전이다.

이 전글에 댓글을 달려다가 좀더 정리를 해야 할 것 같아서 본글로 올린다.

2013/02/27 - [프로젝트/품질관리] - 거의 다 만들었어요.

알파, 베타의 정의를 가지고 이렇게 강하게 주장하는 경우는 처음봐서 약간 당황스러웠다. 독자들은 알아서 판단하겠지만 혼란이 있을 수도 있어서 다시 한번 내 의견을 밝힌다.

나는 20년간 한국, 미국, 대기업, 벤처기업을 다 경험하고 이론과 실전을 다 경험하고 온 국민이 쓰는 소프트웨어 개발에도 다수 참여하고 수많은 소프트웨어 프로젝트를 성공시켰고 여러 소프트웨어의 회사의 역량 개선을 시키고 있고 이런 경험을 책(소프트웨어 개발의 모든 것)으로 쓰고 블로그를 통해서 공유하고 있다. 

소프트웨어 공학은 실전이다. 이론적으로 먼저 정립된 것이 아니라 실전적인 발전을 거듭해오다가 이론적인 정리가 된 것이다. 따라서 보편적인 이론과 원리가 있고 주장이 있으며 회사마다 그 응용이 있다. 물론 모든 회사의 응용이 효율적인 것은 아니다. 대부분의 우리나라 소프트웨어 회사들의 응용이 비 효율적인 이유는 그 원리를 모르고 응용만 해왔거나 스스로 방법을 생각해 냈기 때문에 한계가 있는 경우가 많다.

세상에는 수만가지 종류의 소프트웨어가 있고 그에 알맞는 라이프사이클도 약간씩 다르다. 다른 것이 잘못된 것은 아니다. 따라서 하나의 프로세스나 이론만 들이대고 이대로 따라하면 모든 소프트웨어에 알맞다고 주장하는 것은 틀릴 가능성이 매우 높다. 

이론서를 보거나 Wikipedia를 보더라도 "generally"라는 용어를 주로 사용하는 이유가 그것이다. 

알파, 베타라는 용어도 최초에 한사람이 이를 정의하고 모든 사람들이 이것을 따르라고 한 것이 아니다. IBM에서 최초로 A, B버전을 사용하였고 수많은 회사가 이런 용어를 따라했으며 Microsoft가 이후에 많은 영향을 미쳤으며 수많은 회사들이 이와 유사한 용어를 따라서 써오다보니 어느 정도 정립이 되었을 뿐이다. 각 회사의 프로세스 정의서에 알파, 베타에 대한 정의가 서로 다르며 이것이 틀린 것은 아니다.

제가 컨설팅했던 수많은 회사에서도 알파, 베타 버전의 용어가 비슷은 하지만 미묘하게 약간씩은 다르다. 회사마다 천차만별로 다른 것이 아니고 핵심적인 것은 비슷하지만 약간씩 다른 것이다. 이것이 틀린 것은 아니다. 회사마다 소프트웨어의 성격에 따라서 강조해야 하는 것이 다르고 프로세스가 다르다. 그렇다고 회사에서 개인마다 다르게 사용해서는 안된다. 회사내에서는 동일한 절차와 정의를 사용해야 한다. 회사마다 코딩컨벤션이 다른 것도 그 하나이다.

회사를 옮기면 그 회사의 조직, 프로세스, 규칙을 익혀야 한다. 대부분의 회사가 비슷한 프로세스와 정의를 사용하기 때문에 이를 익히는데 며칠도 걸리지 않는다. 대부분은 그냥 적응한다.

회사마다 다른 극단적인 예를 들면 5년이 걸리는 화상탐사선을 개발할 때와 간단한 Web application은 알파, 베타, RC를 다루는 방법이 다르다. 화성탐사선은 스펙이 완벽하게 정해지고 수정되는 법이 없고 스펙이 바뀐다면 엄청난 크로스체크와 절차가 필요하다. 하지만 간단한 Web application은 많이 다를 것이다.

모든 것은 어떻게 하면 소프트웨어를 가장 효율적으로 개발하느냐에 집중되어 있다. 소프트웨어의 성격에 따라서 회사의 조직, 프로세스, 시스템, 문화등이 비슷은 하지만 조금씩 달라진다. 어떻게 하면 효율적으로 개발할지 고민을 하다보니 여러 라이프사이클이 나오고 방법론도 매우 많다. 그 중에서 개발하는 소프트웨어에 가장 알맞는 방법을 선택해야 한다. 여기서 한가지만 옳다고 주장하는 것도 잘못된 것이지만 비효율적인 방법을 선택하는 것도 안좋다.

우리가 주의할 것은 하나의 경험이나 학습으로 세상의 모든 진리로 착각하면 안되겠다는 것이다. 그래서 나도 글을 쓸때 항상 조심하는 편이다. 또한 다른 사람의견에 빈정대거나 공격하지 않고 건설적인 토론을 하려고 노력한다. 하지만 대중을 상대로 하는 일이라 힘들때가 많다. 교양있는 여러분의 많은 경험을 같이 나누고 싶다.

지금은 바빠서 못한다.

지금은 바빠서 못하고 나중에 여유가 생기면 할 것이다.

비단 소프트웨어 개발이 아니더라도 우리는 이런 말을 달고 사는 사람들을 자주 본다. 이런 사람들이 특징은 시간적인 여유가 생겨도 거의 대부분 안하기는 마찬가지라는 것이다.

운동, 공부, 다이어트, 취미생활 등 이런 핑계를 대는 대상은 다양하다.

영어 속담에 이런 말이 있다.

"A stitch in time saves nine"

직역하면 "필요할 때 한땀이 아홉을 구한다." 

소프트웨어 회사도 마찬가지이다. 한땀이 필요한 결정적인 시기들이 수없이 닥친다. 하지만 그 결정적인 시기를 놓치면 10배, 100배의 비용을 지불한다.

코딩만 보더라도 처음에 제대로 해놓지 않으면 나중에 고치기에는 훨씬 많은 노력이 드는 경우가 많다. 소스코드를 너저분하게 어질러 놓거나 여기 저기 마구 복사를 해넣고 암호 같은 코드를 써 놓으면 나중에 고생을 한다. 

여기까지는 나중에 문제가 되어도 그렇게 심각하지는 않지만 회사는 결정적인 시기를 놓치면 영원히 복구를 못할 수 있다.

어떤 시기에 무엇을 해야 하는지는 워낙 광범위한 이슈라서 한마디로 얘기할 수는 없다. 하지만 많은 회사들이 변화를 두려워하거나 귀찮아해서, 또는 변화에 지불해야 하는 비용이 아까워서 그냥 버텨나가곤 한다. 그리고는 더이상 버티기 힘들다고 판단될 때는 너무 늦은 경우가 많다.

회사의 프로세스, 조직, 시스템, 문화 등 적절한 시긴에 준비하고 변화해야 할 부분은 많다.

비경영자 출신의 경영자는 몰라서 실기를 하기도 하고 개발자 출신의 경영자들도 자신의 경험의 테두리에 갇혀서 사태의 심각성을 깨닫지 못하는 경우가 많다. 가장 좋은 방법은 상황이 좋을 때 변화하는 것이다. 상황이 점점 안좋아지면 변화는 엄두도 못낸다. 일단 상황에 밀리기 시작하면 끝까지 밀려서 꼼짝달싹 못하기 쉽상이다. 

좋은 경영자라면 좋은 세월에 뭘 해야 할지 알아야 한다.

스타트업의 착각들

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

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

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

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

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

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

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

1. 세계 최초

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

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

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

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

2. 아무나 못 만든다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

성공하는 스타트업 파운더의 DNA

요즘 하루를 애니팡 하트를 받는 것으로 시작한다. 조용했던 내 카카오톡은 애니팡 하트를 받는 메시지로 가득 찼다. 최근에 가장 Hot한 게임이 애니팡이고 많은 사람들이 그 성공 스토리에 관심을 가지고 있다. 그러면서 자신도 그런 성공을 할 수 있을까 생각을 하기도 한다.

마크주커버그는 19살에 Facebook을 설립했고, 빌게이츠도 20살에 마이크로소프트를 만들었다. 스티브잡스는 21살에 Apple사를 설립했다. 레리페이지가 Google을 만들었을 때의 나이가 25살이다. 이런 얘기를 들으면 어린 나이에도 좋은 아이디어가 있으면 성공할 수 있을 것도 같은 생각을 들게 한다. 애니팡을 만든 선데이토즈도 20대 후반에 친구 3명이 시작하였다.

미국에서도 모두 성공할 것 같아서 시작한 스타트업의 95%~99%가 3년 안에 문을 닫는다. 실패를 해도 다시 도전을 하면 되기는 하지만 이런 낮은 성공률이 우리를 주저하게 만드는 가장 큰 요소이다.

그럼 스타트업의 성공한 파운더가 되기 위해서는 어떠한 조건들을 갖춰야 할까? 물론 누구도 확실한 성공 조건을 제시할 수 없다. 또한 운이 중요한 요소로 작용하기도 한다. 따라서 아래 조건과 일치를 했다고 성공이 보장되는 것은 절대로 아니다. 반대로 아래 내용과 많은 부분들이 일치하지 않거나 반대라면 스타트업의 파운더가 되기에는 부적합하다고 생각해볼 수는 있다. 사견이니 참고만 하기 바란다.

뛰어난 관찰력과 통찰력

많은 성공한 스타트업 파운더들은 세상에 새로운 기술이 나왔을 때 남들보다 먼저 그 가능성을 알아보고 행동에 옮겼다. 해당 기술의 폭발적인 성장 후에는 누구나 알지만 남들보다 먼저 알아챈 것이다. 소셜게임의 가능성을 먼저 알아챈 Zynga나 선데이토즈가 그렇다. 인터넷, 스마트폰 등 새로운 혁신 기술이 나올 때마다 이를 먼저 알아본 스타트업의 파운더들이 있었고 상당수는 성공했다.

신기술뿐만 아니라 기존 기술의 불편한 점도 가볍게 보지 않는 관찰력도 좋은 자세 중 하나다. 주변에서 쉽게 보는 것들에서 문제점을 찾거나 엉뚱한 발상을 해서 회사의 핵심 아이템으로 키운 경우가 적지 않다. 꼭 최초일 필요도 없다. 남들이 해 놓은 것에서 개선점을 찾거나 더 재미있게 만드는 방식으로도 얼마든지 가능성이 있다.

결단력과 실행력

많은 사람들이 기회를 알아차린다. 세상에 World Wide Web이 출연하고 스마트폰이 나왔을 때 대단한 물건임을 알아차린 사람은 엄청나게 많지만 기존의 자리를 박차고 나와서 스타트업을 시작한 사람은 극소수에 불과하다. 무모함은 경계를 해야 하지만 마음만 먹고 실행하지 않으면 아무 것도 되지 않는다. 아무리 철저히 준비해도 완벽한 준비는 없기 때문에 적당한 준비와 결단력이 필요하다. 많은 스타트업의 파운더들은 그들의 유전자에 결단력이 들어 있는 것 같다.

일을 즐긴다.

내가 만나본 파운더들은 소프트웨어 개발 자체를 매우 즐겁게 생각하고 그래서 더욱 즐겁게 일하려고 자신만의 일을 시작한 경우가 많았다. 사실 소프트웨어 개발은 즐거운 일이고 일을 즐기는 것이 무한한 열정의 원동력이 된다. 아무리 돈이 되는 아이템이 있다고 하더라도 즐겁게 일할 수 없다면 이를 이끄는 힘이 약해진다. 게임, 음악 등 자신이 좋아하는 분야에서 많은 경험을 쌓고 동일 분야로 창업하여 성공한 파운더들이 많다.

좋은 파트너

스타트업을 혼자 시작할 수 있을까? 물론 가능하다. 하지만 회사를 운영하는 모든 중압감을 혼자 짊어져야 한다. 또한 개발과 비즈니스를 혼자 감당해야 하는데 쉽지 않다. 한 사람의 생각은 오류에 빠지기도 쉽다. 혼자 창업을 하게 될 경우 적은 부담감으로 쉽게 포기할 가능성도 높아진다.

스타트업의 적당한 시작 인원은 2~3명으로 생각된다. 실제 많은 성공한 스타트업이 그러했다. 대부분은 개발자들끼리 시작하거나 비즈니스를 담당하는 사람이 한 명 포함되는 경우가 일반적이다. 스타트업은 초기에는 개발이 그만큼 중요하기 때문이다. 스타트업을 시작하고자 마음을 먹은 사람들은 좋은 아이디어를 생각하는 것도 중요하지만 좋은 파트너를 찾는 일이 가장 중요하다고 할 수 있다.

적절한 경험

분야마다 필요한 경험의 기간은 다르다. 해당 분야의 기술을 섭렵할 정도의 기간이 짧게는 3년에서 길게는 10년이 될 수도 있다. 스타트업을 시작하면 한 두 명이 회사 전체의 일을 다 해야 한다. 그래서 경험이 너무 적다면 문제가 될 수도 있다. 반대로 너무 많은 경험을 쌓게 되면 나이도 많아지고 가진 것이 많아져서 쉽게 모험을 하지 못한다. 또한 기존의 시스템에 익숙해져서 아이디어가 적어지고 변화가 쉽지 않다. 너무 많은 경험을 가진 것보다 딱 필요한 만큼만 적당히 경험을 하는 것이 좋다.

헌신할 수 있는 체력

부수적인 요소이기는 하지만 나이가 너무 많거나 헌신할 수 있는 체력이 없다면 문제가 될 수도 있다. 따라서 스타트업을 시작할 거라면 체력이 소진되기 전에 시작하는 것이 어떨까? 아무리 체력 관리를 잘해도 나이에 따른 체력저하는 거스를 수 없는 자연의 섭리인가보다.

실패를 빨리 인정하는 자세

스타트업이 첫 번째 전략에서 바로 성공한 경우는 매우 드물다. 성공한 스타트업의 파운더들은 크고 작은 실패를 빠르게 인정하고 끊임없이 변화를 해 온 경우가 많다. 스타트업은 수많은 크고 작은 실패를 하는 것이 당연하다. 문제는 얼마나 빨리 실패를 알아차리고 전략을 변경하는가에 달려 있다. 자신의 실수와 실패를 쉽게 인정하지 않거나 고집이 센 경우 이미 비용을 너무 많이 치러서 회복하기 어려운 상황에 빠지는 경우가 매우 많다. 대기업은 이런 실패들에도 끄떡없지만 스타트업은 한번에 무너지기도 한다.

글로벌 마인드

이 부분은 아쉬움이 크다. 처음부터 로컬 전략이라면 상관이 없지만 글로벌 시장을 지향하면서도 국내의 많은 스타트업이 국내를 벗어나지 못했다. 즉 전세계 시장의 1~2%에 불과한 시장에서 경쟁하는 경우가 대부분이다. 마음을 먹는다고 갑자기 글로벌 마인드가 생기는 것도 아니다.

몸에 베어 있어야 하고 글로벌화를 위한 기술도 잘 알아야 한다. 5천만명을 고객으로 할지 50억명을 고객으로 할지는 스타트업에게 매우 중요한 전략적 요소이다. 글로벌 시장을 겨냥한다면 글로벌 마인드와 더불어 유창한 영어 실력은 기본적으로 필요하다고 할 수 있다. 아니면 영어가 유창한 파트너를 둬야 한다.

항상 기회는 조용하게 다가온다. 남들이 다 알 때쯤이면 시끄러워진다. 과거 10여년동안 스타트업 붐이 여러 번 있었다. Web과 Web2.0이 있었고 스마트폰과 SNS로 인해서 또 붐이 일고 있다. 물론 10여전과 같이 거품이 크게 일고 있지는 않지만 분위기가 나쁘지 않다. 그런 붐에 무작정 편승하는 것이 좋은 생각은 아니지만, 확신과 열정이 있고 준비가 충분하다면 좋은 시기를 선택하는 것도 나쁜 방법은 아니다.

필자는 우리나라 소프트웨어 생태계를 바꾸는 유일한 방법은 수많은 스타트업이 탄생하는 것으로 생각하고 있다. 실패도 있겠지만 많은 스타트업이 성공하고 성장하고, 또 새로운 스타트업이 많이 탄생하는 사이클을 이뤄야 소프트웨어 생태계가 개선되고 개발 문화가 좋은 방향으로 바뀌어 나갈 것으로 생각한다.

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