개발 프리랜서 잔금 미지급 방지, 산출물 전달 순서가 돈을 지킵니다

잔금은 납품일보다 계약 첫 문장에서 갈립니다

잔금 미지급은 프로젝트가 끝난 날 갑자기 생기는 사고처럼 보이지만, 실제 씨앗은 계약 초반에 심어지는 경우가 많습니다. “개발 완료 후 지급”, “검수 후 잔금 지급”처럼 짧은 문장만 남겨두면 완료와 검수의 의미를 양쪽이 다르게 읽게 됩니다.

개발자는 기능이 정상 작동하면 완료라고 생각합니다. 발주자는 내부 보고, 대표 승인, 실제 운영 확인까지 끝나야 완료라고 생각할 수 있습니다. 두 기준 사이의 빈 공간에 추가 수정과 지급 지연이 쌓입니다.

개발 완료와 계약 완료는 같은 날짜가 아닙니다

1. 요구사항 기준 기능 구현
2. 개발자 내부 테스트 완료
3. 스테이징 환경 공개
4. 발주자 검수 요청
5. 계약 범위 내 오류 수정
6. 최종 승인 또는 계약상 검수 절차 종료
7. 잔금 지급
8. 최종 소스와 운영 권한 이전
9. 하자보수 또는 유지보수 시작

위 단계가 반드시 모두 다른 날이어야 하는 것은 아닙니다. 다만 계약서와 일정표에서는 서로 다른 사건으로 구분해 두는 것이 안전합니다. 그래야 발주자 피드백이 늦어졌을 때 개발 일정과 대금 지급일을 함께 재산정할 수 있습니다.

계약서에 최소한 남겨야 할 여섯 문장

• 완료 여부를 판단할 기준 문서는 무엇인지
• 검수 자료가 모두 제공된 것으로 보는 시점은 언제인지
• 발주자가 검수 의견을 보내야 하는 기한은 며칠인지
• 포함된 수정 횟수와 범위는 어디까지인지
• 잔금 지급일과 세금계산서·청구서 발행 조건은 무엇인지
• 저작권, 소스코드, 서버·도메인 권한이 이전되는 시점은 언제인지

소스코드의 소유권과 사용권은 잔금 문제와 함께 얽히기 쉬운 항목입니다. 계약 문구를 정리할 때는 사이트의 프리랜서 저작권·라이선스 계약서 작성 기준도 함께 살펴보면 권리 이전과 포트폴리오 사용 조건을 분리하는 데 도움이 됩니다.

계약 이름보다 실제 일한 방식도 확인하세요

계약서 제목이 프리랜서 용역계약이라고 적혀 있어도 출퇴근 시간과 장소가 정해져 있고, 업무 과정에서 지속적인 지휘·감독을 받았으며, 다른 고객의 일을 사실상 수행하기 어려웠다면 근로자성 검토가 필요할 수 있습니다.

이 경우 일반 외주대금 청구와 임금 체불 절차 중 어느 경로가 맞는지 먼저 확인해야 합니다. 계약 명칭만 보고 노동관서 절차를 포기하거나, 반대로 모든 외주대금을 임금으로 단정하지 않는 것이 좋습니다.

코딩 전에 만드는 잔금 회수 지도 7칸

프로젝트 관리 도구가 아무리 화려해도 잔금 지급 구조가 빠져 있다면 일정표는 절반짜리입니다. 착수 전에 아래 일곱 칸을 채우면 개발 범위, 검수, 청구, 인도의 연결 관계가 한눈에 들어옵니다.

일곱 칸에 무엇을 적어야 하나요?

