제목 그대로 소프트웨어 개발에 있어서 논쟁이 되어 왔던, 되고 있는 주제에 관해서 50여년 동안 전산분야에서 경험을 쌓아 왔던 로버트 L.글래스가 그 의견을 펼치는 책이다.

1990년에 1판이 출간 되었고, 15년이 지난 2005년 2판이 출간되었다. 책의 90년 당시의 CASE 도구와 4GL이 은총알이 될 수 있을 것이냐가 상당부분의 논쟁 거리이며, 전통 개념의 설계(water fall)과 프로토타입, 오브젝트적 설계가 분쟁하던 시기 였으며, 최근 몇년간 유행하고 있는 UX가 발생시키는 비용, 테스트와 유지보수, 품질관리에 초점울 두고 있다.

위의 주제중 최근에 정립된 것들도 있지만 상당 부분의 논쟁은 지금도 유효하다. 또한, 관리자로 전향하지 않고 개발자로 남은 로버트 L.글래스가 관리자들에게 또는 개발 이외의 팀에게 - 프레드릭 브룩스가 은총알 이란 없다고 말했자나. 그게 진리야, 몇번이나 말해야 알아 듣겠어! - 라고 말을 하고 있는 듯 하다.

번역하신 박재호.이해영님은 책의 끝부분에 용어 사전을 특별부록으로 실었으며, 전산학 전공자 이지만 시간이 많이 흘럿거나, 비 전공자일 경우 먼저 읽는 것이 도움 될 수 있다고 생각한다.

역자들은 '각주'에 신경을 많이 썻으며, 에세이 특성상 발생하는 영어식 비유적 표현의 이해를 돕기 위해 많은 노력을 들인 흔적이 보인다.



이론이 먼저냐, 실제가 먼저냐? - "이기론(理氣論) 과 비슷하다."
십여년이 넘게 정규교육을 받은 우리는 이런 질문에 무의식적으로 대답한다.
"이론이 먼저 나와서 실제의 틀을 마련한다고", 이는 심각한 결함이 내재하며 뿌리 깊은 오해가 도사리고 있다고.

알렉산더에 따르면 실제가 이론보다 선행한다.
*크리스토퍼 알랙산더 - 'A Pattern Laguage:Towns, Buildings, Construction'를 쓴 저자로 요즘 컴퓨터 분야에서 유행하는 디자인 패턴 개념을 창시한 건축 분야의 권위자.

분야의 초기 단계에서는 실제를 관찰하여 이론을 적립한느 방법이 효율적이다. 이론이 실제를 추월하는 시점, 즉 실제가 이론에 귀를 귀울여햐 하는 시점이 있다.


은총알(No Silver Bullet) 은 없다란?
프레드릭 브룩스가 IEEE 컴퓨터 저널 1987년 4월호에 게재한 논문의 늑대인간을 잡을 수 있는 총알인 은총알을 소프트웨어 비용을 극적으로 줄일 수 있는 방법이나 도구에 빚댄 것.

은총알(silver bullet) -  컴퓨터 하드웨어 비용이 급격하게 감소하는 것처럼 소프트웨어 비용을 떨어뜨릴 수 있는 그 어떤것.(  Something to make software costs drop as rapidly as computer hardware costs do)
위키피디아 : http://en.wikipedia.org/wiki/No_Silver_Bullet

소프트웨어 제작이 어려운 이유는 소프트웨어가 본질적으로 지니는, 그리고 지녀야 하는 복잡성 때문이다. "소프트웨어는 어쩌면 인간이 만든 어던 피조물보다도 복잡하며," "소프트웨어 시스템은 컴퓨터보다 상태 수가 몇배는 더 많으며," "소프트웨어의 복잡성은 본질적인 속성으로, " 수학 분야에서는 복잡한 문제를 단순화한 모델이 문제 해결 도구로 효과적이지만, 소프트웨어에서 복잡성은 다른 분야에서 사용하는 기술로 해결하지 못한다. p.14

