개발 마일스톤, 실제로 어떻게 나누나 — 규모별 예시

견적서에서 가장 자주 보이는 형태입니다.

문제는 3단계가 8주라는 점입니다. 그동안 발주사가 확인할 수 있는 게 없습니다.

6주째에 "어떻게 되고 있나요" 라고 물으면 "잘 되고 있습니다" 라는 답이 옵니다

진척을 볼 방법이 없으니 믿는 것 말고 할 게 없습니다

8주 뒤에 결과를 보고 나서야 방향이 어긋난 걸 압니다

그때는 되돌리기에 너무 늦었습니다

공정(기획·디자인·개발)으로 나누면 중간 산출물이 "문서" 뿐입니다. 문서로는 실제로 동작하는지 알 수 없습니다.

기능 단위로 나누면 달라집니다.

각 단계 끝에 직접 눌러볼 수 있는 것이 나옵니다. 2단계에서 주문 화면이 생각과 다르면 그때 고칠 수 있습니다.

2개월 · 소규모 (엑셀 자동화, 단순 크롤러)

작은 프로젝트는 3단계면 충분합니다. 더 쪼개면 검수 왕복이 개발보다 오래 걸립니다.

4개월 · 중규모 (관리자 대시보드, 예약 시스템)

6개월 · 대규모 (SaaS, 다중 사용자 서비스)

한 단계는 2~4주가 적당합니다. 1주면 검수 왕복이 부담이고, 5주가 넘으면 다시 "안이 안 보이는" 상태가 됩니다.

비율의 감각: 기획 10~15%, 개발 60~70%, 검수·안정화 10~15%. 검수를 5% 미만으로 잡은 견적은 검수 기간을 안 잡았다고 보면 됩니다.

"1단계 완료" 라는 말의 뜻이 서로 다르면 거기서 분쟁이 시작됩니다. 완료 기준을 계약서에 적어두십시오.

기획 단계에서 받을 것

화면 목록과 화면별 기능 정의

화면 흐름도 (어디서 어디로 넘어가는지)

데이터 구조 (무엇을 저장하는지)

개발 단계마다 받을 것

실제로 접속해서 눌러볼 수 있는 주소 (테스트 서버)

이번 단계에서 되는 것과 아직 안 되는 것 목록

다음 단계에 넘어가는 항목이 있으면 그 이유

가장 중요한 건 첫 줄입니다. 화면 캡처나 시연 영상으로 대체하면 안 됩니다. 직접 눌러봐야 실제로 동작하는지 압니다.

검수 단계에서 받을 것

소스코드와 저장소 접근 권한

데이터베이스 구조와 API 문서

배포 절차 문서

서버·외부 서비스 계정

완료 기준을 이렇게 적습니다:

> "2단계 완료는 테스트 서버에서 주문 등록·수정·취소·목록 조회가 모두 동작하고, 발주사가 5영업일 내 확인 후 이의를 제기하지 않은 시점으로 한다."

날짜가 아니라 동작으로 정의하는 게 핵심입니다.

마일스톤과 대금을 연결할 때 두 가지를 조심해야 합니다.

앞에 몰아주지 않기

착수금 50%는 흔하지만, 발주사 입장에서는 절반을 내고 아무것도 못 받은 상태가 됩니다. 착수 20~30%, 중간 단계마다 분할, 잔금 10~20% 가 서로에게 안전합니다.

다만 개발사도 인건비를 먼저 씁니다. 착수금을 지나치게 깎으면 작은 개발사는 아예 못 받습니다. 20~30%가 현실적인 균형입니다.

검수 기간을 명시하기

"검수 후 지급" 만 적으면 검수가 늘어지면서 대금도 늘어집니다. 개발사 입장에서는 언제 받을지 모르는 상태가 됩니다.

> "각 단계 완료 통보 후 5영업일 내 검수하고, 이의가 없으면 검수 완료로 본다."

이 한 줄이 양쪽을 다 보호합니다.

단계가 밀릴 때

일정이 밀리는 건 흔합니다. 미리 정해두면 다투지 않습니다.

며칠까지는 협의로 조정하는지

그 이상 밀리면 어떻게 하는지 (지연 배상, 범위 조정, 해지)

발주사 사유로 밀린 경우(자료 미제공, 피드백 지연)는 어떻게 보는지

마지막 항목을 자주 빠뜨립니다. 발주사가 피드백을 2주 미루고 납기를 따지면 다툼이 됩니다.