실제 아마존 내부에서 깊게 일을 했던 분들이 아마존의 성장 과정을 정리하니 대단히 생생하게 전달되었다. 그 당시를 경험한 사람이 정리한 조직의 성장 과정은 '기밀 유출'에 가까울 정도로 상세하게 도움이 되었다.
요즘 제품팀의 성장과정을 정리중이다. 팀에서 이렇게 하고 있으니 그냥 따르는 것과 왜 이렇게 하게 되었는지를 과정을 다 보고나서 프로세를 따르는 것에는 구성원들의 몰입도 차이가 굉장히 크다.
아직 큰 형태가 되진 않았지만, 폭발적으로 성장하지 못하고 있을 때에도 어떤 노력들을 했고, 그 기간을 뚫기 위해 어떤 것들을 시도했는지 남겨서 팀의 노하우가 되었으면 좋겠다.
그런면에서 이번 <순서파괴> 책이 좋은 지침이 되었다. "팀의 성장 과정을 정리한다는 것은 이런 것이구나" 를 많이 느꼈다.
하이라이트
우리는 지금껏 일하며 많은 용병을 접했다. 벼락부자가 되기 위해 합류한 용병들은 조직의 최고 관심사를 염두에 두지 않고, 힘든 시기에도 회사와 함께 가겠다는 의지를 다지지 않았다. 제프식 정의에 따르면 '선교사'는 아마존의 미션을 믿을 뿐만 아니라 아마존의 리더십 원칙을 내재화하는 사람이다. 그들은 조직과 하나가 된다. 우리는 실리콘밸리의 평균 근속 기간인 18~24개월을 넘어, 5년 이상을 동고동락하며 성장할 수 있는 인재를 원했다.
'선교사' 와 같은 팀원을 채용해야하는데는 완전히 공감한다. '선교사' 같은 성향을 가지면서 용병과 같은 전문성을 가진 팀원을 채용할 수 있다면 가장 좋겠지만, 보통 그런 경우는 잘 없다. 완전히 성격적으로 문제가 있는 경우이거나 전문성에서 문제가 되는 경우는 보통 서류나 면접에서 배제되니 크게 고려대상이 되진 않는다.
선교사의 성향은 아니지만, 용병으로서 뛰어난 전문성을 가진 팀원
선교사의 성향을 가지고 있지만, 용병처럼 뛰어난 전문성은 당장엔 없는 팀원
이 둘 사이에선 어떻게 해야할까? 개인적으로는 용병 팀원을 채용하는 것을 항상 경계하는데, 그럼에도 불구하고 우리팀의 당장의 문제를 해결할 수 있는 용병 팀원을 만날때의 유혹은 정말 달콤하다.
그게 아니더라도, 채용은 항상 "이번 지원자 보다 더 나은 지원자가 있을 것이다" 라는 확신을 하기 어려운 분야다보니 많은 지원자를 거쳐 겨우 나온 Good 지원자 (Excellent는 아닌)를 불합격 시키는 것도 힘든 일이다. 그래도 불합격 시켜야하지만 말이다.
중요한 발표 자리일수록 파워포인트 슬라이드를 문장과 숫자, 데이터 그래프와 이미지를 함께 보여주는 종이 핸드아웃으로 대체하는 방법이 유용하다. 상세한 내용이 적힌 핸드아웃은 그걸 읽는 사람에게 증거의 전후 맥락을 살피고 비교하게 하며 재구성할 수 있게 이끈다. 반면 데이터가 빈약하고 금방 잊히는 화면은 청중을 무지하고 수동적으로 만들며 발표자의 신뢰성을 깎아내리는 경향이 있다.
공유용 문서를 회의 시작후 20분간 읽도록 하고, 읽은뒤 40분간 논의하는 과정은 지금 당장 회사에서도 써볼 수 있을것 같다.
지금도 팀 단위의 미팅은 PPT로 공유하는 것은 없고, Confluence 기반으로 내용을 정리한 것을 보고 논의를 시작한다. 다만, 내러티브 양식을 정해둔게 없는데 그걸 좀 더 고도화 해볼 수 있을것 같다.
전사에 공유하는건 PPT를 계속 써야할 것 같은데, 그 외 팀별 공유나 킥오프 등에서는 내러티브를 훨씬 더 적극적으로 써야할 것 같다.
보통은 조직 의존성 문제의 처방으로 '조율'과 '의사결정'을 내놓는다. 그리고 그 의존성이 계속 커질수록 더 많이 조율하고 의사 소통 방법을 개선하는 방향으로 진행 속도를 높이고자 한다. ... 그러다 아마존은 결국 '팀 간의 의사소통 개선'으로 의존성 문제를 해결할 수 없다는 사실을 깨달았다. 팀 간의 의사소통 자체를 없애야 했다. ... '팀 대 팀을 조율하려면 비용이 계속해서 증가한다'는 것이었다. 아마존에서 일하는 동안 우리는 제프가 이렇게 말하는 것을 자주 듣곤 했다. "아마존을 (개발자들이) 개발에 전념할 수 있는 곳으로 만들려면 의사소통을 제거해야 한다. 의사소통을 독려할 필요는 전혀 없다" 팀 간의 '효과적인 의사소통'을 '결함'으로 간주하니, 해결책은 기존과 매우 다르게 보이기 시작했다. 제프는 각 소프트웨어 팀이 모든 시스템과 서비스에 일련의 응용 프로그램 인터페이스 (API) 를 구축하고, 이를 명확하게 문서화해야 한다고 제안했다. 다시 말해, 제프의 생각은 이메일과 회의처럼 '사람'을 통하기보다는, 잘 정의된 API처럼 '기계'를 통한 '약한 결합'에 집중할 필요가 있다는 것이었다. 미리 조치를 잘 취해둔다면, 각 팀이 자율적으로 행동하고 신속하게 움직이는 것은 시간문제였다.
지금에야 팀별로 API로 소통하고, 프론트엔드와 백엔드 간 OpenAPI Spec을 기반으로 Code Generator 까지 활용하는 것이 당연시 되고 있다. 그렇지만 저 시절에, 그것도 CEO가 어떻게 저런 관점을 가지셨을까? 그게 대단히 신기하다.
'효과적인 의사소통'을 '결함'으로 본다는 것에 팀의 협업 방식에 대해 상기하게 해주었다. 물론 여전히 '효과적인 의사소통' 에 대해서는 중요하다고 보는 편인데, 이게 너무 중요하다고 여겨 모든 문제를 이걸로 해결하려고 했던 것은 아닐까? 하고 생각하게 되었다.
당연하게도 요즘 같이 AI와 각종 SaaS가 고도화된 환경에서는 문서화만 잘 해두어도 의사소통을 크게 들이지 않고 업무를 진행할 수 있다. 신규 입사자라 하더라도 말이다.
반면 개발에 관련된 API 기반의 환경은 결국 조직마다 코드 베이스를 모두 분리해야만 할 수도 있다. (조직의 규모가 어느정도냐에 따라 다르긴 하겠지만) 유연한 조직 구조를 가져가기 위해서는 코드 베이스를 도메인마다, 팀마다 계속해서 나누는건 100명 이하 조직에서는 상대적 단점이 더 부각된다. 팀 별로 맡는 서비스/도메인이 언제든지 변경될 수 있고, 다른 팀이 그 팀을 돕기 위해 코드에 손을 댈 수도 있다. 조직 변경이 있을수도 있고 말이다.
팀에서 적극적으로 의사소통 해야하는 부분과 의사소통이 곧 문제인 영역을 분리해서 생각해야하는 것을 다시 한번 강조하게 되었다.
적합도 함수에는 더 큰 문제가 있었다. 첫째, 팀은 가장 의미 있는 적합도 함수를 고안하느라 지나치게 많은 시간을 허비했다. 지표 A에 50퍼센트, 지표 B에 30퍼세트, 지표 C에 20퍼센트를 할당해야 할까? 아니면 지표 A에 45퍼센트, 지표 B에 40퍼센트, 지표 C에 15퍼센트를 배정해야할까? 이런 논쟁들을 벌이면 얼마나 쉽게 헤맬 수 있는지 상상할 수 있을 것이다. 토론은 점점 의미를 잃었고, 결국에는 '논재을 위한 논쟁'으로 변질되고 말았다. ... 상대적 가중치들은 시간의 흐름에 따라 비즈니스 조건이 바뀌면서 함께 변해갔기에 역사적으로 추세를 전혀 반영하지 못했다. 아마존은 결국 적합도 함수 대신 '근원적인 지표'를 각각 사용하는 쪽으로 되돌아갔다.
2001년 제프는 냅킨 위에 '아마존 플라이휠' 이라는 간단한 선순환 다이어그램을 그렸다. 아마존의 통제 가능한 인풋 지표가 어떻게 하나의 핵심 아웃풋 지표를 끌어올리는지를 보여주는 모델이다.
이 그림에서는 '성장'이 핵심 아웃풋 지표다. ... 사이클이기에 어느 인풋에서도 시작할 수 있다. 예를 들어 '고객 경험'을 위한 인풋 지표에는 '배송 속도'와 '제품 구색의 범위' '풍부한 제품 정보'와 '사용의 편리성' 등이 포함된다. '고객 경험' 을 개선하면 어떤 일이 발생할까?
더 나은 '고객 경험' 은 더 많은 '접속량'으로 이어진다.
더 많은 '접속량' 은 구매자를 찾는 더 많은 '판매자'를 유인한다.
더 많은 '판매자'는 더 넓은 '제품 구색'으로 이어진다
더 넓은 '제품 구색'은 고객 경험을 향상시키면서 사이클을 완성한다.
사이클은 다시 '성장'으로 이어지고, '성장'은 '더 낮은 비용 구조'를 가능하게 한다
'더 낮은 비용 구조'는 '더 낮은 가격'으로 연결되고, 이는 다시 '고객 경험'을 향상시키면서 플라이휠을 더 빠르게 회전시킨다.
... 이 단계는 쉽게 들리지만 생각보다 까다로울 수 있다. '제품 구색', 즉 판매를 위해 얼마나 많은 아이템을 제공하느냐에 초점을 맞춰 인풋 지표를 선택했다는 점이다. 우리가 맨 처음 제품 구색에 신경을 쓰며 선택했던 지표가 바로 '신규 상세 페이지의 개수' 였다. ... 엄청난 수의 상세 페이지가 생겨나면서 언뜻 제품 구색이 개선된 것처럼 보였다. 하지만 아웃풋 지표인 '판매'의 증가로는 이어지지 않았다. 분석해보니 각 유통 부서가 아이템 수를 늘리는 일에만 열을 올린 나머지 수요가 그다지 크지 않은 제품들까지 마구잡이로 사들였던 것이다. 이런 활동은 '재고 유지 비용' 이라는 또 다른 아웃풋 지표에 문제를 일으켰고, 이로 인해 수요가 낮은 아이템들이 주문처리센터의 '값비싼' 공간을 점유해버리는 일이 발생했다. 잘못된 인풋 지표를 선택했음을 깨달은 아마존은 소비자의 수요를 반영하는 방향으로 지표를 개선했다.
각 카테고리에서 상세 페이지의 조회 수를 계산할 때, '빠른 배송 & 재고 있음'의 비율이 95퍼센트는 되어야 한다는 기준을 세웠다.
우리 같은 온라인 클래스는 아마존과 같은 커머스처럼 재고 관리 의 리스크를 갖고 있지 않다. 상품(컨텐츠)이 많이 생성 된다고 해서 회사가 부담해야할 리스크가 거의 없다. (서버비나 인코딩 비용 정도?) 잭를 보관하는데 들어가는 비용도 거의 없지만, 판매하기 위해 필요한 재고 관리에 대한 리스크도 거의 없다. 재고 걱정 없이 얼마든지 무한대로 판매할 수가 있다.
만약 재고 보관에 대한 부담도, 재고가 없음으로 인해 판매가 불가능한 상황도, 빠른 배송도 전혀 필요하지 않는 상황이라면 아마존에서는 어떻게 '제품 구색'에 관한 인풋 지표를 세웠을까?
물론 잘 팔리는 컨텐츠에 대한 선행 지표들은 많다. 수강평 (리뷰) 나 강의 수강 당 발생하는 질문/답변 수 등등. 하지만 이들은 어디까지나 상품을 구매하고 난 뒤에 발생하는 지표이다. 그렇다면 구매 하기 전에 이미 이 상품은 좋은 상품임을 알 수 있는 더 확실한 지표들에 대해서 아마존이라면 어떤 것들을 기준으로 세웠을까? 내부에서 세우는 기준들은 있지만, 그 기준들에 대해 정리가 필요하다고 생각한 시점에 이 책을 보게 되어서 신기하다.
