프로젝트가 흔들리는 가장 흔한 이유는 '범위'에 대한 기억이 사람마다 다르기 때문입니다. Scope 정의서는 기능 목록을 넘어 가정·제외·완료 기준까지 고정하는 계약 전 문서입니다. 외주·내부 개발 모두에서 creep을 막는 첫 번째 방어선으로 쓰세요.
Scope 문서 5대 구성
| 구역 | 작성 내용 | 예시 |
|---|---|---|
| 목표 | 측정 가능한 결과 | MAU 1만, 전환율 3% |
| In Scope | 이번에 만드는 것 | 회원가입, 결제, 관리자 |
| Out of Scope | 이번에 안 하는 것 | 네이티브 앱, 다국어 |
| 가정 | 전제 조건 | PG사 계약 완료 |
| 완료 기준 | Acceptance | QA 체크리스트 100% |
협상에서 지켜야 할 3가지 원칙
첫째, Out of Scope를 비우지 마세요. '나중에 추가'가 가장 비싼 변경입니다. 둘째, 완료 기준은 화면이 아니라 검수 가능한 문장으로 씁니다. 셋째, 변경은 CR(Change Request) 프로세스로만 받는다고 Scope 문서 상단에 명시하세요. AI CR 관리 글과 연결하면 재견적 속도도 빨라집니다.
템플릿 적용 순서
- RFP의 In/Out을 복사합니다.
- 기능별로 우선순위(MoSCoW)를 붙입니다.
- 이해관계자 서명 또는 이메일 확인으로 버전(v1.0)을 고정합니다.
- 마일스톤 회의마다 Scope 대비 실제 진행을 대조합니다.
팁: Scope 문서는 10페이지가 아니라 2페이지가 이상적입니다. 길수록 아무도 안 읽고, 짧으면 '그때 말한 거 아닌가요?' 분쟁이 납니다.
실무 적용 사례: B2B SaaS 대시보드
클라이언트가 '간단한 대시보드'라고만 말할 때, Scope 문서에 위젯 5개 목록·데이터 소스·권한 모델을 In Scope로 적고, '모바일 앱·실시간 알림·커스텀 BI'를 Out으로 명시했습니다. 개발 3주차에 '알림도 넣어주세요' 요청이 왔지만, Out of Scope와 CR 단가가 문서에 있어 2일 추가 공수·40만 원으로 합의되었습니다. 범위 문서 없었다면 무상 작업이었을 가능성이 큽니다.
Scope 버전 관리
| 버전 | 변경 | 승인 |
|---|---|---|
| v1.0 | 초기 합의 | 이메일 |
| v1.1 | CR #1 반영 | 서명 |
| v2.0 | Phase 2 | 새 계약 |
버전마다 diff를 마크다운으로 archive하면, 분쟁 시 '언제 합의했는지'가 명확해집니다.
Stakeholder kickoff 미팅에서는 Scope 표의 In/Out 열만 화면 공유하고, 나머지는 사전 읽기 자료로 보냅니다. 회의 시간은 Out of Scope 합의에만 쓰면 30분으로 끝납니다. 합의 후에는 PDF export하여 양측 archive에 저장하고, Slack pin 대신 계약 부속번호로 참조하세요.