팀원 수와 피자 두 판
Jeff Bezos instituted a rule: every internal team should be small enough that it can be fed with two pizzas.
번역: 제프 베조스는 규칙을 제정했다: 모든 내부 팀은 두 개의 피자로 충분히 먹을 수 있을 정도로 작아야 한다.
출처: The two-pizza rule and the secret of Amazon's success, Alex Hern, TheGuardian.com, 2018. 4. 24.
제프 베조스의 규칙은 한 사람이 보통 2조각 정도 먹는다면 결국 한 팀은 8명 이내여야 한다는 뜻이다. 8명을 넘어서면 토론이 쉽지 않아 의사소통 시간과 비용이 급격히 커지기 때문이다.
8명을 넘어선 큰 개발팀
꼭 베조스의 규칙이 아니더라도 8명을 넘어서는 경우 작은 팀으로 다시 팀을 나누게 된다. 개발팀 전체가 11명이었는데 백엔드 3명, 프런트엔드 4명, 앱(안드로이드, iOS) 4명 식으로 나뉜다면 큰 문제가 없다. 담당하는 영역 자체가 달라 다 같이 토론하고 정해야 할 사안이 많지 않기 때문이다. 하지만 백엔드 개발자 12명을 4명씩 세 팀으로 나누는 경우라면 상황이 다를 수 있다. 백엔드 전체가 스프링, NestJs 같은 하나의 프레임워크를 쓰고 한 프로젝트를 서로 영역을 나눠서 개발하고 있다면 말이다. 이 경우는 팀은 나눠졌지만 서로 토론하고 정해야 할 사안이 많기 때문이다.
큰 개발팀에서 발생하는 문제
1. 과거 코드 답습
보통 레거시legacy라고 하는 과거 코드가 문제가 있어도, 더 개선할 방안이 있어도 개발조직 전체 적용이 어렵다. 의사소통 비용이 너무 크기 때문이다. 그래서 과거를 답습하는 방향으로 개발하게 된다.
2. 새로운 아이디어 적용 어려움
세 네 명으로 이뤄진 개발팀은 일상적으로 토론이 이뤄지니 당연히 새로운 아이디어가 채용되기 쉽다. 하지만 개발팀이 커진다면? 팀 전체에 영향을 주는 아이디어는 받아들여지기 쉽지 않다.
해결책
해결책1. 탑다운top-down, 위에서 결정되어 아래로 전달되는 방식
개발팀장이 결정하는 방식이다. 각 팀원은 스스로 결정하지 않고, 개선안 등 안건이 있을 때마다 팀장한테 문의하고 결정을 따른다. 이 방식이 잘 되기 위해서는 팀장의 실력이 다른 팀원에 비해서 월등하게 뛰어나야 한다. 토론보다는 팀장 의견에 따르는 방식이기 때문이다. 팀장의 실력이 팀원과 부족하거나 엇비슷할 때 팀원들 입장에서 팀장의 불합리한 결정이 쌓이면 팀원들은 불만이 생겨서 떠나게 된다.
해결책2. 보텀업bottom-up, 아래에서 위로 전달하는 방식
팀구성원들이 가진 개선안들이 위로 잘 전달되어서 개발팀 전체로 적용되도록 하는 방식이다. 이를 위해서는 체계적인 안건 상정 절차가 필요하다. 체계적으로 해놓지 않으면 개발 조직 책임자의 개인적 성향에 따라 진행되거나 사라지기 때문이다.
안건 상정 절차 예
민주주의 정치체제의 안건 상정 체계를 따르면 된다. 물론 개발 조직 특성상 완전히 민주적으로 안건을 결정할 필요까지는 없다.
1. 개발팀 내 누구나 안건을 올릴 수 있다.
2. 안건 논의에 동의하는 사람들은 해당 안건에 '안건 논의 동의합니다'라고 적는다.
3. 안건 논의에 필요한 최소 동의자 수를 넘어선 안건들을 일정 기간 동안 토론을 진행한다. 온라인을 활용해서 미리 충분히 토론하고, 오프라인에서는 최종 결정만 진행한다면 의사소통 비용을 줄일 수 있다.
4. 함께 토론에서 정한 사안을 위키 등에 문서로 정리하고 개발조직 전체에 적용한다.
기타 세부 절차는 팀 상황에 맞춰 정한다.
안건 상정 방식의 장점
1. 개인 능력 의존도가 낮다.
탑다운 방식은 팀장에 의존한다. 개발 영역은 변화와 발전 속도가 빠르다. 압도적인 실력의 CTO 또는 개발팀장을 데려와도 시간의 흐르면 그의 능력은 금방 시대 흐름에 뒤쳐질 수 있다. 보텀업 방식은 각 구성원의 새 아이디어를 지속적으로 반영할 수 있으니 개인 의존도가 낮다.
2. 시스템 개선 속도를 높여준다.
공식적인 상정 절차, 프로세스가 없다면 팀구성원들은 코드 개선안이나 아이디어가 있어도 말할 수 없게 된다. 하지만 공식 안건 상정 절차가 있다면 말할 수 있게 된다. 토론과 결정이 활발히 이뤄진다면, 개선안 반영 속도가 빨라진다. 곧 시스템 전체가 과거에서 벗어나 빠른 속도로 진화하게 된다.
3. 세부 팀간의 차이를 줄여준다.
세분화된 소규모 팀 안에서는 소통이 활발하다. 어떤 소규모 팀장이 새로운 아이디어를 잘 받아들이고 또 다른 팀장은 보수적일 수 있다. 이 때 팀 전체 소통이 활발하지 않다면 팀간 코딩 방식의 차이가 커지게 된다. 공식 안건 상정 절차를 통해 팀 전체 공유된다면 팀간 차이가 줄어든다.
안건 상정 절차가 없어도 의견 수용이 잘 된다는 착각
팀장은 굳이 안건 상정 절차가 없어도 자신은 조직원들의 의견을 잘 듣고 반영하고 있다고 생각하기 쉽다. 팀장과 팀원이라는 위계가 있는 사이에서 둘이서 진행하는 토론은 토론이 아니다. 자신이 팀장이라면 대표CEO와 어떤 사안을 논의한 경험을 떠올려보면 된다. 대표 의견에 반론을 제기하며 과연 만족스럽게 토론이 제대로 되었던가.
해결책2의 예 Python Enhancement Proposals(PEPs)
PEPs 파이썬 개선 제안들이 한 예가 될 수 있다. 파이썬을 만든 귀도 반 로섬 혼자 파이썬을 만들고 진화시킨 것이 아니다. PEPs를 통해서 다른 개발자들 의견을 듣고 수용해서 함께 발전시켜 온 것이다. PEPs 덕분에 파이썬이 가장 인기있는 언어 중 하나로 성장한 것 아닐까.
참고 글
The two-pizza rule and the secret of Amazon's success, Alex Hern, TheGuardian.com, 2018. 4. 24.
제프 베조스의 팀 빌딩 방식 피자 두 판의 법칙, TTimes
Python Enhancement Proposals