The Mythical Man-Month Chapter 3

2009/09/10 - The Mythical Man-Month Chapter 1
2009/10/08 - The Mythical Man-Month Chapter 2

Chapter 3 The Surgical Team

 컴퓨터 소사이어티 미팅에 가면, 젊은 프로그래밍 매니져가 다수의 그저그런 인력보다는 소수의 뛰어난 인력을 선호한다고 단언하는 것을 종종 들을 수 있다. 우리 모두 그렇다. 하지만 이 주장은 크고 복잡한 문제에 대해서는 해결책을 제시해줄 수 없다.

 프로그래밍 매니져들은 개발자 각각의 생산성에 많은 차이가 있음을 예전부터 잘 알고 있었다. 하지만 실제로 실험적으로 측정된 생산성에 대한 각자의 결과는 놀랍다. Sackman, Erikson, 그리고 Grant에 의해 시행된 실험의 결과에 따르면 개발자들간의 퍼포먼스 차이는 최대 10배 까지 차이가 났으며, 일의 효율에 있어서는 5배까지 차이가 났다고 한다. 그리고 연봉은 퍼포먼스와 효율과 큰 연관성음 없었다고 한다(하지만 일반적으로 그럴 것이라고 생가하지는 않는다).

 앞서 말했지만, 프로젝트의 비용의 대다수는 커뮤니케이션과, 잘못된 커뮤니케이션이 이루어짐에 따라 발생한 문제를 해결하는데서 발생한다. 이것 역시 왜 소수의 뛰어난 사람을 프로그래밍 매니져들이 선호하는지에 대한 증거가 될 수 있다. 그래서 결론은 간단하다. 200명이 투입된 프로젝트에서 25명의 매니져의 직분에 있는 사람만이 경쟁력이 있고, 실력이 있을만큼 경험이 풍부하다면, 나머지 175명은 해고하는 것이다.

 하지만 이 결론을 너무 성급히 내린것은 아닌지 생각해 보자. 우선 25명은 이상적인 소규모 그룹이라고 하기에는 너무 많은 인원이다. 조사에 따르면 일반적으로 프로젝트 내에서의 소그룹은 10명 이상이 되지 않는 것이 좋다고 한다. 25명의 인원은 최소한 2단계의 관리 체계가 필요로 하여 5명의 중간 단계 매니져들이 필요로 하게 된다. 더욱더 나아가 200명의 인력은 아주 큰 프로젝트를 하기에도 너무나 적은 인원이다. OS/360의 예를 살펴보면, 가장 많은 인력이 투입된 시점에서는 프로그래머, 서기, 비서, 매니져, 개발지원 등의 여러가지 일이 분담된 1000명 이상의 인력이 개발에 참여하고 있었다. 1963년 부터 1966년까지 아마도 5000 man-years가 개발 과정에 투입되었던것 같다. 200명의 인력으로는 25년이 걸렸을 일이다. 이것이 작지만 뛰어난 그룹의 문제점이다. 아주 큰 프로젝트를 진행하기 위해서는 터무니 없이 작은 인력이라는 것이다.

 이것이 딜레마다. 매니저는 효율성과 시스템 정체성 유지에 대한 문제 때문에 소수의 뛰어난 디자이너와 개발자를 선호한다. 하지만 아주 큰 프로젝트에 있어서는 아무리 뛰어난 소수의 인력만 가지고는 기한내에 일을 끝마치지 못한다. 이 두가지 문제점을 어떻게 해결할 수 있을까?

 Harlan Mills는 우리에게 신선하고 창의적인 해결책을 제시해준다. 큰 일을 작은 일의 단위로 나누고, 나뉘어진 작은 단위의 일들은 수술실에 투입되는 수술팀과 같이 작고 잘 조직화된 팀으로 해결해 나아가는 것이다. 한 팀의 다수의 인력이 한 문제를 두고 달려들어 해결하는 것이 아니라, 수술실에서 시술자가 집도하고 나머지 사람들은 수술을 거들어주는 방식으로 일을 해결하면 일은 효과적이고 효율적으로 잘 진행될 것이라는 것이다. 이것이 과연 우리가 원하는 결과를 효과적으로 가져다 줄 수 있을지, 아니면 일이 진행되기나 할지 의문을 갖게 될 것이다. 여러 사람이 일을 모두 함께 한다고 해도, 직접적인 설계와 작업에는 소수의 사람만 투입된다. 가능하기나 한 일인가? 은유법을 사용하여 일이 어떻게 분담되는지 설명해 보겠다.

시술자 (The surgeon)
Mills는 chief programmer라고 말한다. 이 사람은 기능(functional) 및 성능(performance) 명세서(specification)를 정의하고, 설계하고, 구현하고, 검증하고, 문서화하는 일까지 한다. 경험이 매우 풍부해야 하며, 수학적인 지식이나 애플리케이션이 적용될 도메인에 대해서 잘 알아야 한다.

조수 (The copilot)
시술자의 일을 뭐든지 대신 할 수 있는 그의 분신. 그러나 시술자 보다 경험이 약간 부족한 사람. 시술자와 함께 같이 일을 하면서 사고하고, 논의하고, 그의 일을 평가해주는 사람. 하지만 모든 결정권은 시술자에게 있다. 현재 작업중인 코드에 대해서 굉장히 자세히 알고 있고, 다른 설계방안에 대해서 생각해볼 여유가 있는 사람. 가끔 코딩도 할 수 있지만, 그 코드들에 대해서는 책임을 지는 위치는 아니다.

