아마존은 왜 싱글 스레드 리더십을 만들게 되었을까?

순서 파괴 - 콜린 브라이어

저번 시간에 블리츠 스케일링을 통해, 조직의 성장 단계에 따라 발생하는 문제들과 경영 관점 변화를 들여다봤는데, 좋은 책이지만 '상호 의존성으로 인한 속도 저하'라는 문제에 대해서는 다루지 않고 있었다.

'순서 파괴'라는 아마존 전 임원 콜린 브라이어의 책을 보다가 아마존이 상호 의존성 문제를 풀어낸 방법을 자세히 적고 있어서 알아보려 한다. '싱글 스레드'라는 방법론이다(책에서 그 외에 6페이저나 리더십 원칙 등 여러 경영 기법을 다루고 있지만 이미 대중에 흔한 내용이므로 굳이 포함하지 않는다)

성장의 발목을 잡는 '의존성'이라는 도전 과제

스타트업에서 일하다보면 100명을 기준으로, 주도적이고 기민하던 조직이 눈에 띄게 느려지는 것을 경험할 수 있다. 여러가지 이유가 있겠지만, 의존성의 문제가 꽤 크다. 코드도 업무도 중첩되기 시작하면서 예전에는 독자적으로 넣던 기능 개발에 이제는 '조율'이란 의사소통이 필요해지기 때문이다.

특히 부족 단계 (참고 블리츠 스케일링) 전후로 급격한 채용이 이루어지는 경우가 많은데, 직원 규모가 선형적으로 증가할때 의사소통의 수는 대부분 기하급수적으로 증가하게 되고 점점 조직의 속도는 지연된다. 이런 의존성 문제는 단순히 속도 차원의 문제가 아니다. 다른 팀에 빈번히 의존하게 되면 영향력을 발휘할 수 없는 직원들은 의욕을 잃어가고, 조직적인 저항으로 인해 혁신 아이디어를 추진할 의지도 사라지게 된다.

세계 최고의 회사 중 하나인 아마존 역시의존성 문제를 겪으며 '폭발적인 성장은 혁신의 속도를 늦춘다'라는 경향을 인정하게 되었다. 아마존의 기술, 조직 의존성 문제에 관한 사례를 하나씩 소개한다.

첫번째는 저자인 콜린이 일주일만에 아마존의 기술 의존성 문제를 절감한 밀착 결합(Tightly Coupled) 관련 사례다.

콜린의 첫번째 임무는 아마존 어소시에이츠 프로그램 (업체들이 아마존 상품 링크를 올리고, 누군가 클릭해서 구매한만큼 보상을 얻는 기능) 관련 업무였다. 당시 아마존은 제휴업체가 링크한 아이템을 구매할때만 보상을 주었는데, 콜린은 방문자가 링크를 클릭해서 들어왔다면 어떤 아이템을 구매해도 보상이 제휴업체에 돌아가도록 변경하고자 했다. 그러나 실상은 녹록치 않았다. 먼저 상품 페이지 - 장바구니 - 주문 - 반품을 담당하는 각 팀은 공유 코드로 기술 의존적이었다. 콜린은 팀마다 모든 세부 단계를 함께 조율해야 했으며, 반대로 각 팀은 다른 팀에서 변경하는 코드가 자신들에게 영향을 끼치지 않도록 촉각을 곤두세워야 했다. 게다가 아마존 DB를 관리하는 'DB 카발'이라는 팀에 코드에 대한 승인을 얻어야했는데, 이들의 심사를 기다리는 요청 건들이 쌓여있어 미칠듯이 지연되었다.   

두번째는 조직도로 인해 필연적으로 생겨나는 조직 의존성 문제에 관한 서술이다

아마존에서도 제품 카테고리, 기능별로 팀을 꾸리자 조직도가 갑자기 커졌다. 회사가 작을 때는 주위를 둘러보며 도움을 요청해도 갈등을 해결할 수 있었는데, 조직 규모가 커지면 누구에게 말해야하는지, 그의 상사는 누구인지 등을 파악하느라 시간이 오래 걸리고 번거로워진다. 설령 담당자를 찾아낸다해도 그 역시 관리자에게 보고를 해야하고, 그 관리자는 다시 본인의 상사나 동료에게 물을 것이다. 또 연관된 직원들에게도 자신의 프로젝트가 있어 다른 팀의 요청에 신경 쓸 여력이 없기도 하다. 요청을 받은 팀에서는 이미 설정한 우선순위와 요청 건의 균형을 잡아야하고, 무엇을 지원해야할지 다시 판단하는 작업도 필요해진다.

'더 나은 조율'은 해결책이 아니다

보통 이런 의존성 문제에 대한 해결책으로 '조율'과 '의사소통'을 늘리거나 개선하는 방향으로 속도를 높이려한다. 하지만 아마존은 이런 방법이 '잘못된 문제'를 해결하려는 노력이라고 판단했다. 그래서 아마존은 팀 간의 의사소통 개선이 아닌, 팀 간의 의사소통 제거를 큰 해결 방향으로 선택했다. 제프 베조스는 의사소통을 일종의 결함으로 간주했고, 먼저 모든 개발팀이 기본적으로 시스템과 서비스의 API를 구축하고 이를 명확히 문서화해야한다고 제안했다. 그리고 상호 의존성을 제거하려는 해결책들을 아래 순서대로 실행하기 시작했다.

