React

2026년 현재 React 생태계의 압도적 주류는 함수형 컴포넌트입니다. 하지만 Error Boundary는 단 하나의 예외로 남아 있습니다. React 공식 문서는 이 이유를 명확하게 설명합니다. Error Boundary를 구현하려면 getDerivedStateFromError 또는 componentDidCatch 를 정의해야 하는데, 이 두 메서드는

React 17까지의 렌더링은 동기(Synchronous) 방식이었습니다. setState 가 호출되면 React는 컴포넌트 트리를 재귀적으로 순회하며 렌더링을 완료할 때까지 메인 스레드를 점유했습니다. 10ms가 걸리든 300ms가 걸리든 그 작업은 중단될 수 없었습니다.

전통적인 Single Page Application(SPA) 아키텍처에서는 브라우저가 빈 HTML을 받은 뒤, 클라이언트 사이드에서 모든 JavaScript 번들을 다운로드하고 실행하여 화면을 그렸습니다. 하지만 애플리케이션이 복잡해질수록 번들 크기는 기하급수적으로 커졌고, 초기 로딩 속도(TTI, Time To Interactive)의 저하, 불안정한 S

Zustand의 가장 큰 미덕은 단순함(Simplicity) 입니다. Flux 패턴을 따르면서도 Redux처럼 Action, Reducer, Dispatcher, Selector를 분리해서 작성할 필요가 없습니다. 1.1 보일러플레이트 제로 Redux Toolkit(RTK)이 많이 간소화되었다고는 하지만, 여전히 스토어를 설정하고 슬라이스를 만드는 과정이

Next.js 14에서 � 1. RSC의 핵심 철학: 번들 크기의 제로화(Zero Bundle Size) RSC의 가장 원초적이고 강력한 목적은 "사용자에게 전달되는 JavaScript 번들 크기를 줄이는 것" 입니다. 전통적인 클라이언트 컴포넌트는 해당 컴포넌트를 렌더링하기 위한 모든 코드 로직과 의존 라이브러리(예: date-fns , markdown-

RSC의 가장 원초적이고 강력한 목적은 "사용자에게 전달되는 JavaScript 번들 크기를 줄이는 것" 입니다. 전통적인 클라이언트 컴포넌트는 해당 컴포넌트를 렌더링하기 위한 모든 코드 로직과 의존 라이브러리(예: date-fns , markdown-it , framer-motion )를 브라우저가 내려받아야 했습니다.

Redux는 여전히 수많은 엔터프라이즈 프로젝트에서 사용되고 있으며, Redux Toolkit(RTK)의 등장으로 보일러플레이트 문제도 상당 부분 해소되었습니다. createSlice, createAsyncThunk 같은 유틸리티는 Redux의 사용 경험을 크게 개선했습니다.

React 애플리케이션에서 상태 관리를 이야기하면 전역 store부터 떠올리기 쉽습니다. 하지만 화면에 보이는 데이터 중 상당수는 클라이언트가 소유한 상태가 아닙니다. 사용자 목록, 주문 상태, 알림 개수, 결제 내역은 서버가 진짜 소스입니다. 클라이언트는 그 시점의 스냅샷을 잠시 들고 있을 뿐입니다.