Amazon의 2-피자 팀을 통해 혁신을 지원하고 속도를 개선

Amazon은 닷컴 시대에 창업한 여타 기업들과 마찬가지로 지속적으로 민첩하고 빠르게 고객에게 가치를 제공할 수 있도록 조직되었습니다. Jeff Bezos는 1997년 주주들에게 보내는 첫 편지에서 단기적인 기업 이익을 희생하더라도 고객에게 집착하고 고객을 위해 지속적이고 장기적인 가치를 제공하는 것이 중요하다고 역설했습니다. 고객에 대한 이러한 끊임없는 집착은 고객의 가장 어려운 문제를 해결하고 그들을 대신하여 제품을 발명하는 데 열정을 다하는 역량 있는 빌더를 고용하고 조직 구조를 유지하는 것을 전제로 합니다.

Jeff는 “채용 기준을 높이는 것은 Amazon.com 성공의 가장 중요한 요소였으며 앞으로도 그럴 것입니다”라고 썼습니다.

전자 상거래 비즈니스에 집중했으며 팀이 빠르게 혁신하기 위해 사용했던 기술 아키텍처가 지금보다 중앙 집중화되고 밀결합됐던 초기에는 민첩하게 움직이기 더 쉬웠습니다. 하지만 시간이 지나면서 Amazon이 고객이 원하는 것을 제공하기 위해 비즈니스 수를 늘리고 혁신적인 신제품을 내놓으면서 빠른 속도와 민첩성을 유지하기 어려워졌습니다. Jeff가 2015년 주주들에게 보내는 편지에서 말했듯 ‘발명 기계’로 남고자 하는 열망에 타격을 받기 시작했습니다. 여기서 발명 기계란 ‘대규모 조직에서 갖출 수 있는 탁월한 고객 서비스 역량과 기업가 정신이 살아 있는 스타트업에서 흔히 볼 수 있는 속도, 민첩성, 위험 수용 자세를 결합’한 회사를 지칭합니다. 밀결합된 아키텍처와 조직은 우리가 원하거나 필요한 만큼 빠르게 변화에 대응하는 데 전혀 도움이 되지 않았습니다.

갈수록 느리고 비효율적이 되어가는 상황을 타개하기 위해 기술 아키텍처를 마이크로서비스 아키텍처로 근본적으로 바꾸었습니다. 모놀리식 아키텍처를 여러 단일 독립 실행형 서비스로 분리해 방대한 네트워크를 구성했습니다. 이를 통해 새로운 혁신 기술과 제품을 신속하게 출시하고 끊임없이 변화하는 고객 요구에 따라 기존 서비스를 빠르게 반복 개발하며 고객 대신 새로운 아이디어를 지속적으로 실험하여 새로운 것을 발명할 수 있었습니다.

하지만 빌더들이 혁신을 주도하는 데 사용한 기술을 단순히 정비하는 것만으로는 충분하지 않았습니다. 그에 더해 팀 구조를 재편하여 팀이 고객과 고객의 요구 사항을 최대한 파악하고 고객을 대신하여 혁신적인 제품과 서비스를 신속하게 출시하며 마이크로서비스 아키텍처로 얻을 수 있는 민첩성과 속도를 최대한 활용할 수 있도록 해야 했습니다. 이 조직 구조는 Amazon의 ‘2-피자 팀’으로 불리게 되었습니다.

Amazon의 2-피자 팀 개념은 간단합니다. 모두 먹는 데 피자 두 판 이상이 필요할 정도로 큰 팀은 없어야 한다는 것입니다. 이야기가 길어질 수 있으니 ‘피자에 파인애플을 올려야 하는가?’ 같은 토핑 수나 재료 논쟁은 제쳐두겠습니다. 어쨌든 10명 미만의 팀이 이상적입니다. 소규모 팀일수록 의사소통 라인이 최소화되고 요식 체계와 의사결정으로 인한 업무 부담이 줄어듭니다. 따라서 2-피자 팀은 고객에게 집중하고 고객을 대신하여 지속적으로 실험하고 혁신하는 데 더 많은 시간을 할애할 수 있습니다. 이는 Amazon에서 성과가 좋은 팀들이 최우선으로 하는 사항입니다.