아마존의 첫 번째 해결책 : NPI

아마존은 항상 실행하거나 지원가능한 수준보다 더 많은 아이디어가 있었다. 하지만, 실질적으로는 매 분기 한 건의 대형 프로젝트만 수행할 수 있었다. 그래서 NPI(New Project Initiaive) 프로세스를 만들게 되었다. '주문처리센터를 위한 비용 절감 프로젝트'와 '의류 카테고리 판매를 신장시킬 수 있는 기능 추가' 중 어떤 것을 진행해야할지를 판단하기 위한 프로세스였다.

1) 각 팀은 먼저 수행 가치가 있는 프로젝트 중 '외부 자원'이 필요한 프로젝트의 목록을 만들어 제출했다. 이 때 1p 수준의 요약, 영향 팀, 소비자 수용 모델, 시급성 설득 자료 등의 요청 자료가 작성되어야 했기 때문에 제안 자체가 자원을 많이 소모하는 일이 되었다.

2) 이렇게 제출한 NPI 요청은 심사 그룹에서 검토하였고, 유망한 아이디어들은 다시 한 번 기술/재무적 심사를 받기 위해 다음 라운드로 넘어갔다. 보통 이 리스트를 검토하는데만 30-40명의 리더들이 투입되었다.

3) 프로젝트의 효과성에 대해서는 항상 큰 오차 범위가 있었는데, 이를 줄이기 위해 제안 자료와 실행 결과를 비교하는 피드백 루프를 강화했고, 팀의 예측은 실제 결과와 점점 가까워지기도 했다.

대부분의 직원에게 이 NPI 프로세스는 환영받지 못했다. '일은 일대로 하고 남는 건 하나도 없다'라는 뜻으로 'NPI 되다'라는 말이 아마존 직원들 사이에서 많이 쓰였다. 결국 아마존은 추가적인 해결책을 고민할 수 밖에 없었다.

아마존의 두 번째 해결책 : 투 피자 팀

제프는 개발자들을 피치 못할 때만 다른 팀과 느슨하게 연결되는 소규모 팀으로 재조직하는 것을 제안했다. 말은 쉽지만 실천하기는 어렵다. 아마존은 전 직원 아이디어 취합을 통해 꽤 유명한 '투 피자 팀' 모델을 만들어 적은 수의 개발팀에 우선 적용하기 시작했다. 투 피자 팀 모델은 아래와 같다.

1) 열 명을 넘지 않는다.

2) 어떤 팀이든 다른 팀의 API를 참조하여 독립적으로 업무할 수 있어야한다.

3) 적합도 함수(잘 정의된 목적에 따른 지표들)를 가중 평균하여 평가 받으며, 실시간 대시보드로 성과가 모니터링 된다.

얼마나 많은 기능을 추가 했나 X 50%

기능을 통해 얼마나 많은 아이템을 판매했나 X 30%

기능을 통해 얼마나 많은 페이지뷰를 올렸나 X 20%

4) 경영자처럼 행동해야 하고, 비즈니스 판단력을 갖춘 리더가 이끌어야한다.

5) 비용을 쓴 만큼 돈을 벌어야한다.

6) 해당 팀의 구성과 목적을 S-팀(아마존의 최상위 전략팀)에 승인 받아야한다.

투 피자 팀은 어느 정도의 의존성을 지닌 채 출범했고, 이를 제거하는 일에 대해서 평가를 떠나 우선 감당해야했다. 혁신을 통해 새로운 기능을 추가하는 것은 그 다음에 할 일이었다. 예를 들어 피킹팀(picking team)은 9개월간 재고 수취와 포장 및 배송 영역에서 의존성을 정리하는 일에 매달렸고, 동시에 주요 이벤트들을 실시간으로 추적할 수 있는 지표 시스템을 구축했다. 어떤 팀은 의존성 해결을 뒤로 미룬채 먼저 화려한 신규 기능을 도입하는데 초점을 맞췄지만, 이는 결과적으로 팀의 가속력을 떨어트리는 잘못된 결정으로 판단되었다.

투 피자 팀의 도입에도 불구하고, 전사 차원에서 여러 기능이 연결되는 프로젝트는 팀 간 협업을 피할 도리가 없었다. 특히 주문, 지불과 관련된 팀은 그들의 목표 선언문에는 없는, 회사의 거의 모든 신규 계획에 참여하게 되었다. 아래는 투 피자 팀에 관한 아마존의 회고 내용이다.

투 피자 팀은 제품 개발 영역에서 효과적이다. 유통, 법무, HR 등에는 큰 의미가 없었는데, 이는 그들은 딱히 복잡한 의존성에 시달리지 않았기 때문이다.

적합도 함수 선정에 너무 시간을 많이 쏟게 되었다. 때로는 의미없는 숫자들에 '논쟁을 위한 논쟁'을 하기도 하였다. 결국 적합도 함수의 사용을 중단하는 것으로 결정했다.

