Before read
회사에서 일을 하다 보면, 이런 저런 이유들로 인해 생산성이 저하되는 경우가 많습니다.
개선 비용이 만만치 않아 미뤄두는 일이 많은데, 어느 순간 투입되는 리소스에 대비해 임팩트가 적은 (즉, 임계점을 넘은) 일이 되어버리곤 합니다. 이런 비효율적인 일들을 없애는것이 결과적으로는 생산성을 크게 향상시킨다고 생각합니다.
이런식으로 개발 조직에서 관성적으로 사용하고있어 남아있는 기술 부채들을 해결하고, 생산성을 올리는 일을 좋아하는데요.
저희 팀에서 있었던 Redux → RQ 마이그레이션 후기를 공유드리고자 합니다.
Legacy
Web-desk 유저챗 화면
저는 채널톡의 WebDesk 팀에서 일하고 있는데요. Desk는 채널톡을 사용하는 고객사의 매니저들이 이용하는 팀 챗, 매니저와 고객이 대화하는 유저챗 등의 서비스를 제공하는 도구입니다.
채널톡의 초기부터 존재하던 제품이다 보니, 오래된 기술 스택을 사용하고 있었습니다.
따라서 지금 시점에 와서는 비효율적으로 보이는 여러 문제들이 존재했고, 팀 내에서 이를 개선하고자 하는 목소리가 생기기 시작했습니다.
Initializer
WebDesk에는 Initializer라는 컴포넌트가 존재합니다
이 컴포넌트는 하위 라우팅에서 필요한 API response들을 라우팅 전에 미리 fetch하여 loading 없이 페이지를 렌더링 하도록 도와줍니다
문제는 Initializer 하위 라우팅과 도메인들이 많아지면서 모든 API를 fetching하는데 많은 비용이 발생하기 시작했고, 내가 방문하지 않을 페이지의 API까지 가져오면서 불필요한 request time이 발생하게 되었습니다
Redux-Saga
Saga를 사용하여 코드를 작성할 때, 불편한 점이 몇 가지 존재했습니다
1.
action의 naming convention으로 인해서 타입 추론이 자동으로 되지 않는다
2.
API call 하나를 위해서 action, success, error 케이스에 대한 boilderplate 문법이 비대하다는 점
3.
Suspense와 Errorboundary 기반으로 코드를 작성하고 유지하기 어렵다는 점
개선하기
마이그레이션 작업의 첫 시작은 팀원들의 의견을 듣는것 으로부터 시작됩니다
어떤 점이 불편한가요?
우선 현재 불편하거나 비효율적으로 동작하는 점들이 무엇인지 리스트를 작성하여 정리해 보기로 하였습니다
페이지에 필요 없는 API call이 발생해요 (initializer)
API req,res의 타입을 추론하기 힘들어요 (action)
코드를 작성하는데 boilerplate가 너무 많이 필요해요
Suspense,Errorboundary를 이용하고 싶어요
불편한 점을 해결해줄 수 있는 기술이 있나요?
작년에 마이그레이션 논의하던 Redux-toolkit으로 가면 어떨까요?
React-Query를 사용하면 어떨까요 등 다양한 의견들이 존재했습니다
결국 여기서 RQ를 선택하게 되었는데요. 이유는 다음과 같았습니다
1.
Redux-toolkit에 비교하자면, Redux에 종속적이지 않아서 나중에 다른 도구도 넘어가더라도 부담이 적다
2.
안그래도 기존의 Redux 대신 Jotai나 Justand와 같은 상태 관리 라이브러리로 넘어가고자 하는 니즈가 있다
3.
비교적 최신에 등장한 도구이며, 많은 이기를 얻고 있어 레퍼런스가 많고 커뮤니티가 활발하다
4.
타입 추론이 쉽고, 적재 적소에 호출할 수 있는 방식을 통해 컴포넌트 작성을 유연하게 할 수 있도록 도와준다
5.
기본적으로 캐싱이 적용되어 로딩 없는 좋은 UX를 제공할 수 있다. 그리고 이를 컨트롤 하는 방식이 간단하다
기술을 적용함에 있어, 우리 도메인에 걸리는 제약 사항은 없나요?
이 부분을 산정하는데에 어려움이 있었는데요, 워낙 프로젝트의 크기가 방대하며 테스트 코드가 존재하지 않는 환경이다 보니 마이그레이션 작업에 사이드 이펙트가 발생하지 않을까 하는 부담을 안게 되었습니다
따라서 현 시점에서 이 부분을 제대로 마이그레이션 하는 방법은
1.
점진적 마이그레이션을 진행한다
2.
CRUD가 적거나 쉬운 도메인부터 작업한다
3.
오류가 발생하더라도 고객에게 이슈가 될 확률이 낮은 기능부터 작업한다
의 원칙을 세우고 진행하게 되었습니다
Summary
여러 부분에서 향상이 있었다고 판단되는 작업이었습니다
코드를 작성하는 사람의 입장에서는 가독성과 타입 추론이 명확해지는 부분이 좋았구요
성능적 측면에서도 initializer 구조를 버리니, 전체 1200개의 API중 300여개가 마이그레이션 되었음을 확인할 수 있었습니다 (post, put, delete가 포함되긴 했지만)
Improvements
단순히 RQ 마이그레이션 작업만 진행된건 아니었어요
앞으로의 개선 작업에서 지표를 확인하고 싶었기에 lhci 서버를 구축하여 성능 점수를 확인하기 시작했구요
turborepo 환경 구축으로 CI나 build time을 개선하는 작업도 진행되었습니다
아직은 부끄러운 점수
채널팀에는 해결해야 할 문제들이 많습니다
요새는 생산성을 챙기기 위해서, 우리가 일 하는 방식을 어떻게 바꿔야 할 까 고민이 많습니다
채널팀에 관심이 있으시다면 언제든 티타임을 요청주셔도 좋구요, 아래에서 채용 공고를 확인해보실 수 있습니다
