공공 소프트웨어사업 첫 분할발주 ´제값주기 실현

[수봉]

공공 소프트웨어사업 첫 분할발주 ´제값주기 실현´

출력하기 발표내용 복사 저작권 보호 정책

[조달청] 김상규 조달청장 | 2015-04-22 11:00

안녕하세요? 오늘은 지난해 10월 경제관계장관회의에 상정하여 마련된 소프트웨어사업 분할발주에 대한 세부 도입방안을 설명 드리겠습니다.

우리 청은 미래창조과학부, 정부 3.0 추진위원회와 공동으로 e-발주지원 통합관리시스템 구축 등 3개 공공정보화사업에 대해 설계를 우선 실시하고, 그 설계서에 따라 구현하는 소프트웨어사업 분할발주 제도를 시범적으로 도입하기로 하였습니다.

이번 시범사업은 사용자 요구사항을 명확히 하고, 계약자가 일한 만큼 제값을 받을 수 있도록 하여 국내 소프트웨어산업 생태계를 정상화하는 데 역점을 두었습니다.

시범사업의 입찰방식은 설계와 구현을 별도로 발주하는 ´설계 분할발주´와 분담이행에 의한 공동계약으로 발주하는 ´설계우선방식´ 중에서 사업기간 등 특성에 따라 선택적으로 적용할 계획입니다.

그동안 공공소프트웨어사업은 설계과정에서 사용자 요구사항이 불명확해서 빈번한 재작업이 발생하고 사업의 효율성이 떨어지는 측면이 있었습니다. 그래서 소프트웨어산업의 경쟁력 약화를 초래한다는 지적이 지속적으로 제기돼 왔습니다.

설계가 확정되지 않은 상태에서 구현사업이 진행되다 보니 최종 단계까지 사용자 요구사항이 자주 변경되는 문제점이 있었고, 이에 따라 기업은 기한 내에 과업을 마무리하기 위해 ´월화수목금금금´의 열악한 근로 환경을 감내하였습니다. 또, 과업 변경에 대한 적정 대가도 지급되지 않아 소프트웨어기업의 수익이 악화되곤 했습니다.

결과적으로 이러한 상황에서 국내 소프트웨어사업에 우수한 전문인력이 유입되지 않아 산업경쟁이 약화되는 악순환이 되풀이되어 왔습니다.

또한, 명확한 설계 없이 구현사업이 수행되어 관련 분야에 대한 지식·정보·자료 축적이 부족해지고, 국내 소프트웨어산업의 발전 기반이 약화된다는 문제점이 지속적으로 제기돼 왔습니다.

이러한 문제점을 해결하고 국내 소프트웨어산업 생태계를 정상화하는 첫걸음으로 3개 공공정보화사업에 대해 분할발주 할 계획입니다.

이를 위해 새로운 발주절차와 규정을 마련하였는데 좀 더 구체적으로 살펴보면, 우선 설계와 구현사업자 간의 설계서의 하자, 납품지연 문제 등 분쟁요인을 없애고 안정적인 계약 이행을 위해 ´소프트웨어용역 계약 특수조건´을 제정하였습니다.

또한, 사용자 요구사항을 명확히 하고 설계서의 완성도를 높이기 위해 ´소프트웨어사업 개별공정별 표준산출물´을 정의하였고, 재작업이나 과업 변경 시 적정한 대가를 지급하기 위해 ´계약금액 조정 가이드´ 등을 마련하였습니다.

아울러, 정보화 역량이 부족한 발주기관을 위해 미래부와 우리 청의 발주지원 전문가를 전담 배치하여 지원할 예정입니다.

이번 시범사업을 통해 소프트웨어사업자 간 역할분담, 사업의 효과성 등을 면밀히 검토하고, 관련규정 정비 등 소프트웨어사업 분할발주 제도를 조기에 정착시켜 나갈 계획입니다.

