2025년 12월부터 2026년 3월까지의 회고

굉장히 오랜만에 회고를 작성한다. 12월은 겨울방학이 있었다 보니 기간이 얼마 안 되니까 1월에 몰아서 적어야지 했던 게, 벌써 4월이 되어버렸다. 그사이 부가세 제품이 "숨은 환급액 찾기" 서비스 내에 녹아들어 1월 중에 배포가 되었고 Coverage Growth Silo가 사라지고, 1월부터는 팀 재편에 따라 Inflow Silo에서 다양한 이벤트 제품들을 만들고 있다. 팀에 적응하고 내 안에 많은 생각을 정리하는 데 3개월이 걸렸던 걸까 쉽게 글을 쓰기 어려웠다. 조금은 정리된 지금 4개월에 대한 이야기를 적어보려 한다.

25년 11월부터 1월의 부가세 출시

25년 12월에 작성했던 새로운 세목이 바로 "부가세"로, 부가세는 사업자 대상의 세목으로 기존 숨은 환급액 찾기 과정에서 진행하는 스크래핑 과정에서 유저의 정보를 가져올 수 있기 때문에, 해당 유저의 부가세 신고를 함께 제공하기 위한 작업을 진행했다. 기존 플로우 내에서 녹아들었기 때문에 프론트 작업이 많지는 않았지만, 그 과정에서 중요했던 건 동적으로 스텝 수가 변경되는 퍼널이었다.

부가세는 여러 사업장에 대한 정보와 사업장 별로 특정 구매 항목들에 대한 정보를 입력받아야 하기 때문에 사업장 목록과 사업장 별 구매 항목이 내려오는 상황이었다. 기존 퍼널들은 길긴 해도 다음 스텝이 정해진 경우였기 때문에 명확하게 관리가 가능했지만, 같은 페이지 구성 내에서 동적으로 다음 페이지로 이동할 수 있어야 하고, 이전 스텝으로도 돌아올 수 있어야 했다.

같은 UI 요소이고 어떤 페이지가 몇 개 있을지 알 수 없기 때문에 별도 페이지로 분리하기 어렵고, 뒤로가기로 이전 입력 사업장 폼은 보여줘야 하는 상황이기 때문에 어떻게 해결할지 고민하다가, 하나의 페이지로의 응집도를 높이면서도 뒤로가기를 유지할 수 있게 useFunnel 패키지를 이용해보기로 했다.

useFunnel은 하나의 퍼널과 내부 스텝들 간 공유되어야 하는 정보를 queryParam으로 관리하기 때문에 히스토리 관리에도 용이한 장점을 가진다. queryParameter가 다르면 다른 화면이니까 각 사업장별 id를 기준으로, 퍼널을 push하는 방식으로 쌓으면 뒤로가기가 되면서, 렌더링하는 화면은 데이터만 해당 id로 찾아서 그려주면 되어 훨씬 간편하게 구현할 수 있었다.

구현하면서 숨고에서 구현했던 요청서 동적 폼이 떠오르던 시간이었다. 동일한 방식으로 웹에도 적용되어 현재 신고까지 잘 운영되고 있다. 나름 기존 제품과 다른 요구사항을 구현해서 재밌었던 작업이었다.

1월부터 진행한 Inflow 제품들

1월부터 Inflow 사일로로 팀이 재편되면서 3월까지 많은 제품을 만들고 실험과 이터레이션을 진행해왔다.

자동차세 연납
머니 리포트
설날 이벤트
연봉 비교
사전 신청 이벤트

자동차세 연납	머니 리포트	설날 이벤트	연봉 비교	사전 신청 이벤트

인플로우 사일로에서의 작업에서 중요했던 건 기존과 다르게, 핵심은 많은 제품들을 관리하고 빠르게 실험하는 것이었다. 또한 마케팅팀과의 협업이 긴밀히 이루어지기 때문에, 어떤 스킴이 푸시로 나갈지, 알림톡으로 나갈지 등 다양한 채널로 나가는 실험을 동시에 진행하는 경우가 많았다.

다행히 제품별로 특성이 다르기 때문에 결과 화면이 다르지만, 해당 서비스들로 유저에게 스크래핑을 진행시키고 해당 스크래핑 과정을 통해 추론한 환급액이 있는 경우 결제까지 연결해 나가는 게 가장 중요한 과정이라 큰 틀은 유사했기에 최대한 코드를 공통화하는 것의 중요성이 커졌다. 중복 코드는 줄이면서 서비스 개발 속도는 더 빠르게 만들 수 있도록 공통화하는 데 시간을 더 써보려 한다.

