Stage 5. CTO의 등장
프로덕트 팀빌딩의 마지막 단계-
프로덕트 조직이 빌딩 되는 과정을 소개하는 시리즈의 마지막 포스팅입니다. Head of Product까지 등장해서 조직이 체계적으로 관리되기 시작했다면 마지막으로 프로덕트 조직 빌딩의 화룡정점을 찍는 사람은 CTO입니다. 비즈니스 성숙단계를 기반으로 생각을 했을 때도 Series-B 이상을 가게 된다면 우선 VC나 투자사에서부터 CTO를 채용해야 한다고 강조할 정도로 자연스럽게 CTO 채용에 대한 니즈는 등장하게 됩니다.
CTO를 채용을 해야 하는 지점이 너무 늦은 게 아니냐는 궁금증이 있을 것 같아 제가 생각하는 CTO의 채용타이밍이 Series B 이후인지에 대해서 한번 설명해 보겠습니다. 우선 Head of Product급의 리더십을 기반으로 프로덕트팀이 양적으로 질적으로 커지기 시작하면서 오는 현상이 있는데요, 바로 조직의 생산성을 극대화하기 위해 프로덕트도 기능중심 조직에서 점진적으로 목적조직으로 진화하기 시작하는 것입니다. 그리고 개발조직도 이 방향에 따라 목적조직화 되면서 커질 때는 반드시 CTO의 기술적 리더십이 필요합니다.
목적조직은 Silo 혹은 Squad라고도 부르는 하나의 조직 단위에 직무 구조의 완결성을 가지고 일하는 개념으로 생각하시면 됩니다. Stage 3. 에서 처음으로 프로덕트팀 빌딩이 시작될 때의 조직 구조도 역시 silo 형태라고 생각하실 수 있습니다. 프로덕트 조직은 일반적으로 최소단위의 완결성을 가진 목적조직으로 시작했다가, 점차 기술 부채의 체계적인 관리나 직무 중심적 업무 생산성 개선을 이유로 기능 중심적으로 진화하는데요. CTO가 등장하는 이 단계는 기능 중심적으로 운영되는 조직에서의 전체 생산성이 Head of Product나 소수의 리더십을 기반으로 조율하고 운영하기에는 벅차지는 지점이 오기 때문에, 임지니스 임팩트를 내는 생산성 개선을 이유로 많은 조직이 이때 한번 더 목적조직으로의 개편을 시도합니다. 참고로 해당 목적조직 구조에서의 가장 큰 장점을 본다면 팀레벨까지 비즈니스 주제, 목표가 명확하고 구체적으로 하달되어 팀의 오너십이 쉽게 올라올 수 있다는 점이고, 단점을 생각해 보자면 각자 silo가 가진 목적에 벗어나는 문제를 해결해야 하거나 다른 조직과의 협업에서는 오히려 더 높은 비효율성이 발생한다는 점입니다.
이 단계에서의 프로덕트 구조에 대해 조금 더 이야기를 해보자면, 많은 조직들이 목적조직구조로 고도화를 한다고는 하지만 대부분은 silo와 더불어 기능중심적인 조직의 조합(Hybrid) 형태로 운영되게 됩니다. 여러 가지 이유가 있기는 하지만, 대부분의 목적조직은 비즈니스 KPI 혹은 목적을 중심으로 설계가 되는데 비해 프로덕트에는 비즈니스 목적과는 쉽게 매칭이 되지 않는 기능중심적인 영역들이 있기 때문입니다. 비즈니스 코어로직을 담당하는 조직들이 그렇고, 인프라등을 관리하고 운영하거나 Data Engineering을 하는 조직들이 대표적인 예시가 될 수 있을 것 같습니다. 이렇게 기술적으로도 전체적인 최적화가 될 수 있도록 목적조직과 기능조직 간의 기술적 R&R을 분리하고 관리하며 그렇게 또 운영될 수 있도록 고객향으로는 보이지 않는 다양한 기술적인 개선을 주도하고 관리해야 하는 것이 바로 CTO의 역할 중 한 꼭지입니다. 물론 이런 기술적 로드맵과 비전을 기반으로 조직에 대한 교육, 코칭을 통한 구성원 역량강화 및 채용을 통한 조직에 필요 전문 리소스를 확보하고 운영하는 것도 CTO의 역할들이기도 합니다.
이렇게 CTO가 등장할 때 프로덕트 조직 안에서는 큰 변화가 한번 더 발생하는데요, Stage 4. 에서도 언급했던 전문성이 다른 리더십 체인지에서 오는 조직 운영 관점의 충돌이 그것입니다. Stage 4. 에서 Head of Product가 등장하며 조직은 ‘생산성’과 ‘업무 가시화 및 준수율’등을 매우 중요한 기준으로 두고 한번 체질 개선이 됩니다. 그런 조직에 CTO가 등장하면서 기술적으로도 확장성 및 안정성에 대한 새로운 가치관이 추가적인 우선순위로 등장하게 되는데요, 그러다 보니 프로덕트 로드맵 과제 우선순위 관리의 난이도가 매우 높아지게 됩니다. 예를 들어 컬리에서는 커머스시스템을 쇼핑몰 솔루션 시스템에서 자체개발하는 시스템으로 점진적으로 개편하는 프로덕트 로드맵을 4년 동안 운영하면서 결국 100% 자체 개발 시스템으로의 구축을 완성했는데요, 이런 기술적 개편 로드맵을 진행하면서 비즈니스적으로 진행해야 하는 우선순위 과제들을 수행했어야 했고, 이 부분에서의 실무적으로의 실무 과제들의 우선순위 최적화가 정말 어려웠던 기억이 있습니다. 이렇게 프로덕트의 기술적인 기반 고도화와 비즈니스 우선순위 과제와의 사이에서 최적화를 위해 Head of Product뿐만 아닌 CTO도 참여하여 기술전략을 설계하고 그에 따른 체계적인 계획을 세우고 운영을 해야만 합니다. 기술적인 과제 중 중요한 과제일수록 중장기적인 관점으로 접근해야 하는 경우가 많지만 비즈니스적으로의 대부분의 과제는 단기에서 중기적인 과제가 많습니다. 어떤 프로덕트 조직은 비즈니스의 호흡을 맞추겠다고 단기적인 과제들을 위주로만 조직을 운영하곤 하는데, 개인적으로는 현명한 선택이 아니라고 생각합니다. 나중에는 감당하지 못할 수준의 기술부채가 되어 프로덕트의 모든 과제가 중, 장기적이고 기술 중심적인 과제가 되어 버리기 때문입니다. 물론 반대의 경우는 말할 필요도 없을것 같습니다. 따라서 현실적으로 그때그때 기술적, 비즈니스적, 운영적 관점들을 고려하여 프로젝트들을 최적화를 진행하며 업무를 진행해야 합니다. 이 과정에서 기술적인 과제들을 점진적으로 구조적으로 해결해 가면서도 비즈니스가 계속 성장할 수 있도록 경험들이 쌓일 수 있는 기술 부채와 과제 우선순위 최적화를 조율해야 하는 것이 비즈니스 리더십 관점에서 CTO의 큰 역할입니다.
비즈니스가 성장하는 과정에서의 프로덕트 이야기는 여기까지입니다.
CTO가 등장한 이후에도 물론 너무 많은 비즈니스와 프로덕트 조직의 성장의 이야기들이 있겠으나 이번 포스팅은 비즈니스 리더들을 위한 초기 비즈니스에서부터 프로덕트 조직이 성장하는 이야기들을 하기로 했으니, 이 정도 단계가 된다면 비즈니스는 더 이상 ‘초기’ 비즈니스라고 보기에는 충분히 성숙한 상태가 되어 버렸기 때문입니다. 이번 시리즈에서 프로덕트 팀빌딩이 되는 단계들을 일반적으로 생각하는 팀빌딩 순서나 타이밍보다는 상대적으로 보수적으로 안내했습니다. 물론, 실제로 그렇게 일하는 조직들이 있기 때문에 이렇게 소개한 것도 있지만, 이번 시리즈의 취지는 해당 프로세스를 통해 비즈니스 리더들이 Product Literacy (프로덕트 문해력)이 올라올 수 있는 가장 자연스러운 순서를 생각하면서 작성하다 보니 더더욱 그런 것도 있는 것 같습니다. 비즈니스 리더는 모든 주제에 대해 전문가가 될 필요는 없지만 각 주제별 전문가들을 파악하고 이해할 수 있어야 합니다. 그러기 위해서는 불가피하게 프로덕트와 기술의 영역도 경험을 기반으로 한 최소한의 주관과 감각은 익혀야 합니다. Stage 3. 이상의 프로덕트 조직을 대상으로 비즈니스 리더가 갑자기 의미 있는 역할을 해 내는 것은 정말 쉽지 않습니다. 그래서 Stage 1.부터 차근차근 프로덕트에 대한 이해도와 감각을 체계적이고 점진적으로(Product Literacy) 쌓아 올려야 프로덕트의 복잡성이 상당히 고도화된 상황에서도 유효한 리더십을 발휘할 수 있습니다. 물론 이 정도 성숙도를 지닌 조직에서는 비즈니스 리더가 직접 감당하지 않더라도 CSO나 다양한 리더십들을 활용하여 구조적으로 문제를 해결할 수도 있습니다만, 결국 비즈니스 리더가 프로덕트 조직을 비즈니스와 얼마나 잘 얼라인(방향성의 정렬) 시키는지에 따라 그만큼 전체 조직의 비효율이 줄어들기 때문에, 그리고 이 이상의 복잡성도 감당이 가능해질 수 있기 때문에, 포기하지 않고 CTO와 Head of Product, 그리고 Tech Lead에게 비즈니스의 미션과 비즈니스의 목표, 그리고 과업들의 당위성, 중요도, 시급성등을 잘 설정해 주시고 함께 문제를 해결해 나가시길 추천드립니다.
