토스는 어떻게 빠르게 움직이는가

토스에서 일하며 가장 인상 깊었던 것 중 하나는 조직의 속도였다.

사람들이 빠르게 의사결정했고, 문제가 생기면 필요한 사람들이 금방 모였으며, 한 번 중요하다고 정해진 일은 꽤 짧은 시간 안에 실제 실행까지 이어졌다. 목표가 예상만큼 움직이지 않으면 금세 새로운 시도가 시작되었다.

처음에는 그 이유를 단순하게 생각했다.

주변에 똑똑하고 열심히 일하는 사람들이 많았기 때문이라고.

물론 그것도 중요한 이유였을 것이다. 실제로 높은 기준을 가진 동료들과 일한다는 것은 토스에서 얻은 가장 큰 행운 중 하나였다.

하지만 1년 동안 조직 안에서 일하며 점점 다른 생각을 하게 됐다.

조직의 속도는 '개인들이 얼마나 열심히 일하는가'만으로 만들어지지 않는다. 사람들이 빠르게 움직일 수밖에 없도록 도와주는 조직적 설계가 있었다.

내가 경험한 토스의 조직 운영 방식에서 특히 인상적이었던 것은 다섯 가지였다.

1. 목표가 숫자로 명확하게 정의되어 있었다

가장 먼저 배운 것은 목표 정렬의 힘이었다.

사업부에는 이번 반기에 반드시 만들어내고 싶은 business outcome이 있었다. 단순히 “이 사업을 성장시킨다” 같은 문장이 아니라, 가능한 한 숫자로 표현되는 목표였다.

예를 들어 어떤 핵심 지표가 현재 70 수준이고 반기 말까지 90 이상으로 올라가야 한다고 해보자.

그러면 그다음 질문은 자연스럽다.

“20이라는 gap은 어디에서 발생하고 있는가?”

고객군별로 나눠볼 수도 있고, 퍼널의 단계별로 볼 수도 있고, 상품이나 채널에 따라 쪼개볼 수도 있다.

전체 숫자 하나만 보고 있으면 막연했던 문제가 쪼개기 시작하면 구체적인 문제로 변한다.

어떤 구간에서 12가 빠지고 있고, 다른 구간에서 5가 빠지고 있으며, 나머지 3은 여러 작은 문제들의 합이라는 식이다.

그러면 팀의 목표 역시 자연스럽게 내려온다.

A팀은 12의 gap 중 7을 줄이는 것이 중요한 목표가 되고, B팀은 다른 병목을 해결해야 한다. 개인 역시 자신이 이번 반기 동안 어떤 숫자를 움직여야 하는지가 비교적 명확했다.

이 구조의 가장 큰 장점은 무엇을 해야 할지보다 무엇을 하지 않아야 할지가 명확해진다는 것이었다.

회사에는 언제나 할 수 있는 일이 해야 하는 일보다 많다.

고객 요청도 있고, 오래된 문제도 있고, 언젠가 하면 좋을 프로젝트도 있다. 흥미로운 아이디어 역시 계속 생긴다.

목표가 명확하지 않으면 각자가 보기에 중요해 보이는 일을 열심히 하게 된다.

모두가 합리적인 판단을 하고 있는데도 조직 전체로 보면 힘이 분산될 수 있다.

반대로 목표가 명확하면 질문이 바뀐다.

“이 일을 하면 좋을까?”가 아니라,

“이 일이 지금 우리가 움직여야 하는 숫자를 얼마나 움직일 수 있을까?”

가 된다.

나 역시 일을 시작할 때 자연스럽게 이런 질문을 하게 됐다.

이 문제가 정말 지금 가장 중요한 문제인가?

이 프로젝트가 성공하면 우리의 목표가 얼마나 움직이는가?

같은 시간을 쓴다면 더 큰 impact를 만들 수 있는 다른 방법은 없는가?

그래서 계획했던 일을 중간에 멈추는 것도 생각보다 자연스러웠다.

몇 주 동안 준비했던 일이더라도 새로운 데이터를 보니 impact가 예상보다 작다면 계속해야 할 이유가 없었다. 반대로 기존 계획에 없던 문제라도 목표 달성에 훨씬 큰 영향을 준다는 사실을 알게 되면 바로 우선순위가 올라갔다.

처음에는 이런 방식이 다소 즉흥적으로 느껴지기도 했다.

계획을 세웠으면 최대한 계획대로 실행하는 것이 좋은 운영 아닌가 싶었다.

하지만 시간이 지나면서 생각이 달라졌다.

계획을 잘 지키는 것과 목표를 잘 달성하는 것은 전혀 다른 일이었다.

