Stage 3. 프로덕트 팀빌딩의 시작
완결성 있는 프로덕트팀을 처음 빌딩 하는 단계
MVP로 가설검증이 되고, VC를 설득할 수 있는 수준의 비즈니스 지표의 성장곡선이 나오기 시작한다면, 혹은 유의미한 매출이 발생하기 시작한다면, 드디어 완결성 있는 첫 번째 프로덕트팀의 빌딩을 시작해야 하는 타이밍입니다. 비즈니스 스테이지적으로는 Series A 언저리가 될 것 같습니다. 이번 포스팅에서는 프로덕트 팀빌딩을 위해 비즈니스 리더가 알고 있어야 하는 기본적인 정보들과 추가적으로 참고하면 좋을만한 팀 운영 측면에서의 지점들을 공유해보려 합니다. 사실 프로덕트 팀빌딩은 일반적으로 Stage 2. 에 소개한 Tech Lead를 채용하는 시기에 자연스럽게 진행되긴 합니다만, 개념적으로는 분리해서 소화하는 것이 더 논리적인 것 같아 Stage3.로 따로 소개합니다.
일반적으로 웹서비스를 관리하는 ‘프로덕트 팀’이라고 하면 PM(Product Manager), PD(Product Designer 혹은 UX Designer라고도 업계에서는 부릅니다), FE(Front-end), BE(Backend)를 최소 구조로 운영합니다. 이 구조에서 저번 포스팅에 언급한 Tech Lead까지 더해 본다면 Tech Lead는 두 번째 BE 역할을 해주거나, 아니면 DevOps(AWS 같은 클라우드 인프라나 서비스의 기술적인 배포등의 프로세스를 관리하는 사람) 역할을 해줄 수 있습니다. 각각의 포지션에 대한 상세한 설명은 구글에서 매우 잘 알려줄 수 있으니 생략하면 될 것 같으나… 팀 빌딩에서 참고할 점은 만약 앱 서비스를 운영하는 회사라고 한다면 웹 Front를 개발하는 FE개발자 대신 앱 개발자가 필요한 점입니다. 앱 개발은 일반적으로 애플의 iOS 운영체제, 그리고 안드로이드 운영체제를 고려하여 각각 iOS 개발자, 안드로이드 개발자를 채용하는 것이 ‘정석’ 일 수 있으나, 서비스 초기에는 기술적으로 하나의 기술스택으로 두 운영체제를 커버할 수 있는 언어인 Flutter 혹은 React Native 개발자를 통해 해소하기도 합니다. 개발자 시장의 공급현황을 기반으로 보았을 때는 현실적으로 RN(React Native) 개발자가 조금 더 효율적인 선택지가 될 것 같고요. 여기서 참고할 점은 위에서와 같이 최소 4~5명의 인력이 한 번에 채용되어야 하는 경제적으로 매우 큰 의사결정이기 때문에 절대로 발생하는 고정 인건비의 증가폭을 간과하고 팀빌딩을 진행하면 안 됩니다. 최악의 경우는 5명 정도 팀 빌딩을 해야 하는 상황인데 2~3명 정도만 뽑아놓고 돈이 없으니 이 인원으로 어떻게든 해보자!라는 식의 접근 방식입니다. 부득이하게 2~3명만 채용을 해야 하는 상황이라면 그 인원에 최적화된 포지션들과 프로덕트 관리 전략이 따로 있기 때문에 우선 해보다가 흐지부지 계획이 수정되는 상황은 최대한 피해야 합니다.
프로덕트 팀 빌딩을 위처럼 진행한다면, 그다음주제는 비즈니스 리더가 프로덕트 팀 빌딩 및 운영을 하면서 알아두면 좋은 점들입니다. 첫 번째로, 팀 빌딩은 그 속도가 느릴 것이기 때문에 염두해서 팀 빌딩을 해야 한다는 점입니다. 위에 4~5명은 프로덕트를 만들어낼 수 있는 ‘최소’ 인원입니다. 그 말인즉슨, 5명 중 몇 명이 부분적으로 채용이 된다고 하면 현실적이고 체계적인 프로덕트를 만들 수 있는 단계가 아니라는 뜻입니다. 따라서 팀빌딩이 되어야 하는 호흡을 너무 길게 가져가는 것보다는 집중력을 가지고 밀도 있게 진행하는 것을 추천합니다. 더 이상적으로는 심지어 이 단계에서도 한 명 한 명 좋은 동료가 온보딩 될 수 있는 버퍼를 확보하기 위해서 실무적으로는 외주 개발등을 진행하며 프로덕트 로드맵을 이행하면서 병렬적으로 팀 빌딩을 진행하는 것이 비즈니스적으로는 리드타임을 최소화할 수 있는 방법이라고 생각합니다. 물론 어떤 지점에서 어떤 기능들은 솔루션, 외주화가 괜찮고 어떤 지점들은 가급적이면 처음부터 꼭 내재화해서 진행하면 좋을지는 프로덕트 전문가와 상의를 하면서 전략을 구상하는 것을 추천드립니다. 모든 개발 영역을 외주화 하는 것이 무조건 건강한 것은 아니기 때문입니다. 누차 이야기하듯 개발 외주나 솔루션은 결국 비즈니스 임팩트를 견인하기 위해서 의도적으로 기술부채를 감당하면서 선택하는 옵션지이기 때문에 어떻게 해서든 감당할 수 있는 기술부채 수준을 관리하면서 프로덕트 로드맵을 구상하고 운영하는 것이 바람직합니다.
두 번째로 프로덕트 팀에 대해 비즈니스리더가 참고해야 할 만한 점은, 정확한 공식은 없겠지만 자체 프로덕트를 만드는데 일반적으로 소요되는 시간은 비즈니스 리더가 기대하는 논리적으로 산출된 타임라인의 최소 1.5배 ~ 2배 정도 타임라인으로 생각하면서 소통하는 것이 좋다는 점입니다. 왜 소요시간이 그렇게 길어지는지는 여러 가지 이유가 있지만, 대표적인 이유로는 팀빌딩 직후에는 아직 조직의 협업 수준이 성숙하지 않은 상황일 것이기 때문에 서비스에 대한 이해도 및 팀빌딩에 시간과 리소스가 소요되기 때문입니다. 일을 하는 도구들, 방식들, 그리고 프로세스에 대해서 학습하고 공유하고 공감대를 쌓아야 하고 개발을 하기 위한 기술적, 행정적 인프라세팅을 하는데도 생각보다 많은 시간과 비용이 투입됩니다. 이 지점들이 대부분의 비즈니스 리더분들이 논리적으로 도출하는 일정에는 거의 들어가 있지 않습니다. 추가적으로 일정이 딜레이 되는 이유를 생각해 본다면, 프로덕트팀이 신규로 개발할 자체 서비스도 있겠지만 기존 레거시 서비스의 유지보수 운영관리에 대한 책임이나 고도화에 대한 니즈가 비즈니스적으로 발생하기 때문입니다. 이렇게 팀 리소스가 기존 시스템에 필요해지는 상황이 발생한다면 context switching 비용 때문에 전체 개발 생산성이 떨어질 수밖에 없습니다. 다만, 혹시나 오해가 있을까 봐 이야기를 해둔다면 저는 개인적으로 팀을 기존 시스템의 운영유지 및 고도화에 최소한 구조적으로는 지속적으로 투입시키면서 팀을 운영하는 것이 더 바람직하다고 생각하는 편입니다(생산성이 좀 떨어지는 한이 있더라도). 프로덕트팀이라고 하는 기존과는 다소 다른 관점과 전문성을 가진 집단이라고는 하지만 결국 같은 서비스를 만들어가는 식구입니다. 그렇다면 이 프로덕트팀은 초기에 조금 생산성을 양보하더라도 서비스와 조직에 대한 이해도를 높여야 하는데 에너지를 많이 활용하는 것이 팀에겐 중장기적으로 좋은 선택이라고 생각합니다. 마지막 대표적인 이유로는 버그대응입니다. 버그대응은 위에 이야기한 ‘유지보수 운영관리’와는 좀 다른 영역인 이유가, 유지보수는 기 구축된 시스템을 고도화하거나 개선하는 계획중심적인 업무 영역이라고 본다면 버그대응은 예상하지 못했던 갑작스러운 이슈대응이기 때문입니다. 서비스를 운영하는 데 있어 버그대응은 (케이스에 따라 다르겠으나) 팀의 최우선순위를 차지합니다. 예상하지 못했던 이슈에 대한 분석 및 이슈 가시화와, 대응 방안의 수립 및 체계적인 대응을 순차적으로 진행하는 이 모든 단계의 업무가 기존 비즈니스 리더가 생각했던 프로덕트 빌딩 계획에는 포함되어 있지 않았을 확률이 높습니다. 이런 이유들로 최초 비즈니스 리더가 생각한 일정보다는 소요시간이 더 발생하게 됩니다.
팁을 하나 또 드리자면, 팀을 본격적으로 빌딩 하기 전 Tech Lead나 PM을 먼저 온보딩 시키고, 기존 솔루션을 운영하면서 도메인 지식을 최대한 먼저 습득시켜 놓는 것을 추천드립니다. 도메인 지식을 PM 혹은 프로덕트팀의 리더가 먼저 확보하고 있다면, 팀에서는 온보딩에 조금 시간이 걸린다고 해도 프로덕트의 요구사항들은 잘 정리되고 준비시킬 수가 있어서, 전체 프로덕트팀의 생산성을 어느 정도 보완하는데 도움이 된다고 생각하기 때문입니다. 그래서 이전 글에서도 Tech Lead를 채용하시면 최대한 데일리로 체크인 미팅을 하면서 실무적으로 최대한 서비스와 조직을 이해하고 공감할 수 있도록 비즈니스 리더가 노력해야 한다고도 이야기하기도 했고요.
마지막으로 비즈니스 리더분들에게 하고 싶은 이야기는,
프로덕트팀이 아무리 어렵더라도, 어떻게든 이해하고 소화하려는 노력이 필요하다는 점입니다. 또 한 번 이야기하지만, 프로덕트팀도 같은 조직에 소속된 동료이고 공동체 구성원입니다. 기술적 전문성을 가진 집단이고, 실무적으로 집중하는 포인트들이 비즈니스 관점에서는 멀어지는 일이 생각보다 빈번하기 때문에 공감대를 맞추거나 동기화를 시키는 부분이 매우 어렵다는 부분은 충분히 이해합니다. 저도 예전 조직에서는 비즈니스 리더들이 프로덕트 조직과 소통하는 것을 어려워하고 불편해해서, 저와만 소통하면 되도록 프로세스도 운영을 해보고 다양한 시도들을 해보기도 했었는데요, 결국 비즈니스 리더가 근본적으로 프로덕트 조직을 이해하고 공감하지 못하면 아무리 프로덕트 리더가 중간에서 조율을 해도 조직적인 융합에서 오는 시너지의 한계지점이 너무 명확하게 발생합니다. 그 모든 내용들을 다 파악하고 이해하고 공감하는 것은 현실적으로 불가능하겠지만 프로덕트 팀의 리더를 잘 활용하든, 아니면 프로덕트 전문가의 구조적인 활용을 통해서든 팀과 소통하고 협업해 보려는 지속적인 방법들을 찾아보는 것을 추천드립니다. 어느 정도 수준까지 노력하면 충분한 지점인지 궁금하다면, 개인적으로 판단하는 기준점은 ‘프로덕트 팀의 업무 우선순위와 요구사항 등에 대해서 충돌하고 논쟁하면서, 그리고 그 과정에서 팀을 설득도 해보고 설득도 당해 보면서 일하고 있는 수준’이면 저는 충분히 건강하다고 생각합니다.
