컴퓨터프로그램(소프트웨어) 또는 앱 개발이 활발해지면서 ‘개발 완성도’에 관한 분쟁도 늘고 있다. 법률상 프로그램 개발의 완성도에 관한 정의 규정이 따로 있지 않고 그 개념이나 기준도 주관적일 수 있기 때문에 발주자와 개발자 간 의견 차이에 기한 분쟁이 종종 발생한다. 판례 중에는 ‘소프트웨어 개발·공급계약은 일종의 도급계약으로서 수급인은 원칙적으로 일을 완성하여야 보수를 청구할 수 있으나, 예컨대 이미 완성된 부분이 도급인에게 이익이 되고 도급인이 프로그램 내용에 대하여 불만을 표시하며 수급인의 수정 제의를 거부하면서 계약해제 통보를 하는 등 특별한 사정이 있다면 수급인은 당시까지의 보수를 청구할 수 있다’고 판시하는 것도 있다.

이처럼 완성도에 따라 보수 지급 여부나 계약 위반 여부에 관한 판단이 달라질 수 있으므로 당사자들은 계약 체결 전부터 개발 완료 시까지 다음과 사항을 유의하여야 한다.

첫째, 발주자는 계약 체결 전에 대상 프로그램의 목적과 기능을 구체적으로 특정하여야 한다. 개발자 역시 발주자가 원하는 프로그램의 목적과 기능을 정확히 확인하여야 한다. 이를 위해 발주자와 개발자는 계약에 첨부할 ‘요구사항 명세서’를 상세하게 합의·작성하여야 한다.

둘째, 계약 체결 시에 ‘요구사항 명세서’를 특정해도 발주자와 개발자는 계약에서 정한대로 프로그램이 개발되고 있는지 ‘단계별’로 또는 ‘정기적’으로 확인할 필요가 있다. 예컨대 프로그램 개발 계약이 체결되어 프로그램이 개발·납품되었지만 요구사항 명세서대로 개발되지 않았다고 하는 반면 개발자는 계약에 첨부된 요구사항 명세서대로 개발 완료되었다고 하여 다투는 경우가 있는데, 이를 미연에 방지하려면 발주자와 개발자는 현재 개발되고 있는 것이 계약에 부합하는지 계속 확인하는 것이 바람직하다.

셋째, 개발자가 요구사항 명세서의 각 항목을 모두 이행하였지만 발주자가 원하는 기능이 충분히 구현되지 않았다고 하면서 대금지급을 거절하거나 하자보수를 요구하는 경우가 있는데, 이 때 완성도의 정의와 기준이 중요하다. 발주자의 이익을 위해서는 ‘요구사항 명세서의 각 항목을 이행하면 어떤 기능이 구현되는지’에 관하여 구체적으로 특정하고 이를 검수사항 또는 보증사항에 포함시키는 것을 고려해볼 수 있다.

넷째, 발주자에게 해당 계약의 중요한 목적이나 동기가 중요할 경우에는 계약에 표시를 해두는 것이 추후 분쟁 발생 시 유리하다. 예컨대 개발기한이 중요할 수 있는데, 발주자와 개발자는 요구사항 명세서에 기재된 항목이 개발기한 내에 이행 가능한 것인지 확인하고 표시할 필요가 있다. 사정에 따라서는 요구사항 명세서에 기재된 항목을 모두 이행하지 않더라도 개발기한 내에 일부 특정 기능이라도 우선 구현하는 것이 더 중요할 때가 있는데, 이것도 당사자 간에 특약으로 정리해두는 것이 바람직하다.

다섯째, 개발과정에서 수정·변경된 부분에 대하여 추가비용이 필요한지 여부가 다투어질 때가 있는데, 예컨대 발주자는 추가·수정 부분이 계약 범위 내이므로 추가 비용을 낼 수 없다고 하는 반면 개발자는 계약 범위 밖의 것이어서 추가 비용을 받아야 한다고 하여 분쟁이 발생하기도 한다. 이를 미연에 방지하기 위해서는 수정·변경을 하기 전에 간단하게라도 서면증거를 남겨두어야 추후 입증이 용이하다.