Search
Duplicate

토스페이먼츠 프론트엔드 챕터를 소개합니다

안녕하세요, 토스페이먼츠 프론트엔드 엔지니어 한재엽입니다. 좋은 분들을 모시기 위해 저희 프론트엔드 챕터 소개글을 작성해봤습니다. 지속적으로 업데이트될 예정이니 많은 관심 부탁드려요! (last updated: 22.09.20)
Table of Contents

엔지니어에게 어떤 기회들이 있나요?

프론트엔드 엔지니어들은 ‘사일로silo’라는 목적 조직에서 개발하고 있어요. 각 사일로마다 다양한 기회와 도전들이 있는데요, 한 가지 기회에만 집중할 수도 있고 본인의 욕심에 따라 자신의 영향력을 넓힐 수도 있어요.
반기마다 전사적으로 진행하는 얼라인먼트 데이(Alignment Day)에서는 팀의 목표, 사일로가 해결하고자 하는 문제들이 공유되는데요, 이때 팀의 목표에 따른 우선순위를 알 수 있고 자신이 원하는 사일로가 어디인지 알 수 있을 거예요.

 새로운 SaaS 제품을 기획 단계부터 만들어갈 수 있는 기회

사업을 시작하는 예비 사장님을 위해, 결제로 맺어진 가맹점들에게 결제 이상의 또 다른 가치를 전달하기 위한 SaaS 제품을 새롭게 만들고 있어요. 사업에 필요한 복잡한 과정들을 대신해 주는 제품(Automation)부터 사업이 더 잘 되는데 필요한 제품(Insights)까지 제공할 예정입니다.
여러 Saas 제품들을 마치 하나의 제품처럼 매끄럽게 제공하기 위해서는 많은 고민이 필요합니다. 프론트엔드에서는 제품 간의 의존성, 공통 모듈들을 잘 관리하여 애플리케이션이 복잡해지지 않도록 구조를 고민하고 있어요. 자연스럽게 대규모 애플리케이션을 보다 잘 설계하고 운영해야 하는 책임이 주어지게 됩니다. (Stripe을 참고해도 좋을 것 같아요)

 개발자를 위한 서비스를 만들 수 있는 기회

가맹점에 결제를 연동하기 위해서는 위해서는 개발이 필수적으로 필요한데요, 이때 저희 결제를 연동하는 가맹점의 개발자들을 위한 제품을 만들고 있어요. Public HTTP API와 API를 사용하기 쉽도록 만들어둔 SDK, 그리고 이런 API/SDK를 기반으로 만들어지는 결제 연동 가이드까지 모두 개발자를 위한 제품이에요.
개발자를 위한 제품을 만들다 보니 “개발자의 경험“을 중심에 놓고 고민하는 특별한 경험을 할 수 있어요. 한 번 쓰고 버려질 API, SDK가 아니기 때문에 한 번을 만들 때도 신중하고 치열하게 고민하며 만들고 있어요. 이렇게 만든 SDK는 오픈소스로 공개하고 있어요.

 원한다면, 제품의 인프라부터 직접 설계하고 운영까지 해볼 수 있는 기회

모든 제품을 처음부터 새롭게 만들고 있기 때문에 여러 시도를 해볼 수 있었어요. 그중 하나는 모노레포(Monorepo) 운영인데요, 만들어지는 제품들을 각각의 프로젝트로 작게 나누고 독립적으로 관리하고 있어요.
서비스를 작게 운영하면 서비스 간의 의존성이 많이 줄어들게 되는데요, 그 결과 제품을 담당하는 엔지니어의 기술적인 의사결정을 최대한 존중할 수 있게 되었고, 새로운 기술 도입에도 사이드 이펙트(Side Effect)가 적기 때문에 도전적인 엔지니어링을 시도해볼 수 있는 환경이 마련되었습니다.
제품들이 계속 커지면서 CI 최적화, 효율적인 에러 모니터링 등 여러 기술적인 도전 거리가 생겨나고 있어요.

 원한다면, 서비스 개발에만 집중하여 제품의 로드맵을 직접 결정하고 개발할 수 있는 기회

어떤 임팩트에 집중할지, 제품을 어떻게 발전시킬지 고민할 수 있는 좋은 환경이기도 해요. 제품 개발을 위한 환경이 대부분 갖춰져 있기 때문입니다.
저희 챕터는 테라폼을 통해 인프라를 직접 관리하고 있고 Self Hosted로 운영하고 있는 GitHub Action으로 CD가 구성하고 있어요. 간단한 어드민을 만들어서 클릭 한 번만으로 배포와 롤백을 할 수 있습니다. 그리고 디자인 시스템, TDS(Toss Design System)와 여러 공통 라이브러리들이 있어서 빠르게 제품 개발에만 집중할 수 있어요.

