mirabo01 님의 블로그

React에서 전역 상태를 관리할 때 보통 세 가지 선택지가 있습니다.Context API, Redux, 그리고 최근 많이 쓰이는 Zustand.그중에서도 Zustand는 “단순함”으로 승부하는 라이브러리입니다.처음 Zustand를 접했을 땐,‘이게 전역 상태 관리라고 할 수 있나?’ 싶을 정도로 코드가 간단했습니다.하지만 몇 번 프로젝트에 적용해보니,이 단순함이 얼마나 강력한 장점인지 알게 됐습니다.왜 Zustand인가Context API는 좋은 도구지만,컴포넌트 트리 깊숙이 들어간 상태를 자주 갱신할 때 성능 문제가 생길 수 있습니다.Redux는 기능은 강력하지만 설정이 복잡하고 코드가 장황해지기 쉽죠.Zustand는 그 중간 지점에 서 있습니다.가볍고 빠르며, 보일러플레이트 코드가 거의 없습니다.설..

React 18이 나오면서 가장 크게 달라진 개념 중 하나가 바로 **비동기 렌더링(Concurrent Rendering)**입니다.이전까지는 데이터가 오기 전까지 화면이 멈추는 게 당연했는데,이제는 React가 렌더링 중에도 다른 작업을 병렬로 처리하면서더 부드럽고 자연스러운 사용자 경험을 만들 수 있게 됐죠.그 중심에는 Suspense와 Error Boundary라는 두 가지 기능이 있습니다.이 둘은 단순히 로딩 스피너를 보여주는 역할을 넘어서,React 애플리케이션의 “안정성과 부드러움”을 책임지는 핵심 기술입니다.Suspense, 그동안 몰랐던 진짜 역할Suspense를 처음 봤을 때는 단순히“데이터 로딩 중일 때 대체 화면을 보여주는 도구” 정도로만 생각했습니다.하지만 실제로 써보면 그 이상의 ..

React 프로젝트를 하다 보면 ‘데이터를 언제, 얼마나 자주 불러와야 하는가’가 늘 고민거리입니다.단순히 한두 번의 요청이라면 신경 쓰지 않아도 되지만,규모가 커질수록 같은 데이터를 반복해서 요청하게 되고,API 트래픽이 급격히 늘어나면서 성능 저하가 일어납니다.저는 이런 문제를 React Query를 통해 해결했습니다.이 라이브러리를 처음 접했을 땐 단순히 useQuery로 API를 감싸는 정도로만 썼지만,이후 실무에서 본격적으로 캐싱 전략을 세워보니 정말 다른 세상이 열리더군요.캐싱을 ‘잘’ 한다는 건 결국 타이밍의 문제입니다React Query의 핵심은 “데이터를 다시 불러올 타이밍을 제어한다”는 점입니다.즉, 같은 데이터를 언제 새로 요청하고, 언제 캐시에서 꺼내 쓸지 결정하는 게 핵심입니다.처..

최근에 작업했던 서비스에서 로그인 유지 기능을 안정적으로 구현해야 하는 일이 있었습니다.그전까진 단순히 access token만으로 인증을 처리했는데, 며칠 지나면 사용자들이 “갑자기 로그아웃돼요”라고 제보하기 시작하더군요.처음엔 단순한 버그겠거니 했는데, 알고 보니 토큰 만료 로직과 세션 관리 구조가 제각각이라 발생한 문제였습니다.그 일을 계기로 React에서 Refresh Token 기반의 인증 흐름을 체계적으로 설계하는 법을 정리하게 되었습니다.로그인 유지 구조를 단순히 생각했던 시절초기엔 정말 단순하게 만들었습니다.백엔드에서 access token을 발급받으면 localStorage에 저장하고,Axios 요청 시마다 헤더에 붙이는 방식이었습니다.이 구조의 문제는, access token이 만료되면..

프로젝트를 하다 보면, 의도치 않게 에러가 터지고 그게 UI까지 그대로 드러나는 경우가 있습니다. 예전엔 콘솔에 찍힌 에러 메시지만 보고 해결하려고 했는데, 서비스 규모가 커지면서 그런 방식이 통하지 않게 됐습니다. 에러가 한 군데서만 나는 게 아니라, API 요청, 렌더링, 상태 관리, 네트워크 등 여러 지점에서 터지기 시작하니까요.그래서 이번에는 제가 최근에 적용했던 “전역 에러 처리”와 “Axios 인터셉터 기반 인증 흐름 관리” 방법을 정리해보려 합니다. 단순히 개념 설명이 아니라, 실제 서비스에 적용하면서 얻은 시행착오 중심으로 이야기해보겠습니다.화면이 멈추지 않게 만드는 첫 번째 장치리액트를 쓰다 보면, 한 컴포넌트에서 에러가 나면 그 아래 트리 전체가 렌더링되지 않는 경우가 있습니다. 화면이..