구분	반드시 기록할 내용	빠뜨렸을 때 생기는 문제
산출물 목록	프로그램, 소스, 데이터베이스, 문서, 계정, 교육, 배포 자료	상대방이 계약에 없던 파일까지 최종 산출물로 요구할 수 있음
지급 단계	계약금, 중도금, 검수 시 지급액, 잔금, 유지보수 대금	마지막 잔금 비중이 지나치게 커져 개발자가 위험을 떠안음
검수 기준	요구사항 문서, 지원 환경, 테스트 조건, 오류 등급	취향 변경이나 신규 기능이 오류 수정으로 섞임
검수 기한	시작일, 회신일, 재검수 기간, 연장 사유	발주자가 답변을 미뤄도 프로젝트가 계속 열린 상태로 남음
변경 요청	포함 수정 횟수, 추가 견적 승인 방식, 일정 연장 기준	무제한 수정과 무상 추가 개발로 번짐
권한 이전	테스트 계정, 운영 계정, 저장소 소유권, 최고 관리자 권한 이전일	잔금 전에 통제권을 모두 잃음
보존 기록	계약서, 승인 기록, 검수표, 테스트 결과, 청구서, 파일 전송 기록	완료와 청구 사실을 나중에 입증하기 어려움

잔금 비중이 클수록 중간 마일스톤을 늘리세요

몇 달 동안 수행하는 프로젝트에서 대부분의 금액을 마지막에 받도록 설계하면 개발자가 사실상 발주자에게 무이자 신용을 제공하는 구조가 됩니다. 화면 설계 승인, 핵심 기능 구현, 연동 테스트, 최종 검수 요청처럼 객관적으로 확인할 수 있는 단계마다 중간 지급을 배치하는 편이 안정적입니다.

중간 지급 비율에 정답이 있는 것은 아닙니다. 중요한 것은 각 지급 시점에 확인 가능한 결과물이 있고, 미지급이 발생하면 다음 단계 투입을 보류할 수 있도록 계약과 일정이 연결돼 있는지입니다.

승인자는 실무 담당자와 다를 수 있습니다

프로젝트를 매일 확인하는 실무자가 최종 대금 지급 권한까지 가진다고 가정하면 위험합니다. 요구사항 승인자, 검수 담당자, 최종 결재권자, 세금계산서 수신자를 따로 기록하세요.

산출물을 세 등급으로 나누면 전달 순서가 보입니다

잔금을 받기 전까지 아무것도 보여주지 않는 방식은 정상적인 검수를 막습니다. 반대로 모든 파일과 권한을 한 번에 넘기는 방식은 검수와 최종 인도를 구분하지 못합니다.

해법은 산출물을 가치가 아니라 통제력에 따라 나누는 것입니다. 발주자가 성능을 확인하는 데 필요한 자료와 사업 전체를 운영·복제·이전할 수 있는 자산을 구별하세요.

검수용, 승인 후, 잔금 후 제공물을 구분하세요

등급	목적	대표 산출물	주의사항
가등급	계약 이행 여부 확인	데모 주소, 스테이징 서버, 제한 계정, 테스트 영상, 결과표, 응답 예시	실제 개인정보와 운영 비밀값은 제외
나등급	승인 후 운영 준비	운영 후보 버전, 읽기 전용 저장소, 배포 절차 초안, 제한된 관리자 계정	삭제·결제·소유권 이전 권한은 제한
다등급	최종 인수인계	전체 소스 원본, 저장소 소유권, 서버 최고 권한, 도메인·DNS 권한, 비밀키	계약상 잔금 및 인도 조건 충족 여부 확인

검수에는 원본 소스가 항상 필요한 것이 아닙니다

사용자 화면, 관리자 기능, 외부 연동, 처리 결과를 확인하는 프로젝트라면 실행 가능한 데모와 테스트 계정, 기능별 검수표만으로도 상당 부분을 확인할 수 있습니다. 코드 품질과 보안 검토가 계약 범위에 포함된 경우에는 읽기 전용 저장소나 특정 브랜치 접근을 제공하는 방법을 고려할 수 있습니다.

다만 발주자 소유 서버나 저장소에서 처음부터 작업하기로 계약했다면 개발자가 임의로 접근을 차단하는 방식은 적절하지 않을 수 있습니다. 이때는 마일스톤 지급, 브랜치 보호, 병합 승인, 배포 기록으로 위험을 분산해야 합니다.

소유권과 사용권도 한 문장으로 묶지 마세요

