토스가 정의하는 TPM(Technical Program Manager)은 일정과 리스크를 관리하는 전통적 조율자를 넘어, 여러 팀 사이에 방치된 구조적 문제를 발견하고 해결하는 **전략 실행자**다. 특히 AI 도입으로 기술·조직·운영의 의존성이 복잡해질수록, 공식 Owner가 없는 회색지대를 구조화하고 실행 가능한 상태로 만드는 역할이 중요해진다. TPM의 성과는 문서나 상태 보고가 아니라 병목 제거와 현실의 변화로 증명된다.
## 기존 TPM 정의의 한계
- 일반적인 TPM은 이미 정의된 기술 프로그램의 일정, 리스크, 의존성, 커뮤니케이션을 관리해 안정적인 전달을 돕는다.
- 그러나 조직이 커질수록 어려운 문제는 정식 프로그램이나 명확한 과제의 형태로 등장하지 않는다.
- 대표적인 문제는 다음과 같다.
- 여러 팀이 관련되어 있지만 최종 책임자가 없는 문제
- 전략은 존재하지만 실행 구조가 없는 문제
- 상태 공유는 계속되지만 실제 상황은 바뀌지 않는 문제
- 제품·기술 전략·조직 설계·운영 방식이 복합적으로 얽힌 문제
- 이런 상황에서는 일정 관리나 이해관계자 조율만으로 문제를 해결하기 어렵다.
## PO·EM·전통적 TPM과의 차이
- **PO(Product Owner)**는 사용자와 비즈니스 관점에서 무엇을 만들고 어떤 우선순위를 둘지 정의한다.
- **EM/SDM**은 사람, 기술 품질, 팀 운영과 조직 건강을 관리해 특정 팀이 꾸준히 실행할 기반을 만든다.
- **전통적 TPM 또는 Technical Project Manager**는 정해진 목표를 일정 안에 전달하도록 계획과 리스크를 관리한다.
- **토스식 TPM**은 이 역할들을 대체하지 않고, 역할 사이와 조직 경계 밖에 남은 문제를 담당한다.
- 제품 방향은 있지만 여러 조직을 움직일 실행 구조가 없을 때
- 각 팀은 제 역할을 하지만 전체 관점의 Owner가 없을 때
- 리더십이 중요성을 인식해도 기존 구조에서는 우선순위를 만들기 어려울 때
- 따라서 이미 정의된 업무를 관리하기보다, 정의되지 않은 중요한 문제를 해결 가능한 형태로 바꾸는 데 초점을 둔다.
## 성숙한 조직에서 커지는 회색지대
- 조직이 성숙하면 각 팀의 책임과 목표가 선명해지고 실행 속도도 빨라진다.
- 반면 명확한 조직 경계 때문에 어느 팀에도 완전히 속하지 않는 문제가 방치될 수 있다.
- 이러한 문제는 여러 조직에 조금씩 걸쳐 있거나, 당장은 긴급하지 않지만 미래를 위해 해결해야 하거나, 개별 팀의 로컬 최적화로는 풀리지 않는 경우가 많다.
- AI 시대에는 모델 도입, 데이터 거버넌스, 품질 기준, 보안, 개발 생산성, 업무 방식이 동시에 얽히면서 이런 현상이 심화된다.
- 높은 자율성과 실행력을 가진 조직일수록 팀 간 경계를 전담해 다룰 역할이 필요하다.
## 토스식 TPM이 다루는 문제
- 중요한데 공식 Owner가 없다.
- 여러 팀과 직무가 동시에 연관되어 있다.
- 전략·기술·운영·사람 문제가 섞여 있다.
- 진행 상황은 자주 공유되지만 실질적인 전환은 일어나지 않는다.
- 기존 역할 하나의 권한과 책임만으로는 끝까지 해결하기 어렵다.
- TPM은 표면적인 현상만 추적하지 않고 다음을 수행한다.
- 진짜 문제와 단순 증상을 구분한다.
- 빠진 이해관계자와 필요한 의사결정을 드러낸다.
- 권한과 책임 구조를 설계한다.
- 결과가 만들어질 때까지 실행에 개입한다.
## 문제 발견부터 현실 변화까지의 역할
- **문제를 선제적으로 발견한다**
- 누군가 정리한 업무를 기다리지 않고 반복되는 병목, 책임의 공백, 이름 붙지 않은 중요 문제를 찾는다.
- **전략을 실행 구조로 전환한다**
- 어떤 팀이 어떤 순서로 움직일지, 무엇을 포기할지, 누가 DRI(최종 책임자)가 될지 구체화한다.
- **팀 사이에서 실행을 설계한다**
- 서로 다른 조직의 목적·속도·제약을 연결하고 공동 문제를 풀 수 있는 협업 구조를 만든다.
- **블로커를 보고하는 데서 그치지 않는다**
- 필요하면 의사결정 구조, 우선순위, 참여자 구성과 협업 방식을 바꿔 실제 장애물을 제거한다.
- **사람과 조직 구조를 함께 본다**
- 필요한 리더십, 팀 구성, 권한 배치와 반복 가능한 운영 메커니즘을 함께 설계한다.
- **현실의 변화로 성과를 판단한다**
- 막힌 실행이 다시 움직이고 반복 병목이 줄어들며, 다음에는 같은 문제를 더 쉽게 해결할 수 있어야 한다.
- 문서와 회의, 조율은 수단이며 TPM의 정체성은 문제 해결에 있다.
## 강한 TPM에게 필요한 역량
- **문제 구조화**
- 모호한 현상에서 본질과 증상을 구분하고, 관계자와 의사결정 병목을 빠르게 파악한다.
- 회의 후 내용을 정리하는 수준을 넘어 회의 전부터 문제의 프레임을 제시한다.
- **전략의 실행 전환**
- 필요한 작업 흐름, 개입 순서, 시점별 책임자를 설계해 방향성을 실제 행동으로 연결한다.
- **영향력과 동원 능력**
- 공식 권한에 의존하지 않고 신뢰와 판단력으로 여러 팀을 움직인다.
- 조직마다 다른 언어를 번역하고, 불편한 대화를 열며, 합의가 느린 상황에서도 실행 기반을 만든다.
- **시스템 사고**
- 문제가 반복되면 개인의 노력보다 조직 구조와 운영 메커니즘을 점검한다.
- 영웅적인 개인의 희생 없이도 기본적으로 잘 작동하는 시스템을 만든다.
- **완결성**
- 문제 발견, 구조 설계, 관계자 동원, 실행, 결과 도출, 재발 방지까지 끝까지 책임진다.
- 업무량보다 어렵고 넓은 회색지대의 문제를 완결할 수 있는지가 중요하다.
## AI 시대의 TPM
- AI 도입이 확대될수록 기술 변화는 빨라지고 팀 간 의존성과 책임 경계는 복잡해진다.
- 조직에 필요한 것은 회의와 상태 보고를 늘리는 사람이 아니라, 비어 있는 구조를 찾아 실행이 다시 움직이도록 만드는 사람이다.
- 모두가 중요하다고 하지만 아무도 끝까지 책임지지 않는 문제가 반복된다면 새로운 형태의 TPM이 필요하다는 신호다.
- 정식 직책이 없더라도 이런 문제를 발견하고 구조화해 해결까지 이끄는 비공식 TPM 역할부터 시도해볼 수 있다.
