mirabo01 님의 블로그

리액트를 좀 써보다 보면, ‘렌더링이 왜 이렇게 자주 일어나지?’ 혹은 ‘이 함수가 왜 또 호출되지?’ 같은 궁금증이 생깁니다.이건 단순히 코드의 문제가 아니라 React의 렌더링 메커니즘을 제대로 이해하지 못해서 생기는 자연스러운 현상입니다.이번 글에서는 React 내부의 렌더링 구조를 실제 동작 흐름 중심으로 풀어보겠습니다.React의 렌더링 사이클이란React는 UI를 함수처럼 다룹니다.“상태(state)가 바뀌면 함수가 다시 실행되고, 그 결과를 UI로 보여주는 구조”입니다.이 과정을 크게 세 단계로 나누면 다음과 같습니다.렌더(Render)컴포넌트 함수가 다시 실행되어 React Element 트리를 새로 만듭니다.커밋(Commit)새로 만들어진 React Element를 실제 DOM에 반영합니..

React를 조금이라도 써봤다면 “리렌더링”이라는 단어를 수도 없이 들었을 겁니다.리렌더링은 React의 핵심 동작이자, 동시에 가장 큰 성능 병목이 되기도 합니다.이번 글에서는 실제 프로젝트에서 리렌더링 때문에 성능이 떨어졌던 경험을 바탕으로,그 원인을 어떻게 파악하고 최적화했는지 정리했습니다.성능이 떨어지는 진짜 이유React는 상태(state)나 props가 변경되면 컴포넌트를 다시 렌더링합니다.이건 의도된 동작이지만, 규모가 커지면 불필요한 렌더링이 눈덩이처럼 불어납니다.예를 들어 이런 상황을 본 적 있을 겁니다.하나의 상위 컴포넌트가 있고, 그 안에 수십 개의 하위 컴포넌트가 있는 구조에서상태가 변경되면, 전혀 관련 없는 하위 컴포넌트들까지 모두 다시 그려지는 현상 말이죠.제가 실제로 작업하던 ..

프로젝트가 커질수록 “상태”는 점점 복잡해집니다.서버에서 가져온 데이터도 있고, 클라이언트 내부에서만 쓰는 상태도 있죠.문제는 이 둘을 한데 섞어버리면 유지보수가 어려워진다는 겁니다.그래서 저는 요즘 대부분의 프로젝트에서React Query + Zustand 조합을 기본 구조로 사용합니다.서버 상태는 React Query가, 클라이언트 상태는 Zustand가 관리하게 분리하는 방식입니다.두 라이브러리는 서로 간섭하지 않으면서, 필요한 시점에 자연스럽게 연결됩니다.React Query는 “서버 상태 관리자”React Query는 서버와 관련된 모든 데이터를 담당합니다.API 요청, 캐싱, 리패치, 에러 처리 같은 서버 중심의 상태를 자동으로 관리해주죠.예를 들어, 게시글 목록을 불러온다고 가정해봅시다.im..

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 인터셉터 기반 인증 흐름 관리” 방법을 정리해보려 합니다. 단순히 개념 설명이 아니라, 실제 서비스에 적용하면서 얻은 시행착오 중심으로 이야기해보겠습니다.화면이 멈추지 않게 만드는 첫 번째 장치리액트를 쓰다 보면, 한 컴포넌트에서 에러가 나면 그 아래 트리 전체가 렌더링되지 않는 경우가 있습니다. 화면이..

1. 왜 라우터와 React Query를 함께 고려해야 할까React Router는 페이지 간의 UI 전환을 담당하고,React Query는 각 페이지의 데이터 로딩과 캐싱을 담당합니다.이 두 가지를 잘 결합하면페이지를 이동할 때마다 새로 데이터를 불러오지 않아도 되고,사용자는 즉각적인 반응성을 느낄 수 있습니다.예를 들어대시보드 → 설정 → 통계 페이지로 이동하더라도이미 캐시에 있는 데이터를 재활용하면 로딩 없이 전환이 가능합니다.2. 예제 시나리오이번 예제는 다음 구조를 가정합니다./dashboard ├── /stats ├── /notifications └── /settings각 페이지는 서버로부터 데이터를 받아오며,React Query를 통해 캐시 관리가 이루어집니다.3. React Query 전역..

1. SPA에서 라우팅이 필요한 이유React는 기본적으로 단일 페이지 애플리케이션(SPA) 구조를 따릅니다.즉, 화면 이동 시 실제로 페이지가 새로고침되지 않고컴포넌트의 전환만 이루어집니다.하지만 대시보드나 관리자 페이지처럼여러 화면(예: 통계, 알림, 설정 등)을 구성할 때는각 화면을 독립된 “페이지 단위”로 나누는 것이 훨씬 효율적입니다.이를 가능하게 해주는 것이 바로 React Router입니다.2. React Router 설치 및 기본 설정먼저 패키지를 설치합니다.npm install react-router-dom그다음 프로젝트의 루트에서 BrowserRouter를 적용합니다.// index.jsimport { BrowserRouter } from 'react-router-dom';import ..