
‘온전한 자율과 철저한 책임’으로 만드는 최초의 비상장 금융 인프라
쿼타랩 프론트엔드 챕터 이야기
2023. 7. 21.
쿼타랩은 챕터와 스쿼드로 이루어져 있습니다. 같은 직무를 하는 팀이 챕터, 같은 제품이나 기능을 만드는 팀이 스쿼드입니다. 그 중에서도 오늘은 쿼타랩 프론트엔드 챕터의 이야기를 준비했습니다. 각기 다른 스쿼드에 속한 개인으로서, 또한 서로 같은 직무를 함께 하는 팀으로서 이들은 어떻게 일하고 있을까요?
각자 자기소개를 부탁드립니다.
에반(Frontend Chapter Lead): 프론트엔드 개발자 문동욱입니다. 2016년부터 개발을 시작해서 다양한 스타트업을 거쳐왔습니다. 시리즈 A에서 D로 라운드를 뛰거나, 인원이 300명에서 2,000명 이상으로 변하는 등 빠르게 성장하는 조직에서 일해본 경험이 많습니다.
현재는 쿼타랩에서 프론트엔드 챕터 리드와 VC 스쿼드의 엔지니어링 매니저 역할을 맡고 있습니다. 때때로 프론트엔드 리소스가 부족한 스쿼드를 지원하기도 합니다.
윤(Frontend Engineer): 1년 차 프론트엔드 개발자 백승윤입니다. 프론트엔드 개발자로서는 쿼타랩이 첫 직장입니다.
노엘(Frontend Engineer): 프론트엔드 개발자 김민혁입니다. 고등학교를 졸업한 2020년 모바일 개발로 커리어를 시작했고, 두 번째 직장에서 시스템 개발과 프론트엔드 개발에 깊게 관여한 것을 계기로 세 번째 직장인 쿼타랩에서는 프론트엔드 개발자로 자리 잡아 일하고 있습니다.
여러분은 스스로 어떤 개발자라고 생각하나요?
노엘(Frontend Engineer): 어려운 질문이네요. 필요하다면 무엇이든 할 수 있는 개발자라고 생각합니다.

프론트엔드 엔지니어 노엘과 에반
에반(Frontend Chapter Lead): 제가 가진 능력으로 세상을 바꾸는 일에 매력을 느끼는 개발자인 것 같습니다. 제품이 실질적으로 사람들의 삶을 편하게 만들어 주고, 이에 따라 회사가 성장할 때 큰 기쁨을 느껴요. 다른 사람의 성장을 돕거나 조직을 성장시키는 일에도 관심이 많습니다.
윤(Frontend Engineer): 커뮤니케이션 잘하는 개발자를 지향합니다. 동료들과 문제를 해결하다 보면, 개발 이전에 커뮤니케이션을 통해 이슈를 해결하거나 시간 및 비용을 줄일 수 있는 사례도 많더라고요. 일 잘하는 개발자가 되기 위해서는 커뮤니케이션 능력도 필수로 가져야 하죠.
쿼타랩 프론트엔드 개발자로 일하는 장점은 무엇인가요?
노엘(Frontend Engineer): 경험해 본 제품 중 쿼타북은 복잡도가 정말 높은 편이에요. 비즈니스 도메인 자체도 난이도가 있고, 하나의 기능에 얽힌 여러 이해관계를 고려하기도 쉽지 않죠. 현재 개발과 함께 설계도 직접 하고 있는데, 쿼타북에서 잘 해낼 수 있다면 개발자로서 급성장할 수 있겠다는 생각을 자주 합니다.
윤(Frontend Engineer): 크게 세 가지 정도가 있는데요. 먼저, 다양한 직군과 협력하며 제품을 제로(0)부터 구축하는 경험을 할 수 있습니다. 프로덕트 디자이너, 백엔드 개발자, 프로덕트 매니저, 데브옵스(DevOps) 개발자 등 다양한 직군의 이해관계자와 소통하며 제품을 만들어 가는 과정이 가끔 도전적일 수 있지만, 개발자로서 제품에 직접 기여할 수 있는 즐거움을 느끼고 있습니다.
또, 프론트엔드 분야의 최신 기술 동향과 이슈를 팀에서 함께 고민하고, 우리 제품에 맞추어 적용하는 재미가 있습니다. 단순히 남들이 하니까 나도 하는 기계적인 개발이 아니라는 점이 특히 매력적이에요.
마지막으로, 비상장 증권 도메인에 대한 지식을 습득하게 됩니다. 비상장 증권 시장에서의 어려움을 해결해 나가고 있는 쿼타북을 만들다 보면, 주식, 스톡옵션, RSU 등에 대해 필요하면서도 어려운 개념들을 자연스럽게 체득해 나갈 수 있어요.
에반(Frontend Chapter Lead): 특히 비상장 증권 지식은 창업을 꿈꾸는 개발자라면 꼭 필요합니다. 미래에 자신만의 비즈니스를 하고 싶어 하는 개발자가 적지 않거든요. 만들고자 하는 서비스가 있으면 처음부터 끝까지 자기가 만들 수 있으니까요. 그래서 사이드 프로젝트를 하거나 회사를 아예 그만두고 창업을 하는 사례도 꽤 많은 편이죠. 윤도 나중에 창업하고 싶다고 하지 않으셨나요?
윤(Frontend Engineer): 맞아요. 스타트업 설립 후 어떤 경영 관리가 필요한지 미리 알아가는 중입니다.
에반(Frontend Chapter Lead): 말하자면 창업 전 집중적인 예행연습이네요.
쿼타북 프론트엔드 개발자로 일하는 것의 큰 장점 중 하나는 개선과 변화를 주는 가능성을 직접 갖게 된다는 점입니다. 대규모 조직에서는 개인의 영향력이 제한적일 수 있어요. 예를 들어 2천 명 규모에 있는 조직에서 영향력과 50명 규모의 조직에서의 영향력은 아무래도 차이가 있을 테고요. 하지만 쿼타랩은 초기 스타트업이라 다양한 도전이 가능합니다. 명확한 근거와 설득력만 있다면 변화를 두려워하지 않는 동료들과 함께 무엇이라도 시도할 수 있어요. 쿼타랩 프론트엔드 챕터는 현재 챕터원들처럼 일을 진심으로 좋아하는 분들을 모시기 위해 노력하고 있습니다. 앞으로도 문제 해결에 집중하며 치열하게 논의하는 경험을 계속해 나가기 위해서요.

쿼타랩 프론트엔드 챕터
쿼타북 프론트엔드 챕터는 어떤 팀인가요?
에반(Frontend Chapter Lead): 온전한 자율과 철저한 책임을 충실하게 실현해 내기 위해 노력하는 챕터입니다.
쿼타랩의 프론트엔드 개발자들은 모두 자신이 담당하는 서비스에 대한 기술적 의사결정에 대한 DRI(Directly Responsible Individual, 최종 의사결정권자)입니다. 권한은 서로에 대한 신뢰를 기반으로 주어지는 것이기 때문에 동료들의 신뢰를 얻고 유지하기 위해 각자 끊임없이 고민하고 노력해야 하죠. 반대로 말하면 신뢰만 얻을 수 있다면 이후로는 내가 하고 싶은 모든 것을 도전해 볼 수 있는 팀이라고 할 수 있어요.
챕터 리드라도 다른 프론트엔드 개발자가 정한 바를 침해할 수 없어서 저 역시도 항상 동료를 설득하고 공감시키기 위해 많은 노력을 기울이고 있습니다.
윤(Frontend Engineer): 챕터원들의 공통점은 멈춰 있는 것을 견디지 못한다는 점이에요. 챕터가 모두 서로에게 자극받으며 꾸준히 성장하고자 하는 욕심이 있는 분들로 구성되어 있어요.
동료들의 자율성을 최대한 보장해 주고 가장 효율적으로 일할 수 있는 방법을 고민해 주는 리드가 있다는 점도 챕터원으로서 자랑거리이고요.
노엘(Frontend Engineer): 챕터의 모두가 각기 다른 강점을 가지고 있어요. 이 강점을 챕터 내에서 발휘하고 전파할 수 있는 능력이 있다는 점이 특징이라고 생각합니다. 한 챕터원이 가진 약점을 다른 챕터원이 보완하는 일이 가능하죠.
예를 들면 저는 설계의 중요성을 크게 생각하고, 꽤 많은 시간을 들여 설계를 최대한 잘하고자 노력하는 성향이에요. 혼자 잘 해내고 끝이 아니라 챕터 내에서 이를 공유하여 공동의 성장 기회를 만들고 있습니다. 반면 저에게 부족한 커뮤니케이션 능력은 에반이나 윤으로부터 적극적인 도움과 조언을 받아 개선해 나가고 있고요.
에반(Frontend Chapter Lead): 저는 비즈니스를 좋아하고 회사 자체에 관심이 많다는 점이 스스로 강점이라고 생각해요. 또 개인의 상태나 심리를 섬세하게 살피고 도움을 줄 수 있어요.
체력 관리를 잘 못한다는 점이 약점인데요. 업무에 집중하기 위해서 필요성을 크게 느끼고 있어서, 컨디션 관리에 일가견이 있는 윤에게 방법을 배우고 있습니다.
쿼타북 프론트엔드에서 어떤 일을 하고 있나요?
에반(Frontend Chapter Lead): 저는 챕터 리드로서 동료들이 "일에만 집중할 수 있는 환경"을 만들기 위해 노력하고 있어요. 개인적으로 제가 생각하는 이상적인 리더는 동료들이 만족스러운 환경에서 행복하게 일할 수 있도록 서포트하는 사람이에요. 직접 선택한 일을 할 때 인간은 자기효능감이 가장 커진다고 생각하기 때문에 동료들이 스스로 옳다고 생각하는 방향으로 결정하고 움직일 수 있도록 도우려고 합니다. 다만 이런 리더십은 의사결정 권한을 타인에게 넘겨주되, 책임은 자신이 져야 한다는 의미이기도 해서 많은 용기가 필요하죠. 그런 용기를 낼 수 있는 리더이자 동료가 되기 위해 계속해서 노력하는 중입니다.
한편으로 리드로서 프론트엔드 챕터의 목표와 방향성을 제안하고, 모호한 문제를 해결하거나 동료들이 겪고 있는 어려움을 해소하기 위해 노력하고 있어요. 동료들이 자기가 맡은 일에 집중하면서 다른 것들에 신경을 쓰지 않도록 지원하는 역할이죠. 좀 더 많은 문제와 다양한 상황을 경험하면서 시행착오를 겪었기 때문에 역할에 자신감을 가지고 일하고 있어요.
노엘(Frontend Engineer): VC 스쿼드 소속 메이커로 투자자 고객을 위한 서비스를 개발하고 있어요. 동시에 챕터 차원에서 함께 쓸 수 있는 추상적인 모듈을 설계하고 있습니다. 생산성을 10X 할 수 있는 여러 가지 방법을 고민하고 있어요. 한 번의 견고한 설계로 여러 사람이 편의를 얻을 수 있는 일이라 보람이 있죠.
윤(Frontend Engineer): 저는 프론트엔드 챕터 소속이자, 스타트업 스쿼드 소속 개발자로서 스타트업 고객사의 문제를 해결하는 일을 하고 있어요. 가장 최근에는 스타트업 고객사가 투자사에게 영업보고할 때 겪는 불편을 해결하는 과정을 함께 고민하고 개발하는 일을 하고 있어요. 다수의 투자를 받은 스타트업은 여러 투자사를 대상으로 여러 차례 중복된 보고를 해야하고, 반대로 투자사는 여러 포트폴리오 스타트업을 대상으로 중복해서 보고를 요청해야하는 번거로움이 있는데, 이런 불편함을 한 번에 해결해 주는 멋진 제품을 동료들과 만들고 있습니다.
쿼타북 프론트엔드 챕터의 특별한 개발 문화가 있나요?
에반(Frontend Chapter Lead): 우리 챕터에는 ‘허락보다 용서가 쉽다’는 말이 있습니다. 원하는 코드가 있다면 우선 작성하고, 논의는 그 다음에 하는 거죠.
저는 뭔가 하고 싶다는 마음 자체가 굉장히 소중하다고 생각하거든요. 일반적인 직장인처럼 일한다면 그냥 시키는 대로 하게 되는 경우가 많잖아요. 하고 싶다는 마음은 누구에게나 언제나 있는 게 아니라는 거죠. 소중한 마음이 정말 임팩트를 내기 위해서는 이걸 구현해 내고 실천까지 해내는 데 있어 아무런 심리적 허들도 있어서는 안 된다고 봅니다.
만약 뭔가 하려고 할 때 챕터의 6명을 모두 설득해야 한다면 굉장히 큰 심리적 허들이 생긴다고 보는 거죠. 아무래도 실행 전 논의가 많아지게 되면 누구나 편하게 기여할 수 있는 일임에도 불구하고 논의에 대한 피로도 때문에 망설이게 되기도 하고요. 차라리 그걸 없애고 리뷰는 어차피 하게 될테니 그때 철저히 논의하자는 거예요. 만들어진 코드를 보면서 이야기하면 이해도 더 잘 될 테고요.
이런 시도를 통해 더 빠른 실행과 실패를 거듭하면서 미친 속도로 성장하자는 모두의 약속이에요. 각자에 대한 신뢰를 기반으로 리뷰 전까지 모든 시도를 자유롭게 하되, 리뷰와 배포 이후 발생하는 일에 대한 책임은 챕터 전체가 함께 지고 가자는 공감대를 가지고 있습니다.
윤(Frontend Engineer): 코드 리뷰 이야기가 나왔는데, 저는 쿼타랩의 코드 리뷰 퀄리티와 속도는 업계 최고 수준이라고 자신해요. 누가 강제하지 않아도, 동료 개발자의 코드 퀄리티와 성장을 위해 말 그대로 ASAP 리뷰를 해 주는 동료들이 있어요. 개발을 사랑하는 이들로만 구성된 챕터가 누릴 수 있는 장점 중 하나죠.

프론트엔드 엔지니어 윤
코드 리뷰의 퀄리티와 속도에 대해 어떻게 자신할 수 있나요?
에반(Frontend Chapter Lead): 챕터에 코드 리뷰를 올리면 “좋네요”하고 넘어가는 경우가 정말 드물어요. 이상한 코드는 없는지, 더 개선할 점은 없는지 강하게 챌린지 들어오는 경우가 많죠. 이 과정에서 의견 충돌이 있더라도 언제나 코드의 퀄리티를 고려하여 논의를 피하지 않습니다.
‘남들 다 하니까’, ‘해야 하니까’하는 리뷰는 저희에게 존재하지 않습니다. 리뷰는 제대로 해야 리뷰고, 그렇지 않으면 단순한 승인에 가깝게 돼요. 쿼타랩 프론트엔드 챕터는 400건의 리뷰라면 400번 치열하게 함께 고민하고 논의합니다. 실제로 이번 한 주에만 챕터에서 425건 정도 작업 내용을 머지(merge)했는데요. 그 말인 즉슨 425건의 치열한 토론이 발생했다는 거겠죠?
쿼타북 프론트엔드 챕터가 원팀으로 일하기 위해 만들어 나가고 있는 그라운드룰은 무엇인가요?
노엘(Frontend Engineer): 사실 필요하지 않은 룰은 만들지 않는 편이 좋다는 데 다들 공감대가 있어요. ‘DRI의 권한을 침해하지 않기’처럼 정말 필요한 룰만 정확히 만들어 지킵니다.
에반(Frontend Chapter Lead): 맞아요. 재미있게 일을 하려면 자유가 있어야 합니다. 자유가 없이 일을 한다면 재미가 있을 수 없죠. 다만 이런 자유에 따라오는 책임도 진다는 동의가 모두에게 있어요. 저희 팀원들에게는 이 책임에 대한 역량도 있다고 믿고 있습니다.
앞서 잠깐 이야기했듯 “머지 후 발생하는 모든 이슈에 대해 챕터 전체가 책임진다”는 암묵적인 룰이 있는데요. 운영 환경에 코드가 배포되었다는 것은 코드 작성자 외에도 챕터가 그 코드에 동의했다는 것을 의미해요. 코드 리뷰는 챕터 누구라도 함께 할 수 있고요. 그렇기 때문에 운영에 배포된 코드에서 문제가 발생했다면 코드 작성자나 그 버그를 잡아내지 못 한 리뷰어만의 책임이 아니라, 리뷰에 참여할 자유가 있었음에도 리뷰하지 못했던 프론트엔드 챕터 모두의 책임이 되는 것이죠. 이런 룰은 챕터 전체를 더 강한 ‘원팀’으로 일할 수 있게 해주는 것 같습니다.
이렇게 동료의 자율성을 존중하고 함께 책임을 지는 문화가 쿼타랩 프론트엔드 챕터를 더 끈끈한 원팀으로 만들어주는 것이라 생각합니다.
윤(Frontend Engineer): 제가 생각하는 우리 챕터의 그라운드룰은 ‘상호 존중’인 것 같아요. 하드 스킬 레벨과 상관 없이 동료들의 의사 결정 과정이 신뢰할 만하다면, 그것을 믿고 지원해 주고, 또 조언도 아끼지 않는 문화가 있어요. 다만 무조건적인 존중과 신뢰는 아니에요. 아닌 것은 아니라고 얘기하는 조직이기 때문에 더욱 서로에 대한 신뢰가 높아지는 것 같아요.

