커뮤니티

Focus

[시론] 턴키와 설계시공일괄의 차이

페이지 정보

작성자 경희대학교 댓글 0건 조회 4,272회 작성일 10-08-26 09:51

본문

이복남 (한국건설산업연구원 연구위원)

  201008170839197490525-2-12949.jpg  
턴키와 설계시공일괄이 같은 방식인지 혹은 차이가 있는지에 대해 논란이 됐던 적이 있다. 논란 여부를 떠나 현재는 ‘턴키=설계시공일괄’이라는 한국적 상황인식이 고착되어 있는 느낌이다. 한국 밖 글로벌 시장에서는 ‘턴키는 turnkey 혹은 EPC‘방식으로 이해되고 있고 설계시공일괄방식은 엄연히 ’design build(DB)’방식으로 이해되고 있다. 분명 차이가 있다는 뜻이다. 국내 공공공사에서 ‘DB방식’을 ‘턴키방식’으로 내세우는 데는 이유가 있는 것 같다. DB방식에서 발주자가 분담해야 할 책임을 턴키라는 용어를 앞세워 계약자에게 일방적으로 전가시키기 때문이다.

 턴키와 DB방식에 공통점도 있다. 설계와 시공이 단일계약으로 처리된다는 점이다. 하지만 공통점보다 차이점이 많다. 턴키는 말 그대로 시작과 끝이라는 의미를 갖고 있어 ‘key’가 핵심 키워드다. 그러나 DB방식은 ‘시작과 끝’이 발주자와 계약자가 함께한다는 점에서 턴키방식과는 근본적 차이가 있다.

 ‘DB’방식이 턴키와 크게 다른 차이점 몇 가지를 살펴보자. 첫째 턴키방식에서 발주자가 입찰자에게 제시하는 기술기준, 품질과 성능요건 등에 큰 차이가 있다. 턴키방식에는 발주자는 설계 혹은 시공을 위한 입력(input)요건보다 목적물(output)에 대한 기준과 규격 중심으로 서술한다. 당연히 발주자가 요구하는 조건 미달 시 발주자는 인수를 거부하는 수단으로 ‘key’를 받지 않는다. 그러나 ‘DB’방식에서는 ‘key’가 없다. 따라서 발주자는 설계와 시공을 위한 입력(input) 정보에 상당한 비중을 둔다. 발주자가 개념설계와 기본설계에 버금가는 상세한 자료(data)를 제공한다. 발주자가 제공한 자료에 대한 신뢰도도 발주자가 책임지는 구조다. 이런 이유 때문에 국내 공공공사와 같이 ‘기본설계 턴키’라는 한국식 용어는 사용되지 않는다. 미국에서 흔히 ‘bridging’방식을 ‘DB’와 함께 사용하는 이유도 여기에 있다.

 둘째 입찰심의방식에도 큰 차이가 있다. 턴키의 심의는 완성상품의 성능과 품질, 공기와 완성공사 투입원가를 보게 된다. 예를 들어 발전소의 경우 ㎾당 운영비가 얼마인지, 건설비가 얼마인지, 소내전력소비가 얼마인지를 입찰자가 보증하는 값을 비교하게 된다. 단순 가격 비교가 어려운 이유다. 그러나 DB방식에서는 발주자가 제시한 기준을 어떻게 맞출 수 있는지와 생산기술 수준과 공법, 공기와 가격 등을 종합 평가하게 된다. 즉, 턴키가 완성상품 단위로 평가하는 것과 달리 생산과정에 훨씬 큰 비중이 걸린 심의다.

 셋째 적용 대상의 차이다. 글로벌시장에서 턴키방식 대상은 시스템이 중심인 플랜트공사가 대부분이다. 반면 DB방식은 도로나 철도, 건물 등 단일시설 중심이다. 이 의미는 공항시설에서 여객청사나 활주로 등 단일 시설물이 DB대상이지 공항 전체가 턴키 혹은 DB 대상은 될 수 없다는 뜻이다. 즉, 공항운영시스템에 대한 성능 보장은 발주자 몫이라는 뜻이다.

 국내 공공공사에 적용하는 DB는 턴키방식이 아님에도 불구하고 턴키방식에서의 일괄책임을 입찰자에게 일방적으로 전가시켜 놓은 셈이다. 즉, 발주자가 입찰자에게 제공해야 할 기본설계 정보와 지반상태 등에 대한 정보를 제공하지 않고 모든 것을 입찰자에게 비용 부담은 물론 결과에 대한 책임까지 지게 만들어 놓은 것이다. 턴키라는 명분으로 DB입찰자에게 무한책임을 강요하는 방식으로 둔갑한 것이다.

 발주자가 턴키라는 명분으로 DB방식에서 무임승차(?) 하는 데는 국계법에 포함된 제도가 큰 몫을 하고 있다. 국내 업체들이 해외시장에서 DB 혹은 턴키 입찰에 참가하는 비용은 국내 DB방식과 비교가 안 될 정도로 적다. 입찰서류를 준비하는 데도 국내만큼 길지 않다. 그러나 발주자가 입찰서를 평가하는 기간은 국내에 비해 훨씬 길다. 발주자의 책임이 크기 때문이다. 입찰서 심의기간이 국내와 비교해 훨씬 길고 심층적인 이유는 사업에 대한 위험을 일방통행식이 아닌, 분담한다는 데 있는 것이다.

 DB방식은 턴키가 아닌 DB방식답게 혹은 글로벌시장과 호환성을 갖게 만들어야 한다. 발주자의 기능과 역할, 그리고 책임을 ‘투명성과 객관성’이라는 명분으로 분리시켜서는 절대 안 된다. 범법자를 처벌하기보다 면책을 위해 외부 심의위원 수 조정 수단은 일시적 방편에 불과하다. 필자가 2002년 미국의 발주세미나에서 던진 질문 중 ‘DB가 영어로 turnkey인가’에서 ‘한국에도 영어를 사용하느냐’로 답 대신 질문으로 되돌아 온 이유를 생각해야 할 때다. 발주기관의 책임을 무시한 발주방식은 절대 성공할 수 없기 때문이다.

댓글목록

등록된 댓글이 없습니다.