계획은 목표를 달성하기 위해 현재 시점에서 세운 가설일 뿐이다.

새로운 정보가 들어오면 계획이 바뀌는 것이 오히려 자연스러웠다.

2. 열심히 하고 있는지가 아니라, 숫자가 움직이고 있는지가 보였다

목표가 숫자로 정의되어 있다는 것만으로는 충분하지 않았다.

더 중요했던 것은 진행 상황 역시 숫자로 계속 보였다는 것이었다.

목표가 90이고 현재가 70이라면, 몇 달 뒤에 결과를 확인하는 것이 아니었다.

이번 주에는 72가 됐는지, 75가 됐는지, 혹은 아무 변화 없이 70에 머물러 있는지가 계속 보였다.

그리고 그 숫자는, 일을 많이 했다고 해서 숫자가 움직이는 것은 아니었다.

회의를 많이 하고, 프로젝트를 여러 개 시작하고, 모두가 바쁘게 일했는데도 핵심 지표가 그대로일 수 있다.

그때 질문은 자연스럽게 다시 시작됐다.

“우리가 하고 있는 일이 정말 맞는가?”

처음에는 Product의 문제라고 생각했는데 데이터를 뜯어보니 특정 파트너군에서 실패율이 유독 높을 수도 있다. 다시 그 안을 보면 기술적인 문제보다 운영 프로세스가 원인일 수 있고, 혹은 특정 고객군에 적용된 방식 자체가 맞지 않을 수도 있다.

그렇다면 처음 세웠던 해결책을 고집할 이유가 없다.

Product를 수정하는 대신 파트너 운영 방식을 바꿀 수도 있고, 특정 고객군을 먼저 집중 공략할 수도 있다.

실행 이후 핵심 지표가 70 초반에서 80대로 올라갔다면 한 번 방향이 맞았다는 신호다.

그런데 목표가 90 이상이라면 아직 충분하지 않다.

다시 남은 gap을 분석하고, 다른 문제를 찾고, 또 실행한다.

이 과정에서 내가 배운 것은 숫자가 urgency를 만든다는 것이었다.

“요즘 이 프로젝트가 조금 늦어지고 있다”는 말은 사람마다 다르게 받아들일 수 있다.

하지만

“반기가 절반 지났는데 목표의 30%밖에 달성하지 못했다”

는 것은 해석의 여지가 훨씬 적다.

목표와 현재 사이의 거리가 계속 보이면 굳이 누군가가 “조금 더 열심히 해주세요”라고 말하지 않아도 된다.

남아 있는 gap 자체가 압박이 된다.

그리고 그 압박은 단순히 더 많은 시간을 일하게 만드는 방향으로만 작동하지 않았다.

오히려 더 좋은 방법을 찾게 했다.

남은 시간 안에 같은 방식으로 목표를 달성할 수 없다면, 더 큰 레버를 찾아야 한다.

그래서 새로운 가설을 세우고, 그동안 하지 않았던 시도를 해보고, 기존 프로세스를 바꾸고, 다른 팀에 도움을 요청하게 된다.

돌이켜보면 내가 토스에서 자주 보았던 'extra mile'은 개인의 근면함만으로 설명하기 어려웠다.

목표까지 남은 거리가 명확하게 보였기 때문에 기존 방식만으로 부족하다는 사실 역시 명확하게 보였고, 그것이 새로운 시도와 혁신을 만들었다.

3. Ownership은 '내 일을 잘하는 것'보다 큰 개념이었다

세번째로 크게 배운 것은 ownership이었다.

토스에서 일을 하다 보면 가끔 내가 정확히 무슨 function으로 일하고 있는지 애매하게 느껴질 때가 있었다.

어떤 business metric을 개선하는 것이 내 문제라면, 내 역할은 분석해서 “이 부분이 문제인 것 같습니다”라고 알려주는 데서 끝나지 않았다.

필요하면 데이터를 직접 봤다.

데이터가 충분하지 않다면 필요한 형태로 다시 만들었다.

문제를 customer, merchant, partner, channel 등 실제 행동할 수 있는 단위로 쪼갰다.

Product 변화가 필요하면 Product 조직과 이야기했고, Sales가 필요하면 Sales와 협업했다. Operations가 병목이라면 운영 프로세스를 같이 봤다.

그리고 실제 실행 이후 숫자가 움직였는지까지 확인했다.

예를 들어 수십만 개에 가까운 특정 서비스 데이터를 하나의 기준으로 연결해 E2E로 현황을 파악할 수 있도록 만든 적이 있었다.

