우리가 미처 알지 못한 소프트웨어 공학의 사실과 오해 | 원제 Facts and Fallacies of Software Engineering (2003)
로버트 L. 글래스 (지은이), 윤성준, 조홍진 (옮긴이) | 인사이트
은빛 총알은 있는가? 없다.
—-
어떤 문제에 맞춰진 컴포넌트를 다른 목적에 이용할 수 있도록 그 기능을 충분히 일반화시키는 것은 거의 불가능하다(93)
소프트웨어 시스템을 20-25% 또는 그 이상 수정해야 한다면 처음부터 다시 새로운 제품을 구축한느 것이 비용도 적게 들로 작업도 쉽다는 것이다. 사실, 그 퍼센트가 아주 낮다는 것은 놀라운 일이다.(109)
왜 그렇게 사람이 중요한가? 복잡성을 극복하는 데는 상당한 사고력과 기술이 필요하기 때문이다.(116)
왜 “기존의 제품을 이해하는 것”이 소프트웨어 유지 보수에서자장 중요하고도 어려운 작업인가? 하나의 문제를 해결하는 데도 적용할 수 있는 접근방법이 매우 많기 때문이다.(117)
최고의 설계자들이 모인 방에서 두 명의 설계자가 동의한다면 그게 다수 의견이다.(150)
한 건축업자는 대부분의 고객이 개축과정에서 지나친 의견 충돌로 이혼한다고 내게 말해 주었다.(217)
아무도 코드를 읽는 방법에 대한 책을 어떻게 써야 할 지 모르기 때문이다… 코드를 읽기가 매우 어려운 작업이기 …(320)
사람은 소프트웨어를 구축하는 데 있어 중요하다. … 도구도 중요하다, 기술 또한 중
요하다. 프로세스도 물론 중요하다. 그러나 이런 것보다 더 중요한 것이 사람이다.
(31)
프로그래머 실무 능력의 현저한 개인차다. … 그 차이가 28배까지 달라질 수 있다…
(37)
우리는 프로그래머 없이 프로그래밍할 수 있는 4세대 언어, 프로그래밍을 자동화하는
CASE 도구, 소프트웨어를 구축하는 최상의 방법인 객체 지향 기술, 차세대 방법론인
XP 등 오늘날 도약이라 부를만한 어떤 것을 가지고 있을 수 있다. …이런 것들이
우리의 소프트웨어 구축 능력을 극적으로 향상 시키지는 못한다. Brooks 의 말을
빌어 간단명료하게 말하자면 “지금은 도약의 시대가 아니고, 그런 시대는 앞으로는
아마 다시는 오지 않을 것이다.” (47)
한 제약회사가 SAP 패키지를 성치한 다음 이로 인한 이득이 즉각적으로 나타날 것이라
생각하고는 몇 몇 계약자에게 낮은 가격으로 입찰했다.학습 곡선 기간은 늦었고, 이
회사는 파산과 소송의 소용돌이 속에서 사라졌다. 새로운 접근방법이 처음부터 이득을
준다는 가정은 매우 위험하다는 게 여기서 얻을 수 있는 교훈일 것이다. (55)
프로젝트의 시작 부분이다. 첫 단계에서 솔루션이 접근해야 할 요구사항을 정하는 것
이다. 좀 더 간단히 말하면, 요구사항 정의는 무슨 문제를 풀지에 대해 생각하는 것이
다. 그런데 풀고자 하는 문제가 무엇인지 모른다면 어떻게 솔루션을 만드는 데 드는
비용과 시간을 추정할 수 있겠는가?(66)
기존 소프트웨어를 수정하는 것이 어려운 데는 또 다른 근본적인 문제가 있다.
소프트웨어 유지보수 작업을 연구한 사람들은 소프트웨어 수정 작업을 압도할 정도로
훨씬 어려운 작업이 있다는 것을 알게됐다. 그것은 ‘기존 솔루션을 이해하는 것’이다.
원래 그 솔루션을 구축한 프로그래머 조차도 몇 달이 지난 후에는 그 코드를 수정하는
데 어려움을 느낀다는 것은 소프트웨어 분야에서 잘 알려져 있다. (105)
