프로젝트가 커지고 시간이 지날수록 그동안 잘 사용했던 기반 기술이 더 이상 최선의 선택이 아닌 순간이 와요. 이런 기술을 바꾸지 않고 방치하면 개발 측면에서는 빌드 시간 및 복잡도 증가, DX 하락 등 예측하기 어려운 여러 문제가 일어날 수 있어요. 개발 생산성이 떨어지고 제품 운영 및 개선의 발목을 잡기도 하고요.그렇지만 제품을 안정적으로 운영하면서 기반 기술을 마이그레이션하기 또한 쉽지 않은데요. 오늘은 제가 속한 토스의 TUBA 팀에서는 이런 문제를 어떻게 해결했는지 소개드릴게요.TUBA(Toss User Behavior Analyzer)는 2018년에 출시된 토스 임직원용 종합 데이터 솔루션이에요. TUBA에는 A/B 테스트, 메세지, 유저 세그먼트 등 총 22개의 하위 제품이 있어요. PO, PM, 디자이너, 개발자 외에도 Account Manager와 같은 비즈니스 직군, Customer Hero와 같은 고객 응대 직군까지 다양한 임직원이 매일 업무를 위해 사용하는 제품이에요!하지만 오래되고 큰 프로젝트인 만큼 TUBA에 여러 문제가 발생했는데요.첫 번째로는 빌드 속도가 매우 느려졌어요. TUBA는 yarn workspace를 활용해서 아래와 같이 하위 서비스와 공통 모듈을 나누어 관리하고 있는데요.각 패키지가 의 패키지를 사용하고 있어요.문제는 에 있는 공통 코드를 수정하면 전체 프로젝트 코드의 최신화가 필요했어요. 그렇기 때문에 작은 코드 수정이 있어도 하위에 있는 22개의 서비스를 모두 새로 빌드해서 배포해야 됐죠.너무 많은 프로젝트를 동시에 빌드하다보니 메모리 이슈로 빌드가 실패하기 시작했어요. 우선 급한 빌드를 내보내야 하니 동시에 1개만 빌드되도록 변경했는데요. 무려 빌드 타임이 2시간 15분으로 나왔어요.느린 빌드 타임의 원인을 파악해 본 결과, next 12에서 Module Federation과 함께 SSG로 빌드하면 SWC를 적용하더라도 빌드 속도와 메모리 사용량이 이상적으로 높다는 것을 발견했어요.마침 이전부터 next의 필요성에 대해서 팀원들과 논의를 했었는데요. 아래와 같이 의견이 모아져서 next의 장점보다 단점이 더 크다는 결론이 났고, next에서 webpack으로 마이그레이션을 시작했어요.• None TUBA는 내부 임직원 전용 서비스이기 때문에 SSR 등으로 첫 로딩 속도를 줄여도 이점이 크지 않다.• None 대부분의 next 기능을 사용하고 있지 않고, SSG 빌드용 도구처럼 사용되고 있다.하지만 막상 next를 제거하려고 보니 프로젝트 전반적으로 next를 사용하는 코드가 많았고, 무엇보다 공통 코드에서 사용되다 보니 점진적 마이그레이션을 하기 어려웠어요. 그래서 next-polyfill이라는 대체 구현 패키지를 만들어서 next에서 사용하고 있는 인터페이스를 최대한 비슷하게 구현했어요. Next 패키지를 사용하지 않아도 대체 구현 패키지를 통해서 필요한 기능을 코드에 쓸 수 있게 된거죠.위의 가 가장 간결하고 좋은 예시인데요. , 등 TUBA 프로젝트에서 사용하는 모든 컴포넌트 및 hook