그 전에는 여러 시스템에 흩어진 데이터를 각각 보고 있어 전체 상황을 한눈에 보기 어려웠다.

데이터를 연결하고 나니 문제가 전혀 다르게 보였다.

“서비스의 어떤 지표가 낮다”는 추상적인 문제가 아니라,

어떤 고객군에서,

어떤 유형의 파트너 때문에,

어떤 단계에서,

얼마나 많은 이슈가 발생하고 있는지가 보이기 시작했다.

그다음부터는 resource allocation도 달라질 수 있었다.

가장 많은 문제를 만들어내는 구간부터 해결했고, 이후 지표가 실제로 얼마나 개선되는지 추적했다.

몇 차례의 실행을 거치며 핵심 성공 지표가 70대에서 90 이상으로 올라가는 것을 볼 수 있었다.

이 경험에서 중요한 것은 내가 분석을 잘했다는 것이 아니었다.

분석이 실행의 시작점이었을 뿐이라는 것이었다.

내가 “문제를 발견했습니다”에서 일을 멈췄다면 아무 숫자도 바뀌지 않았을 것이다.

토스에서 말하는 ownership은 단순히 맡은 일을 책임감 있게 처리한다는 의미보다 훨씬 크게 느껴졌다.

문제의 경계를 자신의 직무보다 넓게 잡는 것.

그리고 가능한 한 outcome이 나올 때까지 문제를 놓지 않는 것.

Function을 기준으로 일을 정의하면 자연스럽게 handoff가 생긴다.

Strategy가 분석한다.

Product가 만든다.

Sales가 판다.

Operations가 운영한다.

각자가 자신의 일을 잘해도 그 사이에는 계속 비용이 발생한다.

왜 이 결정을 내렸는지 다시 설명해야 하고, context가 일부 사라지고, 우선순위가 다르면 기다려야 한다.

결과가 좋지 않을 때는 다시 누가 문제를 해결해야 하는지 논의해야 한다.

반면 한 사람이 outcome을 중심으로 문제를 잡고 있으면 loop가 훨씬 짧아진다.

문제를 발견하고 → 가설을 세우고 → 실행하고 → 숫자를 보고 → 다시 문제를 정의하는 과정이 하나의 ownership 안에서 이어진다.

그리고 이 구조가 속도를 만들었다.

4. 정보가 열려 있을수록 협업은 빨라졌다

네번째로 인상 깊었던 것은 정보의 투명성이었다.

토스에서는 많은 업무가 공개된 Slack 채널과 thread에서 진행됐다.

처음에는 조금 낯설었다.

회의에서 이야기하면 될 내용을 왜 이렇게 공개된 공간에서 이야기하는지, 왜 완벽하게 정리된 문서보다 빠른 메시지와 thread로 일을 이어가는 경우가 많은지 의아하기도 했다.

그런데 시간이 지나며 이 방식의 장점을 크게 느끼게 됐다.

가장 큰 장점은 context가 개인의 머릿속에 갇히지 않는다는 것이었다.

어떤 문제가 발생했고,

누가 보고 있고,

어떤 가설이 나왔고,

누가 무엇을 하기로 했으며,

결과가 어떻게 되었는지

상당 부분이 같은 공간에 남았다.

그러다 보니 새로운 사람이 문제에 참여하는 비용이 낮았다.

처음부터 한 시간짜리 설명을 다시 하지 않아도 thread를 읽으면 지금까지 어떤 일이 있었는지 상당 부분 파악할 수 있었다.

또 재미있는 것은 의도하지 않은 협업이 자주 일어난다는 점이었다.

관련 없어 보였던 사람이 thread를 보다가,

“예전에 비슷한 문제가 있었는데 여기 데이터를 한번 보세요.”

라거나,

“이 부분은 우리 팀에서 이미 해결한 적이 있습니다.”

라고 들어오는 경우가 있었다.

정보가 닫혀 있었다면 일어나기 어려운 협업이다.

그리고 무엇보다 status를 공유하기 위한 별도의 업무가 적었다.

일을 하는 과정 자체가 어느 정도 status sharing이었기 때문이다.

이건 생각보다 큰 차이를 만들었다.

일을 실제로 하는 것과, 일을 하고 있다는 사실을 설명하는 것은 다른 활동이다.

조직이 커질수록 후자에 상당한 시간이 들어간다.

그런데 실제 실행의 흔적이 공개되어 있으면 별도의 보고 비용이 줄어든다.

동시에 accountability도 생긴다.

누가 어떤 일을 하기로 했는지 공개되어 있고, 그 이후 결과도 같은 공간에 이어지기 때문이다.

그래서 협업에 필요한 transaction cost가 낮았다.

