Man-Month 싸움

S/W 공학의 고전 중에 "The Mythical Man-Month" 라는 책이 있다.

Man-Month 는 우리말로 인월(人月) 이라고도 하기도 하는데,

대충 일상생활에서는 맨-먼스 라고 그냥 그대로 읽고,

뜻은 무슨 일을 하는데 투입되는 인력자원을 시간단위로 측정한 것 쯤 된다.

즉, 1개의 일을 하는데 1명의 사람이 9개월간 일을 해야한다면 9 man-month.

다른 말로 1사람의 1개월간 작업량 정도 되겠다.

이 man-month(이하 MM) 계산은 지식인에 올라온 아래 문제로 간단히 살펴보자.

어떤 소프트웨어 개발을 위해 10명의 개발자가 20개월 동안 참여되었다.

그 중 7명은 20개월 동안 계속 참여했고 3명은 5개월 동안만 참여했다.

이 소프트웨어 개발에 필요한 MM(Man-Month)은 얼마인가?

위의 설명대로 계산해 보자. 간단하다. 개발자의 능력은 모두 동일하다는 게 대전제다.

(7 * 20) + (5 * 3) = 155 MM 이다.

역시 간단하게 해석하면 이 S/W 개발을 개발하는데 1명이 일을 하면 155개월이 걸리고,

155명이 투입되면 1개월에 완료된다고 해석이 된다.

그런데 이게 이렇게 안된다는 건 하늘이 알고 땅이 알고 우리가 안다.

위에 잠깐 언급한 책의 저자 브룩스(Brooks)는 왜 이렇게 일처리가 안되는지 한 방에 명쾌하게 설명을 했다(조금 극단적이기는 하지만).

"1 명의 여자가 9달만에 아이를 낳는다고 해서, 9명의 여자가 1달만에 아이를 낳을 수는 없다."

일을 하다 보면 언제나 입에 붙는 말이 "사람이 모자르다"이다.

그런데, 사실 정작 필요한 건 "사람"이 아니라 제대로 된 "일정"일 경우가 훨씬 많다.

불행한 일은 사람은 더 많이 투입하기가 쉽지만, 시간은 더 늘리기 힘들다.

게다가 일정을 늘려주더라도 결국 끝에만 일한다는 인식이 팽배하다.

학교를 다니며 우리는 이런 수 많은 예를 목격했다.

"Due를 1주일을 주든 3일을 주든 여러분은 마지막 3일에서야 열심히 할 것이니까, 이 과제는 3일 후 제출하세요."

물론 대부분의 경우 이 말은 사실이다.

하지만 또 많은 경우 이 말은 틀렸다.

가장 큰 원인 중에 하나는 교수님은 다른 과목들의 과제일정을 전혀 알지 못하거나 신경쓰지 않는다(과목들이 많이 겹치는 학생들의 경우 단체로 격렬히 반발하지만 기한을 하루 늘리는데 성공하는 것에 만족해야 하는 경우가 많다).

따라서 실제로 우리에게 주어지는 시간은 3일이 아니라 하루거나, 이틀인 경우가 상당히 잦다. 정말 3일만에 해낼 수 있는 일도 어려워지기 시작한다.

그 다음으로는 정말 3일만에 끝날 수 있는지 충분히 검증되지 않은 경우가 있다.

컵라면은 뜨거운 물을 붓고 3분이면 먹을 수 있다.

하지만 물이 끓는데도 시간이 필요하다. 게다가 끓기 전까지는 아무리 열을 가해도 변화가 없다!

마찬가지로 일정을 정확하게 짰더라도 어느 시점까지는 일을 하지 않고 있는 것처럼 보이기도 한다. 또한, 진짜 놀고 있는 사람도 구분할 수가 없다.

이런 단점을 보완하고자 일일 보고서를 받기 시작하면, 또 다른 overhead 가 된다.

그냥 일정을 줄여버리면 사람들이 움직이기 시작한다.

뭔가 일하는 것 같다.

공장 돌아가듯이 잘 돌아간다.

하지만 충분한 시간이 없어 결과물이 엉망이다.

고민을 좀 하다, 인력을 더 투입한다.

"1 명의 여자가 9달만에 아이를 낳는다고 해서, 9명의 여자가 1달만에 아이를 낳을 수는 없다."