시리즈 안내
이 글은 “IT 프로젝트 관리 도구 완전 해부” 시리즈의 11편입니다. 3편부터 10편까지, 글로벌 7개와 국산 3개 — 모두 10개의 상용 도구를 해부했습니다. 이번 편에서는 잠시 멈춰, 그 도구들이 — 강력하든 단순하든, 글로벌이든 국산이든 — 공통적으로 무너지는 그 한 지점을 한자리에 모읍니다. 시리즈의 첫 번째 중간 정리입니다.
들어가며
10개의 도구는 저마다 달랐다. Jira는 강력했고, Trello는 단순했다. Linear는 빨랐고, monday는 예뻤다. Notion은 자유로웠고, 국산 도구는 친숙했다. 그런데 8개 회차를 관통하며 반복해서 마주친 장면이 있다. 어떤 도구를 봐도, 결국 같은 자리에서 같은 균열이 났다.
이번 글은 그 균열을 정면으로 본다. 개별 도구의 장단점이 아니라, 모든 도구가 공유하는 구조적 실패를 추려낸다. 이것이 4막에서 PSTA가 답하려는 바로 그 문제다.
1. 다섯 개의 잣대로 다시 보기
이 시리즈는 도구를 볼 때마다 같은 다섯 가지를 따져왔다. 이제 그것을 명시적으로 펼친다.
- ① 팀원 일일 사용성 — PM·PO가 아닌 일반 팀원이 매일 켜고 싶은가.
- ② 입력의 단일성 — 한 번 입력하면 끝나는가, 아니면 도구와 보고서에 따로 또 적는가.
- ③ 학습곡선 — 새 팀원이 설명 없이 바로 쓰는가.
- ④ 설정·권한 오버헤드 — 쓰기 시작하려고 누군가 한참 세팅해야 하는가.
- ⑤ 조직·시스템 연동 — 회사의 인사·조직 정보와 자연스럽게 맞물리는가.
10개 도구를 이 다섯 잣대에 비추면, 흥미로운 패턴이 드러난다. 어떤 도구도 다섯 개를 모두 충족하지 못했다. 그리고 더 중요한 건, 한 잣대를 잘하면 다른 잣대가 무너지는 상충(trade-off)이 반복됐다는 점이다.
2. 패턴 하나: 강력함과 단순함은 시소였다
Jira와 ClickUp은 강력했다. 거의 무엇이든 할 수 있었다. 그 대가로 학습곡선(③)이 가파르고 설정 부담(④)이 컸다. 반대로 Trello는 1분이면 익혔다(③ 만점). 그 대가로 진지한 프로젝트엔 깊이가 부족했다.
도구들은 마치 시소 위에 있는 듯했다. 강력함 쪽으로 기울면 팀원이 떠나고, 단순함 쪽으로 기울면 관리가 얕아졌다. monday는 첫 화면을 쉽게 만들었지만 보드가 늘자 복잡해졌고, Asana는 단정했지만 조직 관리 기능은 비싼 상위 플랜에 있었다. 누구도 “쉬우면서 동시에 깊은” 자리를 잡지 못했다.
3. 패턴 둘: ‘구축하는 사람’과 ‘쓰는 사람’이 갈렸다
거의 모든 도구에서 같은 분업이 나타났다. 한 명(보통 PM이나 도구에 밝은 누군가)이 워크플로우를 설계하고 보드를 만들고 자동화를 짠다. 나머지 팀원은 그가 만든 틀 안에서 시키는 대로 입력한다.
Notion에서 이건 ‘Notion 마스터’로, Jira에서는 ‘전담 관리자’로, monday에서는 ‘보드 설계자’로 나타났다. 이름만 다를 뿐 구조는 같다. 도구가 강력할수록, 그 강력함을 다루는 소수와 그렇지 않은 다수로 팀이 쪼개졌다. 그리고 다수에게 그 도구는 ‘내 도구’가 아니라 ‘윗선이 보는 곳’이 됐다.
4. 패턴 셋: 입력은 늘 팀원의 몫이었다 — 그리고 그건 ‘일’이 아니었다
가장 깊은 균열은 여기다. 2편에서 짚었듯, 소프트웨어의 진행 상황은 누군가 입력해야만 보인다. 그런데 그 입력은 진짜 일이 아니라 일에 대한 보고다.
10개 도구 모두, 이 입력 부담을 팀원에게 지웠다. 색깔을 칠하든(monday), 카드를 옮기든(Trello), 상태를 갱신하든(전부), 결국 사람이 손으로 한 번 더 기록해야 했다. 그리고 그 기록은 대개 도구 안의 작업과, 따로 쓰는 주간보고서에 이중으로 들어갔다(② 입력의 단일성 실패). 사람들이 도구를 안 쓰는 가장 큰 이유가 여기 있다. 게을러서가 아니라, 도구가 ‘일을 위한 일’을 늘렸기 때문이다.
5. 그래서, 공통의 실패는 무엇인가
세 패턴을 한 문장으로 모으면 이렇다.
기존 도구들은 “관리자가 보기 위한 도구”였지, “팀원이 일하기 위한 도구”가 아니었다.
화면은 관리자의 가시성을 위해 설계됐고, 그 가시성을 채우는 입력 노동은 팀원에게 전가됐다. 팀원 입장에서 도구는 자기 일을 돕는 게 아니라, 자기 일을 ‘보고’하라고 요구하는 존재였다. 그러니 안 쓴다. 이건 Jira의 문제도, ClickUp의 문제도, 국산 도구의 문제도 아니다. 프로젝트 관리 도구가 설계되는 방식 그 자체의 문제다.
짚고 가기: 도구를 바꿔도 같은 문제가 반복된다면, 답은 ‘더 나은 도구’가 아니라 ‘다른 구조’에 있다. 팀원이 자기 일을 하는 것이 곧 관리자의 가시성이 되는 구조 — 입력과 보고가 분리되지 않는 구조. 그런 구조가 가능하다면, 팀원은 비로소 도구를 ‘쓰기’ 시작할 것이다.
다음 편 예고
지금까지는 상용 도구였다. 비싸지만 관리되는 SaaS들. 다음 편(12부)부터는 다른 세계로 넘어간다 — 무료로 받아 직접 서버에 올리는 오픈소스 PMS다. 그 첫 주자는 20년 넘게 살아남은 노장, Redmine이다. 자체 호스팅·커스터마이즈·유지보수라는 새로운 잣대를 더해, 같은 다섯 가지 질문을 다시 던진다.
이전 글: IT 프로젝트 관리 도구 완전 해부 – 10. 국산 PMS — Flow·Jandi·콜라비는 무엇이 다른가
다음 글: IT 프로젝트 관리 도구 완전 해부 – 12. Redmine — 20년 된 오픈소스 PMS의 저력과 무게