쿼타랩 프론트엔드 챕터 리드 에반
앞으로 어떤 목표를 가지고 있나요?
에반(Frontend Chapter Lead): 조직 관점에서는 프론트엔드 챕터뿐 아니라 쿼타랩 팀에서 일하는 모든 동료가 자신이 전문성을 가진 범위 내에서 온전한 자율과 책임을 행사할 수 있는 조직을 만드는 것이 목표예요.
이런 조직이 되기 위해서는 동료들 간의 두터운 신뢰가 필수적인데요. 이런 신뢰를 만들어 내기 위해서는 좋은 채용을 통해 뛰어난 동료를 모으는 것, 의사결정권을 위임하기 위한 리더들의 용기, 모두가 같은 곳을 보고 달릴 수 있는 조직 전체의 명확한 비전과 목표 등 다양한 요소들이 모두 충족되어야 합니다.
물론 지금도 쿼타랩은 높은 수준의 자율과 책임 문화를 실천하고 있는 조직이지만, 초기 스타트업인 만큼 아직 더 성장할 수 있는 잠재력과 능력이 많이 남은 조직이기도 합니다. 여기서 제 목표와 역할은 쿼타랩을 지금보다 더 훌륭한 팀으로 만들기 위해 더 좋은 방법을 강구하고 빠르게 실천하는 것이라고 생각해요.
개인적으로는 멘토링이나 글을 통해 제가 해온 경험을 다른 사람들과 나누고 그분들의 성장을 돕는 삶을 살고 싶습니다.
윤(Frontend Engineer): 더 많은 고객들과 투자사들을 하루라도 빨리 모시게 되면 좋겠습니다. 저 역시 맡은 역할이 있지만 그 이전에 스타트업의 구성원이다 보니, 함께 소중한 시간을 보내고 있는 훌륭한 동료들의 노력이 잘 쓰이며 빛을 발할 수 있기를 바라고 있습니다.
개인적으로는 세상에 나만의 것을 내놓는다는 목표로 일하고 있어요. 앞으로 5년 내에 창업하는 것이 목표에요.
어떤 동료와 함께 하기를 기대하나요?
에반(Frontend Chapter Lead): 일을 그저 일로써만 대하지 않는 동료들과 함께하고 싶어요.
개발을 하는 것, 내 능력을 통해 세상을 바꾸고 비즈니스 임팩트를 만들어내는 행위가 그저 인생의 일부가 아닌 정말로 이런 가치를 달성하는 것이 내 인생의 우선순위 1순위인 동료들과 함께한다면, 아무리 일이 많거나 어렵더라도 함께 등을 맞대고 헤쳐 나갈 수 있을 것 같아요.
윤(Frontend Engineer): 쿼타북의 도메인이 비상장 증권 도메인이라 다소 딱딱하거나 어렵게 느껴지실 수 있지만, 정해진 룰 밖에서 자신만의 방식으로 문제를 해결해 나가는 분들만 모여있는, 딱딱함과는 다소 거리가 먼 조직이에요. 이런 멋진 동료들과 함께 문제를 제대로 해결하고 싶으신 분과 함께라면 가슴이 뛸 것 같네요.
지원하는 분들에게 미리 알려주고 싶은 팁은?
노엘(Frontend Engineer): 아주 현실적인 팁이라면 이력서 스킬셋(Skill Set, 능력) 부분에 스스로 레벨이나 점수를 매기지 않는 것을 추천해요. 검토하는 입장에서 특정한 기대치가 생겨날 수 있어 유의해야 합니다.
에반(Frontend Chapter Lead): 마지막으로 개발자로서의 역량은 학력이나 경력보다는 코드 자체로 판단합니다. 이를 확인할 수 있는 깃헙(GitHub) 링크를 꼭 공유해 주시면 좋아요. 깃헙에는 확인할 수 있는 프로젝트를 올려두거나 어필하고 싶은 특이 사항이 있다면 이를 주의 깊게 봐달라는 설명을 덧붙여서 주시면 정확한 검토와 평가에 더욱 도움이 됩니다.
쿼타랩 프론트엔드 챕터는 자율과 책임을 기반으로 빠르게 실행하고 개선하며 성장을 거듭하고 있습니다. 국내 최초로 ‘비상장 금융 인프라’를 함께 만들어 나갈 뛰어난 동료를 찾고 있으니, 아무도 가보지 않은 길을 개척해보고 싶으신 분들의 많은 관심 부탁드립니다.

QuotaLab Team
여러 세대를 위한 최초의 비상장 금융 인프라를 만들어 갑니다.

‘온전한 자율과 철저한 책임’으로 만드는 최초의 비상장 금융 인프라
쿼타랩 프론트엔드 챕터 이야기
2023. 7. 21.
쿼타랩은 챕터와 스쿼드로 이루어져 있습니다. 같은 직무를 하는 팀이 챕터, 같은 제품이나 기능을 만드는 팀이 스쿼드입니다. 그 중에서도 오늘은 쿼타랩 프론트엔드 챕터의 이야기를 준비했습니다. 각기 다른 스쿼드에 속한 개인으로서, 또한 서로 같은 직무를 함께 하는 팀으로서 이들은 어떻게 일하고 있을까요?
각자 자기소개를 부탁드립니다.
에반(Frontend Chapter Lead): 프론트엔드 개발자 문동욱입니다. 2016년부터 개발을 시작해서 다양한 스타트업을 거쳐왔습니다. 시리즈 A에서 D로 라운드를 뛰거나, 인원이 300명에서 2,000명 이상으로 변하는 등 빠르게 성장하는 조직에서 일해본 경험이 많습니다.
현재는 쿼타랩에서 프론트엔드 챕터 리드와 VC 스쿼드의 엔지니어링 매니저 역할을 맡고 있습니다. 때때로 프론트엔드 리소스가 부족한 스쿼드를 지원하기도 합니다.
윤(Frontend Engineer): 1년 차 프론트엔드 개발자 백승윤입니다. 프론트엔드 개발자로서는 쿼타랩이 첫 직장입니다.
노엘(Frontend Engineer): 프론트엔드 개발자 김민혁입니다. 고등학교를 졸업한 2020년 모바일 개발로 커리어를 시작했고, 두 번째 직장에서 시스템 개발과 프론트엔드 개발에 깊게 관여한 것을 계기로 세 번째 직장인 쿼타랩에서는 프론트엔드 개발자로 자리 잡아 일하고 있습니다.
여러분은 스스로 어떤 개발자라고 생각하나요?
노엘(Frontend Engineer): 어려운 질문이네요. 필요하다면 무엇이든 할 수 있는 개발자라고 생각합니다.

프론트엔드 엔지니어 노엘과 에반
에반(Frontend Chapter Lead): 제가 가진 능력으로 세상을 바꾸는 일에 매력을 느끼는 개발자인 것 같습니다. 제품이 실질적으로 사람들의 삶을 편하게 만들어 주고, 이에 따라 회사가 성장할 때 큰 기쁨을 느껴요. 다른 사람의 성장을 돕거나 조직을 성장시키는 일에도 관심이 많습니다.
윤(Frontend Engineer): 커뮤니케이션 잘하는 개발자를 지향합니다. 동료들과 문제를 해결하다 보면, 개발 이전에 커뮤니케이션을 통해 이슈를 해결하거나 시간 및 비용을 줄일 수 있는 사례도 많더라고요. 일 잘하는 개발자가 되기 위해서는 커뮤니케이션 능력도 필수로 가져야 하죠.
쿼타랩 프론트엔드 개발자로 일하는 장점은 무엇인가요?
노엘(Frontend Engineer): 경험해 본 제품 중 쿼타북은 복잡도가 정말 높은 편이에요. 비즈니스 도메인 자체도 난이도가 있고, 하나의 기능에 얽힌 여러 이해관계를 고려하기도 쉽지 않죠. 현재 개발과 함께 설계도 직접 하고 있는데, 쿼타북에서 잘 해낼 수 있다면 개발자로서 급성장할 수 있겠다는 생각을 자주 합니다.
윤(Frontend Engineer): 크게 세 가지 정도가 있는데요. 먼저, 다양한 직군과 협력하며 제품을 제로(0)부터 구축하는 경험을 할 수 있습니다. 프로덕트 디자이너, 백엔드 개발자, 프로덕트 매니저, 데브옵스(DevOps) 개발자 등 다양한 직군의 이해관계자와 소통하며 제품을 만들어 가는 과정이 가끔 도전적일 수 있지만, 개발자로서 제품에 직접 기여할 수 있는 즐거움을 느끼고 있습니다.
또, 프론트엔드 분야의 최신 기술 동향과 이슈를 팀에서 함께 고민하고, 우리 제품에 맞추어 적용하는 재미가 있습니다. 단순히 남들이 하니까 나도 하는 기계적인 개발이 아니라는 점이 특히 매력적이에요.
마지막으로, 비상장 증권 도메인에 대한 지식을 습득하게 됩니다. 비상장 증권 시장에서의 어려움을 해결해 나가고 있는 쿼타북을 만들다 보면, 주식, 스톡옵션, RSU 등에 대해 필요하면서도 어려운 개념들을 자연스럽게 체득해 나갈 수 있어요.
에반(Frontend Chapter Lead): 특히 비상장 증권 지식은 창업을 꿈꾸는 개발자라면 꼭 필요합니다. 미래에 자신만의 비즈니스를 하고 싶어 하는 개발자가 적지 않거든요. 만들고자 하는 서비스가 있으면 처음부터 끝까지 자기가 만들 수 있으니까요. 그래서 사이드 프로젝트를 하거나 회사를 아예 그만두고 창업을 하는 사례도 꽤 많은 편이죠. 윤도 나중에 창업하고 싶다고 하지 않으셨나요?
윤(Frontend Engineer): 맞아요. 스타트업 설립 후 어떤 경영 관리가 필요한지 미리 알아가는 중입니다.
에반(Frontend Chapter Lead): 말하자면 창업 전 집중적인 예행연습이네요.
쿼타북 프론트엔드 개발자로 일하는 것의 큰 장점 중 하나는 개선과 변화를 주는 가능성을 직접 갖게 된다는 점입니다. 대규모 조직에서는 개인의 영향력이 제한적일 수 있어요. 예를 들어 2천 명 규모에 있는 조직에서 영향력과 50명 규모의 조직에서의 영향력은 아무래도 차이가 있을 테고요. 하지만 쿼타랩은 초기 스타트업이라 다양한 도전이 가능합니다. 명확한 근거와 설득력만 있다면 변화를 두려워하지 않는 동료들과 함께 무엇이라도 시도할 수 있어요. 쿼타랩 프론트엔드 챕터는 현재 챕터원들처럼 일을 진심으로 좋아하는 분들을 모시기 위해 노력하고 있습니다. 앞으로도 문제 해결에 집중하며 치열하게 논의하는 경험을 계속해 나가기 위해서요.

쿼타랩 프론트엔드 챕터
쿼타북 프론트엔드 챕터는 어떤 팀인가요?
에반(Frontend Chapter Lead): 온전한 자율과 철저한 책임을 충실하게 실현해 내기 위해 노력하는 챕터입니다.
쿼타랩의 프론트엔드 개발자들은 모두 자신이 담당하는 서비스에 대한 기술적 의사결정에 대한 DRI(Directly Responsible Individual, 최종 의사결정권자)입니다. 권한은 서로에 대한 신뢰를 기반으로 주어지는 것이기 때문에 동료들의 신뢰를 얻고 유지하기 위해 각자 끊임없이 고민하고 노력해야 하죠. 반대로 말하면 신뢰만 얻을 수 있다면 이후로는 내가 하고 싶은 모든 것을 도전해 볼 수 있는 팀이라고 할 수 있어요.
챕터 리드라도 다른 프론트엔드 개발자가 정한 바를 침해할 수 없어서 저 역시도 항상 동료를 설득하고 공감시키기 위해 많은 노력을 기울이고 있습니다.
윤(Frontend Engineer): 챕터원들의 공통점은 멈춰 있는 것을 견디지 못한다는 점이에요. 챕터가 모두 서로에게 자극받으며 꾸준히 성장하고자 하는 욕심이 있는 분들로 구성되어 있어요.
동료들의 자율성을 최대한 보장해 주고 가장 효율적으로 일할 수 있는 방법을 고민해 주는 리드가 있다는 점도 챕터원으로서 자랑거리이고요.
노엘(Frontend Engineer): 챕터의 모두가 각기 다른 강점을 가지고 있어요. 이 강점을 챕터 내에서 발휘하고 전파할 수 있는 능력이 있다는 점이 특징이라고 생각합니다. 한 챕터원이 가진 약점을 다른 챕터원이 보완하는 일이 가능하죠.
예를 들면 저는 설계의 중요성을 크게 생각하고, 꽤 많은 시간을 들여 설계를 최대한 잘하고자 노력하는 성향이에요. 혼자 잘 해내고 끝이 아니라 챕터 내에서 이를 공유하여 공동의 성장 기회를 만들고 있습니다. 반면 저에게 부족한 커뮤니케이션 능력은 에반이나 윤으로부터 적극적인 도움과 조언을 받아 개선해 나가고 있고요.
에반(Frontend Chapter Lead): 저는 비즈니스를 좋아하고 회사 자체에 관심이 많다는 점이 스스로 강점이라고 생각해요. 또 개인의 상태나 심리를 섬세하게 살피고 도움을 줄 수 있어요.
체력 관리를 잘 못한다는 점이 약점인데요. 업무에 집중하기 위해서 필요성을 크게 느끼고 있어서, 컨디션 관리에 일가견이 있는 윤에게 방법을 배우고 있습니다.
쿼타북 프론트엔드에서 어떤 일을 하고 있나요?
에반(Frontend Chapter Lead): 저는 챕터 리드로서 동료들이 "일에만 집중할 수 있는 환경"을 만들기 위해 노력하고 있어요. 개인적으로 제가 생각하는 이상적인 리더는 동료들이 만족스러운 환경에서 행복하게 일할 수 있도록 서포트하는 사람이에요. 직접 선택한 일을 할 때 인간은 자기효능감이 가장 커진다고 생각하기 때문에 동료들이 스스로 옳다고 생각하는 방향으로 결정하고 움직일 수 있도록 도우려고 합니다. 다만 이런 리더십은 의사결정 권한을 타인에게 넘겨주되, 책임은 자신이 져야 한다는 의미이기도 해서 많은 용기가 필요하죠. 그런 용기를 낼 수 있는 리더이자 동료가 되기 위해 계속해서 노력하는 중입니다.
한편으로 리드로서 프론트엔드 챕터의 목표와 방향성을 제안하고, 모호한 문제를 해결하거나 동료들이 겪고 있는 어려움을 해소하기 위해 노력하고 있어요. 동료들이 자기가 맡은 일에 집중하면서 다른 것들에 신경을 쓰지 않도록 지원하는 역할이죠. 좀 더 많은 문제와 다양한 상황을 경험하면서 시행착오를 겪었기 때문에 역할에 자신감을 가지고 일하고 있어요.
노엘(Frontend Engineer): VC 스쿼드 소속 메이커로 투자자 고객을 위한 서비스를 개발하고 있어요. 동시에 챕터 차원에서 함께 쓸 수 있는 추상적인 모듈을 설계하고 있습니다. 생산성을 10X 할 수 있는 여러 가지 방법을 고민하고 있어요. 한 번의 견고한 설계로 여러 사람이 편의를 얻을 수 있는 일이라 보람이 있죠.
윤(Frontend Engineer): 저는 프론트엔드 챕터 소속이자, 스타트업 스쿼드 소속 개발자로서 스타트업 고객사의 문제를 해결하는 일을 하고 있어요. 가장 최근에는 스타트업 고객사가 투자사에게 영업보고할 때 겪는 불편을 해결하는 과정을 함께 고민하고 개발하는 일을 하고 있어요. 다수의 투자를 받은 스타트업은 여러 투자사를 대상으로 여러 차례 중복된 보고를 해야하고, 반대로 투자사는 여러 포트폴리오 스타트업을 대상으로 중복해서 보고를 요청해야하는 번거로움이 있는데, 이런 불편함을 한 번에 해결해 주는 멋진 제품을 동료들과 만들고 있습니다.
쿼타북 프론트엔드 챕터의 특별한 개발 문화가 있나요?
에반(Frontend Chapter Lead): 우리 챕터에는 ‘허락보다 용서가 쉽다’는 말이 있습니다. 원하는 코드가 있다면 우선 작성하고, 논의는 그 다음에 하는 거죠.
저는 뭔가 하고 싶다는 마음 자체가 굉장히 소중하다고 생각하거든요. 일반적인 직장인처럼 일한다면 그냥 시키는 대로 하게 되는 경우가 많잖아요. 하고 싶다는 마음은 누구에게나 언제나 있는 게 아니라는 거죠. 소중한 마음이 정말 임팩트를 내기 위해서는 이걸 구현해 내고 실천까지 해내는 데 있어 아무런 심리적 허들도 있어서는 안 된다고 봅니다.
만약 뭔가 하려고 할 때 챕터의 6명을 모두 설득해야 한다면 굉장히 큰 심리적 허들이 생긴다고 보는 거죠. 아무래도 실행 전 논의가 많아지게 되면 누구나 편하게 기여할 수 있는 일임에도 불구하고 논의에 대한 피로도 때문에 망설이게 되기도 하고요. 차라리 그걸 없애고 리뷰는 어차피 하게 될테니 그때 철저히 논의하자는 거예요. 만들어진 코드를 보면서 이야기하면 이해도 더 잘 될 테고요.
이런 시도를 통해 더 빠른 실행과 실패를 거듭하면서 미친 속도로 성장하자는 모두의 약속이에요. 각자에 대한 신뢰를 기반으로 리뷰 전까지 모든 시도를 자유롭게 하되, 리뷰와 배포 이후 발생하는 일에 대한 책임은 챕터 전체가 함께 지고 가자는 공감대를 가지고 있습니다.
윤(Frontend Engineer): 코드 리뷰 이야기가 나왔는데, 저는 쿼타랩의 코드 리뷰 퀄리티와 속도는 업계 최고 수준이라고 자신해요. 누가 강제하지 않아도, 동료 개발자의 코드 퀄리티와 성장을 위해 말 그대로 ASAP 리뷰를 해 주는 동료들이 있어요. 개발을 사랑하는 이들로만 구성된 챕터가 누릴 수 있는 장점 중 하나죠.

