예를 들어 10M/M인 경우 한 사람이 열 달 동안 작업하는 양, 또는 열 사람이 한 달 동안 작업하는 양을 모두 말합니다. 그런데 소프트웨어 개발은 토목공사와 같은 일이 아니기 때문에, 이 두 경우는 다른 결과를 가져올 수 있습니다.
마치 소프트웨어 개발을 구슬꿰기 같은 노동의 산물이라고 편리하게 생각한 결과이겠지요. 그러나 실제는 적용하는 알고리즘이나 방법론, 그리고 축적해둔 지적 라이브러리(library)의 양에 따라 생산성이 극과 극을 달리게 됩니다. 어느 누구 밖에 할 수 없는 부분은 몇 명을 투입해도 시간이 줄지 않습니다. 또한 사람이 늘수록 커뮤니케이션 비용은 늘어나 시간이 지체될 수도 있습니다.
그러나 더 큰 문제는 시공사가 뛰어난 아이디어와 창의성을 가지고 공기(工期)를 단축해도 별다른 인센티브가 없다는 점이지요. 따라서 프로그래머들은 ‘힘 조절’을 하면서 일부러 ‘맨/먼스’를 부풀리기까지 합니다. 이는 필연적으로 공시 가격의 신뢰성을 떨어뜨리고, 종국에는 부실시공으로 이어지곤 합니다.
현대 프로젝트 방법론은 다양한 계약 방법으로 ‘맨/먼스’의 함정을 피해갈 구멍을 만들어주고 있습니다만, 아쉽게도 대부분 프로젝트의 절대적 기준이 됩니다. 시공사의 설비투자 현황과 생산능력, 즉 인력의 질과 능력에 따라 평가가 이루어지는 프로젝트가 자리잡지 못한다면, 프로젝트 자체가 값싼 ‘맨/먼스’를 찾아 중국으로 그리고 인도로 넘어가는 것은 시간 문제일지도 모릅니다.
