시리즈 안내
이 글은 “IT 프로젝트 관리 도구 완전 해부” 시리즈의 18편입니다. 17편에서 14개 도구의 공통 실패를 “관리자를 위한 그릇에 팀원의 입력을 떠넘긴 구조”로 진단하고, 질문을 뒤집었습니다. 이번 편에서는 그 뒤집힌 질문에서 출발한 새로운 모델을 소개합니다. PSTA — Project·Service·Team·Action. 이름이 곧 구조인 이 도구의 발상을 풀어냅니다.
들어가며
지난 편에서 우리는 질문을 뒤집었다. “관리자가 보려면 팀원이 뭘 입력하게 할까”가 아니라, “팀원이 자기 일을 하는 것이 그 자체로 현황이 되려면 어떤 구조여야 하나”로.
PSTA는 바로 이 질문에서 시작한 모델이다. 먼저 분명히 해둘 것 — 이 시리즈는 14개의 기존 도구를 정직하게 평가했고, 그 강점을 인정했다. PSTA는 그 도구들이 “틀려서”가 아니라, “같은 방향에서 출발했기에 같은 한계에 닿았다”는 진단 위에 서 있다. 출발점을 바꾸면 다른 곳에 도착할 수 있다는 가설, 그것이 PSTA다.
1. 이름이 곧 구조다
PSTA는 네 글자가 그대로 데이터 모델이다.
Project(프로젝트) → Service(서비스) → Team(팀) → Action(액션)가장 큰 단위인 Project가 목표를 담고, 그 아래 Service가 프로젝트 안에서 관리할 업무 영역·서비스 묶음을 나눈다. Team은 그 일을 수행하는 조직이고, 가장 작은 실행 단위가 Action이다. 1편에서 본 WBS의 “큰 일을 작은 실행 단위로 분해”하는 사고가 이름 자체에 박혀 있다.
기존 도구들이 ‘에픽-스토리-이슈'(Jira)나 ‘보드-리스트-카드'(Trello)처럼 임의의 이름을 쓴 것과 달리, PSTA는 분해의 단계를 이름으로 못박았다. 청중이 “PSTA가 무슨 뜻이지?”라고 묻는 순간, 답이 곧 제품의 구조가 된다.
2. 핵심 발상: “PM은 전체를, 팀원은 내 Action만”
PSTA의 가장 중요한 원칙은 이것이다. 화면을 둘로 나눈다.
PM·PO는 Project 전체 그림 — 모든 Service, 모든 Team, 진행률을 본다. 17편에서 말한 ‘관리자의 가시성’이다. 그런데 팀원은 그 복잡한 전체를 볼 필요가 없다. 팀원에게 보이는 건 오직 자신에게 배정된 Action뿐이다.
이 분리가 17편에서 진단한 ‘실패 둘(도구가 관리자를 위해 설계됨)’과 ‘실패 셋(강력함과 단순함의 양립 불가)’을 동시에 겨눈다. 관리자에겐 충분히 강력한 전체 뷰를, 팀원에겐 “오늘 내 Action 세 개”라는 극단적 단순함을 — 한 도구가 두 얼굴로 제공한다. 팀원은 Jira의 복잡함도, Notion의 빈 캔버스도 마주하지 않는다. 그저 자기 Action만 본다.
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번 원칙).
5. 발상의 요약
정리하면 PSTA의 발상은 세 기둥으로 선다.
첫째, 이름이 곧 구조다(Project-Service-Team-Action). 둘째, 화면을 둘로 나눈다 — PM은 전체, 팀원은 내 Action만. 셋째, 팀원의 입력이 위로 자동으로 흐른다 — 입력과 보고가 하나가 된다.
세 기둥 모두 17편에서 진단한 세 실패를 하나씩 겨냥한다. 기존 도구가 “관리자에서 시작해 팀원에게 입력을 떠넘기는” 방향이었다면, PSTA는 “팀원에서 시작해 관리자로 자동으로 흐르는” 반대 방향을 택했다. 이것이 출발점을 바꾼다는 말의 구체적 의미다.
짚고 가기: PSTA의 핵심은 화려한 기능이 아니라 ‘방향’이다. 팀원이 자기 Action 하나를 완료로 바꾸면, 그게 곧 Project 진행률이 된다. 팀원은 보고하지 않았는데 보고가 됐고, 관리자는 취합하지 않았는데 현황을 본다. 입력과 보고 사이의 그 지긋지긋한 이중 노동이, 구조적으로 사라진다.
다음 편 예고
PSTA의 기본 발상 — 4계층 구조와 자동 흐름 — 을 봤다. 다음 편(19부)에서는 PSTA가 이 구조 위에 더한 구체적 차별점들을 다룬다. 진행률 자동 집계를 넘어, 산출물을 작업에 연결하는 방식, 계정 없는 외부 공유, 회사 시스템과의 연동까지 — 기존 도구가 놓친 지점들을 PSTA가 어떻게 메우는지 살펴본다.
이전 글: IT 프로젝트 관리 도구 완전 해부 – 17. 왜 결국 아무도 안 쓰는가 — 14개 도구가 알려준 공통 실패
다음 글: IT 프로젝트 관리 도구 완전 해부 – 19. PSTA는 무엇이 다른가 — 자동 집계, 산출물 허브, 조직 연동