올해 DEVOCEAN을 통해서 스터디를 진행했습니다.제가 준비한 주제는 React를 활용해서 크로스플랫폼을 플랫폼 어플리캐이션을 만드는 React Native입니다!이번주는 12주차, 마지막주에 진행한 스터디 내용을 다루는 포스팅 입니다!스터디시간에 다들 다음주는 뭐할지 궁금해하던 마지막 아이스브레이킹 입니다.이번시간에는 LJia님께서 준비해주신 마피아게임으로, 마지막 아이스브레이킹을 진행 했습니다.아쉬운 마지막 아이스브레이킹을 뒤로하고, 이번주에 배운 내용을 살펴봅니다.이번주역시 React이외에 라이브러리를 사용해서 React Native App을 보다 효율적으로 활용하는 방법에 대해서 다룹니다.App의 전역 상태관리를 할 수 있는 Recoil에 대해서 알아보도록 하겠습니다Recoil의 경우 atom이라고 하는 method를 통해서 createstate와 비슷한 동작을, useRecoilState를 통해서 useState와 비슷한 인터페이스를 제공합니다.보시면 알겠지만 Recoil은 React Hook과 굉장히 유사한 사용경험을 가지고 있습니다.Recoil을 다른 컴포넌트에서 접근시키기 위해서는 RecoilRoot를 사용합니다.이 패턴 역시 ContextAPI 혹은 Redux와 유사한 것을 볼 수가 있습니다.이때 전역 State는 하나의 값이 아니라, 여러값을 관리하겠죠?이때 Recoil같은 경우 다수의값을 을 선택적으로 접근하게 할 수 있는 라고하는 method를 제공합니다.Redux와 유사하지만, 보시는것처럼 좀더 편리한 인터페이스를 제공하는 것을 볼 수 있습니다.하지만 이미 Context API의 UX 편리해진 시점에서, 크게 사용의 필요성이 느껴지진 않네요.여기까지 React Native를 다루는 기술 책에서 핵심 내용들만 추려보았습니다!이번주는 12주동안 진행한 스터디 + 조별과제의 마지막 시간 입니다.처음에 진행 방법을 조정하는데 어려움이 있던것을 생각하면, 다행히 중도하차인원 없이 모든 스터디원분들이 마지막까지 열심히 달려주셨습니다.1조는 식테크(식물 제테크)를 주제로한 싱그럼 이라는 App으로 과제를 마무리 했습니다.1조의 경우 아이디에이션이 오래 걸렸고, 실제 코드로 구현하기 시작한 시간이 늦은 편 이었습니다.그래서 와이어프래임 수준에서 App을 구현하였습니다.특이사항으로는 공공데이터를 사용해서 App에 적용했고, 이 결과를 모두같이 확인할 수가 있었습니다.자료를 보시면 알겠지만, App의 상세화면 설계는 충분히 되었지만프로젝트의 설계 대비 시간의 부족으로 아쉬움이 남은 프로젝트 입니다.2조의 경우, 득근득근이라는 주제로 운동 루틴을 관리할 수 있는 App 프로젝트를 진행 했습니다.2조의 경우 지난 식단, 운동관리 어플리캐이션에 더불어서 카카오지도 API를 접목해서 주변 헬스장정보를 찾을수 있게 하려했습니다.2조같은 경우 Nested Conext API, Nested Router가 되었을 때 발생한 문제점들에 대해서 공유하는 시간이 있었습니다Nested구조가 될 경우, Hook을 사용해서 router, Context에

안녕하세요! 요기요 R&D Center의 FE Developer 변동혁입니다.이 글에서는 Recoil의 장단점과 함께 효과적으로 상태관리 할 수 있는 방법을 소개하려고 합니다.Recoil은 무엇인가요?Recoil은 2020년에 Facebook에서 발표하였으며, React의 Concurrent Renderer를 공식 지원하는 유일한 상태 관리 라이브러리입니다.상태관리에서 상태는 일반적인 데이터가 아닌 UI를 업데이트 하는 데이터입니다. 예를 들면 React의 useState hook이 반환하는 데이터가 있습니다.React만으로는 복잡한 상태관리가 어려우므로 보통은 별도의 라이브러리를 사용합니다.대표적으로 Flux 패턴의 구현체인 Redux, Mobx 등이 있습니다.상태관리 라이브러리들은 컴포넌트 트리에서 거리가 먼 컴포넌트 간에 공유하는 상태(전역 상태)를 비교적 손쉽고 안정적으로 관리하게 해줍니다.Flux 패턴의 Action → Dispatcher → Store → View의 단방향 전역 상태 흐름은 예측 가능한 상태관리를 가능하게 했습니다.근데 이 말이 완전히 사실은 아닙니다. “손쉽게 상태를 관리할 수 있다”라고 말씀드렸지만, Redux는 사실 손쉽게 사용할 수 있는 라이브러리는 아닙니다.RTK(Redux Toolkit)가 출시되어 사용하기 비교적 쉬워졌지만 상태를 업데이트하거나 구독하기 위해 여전히 boilerplate 코드가 많이 사용됩니다.그렇다면 조금 더 간편하게 전역 상태를 관리하는 다른 방법은 없을까요?Recoil을 사용하면 손쉽고 빠르게 전역 상태를 관리하여 웹사이트를 개발할 수 있습니다.Recoil vs 다른 상태관리 방법React useState상태를 공유해 주는 부모 컴포넌트에서 prop drilling을 하는 방법은 많이 해보셨겠지만 불편합니다.하나의 공통 prop이 변경될 때마다 re-rendering 해야 하므로 많은 양의 데이터는 처리할 수 없습니다.React useContext각 상태는 Context Provider가 필요한데, 상태가 1000개라면 1000개의 Provider를 선언해야 합니다. (Wrapper 지옥…)→ Recoil 은 Atom을 동적으로 생성할 수 있습니다.상태가 변경될 때마다 캐싱 없이 매번 re-rendering 합니다.Redux전역 상태를 수정하기 위해서는 반드시 액션을 선언해서 수행해야 하므로 데이터의 흐름을 좀 더 쉽게 예측 가능합니다.좋은 개발자 도구가 있어서 문제가 생긴 경우 빠르게 어느 시점에 무슨 컴포넌트가 어떤 데이터를 변경하는지 확인할 수 있습니다.RTK(Redux Tool Kit)를 사용하면 Reducer를 통한 데이터 업데이트시 RTK가 Immer를 사용하여 불변성을 지켜줍니다.초기 구축, 유지 보수 과정에서 boilerplate 코드를 많이 작성해야 합니다.React concurrent renderer를 지원하지 않습니다.Recoil이 해결하는 문제: 손쉬운 전역 상태관리Recoil의 상태를 구독, 업데이트하는 API는 정말 간단하고 안정적입니다.Recoil에서

“이 문서가 Recoil 전환작업을 하며 고민하는 어느 무명 개발자의 검색에 잡혀 도움이 되길 바랍니다.”고민하는 개발자의 사진, Photo by stable diffusion AI예약 사업주향 서비스 Recoil 전환 배경네이버 예약 사업주향 서비스에선 상태 관리 라이브러리로 Redux를 사용하고 있었는데 워낙 오래된 코드라 class component와 결합된 Redux 코드의 learning curve가 높아 신규로 합류하게 된 분들이 어려움을 겪고 있었습니다. 그리고 오래되고 deprecated 된 코드라 이것을 hook 스타일로 리팩토링 할 지, 아예 Recoil로 전환을 해야할지 결정을 해야했고 검토 결과 아래와 같은 이유로 Recoil 전환을 결정 했습니다.Redux도 useSelector / useDispatch로 hook 스타일로 전환은 가능한데 Recoil로 전환하는 것과 비슷한 정도의 개발 공수가 소요됨.비동기 처리를 위해 Redux saga / thunk를 추가 도입해야 하는데 Recoil은 라이브러리 하나로 이미 동일한 기능을 제공.같은 처리를 할 때 Recoil의 코드량이 좀 더 적고 배우기 쉬움.오래된 코드가 많았고 Redux를 전역적으로 사용하는 부분이 많아 Recoil로 그대로 전환하기에 어려운 부분이 좀 있었는데요. 어려웠던 부분과 그 해결 과정들을 정리하여 공유해 드리고자 이 문서를 작성했습니다.Recoil을 처음 적용해 본 부분이라 미흡한 부분이 있을수도 있어 코멘트 남겨주시면 감사하겠습니다.일부 예제 코드에 typescript에서 금기시하는 any가 포함되어 있는데 내부 코드를 pseudo-code로 바꿔서 기술하다보니 너그러이 봐주시기 바랍니다.Recoil 전환 과정중에 발생한 troubleshooting이전 문단에서 말씀드린 것처럼 예약 사업주향 서비스의Redux가 워낙 오래된 코드라 Recoil로 리팩토링하며 애먹은 부분이 몇 가지 있었는데 recoil에서 제공하는 몇 가지 feature를 이용하여 해결한 좋은 사례들이 있어 이 부분을 공유하려 합니다. Recoil 개발 레퍼런스는 이미 잘 번역이 되어있어 학습 자체는 하기 쉬운데 응용 사례는 stackoverflow에서도 찾아보기가 쉽지 않은 부분들이 많아 향후 Redux에서 Recoil로 전환을 고려하시는 분들에게 이 예제가 많은 도움이 될 것입니다.Class component에 대한 Recoil props 지원 사례예약 사업주향 서비스 legacy 코드에는 class component도 상당수 있어서 대응을 해야 했습니다. Recoil은 hook을 통해서만 사용이 가능하므로 class component에서 Recoil을 사용하려면 아래 예시 코드처럼 wrapper를 구현해서 써야합니다.Recoil atomFamily를 사용한 MiniModal, Modal 에서 atom이 공유 안되는 이슈 대응 사례기존 코드에선 모달을 띄우고 닫는 방식으로 appendChild, removeChild을 사용하다 보니 RecoilRoot에 있는 값이 앱과 모달