토스에서의 시간을 돌아보며
이번 포스팅에서는 필자가 지난 2년 반 동안 몸 담았던 직장인 토스에서 경험하고 느꼈던 것들에 대해서 한번 편하게 적어보려고 한다. 사실 토스에서의 퇴사는 이미 3월에 진행했지만, 그 동안 새로운 곳에서의 할 일도 많았고 개인적인 일들도 겹쳐서 3개월이 지난 지금에서야 회고를 진행하게 되었다.
필자도 7년 정도 개발자로 일을 하면서 이 회사, 저 회사를 다녀봤지만 확실히 토스팀에서의 기억은 강렬하게 남는다. 워낙 문화가 특이한 조직이기도 했고, 함께 일했던 동료들도 훌륭했으며, 개인적으로도 그저 한 명의 개발자가 아닌 팀을 성장시킬 수 있는 개발자로 성장할 수 있었던 기회도 얻었기 때문이다.
토스는 어떻게 그렇게 일을 빠르게 할까?
필자는 작년인 2021년 말부터 주변 지인으로부터 너무 개발자들만 만나지 말고 다른 일을 하는 사람들도 많이 만나보라는 피드백을 받고, 다른 회사의 C-level 또는 HR 담당자나 VC에서 투자 심사역으로 종사하시는 분 같은 다양한 사람들을 만나보며 서로 궁금한 점을 물어보는 시간을 가지게 되었다.
이렇게 몇 번의 커피챗을 거치며 서로를 알아가다가 가끔씩은 그 회사에 놀러가서 개발자분들도 직접 만나보고 그 회사가 겪고 있는 기술적인 문제에 대해 솔루션을 제안하기도 하고, 비즈니스에 대해 더 궁금증이 든다면 Co-founder 분들을 만나뵙고 더 자세한 이야기를 나눠볼 수 있는 기회도 가질 수 있었다. (쓰고나니 뭔가 소개팅 같다)
이 과정 속에서 굉장히 많은 질문들을 받기도 했지만, 기술적인 부분을 제외하고 필자가 제일 많이 들었던 질문이자 가장 처음에 듣는 질문은 보통 이 질문이었다.
IT업계에서 토스는 꽤나 양면적인 이미지를 가진 기업으로 평가 받고 있다. 그 중 좋은 이미지는 굉장히 일을 잘 하고 빠르게 하는 팀이라는 것, 그리고 안 좋은 이미지는 일이 많은 원양어선이라는 것이다.
물론 필자같은 직원 입장에서야 당연히 일을 잘 하는 것도 중요하고 내 개인 생활도 중요하니 저 두 가지 팩터들을 가지고 저울질을 하겠지만, 아무래도 회사를 경영하거나 투자를 해놓은 입장에서는 첫 번째 팩터인 “일을 빠르게 잘 하는 방법”에 대한 관심이 많을 수 밖에 없기 때문에 저 질문은 사실 “어떻게 그렇게 일을 빠르게 잘 할 수 있냐”라는 의미인 것이다.
내 길은 내가 정하는 DRI 문화
DRI(Directly Responsible Indivisual)는 이름 그대로 어떤 사안에 대한 최종의사결정권자를 의미한다. 이 개념은 스티브 잡스가 애플에 처음 도입했던 개념인데, 토스에도 이 DRI라는 개념이 뿌리깊게 박혀있다.
개인적으로 토스가 빠른 속도로 일할 수 있는 원동력은 DRI라는 각자의 최종의사결정권이 굉장히 존중받는 문화에 있다고 생각한다. 토스팀은 조직의 의사결정권이 CEO 한 명에게 집중되어있는 것이 아니라 토스팀 전체의 팀원들에게 퍼져있는 문화이다.
실제로 토스팀은 리더가 마음대로 제품의 방향성을 정하기 어려운 곳이다. 왜냐하면 각 제품에 대한 DRI는 그 제품을 만드는 사일로, 그 중에서도 그 사일로의 PO(Product Owner)가 가지고 있기 때문이다.
물론 토스팀에도 CEO의 권위는 분명히 존재하고, 다른 사람보다 CEO가 던지는 말의 무게가 다른 사람에 비해 더 무거운 것도 사실이다. 하지만 토스팀이 다른 회사들과 달랐던 점은 PO들과 CEO가 싸우는 모습을 자주 볼 수 있다는 것, 그리고 결국 PO들이 이기는 경우가 많다는 점이다. (대표랑 PO가 죽자살자 싸우는 그림은 어느 정도 규모가 있는 회사에서는 보기 힘든 모습이기는 하다)
토스에서 DRI라는 것은 일종의 신성불가침영역과도 같다. 어떤 DRI를 맡고 있다는 것은 동료들이 해당 업무에 대한 그 사람의 능력에 대해 신뢰하고 있다는 것이고, DRI를 잃는다는 것은 동료로부터 신뢰를 잃어 더 이상 토스팀에 필요없는 사람이 되는 것과 마찬가지이기 때문에 다들 죽기살기로 자신의 DRI를 지켜내기 위해 동료로부터 신뢰를 얻고 팀에 도움이 되려고 노력한다.
즉, 아무리 CEO라고 해도 이 DRI를 리더의 권위로 뭉개고 뒤집어 엎으려고 한다면 “대표가 하라면 해야지…”가 아니라 “니가 뭔데 내 DRI를 위협해”와 같은 반응이 나오기 쉬운 환경이라는 이야기이다. 쉽게 말해서 토스에서 DRI를 건드는 행위를 하게 되면 생각보다 사람들이 많이 빡친다. (속된 말로 발작버튼이 눌릴 수도 있다)
그렇기 때문에 토스팀은 회사의 오너인 CEO조차도 쉽게 제품 개발에 이래라 저래라 할 수가 없는 문화라고 이야기하는 것이다. 실제로 CEO가 하지 말자고 했던 아이템을 PO가 끝까지 밀고나가서 성공시킨 사례도 있기 때문에, 이런 성공의 경험이 쌓여서 DRI를 존중하는 문화가 더 강력하게 유지된다.
물론 CEO는 오랜 기간 이 도메인에서 사업을 해왔기 때문에 PO보다 사업에 대한 인사이트가 더 많이 있을 수 있지만, 제품의 방향성에 대한 DRI는 그 사일로의 PO가 가지고 있기 때문에 보통 토스의 CEO는 조언자의 역할을 주로 하게 되는 것 같다.
그리고 이 DRI 덕분에 각 사일로는 본인들이 스스로 제품의 방향성을 결정하고 개발하고 결과를 관찰하는 이터레이션을 거치며 제품을 발전시킬 수 있게 되는 것이며, 이 과정 속에서 쓸데없는 보고나 확인 같은 절차가 없기 때문에 제품을 만드는 사람이 “나 이거 만들래!”라고 의사결정을 하고 하루이틀만에 제품을 개발해내는 재난지원금 같은 사례들이 나올 수 있는 것이다.
필자는 토스가 일을 빠르게 하고, 또 재밌게 할 수 있는 이유는 바로 이러한 완전한 권한의 위임에서부터 출발한다고 느꼈다. 애초에 누가 시켜서 만드는 것이 아니라 팀원들이 스스로 아이디어를 내고 제품을 발전시키기 때문에 제품에 대한 애정도가 높을 수 밖에 없지 않을까.
실패에 관대한 문화
토스팀은 새로운 시도로 인한 실패에 굉장히 관대한 조직이다. 심지어 코어 밸류에는 빨리 실패할 용기를 가지라는 말이 있었고, 전사에 자신의 실패 사례를 공유하는 Failure Party 같은 행사도 열릴 정도였으니 말이다.
이런 문화가 있는 이유는 굉장히 간단한데, 실패를 두려워하지 않고 새로운 시도를 할 수 있는 환경을 제공하기 위해서이다.
물리학자 사피 바칼은 본인의 저서인 룬샷(Loon Shots)에서 성공의 방정식 중 하나로 대다수가 무시하고 홀대하는 프로젝트를 빠르게 자주 시도해야 한다고 이야기한다. 이런 시도들이 쌓이다보면 어느 순간 임계점을 넘어서게 되고, 그때 비로소 문샷(Moon shots)을 쏠 수 있게 되는 것이다.
많은 이들이 손가락질 하는 프로젝트를 시도하고 실패해도 비난받지 않을 수 있는 환경이 결국 문샷을 만든다
토스팀은 이 룬샷을 마음 편하게 쏠 수 있는 환경을 마련해두었다. 실패했다는 사실 자체가 아니라 실패에서 무엇을 배웠는지 인지하고 이 실패를 다른 사람들에게 공유해서 두 번 다시 동일한 실패 사례가 발생하지 않도록 만드는 것에 초점을 맞추고 있는 것이다.
물론 실패는 예방할 수 없다라던가 실패를 발판삼아서 성장한다던가 같은 말들은 이미 많은 사람들이 알고 있는 말이지만, 실제로 실패를 두려워하지 않는 문화를 조직에 녹여내는 것은 생각보다 쉽지않다.
그래서 토스팀은 Failure Party 같이 “우리가 실패에 얼마나 관대한지”를 팀 내부적으로 홍보하는 캠페인을 진행하거나 컬쳐팀이나 리더가 꾸준히 “실패해도 괜찮다”라는 메세지를 입에 달고 다니는 것이다.
즉, 이렇게 조직 구성원들이 실패를 두려워하지 않는 문화를 정착시키기 위해서는 단순히 누군가 실패를 경험했을 때 그를 비난하지 않는 것이 아니라, 그보다 적극적인 액션들이 함께 동반되어야한다.
사실 대부분의 사람들은 지금까지 살아오면서 실패를 장려하는 문화가 아닌 실패를 경질하는 문화를 더 많이 경험해왔기 때문에, 이런 적극적인 액션들이 동반되더라도 실패를 두려워하지 않는 문화가 하루아침에 정착되지는 않는다. 이런 문화는 문화를 만들기 위한 노력들이 회사가 설립된 순간부터 망하는 그 날까지 꾸준히 수행되는 과정에서 천천히 스며드는 것이기 때문이다.
게다가 문화는 현재 상황을 유지하려는 일종의 관성을 가지고 있기 때문에, 처음부터 빌딩하는 것보다 중간에 도입하는 것이 더 큰 비용이 든다. 결국 여러분의 팀에 실패를 두려워하지 않는 문화를 정착시키고 싶다면 적어도 토스보다도 더 파격적이고 적극적인 액션들을 지속적으로 고민하고 수행해야 할 것이다.
CEO 스스로도 문화를 유지하려고 노력한다
하지만 이런 문화들이 일반적인 스타트업에 정착되기란 참 쉽지 않은 일이다. 왜냐하면 기업 문화라는 것은 CEO의 영향을 가장 많이 받을 수 밖에 없는데, CEO 입장에서 실무자들에게 DRI를 넘기거나 팀원들이 실패하는 걸 가만히 보고 있는 것은 꽤나 용기가 필요한 일이기 때문이다.
보통 우리는 친구들끼리 있는 술자리에서 이런 종류의 한탄아닌 한탄을 많이 한다.
우리 대표는 너무 디테일한 것까지 마이크로매니징을 해서 진짜 피곤해…우리를 못 믿나…? 이럴거면 날 왜 뽑은거래?
물론 필자도 이 부분에 대해서는 공감이 간다. 일반적으로 CEO는 경영의 전문가이지 제품 개발의 전문가는 아니니 말이다. 솔직히 그 제품을 개발하고 있는 PO, 디자이너, 개발자 입장에서는 전문가도 아닌 사람이 이래라 저래라하는 것이 귀찮고 짜증날 수 있다.
하지만 잠시만 입장을 바꿔서 생각해보면 그게 오히려 자연스럽고 인간다운 모습이기는 하다. 왜냐면 CEO는 회사가 잘 되었을 때 가장 큰 이익을 챙길 수 있는 사람이기도 하지만, 반대로 망했을 때 가장 큰 리스크를 지는 사람이기도 하기 때문이다.
일반적으로 스타트업은 투자를 받을 때 투자자로부터 회사의 가치를 평가받고 그 평가된 가치로 주식 1주의 가격을 계산해서 주식을 넘겨주는 형태로 투자를 받는데, 이렇게 투자자들이 스타트업에 투자하는 과정은 우리가 일반적으로 주식을 사고 파는 행위와는 약간 차이가 있다.
투자자들은 투자에 대한 리스크를 최대한 줄이기 위해 기업이 발행한 채권을 사서 돈을 빌려주고 나중에 채권을 주식으로 바꾸는 방법(CB, 전환사채)을 사용하거나 자신이 원할 때 기업이 주식을 무조건 사줘야하는 조건 또는 꾸준히 배당금을 받겠다는 조건(RCPS, 상환전환우선주)을 걸기도 하고, 지배주주가 지분을 매각할 때 투자자의 주식도 함께 팔아달라고 요구할 수 있는 조항(Tag-along) 등을 적극적으로 사용하기도 하면서 안전장치를 걸어둔다.
특히 RCPS 같은 우선주를 가진 투자자들은 보통주를 가진 일반주주들보다 여러가지 권리에 대해 우선권을 가지게 되는데, 문제는 CEO도 보통주를 가지고 있다는 것이다.
그렇기 때문에 우선주를 가지고 있는 투자자가 기업이 망해서 청산당했을 경우 보통주를 가진 주주들보다 잔여재산을 먼저 분배받을 수 있는 권리나 투자자가 계약기간 중 원하는 시점에 기업에게 강제로 주식을 팔 수 있는 권리 등을 행사할 경우에는 기업이 손해를 보더라도 이 권리를 지켜줘야 하는 경우도 발생할 수 있다.
즉, 스타트업이 받는 투자는 절대 공짜가 아니며, 사업이 잘 안되었을 경우에는 CEO가 보는 금전적 손해 또한 충분히 발생할 수 있다는 것이다. 그리고 다들 아시다시피 이 금액은 한 두푼이 아니다.
솔직히 이런 상황에서 직원들에게 제품 방향성에 대한 모든 의사결정권을 위임하거나 실패를 용인한다는 결정을 실천하는 것은 결코 쉽지 않다. 아무리 자신의 손으로 뽑은 직원이라고 해도 이 직원이 자신처럼 “내 사업이다”라고 생각할거라는 신뢰를 가지기가 어렵기 때문이다.
아니 이 자식, CEO들을 옹호하는 발언을 해? 알고보니 사측이었잖아?
필자가 이런 이야기를 하는 이유는 “그러니까 CEO들의 마이크로매니징을 이해해주자”라는 의미가 아니라, 오히려 그 반대이다. 이렇게 큰 리스크를 어깨에 짊어지고 있는 상황임에도 불구하고 사업을 성공시키고 싶다면 CEO부터가 팀원들을 신뢰하고 권한을 위임하는 문화를 만들기 위해 노력해야 한다는 이야기를 하고 싶은 것이다.
CEO가 아무리 대단한 사람이라고 할지라도 한 사람이 세상 모든 일을 전부 다 잘 할수는 없는 노릇이다. 게다가 시니어 레벨의 팀원을 영입했다면 그 사람은 CEO보다 그 분야에 있어서 훨씬 더 베테랑이라는 것을 의미하며, 제대로 된 시니어라면 당연히 비즈니스 레벨의 이슈들도 모두 트래킹하면서 의사결정을 진행할 수 있는 능력을 지니고 있다.
즉, CEO가 이래라 저래라 하는 것보다 그냥 팀원에게 권한을 위임하고 각자 잘 하는 분야를 맡아서 협업하는 것이 더 효율적이라는 것이다.
물론 함께 일하다보면 믿었던 팀원이 실패하는 모습들도 보게 될 것이고 이에 실망하는 경우도 있을 수 있다. 하지만 팀원이 저지른 몇 번의 실패 때문에 한번 CEO가 마이크로매니징을 하기 시작하면, 혹여 여러분의 팀원들이 잘 할 수 있는 부분이 있더라도 “어차피 자기 맘대로 할텐데 뭐”라고 생각하며 본인의 능력을 발휘하는 것을 포기하거나, 최악의 경우에는 유능한 직원들이 회사를 떠나는 상황까지도 펼쳐질 수 있다.
CEO가 사사건건 관여하며 내 능력을 제한하는 회사라면 굳이 여기 있어봤자 재미도 없고 성장도 할 수 없지 않은가?
이런 상황이 반복되다보면 회사에는 능동적으로 의사결정을 수행하며 자신의 능력을 발휘하는 사람들이 모두 떠나거나, 혹은 수동적으로 변한 상태가 되고, CEO가 일일히 의사결정해주지 않으면 직원들 스스로는 아무것도 결정하지 못 하는 반쪽짜리 조직이 될 수도 있다.
필자가 지금도 토스의 CEO인 승건님을 대단하다고 생각하는 이유는 단순히 이 분이 일을 잘 해서, 똑똑해서라기보다는 이런 부분을 스스로 인지하고 권한을 위임하는 문화를 본인이 직접 주도해나가고 있다는 점이다.
아무리 대단한 사람이라고 해도 결국 사람인 이상 사업 실패에 대한 두려움은 당연히 있을텐데, 그런 두려움을 이겨내고 팀원들을 온전히 신뢰하고 권한을 위임하며 실패를 장려하는 문화를 만들어나간다는 것 자체가 일반인 수준의 멘탈리티는 아니라고 생각한다.
물론 필자가 상기했던 DRI라던가 실패를 자유롭게 경험할 수 있는 환경이라는 토스의 문화는 정답이 아닐수도 있다. 실제로 토스 내에서도 계속 새로운 시도를 하며 문화를 발전시켜나가고 있고 말이다.
하지만 그 문화가 무엇이던간에 CEO, 즉 리더의 관심없이는 조직 내에 문화가 정착되기 어렵다. 아무리 문화에 관심있는 팀원들이 이리 뛰고 저리 뛰고 해봐도 결국 CEO가 “하지마”라는 말 한마디만 하면 다시 롤백되는 환경이라면 팀원들의 노력이 크게 의미없기도 하고, 어찌어찌 문화를 정착시킨다고 해도 리더부터 그 문화를 지키려는 노력을 하지 않는다면 다른 팀원들도 굳이 그 문화를 지키려고 하지 않게 되기 때문이다.
빠르게 성장한 조직의 문제
사실 토스의 문화도 재밌는 부분이 많았고 새로운 경험이기는 했지만, 필자가 이 회사에서 경험했던 것들 중에서 가장 값진 것은 문화가 아니다.
필자가 토스라는 곳에서 얻어갈 수 있었던 가장 값진 것은 바로 “시니어 개발자란 무엇인지”에 대해서 본격적으로 고민을 함과 동시에 실제로 그런 역할을 수행해볼 수 있는 기회를 얻을 수 있었던 것이다.
필자는 토스에 입사하고 첫 연봉협상을 진행할 때 본인의 성장 뿐만 아니라 팀을 성장시킬 수 있는 사람이 되어달라는 피드백을 받았었다.
물론 필자도 평소에 시니어란 무엇인가에 대한 고민을 거듭하고 있는 상황이었고, 어느 정도는 이 피드백과 비슷한 방향성을 잡고 있는 상태였다. 그렇기 때문에 친구들과 함께 루비콘 멘토링 프로젝트와 같이 다른 사람들을 도와주고 성장시킬 수 있는 경험을 쌓으려고 했던 것이다.
하지만 필자는 스스로 토스팀에서 이런 영향력을 행사할 수 있을 것이라고 생각하지는 않았기 때문에, 당시 저 피드백을 들었을 때 이런 생각을 했었다.
아니 토스에 있는 FE들은 다 나보다 일을 잘 하는 것 같은데 도대체 뭘 도와주라는 거지…?
내가 입사할 당시의 프론트엔드 챕터의 분위기
필자가 이렇게 생각했던 이유를 알기 위해서는 필자가 처음 입사했을 당시 프론트엔드 챕터의 분위기가 어땠는지에 대해서 먼저 알아야 한다.
필자가 처음 토스에 입사했던 2019년에는 프론트엔드 개발자가 총 10명이 조금 넘는 정도 밖에 안 되었고, 토스팀 전체 인원도 아마 300명이 조금 넘는 수준이었던 걸로 기억한다. 그 당시는 막 토스뱅크를 위해 인터넷 은행 예비인가를 받은 시점이었는데, 회사 규모나 가치에 비하면 인원이 확실히 적은 편이긴 했다.
프론트엔드 개발자 20명만 되면 진짜 소원이 없겠다고 말하고 다닐 때
당시 토스팀은 “최고의 인재에게 최고의 보상을”이라는 채용 캐치프라이즈를 내걸만큼 높은 인재밀도를 만들어내기 위한 채용전략에 집중하고 있었고, 실제로 높은 인재밀도를 구축하는데 성공해서 이른바 정예 스포츠팀 같은 조직을 만들어 낼 수 있었다.
이게 그냥 말 뿐만이 아닌게, 실제로 토스의 신규입사자들은 주변 동료들의 업무 능력에 대해서 상당한 압박감을 느낀다. 물론 일의 양도 일의 양이지만 그 많은 일들을 어떻게든 말끔하게 처리해내는 모습을 보면 “나 여기서 버틸 수 있나…?”라는 생각이 들 수 밖에 없다.
물론 필자가 대한민국에 있는 회사를 전부 다녀본 것은 아니기 때문에 토스팀이 절대적으로 다른 곳보다 일을 잘 한다고 말하기는 어렵겠지만, 적어도 필자가 지금까지 경험해본 조직들 중에서는 가장 일을 잘 하는 조직이기는 했다.
토스는 목표만 Align되고 나면 "그냥 각자 알잘딱합시다."라고만 해도 일이 잘 돌아가는 신기한 곳이었다
그래서인지 필자는 같은 프론트엔드 챕터에 있는 사람들의 성장에 대해서는 상당히 무관심했는데, 그 이유는 우리 챕터에 있는 사람들은 모두 각자 알아서 잘 하는 사람들이라고 생각했기 때문이다. 그리고 앞서 이야기했듯이 이렇게 주변에 일 잘하는 놈들이 널려있는 환경이라면 내가 성장하는게 우선이지 남의 성장 따위는 신경쓸 겨를이 없기도 하다.
물론 기술적인 토론이나 사내 스터디 같은 것들은 활발하게 이루어졌지만, 이런 활동들은 나보다 부족한 다른 사람을 성장시키는 것이라기보다는 서로 자극을 주고 받으며 우리가 함께 성장하자는 마음에 가까운 액션아이템이다. 그래서 필자에게 당시 프론트엔드 챕터는 실력이 비슷비슷한 친구들끼리 모여서 서로 자극을 주고 받으며 함께 성장하는 그런 느낌이었다고 기억된다.
즉, 당시 프론트엔드 챕터 내부의 문화를 정리하자면 이렇게 리스트업해볼 수 있겠다.
- 사람이 적기 때문에 서로 얼굴, 이름을 다 알고 친밀도가 높은 편이다.
- 서로의 능력에 대한 신뢰도가 높고, 조직원들 스스로 나도 팀원들에게 신뢰받고 있다는 생각을 하고 있다.
- 이러한 친밀도와 신뢰를 바탕으로 프론트엔드 챕터라는 조직에 대한 심리적 안정감이 형성되어있다.
주니어 개발자라는 개념의 등장
하지만 이러한 프론트엔드 챕터의 문화는 2020년을 기점으로 조금씩 달라지기 시작했다. 필자가 생각하는 원인은 크게 두 가지인데, 하나는 꼴랑 10명 초반대에 불과했던 챕터의 크기가 급격하게 빠른 속도로 커졌다는 것, 그리고 다른 하나는 주니어라는 개념이 등장했다는 것이다.
사실 그 전까지의 프론트엔드 챕터는 이미 서로에 대한 신뢰가 형성되어있기 때문에 내가 누군가를 성장시키기 위해 일방적으로 도와줘야 한다는 개념 자체가 희박했다.
하지만 토스팀이 NEXT Developer와 같은 프로그램을 만들면서까지 현재 실력이 출중하지 않더라도 앞으로의 성장 가능성이 큰 사람에게 기대를 걸고 채용하겠다는 공격적인 채용 스탠스를 취하면서 토스팀에는 “성장을 위해 도움을 받아야하는 팀원”이라는 페르소나가 생기기 시작했으며, 이 페르소나를 “주니어”라고 불렀다.
NEXT Developer 공채 페이지에는 대문짝만하게 "3년차 이하 개발자"라고 적혀있다
NEXT Developer는 일종의 주니어 공채 같은 느낌이었는데, 문제는 이렇게 대외적으로 “저희 주니어 뽑아요!”라고 커뮤니케이션을 했던 채용 퍼널을 통해 입사하신 분들의 심리 상태는 일반 채용 과정을 통해서 입사하셨던 분들과 약간 차이가 있다는 것이다.
물론 해당 프로그램을 통해 훌륭하신 분들을 많이 모실 수 있었지만, 당시 필자는 NEXT Developer를 통해 채용된 몇몇 분들의 행동 패턴이 기존에 있던 사람들과 약간 다르다는 느낌을 받았는데, 대표적으로 차이를 느낀 지점은 대충 이렇다.
- 왜 대부분 좋다, 괜찮다고만 말씀하시지? 맘에 안 드는 부분이 없으신가?
- 저 의견은 근거가 없는 주관적인 의견인데, 왜 그대로 받아들이시지?
- 왜 챕터 활동에 적극적으로 참여를 안 하실까?
사실 이런 특징들은 아직 조직에 적응하지 못한 신규입사자들의 일반적인 특징이기 때문에 크게 이상하지 않다고 생각할 수도 있지만, 이때까지 필자가 경험했던 토스의 신규입사자들은 보통 입사하고 얼마 되지 않았음에도 불구하고 기존의 챕터가 가지고 있던 문제점에 대해 강하게 챌린지를 하거나 사내 라이브러리에 기여를 하는 등 활발한 활동을 하는 경우가 많았다.
또한 단순히 실력이나 연차의 차이라고 하기도 이상했던 것이, 같은 NEXT Developer 퍼널을 통해서 입사하신 분들 중에서도 저런 행동 패턴을 보이는 분과 아닌 분이 나뉘었다. 그래서 필자는 도대체 어떤 이유로 이런 적극성이나 조직 적응 시간에 대한 차이가 발생하는지에 대한 고민을 했던 것이다.
왜 이 분들은 소극적일까?
다행히 이런 문제의식은 필자 뿐 아니라 몇몇 다른 프론트엔드 개발자분들도 가지고 계셨었고, 이러한 행동의 차이가 하드 스킬의 차이, 즉 자신이 이 조직에서 개발자로써 1인분의 역할은 하고 있다는 자신감의 차이가 아닐까 정도로 이야기가 되었었던 걸로 기억한다.
그래서 당시 챕터에서는 개발자들의 하드 스킬 상향 평준화를 위해 스터디, 오프라인 코드리뷰, 메이트와의 페어프로그래밍 등을 적극적으로 추진했었다.
하지만 여기에는 함정이 하나 있는데, 이러한 활동들의 기술적 수준이 하드 스킬 능력이 좋은 팀원들에게 맞춰져있는 경우가 많았다는 것이다. 아무래도 지금까지의 프론트엔드 챕터는 모두 함께 성장하는 것을 추구했던 조직이기 때문에 Promise, React와 같이 이미 알고 있는 기초적인 내용보다는 추상화, 대수적 효과처럼 모두가 새롭게 익히고 토론하며 성장할 수 있는 내용들이 선정되기 쉬운 환경이었다.
이건 마치 고인물만 득시글거리는 게임에 뉴비 몇 명이 들어온 느낌이랄까
여기서의 문제는 이렇게 자신의 지식을 크게 넘어서는 내용에 대한 이야기가 오가는 상황이라면 애초에 그 지식을 흡수하기도 어려울 뿐더러 오히려 자신이 부족해서 이런 이야기를 알아듣지 못 한다는 생각에 더 큰 부담감이나 자책감까지도 생길 수 있다는 것이다.
게다가 NEXT Developer같은 채용 프로그램은 처음부터 “주니어”를 뽑겠다고 대놓고 홍보했던 프로그램이었기 때문에 이 퍼널을 통해 입사하신 분들은 실제 본인의 하드 스킬 수준이 어느 정도던 간에 스스로를 아직 실력이 부족한 주니어라고 인지하는 경향이 있었고, 이로 인해 이런 감정을 느끼기 더 쉬운 상황이었다.
사실 필자도 스터디를 진행할 때까지는 이런 생각을 전혀 못 하고 있다가 나중에 1 on 1 커피챗을 진행하면서 알게 되었는데, 이때부터 필자는 이게 단순히 하드스킬의 차이가 아니라 스스로 느끼는 자신감에 대한 문제라고 생각했다.
토스팀이 챌린지 문화나 투명한 피드백 문화를 지향하고 있기는 하지만, 사실 이런 것들은 자신이 팀 내에서 최소한 1인분의 역할 정도는 하고 있다는 자신감이 기반이 되어야 행동에 옮길 수 있다. 스스로도 잘 하고 있는지 못 하고 있는지 긴가민가한 상황에서 자신의 의견을 적극적으로 밀어붙히거나 다른 사람에게 피드백을 주는 것은 굉장한 용기를 필요로 하기 때문이다.
또한 조직에 대한 심리적 안정감에 대한 차이도 있었는데, 예전에는 챕터에 고작 10명 남짓의 인원 밖에 없었고 기술적인 수준도 비슷했기 때문에 서로 빠르게 친해지고 신뢰가 형성되기도 쉬운 환경이었다.
이렇게 서로가 어떤 성격인지, 일 하는 스타일은 어떤지 잘 알고 있다면 다소 통랄한 피드백을 주고 받더라도 이 사람이 정말로 팀의 발전을 위해 나에게 이런 이야기를 하는 것, 그리고 이 피드백에는 어떠한 감정도 없다는 일종의 확신을 하기가 쉽고, 또 이런 확신이 조직에 대한 심리적 안정감과 신뢰로 이어질 수 있다.
토스 사람들이 좀 빡세보이긴 해도 워낙 일에 진심이라서 그런 것 뿐이지, 막상 알고보면 순딩이들이 많다
하지만 점차 인원이 많아지게 되면서 이제 서로 이름과 얼굴도 잘 모르는 상황이 되어버린데다가 챕터 내에 하드스킬의 차이로 인한 위계까지 생겨버린 상황이니 “내가 이런 이야기를 하면 내가 못 하는 사람으로 보이지는 않을까?”, “내가 지금 이런 이야기를 하는게 맞을까?”와 같은 걱정들도 자연스럽게 생겨버린 것이다. 그리고 이런 상황은 조직에 대한 심리적 안정감을 떨어트리는 요인이 될 수 있다.
그래서 필자는 이렇게 소극적인 행동의 원인이 단순한 하드 스킬 수준의 차이가 아니라 내가 이 조직의 일원으로써 녹아들 수 있다는 자신감의 차이, 그리고 챕터에서 느끼는 심리적 안정감의 차이라고 생각했고, 오히려 스터디나 페어프로그래밍처럼 하드 스킬의 성장을 이끌어낼 수 있는 방향과는 다른 방향으로 접근해야겠다는 생각이 들었다.
F-Evangelist의 등장
앞서 이야기 했듯 2021년 Next Developer 프로그램을 끝마쳤을 때 즈음, 이제 프론트엔드 챕터의 인원은 거의 60명에 육박할 정도로 예전에 비하면 굉장히 거대한 조직이 되어버렸다.
그러다보니 예전과 달리 같은 프론트엔드 챕터끼리도 얼굴이나 이름을 모르는 사람들이 생기기 시작했고, 조직원들의 친밀도는 빠르게 낮아지기 시작했다. (OO님이 누구야? 라는 질문이 점차 많아지던 시절…)
이렇게 낮아진 친밀도는 챕터의 여러 의사결정에 대한 사람들의 참여도에도 좋지 않은 영향을 끼쳤고, 서로에 대해 피드백이나 심지어는 기술적인 의견을 자유롭게 주고 받는 문화도 점차 흐려지게 되었다. 그리고 이런 현상은 앞서 이야기했던 주니어 세그먼트에서 더 잦게 발생하고 있었다.
처음에는 챕터 내에서도 “그래도 예전같은 분위기를 만들기 위해 해볼 수 있는 것은 다 해봐야한다”라는 회귀파의 여론이 강했지만, 점차 시간이 흐르고 인원이 더 늘어나게 되자 현실을 인정하고 현재 챕터의 규모에 맞는 방법을 찾아야한다는 현실파 쪽으로 기울기 시작했다.
그 당시 필자는 처음부터 현실파 쪽에 가까웠는데, 필자가 강하게 주장했던 것은 모두 같은 나이, 비슷한 수준을 가지고 있는 학생 때도 40명 밖에 안 되는 같은 반 친구들조차 전부 친하게 지내지 못 하는데, 인원도 더 많고 하드스킬 수준에 따라 위계가 생겨버린 현재의 프론트엔드 챕터에서 어떻게 예전 같은 친밀도가 형성되기를 기대하냐는 것이었다.
즉, 이제 프론트엔드 챕터는 고작 10명 남짓으로 구성된 조직의 규모가 아닌 60명이 넘는 조직에서의 친밀도를 높히고 조직에 대한 심리적 안정감을 만들어낼 수 있는 새로운 방법을 강구해야했다.
심지어 동갑끼리 모인 같은 반 사람들 중에서도 진짜 친하게 지내는 친구는 보통 10명이 채 안된다
그런 이유로 인원이 가장 많았던 토스 코어 프론트엔드 챕터는 사람들을 더 작은 소그룹으로 나누고 그 안에서의 친밀도를 높혀 조직에 대한 심리적 안정감을 만들어냄과 동시에, 해당 그룹에 속한 사람들을 더 적극적으로 도와주고 성장의 방향성을 부어줄 수 있는 일종의 리드의 역할을 고민하게 되었다.
토스에는 작은 목적조직인 사일로들이 모여서 형성된 트라이브라는 조직이 있는데, 원래 이 트라이브에는 개발자들을 규합하는 T-Lead라는 역할이 한 명씩 존재한다. 하지만 T-Lead는 백엔드 분들이 주로 맡으시다보니 아무래도 자신들의 전문 분야가 아닌 프론트엔드 쪽에 대해서 적극적으로 방향성을 제시해주고 이끌어주는 것을 기대하기 어려운 상황이었다.
그런 이유로 지금까지의 프론트엔드 챕터는 챕터 단위로 의사결정을 내리고 액션아이템을 실천하고 있었지만, 챕터의 인원이 급격하게 늘어나며 조직의 밀도가 낮아지다보니 이제 프론트엔드 쪽에도 챕터 리드보다 더 가까이서 팀원들을 도와줄 수 있는 역할이 필요해졌던 것이다.
그래서 처음에는 T-Lead를 오마쥬한 F-Lead라는 이름의 역할을 만드려고 했었지만 아무래도 Lead라는 단어가 오히려 위계를 더 강화시킬 수 있다는 걱정도 들었고, 프론트엔드 챕터가 생각하는 리드의 역할은 다른 사람들을 관리하는 사람이 아니라 팀원들을 도와주는 사람이었기 때문에, 이름에서부터 이런 느낌이 강하게 드러났으면 좋겠다는 의견이 많았다.
즉, 다른 사일로를 지원해야하는 업무처럼 약간 Gray한 영역에 있는 일들이나 조직 개편같은 행정적인 일 혹은 1 on 1 커피챗을 통한 고민 상담 등을 수행하며 팀원들이 일에 더 집중할 수 있는 환경을 만들어주고, 프론트엔드 챕터의 인원들이 빠르게 성장할 수 있게 도와줌으로써 챕터 전체의 하드스킬과 소프트스킬을 상향평준화시키는 일종의 도우미같은 역할을 기대한 것이다. (그러면서 자기 사일로 업무도 다 해내야한…읍읍)
이런저런 아이데이션을 통해 재미있는 이름들이 많이 나왔지만 최종적으로는 F-Evangelist라는 이름의 역할이 탄생하게 되었고, 챕터의 문화나 심리적 안정감에 관심이 많았던 필자도 어쩌다보니 이 역할을 맡게 되었다.
내가 싼 똥 자랑하기
필자는 프론트엔드 챕터라는 조직 안에 있는 모든 사람들이 무엇이든 편하게 도전할 수 있고, 스스로 이상하다고 생각하는 것을 편하게 피드백할 수 있는 환경이 우선적으로 마련되어야 프론트엔드 챕터가 발전할 수 있다고 생각했었기 때문에, 처음 소그룹과 F-Evangelist가 등장했을 때부터 조직 내 친밀도를 높혀 사람들이 프론트엔드 챕터라는 조직 안에서 심리적 안정감을 느낄 수 있게 만드는 것에 집중해야한다는 의견을 꾸준히 밀었다.
당시 필자가 생각했던 최우선 과제는 필자의 그룹에 있는 주니어 구성원들이 자신보다 연차가 많은 개발자나 F-Evangelist와 같이 특정한 역할을 맡고 있는 개발자를 어려운 사람이 아닌 그냥 한 명의 동료 개발자로 느끼도록 만드는 것이었다.
아무리 위계를 만들기 싫다는 이유로 역할의 이름에서 리드라는 단어를 제거하기는 했지만, 실질적으로 하는 행동들을 보면 리드나 다름없기 때문에 이름 변경과 같은 소극적인 액션만으로 다른 사람들이 이 역할에 대해 느끼는 거리감이나 위계감이 완전히 제거되는 것을 바라는 것은 무리라고 생각했다.
게다가 토스 프론트엔드 챕터에는 여러가지 활동을 통해 네임 밸류가 쌓여있는 개발자들도 여럿 있었고, 주니어 분들은 네임 밸류가 높으면 막연하게 실력도 좋을 것이라고 생각하는 경향이 있었다. 필자는 안 그래도 하드 스킬에 대한 편차로 인해 위계가 발생하는 상황에서 이런 네임 밸류에 대한 오해까지 덧붙혀지면 조직 내 심리적 안정감을 만드는데 큰 방해가 될 것이라고 판단했기 때문에 이런 생각을 완전히 제거하고 싶었다. (유명한 것과 개발 잘 하는 것은 크게 상관관계가 없다)
그래서 필자가 가장 처음 했던 것은 바로 “똥 자랑 대회”였다.
일반적으로 개발자들은 아름다운 설계를 지향하지만 회사에서 개발을 하다보면 비즈니스 상황과 같은 외부 요인으로 인해 설계를 뭉개고 가는 경우도 있으며 바쁜 일정으로 인해 서두르다 버그를 내는 경우도 흔하다.
이런 상황에서 제대로 설계하지 않은 코드를 짜는 행위나 실수를 “똥을 쌌다”라고 표현하고는 하는데, 필자는 바로 이런 코드들을 서로 공유해보자고 제안했던 것이다. 물론 다소 캐쥬얼하기도 하고 더러운 이름이기는 하지만, 필자는 모두가 웃고 즐기며 실수를 편하게 공개할 수 있는 자리를 원했기 때문에 일부러 “부채 공유하기”나 “회고”와 같은 딱딱한 이름이 아닌 재미있는 이름을 선정했다.
필자의 그룹에는 토스가 완전 첫 직장인 신입 개발자부터 연차가 6~7년 정도 되는 개발자까지 다양한 세그먼트들이 분포해있었는데, 똥 자랑 대회를 진행함으로써 연차와 상관없이 개발자라면 누구나 다 실수를 할 수 있고 설계를 뭉개는 상황도 발생한다는 것을 알림과 동시에, 경험이 많은 개발자들이 이런 똥을 어떻게 치워나가는지, 그리고 어떤 사고 과정을 통해 설계를 뭉개서라도 속도를 챙기겠다는 의사결정까지 다다르는지와 같은 경험을 공유하는 것을 의도했다.
그러나 필자는 여기서도 한 가지 실수를 했는데, 하드스킬 수준에 따라서 스스로 똥이라고 생각하는 코드가 달랐던 것이다. 물론 상대적으로 해결 난이도가 낮은 똥에 대해서는 활발한 토론이 이루어졌고 문제 해결 방식도 제안되었지만, 하드스킬이 부족하다면 이해하는 것 자체가 어려운 똥에 대해서는 하드스킬 수준에 따라 참여도가 극명하게 갈렸다.
이 문제는 이미 이전에 진행했던 스터디나 오프라인 코드리뷰 등에서 발생했던 문제였지만, 처음 F-Evangelist를 맡았을 때의 필자는 얼른 심리적 위계를 제거하고 싶다는 마음만 앞서서 지난 실패에서 얻었던 경험을 잊어버리고 만 것이다.
사실 똥 자랑 대회에 대한 사람들의 후기는 나쁘지 않았지만, 필자가 원래 의도했던 심리적 위계를 제거하는 행위까지는 다다르지 못 한채로 첫 번째 액션아이템을 마무리하게 되었다.
강점찾기
이후 필자는 접근 방향을 바꿔서 기술적인 것 외적인 이야기를 서로 많이 나누어서, 개발자가 아닌 사람 대 사람으로써 친해질 수 있는 정보를 쌓아보자는 방식을 밀어보게되었다.
그래서 주말에 할 거 없는 사람들끼리 모여서 이쁜 카페에 가서 맛있는 것도 먹고 개인 작업도 하는 모각코 자리를 마련하거나 소그룹 위클리 미팅 시간을 잡담 타임으로 활용하는 등 여러가지 액션아이템을 계속 반복해서 수행하고 사람들의 반응을 관찰했다. 이렇게 몇 번의 액션아이템을 반복하다보니, 그룹 내에는 확실히 이전에 비해 친밀도가 형성되었고 이에 대한 조직 내 심리적 안정감도 형성되었다.
하지만 아직 필자가 해결하지 못 했던 이슈는 주니어 개발자 분들이 가지고 있는 “나는 아직 부족해”라는 부담감이었다. 물론 이러한 부담감이 건강하게 작용한다면 성장에 대한 훌륭한 동기 부여가 될 수 있었지만, 이런 생각이 너무 과해진다면 오히려 자신감이나 자존감 하락으로 이어져서 독이 될 수도 있다.
그러던 와중 필자는 같은 사일로의 디자이너 분이 어떤 스프레드시트를 보고 있는 것을 발견했는데, 그 시트는 바로 디자인 챕터에서 진행했었던 “강점찾기”라는 테스트의 결과지였다.
이 책을 사면 인터넷에서 강점찾기 테스트를 할 수 있는 코드를 준다
필자는 이런 종류의 테스트는 전혀 믿지 않는 편이라 처음에는 그냥 “디자인 챕터에서 또 재밌는 거 했네” 정도로 생각하고 넘어가려고 했으나, 이내 곧 이 테스트가 사람들의 부담감을 덜어줄 수 있는 좋은 메소드가 될 수도 있겠다는 생각이 들었다. (디자인 챕터가 은근히 이런 재밌는 걸 많이 한다)
성장에는 크게 두 가지 방법이 있는데, 한 가지는 내가 못하는 것을 더 잘하게 만드는 것이고, 다른 한 가지는 내가 이미 잘 하고 있는 부분을 더 잘하게 만드는 방법이다. 하지만 일반적으로 한창 성장하는 시기의 개발자들은 자신이 이미 잘 하고 있는 것보다 자신이 못 하는 것에만 집중하고 그 부분을 채우려고 하는 성향이 크다.
비록 자신이 못 하는 것에 집중하고 보완하는 것이 좋은 성장의 방법이기는 하지만, 자칫 “난 이걸 못해”라는 부정적인 생각에 너무 빠지다보면 스스로를 너무 몰아세워 건강을 해치면서까지 공부나 일을 한다거나, 주변의 개발자들과 자신을 비교하며 좌절하는 상황도 발생할 수 있다.
그래서 필자는 강점찾기라는 테스트를 통해서 사람들이 스스로 “자신이 잘 하는 것이 무엇인지”를 알 수 있도록 메타인지를 심어주면, 자신의 약점에만 집중하는 것이 아닌 강점과 약점을 모두 알게 되면서 스스로에 대한 자신감도 생기지 않을까하는 생각을 했던 것이다.
이후 이 생각에 대해 다른 프론트엔드 개발자 분들에게 이야기를 했는데, 이에 공감해주시는 두 분이 조인하여 우리끼리 강점찾기를 한번 직접 진행해보기로 했다. 이때 디자인 플랫폼팀 소속인 프론트엔드 개발자 분은 이미 디자인 챕터와 함께 강점찾기를 진행해보신 경험이 있었기 때문에, 당시의 경험을 살려 프론트엔드 챕터에 맞는 방식을 찾아나가는 과정에 큰 도움을 주셨다.
강점찾기 프로그램을 진행하는 방법은 굉장히 심플했는데, 그냥 회사에 요청을 해서 책을 구매한 뒤 각자 테스트를 진행하고 PDF로 나온 테스트 결과지를 다시 강점찾기 슬랙 채널에 공유하면, 이후 오프라인으로 모여서 진행자가 각자의 결과지를 해설해주는 것이다.
이때 진행자는 팀원들의 강점 결과를 단순히 읽어주기보다는 강점찾기에 참여한 팀원들이 서로의 강점에 대해서 공감하고 기억할 수 있는 환경을 만들어주는 역할을 하는데, 진행자의 액션아이템은 대략 이런 느낌이었다.
- 결과지를 단순히 읽어주는 것이 아니라, 실제로 토스팀에서 경험해볼 수 있는 상황들을 예를 들어주는 것이 좋다.
- 팀원들의 강점을 한 줄로 요약 정리해서 다른 사람들이 기억하기 쉽도록 만들어주자.
- 내 강점 중 다른 사람들이 더 관심을 가져줬으면 하는 부분에 하이라이팅을 하도록 시키자.
- 서로의 강점을 더욱 더 강화시킬 수 있는 액션아이템을 정해주도록 시키자.
강점찾기의 목적에는 스스로 무엇을 잘 하는지에 대한 메타인지를 키우도록 하는 것도 있었지만, 하나의 팀으로 일을 한다는 것이 얼마나 다양한 강점을 가진 사람들이 모여 시너지를 만드는 과정인지 알려주는 것도 있었기 때문에, 단순히 스스로 강점을 알고 끝나는 것이 아니라 적극적으로 서로의 강점을 인지하고 더 강화시키기 위한 활동도 추가적으로 진행했다.
이렇게 강점찾기에 대한 PoC를 진행해보니 생각보다 각자의 강점에 대해서 상세하게 설명해주기도 하고 재미도 있어서, 곧 필자가 리딩하고 있는 소그룹에서도 강점찾기를 진행해보았다.
그 당시 필자는 팀원들이 이 프로그램을 업무의 일환이라고 느끼게 만들고 싶지 않았기도 했고, 어차피 개발과 조금 동떨어진 느낌의 프로그램을 진행하는 김에 아예 하루 일탈하는 기분도 내기를 바라서 사무실이 아닌 충무로에 있는 이쁜 카페에 모여서 강점찾기 프로그램을 진행했다.
결과는 생각보다 좋았다. 솔직히 이런 테스트에는 어떠한 과학적 근거도 없으니 사람들이 믿지 않을 수도 있기 때문에 큰 기대는 하지 않았지만, 생각보다 다들 자신의 강점을 알아보며 기뻐해주셨고, 좋은 개발자라는 것이 한 가지 모습이 아니라 여러 가지 모습이라는 것, 프론트엔드 챕터는 다양한 강점을 가진 사람들이 모여서 시너지를 만들어내야하는 팀이라는 것들에 크게 공감해주셨다.
물론 필자는 커피챗 등을 통해 팀원들에게 이런 이야기들을 많이 해줬었지만, 백 마디 말보다 이런 프로그램이나 캠페인을 한 번 진행하는 것이 더 효과가 좋다는 점에 큰 감명을 받았다.
이후 소그룹에서 좋은 결과를 얻었던 필자는 F-Evangelist 미팅에서 강점찾기의 목적과 방법을 설명하며 전도하기 시작했다. 원래 목적은 토스 코어에서 우선 테스트해보고 반응이 좋으면 다른 계열사로 수출하는 그림을 그렸었는데, 강점찾기 채널을 눈팅하고 있던 다른 계열사 프론트엔드 개발자 분들이 강점찾기를 알아서 퍼나르기 시작하면서 갑자기 강점찾기를 수출당해버렸다.
원활한 수출을 위해 강점찾기 진행자를 위한 가이드라인도 작성했었다
아쉽게 필자는 이때쯤 퇴사를 했기 때문에 이후 강점찾기가 어떻게 진행되었는지 자세히는 알지 못 하지만, 퇴사 후 건너건너 듣기로는 다른 프론트엔드 개발자 분들도 재밌어했다는 후기도 들었고, 심지어는 DS(Data Scientist)팀에서도 강점찾기를 진행했다는 얘기도 들었다. (수출 속도가 어마무시하다…)
마치며
토스에서 일했던 지난 2년 반은 필자에게 있어서 많은 성장의 밑거름을 만들어 낼 수 있었던 시간이었다. 물론 토스는 일이 많고 빡세긴 하지만 그 만큼 일과 성장에 대한 몰입도가 높은 조직이었다는 생각이 든다.
능력있는 동료들과 서로 신뢰하면서 일을 한다는 것이 어떤 기분인지, 아침에 제품 아이데이션을 하고 저녁에 배포하는 미친 속도감이 무엇인지, 그리고 이런 생산성을 만들어 낼 수 있는 원동력이 무엇인지 등 많은 경험과 고민들을 할 수 있었다.
마지막 퇴사자 면담에서 POM(People Operation Manager)이 필자에게 “동욱님이 토스에 다시 돌아오게 하려면, 토스팀은 어떤 점을 보완해야할까요?”라는 질문을 했었는데, 그때 필자는 “내가 다시 돌아온다면, 아마 토스에 있는 것들이 다른 곳에는 없다는 것을 느낄때일 것 같다”라고 답변했었다. 그만큼 필자는 이 조직에 대한 만족도가 높았던 것 같다. (지나고 나서 보니 뭔가 멋진 대사인듯…?)
이제 토스는 필자가 입사했을 당시의 300명짜리 스타트업이 아니라 2,000명 규모의 머기업이 되어버렸다. 그러니 당연히 그 시절의 토스와는 달라진 부분들이 있고, 필자는 그 부분에서 묘한 향수감과 아쉬움을 느끼고 있기는 하다. 예전에는 챕터든 사일로든 진짜 친한 친구들이랑 으쌰으쌰 일 하는 느낌이었다면, 최근에는 조금 더 회사원 같아진 느낌이랄까.
하지만 이제 토스는 예전의 모습으로 돌아갈 수는 없을 것이다. 300명짜리 문화와 2,000명짜리 문화는 당연히 다를 수 밖에 없기 때문이다.
그래서 필자는 이번에 작은 스타트업으로 이직을 하면서, 업무에 몰입하여 미친 생산성을 만들어내는, 예전에 필자가 사랑했던 그 문화를 직접 만들어내어 제품을 성공의 길로 이끌어내는 경험을 해보고 싶었다.
필자가 이직한 쿼타랩이라는 스타트업에서도 역시 프론트엔드 개발자를 절찬리 채용 중이니, 이 글을 읽는 독자분들 중에서도 혹시 이런 미친 생산성을 만들어내는 문화를 조직에 도입하고 그 문화를 기반으로 제품을 성공시키는 경험을 해보고 싶으신 분들이 있다면 지원해주셨으면 한다. (IT는 진짜 인재밀도랑 문화가 다 해먹는다)