팀 규모가 작으면 책임 의식과 자율권도 강화됩니다. 이는 대규모 그룹에서 개인의 생산성이 감소하는 경향을 나타내는 링겔만 효과를 완화할 수 있습니다. 팀원이 증가하면 업무를 진행할 때 다른 사람에게 더 의존하게 되어 개개인이 덜 노력하게 됩니다. 팀 규모가 커질수록 개인의 기여도는 낮아집니다. 반대로 팀 규모가 작아질수록 개개인이 더 노력하게 됩니다.

팀 규모가 작으면 최고의 인재를 유치하고 유지하기 위해 애쓰는 오늘날의 조직에서 주요 관심사인 직원 만족도도 높아집니다. Hackman과 Vidmar의 주목할 만한 연구에 따르면, 팀 규모가 커질수록 개인의 만족도는 낮아집니다. 규모가 큰 팀에서는 개인의 기여도가 잘 드러나지 않고 특정 영역에 대한 개인의 책임 의식이 흐릿해지는 경우가 많습니다.

이는 Gallup의 ‘The State of the American Workplace’라는 연구에서도 입증되었습니다. 이 연구 결과에 따르면 직원이 10명 미만인 조직은 업무 몰입도가 42% 이상인 반면 대규모 조직의 평균 업무 몰입도는 30% 미만이었습니다.

하지만 Amazon의 2-피자 팀은 단순히 규모에 국한된 개념이 아닙니다. 2-피자 팀 구조가 빠르고 지속적으로 혁신할 수 있는 핵심 요소는 단일 스레드에 집중하여 역량을 강화하는 것입니다.

► 팟캐스트 듣기: C-Suite Strategies for Leading Significant Change

2-피자 팀은 규모를 유지하는 것뿐만 아니라 팀 차원에서 소유권과 독립성을 배양하는 데에도 중점을 둡니다.

Amazon과 AWS에서는 2-피자 팀이 특정 제품 또는 서비스에 대한 소유권을 전적으로 가집니다. 2-피자 팀은 복잡한 시스템을 유지 관리하거나 여러 서비스, 사업부 또는 고객 부문에 걸친 문제를 해결하는 것이 아니라, 하나의 서비스 또는 제품과 이를 사용하는 고객에만 집중합니다. 이러한 단일 스레드 방식의 집중 구조는 효율성과 확장성을 높입니다. 2-피자 팀의 로드맵은 절충과 우선순위 지정을 비롯하여 팀에서 소유한 서비스와 그 서비스를 사용하는 고객 부문만을 혁신하는 데 전적으로 초점을 맞추고 있습니다.

2-피자 구조는 팀의 책임감도 높입니다. 2-피자 팀은 자신들이 출시한 제품과 서비스의 운영을 다른 팀에게 넘기지 않습니다. 전적인 소유권은 전체 고객 경험과 2-피자 팀의 제품 또는 서비스의 전체 수명 주기에 걸쳐 적용됩니다.

따라서 2-피자 팀은 명확한 원칙과 확고한 사명을 가지고 서비스의 모든 부분을 잘 파악해야 합니다. 고객과 긴밀한 관계를 유지하고 올바른 추적 메커니즘, 지표, KPI를 만들어 서비스가 고객에게 지속적으로 가치를 제공하도록 해야 합니다.

이를 위해서는 2-피자 팀이 엔지니어링, 테스트, 제품, 프로그램 관리, 운영 등에 필요한 리소스를 팀 내에 확보하여 서비스를 처음부터 끝까지 소유하고 운영할 수 있는 역량을 갖추어야 합니다.

제품 또는 서비스의 수요가 증가하면 팀원으로 늘리는 것이 아니라 팀원을 별개의 2-피자 팀으로 나누어 서비스의 단일 스레드 하위 영역을 운영하도록 방안을 모색합니다. 이와 같은 분열로 민첩성, 자율성, 단일 스레드 소유권이 유지되는 더 평면적인 조직 구조를 유지할 수 있습니다.

