toss·2026년 5월 22일·3분 읽기큐레이션 요약

Cross Functional 기술 문제 풀기 위한 역량 성장 Tip

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

원문 읽기(새 탭에서 열림)

organizational-designcross-functional-collaborationproblem-solvingtechnical-program-management+2

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

organizational-designAIdata-governancecross-functional-collaboration+3

woowahan·2025년 12월 10일원문

우리는 코드처럼 문화도 리팩토링한다 (새 탭에서 열림)

배달의민족 커머스웹프론트개발팀은 조직 규모 확대에 따른 복잡도와 비효율을 해결하기 위해 문화를 코드처럼 리팩토링하며 '경계 없는 파트' 구조를 도입했습니다. 특정 도메인이나 서비스에 갇히지 않고 책임을 확장하는 R&E(Responsibility & Expandability) 원칙을 통해 기술적 통합과 조직의 유연성을 동시에 확보했습니다. 이러한 시도는 서비스 간 장벽을 허물고 구성원들이 커머스 전반을 조망하는 엔지니어로 성장하며, 비즈니스 요구에 기민하게 대응하는 결과로 이어졌습니다. ### 경계 없는 파트와 R&E 중심의 조직 구성 * **전통적 분할 방식의 탈피**: 프로젝트, 페이지, 서비스(B마트/배민스토어) 단위로 조직을 나눌 경우 발생하는 리소스 불균형과 도메인 파편화 문제를 해결하기 위해 고정된 경계를 제거했습니다. * **R&E(Responsibility & Expandability) 도입**: 단순히 주어진 역할만 수행하는 R&R을 넘어, 문제 해결을 위해 업무 영역을 스스로 확장하고 동료를 돕는 'Own It' 정신을 조직 구조에 이식했습니다. * **유연한 리소스 배분**: 약 20명의 프론트엔드 개발자를 3개 파트로 나누되, 특정 도메인에 종속시키지 않고 팀 상황에 따라 업무를 배분하여 병목 현상을 최소화했습니다. ### 기술적 통합을 통한 도메인 확장성 확보 * **통합 아키텍처 구축**: B마트와 배민스토어의 상품 카드 및 상세 화면 등 유사한 UI/UX를 공통 모듈로 추상화하고 API 구조를 맞춤으로써 코드 베이스의 일관성을 확보했습니다. * **엔지니어링 역량 강화**: 개발자들이 고객 서비스의 UX부터 어드민의 데이터 흐름까지 전방위적인 도메인을 학습하게 하여, 특정 기능 담당자가 아닌 커머스 전체를 이해하는 전문가로 성장하도록 유도했습니다. * **리스크 관리(Bus Factor 개선)**: 특정 인원이 부재하더라도 다른 팀원이 맥락을 즉시 이어받을 수 있는 구조를 만들어 프로젝트 중단 위험인 '버스 팩터'를 획기적으로 낮췄습니다. ### 지속적인 개선을 위한 소통과 기록의 리팩토링 * **의사결정 자산화(ADR)**: 단순한 기획 공유인 1Pager 방식에서 나아가, 기술적 결정의 배경과 맥락을 기록하는 ADR(Architecture Decision Record)을 도입해 팀의 지식을 체계적으로 관리합니다. * **루틴의 재설계와 자동화**: 반복적인 업무나 귀찮은 과정을 레거시로 남기지 않고, 자동화와 프로세스 개선을 통해 개발 효율성을 지속적으로 높입니다. * **심리적 안전감 기반의 협업**: '불판'과 같은 자유로운 논의 문화를 통해 실패를 과정으로 수용하고, 질문이 스터디로 이어지는 선순환 구조를 구축했습니다. 성장하는 조직에서 발생하는 비효율을 방치하지 않고, 코드 리팩토링과 같은 관점에서 구조와 문화를 끊임없이 개선하는 태도가 중요합니다. 특히 도메인 간 경계를 허무는 시도는 대규모 서비스 통합이라는 복잡한 비즈니스 과제를 해결하는 데 매우 강력한 전략이 될 수 있습니다.

organizational-design자동화코드 리뷰refactoring+3