AI 시대, 성과 내는 조직일수록 토스식 TPM이 필요한 이유

아직 한국의 Tech 업계에는 TPM(Technical Program Manager)이 많지 않습니다. 그럼에도 주요한 Tech 회사에서 활약을 하는 소수 정예들이 있습니다.

각 회사들에서 TPM을 설명하는 언어는 유사합니다. Cross-Functional 협업, 이해관계자 조율, 리스크 관리, 일정 관리, 상태 공유. 모두 중요한 일입니다. 큰 프로그램을 움직일 때 꼭 필요한 기능이기도 하죠.

하지만 직접 이 포지션으로 뛰어보니 조금만 더 나아가면 더 큰 임팩트를 낼 수 있겠다는 생각이 들었습니다.

저희 팀에서 해결하려고 한 일들에는 일정표를 더 잘 관리하는 것만으로는 풀리지 않는 문제가 있었기 때문입니다. 여러 팀이 조금씩 얽혀 있지만 아무도 끝까지 책임지지 않는 문제, 전략은 있는데 실행 구조가 없는 문제, 모두가 중요하다고 말하지만 공식 Owner가 없는 문제, 상태 공유는 이어지는데 현실은 잘 바뀌지 않는 문제들이었습니다.

AI가 조직 안으로 깊이 들어올수록 이런 문제는 더 빨리 늘어납니다. 기술 변화는 빠르고, 팀 간 의존성은 복잡해집니다. 기존 역할 정의만으로는 책임지기 어려운 회색지대도 계속 생겨나죠.

24년 12월, 이러한 문제를 해소하고자 Tech Excellence Team과 TPM 포지션을 토스에 신설한 후 계속 여러 사람들과 이 역할에 대해 논의했습니다. TPM은 정말 조율을 잘하는 사람으로만 설명할 수 있을까. 아니면 더 어려운 문제를 풀기 위해 역할 자체를 다시 정의해야 할까.

토스가 TPM의 역할을 재정의해보자고 생각하게 된 이유도 여기에 있습니다.

왜 지금 TPM을 다시 정의해야 하는가

지금 시장에서 TPM은 대체로 정의된 프로그램을 안정적으로 전달하는 역할로 이해됩니다. 여러 팀에 걸쳐 있는 제품이나 기술 조직의 요구사항을 정리하고, 일정과 리스크를 관리하고, 여러 조직의 의존성에 따라 진행 상황을 맞추는 역할입니다. 그래서 딜리버리가 일정 문제 없이 되었다는 표현으로 성과를 이야기할 때도 종종 있고요.

토스에서도 이 정의는 유효했지만, 충분하지 않을 때도 있었습니다.

조직이 커지고 복잡해질수록, 정말 어려운 문제는 이미 정의된 프로그램 안에 들어오지 않기 때문이었습니다. 처음부터 이름이 붙은 과제로 나타나지 않는 경우가 더 많았습니다. 누가 풀어야 하는지조차 분명하지 않은 상태로 남아 있기도 했습니다.

어떤 문제는 제품 이슈처럼 보이지만, 사실은 기술 전략의 문제이기도 합니다. 조직 설계의 문제이기도 하고, 운영 방식의 문제이기도 합니다.

어떤 문제는 여러 팀이 각자 자기 역할을 잘하고 있는데도 전체로 보면 비어 있습니다. 어떤 문제는 리더십도 중요성을 알고 있지만, 기존 구조 안에서는 우선순위를 만들기 어려웠습니다.

이런 문제 앞에서는 조율만으로 부족합니다. 일정 관리만으로도 부족합니다.

필요한 사람은 이미 존재하는 계획을 매끄럽게 흘려보내는 사람이 아닙니다. 아직 구조화되지 않은 문제를 붙잡고, 해결 가능한 상태로 바꾸는 사람입니다.

토스식 TPM은 바로 그 지점에서 출발했습니다.

TPM은 원래 어떤 역할이고, 무엇이 다른가

TPM이라는 직무가 익숙하지 않은 분도 있을 것입니다. 그래서 먼저 이 역할이 보통 무엇으로 이해되는지부터 짚고 가고 싶습니다.

일반적으로 TPM은 Technical Program Manager의 약자입니다. 여러 팀이 함께 움직여야 하는 기술 프로그램에서 일정, 리스크, 의존성, 커뮤니케이션을 관리하며 전달 가능성을 높이는 역할로 설명됩니다.

