- 불씨
- 조회 수 8114
- 댓글 수 0
- 추천 수 0
저자연구
로버트 L. 글래스
Computing Trends 사의 설립자로 소프트웨어공학의 구루로 칭송받고 있다. 그는 소프트웨어 공학, 컴퓨팅 실패에 대한 교훈에 대한 주제로 28권 이상의 책을 저술했으며, 「The SoftwarePractitioner」라는 뉴스레터의 발행인이기도 하다. 그는 1954년에서 1957년 사이 항공우주 업계, 노스 아메리칸 사에서 3년 동안 일한 경험을 시작으로 소프트웨어 부문에서 진정한 선구자 중 한 명으로 거듭났다. 노스 아메리칸 사에서 근무한 경험이 계기가 되어 에어로젯-제네랄과 보잉과 같은 우주항공 회사에서 계속 일하게 되었으며, 그 이후 시애틀 대학교의 소프트웨어 공학 대학원에서 교편을 잡았고 소프트웨어 공학 연구소에서 1년을 보냈다. 워싱턴 대학교에서 도구에 초점을 맞춘 연구를 몇 년 정도(1970년 - 1972년) 진행했다. 1995년 스웨덴 린쉐핑 대학으로부터 며예 박사학위를 받았으며 1999년에는 ACM 전문학회의 특별 회원으로 지명되었다.
저서로는 베스트셀러인 <소프트웨어공학의 사실과 오해>를 비롯하여 <소프트웨어 크리에이티비티 2.0>, <소프트웨어 컨플릭트 2.0> 등이 있다.
감명깊은 글귀
1장 관리
29
많은 프로젝트의 성공과 실패는 어떻게 수행하는가보다 누가 수행하는가에 따라 결정된다
추정을 사이에 두고 경영진과 기술자 사이에 단절이 존재한다
사실1 - 소프트웨어 작업에서 가장 중요한 요소는 프로그래머가 사용하는 도구가 기술이 아니라, 프로그래머의 자질이다
> 너무 당연해서 할 말이 없는...
사실 2 - 개인차에 관한 연구에 따르면, 최상의 프로그래머는 최악의 프로그래머보다 29배 더 뛰어나다.
> 다른 책에서는 28배라고 하던데, 공돌이들은 숫자에 집착하지만 사실 28,29 이런 숫자가 중요한 것은 아니다.
사실 3 - 지체된 프로젝트에 사람을 추가 투입하면 프로젝트가 더 늦어진다
> 저자도 논쟁 부분에서 언급했지만, 상황과 시기, 그리고 투입된 인력에 따라 그렇지 않을수도 있다. 하지만 보편적으로 이 진술은 사실이다.
사실 4 - 작업환경은 생산성과 품질에 지대한 영향을 미친다
사실 5 - 소프트웨어 업계에는 과대선전이 만연해 있다. 소프트웨어 도구와 기술의 진보로 인해 생산성과 품질이 5~35% 향상된다고 한다. 그러나 예전에도 이정도의 향상은 10배 이상 뛰어난 사람이 있으면 가능한 일이었다
사실 6 - 새로운 도구나 기술을 배우는 것은 초기에는 프로그래머의 생산성과 제품의 품질을 저하시킨다
54
열광자들은 엄청난 이득과 빠른 학습곡선을 주장하고, 경영진은 너무도 자주 이런 이득과 빠른 학습 프로세스에 대한 주장을 그대로 믿어버린다.
> 실제로 너무도 빈번하게 일어나는 일이고 간과되는 일이기도 하다.
사실 7 - 소프트웨어 개발자들은 도구에 대해 많은 말을 하지만, 그 중 일부만을 평가해보고, 구입하는 것은 얼마되지 않으며, 실제로 사용하는 것은 거의 없다
사실 8 - 폭주하는 프로젝트의 가장 흔한 원인 두 가지 중 하나는 부정확한 추정이다
60
폭주의 원인 중 가장 두드러지는 두 가지는 형편없는 추정과 불안정한 요구사항이다
대부분의 추정이 현실적인 목표라기보다는 희망에 가깝다. 설상가상으로 이런 잘못된 관행을 개선할 방법도 알지 못한다. 그 결과 사람들은 불가능한 추정목표를 맞추기 위해 노력한다. 지름길이 선택되고, 좋은 관례는 생략되고, 피치 못할 일정의 폭주는 기술의 폭주로 이어진다
사실 9 - 소프트웨어 추정은 보통 부적절한 시기에 수행된다
67
설명한 것처럼 추정관행은 모순이다. 이를 바꾸기 위해 누군가 외쳐야 하지만, 아무도 그러지 않는다
> 그 이유는 그들이 회사원들이기 때문이다. 이런 경향은 공적 사회(공무원 조직)으로 갈수록 보편화, 고착화된다
사실 10 - 소프트웨어 추정은 보통 부적절한 사람들에 의해 수행된다
71
정책척 추정과 이성적 추정 - 정책적 추정은 고위 경영진이나 마케팅 쪽 사람들에게서 수행되고, 이성적 추정은 개발자들에 의해서 수행된다. 정책적 추정이 보편적으로 통용되는 것이 현실이다.
사실 11 - 프로젝트가 진행되면서 소프트웨어 추정을 수정하는 경우는 거의 없다
사실 12 - 소프트웨어 추정이 부정확한 것은 별로 놀라운 일이 아니다. 그러나 우리는 추정에 죽고 산다!
78
XP에서는 고객이나 사용자가 비용, 일정, 기능, 품질 네 가지 요소중 세가지를 선택하도록 한 후에 개발자가 마지막 것을 선택하라고 한다. 네 개의 요소중 두 개만이 추정과 관련된 것임을 명확하게 알 수 있으므로, 이 방법은 소프트웨어 프로젝트에서 무엇이 중요한지를 식별하게 해준다.
> 기능과 품질이 추정에 관련된 것인데, 고객은 기능과 품질은 당연하다고 생각하므로 오직 일정과 비용에 대해서만 이야기하는 것이 현실이다.
사실 13 - 경영진과 프로그래머 사이에는 단절이 있다
사실 14 - 타당성 조사에 대한 대답은 항상 타당하다 이다
사실 15 - 소규모 재사용은 잘 해결된 문제다
사실 16 - 대규모 재사용은 여전히 해결되지 않은 어려운 문제다
사실 17 - 대규모 재사용은 서로 관련 있는 시스템 사이에서 가장 잘 적용된다
사실 18 - 재사용 가능 컴포넌트는 만들기 3배 어렵고, 3곳에 적용해봐야 한다.
사실 19 - 재사용된 코드를 수정하는 것은 특히 오류를 범하기 쉽다
109
나사의 연구에 따르면 소프트웨어 시스템을 20~25% 또는 그 이상 수정해야 한다면 처음부터 다시 새로운 제품을 구축하는 것이 비용도 적게 들고 작업도 쉽다는 것이다.
사실 20 - 디자인 패턴 재사용은 코드 재사용 문제에 대한 해결책이다
사실 21 - 문제의 복잡성이 25% 증가하면 솔루션의 복잡성은 100% 증가한다
116
왜 요구사항은 폭발적으로 증가하는가? 요구사항을 설계로 옮겨가면서 명시적(explicit) 요구사항은 실제 설계에 필요한 훨씬 더 많은 잠재적(implicit) 유구사항을 수반한다. 25% 부분에서 100% 부분으로 옮겨가는 중이기 때문이다.
117
왜 최고의 설계자는 반복적, 경험적 접근방법을 사용하는가? 단순한 명확한 설계 솔루션이 있는 경우는 거의 없기 때문이다.
사실 22 - 소프트웨어 작업의 80%가 지적인 작업이다. 그 중 상당부분이 창조적인 직업이다. 사무적인 일은 거의 없다
사실 23 - 폭주하는 프로젝트에서 가장 흔한 원인 두 가지 중 하나는 불안정한 요구사항이다
사실 24 - 요구사항의 오류는 생산 단계에서 수정하는데 가장 비용이 많이 든다
사실 25 - 누락된 요구사항은 가장 수정하기 힘든 오류다
사실 26 - 명시적 요구사항을 설계로 옮길때 파생 요구사항이 폭발적으로 증가한다
사실 27 - 소프트웨어 문제에서 최적의 솔루션이 하나 존재하는 경우는 거의 없다
사실 28 - 설계는 복잡하고 반복적인 과정이다. 초기 설계 솔루션은 보통 잘못 되었거나 최적이 아닌 경우가 많다
153
최고의 설계자들은 설계 솔루션을 찾으려 할 때 순차적인 상향식 또는 하향식 방법으로 작업하지 않고, 중요 사항와에 중점을 둔다
문제 전반에 대한 설계 솔루션이 있는지 보려면, 설계자는 먼저 이런 의심스러운 부분, 설계가 어려워 보이는 부분을 해결해야 한다
155
설계는 예측가능한, 구조화할 수 있는, 규격화할 수 있는 프로세스와는 거리가 멀고, 너저분하고 시행착오적인 것임을 알 수 있다
최악의 설계 방법으로 대부분의 설계 초보자들이 적용하고 싶은 접근방법은 쉬운 부분을 먼저 처리하는 방법일 것이다.
사실 29 - 설계자의 기본단위와 프로그래머의 기본단위가 일치하는 경우는 거의 없다
사실 30 - COBOL은 별로 훌륭한 언어가 아니지만, 비지니스 데이터 처리에 대해서는 다른 언어도 마찬가지다
사실 31 - 오류 제거는 생명주기에서 가장 많은 시간을 소모하는 단계다
사실 32 - 프로그래머가 완전하게 테스트했다고 믿는 소프트웨어도 보통은 로직 경로의 55~60%만 테스트된 경우가 많다
사실 33 - 100% 테스트 커버리지도 결코 충분하지 않다
사실 34 - 테스트 도구는 꼭 필요하지만, 많은 경우 거의 사용되지 않는다
사실 35 - 특정 테스트 프로세스는 자동화할수 있고, 또 자동화해야 한다. 그러나 자동화할 수 없는 테스트 작업도 많다
187
현재 테스트가 자동화될 수 있다고 주장하는 사람들은 테스트 도구의 벤더들 뿐이다
사실 36 - 프로그래머가 작성한 디버그 코드는 테스트 도구에 대한 중요 보완 수단이다
사실 37 - 엄격한 검사는 첫 번째 테스트 케이스를 실행시키기도 전에 소프트웨어 제품에 포함된 오류의 90%까지 제거할 수 있다
사실 38 - 엄격한 검사도 테스트를 대체할 수는 없다
사실 39 - 출시 후 검토는 중요하지만, 거의 실행되지 않는다
사실 40 - 검토는 기술적 측면과 사회학적 측면을 모두 가지는데, 어느 쪽도 무시하면 안 된다.
205
솔루션을 검토할 때 다른 개발자가 선택한 방법의 관점에서 검토하는 것은 자신의 방법 관점에서 검토하는 것보다 어렵다. 다른 사람의 신발을 신고 먼 길을 가는 것은 쉬운 일이 아니다.
사실 41 - 유지보수는 보통 소프트웨어 비용의 40~80%를 차지한다. 따라서 유지보수는 소프트웨어 생명주기 중 가장 중요한 단계일 것이다
사실 42 - 유지보수 비용의 60%는 개선작업에 소요되는 비용이다
215
60/60 법칙 - 소프트웨어 비용의 60%는 유지보수에 사용되며, 유지보수 비용의 60%는 개선에 사용된다. 따라서 기존 소프트웨어를 개선하는 것은 큰 일이다.
사실 43 - 유지보수는 문제가 아니라 해결책이다
사실 44 - 유지보수에서 가장 어려운 작업은 기존 시스템을 이해하는 것이다
223
소프트웨어 시스템을 유지보수할 때가 되면 설계 문서는 거의 신뢰할 수 없는 상태가 된다. 그 결과, 거의 모든 역설계 작업에서는 문서를 무시하고 코드를 직접 읽는다
사실 45 - 더 좋은 소프트웨어 공학 기술로 개발하면 더 많은 유지보수가 필요하다
사실 46 - 품질은 속성의 집합이다
233
소프트웨어 품질 속성은 이식성, 신뢰성, 효율, 사용 편의성, 테스트 용이성, 이해 용이성, 수정 용이성으로 구성된다
> 그 밖에도 정의하기에 따라 다양한 품질속성이 존재한다
사실 47 - 품질을 사용자 만족, 요구사항 충족, 비용과 일정 목표 달성, 또는 신뢰성이 아니다
사실 48 - 대부분의 프로그래머가 흔히 범하는 오류가 있다
사실 49 - 오류는 뭉치는 경향이 있다
사실 50 - 소프트웨어 오류 제거에 있어 단 하나의 최상의 방법은 없다
사실 51 - 오류는 항상 남아 있다. 심각한 오류를 최소화하는 것이 목표가 되어야 한다
사실 52 - 효율은 훌륭한 코딩보다는 훌륭한 설계에 더 많은 영향을 받는다
사실 53 - 고급 언어 코드도 어셈블리어 코드의 90%에 가까운 효율을 낼 수 있다
사실 54 - 크기와 속도 사이에는 트레이드오프가 있다
264
소프트웨어 분야에 이론과 실무 사이에는 단절이 있다. 연구자들이 어떤 개념의 실질적 효용성은 알지도 못하면서 그 개념을 실무자들에게 강요할 때 그 단절을 최악이 된다.
사실 55 - 많은 연구자들이 연구보다는 옹호에 치중한다
오해 1 - 측정할 수 없는 것들을 관리할 수 없다
280
실제로는 측정할 수 없는 것은 통제할 수 없다
> 똑같은 말 아잉교?
오해 2 - 소프트웨어 품질은 관리로 해결할 수 있다
오해 3 - 프로그래밍은 비자아적이 될 수 있고, 또 되어야 한다
284
자아적 프로그래머의 대안은 뭘까? 팀 플레이어 프로그래머다. 팀 플레이어는 소프트웨어 제품을 팀의 노력, 팀의 성취로 본다. 오류보고서나 검토, 질문은 제품을 향상시키는 데 도움을 주는 자극이지, 진행을 방해하려는 위협적 공격이 아니다
오해 4 - 도구와 기술, 한 가지로 모든 문제를 해결할 수 있다
오해 5 - 소프트웨어 분야에는 더 많은 방법론이 필요하다
오해 6 - 비용과 일정을 추정하기 위해서는 먼저 LOC를 추정해야 한다
> 사실 현업에서는 대부분 직관적인 추정을 먼저 하고, 거기에 LOC를 맞춰서 형식적인 근거를 삼는다
오해 7 - 랜덤 테스트 입력은 테스트를 최적화하는 가장 좋은 방법이다
오해 8 - 보는 눈이 많은면 모든 버그는 그 깊이가 얕다
오해 9 - 과거의 비용 데이터를 살펴봄으로써 미래의 유지보수 비용을 예측할 수 있고, 시스템 교체 결정을 내릴 수 있다
오해 10 - 프로그래밍을 가르칠 때 어떻게 작성하는지 보여주며 가르친다
결론
내가 저자라면
소프트웨어 공학의 거의 모든 분야를 망라하고 있다.조직학, 사회학, 인문학적 접근도 존재하지만 대부분 소프트웨어 공학의 원론과 현업에서의 괴리, 그리고 기술적인 것들에 초점이 맞춰져 있다. 즉, 기술서에 가깝다. 55개의 사실과 10가지의 오해를 해당 분야별로 묶어 놓은 책이다. 열거식은 공돌이들이 좋아하는 포멧으로, 분류된 꼭지글들과 넘버링된 목차는 공돌이들에게 안정감을 준다. 사실 오해와 사실은 이것보다 많으면 더 많고, 적으면 더 적다고 할수도 있다. 구구절절 다 맞는 이야기고, 다 안다고 생각하는 이야기다. 하지만 대부분 현업에서 잘 실천되지 못하는 것들이기에 문제제기가 가능한 부분이다. 상식들이 지켜지는 사회가 건강한 사회라고 한다. 마찬가지로 상식이 지켜지는 소프트웨어 개발이 건강한 소프트웨어 개발이다. 상식을 아느냐 모르느냐의 문제가 아닌, 상식에 대해 작가가 어떠한 경험과 사유를 가지고 있느냐가 책의 레벨을 결정짓는다. 작가가 진부한 사실들을 얼마나 잘 재미있게 풀어내는가가 책의 퀄러티를 만든다는 말이다.
VR Left
| 번호 | 제목 | 글쓴이 | 날짜 | 조회 수 |
|---|---|---|---|---|
| 5032 | 톨스토이, 도덕에 미치다 | 박혜홍 | 2019.03.24 | 9513 |
| 5031 | #51(최종) - 그대 스스로를 고용하라 | 불씨 | 2019.03.24 | 8377 |
| 5030 | 왜 도덕인가? | 박혜홍 | 2019.03.17 | 8274 |
| 5029 | #50 프로페셔널 소프트웨어 개발 外 | 불씨 | 2019.03.17 | 7939 |
| 5028 | 칼날 위의 역사 | 박혜홍 | 2019.03.10 | 8254 |
| » | #49 소프트웨어공학의 사실과 오해 | 불씨 | 2019.03.10 | 8114 |
| 5026 | #48. 글로벌 소프트웨어를 말하다 - 지혜편 | 불씨 | 2019.03.03 | 8600 |
| 5025 | 서지문의 뉴스로 책읽기 | 박혜홍 | 2019.03.03 | 8591 |
| 5024 | 마음을 비추는 거울/ 신봉승 | 박혜홍 | 2019.02.24 | 8396 |
| 5023 | #47 글로벌 소프트웨어를 꿈꾸다 | 불씨 | 2019.02.23 | 8354 |
| 5022 | 은밀한 세계관 | 박혜홍 | 2019.02.17 | 8133 |
| 5021 | #46. 피플웨어 | 불씨 | 2019.02.17 | 7874 |
| 5020 | 하버드의 생각수업 | 박혜홍 | 2019.02.10 | 7762 |
| 5019 | #45. 언어의 온도 & 회사어로 말하라 | 불씨 | 2019.02.09 | 7729 |
| 5018 | 구본형의 마지막 수업 | 박혜홍 | 2019.01.27 | 7260 |
| 5017 | #44 구본형의 마지막 수업 | 불씨 | 2019.01.27 | 7285 |
| 5016 | #43 뼛속까지 내려가서 써라 | 불씨 | 2019.01.20 | 7269 |
| 5015 | 뼛속까지 내려가서 써라 | 박혜홍 | 2019.01.20 | 7294 |
| 5014 | 나는 쓰는대로 이루어진다 | 박혜홍 | 2019.01.13 | 7411 |
| 5013 | #42 나는 쓰는대로 이루어진다 | 불씨 | 2019.01.12 | 7377 |