2-피자 팀에게 규모 유지만 중요한 것이 아닙니다. 아이디어 구상부터 실행까지, 지속적인 운영 개선부터 지속적으로 반복하고 혁신하기까지 팀 차원의 소유권과 독립성을 높이는 것도 매우 중요합니다. 이를 통해 팀은 실행 속도를 높이고 조기에 자주 실험하며 학습한 내용을 빠르게 적용하여 고객에게 지속적으로 가치를 제공할 수 있습니다. 더 빠른 혁신과 실험은 실패로 발생하는 비용을 낮출 수 있습니다. 실패한 이유를 학습하여 개발 과정 후반에 직면할 수 있는 위험을 큰 피해 없이 막을 수 있기 때문입니다.

2-피자 두 팀 구조가 Amazon과 AWS에서는 효과가 있었지만, 모든 조직 또는 모든 사업부에 적합하지는 않을 수 있다는 것을 잘 알고 있습니다. 2-피자 팀은 절대 완벽하지 않으며 제약이 없는 것도 아닙니다. 일례로, 고객의 요구를 충족하기 위해 빠르게 운영되는 자율적인 단일 스레드 팀이 너무 많아 중복되고 사일로화된 형태로 개발이 진행될 위험이 있습니다. 각자 소유권을 가진 영역에서 혁신을 주도하는 팀의 역량을 저해하지 않으면서, 순전히 반복적인 작업을 언제, 어떻게 결합할지 결정하려면 적절한 거버넌스 구조가 필요합니다.

실험이 빠르게 진행됨에 따라 팀 간의 협업을 통해 성공을 확대하고 리소스를 합리화해야 할 필요도 있습니다. 더 중요한 것은 실패에서 얻은 교훈을 확인하여 공유하고 이러한 교훈을 향후 실험에 더 효과적으로 적용하여 반복 실행의 방향과 향후 투자 결정을 세부적으로 조정할 수 있는 능력입니다.

Amazon과 AWS 조직에서 거버넌스와 감독을 장려하는 동시에 팀이 빠르고 독립적이며 자율적으로 운영되도록 뒷받침하는 역할을 하는 단일 스레드 리더라는 개념이 있습니다.

고객을 대신하여 독립적으로 혁신을 실현할 수 있는 팀의 역량을 유지하기 위해 적절한 수준의 감독 체계를 확립하려면 단일 스레드 리더의 역할이 매우 중요합니다.

오늘날의 경영진은 혁신과 디지털 트랜스포메이션을 신속하게 실현했을 때 따르는 엄청난 이점을 인식하고 있습니다. 새로운 제품과 서비스를 신속하게 시장에 선보이는 능력은 고객에게 지속적인 가치를 제공하는 데 중요할 뿐만 아니라 기업의 차별화된 경쟁력이 될 수도 있습니다. 하지만 비즈니스의 규모와 범위가 확대되면 경영진은 팀이 운영 속도를 빠르게 유지할 수 있도록 적절한 구조와 리더십을 구축해야 합니다.

팀의 거버넌스와 관리는 팀이 혁신적인 실험을 진행하기 전에 승인 또는 조율 단계를 늘려 속도를 저해하는 ‘톨게이트’보다는 팀이 빠르게 실행하고 제대로 의사결정을 내릴 수 있는 메커니즘인 ‘가드레일’을 제공해야 합니다.

Amazon과 AWS에서 단일 스레드 리더의 역할은 팀이 고객을 대신하여 독립적으로 혁신할 수 있는 권한을 유지하는 동시에 적절한 수준으로 점검하고 향후 나아갈 방향의 비전을 갖고 일관된 메커니즘을 구축할 수 있도록 적절한 수준의 감독 체계를 확립하는 데 있어 매우 중요합니다. 단일 스레드 리더는 전략적 비전 제시를 돕고 실행 시에는 방해가 되지 않도록 한 발 물러섭니다. 팀 리더는 모든 의사결정에서 통과해야 할 장애물이 되는 것이 아니라 장애물이 없도록 도와야 합니다. 매일 고객 집착의 원칙을 실천하는 작고 민첩하며 자율적인 팀은 서비스와 고객 부문에서 가장 중요한 주제 전문가들입니다.

