10. 개발 조직과 일하는 법
애드테크 종사 3년 만에 개발 조직과 일하는 법을 배우다
예전에 몸 담았던 M사는 '애드테크'에 기반한 스타트업임을 표방했으나 정작 개발 인력은 소수였다. 타 개발사의 솔루션을 화이트라벨링 (라이센스를 구매하거나, 독점 계약을 맺고 겉 포장지만 자사 로고로 바꾸어 판매하는 제휴모델)하고, 소수의 개발 인력으로 이러한 솔루션들에 대한 유지 보수를 하였다. 솔루션 도입에 대한 검토 등부터 사업 개발단에서 진행했기에, 비록 여러 솔루션들을 갖춘 애드테크 스타트업이긴 했으나 개발 조직이라 칭하긴 어려웠다. 이는 초기 자본이 넉넉지 않은 스타트업 특성상 흔히 취하는 전략이다. 아무래도 제로 베이스에서 제품을 개발하는 것에는 시간이라는 자본도 많이 들고, 개발 인건비 라는 자본도 많이 들어가다보니, 제품의 매출 기여도를 빠르게 확인해볼 수 있는 화이트 라벨링 전략을 선호하는 것이다. 물론 경우에 따라 숫자를 확인한 이후에 자사 제품을 새로 빌드하는 경우도 많다. - 비즈니스 도의(道義)상 문제가 없다는 전제하에..
반면, B사는 완전한 개발 조직이다. 경영지원 및 재무 인력을 제외하면 절반 이상은 개발자로 구성되어 있다. 다양한 B2B 솔루션을 보유하고 있는데 이 모든 것을 AtoZ 직접 B사에서 개발하였다. 2018년 조인을 하고 실무상 가장 큰 차이점을 느낀 부분은 그것이었다. 나는 개발자와 일하는 법을 터득해야 했고, 개발 조직에서 일하는 법을 터득해야 했다. B사 또한 효율적인 개발 조직을 만들기 위해 끊임없이 고민을 하는 조직이었고, 감사하게도 2018년을 기점으로 여러 조직적인 변화들을 시도하게 되면서 나 또한 덩달아 값진 경험치를 얻게 된다.
1. 개발자와 일하는 법
기본적으로 '요청'과 '응답'에 기반한 협업 구조이다. 비즈니스 단에서 필요한 개발 과제를 담당 개발 팀에 인입하면, 우선 순위 산정에 따라 순서대로 각 개발 과제들이 처리되는 구조인 것. 이러한 '요청'과 '응답'이 효율적으로 진행되게끔 도와주는 개발 협업 툴들이 있다. 트렐로, 지라 등이 그 예시인데 '카드' 또는 '티켓'이라는 단위로 처리된다. 요청 내용을 '카드' 또는 '티켓'에 적어 넣는데 정해진 탬플릿에 맞게끔 적으면 요청하는 과제의 맥락과, 유형, 관련된 다른 과제, 현재의 우선 순위 등이 포괄적으로 담기게 된다. '텍스트'에 기반한 소통이기 때문에 글 자체를 조리있게 논리적으로 작성하는 것이 중요하며, 필요에 따라 구두 커뮤니케이션이 요구될 수도 있다.
개발 협업 툴 Jira 의 한 화면 예시 (출처 : atlassian 홈페이지)이에 더해 내가 학습한 그들과 '더 잘' 일하는 법은, 해당 과제의 결과물(매출, 유저 리텐션 등 의도했던 지표 임팩트)을 공유하는 것이다. 만약 해당 과제를 통해 매출을 늘리는 것이 목표였다면, 해당 작업으로 인한 실제 매출 증대내역을 사내 메신저 또는 과제 '카드'에 코멘트로 남겨두는 것이 좋다. 이것은 첫째로 개발자들로 하여금 과제 진행에 있어서 오너십을 갖게 해주고, 모티베이션을 불어 넣어주는 효과가 있다. 그저 요청받는 과제들을 수동적으로 '쳐내는' 매너리즘으로부터 벗어나게 해줄 수 있다. 둘째로 나의 '요청'이 '유의미했음'을 입증함으로써 협업에 있어 나에 대한 신뢰도를 높여주는 효과가 있다. 비즈니스 사이드의 수많은 사람들이 본인의 '요청' 과제가 중요하다는 것을 각종 데이터 기반의 프로젝션과 가설로 어필하지만, 그것이 들어맞었는가에 대해 검증하는 절차들은 생략하곤 한다. 본인의 '요청'에 대해 확신이 있다면, 그 결과물에 대한 '검증'도 확신을 갖고 진행하여 장기적으로 본인의 '요청'에 대한 신뢰도를 높일 필요가 있다.
물론 당연하게도 비개발자가 기초적인 개발 지식을 갖추거나, 개발자가 비즈니스 사이드에 대한 이해도를 높인다면 더욱 좋다. 다른 회사와 달리 B사는 비개발 조직과 개발 조직의 직접적인 커뮤니케이션이 빈번했고, 서로의 업무에 대해 많은 관심을 갖고 관련 스터디들을 만들어 운영하곤 했다. 비개발자를 대상으로 안드로이드 스터디가 매일 아침 진행되는가 하면, 머신러닝 스터디, 애드테크 스터디, 독서토론 스터디 등 다양한 스터디를 통해 서로에 대한 이해를 높이고, 더불어 친밀도도 함께 쌓여가며 협업이 보다 용이해지곤 했다.
2. 개발 조직과 일하는 법 ; 펑션팀 vs 미션팀
인력이 부족한 상황에서는, 산업화 시기의 포드 사가 그러했듯 컨베이어벨트 식의 업무 구조가 가장 효율적이다. 개발 조직도 마찬가지다. 클라이언트 (안드로이드, iOS, Web 등의 구조를 갖추고, 필요한 정보값을 요청하는 주체) 개발자와 서버 (클라이언트로부터 받은 '요청'에 매칭되는 '응답'을 내려주는 주체) 개발자, 그리고 프로덕드 디자이너 (개발 제품의 UI, UX 를 기획하고, 디자인 asset 들을 제작하는 주체)를 줄세워 놓고, 그때그때 필요에 따라 과제를 할당하여 진행하는 것이다. 이러한 개발 조직을 function 기반의 조직이라 부른다. 각 기능에 해당되는 사람들은 해당 기능에 충실하며 특정 제품에 국한되지 않고 해당 기능이 활용되는 모든 제품에 필요에 따라 참여하게 된다. 이러한 Function 팀 구조는 아래와 같은 한계점을 지닌다.
1) 과제를 입체적 시각이 아니라 자신이 맡은 펑션의 시각으로만 바라본다.
2) 필요하다고 생각하는 일을 능동적으로 만들기 보다는 주어진 일만 수동적으로 하게 된다.
3) 제품에 대한 오너십이 부족해진다.
물론 소수의 개발 인력으로 최대의 효율을 뽑는다는 극 장점이 있기에 위 단점들에도 불구하고 초기 스타트업들이 많이 취하는 조직 구조이다. 허나 개발 인력이 점차 늘어나게 되면 필연적으로 Function 팀의 구조를 탈피하여 새로운 구조를 찾게 되는데, 그것이 Mission 기반의 조직 구조이다. 이는 클라이언트, 서버, 프로덕트 디자이너들이 전속으로 특정 제품을 담당하게 되는 구조로서, 보다 '팀'이라는 느낌으로 특정 제품의 제작과 고도화를 위해 몰입하는 구조이다.
출처 : 버즈빌 미션 팀 구조 소개 자료이러한 미션 팀 구조는 아래와 같은 특징을 가진다.
1) 특정 목표를 달성할 수 있는 여러 function 직무자들이 모여 동일한 목표를 향해 함께 달린다.
2) 목표 달성을 위해 필요하다고 생각되는 일들을 능동적으로 만들어간다.
위 2가지 장점에서 파생되는 추가적인 매력들이 있는데, 그것은 아래와 같다.
1) 개발자들이 특정 분야의 전문가(Specialist)로 거듭나면서 관련 개발 역량 자체가 고도화된다.
2) 정해진 개발자들과의 합이 맞춰짐에 따라 협업의 유기성이 좋아진다
물론 과정 상에서 치명적인 단점도 노출되었다. 미션 팀을 편성하고 인력을 배치하는 단계에서 오판이 발생하면 특정 팀은 극도로 부족한 리소스 하에서 바쁘게 업무를 진행하는 반면 특정 팀은 넉넉한 리소스 하에서 널널하게 일하게 될 수 있다. 또한 팀 편성이 MECE (Mutually Exclusive Collectively Exhaustive) 하지 않는다면 동일한 업무를 서로 다른 팀에서 중복으로 진행하거나, 역할이 모호한 영역에 대해 그 누구도 담당하지 않게 되는 현상이 벌어질 수 있다.
MECE : 겹치지 않으면서 빠짐없이 나눈 것이를 보완하기 위해 분기별 플래닝시 서로 다른 미션팀끼리 각 팀의 플랜을 공유하며 싱크를 맞추기 시작했고, 분기 중에도 주기적으로 미팅을 진행하며 상호 주지해야 하거나 의견을 주고 받아야 하는 부분에 대해 챙겨 소통하기 시작했다. 미션 팀 체제 도입과 더불어 점차 '커뮤니케이션'이 갖는 중요도가 매우 커지게 되었다.
이렇듯 나는 난생 처음 개발자들과 일하게 되면서 동시에 개발자 조직의 변화를 함께 겪게 된다. 파일럿으로 3개의 미션팀을 창설했던 2018년 하반기, 이는 곧 개발 인력이 추가 채용과 함께 2019년 12개의 미션팀으로 확장되고, 2020년 15개 이상으로 확장된다. 나 또한 주로 협업을 하는, 즉 주로 나와 같은 목표를 공유하는 팀이 별도로 꾸려지게 되었고 전속 개발자들과 그 때부터 지금까지 약 2년 가까운 시간을 함께 하고 있다. (정확히는 나의 직무에 유관한 미션팀을 창설해달라는 장문의 메일을 여러 근거 기반으로 작성하였고, 그것이 감사하게도 반영이 되어 창설된 것이었지만...) 돌아보면 미션팀 체제가 출범한 이래로 분기 플래닝 (OKR) 달성률이 매우 높아졌고, 보다 중장기적인 프로젝트 수행까지도 가능해졌다. 함께하는 개발자 동료들과의 합도 확실히 좋아지면서 업무 진행 과정에서의 실무 만족도도 높아졌다.
앞서 언급한 미션 팀 구조의 치명적인 단점들이 노출되었으나, 나는 여러 팀들 사이의 '가교 역할'을 자처하고 미션 팀 방방곡곡을 누비며 최소한 나의 업무에 대해서만큼은 유관 팀들이 모두 싱크가 맞춰져 있도록 노력하였다. 초기에는 온종일 '미팅', 메일링, 메세징만 하다가 끝나는 하루를 돌아보며 '오늘 하루 뭘 한거지?' 라는 현타를 느낄 때도 있었다만, 그러한 가교 역할 덕에 원하는 결과물을 더 이른 시간 내에 도출할 수 있게 된다는 것을 깨달은 후에는 도리어 미팅의 유의미함에 보람을 느끼곤 한다. 나아가 점차 스스로가 커뮤니케이션 역량에 대해 발군의 재능을 가지고 있다는 사실을 깨닫게 되면서부터는, 마치 날개 돋힌듯 소통의 나래를 펼치며 맡은 바 역할을 fully 수행해내게 된다. 개발 조직의 변화와 함께 급히 요구되던 역량이 때마침 나에게 잠재되어 있었다는 것은 이제와 돌아보니 천운이었다.
B사에서 수많은 실무적 역량을 쌓아갔지만,
가장 큰 성장은 단연 개발자와의 협업, 개발 조직과의 협업을 통한 커뮤니케이션 역량이었다.