[콘텐츠칼럼]SW 제값 받으려면 근본문제 해결해야

공공사업 소프트웨어(SW) 제값 받기 문제는 정부의 많은 노력에도 아직까지 만족스럽게 해결되지 않았다. SW업계가 원하는 것은 세 가지다. SW개발에 소요되는 충분한 예산(Cost) 확보, 명확한 요구사항(Requirement)을 제공해 개발 도중 추가·변경으로 인한 비용증가 방지, 충분한 개발기간(Time) 보장이다.

충분한 예산(Cost)을 확보하기 위해 어떻게 해야 하는가. 일정금액 이상 SW사업은 예산편성 시 반드시 민간 전문업체의 객관적 비용분석 자료 반영을 의무화해야 한다. 그러나 공공 SW사업은 당해 연도에 착수, 완료하는 때가 많아 현실적으로 사전 비용분석할 수 있는 시간적 여유가 부족하다. 그렇다 보니 과거 유사사업을 토대로 대충 예산이 반영되는 때가 있다. 이런 관행을 개선하지 않으면 다른 어떤 대안도 해결책이 될 수 없다. 예산이 충분하게 반영되지 않으면 아무리 요구사항을 잘 작성하고, 기간을 충분히 준다고 해도 SW제값 받기는 요원하다.

ⓒ게티이미지뱅크

충분한 예산이 반영되더라도 현 계약예규에 명시된 비용평가 평정산식을 “입찰가격을 추정가격 100분의 80 이상과 이하”로 하게 되면 때에 따라 1000억원 예산사업은 800억원을 제시해야 비용점수 만점을 받을 수 있다. 이렇게 되면 착수하기도 전에 이미 20% 저가(低價) 수주가 되는 것이다. 이런 문제를 해결하기 위해 현 평정산식을 “입찰가격을 추정가격 100 분의 90 이상과 이하”로 상향해 최대한 적정비용을 줘야 한다. 참고로 국방사업은 2014년부터 100분의 90으로 하고 있다. 입찰가격을 추정가격의 최소 80%에서 90%로 인정하는 대신 고품질 제품을 만들도록 해야 한다. 저가로 어설프게 만드는 것보다 가능한 제값을 주고 잘 만드는 것이 더 중요하다.

요구사항(Requirement) 문제를 해결하기 위해 어떻게 해야 하는가. 요구사항 상세화(BPR/ISP)는 발주자가 안하는 것이 아니라 못한다는 것을 문제점으로 인식하고 해결책을 찾아야 한다. 현재 공공기관 SW 발주 공무원이 원하는 시스템 요구사항을 상세하게 작성하는 자체가 불가능하다. 요구사항 작성은 고도의 기술과 경험 등이 요구되기 때문이다. 그래서 발주자는 개략적인 요구사항을 RFP에 명시할 수밖에 없고, 개발도중 수정, 추가 등을 하는 것이 관행이다. 또 수정, 추가화면 소요비용을 보상하지만 현실에서는 쉽지 않다.

미래창조과학부는 정보통신산업진흥원(SW공학센터)에 SW사업 RFP 작성지원을 위해 SW발주지원센터를 운영하지만 기존 임무를 하면서 매년 수십 개 타 부처 SW사업 요구사항을 상세화하는 데 역부족이다. 자신들이 운용할 부처 직원도 요구사항 상세화가 어렵다. 하물며 공학센터에서 어떻게 타 부처 시스템 요구사항을 상세화할 수 있겠는가. 할 수 있다 하더라도 수십 개 RFP(안)을 동시에 작성할 수 없다. 가뜩이나 개발기간이 부족한데 RFP(안)이 나올 때까지 기다렸다가 1년 안에 언제 발주하고 개발하게 할 것인가.

그래서 요구사항 상세화 문제도 선진국이나 현재 국방사업에서 적용하는 것처럼 일정규모 이상 사업은 민간 전문기관에 의뢰해 작성하는 것을 제도화해야 한다. 현재 국방사업은 2013년부터 용역을 통해 요구사항(ORD:Operational Requirement Document)을 상세화한 다음 이를 RFP에 첨부하도록 의무화했다. 이는 시행착오를 줄이고, 개발비용 증가 최소화 및 품질향상에 크게 기여하고 있다.

적정 개발기간(Time)을 보장하기 위해 어떻게 해야 하는가. SW 사업 관리자의 큰 애로사항은 예산 집행을 반드시 당해 연도 연말까지 완료해야 한다는 것이다. 이렇게 되면 후반기에 발주될 경우 개발기간 부족으로 성능이 미흡하더라도 예산 이월방지를 위해 인수할 수밖에 없는 때가 있다. 따라서 적정 개발기간 보장 문제는 현행 단년도 계약 방식을 국방사업처럼 2년 이상 장기계속 계약으로 변경하여 충분한 개발기간이 보장되도록 정부(미래창조과학부, 기획재정부)가 해결해야 한다.

SW제값 받기는 세 가지 문제(예산·요구사항·개발기간)가 해결되면 상당부분 해소된다. 이런 문제점을 해결한 후 분할발주를 논해도 늦지 않다. 근본문제가 해결되지 않는 상태에서 분할발주를 하면 개발 도중 수정, 변경사항은 줄어들지 모르나 사업관리가 더 복잡하고 설계와 개발자간의 책임문제, 행정기간 추가소요로 가뜩이나 부족한 SW개발 기간이 줄어들게 돼 많은 문제를 야기하게 된다.

이성남 전 SW공학센터 전문위원 pridesoft@naver.com