프로젝트 스코프 검증: 왜 300억 프로젝트가 600억이 되는가?

"이 기능 하나만 더 추가하면 완벽할 것 같은데요"

프로젝트 3개월차 회의에서 흔히 듣는 말입니다.

처음엔 버튼 하나, 리포트 하나였습니다.
"간단한 추가"라고 생각했죠.
그런데 6개월 후, 프로젝트 예산은 두 배로 늘어나고 일정은 1년 더 연장됩니다.

처음엔 작은 추가로 보였는데,
막상 진행하니 예상치 못한 작업들이 줄줄이 나타납니다.
"이것도 해야 하고, 저것도 해야 하고" 하며 스코프가 계속 늘어납니다.

한 PM이 사표를 던지며 남긴 말이 인상적입니다:
"우리는 자전거를 만들다가 우주선을 만들게 됐다."

PMI의 2024년 보고서가 충격적입니다.
프로젝트 실패의 52%가 스코프 크리프(Scope Creep) 때문이었고,
이런 스코프 변경의 73%가 "사소한 추가"로 시작됐습니다.
개구리를 서서히 끓는 물에 넣는 것처럼, 프로젝트는 조금씩 거대해져 갑니다.

스코프 크리프는 왜 일어날까?

"고객이 원하는데 어떻게 거절해요?"

이것이 가장 큰 이유입니다. 하지만 더 깊은 원인들이 있습니다:

1. 초기 스코프의 모호함

"사용자 친화적인 UI를 만들어주세요."

이 요구사항의 범위는 어디까지일까요? 다크모드? 반응형 디자인? 애니메이션? 모호한 요구사항은 무한 확장의 씨앗입니다.

2. 변경의 연쇄 효과 무시

"로그인에 소셜 로그인 하나만 추가해주세요."

간단해 보이지만, 이메일 중복 처리, 프로필 병합, 권한 매핑, 세션 관리 등 연쇄적으로 수정이 필요합니다. 하나의 변경이 열 개의 변경을 낳습니다.

3. "나중은 없다"는 두려움

"지금 안 넣으면 다시는 기회가 없을 것 같아요."

이런 심리가 모든 것을 초기에 넣으려는 욕심으로 이어집니다. MVP(Minimum Viable Product)가 MMP(Maximum Massive Product)가 되는 순간입니다.

스코프 베이스라인 설정하기

1단계: 명확한 경계 그리기

스코프는 "무엇을 할 것인가"보다 "무엇을 하지 않을 것인가"를 명확히 하는 것이 더 중요합니다.

## 프로젝트 스코프 정의

### 포함 (In Scope)

✅ 웹 기반 대시보드
✅ 기본 보고서 5종
✅ 데이터 엑스포트 (CSV, Excel)
✅ 한국어 버전

### 제외 (Out of Scope)

❌ 모바일 앱
❌ 커스텀 보고서 빌더
❌ API 공개
❌ 다국어 지원 (영어, 중국어 등)

### 추후 고려 (Future Consideration)

🔄 실시간 알림
🔄 AI 기반 추천
🔄 타사 시스템 연동

2단계: 변경 영향도 분석 매트릭스

모든 변경 요청에 대해 영향도를 정량화합니다:

영향 범위	가중치	평가 기준
일정	30%	지연 일수
비용	25%	추가 비용
품질	20%	테스트 범위
리스크	15%	신규 리스크 수
리소스	10%	필요 인력

영향도 점수 = Σ(영향 범위 × 가중치)

70점 이상이면 "메이저 변경"으로 분류하여 경영진 승인이 필요합니다.

3단계: 변경 요청 프로세스

스코프 검증 체크포인트

주간 스코프 리뷰

매주 금요일, 15분간 스코프 상태를 점검합니다:

1. 추가된 것: 이번 주 추가된 요구사항
2. 변경된 것: 기존 요구사항의 변경
3. 제거된 것: 스코프에서 제외된 항목
4. 위험 신호: 스코프 크리프 징조

