나는 어떤 문제를 풀고 싶은 사람인가

토스에 합류할 때 내가 가장 배우고 싶었던 것은 Product였다.

맥킨지에서는 주로 Strategy와 Business problem을 다뤘고, MBA 동안 스타트업에서 일하면서 Product Marketing과 Go-To-Market을 경험했다.

그러다 보니 자연스럽게 다음 질문이 생겼다.

“좋은 Product는 실제로 어떻게 만들어지는가?”

고객의 문제를 어떻게 발견하는지, 어떤 문제를 먼저 풀어야 하는지, Product와 Business가 어떻게 연결되는지 가까이서 배우고 싶었다.

그래서 처음 토스에 들어갈 때만 해도 Product에 가까워지는 것이 내 커리어의 중요한 다음 단계라고 생각했다.

실제로 토스에서 1년 동안 Product에 대해 정말 많은 것을 배웠다.

하지만 여러 문제를 풀고, 여러 사람과 일하고, 내가 가장 몰입했던 순간들을 돌아보면서 조금 다른 것을 발견하게 됐다.

내가 가장 좋아했던 것은 Product 자체라기보다, 여러 조직에 걸쳐 있는 복잡한 Business problem을 구조화하고 실제 Outcome이 나올 때까지 움직이는 일이었다.

내가 가장 몰입했던 문제들은 한 팀의 문제로 정의하기 어려웠다.

어떤 서비스의 핵심 지표가 기대만큼 나오지 않는다고 해보자. 처음에는 Product 문제처럼 보일 수 있다. 하지만 조금만 들여다보면 특정 고객군, 파트너의 운영 방식, Sales 과정, 혹은 데이터가 흩어진 구조가 원인일 수 있다.

이런 문제는 어느 한 Function에 넘긴다고 해결되지 않는다.

Product팀이 기능을 고친다고 끝나는 것도 아니고, Sales가 더 많이 판다고 해결되는 것도 아니며, Operations가 프로세스를 개선한다고 전체 Outcome이 자동으로 좋아지는 것도 아니다.

오히려 먼저 해야 하는 것은,

“이 문제를 어떤 단위로 정의해야 실제로 해결할 수 있는가?”

를 다시 정의하는 일이었다.

한 번은 특정 서비스의 운영 현황을 End-to-end로 볼 필요가 있었던 적이 있다. 관련 데이터가 여러 시스템에 흩어져 있어 각 데이터를 따로 보면 일부 사실은 알 수 있었지만 전체 문제는 보이지 않았다.

그래서 먼저 한 일은 전략을 세우는 것이 아니라 문제를 볼 수 있는 공통된 View를 만드는 것이었다.

수십만 개 수준의 데이터를 하나의 기준으로 연결하고 나니, 이전까지 하나의 큰 문제처럼 보였던 것이 여러 개의 서로 다른 문제로 나뉘기 시작했다.

어떤 고객군에서 문제가 많이 생기는지, 어떤 유형의 파트너에서 실패가 집중되는지, 어떤 단계에서 이슈가 발생하는지, 각 원인이 전체 Gap의 얼마나 큰 부분을 설명하는지가 보였다.

그때부터 질문도 달라졌다.

“왜 이 지표가 낮지?”가 아니라,

“어느 구간의 Gap부터 줄이는 것이 가장 Impact가 큰가?”

가 됐다.

그리고 분석만으로는 충분하지 않았다.

가장 큰 병목이 특정 파트너에 있다면 그 문제의 우선순위를 올려야 했고, Product 변경이 필요하다면 제품팀과 같이 봐야 했으며, 운영 프로세스가 원인이라면 다시 반복되지 않도록 구조를 바꿔야 했다.

여러 차례 실행과 수정이 이어졌고, 그 결과 핵심 지표가 70대에서 90 이상까지 올라가는 것을 볼 수 있었다.

내가 이 경험을 좋아했던 이유는 숫자가 좋아졌기 때문만은 아니었다.

