[토스 위닝 세션] 개발자 커리어에 토스가 꼭 있어야 하는 이유 (by 박서진)

박서진은 누구?

20세에 첫 회사로 토스 입사. 개발자 5명 정도를 리딩하던 시점부터 점점 커져서 90명까지 리드. 이후 Head of Frontend가 됨

어떻게 이런 성공적 커리어를 만들었나?

초등학생 때부터 코딩 좋아했고, 이론도 공부하는 것도 좋아했음

하지만 특출나지는 않았음. 진로 고민하는 평범한 컴공과 대학생. 실무 경력 없었음.

토스보다 작은 회사의 직무 인터뷰에서 떨어지기도 했음

이렇게 성장할 수 있었던 건 토스의 특별한 개발 문화 덕분이었다고 생각함

토스 개발 문화가 어땠길래?

3가지로 요약됨. 장인정신, 실패 허용, 몰입.

1) 장인정신

장인정신이란, 사소해보이는 디테일까지 집중해서 탁월하게 풀어내는 것.

서진님이 저도 모르게 한숨이 나오는 상황들

• 느리거나 부자연스러운 화면 (들어가자마자 뜨는 로딩, 갑작스러운 레이아웃 시프트)
• 냄새 나는데 뚜껑만 덮인 코드 (if문이 1개 → 5개, 함수 인자가 1개 → 5개로 늘어남)

이런 상황에서 주변 동료들이 어떻게 반응하냐에 따라 내 행동도 달라짐.

• 어떤 조직에서는 '바쁜데 이정도는 그냥 넘어가시죠'라고 말하고
• 어떤 조직에서는 '이거 어떻게 고칠 수 있을까요?'라고 말함

토스에서는 후자를 훨씬 더 자주 들었음

예시: 아이폰에서 키보드가 열리면 보이지 않는 (화면 다시 터치해서 스크롤 내려야만 보이는) '다음' 버튼

• 너무 불편했는데, 다른 앱들에서도 비슷한 이슈 있었음
• 다른 앱들 이슈 트래커 같은 거 찾아보면, 이슈를 인지는 하지만 어쩔 수 없는 한계니까 넘어가자는 얘기가 많았음
• 내가 한번 해결할 때까지 해보자! 해서 일주일간 매일 새벽까지 사파리 소스코드 뜯어보며 연구
• 여러 고비가 있었지만 고비를 넘어갈 때마다 많은 걸 배우게 되고, 결국 일주일 뒤 완벽하게 처리해서 희열을 느낌
• 사실 문제 푸는 과정 자체는 지난하고 힘들었지만, 그 이후 동료들의 반응이 굉장히 뜨거웠음
  • 좋아진 제품을 사용하는 디자이너
  • 기술적 깊이에 대해 인정해주는 프론트엔드 개발자
  • 토스 앱 전체에서 명확히 보이는 '다음' 버튼
  • 실제로 제품 지표도 개선됨

이런 사례가 토스 안에 많음. Go the extra-mile이라는 토스 코어 밸류 때문.

• 송금 화면을 6년간 100번 넘게 개선
• 3년 전에는 덜 알려졌던 SSR을 이용해서 초기 로딩 시간을 3초 → 1초 미만으로 줄임
• 관성적으로 만드는 대신 치열하게 몇달간 고민하여 약관 동의 화면 구현 → 동의율 63% 상승

작은 개선점을 모아 차별화된 사용자 경험을 제공하는 게 장인정신. 1.01 ^ 365 = 37.78 인 것처럼.

장인정신을 가지고 일하면, 1년차 경험을 6번 반복하는 대신 매년 새롭게 일할 수 있음. 뻔한 게 아니라 도전적인 업무를 해서 일이 더 재미있어짐

2) 실패 허용

화면 배포했는데 갑자기 테스트와 다르게 모든 프론트 화면이 하얗게 나오는 순간이 있었음. 지금보다는 작았지만 그래도 MAU 4~500만 시절. 구조가 지금같지 않아서 한군데서 장애나면 다같이 장애났었음.

몇 분 내로 롤백해서 대처하긴 했으나 자책. 시말서 쓰듯 장문의 슬랙 메시지를 썼음. 챕터 리드에게 무슨 말 들을지 두려웠음.

그런데 챕터 리드의 한마디: "no need to 죄송"

죄송해하지 말고, 실패에서 배워라. 이게 토스의 업무 문화를 보여줌. 다음에 더 잘 하면 된다. 나처럼 실수했던 서버 개발자 분도 계셨는데 이승건 대표가 직접 슬랙에서 "다음에 안그러면 된다"고 했던 적도 있었음

실제로 이 실패 이후 더 잘 하기 위해 했던 일들

