2026년 IT 외주 개발 일정·마일스톤 관리 완전 가이드

왜 외주 개발 일정·마일스톤 관리에서 분쟁이 가장 자주 터지나요?

외주 인계에서 반복적으로 관찰되는 분쟁의 출발점은 "일정"이에요. 산출물이 부족했다거나, 품질이 나빴다거나가 1순위가 아니에요. "왜 이번 주에 끝났어야 할 게 다음 달로 밀리고, 추가 비용은 누가 내냐"가 잔금·분쟁의 첫 트리거예요.

2026년에는 이 패턴이 더 자주 터집니다. AI 코딩으로 초기 속도가 빨라진 만큼, 발주사 기대치가 30~50% 압축됐어요. 5월 초 발표된 James Shore의 "AI 코딩 19개월 만에 productivity 0" 수학 모델이 보여준 게 정확히 이거예요. 초반 속도와 후반 유지보수 부담의 격차. 일정 계약을 어떻게 짜느냐에 따라 이 격차를 누가 메우는지가 결정됩니다.

2026년 외주 개발 일정·마일스톤 계약에 반드시 넣을 8가지 항목은 무엇인가요?

항목 1: WBS와 마일스톤은 '기능 단위'가 아니라 '검증 가능한 결과 단위'로

"로그인 구현 완료" 같은 마일스톤은 분쟁의 출발점이에요. 발주사·외주사 정의가 다르거든요. 결과 단위로 바꾸세요.

로그인 → "이메일+소셜(카카오·네이버·구글) 4종, 비밀번호 재설정 24h 만료, 비밀번호 정책 KISA 권고안 통과, Playwright e2e 12 케이스 PASS, p95 응답 800ms 이하"
결제 → "토스+KCP 2종 PG, 카드·간편결제 4종, webhook 재시도 5회 (지수 백오프), 환불 5분 SLA, 결제 성공률 99% 이상 (1주일 평균)"

마일스톤 1건당 검증 기준 5~7개. 외주사도 받아들이기 쉬워요. 책임 경계가 명확해지니까요.

항목 2: 일정에 'AI 코딩 속도 가정'을 명시한다

2026년 외주 견적은 AI 도구 사용을 가정한 단축 일정이 많아요. 이걸 모호하게 두면 후반에 폭탄입니다. 다음 3줄을 박으세요.

AI 도구 사용 비율 가정: 신규 코드의 60~80%를 AI 도구로 생성 (PR 라벨 'ai-generated')
인계 후 유지보수 부담 분담: AI 생성 코드의 30일 이내 critical 버그는 외주사 무상 (5월 12일 god file 사고 방지)
속도 가정 미달 시 책임: AI 도구 한도·정책 변경으로 인한 지연 시, 7일 이내 발주사 협의 의무

5월 22일 마이크로소프트의 Claude Code 라이선스 회수 사건이 보여준 게 정확히 이거예요. 일정 가정이 한 벤더 정책에 묶여 있으면 다음 분기에 한 번은 터집니다.

항목 3: 'Critical Path'와 'Buffer'를 명문화한다

일정의 60~70%는 기능별 병렬이지만, 항상 1~2개의 critical path가 있어요. 외부 API 인증(애플 디벨로퍼·KISA 본인확인 등) 같은 것들이요. 이건 우리가 통제 못 하는 일정이니까, 다음을 명시하세요.

Critical path 항목 리스트 (5~8개) + 각 항목 평균 대기 시간 (애플 심사 24~48h, KISA 본인확인 등록 2~3주)
Buffer는 전체 일정의 15~20% (외주사 표준), critical path 항목 1건당 +50% 가산
Buffer 소진 시 즉시 발주사 보고 의무 (이메일 또는 Notion 자동 알림)

이 3줄이 있으면 "예상 못했어요" 같은 답변이 안 나옵니다. 5월 22일 앱스토어 심사 가이드에서 같은 결론이 나왔어요. 심사 1~2주 버퍼가 일정에 반영되어 있어야 한다고요.

항목 4: 마일스톤 사인오프와 잔금 지급을 묶는다

마일스톤 1건이 끝났는데 잔금이 안 묶여 있으면 외주사도 발주사도 동기가 떨어져요. 다음 표준을 권장합니다.

전체 계약 금액을 4~6개 마일스톤으로 분할 (각 15~25%)
마일스톤별 잔금 지급 조건: 검증 기준 5~7개 PASS + Notion 사인오프 + 1주일 monitoring 무사고
최종 잔금 10%는 30일 hot-patch 기간 후 지급 (5월 3일 사인오프 가이드 참조)

이 구조에서는 양쪽 모두 "끝났다"의 정의에 동의해야만 잔금이 움직여요. 분쟁 비율이 절반으로 떨어집니다.