최종 소스코드의 소유권, 결과물을 운영할 권리, 제3자에게 수정 맡길 권리, 개발자의 포트폴리오 사용권은 서로 다른 항목입니다. “모든 권리는 발주자에게 귀속한다”는 문장 하나로 처리하면 오픈소스 구성요소, 기존 보유 코드, 재사용 모듈까지 분쟁에 들어올 수 있습니다.

기존 코드와 프로젝트 전용 코드를 나누고 싶다면 소유권과 라이선스 조건을 분리하는 방법을 참고해 권리 이전 범위를 문서로 정리하세요.

잔금 전후를 가르는 6단계 산출물 전달 순서

산출물 전달은 파일을 보내는 행위가 아니라 계약을 닫는 절차입니다. 다음 여섯 단계를 견적서, 일정표, 검수 요청서에 동일하게 반영하면 발주자도 다음 행동을 예측하기 쉬워집니다.

1단계부터 3단계까지: 검수 가능한 상태를 만듭니다

1. 요구사항 기준선 확정: 최종 요구사항 문서에 날짜와 버전 번호를 붙이고, 포함 기능·제외 기능·승인자를 표시합니다.
2. 스테이징 데모 공개: 운영 서버가 아닌 검수용 주소에서 샘플 데이터와 제한 계정을 제공합니다.
3. 기능별 검수표 발송: 기능명, 테스트 절차, 예상 결과, 실제 결과, 수정 요청란, 범위 외 요청 표시란을 넣습니다.

검수 요청 메일에는 단순히 “확인 부탁드립니다”라고 쓰지 마세요. 검수 대상 버전, 접속 방법, 테스트 가능 기간, 알려진 제한사항, 회신 마감일을 함께 적어야 검수 시작점이 생깁니다.

4단계부터 6단계까지: 수정과 인도를 닫습니다

4. 수정 의견 통합: 여러 부서의 의견을 한 명의 담당자가 취합하도록 요청하고, 화면·계정·재현 절차를 함께 받습니다.
5. 검수 완료 확인과 잔금 청구: 수정 완료표, 최종 버전, 남은 제한사항, 지급일, 입금 후 이전할 자산을 한 문서에 정리합니다.
6. 최종 인수인계: 계약상 지급 조건 충족을 확인한 뒤 저장소 소유권, 서버 권한, 문서 원본, 백업, 인증정보를 이전합니다.

이 순서는 모든 프로젝트에 일률적으로 적용되는 법적 공식이 아닙니다. 발주자 소유 계정에서 개발하는지, 결과물 인도와 대금 지급이 동시이행으로 설계됐는지, 선급금과 중도금이 어떻게 나뉘었는지에 따라 조정해야 합니다.

실제 적용 사례: 끝나지 않던 쇼핑몰 검수

한 개발자는 소규모 쇼핑몰을 완성한 뒤 운영 서버에 직접 배포했습니다. 발주자는 사이트를 광고에 사용하기 시작했지만, 매주 새로운 문구와 화면 변경을 요청하며 “아직 검수가 끝나지 않았다”고 답했습니다.

문제는 개발 능력이 아니었습니다. 계약서에는 수정 횟수와 검수 회신일이 없었고, 운영 서버의 최고 관리자 권한도 발주자가 처음부터 가지고 있었습니다. 개발자는 어느 버전이 납품본인지 설명할 기록조차 부족했습니다.

이후 그는 요구사항 목록에 버전 번호를 붙이고, 남은 요청을 오류 수정과 신규 기능으로 분리했습니다. 기존 계약 범위의 수정 완료표와 함께 검수 회신일, 잔금 지급일, 추가 개발 견적을 각각 제시했습니다.

모든 분쟁이 이렇게 정리되는 것은 아니지만, 대화의 중심은 “조금만 더 고쳐달라”에서 “어느 요구사항이 계약 범위인가”로 바뀌었습니다. 좋은 인도 절차는 상대방을 압박하는 장치보다 대화의 단위를 정확하게 만드는 도구에 가깝습니다.

검수 지연을 막는 문장은 자동 승인보다 정교해야 합니다

