외주 개발 프로젝트의 분쟁은 80%가 결제 시점에 터져요. 우리가 그동안 다뤘던 계약서 독소조항, 일정 지연 회복, 외주사 교체 가이드가 다 같은 뿌리를 갖고 있어요. "이 시점에 무엇이 끝났으면 얼마를 지불하는가"가 모호하면, 무슨 사고가 터져도 결제 시점에 한꺼번에 폭발해요. 2026년 외주 시장에서 가장 많이 받는 질문이 "마일스톤은 어떻게 끊어야 하나요?"인 이유예요.
이 글은 7년치 외주 분쟁 사례에서 반복적으로 보이는 패턴을 정리한 7단계 마일스톤 결제 구조 설계 가이드예요. 100% 사후 일괄 결제는 외주사 부도를 부르고, 100% 선급은 발주사 손해를 부르죠. 그 중간을 어떻게 설계하는지 구체적인 비율과 트리거 조건까지 들어갈게요.
한국 외주 시장에서 가장 흔한 구조이자 가장 큰 사고 원인이에요. 착수 50%를 받은 외주사가 4~6개월 동안 보고 없이 잠수하다가 마감 직전에 "거의 다 됐다"는 답만 반복하는 패턴이 너무 많아요. 한편 발주사가 50%만 들고 있으면 외주사가 막판에 추가 비용을 요구할 때 협상력이 거의 없어요. 두 단계 구조는 6개월 이상 프로젝트엔 절대 부적합해요.
월별 정액 결제는 SI(System Integration)에서 쓰던 인건비 정산 방식이에요. 스타트업 MVP·앱 개발 같은 결과물 기반 프로젝트에는 안 맞아요. 외주사가 5명을 투입했다고 해도 그 5명이 실제로 우리 프로젝트에 풀타임으로 일하는지 발주사는 확인할 방법이 없어요. 결과물이 안 나와도 매월 결제가 발생하니 발주사 손해가 누적돼요.
"6월 30일에 30% 지급" 같은 조항이 그 자체로 위험해요. 트리거가 날짜만이면 기능이 절반밖에 안 나와도 지급 의무가 발생해요. 트리거는 반드시 완료 기준(Definition of Done)과 묶여야 해요. 예: "6월 30일까지 회원가입·로그인·결제 3개 화면이 스테이징 환경에서 실 사용 가능 상태로 배포 완료된 시점에 30% 지급."
전체 금액의 100%를 출시 시점에 모두 지급하면, 출시 후 발견되는 버그·보안 취약점·문서 누락에 대해 외주사가 대응할 인센티브가 사라져요. 보통 10~15%를 하자 보증금으로 남겨두고 출시 후 1~3개월 후 지급하는 게 표준이에요.
프로젝트 진행 중 추가 요청은 100% 발생해요. CR 1건당 단가, 최대 누적 금액, 일정 영향까지 정의되지 않으면 결제 시점에 양쪽이 다른 숫자를 들고 충돌해요. CR은 마일스톤과 별도로 주 단위 누적 → 월 단위 정산 구조가 깔끔해요.
3~6개월 짜리 스타트업 MVP·앱 개발에 가장 잘 맞는 7단계 구조예요. 비율은 가이드라인이고 프로젝트 성격에 따라 ±5%p 조정해요.
계약 체결 + 킥오프 미팅 완료 시점. 외주사의 초기 셋업 비용(인력 배정, 환경 구축)을 커버해요. 30% 이상은 발주사 위험이 너무 커요. 우리가 4월 24일에 다룬 킥오프 미팅 가이드의 10가지 합의 항목이 다 끝났을 때만 지급해야 해요.
화면 설계서·디자인 시스템·DB 스키마·API 명세가 모두 발주사 승인을 받은 시점. 이 시점에 변경 요청을 하면 CR이 발생한다는 약속을 양쪽이 명문화. 트리거: "발주사 서면 승인이 완료된 PRD·Figma·ERD 3종 산출물."
가장 중요한 단계예요. 핵심 기능 3~5개가 스테이징 환경에서 실제로 작동하는 시점. 회원가입·로그인·결제·핵심 비즈니스 로직(예: 매칭, 주문, 검색) 등 "이게 안 되면 출시 못한다"는 기능들이에요. 트리거는 반드시 스테이징 URL에서 발주사가 직접 사용해보고 확인. 데모 영상 보여주고 끝내면 안 돼요.
전 기능 통합 + QA 1차 통과 시점. 우리가 4월 13일에 다룬 QA 7가지 테스트가 다 통과돼야 해요. Core Web Vitals·크로스 브라우저·결제·보안·접근성 점검까지 포함. 외주사 자체 QA 리포트가 PDF로 제출돼야 트리거 충족.
프로덕션 배포 + 발주사 승인. 트리거: "프로덕션 환경에서 실 사용자 트래픽 처리 + 24시간 모니터링 정상." 우리가 4월 27일에 다룬 12가지 인수인계 자산도 동시에 전달돼야 이 결제가 나가요.
출시 후 30일간 P0·P1 버그 대응 완료. 사용자 100명 이상이 실제로 쓴 후 나오는 버그가 진짜 버그예요. 이 30일 동안 외주사가 적극 대응해야 한다는 강한 인센티브가 이 5%에서 나와요.
출시 후 90일간 잔여 이슈 처리 완료. 보안 점검·라이선스 이슈·인수인계 후속 질문까지 포함. 이 단계가 있어야 외주사가 "출시했으니 끝"이라고 잠수하지 않아요.
CR은 마일스톤과 완전히 별도 트랙으로 운영하는 게 안전해요. 권장 구조:
마일스톤 결제 구조는 단순한 돈 흐름이 아니라 프로젝트의 척추예요. 7단계로 끊고, 각 단계에 명확한 Definition of Done을 묶고, CR을 별도 트랙으로 분리하고, 하자 보증금 10%를 남기는 것 — 이 4가지만 지켜도 분쟁 발생 확률이 70% 이하로 떨어져요. 90% 짜리 프로젝트가 망하는 게 아니에요. 그냥 결제 구조가 망한 거예요.
포텐랩은 7년간 외주 프로젝트를 운영하면서 97% 수행완수율을 유지하고 있어요. 그 핵심에는 위 7단계 마일스톤 구조와 Notion 기반 투명한 진행 보고가 있어요. 모든 산출물은 발주사 GitHub Org에 직접 푸시되고 소스코드 소유권은 100% 발주사에게 귀속돼요. 외주 프로젝트의 결제 구조 설계부터 분쟁 없는 클로징까지 한 번에 가져가고 싶다면 포텐랩 상담으로 시작해보세요.
핵심 요약 — 마일스톤은 7단계(15·15·25·20·15·5·5%)로 끊고, 트리거는 날짜+Definition of Done 동시 충족, CR은 별도 트랙(MD 단가·주간 누적·월말 정산·30~50% 상한), 하자 보증금 10%(30일 5%+90일 5%) 별도 보관, 1억 이상은 에스크로 검토. 분쟁 70% 감소.