번다운 차트가 이렇게 생겼다면 정말 잘 진행되고 있는 걸까요?
남은 작업
100 |\
80 | \
60 | \
40 | \
20 | \
0 |_____\
Day 1 2 3 4 5
완벽해 보이죠? 하지만 현실은...
남은 작업
100 |\___
80 | \____
60 | ↗️ (갑자기 증가?!)
40 | \___💥
20 | \____???
0 |_____________________
Day 1 2 3 4 5 6 7 8 9 10...
번다운이 안 되고 있습니다. 오히려 번업(Burn-up)이 되고 있네요.
스코프 크립: 프로젝트의 조용한 살인자
스코프 크립(Scope Creep)은 프로젝트 진행 중 요구사항이 슬금슬금 추가되는 현상입니다.
마치 체중계에 올라가 있는데 누군가 계속 추를 올려놓는 것과 같죠.
실제 대화록
Day 1 (킥오프 미팅)
PM: "로그인, 회원가입, 프로필 페이지만 만들면 됩니다."
개발팀: "2주면 충분합니다!"
Day 3
PM: "아, 소셜 로그인도 추가해주세요. 간단하잖아요?"
개발팀: "음... 네..."
(속마음: 구글, 페이스북, 카카오, 애플... 간단하다고?)
Day 5
CEO: "경쟁사 보니까 다크모드 있던데, 우리도 넣어요."
개발팀: "..."
(속마음: CSS 다 뜯어고쳐야 하는데...)
Day 7
마케팅: "이메일 인증도 필요할 것 같아요!"
개발팀: "하..."
(속마음: 메일 서버, 템플릿, 인증 로직...)
Day 10
PM: "왜 아직 안 끝났죠? 2주라고 했잖아요?"
개발팀: "???"
(속마음: 작업이 2배가 됐는데?)
스코프 크립의 유형별 분석
1. 순진한 크립 (Innocent Creep)
"이것도 간단하니까 추가해주세요~"
# PM의 생각
additional_work = {
"다크모드": "CSS 몇 줄", # 실제: 200개 컴포넌트 수정
"알림 기능": "DB 필드 하나", # 실제: 푸시, 이메일, 인앱, 설정...
"다국어": "텍스트 교체" # 실제: i18n 시스템 구축
}
2. 정치적 크립 (Political Creep)
"CEO가 원하시는데..."
const political_additions = {
source: "C-Level",
negotiable: false,
priority: "URGENT",
impact: "전체 일정 30% 지연",
developer_morale: -50
};
3. 완벽주의 크립 (Perfectionist Creep)
"이왕 하는 김에 제대로..."
원래: 기본 검색
├── "이왕이면 자동완성도"
├── "검색 히스토리도 있으면 좋겠네"
├── "필터링 기능도 추가하죠"
├── "AI 추천도 넣어볼까요?"
└── 결과: Elasticsearch + ML 모델 = 3개월 프로젝트
4. 경쟁사 크립 (Competitor Creep)
"경쟁사가 이런 기능을 출시했대요!"
매일 경쟁사 기능이 추가되면, 우리 제품은 언제 완성될까요?
번다운 차트의 진실
이상적인 번다운
작업량
100 |*
75 | *
50 | *
25 | *
0 |________*
1 2 3 4 5 (스프린트)
실제 번다운 (스코프 크립 포함)
작업량
100 |*
75 | *___
50 | *___* ← 추가 요구사항
25 | *___* ← 또 추가
0 |________________???
1 2 3 4 5 6 7 8... (언제 끝?)
정직한 번다운 (번업 차트 병행)
작업량
150 | ___총 작업량 (계속 증가)
100 |* ____/
50 | *_/ 완료 작업
0 |________________
1 2 3 4 5 6
Gap = 스코프 크립의 실체
스코프 크립 방어 전략
1. 변경 요청서 의무화
## 변경 요청서 템플릿
### 요청 사항
- 무엇을:
- 왜:
### 영향도 분석
- 추가 시간: [ ]시간
- 영향받는 기능:
- 리스크:
### 우선순위
- [ ] 필수 (이번 릴리즈)
- [ ] 중요 (다음 릴리즈)
- [ ] 있으면 좋음 (백로그)
### 승인
- PM: [ ]
- 개발 리드: [ ]
- 이해관계자: [ ]
2. 트레이드오프 원칙
"하나를 추가하려면 하나를 빼세요"
def handle_new_request(new_feature, current_sprint):
"""새 기능 요청 처리"""
if new_feature.is_critical():
# 중요하면 다른 것과 교환
removed = current_sprint.remove_lowest_priority()
current_sprint.add(new_feature)
return f"추가: {new_feature}, 제거: {removed}"
else:
# 중요하지 않으면 백로그로
backlog.add(new_feature)
return "다음 스프린트에 검토"
3. 스코프 버퍼 확보
const sprint_planning = {
committed_work: 70, // 70%만 약속
buffer: 20, // 20% 버퍼
innovation: 10 // 10% 실험
};
// 스코프 크립이 와도 버퍼로 흡수
4. 일일 델타 추적
# 매일 변경사항 추적
daily_delta = {
"Day1": {
"added": [],
"removed": [],
"modified": ["로그인 UI"],
"delta": 0
},
"Day2": {
"added": ["소셜 로그인"], # +8시간
"removed": [],
"modified": [],
"delta": +8
}
}
# 델타가 양수면 경고!
if sum(daily_delta.values()) > 0:
alert("스코프 크립 발생!")
실제 사례: 2주 프로젝트가 3개월이 된 이야기
Week 1-2: 순조로운 시작
- 계획: 기본 CRUD
- 진행: 50% 완료
Week 3: 첫 번째 크립
- 추가: "실시간 알림도 있으면 좋겠네요"
- 영향: WebSocket 서버 구축 필요
Week 4: 두 번째 크립
- 추가: "모바일 앱도 만들어주세요"
- 영향: React Native 추가 개발
Week 6: 세 번째 크립
- 추가: "AI 추천 기능도..."
- 영향: ML 파이프라인 구축
Week 12: 프로젝트 종료(?)
- 원래 계획: 2주
- 실제: 12주
- 비용: 6배
- 팀 사기: 바닥
스코프 크립 체크리스트
프로젝트가 스코프 크립에 빠졌는지 확인:
- 번다운 차트가 평평하거나 올라감
- "간단한 추가"라는 말을 자주 들음
- 원래 요구사항 문서가 어디 갔는지 모름
- 매주 새로운 기능 요청
- 팀원들이 "이게 뭐였죠?"라고 자주 물음
- 완료 기준이 계속 바뀜
3개 이상? 스코프 크립 진행 중!
스코프 크립과 공존하기
완전히 막을 수는 없습니다. 비즈니스는 변하니까요.
건강한 변경 관리
class ChangeManagement:
def __init__(self):
self.change_budget = 20 # 전체의 20%까지 변경 허용
self.used_budget = 0
def request_change(self, change):
if self.used_budget + change.size <= self.change_budget:
self.approve(change)
self.used_budget += change.size
else:
self.defer_to_next_sprint(change)
투명한 커뮤니케이션
## 주간 스코프 리포트
### 이번 주 변경사항
- 추가: 다크모드 (8시간)
- 제거: 프로필 편집 (6시간)
- 순 증가: 2시간
### 전체 영향
- 원래 완료일: 3/15
- 새 완료일: 3/17
- 지연: 2일
### 리스크
- 추가 변경 시 3월 내 완료 불가능
번다운 차트 개선안
1. 스코프 라인 추가
작업량
150 | _____ 스코프 라인 (변경 추적)
100 |* /
50 | *_/ 번다운 라인
0 |________________
1 2 3 4 5 6
2. 신뢰 구간 표시
작업량
100 |*
75 | *±10 ← 불확실성 표시
50 | *±15
25 | *±20
0 |________?
3. 번업 차트 병행
완료한 일 vs 전체 일을 동시에 보여주면 스코프 크립이 명확히 보입니다.
마무리: 스코프를 지키는 것도 용기
"아니요"라고 말하는 것은 어렵습니다.
하지만 모든 요청을 받아들이면:
- 프로젝트는 끝나지 않고
- 팀은 지치고
- 제품은 복잡해지고
- 아무도 만족하지 못합니다
좋은 PM의 조건:
- 명확한 스코프 정의
- 변경에 대한 영향 분석
- 트레이드오프 협상
- 투명한 진행 상황 공유
번다운 차트가 거짓말하지 않게 하려면, 우리가 먼저 정직해야 합니다.
"이 기능을 추가하면 2주 늦어집니다. 그래도 하시겠습니까?"
이 질문이 프로젝트를 구합니다.
스코프 관리와 정확한 번다운 추적이 필요하신가요? Plexo를 확인해보세요.