스코프 크리프 조기 경고 신호

다음 신호가 보이면 즉시 대응해야 합니다:

• "그냥 간단한 추가인데..." (간단한 추가는 없습니다)
• "어차피 만드는 김에..." (김에 만드는 것이 제일 위험합니다)
• "경쟁사는 이 기능이 있던데..." (경쟁사 따라하기의 함정)
• "나중에 필요할 것 같은데..." (YAGNI - You Aren't Gonna Need It)

실전 스코프 관리 기법

1. MoSCoW 우선순위

모든 요구사항을 네 가지로 분류합니다:

• Must have (필수): 없으면 프로젝트 실패
• Should have (권장): 있으면 좋지만 차선책 존재
• Could have (선택): 여유가 있으면 포함
• Won't have (제외): 이번엔 안 함 (다음 버전)

2. 타임박스 기법

"추가 기능에 최대 2주만 할당합니다. 2주 안에 못 끝내면 다음 버전으로 미룹니다."

무한정 늘어나는 것을 방지하는 가장 효과적인 방법입니다.

3. 스코프 뱅크 운영

class ScopeBank:
    def __init__(self, total_budget_hours=1000):
        self.total_budget = total_budget_hours
        self.allocated = 800  # 80% 할당
        self.reserve = 200     # 20% 예비

    def request_change(self, hours_needed):
        if hours_needed <= self.reserve:
            self.reserve -= hours_needed
            return "승인: 예비 시간 사용"
        else:
            removed_hours = self.remove_lower_priority()
            if removed_hours >= hours_needed:
                return "승인: 낮은 우선순위 제거"
            return "거절: 예산 초과"

스코프 문서화의 중요성

스코프 명세서 템플릿

# 프로젝트 스코프 명세서 v1.0

## 1. 프로젝트 목표

[명확하고 측정 가능한 목표]

## 2. 주요 결과물 (Deliverables)

- [ ] 결과물 1: [설명] (완료 기준)
- [ ] 결과물 2: [설명] (완료 기준)

## 3. 제약 사항

- 예산: ₩XXX
- 일정: YYYY-MM-DD까지
- 리소스: 개발자 X명

## 4. 제외 사항 (명시적)

- 하지 않을 것 1
- 하지 않을 것 2

## 5. 가정 사항

- 가정 1
- 가정 2

## 6. 승인

- 고객: **\_** (서명/날짜)
- PM: **\_** (서명/날짜)

스코프 크리프와 싸우는 법

1. "No"라고 말하는 기술

"안 됩니다"가 아니라 "다음 버전에서 고려하겠습니다"라고 말하세요. 거절이 아닌 우선순위 조정입니다.

2. 트레이드오프 제시

"이 기능을 추가하려면, 저 기능을 포기해야 합니다. 어느 것을 선택하시겠습니까?"

선택의 책임을 요청자에게 돌립니다.

3. 비용 가시화

"이 '작은' 변경에 2000만원과 3주가 필요합니다."

'작은' 변경의 실제 비용을 보여주면 대부분 철회합니다.

핵심 정리

스코프 관리는 단순히 기능 목록을 관리하는 것이 아닙니다.

고객과의 약속이고, 팀과의 약속이며, 자신과의 약속입니다.
이 약속을 지키는 것이 프로젝트 성공의 첫걸음입니다.

"더 많이"가 아니라 "더 중요한 것"에 집중하세요.
100개의 평범한 기능보다 10개의 핵심 기능이 훨씬 가치 있습니다.

기억하세요.
스코프 크리프는 선의에서 시작되지만 재앙으로 끝납니다.
작은 변경도 경계하고, 모든 변경을 문서화하며, 원칙을 지키세요.

다음 프로젝트부터 스코프 베이스라인을 명확히 설정해보세요.
작은 노력이 큰 차이를 만듭니다.

---

체계적인 프로젝트 스코프 관리가 필요하신가요? Plexo를 확인해보세요.