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