[도서 리뷰] 맨먼스 미신 후기

개발자와 일하는 기획자로서 개발자의 의식흐름이나 생각하는 방식을 알고싶어졌다.

그들의 고전 바이블이라고 불리는 맨먼스 미신을 읽기로 했다. 

맨먼스 미신 국내도서 저자 : 프레더릭 브룩스(Frederick P. Brooks Jr.) / 강중빈역 출판 : 인사이트 2015.03.23 상세보기

 

맨먼스 미신은 아래의 프레드 브룩스라는 1931년생 미국의 개발자가 저술한 책으로

1) 은탄환은 없다 2) 브룩스 법칙 요 2가지로 유명하다.

1) 은탄환은 없다

소프트웨어 개발의 복잡성을 일거에 해소할 마법(은탄환)같은 방법은 없다는게 요지다

ㅠㅠ그래서 IT서비스 개발과 관련해 2020년에도 비슷한 고통을 받고있다는...

 

다만

브룩스 할아버님은 개발 복잡성 해소안을

본질적 복잡성과 우발적 복잡성으로 나누어 제안해주신다. 

 

1-1 본질적 복잡성 해소방안

• 소프트웨어제품 시장 활용 :구입 가능한 것은 굳이 만들지 않도록 큰 시장 이용

• 세련된 기법으로 요구명세서 작성 + 조기 프로토타입 활용

• 점증적 개발

• 사용, 테스트 + 기능 추가하면서 유기적(계통적) 성장

• 위대한 디자이너 육성

• 젊은 세대의 멋진 컨셉 디자이너 발굴·육성

1-2 우발적 복잡성 해소방안

• 고수준 프로그래밍 언어 사용

• 객체지향 프로그래밍 (클래스, 캡슐화, 상속)

• 비주얼 프로그래밍

• 시분할 시스템

• 통일된 프로그래밍 환경 (통합된 라이브러리, 파일포맷 등)

• 인공지능, 전문가시스템

• 프로그램 검증 기법

 

2) 브룩스 법칙

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

 

이유 : 업무 재분배 자체로 인한 작업과 혼란/ 새 인원에 대한 훈련이 필요/ 더 늘어난 의사소통

 

 

---

18장에는 친절하게 전체 책을 요약해주셨는데 기억해두고 싶은 구절을 다시 보기위해 적어둔다.

 

1.3 소프트웨어 개발이 가지는 고달픔에는 이런것이 있다.

     - 완벽함을 요구하는 상황에 적응하는 일 (컴퓨터는 미완을 허용x)

     - 프로젝트 막바지에 가까울수록 마무리에 속도가 붙으리라는 기대와 다르게 현실을 점점 더 느려진다.

     - 제품이 완성되기도 전에 한물간 것이 되어버릴 위험이 항상 존재한다. 

       하지만 마땅한 이유가 있지 않은 이상 진짜 호랑이(세상에 나온 s/w제품)으로

       종이 호랑이(나오지못한 s/w 아이디어)를 상대할 필요는 없다. 

 

2.6 맨먼스는 사람과 일정이 서로 교환이 가능하다는 인식을 깔고 있기에 그릇되고 위험한 미신이다.

 

2.8 경험에 의한 내 나름의 법칙은 전체 일정의 1/3을 설계에, 1/6을 코딩에,

    1/4를 구성요소 테스트, 1/4를 시스템 테스트에 배정하는 것이다.  (결국 절반은 테스트에 할애)

 

2.11 브룩스의 법칙

 

3~6장 요약하자면, 

시스템 설계에서 개념적 일관성이 가장 중요한데 이는 어쩔 수 없이 소수의 담당자에 의해 이루어 질 수 밖에 없다. 

또한 이 일관성은 누군가가 그 개념을 통제해야만 하며 이를 문서화로 할 때는 더더욱 소수가 작업해야 일관성을 유지할 수 있다. 

 

