상태관리
-
클로저·this·viewport를 지키며 큰 컴포넌트를 쪼갠 작업기React 2026. 7. 15. 17:26
"이 컴포넌트 너무 크니까 좀 쪼개 줘." 이 요청을 받으면, 사람이든 AI 에이전트든 가장 쉽게 빠지는 함정이 줄 수(LOC)를 줄이는 데 최적화하는 것이다. 함수로 뽑고 helper로 흩어 메인 본문을 짧게 만든다. 지표는 좋아진다. 그런데 화면이 깜빡이고, 차트 호버가 죽고, 다른 탭에 다녀오면 그래프가 어긋났다. 기술 트렌드를 시각화하는 한 화면(기술 트리·버블 차트·보고서)을 다섯 갈래로 쪼개면서 나는 이걸 다섯 번 확인했다. 큰 컴포넌트·훅을 분해해 봤고 useEffect나 차트 라이브러리에서 미묘한 회귀를 겪어 본 사람이라면 익숙한 장면일 것이다.줄을 세는 일과 의미를 지키는 일은 다르다분해를 하다 보면 매번 같은 단어로 돌아왔다. 런타임 계약. 코드가 겉으로 드러내지 않지만 동작이 의존하는..
-
Zustand stale 플래그와 변경 직전 pre-fetch로 VERSION_CONFLICT 숨긴 작업기React 2026. 7. 13. 19:23
프로젝트 소스 패널에서 폴더를 삭제했을 뿐인데 "잠시 후 다시 시도해 주세요"라는 빨간 토스트가 떴다. 코드를 따라가 보니 서버 응답은 400 VERSION_CONFLICT였다. 우리 서버는 폴더 변경에 낙관적 동시성 제어를 쓴다. 폴더마다 version: number를 들고 있고, 삭제·이름 변경·이동 요청에 내가 알고 있는 expectedVersion을 실어 보내면 서버가 현재 버전과 비교한다. 어긋나면 거부한다. 문제는 사용자 모르게 그 버전이 올라가는 경로가 있었다는 것이다. 외부 소스를 폴더로 적재하는 백그라운드 "불러오기" 작업이 끝나면 서버 폴더 버전이 오른다. 그런데 브라우저 캐시는 옛 버전 그대로다.재현 경로는 이랬다. 사용자가 불러오기를 시작하고, 모달을 닫거나 새로고침하고, 백그라운드..
-
React Flow·dnd-kit·zundo로 트리 편집기 작업기React 2026. 7. 10. 19:02
노드를 끌어다 놓아 트리를 편집하고, 순서를 바꾸고, Ctrl+Z로 되돌린다. 요구사항만 보면 평범하다. 노드 캔버스는 React Flow(@xyflow/react), 드래그 정렬은 dnd-kit, undo/redo는 zundo(Zustand 미들웨어)를 쓰면 된다. 각 라이브러리의 README 예제는 5분이면 동작한다.문제는 이 넷을 같은 DOM, 같은 마우스 이벤트, 같은 상태 트리 위에 포개는 순간 시작됐다. React Flow는 노드 클릭을 자기가 처리하려 하고, dnd-kit도 같은 mousedown을 노리고, zundo는 store에 일어나는 모든 변경을 히스토리에 쌓으려 하고, 캔버스 컨테이너의 overflow는 드롭다운을 가둔다. 기능을 구현하는 시간보다 이 충돌을 격리하는 시간이 더 길었..
-
켰는데 왜 안 먹지 — 하나의 모드를 Claude Code와 Codex 두 호스트에 (Scrooge 4편)AI 엔지니어링 2026. 6. 15. 17:50
🔗 scrooge1. 도입부 — "같은 기능"이 호스트마다 다른 표면을 갖는다압축 모드 하나를 Claude Code에서 잘 돌렸다고 하자. 이걸 Codex에도 태우려 한다. 기능은 "똑같다" — 사용자 입력에 압축 지시를 끼워 LLM이 짧게 답하게 만든다. 그런데 막상 옮기려 보면, 두 호스트가 개입하는 메커니즘 자체가 다르다. 같은 기능인데 표면이 갈린다.여기에 더 음험한 문제가 겹친다. "scrooge가 켜졌다"는 말이 실은 세 가지 다른 의미로 쓰이고 있었다는 점이다. 설치됐다는 뜻인지, 지금 활성이라는 뜻인지, 이 세션에만 거는 지시라는 뜻인지. 이 셋을 섞으면 "분명 켰는데 왜 안 먹지" 같은 혼란이 반드시 생긴다.이 글에서 당신이 얻어갈 것은 두 가지다. 하나는 같은 기능을 다른 hook 메..
-
React 최신 상태관리 라이브러리 비교하기 (feat. zustand, redux-toolkit, jotai, recoil)React 2022. 8. 16. 17:28
1. redux-toolkit(rtk)을 그만 사용하려는 이유 나의 경우 react를 시작하고 redux-saga -> mobx -> redux-saga -> redux-toolkit 순으로 사용했을 정도로 redux의 사용을 좋아하고 즐겨 사용했다. 하지만 이제 api 통신을 react-query로 변경하고 프로젝트를 진행하는 요즘에는 rtk를 통한 글로벌 상태 관리를 하는 경우가 무척 줄어들거나 아예 사용하지 않는 프로젝트들이 생겨났다. 상황이 이렇게 되니 rtk의 단점들이 보이기 시작했고 두 가지 글로벌 상태 관리 라이브러리를 선택했다. 2. zustand와 jotai 두 라이브러리는 각각 독일어와 일본어로 상태를 뜻하는 단어로 이름에서 알 수 있듯이 모두 Poimandres의 카토 다이시가 주가 ..