관리자 (The administrator)
시술자가 두목이고, 시술자가 모든 인사 및 행정 결정권을 가지고 있지만, 그가 이런 일에 시간을 써서는 절대 안된다. 그러므로 돈, 사람에 대한 문제들을 전문적으로 다루는 관리자가 있어야 한다.

편집자 (The editor)
시술자는 생성되는 모든 문서에 대해서 책임을 져야 한다(최대한 명확하게 기술되어야 하기 때문에 본인이 직접 써야 한다). 편집자는 이런 문서들에 대해 비판하고, 수정하고, 참고문헌들까지 정리해서 최종적으로 온전한 문서가 될수 있도록 도와줘야 한다.

비서들 (Two secretaries)
관리자와 편집자는 비서들이 필요하여, 프로젝트의 대외적인 일을 담당할 것이며, 아울러 프로젝트와 직접적으로 관련이 없는 문서들을 정리하게 될 것이다.

서기관 또는 사무관 (The program clerk)
프로그램 개발 과정에 대한 모든 기록들을 관리하게 된다.

대장장이 (The toolsmith)
파일 편집기, 문서 편집기, 디버깅 서비스들은 요새는 대부분 주어진 상태에서 일이 진행되기 때문에 자체적인 기계 운용 요원들이 필요 없다. 하지만 위에서 언급된 기능들은 항상 개발자들이 만족할만한 수준과 높은 신뢰성이 유지될 것이 요구된다. 시술자의 판단하에 언제든지 필요한 서비스나 기능들이 제공되도록 툴의 제공, 업그레이드, 유지 및 보수에 대한 서비스를 제공할 수 있는 사람이 필요하다.

테스터 (The tester)
기능에 대한 요구 명세서에 따라 테스트 케이스를 만들어서 전문적으로 테스트를 하는 사람.

언어 변호사? (The language lawyer)
Algol과 같은 언어를 사용해 시스템을 유용하게 활용하는데 도가 터있어서 시술자에게 조언을 해줄 수 있고, 시술자가 언제든지 조언을 구할 수 있는 사람.

 이렇게 구성된 수술팀과 유사한 팀은 효율적인 프로젝트 운용을 위한 요구사항에 딱 들어맞는다. 일반적으로 두명의 프로그래머들로 이루어진 팀과 시술자와 조수로 이루어진 수술팀과 유사한팀을 비교해 보자.

 일반적인 두명의 프로그래머들로 이루어진 팀에서는 일을 분담하고 각 프로그래머가 자기가 맡은 부분의 디자인과 구현에 책임을 지게 된다. 하지만 수술팀과 같은 팀에서는 시술자와 조수 모두 같은 부분에 대해서 일을 하게 된다. 그 부분의 코드에 대해서 두명이 세밀한 정보까지 공유할 수 있게 되고 일의 분담에 대한 노력도 줄어든다. 그리고 무엇보다도 시스템의 정체성이 지켜질수 있다는 것이 가장 큰 수확일 것이다. 또, 만약 두 프로그래머가 동등한 위치에 있다고 가정한다면, 서로 이견이 있을 경우에는 타협이 이루어져야 한다. 일을 나눠서 하게 되는 경우에는 한정된 자원을 나눠서 해야 하는데, 자원 분배의 판단 기준은 전체적인 안목에서 결정되어야만 함에도 불구하고, 분업이 이루어지면 각자 맡은 일의 관점에 따라 판단이 이루어지게 되므로 편파적인 결정이 이루어질 수 밖에 없다. 따라서 시술자와 보조자로 이루어진 팀과 같은 경우는 일의 분담에 대한 문제가 없고, 상하 주종의 관계가 있기 때문에 두 프로그래머로 이루어진 팀 보다는 uno animo로 작업하는 것이 가능해 진다.

 시스템 개발 이외의 일에 대해서는 각각 세분화시켜 전문가에게 맡기기 때문에 효율은 증대되고 커뮤니케이션의 구조는 매우 간단해져 일이 효과적으로 진행된다. 실제로 행해진 작은 규모의 실험에서는 위와 같이 일을 분담한 팀을 구성할 경우 좋은 결과를 가져온다는 것이 입증되었다. 하지만 이 방법을 큰 규모의 프로젝트에 많은 인력에 대해서 적용할 수 있을까? 오늘날의 많은 일이 5000 man-year가 필요한 것을 감안하면 매우 중요한 사안이다. 큰 프로젝트를 위와 같은 방식의 팀으로 나누는데 있어서 가장 중요한 것은 개발하는 시스템의 각 요소의 정체성이 보존될 수 있는 범위 내에서 일이 나누는 것이다. 이것에 대해서는 뒤에서 또 언급 한다. 여러개의 10명정도로 이루어진 수술팀이 큰 일을 분담하게 되면, 전체적인 사안에 대한 결정을 내려야 할 경우에는 각 팀의 시술자들만 모여서 협의하면 된다.

---

역시 요약하여 정리하는 것은 힘듭니다...
요약이 아니라 거의 번역이군요... 그렇다고 해서 수준높은 번역은 아닌데요... ㅡ.ㅡ;
조금이나마 도움이 되셨으면 좋겠습니다...
개인적으로 이 단원 마지막 소단원인 Scaling Up은 잘 이해가 안되는군요. 다른사람들이 요약한것을 보니 제가 잘못 이해 한듯 하여, 다른 사람들의 요약한 내용을 기반으로 정리했습니다. 혹시 이 책 읽어보신 분이나 읽게 되는 분 계시면 나중에 저랑 짧게 이 부분에 대해서 의견교환 해봤으면 좋겠습니다... 답글남겨주세요~