5단계로 완성하는 개발 프로젝트 WBS
실전 가이드
"WBS 없이 프로젝트 하는 건 지도 없이 등산하는 것과 같다"
PM이 이런 말을 하면 개발자들은 한숨부터 쉽니다. "또 문서 작업이야?" 이런 반응, 당연합니다. Jira에 이슈 몇 개 만들고 열심히 코딩하면 되는 거 아닌가? 애자일이니 스크럼이니 하는 방법론들이 넘쳐나는데, 굳이 WBS라는 구식 방법을 써야 하나?
그런데 프로젝트가 지연되고, 팀원들이 번아웃되고, 고객이 "도대체 언제 끝나냐"고 묻는 상황이 반복되면 생각이 바뀝니다. 문제는 능력이 아니라 체계입니다.
오늘은 복잡한 이론 없이, 당장 실무에 적용할 수 있는 5단계 WBS 작성법을 공유합니다.
시작하기 전에: 실패하는 WBS vs 성공하는 WBS
WBS가 실패하는 이유는 대부분 비슷합니다. 너무 복잡하면 100개 이상 레벨로 나누어 엑셀 파일만 100MB가 되고 아무도 안 봅니다. 너무 단순하면 "개발", "테스트", "배포" 3줄로 끝나서 쓸모가 없죠. 현실을 무시하면 버퍼 0%로 모든 작업이 최선의 시나리오만 가정하고, 담당자가 불명확하면 모든 작업이 "팀" 담당이라 결국 아무도 안 합니다.
반면 성공하는 WBS는 적정 복잡도로 3-4 레벨로 나누어 한 화면에서 전체 구조를 파악할 수 있고, 각 작업이 하루 이내로 완료 가능하도록 구체적이며, 과거 데이터를 기반으로 버퍼를 포함한 현실적인 추정을 하며, 모든 작업에 실명 담당자가 있어 명확한 책임을 가집니다.
핵심은 균형입니다. 너무 자세하지도, 너무 대충이지도 않은. 팀이 실제로 사용할 수 있는 수준의 WBS를 만드는 것이죠.
Step 1: 프로젝트 스코프 명확히 하기
첫 단추를 잘못 끼우면 모든 게 틀어집니다. 스코프 정의는 WBS의 첫 단추입니다.
프로젝트 킥오프 미팅에서 이 3가지 질문에 답하지 못하면, 실패할 확률이 80%입니다.
첫 번째 질문은 "완료"의 정의는 무엇인가입니다. 많은 프로젝트가 "거의 다 됐는데..."라는 말과 함께 지연됩니다. 왜일까요? '완료'의 기준이 모호하기 때문입니다. 모호한 완료 정의는 "로그인 기능 구현"이라고만 하는 것입니다. 하지만 명확한 완료 정의는 이메일과 패스워드 로그인 API 완성, JWT 토큰 발급 및 검증 구현, 비밀번호 5회 실패 시 계정 잠금, 단위 테스트 커버리지 80% 이상, API 문서 작성 완료, 스테이징 서버 배포 및 QA 통과까지 모두 포함합니다.
두 번째 질문은 반드시 포함되어야 하는 것은 무엇인가입니다. MVP(Minimum Viable Product)와 MLP(Minimum Lovable Product)를 구분해야 합니다. 작년에 한 스타트업이 "SNS 로그인도 당연히 포함이죠?"라고 막판에 물어봤습니다. 결과는 2주 지연이었죠.
세 번째 질문은 명시적으로 제외하는 것은 무엇인가입니다. "아, 그것도 당연히 포함인 줄 알았는데요?"라는 말이 프로젝트 막판에 나오면 재앙입니다.
실전 스코프 문서 템플릿을 사용하면 스코프가 명확해집니다. 프로젝트명, 기간, 예산을 명시하고, 반드시 포함되는 기능과 명시적으로 제외되는 기능을 나열하며, 성공 기준을 기술적 지표와 비즈니스 지표로 구분하여 정의합니다. 이렇게 명확히 정의하면, 나중에 "이것도 해주세요"라는 요청이 들어왔을 때 "스코프 문서를 보시면, 이 기능은 v2.0에 포함되어 있습니다"라고 명확히 답할 수 있습니다.
Step 2: 작업 분해하기 - MECE 원칙
MECE(Mutually Exclusive, Collectively Exhaustive)는 맥킨지에서 만든 원칙입니다. "중복 없이, 누락 없이"라는 뜻이죠.
너무 깊으면 관리가 어렵고, 너무 얕으면 의미가 없습니다. 제 경험상 최적의 구조는 Level 1에서 프로젝트 전체를 정의하고, Level 2에서 주요 단계 5-7개를 나누고, Level 3에서 각 단계의 구성 요소 3-5개를 정의하며, Level 4에서 작업 패키지 8-40시간 단위로 분해하는 것입니다.
간단해 보이는 Todo 앱도 제대로 분해하면 기획 및 설계 40시간, 백엔드 개발 80시간, 프론트엔드 개발, 테스트, 배포로 나뉩니다. 각 작업은 구체적인 산출물을 가져야 합니다. "API 개발"이 아니라 "POST /todos 엔드포인트 구현"처럼 명확히 정의해야 합니다.
모든 Level 4 작업은 시간 규칙으로 4시간 이상 40시간 이하, 담당자 규칙으로 "팀"이 아닌 실제 사람 이름, 산출물 규칙으로 완료를 검증할 수 있는 구체적 결과물, 측정 규칙으로 진행률을 측정할 수 있는 기준, 독립성 규칙으로 다른 작업과 명확히 구분되는지 확인해야 합니다.
Step 3: 의존관계 파악하기
가장 큰 실수 중 하나는 모든 작업을 순차적으로 배열하는 것입니다. 병렬로 진행할 수 있는 작업을 찾아내면 일정을 크게 단축할 수 있습니다.
DB 스키마 설계, API 서버 셋업, 프론트 셋업은 독립적으로 동시에 진행할 수 있습니다. API 개발은 DB 스키마 설계와 API 서버 셋업이 완료되어야 하고, 프론트 개발은 프론트 셋업만 완료되면 API와 병렬로 진행할 수 있습니다. Mock API를 만들어 프론트팀이 먼저 작업할 수 있게 하면 더욱 효율적입니다. 통합 테스트는 API 개발과 프론트 개발이 모두 완료되어야 하고, 배포는 통합 테스트가 완료되어야 합니다.
프로젝트에서 가장 긴 경로(Critical Path)를 찾으면, 어떤 작업이 지연되면 안 되는지 알 수 있습니다. 예를 들어 요구사항 2일, 디자인 3일, 프론트 6일, 테스트 2일, 배포 1일이면 Critical Path는 요구사항에서 디자인, 프론트, 테스트, 배포로 이어지는 경로입니다. 이 경로상의 작업이 지연되면 전체 프로젝트가 지연되므로 프론트와 테스트 작업에 버퍼가 필요합니다.
Step 4: 시간 추정하기 - PERT 기법
하나의 추정값만 사용하면 거의 항상 틀립니다. 대신 3개의 값을 사용하세요. PERT(Program Evaluation and Review Technique)는 NASA에서 개발한 과학적 추정 방법입니다.
PERT 공식은 (최선 + 4×현실 + 최악) 나누기 6입니다. 예를 들어 로그인 API 개발에 최선 4시간, 현실 8시간, 최악 16시간을 추정하면 (4 + 4×8 + 16) 나누기 6 = 8.7시간이 됩니다. 표준편차를 계산하면 불확실성을 측정할 수 있고, 68% 확률 구간과 95% 확률 구간을 구할 수 있습니다.
같은 작업도 경력에 따라 속도가 다릅니다. 시니어는 기준 시간에 1.0을 곱하고, 미드레벨은 1.5를 곱하며, 주니어는 2.5를 곱하고 리뷰 시간을 추가해야 합니다. 이를 반영해야 현실적인 추정이 됩니다.
Step 5: 버퍼 전략과 리스크 관리
"버퍼 30% 추가"라고 단순하게 접근하면 안 됩니다. 작업 특성에 따라 다르게 적용해야 합니다. 기본 작업은 10%, 신기술 사용은 추가 30%, 외부 API 연동은 추가 20%, 복잡도가 높으면 추가 15%, 처음 하는 작업은 추가 25%입니다. 최대 버퍼는 50%로 제한합니다. 그 이상이면 작업을 재정의해야 합니다.
개별 작업마다 버퍼를 넣으면 전체 일정이 비현실적으로 늘어납니다. 대신 전략적으로 배치하세요. 나쁜 방법은 모든 작업에 30% 버퍼를 넣어서 총 33.8시간이 되는 것입니다. 좋은 방법은 각 작업은 버퍼 없이 추정하고, 프로젝트 버퍼 풀로 전체의 20%를 할당하여 Critical Path 작업이 지연될 때만 사용하는 것입니다. 이렇게 하면 총 31시간으로 현실적입니다.
실전 체크리스트
WBS 작성이 끝났다면, 모든 작업이 4-40시간 사이인지, 각 작업에 실명 담당자가 있는지, 의존관계가 명확한지, Critical Path를 식별했는지, 3점 추정을 사용했는지, 적절한 버퍼가 있는지, 리스크 대응 계획이 있는지, 완료 기준이 명확한지, 팀 전체가 리뷰했는지, 도구에 입력했는지 확인하세요.
마무리: WBS는 지도다
WBS 없는 프로젝트는 지도 없이 등산하는 것과 같습니다. 처음엔 시간 낭비처럼 보여도, 한 번 제대로 만들어두면 진행 상황을 한눈에 파악하고, 문제 발생 시 빠르게 대응하며, 팀원 간 명확한 역할을 분담하고, 고객과 투명하게 소통할 수 있습니다.
차이는 단 하나, 체계적인 계획입니다.
_체계적인 WBS 관리 도구가 필요하신가요? Plexo를 확인해보세요._
#WBS #프로젝트관리 #실전가이드 #개발PM #작업분해구조