시리즈 안내
이 글은 누스쿨 “IT 프로젝트 관리 도구 완전 해부” 시리즈의 2편입니다. 1편에서 프로젝트 관리 이론의 계보를 살펴보며 “이론 자체는 틀리지 않았다”고 했습니다. 그런데 그 이론들은 대부분 건설·제조를 위해 태어났습니다. 이번 편에서는 그 이론을 소프트웨어에 그대로 가져왔을 때 어디서 깨지는지 — IT 프로젝트만의 특수성을 짚어봅니다. PM·PO로 이직을 준비한다면, 이 특수성을 말로 설명할 수 있는지가 실제 면접에서 갈립니다.
들어가며
다리를 놓는 일과 소프트웨어를 만드는 일은 둘 다 “프로젝트”입니다. 둘 다 목표가 있고, 일정이 있고, 자원이 있고, 끝이 있습니다. 그래서 오랫동안 사람들은 건설과 제조에서 다듬어진 프로젝트 관리 이론을 소프트웨어에도 그대로 적용해 왔습니다.
그런데 잘 안 됐습니다. 같은 이론, 같은 도구를 써도 소프트웨어 프로젝트는 유독 더 자주 늦고, 더 자주 어긋났습니다. 이유는 소프트웨어가 가진 세 가지 특수성 때문입니다. 이 특수성을 이해하는 것이 곧 “왜 IT용 프로젝트 관리가 따로 필요한가”에 대한 답이고, PM·PO 실무에서 당연하게 알고 있어야 할 맥락입니다.
1. 요구사항은 끝까지 변한다
건물을 짓다가 “역시 3층 말고 5층으로 올릴까요”라고 하면 공사는 멈춥니다. 기초 설계가 통째로 바뀌기 때문입니다. 그래서 건설은 처음에 모든 것을 확정하고 시작합니다. WBS도 간트도 CPM도, 이 “처음에 다 안다”는 전제 위에 서 있습니다.
소프트웨어는 반대입니다. 만들어서 보여주기 전까지는 고객도, 심지어 만드는 사람도 진짜 원하는 게 뭔지 모릅니다. 화면을 보고 나서야 “아, 이게 아니네”를 깨닫습니다. 요구사항이 변하는 건 사고가 아니라 소프트웨어의 본질입니다.
여기서 첫 번째 균열이 생깁니다. 처음에 짠 완벽한 WBS와 간트 차트는, 두 달 뒤면 절반이 현실과 맞지 않습니다. 계획을 세우는 데 들인 시간만큼, 그 계획을 수정하는 데 또 시간이 듭니다.
짚고 가기: 건설 도구는 “계획대로 실행”을 돕습니다. 소프트웨어 도구는 “변화에 맞춰 계획을 끊임없이 고치는 일”을 도와야 합니다. 이 둘은 전혀 다른 도구입니다.
2. 산출물이 눈에 보이지 않는다
건설 현장은 진행 상황이 눈에 보입니다. 골조가 올라가고, 벽이 세워지고, 누가 봐도 “70% 정도 됐구나”를 압니다. 물리적 산출물이 그 자체로 진행률입니다.
소프트웨어는 보이지 않습니다. 개발자가 “거의 다 됐어요”라고 말하는 그 코드는 눈에 보이지 않고, 90% 완성과 99% 완성의 차이는 외부에서 식별되지 않습니다. 그 유명한 농담 — “마지막 10%가 전체 시간의 90%를 잡아먹는다” — 가 괜히 나온 게 아닙니다.
그래서 소프트웨어 프로젝트는 진행 상황을 누군가 수동으로 입력해야만 보입니다. 개발자가 상태를 갱신하지 않으면 PM은 아무것도 알 수 없습니다. 바로 여기서 이 시리즈의 핵심 문제가 싹틉니다. 진행 상황을 보이게 하려면 누군가 끊임없이 도구에 입력해야 하는데, 그 입력은 일이 아니라 일에 대한 보고입니다. 그리고 사람들은 보고를 싫어합니다.
3. 추정이 빗나간다
벽돌 1만 장을 쌓는 데 걸리는 시간은 꽤 정확히 예측됩니다. 과거 데이터가 쌓여 있고, 작업이 반복적이기 때문입니다.
소프트웨어의 작업은 매번 다릅니다. 똑같은 기능을 두 번 만들지 않습니다(이미 만든 건 재사용하면 되니까). 그래서 모든 개발 작업은 어느 정도 “처음 해보는 일”이고, 처음 해보는 일의 소요 시간은 정확히 추정할 수 없습니다. 개발자의 “이틀이면 돼요”가 일주일이 되는 건 그가 게을러서가 아니라, 추정이 본질적으로 어렵기 때문입니다.
이 불확실성은 일정 관리를 근본적으로 흔듭니다. CPM이 계산하는 임계경로도, 간트가 그리는 일정 막대도, 각 작업의 추정치가 정확하다는 전제 위에서만 의미가 있습니다. 그 전제가 무너지면 정교한 일정 계산은 모래 위의 성이 됩니다.
4. 그래서 무엇이 필요한가
세 가지 특수성을 종합하면, IT 프로젝트 관리 도구에 필요한 것이 분명해집니다.
첫째, 변화를 전제해야 합니다. 한 번 짜고 끝나는 계획이 아니라, 쉽게 고치고 다시 짤 수 있는 유연한 구조가 필요합니다. 둘째, 진행 상황을 보이게 만들되, 그 입력 부담을 최소화해야 합니다. 보고를 위한 보고가 일이 되어선 안 됩니다. 셋째, 불확실성을 끌어안아야 합니다. 정밀한 예측보다, 변하는 현실을 빠르게 반영하는 쪽이 낫습니다.
애자일이 등장한 게 바로 이 때문입니다. 그런데 여기서 핵심 질문이 남습니다. 애자일이라는 이론은 이 문제를 풀었는데, 그 이론을 구현한 도구들은 과연 이 세 가지를 잘 해내고 있는가? PM·PO 이직을 준비한다면, 이 질문을 스스로 던져보는 것 자체가 도구 선택 능력을 증명하는 방법입니다.
짚고 가기: 진행 상황을 보이게 만드는 입력 부담 — 이것이 앞으로 13개 도구를 평가할 때 가장 자주 등장할 잣대입니다. 좋은 도구는 이 부담을 줄이고, 나쁜 도구는 팀원에게 떠넘깁니다.
다음 편 예고
이론적 토대는 여기까지입니다. 다음 편(03부)부터 드디어 실제 도구 해부에 들어갑니다. 첫 번째 대상은 개발 조직의 사실상 표준, Jira입니다. 강력하고, 유연하고, 거의 모든 기능을 갖춘 이 도구가 — 왜 정작 비개발 팀원에게는 높은 벽이 되는지, 같은 기준으로 차근차근 뜯어봅니다. PM·PO로 이직을 준비한다면, Jira는 반드시 자기 언어로 설명할 수 있어야 할 도구입니다. 오늘 짚은 세 가지 특수성이 Jira를 읽는 렌즈가 될 겁니다. 누스쿨 커뮤니티에서도 이 시리즈에 대한 생각을 나눠 주시면 반갑습니다.
이전 글: IT 프로젝트 관리 도구 완전 해부 – 01. 프로젝트 관리 이론의 계보 — WBS에서 애자일까지
다음 글: IT 프로젝트 관리 도구 완전 해부 – 03. Jira — 개발자의 표준, 그러나 누구를 위한 표준인가
💬 댓글 0