세상에는 정말 다양한 형태의 조직이 있다. 나도 많은 조직을 겪어보진 못했지만, 막연히 ‘이런 조직에 소속되어 있으면 좋겠다’ 는 생각으로 이직을 했고, 그렇게 지금 있는 회사에서 계속 일을 하고 있는 것이다.
강남언니를 서비스하는 힐링페이퍼는 종종 소문으로만 ‘괜찮은 조직이다’, ‘조직원들의 실력이 뛰어나다’ 는 이야기를 들었다. 그러다 회사 슬랙에 공유된 글을 통해 이 조직은 어떻게 일하는지 배울 수 있는 기회를 얻게 되었다.
‘최고의 직자은 탁월한 동료들과 함께 일할 기회가 주어지는 곳이다’ 라는 말은 지당하다고 생각하는데, 그 탁월한 동료들과 함께 일하면서 시너지를 어떻게 끌어올릴 수 있을지 궁금했던 적이 많았다. 내 주변 동료들도 탁월한 사람들이지만 그 사람들과 같이 성장해나간다는 느낌을 잘 받지 못하고 있었기 때문이다. 그래도 환경이 잘 주어진다면 서로를 존중하고 서로를 통해 발전할 수 있다는 듯 하다.
조금씩이지만 분명하게 더 좋은 방향으로 변화를 추구하는 조직이라는 점도 강조했다. 조직은 하나의 유기체와 같아서, 언제나 같은 형태를 유지하진 않는다. 그렇다면 더 좋은 방향으로 변화를 추구하는 것이 옳은 전략일 것이다.
CSS(Continue, Stop & Start)라는 방식의 구성원 사이에 피드백을 주고받는 제도도 흥미로웠다. 가끔은 최소 1년에 한번 최소한 같은 팀의 구성원들끼리 피어 리뷰를 하는 시간을 가질 수 있다면 좋겠다고 생각했는데, 훨씬 자주 서로 의미 있는 피드백을 주고받는다는 것이다.
회사 조직 개편(하지만 내가 가까이 일해야 하는 우리 팀 구성원 자체는 거의 바뀌지 않았다) 이후, 새로운 팀으로 일할 때 어떤 방식으로 우리가 효율적으로 일해야 하나 같이 고민을 해 보았다. 그러던 와중에 이런 글을 추천받아서 읽게 되었는데, 스크럼을 도입하고 활용하게 된 이야기부터 회고를 통한 통찰이 잘 배들어 읽기 좋았다.
덤으로 연결되어 있는 글도 읽어보았다. 글 내용이 GraphQL 도입기인데 ‘언제 나도 GraphQL을 도입해보나’ 라는 생각보단, 업무에서 발생하는 다양한 문제 해결 과정을 이렇게 글로 만들어 공유하는 모습에 주목했다. 나도 이미 매일 작성하는 나만의 업무일지로 기록을 하고 있음에도 불구하고 이 글처럼 내용을 갈무리하여 공유하는 일은 거의 하지 않았다는 생각이 들었다.
물론 모든 사람(개발자 등)이 이런 방식으로 자신의 삽질 과정을 기록하고, 회고하고, 공개하며 발전하기 위한 노력을 하기는 어렵다. 그러므로 이런 글을 작성하고 공유해주시는 분들을 존경한다.
덕분에 누구나 볼 수 있도록 공유하기 위한 목적이 아니어도, 최소한 자기 자신을 위한 기록 및 회고 습관을 더 잘 형성해야겠다고 느끼는 계기를 얻었다.
페이지별로 집중화된 mobx-state-tree 스토어를 운용하는 식으로 프로젝트를 꾸리고 있지만, 장기적인 관점에서 useSWR 혹은 react-query 같은 라이브러리의 방법론을 통해 서버와의 데이터를 동기화하는게 훨씬 효율적이라고 느끼고 있었다. 당장 적용하기에 먼 산처럼 느껴지고 있었지만.
2편까지 있는 이 글은 현재까지 주로 사용되어왔던 Redux, MobX 등을 활용한 상태관리법에서 한 단계 나아가 useSWR 을 어떻게 서버와의 데이터 동기화에 활용할 수 있고, 로컬 상태관리 도구로도 사용할 수 있는지 좋은 예시와 함께 안내한다.
리액트로 SPA를 만든다고 하면 가장 유명한 보일러플레이트가 리액트 팀에서 공식으로 제공하는 create-react-app (CRA)일 것이다. CRA는 많은 편의기능을 제공하긴 하지만 확장성이 좀 부족하고 전반적으로 무겁다는 단점이 있다.
확장성 부족이야 craco 같은 솔루션을 사용하여 커버할 수 있지만, CRA의 버전 자체가 올라가면 대응하는데 간극이 생길 수도 있고, 정말로 높은 수준의 확장성을 필요로 하는 경우에는 맞지 않는다고 느낀다. 또한 2년정도 프로젝트를 확장시켜오면서 크고 작게 ‘느리다’ 라는 인상을 받고 있었다.
위 글은 CRA를 Next.js CLI로 마이그레이션 하는 안내이다. 하나 특징이 있다면, SPA도 Next.js로 마이그레이션할 수 있다는 것이다. 보통 Next.js 는 SSR(Server Side Rendering) 혹은 SSG(Static Site Generation) 용도로 쓰게 되는데, 몇 가지 설정을 통해 SPA에서도 사용할 수 있도록 만들 수 있다고 한다.
특히 현재 SPA로 앱을 만들고 있고 장기적인 관점에서 SSR 도입을 고려하고 있다면 미리 옮겨두어서 나쁠 것은 전혀 없겠다는 생각이 들었다.
react-query 라는게 있다는 것을 알게 되고, 이게 내가 지금까지 리액트 애플리케이션을 설계할 때의 생각을 송두리째 바꾸어야 한다는 것까지는 가볍게 인지하고 있었다. 그러나 대체 이 라이브러리 혹은 패러다임을 어떻게 인지하고 접근해야할까 더 정보를 알아보기 위해 문서를 찾아보니, 공식 문서에 바로 소개 영상이 있었다.
자세한 내용은 영상을 참고하는것이 좋고, (이미 영상 내용은 한번 정리를 하여 팀 내부에서 발표를 한 적이 있으니 의욕이 생긴다면 블로그에 포스팅을 할 수도 있을 것이다.)
핵심은 서버에서 가져오는 ‘서버 캐시’ 에 가까운 상태와 UI 상태는 구분이 되어야하고, 리액트의 상태만으로는 그 서버 캐시를 깔끔하게 다루기 어렵다는 것이다. 커스텀 훅을 통해 그 다루기 어려운 서버 상태를 컴포넌트 사이에 적절히 동기화하는 과정을 이 영상에서 단계별로 보여준 뒤에 최종 완성본에 가까운 react-query 적용부분을 보여주는 형태로 되어있다.
아래의 저장소에서 커밋 단위로 따라가다보면 어떤식으로 그 커스텀 훅이 만들어지게 되는지 살펴볼 수 있다. 꽤 흥미롭다.