단일지점 제어(Single-point control) - 여러 곳에서 해야 할 일을 한 곳에서 해결한 후 필요한 곳에서 참조하는 방법이다. p.65


사용자 편의성 - 사용자 편의성이란 흥미진진한 진보에는 대가가 따른다는 사실에 주목해야 한다. 성공적인 사용자 인터페이스를 제공하려는 소프트웨어 개발자는 개발 시간을 1.5배 심지어 2개까지 예상해야 한다. p.71


비자아 프로그래밍 - 소프트웨어가 점점 복잡해지고 더 많은 사람이 필요함에 따라, 소프트웨어 개발에서 팀이라는 접근 방식이 필연적으로 등장했다. 그런데 소프트웨어 팀에서는 자아가 팀워크를 방해하는 듯 보였다. ~ 자아는 우리에게 동기를 부여하는 강력한 원천이다. 자아를 없애버린다면 무기력하고 무책임한 상태에 빠질 뿐이다. p.83
 
프로그래머는 자신의 프로젝트에 자아를 투영하는 경향을 보이는데, 이는 프로덕트의 오류를 지적하는 것에 대해 자신을 지적하는 것으로 인식하는 경향이 발생하며, 팀 프로그래밍에서 자신의 코드를 고집하려는 경향이 발생할 수 있다. 이는 팀 프로그래밍과 프로덕트에 악영향을 끼친다. 하지만, 자아는 프로젝트 개발의 근원 적인 원동력이란 점에서 양면성을 가지고 있다.

소프트웨어 생명주기(software life-cycle)
누군가의 아이디어가 컴퓨터에서 돌아가는 프로그램으로 구현되기까지 소프트웨어 개발 과정에서 거치는 일련의 단계

프로토 타이핑 - 소프트웨어 생명주기(software life-cycle) 라는 개념에 의문을 제가하면서 불붙은 논쟁.

헤켈식 프로토타이핑 생명주기는 요구사항-설계-구현-요구사항확정과 제품 폐기-설계-구현

표준과 표준 준수
현장 실무 현황을 들여다보면 표준과 표준 준수에 두가지 심각한 문제가 존재한다.
첫째는 대다수 전산 분야에 표준이 너무 많다는 사실
둘째는 대다수 전산 분야가 표준을 거의 무시한다는 사실.

표준을 제대로 정립하는 방법
첫째, 표준은 간결하고 핵심적이어야 한다. 표준이 아니라 지침으로 명시하고 별도의 문서를 만든다. p.96
둘째, 표준은 회사에서 프로그래밍 기량이 가장 뛰어난 사람이 작성하고 검토해야 한다.
셋째, 표준 준수는 의무적이어야 한다.

표준화 제대로 사용하기
전구 꼭지는 모양과 크기가 표준화 되었지만, 유리구는 모양과 크기가 표준화되지 않았다. 꼭지쇠 표준화는 전구 업계가 이익을 창출하기 위해서 필수적인 조치였다. 유리구 비표준화는 전구 업계가 창의성을 발휘하기 위해서 필수적인 조치였다. 제대로만 한다면 표준화는 이익과 창의성을 모두 자극한다. p.99


소프트웨어 업계에서 업적 달성하기
업적을 달성할 자질이 소수에게만 존재하는 탓도 있지만, 업적을 달성하려면 올바른 자질은 물론이고 시기도 적절해야 한다.
과거 업계에서 업적을 달성한 방법이 3가지가 있었는데 ,
Coding a Lot (코드를 작성 공유해서 업적을 쌓는 것),
Write a Lot (논문을 작성 해서 업적을 쌓는것),
Selling a Lot (많이 팔아서 업적을 쌓는것), 글래스는   다음번에는 어떤 것이 될 것인지 독자들이 찾기를 바란다.

소프트웨어 생산성 문제
생산성 향상에 도구, 방법론 등이 마케팅 도구로 많이 사용 되었지만, 그 효과는 미미하다. 생산성을 좌우하는 가장 큰 요소는 '인력' 이다. 우리가 흔이 알고 있는 우수한 개발자는 다른 사람에 비해 7배에서 28배까지 생산성이 차이가 난다.