프론트엔드 엔지니어 윤
코드 리뷰의 퀄리티와 속도에 대해 어떻게 자신할 수 있나요?
에반(Frontend Chapter Lead): 챕터에 코드 리뷰를 올리면 “좋네요”하고 넘어가는 경우가 정말 드물어요. 이상한 코드는 없는지, 더 개선할 점은 없는지 강하게 챌린지 들어오는 경우가 많죠. 이 과정에서 의견 충돌이 있더라도 언제나 코드의 퀄리티를 고려하여 논의를 피하지 않습니다.
‘남들 다 하니까’, ‘해야 하니까’하는 리뷰는 저희에게 존재하지 않습니다. 리뷰는 제대로 해야 리뷰고, 그렇지 않으면 단순한 승인에 가깝게 돼요. 쿼타랩 프론트엔드 챕터는 400건의 리뷰라면 400번 치열하게 함께 고민하고 논의합니다. 실제로 이번 한 주에만 챕터에서 425건 정도 작업 내용을 머지(merge)했는데요. 그 말인 즉슨 425건의 치열한 토론이 발생했다는 거겠죠?
쿼타북 프론트엔드 챕터가 원팀으로 일하기 위해 만들어 나가고 있는 그라운드룰은 무엇인가요?
노엘(Frontend Engineer): 사실 필요하지 않은 룰은 만들지 않는 편이 좋다는 데 다들 공감대가 있어요. ‘DRI의 권한을 침해하지 않기’처럼 정말 필요한 룰만 정확히 만들어 지킵니다.
에반(Frontend Chapter Lead): 맞아요. 재미있게 일을 하려면 자유가 있어야 합니다. 자유가 없이 일을 한다면 재미가 있을 수 없죠. 다만 이런 자유에 따라오는 책임도 진다는 동의가 모두에게 있어요. 저희 팀원들에게는 이 책임에 대한 역량도 있다고 믿고 있습니다.
앞서 잠깐 이야기했듯 “머지 후 발생하는 모든 이슈에 대해 챕터 전체가 책임진다”는 암묵적인 룰이 있는데요. 운영 환경에 코드가 배포되었다는 것은 코드 작성자 외에도 챕터가 그 코드에 동의했다는 것을 의미해요. 코드 리뷰는 챕터 누구라도 함께 할 수 있고요. 그렇기 때문에 운영에 배포된 코드에서 문제가 발생했다면 코드 작성자나 그 버그를 잡아내지 못 한 리뷰어만의 책임이 아니라, 리뷰에 참여할 자유가 있었음에도 리뷰하지 못했던 프론트엔드 챕터 모두의 책임이 되는 것이죠. 이런 룰은 챕터 전체를 더 강한 ‘원팀’으로 일할 수 있게 해주는 것 같습니다.
이렇게 동료의 자율성을 존중하고 함께 책임을 지는 문화가 쿼타랩 프론트엔드 챕터를 더 끈끈한 원팀으로 만들어주는 것이라 생각합니다.
윤(Frontend Engineer): 제가 생각하는 우리 챕터의 그라운드룰은 ‘상호 존중’인 것 같아요. 하드 스킬 레벨과 상관 없이 동료들의 의사 결정 과정이 신뢰할 만하다면, 그것을 믿고 지원해 주고, 또 조언도 아끼지 않는 문화가 있어요. 다만 무조건적인 존중과 신뢰는 아니에요. 아닌 것은 아니라고 얘기하는 조직이기 때문에 더욱 서로에 대한 신뢰가 높아지는 것 같아요.

쿼타랩 프론트엔드 챕터 리드 에반
앞으로 어떤 목표를 가지고 있나요?
에반(Frontend Chapter Lead): 조직 관점에서는 프론트엔드 챕터뿐 아니라 쿼타랩 팀에서 일하는 모든 동료가 자신이 전문성을 가진 범위 내에서 온전한 자율과 책임을 행사할 수 있는 조직을 만드는 것이 목표예요.
이런 조직이 되기 위해서는 동료들 간의 두터운 신뢰가 필수적인데요. 이런 신뢰를 만들어 내기 위해서는 좋은 채용을 통해 뛰어난 동료를 모으는 것, 의사결정권을 위임하기 위한 리더들의 용기, 모두가 같은 곳을 보고 달릴 수 있는 조직 전체의 명확한 비전과 목표 등 다양한 요소들이 모두 충족되어야 합니다.
물론 지금도 쿼타랩은 높은 수준의 자율과 책임 문화를 실천하고 있는 조직이지만, 초기 스타트업인 만큼 아직 더 성장할 수 있는 잠재력과 능력이 많이 남은 조직이기도 합니다. 여기서 제 목표와 역할은 쿼타랩을 지금보다 더 훌륭한 팀으로 만들기 위해 더 좋은 방법을 강구하고 빠르게 실천하는 것이라고 생각해요.
개인적으로는 멘토링이나 글을 통해 제가 해온 경험을 다른 사람들과 나누고 그분들의 성장을 돕는 삶을 살고 싶습니다.
윤(Frontend Engineer): 더 많은 고객들과 투자사들을 하루라도 빨리 모시게 되면 좋겠습니다. 저 역시 맡은 역할이 있지만 그 이전에 스타트업의 구성원이다 보니, 함께 소중한 시간을 보내고 있는 훌륭한 동료들의 노력이 잘 쓰이며 빛을 발할 수 있기를 바라고 있습니다.
개인적으로는 세상에 나만의 것을 내놓는다는 목표로 일하고 있어요. 앞으로 5년 내에 창업하는 것이 목표에요.
어떤 동료와 함께 하기를 기대하나요?
에반(Frontend Chapter Lead): 일을 그저 일로써만 대하지 않는 동료들과 함께하고 싶어요.
개발을 하는 것, 내 능력을 통해 세상을 바꾸고 비즈니스 임팩트를 만들어내는 행위가 그저 인생의 일부가 아닌 정말로 이런 가치를 달성하는 것이 내 인생의 우선순위 1순위인 동료들과 함께한다면, 아무리 일이 많거나 어렵더라도 함께 등을 맞대고 헤쳐 나갈 수 있을 것 같아요.
윤(Frontend Engineer): 쿼타북의 도메인이 비상장 증권 도메인이라 다소 딱딱하거나 어렵게 느껴지실 수 있지만, 정해진 룰 밖에서 자신만의 방식으로 문제를 해결해 나가는 분들만 모여있는, 딱딱함과는 다소 거리가 먼 조직이에요. 이런 멋진 동료들과 함께 문제를 제대로 해결하고 싶으신 분과 함께라면 가슴이 뛸 것 같네요.
지원하는 분들에게 미리 알려주고 싶은 팁은?
노엘(Frontend Engineer): 아주 현실적인 팁이라면 이력서 스킬셋(Skill Set, 능력) 부분에 스스로 레벨이나 점수를 매기지 않는 것을 추천해요. 검토하는 입장에서 특정한 기대치가 생겨날 수 있어 유의해야 합니다.
에반(Frontend Chapter Lead): 마지막으로 개발자로서의 역량은 학력이나 경력보다는 코드 자체로 판단합니다. 이를 확인할 수 있는 깃헙(GitHub) 링크를 꼭 공유해 주시면 좋아요. 깃헙에는 확인할 수 있는 프로젝트를 올려두거나 어필하고 싶은 특이 사항이 있다면 이를 주의 깊게 봐달라는 설명을 덧붙여서 주시면 정확한 검토와 평가에 더욱 도움이 됩니다.
쿼타랩 프론트엔드 챕터는 자율과 책임을 기반으로 빠르게 실행하고 개선하며 성장을 거듭하고 있습니다. 국내 최초로 ‘비상장 금융 인프라’를 함께 만들어 나갈 뛰어난 동료를 찾고 있으니, 아무도 가보지 않은 길을 개척해보고 싶으신 분들의 많은 관심 부탁드립니다.
※ Legal disclaimer │ 법적 고지 사항
쿼타북은 법률 또는 기타 전문적인 자문을 제공하는 주체가 아니며, 쿼타북이 본 웹사이트 및/또는 기타 매체 등을 통하여 전달하는 정보는 일반적인 정보 공유 목적으로만 제공됩니다. 쿼타북이 제공하는 어떠한 정보도 법률 또는 기타 전문적인 자문으로 해석되지 아니하며 이를 어떠한 결정이나 조치의 근거로 활용하여서는 안됩니다. 본 웹사이트 및/또는 기타 쿼타북이 운영하는 매체를 통하여 제공되는 정보는 관련된 가장 최신의 내용이 반영된 정보가 아닐 수 있습니다. 또한 본 웹사이트에 포함된 외부 제3자의 웹사이트 및 기타 정보에 대한 링크는 이용자의 편의를 위하여 제공되는 것일 뿐이며 이로써 링크된 제3자 제공 정보 등을 이용자에게 추천하는 것이 아님을 명시합니다.

QuotaLab Team
여러 세대를 위한 최초의 비상장 금융 인프라를 만들어 갑니다.

‘온전한 자율과 철저한 책임’으로 만드는 최초의 비상장 금융 인프라
쿼타랩 프론트엔드 챕터 이야기
2023. 7. 21.
쿼타랩은 챕터와 스쿼드로 이루어져 있습니다. 같은 직무를 하는 팀이 챕터, 같은 제품이나 기능을 만드는 팀이 스쿼드입니다. 그 중에서도 오늘은 쿼타랩 프론트엔드 챕터의 이야기를 준비했습니다. 각기 다른 스쿼드에 속한 개인으로서, 또한 서로 같은 직무를 함께 하는 팀으로서 이들은 어떻게 일하고 있을까요?
각자 자기소개를 부탁드립니다.
에반(Frontend Chapter Lead): 프론트엔드 개발자 문동욱입니다. 2016년부터 개발을 시작해서 다양한 스타트업을 거쳐왔습니다. 시리즈 A에서 D로 라운드를 뛰거나, 인원이 300명에서 2,000명 이상으로 변하는 등 빠르게 성장하는 조직에서 일해본 경험이 많습니다.
현재는 쿼타랩에서 프론트엔드 챕터 리드와 VC 스쿼드의 엔지니어링 매니저 역할을 맡고 있습니다. 때때로 프론트엔드 리소스가 부족한 스쿼드를 지원하기도 합니다.
윤(Frontend Engineer): 1년 차 프론트엔드 개발자 백승윤입니다. 프론트엔드 개발자로서는 쿼타랩이 첫 직장입니다.
노엘(Frontend Engineer): 프론트엔드 개발자 김민혁입니다. 고등학교를 졸업한 2020년 모바일 개발로 커리어를 시작했고, 두 번째 직장에서 시스템 개발과 프론트엔드 개발에 깊게 관여한 것을 계기로 세 번째 직장인 쿼타랩에서는 프론트엔드 개발자로 자리 잡아 일하고 있습니다.
여러분은 스스로 어떤 개발자라고 생각하나요?
노엘(Frontend Engineer): 어려운 질문이네요. 필요하다면 무엇이든 할 수 있는 개발자라고 생각합니다.

프론트엔드 엔지니어 노엘과 에반
에반(Frontend Chapter Lead): 제가 가진 능력으로 세상을 바꾸는 일에 매력을 느끼는 개발자인 것 같습니다. 제품이 실질적으로 사람들의 삶을 편하게 만들어 주고, 이에 따라 회사가 성장할 때 큰 기쁨을 느껴요. 다른 사람의 성장을 돕거나 조직을 성장시키는 일에도 관심이 많습니다.
윤(Frontend Engineer): 커뮤니케이션 잘하는 개발자를 지향합니다. 동료들과 문제를 해결하다 보면, 개발 이전에 커뮤니케이션을 통해 이슈를 해결하거나 시간 및 비용을 줄일 수 있는 사례도 많더라고요. 일 잘하는 개발자가 되기 위해서는 커뮤니케이션 능력도 필수로 가져야 하죠.
쿼타랩 프론트엔드 개발자로 일하는 장점은 무엇인가요?
노엘(Frontend Engineer): 경험해 본 제품 중 쿼타북은 복잡도가 정말 높은 편이에요. 비즈니스 도메인 자체도 난이도가 있고, 하나의 기능에 얽힌 여러 이해관계를 고려하기도 쉽지 않죠. 현재 개발과 함께 설계도 직접 하고 있는데, 쿼타북에서 잘 해낼 수 있다면 개발자로서 급성장할 수 있겠다는 생각을 자주 합니다.
윤(Frontend Engineer): 크게 세 가지 정도가 있는데요. 먼저, 다양한 직군과 협력하며 제품을 제로(0)부터 구축하는 경험을 할 수 있습니다. 프로덕트 디자이너, 백엔드 개발자, 프로덕트 매니저, 데브옵스(DevOps) 개발자 등 다양한 직군의 이해관계자와 소통하며 제품을 만들어 가는 과정이 가끔 도전적일 수 있지만, 개발자로서 제품에 직접 기여할 수 있는 즐거움을 느끼고 있습니다.
또, 프론트엔드 분야의 최신 기술 동향과 이슈를 팀에서 함께 고민하고, 우리 제품에 맞추어 적용하는 재미가 있습니다. 단순히 남들이 하니까 나도 하는 기계적인 개발이 아니라는 점이 특히 매력적이에요.
마지막으로, 비상장 증권 도메인에 대한 지식을 습득하게 됩니다. 비상장 증권 시장에서의 어려움을 해결해 나가고 있는 쿼타북을 만들다 보면, 주식, 스톡옵션, RSU 등에 대해 필요하면서도 어려운 개념들을 자연스럽게 체득해 나갈 수 있어요.
에반(Frontend Chapter Lead): 특히 비상장 증권 지식은 창업을 꿈꾸는 개발자라면 꼭 필요합니다. 미래에 자신만의 비즈니스를 하고 싶어 하는 개발자가 적지 않거든요. 만들고자 하는 서비스가 있으면 처음부터 끝까지 자기가 만들 수 있으니까요. 그래서 사이드 프로젝트를 하거나 회사를 아예 그만두고 창업을 하는 사례도 꽤 많은 편이죠. 윤도 나중에 창업하고 싶다고 하지 않으셨나요?
윤(Frontend Engineer): 맞아요. 스타트업 설립 후 어떤 경영 관리가 필요한지 미리 알아가는 중입니다.
에반(Frontend Chapter Lead): 말하자면 창업 전 집중적인 예행연습이네요.
쿼타북 프론트엔드 개발자로 일하는 것의 큰 장점 중 하나는 개선과 변화를 주는 가능성을 직접 갖게 된다는 점입니다. 대규모 조직에서는 개인의 영향력이 제한적일 수 있어요. 예를 들어 2천 명 규모에 있는 조직에서 영향력과 50명 규모의 조직에서의 영향력은 아무래도 차이가 있을 테고요. 하지만 쿼타랩은 초기 스타트업이라 다양한 도전이 가능합니다. 명확한 근거와 설득력만 있다면 변화를 두려워하지 않는 동료들과 함께 무엇이라도 시도할 수 있어요. 쿼타랩 프론트엔드 챕터는 현재 챕터원들처럼 일을 진심으로 좋아하는 분들을 모시기 위해 노력하고 있습니다. 앞으로도 문제 해결에 집중하며 치열하게 논의하는 경험을 계속해 나가기 위해서요.