문제가 생겼을 때

“이 문제는 누가 알고 있지?”

“저 사람이 뭘 하고 있는지 물어봐도 되나?”

“예전에 비슷한 논의가 이루어진 적이 있었나?”

를 고민하는 시간이 상대적으로 적었다.

필요한 사람을 thread에 부르고 바로 문제를 풀기 시작할 수 있었다.

5. 자율성이 높을수록 alignment는 더 자주 필요했다

마지막으로 배운 것은 leadership sync의 역할이었다.

처음에는 한 가지 의문이 있었다.

이렇게 ownership과 자율성을 강조하는 조직이라면 리더와의 sync는 오히려 적어야 하지 않을까?

그런데 실제로는 반대에 가까웠다.

실행 방법은 상당히 자율적이었지만, 목표와 priority에 대한 alignment는 매우 자주 일어났다.

리더와의 대화는 단순한 status report라기보다 이런 질문을 계속 맞추는 시간이었다.

지금 목표까지 얼마나 남았는가?

가장 큰 bottleneck은 무엇인가?

우리가 지금 풀고 있는 문제가 여전히 가장 중요한 문제인가?

최근 데이터에서 새롭게 알게 된 것은 무엇인가?

기존 계획 중 무엇을 멈춰야 하는가?

다음 한두 주 동안 무엇에 가장 많은 에너지를 써야 하는가?

이 과정이 반복되면서 individual execution은 빠르게 움직이면서도 조직 전체의 방향은 크게 어긋나지 않았다.

그때 하나의 역설을 배웠다.

자율성을 높이기 위해 alignment를 줄여야 하는 것은 아니었다. 오히려 방향을 자주 맞추기 때문에 실행 방법을 통제하지 않아도 되었다.

매 순간 리더의 approval을 받아야 한다면 속도는 느려진다.

하지만 반대로 아무런 alignment 없이 각자가 자유롭게 움직이면 각 팀은 빠르게 가더라도 서로 다른 방향으로 갈 수 있다.

토스에서는 두 극단 사이의 다른 방식이 가능하다는 것을 경험했다.

방향은 자주 동기화하고,

실행은 owner에게 맡긴다.

결국 Urgency는 시스템에서 만들어졌다

돌이켜보면 각각의 요소는 특별히 새로운 이야기가 아니다.

명확한 목표.

숫자로 보이는 progress.

큰 ownership.

열린 정보.

빠른 communication.

잦은 leadership alignment.

좋은 조직에 관한 책에서 한 번쯤은 볼 법한 이야기다.

내게 특별했던 것은 이 요소들이 각각 존재한 것이 아니라 하나의 operating system처럼 연결되어 작동했다는 점이었다.

목표가 명확하니 큰 ownership을 줄 수 있었다.

목표가 숫자로 보이니 목표와 현실 사이의 gap이 계속 드러났다.

Owner가 명확하니 그 gap을 줄이기 위한 행동이 바로 시작됐다.

빠르게 실행하려면 필요한 정보와 사람이 연결되어야 했고, 그래서 정보의 투명성이 중요했다.

실행 속도가 빠른 만큼 계획은 자주 바뀔 수 있었고, 리더들은 계속 목표와 priority를 맞췄다.

그 결과 조직 전체에 높은 urgency가 생겼다.

나는 토스에서 urgency에 대해 꽤 중요한 것을 배웠다.

Urgency는 “빨리 합시다”라고 말한다고 만들어지는 것이 아니다.

목표가 무엇인지 명확하고,

지금 목표까지 얼마나 남았는지가 보이고,

그 차이를 누가 줄여야 하는지가 분명하며,

필요한 사람과 정보에 빠르게 접근할 수 있을 때,

사람들은 자연스럽게 움직인다.

그리고 기존 방식으로 목표를 달성할 수 없다는 것이 보이면, 더 좋은 방법을 찾기 시작한다.

결국 좋은 조직의 속도는 사람들이 무조건 오래 일하도록 만드는 데서 나오는 것이 아니었다.

좋은 사람들이 중요한 문제를 명확히 알고, 결과를 끝까지 책임지며, 필요한 자원을 빠르게 연결해 실제 숫자를 움직일 수 있도록 만드는 구조에서 나왔다.

토스에서 Product에 대해서도 많은 것을 배웠지만, 앞으로 내 커리어에 더 오래 남을 배움 중 하나는 어쩌면 이것일지도 모르겠다.

고성과 조직은 어떻게 사람을 움직이게 만드는가.

그리고 그 과정에서 처음으로, 조직의 성과를 개인의 능력이 아니라 하나의 system으로 바라보기 시작했다.