[책] Professional 소프트웨어 개발 :: 스티브 맥코넬

스티브 맥코넬 저/윤준호,한지윤 공역 | 인사이트(insight)

미래의 소프트웨어 공학 전문가를 위한 성장 에세이  

이 책은 MS의 빌 게이츠, Linux의 리누스 토발즈와 함께 소프트웨어 업계의 가장 영향력 있는 세인물 중의 한명으로 뽑힌 스티브 맥코넬의 최근 저서로 소프트웨어 업계의 현실과 '소프트웨어 공학 전문가'로 성장하기 위한 개인/조직/업계 차원의 방법론을 구체적인 가이드는 아니지만 에세이 형태로 기술한, 통찰력을 제공해주는 매우 유익한 양서라고 생각된다.

제 1부 '소프트웨어의 늪지대'에서는 소프트웨어 분야의 현실을 '공룡과의 승부', '바보들의 황금', '화물 숭배 소프트웨어 공학'의 은유적 메타포를 통해 예리하게 분석한다.

제 2부 '개인의 프로정신'에서는 프로그래머의 성격 특성을 분석해보고 의식 향상, 커뮤니티 참여, 전문화, 글쓰기 등을 실천할 것을 요구한다.

제 3부 '조직의 프로정신'에서는 소프트웨어 개발 기법을 개선하고 SW CMM과 Construx 전문성 개발 프로그램을 도입할 것을 주장한다. Construx 전문성 개발 프로그램은 스티브 맥코넬이 만든 소프트웨어 엔지니어를 위한 명확한 경력 경로(career path)와 전문성 개발 지원 프로그램으로 Construx 지식영역(CKA)과 4개의 능력 레벨을 조합하여 7단계의 전문성 개발 단계 레벨을 구분하여 각 단계별 필독서, 업무 경력, 교육, 업계 참여 등의 활동 타입별로 관리한다. 다소 개괄적으로 설명되어 있어 구체적으로 이해하기 곤란한 부분이 없진 않지만 이러한 프로그램이 외국에서는 활용되고 있다는 사실을 안 것만으로도 수확이라고 생각하며 추후에 이 부문을 좀 공부할 필요가 있을 거라는 생각이 들었다.

제 4부 '업계의 프로정신'에서는 소프트웨어 공학 전문가를 양성하기 위한 대학 교육 과정, 자격증, 면허제도, 기술사 육성, 소프트웨어 윤리강령 제정 등의 대안을 제시한다.

참고로 먼저 출간된 동 저자의 'Code Complete', 'Rapid Development', '소프트웨어 프로젝트 생존전략'은 이 책의 실용서로 이 책을 읽고 난 후에 접근하면 매우 유용할 것이다.

결론적으로 이 책은 소프트웨어 공학 전문가가 되기 위한 영감을 주기에는 충분하나 소프트웨어 공학 전문가의 정체성(Identity)과 요건에 대한 설명이 부족하고 또 전문가가 되기 위한 방법이 미국의 IT 현실 위주로 기술되어 있는 점이 다소 아쉬움으로 남는다. 그래서 다소 공감하기 어려운 부분이 몇가지 눈에 띈다. 그러나 이 점은 국내 IT 종사자들의 몫이다. 아니 그 역할을 미약하나마 내가 하리라는 결심이 들 정도로 이 책은 넋두리가 아닌 희망을 불러 일으키는 매력이 분명 있다.  

* 밑줄 쫘악~

- 바위를 움직이든 소프트웨어를 만들든 간에, 현명한 팀은 프로젝트 초기에 빠르고 효과적으로 일하기 위한 계획을 세우는 데 시간을 투자한다.

- 현명한 팀은 지속적으로 더 효과적인 방법을 찾아낸다.

- 전체 소프트웨어 개발팀 중 75%는 무작정 바위를 밀면서 프로젝트를 시작한다. 이것을 '일단 작성하고 고쳐보는 개발'(code and fix development)라 한다.  

- 소프트웨어 프로젝트 예산의 40%~80%가 초기 결함을 수정하는 데 쓰인다고 한다.

- 프로젝트에 비용이나 일정을 품질과 맞바꾸려는 시도는 바보들의 황금일 뿐이다.

- 어떠한 툴이나 방법론도(어떠한 '은빛총알'도) 다음 10년에 걸쳐 10배의 생산성을 향상시킬 수는 없다.

- 이름에도 분명 소프트라는 단어가 들어 있는 데고 불구하고, 소프트웨어는 소프트하지 않다. 그리고 소프트웨어를 소프트하게 하기 위해서는 비용이 든다.

- 개발 방식에는 '프로세스 기반 개발'과 '책임 기반 개발'의 두가지가 존재한다. '프로세스 기반 개발'은 잘 짜인 계획, 잘 정의된 프로세스 등 소프트웨어 공학 기법들을 적용해 프로젝트를 성공시키는 것이고 '책임 기반 개발'은 해당 분야의 최고 인재를 고용하여 프로젝트의 전권을 위임하고 자율적으로 프로젝트를 성공시키는 것이다. 문제는 이를 사칭하는 개발이 문제다. '프로세스 사칭 조직'은 소프트웨어 프로세스의 형태를 그 본질보다 더 중요하게 생각하는 '관료조직'이며 '책임사칭조직'은 결과(긴 근무시간)와 원인(높은 동기부여)를 혼동하는 '착취조직'이다.

- 소프트웨어 개발이 어려운 이유는 코딩이나 테스팅 때문이 아니라 소프트웨어의 본질적 어려움인 복잡성, 일치성, 변화 가능성, 비가시성 때문이다.

출처 : http://blog.naver.com/kksobg/1048988