피자 두 판 규모의 팀
기원
- 2002년 아마존.
From: 데브옵스 핸드북
2002년, 아마존은 모놀리식(monolithic) 코드베이스에서 벗어나기 위한 전환 계획의 일환으로, 팀 규모를 피자 두 판을 함께 먹을 수 있을 정도의 인원(보통 다섯~열 명)으로 작게 유지하는 '피자 두 판의 법칙'을 도입했다.
이처럼 팀의 규모를 제한하면 네 가지 효과를 얻을 수 있다.
- 작업 중인 시스템에 대한 팀의 분명하고 공유된 이해가 보장된다. 팀 규모가 커지면 무슨 일이 진행되고 있는지 팀원 모두가 파악하는 데 필요한 커뮤니케이션 양이 증가한다.
- 작업 중인 제품 및 서비스의 성장률을 제한한다. 팀 규모를 제한해 시스템을 발전시킬 수 있는 속도도 제한한다. 그리고 팀이 시스템을 지속적으로 이해할 수 있도록 보장한다.
- 권력을 분산시키고 자율성을 부여한다. 각각 피자 두 판 팀(2PT)은 자율적이다. 팀 리더는 경영진과 협력해 팀이 담당하는 핵심 비즈니스 메트릭을 결정한다. 이 메트릭은 팀의 실험에 대한 전반적인 평가 기준이 된다. 그 후, 팀은 해당 메트릭을 극대화하기 위해 자율적으로 행동할 수 있다.
- 2PT를 리딩하는 것, 즉 소규모의 팀을 이끄는 것을 통해 직원들은 장애가 심각한 결과를 초래하지 않는 환경에서 리더십에 대한 경험을 쌓을 수 있다. 아마존 전략의 핵심 요소는 2PT의 조직 구조와 SOA의 아키텍처 접근 방식 간의 연결이다. 1
From: 개발자에게 물어보세요
밀레니엄이 바뀔 무렵 아마존은 급성장하는 스타트업임에도 혁신 속도가 느려지기 시작했다. 아마존의 최고정보책임자(이자 현재 트윌리오의 이사회 임원인) 릭 달젤Rick Dalzell에 따르면, 코드베이스가 한 덩어리가 되어 얽혀 있었고 프로덕트 개발은 찾아보기, 검색, 실행, 장바구니처럼 몇 개의 큰 부문으로 나뉘어 있었다. 수많은 사람이 같은 코드에 손을 대고 있어서 속도는 갈수록 느려졌고 코드를 전달하기도 어려워졌다. 코드 외에도 모두의 업무가 서로 완전히 얽혀 너무 많은 결정권자가 모든 업무에 참견했다. 짐작했겠지만 아이디어를 실현하려고 고군분투하던 엔지니어와 프로덕트 매니저 들은 좌절했고, 특히 최고경영자 제프 베이조스가 낙담했다.
해마다 제프는 일주일간 온라인 접속을 끊고 사업에 대해 깊이 사색하는 시간을 보낸다. 이 '머리 식히기brain benders' 연례행사에서 그는 기본 원칙을 재고하고 생각을 종이에 끄적이는 시간을 가진 뒤, 보통 리더십 팀에 전달할 새로운 아이디어가 담긴 일련의 한 장짜리 문서들을 들고 돌아온다. 릭은 2001년에 제프가 느려진 혁신 속도를 고민하며 사색의 시간에 들어갔다고 회고한다.
그러고는 제프는 간단한 아이디어를 들고 돌아왔다. 모든 팀을 스타트업 규모로 조직하면, 그러니까 각 팀이 자신만의 로드맵과 코드를 가지고 신속하게 움직일 수 있다면, 아마존 초기에 그랬듯(제프가 기억하기로 피자 두 판이면 팀원 전체가 먹을 수 있던 때처럼) 다시 스타트업과 같이 행동할 수 있을 거라는 내용이었다. 하지만 함께 일하려면 서로 접속 가능한 API를 여러 개 만들어야 했다. 그렇게 하면 팀들 간의 관계가 기술적으로 공식화돼 독립적이게 움직일 수 있을 터였다. 이 한 장짜리 문서로 '피자 두판팀' 이 탄생했다. 릭은 리더들에게 돌아갔고 일주일도 안 돼서 제프의 초기 아이디어는 6장짜리 실행 가능한 계획으로 바뀌었다. 아마존은 계획을 신속하게 채택했다. 2
From: Release의 모든 것
이 개념은 아마존 창립자이자 CEO 인 제프 베조스Jeff Bezos의 규칙으로, 모든 팀은 피자 두 판을 먹을 수 있는 규모 이상으로 커지면 안 된다는 내용이다. 이 개념이 중요하기는 하지만 사람들이 잘못 이해하고 있다. 단순히 팀의 적정한 사람 수에 관한 것이 아니라 그로 인해 소통에 도움이 된다는 뜻이다.
자기 완결적self-sufficient 피자 두 판 팀은 각 팀 구성원이 한 가지 이상의 직무를 담당해야 한다는 뜻이기도하다. DBA, 프런트엔드 개발자, 인프라 전문가, 백엔드 개발자, 머신러닝 전문가, 제품 관리자, GUI 디자이너 등 직무마다 전담하는 사람이 필요하다면 피자 두 판 팀을 만들 수 없다.
피자 두 판 팀은 외부 의존성이 낮아야 한다. 모든 의존성은 릴리퍼트Lilliput 사람이 걸리버를 해변에 묶어둔 밧줄과 같다. 각 의존성 하나하나를 가느다란 실처럼 간단히 처리할 수 있을지 몰라도 수천 개가 모이면 팀의 자유를 빼앗고 속박할 것이다.
여러 팀에 걸친 의존성은 시점과 대기 문제를 일으킨다. 어떤 일을 하려면 다른 사람들이 일을 마치기를 기다려야 하고 이런 식으로 모두의 일처리 속도가 점차 느려진다. 코드 변경 전에 전사 데이터 아키텍처 팀의 DBA가 스키마를 변경해야 한다면 DBA가 다른 작업을 마치고 스키마 변경 요청을 처리할 여유가 생기기 전까지 기다려야 한다는 뜻이다. DBA가 처리하는 시점도 우리가 요청한 작업의 우선순위가 작업 목록에서 어느 정도 높은지에 따라 달라진다.
동일한 일이 후속 검토와 승인 과정에서 일어난다. 아키텍처 검토 위원회, 출시 관리 검토, 변경 제어 위원회 등 각종 검토 절차가 시간을 지연시킨다.
이것이 피자 두 판 팀이라는 개념이 오인되는 이유다. 이 개념은 단지 소수의 코더만 프로젝트에 참여한다는 얘기가 아니다. 이것은 소수의 사람이 운영에 올리기까지 모든 과정을 자기 완결적으로 처리할 수 있도록 하는 것에 관한 이야기다.
팀 규모를 피자 두 판 수준으로 줄이려면 많은 도구와 인프라가 지원되어야 한다. 방화벽, 부하 분산기, SAN 같은 전용 하드웨어가 API 형태로 제공되어야 다른 팀에게 피해를 주지 않으면서도 팀마다 각자의 구성으로 관리할 수 있게 된다. 앞서 언급한 플랫폼 팀은 이 부분에서 맡은 역할이 크다. 플랫폼 팀의 목표는 팀 수준의 자율성을 가능하게 만들고 촉진하는 것이어야 한다. 3
참고문헌
- 개발자에게 물어보세요 / 제프 로슨 저/박설영 역 / 인사이트(insight) / 초판 1쇄 발행 2023년 03월 27일 / 원제: Ask Your Developer
- 데브옵스 핸드북 / 진 킴, 제즈 험블, 패트릭 드부아, 존 윌리스 저/김영기 역 외 1명 정보 더 보기/감추기 / 에이콘출판사 / 2018년 07월 06일 / 원제: The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations
- Release의 모든 것 / 마이클 나이가드(Michael T. Nygard) 저/박성철 역 / 한빛미디어 / 초판 1쇄 발행: 2023년 11월 29일 / 원제: Release It!, 2nd Edition