빠뜨린 일은 '계획에 없던 일'이 아니다

착수 3주 차 주간회의. 개발 리드가 조심스럽게 손을 든다. "저… 데이터 마이그레이션은 누가 하기로 했죠?" 회의실이 조용해진다. 계획서 어디에도 그 작업은 없다. 견적에도, 일정에도, 담당자 배정에도 없다. 하지만 그 일을 하지 않으면 오픈은 불가능하다.

PM은 이 순간을 "예상 못 한 변수"라고 부르고 싶어진다. 하지만 냉정하게 말하면 데이터 마이그레이션은 변수가 아니었다. 시스템을 교체하는 프로젝트에서 데이터를 옮기는 일은 처음부터 존재했다. 계획에 없었을 뿐이다. 빠뜨린 일은 '계획에 없던 일'이 아니라, '계획이 놓친 일'이다. 그리고 이 차이가 프로젝트의 성패를 가른다. 전자는 리스크 관리의 영역이지만, 후자는 계획 품질의 영역이기 때문이다.

왜 우리는 일을 빠뜨리는가

WBS(Work Breakdown Structure)를 만들어 본 PM이라면 안다. 트리를 그리는 것 자체는 어렵지 않다. 어려운 것은 "이 트리가 프로젝트의 전부를 담고 있는가"를 확신하는 일이다.

일을 빠뜨리는 패턴은 대개 세 가지다.

첫째, 눈에 보이는 산출물 중심으로만 분해한다. 화면, 기능, 문서처럼 손에 잡히는 것은 잘 쪼갠다. 그러나 마이그레이션, 권한 셋업, 성능 테스트 환경 구축, 이해관계자 교육처럼 '중간에 껴 있는 일'은 트리에 오르지 못한다.

둘째, 분해 수준이 들쭉날쭉하다. 어떤 가지는 4단계까지 파고들었는데 어떤 가지는 "백엔드 개발" 한 덩어리로 남아 있다. 큰 덩어리 안에는 언제나 빠진 일이 숨어 있다.

셋째, 같은 일이 두 가지에 걸쳐 있다. "API 개발"과 "연동 개발"에 같은 작업이 반쯤 걸쳐 있으면, 서로 상대가 하는 줄 알고 아무도 하지 않는다.

60년 전에 이미 나온 답

이 세 가지 패턴에는 이미 검증된 처방이 있다. PMBok(PMI의 프로젝트 관리 지식체계 표준)이 정리한 WBS 원칙이다.

100% Rule. WBS의 각 상위 노드는 하위 노드의 합과 정확히 100% 일치해야 한다. 하위를 다 합쳤는데 상위가 안 되면 빠진 것이고, 넘치면 범위 밖의 일이 들어온 것이다. 이 규칙 하나만 검토 회의의 기준으로 삼아도 '중간에 껴 있는 일'의 상당수가 드러난다. 실천법은 단순하다. 트리의 모든 부모 노드 옆에 "자식의 합 = 나인가?"라고 묻는 체크를 붙여라.

8/80 Rule. 최하위 작업 단위(Work Package)는 8시간보다 작지도, 80시간보다 크지도 않게 쪼갠다. 80시간이 넘는 덩어리는 아직 분해가 끝나지 않은 것이다. "백엔드 개발 6주"는 계획이 아니라 희망이다.

상호배제(Mutually Exclusive). 어떤 작업도 두 노드에 동시에 속하면 안 된다. 겹침이 보이면 경계를 다시 긋는다. "서로 상대가 하는 줄 알았다"는 사고의 백신이 이것이다.

원칙은 명쾌하다. 문제는 이 원칙이 사람의 집중력에 의존한다는 것이다. 노드가 30개일 때는 눈으로 검토할 수 있다. 300개가 되면 불가능하다. 우리가 PM 도구를 만들며 수십 개의 실제 WBS를 검증해 보니, 노드 100개가 넘는 트리에서 100% Rule 위반이 하나도 없는 경우는 드물었다. 사람의 문제가 아니라 방법의 문제다. 규칙 검증은 본래 사람이 아니라 시스템이 해야 할 일이다.

