맨위로가기

브룩스의 법칙

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

브룩스의 법칙은 프레더릭 브룩스가 제시한 경험 법칙으로, 지연되는 소프트웨어 프로젝트에 인력을 추가하는 것은 개발을 더 늦출 뿐이라고 주장한다. 이는 새로운 인력의 적응 기간, 의사소통 비용 증가, 작업 분할의 한계 등으로 인해 발생하며, 소프트웨어 개발과 같은 복잡한 작업에 적용될 수 있다. 브룩스의 법칙을 완화하기 위해 작업 분할 및 팀 구성, 점진적인 인력 투입 등의 해결책이 제시되며, 다른 분야에도 적용될 수 있다.

더 읽어볼만한 페이지

  • 소프트웨어 프로젝트 관리 - 소프트웨어 개발
    소프트웨어 개발은 요구사항 분석, 설계, 코딩, 테스트, 배포, 유지보수를 포함하는 컴퓨터 프로그램 및 관련 데이터를 만드는 과정으로, 다양한 방법론과 도구가 사용되며, 개발자 외에도 다양한 전문가들이 참여한다.
  • 소프트웨어 프로젝트 관리 - 애자일 소프트웨어 개발
    애자일 소프트웨어 개발은 1990년대에 등장하여 개인과 상호작용, 작동하는 소프트웨어, 고객과의 협력, 변화에 대한 대응을 핵심 가치로 삼고 적응형 계획과 반복적 실행을 통해 시장 출시 속도와 위험 완화를 추구하는 소프트웨어 개발 방법론이다.
  • 소프트웨어 공학 - 통합 개발 환경
    통합 개발 환경(IDE)은 코드 편집, 빌드, 디버깅 등 소프트웨어 개발에 필요한 여러 기능을 통합적으로 제공하는 응용 프로그램이다.
  • 소프트웨어 공학 - 소프트웨어 개발
    소프트웨어 개발은 요구사항 분석, 설계, 코딩, 테스트, 배포, 유지보수를 포함하는 컴퓨터 프로그램 및 관련 데이터를 만드는 과정으로, 다양한 방법론과 도구가 사용되며, 개발자 외에도 다양한 전문가들이 참여한다.
  • 사람 이름을 딴 낱말 - 뒤베르제의 법칙
    뒤베르제의 법칙은 선거제도와 정당 수 사이의 관계를 설명하는 가설로, 단순 다수 대표제는 양당제를, 결선투표제와 비례대표제는 다당제를 낳는다는 내용을 제시한다.
  • 사람 이름을 딴 낱말 - 옴의 법칙
    옴의 법칙은 1827년 게오르크 옴이 발표한, 전압(V)은 전류(I)와 저항(R)의 곱(V=IR)으로 표현되는, 전압, 전류, 저항 간의 관계를 나타내는 기본 법칙이다.
브룩스의 법칙
브룩스의 법칙
정의소프트웨어 개발 프로젝트에 인력을 추가 투입하면, 처음에는 개발 속도가 빨라지는 듯하지만 결국에는 지연이 더 심화되는 현상
원인새로운 인력의 교육 및 숙련에 필요한 시간
늘어난 의사소통 경로로 인한 관리의 복잡성 증가
작업 분할의 어려움과 비효율성
결과프로젝트 지연
품질 저하
비용 증가
해결 방안초기 계획 단계에서 충분한 시간과 인력 확보
숙련된 개발자 중심으로 팀 구성
효율적인 의사소통 및 협업 시스템 구축
변경 사항 최소화 및 요구사항 명확화
점진적인 개발 방법론 적용
자동화 도구 활용
관련 개념
신화 속 인물인월 (人月, Man-Month) - 프로젝트 규모 측정 단위의 비현실성
은총알특효약 (Silver Bullet) - 소프트웨어 개발의 어려움을 해결하는 만병통치약은 없음
관련 서적
저자프레더릭 브룩스
서적맨먼스 미신 (The Mythical Man-Month)
내용소프트웨어 공학 프로젝트 관리의 어려움과 현실적인 해결책 제시

