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