복잡한 기술 과제를 안정적으로 굴러가게 만드는 사람이라고 이해하면 크게 틀리지 않습니다.

다른 역할과 비교하면 더 선명해집니다.

PO(Product Owner)는 보통 무엇을 만들지에 더 가깝습니다. 어떤 문제를 제품으로 풀지, 어떤 우선순위를 둘지, 사용자와 비즈니스 관점에서 무엇이 더 중요한지를 정의합니다. EM(Engineering Manager)이나 SDM(SW Development Manager)은 어떻게 팀이 꾸준히 좋은 실행을 할 수 있을지에 더 가깝습니다. 사람, 팀 운영, 기술 품질, 실행 환경, 조직 건강을 책임지며 팀이 성과를 낼 기반을 만듭니다.

일반적인 Technical Project Manager나 전통적인 TPM은 이미 정해진 목표를 어떻게 일정 안에서 전달할지에 더 가깝습니다. 여러 이해관계자를 맞추고, 리스크를 추적하고, 계획이 흔들리지 않도록 관리하는 역할입니다.

그렇다면 토스식 TPM은 어디에 있을까요?

토스식 TPM은 이 역할들을 대체하지 않습니다. 대신 그 사이와 바깥에 남는 문제의 해결을 시도합니다.

제품 방향은 맞는데 여러 조직이 얽혀 실행 구조가 비어 있을 때가 있습니다. 팀들은 열심히 움직이는데 전체 관점에서 Owner 없는 공백이 생길 때도 있습니다. 리더십의 문제의식은 분명한데, 누가 어떤 권한으로 끝까지 밀어야 할지 불분명할 때도 있죠.

토스식 TPM은 바로 그 지점에 들어갑니다.

그래서 토스식 TPM은 PO처럼 제품 우선순위의 Owner도 아닙니다. EM이나 SDM처럼 특정 팀의 People Manager도 아닙니다. 전통적인 프로젝트 매니저처럼 일정 관리 자체를 역할의 중심에 두지도 않습니다.

토스식 TPM은 이미 정의된 일을 관리하는 사람이 아닙니다. 아직 정의되지 않은 중요한 문제를 구조화하고, 해결 가능한 상태로 바꾸는 사람에 가깝습니다.

PO가 무엇을 만들지 정의하고, EM이나 SDM이 한 팀의 실행 기반을 책임지고, 일반적인 TPM이 이미 정의된 프로그램의 전달을 관리한다면, 토스식 TPM은 그 사이와 바깥에 남는 구조적 문제를 해결합니다.

좋은 조직일수록 왜 팀 사이의 문제가 더 중요해지는가

조직이 덜 성숙했을 때는 병목이 눈에 잘 보입니다. 의사결정이 느리다, 책임이 불분명하다, 협업이 약하다, 우선순위가 흔들린다. 이런 문제는 팀 안에서도 쉽게 드러나죠.

하지만 조직이 일정 수준 이상으로 올라가면 남는 문제가 달라집니다.

각 팀은 자기 목표를 잘 수행합니다. 각 리더는 책임을 분명히 집니다. 실행 속도도 충분히 빠릅니다. 그럴수록 역설적으로 문제는 팀 내부보다 팀과 팀 사이에서 더 많이 남아있게 됩니다.

이유는 단순합니다. 조직 구조는 현재의 전략을 실행하기 위해 만든 장치이기 때문입니다. 구조는 책임을 선명하게 만들고, 자원을 배분하고, 의사결정을 빠르게 합니다.

하지만 그 선명함 때문에 구조의 경계 밖에 있는 문제를 다루기 어려워집니다.

그래서 좋은 조직일수록 중요한 문제는 회색지대에 남습니다. 여러 조직이 조금씩 걸쳐 있지만 누구도 공식 Owner가 아닌 문제, 지금 당장 긴급하지 않아도 미래를 위해 붙들어야 하는 문제, 각 팀의 로컬 최적화로는 풀리지 않는 전사적 문제가 그렇습니다.

AI 시대에는 이 현상이 더 뚜렷해집니다.

모델 도입, 데이터 거버넌스, 품질 기준, 보안, 개발 생산성, 조직의 일하는 방식이 한 번에 얽히기 때문입니다. 팀 하나가 잘한다고 끝나지 않습니다. 기술과 조직과 운영의 경계를 함께 다뤄야 하는 문제가 늘어납니다.

