🎨 03. 불변성(Immutability)과 렌더 트리거 — 화면이 왜 안 변하죠?

🎯 이 섹션을 읽고 나면:

• 리액트가 렌더링을 시작할지 말지 결정하는 기준(Object.is 동등성 비교)을 설명할 수 있다.
• 상태의 배열이나 객체에 원본을 훼손(Mutate)했을 때 벌어지는 '침묵의 버그' 원인을 파악할 수 있다.
• 깊이가 깊은 객체를 안전하게 얕은 복사(Shallow Copy)하여 업데이트하는 법을 꿰뚫는다.

📋 목차

• 🤔 왜 알아야 하는가: 침묵하는 리액트의 함정
• 🏗️ 비유로 먼저 이해하기
• 🧩 불변성(Immutability)을 지키는 얕은 복사의 우아함
  • ❌ 영철이의 배열 폭파 사고
  • ✅ 영호의 리팩토링: Spread 연산자 던지기
• 💥 에러 해결 카탈로그
  • ❌ 중첩 객체(Nested Object)의 부분 갱신 누락 버그

📌 이 문서를 읽기 전에

⏱️ 예상 읽기 시간: 15분 / 핵심 파트: 8분

🗺️ 이 문서의 배경 세계관: '영수네 커뮤니티'

• 영철(신입): "어라? 유저 프로필 페이지에서 user.nickname = '새이름' 으로 직접 문자열을 바꿨는데 화면이 안 변해요. 로그 찍어보면 분명히 객체 값은 잘 들어가 있는데 말이죠! 리액트 버그 아닌가요?"
• 영호(리드): "영철 님... 리액트는 바빠서 객체 안의 내용물을 일일이 검사하지 않아요. 객체의 '껍데기 주소'가 그대로니까 안 바뀐 줄 알고 렌더링을 쿨하게 건너뛴 거잖아요!"

🤔 왜 알아야 하는가: 침묵하는 리액트의 함정

단순한 숫자나 문자는 값이 바뀌면 잘만 렌더링되던 리액트가, 유독 객체(Object)나 배열(Array) 상태를 다룰 때면 아무런 에러 메시지 하나 없이 "화면만" 업데이트에 실패하는 기괴한 현상을 겪어봤을 거야.

🤔 잠깐, 먼저 생각해봐
사용자 정보를 관리하는 코드야. 버튼을 누르면 화면의 닉네임이 바뀔까?

// ❌ 순진한 코드 (Naive Approach)
function UserProfile() {
  const [user, setUser] = useState({ id: 1, name: '초보영철' });
 
  const handleChangeName = () => {
    user.name = '마스터영철';  // 원본 객체 직접 수정 (Mutation)
    setUser(user);        // 변경된 상태 세팅!
  };
 
  return (
    <div>
      <p>유저 이름: {user.name}</p>
      <button onClick={handleChangeName}>이름 변경!</button>
    </div>
  );
}

영철이의 예상과 다르게 화면은 절대 마스터영철로 업데이트되지 않아. 마치 얼어붙은 것처럼.
대체 리액트 안에서 무슨 일이 일어난 걸까?

🏗️ 비유로 먼저 이해하기

🧒 5살에게 설명한다면?
엄마(리액트)가 쌍둥이 아기 두 명을 돌보고 있어. 엄마는 너무 바빠서 아기 얼굴을 자세히 보지 않고, 오직 아기방 문 앞에 붙은 명패(메모리 주소) 만 슬쩍 보고 지나가는 버릇이 있어.
네가 방에 들어가서 아기 한 명의 빨간 모자를 파란색으로 몰래 바꿔씌웠어(user.name = '마스터영철').
그리고 엄마한테 "저기 저 아기 확인해봐요!"(setUser(user)) 라고 불렀지만, 엄마는 문패만 봅니다.
"어? 문패 이름이 똑같네? 안 바뀐 거 다 아니까 귀찮게 하지 마." 하고 그냥 가버리는 거지. (새 집으로 이사 가지 않는 이상 무시함)

✅ 핵심 원리:
리액트는 성능을 아끼기 위해 극단적인 효율을 추구해. 상태가 바뀌었는지 판단할 때 객체 내부의 속성을 1차원부터 끝까지 싹 다 까서 비교하는 무거운 짓(깊은 비교)을 하지 않아.
오직 자바스크립트의 Object.is() (쉽게 말해 === 일치 연산자)를 통해 껍데기의 메모리 참조 주소값이 변경되었는지만 0.001초 만에 비교해 버리지. 객체 내부를 백날 쑤시고 뜯어 고쳐봤자, 껍데기 주소가 같으면 리액트는 절대 화면을 다시 그리지 않아. 이를 불변성(Immutability) 을 지키지 않은 경우라고 불러.

