"우리는 애자일 하니까 WBS 필요 없어요."
"WBS는 워터폴 방식 아닌가요?"
이런 오해를 정말 많이 듣습니다.
심지어 어떤 스크럼 마스터는 "WBS는 애자일의 적"이라고까지 말하더군요.
정말 그럴까요?
아닙니다. WBS와 애자일은 대립 관계가 아닙니다. 오히려 최고의 파트너입니다.
잘못된 이분법
많은 사람들이 이렇게 생각합니다:
# 잘못된 생각
if methodology == "Agile":
wbs = None # "애자일엔 WBS 필요 없어"
elif methodology == "Waterfall":
wbs = Required # "워터폴만 WBS 씀"
# 올바른 접근
def modern_project_management():
return {
"structure": "WBS", # 뼈대
"execution": "Agile", # 실행
"mindset": "Adaptive" # 마인드셋
}
WBS는 방법론이 아니라 도구입니다.
WBS에 대한 3가지 오해
오해 1: "WBS는 워터폴 전용이다"
망치가 특정 건축 양식 전용이 아닌 것처럼, WBS도 어떤 방법론에든 쓸 수 있습니다.
워터폴 WBS:
프로젝트 (12개월 고정)
├── 1. 요구사항 분석 (3개월) ← 변경 불가
├── 2. 설계 (2개월) ← 변경 불가
├── 3. 개발 (6개월) ← 변경 불가
└── 4. 테스트 (1개월) ← 변경 불가
애자일 WBS:
Epic: 사용자 관리 시스템
├── Sprint 1
│ ├── 로그인 API ← 수정 가능
│ └── 회원가입 UI ← 우선순위 변경 가능
├── Sprint 2
│ ├── 프로필 관리 ← 스프린트 이동 가능
│ └── 권한 시스템 ← 재정의 가능
└── Backlog
└── 추가 요구사항 ← 언제든 추가
차이는 유연성이지, WBS 자체가 아닙니다.
오해 2: "애자일은 계획이 없다"
애자일 선언문을 다시 읽어보세요:
"Responding to change over following a plan"
이건 "계획 없이 하자"가 아니라 "변화에 대응할 수 있는 계획을 하자"입니다.
// 계획 없는 개발 (카오스)
function chaotic_development() {
while (true) {
random_task = pick_random_task();
do_something(random_task);
// 언제 끝날지 아무도 모름
}
}
// 애자일 + WBS (체계적)
function agile_with_wbs() {
const epic = breakdown_into_stories(); // WBS!
for (const sprint of sprints) {
const planned_stories = prioritize(epic);
execute(planned_stories);
retrospect_and_adapt(); // 애자일!
}
}
오해 3: "WBS는 너무 상세하고 경직되어 있다"
WBS의 깊이는 여러분이 정하는 겁니다.
과도한 WBS (피해야 할 것):
로그인 기능
├── 로그인 버튼
│ ├── 버튼 색상 정의
│ │ ├── RGB 값 결정
│ │ │ ├── R값: 255
│ │ │ ├── G값: 0
│ │ │ └── B값: 0
│ │ └── Hex 변환
│ └── 버튼 크기
│ ├── 너비: 100px
│ └── 높이: 40px
(이런 건 미친 짓입니다)
적절한 WBS (권장):
로그인 기능
├── 프론트엔드 (3 story points)
├── 백엔드 API (5 story points)
└── 테스트 (2 story points)
실제 사례: 스타트업 A사의 변화
Before: "순수 애자일" (실은 카오스)
상황:
- "우리는 애자일이니까 문서 없어도 돼"
- "스프린트 때마다 정하면 되지"
- "WBS는 구시대 유물이야"
결과:
- 3개월 프로젝트 → 8개월 지연
- 팀원 절반 퇴사
- 투자자 신뢰 상실
After: WBS + 애자일 결합
변화:
- Epic을 WBS로 구조화
- 스프린트는 WBS의 일부 실행
- 전체 그림 + 유연한 실행
결과:
- 예측 가능성 80% 향상
- 팀 만족도 2배 상승
- 다음 투자 유치 성공
WBS와 애자일의 시너지
1. WBS는 지도, 애자일은 여행 방법
class ModernProject:
def __init__(self):
self.wbs = create_roadmap() # 전체 지도
self.agile = navigation_method() # 네비게이션
def execute_sprint(self):
# WBS에서 이번 스프린트 작업 선택
sprint_backlog = self.wbs.get_next_priority()
# 애자일 방식으로 실행
daily_standup()
iterate_and_deliver()
retrospective()
# WBS 업데이트
self.wbs.update_progress()
2. User Story와 WBS의 매핑
Epic (WBS Level 1):
사용자 관리 시스템
Feature (WBS Level 2):
- 인증 시스템
- 프로필 관리
- 권한 관리
User Story (WBS Level 3):
- "사용자는 이메일로 로그인할 수 있다"
- "사용자는 프로필 사진을 업로드할 수 있다"
- "관리자는 사용자 권한을 변경할 수 있다"
Task (WBS Level 4):
- 로그인 API 개발
- JWT 토큰 구현
- 프로필 이미지 S3 업로드
3. 스프린트 계획과 WBS
function sprint_planning_with_wbs() {
// 1. WBS에서 전체 백로그 확인
const all_work = wbs.get_remaining_work();
// 2. 우선순위 정렬 (애자일)
const prioritized = sort_by_business_value(all_work);
// 3. 스프린트 용량 계산
const team_velocity = calculate_velocity();
// 4. WBS 작업을 스프린트에 할당
const sprint_backlog = prioritized.slice(0, team_velocity);
return {
sprint_goal: define_goal(sprint_backlog),
tasks: sprint_backlog,
success_criteria: define_done(sprint_backlog)
};
}
하이브리드 접근법: 최선의 선택
Scrumfall이 아닌 Structured Agile
❌ Scrumfall (최악의 조합):
- 워터폴의 경직성 + 애자일의 혼란
- 긴 계획 단계 + 잦은 변경
- 문서 과다 + 소통 부재
✅ Structured Agile (최선의 조합):
- WBS의 구조 + 애자일의 유연성
- 전체 시야 + 반복적 개선
- 적절한 문서 + 활발한 소통
실전 적용 예시
class StructuredAgileProject:
def __init__(self, project_scope):
# WBS로 전체 구조 정의
self.wbs = self.create_wbs(project_scope)
self.total_points = self.estimate_total()
def run_sprint(self, sprint_number):
# 애자일 스프린트 실행
sprint_goal = self.define_sprint_goal()
sprint_backlog = self.select_from_wbs()
# 데일리 스크럼
for day in range(10):
self.daily_standup()
self.work_on_tasks()
self.update_burndown()
# 스프린트 리뷰 & 회고
self.sprint_review()
self.retrospective()
# WBS 진행상황 업데이트
self.update_wbs_progress()
def adapt_to_change(self, new_requirement):
# 변경사항을 WBS에 반영
self.wbs.add_node(new_requirement)
self.reprioritize_backlog()
# 하지만 전체 구조는 유지
도구 선택 가이드
WBS + 애자일을 지원하는 도구
Plexo ⭐:
- WBS 구조 시각화
- 스프린트 관리
- 실시간 협업
Jira:
- Epic-Story-Task 계층
- 스프린트 보드
- 번다운 차트
Azure DevOps:
- 계층적 백로그
- 스프린트 계획
- WBS 뷰
피해야 할 도구
- 순수 칸반 도구 (구조 부족)
- 전통적 Gantt 도구 (유연성 부족)
- 단순 Todo 앱 (계층 없음)
팀 설득 전략
"우리는 애자일인데요?"라는 팀에게
작은 실험 제안:
"다음 스프린트 하나만 WBS로 구조화해볼까요?"이름 바꾸기:
WBS 대신 "Epic Breakdown", "Story Mapping" 사용시각화 강조:
"전체 그림을 보면서 스프린트 계획하면 어떨까요?"성공 사례 공유:
Spotify, Netflix도 구조화된 백로그 사용
측정 가능한 개선 지표
metrics_before_wbs = {
"스프린트_목표_달성률": "60%",
"예측_정확도": "40%",
"팀_만족도": "5/10",
"이해관계자_신뢰": "낮음"
}
metrics_after_wbs = {
"스프린트_목표_달성률": "85%",
"예측_정확도": "75%",
"팀_만족도": "8/10",
"이해관계자_신뢰": "높음"
}
마무리: 도구는 도구일 뿐
WBS vs 애자일 논쟁은 망치 vs 톱 논쟁과 같습니다.
둘 다 필요합니다. 상황에 맞게 쓰면 됩니다.
핵심 메시지:
- WBS = 구조와 가시성
- 애자일 = 유연성과 적응
- WBS + 애자일 = 예측 가능한 적응
"우리는 애자일이니까 계획 없어도 돼"라고 말하는 팀과
"우리는 WBS 있으니까 변경 불가"라고 말하는 팀,
둘 다 틀렸습니다.
현명한 팀은 이렇게 말합니다:
"우리는 WBS로 전체를 보고, 애자일로 실행합니다."
이게 2025년의 프로젝트 관리입니다.
WBS와 애자일을 완벽하게 결합한 프로젝트 관리가 필요하신가요? Plexo를 확인해보세요.
