[IT용역] 소프트웨어 공급계약의 잔금 지급 청구 전부승소 



A사는 중견 규모의 소프트웨어 개발 회사입니다. 6개월 전, B기업과의 소프트웨어 공급계약을 통해 업무용 플랫폼을 구축하기로 했죠.

계약서에는 다음과 같은 조항이 명시되어 있었습니다.

• 개발 완료 후 납품 → 검수 → 승인 시 잔금 지급

• 하자 발생 시 일정 기간 내 무상보수

• 유지보수는 별도 계약으로 진행

A사는 개발 일정에 맞춰 시스템을 개발했고, 중간 보고 및 베타 버전의 웹퍼블리싱 등을 진행하며 고객사와 계속 개발 경과를 전달하였습니다.

하지만 그때부터 진짜 일이 시작됩니다.

B사는 수일 간격으로 다음과 같은 의견을 전달해왔습니다.

“이 기능이 사용자 입장에서 좀 불편하네요. 수정 가능한가요?”

“이런 알림 기능도 있었으면 좋겠어요.”

“모바일에서도 잘 보이면 좋을 것 같아요.”

A사는 큰 문제 없이 요청에 응해줬습니다. 계약 외 요청이란 인식은 있었지만, 관계 유지를 위해 이의를 제기하지 않았고, 추가 견적도 따로 제시하지 않았습니다. 내부적으로는 "이 정도는 그냥 해주자"는 분위기였습니다.

몇 주 후, 문제가 터집니다. 잔금 지급을 요청하자, B사는 돌연 태도를 바꿉니다.

“계약상 납품이 완료되지 않았습니다. 하자도 많고, 지금은 저희 내부 개발자가 소스 코드를 뜯어고치고 있는 상황입니다. 당연히 잔금은 지급할 수 없습니다.”

A사는 어이가 없었습니다. 지금까지 별 말 없이 요청한 수많은 수정 작업들은 모두 계약 외 추가된 사양이었고, 1차 납품 당시 B사도 별 이의 없이 검수를 마친 상태였기 때문입니다.

양 당사자는 개발 완료 여부에 대하여 완전히 정반대의 인식을 가지고 있었습니다.

이와 같이 소프트웨어 납품 후 잔금 지급을 앞둔 시점에, ‘완료 vs 미완료’, ‘정상 vs 하자’ 논쟁이 벌어지는 건 소프트웨어 공급 개발 용역계약에서 매우 흔한 일입니다.

이 글에서는 실제 업무 사례를 바탕으로 소프트웨어 공급계약에서 납품 완료와 하자의 기준, 그리고 이와 관련된 분쟁 대응 전략의 모든 것을 설명 드리도록 하겠습니다.

1. 핵심 법률 쟁점

✔ 진짜 하자가 발생할 것인가... 계약상 의무인가, 추가 요구인가?

가장 중요한 쟁점은 실제로 하자가 발생한 것인지, 즉 개발이 미흡한 부분이 원 계약에서 정한 개발 범위에 포함되는지 여부입니다.

설령 개발이 덜 된 부분이 있다고 하더라도, 그것이 원래 계약에서 정하고 있던 개발 범위를 넘어선 것이라면, 개발이 미흡해도 '하자'라고 볼 수는 없는 것이죠.

실제 분쟁사례에서는 이를 판단하기 위하여:

• 계약서에 기재된 기능 명세, 요구사항 목록, 기획서/화면설계서 등 부속 문서

• 납품 후 검수 조항에서 "보완", "수정", "하자"의 범위가 어디까지 허용되었는지

• 구두 또는 이메일로 주고받은 내용이 계약 범위 확장으로 볼 수 있을지

이러한 자료 및 쟁점들에 대한 검토가 이루어졌습니다.

✔ "이의 없이 수행한 추가 작업", 원래 개발 범위로 간주될까?

개발사가 추가 스펙을 요청받고 명시적 이의 없이 개발을 진행한 경우, 원 계약 범위를 넘어선 작업임에도 불구하고 “개발 사양에 추가하기로 합의한 것”으로 보일 위험이 있습니다.

특히 다음과 같은 상황에서는 원래 계약 범위를 넘어선 것이라는 증명이 어렵게 될 수 있습니다.