처음에는 아무도 전체 모습을 한 번에 보고 있지 않던 복잡한 문제를 하나의 구조로 만들고, 그 구조를 바탕으로 여러 팀의 행동을 바꾸고, 결국 실제 결과까지 이어지는 과정 자체가 재미있었다.

이런 경험을 반복하면서 한 가지를 더 알게 됐다.

나는 이미 잘 정의된 문제를 받아서 좋은 Solution을 만드는 것도 좋아한다. 하지만 그보다 더 몰입하는 순간은 문제 자체가 아직 제대로 정의되어 있지 않을 때였다.

“매출이 충분히 빠르게 성장하지 않는다.”

“신규 서비스 Adoption이 기대보다 낮다.”

“Product와 Sales가 서로 다른 문제를 보고 있다.”

이런 막연한 문제를 고객, 데이터, Product, Operations, Sales, 그리고 Business priority를 함께 놓고 actionable한 문제로 바꾸는 과정에서 나는 꽤 큰 재미를 느꼈다.

그리고 여기서 Strategy와 Execution의 경계가 흐려졌다.

내가 원하는 것은 Strategy deck을 만드는 일이 아니었다.

그렇다고 특정 Product feature 하나의 성공만을 책임지고 싶은 것도 아니었다.

사업적으로 중요한 문제가 있고, 그것을 풀기 위해 필요한 일을 Function에 상관없이 가져가며, 실제 Outcome을 만드는 역할에 더 가까웠다.

어떤 날은 분석이 필요했고, 어떤 날은 프로젝트를 구조화해야 했으며, 어떤 날은 사람들의 역할과 책임을 다시 정리해야 했다. 때로는 새로운 process를 만들고, 직접 고객이나 파트너의 이야기를 들어야 했다.

상황에 따라 해야 하는 일은 계속 바뀌었다.

하지만 결과를 판단하는 기준은 오히려 단순했다.

Business metric이 실제로 움직였는가.

토스에 오기 전까지 나는 Problem Solving을 비교적 분석적인 능력으로 생각했던 것 같다.

복잡한 문제를 잘게 나누고, 중요한 질문을 찾고, 데이터를 분석하고, 논리적인 답을 제시하는 것.

맥킨지에서 특히 많이 훈련받았던 방식이기도 하다.

하지만 실제 사업 안에서 문제를 끝까지 가져가며 생각이 조금 바뀌었다.

답을 안다고 해서 문제가 해결되는 것은 아니었다.

누군가 실제로 행동해야 했다.

때로는 incentive가 바뀌어야 했고, 데이터가 새롭게 보여야 했으며, ownership이 명확해져야 했다. 여러 팀이 서로 다른 숫자를 보고 있다면 같은 지표를 보도록 만들어야 했고, 문제는 알고 있지만 아무도 책임지지 않고 있다면 owner를 세워야 했다.

그래서 실제 조직의 problem solving은

“정답이 무엇인가?”보다

“조직이 다르게 움직이게 하려면 무엇을 바꿔야 하는가?”

에 더 가까웠다.

나는 특히 같은 문제가 반복되지 않도록 시스템을 만드는 일에 흥미를 느꼈다.

한 번의 분석을 하는 것보다 사람들이 앞으로 계속 더 나은 의사결정을 할 수 있게 데이터 구조를 만드는 일.

프로젝트 하나를 성공시키는 것보다 누가 무엇을 책임져야 하는지가 명확한 Operating Model을 만드는 일.

돌이켜보면 내가 잘하고 좋아했던 일은 Individual Problem Solving보다는 여러 문제와 조직을 연결하고, 하나의 System으로 재구성하는 종류의 Problem Solving에 더 가까웠다.

그리고 또 하나 알게 된 것이 있었다.

나는 문제의 크기에도 꽤 영향을 받는 사람이었다.

한 팀 안에서 잘 정의된 문제를 푸는 것보다, 여러 팀에 걸쳐 있고 사업 전체의 Outcome에 영향을 주는 문제를 볼 때 더 많은 에너지를 얻었다.

