Things...

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


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

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

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


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

  소프트웨어 프로젝트의 대부분은 다른 문제보다도 납기를 지키지 못하는 문제를 가장 많이 가지게 된다. 왜 이런 문제가 보편적으로 발생할까?

  거의 극소수의 프로젝트들만이 테스팅에 전체 개발 기간의 반을 할애한다. 하지만 결과적으로는 대부분의 프로젝트는 원래의 전체 개발 기간의 반이라는 시간이 걸리게 된다. 테스팅 및 디버깅에 너무 짧은 시간을 할애 하게 되면, 대부분의 일정 지연이나 문제점들은 프로젝트 막바지에 나타나기 때문에 치명적일 수 밖에 없다.

  간혹 개발 일정이 지연되면, 인력을 더 추가하는 경우가 다반사인데, 새로 투입된 인력의 훈련과 교육, 그리고 추가된 인원 사이에서 이루어져야 하는 communication의 부하 때문에 일정은 단축되기 보다는 점점 지연되는 불상사가 발생한다. 이것이 수많은 프로젝트들이 개발 일정에 뒤쳐지는 가장 큰 이유이다. 지연된 프로젝트에 추가적인 인원을 투입하는 것은 그 프로젝트를 더 지연시키는 결과를 낳게 된다.

---

  두번째 단원 요약입니다. 실제로 책을 읽어보면 소단원이 여러개로 나뉘어 있는데, 읽다보면 공감이 가는 부분이 많음에도 불구하고, 각 소단원의 연관성은 잘 못찾겠네요 ㅡ.ㅡ;

 책의 내용중에 빼먹은 사소한 것들도 있고. 책에는 일정 지연과 인력 투입에 대해서 좀더 자세하게 다루고 있으니 관심있으신 분은 꼭 책을 읽어보시기 바랍니다. ^^

---