> 7장 10장은 기록물을 통한 의사소통 효율화가 주제다.

 

7.4 프로젝트 워크북이란 "또다른 별개의 문서라기 보다는 프로젝트를 진행하면서

     어차피 생산될 문서들로 구성한 하나의 체계"이다. 이는 초반에 주의 깊게 설계할 필요가 있다.

 

7.7 문서화 작업을 초반부터 적절히 구조화해두면 "차후에 작성될 문건들이 그 구조속에 들어맞는 조각으로 자리잡을"

    수 있으며 제품 매뉴얼 품질도 향상될 것이다. 

 

7.8 모든 팀 구성원이 모든 워크북 자료를 보아야 한다. 

 

7.17 조직에서 의사소통을 줄이기 위한 방법은 '분업'과 '전문화' 이다.

 

10.1 온갖 서류의 홍수 속에서도 몇몇 문서는 점차 모든 프로젝트관리 업무가

      그것을 중심으로 돌아가는 핵심적인 축이 된다. 

 

10.4 sw 프로젝트에 필요한 문서는 목표/사용자 매뉴얼/내부 문서화/일정/예산/조직도/ 공간 할당 등이다.

      

10.5 프로젝트 규모가 작더라도 관리자는 처음부터 이런 일련의 문서를 공식화해두어야한다. 

      문서 하나하나를 준비하면서 생각의 초점이 모이고 논의가 명확해진다. 

      글로 적는 행위는 수백가지의 작은 의사결정이 필요하며

      분명하고 정확한 정책이 모호한 정책과 구분되는 부분은 이러한 의사 결정의 존재 여부에서다. 

 

10.8 각 문서는 체크리스트와 데이터 베이스 역할을 한다. 

 

10.9 프로젝트 관리자의 기본 업무는 모든 사람이 같은 방향으로 계속 가도록 하는 것이며

     주된 일과는 의사 결정이 아니라 의사 소통에 있다. 문서들은 계획과 결정 사항을 전체 팀에 알리는 역할을 한다. 

 

11.9 sw 제품은 끝없는 변경/변화에 노출된며 이러한 변경을 피할 수 없고 

      일어나지 않기를 바라지보다는 사전에 대비를 해두는 편이 낫다. 

 

11.13 변경 사항은 잘 정의된 버전 번호를 가지고 일정한 묶음으로 처리하라

 

11.21 널리 쓰이는 프로그램의 유지보수 비용은 통상 그 개발비용의 40% 또는 그 이상이다. 

 

11.25 매번 수정 후에는 시스템이 알수 없는 방식으로 손상되지 않았음을 보장하기 위해

        이전에 수정된 테스트 케이스 전체를 다시 수행해야 한다. 

 

13.2  비소츠키 "수없이 많은 실패가 제대로 정의하지 않음에서 비롯됩니다"

 

14.2 매일매일 조금씩 일어나는 일정 지연은 큰 재난보다 더 알아차리기 어렵고

      예방도 어려우며 만회하기도 더 힘들다.

 

14.4 마일스톤은 구체적이고 명확하고 측정가능한 이벤트여야 하며, 날이 선듯이 분명하게 정의되어야 한다. 

 

14.13 일정이 지연될 때 보스는 2가지 종류의 정보가 필요하다.

        계획에 차질을 가져와서 조치가 필요한 문제들,

        상황파악과 조기 경고를 위한 프로젝트 전체의 모습이 그것이다. 

 

15.5 많은 문서는 전체적인 개관을 제시하는데 인색하다. 뒤로 한 발 물러난 다음 찬찬히 들여다보라

 

15.14 프로그램을 수정할 사람들이 참조할 문서에는 '어떻게'에 대한 내용 뿐만 아니라

        '왜' 그렇게 되었는지도 포함되어야 한다. '목적'은 이해를 위한 열쇠이다.

         고급 언어의 문법 조차도 목적에 대한 것은 전혀 전달해주지 않는다.  

 

---