"소프트웨어 개발,
제발 무작정 덤비지 말고 전문가답게 공학적으로 접근하라"


사용자 삽입 이미지

- 제목 : Professional 소프트웨어 개발

- 지은이 : 스티브 맥코넬

- 옮긴이 : 윤준호, 한지윤

- 출판연월 : 2003년 11월(초판 4쇄 읽음)

- 출판사 : 인사이트

- 읽은기간 : 2007.8.1~8.20



이 중간에 주요 내용 정리한 것이 다 사라졌다. 다행히 아래처럼 주요 문장 옮겨적은 것은 copy를 해놨기에 살아있고...아...허탈하다...
역자 서문.

[7] 스티브의 글은 세계적인 명성을 자랑하는 IEEE Software지에 실릴 만큼 탁월한 수준을 자랑한다. 이 책에서 스티브가 보여주는 사고의 깊이는 '소프트웨어 공학계의 앨빈 토플러'라는 명칭을 지어주고 싶을 정도다.

[7] 최근 잇달아 나온 스티브의 책들을 다음 순서로 읽을 것을 권장한다. "Professional 소프트웨어 개발" -> "Rapid Development", "Code Complete" -> "소프트웨어 프로젝트 생존전략"

[7] 이 책은 넓은 범위, 즉 개인/프로젝트/조직/업계 수준을 아루는 개념 형성과 동기 부여를 목표로 한다. 즉 과거와 현재를 바탕으로 소프트웨어 개발장이들이 나아갈 길과 개개인의 전문성을 키울 수 있는 방안을 제안한다.


서문

[24] 어떻게 변할 것인가? 그것이 이 책에서 다룰 주제다.


Part 1. 소프트웨어 늪지대

[39] 소프트웨어 프로젝트 관리자들은 매일 '오늘은 우리의 최종 목표까지 하루만큼 더 가까이 갔는가? 만약 아니라면 남은 일들을 하루치 줄일 수 있는 방법을 찾았는가?'라고 물어야 한다.

[48] 소프트웨어 시스템이 점점 더 복잡해짐에 따라, 소프트웨어는 고치기 쉽다는 믿음은 소프트웨어 개발에 있어 오히려 해악이 돼버렸다. 소프트웨어가 가진 소프트하다는 특성을 이용한답시고 요구사항을 바꾸는 일이 비일비재하며, 이것은 비용과 일정을 초과하게 하는 주요 원인이 된다는 연구 결과도 나와 있다.

[56] 프로세스 기반 개발은 잘 짜인 계획, 잘 정의된 프로세스, 효율적인 시간 사용, 오랜 경험을 통해 좋다고 판명된 소프트웨어공학 기법들을 적용해 프로젝트를 성공시키는 것이다.

[56] 책임 기반 개발은 '영웅 중심 개발(hero oriented development)', '개별 권한 부여(individual empowerment)' 등의 이름으로 불리기도 한다. 책임 기반 개발을 적용하는 조직은 해당 분야의 최고 인재를 고용한 다음, 그 사람에게 특정 프로젝트를 맡아주도록 요청하고, 프로젝트에 전권을 위임한다.

[59] 소프트웨어 전문가들은 가끔 프로세스가 더 좋은지 개인 권한 부여(다른 말로 책임 기)가 더 좋은지 논쟁하는 데 시간을 보낸다. 이것은 잘못된 흑백 논리다. 프로세스도 좋고, 그만큼 개인 권한 부여도 좋다. 이 둘은 동시에 존재할 수 있다.

[61] 어떤 스타일을 선택했느냐가 중요한 것이 아니라 프로젝트를 수행하기 위해 어떤 교육, 훈련, 이해를 동반하느냐를 심각하게 고려하여야 한다. 즉 프로세스인가 책임인가에 대해 공방을 벌이기보다는 개발자, 관리자의 능력 수준을 향상시키는 길을 찾아야 한다.

[65] 적절한 질문은 '무엇이 소프트웨어 개발인가?'가 아니라 '전문적인(professional) 소프트웨어 개발은 어떤 모습이어야 하는가?'여야 한다. 위 질문에 대한 나의 의견은 다음과 같다. '진정한 소프트웨어 개발은 반드시 공학이어야 한다'

[66] 만일 과학을 전공한다면 특정 전문지식만을 연구해도 되지만, 공학을 전공한다면 현재 만드는 제품에 관계되는 모든 분야의 지식을 두루 익혀야 한다.

