2025년 3월 회고

2025년 3월도 빠르게 흘러갔다. 우리 팀의 큰 대목인 5월이 다가오면서 갈수록 더 분주하게 준비해나가는 것 같다. 세금 시장에 대한 다양한 실험 작업과 기술적고민과 커리어에 대한 고민 등을 했던 3월에 대해 기록해보려 한다.

세금이란 도메인에 대해 더 알고 싶어

처음 토스 코어에 합류하고 현재 5개월 가량이 되었다. 5개월 간의 시간동안 숨은 환급액 찾기라는 하나의 서비스에 대해서 다양한 시도와 실험을 진행해왔다.

11월 오자마자 일주일만에 만들었던 환급액 2배 이벤트부터 유저들의 많은 관심을 받았던 연말정산 미리보기, 25년 현재까지 conversion boost silo의 한명의 프론트 개발자로서 환급 과정에 필요한 스크래핑, 공제, 결제, 신고라는 서비스 전반적인 작업들에 대한 실험과 개선 작업들을 담당하고 있다.

좋은 동료들과 좋은 결과들을 만들어가면서 내 안에 앞으로의 토스 생활을 어떻게 가져갈지, 인컴과 코어중 어디서 커리어를 이어나갈지에 대한 고민이 시작되게 되었다.

1년 반정도의 모바일 개발, 6개월 정도의 프론트엔드 개발을 하면서 클라이언트 개발은 다양한 분야와 접해져 있고 상대적으로 넓지만 얇게 많이 알아야한다고 느껴졌다. 그과정에서 아쉬웠던 점은 서버 개발자분들에 비해 도메인을 코드로 표현하는 경우가 많지 않았다. 어떤 서비스별로 만드는데 있어서 중요한 특징들에 대해 경험하지 못하고 잘 이해하지 못하고 개발하고 있다는 갈증이 있었다.

이러한 고민을 갖고 있던 나에게 숨은 환급액 찾기라는 서비스는 조금 달랐다. 세금이라는 어려운 도메인을 보다 쉽게 풀어내기 위해서 애쓰는 동료들과 있다보니, 모르면 코드를 작성하지 못하는 경험도 하게 되고, 이 일을 왜 해야하는지 납득하기 위해서 공부할 수 밖에 없었다. 토스에 왔는데 금융 맥락의 제품을 꼭 경험하고 싶던 나에게 정말 운좋게 찾아온 기회같이 느껴졌다.

그래서 큰 결심(?)으로 토스 인컴으로 4월 1일부터 전적하기로 결정했다. 코어에는 90명이나 되는 뛰어난 프론트엔드 개발자분들이 계시고, 각 분야에서 잘하시는 분들이 많이 계셔서 더 가까이 배울수 있는 장점과 코어 내의 100개가 넘는 정말 많은 서비스들이 있다보니 다양한 도메인에서의 성장 기회를 놓치는 건 아닐까 많이 고민했다.

하지만 인컴에서 파견으로 근무하는 과정에서도 여전히 끊기지 않고 계속해서 좋은 코드를 토론하고, 함께 오픈소스를 만들고, 업무 협력을 많이 하고 있고, 현재 서비스를 5개월만으로 "나는 이 서비스를 정말 잘 이해하고 있어", "나는 이 서비스를 만들기 위해 정말 노력했어"라고 하기에는 아직 하고 싶은게 많았다.

코어라는 든든한 울타리, 깔끔하게 포장된 고속도로를 달리는 대신 아직 많이 개선하고 부딪히면서 배워나가야하는 오프로드에서 직접 자갈도 치우고 길을 만들면서 성장하고 싶다는 생각에 선택하게 되었다.

그렇게 선택하고 나니 서비스에 의견을 내는데 왠지 모르게 적극적이게(?) 되었다. 어디서 전환율이 떨어지는지, 어떻게 팀 목표를 이룰 수 있을지 주어진 일만 하는게 아니라 아이디어들도 조금씩 더 내보고 있다.

그리고 추가로 2월에 목표로 했던 세금 도메인 관련 서적 읽기을 액션 아이템을 실행했다. 이번 달 읽은 책은 물어보기 부끄러워 묻지 못한 전국민 세금상식으로 가벼운 책이었지만 상속세, 부가세, 취득세 등 우리 생활에 곳곳에 숨어있는 세금 영역에 대해 알게 되었고 우리 팀이 목표로 할 다양한 시장들에 대해 알 수 있었다.

토스 인컴을 선택하면서 내가 가진 기대감들과 함께, "불편함을 느낄 때 사람은 행동하고, 행동할 때 성장한다"고 생각하는 나에게 새로운 도전의 기회를 만들어 나가길, 그리고 그 기회를 잡아 더욱 성장하는 개발자가 되기를 바라본다.

스크래핑 퍼널 개선

