개발용역대금 청구소송에서 단계별 산출물과 실제 사용을 입증하는 법

개발 화면이 발주회사 서버에서 돌아가는데도 검수확인서가 없다는 이유로 잔금이 멈추는 사건이 있습니다. 반대로 저장소에 코드가 많아도 계약서가 정한 기능과 연결되지 않으면 투입시간만으로 보수를 인정받기 어렵습니다. 개발용역대금 청구소송에서는 ‘다 만들었다’는 결론보다 요구사항별 산출물이 언제 생성되고 누구에게 넘어가 어떤 환경에서 쓰였는지를 이어 붙여야 합니다.

분석·설계·구현·시험·배포가 단계별 지급조건이면 최종 검수 하나에 모든 성과를 몰아넣을 필요가 없습니다. 요구사항 표, 커밋, 계정 권한, 배포 로그와 운영 매출을 마일스톤별로 배열하면 완료 범위와 사용 이익을 함께 보여 줍니다. 이 글은 산출물 인계와 실제 이용을 대금표로 바꾸는 데 초점을 둡니다.

계약표를 마일스톤 단위로 다시 그립니다

‘개발용역’이라는 이름만으로 민법상 도급이 되는 것은 아닙니다. 특정 기능·산출물의 완성을 목적으로 그 결과에 대가를 지급하기로 했다면 도급으로 볼 수 있지만, 사무처리 자체를 맡기고 시간·인력 투입에 따라 보수를 정했다면 위임·준위임일 수 있습니다. 계약의 실질을 먼저 분류한 뒤, 도급이면 민법 제664조의 완성 여부와 단계별 지급요건을 살핍니다. 과업지시서·견적서·일정표·변경합의서에서 단계별 종료조건과 비율을 추출합니다.

완성 여부는 투입시간이나 코드 줄 수가 아니라 약정한 최후 공정이 객관적으로 끝났는지로 판단합니다. 대법원 94다42822·42839의 건축도급 법리를 기계적으로 옮기지 말고, 약정 기능·인도 형식·시험 절차를 기준으로 미완성과 완성 뒤 하자를 나눕니다.

마일스톤 표에는 약속 산출물, 제출일, 수령자, 반려사유, 보완일, 지급비율을 적습니다. 발주자가 구두로 우선순위를 바꾸었거나 기능을 추가했다면 메신저 한 줄만 떼지 말고 변경 전 요구사항과 변경 후 일정, 담당자의 승인, 실제 반영 커밋을 연속해서 놓습니다. 그래야 원계약 성과와 추가업무가 뒤섞이지 않습니다.

산출물은 파일명보다 생성·인계 경로로 증명합니다

요구사항 정의서나 화면설계서 표지의 작성자 이름만으로 내용과 제출시점까지 증명되지는 않습니다. 원본의 생성·수정 이력, 이메일 첨부본, 협업도구 업로드와 수령자의 열람·댓글을 보존합니다. 같은 이름의 파일이 여러 번 오갔다면 해시와 버전번호로 계약상 제출본을 특정합니다.

소스코드는 저장소 주소 외에 브랜치, 릴리스 태그, 커밋 작성자와 병합 승인자를 내보냅니다. 발주자 조직 계정으로 이전됐거나 관리자 권한을 받은 날짜는 인계를 뒷받침합니다. 외부 라이브러리·클라우드·도메인은 소유 주체가 다를 수 있어 코드와 계정 이전을 같은 행위로 단정하지 않습니다.

시험결과는 테스트 케이스 번호, 실행환경, 기대값·실제값, 오류 티켓과 수정 커밋으로 잇습니다. 발주자의 반려 사유가 약정 기능 누락인지 새 요구사항인지 표시합니다. 검수서가 없어도 반복 시연·보완 지시·운영 전환 지시가 있었다면 행위별 날짜와 범위를 제시할 수 있습니다.

저장소가 사라지기 전에 보존할 네 가지 기록

분쟁이 시작되면 계정 권한이 끊길 수 있으므로 저장소 전체 이력, 이슈·풀리퀘스트 내보내기, 배포 파이프라인 로그, 클라우드 접근감사 기록을 원본 형식으로 확보합니다. 개인 화면을 촬영한 이미지뿐 아니라 서비스 제공자가 남긴 타임스탬프와 조직 소유권 정보가 있어야 누가 언제 무엇을 넘겼는지 재현할 수 있습니다.

