Living WBS: 죽은 문서를 살아있는 도구로

만드는 법

by 전규현 Raymond
005-3-living-wbs.png

"WBS 만들어놨는데 아무도 안 봐요."

많은 PM이 하는 하소연입니다. 프로젝트 시작할 때 며칠을 들여 만든 WBS가 2주도 안 돼서 먼지만 쌓이고 있다는 거죠.

왜 열심히 만든 WBS가 죽어버릴까요?

답은 간단합니다. WBS를 "문서"로 만들었기 때문입니다. 살아있는 "도구"로 만들어야 합니다.

죽은 WBS vs 살아있는 WBS

죽은 WBS의 일생은 Day 1 "완벽한 WBS 완성!", Day 7 "음... 실제랑 좀 다르네", Day 14 "WBS? 그거 어디 있더라?", Day 21 "그냥 감으로 하자", Day 30 "WBS 파일 어디 갔지?"(이미 늦음)입니다. 투자한 시간 16시간, 활용도 0%, ROI -100%입니다.

살아있는 WBS의 하루는 09:00 "오늘 뭐하지?" → WBS 확인, 10:00 Task 시작 → 상태 업데이트, 12:00 진행률 50% → 자동 반영, 15:00 이슈 발생 → 즉시 기록, 17:00 Task 완료 → 다음 작업 확인, 18:00 일일 리포트 → 자동 생성입니다. 투자한 시간 16시간, 일일 사용 10분, ROI 1000%+입니다.

왜 WBS가 죽을까?

첫 번째는 한 번 만들고 끝입니다. 프로젝트는 살아 움직이는데 WBS는 정지해 있습니다. 첫날의 계획이 마지막 날까지 유효할 리 없죠.

두 번째는 업데이트가 귀찮습니다. 기존 방식은 엑셀 파일 찾기 2분, 최신 버전 확인 3분, 수정하기 5분, 저장하고 공유 2분, "제가 수정했습니다" 메일 3분, 총 15분입니다. 하루에 3번 업데이트? 45분 낭비입니다.

세 번째는 현실과 동떨어집니다. WBS는 "API 개발 16시간"이라고 하는데, 현실은 "이미 24시간 썼는데 아직도..."입니다. 이런 괴리가 생기면 아무도 WBS를 믿지 않습니다.

Living WBS의 5가지 원칙

첫 번째는 일일 터치포인트입니다. WBS를 매일 최소 3번은 봐야 합니다. 아침에는 오늘 할 일 확인, 점심에는 진행 상황 업데이트, 저녁에는 완료 표시와 내일 준비를 합니다.

두 번째는 실시간 동기화입니다. 팀원 한 명이 업데이트하면 모두가 즉시 봅니다. 파일 기반은 파일 다운로드, 수정, 업로드, 이메일 공유, 충돌 해결로 30분이 걸리지만, 클라우드 기반은 클릭 한 번으로 모두에게 즉시 반영되어 5초면 됩니다.

세 번째는 진행률 시각화입니다. 숫자보다 그래프가 강력합니다. 전체 진행률 80%, 이번 주 번다운으로 월 12 tasks, 화 10 tasks, 수 8 tasks, 목 6 tasks(현재), 금 ? tasks(예상: 3)를 한눈에 보여주면 모두가 관심을 갖습니다.

네 번째는 블로커 알림입니다. 문제가 생기면 즉시 알려야 합니다. 블로커 발생 시 task, blocker, impact를 명시하고, 자동 액션으로 PM에게 즉시 알림, 관련 팀원 소집, 대안 경로 제시, 일정 재조정 시뮬레이션을 수행합니다.

다섯 번째는 예측 가능성입니다. 과거 데이터로 미래를 예측합니다. 완료된 작업 45개, 남은 작업 15개, 경과 일수 10일이면 일일 속도 4.5 tasks/day, 남은 일수 3.3일, 예상 완료일 3일 후, 신뢰도 85%, 리스크는 팀원 1명 휴가 시 5일로 연장입니다.

실제 적용 사례

