공공 소프트웨어 발주에는 납기가 밀리면 얼마를 물어내는지, 하자가 생기면 언제까지 고쳐줘야 하는지가 법으로 정해져 있습니다. 반면 민간 외주 계약서는 '착수금, 중도금, 잔금'이라는 지급 일정만 적어두고 지연과 검수, 하자에 대한 기준을 비워두는 경우가 상당히 많습니다. 그 결과 개발사는 "다 만들어 넘겼다"고 하고 발주사는 "검수를 통과 못 했으니 못 준다"며 잔금이 묶입니다.
이 다툼의 뿌리는 대부분 '무엇이 완료인지'와 '늦으면 어떻게 되는지'를 계약 전에 숫자로 합의하지 않은 데 있습니다. 발주사 PM이 계약서에 넣어야 할 안전장치는 크게 세 가지입니다. 지연배상(지체상금)율과 상한, 검수 완료의 정의와 잔금 연동, 하자담보 기간입니다. 공공 발주 기준을 민간 벤치마크로 삼으면 근거 없는 숫자를 두고 실랑이할 일이 줄어듭니다.
납기를 넘겼을 때의 배상을 계약서에 정하지 않으면, 실제로 손해가 났어도 그 금액을 입증하기가 매우 까다롭습니다. 그래서 '지체 1일당 계약금액에 일정 비율을 곱해 배상한다'는 방식이 실무에서 널리 쓰입니다. 여기서 공공 기준을 참고할 수 있습니다.
국가를 당사자로 하는 계약에 관한 법률 시행규칙 제75조에 따르면 지체상금률은 이행 지체 1일당 계약금액에 곱하는 비율로 정해지며, 용역·기타는 1천분의 1.25, 물품의 제조·구매는 1천분의 0.75, 공사는 1천분의 0.5를 적용합니다. 소프트웨어 개발 외주는 용역 성격에 가깝습니다.
중요한 것은 상한입니다. 상한이 없으면 지연이 길어질수록 배상액이 계약금액을 넘어설 수도 있어 개발사가 계약을 포기하는 역효과가 납니다. 같은 법 시행령 제74조는 지체상금 총액이 계약금액의 100분의 30을 초과할 수 없도록 하고, 초과 시 30%로 한정합니다. 또한 이미 검사·인수한 기성부분이 있으면 그 상당액을 계약금액에서 공제한 금액을 기준으로 지체상금을 계산하도록 합니다. 민간 계약에서도 '1일당 요율, 총액 상한, 기성 인수분 공제'라는 세 축을 그대로 옮겨 적으면 다툼의 여지가 크게 줄어듭니다.
지연배상보다 실제 분쟁이 잦은 지점은 '검수'입니다. 검수의 기준과 절차가 모호하면 발주사는 사소한 수정 요구를 반복하며 검수를 미루고, 개발사는 잔금을 받지 못한 채 추가 작업에 묶입니다. 계약서에는 검수를 이렇게 못 박는 것이 좋습니다.
범위가 계속 늘어나는 '스코프 크립'은 검수를 무한정 지연시키는 흔한 원인입니다. 검수 기준표와 변경관리 조항을 분리해 두면, 추가 요구는 잔금을 묶는 대신 별도 견적과 일정으로 넘어가 양쪽 모두 예측 가능해집니다.
검수를 통과해 인도한 뒤에도 결함은 나옵니다. 이때 '언제까지, 어디까지 무상으로 고쳐주는지'가 없으면 유지보수 요청이 곧 분쟁이 됩니다. 공공 기준을 벤치마크로 삼을 수 있습니다.
소프트웨어 진흥법 제60조는 소프트웨어사업자가 국가기관등과 계약을 체결한 경우, 사업을 종료한 날(검사·검수를 거쳐 최종 산출물을 인도한 날)부터 1년 이내에 발생한 하자에 대해 담보책임을 지도록 정하고 있습니다. 다만 별도로 발주한 사업은 계약으로 하자담보책임을 달리 정할 수 있습니다. 즉 민간 계약에서는 기간과 범위를 당사자가 합의해 정하는 것이 원칙입니다.
계약서에는 하자담보 기간의 시작 시점(인도일 기준), 무상으로 대응하는 하자의 범위(원래 요구사항을 충족하지 못하는 결함인지, 신규 기능 요청과는 구분되는지), 대응 시간(장애 신고 후 착수·복구 기준)을 함께 적어야 합니다. 하자 대응과 신규 개발을 구분해 두지 않으면, 담보 기간이 사실상 무상 유지보수 계약처럼 확대되어 개발사의 부담이 커지고 관계가 틀어집니다.
이 조항들은 개발사를 압박하기 위한 장치가 아니라, 양쪽이 같은 기준을 보고 일하기 위한 공통 언어입니다. 기준이 분명할수록 분쟁 대신 협업이 남습니다. 발주 계약과 검수 기준 설계를 함께 짚어야 하는 SI·업무 시스템 구축 프로젝트라면 SI 개발 서비스에서 상담 단계부터 계약 구조를 함께 검토하실 수 있습니다.