단일 스레드 리더는 비즈니스에서 최선의 결정을 내릴 수 있도록 팀의 자율성을 보장해야 합니다. 정확히 측정된 데이터와 최고 수준의 판단력을 갖추었다 해도 앞으로 나아갈 방향을 명확하게 파악할 수 없는 상황에서 단일 스레드 리더가 팀의 의사결정에 참여하면 팀이 방향을 정하는 데 도움이 되는 경우가 많습니다.

각 중요 시점에 단일 스레드 리더의 감독 업무를 지원하기 위해 Amazon에서 사용하는 메커니즘 중 하나가 바로 글쓰기입니다. 글쓰기는 고객이 직면한 문제를 개략적으로 설명하고 다음 단계를 안내하기 위해 팀에서 수집한 심층 분석 결과와 데이터에서 정보를 도출하며 고려할 수 있는 대체 경로와 각 경로에 내포된 위험성과 이점과 함께 팀이 권장하는 의사결정을 명확히 설명하는 데 도움이 됩니다.

글씨기에 시간을 쓰는 것은 속도 유지와 지속인 실행에 반하는 것처럼 보일 수 있지만, Amazon과 AWS에서는 글쓰기 덕분에 놀라운 이점을 얻을 수 있었습니다. 그중 하나는 이러한 문서가 경영진의 책상 위에 놓이기도 전에 이미 팀, 이해 관계자, 그리고 팀 서비스와 고객 부문 주제 전문가들이 격렬하게 논의하여 개선되는 경우가 많다는 것입니다. 이는 협업을 증진시키고 다양한 관점을 갖게 하며 가정을 입증하고 문서 내 아이디어와 권장 사항을 구체화하는 데 도움이 됩니다. 궁극적으로 이는 더 적절한 의사결정으로 이어지는 경우가 많습니다.

Amazon과 AWS에는 다양한 글쓰기가 있습니다. 역방향으로 작업 방식의 산물인 PR/FAQ(보도 자료/자주 묻는 질문의 약자) 문서가 있으며 그중 일부는 신제품 출시에 초점을 맞추고 있습니다. 팀이 비즈니스를 운용하면서 얻게 되는 주요 지표, 추세, 긴장 상태, 위험, 기회를 점검하고 거버넌스할 수 있는 운영 비즈니스 리뷰(주로 주간, 월간 및 분기별로 작성)도 있습니다.

새로운 서비스를 출시하기 전에 운영 준비 상태를 철저하게 검토하는 글쓰기도 있습니다. 이 글쓰기를 통해 서비스의 아키텍처, 릴리스 품질과 절차, 관련 인시던트와 이벤트 관리 절차의 여러 측면을 심층적으로 분석하여 체계적으로 정리하고 문서화할 수 있습니다. 오류 수정 문서 등 다른 글쓰기는 서비스가 고객에게 부정적인 영향을 미칠 때 사후 조치로 작성됩니다. 이들 문서는 서비스를 소유한 팀이 주도하여 작성합니다. 책임 소재를 밝히려는 것이 아니라, 해당 서비스를 소유한 단일 스레드 팀으로서 해당 서비스와 고객을 가장 가까이에서 접하고 가장 잘 알기 때문입니다.

이 오류 수정(COE) 문서를 통해 팀은 서비스 장애로 인한 영향과 발생 이유와 관련된 정량적 분석 결과와 데이터를 제공하면서 발생한 문제 상황을 자세히 설명합니다. 영향을 미친 모든 요인을 포함하여 근본 원인을 파악하기 위해 다층적으로 분석하고 근본 원인을 해결한 방법뿐만 아니라 이러한 문제가 다시 발생하지 않도록 하기 위해 어떠한 조치를 지속적으로 취할 것인지도 개략적으로 설명합니다. 이와 더불어 점검과 지속적인 개선을 위한 새로운 메커니즘을 업데이트하거나 개발하는 경우도 많습니다. 그런 다음 이 문서는 검색 가능한 데이터베이스에 보관되어 중요 학습 내용을 부서 간에 공유할 수 있습니다.