개발자로서, 프로젝트 관리자로서, 프로덕트 오너로서, 20여년간 IT에서 일하며 느낀 ‘잘하는 개발자’에 대해 얘기해보려 한다.

이전 기고에서도 다뤘지만 이번 글에서는 자주 목격한 바 있는 ‘아주 변화가 빠른 스타트업에서 개발 조직이 변화되어 가는 과정’을 통해 이야기하겠다.

아이템을 발굴하고, 스타트업을 시작하여 서비스/상품을 만드는 시작점을 보면 이렇다. ▲아웃소싱을 통해서 개발자 한 명 정도 구해서 동업자로서 혹은 상당한 지분의 CTO와 같이 시작 등이다.

대부분 위와 같은 경우로 구분을 하는데, 개인적으로는 ‘아웃소싱을 통해서’를 추천한다. ‘동업자로서 혹은 상당한 지분의 CTO와 같이 시작하는 경우'는 장기적인 시각으로 보자면 잠재적 문제점을 갖는다.

CTO가 개발도 하고, 혹은 아웃소싱을 구하거나 개발자를 뽑아서 개발을 진행하는 시점에 시드머니 정도의 투자금액을 받게 되면, 거의 대부분이 가장 먼저 개발인력을 구하게 된다.

이때 당연히 개발 기술이 좋고 업계에서의 경력과 개발 이력이 훌륭한 개발자를 구하려 노력한다. 이 경우 모든 스타트업이 그렇지는 않겠지만, 훗날 개발조직으로 인한 진통을 겪을 가능성이 다분하다. 그래서 그러한 문제들이 왜 일어나는지, 어떻게 풀어 나가야 하는지, 어떤 사람을 채용해야 하는지 아래에서 차근차근 읽어 보자.

첫번째로, 진통을 겪게 되는 부분은 개발 조직이 의사소통이 잘 안되거나(그러니까... 경력과 이력이 훌륭한 그 개발자가 말을 잘 안 듣거나), 개발조직내의 다툼인데 오랜 경력의 개발자를 뽑을수록 후자의 경우가 발생될 가능성이 크다.

특히 CTO의 경력 및 나이가 많지 않을 경우 자주 발생된다. 간혹 채용된 개발자가 CTO 보다 실력이나 결과물이 훌륭하거나, 프로젝트를 CTO 보다 노련하게 이끌며 조직 내에서 영향력이 커지게 되면 CTO는 시간이 갈수록 기술력이 좋은 개발자를 경계하게 된다. 결국 잘하는 개발자를 뽑아도 CTO와 개발자 중 누군가는 회사를 떠나게 되는 상황도 벌어지는 것이다.

하지만 CTO가 공동 창업자라면 얘기가 달라진다. CTO를 바꿀 수 없는 경우가 많기 때문에 이때는 차라리 주니어 개발자를 뽑아 CTO가 개발 리더로 그 뒤를 따라줄 개발자를 뽑아주는게 더 옳을 수 있다.

두 번째로, Pre-A와 시리즈 A정도 규모의 스타트업이 ‘형 같은 개발자’를 주로 뽑는다.

개발 조직의 관리가 안되니까 관리해 줄 사람이 필요하다는 말이다. 이때의 개발 조직이 CEO의 골치를 가장 아프게 만드는 시기가 아닐까 싶다. 이 경우엔 나이가 좀 있어서 형처럼 주니어 개발자들의 이야기도 들어주고 CTO의 의견도 잘 들어주면서 개발 조직과 서비스 조직 사이를 유기적으로 조율할 사람이 필요한 것이다.

세 번째, PM 혹은 시니어(Senior) 개발자를 뽑는다고 채용 공고를 낼 때이다.

시리즈 A 투자금을 받은 이후, 더 크고 빠르고 안정적인 서비스를 제공하려 하니 개발 조직에서는 "기존에 서둘러 만들었던 서비스로는 불가능하다"는 대답을 내놓게 된다. 왜냐면 서비스를 오픈 일정에 맞춰서 큰 문제만 없으면 몇 가지 에러가 간혹 발생하긴 해도 이용하는 데에 불편함이 없을 정도로만 만들었기 때문이다. 시스템의 품질을 보다 유연하게 다듬어 줘야 가능한 일이다.