토스가 TPM을 다시 정의하는 이유는 토스가 특별해서가 아닙니다. 높은 자율과 높은 실행력을 가진 조직일수록, 이런 구조의 경계 문제를 풀 별도의 역할이 더 필요해지기 때문입니다.

토스 TPM은 어떤 문제를 해결하는 사람인가

토스 TPM은 여러 팀 사이와 미정의 영역에 남아 있는 중요한 문제를 발굴하고, 구조화하고, 끝까지 해결하는 사람입니다. 여기서 중요한 것은 문제의 성격입니다. 토스 TPM이 다루는 문제는 처음부터 예쁘게 정리되어 있지 않은 경우가 많습니다.

오히려 이런 특징을 가집니다.

그래서 토스 TPM의 핵심은 프로그램 관리에서 나아가 문제의 재정의에 기반을 두고 있습니다.

겉으로 보이는 현상을 따라가는 것이 아닙니다. 진짜 풀어야 할 문제가 무엇인지 다시 정의합니다. 누가 빠져 있는지 드러냅니다. 어떤 의사결정과 권한이 필요한지 구조를 세웁니다. 그리고 실제 결과가 나올 때까지 개입합니다.

토스식 TPM은 조율자가 아니라, 회색지대의 문제를 해결하는 전략 실행자입니다.

토스 TPM은 실제로 어떤 역할을 해야 하는가

토스 TPM의 역할은 업무 목록보다 몇 가지 원칙으로 설명하는 편이 더 정확합니다.

문제를 받지 않고 먼저 찾는다

토스 TPM은 누군가 정리해준 일감을 처리하는 사람이 아닙니다. 구조적 병목, 반복되는 공백, 책임 경계에 걸쳐 방치되는 문제를 먼저 발견해야 합니다. 중요한데도 아직 이름이 붙지 않은 문제를 찾아내는 것이 역할의 출발점입니다.

전략을 문서로 끝내지 않고 실행 구조로 바꾼다

좋은 방향성만으로는 아무것도 달라지지 않습니다. 토스 TPM은 전략을 읽고 동의하는 것에서 멈추지 않습니다. 어떤 팀이 움직여야 하는지, 어떤 순서가 필요한지, 누가 DRI*가 되어야 하는지, 무엇을 먼저 포기해야 하는지까지 실행 가능한 구조로 바꿔야 합니다.

*DRI(Directly Responsible Individual): 특정 프로젝트나 업무의 최종 의사결정권자

팀 안보다 팀 사이에서 가치를 만든다

이 역할의 주요 무대는 특정 팀 내부가 아닙니다. 서로 다른 조직의 목적과 속도, 제약이 부딪히는 경계가 더 중요한 무대입니다. 그래서 토스식 TPM은 한 팀의 운영자가 아니라, 여러 팀이 함께 풀어야 하는 문제의 설계자에 가깝습니다.

블로커를 설명하는 데서 멈추지 않고 제거한다

리스크를 잘 보고하는 것만으로는 부족합니다. 중요한 것은 실제 장애물을 걷어내는 일입니다. 필요하면 의사결정 구조를 바꾸고, 필요한 사람을 묶고, 우선순위를 다시 세우고, 협업 방식을 재설계해야 합니다. 병목을 설명하는 사람과 병목을 없애는 사람은 다릅니다. 토스 TPM은 후자에 가깝습니다.

사람과 구조를 함께 본다

어려운 문제는 구조만의 문제도, 사람만의 문제도 아닙니다. 어떤 리더십이 필요한지, 어떤 팀 구성이 맞는지, 어디에 권한이 있어야 하는지, 어떤 운영 메커니즘이 반복 문제를 줄일 수 있는지를 함께 봐야 합니다. 토스 TPM은 일정을 보는 사람이 아닙니다. 조직이 실제로 움직이는 방식을 보는 사람입니다.

결과는 문서가 아니라 현실 변화로 증명한다

회의록, 리포트, 정렬 문서는 모두 중요합니다. 하지만 그것이 결과는 아닙니다. 방향이 바로잡혀야 합니다. 막혀 있던 실행이 다시 움직여야 합니다. 반복되던 병목이 줄어야 합니다. 다음부터는 같은 문제가 더 쉽게 풀리는 상태가 만들어져야 합니다. 그때 비로소 역할이 완성됩니다. 조율은 이 모든 과정에 필요합니다. 하지만 조율은 메인 정체성이 아니라 TPM이 자주 유용하게 사용하는 기술에 가깝습니다. 토스 TPM의 정체성은 문제 해결에 있습니다.