“7일 동안 답변이 없으면 검수 완료로 본다”는 문장은 매력적으로 보입니다. 그러나 검수 자료가 불완전했거나 중대한 오류로 테스트가 불가능했다면 그 문장만으로 모든 논쟁이 끝난다고 단정하기 어렵습니다.

무응답 처리 조항은 발주자가 실제로 검수할 수 있는 상태였다는 기록과 함께 작동해야 합니다.

검수 기한의 시작점을 구체적으로 적으세요

• 검수 요청서와 접속 정보가 지정된 담당자에게 도달한 날
• 계약상 필요한 문서와 테스트 계정이 모두 제공된 날
• 영업일 기준인지 달력일 기준인지
• 중대한 오류로 테스트가 불가능한 기간을 어떻게 처리할지
• 담당자 부재 시 대체 승인자가 누구인지
• 기한 연장을 요청할 수 있는 사유와 방식

수정 요청의 형식도 계약에 넣을 수 있습니다

“로그인이 안 됩니다”만으로는 오류를 재현하기 어렵습니다. 사용한 계정, 기기와 브라우저, 발생 시각, 입력값, 기대 결과, 실제 결과, 화면 캡처를 함께 제출하도록 검수표를 구성하면 수정 시간이 줄어듭니다.

검수 의견을 여러 담당자가 따로 보내는 구조도 피하세요. 발주자가 지정한 한 명이 의견을 통합하도록 하고, 마감 후 새로 제출되는 요청은 다음 수정 차수나 별도 변경 요청으로 처리하는 규칙이 필요합니다.

완료와 하자는 구분해서 기록합니다

작은 오류가 남아 있다는 사실이 언제나 프로젝트 전체가 미완성이라는 뜻은 아닙니다. 반대로 핵심 기능이 작동하지 않는데 화면이 보인다는 이유만으로 완료라고 주장하기도 어렵습니다.

대법원 판례도 도급계약에서 일이 완성됐는지 여부를 계약의 구체적인 내용과 예정된 최후 공정, 목적물이 갖춘 성능 등을 기준으로 객관적으로 판단해야 한다는 취지를 제시하고 있습니다. 개별 개발 프로젝트에 그대로 대입할 수는 없지만, 최종 검수와 잔금 지급에 관한 대법원 판례를 읽어보면 완료, 하자, 검사, 지급시기를 구분해야 하는 이유를 이해하는 데 도움이 됩니다.

조금 더 깊이 알고 싶다면

개발 외주는 통상 일정한 결과물을 완성하고 보수를 지급받는 도급 성격을 가질 수 있지만, 실제 계약 구조에 따라 위임·준위임 요소가 함께 나타날 수 있습니다. 따라서 “검수 완료가 잔금 지급의 조건인지”, “단순히 지급 시기를 정한 것인지”, “인도와 지급이 동시에 이루어져야 하는지”는 계약 문구 전체를 살펴야 합니다.

분쟁을 예방하려면 법률 용어를 많이 넣기보다 완료 기준, 검수 절차, 하자 처리, 지급일, 권리 이전 시점을 누구나 실행할 수 있는 문장으로 적는 편이 효과적입니다.

소스코드·서버·비밀번호는 같은 날 넘기지 않습니다

접근권한은 열쇠 한 개가 아닙니다. 코드를 읽는 권한, 코드를 병합하는 권한, 운영 서버에 배포하는 권한, 저장소를 삭제하는 권한, 결제수단을 변경하는 권한은 전혀 다른 위험을 가집니다.

한 번에 “관리자 계정”이라고 부르지 말고 기능별로 쪼개면 검수와 운영 준비를 지원하면서도 실수나 무단 변경 위험을 줄일 수 있습니다.

권장 이전 순서를 프로젝트 표에 넣으세요

순서	권한 또는 자산	권장 시점
1	스테이징 테스트 계정	검수 시작 전
2	읽기 전용 코드·문서 접근	계약상 코드 검토가 포함된 경우
3	제한된 운영 관리자 계정	운영 준비 또는 교육 단계
4	잔금 지급 확인	계약에서 합의한 지급일
5	저장소 소유권·병합·삭제 권한	최종 인수인계 단계
6	서버 최고 관리자 권한	백업과 인수인계 확인 후
7	도메인·DNS·클라우드 결제 권한	서비스 소유권 이전 확인 후
8	비밀키 교체와 개발자 계정 폐기	인수인계 마지막 단계