이때가 대표들이 바라 마지않던 ‘잘하는 개발자 : 기술력 좋은 개발자’가 필요해지는 시기이다.
이 시기를 넘어가면, 개발 조직은 안정화되고, 각 역할의 개발자 및 관리자는 제 역할에서 안정적 개발을 진행할 수 있다. 이제 필요에 따라서 그에 맞는 개발 능력을 가진 개발자들을 채용하면 되는 것이다.

아래에서는 각 포지션에 따라 어떠한 인력이 필요한지 살펴보자.

CTO를 채용하려면
얼마나 많은 기술을 경험해 봤는지가 중요하다, 앞으로의 개발방향을 정해야 하는 사람으로써, 개발을 잘하는 능력보다는 많은 기술 스택을 어떻게 꾸려가야 하는지 충분히 고민하고 결정할 수 있어야 한다.
개발언어, 라이브러리, 프레임워크, 플랫폼 등에 대한 많은 경험은 더 좋은 결정을 이끌어 낼 수 있다.

시드머니 투자 단계에서 개발자를 채용하려면
얼마나 빨리 많은 개발을 수행했는지 확인해야 한다. 각 프로젝트에서 얼마나 자주 커밋하고, 소스를 많이 변경했는지 등이다(물론 절대적 판단 가치는 아니다). 그리고 되도록이면 3년 차 이하의 개발자를 뽑는 것이 좋다. 개발 수행 내역이나 프로젝트 참여에 대한 확인은 개발자의 이력서 외에 깃허브, 깃랩, 비트버켓 등의 깃(Git)주소나 Dev2Job의 이력검증 내용을 함께 받아서 확인할 수 있다.

개발 리더를 채용하려면
각 프로젝트 수행 내역을 살펴서 최초 커밋을 한 경우, 그리고 라이브러리 커밋을 한 경우가 얼마나 있는지 살펴야 한다. 정해진 기술을 가장 먼저 적용시키는 역할을 많이 수행한 사람이 잘 어울릴 수 있는 역할이다. 이 또한 개발자의 깃 주소나 Dev2Job 이력검증 내용을 보고 확인할 수 있다.

멘토를 채용하려면
정말 형 같은 개발자가 필요하다. 물론 성격도 중요한 요소이긴 하지만, 얼마나 오래 개발을 해오고 얼마나 오래 각 프로젝트에 남아 있었는지 확인해야 한다. 어쩌면 이 클래스는 개발 능력보다 얼마나 협업을 더 잘 했는지가 더 중요 할 수 있다.

재설계 혹은 고도화를 할 경우
할 수 있는 모든 테스트 및 검증을 하고 채용해야 한다. 깃 주소나 Dev2Job을 통해 각 프로젝트 수행 이력 검증부터, 코딩 테스트, 수차례의 대면 면접, 기술 면접 등을 살펴봐야 한다. ‘개발 기술’을 중점적으로 봐야 되는 역할이다. 위에서 말한 바와 같이 서둘러 만든 서비스를 시간과 정성을 들여서 다듬고, 고도화시키고, 서비스의 품질을 높이는 역할이기 때문에 가장 기술력이 높은 개발자가 필요하다. 가장 비싼 비용을 지불해야 할 대상이기도 하다.

채용을 한다는 것은 회사의 입장에서 여러모로 신중을 기해야 하는 아주 중요한 사안이다. 정규직이 아니고 아웃 소싱해 프로젝트로 계약을 할 수도 있겠지만 정규직으로 채용한 개발자를 엉뚱한 포지션에 배치하게 되면 개발자와 회사 양측이 그만큼 스트레스와 손실이 발생하게 된다. 결국 제대로 된 결과물이 나올 수 없게 되며 채용에 실패하게 되는 상황이 되는 것이다.

이번 기고와 함께 "[우리가 모르는 개발자 생태계] 기업이 IT 개발자 채용에 실패하는 이유"를 함께 읽어 보기를 권한다.

※ 외부필자의 원고는 IT조선의 편집방향과 일치하지 않을 수 있습니다.

김용욱은 기업과 IT 개발자 Job Matching 전문 서비스 Dev2Job의 CMO로 재직 중이다. 20년간 한국과 일본의 IT 관련 업계에서 퍼블릭 클라우드, 프라이빗 클라우드, 금융 클라우드, 하이브리드 클라우드 관련 컨설팅을 해왔다. 현재는 개발자 채용 전문 서비스인 Dev2Job을 운영하고 있다.


관련기사