항목 5: 변경 요청(CR)이 일정·마일스톤에 미치는 영향을 사전 합의한다

4월 30일 다룬 CR 가이드의 연장선이에요. CR이 들어왔을 때 일정에 자동으로 들어가는 규칙을 미리 박아두세요.

CR 1건당 임팩트 평가 24h SLA (외주사 PM)
5MD 이하 CR은 다음 마일스톤에 흡수, 5MD 초과는 별도 마일스톤 신설 + 일정 +X일 합의
긴급 CR (영업일 외 48h 이내)은 1.3~1.5배 가산 명문화

이게 없으면 CR 한 건이 들어올 때마다 분쟁이 한 번씩 생깁니다. 포텐랩 기준 평균 0.3건/프로젝트의 CR 분쟁이 이 3줄 덕분이에요.

항목 6: 주간 진행 보고와 리스크 보고를 분리한다

대부분의 외주 주간 보고는 "이번 주 한 일·다음 주 할 일·이슈" 3섹션이에요. 마지막 섹션이 비어 있으면 안심이지만, 실제로는 그게 가장 위험합니다. 다음 5섹션을 표준화하세요.

이번 주 완료 항목 (마일스톤 기준)
다음 주 계획 항목 (마일스톤 기준)
현재 critical path 진행률 (각 항목별 %)
리스크 3종: 일정 / 비용 / 품질 (각각 1줄, 레벨 H/M/L)
발주사 의사결정 대기 항목 (보고일 +5영업일 SLA)

특히 5번 항목이 중요해요. 외주 지연의 30~40%가 발주사 의사결정 대기에서 발생합니다.

항목 7: 일정 지연 시 책임 분담 룰을 명문화한다

"지연되면 누가 책임지냐"를 분쟁 직전에 협상하는 건 너무 늦어요. 계약서에 다음 3줄을 박으세요.

외주사 귀책 지연: 1주일 초과 시 1주일당 계약 금액의 0.5% 페널티 (상한 5%)
발주사 귀책 지연: 의사결정 SLA 5영업일 초과 시 자동 일정 연장 (페널티 없음, 단 잔금 지급도 같이 연장)
불가항력 (애플/구글 심사·법령 개정·외부 API 장애): 양쪽 무책임, 14일 단위 재협상

이 룰이 있으면 일정 지연이 분쟁으로 번지지 않아요. 양쪽 모두 "이렇게 합의했으니까"로 마무리됩니다.

항목 8: 마일스톤 사이의 '청소 스프린트'를 1회 이상 포함한다

5월 12일 다룬 god file 사고가 보여준 게 정확히 이거예요. AI 코딩으로 빠르게 쌓이면 누적 부채가 다음 마일스톤을 잡아먹어요. 외주 일정에 다음을 박으세요.

전체 일정 중 1회 이상 '청소 스프린트' (1~2주, 신규 기능 0, 리팩터링·테스트 보강·문서화만)
청소 스프린트에서 ESLint max-lines 700, 단일 함수 80줄, props 7 이하 CI 가드 도입 확인
인계 직전 마일스톤은 청소 스프린트로 (인계받은 발주사의 6개월 부채를 30%까지 줄임)

이 1주가 있고 없고가 인계 후 1년의 유지보수 비용을 좌우합니다.

오늘 5분 안에 점검할 체크리스트는 무엇인가요?

현재 진행 중인 외주 프로젝트의 마일스톤이 '검증 가능한 결과' 단위로 정의되어 있는가?
AI 도구 사용 비율·인계 후 무상 패치 SLA가 계약에 명시되어 있는가?
Critical path 5~8개와 buffer 15~20%가 일정에 반영되어 있는가?
주간 보고에 발주사 의사결정 대기 항목과 SLA(5영업일)가 들어가 있는가?
일정 지연 시 페널티 룰이 양방향으로 명문화되어 있는가?
청소 스프린트가 1회 이상 포함되어 있는가?
마일스톤별 잔금 지급 조건이 검증 기준 + 1주 모니터링으로 묶여 있는가?
최종 잔금 10%가 30일 hot-patch 기간과 연결되어 있는가?

이 8가지 항목은 포텐랩이 외주 프로젝트에서 검증해온 표준이에요. 평균 일정 지연이 작년 대비 22% 감소했고, 일정 관련 분쟁 비율이 60%에서 11%로 떨어졌습니다. 포텐랩은 모든 클라이언트 프로젝트에서 Notion 기반 마일스톤 보드를 일일 공유하고, critical path와 리스크 보고를 분리해서 운영해요. 외주 일정이 자꾸 밀리거나, 마일스톤 잔금에서 분쟁이 반복되고 있다면 포텐랩에 한 번 상담을 받아보세요. 97% 수행완수율의 핵심은 마법이 아니라 8가지 일정 조항의 표준화입니다.