The Surgical Team
다른 분야들도 그러하겠지만, 특히 소프트웨어 분야는 한 명의 천재 개발자가, 백명의 일반 개발자보다 낫다는 말을 하곤 합니다.
실제로 구글에서도 보면, 솔직히 저같은 개발자 100명보다는 Jeff Dean 이나, Sanjay Ghemawat 같은 사람 한 명이 더 뛰어난 것 같습니다.
Jeff Dean이나 Sanjay Ghemawat같은 초특급 개발자가 아니라 하더라도,
주위의 많은 개발자들 가운데에서 연봉은 2~3배 밖(??)에 더 받지 않는데, 생산성은 5배 10배의 사람들을 종종 볼 수 있습니다.
세상의 모든 사장, 매니저들은 그러한 사람들로만 회사를 꾸리고, 팀을 꾸리고 싶어할 것입니다.
팀안에 사람이 많아지면 많이잘 수록, 소통해야하는 관계가 증가하게 되고, 이것은 잘못된 오해를 일으키기 쉽습니다. 또한, 사공이 많으면 배는 산으로 가곤 하지요. 적은 수의 사람으로 작은 팀을 꾸리는 것은, 그러한 비용의 증가를 막을 뿐더러, 빠르게 변화하고 있는 시장 상황에 기민하게 반응할 수 있다는 장점도 있습니다.
예를 들어서, 200명이 일하는 프로젝트에 25명의 경험있는 프로그래머들이 매니저로서 일을 하고, 나머지 175명의 초급 프로그래머들에게 일을 시키기로 계획하였다고 합시다. 사실은 175명을 해고하고, 25명의 매니저들을 다시금 경험있는 프로그래머로서 일하도록 하는 것이 더욱 더 효율적인 방법이 될 수 있습니다.
하지만, 여기에는 치명적인 약점이 두개 있습니다.
첫번째는 200명이라는 숫자도 아주아주 커다란 프로젝트를 수행하는데에는 그다지 커다란 숫자가 아니라는 것입니다.
예를 들어서 저자가 일했던 프로젝트중 하나인 OS/360에는 약 5,000 Man-Year (Month가 아니라, Year입니다!) 가 소요되었습니다.
즉, 200명이 일했다면, 약 25년의 시간이 걸렸을 것입니다.
혹시, 여러분들중에 25년전에 만들어진 프로그램 사용하시는 분 계십니까?
약, 12년전에 나온 Windows XP를 쓰는 사람들도 요즘에는 너무 오래된 구닥다리 OS를 사용한다고 무시를 당하기 일쑤입니다.
두번째는 그렇게 뛰어난 사람들은 세상에 그다지 많지 않습니다.
구글처럼 Jeff Dean과 Sanjay Ghemawat을 동시에 가질 수 있는 것도 굉장히 커다란 행운이라고 생각합니다.
즉, 딜레마는, 세상에 뛰어난 사람들이 아주 많지 않은 상황에서 어떻게 커다란 팀을 꾸릴 수 있느냐 입니다.
저자는, Harlan Mills가 "Chief programmer teams, principles, and procedures,"에서 제안한 의료 수술팀의 형태를 제안합니다.
실제로 병원에서 수술을 할 때면, 단 한명이 처음부터 끝까지 모든 수술을 집도하고, 나머지 사람들은 조수로서 거들어 주는 방식의 분업이 이루어집니다.
소프트웨어 개발에서도 비슷한 구성을 할 수 있을 것이라고 합니다.
1.수술집도의 (The surgeon) = 책임 프로그래머 (a chief programmer)
수행할 프로젝트의 모든 것을 알고 있으며, 디자인, 성능 명세서, 코딩, 테스트, 그리고 문서화작업까지 모든 것을 다합니다.
뛰어난 실력과 10년이상의 경험, 그리고 시스템에 대한 충분한 지식을 가지고 있으며, 필요할 때는 수학적인 지식뿐만 아니라, 데이터를 다룰 수 있는 능력까지 지니고 있는 사람입니다.
전체 프로젝트의 책입자이며 상사(boss)이기도 합니다.
2. 부 집도의 (The copilot) = 프로그래머
이 사람은 책임 프로그래머가 수행하는 대부분의 일을 할 수 있습니다. 다만, 경험이 부족합니다.
책입 프로그래머와 함께 토론하고 새로운 아이디어를 테스트해볼 수 있는 실력이 있는 사람입니다. 코드를 직접 작성할 수도 있지만, 책입 프로그래머의 승락하에서 그 코드가 실제 프로젝트에 적용이 됩니다.
3. 행정 관리자 (the administrator)
책입 프로그래머가 전체프로젝트의 상사이지만, 돈이라던지, 공간, 컴퓨터 기계할당과 같은 일을 다 하기에는 이미 너무 많은 역할이 있으므로, 행정 관리자가 그러한 점들을 도와줍니다. 반드시 하나의 프로젝트에 종속될 필요는 없고, 두개의 프로젝트를 동시에 관리해줄 수도 있습니다.
4. 편집자 (The editor)
프로젝트 안에서 발생하는 모든 문서를 정리하고, 다듬는 역할을 담당합니다. 예를 들어, 프로그래머들이 시스템 디자인에 대한 초안을 만들면, 그것을 다듬에서 대내외적으로 사용할 수 있도록 다시 작업을 해주기도 합니다.
5. 두명의 비서 (Two secretaries)
행정관리자와 편집자를 도와줄 비서가 각각 한명씩, 총 두명이 필요합니다.
6. 프로그램 서기 (The program clerk)
프로젝트가 어떻게 진행되고 있는 모든 기록들을 담당합니다.
7. 도구장이 (The toolsmith)
프로그램을 개발하려면 여러가지 도구들이 필요합니다. 그러한 것들을 개발하고, 지원해주는 팀입니다.
실제로 구글에서는 이러한 도구팀에만 100명이 넘는 엔지니어들이 일을 하고 있습니다.
8. 테스터 (The tester)
기본적으로 프로그래머들이 테스트 케이스들을 작성하기도 하지만, 그것은 단위 테스트일 경우가 많습니다
.이 테스터는 좀더 최종적인 프로젝트의 관점에서 테스트 순서를 세우고 보다 완벽하게 테스트를 합니다.
9. 프로그래밍 언어 상담가 (The language lawyer)
때로는 복잡한 프로그램도 다른 언어를 사용함으로서 쉽게 해결될 수가 있습니다.
그러한 제안을 해주는 것이 바로 이 프로그래밍 언어 상담가입니다.
책입 프로그래머는 때때로 이 상담가를 찾아서 주어진 문제를 이야기하고, 그러한 문제를 해결할 수 있는 가장 최적의 프로그래밍 언어를 알아낼 수 있습니다. 이 상담가는 여러명의 프로그래머를 지원해주고 도와줄 수 있습니다.
10. 왜 10이 없을까요? 그건 5번에서 비서가 두명이기 때문이지요. ^^
자, 그러면 몇명의 책임 프로그래머가 있어야지, 5,000 Man-Year 프로젝트를 1년안에 마칠 수 있을까요?
두가지 가정을 더 해보겠습니다. 저 5,000 Man-Year은 중간 수준의 프로그래머 5,000 명이 1년동안 구현하였다고 하고, 두번째로 10명 팀에서의 책임 프로그래머는 약 7배의 생산성을 가지고 있다고 해보겠습니다.
정답은 5,000 / 7 = 715명이 아닙니다! 그 비밀은 사공이 많을 수록 배는 산으로 가는 것에 있습니다.
실제로 토론하고 결정해야하는 사람의 숫자가 줄어들 수록 효율성은 올라갑니다. 물론, 사람이 줄어드는 만큼 개개인의 역량은 뛰어나야 겠지요.
따라서 실제 정답은 5,000 / 7 / 7 = 102명입니다.
5,000 Man Year 프로젝트를 약 100여개의 작은 프로젝트로 나누고, 각 프로젝트별로 뛰어난 역량의 책임 프로그래머를 임명하고, 그 프로그래머를 도와줄 수 있는 사람들을 붙여주는 것이 가장 효율적으로 일할 수 있는 방법입니다.