AI 시대, 성과 내는 조직일수록 토스식 TPM이 필요한 이유 (새 탭에서 열림)

토스가 정의하는 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 역할부터 시도해볼 수 있다.