• 한 팀에서 장애 나도 다른 팀에서 영향이 없도록 구조 변경
• 테스트를 더 쉽게 만들어서, 배포 내용을 프로덕션 환경과 최대한 유사하게, 사용자가 실제로 보기 2-3단계 전에 미리 알 수 있도록 함

하지만 여전히 여러가지 실패를 함. 영광의 상처들

• 첫 타입스크립트 도입 후 2차례 롤백
• 성능 최적화 작업 중 급증한 서버 부하
• 하루 걸릴 줄 알았다가 2주 걸린 리팩토링

이런 실패에 대처하는 쉬운 방법은 책임 소재를 추궁하고, 결재/보고/승인 체계를 만들고, 매뉴얼을 따르게 하는 것

하지만 토스는 이런 걸 지양함. 대신 개인의 전문화를 추구. 실패를 축하하는 '실패 파티'도 함

토스에서는 사일로의 프론트엔드 개발자가 코드의 완전한 DRI, 완전한 권한과 책임을 가짐

• 이런 환경에서 문제 해결 능력을 키우기 유리함. 의사결정을 위임할 수 없으니까

Q. 다양한 실패를 경험하는 것이 꼭 필요할까요?

• 못 하던 것에 도전하고, 실패해야 성장한다 (점진적 과부하)

Q. 이게 토스에서만 가능한 건 아닐까요?

• 안전하게 실패할 수 있는 환경 먼저 만들면 됨. 상처가 흉터가 아닌 생채기 정도만 될 수 있게.
• 안전하게 테스트하기 위한 개발 환경, 부분적으로 적용할 수 있는 설계 만들기
• 마이크로 프론트엔드 아키텍처. 모두 독립적 빌드와 배포 체계
• 역량에 따른 단계적 위임 레벨의 증가 (매니지먼트 3.0)

3) 몰입

7년동안 토스에 있으면서 가장 많이 한 것이 이것임. 주어진 일에 완전히 빠져들어서 일하기.

토스에 있는 동안 대부분 시간 가는 줄 모르면서 행복하게 일함. 아침부터 저녁까지 일 생각뿐

그런데 사실 이런 몰입 경험이 쉽게 생기진 않음. 왜 나는 가능했을까?

미하일 칙센트미하이가 말하는 몰입의 3요소: 명확한 목표, 유효한 피드백, 적절한 난이도

명확한 목표

• 내부 100 원칙: 모든 정보가 오픈됨. 컨텍스트를 내가 다 찾아볼 수 있음. 내가 하는 일이 어떤 의미를 가지는가
• 설득이 아닌 alignment: 같은 정보와 맥락을 공유하는 사람은 같은 의사결정을 내릴 것이라고 가정
  • 기획자는 개발 상황을 알고, 개발자는 기획 상황을 알고 의사결정

유효한 피드백

• 데이터 기반 의사결정의 일상화. 변경사항 있을 때 A/B 테스트로 지표 추적하는 게 일상화되어있음
  • 배포 후 긴 시간이 걸리지 않고 내가 배포한 기능의 결과가 어땠는지 확인 가능
• 팀원들 사이에서 거의 바로 돌아오는 건설적인 피드백. Radical candor 지향

적절한 난이도

• 조직의 규모가 커지면서 점점 내가 감당해야 하는, 감당할 수 있는 문제의 종류와 깊이가 커짐

추가: 몰입을 방해하는 요소들을 제거하기

• 토스에서 일하는 7년간 점점 고민이 줄어듦
• 점심 고민, 커피 고민, 야근 고민 등 여러 고민들을 회사 내에서 해결해서 업무에 더 집중할 수 있음

Q. 순수한 몰입과 그냥 과로는 어떻게 다른가?

• 몸이 말하는 걸 그대로 들으면 됨. 업무에서 이런 감정이 든다면 그게 몰입이다

QnA

Q1. 토스 프론트엔드 팀의 궁극적 목적이 뭐고 어떻게 나아가고 있는지 궁금하다

애플은 '디자인'이 위닝 전략이듯이 토스의 개발 방식이, 개발 환경이, 프론트엔드 UX가 위닝 전략이 되길 바라고, 그걸 위해 노력하고 있다. 오픈소스 등

Q2. 문화 관점에서 '이런 개발자는 토스에 잘 맞지 않는다'는 사람이 있다면?

Extra mile에 도전하는 걸 누구나 즐기지는 않음. 리스크를 감수하면서 100보다 110, 120을 하려는 분들이 토스에 더 어울릴 거라고 생각

100권의 라이브러리

키링 만들기 워크숍, 커피 사일로, 토스와 함께하는 12개월 등 안에 인상적인 공간이 많았지만 저는 라이브러리가 가장 좋았습니다. 토스 임직원들이 추천한 책 100권이 전시되어 있고 마음껏 읽을 수 있었어요. 제가 좋아하는 책도 많았고요.

주말에 즐거운 경험을 하게 해준 토스 분들께 감사드립니다.