외주 개발 마일스톤 결제 비율 계약서 예시는? > 인사이트

본문 바로가기

인사이트

외주 개발 마일스톤 결제 비율은 선금 몇 퍼센트가 맞느냐보다 각 지급 시점의 산출물과 검수 기준이 먼저입니다. 스타트업·중소기업은 선금은 착수 리스크를 공유하는 수준으로 낮추고, 중도금은 설계·개발·QA처럼 확인 가능한 산출물에 나누며, 잔금은 운영 배포·소스·계정·문서 인수 후 지급되도록 계약서에 써야 합니다. 아래 예시 비율과 조항은 그대로 복사하기보다 귀사의 범위·일정·업체 현금흐름에 맞춰 괄호를 채우는 실무 템플릿으로 보시면 됩니다.

외주 개발 마일스톤 결제 비율과 계약서를 검토하는 회의 장면
결제 비율은 선금 숫자가 아니라 산출물·검수·인수 조건과 함께 설계해야 한다.

주의: 이 글은 계약 실무 체크리스트이며 법률 자문이 아닙니다. 투자계약, 공공조달, 개인정보 대량 처리, 고액 장기 개발, 분쟁 중인 계약은 변호사 또는 전문 계약 검토를 거치세요.

1. 결제 비율을 정하기 전 확인할 5가지

