Reducer + Context로 확장하기

7 문항 · Bloom: Understand:1, Apply:1, Analyze:1, Evaluate:3, Create:1 · v1.0.0

Q1 Understand mcq_single

useReducer + context 패턴에서 state context와 dispatch context를 굳이 두 개로 분리하는 가장 핵심적인 이유는 무엇인가?

A. 두 context를 합치면 React가 런타임 에러를 던지기 때문에 B. tasks가 바뀔 때마다 dispatch만 쓰는 컴포넌트까지 모두 재렌더되는 것을 막고, 읽기/쓰기 관심사를 코드에서 명시적으로 분리하기 위해 C. createContext가 한 모듈에서 한 번만 호출될 수 있다는 React 제약 때문 D. TypeScript가 객체 타입의 context value를 추론하지 못하기 때문

정답: B
단일 context에 { tasks, dispatch }를 묶어 넣으면 tasks 변경 시 그 context를 구독한 모든 자식이 재렌더된다. 두 개로 쪼개면 dispatch만 구독하는 AddTask 같은 컴포넌트는 tasks 변경에 영향받지 않으며(dispatch 참조는 안정적), 동시에 '이 컴포넌트가 읽기/쓰기/둘 다인지'가 호출부에서 드러난다.
오답 해설:

A. 런타임 에러는 발생하지 않는다 — 합쳐도 동작은 한다. 다만 성능과 가독성이 나빠질 뿐.
C. createContext는 모듈당 호출 횟수에 제약이 없다.
D. TypeScript 추론과는 무관한 결정이다.

Q2 Apply mcq_single

다음 중 reducer + context 패턴의 3단계 빌드 순서를 가장 정확하게 기술한 것은?

A. useReducer로 state를 만든 뒤 → createContext로 감싸고 → 자식에서 props로 내려받는다 B. createContext × 2 → Provider 컴포넌트 안에서 useReducer 호출 → 두 context value 흘려보냄 → 자식에서 useContext × 2로 필요한 쪽만 구독 C. useState × 2 → useContext × 2 → 마지막에 reducer로 합친다 D. createContext × 1 → useReducer로 { state, dispatch } 객체를 만들어 한 번에 흘려보냄 → useContext × 1로 둘 다 꺼내 쓴다

정답: B
정석 빌드는 ① createContext 두 개(state용, dispatch용) ② Provider 안에서 useReducer 호출해 두 value를 각 Provider에 흘리고 ③ 자식이 useContext로 자신이 필요한 것만 구독하는 순서다.
오답 해설:

A. context 결합의 동기 자체가 prop drilling 제거였는데 다시 props로 내려보내면 모순이다.
C. useState 두 개로는 reducer의 단일 진입점(action) 이점을 잃는다.
D. 단일 context로 합치는 패턴은 재렌더 분리 이점이 사라진다 — 강의가 명시적으로 회피하는 안티패턴.

Q3 Analyze mcq_multi

TasksContext.js 한 파일에 context 두 개·reducer·initialTasks·TasksProvider·useTasks·useTasksDispatch를 모두 모으는 'Provider 단일 파일 응집' 패턴의 이점으로 옳은 것을 모두 고르시오. (정답 3개)

A. App 트리에서 createContext/useReducer 등 wiring이 사라져 UI 조립에만 집중할 수 있다 B. context 객체를 module-private으로 두고 useTasks/useTasksDispatch만 export 하면 추상화 경계를 강제할 수 있다 C. 추후 셀렉터·로깅·메모이제이션을 커스텀 훅 안에서 추가해도 소비자 호출부는 그대로다 D. React가 단일 파일 모듈을 자동으로 메모이즈하여 재렌더가 줄어든다 E. useReducer가 자동으로 비동기 thunk를 지원하게 된다

정답: A, B, C
단일 파일 응집의 이점은 (1) App.js의 어수선함 제거 (2) context를 비공개로 묶어 추상화 경계 강제 (3) 미래의 변경(셀렉터/로깅/메모) 흡수 — 소비자 코드 불변. 성능·비동기 처리는 이 패턴 자체가 부여하는 이점이 아니다.
오답 해설:

D. React에 '단일 파일 자동 메모이즈' 같은 기능은 없다 — 흔한 오개념.
E. thunk 같은 미들웨어는 reducer+context의 기본 능력이 아니며, 이런 필요가 생길 때 Redux/Zustand 도입을 검토한다.

Q4 Evaluate mcq_single

context를 module-private으로 둔 채 useTasks/useTasksDispatch 커스텀 훅으로 한 겹 감싸 export 하는 가장 본질적인 이유는?

A. 커스텀 훅이 없으면 React가 useContext 호출을 거부하기 때문 B. use 접두사가 있어야 React DevTools에 컴포넌트가 표시되기 때문 C. context 객체 자체를 외부에 노출하지 않아야 내부 구현(셀렉터·메모·로깅 추가, context 분할/병합)을 바꿔도 호출부를 손대지 않기 때문 D. 커스텀 훅으로 감싸야 dispatch 참조가 안정화되기 때문