사례 1은 스타트업 A팀입니다. Before(죽은 WBS)는 WBS 업데이트 주기 2주에 한 번, 정확도 30%, 프로젝트 지연 항상이었습니다. After(Living WBS)는 WBS 업데이트 실시간, 정확도 90%, 프로젝트 예정보다 3일 조기 완료였습니다. 변화 포인트는 엑셀 → 클라우드 도구 전환, 주간 업데이트 → 일일 스탠드업 연동, PM 혼자 → 팀 전체 참여였습니다.

사례 2는 대기업 B팀입니다. 문제는 50명 규모 프로젝트, WBS가 너무 복잡했습니다. 해결책은 계층별 뷰로 CEO View는 전체 진행률만(1개 숫자), PM View는 주요 마일스톤(10개 항목), Team Lead View는 스프린트 목표(50개), Developer View는 일일 태스크(500개)로 각자 필요한 수준만 보니 모두가 WBS를 활용합니다.

Living WBS 구현 전략

Step 1은 도구 선택입니다. 필수 기능은 실시간 협업, 모바일 지원, 알림 기능, API 연동, 시각화입니다. 추천 도구는 Plexo(WBS 특화, 실시간 동기화), Jira(개발팀 친화적), Monday(시각화 강점)입니다.

Step 2는 습관 만들기입니다. 일일 WBS 체크리스트로 아침(5분)에는 어제 완료 작업 확인, 오늘 작업 선택, 예상 시간 입력을 하고, 점심(2분)에는 오전 작업 진행률 업데이트, 블로커 있으면 표시를 하며, 퇴근 전(3분)에는 오늘 작업 완료 표시, 내일 작업 미리보기, 이슈 있으면 코멘트를 합니다.

Step 3은 팀 문화 만들기입니다. WBS를 문화로 만들기 위해 스탠드업 미팅에서 WBS 화면 공유하며 진행하고, 코드 커밋에 WBS 태스크 번호를 포함하며, 성과 평가에 WBS 완료율을 반영합니다.

자동화로 살아있게 하기

Git 연동으로 커밋 메시지에 WBS 번호를 포함하면 자동으로 WBS가 업데이트됩니다. "[WBS-123] 로그인 API 구현 완료"라고 커밋하면 WBS-123이 진행중에서 완료로 자동 변경됩니다.

CI/CD 연동으로 배포 성공 시 WBS가 자동 업데이트됩니다. 배포 성공 시 WBS 태스크를 완료로 표시하고 팀에 알림을 보냅니다.

캘린더 연동으로 WBS 마감일을 구글 캘린더에 자동 동기화합니다. WBS 태스크의 마감일을 캘린더 이벤트로 생성하고 1일 전 알림을 설정합니다.

Living WBS의 ROI

실제 측정 결과, 시간 절약으로 일일 상태 회의 30분 → 10분, 주간 보고서 작성 2시간 → 자동, 진행 상황 파악 즉시로 개선되었습니다.

품질 향상으로 일정 정확도 50% → 85%, 블로커 해결 시간 2일 → 4시간, 팀 만족도 2배 상승했습니다.

비용 절감으로 프로젝트 지연 감소 80%, 재작업 감소 60%, 커뮤니케이션 비용 50% 감소했습니다.

주의사항

과도한 업데이트를 피하세요. 나쁜 예는 10분마다 업데이트, 모든 세부사항 기록, 1% 단위 진행률입니다. 좋은 예는 의미 있는 진척 시 업데이트, 핵심 정보만 기록, 25% 단위 진행률입니다.

도구에 종속되지 마세요. 도구는 수단일 뿐입니다. 중요한 건 매일 보고 업데이트하는 습관입니다.

마무리: WBS는 정원과 같다

WBS는 정원과 같습니다. 한 번 만들고 방치하면 잡초만 무성해집니다. 매일 물 주고 가꾸면 아름다운 꽃을 피웁니다.

Living WBS의 핵심:

매일 터치하고, 실시간 동기화하며, 시각화하고, 자동화하며, 팀 참여를 유도하세요.

죽은 문서 대신 살아있는 도구를 만드세요.

프로젝트가 살아납니다.

실시간으로 살아 움직이는 WBS 관리가 필요하신가요? Plexo를 확인해보세요.

작가의 이전글모두가 놓치는 숨겨진 작업들