🧩 불변성(Immutability)을 지키는 얕은 복사의 우아함

❌ 영철이의 배열 폭파 사고

게시글에 달린 댓글(배열)들을 다룰 때도 똑같은 일이 벌어져. 배열에 댓글을 추가했는데 화면에 새 댓글이 안 떠.

// ❌ 영철이의 Naive 배열 업데이트
const [comments, setComments] = useState(['재밌네요', '퍼가요']);
 
const handleAddComment = () => {
  comments.push('반사요~'); // 배열 원본 훼손 (Mutation)
  setComments(comments);  // 주소값이 그대로이므로 렌더링 씹힘!
};

push, pop, reverse, splice 같은 애들은 기존 메모리 통(배열 원본)을 박살 내고 내부를 바꾸는 악당들이야. 리액트에서 이런 애들을 혐오해.

✅ 영호의 리팩토링: Spread 연산자 던지기

부서진 원본을 고치는 게 아니라, 아예 깔끔한 새 집(새로운 참조 주소) 을 사서 기존 짐들을 복붙해 오는 전략이 필수야. 이게 그 유명한 마침표 세 개 ... (스프레드 문법)의 존재 이유지.

// ✅ 우아한 코드 (Pro Approach)
const handleAddComment = () => {
  // 새로운 배열 껍데기 []를 만들고, 기존 짐(...comments)을 풀고, 맨 뒤에 새 댓글을 추가한다.
  setComments([...comments, '반사요~']); 
};

새로운 []가 선언되는 순간 완전히 새로운 메모리 문패가 탄생하고, 리액트는 "앗! 문패가 달라졌네! 리렌더링 해야지!" 하고 기분 좋게 움직이게 돼.

💥 에러 해결 카탈로그

❌ 중첩 객체(Nested Object)의 부분 갱신 누락 버그

언제 나오는가?

const [user, setUser] = useState({
  name: '영철',
  address: { city: 'Seoul', zip: '123' },
});
 
const handleCityChange = () => {
  setUser({
    ...user, // 얕은 복사
    address: { city: 'Busan' }, // 💥 zip 데이터가 날아가버림!
  });
};

원인: 스프레드 연산자 ...는 껍데기 한 꺼풀만 '새 집'으로 복사해 주는 얕은 복사(Shallow Copy) 도구야. address라는 안방 문짝까지 새걸로 갈아끼워 주지는 않아. 그래서 덩치 큰 JSON 덩어리의 깊숙한 곳을 바꿀 때 머리가 터져나가게 되지. 매번 { ...user, address: { ...user.address, city: 'Busan' } } 처럼 끝도 없이 복사 껍질을 까야 하니까 유지보수 지옥(Maintenance Nightmare)이 펼쳐져.

해결책:
이럴 땐 스프레드만 믿지 말고 리액트 생태계의 구원자, Immer 같은 불변성 라이브러리를 도입하는 게 프로들의 정석이야.

import { produce } from "immer";
 
const handleCityChange = () => {
  setUser(produce((draft) => {
    // 마치 'mutatation(직접 수정)' 하는 것처럼 짜면, Immer가 알아서 복사본을 리턴해줘!
    draft.address.city = 'Busan'; 
  }));
}

🏁 이번에 배운 내용 총정리

💡 한 줄로 기억하기
리액트의 눈은 흐릿하다. 집(객체) 내부에 있는 소파 시트 색깔이 바뀌었다고 알아채지 못한다. 새로운 집을 통째로 이사(... 사용)해야만 비로소 눈을 비비며 렌더링에 돌입한다.

🐣 영철이의 퇴근 일기

배열에 push 하고 왜 화면 안 바뀌지 하면서 삽질했던 어제의 나... 리액트가 객체 속까지 일일이 까보지 않고 껍데기(메모리 주소)만 본다는 사실을 깨닫고 나니 렌더링 트리거 매커니즘이 확 이해됐다. 영호 님이 쌍둥이 아기 비유해주셨을 때 진짜 명쾌했다.

💡 "리액트의 눈은 흐릿하다! 객체나 배열을 건드릴 땐 원본을 훼손하지 말고 무조건 얕은 복사(... 스프레드 연산자)로 새 집을 파주자."