쿼타랩 프론트엔드 챕터
쿼타북 프론트엔드 챕터는 어떤 팀인가요?
에반(Frontend Chapter Lead): 온전한 자율과 철저한 책임을 충실하게 실현해 내기 위해 노력하는 챕터입니다.
쿼타랩의 프론트엔드 개발자들은 모두 자신이 담당하는 서비스에 대한 기술적 의사결정에 대한 DRI(Directly Responsible Individual, 최종 의사결정권자)입니다. 권한은 서로에 대한 신뢰를 기반으로 주어지는 것이기 때문에 동료들의 신뢰를 얻고 유지하기 위해 각자 끊임없이 고민하고 노력해야 하죠. 반대로 말하면 신뢰만 얻을 수 있다면 이후로는 내가 하고 싶은 모든 것을 도전해 볼 수 있는 팀이라고 할 수 있어요.
챕터 리드라도 다른 프론트엔드 개발자가 정한 바를 침해할 수 없어서 저 역시도 항상 동료를 설득하고 공감시키기 위해 많은 노력을 기울이고 있습니다.
윤(Frontend Engineer): 챕터원들의 공통점은 멈춰 있는 것을 견디지 못한다는 점이에요. 챕터가 모두 서로에게 자극받으며 꾸준히 성장하고자 하는 욕심이 있는 분들로 구성되어 있어요.
동료들의 자율성을 최대한 보장해 주고 가장 효율적으로 일할 수 있는 방법을 고민해 주는 리드가 있다는 점도 챕터원으로서 자랑거리이고요.
노엘(Frontend Engineer): 챕터의 모두가 각기 다른 강점을 가지고 있어요. 이 강점을 챕터 내에서 발휘하고 전파할 수 있는 능력이 있다는 점이 특징이라고 생각합니다. 한 챕터원이 가진 약점을 다른 챕터원이 보완하는 일이 가능하죠.
예를 들면 저는 설계의 중요성을 크게 생각하고, 꽤 많은 시간을 들여 설계를 최대한 잘하고자 노력하는 성향이에요. 혼자 잘 해내고 끝이 아니라 챕터 내에서 이를 공유하여 공동의 성장 기회를 만들고 있습니다. 반면 저에게 부족한 커뮤니케이션 능력은 에반이나 윤으로부터 적극적인 도움과 조언을 받아 개선해 나가고 있고요.
에반(Frontend Chapter Lead): 저는 비즈니스를 좋아하고 회사 자체에 관심이 많다는 점이 스스로 강점이라고 생각해요. 또 개인의 상태나 심리를 섬세하게 살피고 도움을 줄 수 있어요.
체력 관리를 잘 못한다는 점이 약점인데요. 업무에 집중하기 위해서 필요성을 크게 느끼고 있어서, 컨디션 관리에 일가견이 있는 윤에게 방법을 배우고 있습니다.
쿼타북 프론트엔드에서 어떤 일을 하고 있나요?
에반(Frontend Chapter Lead): 저는 챕터 리드로서 동료들이 "일에만 집중할 수 있는 환경"을 만들기 위해 노력하고 있어요. 개인적으로 제가 생각하는 이상적인 리더는 동료들이 만족스러운 환경에서 행복하게 일할 수 있도록 서포트하는 사람이에요. 직접 선택한 일을 할 때 인간은 자기효능감이 가장 커진다고 생각하기 때문에 동료들이 스스로 옳다고 생각하는 방향으로 결정하고 움직일 수 있도록 도우려고 합니다. 다만 이런 리더십은 의사결정 권한을 타인에게 넘겨주되, 책임은 자신이 져야 한다는 의미이기도 해서 많은 용기가 필요하죠. 그런 용기를 낼 수 있는 리더이자 동료가 되기 위해 계속해서 노력하는 중입니다.
한편으로 리드로서 프론트엔드 챕터의 목표와 방향성을 제안하고, 모호한 문제를 해결하거나 동료들이 겪고 있는 어려움을 해소하기 위해 노력하고 있어요. 동료들이 자기가 맡은 일에 집중하면서 다른 것들에 신경을 쓰지 않도록 지원하는 역할이죠. 좀 더 많은 문제와 다양한 상황을 경험하면서 시행착오를 겪었기 때문에 역할에 자신감을 가지고 일하고 있어요.
노엘(Frontend Engineer): VC 스쿼드 소속 메이커로 투자자 고객을 위한 서비스를 개발하고 있어요. 동시에 챕터 차원에서 함께 쓸 수 있는 추상적인 모듈을 설계하고 있습니다. 생산성을 10X 할 수 있는 여러 가지 방법을 고민하고 있어요. 한 번의 견고한 설계로 여러 사람이 편의를 얻을 수 있는 일이라 보람이 있죠.
윤(Frontend Engineer): 저는 프론트엔드 챕터 소속이자, 스타트업 스쿼드 소속 개발자로서 스타트업 고객사의 문제를 해결하는 일을 하고 있어요. 가장 최근에는 스타트업 고객사가 투자사에게 영업보고할 때 겪는 불편을 해결하는 과정을 함께 고민하고 개발하는 일을 하고 있어요. 다수의 투자를 받은 스타트업은 여러 투자사를 대상으로 여러 차례 중복된 보고를 해야하고, 반대로 투자사는 여러 포트폴리오 스타트업을 대상으로 중복해서 보고를 요청해야하는 번거로움이 있는데, 이런 불편함을 한 번에 해결해 주는 멋진 제품을 동료들과 만들고 있습니다.
쿼타북 프론트엔드 챕터의 특별한 개발 문화가 있나요?
에반(Frontend Chapter Lead): 우리 챕터에는 ‘허락보다 용서가 쉽다’는 말이 있습니다. 원하는 코드가 있다면 우선 작성하고, 논의는 그 다음에 하는 거죠.
저는 뭔가 하고 싶다는 마음 자체가 굉장히 소중하다고 생각하거든요. 일반적인 직장인처럼 일한다면 그냥 시키는 대로 하게 되는 경우가 많잖아요. 하고 싶다는 마음은 누구에게나 언제나 있는 게 아니라는 거죠. 소중한 마음이 정말 임팩트를 내기 위해서는 이걸 구현해 내고 실천까지 해내는 데 있어 아무런 심리적 허들도 있어서는 안 된다고 봅니다.
만약 뭔가 하려고 할 때 챕터의 6명을 모두 설득해야 한다면 굉장히 큰 심리적 허들이 생긴다고 보는 거죠. 아무래도 실행 전 논의가 많아지게 되면 누구나 편하게 기여할 수 있는 일임에도 불구하고 논의에 대한 피로도 때문에 망설이게 되기도 하고요. 차라리 그걸 없애고 리뷰는 어차피 하게 될테니 그때 철저히 논의하자는 거예요. 만들어진 코드를 보면서 이야기하면 이해도 더 잘 될 테고요.
이런 시도를 통해 더 빠른 실행과 실패를 거듭하면서 미친 속도로 성장하자는 모두의 약속이에요. 각자에 대한 신뢰를 기반으로 리뷰 전까지 모든 시도를 자유롭게 하되, 리뷰와 배포 이후 발생하는 일에 대한 책임은 챕터 전체가 함께 지고 가자는 공감대를 가지고 있습니다.
윤(Frontend Engineer): 코드 리뷰 이야기가 나왔는데, 저는 쿼타랩의 코드 리뷰 퀄리티와 속도는 업계 최고 수준이라고 자신해요. 누가 강제하지 않아도, 동료 개발자의 코드 퀄리티와 성장을 위해 말 그대로 ASAP 리뷰를 해 주는 동료들이 있어요. 개발을 사랑하는 이들로만 구성된 챕터가 누릴 수 있는 장점 중 하나죠.

프론트엔드 엔지니어 윤
코드 리뷰의 퀄리티와 속도에 대해 어떻게 자신할 수 있나요?
에반(Frontend Chapter Lead): 챕터에 코드 리뷰를 올리면 “좋네요”하고 넘어가는 경우가 정말 드물어요. 이상한 코드는 없는지, 더 개선할 점은 없는지 강하게 챌린지 들어오는 경우가 많죠. 이 과정에서 의견 충돌이 있더라도 언제나 코드의 퀄리티를 고려하여 논의를 피하지 않습니다.
‘남들 다 하니까’, ‘해야 하니까’하는 리뷰는 저희에게 존재하지 않습니다. 리뷰는 제대로 해야 리뷰고, 그렇지 않으면 단순한 승인에 가깝게 돼요. 쿼타랩 프론트엔드 챕터는 400건의 리뷰라면 400번 치열하게 함께 고민하고 논의합니다. 실제로 이번 한 주에만 챕터에서 425건 정도 작업 내용을 머지(merge)했는데요. 그 말인 즉슨 425건의 치열한 토론이 발생했다는 거겠죠?
쿼타북 프론트엔드 챕터가 원팀으로 일하기 위해 만들어 나가고 있는 그라운드룰은 무엇인가요?
노엘(Frontend Engineer): 사실 필요하지 않은 룰은 만들지 않는 편이 좋다는 데 다들 공감대가 있어요. ‘DRI의 권한을 침해하지 않기’처럼 정말 필요한 룰만 정확히 만들어 지킵니다.
에반(Frontend Chapter Lead): 맞아요. 재미있게 일을 하려면 자유가 있어야 합니다. 자유가 없이 일을 한다면 재미가 있을 수 없죠. 다만 이런 자유에 따라오는 책임도 진다는 동의가 모두에게 있어요. 저희 팀원들에게는 이 책임에 대한 역량도 있다고 믿고 있습니다.
앞서 잠깐 이야기했듯 “머지 후 발생하는 모든 이슈에 대해 챕터 전체가 책임진다”는 암묵적인 룰이 있는데요. 운영 환경에 코드가 배포되었다는 것은 코드 작성자 외에도 챕터가 그 코드에 동의했다는 것을 의미해요. 코드 리뷰는 챕터 누구라도 함께 할 수 있고요. 그렇기 때문에 운영에 배포된 코드에서 문제가 발생했다면 코드 작성자나 그 버그를 잡아내지 못 한 리뷰어만의 책임이 아니라, 리뷰에 참여할 자유가 있었음에도 리뷰하지 못했던 프론트엔드 챕터 모두의 책임이 되는 것이죠. 이런 룰은 챕터 전체를 더 강한 ‘원팀’으로 일할 수 있게 해주는 것 같습니다.
이렇게 동료의 자율성을 존중하고 함께 책임을 지는 문화가 쿼타랩 프론트엔드 챕터를 더 끈끈한 원팀으로 만들어주는 것이라 생각합니다.
윤(Frontend Engineer): 제가 생각하는 우리 챕터의 그라운드룰은 ‘상호 존중’인 것 같아요. 하드 스킬 레벨과 상관 없이 동료들의 의사 결정 과정이 신뢰할 만하다면, 그것을 믿고 지원해 주고, 또 조언도 아끼지 않는 문화가 있어요. 다만 무조건적인 존중과 신뢰는 아니에요. 아닌 것은 아니라고 얘기하는 조직이기 때문에 더욱 서로에 대한 신뢰가 높아지는 것 같아요.

쿼타랩 프론트엔드 챕터 리드 에반
앞으로 어떤 목표를 가지고 있나요?
에반(Frontend Chapter Lead): 조직 관점에서는 프론트엔드 챕터뿐 아니라 쿼타랩 팀에서 일하는 모든 동료가 자신이 전문성을 가진 범위 내에서 온전한 자율과 책임을 행사할 수 있는 조직을 만드는 것이 목표예요.
이런 조직이 되기 위해서는 동료들 간의 두터운 신뢰가 필수적인데요. 이런 신뢰를 만들어 내기 위해서는 좋은 채용을 통해 뛰어난 동료를 모으는 것, 의사결정권을 위임하기 위한 리더들의 용기, 모두가 같은 곳을 보고 달릴 수 있는 조직 전체의 명확한 비전과 목표 등 다양한 요소들이 모두 충족되어야 합니다.
물론 지금도 쿼타랩은 높은 수준의 자율과 책임 문화를 실천하고 있는 조직이지만, 초기 스타트업인 만큼 아직 더 성장할 수 있는 잠재력과 능력이 많이 남은 조직이기도 합니다. 여기서 제 목표와 역할은 쿼타랩을 지금보다 더 훌륭한 팀으로 만들기 위해 더 좋은 방법을 강구하고 빠르게 실천하는 것이라고 생각해요.
개인적으로는 멘토링이나 글을 통해 제가 해온 경험을 다른 사람들과 나누고 그분들의 성장을 돕는 삶을 살고 싶습니다.
윤(Frontend Engineer): 더 많은 고객들과 투자사들을 하루라도 빨리 모시게 되면 좋겠습니다. 저 역시 맡은 역할이 있지만 그 이전에 스타트업의 구성원이다 보니, 함께 소중한 시간을 보내고 있는 훌륭한 동료들의 노력이 잘 쓰이며 빛을 발할 수 있기를 바라고 있습니다.
개인적으로는 세상에 나만의 것을 내놓는다는 목표로 일하고 있어요. 앞으로 5년 내에 창업하는 것이 목표에요.
어떤 동료와 함께 하기를 기대하나요?
에반(Frontend Chapter Lead): 일을 그저 일로써만 대하지 않는 동료들과 함께하고 싶어요.
개발을 하는 것, 내 능력을 통해 세상을 바꾸고 비즈니스 임팩트를 만들어내는 행위가 그저 인생의 일부가 아닌 정말로 이런 가치를 달성하는 것이 내 인생의 우선순위 1순위인 동료들과 함께한다면, 아무리 일이 많거나 어렵더라도 함께 등을 맞대고 헤쳐 나갈 수 있을 것 같아요.
윤(Frontend Engineer): 쿼타북의 도메인이 비상장 증권 도메인이라 다소 딱딱하거나 어렵게 느껴지실 수 있지만, 정해진 룰 밖에서 자신만의 방식으로 문제를 해결해 나가는 분들만 모여있는, 딱딱함과는 다소 거리가 먼 조직이에요. 이런 멋진 동료들과 함께 문제를 제대로 해결하고 싶으신 분과 함께라면 가슴이 뛸 것 같네요.
지원하는 분들에게 미리 알려주고 싶은 팁은?
노엘(Frontend Engineer): 아주 현실적인 팁이라면 이력서 스킬셋(Skill Set, 능력) 부분에 스스로 레벨이나 점수를 매기지 않는 것을 추천해요. 검토하는 입장에서 특정한 기대치가 생겨날 수 있어 유의해야 합니다.
에반(Frontend Chapter Lead): 마지막으로 개발자로서의 역량은 학력이나 경력보다는 코드 자체로 판단합니다. 이를 확인할 수 있는 깃헙(GitHub) 링크를 꼭 공유해 주시면 좋아요. 깃헙에는 확인할 수 있는 프로젝트를 올려두거나 어필하고 싶은 특이 사항이 있다면 이를 주의 깊게 봐달라는 설명을 덧붙여서 주시면 정확한 검토와 평가에 더욱 도움이 됩니다.
쿼타랩 프론트엔드 챕터는 자율과 책임을 기반으로 빠르게 실행하고 개선하며 성장을 거듭하고 있습니다. 국내 최초로 ‘비상장 금융 인프라’를 함께 만들어 나갈 뛰어난 동료를 찾고 있으니, 아무도 가보지 않은 길을 개척해보고 싶으신 분들의 많은 관심 부탁드립니다.

QuotaLab Team
여러 세대를 위한 최초의 비상장 금융 인프라를 만들어 갑니다.