2. 법칙의 내용 및 근거

브룩스의 법칙은 "지연되는 소프트웨어 프로젝트에 인력을 추가하는 것은 개발을 더 늦출 뿐이다"라는 경험 법칙이다. 이 법칙은 프레더릭 브룩스가 자신의 저서 《맨먼스 미신》에서 처음 제시했다.[1]

뛰어난 프로그래머와 일반적인 프로그래머 개인의 능력 차이가 크기 때문에, 고액의 임금을 받는 소수의 뛰어난 프로그래머를 이용하는 것이 평범한 능력을 가진 다수의 프로그래머를 고용하는 것보다 생산성이 높다는 오해가 있다. 그러나 브룩스 법칙은 극소수의 프로그래머만을 프로젝트에 투입하더라도 개발을 빨리 끝낼 수 있다고 말하는 것은 아니다.

브룩스는 이 법칙이 "터무니없는 과도한 단순화"이지만,[1] 일반적인 규칙을 잘 보여준다고 말한다.

2. 1. 법칙의 성립 근거

브룩스는 이 법칙이 "터무니없는 과도한 단순화"이지만,[1] 일반적인 규칙을 잘 보여준다고 말한다. 그는 이 법칙이 성립하는 주요 요인으로 다음 세 가지를 지적한다.

  • 새 인력의 적응 기간: 새로 투입된 개발자는 생산성을 내기까지 시간이 걸린다. (이를 램프 업 시간이라고 부른다.)
  • 의사소통 비용 증가: 팀원 수가 증가하면 조합 폭발로 인해 의사소통 채널이 급격히 증가한다.[3]
  • 작업 분할의 한계: 호텔 객실 청소와 같이 분할 가능한 작업도 있지만, 소프트웨어 개발은 그렇지 않은 경우가 많다. ("9명의 여성이 한 달 만에 아기를 낳을 수는 없다.")[1]

2. 1. 1. 새 인력의 적응 기간

새롭게 투입된 개발자가 생산성 향상에 기여하기까지는 시간이 걸린다. 브룩스는 이를 "램프 업" 시간이라고 부른다. 소프트웨어 프로젝트는 복잡한 공학적 노력이므로, 프로젝트에 새로 참여하는 사람은 업무를 시작하기 전에 개발 현황이나 설계의 세부 사항 등을 이해해야 한다. 즉, 새로운 인원을 추가하려면 그 인원을 교육하기 위해 자원을 할애해야 한다. 따라서 인원 증가가 팀의 생산성에 미치는 영향은 단기적으로는 마이너스가 된다. 또한 프로젝트에 익숙하지 않은 동안에는 실수를 하기 쉬우므로 새로운 버그가 삽입되는 경우가 많아, 그 결과 프로젝트가 더욱 늦어질 가능성도 있다.[1]

2. 1. 2. 의사소통 비용 증가

프로젝트 팀은 협력하여 문제를 해결해야 하지만, 팀원 수가 증가할수록 의사소통 채널이 기하급수적으로 늘어나 조정 비용이 증가한다.[3] 일반적으로 n명의 팀원은 n(n-1)개의 의사소통 채널을 필요로 하므로, 의사소통 비용은 팀원 수의 제곱에 비례하여 증가한다. 이는 팀원들이 서로의 작업 내용을 파악하고 동기화하는 데 더 많은 시간을 할애해야 함을 의미한다.

2. 1. 3. 작업 분할의 한계

브룩스는 호텔 객실 청소와 같이 분할 가능한 작업은 인력 투입으로 작업 시간을 단축할 수 있지만, 소프트웨어 개발과 같이 고도로 복잡하고 상호 의존적인 작업은 분할에 한계가 있다고 지적한다.[1] 즉, 아무리 많은 인력을 투입해도 특정 작업의 최소 소요 시간은 줄일 수 없다.

