낙관적인 어린아이 - The Mythical Man-Month

어린 아이들은 꿈을 꿉니다. 그리고 그 꿈을 모두 이룰 수 있다고 믿습니다.

저도 어렸을 때는 노벨상 수상, 당연히 할 수 있을 줄로만 알았고, 마음만 먹으면 우주비행사도 될 수 있을 줄 알았습니다.

어른이 된 우리는 이러한 일들이 그리 쉽게 이루어질 수 없다는 사실을 너무나 잘 알고 있습니다.

하지만, 소프트웨어 엔지니어로서의 우리는 여전히 어린 아이들인 것 같습니다.

어떠한 일을 주고, 이 일을 언제까지 할 수 있느냐고 물어보면, 대다수는 낙관적인 대답을 합니다.

그리곤 부지기수로 그 일을 본인이 대답한 기간내에 끝을 내지 못하고, 상사들에게 쪼임을 당하지요.

혹시, 여러분들 중에 "내가 이때까지 하겠습니다."라고 상사에게 말했을 때,

"그거 너무 낙관적인거 아니야" 라고 되물음을 당하신 적이 있다면, 최소한 여러분은 Information Technology 강국의 상사와 일하고 계십니다.

하지만, 반대로 무리할 일정인대도 항상 "그래, 아주 좋아! 한번 해봐!" 라고 말을 듣는다면, 여러분은 Information and Telecommunication 강국의 상사와 일하고 계십니다.

이 책의 저자는 본인이 관리하는 프로젝트의 일정을 다음과 배분합니다.

1/3 계획

1/6 코딩 및 구현

1/4 개별 테스트 및 초기 시스템 테스트

1/4 전체 시스템 테스트.

첫 인상은, 생각보다, 계획이 길고, 생각보다 구현이 짧다는 것을 알 수 있습니다.

프로젝트를 진행할 때마다, 이러한 말들을 많이 듣습니다. 구현 명세(Specification)이 너무 자주 바뀝니다.

혹시, 이것은 우리가 충분한 시간을 계획에 쏟지 않았기 때문은 아닐까요?

통일이 되어서 서울에서 중국 상하이로 가야 하는데, 자동차 여행을 하려고 합니다.

이때, 단순하게 상하이가 서쪽에 있다고, 무작정 서쪽으로 인천으로 자동차를 운전하면 어떻게 될까요?

충분한 시간을 계획에 투자하는 것이 궁극적으로 시간을 절약할 수 있습니다.

하지만, 충분한 계획을 세운다고 하더라도, 일정은 지연될 수도 있지요.

책에 나와있는 예제는 다음과 같습니다.

3명이 4달동안 할 프로젝트가 있습니다. 매달마다 Milestone이 있고, 그것은 A, B, C, D라고 합니다.

즉, 첫달에 A를 도달하고, 두번째 달에 B를 도달하고, 세번째 달에 C를 도달하고, 마지막 네번째달에 D를 도달하여서 전체 프로젝트를 마칩니다.

3명이 4달동안 일하는 프로젝트 이므로, 이 프로젝트의 Man-Month는 3 Man * 4 Month = 12 Man-Month 입니다.

자. 그런데 그 프로젝트가 지연이 되어서, 두달동안 A를 겨우 도달하였습니다.

이때 우리는 무엇을 할 수 있을까요? 저자는 4가지, 우리가 선택하는 방법들을 말해줍니다.

1. 남은 두달 안에 프로젝트를 반드시 끝내야 된다고 가정합시다. 남은 일의 양은 3 Man * 3 Month = 9 Man-Month 입니다. 이것을 두달 만에 해야하므로, 4.5 명이 필요합니다. 우리에게는 현재 3명이 있으니깐, 1.5명을 더 고용합니다.

2. 역시, 남은 두달 안에 프로젝트를 반드시 끝내야 된다고 가정합시다. 애초에 Man Month를 잘 못 계산하였다고 인정을 합니다. 즉, 이 프로젝트는 3명이서 한달마다  각각의 마일스톤을 달성하는 것이 아니라, 3명이서 2달동안 각각의 마일스톤을 달성할 수 있는 프로젝트였습니다. 3명이서 2달동안 1/4인 A를 도달하였으므로, 원래 필요한 Man-Month는 3 * 2 * 4 = 24 Man-Month 이고, 현재 18 Man-Month 가 남았습니다. 2달이 남았으므로 총 9명이 필요하고, 현재 우리에게 3명이 있으므로, 6명을 추가로 고용합니다.

3. 다시 일정을 계획을 세웁니다. 이번에는 다시는 이런 일이 없도록, 아주 조심스럽게 계획을 새로 세웁니다.

4. 프로젝트를 축소하는 것입니다. 이 방법은 일정을 연기하는 비용이 너무 비쌀 때 주로 선택이 됩니다.

여기에서 주목을 해야하는 것은 사람을 추가하는 첫번째와 두번째 방법입니다.

이 방법 들은 아주 중요한 두가지를 빼먹고 있습니다. 훈련과 소통입니다.

새로운 멤버가 중간에 들어오게 되면, 이미 있는 시스템에 익숙해지고,해야할 프로젝트를 이해하는데 시간이 필요합니다.

구글에서는 이 기간을 짧게는 3개월에서 길게는 약 1년정도로 잡고 있다고 들었습니다.

앞의 예에서 만약에 어떠한 사람이 시스템과 프로젝트를 이해하는 데 3개월이 시간이 걸린다고 가정하면, 이미 그 사람이 이해할 때쯤에는 모든 프로젝트가 거의 막 바지에 달해있을 것입니다.

두번재로 소통은 누군가가 들어오면 소통을 해야할 사람이 기하급수적으로 늘어난 다는 사실입니다.

2명밖에 없을 때는 소통의 채널이 A - B만 있으면 되지만,

3명이 되면, A - B, A - C, B - C. 3배로 늘어나고,

4명이 되면, A - B,  A - C, A - D, B - C, B - D, C - D로 2명일 때보다 6배로 늘어나게 됩니다.

함께 프로젝트를 처리해 나가는데 이 소통의 비용 또한 무시할 수 없습니다.

즉, 이러한 훈련과, 소통의 시간 때문에, 실제로 프로젝트 중간에 사람을 추가하는 것은 불난 집에 석유를 붓는 것과 같습니다.

이러한 현실을 저자는 자기의 이름을 붙여 "Brooks's Law"라고 표현하였습니다.

Adding manpower to a late software makes it later.

지연된 소프트웨어 프로젝트에 사람을 더 추가하는 것은 그 프로젝트를 더욱 늦게 만든다.

100층 짜리 높은 빌딩을 지을 때, 우리가 기초공사 다지고, 30층까지 지은 빌딩을 허물고 다시 짓지 않을 수 있는 것은, 충분한 경험을 바탕으로 충분한 시간을 들여서 게획을 세우기 때문이라고 생각합니다.

미리 미리 충분한 시간을 들여서 계획을 세울 때만이, 전체적인 프로젝트 일정을 앞당길 뿐만 아니라, 충분한 테스트를 통하여, 더욱 단단한 소프트웨어를 만들 수 있습니다. 사실 이러한 일을 담당하는 사람이 시스템 아키텍쳐인 것 같습니다. 충분한 경험을 바탕으로, 전체적인 시스템의 그림을 그리고, 일정을 짤 수 있는, 이러한 뛰어난 시스템 아키텍쳐가 한국에서도 많이 나오기를 기대합니다.