• 개발사가 추가 요청에 대해 명확히 “이는 계약 외 요청”임을 통지하지 않은 경우

• 비용, 일정 조율 없이 작업을 수행한 경우

• 후속 합의나 견적서를 별도로 작성하지 않은 경우

실제 분쟁사례에서는 구두로만 '서비스 및 고객관리 차원에서 추가로 개발해준다'는 뉘앙스가 전해졌기 때문에, 추가 작업 부분이 원 계약 범위를 넘어서는 것임을 증명하는 과정에서 섬세한 소송 수행 전략이 필요했습니다.

2. 소프트웨어 개발계약에서 검수 조항과 하자보수 조항이 중요한 이유

소프트웨어 개발 용역계약에서 가장 핵심적인 조항 중 하나는 검수 조항과 하자보수 조항입니다.

이 두 조항은 단순한 후속 절차가 아니라, ‘계약이 제대로 이행되었는지’, ‘대금을 지급해야 하는지’를 판단하는 데 중요한 기준이 됩니다.

🔹 검수 조항이란?

실제로 문제가 된 검수 조항으로, '공정 타당한 방법', '상호협력' 등 모호한 문구로 작성되어 있습니다.

검수란, 개발사가 납품한 결과물이 계약상 요구한 사양을 충족하는지를 발주처가 확인·승인하는 절차입니다.

계약서에는 보통 다음과 같은 내용이 포함됩니다.

• 검수 기간 (예: 7일, 14일 등)

• 검수 기준 (기능 명세서, 계약서 첨부 문서 등)

• 불합격 시 보완 요청 및 재검수 절차

• 검수 완료 후 잔금 지급 조건

검수는 납품 완료 여부를 판단하는 기준점이 되므로, 검수 통과 시점부터 하자보수 기간이 시작되고, 잔금 지급 의무도 발생하는 구조로 계약이 설계되는 것이 일반적입니다. 검수는 단순한 절차가 아니라, 계약의 이행 완료를 선언하는 관문과도 같습니다.

계약서에서 정한 절차대로 실제 납품 및 검수가 이루어졌는지, 적절하게 발주사에서 수정을 요청하였는지 등 구체적인 사실관계를 파악하는 것이 필수적입니다.

따라서 검수 요청, 승인, 보완 요구 등 모든 과정은 가급적 문서나 이메일, 공문 등으로 증거화해두는 것이 중요합니다.

🔹 하자보수 조항이란?

"하자로 간주", 개발사에서 하자가 아니라는 "근거를 적시할 의무"를 정하고 있는 등, 상당히 개발사에 불리한 하자보수 조항이었습니다.

하자보수 조항은, 검수 완료 이후에도 일정 기간 동안 납품된 소프트웨어에 문제가 발생했을 경우 무상으로 보수할 수 있도록 정한 조항입니다.

일반적으로 다음과 같은 내용을 포함합니다.

• 하자보수 기간 (예: 3개월~1년)

• 하자의 범위 (기능 오류, 시스템 장애 등)

• 보수 기한 및 절차

중요한 점은, 하자의 범위는 ‘계약상 구현하기로 약속한 기능’에 한정된다는 점입니다.

즉, 계약서나 명세서에 포함되지 않았던 기능에 대한 요구는 하자보수 대상이 아닐 수 있으며, 이는 별도의 추가 계약이나 유지보수 계약으로 다루어야 합니다.

또 한가지 중요한 점은 '하자임을 증명할 책임'이 누구에게 있는지의 문제인데, 문제된 분쟁 사례에서는 그 입증책임이 개발사에 있다고 정하고 있어(즉 개발사에서 '하자가 아님'을 증명하여야 함), 매우 까다로운 소송이 펼쳐졌죠.

3. 소프트웨어 개발 분쟁에서 실무적으로 중요한 문서 세 가지

소프트웨어 개발 계약에서 문제가 발생했을 때, 현실적으로 “누가 옳은가”보다는 “무엇을 증명할 수 있는가”가 더 중요합니다.

특히 납품 완료 여부, 하자 유무, 대금 지급 의무 등이 쟁점이 되는 분쟁에서는 초기 계약 체결부터 납품 이후까지 어떤 자료를 어떻게 보관했는지가 승패를 가릅니다.