작업 분할의 한계는 다음과 같은 이유로 발생한다.

  • 작업 분해 가능성의 한계: 호텔 객실 청소처럼 분해 가능성이 높은 작업은 인원을 투입해 작업 전체 소요 시간을 단축할 수 있다. 그러나 분해 가능성이 낮은 작업도 있다. 브룩스는 "9명의 여성이 한 달 만에 아기를 낳을 수는 없다"는 예시를 통해 이를 설명한다.[1]

3. 오해

브룩스의 법칙에 대한 가장 흔한 오해는 뛰어난 프로그래머와 일반적인 프로그래머 개인의 능력이 차이가 많이 나기 때문에, 고액의 임금을 받는 매우 뛰어난 소수의 프로그래머를 이용하는 것이 평범한 능력을 가진 다수의 프로그래머를 고용하는 것보다 생산성이 높다는 것이다. 그러나 브룩스의 법칙이 적정선 이하의 극소수의 프로그래머만을 프로젝트에 투입하더라도 개발을 빨리 끝낼 수 있다고 말하는 것은 아니다.

4. 해결책

브룩스의 법칙에서 언급된 문제를 피하기 위한 몇 가지 방법이 있다.[4][5] 우선, 프로젝트를 작은 단위로 나누어 각 팀이 독립적으로 작업할 수 있도록 하고, 상위 팀이 전체 시스템을 통합하는 방식이 있다. 하지만 이 방법은 작업을 잘못 나누면 팀 간 소통 비용이 늘어나 문제가 더 커질 수 있다는 단점이 있다.

4. 1. 작업 분할 및 팀 구성

프로젝트 전체를 소규모 그룹이 맡을 수 있는 조각으로 나누고, 상급 팀이 시스템 통합을 맡는 방식이 효과적일 수 있다. 하지만, 작업을 부적절하게 분할하면 팀 간의 의사소통 비용이 증가하여 오히려 문제를 더 크게 만들 수 있다.[4][5]

훌륭한 세분화는 팀원 간의 의사소통 부담을 최소화하는 데 도움이 된다. 더 작은 하위 문제는 더 작은 팀이 해결하고, 상위 수준 팀은 시스템 통합을 담당한다. 이 방법이 효과가 있으려면 문제의 세분화가 처음부터 올바르게 수행되어야 한다. 잘못 수행하면 프로젝트 계획에서 실제로 밀접하게 연결된 문제의 일부를 작업하는 프로그래머 간의 의사 소통을 방해하여 문제를 더 악화시킬 수 있다.

세분화의 예로는 디자인 패턴이 있는데, 이는 전체 팀이 해당 패턴에서 제공하는 프레임워크 내에서 역할을 수행할 수 있기 때문이다. 디자인 패턴은 프로그래머가 따르는 규칙을 정의하고, 표준 언어 사용을 통해 의사소통을 단순화하며, 일관성과 확장성을 제공한다.

4. 2. 점진적인 인력 투입

브룩스의 법칙에는 예외를 허용하고 가능한 해결책을 제시하는 몇 가지 중요한 요점이 있다.[4][5]

브룩스의 법칙은 이미 지연된 프로젝트에만 적용된다.[6] 초기 단계에 인력을 투입하면 프로젝트를 다시 통제하거나 통제 상태로 유지할 수 있다.[7] 프로젝트가 실제로 지연되었는지, 아니면 원래 일정이 지나치게 낙관적이었는지를 파악하는 것이 중요하다. 일정 오류는 지연된 프로젝트의 많은 부분을 차지한다. 일정을 수정하는 것이 프로젝트 완료에 대한 의미 있고 신뢰할 수 있는 기간을 확보하는 가장 좋은 방법이다.[8]