이번 분할발주 시범사업은 국내 소프트웨어산업 생태계 정상화를 위한 첫 단추를 꿰는 것입니다. 앞으로도 눈에 보이지 않는 소프트웨어의 가치가 제대로 인정될 수 있도록 공공소프트웨어사업 발주시스템을 혁신시키기 위해 가용한 모든 역량을 집중할 계획입니다.




[질문 답변]
※마이크 미사용으로 확인되지 않는 내용은 별표(***)로 처리했으니 양해 바랍니다.

<질문> ****

<답변> 규모는 한 3조 정도인데, 제가 알기로는 한 900건이 넘는 것으로 알고 있습니다. 전체 한 1,000건 가까이...

<질문> ***

<답변> 예, 연간. 보통 한 900몇 십 건, 1,000건이 조금 못 미치는 수준으로 알고 있습니다.

<질문> 그간에, 이런 소프트웨어사업이라는 것이 굉장히 복잡하고 할 텐데 그간에 주먹구구식으로 이루어진 이유가 뭐 있을까요?

<답변> 그것이 우리가 발주자가 내용을 정확하게 모르는 측면이 있습니다. 그래서 회사에 맡긴 것이죠. 믿고, 전에는 대기업이 했기 때문에 대기업이 처음부터 ISP부터 전부 다 하게 됐습니다. 설계·구현, 내부 안에 또 구현, 설계분석도 하고, 구현도 대기업이 다 하는 그런 구조로 갔었습니다. 어느 순간이 되면 이것이 분할돼 나와야 되는데 그것이 안 된 상태로 지금 계속 진행되고 있는 것이죠.

그런데 어떻게 보면 정부가 이니셔티브를 취해야 되는데 조금 업계의 이해관계가 얽히다 보니까 좀 지연된 측면이 있습니다. 일본도 한 2006년부터 한 것으로 알고 있습니다.

<질문> 3개 공공정보화사업 관련해서 예산이 쓰여 있습니다. 그러면 분할발주를 하게 될 경우에 예산은 크게 변동이 없습니까?

<답변> 지금 현재로는 이것이 공동이행방식을 많이 하게 될 것 같습니다. 그래서 기존 예산 내에서 하는 것으로 하고 있습니다. 왜냐하면 설계우선방식으로 하면 기존 예산 내에서 사실상 내용이 분할돼서 추진될 수 있을 것 같습니다. 추가설명은 변 국장이 하시죠. 3개 방식.

<답변> (관계자) 지금 소프트웨어 설계우선방식이나 설계분할방식에 있어서 예산 증액을 전제로 하지 않습니다. 각 부처에 배정된 예산을 가지고 설계우선해서 재작업률을 줄이면서 효과성을 높이겠다는 것이기 때문에, 이런 것이 정착이 되면 예산 당국과 설계 부분을 우선 배정한다거나 이런 부분은 더 추가적으로 협의해야 될 사항입니다.

<질문> 첫 사례 3가지, 조달청과 우정사업본부, 대구도시철도공사. 소프트웨어 분할발주에는 2가지 방식이 있다고 나와 있는데, 설계분할방식하고 설계우선방식, 이 3가지는 어떤 방식으로 진행되는 것입니까?

<답변> (관계자) 우선, 2가지는 지금 예산이 단건 예산으로 배정되어 있는 상황이라서, 3개 다. 그래서 우리가 2가지 방법이 있을 수 있습니다. 하나는 설계를 별건으로 완전히 별도의 계약 건으로 발주하는 방식이 있을 수 있고, 그다음에 공사와 같이, 같이 1건으로 발주가 되되 그 안에서 사업영역이 분할되는 그 2가지 방식이 있습니다.

그래서 그 3건에 대해서는 2가지는 공동이행방식, 그러니까 1건으로 발주가 되되 설계자와 구현사업자가 같이 내용을 분담하는 방식, 그다음에 3건 중에 1건은 설계·구현 분할방식, 완전히 별건으로 하는 방식, 이렇게 2가지 다 테스트를 해볼 생각입니다.

<질문> ***

<답변> (관계자) 그것은 아직 확정되지 않았습니다. 그것은 발주 순서대로 우리가 볼 것입니다.

<질문> ***