또한 특정 기간에 잠시 오픈하고 특정 기간 이후에는 사라지는 경우도 많기 때문에 이벤트를 마감하거나, 참여가 불가하게 되었을 때 코드를 적절하게 정리 작업을 하지 않으면 계속해서 방치될 수밖에 없는 문제점도 있었기 때문에 마감된 서비스를 지속적으로 관리가 필요했다. 이를 위해 배포 없이 빠르게 마감하기 위한 피쳐플래그를 추가하고 공통 이벤트 종료 화면을 추가하는 등 차츰 고도화해갔다.

마지막으로 신경썼던 부분은 스킴과 관련된 부분이다. 먼저는 마케팅을 위해서는 해당 서비스나 이벤트로 들어올 수 있도록 스킴이 필요하다. 이때 중요한 점은 토스 앱 내 인컴 지면을 깔고 인컴 웹으로 진입해야 하는 점이었다.

그러기 위해서는 토스 앱을 이용한 리다이렉션 방식으로 토스 앱을 통해 리다이렉션을 해주어야 할 때 인코딩된 인컴 웹 주소를 넣어주어야 리다이렉션이 가능한데, 이러한 스펙의 단점은 마케팅팀에서 해당 인코딩된 웹 주소에 referrer 값을 넣어야 하는 점이었다.

예를 들면 scheme://토스지면?redirect={인코딩된 인컴 웹 주소} 형태로 스킴이 정의되어 있을 때, referrer에 test를 붙여주려면 referrer%3Dtest가 되는데, 사람이 이해하기 어려운 인코딩된 인터페이스로 넣어야 하다 보니 제대로 동작하는지 확인도 어렵고 의사소통 비용이 커졌다.

이를 해결하기 위해서 네이티브만큼 빠르게 리다이렉션 할 수 있도록 별도 리다이렉션 페이지를 토스 앱 내 지면을 만들고 해당 화면에서 바로 referrer=test와 같은 파라미터를 붙여 인컴 웹으로 리다이렉션 되도록 변경했다.

scheme://토스지면?redirect=https://incom.toss.me?referrer=test이면 토스 지면 내에서 필요한 화면을 파싱해서 웹뷰로 띄워주면 되어 훨씬 간편하게 작업하실 수 있도록 했다.

스킴 관련 두 번째 작업은 공유 스킴 생성기이다. 공유 스킴을 만드는 과정은 꽤나 복잡하다. 스킴 자체의 스펙은 native에 정의되어 있지만 스킴을 앱스플라이어로 분석가능한 스킴으로 다시 만들고 OG 관련 정보를 넣고 마지막에는 단축 과정까지 거쳐야 사람들에게 공유할 수 있는 스킴이 완성된다.

이러한 과정을 매번 반복하다 보니 너무 많은 플랫폼을 오가며 작업하는 게 불편했고 제품 어드민에 직접 작업해서 스킴을 생성할 수 있도록 개선했다. 최근에는 버전 관리까지 추가해 중간에 OG 이미지나 문구가 바뀌어도 기존 앱스플라이어 스킴을 다시 만들지 않고 단순히 OG 정보만 수정해서 스킴을 다시 생성할 수 있도록 개선했다.

인플로우 팀에서 일하면서 기존과 색다른 고민과 접근을 하고 있고, 팀원분들과도 점점 합이 맞아가면서 즐겁게 일하고 있다.

12월의 액션아이템이었던 개인 클러스터 개선작업

개인 클러스터를 11월에 도입하면서, 다양한 의견을 들어 왔다. 처음에는 왜 명확했던 바텀싯 방식에서 개인 클러스터로 변경해서 써야 하는지, 개발 과정 자체가 바뀌다 보니 여러 가지 불편함을 느끼는 분들이 많았다.

가장 첫 번째 어려움은 테스트를 위해 헤더 값을 세팅해야 한다는 점이었다. 기존 바텀싯 방식의 경우 개발자 이름에 따라 들어가면 되다 보니 명확했는데, 바텀싯 방식 대신 개인 클러스터로 변경하면서 특정 헤더 값을 세팅해줘야 하다 보니 어려움이 발생했다. 개발자별로 작업별로 알파 테스트를 할 수 있게 확장하고 특정 작업이 반영이 안 되는 문제를 해결하기 위한 작업이었기 때문에 당연히 겪을 수밖에 없는 문제점이었다.

이를 해결하기 위해 최대한 팀 내 소통을 쉽게 가져가기 위해서 내가 선택했던 방식은 jira 티켓 번호였다. 개발자는 작업을 시작하기 전에 항상 jira 티켓을 따고 있고, 이후 QA 과정에서 이슈 티켓이 만들어져도 사일로 내에 공통되게 참조할 수 있는 작업 단위라고 생각했다. 또한 해당 방법의 장점은 기존 개인 클러스터를 먼저 사용하고 있던 서버 분들께서 경험했던 문제점이었던 일명 개클 납치 현상을 방지할 수 있다. userId로 특정 유저를 해당 서버로 트래픽에 들어가게 할 경우 누구를 위한 결과물인지 바로 타겟팅할 수 있지만, 단점은 세팅을 하고 사용하는 사용자는 본인이 어떤 결과물을 보고 있는지 알 수 없게 된다. 여러 작업을 동시에 테스트하는 QA 분들의 경우 본인이 어떤 빌드 결과물을 보이도록 세팅되어 있는지 알기 어렵기 때문에, 사용자가 주도적으로 보고 싶은 결과물을 볼 수 있게 하는 게 중요하다 생각해 규칙을 정하게 되었다.

