От Ильича до Ильича
by sonnet 2006 이글루스 TOP 100 2007 이글루스 TOP 100 2008 이글루스 TOP 100 2009 이글루스 TOP 100 2010 이글루스 TOP 100 2011 이글루스 TOP 100
rss

skin by 이글루스
브룩스의 법칙
두 번째 잘못된 사고방식은 추정 및 일정 관리에서 투입된 노력을 셈할 때 쓰는 단위에 나타나 있는데, 바로 맨먼스man-month라는 단위다. 물론 프로젝트 비용은 투입된 사람 수와 달수의 곱에 따라 변한다. 하지만 작업 진척도는 그렇지 않다. 그러므로 맨먼스 단위로 작업량을 잰다는 것은 위험하고도 기만적인 미신과도 같다. 거기에는 사람과 일정이 서로 교환 가능하다는 인식이 깔려 있다.

사람과 일정이 교환 가능한 유일한 경우는, 어떤 일을 여러 사람에게 나눠줄 수 있으면서 서로 간에 소통할 필요가 없는 경우다(그림 2.1). 이것은 밀을 수확하거나 목화를 따는 일에는 들어맞겠지만, 시스템 프로그래밍에는 대략이라도 해당되지 않는다.


만약 작업의 성격상 순서가 있어서 나누기가 어렵다면, 거기에 어떤 노력을 더 쏟아 붇더라도 일정에는 아무런 영향을 미치지 못한다.(그림 2.2). 아기가 세상에 태어나려면 임신부가 몇 명이든 아홉 달이 필요하다. 버그를 찾고 고치는 것이 순차적으로 진행될 수밖에 없으므로 소프트웨어 개발 작업은 이처럼 분할이 어려운 경우가 많다.

분할은 가능하지만 나뉜 하위 작업들을 처리하는 데 커뮤니케이션이 필요하다면, 거기에 들어가는 노력 또한 전체 작업에 포함되어야 한다. 따라서 이런 경우는 아무래도 사람과 기간을 대등하게 맞바꿔 계산한 것에 못 미치는 결과를 기대할 수밖에 없다(그림 2.3).

커뮤니케이션으로 추가되는 부담은 훈련과 의사소통의 두 부분으로 나뉜다. 모든 작업자는 기술적인 내용, 작업 목표, 전반적인 전략, 업무 계획 등에 대해 훈련을 받아야 한다. 이런 훈련은 분할할 수가 없는 작업이므로 그 부담은 추가로 투입되는 사람 수에 비례해서 증가한다. [1]

의사소통 쪽은 좀 더 좋지 않다. 각 파트가 모든 파트와 개별적으로 조정을 해야 한다면, 커뮤니케이션 부담은 n(n-1)/2배가 된다. 일대일 의사소통의 횟수는 세 명의 경우 두 명일 때보다 세 배가 되며, 네 명이라면 여섯 배가 된다. 만약 세 명, 네 명, 그 이상의 사람이 모여서 회의를 통해 문제를 해결해야 한다면 일은 더욱 심각해진다. 커뮤니케이션 문제 때문에 더해지는 부담은 작업을 나눠서 얻는 이점을 완전히 상쇄할 수도 있는데, 그림 2.4에 이런 상황이 나타나 있다.

소프트웨어를 만든다는 것은 본래 조직적인 활동, 즉 복잡한 상호연관성을 가진 활동이기 때문에 의사소통에 품이 많이 들 수밖에 없으며, 작업 분할로 확보된 개별 업무 시간을 금방 잠식해 버린다. 따라서 사람을 더 투입하는 것은 일정을 단축시키기는커녕 더 늘어지게 만든다.

[...] 지금까지의 내용을 극도로 단순화한다면, 다음과 같은 브룩스의 법칙을 제시할 수 있을 것이다.

“늦어진 소프트웨어 프로젝트에 인력을 추가로 투입하면 더 늦어지게 된다.”

이렇게 하여 우리는 맨먼스에 관련된 미신을 걷어낼 수 있다. 프로젝트에 소요되는 기간은 순서대로 처리해야 하는 내부 요소에 좌우되며, 필요한 최대 인원수는 독립된 하위 작업의 개수에 좌우된다. 이 두 가지 수치를 파악했을 때, 관리자는 더 적은 수의 사람과 더 긴 기간에 기초한 일정을 수립할 수 있다. (유일한 위험은 제품이 시대에 뒤쳐지게 되는 것이다). 그러나 더 많은 사람과 더 짧은 기간으로는 실행 가능한 일정을 만들어 내지 못한다. 부족한 시간 탓에 망가진 소프트웨어 수는 다른 이유로 그렇게 된 경우를 모두 합한 것보다도 많다.

Brooks Jr., Frederick P. 1995. The Mythical Man-Month: Essays on Software Engineering, Anniversary(2nd) ed. Addison-Wesley Professional. (강중빈 역, 『맨먼스 미신 : 소프트웨어 공학에 관한 에세이』. 서울: 인사이트. pp.15-19, 25-26)
by sonnet | 2020/02/03 14:12 | 과학기술 | 트랙백 | 덧글(10)
트랙백 주소 : http://sonnet.egloos.com/tb/7481542
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
Commented by 일화 at 2020/02/03 19:36
깔끔한 정리네요. 좋은 글 감사합니다.
Commented by paro1923 at 2020/02/03 20:49
Man-Month가 미신인 산업 분야가 비단 소프트웨어 분야만은 아니지 않나 하는 생각이 듭니다. 저건 여러모로 하드웨어적인 단순생산 분야에나 통용될 법칙이니...
Commented by sonnet at 2020/02/04 11:59
네. 저도 브룩스가 이야기하는 것은 일정규모 이상의 팀으로 작업하는 지식근로 대부분에 해당한다고 생각합니다. 그리고 후기산업사회가 되면서 이런 종류의 업무가 과거보다 훨씬 더 많고 중요해졌고요.
Commented by 파파라치 at 2020/02/04 08:58
의뢰인과 수임인 양쪽의 이해가 일치하기 때문에 유지되는게 아닌가 싶습니다. 의뢰인(오너가 아닌 실무자) 입장에서도 보고할 때 가격을 정당화하기 쉽고, 수임인 쪽에서도 투입한 인원에게 들어가는 비용을 예상하기 쉬우니 말이죠. 말씀하신대로 용역의 품질이나 기한과는 무관한 결과가 나올 수도 있지만 말이죠.
Commented by sonnet at 2020/02/04 12:00
네. 비용에 대해선 분명히 이해하기 쉬운 지표긴 합니다.
Commented by Fedaykin at 2020/02/04 16:48
한국 sw 개발쪽 대기업에서도 맨먼스 이야기를 하길래 뜨악했는데, 대충 프로젝트 처음 시작할때 이거 얼마짜리야? 견적 낼때만 쓰고 그 다음에는 안나오더라구요. 결과야 어차피 야근이지만...
Commented by sonnet at 2020/02/09 19:08
많은 도구들이 그렇게 열화된 상태로 사용되죠.. 어차피 엉터리로 할 것이라면 시시껄렁한 규제가 없는 게 차라리 낫다고 생각하는 사람들도 많은 것 같습니다.
Commented by 암달 at 2020/02/05 21:28
암달의 법칙과 비슷하네요.

Commented by 암달 at 2020/02/05 21:39
거대한 오픈소스 프로젝트 (리눅스 등) 개발은 저런 문제를 어떻게 피해갈까요?
Commented by sonnet at 2020/02/06 13:08
아닌게 아니라 그 이야기도 할 생각이었습니다 ^^

:         :

:

비공개 덧글

<< 이전 다음 >>