100% Rule을 눈으로 확인하기 — 전후 비교

말로만 하면 추상적이니, 가장 사고가 잦은 노드인 "Go-live(서비스 오픈) 준비"로 전후를 비교해 보자.

검토 전:

Go-live 준비 = 운영 배포 + 오픈 공지

100% Rule 질문("자식의 합이 나인가?")을 던진 후:

Go-live 준비 = 운영 환경 구성 + 데이터 마이그레이션·정합성 검증 + 계정·권한 셋업 + 배포 리허설(컷오버 시나리오) + 롤백 계획 수립 + 운영 이관 교육 + 운영 배포 + 오픈 공지

여섯 개의 작업이 새로 드러났다. 전부 "3주 차 회의에서 손 들게 만드는" 유형의 일이다.

큰 덩어리 쪼개기 — 8/80 적용 예시

"백엔드 개발 6주(240시간)"를 Work Package로 분해하면 이렇게 된다.

분해의 부산물에 주목하라. 쪼개는 순간 산출물과 완료 기준을 묻게 된다. 그 질문에 답할 수 없는 덩어리가 바로 빠진 일이 숨어 있는 곳이다.

30분 WBS 완전성 리뷰

지금 진행 중인 프로젝트의 WBS를 열고 다음을 점검하라.

구조 점검 (10분)

• 80시간이 넘는 최하위 노드가 있는가 → 분해 미완
• 부모와 자식의 합이 어긋나는 노드가 있는가 → 100% Rule 위반
• 같은 작업이 두 가지에 걸쳐 있는가 → 상호배제 위반

숨은 작업 체크리스트 (10분) — 시스템 프로젝트에서 가장 자주 빠지는 8가지

• 데이터 마이그레이션·정합성 검증
• 계정·권한·SSO 셋업
• 테스트 환경 구축·테스트 데이터 준비
• 보안 검토·취약점 점검
• 이해관계자 교육·매뉴얼
• 운영 이관·모니터링 셋업
• 내부·고객사 승인/결재 절차
• 전환(cut-over) 리허설·롤백 계획

책임 경계 점검 (10분) — 각 Work Package에 세 가지를 물어라

1. 이 작업의 산출물은 무엇인가? (답이 없으면 작업이 아니라 활동이다)
2. 완료를 누가 승인하는가? (승인자가 없으면 영원히 '진행 중'이 된다)
3. 두 팀이 걸친 작업의 최종 책임자는 누구인가? (한 명이 아니면 아무도 아니다)

PM의 실행 블록

내일 바로 할 일 3가지

1. 위 30분 리뷰를 캘린더에 지금 등록한다 (팀 말고 혼자, 먼저)
2. 80시간 초과 노드 상위 3개를 골라 담당자와 함께 분해한다
3. 숨은 작업 체크리스트에서 걸린 항목을 WBS에 추가하고 공수를 배정한다

회의에서 던질 질문

• "이 부모 노드, 자식을 다 합치면 정확히 100%가 됩니까?"
• "이 240시간짜리 작업의 첫 번째 산출물은 언제, 무엇입니까?"
• "마이그레이션·권한·교육은 어느 노드에 있습니까?"

좋은 신호 / 나쁜 신호

도구는 무엇을 해결해야 하는가

이 리뷰의 병목은 판단이 아니라 대조 작업이다. 노드 300개의 합산·중복·크기 검증은 사람이 아니라 시스템의 일이다. 우리가 wbsgantt에 100% Rule·8/80 위반을 저장 시점에 자동 검출하는 엔진을 가장 먼저 넣은 이유다. 규칙 검증이 공짜가 되면, PM의 30분은 전부 판단에 쓰인다.

빠뜨린 일은 반드시 돌아온다. 계획에 없던 얼굴을 하고, 예산에 없던 청구서를 들고.