자랑스런 대우인
[디지털타임스 광장 칼럼] 박재호 와이즈넛 대표
김동휘 10.09.03 조회수 10220
[DT 광장] SW 설계-시공 분리발주 하자
입력: 2010-09-02 21:01
---------------------------------------------------------------
인물소개 : (주)대우 출신
현 와이즈넛 대표
현 대우세계경영연구회 기획위원
----------------------------------------------------------------
최근 대중소기업간의 상생문제가 우리 사회의 주요 이슈로 떠오르는 가운데 소프트웨어 업계도 긍정적인 상생관계가 정립됐으면 하는 바람과 기대가 높다.
그동안 소프트웨어 개발사업을 육성하기 위한 정부의 수많은 정책적 노력에도 불구하고 소프트웨어 종사자들이 느끼는 성과는 여전히 부족하다. 더구나 소프트웨어 업계는 고급인력의 이공계 회피현상으로 인해 인력확보에 어려움을 겪고 있는 가운데 최근 대기업들의 중소기업 소프트웨어 인력 대거 흡수로 인해 어려움이 가중돼 대중소기업 상생노력을 다시 생각하게 한다.
소프트웨어 업계가 우수한 젊은 인재로부터 왜 외면을 당하는가? 왜 소프트웨어 업계는 4D업종으로 취급당해야 하는가?
이에 대한 근본적인 해결 없이는 소프트웨어 업계 발전은 기대하기 힘들다고 생각된다. 그래서 그 근본적인 해결책이 무엇인지 생각해 본다.
첫째는 소프트웨어 사업도 돈이 될 수 있다는 믿음을 줘야 한다. 1990년대 말 벤처 전성기 때 많은 인재들이 광적으로 몰려들었다가 돈이 안 된다고 판단하니 썰물같이 사라진 사례를 보면 알 수 있다. 이를 위해서는 무엇보다 소프트웨어가 제 값을 받아야 한다.
소프트웨어는 눈으로 볼 수 없어서 가치 인정을 제대로 못 받고, 기능적 가치나 효용에 의해서가 아니라 단순히 투입한 인건비로 가치가 책정되는 문제점도 있다. 소프트웨어도 엄연히 용량과 기능의 차이가 있음에도 불구하고 그것을 인정하지 않는다. 마치 800CC경차와 최고급 5000CC급 승용차의 가치를 인정하지 않고 자동차이니 같다고 생각하는 것과 다를 바 없다.
또한 발주와 하청구조에도 문제가 많다. 그동안 정부도 기능점수제 도입과 입찰 평가시 기술점수비율 상향, 소프트웨어 분리입찰제도 시행 등 많은 노력을 했으나 아직도 미흡하기 그지없다. 최근 우려되는 것은 공개경쟁입찰에서 기술평가와 가격평가비율을 종합 평가해서 낙찰자를 선정해야 함에도 불구하고 기술평가에서 2~3개 업체를 우선협상자로 지정해 2차적으로 최저가 경쟁입찰을 시킴으로써 최고급 5000CC급 승용차를 800CC 경차가격으로 납품케 하는 것과 같은 부당한 입찰관행이다.
그래도 아이폰 덕분에 소프트웨어의 중요성이 인식되게 된 것이 그나마 다행이다.
두번째로 해결해야 할 제도적 해결책은 발주와 개발방법의 개선이다. 현재의 소프트웨어 개발사업은 제안요청서(RFP)나 제안서를 토대로 요구사항을 분석해 설계와 개발을 개발사업자가 동시에 진행하지만 발주자와 개발자와의 시각 차이, 수차례의 요구사항 수정 및 번복에 따른 재개발로 인한 낭비요소, 불만, 소프트웨어 개발자의 좌절, 그리고 분쟁의 가능성이 지속된다.
물론 소프트웨어 개발사업을 위해 정보화전략계획(ISP)이나 업무프로세스재설계(BPR) 등 컨설팅 단계도 있고 요구분석단계를 거쳐 개발설계도 만들지만 결정적으로 건설업과 같이 설계자와 시공자가 분리돼 있지 않아 설계도가 수시로 수정되고 변경돼 책임소재를 명확히 하기조차 어렵다는 것이다.
그리고 그 설계도라는 것이 세부적인 사항까지 설계되지 않아 부문별 개발자가 임의적으로 설계를 해 가면서 개발하다보니 논란의 소지가 많은 것이 현실이다.
따라서 이러한 문제점을 근본적으로 해결하기 위해서는 소프트웨어 발주시 소프트웨어 설계부문과 개발시공부문을 구분해 발주하도록 제도화해야 한다. 발주자는 요구사항을 명확히 제시하고, 설계자는 발주자의 요구사항을 반영해 사전의 계획설계와 기본설계단계를 거쳐 최종적으로 상세 실시설계를 완성토록 해야 한다.
그리고 실시설계가 완료되면 소프트웨어 개발사업자를 대상으로 개발 프로젝트를 발주하게 한다는 것이다. 만약 설계확정 후 추가적인 수정사항이나 변경사항이 있을 경우 설계자로 하여금 설계에 반영토록 하되 추가비용이 발생되는 경우 추가 부담케 함으로써 각자가 공정한 역할과 책임을 지게 하는 것이다.
소프트웨어 업계 발전방향의 지혜를 건설업의 업무체계에서 찾아보자는 것이다.
입력: 2010-09-02 21:01
---------------------------------------------------------------
인물소개 : (주)대우 출신
현 와이즈넛 대표
현 대우세계경영연구회 기획위원
----------------------------------------------------------------
그동안 소프트웨어 개발사업을 육성하기 위한 정부의 수많은 정책적 노력에도 불구하고 소프트웨어 종사자들이 느끼는 성과는 여전히 부족하다. 더구나 소프트웨어 업계는 고급인력의 이공계 회피현상으로 인해 인력확보에 어려움을 겪고 있는 가운데 최근 대기업들의 중소기업 소프트웨어 인력 대거 흡수로 인해 어려움이 가중돼 대중소기업 상생노력을 다시 생각하게 한다.
소프트웨어 업계가 우수한 젊은 인재로부터 왜 외면을 당하는가? 왜 소프트웨어 업계는 4D업종으로 취급당해야 하는가?
이에 대한 근본적인 해결 없이는 소프트웨어 업계 발전은 기대하기 힘들다고 생각된다. 그래서 그 근본적인 해결책이 무엇인지 생각해 본다.
첫째는 소프트웨어 사업도 돈이 될 수 있다는 믿음을 줘야 한다. 1990년대 말 벤처 전성기 때 많은 인재들이 광적으로 몰려들었다가 돈이 안 된다고 판단하니 썰물같이 사라진 사례를 보면 알 수 있다. 이를 위해서는 무엇보다 소프트웨어가 제 값을 받아야 한다.
소프트웨어는 눈으로 볼 수 없어서 가치 인정을 제대로 못 받고, 기능적 가치나 효용에 의해서가 아니라 단순히 투입한 인건비로 가치가 책정되는 문제점도 있다. 소프트웨어도 엄연히 용량과 기능의 차이가 있음에도 불구하고 그것을 인정하지 않는다. 마치 800CC경차와 최고급 5000CC급 승용차의 가치를 인정하지 않고 자동차이니 같다고 생각하는 것과 다를 바 없다.
또한 발주와 하청구조에도 문제가 많다. 그동안 정부도 기능점수제 도입과 입찰 평가시 기술점수비율 상향, 소프트웨어 분리입찰제도 시행 등 많은 노력을 했으나 아직도 미흡하기 그지없다. 최근 우려되는 것은 공개경쟁입찰에서 기술평가와 가격평가비율을 종합 평가해서 낙찰자를 선정해야 함에도 불구하고 기술평가에서 2~3개 업체를 우선협상자로 지정해 2차적으로 최저가 경쟁입찰을 시킴으로써 최고급 5000CC급 승용차를 800CC 경차가격으로 납품케 하는 것과 같은 부당한 입찰관행이다.
그래도 아이폰 덕분에 소프트웨어의 중요성이 인식되게 된 것이 그나마 다행이다.
두번째로 해결해야 할 제도적 해결책은 발주와 개발방법의 개선이다. 현재의 소프트웨어 개발사업은 제안요청서(RFP)나 제안서를 토대로 요구사항을 분석해 설계와 개발을 개발사업자가 동시에 진행하지만 발주자와 개발자와의 시각 차이, 수차례의 요구사항 수정 및 번복에 따른 재개발로 인한 낭비요소, 불만, 소프트웨어 개발자의 좌절, 그리고 분쟁의 가능성이 지속된다.
물론 소프트웨어 개발사업을 위해 정보화전략계획(ISP)이나 업무프로세스재설계(BPR) 등 컨설팅 단계도 있고 요구분석단계를 거쳐 개발설계도 만들지만 결정적으로 건설업과 같이 설계자와 시공자가 분리돼 있지 않아 설계도가 수시로 수정되고 변경돼 책임소재를 명확히 하기조차 어렵다는 것이다.
그리고 그 설계도라는 것이 세부적인 사항까지 설계되지 않아 부문별 개발자가 임의적으로 설계를 해 가면서 개발하다보니 논란의 소지가 많은 것이 현실이다.
따라서 이러한 문제점을 근본적으로 해결하기 위해서는 소프트웨어 발주시 소프트웨어 설계부문과 개발시공부문을 구분해 발주하도록 제도화해야 한다. 발주자는 요구사항을 명확히 제시하고, 설계자는 발주자의 요구사항을 반영해 사전의 계획설계와 기본설계단계를 거쳐 최종적으로 상세 실시설계를 완성토록 해야 한다.
그리고 실시설계가 완료되면 소프트웨어 개발사업자를 대상으로 개발 프로젝트를 발주하게 한다는 것이다. 만약 설계확정 후 추가적인 수정사항이나 변경사항이 있을 경우 설계자로 하여금 설계에 반영토록 하되 추가비용이 발생되는 경우 추가 부담케 함으로써 각자가 공정한 역할과 책임을 지게 하는 것이다.
소프트웨어 업계 발전방향의 지혜를 건설업의 업무체계에서 찾아보자는 것이다.
;)