엑셀로 만든 계획은 만든 날부터 죽는다
킥오프 전날 밤, PM은 뿌듯하다. 엑셀로 만든 WBS는 4단계까지 깔끔하게 분해됐고, 그걸 옮겨 그린 간트차트는 색까지 입혀 한 장의 예술 작품이 됐다. 경영진 보고도 무사히 끝났다.
2주 뒤. 개발 일정이 사흘 밀렸고, 작업 두 개가 쪼개졌고, 담당자 하나가 바뀌었다. PM은 엑셀 WBS를 고친다. 간트차트도 고쳐야 하는데 급한 불부터 끄느라 미룬다. 다시 2주 뒤, 팀원이 묻는다. "WBS에는 이 작업이 있는데 간트에는 없어요. 어느 게 맞아요?" PM은 답한다. "어… 제 머릿속에 있는 게 맞아요."
이 장면의 문제는 PM의 성실성이 아니다. 같은 정보를 두 곳에 적는 구조 그 자체다.
문서가 두 개면, 진실도 두 개가 된다
WBS와 간트차트는 별개의 산출물처럼 보이지만, 사실 같은 데이터의 두 가지 표현이다. WBS는 "무엇을 하는가"의 계층 구조이고, 간트는 그 동일한 작업들의 시간 배치다. 그런데 도구가 이 둘을 별도 파일로 관리하게 만들면, 모든 변경을 두 번 반영해야 한다.
두 번 반영하는 일은 반드시 실패한다. 게으름 때문이 아니라 확률 때문이다. 프로젝트 6개월 동안 변경이 200번 일어난다고 하자. 매번 두 문서를 모두, 즉시, 정확히 고칠 확률이 99%라 해도, 200번 뒤 두 문서가 일치할 확률은 13%에 불과하다. 나머지 87%의 세계에서 PM은 회의 때마다 "어느 문서가 맞는지"를 기억으로 보정하는 사람이 된다.
그래서 엑셀 계획은 만든 날부터 죽는다. 정확히 말하면, 첫 변경이 일어나는 순간부터 부패하기 시작한다. 그리고 프로젝트에서 변경이 일어나지 않는 날은 없다.
'문서'가 아니라 '모델'을 관리하라
해법의 방향은 명확하다. WBS와 간트를 두 개의 문서가 아니라 하나의 데이터에 대한 두 개의 뷰(view) 로 만드는 것이다.
소프트웨어 설계에는 오래된 원칙이 있다. Single Source of Truth — 진실의 원천은 하나여야 한다. 회계 시스템이 원장 하나에서 재무제표와 세무 보고서를 모두 뽑아내듯, 프로젝트도 작업 구조라는 원장 하나에서 WBS 뷰와 간트 뷰를 모두 뽑아내야 한다. 트리에서 작업을 쪼개면 간트에 즉시 반영되고, 간트에서 기간을 늘리면 트리의 집계가 즉시 갱신되는 구조. 이 구조에서는 "어느 게 맞아요?"라는 질문 자체가 성립하지 않는다.
우리가 도구를 만들며 이 문제를 파고들었을 때 내린 결론도 같았다. WBS·일정·진척이 같은 그래프 위에 있지 않으면, 어떤 부지런한 PM도 정합성을 이길 수 없다. 이건 노력의 문제가 아니라 구조의 문제이기 때문이다.
무엇이 원본이고, 무엇이 뷰여야 하는가
Single Source of Truth를 선언만 하고 끝내면 안 된다. 필드 단위로 원본과 파생을 나눠야 운영이 된다.
| 데이터 | 성격 | 어디에 존재해야 하는가 |
|---|---|---|
| 작업명·계층 구조 | 원본 | 원장(WBS) 한 곳 |
| 기간·시작/종료일 | 원본 | 원장 한 곳 |
| 선후행 관계(의존성) | 원본 | 원장 한 곳 |
| 담당자 | 원본 | 원장 한 곳 |
| 진척률 | 원본 | 원장 한 곳 |
| 간트차트 | 뷰 | 원장에서 생성 (직접 수정 금지) |
| 주간보고·경영진 요약 | 뷰 | 원장에서 생성 |
| 고객 제출용 엑셀 | 뷰 | 원장에서 export |
그리고 변경이 났을 때 무엇이 따라 움직여야 하는지를 규칙으로 박아 둔다.
| 변경 | 갱신되어야 하는 것 |
|---|---|
| 기간 변경 | 후행 작업 일정, 마일스톤 도달일, 크리티컬 패스(전체 기간을 결정하는 최장 경로) |
| 작업 분할·추가 | 부모 집계(100% Rule), 간트, 담당자 배정 |
| 담당자 변경 | RACI(책임 분담표), 리소스 부하, 통지 대상 |
| 진척 갱신 | 상위 노드 집계(roll-up), 진척 보고, (EVM을 쓴다면) EV |
이 표의 오른쪽 열을 사람이 손으로 수행하고 있다면, 그것이 바로 매주 새는 공수의 정체다.
엑셀을 떠날 수 없다면 — 최소 방어 규칙 4가지
조직 사정상 당장 도구를 못 바꾸는 경우를 위한 차선책이다.
- 원본 파일 하나를 지정한다. 파일명에
[MASTER]를 박고, 나머지 모든 문서는 파생물임을 선언한다 - 파생물 직접 수정을 금지한다. 간트·보고서에서 오류를 발견하면 원본을 고치고 다시 생성한다
- 스냅샷 주기를 고정한다. 예: 매주 금요일 오후, 원본에서 간트·보고서를 재생성해 배포. 그 사이의 파생물은 "낡았을 수 있음"으로 간주
- 변경 로그를 의무화한다. 원본의 별도 시트에 날짜·변경 내용·사유·요청자를 기록. 3편에서 다룰 베이스라인의 최소 버전이다
죽은 계획의 진짜 비용
정합성이 깨진 계획의 비용은 수정 작업 시간이 아니다. 신뢰의 붕괴다. 팀원들이 "어차피 계획은 실제와 다르다"고 학습하는 순간, 계획은 아무도 참조하지 않는 장식물이 된다. 그때부터 프로젝트는 문서가 아니라 소문으로 돌아간다.
계획은 아름답게 만드는 것이 아니라, 살아 있게 유지하는 것이다. 그리고 살아 있으려면, 심장은 하나여야 한다.
PM의 실행 블록
내일 바로 할 일 3가지
- 지금 존재하는 계획 관련 문서를 전부 나열하고 원본 하나를 지정한다
- 나머지 문서 각각에 "이 문서는 MM/DD 원본 기준 파생물" 헤더를 단다
- 위 변경-동기화 표를 팀 위키에 올리고 다음 주간회의에서 합의한다
회의에서 던질 질문
- "이 숫자의 원본은 어느 파일입니까?"
- "지난주 변경 중 간트에 아직 반영 안 된 게 있습니까?"
- "이 보고서, 언제 시점의 원본에서 나온 겁니까?"
좋은 신호 / 나쁜 신호
| 좋은 신호 | 나쁜 신호 |
|---|---|
| "어느 게 맞아요?"라는 질문이 사라졌다 | 회의 때마다 문서 간 숫자를 대조한다 |
| 파생물은 아무도 직접 고치지 않는다 | 간트에만 있는 작업, WBS에만 있는 작업이 존재한다 |
| 변경 로그가 매주 쌓인다 | 최신 파일을 개인 메일함에서 찾는다 |
도구는 무엇을 해결해야 하는가
최소 방어 규칙의 한계는 명확하다 — 사람이 지켜야 유지된다는 것. wbsgantt를 설계하며 우리는 WBS·간트·진척을 같은 그래프의 뷰로 만들어 이 규칙 자체를 없앴다. 트리에서 쪼개면 간트가 즉시 바뀌고, 간트에서 끌면 트리 집계가 즉시 갱신된다. "동기화"라는 업무가 존재하지 않는 구조가 정답이라고 믿는다.