<aside>

🫡 안녕하세요

이번 편에서는 토스페이먼츠에서 TPM으로 일하고 계신 김민종님의 이야기를 전해드릴게요.

복잡한 시스템을 구조화하고, 기술과 비즈니스를 아우르며 일하는 민종님의 시선과 경험을 낱낱이 들어봤습니다. TPM이 궁금했던 분들께 작은 힌트가 되길 바랍니다!

</aside>

<aside> ❓

토스페이먼츠의 TPM이 뭐에요~? TPM은 개발자들과 기술적 맥락에서 깊이 소통하고, 제품과 비즈니스의 방향성을 함께 설계하는 기술 중심의 제품 리더예요.

단순히 기술 문제를 분석하는 데 그치지 않고, 그 기술로 실제 고객의 문제를 해결하고 있어요. 개발자와 긴밀하게 협업하며 기술로 문제를 풀어 나가는 개발 리드의 역할을 의미해요!

</aside>

<aside>

Q1. 안녕하세요, 민종님! 현재 소속된 팀과 맡고 계신 역할에 대해 간단히 소개해 주세요.

</aside>

안녕하세요! 저는 토스페이먼츠에서 Settlement Platform Team에서 TPM 역할을 맡고 있는 김민종입니다.

저희 팀은 사용자의 결제 이후, 그에 따른 정산 전반을 책임지고 있어요. 예를 들어, 가맹점이 우리 서비스를 이용하기 시작하면 계약 정보를 기반으로 정산 조건을 등록하고, 거래가 발생하면 이해관계자 간의 수수료를 계산하거나 지급 금액을 산정해 정산 데이터를 저장해요. 이런 전 과정을 기술적으로 안정적이고 정확하게 운영할 수 있도록 만드는 게 저희 팀의 역할이에요.

저는 TPM으로서 이런 기능을 개발하는 과정에서, 비즈니스 요구사항을 기술적인 관점에서 잘 해석하고 구체화하는 역할을 맡고 있어요. 예를 들어, 어떤 기능이 어떤 구조로 개발되어야 하는지, 우선순위는 무엇인지, 일정은 어떻게 설계되어야 하는지를 개발자들이 실행에 집중할 수 있도록 맥락을 정리하고 의사결정을 지원하는 역할을 ****하죠.

<aside>

Q2. 토스페이먼츠에서 TPM으로 일하시면서 실제로 어떤 프로젝트를 리딩하셨고, 그 안에서 어떤 실무를 맡아오셨는지 구체적으로 들려주실 수 있을까요?

</aside>

현재 집중하고 있는 프로젝트는 비효율적인 레거시 시스템을 개편하는 일이에요!

약 20년 넘게 이어져 온 서비스인 만큼 그동안 쌓인 코드와 기술 부채가 많았고, 이로 인해 새로운 기능을 빠르게 개발하거나 변경하는 데 어려움이 있었어요. 지금은 장기적인 관점에서 시스템 구조를 새롭게 재정비하면서 개발 속도와 민첩성을 확보할 수 있는 기반을 만드는 데 집중하고 있어요.

예를 들어, 기존 시스템에서는 정산 결과가 단순 상점 단위로만 제공되어서, 어떤 계약 조건에 따라 수수료가 계산되었는지 파악하기가 어려웠어요. 이런 문제점을 개편을 통해 거래 건별로 수수료 산정 근거를 추적할 수 있는 구조를 마련했고 정산 데이터의 투명성과 신뢰도를 크게 개선했어요.

이 과정에서 TPM으로서 제가 중요하게 생각한 건 단순히 기능을 구현하는 것에 그치지 않고 ‘개념적으로 합리적이고 확장 가능한 구조’로 만드는 일이었어요.

“특정 목적에만 한정된 기능이 아니라 다양한 시나리오에도 유연하게 대응할 수 있도록 일반화해 두는 것” 이게 결국 팀 전체의 개발 효율성과 미래의 비즈니스 확장 가능성을 높여준다고 믿거든요.

기술 부채를 정리하는 일이 쉽진 않지만, 이렇게 방향성과 구조를 고민하면서 만들어 가는 과정이야말로 앞으로 더 빠르고 안정적으로 비즈니스를 전개하기 위해 꼭 필요한 기반이라고 생각해요.

<aside>

Q3. TPM으로서 일을 하면서 ‘이럴 때 TPM이 필요하구나’, ‘이런 역량이 정말 중요하구나’라고 느꼈던 순간이 있었을까요? 실제 경험을 바탕으로 TPM에게 꼭 필요한 역량이 무엇인지 들려주세요.

</aside>

TPM 역할에서 가장 중요한 역량 중 하나는 ‘이해하고 판단하는 능력’, 그리고 그걸 토대로 전체를 구조화하는 능력이라고 생각해요. 개발자들은 각자 자신들의 언어로 소통하지만, TPM은 개발자 뿐 아니라 운영팀, PM 등 다양한 이해관계자와 협업해야 하거든요. 그래서 상황에 맞게 복잡한 내용을 명확하게 전달하는 능력이 필수적이에요.

제가 담당하는 정산 제품과 PG 시스템은 매우 복잡한 구조로 이루어져 있는데, 처음에는 ‘나무’(개별 기능)만 보이고 ‘숲’(전체 시스템과 비즈니스 맥락)이 잘 보이지 않는 경우가 많았어요. TPM으로서 중요한 건 이 ‘큰 그림’을 파악하는 거예요. 즉, 각각의 기능들이 모여 어떻게 하나의 비즈니스 역할을 수행하는지 포괄적으로 이해하는 것이죠.

전체를 이해하기 위해서는 운영 팀은 어떻게 업무를 하는지, 코드 레벨에서는 어떻게 구현되어 있는지, 데이터는 어떤 흐름으로 움직이는지 모두 살펴야 하죠. 이를 통해 비즈니스와 기술 사이의 연결 고리를 명확히 하고, 복잡한 엔지니어링 문제를 구조적으로 풀어가는 게 TPM의 핵심 역량이라고 생각해요.

복잡한 시스템을 이해하고 그 안에서 효율적인 구조를 만들어 내며, 다양한 팀원들과 효과적으로 소통하는 것. 이 과정에서 오는 도전과 성취감이야말로 TPM 역할의 매력이고, 그래서 어려운 일을 해결하는 데 재미를 느끼는 사람들이 이 일을 잘할 수 있다고 봅니다.

<aside>

Q4. 보통 TPM은 목적 기능에서 일을 해오신 분들이 많다고 생각하는데요! 기능 조직 출신도 TPM 역할에 잘 맞을까요?

</aside>

TPM이라는 직무는 여전히 엔지니어로서의 정체성을 갖고 있어야 해요.

기능 조직에서 개발 리드를 해온 분들도, 이런 정체성을 바탕으로 TPM 역할을 충분히 잘 수행할 수 있습니다. TPM으로서 전체를 바라보고 조율하는 경험을 쌓으면서 시야가 넓어지고, 이는 다시 개발자로서 더 깊고 다양한 관점에서 문제를 해결하는 데 큰 도움이 되죠.

오히려 기능 조직에서 쌓은 탄탄한 기술적 기반과 현장 경험이 TPM 역할 수행에 강점으로 작용할 수 있습니다. TPM과 엔지니어 역할은 상호 보완적이며, 기능 조직 개발자들도 TPM의 역할을 충분히 해낼 수 있다고 자신 있게 말씀드릴 수 있어요!

<aside>

Q5. 프로젝트가 마무리되었을 때, 어떤 임팩트를 만들고 싶으신가요?

</aside>