10월은 1년 가까이 함께 했던 conversion boost silo에서 새로운 coverage growth silo로 이동을 결정하고, 새로운 제품을 위한 준비를 하는 시간을 가졌다. 준비하는 동안에 새롭게 내부 제품인 어드민 관련 작업을 담당하고, 드디어 5명이 된 프론트엔드 챕터의 새로오신 동료분들의 온보딩을 도와드리고 함께 협업을 위한 토대를 다지는 시간을 가졌다.
1년간의 토스와 팀 이동
글을 쓰는 오늘 11월 9일 기준으로 2024년 11월 4일 토스 코어에 입사 후, 1년동안 숨은 환급액 찾기 서비스를 만들어왔다. 숨은 환급액 찾기를 만들면서 개발자로서, 많이 성장했던 것 같다. react native를 이용한 앱 개발에서 프론트 개발을 해보고 싶다는 생각으로 지원해, 토스의 프론트엔드 멘토링 프로그램에 참여하고 토스에 입사하기까지 많은 작업들을 해왔다.
연말정산 미리보기와 같은 인플로우 이벤트 작업부터 스크래핑, 공제, 결제, 신고까지 전반의 복잡한 퍼널까지 기술적인 부분이나 더 잘 만들기 위한 노력과 도메인에 대한 이해도를 높이는 시간이었던 감사한 시간이었고, 부끄럽지만 도메인을 가장 잘 아는 사람 중 하나라고 여겨지는 것 같다.
그러면서 한편으로 컴포트존에 있다는 느낌을 받았다. 당연하게도 시간이 흐르면서 익숙해진 부분들이 생기고, 반복되는 작업 속에서 개발자로서 성장할 수 있는 부분들에 대한 고민이 깊어져 같다. 코어에서 인컴으로 전적을 결정했던 순간처럼, 팀을 옮기는 결정을 통해서 조금 더 새롭게 부딪히기를 바랬고, 내가 회사 밖에서도 무언가를 만들 수 있는 사람이 되기를 바랬다.
회사에서는 큰 문제를 푸는 법을 배우고, 언젠가 회사 밖에서 살아가기 위한 무기를 많이 배워나가는 시간이 되어야 하지 않을까라는 생각이 커져가면서, 단순히 프론트 개발자인 것을 넘어서 개발자로서 조금 더 큰 시야에서 시스템을 이해하고 싶었다. 처음부터 무언가를 만드는 경험을 해보고 싶었고, coverage growth 사일로로 옮기기로 결정했다.
기존의 숨은 환급액 찾기와 함께 더 시너지를 낼 수 있게 다양한 신규 제품을 고민하고 더 성장할 수 있는 0 to 1을 더 고민하는 팀으로, 조금 더 새로운 도전을 하면서도, 숨은 환급액 찾기에 대한 이해도를 바탕으로 제품과 다양한 사일로의 작업을 서포트하기에도 좋은 곳이라 생각했다. 새로운 곳에서 다시 신뢰를 쌓아 나가며, 새로운 무언가를 만들면서 내가 목표로 하는 모습을 이뤄가기를 바라본다.
공제 퍼널 개편
새롭게 월세공제를 제공하게 되면서, 공제 퍼널이 길어지게 되었고 그에 따른 유저경험 개선이 필요하다는 생각이 커졌다. 평소 고민하고 있던 구간이었기 때문에, 짬짬히 어떻게 개선하면 좋을까 정리해두었고 정리해둔 내용을 바탕으로 현재 공제 구간을 개선할 수 있었다.
숨은 환급액 찾기 내 공제구간은 유저의 환급액을 계산하기 위해 수정할 수 있는 공제들이 있다. 예를 들면, 부양가족, 신용카드 공제 등이 있고 현재의 문제는 해당 구간들을 항상 모두 거쳐야 한다는 점이었다. 예를 들어 유저 A는 부양가족, 신용카드, 의료비 공제만 있는 상태라면 해당하는 공제 뿐 아니라 다른 공제들 예를 들어 이번에 추가한 월세공제, 중소기업 취업 감면 등의 페이지를 모두 진입한 후에 해당하는지 체크해, 다음으로 넘어가는 로직으로 구현되어 있었다.
function 의료비Step() {
const [의료비공제_해당, set의료비공제_해당] = useState(false);
useEffect(() => {
const 의료비공제_해당 = await 의료비공제해당확인();
set의료비공제_해당(의료비공제_해당);
if (!의료비공제_해당) {
다음_공제로_이동();
} else {
set의료비공제_해당(true);
}
}, []);
if (!의료비공제_해당) {
return <로딩 />;
}
return <의료비공제_화면 />;
}
function 공제퍼널() {
// ...
return (
<Funnel.Render
의료비={() => (
<의료비공제Step
onNext={() => history.push("다음스텝")}
/>
)}
<!-- ... -->
마지막공제={() => (
<마지막공제Step
onNext={async () => await 공제입력완료()}
/>
)}
/>
);
}위와 같이 구성되면 각 스텝에서 판단을 담당하기 때문에 코드적으로는 명확한 장점을 가지지만, 불필요한 공제 스텝 화면들에 들어가면서 불필요한 계산을 하는 동안 로딩 화면이 오래 노출되는 문제가 있다.
이를 개선하기 위해 유저별로 항상 받아야 하는 공제 내용을 체크하고 동적으로 다음 스텝을 결정하도록 수정하고, 공제 내부의 입력 가능한지 판단하는 로직은 덜어내 유저경험을 개선했다.
function 의료비Step({ onNext }) {
return <의료비공제_화면 onNext={onNext} />;
}
function 공제퍼널() {
const 다음스텝_계산 = async (현재공제) => {
const 입력대상_공제목록 = await get입력대상_공제목록();
const 현재공제_index = 입력대상_공제목록.findIndex(
공제 => 공제.id === 현재공제.id
);
const 다음공제_index = 현재공제_index + 1;
if (다음공제_index >= 입력대상_공제목록.length) {
return null; // 마지막 공제
}
return 입력대상_공제목록[다음공제_index];
};
const 다음스텝으로_이동 = async (현재공제) => {
const 다음공제 = await 다음스텝_계산(현재공제);
if (다음공제) {
history.push(다음공제.id);
} else {
공제입력완료();
}
};
return (
<Funnel.Render
의료비={() => (
<의료비Step
onNext={() => 다음스텝으로_이동({ id: '의료비' })}
/>
)}
<!-- ... -->
마지막공제={() => (
<마지막공제Step
onNext={async () => await 공제입력완료()}
/>
)}
/>
);
}간단히 리팩토링한 코드를 보면 기존과 달리 공제 스텝별 판단 로직을 상위로 옮김으로써, 공제 스텝은 렌더링만 담당하도록 보다 간단해졌고 퍼널의 흐름을 담당하는 공제 퍼널 화면에는 다음 스텝이 어떤 스텝인지 계산하는 로직을 담당해, 불필요한 화면 이동 없이 필요한 화면만 보여주도록 개선할 수 있었다.
해당 개선으로 QA 팀분들의 도움을 받아, 전체적인 유저 플로우를 자동화로 돌려보았을 때 기존 8초 정도 걸리던 공제 퍼널을 1.5초~3초로 개선해 최대 약 40%의 로딩 시간을 단축할 수 있었다.
당시 무조건 모든 공제를 거치게 되어있었던 이유는 서버의 계산 방식과 서버분들도 완전히 이해하기 어려웠던 레거시 로직들이 점점 가시화되고, 함께 리팩토링 작업을 하면서 알려주신 엔진 계산 로직에 대한 이해도가 늘어가면서, API 호출 순서 등 환급액 계산을 위해 필요한 부분이 어떤 건지 알게 되었고, 이를 바탕으로 이번 개선을 주도적으로 진행할 수 있었다. 앞으로도 단순히 내가 맡은 프론트 뿐만이 아니라 제품 전반에 좀 더 관심을 가져야겠다는 생각이 들었던 작업이었다.
2명에서 5명으로 일하기와 온보딩의 온보딩
프론트 개발자가 2명에서 5명으로 늘어나면서, 2명에서 일하는 법이 아닌 5명에서 일하는 방식을 만들어 가는 시간이 필요했다. 기존 2명에서는 당연했던 방식이 적절하지 않게 되면서 새롭게 문제로 떠오르게 되거나, 기존에 문제라고 느끼지 못했던 부분이 문제가 되는 점들이 있었다. 예를 들면 알고보니 각자의 스타일로 만들고 있었던 폴더, 파일 컨벤션으로 인해 어떤 걸 기준으로 만들면 좋을지에 대한 질문에서 시작해, 폴더, api 등 제품 전반에 대한 컨벤션을 함께 정하고 있다.
또한 필요한 부분들에 대해 적극적으로 의견을 주시거나, 직접 작업해주시면서 든든함을 느낄 수도 있었는데, cspell과 같은 툴을 알려주시기도 하고 코드 리뷰가 전보다 활성화되어 다양하게 의견을 들으면 더 좋은 제품을 만드는 감정을 느꼈다.
특히 팀을 옮기면서 새로오신 두분이 conversion boost silo로 오시게 되어, 온보딩을 두 분과 함께 진행하게 되었다. 누군가에게 배우기만 하던 내가 누군가에게 전달하는 경험은 처음이었다. 말그대로 온보딩의 온보딩을 진행하게 된것이다.
"내가 설명을 잘하고 있는 걸까?", "내가 하는 방식이 정답이 아닌데 무조건 받아들이시면 안되는데" 등 다양한 고민을 하면서, 온보딩 과정이 괜찮은가 자주 물어보고 좀 더 좋은 방법이 없을까 고민해보기도 했다. 고민하며 선택한 방식은 함께 스펙을 보고 내가 작업한다면 생각하며 todo를 직접 짜고, 먼저 작업을 해보는 것이었다. 조금 과했던 것 같기는 하지만 전달드리기 위해서는 내가 먼저 이해해야한다고 생각하다보니 사실상 pr만 안올렸지 작업을 먼저 한번씩 해보고 todo로 만들어 전달하는 시간을 가졌다.
다행히 두분 모두 이야기해보았을 때, todo로 만들어 함께 필요한 부분들을 하나씩 전달드리는 방식이 좋았다는 피드백을 받기도 했다. 토스라는 큰 팀에는 워낙 히스토리가 많다보니 필요한 부분을 잘 정리해 드리는게 좋았다고 의견을 주셨다.
내가 무언가를 해야 속이 편하고, 내가 하는 무언가에 대해 고민이 많았던 나에게, 새로운 분들을 도와드리면서 오히려 함께 만드는 것의 기쁨을 더 배우는 시간이 되었다. 이와 함께 기존에 가지고 있던 혼자 다 해야한다는 부담감들을 점점 내려놓을 수 있었고, 드디어 "여유"라는 게 생길 수 있었다.
팀의 생산성을 위한 부분들에 대해, 제품 개발에 조금 더 시간을 집중할 수 있게 도와드릴 수 있는 방법을 더 고민하고 있고 기존 개발 테스트 방식과 배포 방식의 문제점을 해결하기 위한 개인클러스터를 도입해보려고 인프라팀과 함께 이야기하고 개인적으로 인프라를 더 공부해보고도 있다.
돌아보는 10월의 액션아이템과 11월 액션아이템
10월의 목표는 아래와 같았다.
- 히스토리 문서화 하기
- 인프라와 모노레포 구조 공부해보기
드디어 숨은 환급액 찾기 전체에 대한 히스토리 문서 작성 완료했다. 꽤나 오래 걸렸지만, 그래도 새로 입사하신 분들 뿐 아니라, QA분들까지 봐주시고 계신 것 같아 뿌듯했다. 이와 함께 추석에 모노레포에 대해 공부해보았고, 미뤄뒀던 aws 관련 책을 읽으면서 어떻게 인프라가 구성되어 있는지 이해도를 높이고 있다. 생각보다 재밌어서 더 공부해보고 프론트 인프라 부분들과 개발 환경 개선을 위한 작업도 진행해보면 좋을 것 같다는 생각이 들었다.
11월의 목표는 아래로 잡아보려 한다.
- 도커와 쿠버네티스 공부해보기
- 프론트 개인 클러스터 도입
aws 뿐 아니라 도커나 쿠버네티스와 같은 devops 관련 지식들도 공부해보려 한다. 최근 웹 서비스를 준비하면서 신규 배포가 필요한데 다양한 인프라 문제를 겪으시는 것을 보면서 내가 조금 더 잘 알고 있다면, 도움을 드렸을 텐데 아쉬움을 느꼈다.
개인 클러스터를 통해서 보다 다양한 작업을 진행해 프론트 개발자별로 n개의 개별 결과물을 테스트할 수 있게 개선해 팀 전체 생산성도 높여보려 한다. 1년을 다녀도 매번 새로운 토스 생활, 또 다시 성장하는 한달로 만들어보자.