토스에서의 1년을 돌아보며

서언

토스에서 Frontend Developer로 일한 지 1년이 지났다. 정말 밀도 높은 한 해를 보냈다. 매일을 살아가는 것도 중요하지만, 과거를 숙고하는 것이 기반이 되어야 한다. 내가 지금 어디에 있고 앞으로 어디로 가야 할지를 생각해야 한다. 이게 내 삶에서 자정 역할을 해왔다. 오늘도 잠깐 멈춰서서 1년을 돌아보고, 나아갈 길을 정의해볼 생각이다. 글 형식은 토스에서 인상 깊었던 요소를 써내려가며 느낀점을 쓰는 형식으로 해보겠다.

목적조직

토스는 목적조직 문화를 가진다. 목적조직은 직무와 상관없이 목표를 이루기 위해 팀원이 모이는 조직형태를 의미한다. 이게 토스에서 일하는 것이 즐거운 이유 중 하나라고 생각한다. 내가 토스에 합류한 이유이기도 하다. 그래서 대개 한팀에 직무 별로 1명씩 배치된다. 우리 팀도 PO 1명, 디자이너 1명, 프론트엔드 개발자 1명, 백엔드 개발자 1명, 데이터 분석가 1명으로 시작했다. 이런 조직의 몇가지 특징이 있다.

• 1명의 만들 수 있는 기여도가 크다.
• 모두가 아이디어를 내면서 제품을 만들어 간다. 그러므로 제품에 대한 오너십이 크다.
• 속도가 빠르다.

1년 동안 만든 서비스에 내가 산술적으로 20%를 기여한 셈이다. 팀원이 5명밖에 되지 않기 때문에, 자신이 더 많이 기여하고자 하면 그 수치를 훨씬 높일 수 있다.

 

개발자로서 신입부터 서비스에 대한 전적인 책임을 지는 것은 쉽지 않았다. 그것을 해내는 것부터가 어려운 일이며, 신뢰를 받는 것은 더 어렵다. 토스는 채용 시에 경력을 나누어 뽑지 않는다. 단지 한 팀에서 혼자 개발할 수 있는 역량을 가진 사람을 뽑는다. 그렇게 첫 경력임에도 불구하고, 오랫동안 혼자서 서비스를 개발했다. 기술스택 선택, SSR과 CSR 선택, 개발 방식, 일정 산정, 장애 대응 전략 등을 모두 주도적으로 결정했다. 프론트엔드는 전적으로 나 혼자 책임지는 것이다.

 

이런 방식이면 팀의 속도가 매우 빨라진다. 각 직무별로 소통은 직접적으로 이루어진다. 대개 소통의 중간자가 없다. 프로젝트가 정해지면 각자의 역할이 바로 정해지고, 모두 이를 이해하고 있다. 이를테면, 3시에 정해진 실험이 5시에 배포되는 경험도 있었다. 실험 방향성이 정해지고, 디자이너가 바로 디자인하고, 프론트엔드에서 실험 코드를 넣은 후 바로 배포했다.

 

여기까지 얘기하면, 매우 두렵게 느껴지거나, 오히려 성장하기 어렵다고 느낄 수 있다. 하지만 토스의 매트릭스 구조 때문에 부담감을 덜 수 있다. 각 사일로에 1명씩 배치되고, 같은 직무의 사람들이 챕터라는 이름으로 모인다. 그래서 맡은 프로젝트는 다르지만, 서로 고민을 공유하고 코드리뷰를 받을 수 있는 구조를 가지고 있다. 즉, 결정은 프로젝트의 주인이 하지만, 주변에 의견을 구하고 모르는 것을 쉽게 물어볼 수 있다.

이 글에서 내가 왜 토스를 선택하였는지 적었었다.

https://happysisyphe.tistory.com/59

토스 & 우아한형제들 합격, 회사 선택 이유와 앞으로의 목표

여기에서 토스를 선택한 이유를 도전과 주체성이라고 적었다. 토스의 조직문화는 이를 이루기 매우 좋은 형태이기 때문에, 1년간 일하면서 많이 성장할 수 있었다. 팀 인원이 적고, 개인이 맡은 역할이 커서 역할을 확장하기도 쉽다. 내년에는 팀 내에서 영향력을 더 키우고 싶다. 즉, 개발 뿐만 아니라 제품과 팀 문화 등 다양한 측면에서 역할을 확장하고 싶다. 이것에 대해서는 아래에서 더 구체적으로 써보겠다.

