MS Project 대안, 무엇을 보고 고를 것인가 — PM의 선택 기준

MS Project의 대안을 찾는다는 것은 대개 더 싼 도구를 찾는 일이 아니라, 지금 팀이 일하는 방식에 맞는 도구를 찾는 일이다. MS Project는 수십 년간 다듬어진, 가장 깊은 일정 엔진이다. 그런데도 많은 PM이 대안을 검색한다. 이 글은 그 이유를 용도 불일치로 해부하고, 대안을 고를 때 실제로 봐야 하는 네 가지 기준을 제시한 뒤, 반대로 MS Project가 정답인 경우를 분명히 한다.

MS Project는 왜 표준이 되었나

먼저 인정할 것을 인정하자. MS Project는 CPM 계산, 자원 평준화, 비용 관리까지 갖춘 일정 도구의 원형에 가깝다. 건설·방산·EPC 같은 대형 프로그램 업계에서 수십 년간 표준으로 쓰였고, 일정 관리 교육 자체가 사실상 이 도구를 기준으로 쓰인 시기가 길었다. 일정 엔진의 깊이만 놓고 보면 지금도 이만한 도구는 많지 않다.

그러니 대안을 찾는 이유가 "MS Project가 나빠서"라면 질문이 틀렸다. 도구는 훌륭하다. 문제는 그 훌륭함이 지금 내 프로젝트에 필요한 종류인가다.

그런데 왜 대안을 찾는가

첫째, 깊이의 대가는 무게다. 자원 평준화까지 쓰는 PM은 소수이고, 대부분은 기능의 일부만 쓰면서 전체의 학습 곡선을 감당한다. 도구를 배우는 시간이 계획을 다듬는 시간을 잠식하면 주객이 바뀐 것이다.

둘째, 계획이 다시 문서로 유통되기 쉽다. 많은 현장에서 MS Project는 PM 한 사람의 전문 작업대로 남는다. 팀원과 고객은 도구를 열지 않고, PM이 추출한 PDF나 엑셀을 본다. 그 순간 계획은 살아있는 모델이 아니라 스냅샷 문서로 소비되고, 문서 기반 운영의 문제들이 그대로 돌아온다.

셋째, 도입의 문턱이다. 라이선스 결재, 설치, 팀원 수만큼의 비용 계산. 계획 도구 하나를 쓰기 위해 넘어야 할 절차가 프로젝트 착수보다 무거워지는 경우가 있다.

셋 다 도구의 결함이 아니라 상황과의 불일치다. 그래서 대안 선택의 기준도 기능 개수가 아니라 불일치의 해소여야 한다.

기준 1 — WBS를 1급으로 다루는가

경량 도구 상당수는 계획을 "작업 목록과 막대"로 본다. 하지만 일정의 바닥은 범위의 구조다. 전체 일이 빠짐없이 분해되었는지(100% Rule), 계층이 검증 가능한지를 도구가 알아야, 빠진 일이 일정에서도 빠지는 사고를 구조적으로 막을 수 있다. 분해의 방법은 WBS 작성법 5단계에서 다뤘다. 후보 도구에서 WBS가 장식인지 정본인지부터 확인하자.

기준 2 — 베이스라인과 변경 추적이 있는가

실행이 시작되면 계획의 가치는 "원래 계획 대비 지금 어디인가"에 답하는 데서 나온다. 승인 시점의 계획을 스냅샷으로 잠그는 baseline, 그 기준과 현재의 비교, 그리고 누가 무엇을 바꿨는지의 이력. 이 세 가지가 없는 도구는 계획 작성 도구일 수는 있어도 계획 통제 도구는 아니다. MS Project가 오래 표준이었던 이유 중 하나가 바로 이 통제 기능이고, 대안이라면 같은 질문에 답할 수 있어야 한다.

기준 3 — 일정을 계산하는가, 그리는가

간트차트를 그리는 도구와 계산하는 도구는 다르다. 종속성을 입력하면 날짜가 나오고, 선행이 밀리면 후행이 따라 밀리고, critical path가 표시되는가. 근무일과 공휴일 캘린더를 아는가. 원리는 간트차트 만드는 법에서 다뤘고, 지연 하루가 전체 일정을 어떻게 미는지는 한 작업이 3일 밀리면에서 실제 데이터로 실연했다. 확인 방법은 간단하다 — 체험 중에 선행 작업 하나를 일부러 밀어보라. 후행 막대가 제자리에 있다면 그 도구의 간트는 그림이다.

기준 4 — 팀이 실제로 쓰는가

도구의 러닝커브는 둘로 나눠 봐야 한다. 계획을 편집하는 PM의 러닝커브와, 열람하고 진척을 입력하는 팀의 러닝커브다. 전자는 투자할 가치가 있지만, 후자가 높으면 도구는 다시 PM 혼자의 작업대가 되고 계획은 다시 추출물로 유통된다. 브라우저로 바로 열리는가, 읽기 전용 공유가 되는가, 진척 입력이 한 클릭 거리인가 — 팀 관점의 문턱이 두 번째 문제를 결정한다.

접근 방식 비교 — 전문가의 작업대와 팀의 창

늘 그렇듯 오른쪽이 정답인 것은 아니다. 왼쪽 열의 깊이가 실제로 필요한 프로젝트에서 오른쪽을 고르면, 이번에는 반대 방향의 용도 불일치가 생긴다.

그래도 MS Project가 맞는 경우

다음 상황이라면 대안 탐색이 오히려 비용이다.

• 자원 평준화, 비용 관리 같은 깊은 기능을 실제로 매주 쓰는 대형 프로그램
• 발주처나 업계 관행이 MS Project 산출물을 표준으로 요구하는 경우(건설·방산·EPC)
• 조직에 이미 라이선스와 숙련된 전담 플래너가 있는 PMO
• 수백 개 작업·다중 프로젝트 자원 배분을 한 사람이 계산해야 하는 경우

도구 전환은 그 자체가 프로젝트다. 위 조건에 있다면 지금 도구의 깊이를 더 쓰는 편이 낫다.

함께 살펴볼 만한 도구들

대안을 찾기로 했다면, 각자 다른 지점에 최적화된 후보들이 있다.

• Microsoft Planner — 같은 Microsoft 생태계 안의 가벼운 협업 작업 관리 축.
• Smartsheet — 스프레드시트 문법 위에 간트와 자동화를 얹은 도구.
• OpenProject — 오픈소스. 직접 운영할 수 있는 조직에 맞다.
• GanttPRO·TeamGantt 계열 — 간트 중심의 경량 협업 도구.
• wbsgantt — 우리가 만드는 도구다. WBS 트리를 정본으로 두고 계산되는 간트·baseline·읽기 전용 공유 링크로 위 네 기준을 정면으로 겨냥했다. 반대로 자원 평준화는 없다 — 그 기능이 매주 필요하다면 MS Project가 맞는 선택이다.

기능표를 늘어놓고 개수를 세는 비교는 대개 실패한다. 네 가지 기준 중 지금 프로젝트가 앓는 것이 무엇인지에서 출발하면, 도구는 생각보다 빨리 좁혀진다.