‘온전한 자율과 철저한 책임’으로 만드는 최초의 비상장 금융 인프라
쿼타랩 프론트엔드 챕터 이야기
2023. 7. 21.
쿼타랩은 챕터와 스쿼드로 이루어져 있습니다. 같은 직무를 하는 팀이 챕터, 같은 제품이나 기능을 만드는 팀이 스쿼드입니다. 그 중에서도 오늘은 쿼타랩 프론트엔드 챕터의 이야기를 준비했습니다. 각기 다른 스쿼드에 속한 개인으로서, 또한 서로 같은 직무를 함께 하는 팀으로서 이들은 어떻게 일하고 있을까요?
각자 자기소개를 부탁드립니다.
에반(Frontend Chapter Lead): 프론트엔드 개발자 문동욱입니다. 2016년부터 개발을 시작해서 다양한 스타트업을 거쳐왔습니다. 시리즈 A에서 D로 라운드를 뛰거나, 인원이 300명에서 2,000명 이상으로 변하는 등 빠르게 성장하는 조직에서 일해본 경험이 많습니다.
현재는 쿼타랩에서 프론트엔드 챕터 리드와 VC 스쿼드의 엔지니어링 매니저 역할을 맡고 있습니다. 때때로 프론트엔드 리소스가 부족한 스쿼드를 지원하기도 합니다.
윤(Frontend Engineer): 1년 차 프론트엔드 개발자 백승윤입니다. 프론트엔드 개발자로서는 쿼타랩이 첫 직장입니다.
노엘(Frontend Engineer): 프론트엔드 개발자 김민혁입니다. 고등학교를 졸업한 2020년 모바일 개발로 커리어를 시작했고, 두 번째 직장에서 시스템 개발과 프론트엔드 개발에 깊게 관여한 것을 계기로 세 번째 직장인 쿼타랩에서는 프론트엔드 개발자로 자리 잡아 일하고 있습니다.
여러분은 스스로 어떤 개발자라고 생각하나요?
노엘(Frontend Engineer): 어려운 질문이네요. 필요하다면 무엇이든 할 수 있는 개발자라고 생각합니다.

프론트엔드 엔지니어 노엘과 에반
에반(Frontend Chapter Lead): 제가 가진 능력으로 세상을 바꾸는 일에 매력을 느끼는 개발자인 것 같습니다. 제품이 실질적으로 사람들의 삶을 편하게 만들어 주고, 이에 따라 회사가 성장할 때 큰 기쁨을 느껴요. 다른 사람의 성장을 돕거나 조직을 성장시키는 일에도 관심이 많습니다.
윤(Frontend Engineer): 커뮤니케이션 잘하는 개발자를 지향합니다. 동료들과 문제를 해결하다 보면, 개발 이전에 커뮤니케이션을 통해 이슈를 해결하거나 시간 및 비용을 줄일 수 있는 사례도 많더라고요. 일 잘하는 개발자가 되기 위해서는 커뮤니케이션 능력도 필수로 가져야 하죠.
쿼타랩 프론트엔드 개발자로 일하는 장점은 무엇인가요?
노엘(Frontend Engineer): 경험해 본 제품 중 쿼타북은 복잡도가 정말 높은 편이에요. 비즈니스 도메인 자체도 난이도가 있고, 하나의 기능에 얽힌 여러 이해관계를 고려하기도 쉽지 않죠. 현재 개발과 함께 설계도 직접 하고 있는데, 쿼타북에서 잘 해낼 수 있다면 개발자로서 급성장할 수 있겠다는 생각을 자주 합니다.
윤(Frontend Engineer): 크게 세 가지 정도가 있는데요. 먼저, 다양한 직군과 협력하며 제품을 제로(0)부터 구축하는 경험을 할 수 있습니다. 프로덕트 디자이너, 백엔드 개발자, 프로덕트 매니저, 데브옵스(DevOps) 개발자 등 다양한 직군의 이해관계자와 소통하며 제품을 만들어 가는 과정이 가끔 도전적일 수 있지만, 개발자로서 제품에 직접 기여할 수 있는 즐거움을 느끼고 있습니다.
또, 프론트엔드 분야의 최신 기술 동향과 이슈를 팀에서 함께 고민하고, 우리 제품에 맞추어 적용하는 재미가 있습니다. 단순히 남들이 하니까 나도 하는 기계적인 개발이 아니라는 점이 특히 매력적이에요.
마지막으로, 비상장 증권 도메인에 대한 지식을 습득하게 됩니다. 비상장 증권 시장에서의 어려움을 해결해 나가고 있는 쿼타북을 만들다 보면, 주식, 스톡옵션, RSU 등에 대해 필요하면서도 어려운 개념들을 자연스럽게 체득해 나갈 수 있어요.
에반(Frontend Chapter Lead): 특히 비상장 증권 지식은 창업을 꿈꾸는 개발자라면 꼭 필요합니다. 미래에 자신만의 비즈니스를 하고 싶어 하는 개발자가 적지 않거든요. 만들고자 하는 서비스가 있으면 처음부터 끝까지 자기가 만들 수 있으니까요. 그래서 사이드 프로젝트를 하거나 회사를 아예 그만두고 창업을 하는 사례도 꽤 많은 편이죠. 윤도 나중에 창업하고 싶다고 하지 않으셨나요?
윤(Frontend Engineer): 맞아요. 스타트업 설립 후 어떤 경영 관리가 필요한지 미리 알아가는 중입니다.
에반(Frontend Chapter Lead): 말하자면 창업 전 집중적인 예행연습이네요.
쿼타북 프론트엔드 개발자로 일하는 것의 큰 장점 중 하나는 개선과 변화를 주는 가능성을 직접 갖게 된다는 점입니다. 대규모 조직에서는 개인의 영향력이 제한적일 수 있어요. 예를 들어 2천 명 규모에 있는 조직에서 영향력과 50명 규모의 조직에서의 영향력은 아무래도 차이가 있을 테고요. 하지만 쿼타랩은 초기 스타트업이라 다양한 도전이 가능합니다. 명확한 근거와 설득력만 있다면 변화를 두려워하지 않는 동료들과 함께 무엇이라도 시도할 수 있어요. 쿼타랩 프론트엔드 챕터는 현재 챕터원들처럼 일을 진심으로 좋아하는 분들을 모시기 위해 노력하고 있습니다. 앞으로도 문제 해결에 집중하며 치열하게 논의하는 경험을 계속해 나가기 위해서요.

쿼타랩 프론트엔드 챕터
쿼타북 프론트엔드 챕터는 어떤 팀인가요?
에반(Frontend Chapter Lead): 온전한 자율과 철저한 책임을 충실하게 실현해 내기 위해 노력하는 챕터입니다.
쿼타랩의 프론트엔드 개발자들은 모두 자신이 담당하는 서비스에 대한 기술적 의사결정에 대한 DRI(Directly Responsible Individual, 최종 의사결정권자)입니다. 권한은 서로에 대한 신뢰를 기반으로 주어지는 것이기 때문에 동료들의 신뢰를 얻고 유지하기 위해 각자 끊임없이 고민하고 노력해야 하죠. 반대로 말하면 신뢰만 얻을 수 있다면 이후로는 내가 하고 싶은 모든 것을 도전해 볼 수 있는 팀이라고 할 수 있어요.
챕터 리드라도 다른 프론트엔드 개발자가 정한 바를 침해할 수 없어서 저 역시도 항상 동료를 설득하고 공감시키기 위해 많은 노력을 기울이고 있습니다.
윤(Frontend Engineer): 챕터원들의 공통점은 멈춰 있는 것을 견디지 못한다는 점이에요. 챕터가 모두 서로에게 자극받으며 꾸준히 성장하고자 하는 욕심이 있는 분들로 구성되어 있어요.
동료들의 자율성을 최대한 보장해 주고 가장 효율적으로 일할 수 있는 방법을 고민해 주는 리드가 있다는 점도 챕터원으로서 자랑거리이고요.
노엘(Frontend Engineer): 챕터의 모두가 각기 다른 강점을 가지고 있어요. 이 강점을 챕터 내에서 발휘하고 전파할 수 있는 능력이 있다는 점이 특징이라고 생각합니다. 한 챕터원이 가진 약점을 다른 챕터원이 보완하는 일이 가능하죠.
예를 들면 저는 설계의 중요성을 크게 생각하고, 꽤 많은 시간을 들여 설계를 최대한 잘하고자 노력하는 성향이에요. 혼자 잘 해내고 끝이 아니라 챕터 내에서 이를 공유하여 공동의 성장 기회를 만들고 있습니다. 반면 저에게 부족한 커뮤니케이션 능력은 에반이나 윤으로부터 적극적인 도움과 조언을 받아 개선해 나가고 있고요.
에반(Frontend Chapter Lead): 저는 비즈니스를 좋아하고 회사 자체에 관심이 많다는 점이 스스로 강점이라고 생각해요. 또 개인의 상태나 심리를 섬세하게 살피고 도움을 줄 수 있어요.
체력 관리를 잘 못한다는 점이 약점인데요. 업무에 집중하기 위해서 필요성을 크게 느끼고 있어서, 컨디션 관리에 일가견이 있는 윤에게 방법을 배우고 있습니다.
쿼타북 프론트엔드에서 어떤 일을 하고 있나요?
에반(Frontend Chapter Lead): 저는 챕터 리드로서 동료들이 "일에만 집중할 수 있는 환경"을 만들기 위해 노력하고 있어요. 개인적으로 제가 생각하는 이상적인 리더는 동료들이 만족스러운 환경에서 행복하게 일할 수 있도록 서포트하는 사람이에요. 직접 선택한 일을 할 때 인간은 자기효능감이 가장 커진다고 생각하기 때문에 동료들이 스스로 옳다고 생각하는 방향으로 결정하고 움직일 수 있도록 도우려고 합니다. 다만 이런 리더십은 의사결정 권한을 타인에게 넘겨주되, 책임은 자신이 져야 한다는 의미이기도 해서 많은 용기가 필요하죠. 그런 용기를 낼 수 있는 리더이자 동료가 되기 위해 계속해서 노력하는 중입니다.
한편으로 리드로서 프론트엔드 챕터의 목표와 방향성을 제안하고, 모호한 문제를 해결하거나 동료들이 겪고 있는 어려움을 해소하기 위해 노력하고 있어요. 동료들이 자기가 맡은 일에 집중하면서 다른 것들에 신경을 쓰지 않도록 지원하는 역할이죠. 좀 더 많은 문제와 다양한 상황을 경험하면서 시행착오를 겪었기 때문에 역할에 자신감을 가지고 일하고 있어요.
노엘(Frontend Engineer): VC 스쿼드 소속 메이커로 투자자 고객을 위한 서비스를 개발하고 있어요. 동시에 챕터 차원에서 함께 쓸 수 있는 추상적인 모듈을 설계하고 있습니다. 생산성을 10X 할 수 있는 여러 가지 방법을 고민하고 있어요. 한 번의 견고한 설계로 여러 사람이 편의를 얻을 수 있는 일이라 보람이 있죠.
윤(Frontend Engineer): 저는 프론트엔드 챕터 소속이자, 스타트업 스쿼드 소속 개발자로서 스타트업 고객사의 문제를 해결하는 일을 하고 있어요. 가장 최근에는 스타트업 고객사가 투자사에게 영업보고할 때 겪는 불편을 해결하는 과정을 함께 고민하고 개발하는 일을 하고 있어요. 다수의 투자를 받은 스타트업은 여러 투자사를 대상으로 여러 차례 중복된 보고를 해야하고, 반대로 투자사는 여러 포트폴리오 스타트업을 대상으로 중복해서 보고를 요청해야하는 번거로움이 있는데, 이런 불편함을 한 번에 해결해 주는 멋진 제품을 동료들과 만들고 있습니다.
쿼타북 프론트엔드 챕터의 특별한 개발 문화가 있나요?
에반(Frontend Chapter Lead): 우리 챕터에는 ‘허락보다 용서가 쉽다’는 말이 있습니다. 원하는 코드가 있다면 우선 작성하고, 논의는 그 다음에 하는 거죠.
저는 뭔가 하고 싶다는 마음 자체가 굉장히 소중하다고 생각하거든요. 일반적인 직장인처럼 일한다면 그냥 시키는 대로 하게 되는 경우가 많잖아요. 하고 싶다는 마음은 누구에게나 언제나 있는 게 아니라는 거죠. 소중한 마음이 정말 임팩트를 내기 위해서는 이걸 구현해 내고 실천까지 해내는 데 있어 아무런 심리적 허들도 있어서는 안 된다고 봅니다.
만약 뭔가 하려고 할 때 챕터의 6명을 모두 설득해야 한다면 굉장히 큰 심리적 허들이 생긴다고 보는 거죠. 아무래도 실행 전 논의가 많아지게 되면 누구나 편하게 기여할 수 있는 일임에도 불구하고 논의에 대한 피로도 때문에 망설이게 되기도 하고요. 차라리 그걸 없애고 리뷰는 어차피 하게 될테니 그때 철저히 논의하자는 거예요. 만들어진 코드를 보면서 이야기하면 이해도 더 잘 될 테고요.
이런 시도를 통해 더 빠른 실행과 실패를 거듭하면서 미친 속도로 성장하자는 모두의 약속이에요. 각자에 대한 신뢰를 기반으로 리뷰 전까지 모든 시도를 자유롭게 하되, 리뷰와 배포 이후 발생하는 일에 대한 책임은 챕터 전체가 함께 지고 가자는 공감대를 가지고 있습니다.
윤(Frontend Engineer): 코드 리뷰 이야기가 나왔는데, 저는 쿼타랩의 코드 리뷰 퀄리티와 속도는 업계 최고 수준이라고 자신해요. 누가 강제하지 않아도, 동료 개발자의 코드 퀄리티와 성장을 위해 말 그대로 ASAP 리뷰를 해 주는 동료들이 있어요. 개발을 사랑하는 이들로만 구성된 챕터가 누릴 수 있는 장점 중 하나죠.

프론트엔드 엔지니어 윤
코드 리뷰의 퀄리티와 속도에 대해 어떻게 자신할 수 있나요?
에반(Frontend Chapter Lead): 챕터에 코드 리뷰를 올리면 “좋네요”하고 넘어가는 경우가 정말 드물어요. 이상한 코드는 없는지, 더 개선할 점은 없는지 강하게 챌린지 들어오는 경우가 많죠. 이 과정에서 의견 충돌이 있더라도 언제나 코드의 퀄리티를 고려하여 논의를 피하지 않습니다.
‘남들 다 하니까’, ‘해야 하니까’하는 리뷰는 저희에게 존재하지 않습니다. 리뷰는 제대로 해야 리뷰고, 그렇지 않으면 단순한 승인에 가깝게 돼요. 쿼타랩 프론트엔드 챕터는 400건의 리뷰라면 400번 치열하게 함께 고민하고 논의합니다. 실제로 이번 한 주에만 챕터에서 425건 정도 작업 내용을 머지(merge)했는데요. 그 말인 즉슨 425건의 치열한 토론이 발생했다는 거겠죠?
쿼타북 프론트엔드 챕터가 원팀으로 일하기 위해 만들어 나가고 있는 그라운드룰은 무엇인가요?
노엘(Frontend Engineer): 사실 필요하지 않은 룰은 만들지 않는 편이 좋다는 데 다들 공감대가 있어요. ‘DRI의 권한을 침해하지 않기’처럼 정말 필요한 룰만 정확히 만들어 지킵니다.
에반(Frontend Chapter Lead): 맞아요. 재미있게 일을 하려면 자유가 있어야 합니다. 자유가 없이 일을 한다면 재미가 있을 수 없죠. 다만 이런 자유에 따라오는 책임도 진다는 동의가 모두에게 있어요. 저희 팀원들에게는 이 책임에 대한 역량도 있다고 믿고 있습니다.
앞서 잠깐 이야기했듯 “머지 후 발생하는 모든 이슈에 대해 챕터 전체가 책임진다”는 암묵적인 룰이 있는데요. 운영 환경에 코드가 배포되었다는 것은 코드 작성자 외에도 챕터가 그 코드에 동의했다는 것을 의미해요. 코드 리뷰는 챕터 누구라도 함께 할 수 있고요. 그렇기 때문에 운영에 배포된 코드에서 문제가 발생했다면 코드 작성자나 그 버그를 잡아내지 못 한 리뷰어만의 책임이 아니라, 리뷰에 참여할 자유가 있었음에도 리뷰하지 못했던 프론트엔드 챕터 모두의 책임이 되는 것이죠. 이런 룰은 챕터 전체를 더 강한 ‘원팀’으로 일할 수 있게 해주는 것 같습니다.
이렇게 동료의 자율성을 존중하고 함께 책임을 지는 문화가 쿼타랩 프론트엔드 챕터를 더 끈끈한 원팀으로 만들어주는 것이라 생각합니다.
윤(Frontend Engineer): 제가 생각하는 우리 챕터의 그라운드룰은 ‘상호 존중’인 것 같아요. 하드 스킬 레벨과 상관 없이 동료들의 의사 결정 과정이 신뢰할 만하다면, 그것을 믿고 지원해 주고, 또 조언도 아끼지 않는 문화가 있어요. 다만 무조건적인 존중과 신뢰는 아니에요. 아닌 것은 아니라고 얘기하는 조직이기 때문에 더욱 서로에 대한 신뢰가 높아지는 것 같아요.