코드 치는 것은 개발자의 일부일 뿐이다.

개발자가 코드만 치는 사람인가? 전혀 아니라는 걸 많이 깨달았다. 프론트엔드 개발자가 해결해야 할 문제는 코드 치는 것 이외에도 많다.

생각나는 것을 써보자면, 아래와 같이 다양한 문제가 있다.

• 성능 문제 해결
  • 이미지 성능
  • 폰트 성능
  • 리소스 번들 사이즈
  • 리소스 캐싱 전략 (브라우저, CDN)
• 장애 줄이기 / 장애 대응 방법
  • 코드리뷰 시스템이 없는데, 어떻게 할 것인가?
  • 장애가 났다는 사실을 빠르게 인지하려면 어떻게 해야 하는가?
  • 페이지에서 하나의 API 에서 장애가 나도, 전체 페이지를 못 보게 하는게 맞는가? 에러를 전파시키지 않으려면 어떻게 해야할까?
  • 모니터링을 어떻게 잘 할 수 있을까?
• 휴먼 전략 문제
  • 현재 팀에 프론트엔드 1명으로 충분한가? 1명이 늘어나면, 효율을 얼마나 높일 수 있을까?
  • 사람이 더 있어야 할 것 같은데, 누구한테 뭐라고 설득하지?

이 역할을 잘 해내기 위해서는 결국 문제 해결 능력, 커뮤니케이션 역량, 적극적인 태도가 가장 중요하다고 생각한다. 그러므로 토스에서 일하다 보면, 개발 뿐만 아니라 다양한 역량을 강화할 수 있다. 그게 내가 바라던 것이었다.

코드를 치는 것보다 근본적으로 문제를 푸는 데 관심이 많은 나로서는 일 자체가 매우 흥미롭다. 동료들과 문제를 어떻게 풀지 치열하게 논의하는 과정이 기억에 남는다.

실험

토스는 실험을 많이 한다. 유저가 마주하는 화면의 크기에는 제한이 있고, 그 안에서 유저에게 더 좋은 경험을 주기 위해서, 돈을 더 잘 벌기 위해서 가장 효율적인 방법을 찾아야 한다. 토스는 함부로 결정하지 않는다. 수평적인 문화 때문에 아무도 함부로 결정할 수도 없다. 이때 우리는 실험을 진행한다. 예를 들어 유저가 특정 상품에 가입하기 위해 정보를 입력해야 하는 상황이 있다고 치자. 누군가는 한 페이지에서 모든 정보를 입력해야 한다고 주장할 수 있고, 누군가는 한 페이지에 하나의 정보만 입력하도록 해야 한다고 주장할 수 있다. 결국 뭐가 더 나은지 판단하려면 데이터가 필요하다. 이 결정이 특정 리더의 추측에 의한 명령으로 이루어지지 않는다. A/B 테스트 실험을 하고, 데이터를 확인한 후 의사결정을 한다.

 

이 부분이 나에게 매우 흥미롭게 다가왔다. 모든 결정은 데이터를 기반으로 하고, 언제나 데이터를 바꿀 수 있는 아이디어를 제안할 수 있다. 그리고 구현할 때가 오면 정말 재미있다. 일 할 때 동기부여가 떨어지는 이유 중 하나는 효능감을 느끼지 못하기 때문이다. 왜 해야 하는지 납득하지 못 하는데도 그 일을 해야 한다면 효능감이 떨어진다. 하지만 데이터로 결정된 것을 수행해야 할 때, 그 아이디어가 내게서 나왔을 때, 이를 구현하는 것은 매우 즐거운 일이다. 일하면서 살아있다고 느끼고 더 적극적으로 해내게 만든다.

 

하지만 무작정 실험을 진행한다고 하여 좋은 것은 아니다. 좋은 실험을 진행해야 한다. 그 실험이 비즈니스적으로 중요하지 않은 가설임에도 실험을 진행하거나, 검증하고자 하는 것을 정확히 검증해내지 못 한다면, 시간만 더 쓸 뿐 실제로는 도움이 되지 않는다. 그래서 좋은 실험에 대해 관심을 가지고 공부하고 있다. 팀 내에서 더 좋은 실험을 진행할 수 있도록 많은 도움을 주고 싶다. 23년은 좋은 실험에 대해 개괄적으로 이해하는 시간이었다고 하면, 24년에는 이를 심도있게 파악하고 액션을 취해보고 싶다.

