Talk about Software with hani

소프트웨어 유지보수는 해결책이지 골칫거리가 아니다.

소프트웨어 컨플릭트 2.0, 로버트 L. 글래스, 위키북스

요구사항을 제대로 반영하지 못해서 생기는 문제나 품질 문제 때문에 발생하는 유지보수를 제외하더라도, 소프트웨어에서 유지보수는 필연적으로 발생한다.

시간을 X 축으로 두고 사업 환경, 비즈니스 모델, 고객의 눈높이를 그려보면 이 모든 Y의 그래프는 X축을 따라서 변한다. 따라서 변하는 요구사항을 반영하기 위하여 소프트웨어는 반드시 개선되어야 한다. 즉 유지보수는 변하는 요구사항을 반영하기 위한 해결책이지 골칫거리가 아닌 셈이다.

때로는 골칫거리다.

지금으로부터 몇 년전 이야기다. A라는 SI회사가 있었다. 일반적인 SI회사의 주요한 수입원은 SM이지만, A회사는 특이하게도 SI 프로젝트를 수행해서 성장했다. A회사가 클 수 있었던 이유는 SM을 무상으로 1년간 해주었기 때문이다. 즉 계약서 상에는 1년간 무상 유지보수라는 사항이 명기되었지만, A회사는 새로운 SI 계약을 따내기 위해서 무상 유지보수 기간이 끝났어도 개발자에게 무상 유지보수를 해주라고 암묵적으로 지시했다.

따라서 프로젝트가 끝날 때마다, 개발을 담당한 개발자의 유지보수 목록에는 유지보수를 해야하는 새로운 SW가 추가되었다. 운 좋게도 자신이 만든 SW가 잘 사용되지 않는다면 개발자는 구렁이 담 넘어 가듯이 SM에서 벗어날 수 있었지만, 시스템이 대박나는 날에는 유지보수 요청이(새로운 기능 추가 포함) 하루에도 몇 건씩 고객으로부터 나왔다. 즉 어떤 개발자가 대박 프로젝트를 3번 정도 겪고, 현재 참여하는 프로젝트가 하나 정도 된다면, 이 개발자는 보이지 않는 유지보수 프로젝트를 포함하여 총 4개의 프로젝트에 참여하는 셈이다. 따라서 숨겨진 프로젝트를 고려하지 않는다면, 프로젝트 관리 시스템에 표시되는 이 개발자의 생산성은(자발적인 초과 근무를 제외하면) 평균 이하였다. 이 개발자는 낮은 생산성때문에 상관으로부터 좋은 평가를 받지 못했다. 이런 힘든 현실 때문에 가끔은 프로 의식으로 처철히 무장한 개발자라도 자신이 만든 SW가 잘 사용되지 않기를 바라곤 했다.

회사의 정책

극단적인 예이기 하지만, 이런 이야기를 놓고 본다면 소프트웨어 유지보수는 분명히 골칫거리가 맞다. 그러나 긍정적인 관점에서 바라본다면 글래스씨가 지적하였듯이 유지보수는 해결책이기도 하다. 갑돌이도 옳고 개똥이도 옳다는 황희 정승식 논리는 아니다. 다만 유지보수가 진정한 의미의 해결책이 되기 위해서, 경영층이 혹은 관리층이 유지보수를 비즈니스 모델의 어디에 두는지 살펴 봐야 한다. A회사처럼 일종의 돈 안 쓰는 마케팅의 수단으로 생각한다면 유지보수는 골칫거리를 넘어 회사를 공중 분해 시켜 버리는 시한폭탄일 뿐이다.

A회사는 어떻게 됐을까? 유지보수 시한폭탄 때문에 지구 상에서 사라졌다고 한다.

This entry was posted on Thursday, February 8th, 2007 at 12:45 am and is filed under software. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.