<답변> (관계자) 그렇습니다. 한 계약 건에 설계자와 구현사업자가 같이 들어가게 됩니다.

<답변> 두 군데에 대해.

<질문> 지금 3개 사업을 대상으로 시범사업을 실시하는 것인데, 언제부터, 본격적으로 이것이 다 하게 되는 것인지요.

<답변> 본격적으로 하게 되는 것은 사실 법, 이런 것이 고쳐져야 합니다. 그래서 우선 시범사업을 계속 넓혀갈 것이고, 금년 중에 법 개정을 추진할 계획으로 있습니다. 그것을 관계부처와 협의해서 추진토록 하겠습니다. 어느 정도 시범사업을 봐야 확신이 서잖아요, 법 개정은. 그러니까 이것을 추진하는 과정을 보면서 그렇게 하도록 하겠습니다.

<질문> ***

<답변> 아니 이해를 못한다기보다 조금 부족한 측면이 있습니다. 왜냐하면 우리가 요구사항을 명확히 한다든가 이런 것을 발주자가 해야 되는데, 좀 힘든 측면이 있었습니다.

<질문> ***

<답변> 그것은 이런 것입니다. 지금 소프트웨어가 계획이 명확히 서지 않은 다음에 구현되고 있기 때문에 중간에 추가 지시를 해도 계속 받아들여야 하는 형편입니다. 그런데 서로 간에 명확한 계약이 안 된 것이죠. 설계가 명확히 되면 추가 과업 지시를 하려면 돈을 더 주든지 뭘 해야 될 것 아닙니까? 기간을 연장해 주든지. 그런데 이때까지 서로 간에 설계 이런 것이 명확하지 않기 때문에 추가 과업을 해도 받아들여야 되고, 또 추가 과업에 대해서 추가 청구를 하기도 어려운 형편이에요. 모든 게 불명확한 상태예요. 그러니까 갑이 우선화되는 그런 상황이 되는 것이죠. 갑을 관계에 있어서. 그런데 설계도가 명확하면 갑을 관계가 있어도 서로 간에 법률적인 요청을 할 수 있는, 요구를 할 수 있는 그런 힘이 생기는 것입니다.

<질문> 설계분할발주를 한다 하더라도 설계를, 예를 들어서 설계가 3이고 구동이 7이라고 한다면 설계를 먼저 하는 것이지 않습니까? 1년이면 3개월 먼저 하는 것인데, 그러면 설계도, 예를 들어서 설계용역 발주가 예를 들어서 3억이면 그것도 늘어날 수 있는 거잖아요.

<답변> 그것도 하는 과정에서 하다 보면 서로 간에 요구사항이 명확하지 않으면 기간이 늘어날 수도 있는 것이죠. 우선 계약은 3개월로 한다 하더라도 하다 보면 늘어날 수도 있는 것이죠.

<질문> 늘어나고 비용도 추가될 수 있지 않습니까?

<답변> ***도 추가될 수 있죠. 그런데 설계도를 하는데 처음에는 3억에 하자고 했다가 하다 보면 ´이것이 아닌가 보다´ 해서 더 늘어날 수도 있는 것입니다. 그런데 설계가 명확하게 되면 구현은 그만큼 단순화되는 것입니다. 그것을 말하는 것입니다. 지금 구현과정에서 설계변경이 일어나잖아요. 그런 것이 줄어든다는 것입니다.

<답변> (관계자) 당초에 이 건에 대해서 업계의 의견을 모을 때도 예산 증액 부분에 대해서 오해가 있는 경우가 많이 있었습니다. 잠깐 설명 드리겠습니다.

이런 것입니다. 지금 예산 당국에서, 예를 들어서 한 50억짜리 소프트웨어사업 예산을 준다, 50억이라는 것에 대한 산출내역서가 없습니다. 그러니까 대충 그동안의 경험에 의해서 한 이정도 사업에는 50억 정도 되겠다, 이렇게 ***하게 예산을 주죠. 그런데 그것을 하다 보면, 예를 들면 업계에서는 이런 얘기를 많이 합니다. 당초에 요구할 때 50억이 아니라 한 70억 정도 요구해서 한 50억으로 예산이 깎이고, 그다음에 그것이 발주 절차 어쩌고 해서 한 35억으로 깎였을 때 당초에 처음 요구했던 그 요구사항 그대로 다 온다는 것입니다.