저장소 권한은 여섯 가지 이상으로 나뉩니다

• 코드 열람과 내려받기
• 이슈와 수정 요청 등록
• 새 브랜치 생성
• 기본 브랜치 병합
• 자동 배포 실행
• 저장소 삭제와 조직 소유권 이전

발주자가 코드 검수를 요구한다면 읽기 권한을 제공하는 것으로 충분한지, 내려받기까지 허용해야 하는지 계약 목적에 따라 협의하세요. 코드 공개가 포함된 프로젝트라면 비밀정보, 제3자 라이선스, 환경변수 파일을 먼저 점검해야 합니다.

발주자 서버에서 개발할 때는 통제보다 기록이 중요합니다

보안 정책 때문에 발주자 소유 서버와 계정에서만 작업해야 하는 프로젝트도 많습니다. 이런 상황에서 개발자가 임의로 비밀번호를 바꾸거나 접근을 끊으면 오히려 문제가 커질 수 있습니다.

• 개발용·검수용·운영용 브랜치를 분리합니다.
• 운영 배포에는 발주자 승인 기록을 남깁니다.
• 마일스톤마다 커밋 식별값과 배포 일시를 기록합니다.
• 미지급 시 다음 단계 작업을 보류할 수 있는 조건을 계약서에 둡니다.
• 발주자 계정에서 작업한 코드의 인도 시점을 별도 확인서로 남깁니다.

잔금 청구서보다 먼저 보내야 할 증거 패키지

잔금 청구서에 금액과 계좌만 적혀 있으면 발주자는 다시 “무엇이 완료됐는지 정리해 달라”고 요청할 수 있습니다. 청구서보다 먼저 또는 동시에 완료, 확인, 청구를 세 묶음으로 정리하세요.

완료 사실을 보여주는 자료

• 계약 요구사항 대비 완료표
• 최종 버전 번호와 배포 일시
• 기능별 테스트 결과와 오류 수정 내역
• 데모 영상과 스테이징 접속 안내
• 알려진 제한사항과 계약 범위 밖 항목
• 최종 파일 목록과 파일별 설명

발주자의 확인과 사용을 보여주는 자료

• 요구사항과 디자인 승인 메일
• 중간 결과물 확인 메시지
• 발주자가 제출한 수정 요청과 개발자의 완료 회신
• 검수 회의록과 참석자
• 운영 서비스 공개 또는 실제 사용 기록
• 운영 배포 승인과 배포 결과

전자문서는 전자적 형태라는 이유만으로 법적 효력이 일률적으로 부인되는 것은 아닙니다. 다만 캡처 화면 한 장만 보관하면 앞뒤 대화와 첨부파일, 발신자 정보를 확인하기 어려울 수 있습니다.

원본 이메일, 메신저 대화 내보내기 파일, 첨부파일 원본, 저장소 기록, 파일 전송 내역을 함께 보관하세요. 파일명에는 날짜와 버전을 넣고, 수정본을 덮어쓰기보다 별도 보관하는 편이 좋습니다.

청구 내용을 한 장에 모으세요

청구 항목	기록 예시
계약 금액	부가가치세 포함 여부와 총 계약금
기존 지급액	계약금·중도금별 입금일과 금액
남은 잔금	공제 또는 추가 합의가 있다면 근거 포함
지급 기한	계약서 조항과 구체적인 날짜
청구 서류	청구서, 세금계산서, 거래명세서 등 합의된 서류
입금 후 이전물	소스 원본, 저장소 소유권, 운영 권한, 문서 원본

청구와 파일 관리를 한곳에서 정리하고 싶다면 인보이스와 입금 상태를 관리하는 문서 구조를 참고해 프로젝트별 청구일, 지급일, 후속 조치를 관리할 수 있습니다.

유지보수와 유료 도구는 잔금에서 분리합니다

