시리즈 안내
이 글은 “IT 프로젝트 관리 도구 완전 해부” 시리즈의 19편입니다. 18편에서 PSTA의 기본 발상 — 4계층 구조와 “팀원에서 시작해 관리자로 흐르는” 방향 — 을 봤습니다. 이번 편에서는 그 위에 더해진 구체적 차별점들을 다룹니다. 자동 집계를 넘어, 산출물 연결·외부 공유·조직 연동까지, 기존 도구가 놓친 지점을 PSTA가 어떻게 메우는지 살펴봅니다.
들어가며
18편에서 본 자동 흐름(Action 완료 → Project 진행률 자동 갱신)이 PSTA의 척추라면, 이번 편의 세 가지는 그 위에 붙는 근육이다. 각각이 시리즈 내내 짚어온 구체적 결핍을 겨냥한다. 하나씩 보자.
1. 자동 집계 — “PM이 취합하지 않는다”
먼저 18편의 자동 흐름을 한 번 더, 이번엔 그 의미를 짚으며 본다.
기존 도구에서 진행률은 누군가 만든다. PM이 팀원들에게 묻고, 주간보고를 취합하고, 대시보드를 수동으로 갱신한다. 그 취합 노동이 곧 PM의 일과였다. 17편에서 본 “일을 위한 일”이 관리자 쪽에서도 똑같이 벌어졌던 것이다.
PSTA에서는 이 취합이 사라진다. 팀원이 자기 Action을 완료로 바꾸는 순간, 그 변화가 Team → Service → Project로 자동으로 전파된다. PM은 묻지 않고, 취합하지 않는다. 그저 자동으로 채워진 현황을 본다. 한 번의 입력이 세 곳(진행률·보고·가시성)을 동시에 채운다. 16편 채점표에서 14개 도구 모두 비어 있던 ‘입력의 단일성’을, 이 자동 집계가 메운다.
2. 산출물 허브 — 문서를 만들지 말고 연결하라
두 번째 차별점은 7편 Notion을 다루며 미리 깔아둔 지점이다.
대부분의 PMS는 두 가지 중 하나다. 문서 기능이 빈약해 작업과 산출물이 따로 놀거나(대부분의 전용 도구), 아니면 문서까지 다 담으려다 무거워지거나(Notion·ClickUp). PSTA는 제3의 길을 택한다. 문서를 직접 만들지 않고, 연결한다.
팀은 이미 Notion에 기획서를, 구글 시트에 데이터를, 구글 슬라이드에 발표자료를, 드라이브에 파일을 둔다. PSTA는 이걸 PSTA 안으로 옮겨오라고 하지 않는다. 대신 각 Action에 그 산출물을 링크로 연결한다. Action을 열면 그 일의 실제 결과물(외부 문서)이 바로 거기 있다.
이게 왜 중요한가? 첫째, 팀원이 익숙한 도구를 계속 쓴다. 새 에디터를 배울 필요가 없다(학습곡선 부담 감소). 둘째, 작업과 산출물이 한자리에 모인다 — “그 문서 어디 있더라”가 사라진다. PSTA는 만능 워크스페이스가 되려 하지 않고, 이미 흩어진 산출물을 작업에 꿰는 허브가 되기를 택했다. 무거워지지 않으면서 맥락을 잇는 방법이다.
3. 외부 공유 — 계정 없이 현황을 보여준다
세 번째는 8편 Linear에서 대비로 짚었던 지점이다.
기존 도구 대부분은 현황을 보여주려면 상대가 계정을 만들어야 한다. 고객이나 외부 이해관계자에게 진행 상황을 공유하려면, 그들을 유료 시트로 초대하거나(Linear처럼 관찰자도 과금), 따로 보고서를 만들어 보내야 했다. 둘 다 마찰이다.
PSTA는 계정 없이 URL로 공유한다. 현황 페이지의 링크를 열고, 필요하면 OTP(일회용 인증)로 보호한다. 고객은 가입도, 로그인도 없이 그 링크만 열면 프로젝트가 지금 어디까지 왔는지 본다. PM은 보고서를 따로 만들 필요가 없다 — 18편의 자동 집계로 이미 최신인 그 현황을, 링크 하나로 내보내면 된다. “보고를 위한 보고”가 외부 공유에서도 사라진다.
4. 조직 연동 — 회사 시스템이 곧 PSTA의 조직
마지막은 13편 OpenProject의 LDAP을 다루며 대비로 깔아둔 지점이다.
5개 평가 축 중 하나가 ‘조직·시스템 연동’이었다. 회사는 이미 인사 시스템에 누가 어느 부서이고 누가 누구의 상사인지를 갖고 있다. 그런데 대부분의 PMS는 이 정보를 무시하고, 도구 안에서 조직을 처음부터 다시 만들게 한다. 사람을 일일이 초대하고, 팀을 다시 짜고, 권한을 새로 설정한다.
PSTA는 회사의 인사·조직 정보(LDAP 등)와 연동해, 회사 시스템이 곧 PSTA의 조직 구조가 되게 한다. 인사 시스템이 사람과 부서를 책임지고, PSTA는 프로젝트 상의 역할을 책임진다. 둘이 맞물리니, 도입할 때 조직을 처음부터 세팅하는 부담이 크게 준다. 17편에서 본 ‘설정 오버헤드’를 조직 차원에서 덜어내는 장치다.
5. 차별점이 향하는 하나의 방향
네 가지 차별점은 제각각으로 보이지만 한 방향을 가리킨다. 마찰을 없애는 것.
자동 집계는 PM의 취합 마찰을, 산출물 허브는 도구 전환과 학습의 마찰을, 외부 공유는 보고와 초대의 마찰을, 조직 연동은 도입 세팅의 마찰을 없앤다. 17편에서 진단한 “일을 위한 일”을 — 팀원에게서도, PM에게서도, 외부 공유에서도, 도입 단계에서도 — 줄이려는 일관된 설계다.
이 모든 게 18편의 한 가지 방향에서 흘러나온다. 팀원이 자기 일을 하면, 나머지는 구조가 알아서 한다.
짚고 가기: PSTA의 차별점은 “더 많은 기능”이 아니라 “더 적은 마찰”이다. 문서를 만들지 않고 잇고, 보고서를 쓰지 않고 링크로 내보내고, 조직을 다시 짜지 않고 회사 시스템에 얹는다. 기능을 더할수록 무거워진 14개 도구와 정반대로, PSTA는 덜어내는 방향으로 차별화를 시도한다.
다음 편 예고
PSTA의 발상(18편)과 차별점(19편)을 모두 봤다. 그런데 이 시리즈가 14개 도구의 강점을 정직하게 인정했듯, PSTA에도 같은 잣대를 들이대야 공정하다. 마지막 편(20편)에서는 PSTA의 장점만이 아니라 단점과 한계를 솔직하게 짚는다. PSTA가 안 맞는 경우, 풀지 못한 숙제, 신생 도구의 약점까지 — 그리고 21편에 걸친 이 긴 시리즈를 마무리한다.
이전 글: IT 프로젝트 관리 도구 완전 해부 – 18. PSTA의 발상 — Project·Service·Team·Action이라는 구조
다음 글: IT 프로젝트 관리 도구 완전 해부 – 20. PSTA의 장단점과 한계 — 그리고 시리즈를 마치며