그게 무슨 소리냐 하면, 70억 요구했을 사업이 최종적으로 내려올 때는 35억에 된다는 것이죠. 그만큼 불명확하다는 것입니다. 그래서 이 설계우선방식이라는 것이 ´예산 증액을 전제로 하지 않는다´는 것이 무슨 뜻이냐면, 내가 만약 50억을 예산을 가지고 있다, 그러면 설계를 해보는 것입니다. 그러면 보나마나 설계 성과물을 내놓으면 이것까지 구현하려면 50억까지는 안 되고 한 70억이 필요하다, 이렇게 나오는 것이 거의 십중팔구일 것입니다.

자, 그런 경우에 2가지 방법이 있습니다. 그 설계물을 가지고 예산 당국에 ‘도저히 안 되겠다, 이 사업 목적을 위해서 예산 증액 해달라’고 더 요구할 수 있고, 또 하나는 사용자 요구사항을 줄이라는 것입니다. 그 금액에 맞게. 그것이 우리가 설계검증위원회를 통해서 최종 설계 성과물은 산출내역서까지 나옵니다. 과연 이 목표를 가지고 실제 구현했을 때 돈이 얼마나 들어간다는 것이 명확히 내도록 되어 있습니다. 예산 증액을 전제로 하지 않지만 더 많이 예상이 될 때는 예산 당국에 예산을 요구하거나 사용자의 요구를 줄이라는 그런 내용입니다.

<질문> ***

<답변> 사실은 설계가 잘 돼야, 모든 일반 건축물도 마찬가지입니다. 설계가 돼야 제대로 된 건축물이 나오는 것이죠. 소프트웨어도 설계를 하는 이유가 사실은 안 보이기 때문에 우리가 깎아치기라든지 후려치기나 이런 게 너무 쉽게 됩니다. 그런데 설계가 명확히 되면 그런 게 좀 힘들어진다는 그런 측면이 있습니다. 그래서 제값주기가 실현될 가능성이 높습니다.

<질문> ***

<답변> 그렇죠. 그러니까 설계변경을, 지금은 설계변경이라는 개념이 없잖아요. 설계와 구현이 같이 되고 있으니까. 그러니까 ´설계변경´이라는 개념이 생기는 것입니다. 설계변경을 하면 돈이 추가되면 돈을 더 줘야 되는 것이고 줄일 것이면 줄일 수 있는 것이고 그렇게 되는데, 지금은 설계변경이라는 개념이 없잖아요. 그게 발전이라는 것입니다.

<질문> ***

<답변> (관계자) *** 소프트웨어사업의, 우리의 것은 아니지만 일본의 연구결과에 의하면 종전에 설계우선방식이 적용되지 않은 사업에 대해서는 재작업률이 40%로 나와 있습니다. ´재작업률´이라고 하는 것은 실제 구현이 끝나고 그것을 사용자한테 제시했을 때 사용자 요구사항이 바뀌어서 다시 작업해야 되는 비율을 ´재작업률´이라고 하는데 그것을 40%로 보고 있고, 좀 부가설명 드리자면, 우리 공사에 있어서 설계도 없이 공사가 진행된다는 것은 상상을 못하지 않습니까? 하다못해 턴키공사라 하더라도 설계를 다 해놓고 그것을 검증받은 다음에 시작이 되거든요.

