시리즈 안내
이 글은 “IT 프로젝트 관리 도구 완전 해부” 시리즈의 18편입니다. 17편에서는 14개 도구의 공통 실패를 “관리자를 위한 그릇에 팀원의 입력을 떠넘긴 구조”로 진단하고, 질문을 뒤집어 봤어요. 이번 편에서는 그 뒤집힌 질문에서 출발한 새로운 모델을 소개합니다. PSTA — Project·Service·Team·Action. 이름이 곧 구조인 이 접근의 발상을 함께 풀어 볼게요.
들어가며
지난 편에서 우리는 질문을 뒤집었습니다. “관리자가 보려면 팀원이 뭘 입력하게 할까”가 아니라, “팀원이 자기 일을 하는 것이 그 자체로 현황이 되려면 어떤 구조여야 할까”로요. PM·PO를 준비하는 분이라면, 이 질문 하나가 도구 선택의 기준을 통째로 바꾼다는 걸 곧 느끼게 될 거예요.
PSTA는 바로 이 질문에서 시작한 모델입니다. 먼저 분명히 해둘 게 있어요. 이 시리즈는 14개의 기존 도구를 정직하게 평가했고, 그 강점도 충분히 인정했습니다. PSTA는 그 도구들이 “틀려서”가 아니라, “같은 방향에서 출발했기에 같은 한계에 닿았다”는 진단 위에 서 있는 구조적 발상이에요. 출발점을 바꾸면 다른 곳에 도착할 수 있다는 가설, 그게 PSTA가 던지는 이야기입니다.
1. 이름이 곧 구조다
PSTA는 네 글자가 그대로 데이터 모델입니다.
Project(프로젝트) → Service(서비스) → Team(팀) → Action(액션)가장 큰 단위인 Project가 목표를 담고, 그 아래 Service가 프로젝트 안에서 관리할 업무 영역·서비스 묶음을 나눕니다. Team은 그 일을 수행하는 조직이고, 가장 작은 실행 단위가 Action이에요. 1편에서 봤던 WBS의 “큰 일을 작은 실행 단위로 분해”하는 사고가 이름 자체에 박혀 있는 셈이죠.
기존 도구들이 ‘에픽-스토리-이슈'(Jira)나 ‘보드-리스트-카드'(Trello)처럼 임의의 이름을 쓴 것과 달리, PSTA는 분해의 단계를 이름으로 못박았습니다. 누군가 “PSTA가 무슨 뜻이죠?”라고 묻는 순간, 그 답이 곧 구조 설명이 되는 거예요. PM·PO 면접에서도 이렇게 “이름과 구조가 일치하는 모델”은 설명하기 쉽고 팀에 공유하기도 좋다는 점을, 한 번쯤 떠올려 두면 좋습니다.
2. 핵심 발상: “PM은 전체를, 팀원은 내 Action만”
PSTA의 가장 중요한 원칙은 이것입니다. 화면을 둘로 나눕니다.
PM·PO는 Project 전체 그림 — 모든 Service, 모든 Team, 진행률을 봅니다. 17편에서 말한 ‘관리자의 가시성’이죠. 그런데 팀원은 그 복잡한 전체를 볼 필요가 없어요. 팀원에게 보이는 건 오직 자신에게 배정된 Action뿐입니다.
이 분리가 17편에서 진단한 ‘실패 둘(도구가 관리자를 위해 설계됨)’과 ‘실패 셋(강력함과 단순함의 양립 불가)’을 동시에 겨눕니다. 관리자에겐 충분히 강력한 전체 뷰를, 팀원에겐 “오늘 내 Action 세 개”라는 극단적 단순함을 — 한 도구가 두 얼굴로 제공하는 거예요. 팀원은 Jira의 복잡함도, Notion의 빈 캔버스도 마주하지 않습니다. 그저 자기 Action만 봅니다. PM 입장에서 보면, ‘도구 도입 후에도 팀원이 입력을 안 한다’는 그 단골 고민을 구조로 푸는 방식인 셈이죠.
3. Action이 모든 것의 중심이다
PSTA에서 가장 중요한 사용 단위는 Action입니다. 필드는 최소화돼 있어요 — 이름, 유형, 시작·종료일, 담당자, 상태. 그게 거의 전부입니다.
왜 이렇게 단순할까요? 17편의 ‘실패 하나(입력이 곧 보고)’를 줄이기 위해서입니다. 팀원이 채워야 할 게 적을수록, 입력은 ‘보고’가 아니라 ‘내 일의 자연스러운 기록’에 가까워져요. 팀원은 복잡한 양식을 채우는 게 아니라, 자기 Action의 상태를 “진행 중 → 완료”로 바꾸기만 하면 됩니다.
그리고 여기에 PSTA의 결정적 발상이 연결됩니다. 팀원이 자기 Action 상태를 바꾸는 그 행위가, 위로 자동으로 흐릅니다. Action이 완료되면 그것이 속한 Team의 진행률이, 다시 Service가, 다시 Project 전체의 진행률이 자동으로 갱신돼요. PM이 따로 취합하지 않습니다. 팀원은 자기 일만 했는데, 관리자의 현황이 저절로 채워지는 거죠.
이것이 17편에서 뒤집은 질문에 대한 PSTA의 답입니다. 입력과 보고가 분리되지 않습니다. 팀원의 한 번의 상태 변경이, 곧 전사 진행률이 됩니다. 16편 채점표에서 14개 도구 모두 비어 있던 그 열 — ‘입력의 단일성’ — 을 정조준한 설계예요.
4. N:M이라는 현실적 구조
한 가지 더 있습니다. PSTA의 Service와 Team은 N:M 관계예요. 한 팀이 여러 프로젝트·여러 서비스에 걸칠 수 있고, 한 프로젝트의 서비스는 여러 팀과 협업합니다.
이건 단순한 트리(한 부모-여러 자식)보다 복잡하지만, 실제 조직이 일하는 방식에 가깝습니다. 현실에서 디자인팀 하나가 여러 프로젝트에 동시에 투입되고, 한 서비스를 개발·디자인·기획팀이 함께 만들죠. PSTA는 이 현실을 구조에 담았어요. 다만 이 N:M이 팀원 화면까지 복잡하게 만들지는 않습니다 — 팀원은 여전히 자기 Action만 보면 되니까요(2번 원칙). 실무에서 리소스가 여러 프로젝트에 겹쳐 배정되는 상황을 도구가 어떻게 표현하는지는, PM·PO가 도구를 고를 때 꼭 확인하는 포인트이기도 합니다.
5. 발상의 요약
정리하면 PSTA의 발상은 세 기둥으로 섭니다.
첫째, 이름이 곧 구조입니다(Project-Service-Team-Action). 둘째, 화면을 둘로 나눕니다 — PM은 전체, 팀원은 내 Action만. 셋째, 팀원의 입력이 위로 자동으로 흐릅니다 — 입력과 보고가 하나가 됩니다.
세 기둥 모두 17편에서 진단한 세 실패를 하나씩 겨냥해요. 기존 도구가 “관리자에서 시작해 팀원에게 입력을 떠넘기는” 방향이었다면, PSTA는 “팀원에서 시작해 관리자로 자동으로 흐르는” 반대 방향을 택했습니다. 이것이 출발점을 바꾼다는 말의 구체적 의미예요.
짚고 가기: PSTA의 핵심은 화려한 기능이 아니라 ‘방향’입니다. 팀원이 자기 Action 하나를 완료로 바꾸면, 그게 곧 Project 진행률이 됩니다. 팀원은 보고하지 않았는데 보고가 됐고, 관리자는 취합하지 않았는데 현황을 봅니다. 입력과 보고 사이의 그 지긋지긋한 이중 노동이, 구조적으로 사라지는 거예요.
다음 편 예고
PSTA의 기본 발상 — 4계층 구조와 자동 흐름 — 을 함께 봤습니다. 다음 편(19부)에서는 PSTA가 이 구조 위에 더한 구체적 차별점들을 다뤄요. 진행률 자동 집계를 넘어, 산출물을 작업에 연결하는 방식, 계정 없는 외부 공유, 회사 시스템과의 연동까지 — 기존 도구가 놓친 지점들을 어떻게 메우는지 살펴보겠습니다. 도구를 평가하는 이 시선 자체가, PM·PO로 일하거나 면접을 볼 때 그대로 무기가 됩니다.
여러분의 팀은 지금 어떤 도구를 쓰고 있고, 어디서 입력과 보고의 이중 노동을 겪고 있나요? 누스쿨 커뮤니티에 경험을 나눠 주시면, 같은 고민을 하는 PM·PO 동료들과 함께 답을 찾아갈 수 있어요.
이전 글: IT 프로젝트 관리 도구 완전 해부 – 17. 왜 결국 아무도 안 쓰는가 — 14개 도구가 알려준 공통 실패
다음 글: IT 프로젝트 관리 도구 완전 해부 – 19. PSTA는 무엇이 다른가 — 자동 집계, 산출물 허브, 조직 연동
💬 댓글 0