분쟁 상황

서비스는 이미 열렸습니다. 발주사 직원도 관리자 화면을 쓰고 있습니다. 그런데 잔금일이 되자 “검수가 끝나지 않았다”는 답만 돌아옵니다. 개발 외주비 미지급 분쟁에서 자주 보이는 장면입니다. 배포 화면 한 장이나 버그 목록만으로는 결론이 나지 않습니다. 계약서가 약속한 결과가 무엇이었는지, 잔금 조건이 납품인지 검수 통과인지부터 읽어야 합니다.

개발자 입장에서는 밤새 작업한 시간과 커밋 수부터 말하고 싶어집니다. 하지만 대금 판단의 출발점은 약정한 일을 마쳤는지입니다. 중간에 기능이 계속 늘었다면 원래 범위의 수정인지, 돈을 더 받아야 할 별도 개발인지도 갈라야 합니다. 이 문제를 모두 섞어 “거의 다 했다”고만 하면 오히려 청구액의 근거가 흐려집니다.

결과물 완성과 업무수행의 구분

민법 제664조의 도급은 한쪽이 일을 완성하고 상대방이 그 결과에 보수를 지급하기로 하는 계약입니다. 민법 제665조는 별도 약정이 없다면 완성된 목적물의 인도와 동시에, 인도가 필요 없는 일은 완성 뒤 지체 없이 보수를 지급하도록 정합니다. 다만 실제 계약이 월 단위 운영 지원이나 인력 제공에 가까우면 ‘전체 시스템 완성’만으로 보수 발생을 판단하기 어렵습니다.

계약서의 모습	먼저 볼 문구	대금 청구를 뒷받침하는 기록
완성형 개발	기능명세, 납품물, 검수 기준, 완료일	배포본, 인수확인, 시험 결과
단계별 개발	화면·모듈별 마일스톤과 각 지급액	단계별 승인 메일, 데모 기록
월 단위 업무	투입 인력, 시간, 업무보고와 월 보수	작업일지, 회의록, 월별 승인
혼합형	구축비와 유지보수비의 구분	구축 인도자료와 운영 요청을 분리한 내역

보수 발생 조건은 계약 이름보다 실제 의무의 내용으로 정해집니다. 계약서 표지에 ‘용역’이라고 적혀 있어도 특정 프로그램 완성을 약정했다면 도급의 성질이 문제 될 수 있고, 반대로 계속되는 운영 업무까지 하나의 완성일로 묶을 이유는 없습니다.

완성형 계약의 검수 기준

“정상 작동”처럼 넓은 문구만 있다면 요구 명세서, 제안서, 화면설계서와 양쪽이 승인한 테스트 항목을 이어서 봅니다. 개발 외주비 미지급 통지를 받은 시점에 새 기준을 만들어 맞추기보다는 계약 체결 뒤 실제로 사용해 온 승인 절차를 재현하는 편이 설득력이 있습니다.

월 단위 업무, 수행 흔적

가령 발주사 지시에 따라 매주 우선순위를 바꾸며 개발자를 상주시킨 계약이라면, 최종 기능의 완성 여부만큼 월별 업무가 제공됐는지가 쟁점이 됩니다. 티켓 배정, 회의 참석, 업무보고 승인과 이미 지급된 달의 처리 방식은 당사자가 보수를 어떤 구조로 이해했는지 보여 줍니다.

검수 불합격 사유의 구체적 검토

발주사의 거절 이유를 그대로 옮기지 말고 미완성, 하자, 추가 요구로 나눠야 합니다. 예정된 기능 자체가 빠졌다면 미완성 주장에 가깝고, 기능은 구현됐지만 약정 성능에 못 미친다면 하자 문제입니다. 계약 뒤 나온 새 관리자 통계나 외부 서비스 연동은 별도 범위인지 따져야 합니다.

