toss2026년 5월 22일

Cross Functional 기술 문제 풀기 위한 역량 성장 Tip (새 탭에서 열림)

조직이 커질수록 각 팀이 맡은 일은 잘 수행해도 팀과 팀 사이의 공백이 커지며, Cross Functional 기술 문제가 발생합니다. 이런 문제는 회의·보고·리스크 관리 같은 조율만으로 해결되지 않으며, 문제를 재정의하고 구조화해 실제 실행으로 전환해야 합니다. 토스의 TPM은 공식 권한보다 문제 정의력, 구조화 능력, 영향력과 실행력을 바탕으로 복합적인 문제를 끝까지 해결하는 역할을 합니다. ## 조직 성장과 함께 커지는 경계의 문제 - 팀별 책임과 전문성이 높아질수록 팀의 경계 밖 문제가 늘어납니다. - 인프라, 제품, 데이터, 보안, 운영 이슈가 서로 얽혀 한 조직만으로 해결하기 어렵습니다. - 단기 대응과 장기 구조 개선이 충돌합니다. - 중요하지만 공식 Owner가 없는 회색지대가 생깁니다. - 각 팀이 최선을 다해도 전체 최적화가 이뤄지지 않을 수 있습니다. ## 조율만으로 해결되지 않는 이유 - 회의를 더 자주 열고 진행 상황을 공유해도 문제의 본질은 남을 수 있습니다. - 리스크 목록이나 일정표에는 결정 구조의 공백, 모호한 책임, 충돌하는 우선순위가 잘 드러나지 않습니다. - 핵심은 관리의 밀도를 높이는 것이 아니라, 문제를 해결 가능한 구조로 바꾸는 것입니다. - 먼저 “진짜 병목은 무엇인가”, “누가 빠져 있는가”, “어떤 결정이 비어 있는가”를 물어야 합니다. ## TPM에게 필요한 핵심 역량 ### 문제를 다시 정의하는 힘 - 일정 지연이나 협업 속도 저하 같은 표면적 현상에 머물지 않습니다. - 지연의 원인, 비어 있는 의사결정, 불명확한 Owner, 반복되는 조직 구조의 문제를 찾아냅니다. - 증상을 관리하는 대신 해결해야 할 문제 자체를 다시 설정합니다. ### 모호함을 구조로 바꾸는 힘 - 무엇을 결정해야 하는지 명확히 합니다. - 가능한 선택지와 책임자를 정리합니다. - 문제를 실행 가능한 단위로 쪼개고 우선순위와 순서를 만듭니다. - 복잡한 문제를 여러 사람이 함께 다룰 수 있는 단순한 구조로 바꿉니다. ### 전략적 판단력 - 일시적인 이슈인지 반복될 구조적 문제인지 구분합니다. - 팀 내부 해결이 가능한지, 조직 차원의 개입이 필요한지 판단합니다. - 지금 개입해야 하는 문제와 관찰해도 되는 문제를 나눕니다. - 해결했을 때 조직의 실행 수준 자체를 높일 수 있는 문제에 집중합니다. ### 실행으로 전환하는 힘 - 실제로 움직여야 할 사람을 명확히 합니다. - 선행 결정과 Blocker를 정리합니다. - 모호한 논의를 결정 포인트로 바꾸고 담당자가 결론을 내리게 합니다. - 합의된 액션 플랜을 실제 행동으로 연결합니다. ### 공식 권한 없이 영향력을 만드는 힘 - 직함이나 지시가 아니라 신뢰와 판단력으로 참여를 이끌어냅니다. - 각 팀의 맥락과 제약을 이해하고 서로 다른 언어를 번역합니다. - 필요한 경우 불편한 대화를 열어 우선순위와 책임 문제를 드러냅니다. ### 사람과 구조를 함께 보는 시각 - 기술 문제가 역할 정의, 팀 구조, 운영 방식에서 비롯될 수 있음을 고려합니다. - 프로세스 개선만으로 충분한지, 역할 재설계나 리더십 개입이 필요한지 판단합니다. - 사람과 시스템을 분리하지 않고 함께 바라봅니다. ## 자율성이 낮은 조직에서의 단계적 접근 - **작은 문제부터 해결하기:** 분명한 병목 하나를 구조적으로 해결해 신뢰를 쌓습니다. - **조율에 구조화를 더하기:** 회의를 진행하면서 결정 사항, 의존성, 병목을 함께 드러냅니다. - **작은 범위에서 Owner 명확히 하기:** 담당자, 의사결정권자, 완료 기준을 구체화합니다. - **사례로 역할 증명하기:** 역할을 설명하기보다 Owner 없는 문제를 해결하고 반복 병목을 줄인 실적을 만듭니다. ## 주의할 점 - 조율은 중요하지만 목적이 아니라 문제 해결을 위한 수단이어야 합니다. - 공식 권한이 없어도 신뢰와 구조화 능력으로 영향력을 만들 수 있습니다. - 조직에 이상적인 역할 모델을 한 번에 강요하기보다 현재 환경에서 작동하는 작은 성공 사례부터 만들어야 합니다. 결국 Cross Functional 기술 문제를 풀기 위해서는 일정과 회의부터 관리하기보다 문제를 다시 정의해야 합니다. 진짜 병목, 누락된 사람과 책임, 실행을 가로막는 구조를 찾아 작은 범위에서부터 바꾸는 것이 실용적인 출발점입니다.

technical-program-managementcross-functional-collaborationproblem-solvingorganizational-design+2

toss2026년 5월 14일

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 역할부터 시도해볼 수 있다.

technical-program-managementaidata-governancecross-functional-collaboration+3