시리즈 안내
이 글은 “IT 프로젝트 관리 도구 완전 해부” 시리즈의 마지막 20편입니다. 18·19편에서 PSTA의 발상과 차별점을 소개했습니다. 이번 편에서는 그 PSTA에도 14개 도구에 들이댄 것과 똑같은 잣대를 들이대, 장점만이 아니라 단점과 한계를 솔직하게 짚습니다. 그리고 직접 써볼 수 있는 곳을 안내하며, 21편에 걸친 이 긴 여정을 마무리합니다.
들어가며
이 시리즈는 처음부터 한 가지를 약속했다. “특정 도구를 깎아내려 다른 것을 띄우지 않겠다”고. 그 약속은 PSTA에도 똑같이 적용된다. 앞의 두 편이 PSTA의 강점을 말했다면, 이번 편은 그 약점을 말한다. 자기 도구의 한계를 인정하지 않는 소개는 광고일 뿐이고, 이 시리즈는 광고로 끝나고 싶지 않다.
그리고 한 가지 더. PSTA는 더 이상 글 속의 발상만이 아니다. 실제로 돌아가는 데모가 있고, 공개된 소스가 있다. 그래서 이번 편은 PSTA를 정직하게 평가한 뒤, 당신이 직접 확인할 수 있는 곳으로 안내하는 것으로 끝맺는다. 읽고 판단하지 말고, 들어가서 만져보길 바라는 마음에서다.
1. PSTA의 장점 — 무엇을 풀었나
먼저 PSTA가 분명히 풀어낸 것을 정리한다.
가장 큰 장점은 입력과 보고의 통합이다. 팀원이 자기 Action을 완료로 바꾸면 그게 곧 전사 진행률이 된다. 16편 채점표에서 14개 도구 모두 비어 있던 ‘입력의 단일성’을, PSTA는 구조적으로 채운다. 이게 PSTA의 존재 이유이자 가장 선명한 기여다.
둘째는 화면 이분에 따른 단순함이다. 팀원은 자기 Action만 본다. Jira의 복잡함도, Notion의 빈 캔버스도 마주하지 않는다. “팀원이 매일 켜고 싶은가”라는 이 시리즈의 핵심 잣대를, 팀원 화면을 극단적으로 단순화함으로써 정조준한다.
셋째는 마찰을 더는 차별점들이다. 산출물을 연결하고(만들지 않고), 링크로 공유하고(보고서 없이), 회사 시스템에 얹는다(조직 재설정 없이). 기능을 더하는 대신 마찰을 덜어내는 방향이 일관된다.
2. PSTA의 단점 — 무엇이 약한가
이제 냉정하게 약점을 본다.
첫째, 4계층이 안 맞는 프로젝트가 있다. Project-Service-Team-Action은 어느 정도 규모가 있고, 여러 팀이 여러 서비스를 나눠 맡는 구조에 잘 맞는다. 그런데 1인 개발자나 두세 명짜리 팀에게는 이 4계층이 오히려 과하다. Service와 Team을 굳이 나눌 필요가 없는 작은 일에는, Trello 같은 평면 칸반이 더 가볍고 적합하다. 모든 구조는 특정 규모를 전제하며, PSTA도 예외가 아니다.
둘째, 자동 집계는 ‘정직한 입력’을 전제한다. 팀원이 Action 상태를 제때 바꿔야 진행률이 정확하다. 만약 팀원이 일은 다 해놓고 상태를 안 바꾸면, 자동 집계는 틀린 그림을 그린다. PSTA는 입력 부담을 줄였지만 0으로 만들지는 못했다 — 최소한의 상태 변경은 여전히 사람의 몫이다. “팀원이 안 쓰는 문제”를 구조로 완화했을 뿐, 완전히 없앤 건 아니다.
셋째, N:M 구조의 양날. 한 팀이 여러 서비스에 걸치는 N:M은 현실적이지만, 동시에 복잡하다. 잘못 설계하면 “이 Action이 어느 Service 소속인지” 헷갈리고, 관리 화면이 거미줄처럼 얽힐 수 있다. 현실을 담은 대가로 단순함을 일부 내준다.
넷째, 산출물 허브는 외부 의존이다. 문서를 직접 만들지 않고 Notion·구글 문서를 연결하는 방식은 가볍지만, 그 외부 서비스가 없으면 반쪽이 된다. 외부 도구를 안 쓰는 조직, 모든 걸 한 곳에 두고 싶은 조직에는 오히려 불편할 수 있다. 연결의 가벼움과 통합의 완결성은 맞바꾼 관계다.
3. PSTA의 한계 — 신생 1인 프로젝트라는 숙명
설계상의 단점과 별개로, PSTA에는 더 본질적인 한계가 있다. 아직 신생이고, 한 사람이 만든 프로젝트라는 점이다.
12편에서 Redmine의 강점으로 “20년간 검증된 안정성”을 꼽았다. PSTA에는 그게 없다. 공개된 저장소는 GitHub 스타 한 개 남짓한, 이제 막 세상에 나온 1인 개발 프로젝트다. Jira의 마켓플레이스 수천 개 부가기능, Linear의 오랜 시간이 다듬은 디테일, 대규모 도입 레퍼런스 — 이런 건 시간과 조직이 만든 것이고, 신생 1인 프로젝트가 단번에 가질 수 없다.
또 하나. 이 시리즈는 PSTA의 설계 의도를 다뤘지, 그 의도가 실제로 구현됐을 때 얼마나 매끄러운지는 별개 문제다. 좋은 발상도 구현이 거칠면 사람을 떠나게 만든다 — 이건 1편에서 “이론은 옳아도 도구가 옳다는 보장은 없다”고 한 그 말이, PSTA 자신에게도 돌아오는 부분이다.
다만 이 한계는 뒤집으면 다른 얼굴이 된다. 검증이 부족하다는 건, 지금 남기는 피드백 하나가 제품의 방향을 실제로 바꿀 수 있다는 뜻이기도 하다. 거대한 도구에 의견을 보내면 수천 번째 요청으로 묻히지만, 이제 막 시작한 도구에서는 그 의견이 다음 버전에 반영될 수 있다. 뒤에서 안내할 데모와 게시판은 바로 그 가능성을 위한 것이다.
4. 그래서 PSTA는 무엇인가
정직하게 정리하면 이렇다. PSTA는 모든 팀을 위한 만능 도구가 아니다. 1인 팀에는 과하고, 외부 도구를 안 쓰는 조직엔 안 맞고, 신생이라 검증이 부족하다.
그러나 PSTA는 하나의 분명한 질문에 대한 하나의 분명한 답이다. “팀원이 자기 일을 하는 것이 곧 관리자의 현황이 되게 하려면 어떤 구조여야 하나” — 17편에서 뒤집은 그 질문에, PSTA는 4계층과 자동 흐름으로 답한다. 그 답이 완벽하진 않아도, 적어도 14개 도구가 묻지 않았던 질문을 정면으로 묻는다는 점에서, 한 번 들여다볼 가치가 있다.
짚고 가기: PSTA의 가장 정직한 한 줄 평 — “여러 팀이 협업하는 중간 규모 이상의 프로젝트에서, 팀원의 참여를 끌어내고 PM의 취합을 없애고 싶은 조직에 맞다. 단, 작은 팀에는 과하고, 신생이라 검증은 진행 중이다.” 14개 도구에 들이댄 잣대를, PSTA에도 똑같이.
5. 직접 확인하고 써보기
여기까지 읽고 PSTA가 궁금해졌다면, 글로만 끝낼 이유가 없다. PSTA는 실제로 돌아가는 데모와 공개된 소스 저장소가 있다. 18·19편에서 글로 읽은 발상이 실제 화면에서 어떻게 작동하는지, 직접 클릭해보는 편이 백 마디 설명보다 빠르다.
데모로 둘러보기 — psta.app
데모 사이트: psta.app
이 글에서 설명한 구조를 실제 화면으로 확인할 수 있도록, 데모 환경에 팀과 팀원을 미리 구성해 두었다. 개발팀과 기획팀을 만들고, 각 팀에 PO·PM·일반 멤버 역할을 배치해 두었다. 그래서 18편에서 설명한 “PM은 전체를, 팀원은 자기 Action만”이라는 화면 분리가, 어떤 역할로 보느냐에 따라 실제로 어떻게 달라지는지 눈으로 확인할 수 있다.
좌측 메뉴를 보면 이 시리즈의 핵심 구조가 그대로 들어 있다. 데이터 관리 영역의 프로젝트(P) · 서비스(S) · 팀별 현황(T) · 액션(A) — PSTA라는 이름 그 자체다. 여기에 일정관리(WBS Gantt), 조직도, 통합 파일 관리, 알림앱 연동, 권한 관리 같은 메뉴가 더해져 있다. 18·19편에서 글로 읽은 발상이 실제 메뉴 구조로 어떻게 구현됐는지 비교하며 둘러보면 좋다.
막히면, 게시판에 직접 남기면 된다
데모를 둘러보다 막히거나, 버그를 발견하거나, “이런 기능이 있으면 좋겠다” 싶은 게 생기면 그냥 넘기지 말기를 바란다. 데모 안에는 버그/건의 게시판이 있다. 거기에 버그 제보든 기능 제안이든 자유롭게 남기면 된다.
특히 이런 요청도 환영한다 — “우리 팀처럼 ○○팀과 팀원을 추가해서 테스트해보고 싶다”거나 “이 역할로 로그인해서 화면을 보고 싶다” 같은 요청. 버그/건의 게시판에 남겨주면, 데모 환경에 팀과 팀원을 추가해 직접 체험할 수 있도록 돕겠다. 3절에서 말한 “신생 도구라 피드백이 방향을 바꾼다”는 게 빈말이 아니다 — 읽기만 하는 글이 아니라, 만든 사람과 주고받을 수 있는 살아 있는 데모로 쓰였으면 한다.
소스를 직접 보고 설치하기 — GitHub
소스 저장소: github.com/GUNIQ-G/psta
PSTA는 소스가 공개돼 있다. 구조가 궁금한 개발자라면 저장소를 직접 뜯어볼 수 있고, 자체 서버에 설치해 써볼 수도 있다. Ubuntu 환경이라면 README의 한 줄 설치 스크립트로 비교적 간단히 올릴 수 있고(요구사항: Ubuntu 22.04 LTS, RAM 4GB+), 설치 후 브라우저에서 웹 설치 마법사로 초기 설정을 마친다. 기술 스택은 React 18 + Ant Design(프론트엔드), Node.js + Express + Prisma(백엔드), PostgreSQL이며, Slack·Telegram·Discord 알림과 LDAP 연동, Excel Import/Export 등 19편에서 언급한 조직 연동 기능이 실제로 들어 있다.
라이선스는 정확히 알고 쓰자 — ‘소스 공개’와 ‘오픈소스’는 다르다
여기서 한 가지를 분명히 짚고 넘어가야 한다. 이 시리즈는 3막에서 Redmine·Taiga 같은 진짜 오픈소스를 깐깐하게 평가했다. 그러니 PSTA에도 같은 정직함을 적용해야 공정하다. PSTA는 소스가 공개돼 있지만, 그 오픈소스들과는 라이선스 성격이 다르다.
PSTA는 MIT나 GPL 같은 표준 오픈소스 라이선스가 아니라, 자체적인 “PSTA Source Available License v1.0”(소스 공개 라이선스)을 쓴다. 소스를 볼 수 있다(source-available)는 점은 오픈소스와 같지만, 누구나 자유롭게 상업적으로 이용할 수 있는 오픈소스(open-source)와는 구분된다. 이 차이를 뭉뚱그리면 안 된다.
요지는 간단하다.
- 무료로 쓸 수 있는 경우: 개인 사용(학습·연구), 기업·기관의 사내 내부 업무용 자체 설치, 비영리 단체의 내부 사용. 저작권·라이선스 고지를 사본에 포함하는 조건이다.
- 별도 계약이 필요한 경우: 재판매, 이 소프트웨어 기반의 SaaS(구독·과금) 서비스 운영, 고객에게 설치·구축해주고 대가를 받는 SI 사업, 다른 상용 제품에 포함하는 OEM·번들.
쉽게 말해, 우리 회사가 우리 일을 관리하려고 우리 서버에 깔아 쓰는 건 무료다. 반면 이걸 가지고 남에게 팔거나 서비스로 돈을 받으려면 별도 라이선스 문의(gunique.co.kr@gmail.com)가 필요하다. 3막에서 “오픈소스는 1인당 과금이 없다”고 했던 그 자유와는 결이 다르니, 도입을 검토한다면 이 차이를 정확히 알고 시작하는 게 좋다. 자세한 조건은 저장소의 LICENSE 문서에서 직접 확인할 수 있다.
이 라이선스 선택 자체가 PSTA가 어떤 도구인지 말해준다. 완전한 오픈소스로 모든 걸 내주지도 않고, 소스를 닫아건 상용도 아닌, 그 사이의 길이다. 내부에서 쓰는 조직에는 열어주되 상업화는 만든 사람과 상의하자는 — 1인 제작자가 자기 작업물을 지속 가능하게 가져가려는 현실적인 선택이다.
6. 시리즈를 마치며
0편에서 우리는 익숙한 풍경 하나로 시작했다. 멈춰 있는 보드, “그거 따로 메신저로 공유했어요”라는 답. 그리고 물었다 — 왜 좋다는 도구를 정작 팀원들은 안 쓰는가?
21편에 걸쳐 우리는 그 답을 추적했다.
- 1막에서 이론의 계보와 IT 프로젝트의 특수성으로 잣대를 세웠고,
- 2막에서 상용 10개(Jira·ClickUp·monday·Asana·Notion·Linear·Trello·국산)를,
- 3막에서 오픈소스 4개(Redmine·OpenProject·Taiga·Plane)를 같은 다섯 잣대로 해부했으며,
- 4막에서 그 공통 실패를 “관리자를 위한 그릇에 팀원의 입력을 떠넘긴 구조”로 진단하고, 그 대안으로 PSTA를 제시하고 그 한계까지 짚었다.
긴 여정의 결론은 의외로 단순하다. 좋은 도구가 안 쓰이는 건 팀원이 게을러서가 아니라, 도구가 팀원이 아니라 관리자를 위해 설계됐기 때문이다. 답은 더 나은 기능이 아니라, 출발점이 반대인 구조다.
이 시리즈가 전하고 싶었던 것
도구를 하나하나 평가하는 것보다 중요했던 건, 평가의 잣대였다. “이 도구가 화려한가”가 아니라 “팀원이 정말 쓰는가, 입력이 단일한가”를 묻는 시선. 어떤 도구를 고르든, 이 질문을 들고 있으면 광고에 휘둘리지 않고 자기 팀에 맞는 선택을 할 수 있다. PSTA를 택하든 안 택하든, 그 잣대만큼은 남기고 싶었다.
PSTA는 그 잣대를 들고 만든 하나의 답이다. 완성된 정답이 아니라, 14개 도구가 묻지 않은 질문에 한 사람이 내놓은 진행 중인 시도다. 그래서 더더욱, 평가받기보다 함께 다듬어지기를 바란다.
더 나아간다면
이 시리즈는 도구의 ‘구조’에 집중했다. 더 깊이 들어가고 싶다면 다음 주제들로 확장할 수 있다.
- 도입 변화관리: 좋은 도구도 도입 과정이 서툴면 실패한다. 팀의 습관을 바꾸는 법.
- AI와 프로젝트 관리: 상태 입력조차 AI가 대신한다면? 입력 부담의 다음 해법.
- 측정의 함정: 진행률·속도를 측정하면 그 숫자를 위한 일이 생긴다. 무엇을 측정해야 하는가.
- 원격·비동기 협업: 같은 공간에 없는 팀에게 프로젝트 관리란 무엇인가.
긴 시리즈를 끝까지 따라와 주셔서 감사하다. 부디 이 기록이, 당신의 팀이 ‘모두가 실제로 쓰는’ 프로젝트 관리에 한 걸음 다가가는 데 보탬이 되기를 바란다. 그리고 psta.app에서, 글로 읽은 그 발상을 직접 만져보고, 막히는 곳이 있다면 게시판에 한 줄 남겨주기를 바란다. 그 한 줄이 다음 버전을 만든다.
이전 글: IT 프로젝트 관리 도구 완전 해부 – 19. PSTA는 무엇이 다른가 — 자동 집계, 산출물 허브, 조직 연동
— 시리즈 완결 —
