엑셀로 만든 계획은 만든 날부터 죽는다

킥오프 전날 밤, PM은 뿌듯하다. 엑셀로 만든 WBS는 4단계까지 깔끔하게 분해됐고, 그것을 옮겨 그린 간트차트는 색까지 입혀 한 장으로 잘 정리됐다. 경영진 보고도 무사히 끝났다.

2주 뒤다. 개발 일정이 3일 밀렸고, 작업 2개가 쪼개졌고, 담당자 하나가 바뀌었다. PM은 엑셀 WBS를 고친다. 간트차트도 고쳐야 하는데 급한 불부터 끄느라 미룬다. 다시 2주 뒤, 팀원이 묻는다. "WBS에는 이 작업이 있는데 간트에는 없어요. 어느 게 맞아요?" PM은 답한다. "제 머릿속에 있는 게 맞아요."

이 장면의 문제는 PM이 성실하지 않아서가 아니다. 같은 정보를 두 곳에 적는 구조 자체가 문제다.

문서가 두 개면 진실도 두 개가 된다

WBS와 간트차트는 별개의 산출물처럼 보이지만 사실 같은 데이터의 두 가지 표현이다. WBS는 무엇을 하는가의 계층 구조이고, 간트는 같은 작업들의 시간 배치다. 그런데 도구가 이 둘을 별도 파일로 관리하게 만들면 모든 변경을 두 번 반영해야 한다.

두 번 반영하는 일은 반드시 실패한다. 게을러서가 아니라 확률 때문이다. 프로젝트 6개월 동안 변경이 200번 일어난다고 하자. 매번 두 문서를 모두 즉시 정확히 고칠 확률이 99%라 해도, 200번 뒤 두 문서가 일치할 확률은 13%에 불과하다. 나머지 87%의 경우 PM은 회의 때마다 어느 문서가 맞는지를 기억으로 보정하는 사람이 된다.

그래서 엑셀 계획은 만든 날부터 낡기 시작한다. 정확히 말하면 첫 변경이 일어나는 순간부터 어긋나기 시작한다. 그리고 프로젝트에서 변경이 없는 날은 없다.

문서가 아니라 모델을 관리한다

해법의 방향은 명확하다. WBS와 간트를 두 개의 문서가 아니라 하나의 데이터를 보여주는 두 개의 뷰로 만드는 것이다.

소프트웨어 설계에는 오래된 원칙이 있다. 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·간트·진척을 같은 데이터의 뷰로 만들어 이 규칙 자체를 없앴다. 트리에서 쪼개면 간트가 바로 바뀌고, 간트에서 끌면 트리 집계가 바로 갱신된다. 동기화라는 업무가 아예 없는 구조가 정답이라고 본다.