[68] '공학'의 사전적 의미는 수학의 원리와 과학을 응용하여 실세계의 문제를 해결하는 것이다. 이야말로 대부분의 프로그래머가 추구하는 것이다. 즉, 과학적으로 발전하고 수학적으로 잘 정의된 알고리즘, 실용적으로 디자인한 방법론, 이미 안전하다고 알려진 방법 등을 실세계에 적용해서 소프트웨어 제품과 서비스를 개발하는 것이다.

[73] 한 분야의 전문가가 되기 위해서는 50,000여의 지식을 알아야 하고, 이 지식들은 기존의 지식에서 유도할 수 있는 것이 아니라 각각 따로 기억해야 하는 성질의 것이라고 한다. 특히 성숙한 분야의 경우 모든 관련 정보를 소화하려면 세계적인 수준의 전문가일지라도 최소 10년이 걸린다고 알려져 있다.

[74] 기술 관련 지식들의 경우 3년 후에는 반 정보만 계속 사용되는 경우가 대부분이다. 그러나 프로그래머로 살아가는 동안 지속적으로 도움을 주는 지식들도 분명히 존재한다. 이 지식은 반감기(half-life)를 뛰어넘어 계속 살아 남는다.

[75] 브룩스는 '본질(essence)'과 우유(accident)'라는 단어를 이용해, 소프트웨어공학 논의에 고대 철학('본질'과 '우유'적 성질을 구별하려고 시도했던)을 끌어다 놓았다.

[80] 다른 공학 영역들이 그런 것처럼, 소프트웨어 공학 지식체계가 안정되면 소프트웨어 공학은 교육의 터전으로 옮겨질 것이다. 데이비드 파나스가 지적했듯이, 물리학의 수업 내용은 연구소에 오실로스코프를 들여놓더라도 바뀌지 않을 것이다. 소프트웨어 공학의 수업 내용은 C++이나 자바 같은 상대적으로 수명이 짧은 특정 기술과 관련이 없어야 한다. 학생들은 이런 기술들을 실습을 통해 배워야 하고, 수업시간에는 좀더 오래 쓸 수 있는 지식들에 초점을 맞춰야만 한다.

[85] 과학자와 엔지니어의 차이점 중 하나는, 과학자는 좁은 영역에만 깊은 지식을 가져도 되는데 비해, 엔지니어는 그들이 만들고자 하는 제품에 영향을 미치는 모든 요소들에 대해 광범위하게 이해할 필요가 있다는 것이다.


Part 2. 개인의 프로정신

[106] 연구에 따르면, ISTJ가 소프트웨어 개발자에게 가장 흔하게 발견되는 성격 유형이라고 한다. 이 유형은 진지하고 과묵하며, 실리를 중요시하고, 원리 원칙, 정리 정돈을 우선으로 한다. 실제 소프트웨어 개발자의 25~40% 정도가 이 유형이다.

[116] 많은 소프트웨어 개발자들이 컴퓨터 분야에 대해 체계적인 훈련을 받지 못한다. 소프트웨어 공학 분야에서 세부적으로 바라본다면 사태는 더욱 심각하다. 개발자들이 아는 것은 회사에서 교육을 받거나, 독학한 것이 대부분이다. 소프트웨어 개발 수준을 한단계 높이기 위해서는, 지속적으로 소프트웨어 공학을 교육해야 한다.

[130] 필요에 따라 규칙을 깰 수 있을 정도로 소프트웨어 프로젝트 역할을 깊이 이해하는 의식 III 수준으로 발전시키려면, 개발자는 규칙들을 배우고 그것들을 실제로 적용하는 경험을 쌓아야만 한다.

[140] 오늘날 소프트웨어 업계에는 두 종류의 전문화가 등장했다. 하나는 기술 전문화이고, 다른 하나는 소프트웨어 공학 전문화이다.

[146] '미국의 학자' 강연에서 에머슨은 '단순 사상가(Thinker)'와 '생각하는 인간(Man Thinking) 간의 차이점을 이끌어 냈다. 단순 사상가는 유일하게 하는 일이 바로 생각하는 것인 사람을 의미한다. 단순 사상가가 책이나, 기사 같은 것을 통해 삶을 간접적으로 경험하는 비해, 생각하는 인간은 어떤 직업을 가지면서 현실에서 역동적이고 가끔은 자기 반성을 위해 멈춰서기도 하는 사람을 의미한다. 생각하는 인간은 실천을 중시한다.

