시리즈 안내
이 글은 “IT 프로젝트 관리 도구 완전 해부” 시리즈의 마지막 20편입니다. 18·19편에서 PSTA의 발상과 차별점을 소개했어요. 이번 편에서는 그 PSTA에도 14개 도구에 들이댔던 것과 똑같은 잣대를 들이대서, 장점만이 아니라 단점과 한계까지 솔직하게 짚어 봅니다. 그리고 직접 써볼 수 있는 곳을 안내하면서, 21편에 걸친 이 긴 여정을 마무리할게요.
들어가며
이 시리즈는 처음부터 한 가지를 약속했습니다. “특정 도구를 깎아내려 다른 것을 띄우지 않겠다”고요. 그 약속은 PSTA에도 똑같이 적용됩니다. 앞의 두 편이 PSTA의 강점을 말했다면, 이번 편은 그 약점을 말합니다. 자기 도구의 한계를 인정하지 않는 소개는 광고일 뿐이고, 이 시리즈는 광고로 끝나고 싶지 않거든요.
그리고 한 가지 더. PSTA는 더 이상 글 속의 발상만이 아닙니다. 실제로 돌아가는 데모가 있고, 공개된 소스가 있어요. 그래서 이번 편은 PSTA를 정직하게 평가한 뒤, 여러분이 직접 확인할 수 있는 곳으로 안내하는 것으로 끝맺으려 합니다. 읽고 판단만 하지 말고, 들어가서 직접 만져보셨으면 하는 마음에서예요. PM·PO로 커리어를 전환하려는 분이라면, 도구 하나를 이렇게 끝까지 뜯어본 경험 자체가 면접에서 들려줄 좋은 이야깃거리가 됩니다.
1. PSTA의 장점 — 무엇을 풀었나
먼저 PSTA가 분명히 풀어낸 것을 정리해 볼게요.
가장 큰 장점은 입력과 보고의 통합입니다. 팀원이 자기 Action을 완료로 바꾸면 그게 곧 전사 진행률이 됩니다. 16편 채점표에서 14개 도구 모두 비어 있던 ‘입력의 단일성’을, PSTA는 구조적으로 채워요. 이게 PSTA의 존재 이유이자 가장 선명한 기여입니다. PM·PO 입장에서 보면, 진행 상황을 취합하느라 사람마다 메신저로 물어보던 일이 사라진다는 뜻이죠.
둘째는 화면 이분에 따른 단순함입니다. 팀원은 자기 Action만 봅니다. Jira의 복잡함도, Notion의 빈 캔버스도 마주하지 않아요. “팀원이 매일 켜고 싶은가”라는 이 시리즈의 핵심 잣대를, 팀원 화면을 극단적으로 단순화함으로써 정조준합니다.
셋째는 마찰을 더는 차별점들입니다. 산출물을 연결하고(만들지 않고), 링크로 공유하고(보고서 없이), 회사 시스템에 얹습니다(조직 재설정 없이). 기능을 더하는 대신 마찰을 덜어내는 방향이 일관돼요.
2. PSTA의 단점 — 무엇이 약한가
이제 냉정하게 약점을 봅니다.
첫째, 4계층이 안 맞는 프로젝트가 있습니다. Project-Service-Team-Action은 어느 정도 규모가 있고, 여러 팀이 여러 서비스를 나눠 맡는 구조에 잘 맞습니다. 그런데 1인 개발자나 두세 명짜리 팀에게는 이 4계층이 오히려 과해요. Service와 Team을 굳이 나눌 필요가 없는 작은 일에는, Trello 같은 평면 칸반이 더 가볍고 적합합니다. 모든 구조는 특정 규모를 전제하며, PSTA도 예외가 아니에요.
둘째, 자동 집계는 ‘정직한 입력’을 전제합니다. 팀원이 Action 상태를 제때 바꿔야 진행률이 정확합니다. 만약 팀원이 일은 다 해놓고 상태를 안 바꾸면, 자동 집계는 틀린 그림을 그려요. PSTA는 입력 부담을 줄였지만 0으로 만들지는 못했습니다 — 최소한의 상태 변경은 여전히 사람의 몫이거든요. “팀원이 안 쓰는 문제”를 구조로 완화했을 뿐, 완전히 없앤 건 아닙니다. PM·PO가 입력을 강제하기보다 왜 입력이 필요한지 합의시키는 일이 여전히 남는 셈이죠.
셋째, 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만”이라는 화면 분리가, 어떤 역할로 보느냐에 따라 실제로 어떻게 달라지는지 눈으로 확인할 수 있습니다. PM·PO를 준비한다면 역할별로 번갈아 로그인해 보면서, 같은 데이터가 권한에 따라 어떻게 다르게 보이는지 비교해 보세요.
좌측 메뉴를 보면 이 시리즈의 핵심 구조가 그대로 들어 있습니다. 데이터 관리 영역의 프로젝트(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 문서에서 직접 확인할 수 있어요. 참고로 이 ‘소스 공개 vs 오픈소스’의 차이는 실무에서도 자주 헷갈리는 주제라, 정확히 구분해 두면 두고두고 도움이 됩니다.
이 라이선스 선택 자체가 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를 택하든 안 택하든, 그 잣대만큼은 남기고 싶었어요. PM·PO 면접에서 “왜 이 도구를 선택했나요”라는 질문에, 바로 이 잣대로 답할 수 있다면 그 자체가 강력한 무기가 됩니다.
PSTA는 그 잣대를 들고 만든 하나의 답입니다. 완성된 정답이 아니라, 14개 도구가 묻지 않은 질문에 한 사람이 내놓은 진행 중인 시도예요. 그래서 더더욱, 평가받기보다 함께 다듬어지기를 바랍니다.
더 나아간다면
이 시리즈는 도구의 ‘구조’에 집중했습니다. 더 깊이 들어가고 싶다면 다음 주제들로 확장할 수 있어요.
- 도입 변화관리: 좋은 도구도 도입 과정이 서툴면 실패합니다. 팀의 습관을 바꾸는 법.
- AI와 프로젝트 관리: 상태 입력조차 AI가 대신한다면? 입력 부담의 다음 해법.
- 측정의 함정: 진행률·속도를 측정하면 그 숫자를 위한 일이 생깁니다. 무엇을 측정해야 하는가.
- 원격·비동기 협업: 같은 공간에 없는 팀에게 프로젝트 관리란 무엇인가.
긴 시리즈를 끝까지 따라와 주셔서 정말 감사합니다. 부디 이 기록이, 여러분의 팀이 ‘모두가 실제로 쓰는’ 프로젝트 관리에 한 걸음 다가가는 데 보탬이 되기를 바라요. 도구 선택이든 PM·PO 커리어 준비든 혼자 고민이 깊어질 때는, 누스쿨 커뮤니티에서 같은 길을 걷는 동료들과 이 시리즈의 잣대를 함께 나눠 보세요. 그리고 psta.app에서, 글로 읽은 그 발상을 직접 만져보고, 막히는 곳이 있다면 게시판에 한 줄 남겨주세요. 그 한 줄이 다음 버전을 만듭니다.
이전 글: IT 프로젝트 관리 도구 완전 해부 – 19. PSTA는 무엇이 다른가 — 자동 집계, 산출물 허브, 조직 연동
💬 댓글 0