<div id="readability-page-1" class="page"><div>
 <div id="SE-24f31ff3-4667-4559-9c56-fa78e6d6ee5e">
 useState는 강력하지만, 다루는 state가 복잡해지면 한계가 보입니다. 상태를 바꾸는 코드가 여러 이벤트 핸들러에 흩어지고, 비슷한 setState 호출이 곳곳에 반복되죠. 이번 챕터에서는 이렇게 흩어진 state 로직을 한곳에 모으는 도구, useReducer를 배웁니다.​​문제 — state 로직이 흩어진다할 일 목록을 useState로 만들어봅시다. 추가·삭제·완료 토글이 각각 핸들러로 있습니다.
 </div> <div id="SE-83385039-b447-4462-ac50-8c6d9d04e2ec">
 function TodoList() {
 const [todos, setTodos] = useState&lt;Todo[]&gt;([]);

 function handleAdd(text: string) {
 setTodos([...todos, { id: Date.now(), text, done: false }]);
 }
 function handleDelete(id: number) {
 setTodos(todos.filter((t) =&gt; t.id !== id));
 }
 function handleToggle(id: number) {
 setTodos(todos.map((t) =&gt; (t.id === id ? { ...t, done: !t.done } : t)));
 }
 // ...
}
 </div> <div id="SE-7b005ba7-033b-40cb-b5e0-28829474d567">
 지금은 셋뿐이라 견딜 만하지만, 기능이 늘어날수록 todos를 다루는 로직이 컴포넌트 곳곳에 퍼집니다. "이 state가 어떤 경우에 어떻게 바뀌는지"를 한눈에 보기 어려워지죠. state 변경 로직을 컴포넌트 바깥의 한 함수로 모으면 어떨까요? 그게 reducer의 발상입니다.
 </div> <div id="SE-b8ae3984-6a37-49d8-8822-644f476e7736">
 reducer의 3요소 — action, dispatch, reducer
 </div> <div id="SE-876b09af-5318-4c6e-be13-213389bc8f4e">
 ​useReducer는 세 가지 개념으로 돌아갑니다. 처음엔 용어가 낯설지만, 식당 주문에 비유하면 쉽습니다.<ul><li>action — "무슨 일이 일어났는가"를 적은 객체. 주문서 한 장입니다. 예: { type: 'added', text: '우유 사기' }</li><li>dispatch — action을 보내는 함수. 주문서를 주방에 전달하는 행위입니다. dispatch({ type: 'added', text: '...' })</li><li>reducer — 현재 state와 action을 받아 새 state를 돌려주는 함수. 주문서를 보고 요리하는 주방입니다. (state, action) =&gt; 새 state</li></ul>​흐름은 이렇습니다. 컴포넌트는 "무슨 일이 일어났는지"만 dispatch로 알리고, 어떻게 state를 바꿀지는 reducer 한 곳에서 결정합니다. 핸들러가 직접 setState를 부르지 않는 게 핵심입니다.​​useState를 useReducer로 바꿔보기위 할 일 목록을 reducer로 옮겨봅시다. 먼저 reducer 함수를 컴포넌트 바깥에 둡니다.
 </div> <div id="SE-b1dd7064-928b-49cd-934e-d08ad5058289">
 type Todo = { id: number; text: string; done: boolean };

// action의 종류를 유니온 타입으로 정의 (TypeScript의 핵심)
type Action =
 | { type: 'added'; text: string }
 | { type: 'deleted'; id: number }
 | { type: 'toggled'; id: number };

function todosReducer(todos: Todo[], action: Action): Todo[] {
 switch (action.type) {
 case 'added':
 return [...todos, { id: Date.now(), text: action.text, done: false }];
 case 'deleted':
 return todos.filter((t) =&gt; t.id !== action.id);
 case 'toggled':
 return todos.map((t) =&gt;
 t.id === action.id ? { ...t, done: !t.done } : t,
 );
 }
}
 </div> <div id="SE-725b5f64-dd33-4fa2-ad2e-6800dbef340d">
 이제 컴포넌트에서 useReducer로 연결합니다.
 </div> <div id="SE-e7276177-4f18-4e97-9e00-ddd43fe65a1d">
 import { useReducer } from 'react';