어떤 개발 문화를 만들어가고 있어요?

이번엔 토스페이먼츠 프론트엔드 챕터의 개발 문화를 소개해 보려고 해요.
함께 성장하는 문화를 만들기 위해 여러 시도를 하고 있는데요, 다른 개발팀에게도 도움이 되지 않을까 싶어 정리해봤습니다.
챕터를 단순히 같은 일을 하는 사람들이 모인 조직이 아니라, 힘들 때 서로 도와주고 스터디도 모집하고 모각코도 하는 커뮤니티로 만들어가고 있어요. 계열사마다 조금씩 다른데요, 페이먼츠의 개발 문화를 소개합니다!

서비스 Overview

앞에서 말씀드렸듯이 토스페이먼츠의 프론트엔드 엔지니어는 사일로에 속해있어요. 사일로 조직 구조에서는 프론트엔드 엔지니어끼리 서로 담당하는 제품을 이해하기 어려운데요, 챕터 차원에서 이러한 문제를 해결하기 위해 여러 장치를 마련해보고 실험하고 있어요.
그중 하나가 서비스 Overview라는 활동입니다. 제품의 담당자가 서비스의 전체적인 흐름과 도메인 지식에 대한 내용을 문서로 정리하고 공유하는데요, 이때 서비스에 대한 맥락이 공유되어 코드 리뷰 시 큰 도움이 되곤 합니다.
아래는 실제로 저희가 서비스 Overview 활동을 한 노션 문서입니다! 현재 총 6개 제품에 대한 오버뷰가 진행됐네요! 이 활동은 효과가 좋아 격주로 로테이션을 돌며 진행하고 있습니다!
리스트 보기
List
Table
Search
대시보드
사업을 위한 플랫폼으로써 가맹점을 더 빛나게 해줄 제품
한재엽
보안상의 이유로 문서 내부에 존재하는 링크 일부가 동작하지 않을 수 있어요.
정해진 템플릿 없이 자신이 담당하는 제품을 소개하기 때문에 각자 다른 형태로 설명하는 것도 관전 포인트입니다.

엔지니어링 데이

프론트엔드 챕터 구성원 모두 매주 목요일 오후가 되면 라운지로 모여요. 정확히는 점심 식사 후 3시부터 인데요, 진행하고 있던 사일로 업무를 잠시 멈추고 함께 엔지니어링에 집중해요. 엔지니어링 데이 때 진행하는 활동들을 템플릿으로 만들어서 노션에 기록하고 있어요.
토스페이먼츠 프론트엔드 챕터 엔지니어링 데이 로그 노션 템플릿
저희 엔지니어링 데이 템플릿입니다! 활동은 없어지기도 하고 새로 생기기도 해요.

Health Check

엔지니어링 데이를 시작하기 전에 간단히 서로의 근황을 공유하는 Health Check로 엔지니어링 데이가 시작됩니다! 주로 스프린트에서 어떤 작업을 하고 있는지 이야기를 나눠요. (각종 드립과 TMI가 난무하는 시간입니다)
이런 느낌입니다!

Discussion

챕터 차원에서 논의해야 하는 이슈가 있다면 함께 토론합니다.
최근에는 ‘세종대왕 프로젝트’라는 긴 논의를 마무리 지었는데요, 코드에 ‘한글’을 부분적으로 사용하는 부분에 대한 컨벤션을 정의했어요. 관련 내용은 아래 노션 문서를 통해 보실 수 있어요.
이 외에도 코드 리뷰 시스템에서 보완됐으면 하는 부분이 있다던가, 합의에 이른 컨벤션에 제안하고 싶은 게 있다던가 등의 이야기를 나눠요. 당연히 챕터 구성원이라면 누구든 주제을 발제할 수 있어요!
논의가 길어진다면?

Mob Programming

몹 프로그래밍이라고 들어보셨나요? 서로 담당하는 제품을 이해하기 위한 실험 중 하나로 몹 프로그래밍을 하고 있어요. 저희는 3명 단위로 진행을 하고 Driver가 진행하고 있던 작업을 함께 진행하는 방식입니다.
같이 코드를 작성하다 보면 서로 많은 것들을 공유할 수 있었는데요, 생산성을 높여줄 수 있는 단축키를 알아가는 것부터 전혀 생각하지 못했던 관점을 배울 수 있다는 피드백까지 긍정적인 의견이 많아서 잘 운영되고 있습니다.
최근엔
최근 진행 목록

