토스식 TPM 공부 정리 | 회색지대를 누가 잡아야 할까
토스 블로그에서 TPM을 다시 정의한 글을 읽고, 팀 경계에서 빠지는 문제들이 왜 어려운지 정리해봤다.
토스 테크 블로그에서 TPM 역할에 관한 글을 읽었다. 제목은 “AI 시대, 성과 내는 조직일수록 토스식 TPM이 필요한 이유”였는데, 처음엔 그냥 조직론 이야기겠거니 했다. 근데 읽어보니 디자이너–개발자 사이에서 내가 자주 느끼던 “이건 누가 챙기지?” 하는 순간이랑 비슷한 구조가 다뤄지고 있었다.
조직이 잘 굴러갈수록 오히려 이상하게 빠지는 일들이 생긴다는 게 이 글의 핵심이었다. 팀마다 열심히 하는데, 두 팀의 경계에 있는 문제는 아무도 주인이 아닌 상태가 된다는 것. 토스는 이걸 ‘회색지대’라고 불렀다.
1️⃣ 토스가 말하는 TPM이 뭔가
TPM은 Technical Program Manager의 줄임말이다. 원래 정의에서는 “정해진 프로그램을 일정에 맞게 전달하는 사람”에 가까운 역할이다. 그런데 토스는 이 정의를 꽤 다르게 가져갔다.
토스식 TPM은 “아직 구조화되지 않은 문제를 잡고, 풀 수 있는 상태로 만드는 사람”이다. 누군가 정의해주기를 기다리는 게 아니라, 문제 자체를 먼저 찾아야 한다. 실행의 시작점이 지시가 아니라 발굴이라는 거다.
글에서는 다섯 가지 원칙을 정리했는데, 내가 이해한 바로는 크게 두 묶음으로 나뉘는 것 같았다. 하나는 문제를 스스로 발굴하고 전략과 연결하는 것, 다른 하나는 팀 경계에서 실제 움직임을 만들고 장애물을 치우는 것. 리스크를 보고서로 정리하는 역할이 아니라, 막혀 있는 걸 직접 뚫는 역할에 더 가깝다는 인상이었다.
2️⃣ 내가 든 생각
이 글을 읽으면서 자꾸 디자인-개발 협업 과정이 떠올랐다. 인터랙션 디테일이 시안에서 구현까지 내려오는 사이에서 “이건 디자이너가 결정해야 해, 아니면 개발에서 판단하는 거야?” 싶은 순간이 꽤 있다. 아무도 명시적으로 챙기지 않으면, 그냥 기본값으로 처리되거나 어물쩍 넘어가게 된다.
회색지대가 생기는 방식은 조직 레벨이든 팀 내부든 비슷한 것 같다. 책임이 명확히 정의된 영역보다, 두 영역이 겹치는 경계에서 더 자주 뭔가 빠진다. 이게 개인의 책임감 문제가 아니라 구조 문제라는 점이 꽤 납득됐다.
👉🏻 “누가 Owner인가”를 논의하는 것도 중요하지만, 그보다 “지금 아무도 안 잡고 있는 문제가 어디 있나”를 먼저 보는 게 다른 결과를 낳는다는 느낌이 들었다.
💡 여기서 드는 질문?
회색지대에서 빠진 문제를 TPM이 줍는 역할이라면, 처음부터 덜 빠지게 설계하는 건 누구 일일까? 그게 TPM의 범위 안에 있는 건지, 아니면 애초에 다른 구조 문제인 건지.
공부한 내용 기준으로는 이 부분까지 명확히 나오진 않았는데, 그래서 오히려 더 궁금해졌다. 어떤 글에서는 답보다 질문이 더 오래 남는 것 같다.
⭐️ 마지막으로, 조직 구조 공부하며 느낀 점
공부 끝에 남은 건 “조직이 성숙할수록 잘 빠지는 게 생긴다”는 한 줄이다. TPM이라는 직함 자체보다 ‘회색지대’라는 개념이 더 오래 기억에 남을 것 같다. 경계를 보는 사람이 있느냐 없느냐가 꽤 다른 결과를 만든다는 게, 디자인 프로세스에도 꽤 겹쳐 보이는 이야기였다.