3월에는 신고 내역 개선, 결제 화면 실험 등 다양한 작업들을 진행했지만 그중 가장 개인적으로 하고 싶었고, 고민을 많이 했던 것은 스크래핑 퍼널 개선 작업이었다.

스크래핑은 특정 서비스를 진행하기 위해서 필요한 인증이나 특정 절차를 앱내에서 할 수 있도록 구현하는 과정으로 숨은 환급액 찾기 서비스에서는 유저별 환급액을 계산하는 기준이 되는 여러가지 데이터를 가져오는 서비스의 시작점이라고 볼 수 있다.

기존에는 2개 또는 3개의 스텝만 거치면 되기 때문에 하나의 페이지에서 퍼널이 구현되어 있던 상황이었지만, 현재 조건에 따라 2개에서 5개까지 늘어난 상황이다보니 여러가지 문제점이 발생하게 되었다.

먼저 유저 경험적으로 길어진 퍼널 스텝만큼 이탈율이 증가할 수 있게 되었고, 내부적으로 스크래핑에 걸리는 시간이 길어질 수록 이탈율이 급격하게 증가하는 데이터가 있어 이를 근거로 작업을 진행할 수 있었다.

두 번째로는 하나의 화면에 여러 서비스를 대응하는 방식으로 구현되어 있기 때문에, 각각의 서비스 특성을 살린 코드를 작성하기 어려웠다. 단순 문구를 변경하는 것에도 여러 depth를 거쳐서 수정해야했고 이로 인해 컴포넌트 별 내부는 서비스 분기문이 늘어나 한번에 읽기 어려운 코드들이 작성되고 있었다.

세 번째로 엔진의 개선으로 불필요해진 스텝과 로딩 시간이 줄어들었다. 엔진을 개발하시는 개발자분들의 노력으로 특정 유저들의 환급액 계산에 필요했던 스텝이 엔진의 개선으로 불필요해짐에 따라 제거가 가능해졌고, 스크래핑에 걸리는 시간이 줄어들어 로딩화면도 그에 맞게 단축된 버전으로 만들 필요가 생겼다.

이러한 제품적 필요성과 함께 평소에 개선하면 좋겠다 싶었던 다소 모호했던 API 인터페이스를 서버 개발자분들과 다시 정의하고 적용하는 작업을 했고, 구간별 성능 개선작업도 함께 진행했다.

작업을 진행하면서 특히 신경썼던 부분은 도메인에 서비스별 스크래핑 분기를 최대한 상위에서 사용처와 함께 두고, 하위 컴포넌트들은 도메인 맥락없이 단순히 조합할 수 있는 구조를 가져가려했다.

예를 들어, 인증 스텝을 구현할 때 공통되는 컴포넌트를 만들고, 공통되는 컴포넌트 필요한 요소를 prop으로 전달해 만든 컴포넌트를 사용처에서 사용하는 형식으로 코드 중복은 줄이면서도 최대한 사용처에서 명확하게 사용할 수 있게 하려했다.

function BaseAuthStep(props:AuthStepProps){
    // 공통로직
}

export const AuthStep={
    숨은환급액찾기: (props:AuthStepProps)=> <BaseAuthStep title={"숨은 환급액 찾기"} {...props}>
    연말정산미리보기:(props:AuthStepProps)=> <BaseAuthStep title={"연말정산 미리보기"} {...props}>
}

function 숨은환급액찾기Funnel(){
    return(
        <Funnel.Render
            AuthStep={()=> <AuthStep.숨은환급액찾기 >}
            //...
        />
    )
}

function 연말정산미리보기Funnel(){
    return(
        <Funnel.Render
            AuthStep={()=> <AuthStep.연말정산미리보기 >}
            // ...
        />
    )
}

열심히 개선 작업을 하고 동료분들의 좋은 피드백도 받았지만, 개선으로 인해 새로운 문제도 발생하게 되었다. 예를 들면, N개의 서비스에 따른 N개의 퍼널 페이지가 만들어지다 보니 로깅과 같이 명령적으로 작성되는 코드들에서 누락되는 문제가 있었다.

기존 하나의 페이지에서 공통화 되어있던 부분들이 쪼개지는 과정에서 서비스마다 다른 부분, 공통으로 관리해야할 부분 등에서 놓치는 부분이 생겼던 부분이었다.

그래도 작업을 진행하면서 퍼널 개선 작업의 원래 범위는 숨은 환급액 찾기만이었지만 extra mile로 인플로우 팀의 다양한 제품들도 모두 개선된 스크래핑 퍼널을 이용할 수 있게 추가작업을 진행해 전체 제품에서의 개선을 이끌어내기도 해 적극적으로 작업해본 성공적인 첫 시도였다.

배포를 이번주에 나가 아직 퍼널 전환율 등 데이터를 보지 못했지만 좋은 영향이 있기를 기대하고 있다.

조금 더 과감해지자