발주자의 배포와 운영은 별도의 이용사슬로 제시합니다

검수의 법적 효과는 계약 문언에 따라 달라집니다. 검수 합격을 보수청구권 발생의 정지조건으로 정했는지, 완성된 일의 지급시기만 미룬 불확정기한인지 구별합니다. 예정된 최후 공정이 객관적으로 끝났는데 발주자의 거부로 검수 완료가 불가능해졌다면, 불확정기한인 사안에서는 지급기가 도래할 수 있습니다(대법원 2019. 9. 10. 선고 2017다272486·272493). 반면 핵심 기능이나 최후 공정이 끝나지 않았다면 운영 흔적이나 일부 사용만으로 완성·검수 합격이 자동 인정되지 않습니다.

발주자가 다른 업체의 코드를 배포했을 가능성도 배제해야 합니다. 패키지 해시, API 경로, 데이터베이스 구조와 화면 리소스로 납품본을 식별하고 후속업체의 커밋 시점을 나눕니다. 원고 코드가 바탕이어도 후속개발비 전부를 원고 성과로 볼 수는 없습니다.

시험 접속과 영업상 계속 사용은 다릅니다. 사용자 수, 거래, 장애 티켓과 유지보수 요청을 기간별로 배열해 이용 강도를 제시합니다. 접근할 수 없는 로그는 문서제출명령이나 사실조회에 대비해 보유 주체와 보존기간을 적어 둡니다.

발주자 보유 로그를 소송 증거로 바꾸는 순서

소장에는 로그 명칭, 보유 회사·서비스, 조회 기간과 입증 취지를 적습니다. 막연히 ‘전산기록 일체’를 요구하기보다 특정 릴리스의 배포일과 관리자 계정 사용을 밝힐 항목으로 좁혀야 제출 대상을 식별하기 쉽습니다. 보존기간이 짧은 클라우드 로그는 소 제기 전 증거보전 가능성도 살핍니다.

청구액은 달성분·변경분·미완성분을 다른 칸에 놓습니다

민법 제665조는 보수 지급시기를 원칙적으로 목적물 인도와 연결하지만, 당사자가 단계별 지급일을 따로 정했다면 그 약정이 계산의 출발점입니다. 각 마일스톤의 약정금액에서 기지급액을 빼고, 반려 뒤 보완이 끝난 범위와 아직 끝나지 않은 범위를 표시합니다. 인력 투입표는 성과를 뒷받침하는 보조지표일 뿐 정액 계약의 대금을 곧바로 사람·월 단가로 바꾸지는 않습니다.

추가 기능은 발주 요청, 예상 비용과 일정, 승인, 납품의 네 고리를 갖춰 원계약과 다른 행으로 계산합니다. 담당자가 기능 변경을 요구했어도 대금 결정 권한이 없거나 무상보완 범위라면 추가대금이 인정되지 않을 수 있습니다. 견적서 송부 뒤 침묵만 있었는지, 실제 추가 결과물을 배포하고 이용했는지까지 정황을 모읍니다.

도급형 계약이 중도 종료돼도 전체 잔금은 자동 청구되지 않습니다. 단계별 지급요건이 성취됐다면 그 대금은 약정에 따라 청구할 수 있습니다(대법원 1997. 11. 14. 97다6193). 단계 약정이 없거나 완성 전 종료됐다면 완성률만으로 보수청구권이 생기지 않습니다. 다만 설치 부분이 독립적으로 이용 가능해 발주자에게 이익이 되고, 조금만 보완하면 완성되는데 발주자가 보완을 거절한 등 특별한 사정은 따집니다(대법원 1996. 7. 30. 95다7932). 반대채권은 오류와 합리적 수정비를 항목별로 심리합니다.

개발용역대금 청구소송의 핵심은 코드의 양이 아니라 약속한 단계와 실제 성과 사이의 연결입니다. 요구사항부터 커밋·인계·배포·운영까지 같은 번호로 이어지면 검수서가 비어 있어도 완료 범위와 사용 정황을 구체적으로 설명할 수 있습니다.

청구액은 마일스톤, 승인된 변경업무와 미완성 부분을 별도 장부에 적습니다. 발주자의 실제 이용은 자동 승인이 아니므로 약정 지급조건과 함께 제시합니다.