베리보엠의 X, Y, Z 이론 - 소프트웨어 관리 이론
X이론 - 일 하라고 사람들을 부추겨야 한다는 가정에 기반한다. 하지만 이는 적대적 관리자-개발자 관계를 초래하며, 실제로 소프트웨어 업계 종사자의 본성을 정확히 반영하지도 않는다.
Y이론 - 적절히 보상만 하면 사람들이 일을 잘 한다는 가정에 기반한다. 이 이론은 자기중심적인 인력을 만들어내며, 충돌이 발생할 경우는 통하지 않는다.
Z이론 - 소위 '일본식 관리'라는 Z이론은 동질적인 구성원으로 이루어진 공동체에는 유용하지만, 소프트웨어 관리자, 고객, 개발자, 유지보수 담당자 등 여러조직이 관려된 경우에는 통하지 않는다. pp.149.150

실패한 소프트웨어 프로젝트에 관한 전설 - 관련포스트 : 소프트웨어 위기
재미있게 읽은 에세이중 하나이다.
전산 분야에서 둘째가라면 서러울 대학을 졸업하고, 여러해 동안 탄탄한 경력을 쌓은 소프트웨어 실무자가 난관에 봉착 했다. 소프트웨어는 예산을 초과했고 일정을 놓쳤으며 불안전했다.
무엇이 문제 였을까?
관리층은 그에게 말했다. "첫번째로 특별히 취급해야 할 사항은 특정 날짜까지 끝내야 한다는 점이다.", 마케팅도 그렇게 말했다. 담당할 소프트웨어 실무자가 그 날짜까지 불가능하다고 생각해도 소용이 없었다. 무조건 날짜를 맞춰야 했다.

협조적인 태도를 보이느라, 실무자는 우려에도 불구하고 일을 시작했다.

시간이 흐르고 기한이 다가오면서, 우리의 실무자는 점점 더 초조해졌다. 처음에는 자신의 품질 기준에 맞추어서 소프트웨어를 개발했다. 요구 사항을 주의 깊게 검토하고, 철저히 설계한 다음에, 프로그램을 실행하기 전에 코드 행 한줄 한줄 신중하게 검토 했다.

그러나, 기한이 다가오면서, 그는 우수한 기법을 생략하기 시작했다. 요행을 바라면서 테스트를 대충 해버렸다. 어떤 모듈은 테스트하지 않은 채로 통합되기도 했다.제품은 자체 표준 테스트도 통과하지 못한 상태에서 베트 테스트로 돌입했다. 그러나 기한은 꿈쩍할 가능성이 없어 보였고, 결국 압박감을 견디다 못해 덜 중요해 보이는 사항을 희생시켰다.

결국 우리의 실무자는 기한을 맞추지 못햇다. 프로젝트는 그가 처음 예측했던 날짜대로 그만큼 늦어졌다. 당연히 비용은 예상보다 많이 들었다. 
~
요약하자면, 옛날 옛적에 우수한 소프트웨어 실무자가 실패한 소프트웨어 프로젝트를 내놓았다. 마음속으로는 대충 건너뛰면 안된다는 사실을 알았다. 동시에 마음속으로는 개발 과정에서 저지른 실수가 하나뿐이라는 사실도 알았다.

그가 저지른 실수는 소프트웨어를 제작한 방식이 아니었다. 처음부터 잘못된 일정에 맞추려는 시도 자체가 실수 였다.

소프트웨어 시룸자가 관리층으로 부터 성과 평가를 받았을 때, 그는 실패한 프로젝트로 인해 자신의 업무 평가가 낮아졌음을 발견했다. p.166~168

-- 끝 -- 






현재글 : [개발 교양서] 소프트웨어 컨플릭트 2.0 (로버트 L. 글래스) posted By - 반더빌트 2009/09/25 10:15