앞으로는 깊은 복사 하느라 중첩 스프레드로 고통받지 말고, 내일 당장 팀 프로젝트에 Immer를 도입하자고 건의해 봐야겠다. 조금씩 프로 프론트엔드 개발자의 시야가 생기는 것 같아 뿌듯하다. 얼른 헬스장 가서 땀 쫙 빼고 꿀잠 자야지.

📝 마무리 퀴즈

Q1. 자바스크립트의 배열 메서드 중에서 불변성을 해치는 악당(Mutating method)과 원본을 보존하는 천사(Non-mutating method)가 섞여 있습니다. 리액트 상태에 직접 때려박으면 치명타를 입히는 악당만을 묶은 것은?

• A) splice(), map(), push()
• B) filter(), map(), concat()
• C) push(), pop(), reverse(), splice()
• D) slice(), filter(), reduce()

✅ 정답: C

💡 상세 해설: 리액트 배열 상태를 건드릴 때 B나 D의 메서드들(map, filter, concat, slice 등)은 함수 실행 결과로 "완전히 새로운 배열"을 리턴하기 때문에 안전합니다(천사). 하지만 C에 나열된 메서드들은 메모리에 이미 할당된 원본 배열 자체의 내용을 찢어발기거나 덧댄 후 기존 주소를 그대로 반환합니다(악당). 그래서 리액트가 변화를 감지하지 못하고 렌더링을 멈추게 만듭니다.

Q2. 두 개의 자바스크립트 객체의 일치 여부에 대한 질문입니다. 코드 실행 결과를 맞혀보세요.

const obj1 = { name: "영호" };
const obj2 = { name: "영호" };
console.log(Object.is(obj1, obj2)); // 또는 obj1 === obj2

• A) true (내부 내용물이 완벽히 같으므로)
• B) false (메모리에 할당된 고유 참조 주소값이 엄연히 다른 두 개의 집이므로)
• C) undefined (알 수 없음)

✅ 정답: B

💡 상세 해설: 이게 리액트가 깊은 렌더링 감지를 포기하고 얕은 비교(===)를 하는 이유입니다. 모양과 속성이 100% 똑같더라도 컴퓨터의 힙(Heap) 공간에 따로 방을 팠기 때문에 주소가 다릅니다. 역으로 말하면, let a = { id: 1 }; let b = a; b.id = 2;라고 했을 때 a === b는 무조건 true가 나옵니다. 같은 방이니까요! 리액트가 껍데기만 쳐다볼 때 이를 헷갈리게 하면 방금 영철이 같은 대참사가 일어납니다.

Q3. '불변성'을 지킨답시고 아래처럼 긴급 수정을 도입했지만 여전히 문제가 존재합니다. 무엇이 잘못되었는지, 완벽한 해결책과 원리(얕은 복사의 한계)를 설명해보세요.

const [serverConfig, setConfig] = useState({ 
  port: 8080, 
  settings: { timeout: 3000 } 
});
 
const reduceTimeout = () => {
  const newConfig = { ...serverConfig }; // 오, 불변성 지켰다!
  newConfig.settings.timeout = 1000;     // 직접 수정?
  setConfig(newConfig);
};

✅ 정답 및 주관식 해설:

원인(Why): 놀랍게도 부분적인 치명타를 입습니다! newConfig = { ...serverConfig }는 얕은 복사(Shallow Copy)로, 바깥쪽 껍데기(serverConfig 자체)의 메모리 주소는 새것으로 바뀌었습니다. 그래서 리액트는 "앗! 바뀌었네?" 하고 렌더링에 돌입하긴 합니다.
하지만! 얕은 복사 특성상 내부에 있는 자식 객체 settings의 메모리 주소는 완전히 옛날 것과 동일하게 복사되어 연결되어 있습니다. 만약 자식 컴포넌트 중 일부가 React.memo 등으로 최적화되어 있다면, 걔네들은 settings 주소가 안 바뀌었으므로 렌더링을 거부하는 파편화 버그가 생깁니다.
해결 로직: 내부의 중첩 객체까지 완전히 새로 복사해 주어야 합니다. setConfig({ ...serverConfig, settings: { ...serverConfig.settings, timeout: 1000 } }) 처럼 각 깊이마다 독립된 얕은 복사를 수행하거나, 제일 속 편하게 Immer 라이브러리를 사용해 깔끔하게 우회하는 게 정석입니다.