1975년에 출판된 이 고전에는 지금도 유효한 여러 교훈들이 나온다. 개발자가 겪는 어려움의 원인을 개념적으로 잘 설명하고 있으므로 필독서라고 생각한다.
이하는 인용 모음이다.
맨먼스 미신
Author : 프레더릭브룩스
Format : 412 pages, book
ISBN : 9788995982204
프로그램을 작성하는 것은 시를 짓는 것처럼 거의 순수에 가까운 사고 영역에서 작업하는 것이다. 프로그래머는 아무 것도 없는 허공에, 허공으로부터 상상력을 동원하여 성을 쌓는다. 이렇게 유연하며, 가다듬고 고치기 쉽고, 커다란 개념 구상을 쉽게 실현할 수 있는 창조 매체는 찾아보기 힘들다.(나중에 알게 되겠지만, 이처럼 아주 쉽게 다룰 수 있다는 점이 오히려 문제가 된다)
하지만 프로그램 구문은 시어와 달리 움직이고 작동하며, 구문 자체와 별도로 가시적인 출력을 만들어낸다는 점에서 실재적이다. 프로그램 구문은 결과를 인쇄하고, 그림을 그리며, 소리를 만들어내고, 심지어 군대까지 움직인다. 신화와 전설 속에만 있던 마법이 이제 우리 시대에 현실로 등장했다. 키보드에 정확히 주문을 입력하면 표시화면이 살아나면서 여태껏 존재하지도 존재할 수도 없었던 것을 보여 준다.
P.25 ~ 26
두 번째로 잘못된 사고방식은 바로 견적과 일정에 사용되는 노력의 단위, 즉 맨먼스(Man-Month)로 표현된다. … 그것은 인력과 기간은 상호 교환이 가능하다는 의미를 내포한다. … 밀을 수확하거나 목화를 따는 일일 경우, 인력과 기간의 상호 교환이 가능하다. … 순차적 제한 때문에 분할이 불가능한 업무일 경우, 노동력을 더 투입하더라도 일정을 단축하는 효과가 전혀 없다. 몇 명의 여성이 임신하든 사람의 임신 기간은 9개월이다.
P.36 ~ 37
[프로젝트 중간에] 인력을 더 많이 투입하고 일정을 짧게 잡는 일정 계획은 결코 성공할 수 없다. 일정이 모자라서 실패한 소프트웨어 프로젝트는 다른 이유로 실패한 소프트웨어 프로젝트 수를 다 합친 것보다 더 많다.
P.48
저자는 개념적 무결성이 시스템 설계에서 가장 중요하다고 감히 주장한다. 좋은 기능이긴 하지만 서로 독립적이고 조화되지 못한 아이디어들을 담고 있는 시스템보다는 여러가지 다양한 기능이나 갱신된 내용은 비록 빠졌더라도 하나로 통합된 일련의 설계 아이디어를 반영하는 시스템이 훨씬 좋다.
P.65 ~ 66
구축 담당자의 아키텍쳐 수정 요구는 결국 설계자에 대한 반론이라는 의미를 갖는 경우가 많다. 그리고 그의 주장이 옳을 때가 많다. 대수롭지 않은 기능이지만 구현하려면 예상치 못하게 큰 비용이 드는 수가 많다.
P.80
컴퓨터 업계 모임에 가보면, 젊은 프로그래밍 관리자들이 자신들은 “프로그래머 수백 명(이들이 평범한 능력을 갖췄다는 점을 넌지시 암시하면서)이 동원된 프로젝트보다는 1등급 능력을 지닌 사람들로 빈틈없이 구성된 소규모 팀을 선호한다”라고 단정적으로 얘기하는 것을 끊임없이 듣게 된다. 사실 우리 모두 그런 식으로 얘기한다.
하지만 둘 가운데 하나라는 식의 이런 순진한 발상은 진짜 어려운 문제를 회피하고 있다.
P.51
영국 맨체스터(서북부)에 있는 컴퓨터 장비 회사 ICL의 소프트웨어 부서 관리자인 찰스 포스트만은 또 하나의 유용한 개인적 견해를 제안한다.
그는 자신의 프로그래밍 팀이 절반 정도로 일정에 맞추지 못하는 것을 발견했는데, 각 작업은 개산치[추정치]의 약 2배 정도의 시간이 걸리고 있었다. 개산은 경험 많은 팀에 의해서 프로그램 평가 검토 기법(PERT) 표에 따라 수백 개의 하부 작업에 대한 노동력, 즉 소요 시간을 예측하여 매우 신중하게 이뤄진 것이다. 그런데 여기에서 물이 새는 것과 같은 빈 틈이 발견되자, 그는 시간 사용에 대한 일간 기록을 조심스럽게 작성하라고 지시했다. 이렇게 함으로써 그의 팀이 일하는 시간의 50%만 실제 프로그래밍 작업과 디버깅 작업시간으로 쓰였다는 사실응 발견할 수 있었다. 개산 오류는 바로 이런 점을 간과한 데서 발생한 것이었다. 나머지 시간은 머신이 작동을 멈춘 시간, 우선순위가 더 높지만 작업과는 관계없는 업무들, 회의, 문서 작업, 회사 일, 병, 개인 시간 등에 쓰였다. 간단히 말해, 개산하면서 기술적인 작업 시간/맨이어(man-year, 한 사람이 1년 동안 할 수 있는 작업량을 단위로 표현함 것 – 옮긴이)의 숫자를 비현실적으로 가정했던 것이다. 저자 자신의 경험도 그의 결론과 일치한다.
P.125 ~ 126
바데인의 연구(미출간)에 따르면 프로그래머의 생산시간 중 27%만 실제 프로그래밍에 사용된다. (메이어와 스톨네이커가 “컴퓨터 직원의 선발과 평가”에서 바데인의 연구를 인용)
P.126
장인정신 저 너머에는 번득이는 발명이 있다. 그리고 알차고 군더더기가 없으며 빠른 프로그램은 바로 이 지점에서 탄생한다. 이런 것은 거의 전부 전술적 현명함보다는 전략적 발명의 결과다.
P.141
[소프트웨어 프로젝트 관리용 문서와 대학 학장의 학과 관리용 문서는 굉장히 비슷하다.] 우연히 비슷한 것이 아니다. 모든 관리 작업은 무엇을, 언제, 얼마나, 어디서, 누가 수행할 것인가 하는 문제와 관련되어 있다.
P.149
모든 시스템의 구조는 그 시스템을 설계하는 조직의 커뮤니케이션 구조와 똑같을 수밖에 없다
P.150
모든 대형 시스템 개발을 통해서 보면, 설계 변경은 항상 발생하는 필연적인 현상이라고 봐야 한다.
P.155
널리 쓰이는 프로그램의 경우, 유지 관리 총 비용은 대개 개발비용의 40% 또는 그 이상에 이른다.
P.162
모든 [프로그램] 수리 작업은 전체 시스템의 구조를 망가뜨려 시스템의 무질서와 혼란 상태를 가중시킨다. 원래 설계 결함을 고치는 데는 점점 더 노력을 기울일 수 없게 되고, 시간이 갈수록 시스템의 상태는 더욱 나빠진다. 그리고 조만간 고장 수리 작업은 기준을 잃게 된다. 한 발짝 앞으로 갈 때마다 한 발작 뒤로 가게 된다.
P.165
20년 전 저자가 701 작업을 할 때, 머신 관리자들은 모두 집에서 깊이 잠들어 있고, 오퍼레이터들은 잔소리가 적어졌던 새벽쯤에 생산성이 가장 좋아져 그 비공식적인 시간에 일하는 버릇이 생겼다. 이제 컴퓨터 3세대가 지났다. 기술은 완전히 변했다. 운영체계의 중요성이 커졌다. 그러나 아직도 이런 작업 취향은 변하지 않았다. 그런 버릇이 지속되는 것은 그것이 가장 생산적이기 때문이다. 그것의 생산성이 높고 좋은 결실을 맺는다는 것을 인정하고 공개적으로 받아들일 때가 되었다고 본다.
P.174
“제품을 정의하는 것이 가장 중요한 일이다. 수많은 실패 원인은 바로 명세화하지 않는 부분들 때문에 생긴다.” 기능 정의와 명세를 신중하게 만들고, 허식적인 기능과 쓸데없는 기술 자랑을 제거하는 것, 이 모두가 시스템 버그의 수를 줄인다. 시스템 버그는 반드시 전부 찾아내야 한다.
P.187 ~ 188
어떤 프로젝트에 일정이 지체되어 대재난이 빚어졌다는 소식을 전해 들었을 때 우리는 뭔가 큰 사고가 발생한 것으로 생각하기 쉽다. 하지만 원인이 된 재난은 태풍이 아니라 흰개미일 경우가 보통이다. 그리고 일정은 조금씩이지만 돌이킬 수 없개 늦어져 버린다. 사실 큰 재해는 다루기가 한결 쉽다. 대대적인 추진력, 근본 문제에 대한 인식, 새로운 접근방법 등으로 대처하면 된다. 팀 전체가 나서서 문제에 맞서나가면 되는 것이다.
하지만 매일 조금씩 늦어지는 것은 지각하기도 어렵고, 사전 방지하기도 그리고 만회하기도 어렵다. 어제는 핵심 인물이 아파서 회의가 취소되었고, 오늘은 번개가 건물 변압기를 때려서 머신들이 모두 작동 불능이다. 그리고 내일은 공장에서 첫 번째 디스크가 일주일 늦어져 디스크 루틴이 작동하지 않아 테스트를 못하게 된다. 이밖에도 눈이 많이 내려서, 법원에 배심원으로 참석할 수밖에 없어서, 가족에 문제가 생겨서, 고객과 긴급한 면담 일정이 잡혀서, 고위급 감사가 실시되어서 등등 하루하루 발생하는 자잘한 문제점들을 나열하자면 끝이 없다. 이런 사건들 하나하나로 본다면 프로젝트 활동을 겨우 반나절씩이나 하루씩 늦출 뿐이다. 하지만 이런 식으로 일이 한 번 생길 때마다 일정이 하루씩 예정에서 빗나간다.
P.205
[역할 충돌 줄이기] 상사는 먼저 자신이 행동을 취해야 할 정보와 상황 파악만 하고 있어도 될 정보를 구별해야 한다. 관리자가 해결할 수 있는 문제에 대해서는 행동하지 않도록 조심해야 된다. 그리고 관리자가 상황을 검토하고 있는 것이 확실할 때는 절대로 그 문제에 대해 행동을 취하지 말아야 한다. 예전에 저자가 알았던 어떤 상사는 언제나 상황 보고서의 첫 문장을 마치기도 전에 전화를 걸어 명령을 내리곤 했다. 그렇게 반응하면 모든 것이 공개될 가능성이 확실히 막혀 버린다.
반대로, 관리자 생각에 자신의 상사가 상황 보고서를 받고서는 당황하지도 자기 혼자만 알고 처박아 두지도 않을 것이라고 판단되면 관리자는 정직한 상황 평가 보고서를 들고 올 것이다.
보스가 상황 검토(status-review) 회의, 문제 조처(problem-action) 회의 같은 방식으로 모든 모임, 검토, 회의 등을 구분하고, 그에 따라 자기 스스로를 통제하면 이런 전체 과정에 도움이 된다. 물론 상황 회의 결과, 어떤 문제가 걷잡을 수 없는 상태라고 판단되면 문제 조처 회의를 소집할 수 있다. 하지만 그런 회의가 소집되더라도 적어도 모든 사람이 현재 점수를 알고 있고, 상사 역시 공을 잡기 전에 두 번은 생각하게 된다.
P.210 ~ 211
명확한 이정표들은 팀에 대한 좋은 서비스며, 팀원들은 관리자가 이정표를 명확하게 만들어 주리라고 당연히 기대한다. 불분명한 이정표를 갖고 작업하는 것은 매우 큰 부담이다. 이정표가 분명하지 않으면 나중에 시간이 모자란 것을 알게 될 때까지는 속고 있다가 사실을 인식하게 되면서 사기만 떨어진다. 그리고 일정이 예정에 엇나가는 일이 만성적으로 벌어지면 사기를 크게 떨어뜨린다.
P.207
매우 상세한 흐름도[순서도]는 초보자가 알고리듬적인 사고를 배우는 데나 적절할 뿐, 진부하고 귀찮기만 하다.
P.222
기술에서든 관리기법에서든 어떤 한 가지 발전이 그 자체만으로 10년 내에 생산성, 신뢰성, 단순성을 단 열 배라도 향상시켜줄 것 같아 보이는 것은 없다.
P.233
지금껏 소프트웨어 생산성 부문에서 이룩한 큰 업적 대부분은 인위적인 장애들, 즉 심한 하드웨어 제약, 불편한 프로그래밍 언어, 부족한 컴퓨터 사용시간 등과 같이 비본질적인 작업들을 매우 어렵게 하는 장애들을 제거함으로써 달성되었다.
P.235
소프트웨어 본체의 본질은 데이터 집합, 데이터 아이템들의 상호 관계, 알고리듬, 기능 호출 등 서로 맞물려 돌아가는 개념들의 구성이다. 개념들의 구성이 서로 다른 여러 표현에서도 동일하다는 점에서 이 본질은 추상적이다. 그럼에도 불구하고 이 본질은 매우 정밀하고 자세하다.
저자는 소프트웨어 구축에서 어려운 부분은 이 개념적 구성의 명세와 설계 그리고 시험이지, 그것을 표현고 그 표현의 충실도를 시험하는 노동이 어려운 것은 아니라고 믿는다. 우리는 아직도 구문 오류를 유발하고 있지만, 이런 오류는 대다수 시스템에서 나타나는 개념적인 오류에 비하면 솜털에 지나지 않는다.
만약 이것이 사실이라면, 소프트웨어 구축은 언제나 어려운 작업일 것이다. 본질적으로 은 총알은 없는 것이다.
오늘날의 소프트웨어 시스템들에서 도저히 줄일 수 없는 이 본질에 내재한 속성들, 즉 복잡성, 순응성, 변경 가능성, 비가시성 등을 하나씩 따져 보도록 하자.
P.238 ~ 239
소프트웨어 본체를 확대하는 것은 동일한 요소들을 단순히 크기만 키우는 것이
아니다. 즉, 반드시 요소들의 가짓수를 늘려야 한다. 대다수 경우, 요소들은 다른 요소들과 비선형적으로 상호작용하고, 그렇게 모인 전체의 복잡성은 요소 가짓수에 선형적으로 비례하기보다는 훨씬 가파르게 증가한다.
소프트웨어의 복잡성은 본질적인 속성이지, 부차적인 속성이 아니다.
P.239
소프트웨어 엔지니어 … 가 반드시 숙달해야 할 복잡성의 상당 부분은 제멋대로인, 즉 인터페이스를 만들 때 반드시 순응해야 하는 숱한 인간 조직들과 체계들에 의해 아무런 운율이나 조리도 없이 강제되는 복잡성이다. 게다가 필연 때문이 아니라, 단지 신이 아니라 다른 사람이 설계했다는 바로 그 이유 때문에 인터페이스 하나하나마다, 시시각각으로 달라진다.
P.241
변경 가능성 ㅡ 소프트웨어 본체는 지속적으로 변경 압박을 받는다. 물론 건축물, 자동차, 컴퓨터 등도 마찬가지다. 하지만 대량 생산된 것들은 일단 제작되고 나면 그렇게 자주 변경되지 않는다. 아예 후속 모델로 대체되거나, 아미면 동일한 기초 설계를 바탕으로 만든 모사 제품을 후속 일련번호를 달아 출시할 때 본질적인 변경을 반영한다. 이미 판매된 자동차를 하자 때문에 회수하는 경우는 정말이지 드물다. 현장에서 사용되고 있는 컴퓨터를 바꾸는 것 역시 그보다는 약간 덜하지만 그래도 찾아보기 힘들다. 두 경우 모두 현장 소프트웨어에 행해지는 수정보다는 훨씬 빈도가 낮다.
이는 시스템에 있는 소프트웨어가 시스템의 기능을 구현하고 있으며, 다수가 변경 압박을 느끼는 부분이 바로 그 기능이라는 데 부분적인 이유가 있다. 소프트웨어는 변경하기가 한결 수월하다는, 즉 순전히 생각만으로 이뤄지며 무한하게 늘일 수 있다는 점도 부분적인 이유이다. 사실 건물 또한 변경된다. 하지만 건물을 변경하려면 누구나 다 납득하고 있듯이 비용이 많이 들고, 이 점은 이리저리 변덕스럽게 변경하려는 마음을 누드러뜨리는 요인이 된다.
어떤 성공적인 소프트웨어도 모두 변경되기 마련이다. 그리고 다음과 같이 두 가지 과정을 거친다. 어떤 소프트웨어가 유용하다고 밝혀지면 사람들은 그것을 원래 정의역의 극한까지 또는 그 영역을 넘어서까지 새로운 경우에 적용하려고 한다. 기능 확장에 대한 압박은 기본 기능을 좋아하는 사용자가 그 기능의 새로운 용도를 고안해내면서 주로 발생한다.
둘째, 성공적인 소프트웨어 역시 처음 작성될 때 목표로 했던 머신보다 오래 살아남는다. 완전히 새로운 컴퓨터가 아니더라도, 최소한 새로운 디스크나 새로운 화면 장치, 새로운 프린터가 달려 나오면 소프트웨어는 그 새로운 기회의 매체들에 순응해야 한다.
간단히 말해, 소프트웨어 제품은 애플리케이션, 사용자, 법, 머신 매체 등으로 이뤄진 문화적 매트릭스 속에 놓여진다. 이 모든 것들은 쉬지 않고 변하고, 그 변화는 소프트웨어 제품의 변경을 냉혹하게 강요한다.
P.241 ~ 243
완벽한 프로그램 검증도 프로그램 명세의 요구사항을 충족시킨다는 것밖에 확증할 수 없다는 것이다. 소프트웨어 작업의 가장 어려운 부분은 완전하고 일관된 명세에 도달하는 것이며, 사실상 프로그램 구축의 핵심은 대부분 명세를 디버깅하는 작업이다.
P.259
저자는 오늘날 여러 조직에게 제일 중요한 소프트웨어 생산성 전략은 컴퓨터는 잘 모르지만 총명한 일선 작업자들에게 개인용 컴퓨터와 좋은 범용 문서 작성, 그림 작성, 스프레드시트 프로그램들을 주고 마음대로 쓰게 하는 것이라고 믿는다. 수많은 연구실의 과학자들에게도 일반화한 수학 및 통계 패키지들 그리고 몇몇 간단한 프로그래밍 기능 등을 제공하는 똑같은 전략을 쓰는 것이 최선일 것이다.
P.264
고객은 사실 자신이 원하는 것이 무엇인지 잘 모른다. 고객은 질문에 어떻게 답변해야 할지 모르는 게 보통이며, 명세되어야 할 문제를 자세히 생각해 본 적도 거의 없다. … 저자는 여기서 한 발 더 나아가, 고객이, 심지어 소프트웨어 엔지니어들과 함께 작업하는 고객까지도, 자신이 명세서에 지정한대로 몇몇 제품 버전들이 만들어져 직접 시험해 보기 전에는 최신 소프트웨어 제품의 요구사항들을 완벽하고 꼼꼼하며 정확히 명세하는 것이 실질적으로 불가능하다고 단언한다.
P.265
오늘날 우리가 구성하는 개념 구조는 너무 복잡해서 미리 정확하게 명세될 수 없고, 너무 복합적이라 오류없이 구축될 수 없기 때문에, 근본적으로 다른 접근방법을 취해야 한다.
… 비결은 그것이 구축(building)된 것이 아니라 성장(grow)한 것이기 때문이다.
우리의 소프트웨어 시스템도 그렇게 되어야 한다.
P.267
동일한 훈련과 2년 경력의 수준에서, 매우 훌륭한 프로그래머는 좋지 못한 프로그래머보다 생산성이 10배 높다. (색맨, 그랜트, 에릭슨)
P.312
한 명의 대장 프로그래머와 수술 팀으로 이루어진 조직은 커뮤니케이션이 파격적으로 줄어든 덕분에 소수 두뇌를 통한 제품의 무결성 그리고 여러 조력자들을 통한 총체적 생산성을 한꺼번에 얻을 수 있는 한 방법이다.
P.313
개념적 무결성을 얻으려면, 한 사람의 두뇌에 의해서 또는 의견이 잘 맞는 소수그룹에 의해 설계가 진행되어야 한다.
P.313
시스템의 개념적 무결성을 얻으려면, 개념을 통제할 사람이 필요하다. 이는 변명의 여지없이 분명한 귀족정치다.
P.313
두 번째 시스템은 어떤 설계자에게든 가장 위험하다. 두 번째 시스템을 과도하게 설계하는 것이 일반적인 추세다.
P.314
이름과 선언처럼 어쨌거나 그 자리에 있어야 할 프로그램 부분을 사용하여 가능한 문서의 많은 부분을 전달하게 하라
P.336
소프트웨어 시스템들은 아마도 인간이 만드는 사물들 가운데 가장 얽히고 설킨 그리고 가장 복잡한(뚜렷이 다른 종류들로 이뤄진 부분들의 가짓수 측면에서) 것이다.
P.337
요즘 저자는 그 어느 때보다도 더 확신하고 있더. 개념적 무결성은 제품의 품질에서 가장 중요하다. 시스템 설계자를 두는 것은 개념적 무결성을 향한 가장 중요하고 유일한 행보이다.
P.345
개념적 무결성을 이루려면 … 통일된 사용자 이미지를 공유하는 것이 필수불가결하다. 그리고 다음과 같은 사항을 포함하여, 예상되는 사용자 집합의 속성은 반드시 기록되어야 한다.
– 사용자들은 누구인가
– 사용자들은 무엇을 요구하는가
– 사용자들 자신이 필요하다고 생각하는 것은 무엇인가
– 사용자들이 무엇을 원하는가
P.348
지난 수년간의 경험을 통해, 저자는 설계자가 사용자 집합을 완전하고 명백하게 묘사한 공동 명세서를 개발하려면 속성들과 빈도수를 지닌 값들 전부를 하나도 빠짐없이 추측(guess)하거나 원할 경우 가설(postulate)을 세워야 한다는 확신에 도달했다.
현실에서는 전혀 찾아보기 힘든 듯한 이 절차를 도입하면 많은 이점을 얻을 수 있다. 첫째, 빈도수를 신중하게 추측하는 과정을 통해 설계자는 예상 사용자 집합에 관해 아주 신중하게 고민하게 된다. 둘째, 빈도수를 구체적으로 기록하면 그것을 놓고 토론이 벌어짐으로써 모든 참여자들의 눈을 뜨게 할 수 있고 여러 설계자들이 각자 생각하고 있던 사용자 이미지들이 어떻게 다른지를 수면 위로 끌어올릴 수 있다. 셋째, [어떤 사용자 집합이 많은지] 빈도수를 명료하게 열거해 보면 어떤 결정이 어떤 사용자 집합의 속성에 의해 좌우되는지를 모든 사람이 인식하는 데 도움이 된다. 심지어 이런 종류의 비공식적인 감수성 분석조차도 가치가 있다. … 애매모호한 것보다는 설사 잘못되더라도 명시적인 것이 훨씬 낫다.
P.349
흔히들 패키지를 사서, 집으로 가져와서는, 설명서를 보지 않고도, 단순히 패키지를 산 목적을 알고 있는 것만으로 그리고 여러 가지 메뉴 동사들을 시험해 보는 것만으로 사용하기 시작한다.
P.355
[애플 컴퓨터의] Command+Z가 어떤 실수도 실행 취소로 되돌려 놓아 주는 덕에, 사용하고 싶지만 확실하지 않은 어떤 단축키도 시도해볼 수 있다.
P.356 ~ 357
폭포 모델은 시스템 테스트를 구축과정의 제일 끝에 두며, 따라서 사용자 테스트도 제일 끝에 둔다. 그래서 사용자로서는 도저히 수용할 수 없는 불편, 도저히 받아들이기 힘든 수준의 성능, 또는 사용자 오류나 악의에 노출될 수 있는 위험한 취약성 등을 전체 구축비용이 다 투자된 뒤에야 비로소 발견할 수 있다. 확실히 해 둘 것은, 명세에 대해 정밀조사를 벌이는 알파 테스트는 그런 결함을 조기에 발견할 목적으로 실시하는 것이며, 테스트에 참여하는 사용자를 대신할 수 있는 것은 아무것도 없다는 사실이다.
P.360
그것을 컴파일하고, 그것을 테스트하라. 그것은 사실상 아무것도 하지 않지만 정확하게 하면서 계속 반복한다.
다음으로, 입력 모듈(아마도 원시적인)과 출력 모듈에 살을 붙여 나간다. 자, 보라! 시스템이 단조롭긴 하지만 뭔가를 작업하면서 실행되지 않은가. 이제 기능 하나하나씩 모듈을 점증적으로 구축하고 추가해나간다. 이로써 우리는 어떤 단계에서든 실행되고 있는 시스템을 갖게 된다. … 저자는 대략 22년 동안 노스캐롤라이나 대학교에서 소프트웨어 공학 실습을 가르쳤다. … 22년이란 시간의 절반쯤을 경과하는 시점에서, 저자는 점증적 개발을 가르치는 쪽으로 강의 내용을 바꿨다. 학생들이 자신이 작업한 결과가 화면에 처음 나타났을 때, 시스템이 실행되는 시스템을 처음 보았을 때 팀의 사기가 마치 전기충격을 받은 듯 뛰어오르는 것을 눈으로 직접 보고는 놀랐기 때문이었다.
P.363 ~ 364
파나스는 설계자는 제품의 수평적 확장과 후속 버전 둘 다를 미리 내다봐야 하고, 확장 및 후속 버전들의 기능 또는 플랫폼 상의 차이점들을 정의하여 관련 제품들의 계보를 구축해야 한다고 역설했다.
P.364
몇 사람을 투입하든 상관없이, 계산된 최적 일정의 3/4 이내에 성공적으로 마무리되는 프로젝트는 거의 없다! 인용할 만한 가치가 충분한 이 결과는 고위 관리자가 실현 불가능한 일정 약속을 요구할 때 소프트웨어 관리자가 맞설 수 있는 강력한 무기가 된다.
P.373
모든 것을 고려할 때, 저자는 아직도 [일정이 계획보다 늦어진 소프트웨어 프로젝트에 인력을 추가하면 일정은 더 늦어진다는 브룩스의 (일부러 극단적으로 단순화한)] 직설적인 진술이 진실에 가장 가까운 최상의 0점대 근사치이며, 관리자들이 늦어진 프로젝트에 무턱대고 즉흥적으로 대응하지 말 것을 경고하는 경험법칙이라는 입장을 고수한다.
P.375
뵘의 코코모(COCOMO) 모델은 팀의 자질이 성공을 가름하는 가장 중요한, 그것도 두 번째 중요한 것보다 4배 이상으로 타의 추종을 불허하는, 절대적으로 중요한 요소라는 점을 밝혀 주었다. 그동안 소프트웨어 공학에 대한 학술 연구는 대부분 도구에 집중되어왔다. 저자 역시 예리한 도구들에 찬탄을 금치 못하고 몹시 탐도 낸다. 그럼에도 불구하고, 사람들을 돌보고 성장시키고 북돋우는 것에 대한, 그리고 소프트웨어 관리의 정신 역학에 대한 지속적인 연구 노력이 이뤄지고 있음을 눈으로 확인할 수 있어 고무적이다.
P.376
소프트웨어 관리자가 해결해야 할 핵심은 창조성과 자발성을 방해하는 것이 아니라 향상시켜 줄 수 있도록 구조와 과정을 설계하는 방안을 마련해내는 것이다. 다행히, 이 문제는 소프트웨어 관련 조직들에만 해당되는 것이 아니라서, 그동안 위대한 사상가들이 이 문제에 관해 지속적으로 작업을 벌여 왔다. 슈마허는 고전이 된 《작은 것이 아름답다: 사람 중심의 경제학》에서 일하는 사람들의 창조성과 기쁨을 최대화할 수 있도록 기업을 조직하는 방법론을 제시한다. …
(인용 – 교황 비오 14세) 한층 작은 하위 조직체들이 수행할 수 있는 기능과 역할을 더 큰 상위 조직에 맡기는 것은 불의임과 동시에 중대한 해악이며 올바른 질서를 교란하는 것이다.
(인용 – 슈마허, 작은 것이 아름답다) 보조 기능의 원리가 가르치는 바는, 하위 구성체들의 자유와 의무를 신중하게 보호하면, 중앙은 권위와 효율을 얻고, 그 결과, 조직 전체가 “한층 행복해지고 번영하는” 결실을 얻으리라는 것이다.
어떻게 하면 그런 구조를 이룰 수 있는가? … (중략) … 큰 조직은 수많은 반(semi-)자율적 단위들로 구성될 것이며 우리는 그것을 사내 회사(quasi-firm)라고 부르게 될 것이다. 창의성과 기업가 정신을 발휘할 수 있는 최대한의 기회를 부여하기 위해, 그들 각각은 엄청나게 많은 자유를 누릴 것이다. … (중략) … 각 준회사는 필연코 손익계산서와 대차대조표 둘 다를 갖추게 될 것이다.
P.378 ~ 379
유닉스의 창조자인 벨연구소의 켄 톰슨(Ken Thompson)은 프로그래밍 작업을 하는 데 큰 화면이 얼마나 중요한지 일찍이 깨달았다. 그는 자신의 원시적인 텍트로닉스 전자축적관(Tektronix electron-storage tube에서 120행의 코드를 2열로 표시하는 방법을 고안해냈다. 그는 화면 창이 작았던 시절 내내 이 터미널만 사용했다.
P.396
댓글 남기기