Stage 2. 성장곡선을 같이 만들 개발리더 찾기
프로덕트 조직의 첫번째 동료를 찾는 단계
이번 포스팅은 저번 MVP 검증 단계 ~ 다음 단계까지의 이야기입니다.
스타트업의 스테이지로 본다면 MVP를 통해 가설을 치열하게 검증해 보면서 서비스의 성장곡선을 만들어가는 과정일 테니 Pre-A ~ Series A 정도의 단계라고 생각할 수 있을 것 같습니다. 서비스가 MVP를 통해 가설검증이 되기 시작하면 그에 따르는 비즈니스적인 지표의 반응이 오기 시작합니다. 가장 이상적으로는 매출이 발생하는 것이겠지만, 서비스나 판매하는 상품의 특성에 따라 매출보다 선행지표를 기준으로 보는 경우도 많이 있습니다. 회원가입수가 기하급수적으로 올라가기 시작한다든가, 서비스의 재방문율이 40~50%가 넘어간다든가 하여 아직 본격적인 매출은 발생하지 않았지만 조금만 더 잘하면 비즈니스가 충분히 성공할 수 있을 것 같다는 예측을 할 수 있는 단계가 이 단계입니다.
이 단계는 MVP를 통해서 가설을 검증하는 단계이긴 하지만 Product적으로(심지어 솔루션이라도) 지속적인 변화와 고도화를 진행해야 하긴 합니다. 고객 VOC나 비즈니스 요구사항들이 점점 들어오고 고객경험 고도화를 위한 추가적인 대응도 해야 하기 때문입니다. 그렇게 솔루션이 되었던 외주개발한 시스템도 결국 유지보수 관리, 그리고 고도화를 하려고 하니 자연스럽게 ‘개발자가 필요하다’는 생각이 들게 됩니다.
‘개발자를 채용해야 한다’는 일반적인 논리의 흐름은 한번 더 디테일하게 보면 대개 이런 방식으로 흐릅니다:
개발자가 필요하다
근데 나는 주변에 아는 개발자가 없고, 어떤 사람을 뽑아야 할지도 모르겠으니 개발자(들) 채용할 수 있는 리더를 뽑아야겠다
개발자를 리딩하는 리더면 CTO 지!
라는 흐름으로 많은 Series A급 이전 회사에 CTO가 등장하기 시작합니다.
이 포스팅에서 제일 하고 싶은 이야기는, 이때 비즈니스 리더가 채용해야 하는 사람은 CTO가 아닌 ‘개발리더’라는 것입니다. 특히 기술을 기반으로 하는 비즈니스가 아닌 솔루션이나 최소한의 외주개발로 시작한 스타트업이라면 더더욱 그렇습니다.
한국말로 하면 CTO가 곧 개발리더가 아닌가라고 생각할 수 있겠지만, 여기서 제가 이야기하는 ‘개발리더’는 Tech Lead입니다. 해당 포지션의 일반적인 명칭을 생각해 본다면 Tech Lead나 Head of Engineering 정도가 될 수 있을 것 같습니다. 이 분들의 최소 자격기준을 생각해 본다면
개발 실무 경험이 풍부하고
비즈니스 리더를 비롯한 비개발직군과도 실무적으로 유기적으로 소통할 수 있는 역량을 갖추었으며
기술 자체에 대한 열정만큼이나 비즈니스 혹은 서비스적인 문제 해결에 관심이 많은 사람
정도가 될 것 같습니다.
이런 사람을 찾아서 Tech Lead로 채용하게 된다면 이 사람의 대표 업무는
비즈니스 리더가 그때까지 벌려놓은 수많은 기술부채(솔루션, 외주 개발)등을 수습하고 유지관리를 하면서
그 위에 새롭게 기능들을 자체적으로 고도화하는 역할을 수행하게 됩니다.
위의 지점들 중에서 Tech Lead가 CTO와 가장 크게 다른 지점은 (최소 자격기준은 비슷해도) 바로 대표업무 영역의 성격이 다른다는 점입니다. 제가 지금까지 만나본 성숙한 CTO 중에서 팀원이 없거나 한두 명밖에 없는 상황에서 솔루션을 운영관리하고 그 위에 기능들을 점진적으로 개선하는 사람은 만나본적이 없습니다. 왜냐하면 CTO는 기술을 구조적이고 전략적으로 선택/관리하면서 조직을 통해 구조적으로 기술적 미션과 비전을 달성하여 비즈니스 임팩트를 내야 하는 사람이기 때문입니다. 즉 조직적으로는 CTO가 가지고 있는 기술적 비전과 로드맵을 수행할 수 있는 팀의 규모가 최소 수준 이상으로 존재했을 때 (개발자 기준 최소 10명~20명 이상) CTO가 CTO 답게 일을 시작할 수 있다는 뜻이기도 합니다. 이런 역할을 수행할 수 있고 니즈가 있는 사람에게 Tech Lead가 해야 하는 업무를 맡기기 시작하면 소위 ‘짜치는 짓’이라고 표현하면서 강한 거부감을 보이거나 매우 수동적으로 반응을 하는 경향이 있는데요 (그렇게 반응하지 않더라도 CTO개인적으로 동기부여가 되지도 않을 거고요) 이게 조직적으로는 매우 잘못된 첫 단추를 꿰는 게 됩니다. 비즈니스 성숙도와 매칭되지 않는 CTO를 채용하면, 해당 CTO의 첫 번째 채용은 제가 위에 열거한 문제를 대응해 줄 수 있는 Tech Lead가 되고, 그 이후 CTO 본인의 기술적 비전을 실현시켜 줄 개발자들을 뽑기 시작하기 때문입니다. 비즈니스에서의 니즈는 솔루션을 안정화하여 운영관리하고, 그 위에 점진적으로 문제를 해결할 수 있는 사람을 뽑는 것이었지만 구렁이 담 넘어가듯 벌써 개발팀은 4~5명이 아무런 Product가 없는 상황에서 넘어가기 시작합니다.
제가 팀빌딩에 있어서 보수적인 성향인 것은 분명 맞긴 하지만, 그렇다고 해서 프로덕트팀의 오버스펙 팀빌딩이 정당화되는 것은 아닙니다. 그래서 이때는 Tech Lead가 필요합니다. Tech Lead는 일반적으로 시니어 개발자에서 팀장급으로 정상하는 단계에 있는, 그래서 의지는 높지만 아직 비즈니스적 감각이나 팀빌딩에 대한 역량은 내재화되어 있지는 않은, 다소 정제되지 않은 예비 CTO를 뽑는다는 생각에서 접근해야 합니다. 조직적으로는 아직 규모가 절대로 클 수가 없는 상황이기 때문에, 고객향 서비스를 고도화한다고 해도 아직은 외주나 솔루션에 의존하는 구조를 유지하면서 내재화 인력을 기반으로 어드민 혹은 내부 생산성을 고도화하는 프로덕트(예: 슬랫봇) 하나둘씩 만들면서 업무를 진행하는 것이 실무적 전체 생산성을 타협하지 않고 운영할 수 있는 방법입니다. 과정에서 Tech Lead 역시 고객향 서비스보다는 어드민, 내부 프로세스의 시스템화를 통해 도메인지식을 확보할 수도 있고요.
이런 Tech Lead가 있는 팀을 두 팀정도 만난 적이 있습니다. 두 회사 모두 각자의 도메인에서 잘 자리 잡고 있고 Series-B 이상 투자를 유치하기도 한 규모 있는 회사로 성장하고 있습니다. 두 팀 중 첫 번째 팀의 경우 아직 저 조차도 어떤 비즈니스 스테이지에 어떤 프로덕트 리더가 필요하고 어울리는지 소화를 하지 못한 상태에서 만났던 팀이긴 했었는데요. 그 회사에서 CTO라고 하면서 저한테 소개해준 분은 저보다 나이와 경험도 상당히 적어 보이고, 또 신기하게도 기술에 대한 이야기는 그리 많이 하지 않고 서비스와, 그리고 본인의 취미생활에 대해서만 한참 이야기를 나눴던 기억이 있습니다. 개발 조직은 그렇게 크지 않았지만 규모나 팀 구성자체에 있어서도 그렇게 큰 고민이 있어 보이진 않았고요, 무엇보다 그냥 필요하면 본인이 팀원들과 뚝딱뚝딱 만들어가면서 서비스를 만들어가고 있다는 이미지가 강했습니다. 그 회사 대표님은 이분이 기술역량이 압도적이진 않더라도 지금 우리 비즈니스에서 필요로 하는 기술 역량에 대한 부분은 충분히 갖추고 있는 사람이기 때문에 CTO로 불러도 문제가 없을 것 같다고 이야기했었습니다. 두 번째 팀은 꽤 최근에 제 지인분의 소개로 만나 뵙게 된 팀이었습니다. 이 대표님은 벌써 스타트업에서 한차례 성공적으로 EXIT을 하시고 새로운 사업을 도전하고 계신 연쇄창업가셨는데요, 이 분도 첫 번째 회사 대표와 마찬가지로 기술역량에 있어서는 압도적이지는 않을지 몰라도 우리 회사에서는 너무 완벽한 핏인 개발리더라며 저에게 팀 소개를 해주신 부분이 인상적이었습니다. 회사에서 그 리더분이 무슨 역할을 하시는지 여쭤봤을 때, PM부터 시작해서 프로덕트팀을 조직적으로 관리하고 있고, 개발실무를 또 총괄하고 있으며 무엇보다 비즈니스적으로 대표님과 말이 너무 잘 통해서 매우 만족하면서 일하신다는 이야기가 굉장히 인상적이었습니다. 프로덕트 전문성이 없는 비즈니스 리더분들임에도 불구하고 본인 서비스가 필요로 하는 기술역량의 수준을 정확히 진단하고 채용했으며, 비즈니스와 매우 또 밀접하게 협업하고 있는 개발리더분들의 태도 역시 매우 멋있다고 느꼈습니다.
이런 사람들을 채용하는 방법은 CTO를 채용하려고 했던 방법과 동일합니다. Linkedin에서 열심히 영업을 해보시고, 헤드헌팅이나 채용공고도 올려보시고, 인터뷰를 보게 된다면 회사를 피칭한다는 마음으로 IR을 하듯이 기업을 세일즈를 했을 때 가슴이 두근거리는 사람인지 등을 보시면서, 그리고 그 와중에 이 사람이 해야 하는 업무 영역과 업무 내용은 최대한 명확히 고민해서 공유하면서 진정성으로 승부를 봐야 합니다. 개발리더는 연봉이 높지 않더라도 가급적이면 스톡옵션을 적극적으로 고려하는 것을 추천합니다. 스톡옵션에서 오는 오너십에 감동하지 않는 사람이라면 애초에 해당 기업의 비전에 크게 공감하지 않았음을 의심해 볼 수 있고, 그런 사람들은 겉으로는 아닌척해도 결국 외주 개발이나 솔루션을 관리해야 하는 PM 역할은 절대 선호하지 않을 것이기 때문입니다.
그리고 Tech Lead를 채용 성공한 경우, 초기에는 (그리고 이상적으로는 비즈니스 리더가 가능한 최대한 오랫동안) 데일리를 진행하시는 것을 추천드립니다. 원래 모르는 영역에 그만큼 더 시간과 에너지를 투자해야 하는데, 기술의 영역은 단기적으로 소화하기엔 어려운 주제이기 때문에 매일 대응해야 하는 이슈 하나하나를 짚고 이야기 나눠가면서 프로덕트와 기술 개념을 탑재하시는 것을 추천드립니다. 동시에 기술적인 주제 여부를 떠나 이런 데일리 체크인 프로세스를 통해 Tech Lead가 어떻게 소통하는지, 그리고 어떻게 일하는 사람인지 쉽게 파악할 수 있기 때문에 최악의 경우의 조치 (3개월 수습기간 내 입사취소)를 해야 하는 부분도 조금 더 논리적이고 체계적으로 접근할 수 있습니다. 반대 입장에서 Tech Lead의 경우에도 본인이 기대하고 예상했던 부분들과 현실과 괴리가 분명히 있을 것이기 때문에 그런 부분들을 비즈니스 리더와 잘 소통하며 현명하게 개선하고 해결할 수 있는 조직인지 평가, 판단할 수 있는 좋은 기회가 될 것으로 생각합니다.
이 글에서 이상적이라고 소개드린 Tech Lead는 프로덕트 조직을 많이 경험한 저 역시도 쉽게 찾을 수 있는 사람은 아닙니다. 하지만 이 과정에서 얼마나 진정성 있게 비즈니스 리더가 시간과 에너지를 투자하고 노력했는지에 따라 나중에 팀빌딩과 비즈니스 임팩트 측면에서 기여하는 부분은 정말 많은 차이가 납니다. 예전과는 다르게 이젠 다양한 개발자분들과 교류할 수 있는 다양한 온/오프라인 서비스들이 많이 있는 만큼 열심히 다양한 분들과 만나보시고 소통하시면서 멋진 팀빌딩 하시길 응원합니다.