쿼타랩 프론트엔드 챕터 리드 에반
앞으로 어떤 목표를 가지고 있나요?
에반(Frontend Chapter Lead): 조직 관점에서는 프론트엔드 챕터뿐 아니라 쿼타랩 팀에서 일하는 모든 동료가 자신이 전문성을 가진 범위 내에서 온전한 자율과 책임을 행사할 수 있는 조직을 만드는 것이 목표예요.
이런 조직이 되기 위해서는 동료들 간의 두터운 신뢰가 필수적인데요. 이런 신뢰를 만들어 내기 위해서는 좋은 채용을 통해 뛰어난 동료를 모으는 것, 의사결정권을 위임하기 위한 리더들의 용기, 모두가 같은 곳을 보고 달릴 수 있는 조직 전체의 명확한 비전과 목표 등 다양한 요소들이 모두 충족되어야 합니다.
물론 지금도 쿼타랩은 높은 수준의 자율과 책임 문화를 실천하고 있는 조직이지만, 초기 스타트업인 만큼 아직 더 성장할 수 있는 잠재력과 능력이 많이 남은 조직이기도 합니다. 여기서 제 목표와 역할은 쿼타랩을 지금보다 더 훌륭한 팀으로 만들기 위해 더 좋은 방법을 강구하고 빠르게 실천하는 것이라고 생각해요.
개인적으로는 멘토링이나 글을 통해 제가 해온 경험을 다른 사람들과 나누고 그분들의 성장을 돕는 삶을 살고 싶습니다.
윤(Frontend Engineer): 더 많은 고객들과 투자사들을 하루라도 빨리 모시게 되면 좋겠습니다. 저 역시 맡은 역할이 있지만 그 이전에 스타트업의 구성원이다 보니, 함께 소중한 시간을 보내고 있는 훌륭한 동료들의 노력이 잘 쓰이며 빛을 발할 수 있기를 바라고 있습니다.
개인적으로는 세상에 나만의 것을 내놓는다는 목표로 일하고 있어요. 앞으로 5년 내에 창업하는 것이 목표에요.
어떤 동료와 함께 하기를 기대하나요?
에반(Frontend Chapter Lead): 일을 그저 일로써만 대하지 않는 동료들과 함께하고 싶어요.
개발을 하는 것, 내 능력을 통해 세상을 바꾸고 비즈니스 임팩트를 만들어내는 행위가 그저 인생의 일부가 아닌 정말로 이런 가치를 달성하는 것이 내 인생의 우선순위 1순위인 동료들과 함께한다면, 아무리 일이 많거나 어렵더라도 함께 등을 맞대고 헤쳐 나갈 수 있을 것 같아요.
윤(Frontend Engineer): 쿼타북의 도메인이 비상장 증권 도메인이라 다소 딱딱하거나 어렵게 느껴지실 수 있지만, 정해진 룰 밖에서 자신만의 방식으로 문제를 해결해 나가는 분들만 모여있는, 딱딱함과는 다소 거리가 먼 조직이에요. 이런 멋진 동료들과 함께 문제를 제대로 해결하고 싶으신 분과 함께라면 가슴이 뛸 것 같네요.
지원하는 분들에게 미리 알려주고 싶은 팁은?
노엘(Frontend Engineer): 아주 현실적인 팁이라면 이력서 스킬셋(Skill Set, 능력) 부분에 스스로 레벨이나 점수를 매기지 않는 것을 추천해요. 검토하는 입장에서 특정한 기대치가 생겨날 수 있어 유의해야 합니다.
에반(Frontend Chapter Lead): 마지막으로 개발자로서의 역량은 학력이나 경력보다는 코드 자체로 판단합니다. 이를 확인할 수 있는 깃헙(GitHub) 링크를 꼭 공유해 주시면 좋아요. 깃헙에는 확인할 수 있는 프로젝트를 올려두거나 어필하고 싶은 특이 사항이 있다면 이를 주의 깊게 봐달라는 설명을 덧붙여서 주시면 정확한 검토와 평가에 더욱 도움이 됩니다.
쿼타랩 프론트엔드 챕터는 자율과 책임을 기반으로 빠르게 실행하고 개선하며 성장을 거듭하고 있습니다. 국내 최초로 ‘비상장 금융 인프라’를 함께 만들어 나갈 뛰어난 동료를 찾고 있으니, 아무도 가보지 않은 길을 개척해보고 싶으신 분들의 많은 관심 부탁드립니다.
※ Legal disclaimer │ 법적 고지 사항
쿼타북은 법률 또는 기타 전문적인 자문을 제공하는 주체가 아니며, 쿼타북이 본 웹사이트 및/또는 기타 매체 등을 통하여 전달하는 정보는 일반적인 정보 공유 목적으로만 제공됩니다. 쿼타북이 제공하는 어떠한 정보도 법률 또는 기타 전문적인 자문으로 해석되지 아니하며 이를 어떠한 결정이나 조치의 근거로 활용하여서는 안됩니다. 본 웹사이트 및/또는 기타 쿼타북이 운영하는 매체를 통하여 제공되는 정보는 관련된 가장 최신의 내용이 반영된 정보가 아닐 수 있습니다. 또한 본 웹사이트에 포함된 외부 제3자의 웹사이트 및 기타 정보에 대한 링크는 이용자의 편의를 위하여 제공되는 것일 뿐이며 이로써 링크된 제3자 제공 정보 등을 이용자에게 추천하는 것이 아님을 명시합니다.

QuotaLab Team
여러 세대를 위한 최초의 비상장 금융 인프라를 만들어 갑니다.

‘온전한 자율과 철저한 책임’으로 만드는 최초의 비상장 금융 인프라
쿼타랩 프론트엔드 챕터 이야기

QuotaLab Team
·
여러 세대를 위한 최초의 비상장 금융 인프라를 만들어 갑니다.
쿼타랩은 챕터와 스쿼드로 이루어져 있습니다. 같은 직무를 하는 팀이 챕터, 같은 제품이나 기능을 만드는 팀이 스쿼드입니다. 그 중에서도 오늘은 쿼타랩 프론트엔드 챕터의 이야기를 준비했습니다. 각기 다른 스쿼드에 속한 개인으로서, 또한 서로 같은 직무를 함께 하는 팀으로서 이들은 어떻게 일하고 있을까요?
각자 자기소개를 부탁드립니다.
에반(Frontend Chapter Lead): 프론트엔드 개발자 문동욱입니다. 2016년부터 개발을 시작해서 다양한 스타트업을 거쳐왔습니다. 시리즈 A에서 D로 라운드를 뛰거나, 인원이 300명에서 2,000명 이상으로 변하는 등 빠르게 성장하는 조직에서 일해본 경험이 많습니다.
현재는 쿼타랩에서 프론트엔드 챕터 리드와 VC 스쿼드의 엔지니어링 매니저 역할을 맡고 있습니다. 때때로 프론트엔드 리소스가 부족한 스쿼드를 지원하기도 합니다.
윤(Frontend Engineer): 1년 차 프론트엔드 개발자 백승윤입니다. 프론트엔드 개발자로서는 쿼타랩이 첫 직장입니다.
노엘(Frontend Engineer): 프론트엔드 개발자 김민혁입니다. 고등학교를 졸업한 2020년 모바일 개발로 커리어를 시작했고, 두 번째 직장에서 시스템 개발과 프론트엔드 개발에 깊게 관여한 것을 계기로 세 번째 직장인 쿼타랩에서는 프론트엔드 개발자로 자리 잡아 일하고 있습니다.
여러분은 스스로 어떤 개발자라고 생각하나요?
노엘(Frontend Engineer): 어려운 질문이네요. 필요하다면 무엇이든 할 수 있는 개발자라고 생각합니다.

프론트엔드 엔지니어 노엘과 에반
에반(Frontend Chapter Lead): 제가 가진 능력으로 세상을 바꾸는 일에 매력을 느끼는 개발자인 것 같습니다. 제품이 실질적으로 사람들의 삶을 편하게 만들어 주고, 이에 따라 회사가 성장할 때 큰 기쁨을 느껴요. 다른 사람의 성장을 돕거나 조직을 성장시키는 일에도 관심이 많습니다.
윤(Frontend Engineer): 커뮤니케이션 잘하는 개발자를 지향합니다. 동료들과 문제를 해결하다 보면, 개발 이전에 커뮤니케이션을 통해 이슈를 해결하거나 시간 및 비용을 줄일 수 있는 사례도 많더라고요. 일 잘하는 개발자가 되기 위해서는 커뮤니케이션 능력도 필수로 가져야 하죠.
쿼타랩 프론트엔드 개발자로 일하는 장점은 무엇인가요?
노엘(Frontend Engineer): 경험해 본 제품 중 쿼타북은 복잡도가 정말 높은 편이에요. 비즈니스 도메인 자체도 난이도가 있고, 하나의 기능에 얽힌 여러 이해관계를 고려하기도 쉽지 않죠. 현재 개발과 함께 설계도 직접 하고 있는데, 쿼타북에서 잘 해낼 수 있다면 개발자로서 급성장할 수 있겠다는 생각을 자주 합니다.
윤(Frontend Engineer): 크게 세 가지 정도가 있는데요. 먼저, 다양한 직군과 협력하며 제품을 제로(0)부터 구축하는 경험을 할 수 있습니다. 프로덕트 디자이너, 백엔드 개발자, 프로덕트 매니저, 데브옵스(DevOps) 개발자 등 다양한 직군의 이해관계자와 소통하며 제품을 만들어 가는 과정이 가끔 도전적일 수 있지만, 개발자로서 제품에 직접 기여할 수 있는 즐거움을 느끼고 있습니다.
또, 프론트엔드 분야의 최신 기술 동향과 이슈를 팀에서 함께 고민하고, 우리 제품에 맞추어 적용하는 재미가 있습니다. 단순히 남들이 하니까 나도 하는 기계적인 개발이 아니라는 점이 특히 매력적이에요.
마지막으로, 비상장 증권 도메인에 대한 지식을 습득하게 됩니다. 비상장 증권 시장에서의 어려움을 해결해 나가고 있는 쿼타북을 만들다 보면, 주식, 스톡옵션, RSU 등에 대해 필요하면서도 어려운 개념들을 자연스럽게 체득해 나갈 수 있어요.
에반(Frontend Chapter Lead): 특히 비상장 증권 지식은 창업을 꿈꾸는 개발자라면 꼭 필요합니다. 미래에 자신만의 비즈니스를 하고 싶어 하는 개발자가 적지 않거든요. 만들고자 하는 서비스가 있으면 처음부터 끝까지 자기가 만들 수 있으니까요. 그래서 사이드 프로젝트를 하거나 회사를 아예 그만두고 창업을 하는 사례도 꽤 많은 편이죠. 윤도 나중에 창업하고 싶다고 하지 않으셨나요?
윤(Frontend Engineer): 맞아요. 스타트업 설립 후 어떤 경영 관리가 필요한지 미리 알아가는 중입니다.
에반(Frontend Chapter Lead): 말하자면 창업 전 집중적인 예행연습이네요.
쿼타북 프론트엔드 개발자로 일하는 것의 큰 장점 중 하나는 개선과 변화를 주는 가능성을 직접 갖게 된다는 점입니다. 대규모 조직에서는 개인의 영향력이 제한적일 수 있어요. 예를 들어 2천 명 규모에 있는 조직에서 영향력과 50명 규모의 조직에서의 영향력은 아무래도 차이가 있을 테고요. 하지만 쿼타랩은 초기 스타트업이라 다양한 도전이 가능합니다. 명확한 근거와 설득력만 있다면 변화를 두려워하지 않는 동료들과 함께 무엇이라도 시도할 수 있어요. 쿼타랩 프론트엔드 챕터는 현재 챕터원들처럼 일을 진심으로 좋아하는 분들을 모시기 위해 노력하고 있습니다. 앞으로도 문제 해결에 집중하며 치열하게 논의하는 경험을 계속해 나가기 위해서요.

쿼타랩 프론트엔드 챕터
쿼타북 프론트엔드 챕터는 어떤 팀인가요?
에반(Frontend Chapter Lead): 온전한 자율과 철저한 책임을 충실하게 실현해 내기 위해 노력하는 챕터입니다.
쿼타랩의 프론트엔드 개발자들은 모두 자신이 담당하는 서비스에 대한 기술적 의사결정에 대한 DRI(Directly Responsible Individual, 최종 의사결정권자)입니다. 권한은 서로에 대한 신뢰를 기반으로 주어지는 것이기 때문에 동료들의 신뢰를 얻고 유지하기 위해 각자 끊임없이 고민하고 노력해야 하죠. 반대로 말하면 신뢰만 얻을 수 있다면 이후로는 내가 하고 싶은 모든 것을 도전해 볼 수 있는 팀이라고 할 수 있어요.
챕터 리드라도 다른 프론트엔드 개발자가 정한 바를 침해할 수 없어서 저 역시도 항상 동료를 설득하고 공감시키기 위해 많은 노력을 기울이고 있습니다.
윤(Frontend Engineer): 챕터원들의 공통점은 멈춰 있는 것을 견디지 못한다는 점이에요. 챕터가 모두 서로에게 자극받으며 꾸준히 성장하고자 하는 욕심이 있는 분들로 구성되어 있어요.
동료들의 자율성을 최대한 보장해 주고 가장 효율적으로 일할 수 있는 방법을 고민해 주는 리드가 있다는 점도 챕터원으로서 자랑거리이고요.
노엘(Frontend Engineer): 챕터의 모두가 각기 다른 강점을 가지고 있어요. 이 강점을 챕터 내에서 발휘하고 전파할 수 있는 능력이 있다는 점이 특징이라고 생각합니다. 한 챕터원이 가진 약점을 다른 챕터원이 보완하는 일이 가능하죠.
예를 들면 저는 설계의 중요성을 크게 생각하고, 꽤 많은 시간을 들여 설계를 최대한 잘하고자 노력하는 성향이에요. 혼자 잘 해내고 끝이 아니라 챕터 내에서 이를 공유하여 공동의 성장 기회를 만들고 있습니다. 반면 저에게 부족한 커뮤니케이션 능력은 에반이나 윤으로부터 적극적인 도움과 조언을 받아 개선해 나가고 있고요.
에반(Frontend Chapter Lead): 저는 비즈니스를 좋아하고 회사 자체에 관심이 많다는 점이 스스로 강점이라고 생각해요. 또 개인의 상태나 심리를 섬세하게 살피고 도움을 줄 수 있어요.
체력 관리를 잘 못한다는 점이 약점인데요. 업무에 집중하기 위해서 필요성을 크게 느끼고 있어서, 컨디션 관리에 일가견이 있는 윤에게 방법을 배우고 있습니다.
쿼타북 프론트엔드에서 어떤 일을 하고 있나요?
에반(Frontend Chapter Lead): 저는 챕터 리드로서 동료들이 "일에만 집중할 수 있는 환경"을 만들기 위해 노력하고 있어요. 개인적으로 제가 생각하는 이상적인 리더는 동료들이 만족스러운 환경에서 행복하게 일할 수 있도록 서포트하는 사람이에요. 직접 선택한 일을 할 때 인간은 자기효능감이 가장 커진다고 생각하기 때문에 동료들이 스스로 옳다고 생각하는 방향으로 결정하고 움직일 수 있도록 도우려고 합니다. 다만 이런 리더십은 의사결정 권한을 타인에게 넘겨주되, 책임은 자신이 져야 한다는 의미이기도 해서 많은 용기가 필요하죠. 그런 용기를 낼 수 있는 리더이자 동료가 되기 위해 계속해서 노력하는 중입니다.
한편으로 리드로서 프론트엔드 챕터의 목표와 방향성을 제안하고, 모호한 문제를 해결하거나 동료들이 겪고 있는 어려움을 해소하기 위해 노력하고 있어요. 동료들이 자기가 맡은 일에 집중하면서 다른 것들에 신경을 쓰지 않도록 지원하는 역할이죠. 좀 더 많은 문제와 다양한 상황을 경험하면서 시행착오를 겪었기 때문에 역할에 자신감을 가지고 일하고 있어요.
노엘(Frontend Engineer): VC 스쿼드 소속 메이커로 투자자 고객을 위한 서비스를 개발하고 있어요. 동시에 챕터 차원에서 함께 쓸 수 있는 추상적인 모듈을 설계하고 있습니다. 생산성을 10X 할 수 있는 여러 가지 방법을 고민하고 있어요. 한 번의 견고한 설계로 여러 사람이 편의를 얻을 수 있는 일이라 보람이 있죠.
윤(Frontend Engineer): 저는 프론트엔드 챕터 소속이자, 스타트업 스쿼드 소속 개발자로서 스타트업 고객사의 문제를 해결하는 일을 하고 있어요. 가장 최근에는 스타트업 고객사가 투자사에게 영업보고할 때 겪는 불편을 해결하는 과정을 함께 고민하고 개발하는 일을 하고 있어요. 다수의 투자를 받은 스타트업은 여러 투자사를 대상으로 여러 차례 중복된 보고를 해야하고, 반대로 투자사는 여러 포트폴리오 스타트업을 대상으로 중복해서 보고를 요청해야하는 번거로움이 있는데, 이런 불편함을 한 번에 해결해 주는 멋진 제품을 동료들과 만들고 있습니다.
쿼타북 프론트엔드 챕터의 특별한 개발 문화가 있나요?
에반(Frontend Chapter Lead): 우리 챕터에는 ‘허락보다 용서가 쉽다’는 말이 있습니다. 원하는 코드가 있다면 우선 작성하고, 논의는 그 다음에 하는 거죠.
저는 뭔가 하고 싶다는 마음 자체가 굉장히 소중하다고 생각하거든요. 일반적인 직장인처럼 일한다면 그냥 시키는 대로 하게 되는 경우가 많잖아요. 하고 싶다는 마음은 누구에게나 언제나 있는 게 아니라는 거죠. 소중한 마음이 정말 임팩트를 내기 위해서는 이걸 구현해 내고 실천까지 해내는 데 있어 아무런 심리적 허들도 있어서는 안 된다고 봅니다.
만약 뭔가 하려고 할 때 챕터의 6명을 모두 설득해야 한다면 굉장히 큰 심리적 허들이 생긴다고 보는 거죠. 아무래도 실행 전 논의가 많아지게 되면 누구나 편하게 기여할 수 있는 일임에도 불구하고 논의에 대한 피로도 때문에 망설이게 되기도 하고요. 차라리 그걸 없애고 리뷰는 어차피 하게 될테니 그때 철저히 논의하자는 거예요. 만들어진 코드를 보면서 이야기하면 이해도 더 잘 될 테고요.
이런 시도를 통해 더 빠른 실행과 실패를 거듭하면서 미친 속도로 성장하자는 모두의 약속이에요. 각자에 대한 신뢰를 기반으로 리뷰 전까지 모든 시도를 자유롭게 하되, 리뷰와 배포 이후 발생하는 일에 대한 책임은 챕터 전체가 함께 지고 가자는 공감대를 가지고 있습니다.
윤(Frontend Engineer): 코드 리뷰 이야기가 나왔는데, 저는 쿼타랩의 코드 리뷰 퀄리티와 속도는 업계 최고 수준이라고 자신해요. 누가 강제하지 않아도, 동료 개발자의 코드 퀄리티와 성장을 위해 말 그대로 ASAP 리뷰를 해 주는 동료들이 있어요. 개발을 사랑하는 이들로만 구성된 챕터가 누릴 수 있는 장점 중 하나죠.

