WBS vs 애자일? 그런 대립은 없다
"우리는 애자일 하니까 WBS 필요 없어요."
"WBS는 워터폴 방식 아닌가요?"
이런 오해를 정말 많이 듣습니다.
심지어 어떤 스크럼 마스터는 "WBS는 애자일의 적"이라고까지 말하더군요.
정말 그럴까요?
아닙니다. WBS와 애자일은 대립 관계가 아닙니다. 오히려 최고의 파트너입니다.
잘못된 이분법
많은 사람들이 이렇게 생각합니다. 방법론이 애자일이면 WBS는 필요 없고, 방법론이 워터폴이면 WBS가 필요하다고 생각합니다.
하지만 올바른 접근은 구조는 WBS, 실행은 애자일, 마인드셋은 적응적입니다.
WBS는 방법론이 아니라 도구입니다.
WBS에 대한 3가지 오해
첫 번째 오해는 "WBS는 워터폴 전용이다"입니다. 망치가 특정 건축 양식 전용이 아닌 것처럼, WBS도 어떤 방법론에든 쓸 수 있습니다.
워터폴 WBS는 프로젝트 12개월 고정으로 요구사항 분석 3개월 변경 불가, 설계 2개월 변경 불가, 개발 6개월 변경 불가, 테스트 1개월 변경 불가입니다.
애자일 WBS는 Epic: 사용자 관리 시스템으로 Sprint 1에 로그인 API 수정 가능, 회원가입 UI 우선순위 변경 가능, Sprint 2에 프로필 관리 스프린트 이동 가능, 권한 시스템 재정의 가능, Backlog에 추가 요구사항 언제든 추가입니다.
차이는 유연성이지, WBS 자체가 아닙니다.
두 번째 오해는 "애자일은 계획이 없다"입니다. 애자일 선언문을 다시 읽어보세요. "Responding to change over following a plan"은 "계획 없이 하자"가 아니라 "변화에 대응할 수 있는 계획을 하자"입니다.
계획 없는 개발은 카오스로 랜덤 태스크를 선택하고 무언가를 하며, 언제 끝날지 아무도 모릅니다.
애자일 + WBS는 체계적으로 Epic을 Story로 분해하고, 각 스프린트마다 우선순위를 정하고 실행하며, 회고하고 적응합니다.
세 번째 오해는 "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와 애자일의 시너지
첫 번째는 WBS는 지도, 애자일은 여행 방법입니다. ModernProject 클래스로 WBS로 전체 지도를 만들고, 애자일로 네비게이션 방법을 사용하며, execute_sprint로 WBS에서 이번 스프린트 작업을 선택하고, 애자일 방식으로 실행하며, WBS를 업데이트합니다.
두 번째는 User Story와 WBS의 매핑입니다. Epic(WBS Level 1)은 사용자 관리 시스템, Feature(WBS Level 2)는 인증 시스템, 프로필 관리, 권한 관리, User Story(WBS Level 3)는 '사용자는 이메일로 로그인할 수 있다', '사용자는 프로필 사진을 업로드할 수 있다', '관리자는 사용자 권한을 변경할 수 있다', Task(WBS Level 4)는 로그인 API 개발, JWT 토큰 구현, 프로필 이미지 S3 업로드입니다.
세 번째는 스프린트 계획과 WBS입니다. sprint_planning_with_wbs 함수로 WBS에서 전체 백로그를 확인하고, 우선순위를 정렬(애자일)하며, 스프린트 용량을 계산하고, WBS 작업을 스프린트에 할당합니다.
하이브리드 접근법: 최선의 선택
Scrumfall(최악의 조합)은 워터폴의 경직성 + 애자일의 혼란, 긴 계획 단계 + 잦은 변경, 문서 과다 + 소통 부재입니다.
Structured Agile(최선의 조합)은 WBS의 구조 + 애자일의 유연성, 전체 시야 + 반복적 개선, 적절한 문서 + 활발한 소통입니다.
실전 적용 예시
StructuredAgileProject 클래스로 WBS로 전체 구조를 정의하고, 애자일 스프린트를 실행하며, 데일리 스크럼을 진행하고, 스프린트 리뷰와 회고를 하며, WBS 진행상황을 업데이트하고, 변경사항을 WBS에 반영하지만 전체 구조는 유지합니다.
도구 선택 가이드
WBS + 애자일을 지원하는 도구로 Plexo는 WBS 구조 시각화, 스프린트 관리, 실시간 협업을 제공하고, Jira는 Epic-Story-Task 계층, 스프린트 보드, 번다운 차트를 제공하며, Azure DevOps는 계층적 백로그, 스프린트 계획, WBS 뷰를 제공합니다.
피해야 할 도구는 순수 칸반 도구(구조 부족), 전통적 Gantt 도구(유연성 부족), 단순 Todo 앱(계층 없음)입니다.
팀 설득 전략
"우리는 애자일인데요?"라는 팀에게는 작은 실험 제안("다음 스프린트 하나만 WBS로 구조화해볼까요?"), 이름 바꾸기(WBS 대신 "Epic Breakdown", "Story Mapping" 사용), 시각화 강조("전체 그림을 보면서 스프린트 계획하면 어떨까요?"), 성공 사례 공유(Spotify, Netflix도 구조화된 백로그 사용)를 제안합니다.
측정 가능한 개선 지표로 WBS 적용 전은 스프린트 목표 달성률 60%, 예측 정확도 40%, 팀 만족도 5/10, 이해관계자 신뢰 낮음이었지만, WBS 적용 후는 스프린트 목표 달성률 85%, 예측 정확도 75%, 팀 만족도 8/10, 이해관계자 신뢰 높음으로 개선되었습니다.
마무리: 도구는 도구일 뿐
WBS vs 애자일 논쟁은 망치 vs 톱 논쟁과 같습니다.
둘 다 필요합니다. 상황에 맞게 쓰면 됩니다.
핵심 메시지:
WBS = 구조와 가시성, 애자일 = 유연성과 적응, WBS + 애자일 = 예측 가능한 적응입니다.
"우리는 애자일이니까 계획 없어도 돼"라고 말하는 팀과 "우리는 WBS 있으니까 변경 불가"라고 말하는 팀, 둘 다 틀렸습니다.
현명한 팀은 이렇게 말합니다:
"우리는 WBS로 전체를 보고, 애자일로 실행합니다."
이게 2025년의 프로젝트 관리입니다.
WBS와 애자일을 완벽하게 결합한 프로젝트 관리가 필요하신가요? Plexo를 확인해보세요.