다음은 실제 분쟁에서 결정적인 역할을 하는 세 가지 핵심 문서입니다.

1. RFP 등 제안요청서 및 초기 기획 문서

RFP(Request For Proposal)는 발주처가 개발을 의뢰하면서 제시한 초기 요구사항 문서입니다.

이 문서는 개발 범위, 우선순위 기능, 목적 등을 기준선으로 제시하기 때문에, ‘계약에서 무엇을 하기로 했는가’를 판단하는 출발점이 됩니다.

✅ 실무 팁

• 계약 체결 전 주고받은 RFP, 기획서, 초기 요구사항 목록은 모두 보관해 두어야 합니다.

• "이건 당연히 들어간다고 생각했는데?"라는 주장은 대부분 초기 문서에 기재되어 있었는가 여부로 갈립니다.

2. 계약서와 사양 명세서

소프트웨어 계약에서는 본 계약서 외에도 별첨으로 사양 명세서(Specification)가 붙는 경우가 많습니다.

이 문서에는 납품해야 할 기능, 화면 설계, API 목록 등 구체적인 작업 범위가 정의되어 있습니다.

✅ 실무 팁

• 구두 설명이나 회의 내용이 아니라, 계약서에 실제로 기재된 사양이 판단 기준입니다.

• 사양 명세서 없이 “협의 후 구현” 등으로만 정리되었다면, 향후 해석에 큰 분쟁 소지가 생깁니다.

• 계약 변경이 있었다면 그 역시 변경 계약서나 합의서 형태로 문서화해 두어야 합니다.

다행히 사양 명세서가 상세히 정해져 있어, 소송에서 가장 핵심적 자료로 활용되었습니다.

3. 커뮤니케이션 자료 (이메일, 메신저, 회의록 등)

실무에서는 계약서보다 카카오톡, 슬랙, 이메일이 더 많은 의사결정을 담고 있는 경우가 많습니다.

하지만 이런 대화 기록도 충분히 법적 증거가 될 수 있습니다.

★ 특히 다음과 같은 내용은 매우(!) 중요합니다.

• 기능 보완 또는 일정 변경에 대한 요청과 답변

• 검수 승인 또는 하자 통보

• 추가 요청에 대해 “계약 외 요청입니다”라는 입장 전달 여부

• 개발 완료 통보 및 발주처의 수령 여부

4. 업무 성공 사례

A사는 계약상 납품 의무를 모두 이행했음에도, 발주처가 "하자가 있다", "지연됐다"며 잔금 지급을 거부하자 미지급 개발대금 지급 청구 소송을 제기했습니다.

소송 과정에서 A사는 ✔ 초기 계약서와 기능 명세서 ✔ 납품 완료 보고서 및 검수 관련 이메일 ✔ 추가 요청이 계약 외 요구였음을 보여주는 카톡 대화 ✔ 보완 작업 내역과 대응 일지 등을 증거로 제출했습니다.

이에 대하여 법원은

“문제 삼은 기능들은 원래 계약에 포함되지 않았고, A사가 납품 후 요청에 성실히 대응한 점을 고려하면,

계약상 하자가 있다고 보기 어렵다”

고 판단하며, 미지급 잔금 전액을 지급하라는 판결을 내렸습니다.

의뢰인은 요청에 따라 ✔ 초기 계약서 및 기능 명세서, ✔ 추가 요청이 오간 카카오톡 메시지, ✔ 납품 완료 보고서 및 대응 내역 등 핵심 자료를 모두 전달해 주셨고, 저희는 흩어진 자료들을 일목요연하게 정리 및 검토를 진행하였습니다.

특히 분쟁의 쟁점이 된 ‘추가 업데이트 요청 시점’을 중심으로, 요구사항의 범위가 어떻게 달라졌는지를 명확한 타임라인으로 정리해 법원이 한눈에 사실관계를 이해할 수 있도록 설명했습니다.

결국, 실무적인 분쟁 대응의 핵심은 ‘충실한 입증’과 ‘구체적인 흐름 설명’에 있습니다.

모든 것을 다투는 것이 아니라, 무엇이 계약이었고 무엇이 아니었는지를 증명하는 싸움임을 잘 이해한다면, 반드시 이길 수 있습니다.

법률사무소 창작

Ideas. Protected. Empowered.