프론트엔드 엔지니어 윤
코드 리뷰의 퀄리티와 속도에 대해 어떻게 자신할 수 있나요?
에반(Frontend Chapter Lead): 챕터에 코드 리뷰를 올리면 “좋네요”하고 넘어가는 경우가 정말 드물어요. 이상한 코드는 없는지, 더 개선할 점은 없는지 강하게 챌린지 들어오는 경우가 많죠. 이 과정에서 의견 충돌이 있더라도 언제나 코드의 퀄리티를 고려하여 논의를 피하지 않습니다.
‘남들 다 하니까’, ‘해야 하니까’하는 리뷰는 저희에게 존재하지 않습니다. 리뷰는 제대로 해야 리뷰고, 그렇지 않으면 단순한 승인에 가깝게 돼요. 쿼타랩 프론트엔드 챕터는 400건의 리뷰라면 400번 치열하게 함께 고민하고 논의합니다. 실제로 이번 한 주에만 챕터에서 425건 정도 작업 내용을 머지(merge)했는데요. 그 말인 즉슨 425건의 치열한 토론이 발생했다는 거겠죠?
쿼타북 프론트엔드 챕터가 원팀으로 일하기 위해 만들어 나가고 있는 그라운드룰은 무엇인가요?
노엘(Frontend Engineer): 사실 필요하지 않은 룰은 만들지 않는 편이 좋다는 데 다들 공감대가 있어요. ‘DRI의 권한을 침해하지 않기’처럼 정말 필요한 룰만 정확히 만들어 지킵니다.
에반(Frontend Chapter Lead): 맞아요. 재미있게 일을 하려면 자유가 있어야 합니다. 자유가 없이 일을 한다면 재미가 있을 수 없죠. 다만 이런 자유에 따라오는 책임도 진다는 동의가 모두에게 있어요. 저희 팀원들에게는 이 책임에 대한 역량도 있다고 믿고 있습니다.
앞서 잠깐 이야기했듯 “머지 후 발생하는 모든 이슈에 대해 챕터 전체가 책임진다”는 암묵적인 룰이 있는데요. 운영 환경에 코드가 배포되었다는 것은 코드 작성자 외에도 챕터가 그 코드에 동의했다는 것을 의미해요. 코드 리뷰는 챕터 누구라도 함께 할 수 있고요. 그렇기 때문에 운영에 배포된 코드에서 문제가 발생했다면 코드 작성자나 그 버그를 잡아내지 못 한 리뷰어만의 책임이 아니라, 리뷰에 참여할 자유가 있었음에도 리뷰하지 못했던 프론트엔드 챕터 모두의 책임이 되는 것이죠. 이런 룰은 챕터 전체를 더 강한 ‘원팀’으로 일할 수 있게 해주는 것 같습니다.
이렇게 동료의 자율성을 존중하고 함께 책임을 지는 문화가 쿼타랩 프론트엔드 챕터를 더 끈끈한 원팀으로 만들어주는 것이라 생각합니다.
윤(Frontend Engineer): 제가 생각하는 우리 챕터의 그라운드룰은 ‘상호 존중’인 것 같아요. 하드 스킬 레벨과 상관 없이 동료들의 의사 결정 과정이 신뢰할 만하다면, 그것을 믿고 지원해 주고, 또 조언도 아끼지 않는 문화가 있어요. 다만 무조건적인 존중과 신뢰는 아니에요. 아닌 것은 아니라고 얘기하는 조직이기 때문에 더욱 서로에 대한 신뢰가 높아지는 것 같아요.

쿼타랩 프론트엔드 챕터 리드 에반
앞으로 어떤 목표를 가지고 있나요?
에반(Frontend Chapter Lead): 조직 관점에서는 프론트엔드 챕터뿐 아니라 쿼타랩 팀에서 일하는 모든 동료가 자신이 전문성을 가진 범위 내에서 온전한 자율과 책임을 행사할 수 있는 조직을 만드는 것이 목표예요.
이런 조직이 되기 위해서는 동료들 간의 두터운 신뢰가 필수적인데요. 이런 신뢰를 만들어 내기 위해서는 좋은 채용을 통해 뛰어난 동료를 모으는 것, 의사결정권을 위임하기 위한 리더들의 용기, 모두가 같은 곳을 보고 달릴 수 있는 조직 전체의 명확한 비전과 목표 등 다양한 요소들이 모두 충족되어야 합니다.
물론 지금도 쿼타랩은 높은 수준의 자율과 책임 문화를 실천하고 있는 조직이지만, 초기 스타트업인 만큼 아직 더 성장할 수 있는 잠재력과 능력이 많이 남은 조직이기도 합니다. 여기서 제 목표와 역할은 쿼타랩을 지금보다 더 훌륭한 팀으로 만들기 위해 더 좋은 방법을 강구하고 빠르게 실천하는 것이라고 생각해요.
개인적으로는 멘토링이나 글을 통해 제가 해온 경험을 다른 사람들과 나누고 그분들의 성장을 돕는 삶을 살고 싶습니다.
윤(Frontend Engineer): 더 많은 고객들과 투자사들을 하루라도 빨리 모시게 되면 좋겠습니다. 저 역시 맡은 역할이 있지만 그 이전에 스타트업의 구성원이다 보니, 함께 소중한 시간을 보내고 있는 훌륭한 동료들의 노력이 잘 쓰이며 빛을 발할 수 있기를 바라고 있습니다.
개인적으로는 세상에 나만의 것을 내놓는다는 목표로 일하고 있어요. 앞으로 5년 내에 창업하는 것이 목표에요.
어떤 동료와 함께 하기를 기대하나요?
에반(Frontend Chapter Lead): 일을 그저 일로써만 대하지 않는 동료들과 함께하고 싶어요.
개발을 하는 것, 내 능력을 통해 세상을 바꾸고 비즈니스 임팩트를 만들어내는 행위가 그저 인생의 일부가 아닌 정말로 이런 가치를 달성하는 것이 내 인생의 우선순위 1순위인 동료들과 함께한다면, 아무리 일이 많거나 어렵더라도 함께 등을 맞대고 헤쳐 나갈 수 있을 것 같아요.
윤(Frontend Engineer): 쿼타북의 도메인이 비상장 증권 도메인이라 다소 딱딱하거나 어렵게 느껴지실 수 있지만, 정해진 룰 밖에서 자신만의 방식으로 문제를 해결해 나가는 분들만 모여있는, 딱딱함과는 다소 거리가 먼 조직이에요. 이런 멋진 동료들과 함께 문제를 제대로 해결하고 싶으신 분과 함께라면 가슴이 뛸 것 같네요.
지원하는 분들에게 미리 알려주고 싶은 팁은?
노엘(Frontend Engineer): 아주 현실적인 팁이라면 이력서 스킬셋(Skill Set, 능력) 부분에 스스로 레벨이나 점수를 매기지 않는 것을 추천해요. 검토하는 입장에서 특정한 기대치가 생겨날 수 있어 유의해야 합니다.
에반(Frontend Chapter Lead): 마지막으로 개발자로서의 역량은 학력이나 경력보다는 코드 자체로 판단합니다. 이를 확인할 수 있는 깃헙(GitHub) 링크를 꼭 공유해 주시면 좋아요. 깃헙에는 확인할 수 있는 프로젝트를 올려두거나 어필하고 싶은 특이 사항이 있다면 이를 주의 깊게 봐달라는 설명을 덧붙여서 주시면 정확한 검토와 평가에 더욱 도움이 됩니다.
쿼타랩 프론트엔드 챕터는 자율과 책임을 기반으로 빠르게 실행하고 개선하며 성장을 거듭하고 있습니다. 국내 최초로 ‘비상장 금융 인프라’를 함께 만들어 나갈 뛰어난 동료를 찾고 있으니, 아무도 가보지 않은 길을 개척해보고 싶으신 분들의 많은 관심 부탁드립니다.

‘온전한 자율과 철저한 책임’으로 만드는 최초의 비상장 금융 인프라
쿼타랩 프론트엔드 챕터 이야기

QuotaLab Team
·
여러 세대를 위한 최초의 비상장 금융 인프라를 만들어 갑니다.
쿼타랩은 챕터와 스쿼드로 이루어져 있습니다. 같은 직무를 하는 팀이 챕터, 같은 제품이나 기능을 만드는 팀이 스쿼드입니다. 그 중에서도 오늘은 쿼타랩 프론트엔드 챕터의 이야기를 준비했습니다. 각기 다른 스쿼드에 속한 개인으로서, 또한 서로 같은 직무를 함께 하는 팀으로서 이들은 어떻게 일하고 있을까요?
각자 자기소개를 부탁드립니다.
에반(Frontend Chapter Lead): 프론트엔드 개발자 문동욱입니다. 2016년부터 개발을 시작해서 다양한 스타트업을 거쳐왔습니다. 시리즈 A에서 D로 라운드를 뛰거나, 인원이 300명에서 2,000명 이상으로 변하는 등 빠르게 성장하는 조직에서 일해본 경험이 많습니다.
현재는 쿼타랩에서 프론트엔드 챕터 리드와 VC 스쿼드의 엔지니어링 매니저 역할을 맡고 있습니다. 때때로 프론트엔드 리소스가 부족한 스쿼드를 지원하기도 합니다.
윤(Frontend Engineer): 1년 차 프론트엔드 개발자 백승윤입니다. 프론트엔드 개발자로서는 쿼타랩이 첫 직장입니다.
노엘(Frontend Engineer): 프론트엔드 개발자 김민혁입니다. 고등학교를 졸업한 2020년 모바일 개발로 커리어를 시작했고, 두 번째 직장에서 시스템 개발과 프론트엔드 개발에 깊게 관여한 것을 계기로 세 번째 직장인 쿼타랩에서는 프론트엔드 개발자로 자리 잡아 일하고 있습니다.
여러분은 스스로 어떤 개발자라고 생각하나요?
노엘(Frontend Engineer): 어려운 질문이네요. 필요하다면 무엇이든 할 수 있는 개발자라고 생각합니다.

프론트엔드 엔지니어 노엘과 에반
에반(Frontend Chapter Lead): 제가 가진 능력으로 세상을 바꾸는 일에 매력을 느끼는 개발자인 것 같습니다. 제품이 실질적으로 사람들의 삶을 편하게 만들어 주고, 이에 따라 회사가 성장할 때 큰 기쁨을 느껴요. 다른 사람의 성장을 돕거나 조직을 성장시키는 일에도 관심이 많습니다.
윤(Frontend Engineer): 커뮤니케이션 잘하는 개발자를 지향합니다. 동료들과 문제를 해결하다 보면, 개발 이전에 커뮤니케이션을 통해 이슈를 해결하거나 시간 및 비용을 줄일 수 있는 사례도 많더라고요. 일 잘하는 개발자가 되기 위해서는 커뮤니케이션 능력도 필수로 가져야 하죠.
쿼타랩 프론트엔드 개발자로 일하는 장점은 무엇인가요?
노엘(Frontend Engineer): 경험해 본 제품 중 쿼타북은 복잡도가 정말 높은 편이에요. 비즈니스 도메인 자체도 난이도가 있고, 하나의 기능에 얽힌 여러 이해관계를 고려하기도 쉽지 않죠. 현재 개발과 함께 설계도 직접 하고 있는데, 쿼타북에서 잘 해낼 수 있다면 개발자로서 급성장할 수 있겠다는 생각을 자주 합니다.
윤(Frontend Engineer): 크게 세 가지 정도가 있는데요. 먼저, 다양한 직군과 협력하며 제품을 제로(0)부터 구축하는 경험을 할 수 있습니다. 프로덕트 디자이너, 백엔드 개발자, 프로덕트 매니저, 데브옵스(DevOps) 개발자 등 다양한 직군의 이해관계자와 소통하며 제품을 만들어 가는 과정이 가끔 도전적일 수 있지만, 개발자로서 제품에 직접 기여할 수 있는 즐거움을 느끼고 있습니다.
또, 프론트엔드 분야의 최신 기술 동향과 이슈를 팀에서 함께 고민하고, 우리 제품에 맞추어 적용하는 재미가 있습니다. 단순히 남들이 하니까 나도 하는 기계적인 개발이 아니라는 점이 특히 매력적이에요.
마지막으로, 비상장 증권 도메인에 대한 지식을 습득하게 됩니다. 비상장 증권 시장에서의 어려움을 해결해 나가고 있는 쿼타북을 만들다 보면, 주식, 스톡옵션, RSU 등에 대해 필요하면서도 어려운 개념들을 자연스럽게 체득해 나갈 수 있어요.
에반(Frontend Chapter Lead): 특히 비상장 증권 지식은 창업을 꿈꾸는 개발자라면 꼭 필요합니다. 미래에 자신만의 비즈니스를 하고 싶어 하는 개발자가 적지 않거든요. 만들고자 하는 서비스가 있으면 처음부터 끝까지 자기가 만들 수 있으니까요. 그래서 사이드 프로젝트를 하거나 회사를 아예 그만두고 창업을 하는 사례도 꽤 많은 편이죠. 윤도 나중에 창업하고 싶다고 하지 않으셨나요?
윤(Frontend Engineer): 맞아요. 스타트업 설립 후 어떤 경영 관리가 필요한지 미리 알아가는 중입니다.
에반(Frontend Chapter Lead): 말하자면 창업 전 집중적인 예행연습이네요.
쿼타북 프론트엔드 개발자로 일하는 것의 큰 장점 중 하나는 개선과 변화를 주는 가능성을 직접 갖게 된다는 점입니다. 대규모 조직에서는 개인의 영향력이 제한적일 수 있어요. 예를 들어 2천 명 규모에 있는 조직에서 영향력과 50명 규모의 조직에서의 영향력은 아무래도 차이가 있을 테고요. 하지만 쿼타랩은 초기 스타트업이라 다양한 도전이 가능합니다. 명확한 근거와 설득력만 있다면 변화를 두려워하지 않는 동료들과 함께 무엇이라도 시도할 수 있어요. 쿼타랩 프론트엔드 챕터는 현재 챕터원들처럼 일을 진심으로 좋아하는 분들을 모시기 위해 노력하고 있습니다. 앞으로도 문제 해결에 집중하며 치열하게 논의하는 경험을 계속해 나가기 위해서요.

