Table of Contents
엔지니어에게 어떤 기회들이 있나요?
다양한 기회들이 있는데요, 제품 조직에서 메이커로 활동하는 프론트엔드 개발자 입장과 플랫폼 조직에서 플랫폼 엔지니어로 활동하는 입장 두 가지로 나누어서 소개하고 싶어요.
메이커, 프론트엔드 개발자
프론트엔드 개발자들은 ‘사일로silo’라는 목적 조직에서 개발하고 있어요. 사일로마다 다양한 기회와 도전들이 있는데요, 한 가지 기회에만 집중할 수도 있고 본인의 욕심에 따라 영향력을 넓힐 수도 있어요.
반기마다 전사적으로 진행하는 얼라인먼트 데이(Alignment Day)에서는 팀의 목표, 사일로가 해결하고자 하는 문제들이 공유되는데요, 이때 팀의 목표에 따른 우선순위를 알 수 있고 자신이 원하는 사일로가 어디인지 알 수 있을 거예요.
앱을 초기 단계부터 만들어갈 기회
2022년 12월, 토스비즈니스라는 새로운 앱을 공개했어요. 개인 사업자분들의 사업을 위해 만들어진 앱입니다. 송금, ‘금융’하면 토스가 떠오르는데요, 사장님을 위한 앱 하면 떠오르는 앱이 토스비즈니스가 되기 위해 시작했습니다.
React Native라는 기술로 빠르게 만들어서 오픈했고 아직 초기 단계라서 새롭게 만들 시스템이 참 많습니다.
•
앱을 막힘없이 배포하기 위해 code-push와 같은 시스템을 직접 만들어 운영하고 있어요.
•
앱이 커지는 것을 막고자 하나의 앱을 여러 청크(Chunk)로 쪼개는 것을 고민하고 있어요.
제품이 초기 단계인 만큼 수많은 기회가 있고, 이제 막 세상에 나온 앱이 점차 성장하는 모습을 직접 만들어 나갈 기회라고 생각합니다.
결제 제품의 로드맵을 처음부터 고민하며 개발할 기회
어떤 임팩트에 집중할지, 제품을 어떻게 발전시킬지 PO와 함께 고민할 수 있는 좋은 환경이기도 해요. 결제 시장은 그동안 공급자 중심이었어요. 못생긴 결제창이 전부였다면, 코드 수정 없이 결제창을 조작할 수 있는 결제 제품, OO페이를 쉽게 만들 수 있도록 제공하는 결제 제품, 결제 연동 작업을 더없이 간단하게 만들어버리는 결제 제품 등 수많은 제품이 결제 시장을 혁신하기 위해 만들어지고 있어요.
제품 개발을 위한 환경이 비교적 잘 갖춰져 있다고 생각해요. 그렇기 때문에 어떤 제품으로 이 결제 시장을 바꿀지, 어떤 제품이 매력적일지 고민하는 데 집중하면서 임팩트 있는 제품을 만들어 볼 수 있습니다. 결제라는 복잡한 도메인을 코드로 풀어내고 이를 운영하는 것은 어디에서도 할 수 없는 경험이라고 생각합니다.
개발자를 위한 서비스를 만들 수 있는 기회
결제를 연동하기 위해서는 위해서는 개발이 꼭 필요한데요, 이때 저희 결제 제품을 연동하는 개발자들을 위한 제품을 만들어요. Public HTTP API와 API를 사용하기 쉽도록 만들어둔 SDK, 그리고 이런 API/SDK를 기반으로 만들어지는 결제 연동 가이드까지 모두 개발자를 위한 제품이에요.
개발자를 위한 제품을 만들다 보니 “개발자의 경험“을 중심에 놓고 고민하는 특별한 경험을 할 수 있어요. 한 번 쓰고 버려질 API, SDK가 아니기 때문에 한 번을 만들 때도 신중하고 치열하게 고민하며 만들고 있어요. 이렇게 만든 SDK는 오픈소스로 공개하고 있어요.
플랫폼 엔지니어
제품도 중요하지만, 이 제품들이 많아지면서 원활하게 개발될 수 있도록, 더 빠르게 개발될 수 있도록 환경을 가꾸는 역할이 필요하게 됩니다. 사용자도 자연스럽게 많아지니 서비스가 안정적으로 운영되는 것도 중요합니다. 프론트엔드 챕터에서는 클라이언트 플랫폼 팀이 따로 존재해 이 팀에서 인프라와 개발 환경을 직접 고민하고 관리하고 있습니다.
인프라부터 직접 설계하고 운영까지 해볼 기회
저희 챕터는 테라폼을 통해 인프라를 직접 관리하고 있고 Self Hosted로 운영하고 있는 GitHub Action으로 CD를 구성하고 있어요. 배포를 위해 어드민을 자체 제작했고 생산성을 높이기 위한 여러 가지 기능들을 추가하고 있는데요, 한 번의 클릭으로 배포할 수 있고 롤백할 수 있습니다.
모노레포(Monorepo) 구조로 토스페이먼츠의 서비스들을 운영하는데요, 만들어지는 제품들을 각각의 프로젝트로 작게 나누고 독립적으로 관리해요.
서비스를 작게 운영하면 서비스 간의 의존성이 많이 줄어드는데요, 그 결과 제품을 담당하는 엔지니어의 기술적인 의사결정을 최대한 존중하게 되었고, 새로운 기술 도입에도 사이드이펙트(Side Effect)가 적기 때문에 도전적인 엔지니어링을 시도할 수 있는 환경을 마련할 수 있었습니다.
여러 Saas 제품을 마치 하나의 제품처럼 매끄럽게 제공하기 위해서는 많은 고민이 필요합니다. 프론트엔드에서는 제품 간의 의존성, 공통 모듈들을 잘 관리하여 애플리케이션이 복잡해지지 않도록 구조를 고민하고 있어요. 자연스럽게 대규모 애플리케이션을 보다 잘 설계하고 운영해야 하는 책임이 주어집니다. (Stripe을 참고해도 좋아요)
제품들이 계속 많아지고 커지면서 CI 최적화, 더 효율적인 배포 전략 등 여러 기술적인 도전 거리가 생겨나고 있어요. 수십개의 서비스와 수십개의 도메인 모듈, 수십개의 패키지들의 오케스트레이션을 해볼 기회가 있습니다.
크로스 플랫폼을 운영할 기회
앞서 React Native라는 기술로 토스비즈니스 앱을 출시했다고 말씀드렸는데요, 이 앱에는 여러 사일로가 제품을 추가하는 한편 빌드 최적화, Canary release, File based routing, AB 테스트 SDK 등 다양한 플랫폼 작업도 이뤄지고 있습니다. 이런 작업을 클라이언트 개발자(iOS, Android)분들과 함께 진행하고 있어요.
이외에도 code-push와 비슷한 인프라를 구축하여 서비스 개발자들이 수시로 배포할 수 있는 환경을 만드는가 하면 디버깅을 쉽게 할 수 있는 도구를 만들고 개선하고 있어요.
어떤 개발 문화를 만들어가고 있어요?
이번엔 토스페이먼츠 프론트엔드 챕터의 개발 문화를 소개해 보려고 해요.
함께 성장하는 문화를 만들기 위해 여러 시도를 하고 있는데요, 다른 개발팀에게도 도움이 되지 않을까 싶어 정리해봤습니다.
챕터를 단순히 같은 일을 하는 사람들이 모인 조직이 아니라, 힘들 때 서로 도와주고 스터디도 모집하고 페어 프로그래밍도 하는 커뮤니티로 만들어가고 있어요. 계열사마다 조금씩 다른데요, 페이먼츠의 개발 문화를 소개합니다!
“알고싶어요”
여러 사람 앞에서 발표하는게 쉬운 사람은 많지 않을 겁니다. 저희 챕터원들도 마찬가지인데요, 그럼에도 불구하고 조금 더 러닝(learning)이 잘 공유될 수 있으면 좋지 않을까? 고민을 했고 “알고싶어요”라는 것을 시작했어요.
공급자 중심의 기술 공유 세션을 반대로 역전한 활동인데요, 지금 우리 챕터가 제대로 모르는 부분을 아카이빙하고 이것을 세션으로 만드는 방식입니다. 특정 주제에 대해 수요을 먼저 파악하고 연구하여 공유하는 기술 공유 활동입니다.
특정 주제에 대해 궁금한 것을 아카이빙하기도 하구요, 잘 알 것 같은 사람을 추천하기도 하구요, 올라온 주제에 대해 관심을 표현하기도 합니다. 물론 스스로 공유하고 싶었던 주제를 올리기도 해요.
관심을 표한 사람들끼리 소규모로 지식 공유 세션을 진행합니다.
“알고싶어요”는 다음과 같은 문제를 해결했어요.
•
이 주제 나만 몰랐던 거면 어떡하지?
•
괜히 시간만 뺐는 것은 아닐까?
보충) “알고싶어요”에서 기존에 진행하던 서비스 오버뷰도 그대로 다뤄요.
서비스 Overview
앞에서 말씀드렸듯이 토스페이먼츠의 프론트엔드 엔지니어는 사일로에 속해있어요. 사일로 조직 구조에서는 프론트엔드 엔지니어끼리 서로 담당하는 제품을 이해하기 어려운데요, 챕터 차원에서 이러한 문제를 해결하기 위해 여러 장치를 마련해보고 실험하고 있어요.
그중 하나가 서비스 Overview라는 활동입니다. 제품의 담당자가 서비스의 전체적인 흐름과 도메인 지식에 대한 내용을 문서로 정리하고 공유하는데요, 이때 서비스에 대한 맥락이 공유되어 코드 리뷰 시 큰 도움이 되곤 합니다.
아래는 실제로 저희가 서비스 Overview 활동을 한 노션 문서입니다! 현재 총 6개 제품에 대한 오버뷰가 진행됐네요! 이 활동은 효과가 좋아 격주로 로테이션을 돌며 진행하고 있습니다!
Table
리스트 보기
List
Search
보안상의 이유로 문서 내부에 존재하는 링크 일부가 동작하지 않을 수 있어요.
정해진 템플릿 없이 자신이 담당하는 제품을 소개하기 때문에 각자 다른 형태로 설명하는 것도 관전 포인트입니다. 
엔지니어링 데이
프론트엔드 챕터 구성원 모두 매주 목요일 오후 2시 15분이 되면 라운지로 모여요. 진행하고 있던 사일로 업무를 잠시 멈추고 엔지니어링에 집중해요. 엔지니어링 데이 때 진행하는 활동들을 템플릿으로 만들어서 노션에 기록하고 있어요.
Check-in
엔지니어링 데이를 시작하기 전에 간단히 서로의 근황을 공유하는 Check-in으로 엔지니어링 데이가 시작됩니다! 주로 스프린트에서 어떤 작업을 할 예정인지(미래) 이야기를 나눠요. (각종 드립과 TMI가 난무하는 시간입니다)
이런 느낌입니다!
톡톡
챕터 차원에서 논의해야 하는 이슈가 있다면 함께 토론합니다.
최근에는 ‘세종대왕 프로젝트’라는 긴 논의를 마무리 지었는데요, 코드에 ‘한글’을 부분적으로 사용하는 부분에 대한 컨벤션을 정의했어요. 관련 내용은 아래 노션 문서를 통해 보실 수 있어요.
이 외에도 코드 리뷰 시스템에서 보완됐으면 하는 부분이 있다던가, 합의에 이른 컨벤션에 제안하고 싶은 게 있다던가 등의 이야기를 나눠요. 당연히 챕터 구성원이라면 누구든 주제을 발제할 수 있어요!
엔지니어링 Time
각자가 마음 속에 간직해둔 기술 부채들을 모아두는 데이터베이스가 있어요. 엔지니어링 DB에 백로그를 쌓아두고 이 시간에 해결해요. 혼자 해도 좋고 함께 해도 좋아요. 평소에 공부하고 싶었던 프레임워크를 살펴보는 스터디 시간으로도 활용할 수 있어요.
코드 리뷰
저희 챕터는 서로의 성장을 위한 코드 리뷰를 하려고 노력하고 있어요.
리뷰 과정에서 새로운 관점을 배웠거나 좋은 리뷰라고 생각되는 Pull Request에는 Good Review 라는 라벨로 표시를 해둬요.
Good Review 라벨이 등록된 Pull Request 목록
라벨이 등록된 PR은 슬랙으로 발송되어 챕터 구성원에게 공유되고 같이 이야기를 나눌 수 있어요.
주로 어떤 내용을 리뷰할까?
저희 챕터 코드 리뷰가 어떻게 이뤄지는지 실제 Pull Request 스크린샷을 통해 보여드릴게요.
리팩토링 내성을 고려하여 테스트 코드를 작성해보자. 좋은 설계를 만드는 테스트 코드!
선언적으로 작성하자
숨겨진 의존성을 드러내고 UI 추상화를 고민하자
노출할 필요 없는 파라미터는 숨겨도 좋지 않을까?
Sub Path를 잘 활용해보자.
사용하는 방향을 고려해서 반환 인터페이스 결정하기
Command에서는 값을 반환하지 말자
사용하는 인터페이스를 고려한 리팩토링
Fair time
Fair time은 Frontend + Pair time의 합성어입니다. fair는 "장애물이 없는"이라는 뜻도 가지고 있는데요, 서로 도움을 요청하는데 스스럼없는 시간이라는 의미도 있습니다. 하루 30분 정도 일정을 미리 잡아두고 필요한 사람들끼리 진행하는 시간입니다.
주로 다음과 같은 것들을 하곤 합니다.
•
페어 프로그래밍
•
프리 커밋 리뷰
•
인터페이스 고민
•
페어 코드 리뷰
•
에러 함께 디버깅하기
테크런치(Tech lunch)
매주 화요일, 수요일은 점심 시간을 활용하여 개인 스터디를 하는 시간입니다. 먹기 간편한 음식을 먹으면서 평소에 보고 싶었던 아티클, 발표 영상, 읽고 싶었던 책 등을 보는 시간입니다. 참여하는 인원은 계속 바뀌면서 6-7명 정도 꾸준히 참여하고 있어요.
그 외 Learning Share
기대만큼 흥하지 않던 개발 문화들
합류 예정자분께
어느 팀이나 마찬가지지만 완벽한 팀은 없는 것 같아요. 저희 챕터도 부족한 부분이 많은데요, 함께 문제를 정의하고 해결 방법을 찾아가고 있습니다.
메이커를 기다리는 수많은 제품들
아직도 새로 만들어야 하는 제품들이 정말 많이 있어요. 개인 사업자들의 고충을 해결할 제품부터 차별화된 결제 경험을 제공할 제품까지 메이커의 손길이 필요한 제품들이 아직도 많습니다.
해야 할 일이 없는 팀은 당연히 없겠지만 임팩트를 낼 것이 당연한 제품들이 만들어지고 있지 못한다는 것은 아쉬울 따름입니다.
비즈니스에 기여하는 코드
우리가 작성하는 코드는 궁극적으로 비즈니스에 기여하고 임팩트을 만들어야 한다고 생각해요. 위에서 언급한 개발 문화들도 이를 위해 존재해야 합니다.
개발을 하다 보면 야크쉐이빙에 빠지기 쉬운데요, 이를 경계하고 해결하고자 하는 문제에 집중하려고 합니다. 정말로 제품이 필요한지, 기능을 추가해야 하는지, 코드를 작성해야 하는지 먼저 고민하는 엔지니어를 지향합니다.
무엇은 하지 말아야 한다를 넘어 제품들이 지속 가능할 수 있도록 여러 고민을 하고 있어요.
•
코드를 덜 쓰고 문제를 해결할 수 없을까?
•
변경에 유연한 코드는 무엇일까?
•
지금보다 더 빠르게 서비스를 배포할 수 없을까?
•
변경에 깨지지 않는, 좋은 테스트 코드란 무엇일까? 테스트 환경을 빠르게 구축할 수는 없을까?
•
챕터 구성원들의 상향 평준화를 위한 시스템을 어떻게 만들 수 있을까?
마무리
토스페이먼츠의 프론트엔드 개발자에겐 어떤 기회가 있는지, 어떤 문화를 만들어가고 있는지 정리해봤어요. 최대한 생생하게 보여드리고 싶었는데 잘 전달이 되었을까요?
지면 관계상 어떤 활동을 하고 있는지 간단하게 소개하고 넘어간 부분이 있는데요, 좀 더 궁금한 개발 문화나 프론트엔드 챕터에 궁금한 점이 있다면 언제든 편하게 연락주세요! (jaeyeop@toss.im)
끝까지 읽어주셔서 고맙습니다.
(지금부터 광고) 저희 챕터에 합류하셔서 또 다른 개발 문화를 함께 만들어나가며 성장할 수 있으면 좋겠어요!
온보딩은 준비됐는데, 온보딩 할 사람이 없네... 