[147] 에머슨은 생각하는 인간의 직접 경험이 천재성(genius)을 이루는 결정적인 요소고, 이 천재성은 단순 사상가가 아닌, 생각하는 인간에게서만 나올 수 있다고 주장했다.

[147] 읽은 것을 행동으로 옮기지 않는 독자는 읽은 것을 거의 이해하지 못할 것이다.

[150] 마크 트웨인은 최고의 개척 모험 소설은 실제 개척지에 살았던 사람이 예리한 시각으로 써야 한다고 주장했다. 마찬가지로 나도 최고의 소프트웨어 안내서는 최근까지 상용 소프트웨어 프로젝트에 주도적으로 참여한 사람이 써야 한다고 믿는다. 소프트웨어 공학 안내서의 타일과 기단석들은 생각하는 인간이나 글 쓰는 프로그래머(Programmer Writing)처럼, 상용 소프트웨어 프로젝트에 주도적으로 참여하면서, 가끔은 그들의 업무에 대해 반성도 하고, 그것에 대해 글을 쓰는 사람들로부터 캐내져야 한다.


Part 3. 조직의 프로정신

[167] 20~30년 동안 소프트웨어 업계에서 일해 온 사람들조차도 최상의 소프트웨어 개발을 경험하지 못했을 수도 있다.

[184] SW-CMM의 기본적인 원칙은 콘웨이(Conway) 법칙과 유사하다. 콘웨이 법칙은 '프로그램의 구조는 그것을 제작하는 조직의 구조를 반영한다'는 것이다.

[191] SEPG는 조직의 개선 목표와 실제 프로세스 개선에 맞물린 민감한 문제들을 충분히 이해하는 선임 개발자나 관리자로 구성되어야 한다. 이 그룹의 역할은 내부에서 조직을 컨설팅하는 것이다.

[193] 소프트웨어 업계는 소프트웨어 공학을 통해 더 높은 레벨의 전문 영역으로 이동하고 있다. 그런 의미에서 SW-CMM를 반드시 고려해야 한다. SW-CMM에서 중요한 건 내용이지 형식이 아니다.

[197] 효율적인 소프트웨어 개발, 프로세스 개선 같이 중요한 주제들에 대해 토의할 때 무시하기 쉬운 것이 바로 소프트웨어 개발에 대한 인간의 역할이다.

[203] Cocomo에서 선임 직원(Staff Seniority)을 강조하듯이, 업계 선두를 달리는 많은 조직들은 경험 많은 선임 직원의 중요성을 인식한다.


Part 4. 업계의 프로정신

[237] 예술이 결핍된 공학은 흉해 보일 수 있다. 하지만 공학을 포함하지 않는 예술은 불가능하다. 공학은 예술을 속박하지 않는다. 하지만 공학의 결핍은 예술이 존재할 수 없게 만든다.

[241] 공학의 기본은 바로 친숙한 문제에 반복되는 설계 기법들을 적용하는 것이다.

[248] 내가 이 책에서 계속 주장했듯이, 공학은 소프트웨어 개발 전문가를 형성하는데 좋은 모델이다. 또한 엔지니어가 따라야 할 전문성 개발 단계에 있어서도 많은 것을 시사해 준다.

[249] 오랫동안 도움이 될 소프트웨어 공학 원리들을 가르치는 교육은 거의 이루어지지 않고 있다.

[253] 아직 해결되지 않은 문제는 소프트웨어공학 과정에서 '소프트웨어에 중점을 둬야 하나, 아니면 공학에 중점을 둬야 하나'이다.

[256] 배지(Badge)를 광내자! 기본 교육을 받고 경력을 좀 쌓고, 자격증을 얻으면, 이게 다인가? 대부분의 전문가들은 계속 연수를 받을 것을 요구받는다. 지속적인 연수교육 제도를 통해 전문가는 자신의 분야의 최신 기술을 받아들여 자신의 위치를 그대로 유지할 수 있다.

[257] 소프트웨어 공학 분야의 역사는 단지 50년 정도이다.

[274] 잘 정의된 전문성(면허, 윤리 강령, 학력 등등)을 갖췄다면, 당신은 무지한 관리자, 사장, 고객의 압박에 반박할 수 있는 전문적, 법적인 기반을 가지게 되는 것이다.

[274] 조직의 관점에서 살펴본다면, 기술사 면허와 SW-CMM 레벨 사이에 상관 관계가 있다는 것을 알 수 있다.

Posted by 일상과꿈

댓글을 달아 주세요