외주개발 비용 지불 구조 가이드: 고정가·마일스톤·T&M·성과보수 비교

정답부터: 외주개발 비용은 총액보다 지불 구조가 더 중요합니다
외주개발 비용 지불 구조의 정답은 하나가 아닙니다. 요구사항이 이미 확정되어 있고 산출물을 객관적으로 검수할 수 있다면 고정가에 마일스톤 지급을 붙이는 방식이 안전합니다. 반대로 MVP, SaaS, 예약·결제·매칭 서비스, AI 기능, 데이터 이전처럼 만들면서 판단해야 하는 일이 많다면 순수 고정가보다 ‘고정가 discovery → 핵심 범위 마일스톤 → 변경 구간 상한 있는 T&M → 출시 후 유지보수’로 나누는 편이 리스크를 줄입니다. 성과보수는 개발비를 대체하는 방식이 아니라 제한된 인센티브로만 쓰는 것이 안전합니다.
많은 분쟁은 견적 총액이 비싸서가 아니라 ‘언제 지급하는가’, ‘무엇을 완료로 볼 것인가’, ‘변경 요청은 어떻게 계산하는가’, ‘잔금 전 무엇을 인수받는가’가 비어 있어서 발생합니다. 특히 웹·앱 서비스는 화면이 보인다고 끝난 것이 아닙니다. 관리자 권한, 서버 배포, 결제 승인·취소·환불, 알림, 로그, 데이터 이전, QA, 소스코드와 운영 문서까지 연결되어야 실제 운영이 가능합니다.
계약서에서 ‘개발 완료 후 잔금 지급’이라는 문장만 있으면 부족합니다. ‘개발 완료’가 staging 배포인지, 운영 서버 배포인지, 결제 연동까지인지, 소스코드 인수까지인지, 하자 수정까지인지 분리해야 합니다.
왜 검수 기준이 지불 구조의 핵심인가
외주개발 계약은 실무상 도급 성격을 갖는 경우가 많습니다. 민법상 도급은 일을 완성하고 그 결과에 대해 보수를 지급하는 구조이며, 보수 지급은 완성된 목적물의 인도 또는 일의 완성과 연결됩니다. 대법원 판례도 목적물 인도를 단순한 파일 전달이 아니라 도급인이 검사 후 계약 내용대로 완성되었음을 명시적 또는 묵시적으로 시인하는 의미까지 포함한다고 보았습니다. 그래서 발주사는 ‘검수’가 무엇인지 계약서에 써야 하고, 개발사는 ‘어떤 상태가 되면 대금을 받을 수 있는지’를 알아야 합니다. ([law.go.kr](https://www.law.go.kr/LSW/lsInfoP.do?lsiSeq=58433&utm_source=openai))
공공 SW사업 지침에서도 예산과 과업 범위를 잡을 때 기능·비기능 요구사항과 하드웨어·소프트웨어 도입 비용 등 과업의 내용과 범위를 명확히 해야 한다는 취지가 반복됩니다. 민간 외주 프로젝트에 그대로 적용되는 강행 규칙은 아니더라도, 요구사항과 변경 절차를 문서화해야 한다는 운영 원칙은 그대로 유효합니다. ([nhis.or.kr](https://www.nhis.or.kr/lm/lmxsrv/law/lawFullContent.do?SEQ=1540&SEQ_HISTORY=44804&utm_source=openai))
따라서 결제 구조를 고르기 전에 먼저 세 가지 질문을 해야 합니다. 첫째, 요구사항이 얼마나 확정되어 있는가. 둘째, 산출물을 누가 어떤 기준으로 검수할 수 있는가. 셋째, 출시 전후 변경 가능성이 얼마나 큰가. 이 세 가지 답이 없으면 고정가도 안전하지 않고, T&M도 투명하지 않으며, 성과보수는 거의 반드시 해석 차이를 낳습니다.

고정가·마일스톤·T&M·성과보수 비교표
| 방식 | 적합한 상황 | 발주사 장점 | 주요 리스크 | 계약 보완 장치 |
|---|---|---|---|---|
| 고정가 | 범위가 명확한 홈페이지, 랜딩페이지, 단순 관리자, 기존 화면 클론 수준의 개선 | 총액 예측이 쉽고 내부 결재가 편함 | 범위가 바뀌면 추가비 분쟁이 잦고, 개발사가 마진 보호를 위해 최소 구현만 할 수 있음 | 포함·제외 범위, 검수 기준, 변경 단가, 산출물 목록을 명시 |
| 마일스톤 지급 | 기획, 디자인, 1차 기능, QA, 운영 배포처럼 단계를 나눌 수 있는 프로젝트 | 중간 산출물을 보며 위험을 줄일 수 있음 | 날짜 기준 마일스톤은 실질 검수 없이 지급될 수 있음 | 일정이 아니라 기능·배포·문서·테스트 기준으로 지급 게이트 설정 |
| T&M | MVP, SaaS, AI 기능, 레거시 연동, 데이터 이전처럼 불확실성이 높은 프로젝트 | 변경과 실험에 유연하고 실제 투입에 맞춰 정산 가능 | 예산 상한과 리포트가 없으면 비용이 늘어날 수 있음 | 주간 투입내역, 번다운, 예산 상한, 사전 승인 없는 초과작업 금지 |
| 성과보수 | 개발사가 결과에 직접 영향을 줄 수 있는 제한적 지표가 있을 때 | 일부 목표 달성 동기를 줄 수 있음 | 매출·가입자·MAU는 마케팅, 가격, 영업, 시즌성 영향을 받아 귀책 판단이 어려움 | 기본 개발비, 측정 지표, 기간, 데이터 접근권, 지급 상한, 종료 정산 조건 명시 |
해외 애자일 계약 가이드에서도 고정가와 T&M을 단순 양자택일로 보지 않고, 마일스톤 릴리즈와 유지보수 항목을 혼합하거나 수용 기준과 성과 요건을 사전에 합의하는 구조를 다룹니다. 반대로 고정 범위·고정 일정·고정 비용을 너무 이른 시점에 모두 잠그면 실제로 필요한 제품이 바뀌었을 때 계약이 발주사와 개발사 모두를 묶는 문제가 생길 수 있습니다. ([techfarhub.usds.gov](https://techfarhub.usds.gov/solicitation/contract-design/))
1. 고정가: 범위가 명확할 때만 안전합니다
고정가는 ‘총액이 정해져 있으니 안전하다’는 인상을 줍니다. 하지만 고정가는 요구사항이 명확할 때 안전한 방식입니다. 예를 들어 회사 소개 홈페이지 리뉴얼, 캠페인 랜딩페이지, 정해진 입력·조회·다운로드 중심의 내부 관리자, 기존 서비스의 작은 기능 추가처럼 화면 수와 데이터 흐름이 분명한 프로젝트에는 잘 맞습니다.
반대로 초기 SaaS처럼 사용자가 어떤 흐름에서 이탈하는지 아직 모르는 프로젝트, 결제·정산·쿠폰·환불 정책이 바뀔 수 있는 커머스, 외부 API 안정성을 확인해야 하는 예약·매칭 서비스, RAG·챗봇·추천처럼 품질 평가가 필요한 AI 기능은 순수 고정가가 오히려 위험할 수 있습니다. 개발사는 불확실성을 견적에 얹거나, 계약 범위 밖 변경으로 처리하거나, 최소 동작만 맞추려는 유인을 갖게 됩니다.
고정가를 쓰려면 견적서에 다음 표현이 있어야 합니다. ‘포함 범위’, ‘제외 범위’, ‘가정 사항’, ‘검수 기준’, ‘수정 횟수’, ‘브라우저·디바이스 지원 범위’, ‘외부 서비스 연동 책임’, ‘데이터 이전 범위’, ‘운영 배포 포함 여부’. 이 항목이 없다면 총액이 낮아 보여도 실제 비용은 뒤에서 열립니다.
2. 마일스톤 지급: 날짜가 아니라 산출물 기준이어야 합니다
마일스톤 지급은 외주개발에서 가장 현실적인 기본 구조입니다. 다만 ‘계약 후 2주 30%, 4주 30%, 완료 후 40%’처럼 날짜만 적으면 안전하지 않습니다. 기간이 지났다는 이유만으로 돈이 나가면 발주사는 실질 검수권을 잃고, 개발사는 어떤 품질로 중간 결과물을 내야 하는지 모릅니다.
마일스톤은 다음처럼 검수 가능한 산출물에 연결해야 합니다. 예를 들어 ‘결제 연동 완료’라는 말은 너무 넓습니다. 안전한 기준은 ‘테스트 계정으로 카드 승인, 승인 취소, 부분 취소 또는 환불 정책, 결제 실패 메시지, 관리자 결제내역 조회, PG 관리자 콘솔 확인, 운영 키 전환 절차 문서 제공’처럼 나눠야 합니다. ‘관리자 페이지 완료’도 ‘회원 검색, 권한 변경, 주문 상태 변경, 엑셀 다운로드, 감사 로그, 관리자 역할 3종’처럼 기능과 권한으로 써야 합니다.
검수 기간도 필요합니다. 예를 들어 각 마일스톤 산출물 제출 후 발주사가 일정 기간 내 이슈를 등록하고, 치명·주요·경미 결함을 나누며, 경미 결함은 잔금 일부 보류 또는 유지보수 기간 내 수정으로 넘기는 방식을 정할 수 있습니다. 중요한 것은 ‘개발사가 제출했다’와 ‘발주사가 인수했다’를 구분하는 것입니다.

3. T&M: 불확실한 프로젝트에는 유리하지만 통제 장치가 필요합니다
T&M은 투입 시간 또는 일수와 역할별 단가를 기준으로 정산하는 방식입니다. MVP, SaaS, AI 서비스, 업무 자동화, CRM·ERP 연동, 기존 데이터 마이그레이션처럼 범위를 처음부터 완전히 확정하기 어려운 프로젝트에 적합합니다. 한국인공지능·소프트웨어산업협회는 SW사업 대가산정 가이드를 통해 기획·구현·운영 등 수명주기 단계의 대가 산정 기준을 제공하고 있으며, 2026년 산정 템플릿에는 SW개발비뿐 아니라 AI 도입비, 운영비, SLA 산정 양식도 포함되어 있습니다. 이는 민간 스타트업 견적에 그대로 대입할 공식 가격표라기보다, 개발비가 단순 코딩 시간이 아니라 설계·검증·운영 항목과 연결된다는 점을 확인하는 참고 기준으로 볼 수 있습니다. ([swai.or.kr](https://www.swai.or.kr/site/sw/01/10101000000002017062610.jsp))
T&M의 약점은 예산 예측입니다. 그래서 ‘상한 없는 T&M’은 피해야 합니다. 안전한 T&M 계약에는 월별 또는 스프린트별 예산 상한, 주간 투입내역, 역할별 단가, 작업 항목별 소요시간, 다음 주 예상 투입, 남은 예산, 우선순위 승인 절차가 있어야 합니다. 발주사가 승인하지 않은 초과 작업은 청구하지 않는다는 조항도 필요합니다.
초기 제품에는 ‘상한 있는 T&M’이 실무적으로 유용합니다. 예를 들어 첫 2주는 discovery와 기술 검증을 T&M 상한으로 운영하고, 그 결과를 바탕으로 MVP 핵심 기능은 마일스톤 고정가로 잡을 수 있습니다. 이후 고객 피드백 기반 개선은 다시 월 단위 T&M 또는 유지보수 계약으로 전환합니다. 이렇게 나누면 발주사는 예산 폭주를 막고, 개발사는 불확실성을 무리하게 고정가에 넣지 않아도 됩니다.
4. 성과보수: 개발비 절감 카드가 아니라 제한적 인센티브입니다
성과보수는 매력적으로 보입니다. ‘개발비 일부를 낮추고 매출이 나면 나눠주자’는 구조입니다. 하지만 소프트웨어 개발에서 성과의 원인은 복합적입니다. 매출은 제품 품질뿐 아니라 가격, 광고비, 영업력, 시즌성, 고객지원, 브랜드 신뢰, 약관, 결제 실패율, 시장 상황 영향을 받습니다. 개발사가 이 모든 것을 통제하지 못하는데 매출을 기준으로 대금을 받게 하면, 나중에 성과 귀속과 데이터 검증에서 분쟁이 생깁니다.
성과보수를 넣고 싶다면 기본 개발비를 없애지 말고 일부 인센티브로 제한해야 합니다. 조건은 구체적이어야 합니다. 지표는 무엇인지, 측정 기간은 언제부터 언제까지인지, 환불·취소·중복 가입은 어떻게 제외하는지, 광고비와 쿠폰 비용은 매출에서 차감하는지, 개발사가 데이터에 접근할 수 있는지, 지급 상한은 얼마인지, 계약 종료 후 미지급 성과는 어떻게 정산하는지까지 정해야 합니다.
특히 정부지원사업, 연구개발 과제, 내부 전산 시스템처럼 사업비 집행·정산 근거가 중요한 프로젝트에서는 성과보수 구조가 해당 사업의 지침과 맞는지 별도로 확인해야 합니다. 프로그램별 규정이 다르므로 계약 전 담당 기관의 집행 기준, 세금계산서 발행 시점, 산출물 증빙 방식을 먼저 확인하는 편이 안전합니다.
프로젝트 유형별 추천 지불 구조
| 프로젝트 유형 | 추천 구조 | 이유 | 주의점 |
|---|---|---|---|
| 회사 홈페이지·랜딩페이지 | 고정가 + 디자인·퍼블리싱·배포 마일스톤 | 범위와 화면 수가 비교적 명확함 | 콘텐츠 제공 지연, 반응형 범위, SEO 기본 설정 포함 여부 확인 |
| 웹·앱 MVP | 고정가 discovery + 핵심 기능 마일스톤 + 변경 T&M 상한 | 기획은 바뀌지만 핵심 검증 기능은 묶을 수 있음 | MVP 이후 개선을 본계약에 과하게 넣지 않기 |
| SaaS 프로토타입 | 기능 우선순위 기반 마일스톤 + 월 단위 T&M | 요금제, 권한, 온보딩, 관리자 기능이 출시 후 조정됨 | 테넌트 분리, 결제, 관리자 권한, 로그 기준을 초기에 잡기 |
| 예약·결제·매칭 서비스 | 기술 검증 T&M + 결제·정산·알림별 마일스톤 | 외부 API와 정책 변경 리스크가 큼 | 환불, 노쇼, 수수료, 관리자 조정 기능을 별도 범위로 명시 |
| 업무 자동화·CRM·관리자 시스템 | 업무흐름 확정 후 고정가 또는 마일스톤 | 내부 프로세스가 정리되면 검수가 쉬움 | 예외 처리, 엑셀 업로드, 권한, 감사 로그를 빠뜨리기 쉬움 |
| AI 챗봇·RAG·추천 기능 | PoC T&M 상한 + 평가 기준 통과 후 구현 마일스톤 | 정확도와 비용, 응답속도는 실험 후 판단해야 함 | 데이터 품질, 프롬프트 변경, 모델 비용, 로그 보관 기준을 계약에 포함 |
계약 전 발주사가 준비해야 할 8가지
견적을 받기 전 준비가 부족하면 개발사는 안전마진을 크게 넣거나, 반대로 낮은 총액을 제시한 뒤 변경 비용으로 보전하려고 합니다. 다음 자료를 준비하면 견적의 품질이 올라가고 지불 구조도 협상하기 쉬워집니다. 요구사항을 어떻게 정리할지 막막하다면 요구사항 명세서 템플릿과 실전 예시를 먼저 참고해도 좋습니다.
- 서비스 목적: 매출, 내부 효율, 심사 데모, 고객 검증 중 무엇이 우선인지
- 필수 기능: 출시 전 반드시 필요한 기능과 출시 후로 미룰 기능 구분
- 사용자 역할: 일반회원, 사업자, 관리자, 슈퍼관리자 등 권한 구조
- 데이터 흐름: 입력, 저장, 조회, 다운로드, 삭제, 외부 연동
- 관리자 기능: 운영자가 매일 처리해야 하는 업무 목록
- 레퍼런스 서비스: 따라갈 부분과 따라가지 않을 부분을 분리
- 검수 기준: 어떤 계정, 어떤 데이터, 어떤 브라우저에서 성공으로 볼지
- 출시 마감일과 예산 상한: 협상 가능한 범위와 절대 불가능한 제약
변경 요청은 ‘좋은 관계’가 아니라 절차로 관리해야 합니다
외주개발에서 가장 흔한 문장이 ‘기능 하나만 더’입니다. 문제는 작은 기능도 화면, API, DB, 권한, 테스트, 배포, 문서에 영향을 줍니다. 따라서 변경 요청은 메신저 대화가 아니라 변경 요청서로 관리해야 합니다. 최소한 요청 내용, 요청 사유, 기존 범위 포함 여부, 예상 투입, 일정 영향, 추가 비용, 우선순위, 승인자, 적용 마일스톤을 남겨야 합니다.
변경을 모두 막을 필요는 없습니다. MVP에서는 변경이 정상입니다. 다만 변경이 생겼을 때 기존 범위에서 무엇을 빼고 무엇을 넣을지, 아니면 비용과 기간을 늘릴지 선택해야 합니다. 이 원칙이 없으면 발주사는 ‘당연히 포함’이라고 생각하고, 개발사는 ‘추가 비용’이라고 생각합니다. 더 구체적인 변경 관리 방식은 외주개발 스코프 변경 관리 가이드에서 이어서 볼 수 있습니다.

잔금 지급 전 체크리스트: 화면보다 운영 가능 상태를 보세요
잔금은 ‘화면이 보인다’가 아니라 ‘운영 가능한 상태’에 지급해야 합니다. 다음 항목 중 일부라도 빠지면 실제 서비스 오픈 후 발주사가 직접 해결하기 어렵습니다.
- 운영 서버 배포가 완료되었는가, staging과 production이 분리되어 있는가
- 도메인, 클라우드, DB, 스토리지, 이메일, SMS, PG, 지도 API 계정의 소유자가 발주사인가
- 관리자 권한, 운영자 계정, 비밀번호 초기화, 접근 제한이 준비되어 있는가
- 결제 승인, 취소, 환불, 실패, 영수증, 관리자 조회가 검수되었는가
- 주요 데이터 등록·수정·삭제·검색·엑셀 다운로드가 검수되었는가
- 소스코드 저장소, 배포 방법, 환경변수 목록, DB 마이그레이션 문서가 인수되었는가
- 치명·주요·경미 버그 목록과 수정 일정이 합의되었는가
- 출시 후 하자보수와 신규 기능 개발의 경계가 정리되었는가
소스코드 인수와 저작재산권 양도도 구분해야 합니다. 저작권법은 저작재산권의 전부 또는 일부 양도를 인정하고, 프로그램의 경우 전부 양도 시 2차적저작물작성권에 관한 특칙도 둡니다. 하지만 실무에서는 ‘소스 파일을 받았다’와 ‘어떤 권리를 언제, 어떤 범위로 이전받았다’가 다를 수 있으므로 계약서에 소스코드, 산출물, 디자인 원본, 배포 스크립트, 이용허락 또는 양도 범위를 분리해 적는 것이 안전합니다. ([law.go.kr](https://www.law.go.kr/LSW/lsLinkCommonInfo.do?chrClsCd=010202&lsJoLnkSeq=1029423521))
지급 일정 예시: 비율보다 게이트가 중요합니다
아래는 협상용 예시입니다. 모든 프로젝트에 적용되는 표준 비율이 아니라, 어떤 산출물에 돈을 연결할지 보여주는 구조입니다.
| 단계 | 지급 트리거 | 확인할 산출물 | 주의점 |
|---|---|---|---|
| 착수 | 계약 체결, 일정 확정, 접근 권한 제공 | 계약서, 범위표, 커뮤니케이션 채널, 계정 목록 | 착수금은 필요하지만 과도한 선지급은 피함 |
| 기획·설계 | 요구사항, 화면 흐름, 데이터 구조 승인 | IA, 와이어프레임, API 초안, 관리자 범위 | 이 단계 승인 후 변경은 변경 요청으로 처리 |
| 1차 구현 | 핵심 사용자 플로우 staging 시연 | 회원가입, 검색, 예약 또는 주문, 관리자 핵심 기능 | 시연만이 아니라 테스트 계정과 이슈 목록 필요 |
| 2차 구현·연동 | 결제, 알림, 외부 API, 권한 검수 | PG, SMS·메일, 권한, 로그, 예외 처리 | 운영 키 전환과 실패 케이스 검수 포함 |
| 운영 배포·인수 | production 배포, 소스코드와 문서 인수 | 저장소, 배포 문서, 환경변수, 관리자 매뉴얼, QA 결과 | 치명 버그가 남아 있으면 잔금 일부 보류 조건 검토 |
| 출시 후 유지보수 | 별도 월 계약 또는 티켓 단위 승인 | 장애 대응, 버그 수정, 개선 요청, 서버 모니터링 | 하자보수와 신규 개발을 명확히 분리 |
유지보수는 개발 계약의 덤이 아닙니다. 출시 후에는 장애 대응, 서버 비용, 보안 패치, 로그 확인, 사용자 문의, 데이터 정정, 신규 기능 요청이 발생합니다. 운영까지 맡길 예정이라면 개발 계약과 별도로 외주개발 유지보수 SLA 설계 가이드의 기준처럼 응답 시간, 처리 시간, 제외 범위, 월 투입 한도, 긴급 장애 기준을 정리해야 합니다.
계약서에 반드시 들어가야 할 지급 관련 조항
- 대금 구조: 총액, 부가세, 지급 단계, 청구서 발행 시점, 지급 기한
- 선금 조건: 계약 해제 시 정산 방식, 착수 산출물, 환불 가능 여부
- 중도금 조건: 마일스톤별 검수 산출물, 검수 기간, 재검수 절차
- 잔금 조건: 운영 배포, 인수 자료, 치명 버그 해결, 계정 소유권 이전
- 범위 변경: 변경 요청서, 견적 산정 방식, 승인 전 작업 금지
- T&M 정산: 역할별 단가, 투입 리포트, 예산 상한, 초과 승인
- 성과보수: 지표, 측정 기간, 데이터 원천, 지급 상한, 환불·취소 처리
- 권리 귀속: 소스코드, 디자인 원본, 문서, 오픈소스, 제3자 라이선스
- 운영 계정: 클라우드, 도메인, PG, 이메일, SMS, AI API 키의 소유자
- 종료와 인수인계: 중도 종료 시 완성 부분 정산, 자료 반환, 접근권한 회수
AgentMit 관점: 개발비 상담은 견적 총액보다 범위 리뷰부터 시작해야 합니다
AgentMit은 외주개발을 저렴한 코딩 계약으로 보지 않습니다. 실제 프로젝트에서는 기획, UI, 백엔드, 관리자, 자동화, AI 기능, 배포, 유지보수, 운영 문서가 한 흐름으로 연결됩니다. 특히 BizMit처럼 SaaS·관리자·업무 운영을 다루는 프로젝트는 결제 구조를 잘못 잡으면 개발 도중 변경 비용이 커지거나, 출시 후 운영자가 사용할 수 없는 상태로 끝날 수 있습니다.
이미 견적서를 받았다면 총액만 보지 말고 다음을 확인해 보세요. 마일스톤이 기능 검수 기준인지, 변경 요청 단가가 있는지, T&M 상한이 있는지, 잔금 전 소스코드와 운영 계정을 인수받는지, 유지보수 조건이 분리되어 있는지입니다. 아직 견적 전이라면 요구사항과 우선순위를 먼저 정리한 뒤 범위를 나누는 편이 좋습니다.
AgentMit은 MVP, SaaS, 관리자 시스템, 예약·결제·매칭 서비스, AI 자동화 기능 개발에서 범위 리뷰와 현실적인 견적 구조 설계를 함께 검토합니다. 계약 전 지불 구조가 불안하거나, 기존 견적서의 선금·중도금·잔금 조건이 적절한지 판단하기 어렵다면 AgentMit에 범위 리뷰 또는 개발 상담을 요청해 보세요.
FAQ
Q1. 외주개발 선금은 얼마가 적정한가요?
정해진 정답은 없습니다. 선금은 착수 준비와 인력 배정을 가능하게 하는 수준이어야 하지만, 검수 전 과도한 리스크를 발주사가 떠안는 구조는 피해야 합니다. 총액을 한 번에 크게 지급하기보다 기획 승인, 디자인 승인, 1차 기능 검수, 운영 배포, 소스코드 인수처럼 확인 가능한 단계로 나누는 편이 안전합니다.
Q2. MVP 외주개발은 고정가와 T&M 중 무엇이 더 안전한가요?
초기 MVP는 요구사항이 바뀔 가능성이 높기 때문에 순수 고정가보다 고정가 discovery, 핵심 기능 마일스톤, 변경·실험 구간은 상한 있는 T&M으로 나누는 혼합 구조가 안전한 경우가 많습니다. 단, T&M은 주간 리포트, 투입내역, 예산 상한, 우선순위 승인 절차가 없으면 예산이 쉽게 늘어납니다.
Q3. 마일스톤 중도금은 날짜 기준으로 지급해도 되나요?
날짜만으로 지급하는 방식은 권장하기 어렵습니다. 중도금은 특정 날짜가 아니라 검수 가능한 산출물 기준으로 연결해야 합니다. 예를 들어 관리자 상품 등록 기능, 결제 승인·취소·환불 흐름, staging 배포, 테스트 계정, QA 결과표처럼 발주사가 확인할 수 있는 단위가 있어야 합니다.
Q4. 외주개발 잔금 지급 전 반드시 확인할 것은 무엇인가요?
운영 배포 여부, 관리자 권한, 결제·알림·로그·백업, 핵심 QA, 남은 버그 목록, 소스코드 저장소 접근권한, 배포 문서, 환경변수 인수, 클라우드·도메인·API 계정 소유권, 유지보수 조건을 확인해야 합니다. 화면만 보이는 상태와 실제 운영 가능한 상태는 다릅니다.
Q5. 성과보수로 외주개발 비용을 낮춰도 되나요?
성과보수는 기본 개발비를 대체하기보다 보조 인센티브로 쓰는 편이 안전합니다. 매출, 가입자, MAU 같은 지표는 개발사 통제 밖의 마케팅·가격·영업·운영 변수 영향을 크게 받습니다. 적용하려면 측정 지표, 기간, 데이터 접근권, 환불·취소 처리, 지급 상한, 계약 종료 시 정산 기준을 반드시 정해야 합니다.
참고 자료
- 민법 도급 관련 조항과 대법원 용역비 판례는 검수·인도·보수 지급 시점 설명에 참고했습니다. ([law.go.kr](https://www.law.go.kr/LSW/lsInfoP.do?lsiSeq=58433&utm_source=openai))
- 소프트웨어사업 계약 및 관리감독에 관한 지침은 기능·비기능 요구사항과 과업범위 명확화 원칙을 민간 외주계약에 응용하는 데 참고했습니다. ([nhis.or.kr](https://www.nhis.or.kr/lm/lmxsrv/law/lawFullContent.do?SEQ=1540&SEQ_HISTORY=44804&utm_source=openai))
- 한국인공지능·소프트웨어산업협회 SW사업 대가산정 자료는 개발비가 기획·구현·운영 단계와 연결된다는 점을 설명하는 데 참고했습니다. ([swai.or.kr](https://www.swai.or.kr/site/sw/01/10101000000002017062610.jsp))
- TechFAR Hub와 Scaled Agile Framework의 애자일 계약 자료는 고정가, T&M, 마일스톤, 하이브리드 구조 비교에 참고했습니다. ([techfarhub.usds.gov](https://techfarhub.usds.gov/solicitation/contract-design/))
- 저작권법 제45조는 소스코드 인수와 저작재산권 양도 조건을 구분해야 한다는 설명에 참고했습니다. ([law.go.kr](https://www.law.go.kr/LSW/lsLinkCommonInfo.do?chrClsCd=010202&lsJoLnkSeq=1029423521))

