엑셀로 만드는 WBS와 일정표: 어디까지 가능하고 언제 넘어갈 것인가

엑셀로 WBS와 일정표를 만들 수 있다. 많은 프로젝트에서 합리적인 출발점이기도 하다. 문제는 도구가 아니라 시점이다. 스프레드시트는 계획을 적어 두는 문서로는 훌륭하지만, 계획을 계산하고 유지하는 모델은 아니다. 이 글에서는 엑셀이 잘하는 일을 먼저 보고, 표와 일정 모델이 갈라지는 세 지점을 짚는다. 그다음 그래도 엑셀이 맞는 경우와, 전용 도구로 넘어갈 때가 됐음을 알리는 신호들을 정리한다.

엑셀은 왜 언제나 첫 도구인가

이유는 단순하다. 이미 모두의 컴퓨터에 있고, 모두가 쓸 줄 알고, 어떤 양식이든 즉시 만들 수 있다. 행을 늘리면 작업 목록이 되고, 열을 늘리면 주차가 되고, 셀에 색을 칠하면 간트차트 비슷한 것이 된다. 추가 비용도, 결재도, 학습도 필요 없다.

계획 초안을 잡는 단계에서 이만한 도구는 드물다. 생각나는 대로 적고 마음대로 지우고, 구조를 세 번 갈아엎어도 걸리는 것이 없다. 우리는 일정 도구를 만드는 팀이지만 첫 브레인스토밍은 지금도 종이나 스프레드시트로 할 때가 많다. 초안 단계에서는 유연한 것이 가장 큰 장점이다.

표와 일정 모델은 다른 물건이다

계획이 적어 두는 문서에서 관리하는 대상으로 바뀌는 순간 둘은 갈라진다. 표는 셀에 적힌 값을 보여줄 뿐 값들 사이의 관계는 담지 못한다. "설계가 끝나야 개발을 시작할 수 있다"는 사실은 표가 아니라 그 표를 만든 사람의 머릿속에 있다.

일정 모델은 반대로 관계가 정본이다. 작업의 기간과 순서(종속성)를 입력하면 날짜는 계산해서 나온다. 선행 작업이 3일 밀리면 후행 작업의 날짜도 따라 움직인다. 표에서는 사람이 그 3일을 기억했다가 아래 수십 개 행을 손으로 고쳐야 한다.

첫 번째 한계, 구조가 셀에 갇힌다

WBS는 들여쓰기 목록이 아니라 검증할 수 있는 분해 구조다. 전체 범위가 하위 항목으로 빠짐없이 나뉘었는지(100% Rule), 같은 작업이 두 곳에 걸쳐 있지는 않은지 물을 수 있어야 한다. 이 질문에 답할 수 있어야 계획이 단단해진다. 분해하는 방법은 WBS 작성법 5단계에서 다뤘다.

엑셀에서 계층은 들여쓰기와 병합 셀로 표현한다. 눈에는 트리로 보이지만 엑셀이 아는 것은 이 셀을 몇 칸 들여썼는지뿐이다. 하위 항목을 빠뜨려도, 같은 일을 두 단계에 적어도 경고가 뜨지 않는다. 행을 옮기다 들여쓰기가 한 칸 어긋나면 구조가 그대로 바뀌어 버린다. 검증은 전부 사람의 눈에 달려 있다.

두 번째 한계, 날짜가 계산되지 않는다

수식을 잘 쓰면 엑셀도 날짜를 계산한다. WORKDAY 함수로 주말을 건너뛰고 시작일에 기간을 더할 수 있다. 하지만 작업 사이의 종속성, 여러 선행 작업 중 가장 늦게 끝나는 쪽에 맞추는 계산, 전체 일정을 결정하는 critical path, 프로젝트마다 다른 공휴일 캘린더까지 수식으로 유지하려면 사실상 소프트웨어를 하나 더 개발해야 한다.

그래서 엑셀 일정표는 대부분 계산을 포기하고 날짜를 직접 적는다. 그 순간부터 표는 "선행이 밀리면 후행은 얼마나 밀리는가"에 답하지 못한다. 지연은 이미 생겼는데 일정표는 멀쩡해 보이는, 가장 위험한 상태가 된다.