프로젝트가 끝나지 않는 가장 흔한 이유 중 하나는 하자보수, 운영지원, 신규 기능이 모두 “마지막 수정”이라는 이름으로 섞이는 것입니다. 잔금은 계약 범위의 완료에 대한 대금이고, 유지보수는 완료 이후의 별도 서비스라는 경계를 세워야 합니다.

무상 하자보수와 추가 개발을 구분하세요

상황	분류 가능성	확인할 내용
합의한 기능이 지정 환경에서 작동하지 않음	하자보수 가능성	재현 조건과 요구사항 문서
수정 과정에서 기존 기능에 새로운 오류 발생	하자보수 가능성	변경 전후 버전과 영향 범위
새 화면·필드·권한·보고서 추가	추가 개발 가능성	초기 범위 포함 여부
발주자의 정책이나 업무 절차 변경	변경 요청 가능성	변경일과 추가 작업량
외부 서비스 정책·응용프로그램 인터페이스 변경	별도 유지보수 가능성	계약상 외부 변경 대응 범위
지원 대상이 아닌 기기·브라우저 요청	추가 범위 가능성	계약상 지원 환경

무료 관리와 유료 도구의 차이는 자동화보다 기록성입니다

방식	적합한 프로젝트	장점	확인할 점
기본형: 이메일·표 계산 문서	기간이 짧고 이해관계자가 적은 작업	비용이 거의 없고 시작이 빠름	버전과 승인 기록을 수동으로 관리해야 함
실속형: 프로젝트 관리·전자계약 도구	수정 요청과 마일스톤이 많은 작업	담당자, 기한, 변경 이력을 한곳에서 확인	내보내기 기능과 데이터 보관 정책 확인
전문형: 계약 검토·에스크로·법률 상담	금액이 크거나 권리·보안 위험이 높은 작업	분쟁 가능성을 계약 단계에서 점검	수수료, 지급 조건, 관할, 서비스 책임 범위 확인

유료 도구를 사용한다고 잔금이 보장되는 것은 아닙니다. 전자서명 기록, 변경 이력, 파일 내보내기, 계정 권한, 지급 조건 설정이 실제 업무 흐름에 맞는지 비교하세요.

계약 검토 비용을 지불할 가치가 큰 경우

• 잔금 비중이 크고 프로젝트 기간이 긴 경우
• 개인정보, 결제, 의료·금융 데이터 등 규제 정보가 포함된 경우
• 기존 보유 코드와 프로젝트 전용 코드가 섞이는 경우
• 지식재산권 귀속과 제3자 재판매 권한이 중요한 경우
• 발주자가 해외 법인이거나 준거법·관할이 다른 경우
• 서비스 중단이 다수 이용자의 피해로 이어질 수 있는 경우

상담 전에는 계약서만 보내지 말고 요구사항 문서, 견적서, 지급 내역, 수정 요청, 현재 이전한 권한, 아직 보유한 자산을 시간순으로 정리하세요. 상담 시간이 사실관계 확인에만 소모되는 것을 줄일 수 있습니다.

미지급 징후가 보일 때 대응 순서를 바꾸지 마세요

지급일이 지나면 마음이 급해집니다. 그러나 즉시 서비스를 차단하거나 감정적인 메시지를 보내면 원래의 대금 문제에 운영 장애와 손해배상 논쟁이 더해질 수 있습니다.

미지급 대응은 사실 확인, 비공식 확인, 공식 요청, 법적 절차 검토 순으로 진행하는 편이 안전합니다.

1단계: 사실관계를 한 장으로 정리합니다

• 계약일과 계약 당사자
• 총 계약 금액과 현재까지 입금액
• 작업 완료일과 검수 요청일
• 수정 요청일과 수정 완료일
• 계약상 잔금 지급일
• 발주자가 이미 받은 산출물과 권한
• 아직 이전하지 않은 핵심 자산
• 서비스의 현재 사용·운영 상태

2단계와 3단계: 회계 지연인지 분쟁인지 구분합니다

첫 메시지에서는 미입금이 단순 회계 지연인지, 세금계산서나 거래명세서가 누락됐는지, 내부 결재에 추가 자료가 필요한지 확인합니다. 지급 예정일을 구체적인 날짜로 요청하세요.

