The Surgical Team

많은 사람들이 똑똑한 사람들로 이루어진 작고 빠른 팀이 더 좋다고 한다. 너무 당연한 이야기이고 요즘 들어 특히 AI의 발전으로 인해 스타트업 업계에서도 많이 돌고 있는 말이다. 하지만 이 나이브한 간과한 문제가 있다. 그렇다면 어떻게 큰 시스템을 정해진 일정 안에 만들 수 있을까? 이것은 작은 팀만으로는 불가능하다.

 

The Problem

프로그래머의 생산성은 차이가 심하다. 연봉이 2배차이 나더라도 생산성은 10배까지 차이 날 수 있다. 200명으로 이루어진 팀이 있다고 가정해 보자. 여기에 25명의 매니저 역할을 하는 고급 프로그래머가 있다고 했을 때 우리가 해야 할 일은 175명을 자르고 25명의 매니저를 프로그래머로 바꾸는 것이다. 여전히 25명의 팀은 크다. OS/360을 완성하는데 3년동안 5000 man-year를 사용했다. 해당 시스템을 만드는데 200명으로 이루어진 팀은 25년이 걸린다. 이 보다 작은 팀은 훨씬 오래 걸릴 것이다. 그렇게 많이 시간이 지난 후에 우리가 만든 것은 더 이상 쓸모 있지 않을 것이다.

 

MMills's Proposal

10명으로 이루어진 팀은 어떻게 구성되어야 할까. 문제를 쪼개서 각자가 푸는 식으로 구성하는게 아니라 수술실의 멤버처럼 구성되어야 한다. 중심에는 surgeon이 있다. 그는 chief programmer이며 모든 디자인 결정과 코딩을 한다. 그리고 다른 멤버들은 surgeon의 손과 발이 되어 한 사람이 여러 개의 손이 있는 것과 같은 효과를 내준다. copilot이라고 surgeon과 같은 역할을 하지만 덜 경험이 있는 사람이고 여전히 모든 최종 판단은 surgeon이 한다. 이외의 인원들은 surgeon이 하지 않아도 될 일들을 처리하는 역할을 한다.

 

여기서 surgeon과 copilot의 기존의 페어프로그래밍 팀과는 다르게 종속적이다. 따라서 서로의 이해관계에 따른 논쟁 없이 무조건 최종적으로는 surgeon의 판단을 따라야 한다. 또한 기존의 페어프로그래밍 팀에서는 한명이 일을 나눈 후에 각자 맡은 부분에서 디자인을 하고 구현을 한다. 하지만 새로운 팀에서는 모든 부분을 같이한다. 이제 surgical team으로 10명을 구성해서 효율적인 작은 팀을 만들었다. 하지만 여전히 이 팀으로는 5000 man-year가 걸리는 큰 프로젝트는 하지 못한다. 그러면 어떻게 스케일 업을 할 수 있을까. 핵심은 해당 팀들에게 나누어진 문제들이 각각 conceptual integrity가 잘 지켜지느냐이다. 그리고 전체 시스템을 설계하고 문제를 나누는 일은 이제 200명의 팀에서 20명의 surgeon들의 문제로 줄어들었다.