해당 룰을 정하고 처음 정했을 때, 상대적으로 코어나 뱅크처럼 프론트엔드 조직이 큰 트라이브 단위에서 일해오셨던 PO 분들이나 디자이너 분들은 빠르게 적응하셨지만 어려움을 겪으시는 분들도 있었다. 하지만 현재는 다들 잘 적응해서 사용하고 있고, 최근에는 토스에서는 보통 한 명의 프론트 개발자가 하나의 서비스를 개발하니까 이런 일이 없는데 우리 같이 여러 명이 개발하고 작년에는 서로 QA 도중에 엉키고 문제가 많았는데 많이 나아졌다고 이야기해주기도 했다. 도입 후 적응의 시간이 필요했지만 해당 시간을 거쳐 팀 전체의 생산성을 늘릴 수 있어 보람을 느낄 수 있었다.

두 번째 어려움은 세팅을 위한 개발 툴의 접근 방식이었다. 네이티브 단에서 헤더 값을 설정하고 웹뷰를 열어야 해당 헤더 값을 주입할 수 있기 때문에 앱 내 세팅 필요했고, 이를 위해 네이티브 팀과 협업해 바로 세팅 화면으로 갈 수 있는 스킴을 만들고 편하게 세팅할 수 있게 진입점을 추가하고, 인컴 웹에 들어와서도 어떻게 세팅이 되었는지 모를 수 있기 때문에 세팅된 헤더 값을 인컴 웹에서 보여줄 수 있게 UI를 추가했다.

해당 작업을 하고 현재 기준에서 봤을 때 도입하기를 참 잘했다는 생각이 들지만, 어떤 기술을 도입하는 것보다 더 중요한 건 도입 과정에서 책임지고 과정을 이끌어가는 것 같다. 나에게는 필요하다고 하지만 누군가에게는 갑자기 생긴 불편함이 될 수 있다는 점을 염두에 두고, 불편함을 최소화하기 위해 노력하는 자세가 중요하다는 것을 또 한 번 느꼈다. 주기적으로 팀원들의 의견을 듣고 어떻게 하면 해결할지 계속해서 노력했던 게 유효했고, 보통 도입만 하고 팀의 부담으로 이어지는 경우가 많았지만 끝까지 책임지는 모습이 좋았다는 피드백을 듣기도 했다. 앞서 SSR 도입, 숨은 환급액 찾기 리팩토링 작업을 거쳐오면서 생기게 된 경험들이 지금의 나를 만드는 데 큰 도움이 되었던 것 같다.

앞으로 잘해보고 싶은 것들

사실 글을 쓰지 않았던 건 다양한 이유가 있었지만, 내가 어떤 걸 더 잘하고 싶은지 모르겠는 혼란이 컸다. AI가 발전하면서 개발자는 어떤 역할이 되는 걸까? 나는 어떤 걸 더 잘하고 싶은 걸까? 나는 프론트엔드 개발자로서 어떤 걸 잘하고 싶고 어떤 걸 잘하는 사람인거지? 주말마다 혼자서 고민하는 시간을 3개월 동안 보냈다.

그와 함께 주변 동료 분들께 처음으로 1 on 1을 요청드려서 나와 협업하면서 느꼈던 점을 물어봤다. 내가 어떤 장점이 있는지, 나와 협업하시면서 어려웠던 점은 없었는지 등 솔직하게 들어보고자 했을 때, 생각보다 내가 몰랐던 장점을 발견하기도 했고 커리어에 대한 다양한 고민도 같이 이야기 나누면서 정리가 되어가고 있다.

글을 쓰는 지금의 나는 즐겁게 일하고 싶은 마음이 가장 큰 것 같다. 어떤 때는 나는 아직 부족하다는 조바심과 인정받고 싶은 마음으로 이것저것 해보려 하기도 하고, 어떤 때는 AI가 더 잘할 수 있는 일이라면 굳이 내가 할 필요가 있을까 싶은 마음도 생기는 여전히 애매한 마음들을 가지고 있다. 하지만 즐겁게 일하면서 나를 단단하게 만들어나갈 수 있기를 기대해본다. 그리고 생각보다 내가 할 수 있는 것들이 아직 내가 더 잘할 수 있는 것들이 많다는 걸 발견해가고 있어서 조금 더 애써보기를 다짐해 본다.