정답: C
핵심은 캡슐화다. context를 외부로 export 하면 소비자가 useContext(TasksContext)를 직접 부를 수 있고, 그 순간 추상화 경계가 깨져 내부 구현 변경 비용이 폭증한다. use… 훅 한 겹이 미래의 변경 비용(셀렉터·로깅·메모·분리/통합)을 흡수한다.
오답 해설:

A. useContext 직접 호출은 완전히 합법이다.
B. DevTools 표시 여부와는 무관하다.
D. dispatch 안정성은 useReducer가 보장하는 것이지 커스텀 훅 래핑 효과가 아니다.

Q5 Create mcq_single

현재 앱이 Tasks 도메인 하나만 reducer+context로 관리 중이다. 사용자 인증과 다크모드 테마를 추가하려고 한다. 다중 도메인 확장 전략으로 가장 적절한 것은?

A. 기존 TasksProvider 안에 auth와 theme state를 추가해 단일 reducer로 모든 도메인을 처리한다 B. AuthProvider, ThemeProvider를 같은 (reducer + 두 context + 커스텀 훅) 패턴으로 각각 독립시키고, 의존성 방향에 따라 바깥부터 중첩(Theme → Auth → Tasks)한다 C. Tasks/Auth/Theme을 모두 props로 내려보내 단일 진실의 원천을 root에 둔다 D. 도메인이 셋이 되었으니 즉시 Redux로 마이그레이션한다

정답: B
도메인 경계 기준은 '함께 변하는가? 같은 사용자 액션에 반응하는가? 분리되어도 의미 있는가?'다. Tasks/Auth/Theme은 서로 독립적으로 변하므로 같은 패턴을 복제해 분리하고, 의존성 방향(Theme이 가장 외곽, Tasks가 가장 안쪽)에 맞춰 중첩한다.
오답 해설:

A. 독립 변화 도메인을 한 reducer에 묶으면 action 종류가 폭증하고 도메인 간 결합이 생긴다.
C. prop drilling 지옥으로 회귀 — 이번 섹션이 풀려고 한 문제 그 자체.
D. 도메인 수만으로는 라이브러리 도입 근거가 부족하다 — 통증(미들웨어·devtools·스케일)이 명확할 때 도입한다.

Q6 Evaluate mcq_multi

reducer+context 패턴에서 졸업해 Zustand 또는 Redux Toolkit 같은 외부 라이브러리 도입을 진지하게 검토할 만한 신호를 모두 고르시오. (정답 3개)

A. thunk/saga 같은 비동기 미들웨어가 여러 도메인에서 반복적으로 필요해진다 B. time-travel 디버깅, 액션 로깅 같은 전역 devtools가 팀 디버깅에 필수가 된다 C. 도메인이 늘고 셀렉터 메모이제이션·렌더 최적화 요구가 누적된다 D. TasksProvider를 App.js에서 import 한 줄이 길어졌다 E. TypeScript에서 useContext 반환 타입을 좁히기 귀찮다

정답: A, B, C
도입 판단의 진짜 기준은 스케일·디버깅·미들웨어 통증의 누적이다. 비동기 미들웨어 필요(A), devtools 필요(B), 셀렉터·렌더 최적화 누적(C)이 겹치기 시작하면 라이브러리가 정직한 선택이 된다. import 길이나 타입 정리 귀찮음은 패턴 자체로 충분히 해결할 수 있는 수준의 통증이 아니다.
오답 해설:

D. import 한 줄은 도입 신호가 아니다 — '통증 없이 라이브러리부터'는 강의가 경고하는 과잉 설계.
E. 타입 좁히기는 커스텀 훅 한 곳에서 해결할 수 있다.

Q7 Evaluate short_answer

한 시니어 동료가 '아직 도메인이 둘뿐인데 그냥 처음부터 Redux 깔자'고 제안한다. 당신은 reducer+context 패턴으로 충분하다고 판단했다. 자신의 결정을 정당화하는 근거 3가지와, 향후 어떤 신호가 보이면 마음을 바꿀지 1가지를 2~4문장으로 작성하시오.

모범 답안: 현재 도메인이 적고(2개), 비동기 미들웨어 요구가 없으며, devtools/time-travel이 팀 디버깅에 필수가 아니다. reducer+context는 의존성 0, 학습 곡선 0이라 작은 앱에서 정직한 선택이다. 향후 (a) 여러 도메인이 동일한 비동기 흐름(thunk/saga)을 반복 요구하거나 (b) 액션 로깅·time-travel이 팀 디버깅에 필수가 되거나 (c) 셀렉터 메모이제이션 요구가 쌓이면 Zustand/RTK 검토를 시작한다.채점 기준: