9월은 드디어 조금 무난한 한달이었던 것 같다. 매달 새로운(?) 토스 생활이지만 그래도 조금은 안정화되어 가는 느낌을 받았다. 그리고 드디어 새로운 동료 분이 오셨다. 돌아보니 굉장히 다양한 작업을 한 것 같지만 그래도 적응해가는지 무난했던 한달간의 생활을 돌아보자.
TDS V2 업데이트
TDS는 토스 개발자라면 매일 마주하는 제품으로 토스 디자인 시스템을 의미한다. TDS는 데우스라는 디자인 툴과 함께 사용하는데 인컴은 이전 버전의 다소 오래된 패키지를 사용하다보니, 8월 회고 마지막에 이야기했던 부분처럼 Breaking Change가 있는 상태로 코드젠이 제공되면서 지속적으로 일일이 싱크를 맞춰야하고, 코드 젠에 되어있는 대로 코드를 작성했지만, 실제로는 보이지 않는 디자인 QA 티켓이 지속적으로 발생해 팀의 리소스가 사용되는 이슈가 있었다. 이러한 부분을 해소하기 위해서 디자인 시스템 버전 업데이트를 제안하고 진행하게 되었다.
작업을 진행하면서 가장 고민했던 부분은 어떻게 하면 달리는 차의 바퀴를 갈아 끼울 수 있을까였다. 왜냐하면 디자인 시스템은 정말 매일 개발을 하면서 사용되다보니 작업하는 순간에도 동료의 작업에 마이그레이션 해주어야할 부분이 생길 수 있기 때문이었다. 내가 작업한 브랜치가 최대한 따라가려고 해도 작업범위가 늘어나고 어디서 놓쳤는지 알기 어렵기 때문에, 해당 부분이 디자인 이슈로 이어질 수 있었다.
예를 들면 Text 컴포넌트의 title1이라는 요소가 titleTop이라는 요소로 바뀌는 breaking change가 생겼다고 하면, 이전 버전을 사용하면서 title1으로 작성된 부분은 컴포넌트 props이기 때문에 따로 에러가 발생하지 않아 놓칠 수 밖에 없고, IDE로 찾아서 전부 교체를 한다해도 병합 순서에 따라 남는 부분이 생기고 해당 요소가 안보이는 이슈가 발생할 수 있다. 이러한 부분을 감지하기 위해 아래와 같은 커스텀 린트 룰을 추가했다.
"rules": {
"no-restricted-syntax": [
"error",
{
"selector": "JSXElement[openingElement.name.name='Text'] JSXAttribute[name.name='title1']",
"message": "Text 컴포넌트에서 title1 속성은 더 이상 사용되지 않습니다. titleTop을 사용해주세요."
}
]
}내 작업 스타일 탓일까 디자인 시스템 팀에서 CLI를 제공해주시긴 했지만, 모든 게 한번에 바뀌면 변경점이 커서 오히려 감지 못하는 이슈가 많아지지 않을까 걱정이 되어, 한번에 변경하는 CLI 대신 필요한 부분들에 대한 변경점에 대한 린트룰을 추가하는 방식으로 작업해보았다. 약간 TDD 비슷하게 에러 상황 -> 코드 수정 -> 테스트 통과 방식으로 진행하는게 내 스타일에 더 잘 맞았고, 다행히 안정적이고 빠르게 마이그레이션 작업을 완료할 수 있었다. 다음에도 비슷한 마이그레이션 과정에서 사용할 수 있는 전략으로 생각되어 해당 전략을 챕터 위클리에 소개하기도 했다.
토스폼 내재화
토스에는 다양한 내부 제품들이 있다. 다양한 실험을 위한 튜바, 디자이너/개발자 모두의 편의를 위한 데우스, 운영을 위한 어드민 제품 등 조직 내부의 문제를 해결하기 위해, 생산성 향상을 위한 다양한 제품들이 있다. 현재 인컴은 이러한 제품들을 인컴 환경에 맞게 제공하기 위해 내재화하는 작업을 많이 진행중에 있다. 그중 이번달에는 토스폼으로 유저에게 설문조사를 위한 폼을 보내고 받은 응답을 어드민을 통해 볼 수 있게 해주는 서비스를 내재화하는 작업을 진행했다.
작업 자체는 토스폼을 담당해주시는 팀과 함께 협업하는 형식이어서 크게 어렵지는 않았지만, 코어와는 다른 회원 체계 등 인컴에 맞게 내재화를 위한 작업이 필요했다. 이 과정에서 데스크탑 제품이었던 홈페이지 작업과는 다르게 처음으로 모바일 제품으로서 신규 서비스 구현이 필요했다. 그래서 숨은 환급액 찾기 서비스에서 자주 사용하고 있는 유틸, 컴포넌트, 패키지들이 똑같이 필요하다는 점을 알게 되었고, 해당 유틸들을 공통 워크 스페이스로 정리해두면 앞으로 더 다양한 서비스들을 제공할 떄의 큰 효율을 만들 수 있겠다는 생각이 들었다.
이러한 개발 효율화에 대한 니즈는 자연스럽게 모노레포에 대해 관심이 생기게 되었고, 코어 프로젝트의 100개가 넘는 서비스를 서빙하기 위해 모노레포가 어떠한 구조를 이용하고 있는지, 그와 함께 이전에 간단하게 살펴봤던 패키지 매니저들의 역할은 어떻게 되는지 글을 작성하는 추석 연휴동안 공부해보고 정리해보려 한다.
표동모 v2 마이그레이션
표동모는 표준동의모듈의 줄임말로 토스폼과 같이 토스의 내부 제품 중 하나다. 토스에서 수집하는 다양한 동의문들에 대해 규격화한 제품으로 인컴 내 제품에도 새로운 패키지를 구현해서 적용해야 하는 순간이 왔다. 기존에는 오래된 레거시 패키지를 사용하고 있었지만 이번에 새로운 요구사항 (커스텀 로그, 새로운 버전의 UI) 대응을 위해 전체적으로 v2로 마이그레이션 작업을 진행했다.
작업 자체는 어렵지는 않지만 동료분께서 만들어주신 인컴 전용 표동모 패키지를 분석하고, 핵심 부분에 해당하는 코어 패키지들을 보면서 어떻게 적용하면 될지 파악하는 등 패키지간의 의존관계도 공부하고, 모노 레포로 구성된 패키지 구조에서 개발 환경에서 어떻게 패키지를 업데이트하고 해당 패키지를 반영될 때, 패키지 캐시가 남아 적용안되는 문제도 겪으면서 배움이 많았던 작업이었다.
아직 구버전 패키지 의존성이 남아있어서 완전히 정리하는 작업까지 10월중에 진행해보려 한다.
배포시 에러 급증 문제 해결하기
프론트 개발을 하면서 조금 이상한 에러가 찍히는 경우가 지속적으로 발생했다. unexpected token '<' 에러로 이상하게 배포하는 시점에 정말 많은 에러가 찍혀 센트리 error peak 알림으로 제보되고 있었다가 조금 시간이 지나면 급격하게 줄어들었다. 해당 이슈가 있다는 것을 인지한건 4개월 정도 되었지만, 배포시점에만 발생하는 이슈라 파악하기가 어려웠고, 자주 발생하는 이슈가 아니라는 점, 금세 에러가 줄어들기 때문에 우선순위를 뒤로해두었다.
하지만 노드 개발자분께서 특정시점에 트래픽이 쭉 빠지는 시점이 있는데 어떤 문제가 있는지 같이 봐줄 수 있는지 물어보셨고, 시점이 프론트 배포 시점이었다. 내가 생각했던 것보다 유저에게도 영향을 줄 수 있는 문제라는 점을 인지하게 된 순간이었다.
해당 문제를 파악하기 위해서는 먼저 인프라 구조와 Next의 빌드, 배포 과정을 이해해야 했다.
우리가 제공하는 웹 서비스는 결국 사용자의 브라우저에 다운로드 되는 HTML, CSS, JS 파일이다. 배포라는건 해당 파일들을 새롭게 만들어서 저장소에 업로드하는 작업이고 유저는 페이지를 이동하면서 필요한 파일들을 해당 저장소에 요청을 보내고 응답으로 받아서 보게 된다.
이때 중요한건 새롭게 배포될 빌드 결과물은 별도의 build id를 가진 이전 결과물과 다른 결과물이 된다는 점이다.
예를 들어 intro 페이지를 빌드한 결과물이 intro-1.js로 빌드가 되어서 배포된 상태에서, 새롭게 배포할때는 intro 페이지는 intro-2.js라는 다른 파일을 빌드과정에서 만들어서 배포되게 된다.
이러한 구조에서 유저가 이전 버전의 결과물을 보고 있다가 서비스를 이용하는 와중에 새로운 배포 결과물로 덮어씌워지는 상태가 된다면 어떻게 될까?
이전 빌드 결과물인 intro-1.js를 찾고 싶어도 intro-2.js로 바뀌어 있기 때문에 찾을 수 없어 404 에러가 발생하게 된다.
여기서 더 이상했던 점은 404가 에러가 아니라 unexpected token '<' 에러가 발생했던 점인데 해당 에러는 js을 요청했는데 HTML이 응답으로 받아지면서 발생했다는 것을 발견했다. 바뀐 서빙 주소에 요청을 보냈을 때 404 에러가 발생했지만 CloudFront에서 해당 404를 커스텀 에러 페이지와 함께 200으로 응답하게 되면서 발생했던 에러였다.
근본적인 문제는 이전 빌드 결과물이 덮어 씌워지면서 발생하는 에러였고, 해당 에러를 해결하기 위해서 정적 asset들은 CDN에 이전 빌드와 현재 빌드 모두 서빙하는 방식을 적용해 해결할 수 있었다. 커스텀 에러 페이지는 서비스 내에서 직접 구현하는게 맞다고 생각해 제거하게 되었다.
해당 이슈를 해결하면서 작게 봤던 이슈가 작지 않은 영향을 주고 있었던 점과 디버깅 과정에서 next build과정으로 만들어진 결과물을 서빙하는 인프라 구조 + 블루 그린 배포 전략에 따른 배포 방식 등을 이해할 수 있었는데 조금 더 자세한 내용은 별도 글로 정리해보려 한다.
어떻게 결제와 신고를 편하게 하도록 해줄 수 있을까
사일로 작업은 주로 결제 전환과 신고 전환율을 높이기 위한 작업들을 진행하고 있다. 이전에는 최대한 많은 맥락을 줌으로서 유저가 잘 이해하도록 돕는다면 요즘은 필요한 맥락만 남기고 최대한 퍼널을 정리하는 방향으로 작업이 진행되고 있다. 이러한 방향성이 개인적으로 세금이라는 어려운 맥락에 필요한 부분만 전달할 수 있게 정리함으로서 조금 더 유효하지 않을까라는 생각이 있다.
이에 따라 기존 결제 퍼널과 신고 퍼널간의 길었던 구간을 합쳐서 결제 직후 바로 신고가 되게 하거나, 순서를 바꾸는 등 기존과 달리 큰 퍼널의 변경 실험들을 진행하고 있다. 이에 따라 고려할 점은 많아지고 있지만 퍼널간 연결관계나 네비게이션 스택 관리 등 다양한 부분들을 고려하는 새로운 요구사항들을 고민해보는 기회가 되었다.
특히 주민번호 스크래핑을 추가해서 유저가 부양가족들의 정보를 보다 쉽게 가져올 수 있게 하는 실험과, 결제 구간내 공제 요약과 결제 요약을 합치는 실험은 기대가 되고 있다.
새로운 동료가 생겼어요
드디어 6개월 만에 새로운 동료분이 들어오셨다. 메이트는 다른 동료분께서 담당해주셨지만 같이 잘 적응하실 수 있게 도와드리고 싶었다. 새로운 분이 오신 게 처음이라서 그런지 많이... 어려움을 겪으시는 것 같았다. 최근 어떤 점이 어려운지 여쭤봤을 때 제품을 이해하기 어렵다는 피드백을 주셨다. 구체적으로는 어떤 페이지가 데우스의 어떤 화면에 해당하는지 등을 찾는데 많은 시간을 쓰고 계신다고 알려주셨다. 참고해서 구현할 만한 부분은 어디일지, 어떤 패키지들이 있는지 등 토스 개발 생태계 자체를 이해하는데 많은 어려움이 있으셨던 것 같다.
추석 직후에 또 다른 동료 두 분이 합류하시기로 되면서 갑자기 기존 2명에서 5명이 될 예정인 상태로 인해 걱정이 많다. 좋은 동료가 많아지는 건 너무 좋은데 우리는 그분들이 잘 적응하실 수 있게 준비가 되어 있는지 걱정이 되었다. 좀 더 제품 맥락을 많이 알고 있는 내가 문서화에 더 기여하기 위해 노력이 필요한데 아직 담당 업무를 하는 것에 많은 시간을 쏟고 있어서 챙기지 못하는 것 같다는 생각이 든다. 조금씩이라도 제품 한판 정리를 매일 작성해서 챕터 전체의 이해도를 높이기 위한 노력을 기울여보려 한다.
돌아보는 9월의 액션아이템과 10월 액션아이템
9월의 목표는 아래와 같았다.
- 디자인 시스템 최신화
- 인프라와 모노레포 구조 공부해보기
두가지 중에서 디자인 시스템 최신화 작업은 완료했지만, 인프라와 모노레포 구조는 문제를 해결하면서 조금씩 문제 해결을 위한 부분만 이해하고 깊이 있게 이해하지는 못했다. 앞으로 해당 부분의 중요성과 담당 업무가 조금씩 생기는 걸 고려했을 때 10월에 똑같이 가져가보려 한다. 추가로 7월부터 지속적으로 하겠다했지만 못했던 히스토리 문서화 작업이 정말 필요해졌다. 새로운 동료분이 더 좋은 퍼포먼스를 내실 수 있도록 책임감을 가지고 진행해보려 한다.
- 히스토리 문서화 하기
- 인프라와 모노레포 구조 공부해보기
9월은 내재화나 내부 제품들을 챙기는데 많은 작업을 진행했던 것 같다. 8월 회고에 작성했던 부분 처럼 단순 사일로 작업 뿐 아니라 점점 내가 할 수 있는 역량을 늘려가는 것 같다. 인프라도 모노레포도 기술적 성장도 조금씩 챙겨가고 있고, 사람적으로도 기술적으로도 새로운 부분들을 조금씩 맡고 도전할 때 내가 더 성장한다는 것을 느끼는 것 같다. 나는 익숙한 곳에 있는 것을, 컴포트 존에 있는 것을 싫어하는 건 아닐까란 생각이 많이 드는 요즘, 다음 달은 또 어떤 걸 해볼지 기대해본다.