Event와 Effect 분리하기 — useEffectEvent

Q1 Understand mcq_single

동일한 `sendMessage(text)` 호출을 event handler에 둘지 Effect에 둘지 결정하는 가장 본질적인 질문은 무엇인가?

A. A. 그 함수가 비동기인지 동기인지 B. B. 사용자가 그 액션을 했기 때문에 실행되는가, 컴포넌트가 화면에 있기 때문에 실행되는가? C. C. 함수 내부에서 props/state를 읽는가, 읽지 않는가? D. D. 함수가 외부 시스템(서버, DOM)을 건드리는가?

정답: B
S6.C1의 결정 질문은 '왜 실행돼야 하나?' — 인터랙션 응답이면 handler(non-reactive), 표시 중 동기화면 Effect(reactive). 이 한 줄이 위치 결정의 모든 것이다.
오답 해설:

A. 비동기 여부는 위치 결정의 기준이 아니다. fetch는 클릭 결과면 handler, 동기화면 Effect 어느 쪽에도 들어갈 수 있다.
C. 두 곳 모두 reactive value를 읽을 수 있다. 위치는 '왜 실행되는가'에 따라 갈린다 — 핵심은 트리거의 본질이지 읽기 여부가 아니다.
D. 외부 시스템 접근은 Effect의 정의 중 일부지만, handler도 외부 시스템을 호출한다(예: addToCart, sendMessage). 결정 기준은 트리거다.

Q2 Apply mcq_single

다음 중 Event handler가 아니라 Effect에 두는 것이 적절한 시나리오는?

A. A. 'Submit' 버튼 클릭 시 폼을 서버에 전송한다 B. B. 검색창의 query state가 바뀔 때마다 자동완성 결과를 fetch 해 동기화한다 C. C. 'Buy' 버튼 클릭 시 장바구니에 아이템을 추가하고 토스트를 띄운다 D. D. 사용자가 'Logout'을 누르면 토큰을 삭제한다

정답: B
B만 '컴포넌트가 화면에 있는 동안 query에 동기화'되는 케이스 — query 변경에 자동 반응해야 하므로 Effect. 나머지는 모두 사용자 인터랙션 결과로 일어나는 일이라 handler.
오답 해설:

A. submit은 명백한 인터랙션. Effect로 옮기면 mount/deps 변경 때 의도 없이 발사된다.
C. 클릭 결과로 일어나는 한 번의 부수효과 — handler가 정답.
D. logout 버튼 누름이라는 인터랙션의 결과. Effect에 두면 의도하지 않은 시점에 토큰이 삭제될 수 있다.

Q3 Understand mcq_multi

react.dev 기준 useEffectEvent의 특성으로 옳은 것을 모두 고르시오. (정답 3개)

A. A. wrap 된 함수는 항상 최신 props·state를 본다 B. B. wrap 된 함수는 reactive 하지 않아 Effect의 deps에 올리지 않는다 C. C. Effect 외부(예: onClick 핸들러 자리)에서도 자유롭게 호출할 수 있다 D. D. 다른 컴포넌트나 Hook에 인자/prop으로 전달해 재사용해도 안전하다 E. E. React의 실험적(experimental) API이며 stable 출시 전에는 import 경로가 달라질 수 있다

정답: A, B, E
useEffectEvent의 핵심 특성은 (1) 항상 최신 값, (2) non-reactive(deps 제외), (3) Effect 안에서만 호출, (4) 외부 전달 금지, 그리고 실험적 API라는 점. A·B·E가 옳다.
오답 해설:

C. 제약 1 — Effect 안에서만 호출. 평범한 핸들러 자리에는 그냥 함수를 쓰면 된다.
D. 제약 2 — 다른 컴포넌트/Hook에 전달 금지. 넘기면 reactive 흐름에서 분리된 '섬'이 외부로 새어나가 추적 불가능해진다.

Q4 Apply mcq_single

다음 ChatRoom 코드는 다크/라이트 테마를 토글할 때마다 채팅이 끊겼다 다시 연결된다. ```tsx function ChatRoom({ roomId, theme }) { useEffect(() => { const c = createConnection(roomId); c.on('connected', () => showNotification('Connected!', theme)); c.connect(); return () => c.disconnect(); }, [roomId, theme]); } ``` 가장 적절한 리팩터링은?

A. A. deps에서 theme를 빼고 `// eslint-disable-next-line react-hooks/exhaustive-deps` 로 lint를 누른다 B. B. `onConnected = useEffectEvent(() => showNotification('Connected!', theme))`로 추출하고 Effect 본체에서 호출, deps는 `[roomId]`만 남긴다 C. C. theme를 useRef에 저장해 Effect 안에서 ref.current로 읽는다 D. D. theme이 바뀔 때마다 connection을 끊고 재연결하는 것이 정상 동작이므로 그대로 둔다

정답: B
alert/notification 은 'theme를 읽는다 ≠ theme에 반응한다' — non-reactive 로직이다. useEffectEvent로 추출하면 항상 최신 theme로 알림이 뜨면서도 deps에는 빠져 재연결이 사라진다. S6.C2의 핵심 패턴.
오답 해설:

A. Lint suppress는 의미 분리가 아닌 우회 — stale closure 위험을 그대로 둔 채 경고만 가린다. 'suppress 대신 useEffectEvent' 원칙 위반.
C. ref 우회는 렌더 중 mutation/읽기 안티패턴이 될 수 있고, 의미를 코드로 표현하지 못한다. useEffectEvent가 정확히 이 문제를 위한 도구다.
D. 사용자 의도는 '테마 토글로는 연결을 유지'다. 재연결을 정상 동작으로 받아들이면 UX가 망가진다.

Q5 Apply mcq_single

Page 컴포넌트는 `url`이 바뀔 때만 방문 로그를 남기되, 로그에는 항상 최신 장바구니 개수(`numberOfItems`)를 함께 기록해야 한다. '재발화 조건은 의도대로 url에만, numberOfItems는 본체에서 직접' 패턴을 가장 정확히 구현한 코드는?

A. A. ```tsx const onVisit = useEffectEvent(visitedUrl => logVisit(visitedUrl, numberOfItems)); useEffect(() => { onVisit(url); }, [url]); ``` B. B. ```tsx const onVisit = useEffectEvent(() => logVisit(url, numberOfItems)); useEffect(() => { onVisit(); }, [url, numberOfItems]); ``` C. C. ```tsx useEffect(() => { logVisit(url, numberOfItems); }, [url]); // eslint-disable-next-line react-hooks/exhaustive-deps ``` D. D. ```tsx const onVisit = useEffectEvent(() => logVisit(url, numberOfItems)); useEffect(() => { onVisit(); }, []); ```

정답: A
원칙: reactive 값(url)은 인자로 전달하고, non-reactive 값(numberOfItems)은 Effect Event 본체에서 직접 읽는다. deps는 재발화 조건인 [url]만. A가 정확히 이 패턴이다.
오답 해설:

B. numberOfItems를 deps에 넣으면 카트 변경마다 재발화한다 — 의도와 정반대. 또한 url을 본체에서 직접 읽는 건 reactive 인자 패턴을 어긴다.
C. lint suppress 우회 — stale closure로 numberOfItems가 옛 값으로 기록될 수 있고, 의미가 코드에 드러나지 않는다.
D. deps `[]`는 mount 시 한 번만 — url 변경에 재발화하지 않으므로 요구사항 위반.

Q6 Analyze mcq_single

다음 코드의 가장 큰 문제와 올바른 처방을 고르시오. ```tsx function Timer() { const [count, setCount] = useState(0); const onTick = useEffectEvent(() => setCount(c => c + 1)); useTimer(onTick, 1000); // 자식 Hook에 전달 } ```

A. A. 문제 없음 — useEffectEvent의 일반적인 재사용 패턴이다 B. B. setCount는 이미 stable 하므로 useEffectEvent 자체가 불필요하고, useEffect로 그냥 setInterval을 걸면 된다 C. C. useEffectEvent를 다른 Hook에 인자로 전달하는 것은 제약 위반 — useTimer 내부에서 callback을 받아 그곳에서 `onTick = useEffectEvent(() => callback())`로 정의해야 한다 D. D. onTick의 이름이 라이프사이클 어휘라서 문제 — `onMount`로 바꾸면 해결된다

정답: C
S6.C3 핵심 안티패턴 — '다른 Hook/컴포넌트에 인자로 전달 금지'. 처방은 '사용처 동거': useEffectEvent를 그것이 호출되는 Hook(useTimer) 내부에서 정의한다. 그러면 Timer는 `useTimer(() => setCount(c => c+1), 1000)`로 깔끔해진다.
오답 해설:

A. 정확히 제약 2 위반. 자식 Hook은 onTick의 reactive 여부를 모르고 호출 시점이 부모 렌더와 어긋난다.
B. setCount가 stable인 건 맞지만, 일반적으로 callback이 reactive 값을 읽는 경우를 다루는 구조 — 사용처-동거 원칙이 더 본질이다.
D. onTick은 'on + 사건' 형의 좋은 이름이다. onMount는 오히려 라이프사이클 어휘로 회귀하는 잘못된 명명이다.

Q7 Evaluate mcq_multi

팀 코드 리뷰에서 useEffectEvent 사용에 대한 다음 의견 중 옳은 것을 모두 고르시오. (정답 2개)

A. A. exhaustive-deps lint 경고를 끄지 않으려고 어떤 값이든 useEffectEvent로 감싸는 건 실질적으로 lint suppress와 같은 우회다 — 먼저 '이 값이 변했을 때 정말 재동기화가 필요 없는가?'를 물어야 한다 B. B. Effect Event의 이름은 `onMount`/`onUpdate`/`onAfterRender` 같은 라이프사이클 어휘를 권장한다 — 실행 시점을 명확히 알리기 때문이다 C. C. 도메인 사건명(`onConnected`, `onVisit`, `onTimerFinished`)을 쓰는 것이 권장된다 — 이름이 '무슨 사건이 일어났나'를 가리키도록 설계해야 한다 D. D. useEffectEvent는 stable API이므로 production에 자유롭게 도입해도 무방하다 E. E. 평범한 onClick 핸들러는 useEffectEvent로 감싸는 것이 항상 더 안전하다 — 항상 최신 값을 보장하기 때문이다

정답: A, C
A는 'suppress 대신 useEffectEvent'의 정확한 해석 — 의미 판단이 먼저다. C는 react.dev의 명명 가이드. B는 라이프사이클 어휘로 회귀시키는 잘못된 명명, D는 사실 오류(실험적 API), E는 핸들러 자리에는 그냥 함수를 쓰면 되므로 과사용이다.
오답 해설: