시리즈 안내
이 글은 “IT 프로젝트 관리 도구 완전 해부” 시리즈의 1편입니다. 0편에서 “좋다는 도구를 왜 팀원들은 안 쓰는가”라는 질문을 던졌습니다. 그 답을 찾기 전에, 이번 편에서는 토대를 세웁니다. 우리가 매일 쓰는 프로젝트 관리 도구들이 어떤 이론에서 출발했는지 그 계보를 정리합니다.
들어가며
우리는 매일 프로젝트 관리 도구를 켠다. Jira에 이슈를 만들고, 칸반 보드에서 카드를 옮기고, 스프린트를 끊는다. 그런데 이 익숙한 방식들이 어디서 왔는지, 애초에 무슨 문제를 풀려고 등장했는지 묻는 일은 드물다.
도구를 제대로 평가하려면 그 도구가 어떤 이론 위에 서 있는지부터 알아야 한다. 그래서 본격적인 도구 해부에 앞서, 프로젝트 관리 이론의 족보를 그려본다. 이 계보가 앞으로 13개 도구를 같은 잣대로 비교하는 기준점이 된다.
1. 모든 것의 출발: WBS와 간트 차트
현대 프로젝트 관리의 가장 오래된 뿌리는 WBS(Work Breakdown Structure, 작업 분해 구조)다. 핵심 발상은 단순하다. 거대한 일을 더 작은 단위로 쪼개고, 그것을 다시 쪼개서, 결국 “실행 가능한 최소 단위”까지 내려가는 것이다. 큰 목표는 손에 잡히지 않지만, 잘게 쪼갠 작업 하나는 누구든 할 수 있다.
비슷한 시기에 등장한 간트 차트(Gantt Chart)는 그렇게 쪼갠 작업들을 시간축 위에 막대로 늘어놓았다. 무엇이 언제 시작하고 끝나는지, 무엇이 무엇에 의존하는지를 한눈에 보여준 것이다. WBS가 “무엇을 할 것인가”의 구조라면, 간트는 “언제 할 것인가”의 그림이다.
이 둘은 100년 가까이 살아남았다. 지금도 거의 모든 PMS가 WBS식 트리 구조와 간트 뷰를 기본으로 품고 있다. 이론이 틀려서가 아니라, 너무 근본적이어서다.
짚고 가기: WBS의 “큰 일을 작은 실행 단위로 쪼갠다”는 발상은 이 시리즈 끝에서 다시 만난다. 가장 오래된 이론이 가장 중요한 단서가 된다.
2. 일정의 과학: CPM과 PERT
1950년대에 들어 프로젝트가 거대해지면서, 단순히 작업을 나열하는 것을 넘어 “어디가 병목인가”를 계산할 필요가 생겼다. 여기서 CPM(Critical Path Method, 임계경로법)이 나왔다. 수많은 작업의 의존 관계를 따라가다 보면, 전체 일정을 결정짓는 가장 긴 경로가 있다. 그 경로가 늦어지면 프로젝트 전체가 늦어진다. CPM은 “어디에 집중해야 마감을 지키는가”에 답했다.
PERT는 여기에 불확실성을 더했다. 각 작업이 얼마나 걸릴지 정확히 모를 때, 낙관·비관·평균 추정을 섞어 확률적으로 일정을 보는 기법이다. 이 둘은 건설·국방처럼 일정이 곧 돈인 분야에서 강력했다.
3. 소프트웨어의 반란: 애자일의 등장
문제는 소프트웨어였다. WBS·간트·CPM은 모두 “무엇을 만들지 처음에 다 안다”는 가정 위에 서 있다. 다리를 놓거나 건물을 올릴 때는 맞는 가정이다. 그런데 소프트웨어는 만들면서 요구사항이 바뀐다. 다 설계하고 시작해도, 두 달 뒤엔 절반이 쓸모없어진다.
2001년 애자일 선언(Agile Manifesto)은 이 모순을 정면으로 받았다. 계획을 한 번에 다 세우지 말고, 짧은 주기로 만들고 피드백받고 고치자는 것이다. 무거운 문서보다 작동하는 소프트웨어를, 계획 준수보다 변화 대응을 택했다.
애자일은 하나의 방법이 아니라 우산이다. 그 아래 여러 실천법이 있다.
스크럼(Scrum)은 일을 짧은 스프린트(보통 1~2주)로 끊고, 그 안에서 정해진 만큼만 완성한다. 매일 짧게 모여 진행을 공유하고, 스프린트가 끝나면 회고한다. 칸반(Kanban)은 더 유연하다. 스프린트 없이, 보드 위에서 작업 카드를 “할 일 → 진행 중 → 완료”로 흘려보낸다. 동시에 진행하는 일의 양을 제한해 흐름을 관리한다.
오늘날 우리가 쓰는 거의 모든 협업 도구가 이 스크럼과 칸반의 자식이다. Jira의 스프린트, Trello의 보드, 그 모든 것이 여기서 나왔다.
4. 목표의 언어: OKR
마지막으로 비교적 최근의 흐름 하나. OKR(Objectives and Key Results)는 엄밀히는 프로젝트 관리 기법이라기보다 목표 설정 프레임워크다. “무엇을 이루고 싶은가(Objective)”와 “그것을 어떻게 측정할 것인가(Key Results)”를 분리해, 팀이 같은 방향을 보게 만든다. 실행보다 정렬(alignment)의 도구이고, 그래서 많은 조직이 애자일 실행과 OKR을 함께 쓴다.
5. 이론은 틀리지 않았다
여기서 이 글의 가장 중요한 결론을 미리 못박아 두고 싶다. 위의 이론들은 대부분 틀리지 않았다. WBS의 분해, 애자일의 반복, 칸반의 흐름 제한 — 전부 수십 년간 검증된 사고들이다.
그렇다면 왜 우리는 도구 앞에서 매일 좌절하는가? 왜 그렇게 좋은 이론을 구현했다는 도구를, 정작 팀원들은 열어보지도 않는가?
힌트는 여기 있다. 이론은 옳지만, 그 이론을 담은 도구가 옳다는 보장은 없다. 좋은 이론도 잘못 구현되면 사람을 떠나게 만든다.
짚고 가기: 이론과 도구는 다른 문제다. 이 시리즈가 도구를 비판할 때, 그건 그 도구가 구현한 이론을 비판하는 게 아니라 구현 방식을 비판하는 것이다.
다음 편 예고
이론은 옳다. 그런데 그 이론들은 대부분 건설·제조처럼 “처음에 다 아는” 프로젝트를 위해 태어났다. 소프트웨어는 다르다. 다음 편(02부)에서는 이 간극을 파고든다. 건설 PM 이론을 IT 프로젝트에 그대로 가져왔을 때 정확히 어디서 깨지는지 — 요구사항 변동, 비가시적 산출물, 추정의 어려움이라는 IT만의 특수성을 다룬다.
이전 글: IT 프로젝트 관리 도구 완전 해부 – 00. 왜 이 시리즈를 쓰는가
다음 글: IT 프로젝트 관리 도구 완전 해부 – 02. IT 프로젝트의 특수성 — 건설 PM 이론이 깨지는 지점