이런 TPM으로 성장하려면 무엇이 필요한가

실제로 이 역할을 해보니, 잘 해낸다는 것이 꽤 어려웠습니다. 저 역시도 지금도 계속 잘하기 위한 방법을 찾아가고 있고요.

문제만 잘 본다고 되는 일도 아니고, 실행력만 강하다고 되는 일도 아니기 때문입니다. 전략, 조직, 사람, 기술, 운영을 함께 다루는 감각이 필요합니다.

첫째는 문제 구조화 능력입니다. 모호한 현상을 보자마자 무엇이 진짜 문제인지, 무엇이 증상인지, 누가 관련되어 있는지, 어디서 결정이 막히는지 빠르게 구조화할 수 있어야 합니다. 좋은 TPM은 회의가 끝난 뒤 정리하는 사람이 아닙니다. 회의가 시작되기 전부터 문제의 프레임을 들고 오는 사람입니다.

둘째는 전략을 실행으로 바꾸는 힘입니다. 방향성에 공감하는 사람은 많습니다. 하지만 실제로 팀을 움직이게 하는 사람은 드뭅니다. 어떤 작업 흐름이 필요한지, 어떤 순서로 개입해야 하는지, 어느 시점에 누가 책임을 져야 하는지를 설계하는 힘이 있어야 합니다.

셋째는 영향력과 동원 능력입니다. 토스 TPM은 공식 권한만으로 일하기 어렵습니다. 여러 팀을 움직여야 합니다. 서로 다른 언어를 번역해야 합니다. 때로는 불편한 대화를 열어야 합니다. 합의가 느린 상황에서도 실행의 판을 만들어야 합니다. 직함보다 신뢰와 판단력이 중요한 이유입니다.

넷째는 시스템 사고입니다. 같은 문제가 두 번 반복되면, 그때부터는 개별 대응보다 구조를 의심해야 합니다. 왜 이 병목이 계속 생기는지, 어떤 운영 매커니즘을 바꿔야 하는지, 어떻게 하면 사람의 Heroic Effort가 아니라 기본값으로 굴러가게 만들 수 있는지를 보는 힘이 필요합니다.

다섯째는 완결성입니다. 시작은 누구나 할 수 있습니다. 중요한 것은 끝내는 능력입니다. 문제를 발견하고, 구조를 만들고, 사람을 모으고, 실행을 밀고, 결과를 남기고, 다음에 같은 문제가 더 적게 생기게 만드는 것까지 가야 합니다. 결국 좋은 TPM은 많은 일을 하는 사람이 아닙니다. 어려운 문제를 끝까지 풀 수 있는 사람입니다. 더 넓은 회색지대를 감당하고, 더 큰 난이도의 문제를 해결 가능한 상태로 바꿀수록 강한 TPM에 가까워집니다.

TPM이 Tech 업계 전반의 표준 포지션이 될 때까지

AI 시대의 조직은 점점 더 많은 문제를 팀 하나로 해결할 수 없게 됩니다.

기술은 빠르게 들어오고, 의존성은 늘고, 책임 경계는 더 복잡해집니다. 이때 조직에 필요한 사람은 회의를 더 많이 여는 사람이 아닙니다. 비어 있는 구조를 보고, 중요한 문제를 붙들고, 실행이 다시 움직이게 만드는 사람입니다.

토스가 TPM을 이렇게 정의하는 이유도 같습니다. 더 어려운 문제를 풀고 싶기 때문입니다. 더 큰 임팩트를 만드는 역할에 더 큰 책임을 맡기고 싶기 때문입니다.

그래서 이 글을 읽고 있는 누군가가 자기 조직을 떠올렸으면 좋겠습니다. 모두가 열심히 일하는데도 자꾸 비는 문제, 모두가 중요하다고 말하지만 아무도 끝까지 밀지 않는 문제, 기술과 조직과 운영이 얽혀 있어 역할 경계 밖으로 밀려나는 문제는 없는지 말입니다.

그런 문제가 있다면, 그 조직에는 이미 새로운 TPM이 필요할 가능성이 큽니다.

그리고 그런 문제를 보면 그냥 지나치기 어렵다면, 어쩌면 당신이 그 역할을 잘할 사람일지도 모릅니다. 지금 계신 그곳에서 한 번 비공식 TPM 역할을 자발적으로 해봐 주세요.

저희도 계속 노력하고 있겠습니다. 언젠가 만나 그 과정을 대화하는 날이 오길 고대하고 있겠습니다.