일상/스타트업

초기 스타트업 엔지니어링 팀 구축

jordan.bae 2025. 3. 26. 18:54

최근 팀에서 엔지니어링팀을 어떻게 확장할지에 대한 논의도 많고, 관련해서 멘토링도 받고 있다. 팀 구축 그리고 구축 과정에서 고려해야 할 부분에 대해서 자료를 찾는 중에 일본에 Ubie라는 AI 헬스케어 스타트업 CTO께서 작성하신 The Evolution of an Early-Stage Startup Engineering Team 라는 엔지니어링 팀이 3명에서 19명이되기까지 여정에 대한 포스팅을 읽고, 인상깊었던 부분은 아래와 같다.

- 초기 팀원 바는 절대 타협하지 말아라. 초기 팀이 구축한 시스템은 변경하기 굉장히 어렵고 이는 비즈니스가 성장했을 때 채용/제품 개발에서 큰 병목이 된다. -> 맞다. 비즈니스가 성장할 때 엔지니어링 부채를 해결하기 위해서 일정시간 보장 받는것도 굉장히 어렵고, 이 과정에서 성장이 멈추기도 한다. 채용 측면에서도 시스템이 많이 낙후되어 있는 경우 정말 빠른성장을 하거나 많은 투자를 받은 경우가 아니면 채용이 점점 어려워지고 바를 낮춰야하는 악순환이 반복된다.

- 초기에 채용 진짜 진짜 어렵다. 그럼에도 멈추지 않고 계속 다양한 시도 및 조치를 반복했고, 채용 추천시스템, 채용플로우 최적화등을 지속적으로 노력해서 해결. -> 진짜 어렵다. 내부적으로 내부 네트워크를 통해서 해결하는 방법밖에 없다고 생각.

- 초기 멤버 채용시 아래와 같은 것들을 검증해라
1. 검증에 능하고, 테스트용 일회성 애플리케이션을 만들 수 있는 사람
2. 제품을 만드는 ‘과정‘이 아닌, ‘제품의 성장’에 헌신할 수 있는 사람
3. 데이터 부채를 만들지 않는 시스템을 설계할 수 있는 사람 (애플리케이션은 버리고 새로 만들 수 있지만, 과거에 유저가 입력한 데이터는 버릴 수 없다.) 

-> 1,2번은 너무 분명한 포인트여서 3번째 포인트가 인상적이었다. 맞다. 데이터는 변경하기 어렵고 계속 쌓인다. 또, 해당 데이터를 기반으로 비즈니스 로직을 개발하고, 데이터를 분석하고, AI를 만든다. 중요하다.


-2020년 이글 쓸 때 팀 구조: FE+BE 9, SRE 2, QAE 1, DE 2, MLE 3 -> 큰 인사이트는 아니지만 AI기반 스타트업에서 이정도 비율 가져가나 하는 정도. 하지만 팀 구조는 팀바팀.

원문: https://medium.com/@quvo_ub/the-evolution-of-an-early-stage-startup-engineering-team-f8dd5c140468#:~:text=engineering%20team,is%20our%20development%20team%20structure

반응형