ICT 분야의 스타트업을 팀빌딩할 때 빠질 수 없는 팀원이 개발자 팀원이다.
물론 기획자, 디자이너, 마케터 등 다른 파트의 팀원 또한 매우 중요한 역할을 담당하지만,
서비스를 개발하기에 앞서 초기에 비용이 가장 많이 투입되는 부분이 개발쪽이기에 부담이 큰 파트라는 부분은
어느정도 동의할 것이다.
여기서 내가 얘기하고자 하는 것은 단순한 개발자 팀원 뽑는 것보다 더 중요한 것은 CTO의 영입이라는 것이다.
심지어 개발 팀원을 두지 않고 외주 개발로만 진행한다하더라도 CTO를 영입하는 것을 권장한다.
단, 팀의 대표가 개발에 대한 역량이 없고, 개발에 대한 커뮤니케이션 능력이 없다는 가정이다.
여기서 CTO라는 것은 원론적인 의미의 CTO라기보다는 어느정도 중간 관리자 수준 급(개발자 컨트롤이 가능한)의 개발자를 의미하는 것으로 보면 될 것 같다.
초기 스타트업의 경우 당연히 각 분야 인재를 영입하는게 쉽지 않지만, 개발자 자체도 영입하는게 쉽지 않아서
그냥 개발자라면 무턱대고 뽑거나, 뽑는 것을 포기하고 바로 외주 업체를 찾아나선 후 개발을 시작하는 경우가 많다.
이것이 무조건 잘못됐다고 하는 것은 아니며 리스크가 있을 수 있는 부분을 설명하고자 한다.
이유는 여러가지가 있지만 여기서 살펴볼 이유는 '구현된 제품의 수준'이다.
어떤 고도화된 서비스 개발을 경험해보지 않은 개발자의 경우 아무리 초기 제품으로 MVP 모델을 만든다하더라도 이를 확장 모델로 고도화시키기가 매우 어렵게 만들곤 한다.
조금 더 쉽게 예를 들면, MVP 모델을 완성한 후 런칭을 하였는데 사용자가 급격히 늘어나며 데이타베이스에 데이타가 쌓이게 되면서 앱 속도가 점점 느려지고, 사용하기 어려울 정도가 되버리는 경우가 발생할 수 있다.(하나의 예이다.)
이 때 간단한 수정으로 해결될 수도 있지만 상황에 따라 설계의 문제라면, 다시 엎고 새로 만들어야 하는 경우까지 발생하게 된다.
나는 주변 스타트업에서 이런 상황을 직접 보기도 했고, 간접적으로 들은 것까지 포함하면 꽤나 흔한 상황이라 느꼈다.
이런 일이 발생하는 이유는 개발자가 이를 고려하지 않거나(혹은 역량 문제로 고려하지 못하거나),
외주에 의뢰하는 경우라면 이러한 디테일한 부분까지는 언급하지 않기 때문이다.
개발자의 역량이 높을 수록 당장의 구현에 급급하지 않고 앞으로를 고려한 설계를 신경쓰게 된다.
(귀차니즘의 문제로 그렇지 않은 경우도 있기는 하다.)
반대로 개발 역량이 낮을 수록 당장 구현에 급급할 뿐, 설계에 대한 노하우가 부족하므로 위와 같은 문제를
초래하게 된다.
외주업체의 경우 당연히 외주 업체마다 case by case인 부분인데, 의뢰하는 경우 외주업체 입장에서는
단발성 프로젝트로 치부되는 경향이 있기 때문에, 고도화된 설계보다 프로젝트를 빨리 마무리하는데 중점을 두게 된다.
그래서 초기 스타트업이 외주 업체에 맡겨 개발한 초도 제품을 고도화시킬 때 쯤에는 새롭게 팀빌딩한 멤버들과 함께
처음부터 온전한 설계를 통해 새로 만드는 경우가 꽤 흔하다.
초기 스타트업은 개발 단가에도 민감할 수밖에 없는데, 무조건 싸게 진행하려는 것도 문제가 될 수 있다.
외주 업체는 특히 진행 비용에 맞추어 개발하는 경향이 있기 때문에 개발 단가는 제품 퀄리티에 영향을 크게 미친다.
만약 CTO에 버금가는 인력이 있었다면 단가 문제를 떠나서 외주를 주던, 개발자 팀원을 뽑던 위와 같이 발생할 수 있는 문제를 최소한으로 줄일 수 있었을 것이다.
물론 개발하려는 제품에 따라, 혹은 개발하는 개발자에 따라 위와 같은 문제가 없을 수 있고 의외로 순조로울 수도 있다.
하지만 많은 스타트업에서 이런 문제가 발생하고, 또 스타트업이 아니더라도 일반 기업에서 위시캣, 프리모아 등과 같은 개발 중개 사이트를 통해 진행하는 경우에도 개발에 대한 트러블이 꽤나 많이 발생하므로 위 내용을 어느정도 주의하는 것은 좋을 것 같다.
'스타트업' 카테고리의 다른 글
| 폭포수(Waterfall), 애자일(Agile), 린(Lean) 모델 차이점 (0) | 2021.12.13 |
|---|