function TodoList() {
 const [todos, dispatch] = useReducer(todosReducer, []);

 function handleAdd(text: string) {
 dispatch({ type: 'added', text }); // "추가됐다"고 알리기만
 }
 function handleDelete(id: number) {
 dispatch({ type: 'deleted', id });
 }
 function handleToggle(id: number) {
 dispatch({ type: 'toggled', id });
 }
 // ...
}
 </div> <div id="SE-160b8c74-bd02-4d28-bec7-6acc497a8a5e">
 useReducer(todosReducer, [])는 [현재 state, dispatch 함수]를 돌려줍니다(useState와 모양이 닮았죠). 핸들러는 이제 "무슨 일이 일어났는지"만 dispatch하고, 실제로 todos를 어떻게 바꿀지는 전부 todosReducer 한 곳에 모였습니다. state 변경 로직을 한눈에 읽을 수 있게 된 겁니다.​TypeScript가 빛나는 순간: Action을 구별된 유니온(discriminated union)으로 정의하면, reducer의 switch 안에서 action.type에 따라 사용할 수 있는 필드가 자동으로 좁혀집니다. case 'added' 안에서는 action.text가 보이지만 action.id는 안 보이는 식이죠. 오타나 빠진 필드를 컴파일 단계에서 잡아줍니다. reducer와 TypeScript는 환상의 짝입니다.
 </div> <div id="SE-1a376fb8-8099-41b7-8edc-770eca63348e">
 reducer는 순수해야 한다​reducer에는 순수성 챕터에서 배운 원칙이 그대로 적용됩니다. reducer는 순수 함수여야 합니다.<ul><li>같은 state와 action이면 항상 같은 결과를 반환할 것.</li><li>기존 state를 직접 바꾸지 말 것(불변성). todos.push(...) 같은 변경은 금지. 항상 새 배열·객체를 반환합니다.</li><li>네트워크 요청, 타이머 같은 부수효과를 넣지 말 것. 그건 이벤트 핸들러의 몫입니다.</li></ul>​reducer가 순수해야 하는 이유는 React의 안정적인 동작뿐 아니라, 1번 챕터부터 켜둔 React Compiler의 최적화 전제와도 같습니다. 순수성은 여기서도 약속입니다.
 </div> <div id="SE-adefbabd-7dee-417a-8d13-2be3ca262a92">
 ⚠️ 언제 useReducer를 쓰고, 언제 쓰지 말까
 </div> <div id="SE-5aadfdc4-983c-4bdb-bc4f-9af0afe45944">
 ​reducer가 좋아 보인다고 모든 state를 reducer로 바꾸지는 마세요. 이건 흔한 과용입니다.<ul><li>useState가 나을 때: 단순한 값 하나(토글, 입력값, 카운터). 굳이 reducer로 만들면 오히려 코드가 늘어납니다.</li><li>useReducer가 나을 때: state 전이가 복잡하거나, 여러 핸들러가 비슷한 방식으로 같은 state를 바꿀 때. 변경 로직을 한곳에 모으면 읽기·테스트가 쉬워집니다.</li></ul>​판단 기준은 "이 state를 바꾸는 경우의 수가 많고 서로 얽혀 있는가"입니다. 그렇다면 reducer, 아니면 useState입니다.
 </div> <div id="SE-899825ae-c3a6-46e3-8d72-ff75afd44285">
 ​<ul><li>useReducer는 흩어진 state 변경 로직을 reducer 함수 하나에 모은다.</li><li>3요소: action(무슨 일이 일어났는가) → dispatch(action 보내기) → reducer((state, action) =&gt; 새 state).</li><li>핸들러는 "무슨 일이 일어났는지"만 dispatch하고, 어떻게 바꿀지는 reducer가 결정한다.</li><li>action을 구별된 유니온 타입으로 정의하면 TypeScript가 필드를 좁혀주고 실수를 막아준다.</li><li>reducer는 순수 함수여야 한다. 불변성을 지키고 부수효과를 넣지 않는다.</li><li>단순한 state엔 useState, 복잡하게 얽힌 state엔 useReducer. 모든 걸 reducer로 만들지 않는다.</li></ul>​useReducer로 한 컴포넌트의 복잡한 state를 정리했습니다. 그런데 그 state를 멀리 떨어진 여러 컴포넌트가 함께 써야 한다면? 매번 props로 내려보내자니 중간 컴포넌트들을 거쳐야 해서 번거롭습니다. 다음 챕터에서 이 prop 내려보내기 지옥(prop drilling)을 해결하는 Context를 배웁니다.
 </div> <div id="SE-f8679269-7aeb-45ed-a6ae-c8fd6e1542b5">
 ​<ul><li>Extracting State Logic into a Reducer — React 공식 문서 (확인: 2026-06-14)</li></ul>
 </div> </div></div>

개발하는 기획자. 기획하는 개발자.

useState는 강력하지만, 다루는 state가 복잡해지면 한계가 보입니다. 상태를 바꾸는 코드가 여러 이벤트 핸들러에 흩어지고, 비슷한 setState 호출이 곳곳에 반복되죠. 이번 챕터에서는 이렇게 흩어진 state 로직을 한곳에 모으는 도구, useReducer를 배웁니다. 문제 — state 로직이 흩어진다 할 일 목록을 useState로 만들어봅시다. 추가·삭제·완료 토글이 각각 핸들러로 있습니다. 지금은 셋뿐이라 견딜 만하지만, 기능이 늘어날수록 todos를 다루는 로직이 컴포넌트 곳곳에 퍼집니다. "이 state가 어떤 경우에 어떻게 바뀌는지"를 한눈에 보기 어려워지죠. state 변경 로직을 컴포넌트 바깥의 한 함수로 모으면 어떨까요? 그게 re.......

useReducer — 흩어진 state 로직을 한곳에 모으기

댓글