---
type: template
domain: product
role: 사업·제품책임
status: active
last-reviewed: 2026-07-27
---

# 투자·제약·우선순위

> 외주의 투자 결정은 "이 범위를 이 기간·금액에 계약대로 완수할 수 있나"다. 견적에는 리스크 버퍼를 심고, 범위는 포함 목록보다 **제외 목록(Out of Scope)**으로 지키고, 마일스톤은 지불 조건에 연결한다.

## 견적 산정

| 항목 | 값 | 산정 근거 |
|---|---|---|
| 개발 공수 | `{MM · 금액}` | `{WBS 추정 링크}` |
| 회의·보고 | `{공수 · 금액}` | `{주간보고·검수 회의 횟수}` |
| 문서화 (납품 산출물) | `{공수 · 금액}` | `[[외주 개발 산출물]] 목록 기준` |
| 검수 대응·결함 조치 | `{공수 · 금액}` | `{검수 라운드 횟수}` |
| 배포·이관·인수인계·교육 | `{공수 · 금액}` | `{이관 계획}` |
| **리스크 버퍼** | `{15~25% 또는 근거}` | `{미확인 가정 수·발주사 이력·연동 불확실성}` |
| 합계·제안가 | `{금액}` | |

> 개발 시간만 견적하면 30%를 무료로 일하게 된다. 숨은 비용을 명시 항목으로 올려라. 낮은 견적으로 수주하고 CR로 회수하는 전략은 신뢰를 태운다 — 정직한 견적 + 1차/2차 범위 분리가 이긴다 ([[SI 수주와 범위 관리]] §견적).

## 제약 레지스터

| ID | 제약 | 종류 | 협상 가능 여부 | 영향 | 확인 근거 | Owner |
|---|---|---|---|---|---|---|
| `CON-01` | `{예: 계약 납기}` | `납기 / 예산 / 법무 / 보안 / 발주사 내부 절차 / 기술 / 운영` | `고정 / 협상 가능` | `{범위·설계 영향}` | `{계약·RFP·회의록 링크}` | `{이름}` |

## 계약 범위 — 포함과 제외

### 포함 (계약 Must)

| ID | 항목 | RFP 근거 | 납품 산출물 형태 | 검수 기준 연결 |
|---|---|---|---|---|
| `IN-01` | `{기능·업무}` | `{RFP 항목 번호}` | `{화면·API·문서}` | `{ACC ID}` |

### 제외 명시 (Out of Scope) — 분쟁 예방의 본체

| ID | 항목 | 제외 이유 | 발주사 안내 문구 | CR 시 처리 |
|---|---|---|---|---|
| `OUT-01` | `관리자 화면 / 데이터 이관 / 타 시스템 연동 / 앱 심사 대응 / 콘텐츠 입력 / 호스팅 비용 등` | `{RFP 밖 / 예산 밖}` | `{계약서 문구}` | `CR 견적 별도 산정` |

> 포함 목록은 아무리 길어도 "여기 없는 건 뭔가요"를 막지 못한다. 제외 목록이 갈등을 막는다. 수정 라운드 횟수도 여기 명시한다 (예: 디자인 시안 2회, 검수 피드백 2회).

## 우선순위 — 계약 Must와 CR 후보 구분

| ID | 항목 | 구분 | 이유 | 마일스톤 | 재검토 조건 |
|---|---|---|---|---|---|
| `{IN-01}` | `{핵심 업무 관통 기능}` | `계약 Must` | `{검수 기준 직결}` | `{1차}` | `없음` |
| `{IN-05}` | `{항목}` | `계약 Must (후순위)` | `{이유}` | `{2차}` | `{조건}` |
| `{CAND-01}` | `{발주사가 구두로 언급한 항목}` | `CR 후보` | `계약 밖 — 요청 시 CR 견적` | `없음` | `CR 접수 시` |
| `{OUT-01}` | `{명시적 제외}` | `Out of Scope` | `{이유}` | `없음` | `차기 계약` |

- 우선순위의 기준은 사용자 가치 점수가 아니라 **계약 이행 순서**다: 검수 기준에 직결되는 것 → 마일스톤 산출물 → 나머지.
- "구두로 언급됐지만 계약에 없는 것"은 지금 CR 후보로 분류해 둔다 — 검수일에 튀어나오는 것을 막는다.

## 마일스톤 = 지불 조건

| 마일스톤 | 납품 산출물 | 검수 기준 | 목표일 | 지불 비율 | 검수 기간 상한 |
|---|---|---|---|---|---|
| 착수 | `착수보고서·SRS·WBS·RTM` | `{발주사 확인}` | `{날짜}` | `{선금 N%}` | `{N영업일}` |
| 설계 완료 | `화면정의서·기능사양서·ERD·API정의서` | `{설계 검토 승인}` | `{날짜}` | `{중도금 N%}` | `{N영업일}` |
| 개발 완료·검수 | `테스트결과서·검수확인서` | `{ACC 전 항목 PASS}` | `{날짜}` | `{중도금 N%}` | `{N영업일}` |
| 이관·종료 | `매뉴얼·인수인계서·완료보고서` | `{산출물 목록 대조}` | `{날짜}` | `{잔금 N%}` | `{N영업일}` |

> 마일스톤에 지불 조건이 없으면 "종료 시 일괄 정산"으로 밀려 현금 흐름과 협상력을 잃는다. 산출물 목록은 [[외주 개발 산출물]]의 계약 첨부용 체크리스트를 그대로 쓴다.

## 1차 관통 범위 (Walking Skeleton)

> 첫 마일스톤은 입력→처리→출력→배포를 관통하는 가장 얇은 한 경로여야 한다. 발주사가 처음 보는 화면이 검수일이어선 안 된다 — 중간 데모가 기대 어긋남을 가장 싸게 조기 발견한다.

| 입력 | 처리 | 출력 | 배포·확인 환경 | 데모 시점 |
|---|---|---|---|---|
| `{최소 입력}` | `{최소 처리}` | `{발주사에게 보이는 결과}` | `{개발/검증 환경}` | `{중간 데모일}` |

## 일정 압박 시 협상 순서

1. `{CR 후보·Could 항목의 차기 이관}` — 발주사 합의 후
2. `{단계 오픈 분리: 파일럿 → 베타 → 가오픈 → 오픈}` — 범위는 유지, 오픈 시점 분리
3. `{발주사 지연 기록 기반 납기 연장 협의}` — 서면 근거 필수
4. 계약 Must·검수 기준·보안·데이터 정합은 임의로 자르지 않는다 — 자르려면 계약 변경 절차.

## 수주·계약 결정

- 결정: `제안 진행 / 조건부 진행(조건 명시) / 범위 재협상 / 수주 포기`
- 계약 범위·버전: `{IN ID 목록 · 계약서 버전}`
- 조건: `{발주사 제공 사항 · Owner · 기한}`
- 제외·CR 후보: `{OUT/CAND ID}`
- 다음 소비자: `PM·PO·BA / Tech Lead`
- 다음 행동: `{한 문장}`

## 관련 문서

- [[우선순위와 스코프]]
- [[SI 수주와 범위 관리]]
- [[04_중단·피벗·승인 기준]]