<div id="readability-page-1" class="page"><div>
    
    <article>
        <ul id="markdown-toc">
  <li><a href="#개요" id="markdown-toc-개요">개요</a></li>
  <li><a href="#맨먼스-미신-내용-요약" id="markdown-toc-맨먼스-미신-내용-요약">맨먼스 미신 내용 요약</a>    <ul>
      <li><a href="#소프트웨어-프로젝트가-망가지는-주요-원인은-시간이-부족한-탓이다" id="markdown-toc-소프트웨어-프로젝트가-망가지는-주요-원인은-시간이-부족한-탓이다">소프트웨어 프로젝트가 망가지는 주요 원인은 시간이 부족한 탓이다.</a></li>
      <li><a href="#프레드-브룩스의-성공적인-일정-수립-방법" id="markdown-toc-프레드-브룩스의-성공적인-일정-수립-방법">프레드 브룩스의 성공적인 일정 수립 방법</a></li>
      <li><a href="#일정-붕괴의-악순환" id="markdown-toc-일정-붕괴의-악순환">일정 붕괴의 악순환</a></li>
    </ul>
  </li>
  <li><a href="#함께-읽기" id="markdown-toc-함께-읽기">함께 읽기</a>    <ul>
      <li><a href="#from-해커-영어사전" id="markdown-toc-from-해커-영어사전">From: 해커 영어사전</a></li>
    </ul>
  </li>
  <li><a href="#links" id="markdown-toc-links">Links</a></li>
  <li><a href="#참고문헌" id="markdown-toc-참고문헌">참고문헌</a></li>
  <li><a href="#주석" id="markdown-toc-주석">주석</a></li>
</ul>

<h2 id="개요">개요</h2>

<blockquote>
  <p>Brooks's law : "adding human resources to a late software project makes it later"</p>
</blockquote>

<blockquote>
  <p>브룩스의 법칙 : "늦어진 소프트웨어 프로젝트에 인력을 추가로 투입하면 더 늦어지게 된다"</p>
</blockquote>

<p>프레드 브룩스(Frederick P. Brooks Jr.)가 자신의 책 [[/book/mythical-man-month]] 2장 '맨먼스 미신'에서 제시한 법칙이다.</p>

<ul>
  <li>프레드 브룩스는
    <ul>
      <li><a href="https://amturing.acm.org/award_winners/brooks_1002187.cfm">1999년 튜링상 수상자</a>.</li>
      <li><a href="http://cs.unc.edu/people/frederick-p-brooks-jr/">노스 캐롤라이나 대학 컴퓨터 과학과의 설립자</a>.</li>
    </ul>
  </li>
</ul>

<h2 id="맨먼스-미신-내용-요약">맨먼스 미신 내용 요약</h2>

<h3 id="소프트웨어-프로젝트가-망가지는-주요-원인은-시간이-부족한-탓이다">소프트웨어 프로젝트가 망가지는 주요 원인은 시간이 부족한 탓이다.</h3>

<ul>
  <li>시간이 부족한 원인은 다음과 같다.
    <ul>
      <li>추정을 할 때 투입 공수와 작업 진척도를 혼동한다.</li>
      <li>일정 진척도가 제대로 모니터링되지 않는 것도 문제.</li>
      <li><strong>일정이 어긋났을 때 인력을 추가로 투입한다.</strong></li>
    </ul>
  </li>
</ul>

<p>너무 긍정적으로 일정을 짠다.</p>

<ul>
  <li>작업이 한 가지 뿐이라면 낙관주의적으로 일정을 산출해도 된다.</li>
  <li>그러나 대형 프로그래밍 프로젝트는 수많은 작업으로 이루어진다.
    <ul>
      <li>각각의 모든 작업이 모두 예정대로 진행될 확률은 매우 낮다.</li>
    </ul>
  </li>
</ul>

<p>맨먼스(Man-Month) 단위를 사용해 일정을 추정하는 것은 잘못된 사고방식이다.</p>

<ul>
  <li>맨몬스는 프로젝트 비용의 관점에서만 의미가 있는 단위이다.</li>
  <li>맨몬스는 사람과 일정이 서로 교환 가능하다는 인식이 깔려 있다.
    <ul>
      <li>사람과 일정이 서로 교환 가능한 경우는 다음과 같다.
        <ul>
          <li>순서를 고려하지 않고 여러 사람에게 나눠줄 수 있는 일.</li>
          <li>작업자들 간에 의사소통이 필요없는 일.</li>
          <li>즉, 프로그래밍에서는 이 관점이 해당되지 않는다.</li>
        </ul>
      </li>
    </ul>
  </li>
  <li>순서가 정해져 있는 작업이라면, 작업자를 더 쏟아부어도 일정을 앞당기는 것은 불가능하다.
    <ul>
      <li>예: 임산부가 9명이라고 해서 1달 만에 아기가 태어나는 것은 아니다.</li>
      <li>소프트웨어 개발 작업은 각 단계별로 순차적으로 진행된다. (개발 - 디버깅 - 테스트…)</li>
      <li>커뮤니케이션도 전체 일정에 포함시켜야 한다.</li>
    </ul>
  </li>
</ul>

<h3 id="프레드-브룩스의-성공적인-일정-수립-방법">프레드 브룩스의 성공적인 일정 수립 방법</h3>

<ul>
  <li>계획 수립: \({1 \over 3}\)</li>
  <li>코딩: \({1 \over 6}\)</li>
  <li>구성 요소 테스트와 초기 시스템 테스트: \({1 \over 4}\)</li>
  <li>모든 구성 요소가 준비된 후의 시스템 테스트: \({1 \over 4}\)</li>
</ul>