답변이 없거나 약속한 날짜가 다시 지나면 공식 지급 요청을 보냅니다. 계약 근거, 완료 근거, 미지급 금액, 지급 기한, 입금 계좌, 답변 요청일, 지급 후 이전할 자산을 포함합니다.

4단계: 내용증명·지급명령·민사소송을 비교합니다

방법	주요 목적	확인할 점
공식 지급 요청·내용증명	청구 의사와 기한을 명확히 전달	그 자체로 강제집행 권원이 되는 것은 아님
지급명령	금전 청구를 비교적 간소한 절차로 진행	상대방이 이의하면 통상 소송 절차로 이어질 수 있음
민사조정·소송	하자, 계약 해지, 손해배상 등 쟁점을 함께 판단	증거, 비용, 기간, 상대방 재산 상태 검토
강제집행	확정된 권원을 바탕으로 실제 회수 시도	상대방의 집행 가능한 재산 확인이 별도로 필요할 수 있음

지급명령이 확정되더라도 실제 입금이 자동으로 이뤄지는 것은 아닙니다. 상대방의 재산 상태와 집행 가능성까지 살펴야 하므로 미지급 금액, 증거 수준, 상대방의 이의 가능성을 기준으로 절차를 비교하세요.

자주 묻는 질문

계약서가 없어도 카카오톡 대화로 잔금을 청구할 수 있나요?

서명된 계약서가 없다는 이유만으로 청구가 언제나 불가능해지는 것은 아닙니다. 견적서, 계좌 입금, 요구사항 대화, 작업 파일, 승인 메시지, 서비스 사용 기록 등을 통해 계약의 존재와 범위, 대금을 설명할 수 있는지 살펴봐야 합니다.

다만 대화 일부만 잘라낸 캡처보다 원본 대화 내보내기, 첨부파일, 입금 기록, 버전 기록을 함께 보존하는 편이 좋습니다. 계약 조건을 다투는 상황이라면 개별 증거의 의미를 전문가에게 검토받으세요.

고객이 검수 의견을 보내지 않으면 언제까지 기다려야 하나요?

계약서에 검수 기한과 무응답 처리 방식이 있다면 우선 그 절차를 따릅니다. 규정이 없다면 검수 가능한 상태와 자료 제공 사실을 다시 알리고, 합리적인 회신 기한과 구체적인 테스트 방법을 제시하세요.

한 차례 메시지만 보내고 자동으로 승인됐다고 단정하기보다 공식 검수 요청, 리마인드, 실제 사용 여부, 중대한 오류 유무를 함께 기록하는 것이 안전합니다.

잔금 전에 워드프레스 최고 관리자 계정을 넘겨도 괜찮나요?

발주자가 콘텐츠 입력이나 기능 검수를 해야 한다면 제한된 관리자 계정을 먼저 제공하는 방법을 고려할 수 있습니다. 플러그인 삭제, 사용자 변경, 파일 편집, 결제 정보 접근 등 검수와 무관한 권한은 제한할 수 있습니다.

최고 관리자 권한의 최종 이전 시점은 계약상 인도·지급 조건과 일치시켜야 합니다. 이미 발주자 소유 계정에서 작업한 경우에는 임의 차단보다 변경 이력과 배포 승인 기록을 강화하세요.

고객 서버에서 개발했다면 소스코드 전달 시점을 어떻게 정하나요?

소스가 이미 고객 서버나 저장소에 존재한다면 파일을 넘기는 행위만으로 인도 시점을 구분하기 어렵습니다. 최종 버전의 커밋 식별값, 배포 일시, 브랜치, 완료표, 인수인계 확인서를 기준으로 인도 시점을 문서화하세요.

다음 프로젝트부터는 개발·검수·운영 브랜치를 분리하고, 병합과 배포 승인 절차를 지급 마일스톤과 연결하는 편이 좋습니다.

일부 기능에 오류가 있으면 잔금 전액을 받기 어려운가요?

오류의 중요도, 계약 목적에 미치는 영향, 수정 가능성, 이미 완료된 범위에 따라 판단이 달라질 수 있습니다. 핵심 기능을 사용할 수 없는 중대한 오류와 부수적인 표시 오류를 같은 수준으로 취급하기는 어렵습니다.

오류를 숨기지 말고 등급, 재현 조건, 임시 대안, 수정 예정일을 기록하세요. 잔금 지급과 하자보수의 관계는 계약 문구와 실제 이행 상태를 함께 검토해야 합니다.

고객이 신규 기능을 오류 수정이라고 주장하면 어떻게 구분하나요?

최종 승인된 요구사항 문서와 테스트 기준으로 돌아가야 합니다. 약속한 결과와 실제 결과가 다르면 오류 가능성이 높고, 기존 문서에 없던 화면·필드·권한·업무 규칙을 요구한다면 범위 변경 가능성이 높습니다.

판단이 애매하면 요청 내용을 작은 단위로 나누고, 기존 요구사항 번호, 예상 작업시간, 일정 영향, 추가 비용 여부를 표로 제시하세요.

세금계산서를 먼저 발행해야 잔금 지급을 요구할 수 있나요?

세금계산서 발행 시기와 대금 지급 조건은 거래 구조, 계약 내용, 사업자 유형에 따라 달라질 수 있습니다. 계약서에 청구서나 세금계산서 수령 후 지급한다고 정했다면 필요한 서류를 제때 발행해야 회계 지연을 줄일 수 있습니다.

세금계산서 발행이 곧 검수 완료나 권리 이전을 의미하는지는 별개의 문제입니다. 세무 처리와 계약상 인도 절차를 각각 기록하고, 발행 시기가 불분명하면 세무 전문가나 국세청 안내에서 최신 기준을 확인하세요.

미입금을 이유로 웹사이트나 앱을 중단해도 되나요?

계약서에 미지급 시 작업 중단이나 서비스 정지 권한이 있고 사전 통지 절차가 정해져 있는지 먼저 확인해야 합니다. 운영 서비스에는 발주자뿐 아니라 일반 이용자와 거래처의 데이터가 포함될 수 있습니다.

비밀번호 변경, 데이터 삭제, 도메인 차단처럼 회복하기 어려운 조치는 새로운 손해 문제를 만들 수 있습니다. 금액이 크거나 운영 피해 가능성이 있다면 실행 전에 법률 검토를 받는 편이 안전합니다.

프리랜서 계약이지만 사실상 직원처럼 일했다면 노동청에 신고할 수 있나요?

가능 여부는 계약 명칭이 아니라 실제 업무 관계를 기준으로 검토됩니다. 시간과 장소 통제, 업무 지시의 구체성, 전속성, 장비 제공, 보수 구조, 독립적인 사업 위험 부담 등을 종합적으로 살펴볼 수 있습니다.

외주대금 청구와 임금 체불은 절차와 판단 기준이 다르므로, 근로자성 가능성이 있다면 고용노동부 상담이나 노무 전문가의 검토를 통해 적절한 경로를 확인하세요.

지금 15분 안에 인도표 한 장을 만드세요

현재 프로젝트 폴더를 열고 산출물을 아래 네 칸으로 나누세요. 파일을 실제로 이동할 필요는 없습니다. 무엇을 언제 제공할지 표에 적는 것만으로도 다음 대화의 방향이 달라집니다.

구분	지금 기록할 내용
검수용 제공물	데모 주소, 테스트 계정, 기능 영상, 검수표
승인 후 제공물	운영 후보 버전, 문서 초안, 읽기·제한 권한
잔금 후 제공물	전체 소스, 저장소 소유권, 서버·도메인 최고 권한
보존할 증거	계약서, 승인 기록, 수정 내역, 테스트 결과, 청구 기록

그다음 발주자에게 현재 버전, 검수 마감일, 잔금 지급일, 입금 확인 후 이전할 자산을 한 번의 이메일로 확인받으세요. 이미 일정이 어긋났다면 숨기지 말고 새 기준일을 제안하는 편이 낫습니다.

최종 검토: 2026-07