3월에는 동료분께서 인트로 화면 진입시간의 문제점을 제기하고 SSR도입 작업에 대해 팀에 적극적으로 공유하고 공감대를 만들어 내 4초에서 5초까지 걸리던 구간을 0.5초로 단축하는 큰 성과를 만들어냈다.

동료분의 일하는 모습을 보면서 토스가 일하는 방식에 대해 생각을 다시 한번 이해하게 되었다.

나 또한 인트로 화면에서 오래걸리고 있다는 문제가 있다는 것을 알고 있었다. 당시 그것보다는 팀의 다른 작업을 하는 게 더 중요하다고 생각한 것도 있지만 나는 로딩 시간이 오래걸리는 게 큰 문제라고 나에게 시간을 주면 해결해보겠다고 말할 용기가, 팀원들을 설득할 용기가 없었던 것 같다.

동료분의 문제 제기를 하고 공감대를 만드시는 과정을 보면서 행동하지 못했던 나의 부족함을 느꼈고, CSR과 RN만 경험했던 나와 달리 SSR을 도입했을 때 명확한 효과가 있을 것이라는 것에 물음표를 던졌던 나와달리 다른 개발자 분들과 치열하게 의논하고 플랫폼팀의 도움을 받아 작업하시는 모습에서 방법을 찾고 문제를 해결하는 방향에서도 적극적으로 도움을 구해야한다는 것을 배울 수 있었다.

문제를 문제라고 생각한다면 조금 더 과감하게 말하는 것, 그리고 그 문제를 풀기 위해 다양한 리소스를 구하고 책임지고 해결하는 것 내가 배울 부분이라 느껴졌다.

너무 고민만 하기보다 행동으로 시도해보는 것, 3월에 배운 토스에서 일 잘하는 동료의 모습이었다.

3월의 액션아이템과 다음 달을 위한 액션 아이템 정리

3월 회고에서 작성했던 액션아이템은 아래와 같다.

퍼널 개선 작업 진행하기
더 일을 잘하기 위해 일감을 쌓고 함께 진행하기
세금 도메인 관련 서적 읽고 정리하기
사내 라이브러리 기여하기
HMR 관련 글 작성하기

2월에 비해 많은 부분을 진행했던 달이었다. 앞서 작성했던 대로 퍼널개선 작업과 세금 도메인 관련 서적을 읽었다.

더 일을 잘하기 위해 일감을 쌓고 함께 진행하기 위한 작업은 리스트업을 했을 때 가장 필요한 작업으로 개인 클러스터 작업이 떠올랐다. 두명이 하나의 서비스에서 작업하다보니 테스트 환경을 점유하는 형식으로 테스트가 진행되거나, 서로 버전이 달라 덮어써져 QA에서 해결된 문제가 다시 발생하는 등 여러가지 이슈가 있어 왔다. 4월에는 이를 위한 작업을 진행하고, AWS에 대해서도 공부해보고자 한다.

HMR 관련 글도 드디어 작성했다. 사실 목표는 fast-refresh 동작방식까지 보고 싶었지만 너무 방대하기도 했고, webpack을 잘모르는 상황이었다 보니 webpack-dev-server과 webpack에서의 HMR 동작방식을 먼저 알아보았다.

사내 라이브러리 작업은 아직 정체기에 있다. 길드에서 호기롭게 추가할 작업목록을 작성해보겠다 했지만 아직... 하지 못했다. 메인 업무와 함께 길드 작업을 하는 건 생각보다 많이 빠듯하긴 하지만, 오픈 소스가 제대로 오픈되고 많은 관심을 받을 수 있게, 조금 더 내가 반복적으로 코드를 작성하는 부분들에 대해 관심을 갖고 동료분들의 코드를 보면서 같이 포함되면 좋을 부분을 정리하려 한다.

4월의 액션아이템

다음 달을 위한 액션아이템은 아래와 같다.

Tanstack Query 문서 정리하고 소그룹 내 발표하기
개인 클러스터 지원 작업 진행해보기
세금 도메인 관련 서적 읽고 정리하기
사내 라이브러리 기여하기

3월과 동일하게 가져가는 두가지 액션아이템과 함께 새롭게 개인 클러스터 관련 작업과 Tanstack Query 문서 정리하고 소그룹 내 발표하기는 새롭게 진행해보려 한다.

인트로 뿐 아니라 서비스 전반적으로 SSR을 도입하려는 상황에서 토스의 SSR에서 데이터 패칭 방식을 이해가 필요해졌다. 이에 대해 정리하고 소그룹 내에 발표도 하면서 조금 적극적으로 학습을 해보려 한다.

글로 정리하다 보니 정말 다양한 고민과 결정을 했던 한달이었던 것 같다. 다가오는 5월을 대비해 아마 막판 스퍼트를 하게될 4월에 더 많은 기여와 성장을 기대해본다.