<p>\({1 \over 4} + {1 \over 4} = {1 \over 2}\) 이니까, 테스트가 절반이나 된다.</p>

<blockquote>
  <div><p>일반적인 방법으로 일정을 관리했던 프로젝트들을 살펴보다가 발견한 사실은,
일정의 절반을 테스트에 배정한 경우는 거의 없었지만
대부분 나중에는 그만큼의 시간을 결국 테스트에 썼다는 것이다.
그런 프로젝트들이라 해도 상당수가 시스템 테스트 전까지는 원래 일정대로 진행되고 있었다.
</p><p>
특히 시스템 테스트에 충분한 시간을 배정하지 않는 것은 아주 참담한 결과를 초래한다.
일정 지연은 프로젝트 말미에 발생하기 때문에,
납품일이 코앞에 닥칠 때까지 어느 누구 하나 일정에 문제가 있다는 것을 알아차리지 못한다.</p></div>
</blockquote>

<p>추정은 소심하게 하고, 관리자들은 고객들의 일정 축소 요구로부터 스스로의 일정 추정을 지켜야 한다.</p>

<h3 id="일정-붕괴의-악순환">일정 붕괴의 악순환</h3>

<p>\(n\) 명이 수행중인 프로젝트 막바지에 새로 \(m\) 명의 인력이 투입되었다.</p>

<ul>
  <li>실력이 아무리 뛰어나도, 기존 멤버로부터 프로젝트에 대한 훈련을 받아야 한다.</li>
  <li>규모가 커지므로, 조직 구성이나 업무 분배에 있어서 본질적인 차이가 발생한다.</li>
  <li>원래 \(n\) 으로 분할했던 작업을 \(n + m\) 으로 나눠야 한다.
    <ul>
      <li>이미 진행된 작업 중 일부가 날아간다.</li>
      <li>시스템 테스트 시간도 더 미뤄지고 늘어난다.</li>
    </ul>
  </li>
</ul>

<blockquote>

  <p>지금까지의 내용을 극도로 단순화하면, 다음과 같은 브룩스의 법칙을 제시할 수 있을 것이다.<br>
"늦어진 소프트웨어 프로젝트에 인력을 추가로 투입하면 더 늦어지게 된다."<br>
이렇게 해서 우리는 맨먼스에 관련된 미신을 걷어낼 수 있다.
프로젝트에 소요되는 기간은 순서대로 처리해야 하는 내부 요소에 좌우되며, 필요한 최대 인원수는 독립된 하위 작업의 개수에 좌우된다.</p>
</blockquote>

<h2 id="함께-읽기">함께 읽기</h2>

<h3 id="from-해커-영어사전">From: 해커 영어사전</h3>

<blockquote>

  <p>“Adding manpower to a late software project makes it later” — a result of the fact that the expected advantage from splitting development work among N programmers is O(N) (that is, proportional to N), but the complexity and communications cost associated with coordinating and then merging their work is O(N^2) (that is, proportional to the square of N).
The quote is from Fred Brooks, a manager of IBM's OS/360 project and author of The Mythical Man-Month (Addison-Wesley, 1975, ISBN 0-201-00650-2), an excellent early book on software engineering.
The myth in question has been most tersely expressed as “Programmer time is fungible” and Brooks established conclusively that it is not.
Hackers have never forgotten his advice (though it's not the whole story; see bazaar); too often, management still does. See also creationism, second-system effect, optimism.</p>
</blockquote>

<p>"늦어지는 소프트웨어 프로젝트에 인력을 추가하면 프로젝트가 늦어진다"는 말은,
프로그래머 N명이 개발 작업을 분할할 때 예상하는 이점은 \(O(N)\) (즉, N에 비례)이지만,
이들의 작업을 조율하고 통합하는 데 드는 복잡성과 커뮤니케이션 비용은 \(O(N^2)\)(즉, N의 제곱에 비례)라는 사실에서 유래합니다.</p>

<p>이 인용문은 IBM의 OS/360 프로젝트 매니저이자 소프트웨어 엔지니어링에 관한 훌륭한 초기 저작인 '맨먼스 미신'의 저자인 프레드 브룩스(Fred Brooks)의 것입니다.
문제의 미신은 "프로그래머의 시간은 대체 가능하다"는 말로 굉장히 간단하게 표현되어 왔지만, 브룩스는 그것이 사실이 아니라는 것을 확실하게 입증했습니다.
해커들은 그의 조언을 결코 잊은 적이 없습니다. 그러나 경영진은 여전히 너무 자주 잊어버립니다.
<sup id="fnref:dict-149" role="doc-noteref"><a href="#fn:dict-149" rel="footnote">1</a></sup></p>

<h2 id="links">Links</h2>

<ul>
  <li>[[/book/mythical-man-month]]</li>
  <li><a href="https://en.wikipedia.org/wiki/Brooks%27s_law#cite_note-BROOKS-1">Brooks's law(wikipedia)</a></li>
  <li><a href="https://amturing.acm.org/award_winners/brooks_1002187.cfm">1999년 튜링상 수상</a>.</li>
</ul>

<h2 id="참고문헌">참고문헌</h2>

<ul>
  <li>해커 영어사전 제3판 / ERIC S.RAYMOND 편 / 기전연구사 / 1998년 12월 25일 제1판 제1발행 / 원제: The New Hacker's Dictionary
    <ul>
      <li><a href="http://www.catb.org/jargon/html/B/Brookss-Law.html">Brooks's Law (catb.org)</a></li>
    </ul>
  </li>
</ul>

<h2 id="주석">주석</h2>



    </article>


    
    
    



</div></div>

기계인간 John Grib

JohnGrib

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

브룩스의 법칙

댓글