마일스톤 결제는 “업체가 일했으니 지급”이 아니라 “계약서에 적힌 산출물이 나오고, 발주자가 검수할 수 있는 상태가 되었으니 지급”입니다. 과학기술정보통신부와 NIPA가 안내한 SW 표준계약서도 개발·구축, 유지관리, 상용SW 등 계약 유형을 나누어 배포하고 있으므로, 외주 계약서는 한 장짜리 견적서보다 산출물·검수·권리·유지보수 구조를 먼저 잡아야 합니다. ([nipa.kr](https://www.nipa.kr/home/bsnsAll/1/nttDetail?bbsNo=1&bsnsDtlsIemNo=&nttNo=7817&tab=3))

  1. 개발 범위가 확정됐는가? 화면 수, 사용자 권한, 관리자 기능, 외부 연동, 데이터 이전 범위가 불명확하면 선금을 크게 주지 않습니다.
  2. 설계 산출물이 개발 범위를 잠그는가? 화면 설계서가 단순 디자인 이미지인지, API·데이터·예외 상태까지 포함한 기능 명세인지 구분합니다.
  3. 검수 담당자가 실제로 테스트할 수 있는가? 검수 계정, 테스트 데이터, 시나리오, 결제 테스트 카드, 관리자 권한을 미리 정합니다.
  4. 잔금 전에 무엇을 넘겨받는가? 소스코드 저장소, 클라우드 계정, 배포 문서, DB 스키마, 운영 매뉴얼이 잔금 조건에 들어가야 합니다.
  5. 변경 요청을 누가 승인하는가? 대표, PM, 마케팅팀, 운영팀이 각자 “기능 하나만 더”를 말하면 일정과 비용이 무너집니다. 변경 승인권자를 1명으로 둡니다.

비용 지불 방식 자체가 처음이라면 먼저 외주개발 비용 지불 구조 가이드에서 고정가·마일스톤·T&M 구조를 비교한 뒤, 이 글의 계약 조항으로 내려오면 이해가 쉽습니다.

2. 마일스톤별 결제 비율 예시표

아래 비율은 시장 평균이나 법정 기준이 아니라 실무에서 협상안을 만들 때 쓰는 예시 구조입니다. 계약금액 100% 중 유지보수비, 클라우드비, PG 가입비, 문자·지도·LLM API 같은 외부 실비는 별도인지 포함인지 먼저 표시해야 합니다.

프로젝트 유형예시 결제 비율지급 트리거주의할 점
홈페이지 리뉴얼·소규모 관리자착수 20% / 화면·콘텐츠 구조 승인 30% / 개발 완료 30% / 배포·인수 20%페이지 목록, 반응형 시안, 관리자 CRUD, 운영 배포 확인콘텐츠 입력, 이미지 구매, 번역, 검색엔진 등록 범위를 별도 표시
웹서비스·SaaS MVP착수 20% / 요구사항·화면설계 20% / 핵심 기능 1차 30% / QA·수정 20% / 인수인계 10%사용자 플로우, API 명세, 스테이징 테스트, 운영 배포, 소스·문서 인수잔금 10%를 너무 작게 두면 인수인계 협상력이 약해질 수 있어 산출물 조건을 촘촘히 적어야 함
예약·매칭·결제 시스템착수 15% / 설계 20% / 예약·매칭 25% / 결제·알림·정산 25% / 배포·인수 15%상태값, 결제 취소·환불, 관리자 정산, 알림 실패 재시도 테스트PG 심사, 카드사 정책, 정산 로직 변경은 외부 변수이므로 책임과 일정 제외 사유를 명시
AI 기능·자동화·RAG 프로토타입착수 10% / 2~4주 스프린트별 검수 정산 / 최종 운영 연결 10~20%테스트 데이터셋, 응답 품질 기준, 비용 로그, 관리자 승인 흐름, 실패 시 대체 경로모델 성능을 추상적으로 보장하지 말고 평가 질문, 금지 응답, 비용 한도, 재시도 정책을 검수 기준으로 둠
정부지원 MVP·사업화 과제착수 20% / 설계 20% / 1차 구현 30% / 최종검수·성과증빙 30%협약상 개발 범위, 견적서 항목, 세금계산서, 산출물 파일, 결과보고 증빙지원사업 집행 규정이 우선입니다. 사업비 선집행 가능 여부와 증빙 양식은 전담기관 안내를 따르세요.

선금 50%가 항상 부당한 것은 아닙니다. 다만 선금이 높다면 해지 시 기성고 산정, 미완료 산출물 반환, 소스·설계 문서 소유, 일정 지연 시 조정 기준까지 함께 올라와야 합니다.

위험한 외주 개발 계약 조항과 안전한 조항 비교 화면
같은 결제 비율이라도 조항 문구에 따라 발주자 리스크가 달라진다.

3. 계약서에 바로 넣는 핵심 조항 예시

3-1. 대금 지급 조항

제○조 대금 및 지급 조건
총 계약금액은 금 [ ]원으로 하며 부가가치세 [포함/별도]로 한다. 갑은 아래 표의 마일스톤 산출물이 제출되고 제○조의 검수 절차에 따라 승인된 경우, 각 단계별 금액을 을의 세금계산서 발행일로부터 [ ]영업일 이내 지급한다.

  • 1차 착수금: 계약 체결 및 착수회의 완료 후 총 계약금액의 [20]%
  • 2차 설계 중도금: 요구사항정의서, 화면목록, 주요 화면설계, 데이터·API 개요 승인 후 [20]%
  • 3차 개발 중도금: 스테이징 서버에서 핵심 기능 [목록 기재] 테스트 가능 상태 확인 후 [30]%
  • 4차 QA 중도금: 치명·주요 결함 수정, 테스트 결과표 제출, 운영 배포 준비 완료 후 [20]%
  • 잔금: 운영 배포, 소스코드 저장소 권한, 서버·도메인·DB 계정, 배포 문서, 관리자 매뉴얼 인수 후 [10]%

핵심은 “착수회의 완료”처럼 실제 가치가 낮은 이벤트에 큰 금액을 걸지 않는 것입니다. 설계·개발·QA·인수인계처럼 발주자가 확인 가능한 산출물을 지급 트리거로 둬야 합니다.

3-2. 검수 조항

제○조 검수
을은 각 마일스톤 완료 시 검수요청서와 산출물 목록을 갑에게 제출한다. 갑은 검수요청서를 받은 날로부터 [7~10]영업일 이내 합격, 조건부 합격, 불합격 및 보완 요청사항을 서면 또는 협업도구에 기록하여 통지한다. 불합격 또는 조건부 합격 시 을은 [ ]영업일 이내 보완하고, 갑은 보완 완료 통지일로부터 [ ]영업일 이내 재검수한다.

소프트웨어사업 표준하도급계약서에는 지식·정보성과물 수령 후 정당한 사유가 없으면 10일 이내 검수결과를 서면 통지하고, 기간 내 통지하지 않으면 합격으로 보는 구조가 포함되어 있습니다. 민간 발주자는 내부 의사결정 기간, 휴가, 외부기관 승인, 앱 심사 같은 변수를 고려해 검수 기간과 간주승인 예외를 조정해야 합니다. ([law.go.kr](https://www.law.go.kr/flDownload.do%3FflSeq%3D13209691))

3-3. 산출물 인수 조항

제○조 산출물 및 인수인계
을은 잔금 청구 전 다음 산출물을 갑에게 인도한다. 소스코드 저장소 관리자 권한, 배포 가능한 최신 브랜치, 환경변수 목록, DB 스키마 및 마이그레이션 파일, API 문서, 관리자 매뉴얼, 배포·복구 절차서, 외부 서비스 계정 목록, 오픈소스·상용 라이선스 목록, 하자보수 접수 채널과 담당자 정보를 포함한다.

서버와 계정 인수는 기능 검수와 별개의 리스크입니다. 클라우드·도메인·DNS·결제·문자·메일 계정을 업체 개인 명의로 둔 채 잔금을 지급하면 운영권이 사실상 넘어오지 않습니다. 구체적인 계정 항목은 외주개발 서버 인수 체크리스트를 함께 확인하세요.

3-4. 지연 및 책임 조항

제○조 일정 지연
을의 귀책으로 각 마일스톤 납기일이 지연되는 경우, 갑은 지연일수에 대하여 [해당 마일스톤 금액 또는 미지급 잔여대금] × [ ]%를 지체상금으로 산정할 수 있다. 단, 갑의 자료 제공 지연, 의사결정 지연, 계정 승인 지연, 외부기관 심사 지연, 천재지변, 양사가 승인한 범위변경으로 인한 일정 변경 기간은 지연일수에서 제외한다. 지체상금 총액은 [ ]원을 한도로 한다.

표준하도급계약서에는 지체상금, 기성부분 공제, 갑의 책임으로 인한 착수 지연·중단 등의 제외 사유 구조가 들어 있습니다. 다만 그 수치와 구조를 민간 스타트업 계약에 그대로 가져오기보다 기준금액, 일율, 한도, 귀책 제외 사유를 프로젝트에 맞춰 별도로 합의해야 합니다. ([law.go.kr](https://www.law.go.kr/flDownload.do%3FflSeq%3D13209691))

3-5. 범위변경 및 추가비 조항

제○조 과업 범위 변경
계약서, 제안서, 요구사항정의서, 화면설계서에 명시되지 않은 기능 추가, 정책 변경, 외부 연동 추가, 디자인 전면 변경, 데이터 이전 범위 확대는 범위변경으로 본다. 범위변경은 변경요청서에 기능 설명, 제외 범위, 추가 산출물, 추가 비용, 일정 영향, 검수 기준을 기재하고 양사 책임자의 서면 승인 후 진행한다. 승인 전 구두 요청, 회의 중 발언, 메신저 의견은 범위변경 승인으로 보지 않는다.

공공 소프트웨어사업에서는 과업내용 확정, 과업내용 변경, 그에 따른 계약금액·계약기간 조정이 과업심의의 대상이 됩니다. 민간 계약에 공공 절차가 그대로 적용되는 것은 아니지만, “변경 요청 → 비용·일정 영향 산정 → 서면 승인 → 계약 반영”이라는 구조는 스타트업 외주에서도 그대로 차용할 만합니다. ([law.go.kr](https://www.law.go.kr/lsLinkCommonInfo.do?lsJoLnkSeq=1031614471)) ([law.go.kr](https://www.law.go.kr/LSW/lsSideInfoP.do?docCls=jo&joBrNo=00&joNo=0047&lsiSeq=281427&urlMode=lsScJoRltInfoR&utm_source=openai))

외주 개발 설계 개발 QA 배포 인수인계 워크플로우 보드
마일스톤은 일정표가 아니라 지급 가능한 산출물의 흐름이다.

4. 범위변경 추가비 산정식

추가비를 “협의한다”라고만 쓰면 협의가 결렬되는 순간 프로젝트가 멈춥니다. 계약서에 단가표를 넣거나, 최소한 산정식을 넣어두면 감정 싸움을 줄일 수 있습니다.

추가비 예시 산정식
추가비 = 추가·변경 기능 예상 공수 × 계약서상 역할별 단가 + 직접경비 + 외부 서비스 비용 + 추가 QA·문서 보정비

일정 영향 예시 산정식
추가 일정 = 추가 개발일 + QA·재검수일 + 외부 승인 대기일 + 배포 준비일

역할별 단가는 “기획 [ ]원/일, UI [ ]원/일, 프론트엔드 [ ]원/일, 백엔드 [ ]원/일, QA [ ]원/일”처럼 계약서 부속 견적서에 둡니다. KOSA는 SW사업대가 산정 방식별 템플릿과 대가산정 가이드를 자료실에서 운영하고 있으므로, 공공·대형 프로젝트나 예산 산정 근거가 필요한 경우에는 최신 가이드를 참고해 산정 방식의 언어를 맞추는 것이 좋습니다. ([sw.or.kr](https://www.sw.or.kr/site/sw/ex/board/List.do?cbIdx=276))

5. 산출물별 검수 기준표

발주자가 가장 자주 놓치는 부분은 “개발 완료”의 정의입니다. 기능이 보이는 것과 인수 가능한 것은 다릅니다.

마일스톤필수 산출물합격 기준불합격 예시
요구사항 정의기능 목록, 제외 범위, 사용자 역할, 관리자 역할, 데이터 흐름대표·PM·운영 담당자가 같은 범위를 이해하고 서명 또는 승인 기록을 남김“관리자 페이지 포함”처럼 메뉴·권한·처리 상태가 없는 문장만 존재
UI·화면설계화면 목록, 주요 화면, 상태별 화면, 입력값 검증, 오류 메시지개발자가 화면만 보고 입력·수정·삭제·검색·정렬·권한 조건을 구현할 수 있음예쁜 메인 화면만 있고 회원가입 실패, 결제 실패, 빈 데이터 화면이 없음
백엔드·APIAPI 명세, 인증 방식, DB ERD, 로그 정책, 배치·알림 정책스테이징에서 프론트엔드와 연동되고 주요 예외가 기록됨API는 있으나 오류 코드, 권한 오류, 재시도 정책이 문서화되지 않음
관리자 시스템계정·권한, 목록·검색·필터, 상세·수정, CSV, 감사 로그운영자가 고객 문의, 주문·예약·정산, 콘텐츠 수정 업무를 직접 처리 가능개발자 DB 수정 없이는 운영 데이터를 바꿀 수 없음
QA테스트 케이스, 결함 목록, 수정 내역, 재검수 결과치명 결함 0건, 주요 결함 처리 기준 합의, 잔여 경미 결함 목록화“테스트 완료”라고만 하고 어떤 기능을 확인했는지 기록이 없음
배포·인수소스, 계정, 배포 문서, 백업·복구 절차, 라이선스 목록, 운영 매뉴얼발주자 계정으로 배포·백업·장애 대응의 최소 절차를 재현 가능운영 서버 접속권한이 업체에게만 있고 발주자는 화면만 확인 가능

6. 나쁜 조항과 더 안전한 조항 비교

위험한 문구왜 위험한가더 안전한 문구 방향
계약금 50%, 잔금 50%로 지급한다.설계·개발·QA 중간 통제권이 약합니다.착수, 설계 승인, 1차 구현, QA, 배포·인수로 쪼개고 각 산출물을 표로 붙입니다.
검수는 상호 협의하여 진행한다.검수 기간, 불합격 기준, 재검수 절차가 없어 잔금 분쟁이 생깁니다.검수요청서 제출일, 검수 기간, 보완 기간, 재검수 횟수, 조건부 합격 기준을 둡니다.
필요한 기능은 개발 중 협의하여 반영한다.무상 추가 범위로 해석될 수 있습니다.계약 산출물에 없는 기능은 범위변경이며 변경요청서 승인 후 진행한다고 씁니다.
하자보수 1년을 제공한다.버그 수정과 기능 개선, 운영 문의, 데이터 수정이 섞입니다.하자, 유지보수, 기능개선, 운영지원, 교육, 데이터 정리의 범위를 각각 구분합니다.
소스코드를 제공한다.압축파일만 받아서는 운영·수정이 어렵습니다.저장소 관리자 권한, 최신 브랜치, 빌드 방법, 환경변수, 배포 절차, 라이선스 목록까지 포함합니다.
서버는 업체가 관리한다.업체 교체 시 운영권 이전이 어렵습니다.클라우드·도메인·DNS·DB·스토리지·메일·문자 계정의 소유자와 관리자 권한을 발주자로 둡니다.

범위 변경이 자주 생기는 팀이라면 외주개발 스코프 변경 관리 가이드의 변경요청서 구조를 함께 계약 부속문서로 붙여두는 편이 좋습니다.

외주 개발 계약 전 검수 산출물 인수 체크리스트를 확인하는 장면
잔금 지급 전에는 기능보다 계정·문서·소스·배포권한을 먼저 확인한다.

7. 계약 전 복사 체크리스트

  • 계약금액에 부가세 포함 여부를 표시했다.
  • 선금·중도금·잔금의 각 비율 합계가 100%인지 확인했다.
  • 각 지급 단계마다 산출물 이름과 파일 형식이 있다.
  • 검수요청서 제출 방식과 검수 기간을 정했다.
  • 불합격 시 보완 기간과 재검수 기준을 정했다.
  • 발주자 자료 제공 지연 시 일정이 자동 조정되는지 적었다.
  • 외부 API, PG, 지도, 문자, 메일, LLM API 비용 부담자를 정했다.
  • 디자인 수정 횟수와 전면 변경 기준을 적었다.
  • 관리자 권한, 역할, 로그, CSV 다운로드 범위를 적었다.
  • 개인정보 처리, 접근권한, 로그 보관, 백업 기준을 정했다.
  • 소스코드 저장소 관리자 권한 인수 시점을 잔금 조건에 넣었다.
  • 클라우드, 도메인, DNS, DB, 스토리지 계정 소유자를 발주자로 정했다.
  • 오픈소스·상용 라이선스 목록 제출을 요구했다.
  • 하자보수와 기능개선의 차이를 정의했다.
  • 하자 접수 채널, 응답 시간, 처리 우선순위를 정했다.
  • 범위변경 승인권자를 1명으로 정했다.
  • 추가비 산정식 또는 역할별 단가표를 붙였다.
  • 지연 책임에서 발주자 지연과 외부 승인 지연을 제외했다.
  • 계약 해지 시 기성 산출물과 미사용 선금 정산 기준을 적었다.
  • 잔금 지급 전 배포 문서와 운영 매뉴얼을 받도록 했다.

8. 하자보수 조항은 “무료 유지보수”가 아니다

공공 소프트웨어사업의 경우 소프트웨어 진흥법에는 최종 소프트웨어 산출물을 인도한 날부터 1년 이내 발생한 하자에 대한 담보책임 규정이 있습니다. 다만 민간 외주 계약에서 “하자보수 1년”이라고만 쓰면 버그 수정, 기능 개선, 운영 문의, 데이터 수정, 서버 장애 대응까지 섞여 분쟁이 생기므로, 하자의 정의와 제외 항목을 따로 써야 합니다. ([law.go.kr](https://www.law.go.kr/LSW/lsInfoP.do?ancYnChk=0&chrClsCd=010202&efYd=20240724&joNo=004600&lsiSeq=258993&urlMode=lsInfoP&utm_source=openai))

하자보수 조항 예시
하자란 계약서 및 승인된 산출물의 명시 기능이 재현 가능한 오류로 작동하지 않는 경우를 말한다. 다음 항목은 하자보수에 포함하지 않는다: 신규 기능 추가, 정책 변경, 디자인 변경, 외부 API 정책 변경 대응, 발주자 또는 제3자의 데이터 오입력 수정, 운영자 교육, 대량 데이터 정리, 성능 목표가 계약서에 없는 트래픽 증가 대응. 해당 항목은 별도 유지보수 또는 범위변경 계약으로 처리한다.

9. AgentMit이 계약 전에 보는 포인트

AgentMit은 단순히 “저렴한 개발 견적”보다 MVP·SaaS·웹서비스·관리자 시스템의 개발 범위를 먼저 구조화하는 쪽에 가깝습니다. BizMit 기반 업무 자동화, AI 기능, 관리자 대시보드, 예약·매칭·결제 흐름처럼 운영 로직이 있는 프로젝트는 결제 비율보다 산출물과 검수 기준을 먼저 잡아야 실제 서비스 전환이 가능합니다.

이미 견적서나 계약서 초안이 있다면 기능 목록, 마일스톤, 잔금 조건, 서버·소스 인수, 유지보수 범위를 표시해 오세요. AgentMit은 범위 검토, MVP 개발 견적, 설계·개발·QA·배포·유지보수 구조를 함께 정리해 드릴 수 있습니다. 필요하면 AgentMit 개발 상담으로 범위 검토 요청을 남겨 주세요.

참고한 공공·표준 자료

  • NIPA SW종사자 표준계약서 활용 안내: 개발·구축, 유지관리, 도급 등 계약 유형을 구분해 참고했습니다. ([nipa.kr](https://www.nipa.kr/home/bsnsAll/1/nttDetail?bbsNo=1&bsnsDtlsIemNo=&nttNo=7817&tab=3))
  • 소프트웨어 진흥법 제50조 및 시행령 제47조: 공공 소프트웨어사업의 과업 확정·변경, 계약금액·계약기간 조정 구조를 민간 변경관리 조항 작성에 참고했습니다. ([law.go.kr](https://www.law.go.kr/lsLinkCommonInfo.do?lsJoLnkSeq=1031614471)) ([law.go.kr](https://www.law.go.kr/LSW/lsSideInfoP.do?docCls=jo&joBrNo=00&joNo=0047&lsiSeq=281427&urlMode=lsScJoRltInfoR&utm_source=openai))
  • 소프트웨어사업 표준하도급계약서: 검수 통지, 불합격 처리, 하자보증, 지체상금, 지식재산권, 기술자료 예치 조항의 구조를 참고했습니다. ([law.go.kr](https://www.law.go.kr/flDownload.do%3FflSeq%3D13209691))
  • KOSA 사업대가 자료실: 최신 SW사업대가 산정 템플릿과 가이드가 운영되는 자료 출처를 확인했습니다. ([sw.or.kr](https://www.sw.or.kr/site/sw/ex/board/List.do?cbIdx=276))

FAQ

Q1. 외주 개발 선금 50%는 무조건 위험한가요?

무조건 위험하다고 볼 수는 없지만, 산출물과 해지 시 정산 기준이 없으면 발주자에게 불리합니다. 범위가 작고 기간이 짧으며 기존 협업 이력이 있는 경우가 아니라면 선금을 낮추고 설계·개발·검수·인수 단계로 나누는 편이 안전합니다.

Q2. 화면 설계 완료 시점에 중도금을 지급해도 되나요?

가능합니다. 다만 단순 Figma 화면이 아니라 화면 목록, 사용자 흐름, 입력값 검증, 예외 상태, 관리자 권한, API·데이터 항목까지 검수 기준으로 적어야 합니다. 설계 산출물이 개발 범위를 확정하는 문서가 되어야 중도금 지급 근거가 됩니다.

Q3. 외주 개발 검수 기간은 계약서에 며칠로 쓰는 것이 좋나요?

정답은 없지만 MVP·관리자 시스템은 7~10영업일, 결제·외부 API·기관 승인 연동이 있으면 더 길게 잡는 식으로 정합니다. 검수 기간보다 중요한 것은 검수 항목표, 재검수 횟수, 발주자 자료 지연 시 일정 조정 기준입니다.

Q4. 잔금은 배포 전에 줘야 하나요, 배포 후에 줘야 하나요?

운영 배포, 소스코드 저장소 권한, 클라우드·도메인·DB 계정, 배포 문서, 관리자 매뉴얼을 받은 뒤 지급되도록 하는 것이 안전합니다. 앱스토어 심사처럼 외부 승인 기간이 있는 경우에는 배포 신청 완료와 최종 승인 후 지급분을 분리할 수 있습니다.

Q5. 범위 변경 추가비는 계약서에 어떻게 넣어야 하나요?

구두 요청은 효력이 없고, 변경요청서에 기능 설명, 제외 범위, 추가 비용, 일정 영향, 검수 기준을 적은 뒤 양사가 승인해야 한다고 쓰는 방식이 실무적입니다. 추가비는 역할별 단가 또는 스프린트 단가를 계약서에 미리 두고 산정하면 분쟁을 줄일 수 있습니다.

자주 묻는 질문

외주 개발 선금 50%는 무조건 위험한가요?
무조건 위험하다고 볼 수는 없지만, 산출물과 해지 시 정산 기준이 없으면 발주자에게 불리합니다. 범위가 작고 기간이 짧으며 기존 협업 이력이 있는 경우가 아니라면 선금을 낮추고 설계·개발·검수·인수 단계로 나누는 편이 안전합니다.
화면 설계 완료 시점에 중도금을 지급해도 되나요?
가능합니다. 다만 단순 Figma 화면이 아니라 화면 목록, 사용자 흐름, 입력값 검증, 예외 상태, 관리자 권한, API·데이터 항목까지 검수 기준으로 적어야 합니다. 설계 산출물이 개발 범위를 확정하는 문서가 되어야 중도금 지급 근거가 됩니다.
외주 개발 검수 기간은 계약서에 며칠로 쓰는 것이 좋나요?
정답은 없지만 MVP·관리자 시스템은 7~10영업일, 결제·외부 API·기관 승인 연동이 있으면 더 길게 잡는 식으로 정합니다. 검수 기간보다 중요한 것은 검수 항목표, 재검수 횟수, 발주자 자료 지연 시 일정 조정 기준입니다.
잔금은 배포 전에 줘야 하나요, 배포 후에 줘야 하나요?
운영 배포, 소스코드 저장소 권한, 클라우드·도메인·DB 계정, 배포 문서, 관리자 매뉴얼을 받은 뒤 지급되도록 하는 것이 안전합니다. 앱스토어 심사처럼 외부 승인 기간이 있는 경우에는 배포 신청 완료와 최종 승인 후 지급분을 분리할 수 있습니다.
범위 변경 추가비는 계약서에 어떻게 넣어야 하나요?
구두 요청은 효력이 없고, 변경요청서에 기능 설명, 제외 범위, 추가 비용, 일정 영향, 검수 기준을 적은 뒤 양사가 승인해야 한다고 쓰는 방식이 실무적입니다. 추가비는 역할별 단가 또는 스프린트 단가를 계약서에 미리 두고 산정하면 분쟁을 줄일 수 있습니다.
  • Company. 주식회사 에이전트밋
  • Addr.부산광역시 남구 전포대로 133, 11층 102호(문현동) CEO. 윤성훈 Email. agentmit@naver.com
  • BR. 333-87-04232 TEL. 0507-1314-2790
Copyright © 2026 ~ 에이전트밋. All rights reserved.