들어가며

25년을 이어 26년에도 인컴 내 가장 큰 비즈니스 이벤트인 5월이 돌아왔다. 작년과 달리 이번 년도는 다른 팀에서 인플로우를 위한 제품들과 챕터 내 제품을 서포트하는 작업을 주로 진행했다. 작년과는 사뭇 달랐던 5월, 5월을 경험하면서 팀내 쌓인 기술 부채를 정리하고 개선했던 6월의 작업 내용을 정리해보려 한다.

26년의 5월

작년 5월 회고를 마무리하며 이런 고민을 적었다. 혼자 고맥락의 제품을 개발하면서 높아진 버스지수, 서로가 백업해줄 수 있고 인컴 프론트 개발자 모두가 심리적 안정감을 갖고 일할 수 있으면 좋겠다는 바람이었다. 1년이 지난 지금, 이번 5월을 보내며 그 바람이 꽤 현실이 되었다는 걸 느꼈다.

작년에는 내가 아니면 봐줄 사람이 없어라는 생각으로 혼자 책임감에 끙끙 앓기도 했다. 하지만 이번에는 동료가 늘어난 만큼 부담이 줄었고, 작년에 내가 겪었던 어려움을 누군가 겪고 있지는 않을까하는 생각으로 대신 커버해줄 수 있는 작업은 없을지 돌아보는 데 시간을 더 쓸 수 있었다. 작년이 신생 계열사로서 무언가를 숫자로 증명해야 하는 시기였다면, 올해는 작년의 노하우를 살려 안정적으로 운영하며 심리적 안정감을 가지고 일할 수 있었다.

개인적으로 가장 달랐던 건 팀이었다. 작년에는 종합소득세 신고 전과정을 담당하는 팀에서 5월을 보냈지만, 이번에는 인플로우 팀에서 머니리포트, 작년 소비 돌려받기, 올해 환급액 미리보기처럼 신규 유저와 사전 신청자를 모으기 위한 작업을 진행했다.

5월 정기신고 전 예상 환급액을 미리 알아볼 수 있는 '올해 환급액 미리보기' 서비스 (출처: 토스인컴 보도자료)

제품과 플랫폼, 두 방향으로

시기가 정해져 있거나 빠르게 준비되어야 하는 작업이 많다 보니, 운영을 효율화하고 빠르게 개발할 수 있도록 준비해두는 게 중요했다. 이번 5월에 신경 쓴 부분은 아래와 같다.

• 신규 서비스 개발로 사전 신청자와 신규 유저를 목표의 80% 이상 모을 수 있었다.
• 트래픽이 몰리는 시기인 만큼 장애 민감도를 높이기 위해 false alert를 줄여, 진짜 유효한 에러 위주로 모니터링이 가능하도록 정비했다.
• 간헐적으로 발생해 테스트를 어렵게 만들던 알파 배포 실패는 빌드 메모리 개선 작업을 통해 하루 2~3건에서 현재는 0건에 가깝게 줄일 수 있었다.

또한 4월부터 이어온 머니리포트를 비롯해, 인플로우 서비스 간 중복되던 스크래핑 로직을 공통화하고 스킴 관리를 위한 어드민을 구성하는 등 운영을 위한 준비를 통해 서비스별 개발을 더 편하고 빠르게 할 수 있도록 지원했다.

아쉬웠던 점도 있었다. 서비스를 정리하는 과정에서 서비스 간 공통으로 쓰던 페이지를 잘못 지웠는데, 기존에는 404 페이지에 대한 에러 알림이 없어 뒤늦게 발견하게 되었다. 이를 계기로 이번에는 404 페이지로 렌더링되면 이전 페이지 주소를 센트리에 빠르게 제보하도록 해 같은 문제를 방지할 수 있게 했다.

서비스와 플랫폼 두 방향 모두 신경 쓸 수 있었던, 작년과는 사뭇 다른 5월이었다.

5월을 마치고 6월

상반기 회고에서 중복 코드를 줄이면서 서비스 개발 속도를 더 빠르게 만들기 위해 공통화에 시간을 더 써보겠다고 적었는데, 5월을 지나며 쌓인 기술 부채를 정리한 6월이 그 시간이 되었다. 빌드 메모리 최적화를 마친 뒤, 제품 내 기술적으로 챙기면 좋을 부분에 집중했다. 내가 집중했던 부분은 아래와 같다.

• 스테이징 테스트 환경 개선
• 서비스별로 다른 파이프라인 정리
• 서비스 간 중복 코드 관리를 위한 workspace와 catalog

스테이징 테스트 환경 개선과 파이프라인 정리