그런데 소프트웨어산업계에서는 그런 개념이 정착되지 않았습니다. 설계 없이 하다 보니까 최종 단계, 사용자들이 최종 단계라 하는 것은 화면상에 기능이 구현되는 것을 보는 것이 최종 단계이거든요. 그때서야 비로소 사용자들이 여러 가지 요구사항이 나오기 시작합니다. ´화면을 이렇게 바꿔 달라´, ´기능을 이렇게 바꿔 달라´ 그때는 이미 구현이 끝난 상태이거든요. 그때 사용자 요구사항을 바꾸려면 결국 재작업이 들어가야 된다는 것인데 불행하게도 그렇게 바꾸는 사용자 요구사항이 설계변경이 아니라는 것입니다. 제안요청서에 보면 사용자들이 그런 기능을 애초에 제안요청서상에 글로써 다 요구를 했기 때문에 그것은 계약조건이었던 것이죠. 그래서 그것을 사전에 이제 설계에 다 담아서 완전히 설계 성과물을 내놓고 그것에 의해서 구현하겠다는 것입니다.

<답변> 2페이지에 보면 일본의 경우에는 작은 글씨로 되어 있지 않습니까? 고딕체로 되어 있는 게 기존 40%에서 2.2% 감소되었다는 그런 게 여기 있고, 공공도 우리 한국소프트웨어산업협회에서는 한 50%가 RFP가 부정확해서 과업이 추가·변경되었다는 그런 지적이 있었습니다.

<질문> ***

<답변> 그게 아니고 전체 소프트웨어산업 예산, 총 사업비 중에서 한 30% 정도가 앞으로는 설계에 쓰일 것 아니냐, 이런 판단을 하고 있습니다. 왜냐하면 돈이 늘어나는 게 아니고 기존 사업 안에 구현하고 설계하고 같이 들어있는데 그것을 쪼개는 것이기 때문에 그 예산이 추가 증액되는 개념은 아닙니다.

<질문> ***

<답변> 중소기업이 두 가지 종류로 나눠지는 것이죠. 하나는 설계전담 부서가 생기는 것이고, 중소기업 생기고, 하나는 구현업체가 생기는 것이고 그렇게 되는 것이죠.

<답변> (관계자) 추가적으로 말씀을 드리겠습니다. 지금 우려하시는 바는 충분히 알겠는데 이런 것입니다. 그동안에 사업자 입장에서는 똑같은 금액을 가지고 140% 일을 했다고 보시면 됩니다. 똑같은 사업자가요. 결과적으로 설계서라는 것은 최종적으로 나중에 나오게 되어 있습니다. 나중에요. 그러니까 그것이 사용자 요구사항으로 계속 바뀌어가면서 최종 성과물에는 그것이 어떤 절차를 거쳐서 어떤 코딩을 거쳐서 어떤 화면으로 나왔다는 것이 최종적으로는 다 나옵니다. 그렇기 때문에 기존의 사업자들도 설계는 다 했던 것이죠. 그런데 그 설계자가, 설계라는 성과물이 애초에 사업 첫 단계에서 나와서 그대로 구현하면 재작업률이 없는데 수없이 시행착오를 거치면서 마지막 단계에, 그 시스템을 오픈을 하면서 그때 모든 도큐먼트가 그때 나온다는 것입니다. 그러니까 그 사업자 입장에서는 다시 재작업하는 비율을 줄이기 때문에 사업 효율성이 훨씬 높아진다고 볼 수 있습니다.

<질문> ***

<답변> (관계자) 아, 좀 오해가 있으신데요. 지금 보통 우리 건설공사의 설계와 같이 설계물을 제출을 하는 그것을 가지고 그중에 설계를 하나 선택을 해서 그것 가지고 구현한다면 지금 말씀이 맞습니다. 그러면 지금 공사하고 같이 설계보상비를 준다거나 이런 말씀을 하시는 것입니까?

아, 이것은 그게 아니고요. 이건 같은 경우는... SI사업자들의 계약이행능력을 평가해서 하나의 컨소시엄을 선택을 하는 것입니다. 그 안에서 하나의 계약자가 설계를 하는 것이기 때문에 지금 우려하시는 ´여러 업체가 설계를 하고 나머지는 버리고 하나 쓰는´ 이런 것이 아닙니다. 이런 계약 방법이 아닙니다.

<답변> 설계서를 공모 받아서 하는 그런 개념으로 생각하셨습니까? 그런 것은 아닙니다.