쿼타랩 프론트엔드 챕터
쿼타북 프론트엔드 챕터는 어떤 팀인가요?
에반(Frontend Chapter Lead): 온전한 자율과 철저한 책임을 충실하게 실현해 내기 위해 노력하는 챕터입니다.
쿼타랩의 프론트엔드 개발자들은 모두 자신이 담당하는 서비스에 대한 기술적 의사결정에 대한 DRI(Directly Responsible Individual, 최종 의사결정권자)입니다. 권한은 서로에 대한 신뢰를 기반으로 주어지는 것이기 때문에 동료들의 신뢰를 얻고 유지하기 위해 각자 끊임없이 고민하고 노력해야 하죠. 반대로 말하면 신뢰만 얻을 수 있다면 이후로는 내가 하고 싶은 모든 것을 도전해 볼 수 있는 팀이라고 할 수 있어요.
챕터 리드라도 다른 프론트엔드 개발자가 정한 바를 침해할 수 없어서 저 역시도 항상 동료를 설득하고 공감시키기 위해 많은 노력을 기울이고 있습니다.
윤(Frontend Engineer): 챕터원들의 공통점은 멈춰 있는 것을 견디지 못한다는 점이에요. 챕터가 모두 서로에게 자극받으며 꾸준히 성장하고자 하는 욕심이 있는 분들로 구성되어 있어요.
동료들의 자율성을 최대한 보장해 주고 가장 효율적으로 일할 수 있는 방법을 고민해 주는 리드가 있다는 점도 챕터원으로서 자랑거리이고요.
노엘(Frontend Engineer): 챕터의 모두가 각기 다른 강점을 가지고 있어요. 이 강점을 챕터 내에서 발휘하고 전파할 수 있는 능력이 있다는 점이 특징이라고 생각합니다. 한 챕터원이 가진 약점을 다른 챕터원이 보완하는 일이 가능하죠.
예를 들면 저는 설계의 중요성을 크게 생각하고, 꽤 많은 시간을 들여 설계를 최대한 잘하고자 노력하는 성향이에요. 혼자 잘 해내고 끝이 아니라 챕터 내에서 이를 공유하여 공동의 성장 기회를 만들고 있습니다. 반면 저에게 부족한 커뮤니케이션 능력은 에반이나 윤으로부터 적극적인 도움과 조언을 받아 개선해 나가고 있고요.
에반(Frontend Chapter Lead): 저는 비즈니스를 좋아하고 회사 자체에 관심이 많다는 점이 스스로 강점이라고 생각해요. 또 개인의 상태나 심리를 섬세하게 살피고 도움을 줄 수 있어요.
체력 관리를 잘 못한다는 점이 약점인데요. 업무에 집중하기 위해서 필요성을 크게 느끼고 있어서, 컨디션 관리에 일가견이 있는 윤에게 방법을 배우고 있습니다.
쿼타북 프론트엔드에서 어떤 일을 하고 있나요?
에반(Frontend Chapter Lead): 저는 챕터 리드로서 동료들이 "일에만 집중할 수 있는 환경"을 만들기 위해 노력하고 있어요. 개인적으로 제가 생각하는 이상적인 리더는 동료들이 만족스러운 환경에서 행복하게 일할 수 있도록 서포트하는 사람이에요. 직접 선택한 일을 할 때 인간은 자기효능감이 가장 커진다고 생각하기 때문에 동료들이 스스로 옳다고 생각하는 방향으로 결정하고 움직일 수 있도록 도우려고 합니다. 다만 이런 리더십은 의사결정 권한을 타인에게 넘겨주되, 책임은 자신이 져야 한다는 의미이기도 해서 많은 용기가 필요하죠. 그런 용기를 낼 수 있는 리더이자 동료가 되기 위해 계속해서 노력하는 중입니다.
한편으로 리드로서 프론트엔드 챕터의 목표와 방향성을 제안하고, 모호한 문제를 해결하거나 동료들이 겪고 있는 어려움을 해소하기 위해 노력하고 있어요. 동료들이 자기가 맡은 일에 집중하면서 다른 것들에 신경을 쓰지 않도록 지원하는 역할이죠. 좀 더 많은 문제와 다양한 상황을 경험하면서 시행착오를 겪었기 때문에 역할에 자신감을 가지고 일하고 있어요.
노엘(Frontend Engineer): VC 스쿼드 소속 메이커로 투자자 고객을 위한 서비스를 개발하고 있어요. 동시에 챕터 차원에서 함께 쓸 수 있는 추상적인 모듈을 설계하고 있습니다. 생산성을 10X 할 수 있는 여러 가지 방법을 고민하고 있어요. 한 번의 견고한 설계로 여러 사람이 편의를 얻을 수 있는 일이라 보람이 있죠.
윤(Frontend Engineer): 저는 프론트엔드 챕터 소속이자, 스타트업 스쿼드 소속 개발자로서 스타트업 고객사의 문제를 해결하는 일을 하고 있어요. 가장 최근에는 스타트업 고객사가 투자사에게 영업보고할 때 겪는 불편을 해결하는 과정을 함께 고민하고 개발하는 일을 하고 있어요. 다수의 투자를 받은 스타트업은 여러 투자사를 대상으로 여러 차례 중복된 보고를 해야하고, 반대로 투자사는 여러 포트폴리오 스타트업을 대상으로 중복해서 보고를 요청해야하는 번거로움이 있는데, 이런 불편함을 한 번에 해결해 주는 멋진 제품을 동료들과 만들고 있습니다.
쿼타북 프론트엔드 챕터의 특별한 개발 문화가 있나요?
에반(Frontend Chapter Lead): 우리 챕터에는 ‘허락보다 용서가 쉽다’는 말이 있습니다. 원하는 코드가 있다면 우선 작성하고, 논의는 그 다음에 하는 거죠.
저는 뭔가 하고 싶다는 마음 자체가 굉장히 소중하다고 생각하거든요. 일반적인 직장인처럼 일한다면 그냥 시키는 대로 하게 되는 경우가 많잖아요. 하고 싶다는 마음은 누구에게나 언제나 있는 게 아니라는 거죠. 소중한 마음이 정말 임팩트를 내기 위해서는 이걸 구현해 내고 실천까지 해내는 데 있어 아무런 심리적 허들도 있어서는 안 된다고 봅니다.
만약 뭔가 하려고 할 때 챕터의 6명을 모두 설득해야 한다면 굉장히 큰 심리적 허들이 생긴다고 보는 거죠. 아무래도 실행 전 논의가 많아지게 되면 누구나 편하게 기여할 수 있는 일임에도 불구하고 논의에 대한 피로도 때문에 망설이게 되기도 하고요. 차라리 그걸 없애고 리뷰는 어차피 하게 될테니 그때 철저히 논의하자는 거예요. 만들어진 코드를 보면서 이야기하면 이해도 더 잘 될 테고요.
이런 시도를 통해 더 빠른 실행과 실패를 거듭하면서 미친 속도로 성장하자는 모두의 약속이에요. 각자에 대한 신뢰를 기반으로 리뷰 전까지 모든 시도를 자유롭게 하되, 리뷰와 배포 이후 발생하는 일에 대한 책임은 챕터 전체가 함께 지고 가자는 공감대를 가지고 있습니다.
윤(Frontend Engineer): 코드 리뷰 이야기가 나왔는데, 저는 쿼타랩의 코드 리뷰 퀄리티와 속도는 업계 최고 수준이라고 자신해요. 누가 강제하지 않아도, 동료 개발자의 코드 퀄리티와 성장을 위해 말 그대로 ASAP 리뷰를 해 주는 동료들이 있어요. 개발을 사랑하는 이들로만 구성된 챕터가 누릴 수 있는 장점 중 하나죠.

프론트엔드 엔지니어 윤
코드 리뷰의 퀄리티와 속도에 대해 어떻게 자신할 수 있나요?
에반(Frontend Chapter Lead): 챕터에 코드 리뷰를 올리면 “좋네요”하고 넘어가는 경우가 정말 드물어요. 이상한 코드는 없는지, 더 개선할 점은 없는지 강하게 챌린지 들어오는 경우가 많죠. 이 과정에서 의견 충돌이 있더라도 언제나 코드의 퀄리티를 고려하여 논의를 피하지 않습니다.
‘남들 다 하니까’, ‘해야 하니까’하는 리뷰는 저희에게 존재하지 않습니다. 리뷰는 제대로 해야 리뷰고, 그렇지 않으면 단순한 승인에 가깝게 돼요. 쿼타랩 프론트엔드 챕터는 400건의 리뷰라면 400번 치열하게 함께 고민하고 논의합니다. 실제로 이번 한 주에만 챕터에서 425건 정도 작업 내용을 머지(merge)했는데요. 그 말인 즉슨 425건의 치열한 토론이 발생했다는 거겠죠?
쿼타북 프론트엔드 챕터가 원팀으로 일하기 위해 만들어 나가고 있는 그라운드룰은 무엇인가요?
노엘(Frontend Engineer): 사실 필요하지 않은 룰은 만들지 않는 편이 좋다는 데 다들 공감대가 있어요. ‘DRI의 권한을 침해하지 않기’처럼 정말 필요한 룰만 정확히 만들어 지킵니다.
에반(Frontend Chapter Lead): 맞아요. 재미있게 일을 하려면 자유가 있어야 합니다. 자유가 없이 일을 한다면 재미가 있을 수 없죠. 다만 이런 자유에 따라오는 책임도 진다는 동의가 모두에게 있어요. 저희 팀원들에게는 이 책임에 대한 역량도 있다고 믿고 있습니다.
앞서 잠깐 이야기했듯 “머지 후 발생하는 모든 이슈에 대해 챕터 전체가 책임진다”는 암묵적인 룰이 있는데요. 운영 환경에 코드가 배포되었다는 것은 코드 작성자 외에도 챕터가 그 코드에 동의했다는 것을 의미해요. 코드 리뷰는 챕터 누구라도 함께 할 수 있고요. 그렇기 때문에 운영에 배포된 코드에서 문제가 발생했다면 코드 작성자나 그 버그를 잡아내지 못 한 리뷰어만의 책임이 아니라, 리뷰에 참여할 자유가 있었음에도 리뷰하지 못했던 프론트엔드 챕터 모두의 책임이 되는 것이죠. 이런 룰은 챕터 전체를 더 강한 ‘원팀’으로 일할 수 있게 해주는 것 같습니다.
이렇게 동료의 자율성을 존중하고 함께 책임을 지는 문화가 쿼타랩 프론트엔드 챕터를 더 끈끈한 원팀으로 만들어주는 것이라 생각합니다.
윤(Frontend Engineer): 제가 생각하는 우리 챕터의 그라운드룰은 ‘상호 존중’인 것 같아요. 하드 스킬 레벨과 상관 없이 동료들의 의사 결정 과정이 신뢰할 만하다면, 그것을 믿고 지원해 주고, 또 조언도 아끼지 않는 문화가 있어요. 다만 무조건적인 존중과 신뢰는 아니에요. 아닌 것은 아니라고 얘기하는 조직이기 때문에 더욱 서로에 대한 신뢰가 높아지는 것 같아요.

쿼타랩 프론트엔드 챕터 리드 에반
앞으로 어떤 목표를 가지고 있나요?
에반(Frontend Chapter Lead): 조직 관점에서는 프론트엔드 챕터뿐 아니라 쿼타랩 팀에서 일하는 모든 동료가 자신이 전문성을 가진 범위 내에서 온전한 자율과 책임을 행사할 수 있는 조직을 만드는 것이 목표예요.
이런 조직이 되기 위해서는 동료들 간의 두터운 신뢰가 필수적인데요. 이런 신뢰를 만들어 내기 위해서는 좋은 채용을 통해 뛰어난 동료를 모으는 것, 의사결정권을 위임하기 위한 리더들의 용기, 모두가 같은 곳을 보고 달릴 수 있는 조직 전체의 명확한 비전과 목표 등 다양한 요소들이 모두 충족되어야 합니다.
물론 지금도 쿼타랩은 높은 수준의 자율과 책임 문화를 실천하고 있는 조직이지만, 초기 스타트업인 만큼 아직 더 성장할 수 있는 잠재력과 능력이 많이 남은 조직이기도 합니다. 여기서 제 목표와 역할은 쿼타랩을 지금보다 더 훌륭한 팀으로 만들기 위해 더 좋은 방법을 강구하고 빠르게 실천하는 것이라고 생각해요.
개인적으로는 멘토링이나 글을 통해 제가 해온 경험을 다른 사람들과 나누고 그분들의 성장을 돕는 삶을 살고 싶습니다.
윤(Frontend Engineer): 더 많은 고객들과 투자사들을 하루라도 빨리 모시게 되면 좋겠습니다. 저 역시 맡은 역할이 있지만 그 이전에 스타트업의 구성원이다 보니, 함께 소중한 시간을 보내고 있는 훌륭한 동료들의 노력이 잘 쓰이며 빛을 발할 수 있기를 바라고 있습니다.
개인적으로는 세상에 나만의 것을 내놓는다는 목표로 일하고 있어요. 앞으로 5년 내에 창업하는 것이 목표에요.
어떤 동료와 함께 하기를 기대하나요?
에반(Frontend Chapter Lead): 일을 그저 일로써만 대하지 않는 동료들과 함께하고 싶어요.
개발을 하는 것, 내 능력을 통해 세상을 바꾸고 비즈니스 임팩트를 만들어내는 행위가 그저 인생의 일부가 아닌 정말로 이런 가치를 달성하는 것이 내 인생의 우선순위 1순위인 동료들과 함께한다면, 아무리 일이 많거나 어렵더라도 함께 등을 맞대고 헤쳐 나갈 수 있을 것 같아요.
윤(Frontend Engineer): 쿼타북의 도메인이 비상장 증권 도메인이라 다소 딱딱하거나 어렵게 느껴지실 수 있지만, 정해진 룰 밖에서 자신만의 방식으로 문제를 해결해 나가는 분들만 모여있는, 딱딱함과는 다소 거리가 먼 조직이에요. 이런 멋진 동료들과 함께 문제를 제대로 해결하고 싶으신 분과 함께라면 가슴이 뛸 것 같네요.
지원하는 분들에게 미리 알려주고 싶은 팁은?
노엘(Frontend Engineer): 아주 현실적인 팁이라면 이력서 스킬셋(Skill Set, 능력) 부분에 스스로 레벨이나 점수를 매기지 않는 것을 추천해요. 검토하는 입장에서 특정한 기대치가 생겨날 수 있어 유의해야 합니다.
에반(Frontend Chapter Lead): 마지막으로 개발자로서의 역량은 학력이나 경력보다는 코드 자체로 판단합니다. 이를 확인할 수 있는 깃헙(GitHub) 링크를 꼭 공유해 주시면 좋아요. 깃헙에는 확인할 수 있는 프로젝트를 올려두거나 어필하고 싶은 특이 사항이 있다면 이를 주의 깊게 봐달라는 설명을 덧붙여서 주시면 정확한 검토와 평가에 더욱 도움이 됩니다.
쿼타랩 프론트엔드 챕터는 자율과 책임을 기반으로 빠르게 실행하고 개선하며 성장을 거듭하고 있습니다. 국내 최초로 ‘비상장 금융 인프라’를 함께 만들어 나갈 뛰어난 동료를 찾고 있으니, 아무도 가보지 않은 길을 개척해보고 싶으신 분들의 많은 관심 부탁드립니다.