납품하고 두 달이 지난 어느 날 고객사에서 연락이 옵니다. 특정 조건에서 주문 목록이 빈 화면으로 나온다는 내용입니다. 고객은 당연히 무상 하자보수라고 생각하고, 개발사는 조건을 하나 더 붙여 달라는 새 요청으로 읽습니다.
이 다툼은 기술 문제가 아닙니다. 계약서에 하자와 유지보수를 나누는 문장이 없거나, 있어도 기준 날짜와 기준 문서를 지정하지 않아서 생깁니다. 나눌 기준이 없으면 결국 목소리 큰 쪽이 이깁니다.
두 달 뒤 발견한 문제는 세 가지 질문으로 갈립니다
첫째, 하자담보책임 기간 안인가입니다. 둘째, 오류를 고치는 일인가 새 요구를 반영하는 일인가입니다. 셋째, '원래 이렇게 동작해야 한다'는 기준이 어느 문서에 적혀 있는가입니다.
두 달이면 기간은 대부분 통과합니다. 그래서 실제 승부는 두 번째와 세 번째에서 납니다. 계약서가 이 두 질문에 답을 주지 못하면 무상이냐 유상이냐는 협상으로 넘어갑니다.
1년은 검수확인서에 적힌 날짜부터 셉니다
소프트웨어 진흥법 제60조 제1항은 국가기관등과 소프트웨어사업 계약을 체결한 경우, 사업을 종료한 날부터 1년 이내에 발생한 하자에 담보책임이 있다고 정합니다. 법은 '사업을 종료한 날'을 괄호로 다시 정의합니다. 시험과 검사를 수행하여 최종 산출물을 인도한 날입니다.
즉 기산점은 개발이 끝났다고 생각한 날도, 고객이 쓰기 시작한 날도 아닙니다. 검수확인서에 적힌 날짜입니다. 검수 절차 없이 운영부터 시작하면 기산점이 사라지고, 이건 개발사에게 더 불리합니다. 책임이 언제 끝나는지 아무도 증명할 수 없기 때문입니다.
검수확인서를 받지 않고 운영을 시작한 프로젝트는 하자담보책임이 끝나는 날이 없는 프로젝트입니다.
민간 계약이면 근거 법이 달라집니다
제60조는 국가기관등과의 계약에 적용되는 조문입니다. 회사 대 회사의 민간 개발 계약에는 민법 제670조가 기준이 됩니다. 하자의 보수와 손해배상 청구, 계약 해제는 목적물을 인도받은 날부터 1년 내에 해야 하고, 인도가 필요 없는 경우에는 일이 종료한 날부터 셉니다.
두 조문 모두 1년이지만 기산 문구가 다릅니다. 그래서 민간 계약이라도 '하자담보책임기간은 검수확인서 발급일부터 12개월로 한다'는 문장을 직접 넣는 편이 안전합니다. 법 해석을 다투는 대신 계약서 한 줄로 끝납니다.
오류 수정은 무상이고 기능 개선은 유상입니다
과학기술정보통신부 고시 「소프트웨어사업 계약 및 관리감독에 관한 지침」(제2023-15호, 2023년 5월 15일 시행)은 하자보수를 무상, 유지관리를 유상 개념으로 나눕니다. 그리고 제안요청서 단계에서 둘을 명확히 구분해 적도록 요구합니다.
하자보수는 개발 과정에서 생긴 원천적인 오류와 결함을 고치는 일입니다. 유지관리는 인도 후 업무 절차가 바뀌면서 생기는 기능 변경과 추가, 보완, 사용 방법 개선, 문서 보완까지를 말합니다.
만들 때 잘못 만든 것을 고치면 무상이고, 만든 뒤에 달라진 것을 반영하면 유상입니다.
정기 점검과 상주 지원은 하자보수 이름으로 요구할 수 없습니다
하자담보책임 범위를 벗어난 요구로 자주 거론되는 항목은 정해져 있습니다. 계약서에 이 목록을 그대로 옮겨 적어 두면 두 달 뒤의 대화가 짧아집니다.
- 최신 버전으로의 무상 업그레이드
- 안정화를 위한 개발자 상주와 시범운영 지원
- 구축된 시스템과 상용 소프트웨어의 정기 점검
- 화면 등 사용 방법과 기능의 개선
- 하드웨어와 소프트웨어의 설정 변경 및 최적화
- 재설치와 이전 설치, 정부표준 변경에 따른 수정
지침은 유지관리를 검수 또는 설치확인 직후에 별도 계약으로 체결하고 정당한 대가를 지급하도록 명기하라고 합니다. 하자보수 조항 바로 아래에 제외 목록을 붙이는 것이 실무에서 가장 효과가 큽니다.
'요구사항과 다르게 동작함'은 기준 문서가 있어야 성립합니다
하자 주장은 두 종류입니다. 하나는 오류가 나서 아예 동작하지 않는 경우이고, 이건 누가 봐도 하자입니다. 다른 하나는 동작은 하는데 요구한 대로가 아닌 경우입니다.
두 번째를 하자로 주장하려면 '요구한 대로'가 어디에 적혀 있는지 보여야 합니다. 요구사항 정의서가 계약 밖의 참고 자료로만 남아 있으면 개발사는 협의 과정의 초안이었다고 답할 수 있습니다. 그때부터는 회의록과 메신저 기록을 뒤지는 기억 싸움이 됩니다.
요구사항 정의서는 계약서에 첨부해야 힘이 생깁니다
계약서 본문에 이런 문장을 넣으세요. '본 계약의 계약문서는 계약서, 요구사항 정의서(별첨 1), 제안요청서, 제안서로 구성하며 해석의 우선순위는 기재된 순서에 따른다.' 첨부되지 않은 문서는 계약 내용이 아닙니다.
첨부할 때는 문서에 버전과 확정일을 박아야 합니다. '요구사항 정의서 v1.3, 2026년 3월 10일 확정본'처럼 적습니다. 개발 중에 요구사항이 바뀌면 서면 합의로 별첨을 교체하고 버전을 올립니다. 이 절차가 없으면 첨부해도 어느 판이 기준인지 다시 다투게 됩니다.
발주자가 지시한 대로 만든 것은 하자가 아닙니다
제60조 제2항은 발주자가 제공한 물품이나 재료가 기준에 미치지 못한 경우, 그리고 발주자의 지시에 따라 구축한 경우에는 담보책임이 없다고 정합니다. 다만 사업자가 그 지시나 재료가 부적당하다는 것을 알고도 알리지 않았다면 면책되지 않습니다.
실무로 옮기면 이렇습니다. 고객이 정한 사양대로 만든 뒤 문제가 생기면 무상 대상이 아닙니다. 대신 개발사는 위험을 발견한 시점에 서면으로 알려야 그 면책을 쓸 수 있습니다. 회의 중에 한 구두 경고는 나중에 근거가 되지 못합니다.
이렇게 써도 다툼이 남는 지점이 있습니다
수치가 없는 요구사항은 계약서를 잘 써도 판정이 되지 않습니다. '조회가 빠르게 되어야 한다'는 문장으로는 하자를 가릴 수 없습니다. 목표 수치와 측정 조건, 예를 들어 데이터 10만 건 기준 3초 이내처럼 함께 적어야 기준이 됩니다.
연동 상대의 API 변경, 브라우저 업데이트, 데이터량 급증처럼 요구사항에 없던 환경 변화도 경계가 흐립니다. '제3자 시스템의 변경으로 필요해진 수정은 유상으로 한다'를 미리 적어 두는 편이 낫습니다.
그리고 소송까지 가면 일의 완성 여부와 하자 여부는 감정 절차로 판단됩니다. 비용과 기간이 계약 금액을 흔들 수준입니다. 계약서 몇 줄이 훨씬 쌉니다.
계약서에 반드시 들어가야 할 문장은 다섯 개입니다
- 하자담보책임 기산점을 검수확인서 발급일로 못 박는 문장
- 기간을 12개월 등 숫자로 적은 문장
- 무상 하자보수를 '오류와 결함의 수정'으로 한정하는 문장
- 기능 개선, 설정 변경, 정기 점검, 상주 지원을 유상으로 명시한 제외 목록
- 계약문서 구성과 해석 우선순위, 요구사항 정의서 별첨 표시
고시 원문은 국가법령정보센터의 소프트웨어사업 계약 및 관리감독에 관한 지침에서 확인할 수 있습니다. 계약과 납품 실무에 관한 다른 글은 실무 가이드에 모아 두었습니다. 개발 위탁 계약 검토가 필요하시면 Codeforest로 문의하세요.
결론: 두 달 뒤의 답은 계약서를 쓰던 날에 이미 정해집니다
납품 두 달 뒤에 발견한 문제는 기간으로는 하자담보책임 안에 있습니다. 무상이냐 유상이냐는 그다음, 오류를 고치는 일인지 요구를 새로 반영하는 일인지에서 갈립니다. 그 판단의 기준은 검수확인서 날짜와 계약서에 첨부된 요구사항 정의서입니다.
검수확인서를 남기고, 무상 범위를 오류 수정으로 한정하고, 유상 항목을 목록으로 적고, 요구사항 정의서를 버전과 함께 별첨하세요. 이 네 가지가 없는 계약은 두 달 뒤에 반드시 협상 테이블로 돌아옵니다.