<질문> 여기 지금 시범사업 3군데 한다고 하셨는데, 지금 설명, 말씀 들어보니까 지금 현재 있는 예산 책정된 것은 기존에 해오던 관행대로 지금 예산이 책정됐을 것 아니겠어요? 그런데 지금 말씀하신 것처럼 거의 이게 재작업해서 거의 실제로는 증액이 되어야 공사, 이 사업을 받은 사업자들한테는 손해가 안 가는 게 그전의 관행이었다고 하면 여기에 대해서 기존 예산에 대해서, 이 시범사업에 대해서 예산 확보를 충분히 플렉서블하게 더 증액하고 이런 부분들이 전제가 안 된다고 하면, 반대로 업체들은 지금 말씀하신 것처럼 계약서에 있는 것만큼만 하면 되는데 그렇게 되면 수요기관에서, 수요기관 입장에서는 반대로 이 사업 시스템이 완성도가 그만큼 떨어지는 것 아닌가요? 그런 우려는 없나요, 지금? 예산이 전제가 되어야 되지 않나요?

<답변> 예산은 있는 것이죠. 있는데,

<답변> (관계자) 제가 설명 드리겠습니다. 정확한 지적이신데요. 이렇게 보시면 됩니다. 어떠한 정보화시스템을 만들어 놨을 때 그 활용도는 거의 20%에도 미치지 못한다고 얘기합니다. 그것이 모든 소리냐면 여러 가지 기능을 많이 만들어놓고 그중에 가장 중요한 핵심기능은 쓰겠지만 여러 가지 부대기능들은 매우 활용도가 떨어집니다.

지금 우리가 목표로 하고 있는 것은, 예를 들어서 30억짜리가 있다고 하면 설계에 한 10억 정도 들여서 열심히 설계를 하면 그때에 정확히 성과물의 구조가 다 나옵니다. 크기도 나오고요. 그럴 때 지금 말씀하신 바와 같이 그것이 매우 핵심적인 기능이고 도저히 포기할 수 없는 기능이라면 이제는 그 사업을 중단하고 예산 당국에 필수적인 예산을 더 요구해야 합니다.

그런데 그것이 지금 금방 말씀드린 대로 통상의 정보화시스템 같은 경우에는 전부다 100% 활용되는 것은 있을 수 없습니다. 그래서 우선순위별로 사업의 규모를 줄이라는 것입니다. 그리고 기능도 좀 떼어내고요.

그렇게 하다보면 실제로 꼭 필요한 부분만 우리 예산을 들여서 구현이 되고, 나머지 쓰지도 않을 기능들은 많이 줄어들게 될 것입니다.

<답변> 아까 말씀드린 것이 예산 증액이 필요하다는 그런 말씀입니까? 이게 왜냐하면 2개를 쪼개기 때문에요.

<질문> 아니, 예산 증액, 아까 처음에 말씀하실 때 이 예산이 예년에 했던 예산 수준이라고 하시기에 그러면 그만큼 사업에 대한 완성도가, 시스템에 대한 완성도가 떨어지지 않겠느냐, 그러니까 시범사업을 할 때는 이것에 대해서 예산을 충분히 증액할 수 있는 여지를 둔 상태에서 시범사업을 하셔야 완성도에, 발주기관에 있어서는 완성도에 있어서 큰 문제가 없지 않을까 하는 그런 생각 때문에 말씀드린 것이에요.

<답변> (관계자) ***

<질문> 예, 무슨 말씀인지 알겠어요.

<답변> 설계를 제대로 하면 여러 가지 정비가 되겠죠.

<질문> ***

<답변> 설계능력은, 아니 자기들은 다 옛날도 자기들이 다 했다는 것 아닙니까? 하청 받아서 중소기업들이. 사실 대기업이 하청을 줘서 전부 다 그런 것을 다 해왔다고 그러는 것도 있고, 또 컨설팅 업체가 많아서 충분히 할 수 있을 것으로 생각됩니다. 우리가 간담회를 해보니까 할 수 있다고 하는 데가 많습니다.

