핏펫 개발조직의 방향성과 애자일 리더십
이 글에서는 핏펫 개발 조직이 어떻게 진화하고 있는지, 현재까지의 Lesson Learn과 함께 정리된 방향성에 대해 공유하고자 합니다. 가장 중요한 점은 더 나은 모습을 위해 스포티파이의 문서에서도 언급되었던 것과 마찬가지로 현재도 변화하고 있으며 계속 진화해나갈 것입니다.
스포티파이 애자일 조직의 실패 사례
스포티파이의 애자일 조직은 현재 국내 스타트업에서 가장 광범위하게 알려진 사례라고 생각됩니다. 성취하고자 하는 목적을 중심으로 구성된 Squad와 기능 중심으로 구성된 Chapter는 크로스펑셔널한 매트릭스 조직의 근간을 이루어 줍니다. 혁신을 만들고 급성장시키는 것에 비전을 가지는 스타트업에서는 이런 애자일 조직을 명시화한 방법론을 빠르게 이해하고 받아들일 수 있어서 현재도 많은 조직이 채택을 하고 있고 또 이를 통해 애자일 조직으로 성장해 나갈 것을 기대하고 있습니다.
다만 이 널리 알려진 스포티파이 애자일 조직의 모델에 대한 실패 사례도 많이 언급되고 있습니다. 스포티파이의 애자일 모델이 실패했다기보다는 일반적으로 우리가 알고 있는 명시화된 애자일 모델의 문제점에 대해 공유되고 있습니다. 이에 대해 스포티파이는 2012년 해당 내용이 공표된 문서에서조차 이렇게 말하고 있습니다.
우리는 이 모델을 발명한 것이 아니다. 스포티파이는 빠르게 진화하고 있고 이 문서는 그 진행단계의 스냅샷일 뿐이다. 여정은 계속되며 이것을 당신이 읽고 있을 때 우리는 이미 변해있을 것이다.
우리가 쉽게 받아들이고 있는 스포티파이의 애자일 모델은 다음과 같은 문제점이 있으며, 이는 인용에 따르면 실제 스포티파이의 근무자들도 인정하고 있습니다.
- 챕터 중심의 매트릭스 관리는 실제로 잘 워킹하지 않았다
- 스쿼드의 목적이 상당수 오래 지속되었기 때문에 크로스펑셔널하게 운영되기는 어려웠음. 챕터의 중심 역할을 하는 기술적 테크 리드는 스쿼드에 종속되지 않았기에 팀의 구성원 변경이나 새로운 스쿼드를 만드는 것은 사실 제한이 많았음
- 스쿼드에 소속된 구성원들에게는 단순히 기술 역량을 높일 수 있는 가이드만 필요하지 않았음. 회사생활에 대한 적응과 온보딩, 그리고 적절하게 커뮤니케이션을 하는 것과 스쿼드 내부에서의 업무 일정 조정이 필요한 상황이 빈번하게 발생함에도 스쿼드 책임자인 PO가 테크 구성원의 그런 문제들을 모두 해결할 수 없었음
- 위의 사례는 전적으로 각 스쿼드의 테크 구성원들을 담당하는 단일 관리자가 없었기 때문임. mini-CEO 역할을 하는 PO에게 mini-CTO 역할을 기대할 수 없었음. PO에게도 기술 및 일정에 대해 의논할 동등한 급의 테크리드가 필요했으나 챕터리더의 역할에는 그것이 빠져 있었음
2. 모든 스쿼드, 구성원에게 주어진 자율성 뒤에 프로세스가 빠져 있었다
- 구성원에게 자율성을 주는 것은 팀 간 업무 프로세스가 서로 제각각이 되는 혼란함을 주었음. 이에 팀 간 협업이 어떻게 이루어져야 하는지에 대한 공통 프로세스를 만들기가 어려워졌고 결국 조직의 생산성을 떨어뜨리게 됨
- 구성원 간, 팀 간 협업을 함에 있어 기존의 Waterfall이나 관료주의에서 강조하는 명시적인 프로세스가 있어야 함. 협업할 때의 방식이나 우선순위를 조율할 수 있는 기준이 있어야 함
- 특히 우선순위는 경영진의 방향성에 의해 목표가 얼라인되어 내려와야 하며 그에 따라 스쿼드 내에서의 업무 분배를 우선 고려했어야 함
3. 모든 구성원들이 애자일 정신을 오롯이 이해하지 못했다
- 애자일조직의 역할이 정의가 되었다는 것은 구성원들이 어떻게 주도성을 가지고 일에 대한 책임을 갖고 일하는지에 대한 동기부여를 주진 못했음
- 구성원들은 입/퇴사로 인해 변경될 수 있고 그에 따른 교육비용이 추가되며 문화적으로 애자일 정신을 받아들이지 못하는 구성원이 항상 존재했음
- 애자일이라기보다는 Not-Waterfall 적인 업무 진행은 이도저도 아니게 되었음
현재 핏펫 개발조직의 모습은?
저희는 스포티파이의 실폐사례를 먼저 접할 수 있었기에 급진적으로 애자일 조직으로 전환해야 한다기보다 현재 구조에서 점진적으로 필요에 의해 하나씩 바꾸어가는 방법을 취하고 있습니다.
가령 예를 들면 전체 개발조직이 스쿼드화되지는 않았습니다. 핏펫은 현재 스포티파이의 조직구성을 차용한 주요 3개의 스쿼드가 주축이 되어, 데이터실, 인프라팀, 그리고 물류솔루션팀이 개별로 구성되어 있습니다. 또한 스크럼 내에서도 QA와 모바일은 중복 스쿼드에 크로스 배치가 가능한 구조로 되어 있어 팀의 구심점이 스쿼드보다는 챕터에 가깝습니다. 이는 기존 스타트업에서 QA와 모바일을 별도의 팀으로 분리한 모습에 가깝습니다. 그리고 지금 이순간에도 구성원과의 합의를 거쳐 혼란을 주지 않는 범위 내 조직 내 변화가 조금씩 진행 중이며 효과적인 실험을 해보려고 합니다.
또한 무분별한 자율성으로 생산성이 떨어지는 일을 막기 위해 방향성의 얼라인을 전사적으로 통일되는 것을 중시했습니다. 비전과 비전 내 방향성이 경영진이나 리더군에서 수립되면 그 구체화하는 과정에 대한 주도성을 점진적으로 스쿼드에 내려줌으로써 수직과 수평을 적절하게 섞으려고 합니다.
마지막으로 협업 프로세스에 대한 명시화도 진행중인데 이는 아래 테크리드의 리더십과 R&R에서 자세하게 다루어보겠습니다.
핏펫의 개발조직이 나아갈 방향성 1. Role-driven with Rank-driven
핏펫은 Role-driven 기반으로 Rank-driven이 혼합된 방식으로 의사결정하는 체계를 갖추어 나가려고 합니다.
Role-driven 의사결정은 각 역할을 맡은 구성원이 결정권을 가지는 방식입니다. 가령 엔지니어가 어떤 의견을 내어도 마케팅비의 분배는 마케터의 결정사항입니다. 이 방식의 가장 중요한 점은 매니징의 역할을 상위 직군이 아닌 역할 직군으로 이해하는 것에 있습니다. 따라서 매니저, 또는 리더는 각 엔지니어들이 조화롭게 자신의 역량을 발휘하도록 돕는 역할을 함에 있습니다. 이런 Role-driven 방식은 구성원이 동기부여를 가지고 책임감과 주도성을 발휘할 때 혁신을 이뤄낼 수 있습니다. 그러나 의사결정자가 많아지고 의견 충돌이 빈번해지는 가운데 생산속도는 늦춰질 확률이 높습니다.
반면, Rank-driven 의사결정 방식은 기존의 직급체계에서 흔히 볼 수 있는 방식으로 속도면에서는 Role-driven에 비해 우월합니다. 이는 서로 다른 의견이 있을 때 상위 의사결정자가 빠르게 결정할 수 있기 때문이며 결정 시간을 최소화할 수 있는 반면 해야 할 일이 명확하고 의사결정자가 경험에 따른 높은 직관력을 보유하고 있어야 합니다.
핏펫의 개발조직은 구성원의 전문성과 실행력을 반복되는 태스크를 통해 확인하여 신뢰를 쌓고 점진적으로 그들에게 의사결정의 자율성을 보장해가는 방향을 추구합니다. 이는 처음부터, 그리고 모두에게 Role-driven 방식의 의사결정을 보장해주기보다 반복되는 신뢰를 기반으로 Rank-driven에서 Role-driven으로 이전해감을 의미합니다. 그리고 애자일 조직이지만 Rank-driven 기반의 상위 의사결정자가 존재하며 상호 신뢰에 따라 의사결정 권한을 분배해나감을 의미합니다.
무엇보다도, 수평과 수직 한쪽에만 치우치는 것이 아니라 상황에 맞게 적절하게 조화를 갖추어 실제 업무의 아웃풋이 나오도록 유도하고, 생산성을 높이며 그 생산성과 아웃풋의 질이 높은 방식을 찾아보는 것을 반복하는 것. 이것이 저희가 추구하는 개발조직의 협업 프로세스입니다.
핏펫의 개발조직이 나아갈 방향성 2. 테크리더의 리더십과 R&R
스포티파이의 애자일 조직 모델은 수평적인 방향성에 과도하게 집중되어 있고 프로세스조차 명확한 가이드 없이 자율성에 의지한 과오가 있습니다. 그 중 협업 프로세스를 명시화하고 스쿼드 간 협업을 위한 프로세스, 그리고 챕터의 적절한 업무 분배를 위해 테크리더의 R&R을 정리해 보았습니다. 저희는 독창적으로 챕터 리더(이하 CL) 외 각 스쿼드마다 테크니컬 리더(TL)를 별도로 두기로 했습니다. CL과 TL의 역할은 아래에 요약해 보았습니다.
CL의 역할
CL은 직무별 Mini CTO의 역할을 합니다. 챕터 내 기술에 대해 오너십을 가지고 TL과 챕터별 엔지니어 간 중재인 역할을 합니다. 유동적으로 특정 스쿼드 내 소속되어 실무 역할도 수행할 수 있습니다.
- 멘토 역할
- 1:1 미팅을 통해 챕터 구성원의 기술적 커리어에 도움을 주고 기술 자문을 합니다
2. 팀 관리
- 스쿼드 내 엔지니어 구성원을 배치하는데 주도적인 의사결정을 가집니다. 이를 위해 코드 리뷰, 1:1 면담을 통해 챕터 구성원의 동기부여요소와 역량을 파악합니다.
- 코드 리뷰 프로세스 설계 및 체계화에 대해 책임을 집니다.
- 스쿼드 간 기술적 논의를 위한 미팅의 주체 역할을 하여 기술적 의견 불일치나 갈등을 해결합니다.
- 아키텍처, 코드 퀄리티를 관리하고 엔지니어 구성원의 문서화를 장려합니다.
- 구성원의 결과물에 대한 품질과 속도가 점진적으로 향상할 수 있도록 지원합니다.
3. 전략
- 신규 기술의 도입을 검토하고 적용하는데 의사결정을 합니다. 이는 기술로써 장기적으로 더 빠르게, 더 정확하게 회사의 비전을 달성할 수 있도록 돕는다는 목표 아래 실행됩니다.
- 아키텍처의 현황을 파악하고 개선점을 도출, 방향성을 제시합니다
- 개발코드의 테스트 프로세스에 대한 정책을 수립하고 구성원에게 제시합니다
- 빌드타임을 줄이거나 스쿼드 간 공통으로 쓸 수 있는 개발산출물 등 기술적 생산성을 기여할 수 있는 일을 위한 업무 방향을 제시하고 실행될 수 있도록 합니다. 이를 위해 합의 하에 기존 스쿼드의 인력차출을 요구할 수도 있습니다.
TL의 역할
TL은 스쿼드별 Mini CTO의 역할을 합니다. 스쿼드 개발 공수 관점에서 업무의 일정을 리딩하고 조율하며 동시에 실무 역할을 수행합니다. 회사의 비즈니스 및 프로덕트 관점에서 스쿼드 내 기술 현황을 파악하고 관리합니다.
- 멘토 역할
- 구성원들에게 스쿼드 내 소속감을 부여하고 회사의 방향과 얼라인된 스쿼드 내 미션을 인지시킵니다
- 우선순위와 일정, 업무 역량을 고려하여 1: 1 면담을 통한 구성원의 업무를 조율합니다.
- 구성원의 직무 역량 외 협업자로서 평가를 하며 구성원의 평가를 주관합니다.
2. 팀 관리
- 스쿼드 내 구성원의 업무를 조율해 적합한 사람에게 적합한 업무가 정해진 기간에 효과적으로 배분되도록 합니다.
- 백로그의 업무도 필요 시 기술적으로 잘개 쪼개어 구성원에게 분배합니다.
- 스쿼드 내 엔지니어 구성원의 분쟁을 조율하고 비프로덕트 조직과 기술적 업무에 관해 PO와 협조하여 일정을 조율합니다.
- 스쿼드 간 업무의 일정을 조율하고 유관 미팅을 주체합니다.
3. 전략
- 스쿼드 내 개발 산출물에 대한 일정을 개발공수 관점에서 PO와 협의 일정에 반영합니다.
- 스쿼드 내 기술적 장애물을 규명하고 실행하여 점진적으로 기술부채가 일정에 반영되어 제거될 수 있도록 합니다.
- CL의 요구사항을 적시에 구성원에게 배분하여 실행합니다.
Ongoing..
앞으로도 저희의 시도는 계속될 것이고 계속 변화할 것입니다. 그리고 그 변화는 구성원과 회사가 동반성장할 수 있는 목표를 위해 이루어질 것입니다. 구성원들이 혼란스럽지 않게 점진적으로 애자일의 본질적인 정신을 추구하기 위해 노력하려고 합니다. 또 한번 멋진 변화와 함께 저희 모습을 공유드리는 날이 오기를 기다리며 글을 마치겠습니다.
읽어주셔서 감사드립니다.
written by Shaun (Juyup Sung)
email: jy.sung@fitpet.co.kr
