젊은 프로그래머 시절 소프트웨어 개발 비용의 70%가 유지보수에 들어간다는 끔찍한 보고를 들었던 기억이 납니다. 70%라고요! 우리가 얼마나 형편없는 일을 하고 있기에 물건을 만들어 놓고도 그것을 유지하는 데만 두 배의 비용을 지출해야 하는 걸까요?
소프트웨어는 일종의 영구 운동 기계처럼 한 번 만들어지면 영원히 변함없이 작동해야 한다는 정신적 모델은 실제로 일어나는 일과 정반대이며, 일어나야 하는일 역시 마찬가지입니다. 시스템의 미래 가치는 어제의 추측이 아니라 오늘의 현실에서 드러납니다.
결합이 소프트웨어 개발에 영향을 미치는 방식 이제 결합의 중요성을 이해할 준비가 되었습니다. 결합과 응집력에 관한 최초의 연구인 Structured Design에서 Ed Yourdon과 래리 콘스탄틴은 소프트웨어 설계의 목표는 소프트웨어의 비용을 최소화하는 것이라고 가정했습니다(가치를 극대화하는 것도 목표이지만 이 부분은 나중에 다루도록 하겠습니다). 하지만 그 비용은 무엇일까요?
70%라는 추정치는 너무 낮은 것으로 밝혀졌습니다. 창의력을 발휘하면 최종 개발 비용의 몇 퍼센트만 투자해도 가치를 창출하는 소프트웨어를 출시할 수 있습니다. 그렇게 하는 것이 모두에게 이익이 됩니다. 실제 사용으로부터 피드백을 빨리 얻을수록 중요하지 않은 행동에 소비하는 시간/비용/기회를 줄일 수 있습니다.
제가 '콘스탄틴의 등가성'이라고 이름 붙인 첫 번째 용어는 소프트웨어의 비용이 소프트웨어 변경 비용과 거의 같다는 것입니다. 물론 소프트웨어를 '변경'한다고 말하기까지 짧은 기간이 있긴 하지만 누가 신경 쓰겠습니까? 그 기간은 경제적으로 중요하지 않으니까요. 그래서
비용(소프트웨어) ~= 비용(변경)
이를 그래픽으로 생각해보는 또 다른 방법도 있습니다. (다음은 실제 데이터가 아니라 문제를 생각하는 또 다른 방법일 뿐입니다. 적절히 조정하세요.)
소프트웨어의 수명에 따른 누적 비용( )을 그래프로 나타내면 물류 곡선과 같은 것을 얻을 수 있습니다(그림 30-1). 출시 전 기간은 총 시간의 작은 부분과 총 비용의 작은 부분을 모두 나타냅니다.
그림 30-1. 변경이 비용의 대부분을 차지함을 보여주는 누적 비용의 로지스틱 곡선
변화의 비용에 대해 어떻게 말할 수 있을까요? 모든 변화가 동등할까요? 물론 그렇게 질문한다면 그렇지 않습니다. 우리는 시스템의 동작을 조금씩 변경하면서 부딪힐 수 있으며, 그 비용은 모두 거의 동일합니다. 그러던 어느 날 표면적으로는 이전의 모든 변경 사항과 유사한 변경 사항을 적용했는데, 이 변경 사항은 우리의 얼굴을 날려버립니다. 한 단위의 비용이 아니라 10, 100, 1000 단위의 비용이 들게 ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month, and much more.