<질문> ***

<답변> 예.

<질문> ***

<답변> 아니요. 그것은 영향이 없죠. 지금은 공공사업은 대기업은 참여 못 하게 되어 있으니까. 어차피 중소기업이 다 하는 것입니다.

<질문> ***

<답변> 그렇죠, 쪼개지니까 사업이. 그런 측면이 있을 것 같습니다.

<답변> (관계자) 우리가 하나의 기대효과로 생각하고 있는 것은 여기 자료에도 있습니다만, 우리는 소프트웨어산업계에서는 ´도큐먼트´라고 표현하는데, 지식의 축적입니다. 그 부분이 지금 기자님께서 말씀하신 내용대로 그동안은 대기업이 하면서도 앞에 있는 BPR, ISP 분석설계 부분들, 앞에 있는 컨설팅 그런 부분들이 일부 대기업이 참여했지만 사실 그것도 하청을 준 적이, 전문 컨설팅 업체들 많이 활용했습니다.

그중에서 전체 사업을 총괄하는 대기업이 떨어져 나가고, 나머지 예전에 하청을 받아서 했던 그 기업들이 설계 부분에 사업자들이 들어올 것입니다. 그렇게 보면 우리가 지식을 전문화시키고 축적시킨다는 그런 부분에 있어서 훨씬 더 좋은 토양이 만들어진다고 생각합니다. 그래서 중소기업자 간에도 적은 인력 가지고 이것저것 다 손대는 것이 아니고 전문화 쪽으로 유도되는 그런 효과가 있습니다.

<질문> ***

<답변> (관계자) 지금 우리 법 개정 방향은 지금 무조건이라는 것은 있을 수 없고, 예컨대 이런 것입니다. 우리 건축공사 같은 경우도 기본적으로는 다 설계가 있어야지만 공사가 진행되지 않습니까? 그러면 당연히 설계를 우선한다는 것은 관련 건축법에 다 되어 있고, 설계라는 것도 건축사만 하도록 되어 있지 않습니까? 우리가 목표로 하는 바는 그것이지만, 지금 여러 가지 우리 국내 상황이 모든 사업을 다 그렇게 할 정도로 사업자들이 전문화되어 있거나 이것은 아닙니다. 건축사 제도처럼 그렇게 되어 있는 상황이 아닙니다.

그렇기 때문에 지금은 원칙적으로는 분할발주 쪽으로 우리가 방향을 가려고 하지만, 지금 말씀하신 대로 그것이 완전히 의무화되거나 이렇게 하기에는 아직 좀 빠른 상황입니다.

<답변> 우리가 지금 시범사업을 해봐야 명확한 방향이 나오는데, 지금 생각에는 가급적 분할하려고 하고 있습니다. 왜냐하면 분할해야 사실은 전문지식도 축적되고, 도큐멘테이션도 발달되고, 아까 말한 제값주기도 실현되기 때문에 그 방향으로 가는데, 그런데 처음 하기 때문에 어느 수준까지 처음 할지 이런 것도 고민해 봐야 할 것 같습니다.

<질문> ***

<답변> (관계자) 우려한 바가 있습니다만, 이번은 그런 개연성은 전혀 없습니다. 우선, 우리가 설계자하고 구현사업자하고 완전히 분할했습니다. 설계자가 자기의 입맛에 맞게 설계해놓고 그것을 자기가 수주할 때 혜택을 보는 이런 것을 끊기 위해서 설계자는 구현사에 못 들어오게 일단은 만들어 놓았습니다. 그것은 하나 해결이 되고요.

그다음에 이것은 최저가방식으로 할 것이 아닙니다. 이것은 제안평가방식으로 하기 때문에 그러면 설계사업자가 만들어 놓은 것을 구현사가 최저가로 하는 그런 방식으로 진행되지 않을 것입니다.

잘 써 주십시오.

<끝>

관련자료

04-22 11:53 [동영상] 동영상 다운로드

04-22 17:49 [속기] 속기자료

04-22 17:49 [속기] 속기자료