Product Conversion을 몇 퍼센트 올리는 것보다, 애초에 충분한 고객이 들어오지 않는 것이 더 큰 문제일 수도 있다. 고객은 들어오지만 Onboarding에서 대부분 이탈하는 것이 문제일 수도 있고, Product보다 Sales, Operations, Partner Ecosystem의 병목이 훨씬 클 수도 있다.

나는 이런 Trade-Off를 보는 것이 재미있었다.

“지금 이 Business에서 가장 중요한 한두 가지 문제는 무엇인가?”

를 찾고, 그 문제를 풀기 위해 어디에 Resource를 써야 하는지 고민하는 일.

하지만 큰 문제를 보는 것과 그 문제를 실제로 풀 수 있는 것은 다른 일이었다.

CPO Staff 역할을 하면서 조직의 중요한 문제를 가까이서 볼 수 있었지만, 어느 순간 이런 질문이 생겼다.

“나는 이 문제에 대해 실제로 어디까지 결정할 수 있는가?”

문제를 발견했다면 Resource를 움직여보고 싶었고, 가설을 세웠다면 직접 실행해보고 싶었으며, 그 결과에 대해서도 책임지고 싶었다.

좋은 의사결정은 결국 실제 Outcome을 책임질 때 더 빠르게 좋아진다고 느꼈다.

그래서 나는 점점 권한과 책임이 함께 커지는 역할을 원하게 됐다.

앞으로의 커리어에서 나는 더 큰 문제를 풀고 싶다.

여기서 ‘큰 문제’는 꼭 수천억 원의 매출이나 거대한 시장을 의미하지 않는다.

사업이나 조직의 중요한 결과를 크게 바꿀 수 있는 문제.

여러 Function을 함께 고려해야 하는 문제.

정답이 아직 명확하지 않은 문제.

그리고 해결했을 때 Organization-Level Impact가 나는 문제다.

동시에 그 문제에 대해 더 큰 Ownership을 갖고 싶다.

좋은 분석을 제공하거나 방향을 제안하는 데서 끝나는 것이 아니라, 어떤 문제를 풀지 정하고, Resource를 어디에 쓸지 판단하고, 사람들을 정렬하고, 필요하면 계획을 바꾸고, 결국 결과까지 책임지는 역할.

이 두 가지가 함께 있을 때 내가 가장 빠르게 성장하고, 가장 몰입할 수 있다는 생각이 들었다.

그래서 커리어를 보는 질문도 조금 바뀌었다.

예전에는 다음 역할을 볼 때 Strategy인가 Product인가, 대기업인가 스타트업인가, 어떤 Title인가 같은 질문을 많이 했다.

물론 여전히 중요한 질문들이다.

하지만 이제는 그보다 먼저 이런 질문을 보게 된다.

이 역할에서는 어떤 크기의 문제를 풀게 되는가?

그 문제의 Outcome에 대해 나는 어디까지 책임질 수 있는가?

좋은 결과를 만들기 위해 사람과 Resource를 얼마나 움직일 수 있는가?

내가 내린 판단에 대한 Feedback Loop는 얼마나 빠른가?

이 질문들에 대한 답이 좋다면 직함이 조금 애매해도 괜찮겠다는 생각이 들었다.

반대로 Title이 좋아 보이거나 이름 있는 회사더라도 실제로 작은 Scope 안에서 제한된 문제만 반복한다면 나에게는 좋은 선택이 아닐 수도 있다.

-----------------------------------------------------------

토스에서 Product에 대해 정말 많이 배웠다.

하지만 1년을 지나고 돌아보니, 내가 얻은 가장 큰 배움은 조금 다른 곳에 있었다.

나는 특정 Function의 전문가가 되는 것 자체를 최종 목표로 삼고 있는 것은 아닌 것 같다.

Product도 좋아하고, Strategy도 좋아하고, Growth나 Operations의 문제도 재미있다.

앞으로 커리어가 어디로 이어질지는 아직 잘 모르겠다.

하지만 적어도 다음 선택을 할 때 무엇을 찾아야 하는지는 이전보다 훨씬 명확해졌다.

그리고 그것만으로도 토스에서의 1년은 내게 꽤 중요한 전환점이었다.