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

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

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

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

계획의 초안을 잡는 단계에서 이만한 도구는 드물다. 생각나는 대로 적고, 마음대로 지우고, 구조를 세 번 갈아엎어도 아무 저항이 없다. 우리는 일정 도구를 만드는 팀이지만, 첫 브레인스토밍은 지금도 종이나 스프레드시트로 할 때가 많다. 유연함이 필요한 국면에서 유연함은 미덕이다.

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

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

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

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

WBS는 들여쓰기 목록이 아니라 검증 가능한 분해 구조다. 전체 범위가 자식들로 빠짐없이 나뉘었는가(100% Rule), 한 작업이 두 곳에 걸치지 않는가. 이 질문에 답할 수 있어야 계획의 바닥이 단단해진다. 분해를 어떻게 하는지는 WBS 작성법 5단계에서 다뤘다.

엑셀에서 계층은 들여쓰기와 병합 셀로 표현된다. 보기에는 트리지만, 도구가 아는 것은 "이 셀이 몇 칸 들여써졌는가"뿐이다. 하위 항목을 빠뜨려도, 같은 일을 두 단계에 적어도 경고는 없다. 행을 옮기다 들여쓰기가 한 칸 어긋나면 구조 자체가 소리 없이 바뀐다. 검증이 전부 사람의 눈에 걸려 있다.

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

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

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

세 번째 한계 — 두 파일이 서로 다른 말을 한다

계획은 혼자 보는 문서가 아니다. 팀원이 진척을 적고, 고객이 최신본을 요구하고, PM이 보고서를 만든다. 파일 기반 계획의 종착지는 대개 비슷하다. 일정_최종_v7_고객공유용.xlsx가 메일함마다 다른 버전으로 존재하고, 회의는 어느 파일이 진짜인지 확인하는 것으로 시작된다.

이 문제는 엑셀로 만든 계획은 만든 날부터 죽는다에서 길게 해부했다. 요점만 옮기면, 문서는 만들어진 순간부터 현실과 멀어지기 시작하고, 갱신 비용이 작성 비용을 넘는 순간 아무도 갱신하지 않게 된다.

그래도 엑셀이 맞는 경우

균형을 위해 반대 경우를 분명히 하자. 다음 상황이라면 엑셀로 충분하고, 도구 도입이 오히려 과하다.

• 작업이 스무 개 안팎이고 기간이 몇 주인 단발 프로젝트
• 종속성이 거의 없어 순서가 자명한 일
• 계획을 한 번 세우면 바뀔 일이 드문 일
• 계획의 소비자가 나 하나뿐인 경우

그리고 규모와 무관하게, 보고 산출물 포맷으로서의 엑셀은 여전히 표준이다. 고객과 경영진은 엑셀 파일을 원하고, 그 사실은 앞으로도 크게 바뀌지 않을 것이다. 우리도 일정 도구의 계획을 엑셀 보고서로 뽑아내는 실험을 했을 정도다. 문제는 엑셀이라는 포맷이 아니라, 엑셀을 계획의 정본으로 삼는 운영이다.

전환 시점을 알리는 신호들

전환이 필요한 시점은 도구가 아니라 증상으로 나타난다.

• 일정표 갱신에 매주 두세 시간을 쓰고 있다 — 갱신 비용이 작성 비용을 넘었다
• "원래 계획이 뭐였죠?"라는 질문에 파일을 뒤져야 한다 — baseline이 없다
• WBS 문서와 일정표 문서가 서로 다른 말을 한다 — 정본이 둘이다
• 선행 작업이 밀렸는데 일정표의 후행 날짜는 그대로다 — 지연이 숨는다
• 회의가 "어느 버전이 최신인가"로 시작된다 — 버전 관리가 곧 리스크다

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

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

표의 오른쪽이 항상 옳은 것은 아니다. 왼쪽 열의 "학습 곡선 없음"과 유연함은 실전에서 매우 큰 이점이고, 국면이 초안이라면 왼쪽이 정답이다.

함께 살펴볼 만한 도구들

전용 도구로 넘어가기로 했다면 선택지는 넓다. 각자 최적화된 지점이 다르다.

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

어느 쪽이든 판단 기준은 도구의 기능 목록이 아니라 지금 계획이 앓고 있는 증상이어야 한다. 위 신호 목록에서 출발하면 과한 도구를 사는 일도, 너무 늦게 넘어가는 일도 피할 수 있다.