프로젝트에 투입되는 인력의 양, 질 및 역할도 고려해야 한다. 지연된 프로젝트에 대한 이 법칙을 피하는 간단한 방법 중 하나는 필요한 것보다 더 많은 인력을 추가하여 추가 인력이 교육 및 의사 소통 부담을 상쇄하도록 하는 것이다.[9] 훌륭한 프로그래머나 전문가는 교육에 대한 부담을 줄여 추가할 수 있다.[10] 품질 보증 또는 문서화와 같이 프로젝트와 관련된 다른 작업을 수행하기 위해 인력을 추가할 수 있다. 작업이 명확하게 정의되어 있으면 적응 시간이 최소화된다.[11]

4. 3. 버뮤다 계획 (극단적인 해결책)

대부분의 개발자를 해고하고 ("버뮤다로 보냄") 나머지 개발자가 소프트웨어를 완료하도록 하는 극단적인 해결책인 '버뮤다 계획'이 제안되기도 했다.[12][13]

5. 다른 분야에의 적용

브룩스의 법칙은 달성하고자 하는 일의 속성에 따라 그 적용 가능성이 크게 달라진다.

작업의 성격에 따라 브룩스의 법칙의 적용 가능 여부가 달라진다. 예를 들어, 지연된 건설 계획에 덤프트럭을 추가 투입하는 경우에는 계획이 더 지연되지 않는다. 이는 작업의 성격상 최소한의 기술과 트럭만 있으면 누구든지 업무를 바로 처리할 수 있고, 트럭 운전사들끼리 논의하며 작업을 할 필요도 적기 때문이다.

반면, 소프트웨어 개발과 같은 디자인 작업에서는 새롭게 투입된 인원이 프로젝트에 대한 기본적인 방향, 방법, 이미 진행된 작업에 대한 교육을 받아야 프로젝트에 도움이 될 수 있다.

5. 1. 적용 가능한 경우

덤프트럭 추가 투입과 같이, 작업이 단순하고 분할 가능하며, 작업자 간 의사소통이 적게 필요한 경우에는 인력 투입이 효과적일 수 있다. 예를 들어 늦어진 건설 계획에서 덤프트럭을 더 투입한다고 해서 부가적으로 계획이 지체되거나 하지 않는다. 이는 일의 속성상 누구나 최소한의 기술과 트럭만 갖고 있다면 업무를 바로 처리할 수 있고, 트럭 운전사들끼리 의논을 해 가며 일을 할 필요 또한 적기 때문이다.[1]

5. 2. 적용이 어려운 경우

소프트웨어 개발과 같은 디자인 작업에서는, 새롭게 투입된 인원은 프로젝트에 대한 기본적인 방향이나 방법, 이미 진행 중인 작업에 대한 교육이 이루어져야 비로소 프로젝트에 기여할 수 있다.[1] 이러한 작업은 복잡하고 상호 의존적이기 때문에, 새 인력 투입 시 교육 및 적응 기간이 필요하고 의사소통 비용이 커서 브룩스의 법칙이 적용될 가능성이 높다.

참조

[1] 서적 The Mythical Man-Month Addison-Wesley
[2] 뉴스 Better use the phone: Why Obamacare website is such a fail https://www.nbcnews.[...] NBC News 2013-10-21
[3] 서적 A Survival Guide for Project Managers AMACOM 2015-06-00 #날짜가 명확하지 않아 00으로 처리
[4] 논문
[5] 논문
[6] 논문
[7] 논문
[8] 논문
[9] 논문
[10] 논문
[11] 논문
[12] 학술지 Developers Unveil 'Vaporware' https://books.google[...] InfoWorld Media Group 1984-05-07
[13] 웹사이트 Curly Braces #9: Was Fred Brooks wrong about late software projects? https://blogs.oracle[...] Oracle Corporation 2023-02-06
[14] 서적 人月の神話 狼人間を撃つ銀の弾はない（新装版） 丸善出版


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com