Focus on impact

토스의 Core Values 중 하나가 Focus on impact다. 임팩트에 집중하라는 건데, 이 세부 설명을 보면 놀랍다. 하면 좋을 10가지 일을 하지 말아야 할 일로 규정하는 것부터 시작하라고 한다. 일하다 보면, 하면 좋은 일들이 넘쳐난다. 중요하지 않은 디자인을 변경하고, 애니메이션을 추가하고, 기능을 덕지덕지 추가하는 일이 그 예시가 될 수 있다. 이런 일들을 모두 하다 보면, 핵심적인 임팩트를 만들지 못 한다. 그러니 하지 말아야 할 일을 정의하고, OKR을 달성하기 위해 어떤 액션을 해야 할지 근본부터 다시 생각한다. 여기서 가장 임팩트 있는 액션만을 취한다.

 

우리는 회의할 때 항상 임팩트의 크기를 논의한다. 이것을 왜 해야 하는지, 동일 시간 대비 더 큰 임팩트를 낼 수 있는 일은 없는지, 모두가 지속적으로 고민한다. 그러면서 “왜 해야 하는지 모르겠다”, “이것 보다 저것을 하는 것이 더 낫지 않을까요?” 같은 의견이 쏟아지면서, 더 나은 방향성을 찾아간다.

 

Focus on impact 라는 가치를 중시하면서 일 하는 것은 매우 흥미롭다. 덕분에 무의미한 일은 거의 하지 않고, 임팩트 있는 일만 할 수 있다. 그러므로 일 자체가 언제나 의미가 있고, 그 자체로 자기 효능감을 가져다 준다. 하지만 임팩트 라는 것을 잘 정의하는 것이 중요하다. 임팩트가 크지만, 작다고 판단하면 안 된다. 또는 단기적인 임팩트에만 집중하다 보면, 장기적인 임팩트를 놓치게 된다. 가령, 조금의 유저 경험 개선은 단기적으로 아무것도 아닌 것처럼 보일 수 있지만, 계속 쌓여가다 보면 전체적으로 경험이 매우 안 좋아질 수 있다. 그러면 이것이 곧 큰 Bad 임팩트가 될 수 있다. 그러므로 임팩트 라는 것을 잘 이해하고 판단하는 것이 중요하다. 아래에서는 기술이 가져다주는 임팩트를 간과하여, 잘못된 방향으로 갔던 경험을 서술하겠다.

기술의 중요성

Focus on impact를 단기적으로 이해하다 보니, 임팩트를 오직 제품 관점으로만 생각했다. 유저에게 좋은 경험을 주고, 우리의 매출을 올려주는 액션이 아니라면 모두 의미없다고 생각했다. 그래서 나는 개발자이지만서도 코드 퀄리티, 개발 안정성 등을 크게 고려하지 않은 순간들이 많았다.

 

사례 1 : 사라질지도 모르는 기능이므로, 코드 퀄리티를 신경 쓰지 않고 최대한 빠르게 구현했다. 그리고 그 기능이 확장되고 핵심 기능이 되었지만, 여전히 코드가 리팩터링 되지 않아, 개발 시간이 오래 걸리고 장애 확률이 높아졌다. 단기적으로는 코드 개선보다, 기능을 추가하는 것이 더 큰 임팩트를 가져다 준다고 생각했기 때문이다.

사례 2 : 장애 감지가 정확히 되지 않는다는 것을 알았지만, 현재로서 크게 문제를 겪은 적이 없고, 더 시급해 보이는 문제들이 있어서 외면하다가 큰 장애를 맞이한 순간이 있었다. 테스트를 열심히 해서 장애를 내지 않으면 그만이라고 생각했기 때문이다.

이런 경험들이 쌓이다 보니, 내가 개발자로서 기술의 중요성을 간과했다는 생각이 들었다. 빠르게 구현하여 비즈니스 임팩트를 주는 것도 중요하지만, 이 프로젝트에 유저가 많아지고, 장기적으로 지속될 기능이라면 기술이 꼭 뒷받침해 줘야 한다.

 

기술 부채가 쌓여서 생산성을 과도하게 깎아 먹으면 안 되고, 내가 아닌 다른 사람도 편하게 개발할 수 있어야 하며, 장애가 나더라도 빠르게 감지 및 대응할 수 있어야 한다. 혼자 개발하다 보니, 그런 측면을 고려하지 못 했다. 하지만 팀이 커지면서 프론트엔드 개발자 동료가 한명 더 합류했고, 이게 문제가 되는 것을 느꼈다.

 

이것을 깨달은 후, 비즈니스와 개발 안정성 사이에서 적절한 의사결정을 하려고 많이 노력하고 있다. 기술 부채를 컨트롤 하며 장기적인 안정성 및 생산성을 보수하려고 노력하고 있다. 앞으로 좀 더 적극적으로 기술 부채 해소를 제안하고 싶다. 이대로 기술 부채가 지속되면, 생산성이 저하되고, 장애 발생 확률이 높아지므로 지금 해소하는 것이 좋겠다는 의견을 합리적으로 내면서 설득하는 과정을 경험하고 싶다.

역할의 확장

나는 안주하기를 싫어한다. 하는 일에 적응이 되면 새로운 일을 찾아나간다. 그리고 토스는 이에 열려 있다. 팀에서 프론트엔드 개발을 하는 것에 익숙해지자, 다른 것들도 잘하고 싶어졌다. 프로덕트 매니징, 기획 아이디에이션, DB 조회 등이 있다. 하반기는 이것들에 눈을 뜨고, 조금씩 해나가는 과정이었다. 24년에는 더 적극적으로 역할을 확장해나가고 싶다.

 

내가 하고 싶은 것들을 써보자

• SQL 을 좀 더 자유자재로 쓰면서, DB를 조회하여 CS 대응 및 데이터 분석 하기
• 팀의 데이터 지표를 이해하고, 이를 바꿀 수 있는 기획 아이디어를 많이 내기
• 웹 서비스 바깥의 문제 풀기
• 매니징 역할 많이 해보기 (프로젝트 매니징, 신규 입사자 온보딩)

동료들과의 신뢰관계

훌륭한 동료들과 함께 하는 것은 언제나 즐겁다. 배울 점이 많다. 토스에서는 각 파트별로 1명씩이 모여서 팀을 이루고 있다. 그러려면 각 파트의 사람이 그 일에 능통해야 한다. 척하면 척 해낼 줄 알아야 한다. 이것이 가능한 사람들이 모여 있으니, 그들의 역량이 매우 훌륭하다고 할 수 있겠다. 그들과 일하는 것이 영광이다. 팀원들을 전적으로 신뢰할 수 있고, 팀원들도 나를 신뢰해준다. 신뢰관계가 있으면 불필요한 논의가 최소화된다. 이것이 토스가 일이 많고 어렵지만, 계속 지속할 수 있게 해주는 힘인 것 같다. 역량이 부족한 동료에 대한 스트레스가 적고, 훌륭한 동료들과 끈끈한 팀을 이루어서 어려운 문제를 풀어가는 과정이 즐겁다.

끝마치며

이처럼 훌륭한 조직에 들어와서 일 할 수 있음에 감사하다. 첫 직장생활이지만, 무탈히 랜딩해냈다. 쉽지만은 않았지만, 좋은 시작을 했다고 생각한다. 즐겁게 일하면서 성장해낸 시간이었다. 아마 이후에도 그런 시간이 지속될 것 같다.

 

하고 싶은 것, 잘 해내고 싶은 것이 넘쳐난다. 새롭게 경험하는 것이 많으니, 호기심이 많이 생긴다. 이것도 마찬가지로 Focus on impact 하는게 중요한 것 같다. 모든 것을 잘 해내려고 하다 보면, 아무 것도 잘 해내지 못 할 가능성이 높다. 올해 하반기에 그러한 경향이 있었다. 잘 해내고 싶은게 많았고, 그 사이에서 허둥지둥 헤맸다. 잘 해내고 싶은 것을 리스트업 하고, 그 중 가장 중요한 것 하나를 꼽아서 진득하게 해내는 1년을 만들고 싶다. 훌륭한 동료들과 즐겁게 제품을 성공적으로 이끌면서, 개인적인 성장을 이룩하고 싶다.