대법원 1996. 7. 30. 선고 95다7932 판결은 소프트웨어 개발·공급계약을 도급으로 보면서, 계약이 중도에 해소된 사안에서 이미 설치된 부분의 완성도와 발주사에 주는 이익, 보완 제의를 발주사가 거절한 경위 등을 살펴 완성된 부분의 보수를 인정했습니다. 이 판결이 모든 미완성 프로젝트의 비율 정산을 보장하는 것은 아닙니다. 사용 가능한 기성 부분과 발주사의 중단 경위를 함께 입증한 사안이었다는 점을 읽어야 합니다.

검수라는 한 단어가 대금 지급일을 무한정 미루는 장치는 아닙니다. 다만 개발사가 약정한 최종 공정을 끝내지 못했다면, 배포 사실만으로 잔금 전부가 발생했다고 단정할 수도 없습니다.

개발 외주비 미지급 사유가 버그라면 오류별 재현 조건과 약정 기준을 맞춰 보세요. ‘로그인이 느리다’는 평가만으로는 부족합니다. 어느 환경에서 몇 초가 걸렸는지, 계약상 성능 수치가 있었는지, 수정본 제공 뒤 재시험했는지를 한 줄씩 붙이면 미완성과 하자의 경계가 보입니다.

계약 변경 이력과 추가합의 확인

커밋 수가 많다는 사실은 노동량을 보여 줄 뿐, 그 작업이 발주 범위였다는 점까지 말해 주지는 않습니다. 개발 외주비 미지급 청구를 준비할 때에는 최초 명세와 변경 요청을 먼저 맞춘 뒤 기술 기록을 붙이는 순서가 낫습니다.

계약서·견적서는 최초 기능과 단계별 지급액을 정하는 데 씁니다.

메신저와 회의록은 누가 어떤 기능을 추가하거나 우선순위를 바꿨는지 밝힙니다.

저장소 이력과 배포 로그는 구현 시각, 버전, 인도 상태를 확인하는 자료입니다.

테스트 결과와 오류표는 남은 문제가 미완성인지 보완 가능한 하자인지 가르는 데 씁니다.

발주사의 실제 사용 기록은 설치된 부분이 업무에 이용됐는지 살피는 자료가 됩니다.

자료를 모으는 동안에는 원본을 그대로 보존하세요. 대금 압박을 위해 운영 계정을 막거나 소스를 삭제하지 마세요. 계약상 유지 의무 위반이나 별도 손해 주장으로 번져 본래의 대금 다툼을 더 복잡하게 만들 수 있습니다. 제공 범위와 접근 권한에 관한 입장은 서면으로 남기는 편이 좋습니다.

청구금액의 항목별 정리: 구축비·추가기능비·운영비

계약금에서 받은 돈을 빼는 계산만으로는 부족할 수 있습니다. 원래 개발대금, 승인된 추가 기능비, 월 운영비를 나누고 각 항목의 지급 조건과 도래일을 적으세요. 발주사가 하자보수비나 지체상금을 주장한다면 그 금액과 근거도 별도 칸에 둬야 상계 주장을 구분할 수 있습니다.

예를 들어 기본 구축은 인도됐지만 제3자 결제 연동이 발주사 계정 미발급으로 멈춘 경우라면, 연동 미완료의 원인이 누구에게 있는지와 나머지 구축 부분의 사용 가능성을 함께 봅니다. 내용증명에는 감정적인 경과보다 납품 버전, 검수 요청일, 상대방의 구체적인 거절 사유, 청구액 산식과 지급기한을 담는 편이 분명합니다.

이 분쟁은 커밋 수로 이기기 어렵습니다. 계약서의 지급 조건 옆에 실제 인도본을 놓고, 중간 변경 요청은 별도 열로 빼 보세요. 그러면 개발 외주비 미지급 청구액이 구축 잔금인지, 추가 개발비인지, 월 운영비인지 드러납니다. 빈칸으로 남는 항목이 있다면 그 부분이 지금 더 찾아야 할 자료입니다.