앞서 스테이징 테스트 환경 개선 글에서 정리한 것처럼, 스테이징 테스트 환경의 편의성을 크게 올렸다. 신규 서비스가 계속 늘어나고 앞으로 더 많아질 것이 예상되기 때문에 이러한 변화가 필요하다고 생각했고, devops·security·platform 팀 분들과 함께 작업해 이룰 수 있었던 성과였다. 덕분에 이제는 스테이징 wifi나 vpn만 켜면 별도 스킴 없이 라이브 앱에서 바로 진입할 수 있어, 편하고 유용하게 사용하고 있다.

개인적으로 가장 큰 성과는, 그동안 블랙박스로 남아 있던 인프라 서빙 과정 전체를 이해하게 된 것이다. 이 경험은 새로운 서비스를 만들 때 무엇이 필요한지, 회사와 비즈니스가 커짐에 따라 어떤 준비가 필요한지에 대한 식견을 크게 넓혀줬다.

그래서 6월 이후 이어서 진행하고 있는 작업은, 서비스마다 제각각이던 파이프라인을 하나로 통일하는 일이다. 새로운 app-router 서비스를 만들 때 필요한 템플릿을 CLI로 제공해 서비스·모니터링·인프라 세팅까지 전 과정을 원스톱으로 구현할 수 있게 하는 데 관심을 두고 작업하고 있다. 그 하위 작업으로, 인프라를 한 번에 생성하기 위해 standalone 출력에 맞게 도커 파일과 build 스크립트를 최적화하고 통일하는 작업을 진행했다.

토스라는 거대한 제품이 돌아가는 방식에 대한 이해도를 높이고, 아직 배울 게 많다는 걸 느끼는 순간이었다.

서비스 간 중복 코드 관리를 위한 workspace와 catalog

인컴 홈 서비스를 새롭게 개편하면서, 하나의 서비스를 넘어 인컴 전체의 패키지를 관리하고 고도화할 필요성이 커졌다. 그래서 yarn workspaces로 인컴 내 패키지를 하나로 묶고, yarn PnP 환경에서 서비스마다 제각각이던 의존성 버전을 catalog로 한곳에서 관리하도록 정리하고 있다. catalog는 의존성 버전을 .yarnrc.yml에 상수처럼 정의해두고 각 package.json에서 catalog: 프로토콜로 참조하는 방식이라, 버전 업그레이드가 한 번의 수정으로 끝나고 버전 불일치나 머지 충돌을 줄일 수 있다.

숨은 환급액 찾기를 담당해주시는 팀원분들이 도메인 코드 관리에 집중하시는 동안, 나는 도메인이 아닌 공통 관심사인 인증, app-router/pages-router별 공통 패키지 등을 정리해가고 있다.

서비스가 커질수록 내가 감당하고 고려해야 하는 범위도 함께 커졌고, 팀이 최대한 편하게 개발할 수 있도록 여러 플랫폼 업무를 고민하고 적용하면서 깊이를 쌓아가고 있다.

2학기는

2학기가 이미 시작된 지금, 사일로 내에서는 인컴 홈 서비스를 새롭게 만들어가고 있다. 챕터 내에서는 기존 pages-router 기반 서비스를 app-router와 인증 개편에 맞춰 어떻게 함께 서빙할지 이어서 고민하고 있다.

앞으로는 에러를 줄이는 것을 넘어 성능과 안정성까지 챙기는 방향으로 시스템을 더 단단하게 만들어가려 한다. 먼 훗날일 수도 있지만, 큰 그림으로는 서비스 간 통신을 보호하는 mTLS, 관측성을 표준화하는 OpenTelemetry, 프론트 자체 게이트웨이 설계를 통한 인프라 개선, 그리고 템플릿화를 통한 서비스 표준화까지 그려보고 있다.

몇 개월 전만 해도 프론트로서 더 도전해볼 기술적 챌린지가 있을까 막막했는데, 제품이 커지고 회사가 커지고 동료가 늘어나면서 풀 수 있는 문제의 크기도 함께 커지는 걸 체감한다. 하나하나가 개별 제품을 넘어 인컴 전체의 기반을 다지는 일이자 챕터 안에서 이뤄가보고 싶은 기술적 도전이라, 막막하면서도 즐겁다.

돌아보면 나는, 제품을 만드는 즐거움만큼이나 그 제품이 돌아가는 시스템을 이해하고 단단하게 만들어가는 데서 더 많이 배우고 더 크게 즐거움을 느끼는 사람이라는 걸 이번 분기를 보내며 알게 됐다. 작년에 혼자 끙끙 앓던 자리에서 이제는 팀과 인프라 전체를 바라보게 된 만큼, 개발자로서 더 성장하고 더 큰 문제를 사람들과 함께 풀어갈 수 있기를 기대해본다.