[Trouble Shooting] useEffect도 useMemo도 답이 아니었다 — 한 박자 늦는 state

📍 useEffect도 useMemo도 답이 아니었다 — 한 박자 늦는 state

들어가며

해외 T&A 상품 상세(PDP) 페이지에는 두 개의 예약 버튼이 있다. 하나는 옵션 영역 안의 예약 버튼이고, 다른 하나는 스크롤을 내리면 따라다니는 CTA 플로팅 버튼이다.

 

맡던 업무가 예상보다 빠르게 마무리 되어 리소스가 조금 남아 백로그를 살펴보다 눈에 띄는 티켓을 발견했다.

필수 옵션을 선택하지 않았는데도 CTA 플로팅 "예약하기"를 누르면 결제 페이지로 넘어간다.

 

옵션 영역 버튼은 검증을 통과하지 못 하면 버튼이 disabled 처리가 되는데, CTA 플로팅 버튼은 클릭이 가능한 상태였다. 두 버튼이 같은 상태를 공유하지 못하고 있던 것이다.

문제 발견

버튼 disabled 처리는 옵션 컴포넌트(/item/index.tsx)에서 계산한다. 유저가 선택한 수량 (finalAmounts), 타임슬롯 (selectedTimeslot), 상품상세 데이터로부터 필수 옵션, 단독 구매, 최소 인원 조건을 고려하여 만든 값이다.

 

문제는 CTA 플로팅 버튼이 별도 컴포넌트(/cta/desktop.tsx)라는 것인데, 이 계산 로직을 그대로 가져가면 CTA 버튼이 상품 데이터와 검증 로직 전체를 가지게 되어 결합도가 너무 높아진다. 그래서 계산은 옵션 컴포넌트에서 진행하고, 결과 값만 전역 store에 실어서 CTA가 읽도록 하기로 했다.

// floatingOptionsAtom 에 buttonDisabled 필드 추가
  export const floatingOptionsAtom = atom<{
    // ...
    buttonDisabled?: boolean
  } | undefined>(undefined)

  // cta/desktop.tsx — 읽어서 disabled 에 반영
  const floatingOptionButtonDisabled = floatingOptions && floatingOptions.buttonDisabled

  return (<CtaButton disabled={!isSaleable || floatingOptionButtonDisabled} ... />)

 

여기까지는 단순해 보였다. 문제는 옵션 컴포넌트가 atom에 buttonDisabled를 언제, 어떤 값으로 넣느냐였다.

📍 시도 1 — useEffect로 atom에 동기화

가장 빠르게 처리할 수 있는 방법. buttonDisabled가 변경될때마다 useEffect로 atom에 따라 쓰게 했다.

const buttonDisabled = useMemo(() => compute(finalAmounts, selectedTimeslot), [finalAmounts, selectedTimeslot])

useEffect(() => {
  setFloatingOptions((prev) => (prev && { ...prev, buttonDisabled }))
}, [buttonDisabled])

 

결과는 한 박자 (1렌더) 늦게 반영됨. 옵션을 선택한 직후 CTA를 누르면 비활성화돼야 할 버튼이 그대로 눌렸다.

원인은 useEffect의 실행 시점이다. useEffect는 렌더가 화면에 커밋된 이후에 실행된다.

1. 옵션 변경 → setFinalAmounts(새 값)
2. 리렌더 → useMemo가 buttonDisabled 재계산
3. DOM 커밋
4. 그제서야 useEffect 실행 → setFloatingOptions(buttonDisabled 덮어쓰기)
5. 4번 때문에 다시 한 번 더 렌더

buttonDisabled가 atom에 도달하는건 4번 시점인데, 그 전 (2 ~ 3번 사이)에 클릭이 들어오면 이전 사이클 값이 잡힌다.

📍 시도 2 — useEffect 대신 setFloatingOptions에 직접 덮어쓰기

그러면, useEffect를 빼고, 옵션을 바꾸는 핸들러에서 setFloatingOptions에 buttonDisabled를 바로 넣으면 되지 않을까?

 onChange={(value) => {
    const amounts = amountToSnapshotOptions({ value, ... })
    setFinalAmounts(amounts)
    setFloatingOptions({ ...floatingOptions, amounts, buttonDisabled })
    //                                                 ^^^^^^^^^^^^^^ useMemo 값
  }}

 

그런데 여전히 한 박자가 늦었다. 여기서 헤맸는데, 핵심 인사이트는 이거였다.

렌더 중 계산된 값 (useMemo든 아니든) 직전에 커밋된 state 기준이다.

 

이 핸들러 안에서 참조하는 buttonDisabled는 이번 렌더의 useMemo의 결과 = 직전 finalAmounts 기준 값이다. 방금 setFinalAmounts(amounts)를 호출했어도 그건 다음 렌더를 예약한 것일 뿐, 지금 핸들러가 보는 buttonDisabled는 새 amounts를 모른다.

 

useMemo는 다음 렌더에서야 재계산되기 때문이다. 즉 useEffect를 없애도, stale한 useMemo를 그대로 넣는 한 무조건 늦는다. useMemo를 빼도 똑같다. "useMemo가 캐싱해서 늦는 건가?" 싶어서 useMemo를 빼고 렌더 본문에서 그냥 계산해봤다.

 

