하자보수와 유지보수는 무엇이 다르고, 경계는 어디입니까?

한 문장으로 가르면

하자보수와 유지보수는 둘 다 「납품 뒤에 시스템을 고치는 일」이라 한데 묶이기 쉽습니다. 그러나 원인과 책임, 비용의 근거가 다릅니다. 이 차이를 계약 단계에서 정리해 두지 않으면 납품 직후 몇 달 동안 요청 하나하나가 협상이 됩니다.

정리하면 하자는 「약속한 것이 안 되는 것」이고, 유지보수는 「약속 이후에 달라진 것」에 대응하는 것입니다. 그래서 경계를 가르는 기준은 언제나 인수 때 합의한 요구사항과 검수 기준입니다. 이 기준이 문서로 남아 있지 않으면, 같은 오류를 두고 한쪽은 하자라 하고 다른 쪽은 개선이라 해도 판정할 근거가 없습니다.

예를 들어 「모바일에서 표가 잘린다」는 같은 현상도, 인수 때 모바일 화면을 지원 범위에 넣었다면 하자이고 넣지 않았다면 새 요구입니다. 현상만 보고 분류하려 하면 끝이 나지 않으므로, 먼저 그때 무엇을 약속했는지를 찾는 것이 순서입니다.

법이 정한 기본값

개발 계약이 민법상 도급에 해당한다면, 민법은 수급인에게 하자에 대한 담보책임을 지웁니다. 제667조는 완성된 목적물이나 완성 전의 성취된 부분에 하자가 있으면 도급인이 상당한 기간을 정해 하자의 보수를 청구할 수 있고, 하자 보수(고쳐 달라는 청구)에 갈음하여 또는 그와 함께 손해배상을 청구할 수 있다고 정합니다. 다만 하자가 중요하지 않은데 보수에 과다한 비용이 드는 경우는 예외입니다.

조문이 「상당한 기간을 정해」 청구하도록 하고 있으므로, 실무에서는 요청에 수정 기한을 함께 적어 두는 편이 안전합니다. 하자 보수를 요청할 때는 언제, 어떤 화면에서, 어떤 입력으로 문제가 생겼는지와 재현 방법을 적어 메일이나 문서로 보내십시오. 전화로만 요청하면 나중에 요청 시점과 내용을 증명하기 어렵습니다.

제670조는 하자의 보수, 손해배상 청구와 계약 해제를 목적물의 인도를 받은 날부터 1년 안에 하도록 정하고(인도가 필요 없는 일이라면 일이 끝난 날부터), 제672조는 담보책임을 지지 않기로 약정했더라도 수급인이 알면서 고지하지 않은 사실에 대해서는 책임을 면하지 못한다고 정합니다.

다만 소프트웨어 개발 계약이 언제나 민법상 도급으로만 판단되는 것은 아니고, 실무에서는 계약서에서 하자 대응 기간과 범위를 따로 정하기도 합니다. 그러므로 하자 대응 기간, 대상, 요청 방법, 수정 기한을 계약서에 명시해 두는 편이 분명합니다. 금액이 크거나 다툼이 이미 생긴 경우라면 법률 자문을 받으시기 바랍니다.

경계가 흐린 사례

다툼이 생기기 쉬운 것은 경계에 걸친 사례입니다. 판단의 갈림 기준을 함께 보면 정리가 쉬워집니다.

표의 「갈림 기준」 열이 비어 있는 상태로 계약하면 모든 사례가 협의 대상이 됩니다. 반대로 지원 환경 목록, 성능 기준, 보안 기준을 검수 기준에 넣어 두면 상당수의 사례를 문서만으로 분류할 수 있습니다.

보안 취약점은 따로 생각해 둘 필요가 있습니다. 납품 당시 이미 알려진 유형의 취약점을 그대로 두었다면 하자로 볼 여지가 크지만, 납품 뒤 새로 공개된 취약점에 대응하는 일은 성격상 유지보수에 가깝습니다. 어느 쪽이든 발견 즉시 조치가 필요하므로, 책임 분류는 조치 뒤에 하고 조치 자체는 미루지 않는다는 원칙을 계약에 넣어 두는 편이 안전합니다.

유지보수 계약에 적을 것

하자 대응 기간이 끝나면 시스템을 계속 돌보는 일은 유지보수 계약으로 넘어갑니다. 과학기술정보통신부가 배포하는 SW 분야 표준계약서에도 정보시스템 유지관리와 상용 소프트웨어 유지관리 계약서가 따로 있을 만큼, 유지보수는 구축과 다른 계약입니다. 계약서에는 다음 항목을 확인하십시오.

• 범위: 장애 대응, 오류 수정, 작은 변경, 보안 패치·버전 갱신, 모니터링 중 무엇이 들어가는가
• 제외: 새 기능 개발과 화면 개편은 별도 견적인가
• 작업량의 단위: 정액 범위, 건별, 시간 단위 중 무엇으로 계산하는가
• 요청 창구와 우선순위를 정하는 방식
• 작업 내역을 보고하는 주기와 형식
• 하자 대응 기간과 겹칠 때 어느 쪽이 먼저인가
• 계약이 끝날 때 넘겨받을 최신 소스와 문서

유지보수를 만든 곳이 아닌 다른 업체에 맡긴다면, 하자 대응 기간 안에 원래 개발사로부터 인수인계를 받는 일정도 함께 잡아야 합니다. 하자 대응 기간이 끝난 뒤에는 원래 개발사에 설명을 요청할 계약상 근거가 약해지기 때문입니다.

하자 대응 기간이 끝나기 전에

하자 대응 기간의 마지막 무렵에 할 일이 있습니다. 그동안 쌓인 불편 사항을 모아 하자와 개선으로 나누고, 하자로 분류한 항목은 기간 안에 서면으로 요청합니다. 기간이 끝난 뒤 발견된 결함은 원인이 납품 당시에 있었더라도 계약상 처리 근거가 약해질 수 있기 때문입니다. 그리고 유지보수 계약의 시작일을 하자 대응 기간의 종료일과 맞춰, 아무도 책임지지 않는 공백이 생기지 않게 합니다. 하자로 요청한 항목과 처리 결과는 목록으로 남겨 두면, 다음 유지보수 업체가 시스템의 약한 곳을 파악하는 자료로도 쓰입니다.

빌드업웍스도 구축 완료 뒤 일정 기간 무상으로 하자에 대응하고, 새 기능 추가나 범위 변경은 별도로 협의하며, 그 이후의 개선과 운영은 운영 · 개선 서비스로 이어 갑니다.

참고 자료

• 민법 제667조(수급인의 담보책임) — 국가법령정보센터
• 민법 제670조(담보책임의 존속기간) — 국가법령정보센터
• 민법 제672조(담보책임면제의 특약) — 국가법령정보센터
• 과학기술정보통신부 — 소프트웨어(SW)분야 표준계약서(6종) 활용 안내