상태 관리는 라이브러리 선택이 아니라 소유권, 렌더링 위치, 생명주기 설계다React 프로젝트를 시작하면 상태 관리는 대체로 단순하다. const [isOpen, setIsOpen] = useState(false);const [keyword, setKeyword] = useState("");const [selectedId, setSelectedId] = useState(null); 하지만 프로젝트가 커지면 질문이 달라진다.이 상태를 useState에 둘까?Context에 둘까?Zustand에 둘까?TanStack Query에 둘까?URL에 둘까?Server Component에서 가져올까?Server Action으로 바꿀까?localStorage에 저장할까? 상태 관리가 어려워지는 이유는 상태가 많아져서만..

상태 관리는 “어디에 저장할까”가 아니라 “누가 소유하는가”의 문제다프론트엔드 애플리케이션이 작을 때 상태 관리는 단순해 보인다. const [user, setUser] = useState(null);const [isModalOpen, setIsModalOpen] = useState(false);const [keyword, setKeyword] = useState(""); 하지만 기능이 늘어나면 상태는 빠르게 복잡해진다.사용자 정보, 권한, 상품 목록, 검색 필터, 페이지 번호, 모달 열림 여부, 폼 입력값, 선택된 행, 정렬 조건, 알림 배지, 로딩 상태, 에러 상태, 캐시, WebSocket 메시지, optimistic update까지 모두 “상태”라는 이름으로 섞이기 시작한다.이때 많은 팀이 다음 ..