// useMemo 제거 — 렌더할 때마다 직접 계산
const buttonDisabled = getItemButtonDisabled({ detailData, finalAmounts, selectedTimeslot })

onChange={(value) => {
  const amounts = amountToSnapshotOptions({ value, ... })
  setFinalAmounts(amounts)
  setFloatingOptions({ ...floatingOptions, amounts, buttonDisabled })
//                                                 ^^^^^^^^^^^^^^ 여전히 옛 값
}}

 

그래도 한 박자 늦었다. 이유는 클로저에 있다. onChange 핸들러는 이번 렌더에서 만들어진 함수라, 그 안의 buttonDisabled는 이번 렌더 시점의 finalAmounts(옛 값)로 계산된 값을 캡처한다.

 

핸들러 안에서 setFinalAmounts(amounts)를 불러도 그건 다음 렌더를 예약할 뿐, 이미 캡처된 buttonDisabled는 바뀌지 않는다.
즉 늦는 원인은 useMemo의 캐싱이 아니라, "렌더 시점에 만들어진 값을, 그 렌더에서 생성된 핸들러가 그대로 들고 있다"는 구조 자체였다. memoize는 거들 뿐, 빼도 결과는 같다.

 

그래서 답은 하나로 모인다 — 렌더가 만들어 준 값을 재사용하지 말고, 핸들러가 방금 만든 amounts로 그 자리에서 다시 계산할 것.

💡 react 18에 사용하는 useTransition, flushSync는?

• useTransition / useDeferredValue는 업데이트를 미루는(defer) API다. "같은 cycle 내 즉시 반영"과는 정반대라 도움이 안 된다.
• flushSync로 강제 동기 렌더를 시키면 증상은 가려지지만 근본적인 해결방안은 아니다. React 18의 자동 배칭을 깨서 성능을 떨어뜨리고, 늦는 원인(렌더 파생값은 직전 커밋 state 기준)은 그대로라 조건이 추가되기라도 한다면 상태가 깨지기도 쉽다.

즉, 타이밍 API로 풀 문제가 아니라, 데이터 흐름을 고쳐야 하는 문제였다.

📍 최종 솔루션 — 쓰는 시점에 fresh 값으로 직접 계산

해결은 의외로 단순했다. useMemo가 다음 렌더에 계산해 줄 값을, 핸들러가 이미 손에 쥔 fresh 값(amounts)로 미리 당겨서 직접 계산해 같은 트랜잭션에 함께 넣으면 된다.
먼저 계산 로직을 순수 함수로 추출해 useMemo와 핸들러가 같은 공식을 공유하게 했다.

// helpers.ts
export function getItemButtonDisabled({ detailData, finalAmounts, selectedTimeslot }): boolean {
  if (!detailData) return true
  // ... 필수 옵션 / 단독구매 / 최소 인원 / 회차 조건 계산
  return hasTimeslots ? !(!!selectedTimeslot && isCommonConditions) : !isCommonConditions
}

 

그리고 atom에 쓰는 시점에 fresh 값으로 호출한다.

onChange={(value) => {
  const amounts = amountToSnapshotOptions({ value, ... })

  const buttonDisabled = getItemButtonDisabled({
    detailData,
    finalAmounts: amounts,   // ✅ state가 아니라 방금 만든 fresh 값
    selectedTimeslot,
  })

  setFinalAmounts(amounts)
  setFloatingOptions({ ...floatingOptions, amounts, buttonDisabled })
}}

 

회차 선택(onTimeslotClick)에서도 똑같이 그 순간의 fresh 값으로 계산해서 넣었다. 그리고 useEffect는 삭제했다.

핵심은 amounts와 buttonDisabled가 한 트랜잭션에 일관되게 atom으로 들어간다는 것이다. 렌더 사이클을 기다리지 않으니 어긋날 틈이 없다.

📍 기대 효과 / 성능

• 한 박자 늦는 사이클 제거 → 타이밍 문제가 발생할 수 없는 구조
• flushSync 같은 강제 동기 렌더 불필요 → 자동 배칭 유지
• CTA는 기존에도 floatingOptions를 구독하고 있었으므로 추가 렌더·신규 구독 없다. 동일 write에 필드 하나만 더 실릴 뿐
• 늘어난 비용은 사용자 인터랙션당 순수 함수 호출 몇 번(렌더 경로 아님)뿐 → 사실상 영향 없음

📍 회고

이번 이슈를 해결하면서 가장 크게 남은 건 두 가지다.

 

첫째, 파생 상태(derived state)는 store에 복제하지 말자. 복제하는 순간 원본과 복사본 두 개의 진실이 생기고, 둘을 맞추는 동기화 책임이 따라온다. useEffect로 맞추면 한 박자 늦고, flushSync로 맞추면 성능을 깎는다. 둘 다 증상을 다룰 뿐이다.

 

둘째, 렌더 중 계산된 값은 "직전 커밋 state" 기준이다. 이벤트 핸들러에서 방금 setState로 바꾼 값을 그 자리에서 쓰고 싶다면, state를 다시 읽지 말고 내가 방금 만든 fresh 값으로 직접 계산해야 한다. 너무 당연한 사실인데, "값이 늦는다"는 증상을 만나면 자꾸 타이밍 API부터 찾게 된다. 이후 동일한 이슈가 있어도 당황하고 헤매지 말자는 취지에서 이 글을 남긴다.