"이거... 아무도 안 만들었네요?"
출시 3일 전, 결제 시스템 통합 테스트 중에 나온 한 마디였습니다.
1000개가 넘는 작업을 완료했는데,
딱 하나 - 결제 실패 시 롤백 처리 - 가 WBS에 없었던 겁니다.
그 하나 때문에 출시가 2주 연기됐고, 마케팅 비용 20억이 날아갔습니다.
사후 분석 결과는 어이없었습니다.
세 번의 리뷰 미팅을 했는데, 모두가 "당연히 누군가 체크했겠지"라고 생각했던 거죠.
리뷰는 했지만, 리뷰 프로세스는 없었던 겁니다.
처음엔 완벽해 보였던 WBS였는데,
막상 출시를 앞두니 빠진 작업이 발견됩니다.
"왜 이걸 놓쳤을까?" 하며 후회합니다.
NASA 연구에 따르면, 체계적인 WBS 리뷰를 하는 프로젝트의 성공률은 89%인 반면,
그렇지 않은 프로젝트는 34%에 불과합니다.
리뷰는 선택이 아니라 필수입니다.
왜 우리는 중요한 것을 놓칠까?
1. 확증 편향의 함정
우리는 있는 것만 보고, 없는 것은 보지 못합니다.
WBS에 "로그인 기능"이 있으면 안심합니다. 하지만 "비밀번호 재설정", "계정 잠금 해제", "소셜 로그인 연동 해제"는? 이런 주변 기능들이 빠지기 쉽습니다.
2. 전문가의 맹점
"너무 당연해서 굳이 적지 않았어요."
시니어 개발자일수록 이런 실수를 합니다. 본인에게는 당연한 것이 주니어에게는 미지의 영역입니다.
3. 책임 분산의 역설
리뷰어가 많을수록 오히려 더 많이 놓칩니다. "다른 사람이 봤겠지"라는 방관자 효과 때문입니다.
4층 리뷰 시스템: 다각도로 검증하기
Intel의 칩 설계팀은 같은 WBS를 네 번 다른 관점으로 리뷰합니다. 번거로워 보이지만, 이 방식으로 결함률을 0.001%까지 낮췄습니다.
Layer 1: 완전성 리뷰 (Completeness Review)
목적: 빠진 작업이 없는지 확인
리뷰어: 제품 관리자, 비즈니스 분석가
체크리스트:
- 모든 요구사항이 WBS에 매핑되었는가?
- 각 결과물에 대한 작업이 있는가?
- 비기능 요구사항(성능, 보안)이 포함되었는가?
Layer 2: 기술 리뷰 (Technical Review)
목적: 기술적 타당성과 의존성 확인
리뷰어: 기술 리드, 아키텍트
체크리스트:
- 기술적 의존성이 올바른가?
- 필요한 기술 작업이 모두 있는가?
- 리스크 완화 작업이 포함되었는가?
Layer 3: 실행 가능성 리뷰 (Feasibility Review)
목적: 현실적으로 실행 가능한지 확인
리뷰어: 프로젝트 매니저, 팀 리드
체크리스트:
- 일정이 현실적인가?
- 리소스 배분이 적절한가?
- 병목 지점이 있는가?
Layer 4: 교차 검증 (Cross Validation)
목적: 다른 프로젝트와의 충돌 확인
리뷰어: PMO, 다른 프로젝트 PM
체크리스트:
- 공유 리소스 충돌이 있는가?
- 다른 프로젝트 의존성이 있는가?
- 조직 표준을 준수하는가?
리뷰 기법: 빠진 것을 찾는 7가지 방법
1. 역방향 추적 (Backward Tracing)
최종 결과물에서 시작하여 거꾸로 추적합니다:
배포된 시스템
← 배포 작업
← 테스트 완료
← 통합 테스트
← 단위 테스트
← 코드 구현
← 설계
← 요구사항 분석
각 단계에서 "이것을 위해 무엇이 필요한가?"를 묻습니다.
2. 시나리오 워크스루 (Scenario Walkthrough)
실제 사용 시나리오를 따라가며 확인합니다:
"사용자가 로그인 → 상품 검색 → 장바구니 추가 → 결제 → 배송 추적"
각 단계에서 필요한 모든 작업이 WBS에 있는지 확인합니다.
3. 5W1H 체크
모든 작업에 대해 질문합니다:
- What: 무엇을 만드는가?
- Why: 왜 필요한가?
- Who: 누가 하는가?
- When: 언제 해야 하는가?
- Where: 어디에 배포하는가?
- How: 어떻게 구현하는가?
답이 없는 질문이 있다면, 작업이 빠진 것입니다.
4. 인터페이스 분석
모든 연결점을 확인합니다:
Frontend ↔ Backend: API 정의, 인증, 에러 처리
Backend ↔ Database: 스키마, 마이그레이션, 백업
System ↔ External: 외부 API, 웹훅, 콜백
인터페이스마다 최소 3개의 작업(정의, 구현, 테스트)이 필요합니다.
5. 부정 테스트 (Negative Testing)
"만약 이것이 실패한다면?"을 묻습니다:
- 로그인이 실패하면? → 에러 처리 작업 필요
- 결제가 실패하면? → 롤백 작업 필요
- 서버가 다운되면? → 복구 작업 필요
6. 체크리스트 대조
표준 체크리스트와 비교합니다:
## 웹 프로젝트 필수 작업
- [ ] 보안 (인증, 인가, 암호화)
- [ ] 성능 (캐싱, 최적화, CDN)
- [ ] 모니터링 (로깅, 메트릭, 알람)
- [ ] 백업/복구
- [ ] 문서화
- [ ] 배포 자동화
7. 델파이 기법
전문가들이 독립적으로 리뷰 후 결과를 종합합니다:
- 각자 독립적으로 빠진 작업 목록 작성
- 익명으로 취합
- 전체 목록 공유
- 재검토 및 합의
리뷰 도구와 템플릿
WBS 리뷰 체크리스트
## WBS 리뷰 체크리스트 v2.0
### 구조 검증
- [ ] 모든 레벨이 100% 규칙을 만족하는가?
- [ ] 작업 분해 수준이 일관적인가?
- [ ] 작업 ID가 체계적인가?
### 내용 검증
- [ ] 모든 요구사항이 커버되는가?
- [ ] 비기능 요구사항이 포함되었는가?
- [ ] 리스크 대응 작업이 있는가?
### 의존성 검증
- [ ] 순환 의존성이 없는가?
- [ ] 외부 의존성이 명시되었는가?
- [ ] 크리티컬 패스가 식별되었는가?
### 리소스 검증
- [ ] 작업별 담당자가 명확한가?
- [ ] 리소스 충돌이 없는가?
- [ ] 예비 리소스가 계획되었는가?
### 일정 검증
- [ ] 버퍼가 포함되었는가?
- [ ] 마일스톤이 현실적인가?
- [ ] 휴일/휴가가 고려되었는가?
리뷰 기록 템플릿
## WBS 리뷰 기록
**프로젝트**: [프로젝트명]
**리뷰 일자**: 2024-XX-XX
**리뷰어**: [이름들]
### 발견된 이슈
1. [이슈 설명] - 심각도: High/Medium/Low
2. ...
### 추가된 작업
- WBS ID: 설명
### 수정된 작업
- WBS ID: 변경 내용
### 다음 리뷰 일정
- 날짜:
- 참석자:
리뷰 프로세스 자동화
1. 자동 검증 스크립트
def validate_wbs(wbs_data):
errors = []
# 100% 규칙 검증
for parent in wbs_data.get_parents():
if not parent.is_fully_decomposed():
errors.append(f"Incomplete: {parent.id}")
# 순환 의존성 검증
if has_circular_dependency(wbs_data):
errors.append("Circular dependency detected")
# 담당자 누락 검증
for task in wbs_data.get_tasks():
if not task.assignee:
errors.append(f"No assignee: {task.id}")
return errors
2. 리뷰 대시보드
실시간으로 WBS 상태를 모니터링합니다:
- 완성도: 87%
- 리뷰 상태: 3/4 레이어 완료
- 발견된 이슈: 12개
- 해결된 이슈: 8개
핵심 정리
"리뷰할 시간이 없어요"라고 말하는 PM들이 있습니다.
하지만 1시간의 리뷰가 100시간의 재작업을 막습니다.
리뷰는 시간 낭비가 아니라 시간 절약입니다.
완벽한 WBS는 없습니다.
하지만 체계적인 리뷰를 통해 99.9%의 완성도는 달성할 수 있습니다.
그 0.1%의 차이가 프로젝트의 성패를 가릅니다.
오늘부터 4층 리뷰 시스템을 도입해보세요.
처음엔 번거롭겠지만, 곧 그 가치를 실감하게 될 것입니다.
체계적인 WBS 관리와 리뷰가 필요하신가요? Plexo를 확인해보세요.
댓글 없음:
댓글 쓰기