4부 9번 수필은 짧지만 너무나도 재미있어서(그리고 가슴 찡하기에) 전체를 소개한다. 흥미가 당기신 분들은 소프트웨어 컨플릭트 2.0 책을 구입해서 다른 글도 읽어보시길... ;) 자, 시작한다!
옛날 옛적에 아주 거대한 난관에 봉착한 소프트웨어 실무자가 있었다. 이 실무자가 처한 곤경을 얘기하자면, 소프트웨어는 예산을 초과했고 일정을 놓쳤으며 불안정했다.
소위 소프트웨어 위기에 관한 글을 읽어보았다면 ‘별로 대단한 일이 아니잖소?’라고 말할지도 모르겠다.
하지만 이 사람에게는 대단한 일이었다. 덧붙이자면, 여러분이 생각하는 정도보다 훨씬 심각했다. 이 소프트웨어 실무자는 전산 분야에서 둘째가라면 서러울 대학을 졸업했다. 졸업 후에는 여러 해 동안 탄탄한 프로그래밍 경력을 쌓았다. 심지어는 수년 동안 실무에서 배운 지식과 학교에서 배운 지식의 정수를 조화시키는 방법까지 익혔다.
다시 말하면, 이 소프트웨어 실무자는 우수한 소프트웨어 실무자가 갖출 조건을 모두 갖춘 셈이다. 그렇다면 무엇이 잘못되었을까?
모든 문제는 맨 처음, 해결할 문제가 처음으로 등장했던 때로 거슬러 올라간다. 회사에 큰 돈을 벌어줄, 아주 중대한 문제였다. 관리층이 그렇게 말했다. 마케팅도 그렇게 말했다. 특별한 문제로 취급해야 한다는 사실에는 의심의 여지가 거의 없었다.
첫번째로 특별히 취급해야 할 사항은 특정 날짜까지 끝내야 한다는 점이었다. 관리층이 그렇게 말했다. 마케팅도 그렇게 말했다. 담당할 소프트웨어 실무자가 그 날짜까지 불가능하다고 생각해도 소용이 없었다. 무조건 날짜를 맞춰야 했다.
협조적인 태도를 보이느라, 실무자는 우려에도 불구하고 일을 시작했다. 관리층이 그의 우려에 귀를 기울이기는 했다. 실무자가 소프트웨어를 개발하는 동안, 관리층은 원하는 답이 나올 때까지 비용 예측 모델링 프로그램을 돌렸다. 그리고는 회심의 미소를 띄우며 이렇게 말했다. “봤죠? 시간 내에 소프트웨어를 개발할 수 있다니까요.”
시간이 흐르고 기한이 다가오면서, 우리의 실무자는 점점 더 초조해졌다. 처음에는 자신의 품질 기준에 맞춰서 소프트웨어를 개발했다. 요구사항을 주의 깊게 검토하고, 철저히 설계한 다음에, 프로그램을 실행하기 전에 코드 행 한줄한줄을 신중하게 검토 desk-checkin했다.
그러나 기한이 코앞에 닥치면서, 그는 우수한 기법을 생략하기 시작했다. 요행을 바라면서 테스트를 대충 해버렸다. 어떤 모듈은 테스트하지 않은 채로 통합하기도 했다. 제품은 자체 표준 테스트도 통과하지 못한 상태에서 베타 테스트로 돌입했다. 그러나 기한은 꿈쩍할 가능성이 없어 보였고, 결국 압박감을 견디다 못해 덜 중요해 보이는 사항을 희생하게 되었다.
결국 우리의 실무자는 기한을 맞추지 못했다. 프로젝트는 그가 처음 예측했던 날짜대로 그만큼 늦어졌다. 당연히 비용은 예상보다 많이 들었다. 낙관적인 일정에 맞추어 비용을 예측했으니까. 안정성? 실무자가 기한을 맞추려고 이것저것 건너뛰는 바람에 안정성도 역시 문제였다. 사람들이 말하는 소프트웨어 위기 그대로였다. 일정을 놓치고 예산을 초과하고 불안정한 소프트웨어 프로젝트가 하나 더 생겨났을 뿐이었다.
요약하자면, 옛날 옛적에 우수한 소프트웨어 실무자가 실패한 소프트웨어 프로젝트를 내놓았다. 마음 속으로는 대충 건너뛰면 안 된다는 사실을 알았다. 하지만 동시에 마음속으로는 개발 과정에서 저지른 실수가 하나뿐이라는 사실도 알았다.
그가 저지른 실수는 소프트웨어를 제작한 방식이 아니었다. 처음부터 잘못된 일정에 맞추려는 시도 자체가 실수였다.
소프트웨어 실무자가 관리층으로부터 성과 평가를 받았을 때, 그는 실패한 프로젝트로 인해 자신의 업무 평가가 낮아졌음을 발견했다.
그는 궁금했다. 나와 같은 입장에서 괴로워하는 사람들이 얼마나 많을까? 순전히 잘못된 예측이나 대충 꾸며댄 예측 탓으로 생기는 소프트웨어 위기가 얼마나 많을까?
아직도 그는 궁금해한다.
"소프트웨어 컨플릭트 2.0: 시대를 뛰어넘는 즐거운 논쟁" 역자 박재호 올림
라벨: 소프트웨어 컨플릭트, 프로젝트 실패
