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