Mutable vs Immutable 업데이트

Mutable 업데이트

Mutable(가변) 업데이트는 기존 객체나 배열 자체를 직접 변경하는 방식입니다.

 

---

const user = { name: 'Alice', age: 20 };

user.age = 21; // 기존 객체 변경

• 배열도 마찬가지입니다.

const list = [1, 2, 3];
list.push(4); // 기존 배열 변경

 

• 코드가 짧고 직관적
• 메모리 사용량이 적음
• 변경 추적이 어려움
• 상태 관리 / 렌더링에서 문제 발생 가능

---

2. Immutable 업데이트란?

Immutable(불변) 업데이트는 기존 데이터는 유지하고, 새 객체 / 새 배열을 만들어 변경하는 방식입니다.

---

const user = { name: 'Alice', age: 20 };

const newUser = {
  ...user,
  age: 21
};

 

const list = [1, 2, 3];
const newList = [...list, 4];

• 변경 지점이 명확함
• 참조(reference) 비교가 쉬움
• 프레임워크 최적화와 궁합이 좋음
• 객체/배열 생성 비용 발생

 

---

 

왜 프론트엔드에서는 Immutable이 중요할까?

핵심 이유: 참조(reference) 비교

Angular와 React는 많은 경우
값 자체가 아니라 참조가 바뀌었는지로 변경 여부를 판단합니다.

즉,

• 값은 바뀌었지만
• 참조가 그대로라면
• "변경되지 않았다"고 판단할 수 있습니다.

 

---

React에서의 문제 예시

Mutable 업데이트

const [list, setList] = useState<number[]>([]);

const addItem = () => {
  list.push(1);
  setList(list); // 같은 참조
};

 

• 배열 내부 값은 변경됨
• 참조는 동일
• React는 변경 없음으로 판단
• 리렌더링 안 됨

Immutable 업데이트

const addItem = () => {
  setList(prev => [...prev, 1]);
};

• 새 배열 생성
• 참조 변경
• React 정상 리렌더링

---

Angular에서도 동일한 문제 발생

특히 다음 상황에서 중요합니다.

• OnPush Change Detection
• signal / computed

Mutable (Signal)

items = signal<number[]>([]);

addItem() {
  this.items().push(1);
  this.items.set(this.items());
}

• 배열 참조 동일
• signal 변경 감지 실패

Immutable

addItem() {
  this.items.update(list => [...list, 1]);
}

• 새 배열 반환
• signal 정상 반응

 

---

"값은 바뀌었는데 UI가 안 바뀌어요"의 정체

실무에서 매우 흔한 상황입니다.

• 서버 업데이트는 됨
• 콘솔 찍어보면 값도 바뀜
• 그런데 화면은 그대로

대부분 원인은 mutable 업데이트입니다.

프레임워크는 값 변경이 아니라 참조 변경을 보고 있기 때문입니다.

 

언제 Mutable이 허용될까?

Immutable이 항상 정답은 아닙니다.

Mutable이 괜찮은 경우

• 함수 내부 임시 변수
• UI와 무관한 계산용 데이터
• 상태로 관리되지 않는 로컬 객체

const temp = { count: 0 };
temp.count += 1; // 문제 없음

Immutable을 써야 하는 경우

• React state
• Angular signal / @Input
• 상태 관리 라이브러리 (Redux, NgRx 등)
• 렌더링과 연결된 데이터

 

---

요약

상황	권장 방식
UI 상태	Immutable
상태 관리	Immutable
Change Detection 대상	Immutable
임시 계산 데이터	Mutable