React 상태와 객체 동일성: 속성이 바뀌어도 왜 같은 상태일 수 있는가

30초 요약

React의 useState 상태 설정 함수는 이전 상태와 다음 상태를 Object.is로 비교한다. 객체에서는 속성 내용이 비슷한지가 아니라 같은 객체 값인지가 핵심이다.

기존 객체의 속성만 변경 → 객체 동일성은 그대로 → 같은 상태 신호가 될 수 있음
새 객체를 만들어 전달     → 객체 동일성이 달라짐 → 새 상태를 표현할 수 있음

화면이 바뀌지 않을 때 강제 다시 렌더링부터 추가하지 않는다. 상태 설정 직전 Object.is(previous, next)를 확인하고, 같은 객체를 다시 전달했는지 먼저 찾는다.

이 글을 관통하는 상황: 수량 값은 2인데 화면은 1이다

주문 수량과 합계를 한 객체 상태로 관리한다고 하자.

import { useState } from 'react'
 
export default function OrderEditor() {
  const [order, setOrder] = useState({
    quantity: 1,
    unitPrice: 10000,
  })
 
  function handleAdd() {
    order.quantity += 1
    setOrder(order)
  }
 
  return (
    <section>
      <p>수량: {order.quantity}</p>
      <p>합계: {order.quantity * order.unitPrice}원</p>
      <button type="button" onClick={handleAdd}>수량 추가</button>
    </section>
  )
}

처리 함수 안에서 console.log(order.quantity)는 2를 보여 줄 수 있다. 하지만 상태 설정 함수에 전달한 값은 이전 렌더링이 읽던 바로 그 order 객체다. React는 “속성 로그가 달라졌다”가 아니라 “이전 상태 값과 다음 상태 값이 같은가?”를 판단한다.

잘못된 대응은 DOM을 직접 바꾸거나, 화면을 억지로 다시 계산하려고 주문과 무관한 카운터 state를 추가하는 우회다. 그러면 상태와 화면의 기준이 더 멀어진다. 먼저 전달한 값의 동일성을 확인해야 한다.

상태는 현재 렌더링의 스냅샷이다

“어차피 다음 화면에 쓸 값인데 지금 바꿔도 된다”는 생각은 이전과 다음 상태를 동시에 관찰할 수 없게 만든다. 오류 기록이나 비동기 처리 함수가 이전 렌더링의 객체를 들고 있다면 그 객체의 내용도 예상하지 못한 시점에 달라진다.

속성 변경과 새 객체는 다른 사건이다

따라서 다음 두 구현은 React에 다른 신호를 준다. 두 함수를 한 클릭에서 차례로 실행하는 코드가 아니라, 같은 수량 추가 요구를 구현하는 서로 독립된 대안이다. 코드를 읽고 먼저 예측해 보자.

• 잘못된 구현에서 Object.is(previousOrder, nextOrder)는 무엇이며 화면은 새 수량을 받을까?
• 교정 구현에서는 같은 비교가 무엇이며 이전 객체의 수량은 보존될까?

먼저 잘못된 구현이다.

function handleAddWrong() {
  const previousOrder = order
  previousOrder.quantity += 1
  const nextOrder = previousOrder
 
  console.log(Object.is(previousOrder, nextOrder)) // true
  setOrder(nextOrder)
}

속성을 바꿨지만 nextOrder는 같은 객체이므로 비교 결과는 true다. React는 같은 상태 신호를 받아 새 화면 계산을 생략할 수 있다. 이제 기존 객체를 바꾸지 않고 새 객체를 명시적으로 만든다.

function handleAddCorrect() {
  const previousOrder = order
  const nextOrder = {
    quantity: previousOrder.quantity + 1,
    unitPrice: previousOrder.unitPrice,
  }
 
  console.log(Object.is(previousOrder, nextOrder)) // false
  setOrder(nextOrder)
}

교정 구현의 비교 결과는 false이고 previousOrder.quantity는 그대로다. React에는 새 상태 값이 전달되어 수량과 합계를 다시 계산할 수 있다. 속성이 많거나 중첩된 객체에서 변경 경로를 복사하는 방법은 4편에서 다룬다.

Object.is로 상태 신호를 먼저 확인한다

상태를 전달하기 직전에 이전 값과 다음 값을 기록한다.

const nextOrder = order
nextOrder.quantity += 1
 
console.log({
  sameState: Object.is(order, nextOrder), // true
  quantity: nextOrder.quantity,          // 2
})
 
setOrder(nextOrder)

quantity가 2라는 로그와 sameState가 true라는 로그는 모순이 아니다. 하나는 객체 속성의 현재 내용이고, 다른 하나는 두 이름이 같은 객체 값을 가리키는지 보여 준다.

같은 비교 규칙이 원시 값에도 적용된다

객체가 아닌 숫자 상태도 같은 Object.is 기준을 사용한다.

const [quantity, setQuantity] = useState(2)
setQuantity(2)
 
Object.is(2, 2) // true

NaN, +0, -0처럼 Object.is와 ===의 결과가 달라지는 숫자 경계는 JavaScript 동일성 선행 글에서 다뤘다. React는 그 규칙을 상태 비교에 사용하므로 필요한 경우 그 결과를 그대로 대입해 예측할 수 있다.

생략은 화면 결과의 경계로 검증한다

2편에서 본 것처럼 함수 호출과 실제 화면 반영은 다른 증거다. 테스트에서는 내부 호출 횟수보다 다음 사용자 결과를 확인한다.

• 같은 상태를 다시 전달해도 화면 결과가 불필요하게 달라지지 않는가?
• 새 상태를 전달하면 수량과 합계가 함께 바뀌는가?
• 이전 상태 객체가 변경되지 않은 채 로그와 비동기 처리에서 보존되는가?

같은 상황을 동일성 신호로 다시 진단한다

문제       처리 함수의 수량 로그는 2인데 화면은 1로 남음
잘못된 판단 객체 속성이 바뀌면 React가 내부 변경을 찾아낼 것임
관찰       Object.is(previousOrder, nextOrder)가 true
원인       이전 상태 객체를 직접 바꾸고 같은 객체를 다음 상태로 전달
행동       이전 객체를 보존하고 변경을 표현하는 새 객체를 상태 설정 함수에 전달
검증       Object.is(previousOrder, nextOrder)는 false이고 수량·합계가 함께 2로 바뀜

풀 리퀘스트에서는 다음 질문을 확인한다.

• 상태 객체의 속성을 직접 대입하거나 배열을 직접 변경하지 않는가?
• 상태 설정 함수에 이전과 같은 객체를 다시 전달하지 않는가?
• 화면 갱신 실패를 조사할 때 Object.is(previous, next)를 확인했는가?
• 함수 호출 횟수와 사용자에게 보이는 상태 변경을 같은 계약으로 만들지 않았는가?

기억할 축은 짧다.

속성이 달라진 것과 새 객체가 된 것은 다르다. React에는 다음 상태 값을 전달한다.

다음 글에서는 중첩 상태를 직접 바꾸지 않고 변경 경로에 새 객체를 만드는 방법과 그 이유를 살펴본다.