웹사이트 제작 중 추가 비용을 계속 요구받는다면 확인할 기준

웹사이트 제작 도중 또는 납품 직전에 예상하지 못한 추가 견적서를 받았다면, 먼저 그 작업이 원래 계약 범위인지, 고객이 새로 요청한 변경인지, 제작업체의 오류를 고치는 일인지를 구분해야 합니다. 업체가 ‘추가 작업’이라고 부른다고 바로 비용을 내야 하는 것도 아니고, 총액 계약을 했다는 이유만으로 모든 변경이 무료가 되는 것도 아닙니다.

판단의 출발점은 계약서 제목보다 실제 합의 내용입니다. 웹사이트 제작은 결과물을 완성하는 계약의 성격이 강하지만, 운영 지원이나 지속적인 디자인 업무가 함께 포함되면 업무 위임의 성격이 섞일 수 있습니다. 따라서 계약서, 제안서, 기능명세서와 실제 요청 과정을 함께 살펴봐야 합니다.

원래 기능, 변경 작업, 오류 수정을 나누어 봅니다

‘쇼핑몰 제작’, ‘예약 시스템 구축’처럼 넓은 문구만으로는 구체적인 범위를 알기 어렵습니다. 회원가입 방식, 결제수단, 관리자 페이지, 모바일 대응, 외부 서비스 연동처럼 세부 기능이 기능명세서나 견적서에 적혀 있는지 확인해야 합니다.

원래 계약 범위

계약서와 견적서에 포함된 페이지·기능, 제안 단계에서 구현하기로 명확히 답한 사항, 약정한 수정 횟수 안의 작업이 여기에 해당할 수 있습니다.

추가 또는 변경 작업

승인된 화면을 전면 변경하거나 새로운 기능·페이지를 넣은 경우, 추가 외부 연동을 요청한 경우에는 별도 비용이 문제 될 수 있습니다.

하자 또는 오류 수정

합의한 기능이 작동하지 않거나 승인된 화면과 다르게 구현된 경우라면, 새로운 작업보다 기존 의무를 제대로 이행하는 문제에 가까울 수 있습니다.

다만 같은 작업도 원인에 따라 달라집니다. 결제 오류가 제작상의 문제인지, 고객이 나중에 바꾼 서버 환경이나 외부 결제업체의 정책 변경 때문인지 확인해야 합니다. ‘수정’이라는 이름만으로 무료 또는 유료라고 단정할 수는 없습니다.

추가 비용의 핵심은 요청과 승인 기록입니다

추가 작업을 요청하면서 비용이나 일정에 관한 대화를 전혀 하지 않았다면 분쟁이 커지기 쉽습니다. 서면으로 추가 비용에 합의한 자료가 가장 분명하지만, 서면 합의가 없다고 언제나 비용 청구가 불가능한 것은 아닙니다. 고객이 작업 내용을 구체적으로 요청했고, 통상 유상임을 알 수 있었으며, 결과물을 확인하고 사용한 사정 등이 함께 검토될 수 있습니다.

반대로 제작업체가 사전 설명 없이 기능을 늘렸거나, 자신의 설계 오류 때문에 다시 작업한 경우에는 추가 대금의 근거가 약해질 수 있습니다. 담당 직원이 승인한 경우에는 그 직원에게 비용을 확정할 권한이 있었는지도 확인해야 합니다.

• 서명한 계약서와 부속 기능명세서의 최종 버전
• 최초 견적서, 추가 견적서, 세금계산서와 입출금 내역
• 이메일·메신저 원문과 요청·답변 날짜
• 화면 시안 승인 기록과 약정한 수정 횟수
• 업무관리 도구, 개발 이력, 테스트 서버와 배포 기록
• 추가 비용을 처음 알린 날짜와 산출 근거

메신저 화면을 일부만 캡처하면 앞뒤 문맥이나 날짜가 빠질 수 있습니다. 가능하면 대화 원문을 내보내고, 파일명과 작성일이 보이는 제안서·시안도 원본 상태로 보관하는 편이 좋습니다.

금액도 항목별 근거가 있어야 합니다

추가 작업 자체가 인정되더라도 청구한 금액이 그대로 확정되는 것은 아닙니다. 별도로 합의한 단가가 있는지, 투입 시간과 인원이 실제 작업에 맞는지, 외부 프로그램 사용료나 서버 비용을 누가 부담하기로 했는지 살펴봐야 합니다. 단순히 ‘개발 난도가 높았다’는 설명만으로는 산정 과정을 확인하기 어렵습니다.

고정 금액 계약이라면 제작업체가 예상보다 많은 시간이 들었다는 사정만으로 곧바로 추가 비용을 청구하기는 어려울 수 있습니다. 그러나 고객이 중간에 구조를 바꾸거나 기능을 계속 늘렸다면 고정 금액의 범위를 벗어났다고 판단될 여지도 있습니다. 견적서에 ‘별도 협의’, ‘외부 연동 제외’, ‘수정 2회 포함’ 같은 문구가 있는지 확인해야 하는 이유입니다.

비용 분쟁이 생겼을 때 정리하는 순서

추가 비용에 동의하지 않는다면 단순히 지급을 거절하기보다 어느 항목을 왜 다투는지 구분해 전달하는 것이 좋습니다. 다툼이 없는 잔금과 문제 되는 추가비를 섞지 않으면 이후 이행 지연의 책임을 판단하기도 쉬워집니다.

1. 계약 범위를 한 문서에 모읍니다

   계약서, 견적서, 기능명세서, 시안과 수정 요청을 날짜순으로 배열합니다.

2. 추가 견적의 세부 내역을 확인합니다

   작업명, 요청일, 승인자, 투입 시간, 단가와 외부 비용을 항목별로 요청해 기존 합의와 대조합니다.

3. 동의 여부와 이행 방향을 서면으로 남깁니다

   원래 범위의 작업은 계속할 것인지, 변경 작업은 보류할 것인지, 새 일정과 비용에 합의할 것인지 구분해 기록합니다.

4. 계약 종료 문제는 이행 상태를 확인한 뒤 검토합니다

   원래 의무가 이행되지 않았다면 상당한 기간을 정해 이행을 요구하는 절차가 필요한 경우가 있습니다. 이행이 불가능하거나 위반이 중대한 경우처럼 예외가 될 사정도 따로 확인해야 합니다.

제작업체가 보낸 청구서에 지급기한이 적혀 있다는 이유만으로 다투는 추가 대금이 자동으로 확정되지는 않습니다. 다만 법원의 지급명령이나 소장 같은 서류를 받았다면 이야기가 다릅니다. 답변이나 이의 제기 기간은 보통 서류가 송달된 날을 기준으로 계산되므로, 봉투와 송달일, 문서에 적힌 안내를 바로 확인해야 합니다.

사이트와 계정 자료도 함께 지켜야 합니다

비용 다툼이 생기면 도메인, 서버, 관리자 계정, 소스코드와 디자인 원본을 누가 관리하는지도 중요해집니다. 대금이 남았다는 이유로 사이트 접속이 막히거나, 반대로 고객이 개발 계정을 갑자기 차단하면 손해와 책임을 둘러싼 새로운 분쟁이 생길 수 있습니다. 계약에 납품 조건, 소스코드 인도 시점, 이용 권한과 계정 명의가 어떻게 정해져 있는지 먼저 확인해야 합니다.

추가 제작비 청구권의 시효는 일반적으로 돈을 청구할 수 있게 된 때가 출발점이 되지만, 계약상 지급 조건과 작업 완료·검수 시점에 따라 달라질 수 있습니다. 일부 지급, 채무 인정, 재판상 청구 등으로 계산이 달라질 가능성도 있으므로 오래된 청구라면 계약서의 지급일과 마지막 합의 날짜를 함께 확인해야 합니다.

결국 중요한 것은 ‘추가 비용’이라는 이름이 아니라 처음 약속한 범위, 이후 변경 요청, 비용 안내와 승인, 실제 완료된 작업을 연결하는 일입니다. 이 네 가지가 시간순으로 정리되면 지급할 항목과 다툴 항목, 계약을 계속할 조건을 보다 분명하게 나눌 수 있습니다.