세 번째 한계, 파일마다 내용이 다르다

계획은 혼자 보는 문서가 아니다. 팀원이 진척을 적고, 고객이 최신본을 달라고 하고, PM이 보고서를 만든다. 파일로 관리하는 계획은 대개 비슷하게 끝난다. 일정_최종_v7_고객공유용.xlsx가 메일함마다 조금씩 다른 버전으로 남고, 회의는 어느 파일이 진짜인지 확인하는 것으로 시작된다.

이 문제는 엑셀로 만든 계획은 만든 날부터 죽는다에서 자세히 다뤘다. 요점만 옮기면 이렇다. 문서는 만든 순간부터 현실과 멀어지고, 갱신하는 비용이 처음 작성한 비용을 넘어서면 아무도 갱신하지 않는다.

그래도 엑셀이 맞는 경우

반대 경우도 분명히 해 두자. 다음 상황이라면 엑셀로 충분하고, 전용 도구를 들이는 편이 오히려 과하다.

• 작업이 20개 안팎이고 기간이 몇 주인 단발 프로젝트
• 종속성이 거의 없어 순서가 뻔한 일
• 한 번 세우면 바뀔 일이 거의 없는 계획
• 그 계획을 볼 사람이 나 혼자인 경우

규모와 상관없이, 보고서를 주고받는 형식으로서 엑셀은 여전히 표준이다. 고객과 경영진은 엑셀 파일을 원하고 이 사실은 앞으로도 크게 바뀌지 않는다. 우리도 일정 도구의 계획을 엑셀 보고서로 뽑아내는 실험을 했다. 문제는 엑셀이라는 형식이 아니라 엑셀을 계획의 정본으로 두고 운영하는 방식이다.

전환 시점을 알리는 신호들

넘어갈 때가 됐는지는 도구를 비교해서가 아니라 지금 겪는 증상으로 판단한다.

• 일정표를 갱신하는 데 매주 2~3시간을 쓴다. 갱신 비용이 작성 비용을 넘었다
• "원래 계획이 뭐였죠?"라는 질문에 파일을 뒤져야 한다. baseline이 없다
• WBS 문서와 일정표 문서의 내용이 서로 다르다. 정본이 둘이다
• 선행 작업이 밀렸는데 일정표의 후행 날짜는 그대로다. 지연이 드러나지 않는다
• 회의가 "어느 버전이 최신인가"로 시작된다. 버전 관리 자체가 리스크가 됐다

체크리스트로 쓰면 된다. 2개 이상 해당하면 지금 쓰는 도구의 한계에 계획이 눌려 있을 가능성이 크다.

접근 방식 비교, 문서와 모델

오른쪽 열이 항상 옳지는 않다. 왼쪽 열의 "학습 곡선 없음"과 유연함은 실무에서 아주 큰 장점이다. 지금이 초안을 잡는 단계라면 왼쪽이 정답이다.

함께 살펴볼 만한 도구들

전용 도구로 넘어가기로 했다면 선택지는 넓다. 도구마다 잘하는 지점이 다르다.

• Google Sheets. 엑셀의 공동 편집 문제를 푼 표다. 다만 표라는 점은 같다.
• MS Project. 데스크톱 일정 도구의 오랜 표준이다. CPM과 자원 관리 기능이 깊다. 선택 기준은 다음 편에서 따로 다룬다.
• Smartsheet·Asana·Monday 계열. 협업 중심의 워크 매니지먼트 도구다. 일정 계산보다 업무 흐름에 무게가 있다.
• wbsgantt. 우리가 만드는 도구다. WBS 트리를 정본으로 두면 간트와 CPM, 근무일 캘린더, baseline이 따라오는 구조라, 이 글에서 말한 문서에서 모델로 넘어가는 지점을 겨냥했다. 엑셀이 필요한 순간을 위해 보고서 Excel 출력을 넣어 두었다.

어느 쪽을 고르든 판단 기준은 기능 목록이 아니라 지금 계획에서 나타나는 증상이다. 위 신호 목록에서 출발하면 필요 이상으로 비싼 도구를 사는 일도, 너무 늦게 넘어가는 일도 피할 수 있다.