라이트닝톡

TIL(Today I Learned) 처럼 알게 된 내용을 가볍게 공유하는 시간입니다. 보통 5분 내로 끝나는 가벼운 주제로 이야기를 해요. 사용하고 있던 라이브러리에서 좋은 인터페이스를 알게 되었다던지 Safari에서 겪은 삽질기라던지 매주 있지는 않고 가끔가다 진행하고 있습니다.
다른 계열사에도 충분히 도움 될 것 같은 내용은 전체 계열사 엔지니어링 데이의 Tech talk에서 공유합니다.

코드 리뷰

저희 챕터는 서로의 성장을 위한 코드 리뷰를 하려고 노력하고 있어요.
리뷰 과정에서 새로운 관점을 배웠거나 좋은 리뷰라고 생각되는 Pull Request에는 Good Review 라는 라벨로 표시를 해둬요.
Good Review 라벨이 등록된 Pull Request 목록
엔지니어링 데이에서 한 주간 Good Review 라벨이 달린 코드 리뷰를 함께 봅니다. 미처 리뷰하지 못했더라도 러닝이 공유될 수 있도록 마련한 활동입니다.

주로 어떤 내용을 리뷰할까?

저희 챕터 코드 리뷰가 어떻게 이뤄지는지 실제 Pull Request 스크린샷을 통해 보여드릴게요.
리팩토링 내성을 고려하여 테스트 코드를 작성해보자. 좋은 설계를 만드는 테스트 코드!
선언적으로 작성하자
숨겨진 의존성을 드러내고 UI 추상화를 고민하자
노출할 필요 없는 파라미터는 숨겨도 좋지 않을까?
Sub Path를 잘 활용해보자.
사용하는 방향을 고려해서 반환 인터페이스 결정하기
Command에서는 값을 반환하지 말자
사용하는 인터페이스를 고려한 리팩토링

기대만큼 흥하지 않던 개발 문화들

Learning Share

앞으로 남은 과제들

어느 팀이나 마찬가지지만 완벽한 팀은 없는 것 같아요. 저희 챕터도 부족한 부분이 많은데요, 함께 문제를 정의하고 해결방법을 찾아가고 있습니다.

메이커를 기다리는 수많은 제품들

아직도 새로 만들어야 하는 제품들이 정말 많이 있어요. PG를 다시 Building하고 있다 보니 미친 효율성을 만들어낼 내부 운영을 위한 도구들부터 시작해서 차별화된 결제 경험을 제공할 제품까지 메이커의 손길이 필요한 제품들이 아직도 많아요. 결제는 여러 Saas 제품 중 하나일뿐, 여러 사업자를 위한 제품들이 메이커를 기다리고 있습니다.
해야 할 일이 없는 팀은 당연히 없겠지만 임팩트를 낼 것이 당연한 제품들이 만들어지고 있지 못한다는 것은 문제라고 생각해요.

지속 가능한 제품을 위한 고민

만들어지는 제품이 종료될 확률이 거의 없어요. 그렇기 때문에 오래갈 수 있는 제품을 만들어야 해요. 낡은 PG를 직격으로 겪다 보니 많은 것을 학습할 수 있었어요. 무엇은 하지 말아야 한다를 넘어 제품들이 지속 가능할 수 있도록 여러 고민을 하고 있어요.
매번 신경써야 하는 로깅, 자동화 할 수 없을까?
변경에 깨지지 않는, 좋은 테스트 코드란 무엇일까? 테스트 환경을 빠르게 구축할 수는 없을까?
조금 더 빠르게 서비스를 배포할 수 없을까? CI/CD를 개선해보자
이메일 템플릿 작업, 좀 더 자동화 할 수 없을까?

마무리

토스페이먼츠의 프론트엔드 개발자에겐 어떤 기회가 있는지, 어떤 문화를 만들어가고 있는지 정리해봤어요. 최대한 생생하게 보여드리고 싶었는데 잘 전달이 되었을까요?
지면 관계상 어떤 활동을 하고 있는지 간단하게 소개하고 넘어간 부분이 있는데요, 좀 더 궁금한 개발 문화나 프론트엔드 챕터에 궁금한 점이 있다면 언제든 편하게 연락주세요! (jaeyeop@toss.im)
끝까지 읽어주셔서 고맙습니다.
(지금부터 광고) 저희 챕터에 합류하셔서 또 다른 개발 문화를 함께 만들어나가며 성장할 수 있으면 좋겠어요!
온보딩은 준비됐는데, 온보딩 할 사람이 없네...