팀을 이끌 훌륭한 리더를 충분히 찾는 일은 무척 어려웠다. 이를 보완하기 위해 매트릭스 조직 (기능 관련 관리자와 목적 관련 관리자에 동시 보고하는 조직)을 도입하였고, 이는 일반적인 구조로 자리잡았다.

규모가 문제가 아니었다. 팀의 성공 여부는 리더의 스킬과 권한에 달려있었다.

결국 아마존은 투 피자 팀에서 인력 규모 제한을 제거한 조직의 이름을 구상하게 되었고, '싱글 스레드 팀'이라는 이름을 붙였다. 싱글 스레드란 한 번에 한 가지 일만 처리한다는 뜻이다.

아마존의 마지막 해결책 : '싱글 스레드 리더'와 '분리 가능한 싱글 스레드 팀'

아마존은 결국 투 피자 팀을 조정하고 개선하여 훨씬 유용한 것을 손에 쥐었다 (여전히 대중에는 싱글 스레드보다 '투 피자 팀'에 대한 내용이 유명한 것 같지만) 싱글 스레드 팀은 어떤 것이 투 피자 팀에 비해 더 나아졌을까?

무언가를 만드는 데 실패하기 위한 최고의 방법은, 그 일을 누군가에게 파트타임 업무로 맡기는 것이다 - 데이브 림프 (아마존 디바이스 담당 수석 부사장)

싱글 스레드 리더의 가장 중요한 개념은 오로지 그 프로젝트에만 매달린 관리자를 세우는 것이다. 지금은 당연한 아마존의 풀필먼트 사업은 모두가 흥미로운 아이디어라고 생각했지만 1년이 넘게 제대로 진행되지 못했다. 아마존 소비자 사업부의 CEO인 제프 윌케는 당시 부사장이던 톰 테일러에게 모든 책임을 벗어던지고 풀필먼트에만 집중하도록 지시했고, 1년 뒤 풀필먼트 사업은 성공적으로 고객의 구매경험을 향상시켰다. 톰 테일러 전에 담당하던 리더'들'도 능력은 충분했지만, 다른 책임 업무가 산더미 같았기에 충분한 세부 내용을 관리할 여력이 없었다. 그리고 제프 윌케가 톰이 이 프로젝트 하나에만 집중하도록 일을 덜어주지 않았다면 론칭 후에도 그 진행과 개선 속도는 현저히 느렸을 것이다.

또 하나의 결정적인 요소는 그 일 외에 아무 일도 하지 않는 싱글 스레드 팀이다. 단지 싱글 스레드 리더를 지정하는 것만으로 충분치 않다. 자신이 맡은 기능에 명확한 오너십을 가지고, 다른 팀에 최소한의 영향을 받는 팀을 구성해야한다. 자율성이 충분한지 판단하는 좋은 경험법칙은 '단독 행동 전개' 가능 여부를 살피는 것이다. 다른 팀에 승인을 받지 않아도 우리 팀이 단독으로 변화를 추진할 수 있냐는 말이다. 싱글 스레드 팀의 크기 자체는 상관없지만, 이와 같은 단독 행동 전개 가능 여부를 물었을때 '아니요'라면, 자율적으로 반복할 수 있는 더 작은 기능을 찾아 맡겨야한다. 싱글 스레드 리더는 제품의 문제를 확인하고, 어떤 팀이 얼마나 필요한지, 책임은 어떻게 배분되는지 평가하고 결정할 권한을 얻는다.

결국 싱글 스레드의 핵심은 '명확한 오너십과 책임 범위'로 나누어 팀을 구성해야 쉽게 목표를 달성할 수 있다는 것이다. 이 내용은 사실 인스파이어드에서 말하는 좋은 제품팀의 구성 요소에도 등장한다. 명확히 팀의 오너십과 책임이 정립되었을때, 팀은 회사의 전략에 적절하게 초점을 맞추며 몰입할 수 있으며 더 빠르고 정교해질 것이다.

싱글 스레드라는 방법론을 떠나 아마존에게 배워야할 것

'비전을 고집하되, 세부 내용에는 유연성을 가져라'라는 아마존의 유명한 원칙이 있다. 책을 읽으며 싱글 스레드에 관한 내용에 공감하기도 했지만, 그 전에 시도했던 NPI, 투 피자 팀이 결과적으로 사라진 시도라는 것과 그 내용을 충분히 피드백해서 싱글 스레드라는 개념을 만들어낸 것도 아마존 답다는 생각이 들었다. (우리 주변에는 여전히 투 피자 팀이 최선의 방법이라고 알고 있는 회사도 많지 않은가?)

싱글 스레드 역시 몇 년 후에는 사라지고 더 좋은 방법론으로 대체될지 모른다. 어쨌든 풀어야할 문제는 '각 팀이 상호 의존성을 줄이고 더 주도적으로 일하도록' 돕는 것이고, 아마존이 이 문제를 풀어가는 과정에서 선택한 큰 방향과 개선은 비슷한 고민을 겪고 있는 조직들에 좋은 힌트가 되지 않을까 생각한다.