💡 06. useEffect 파괴하기 (2): 의존성 배열의 거짓말

🎯 이 섹션을 읽고 나면:

• IDE(에디터)가 띄워주는 react-hooks/exhaustive-deps 경고를 왜 절대 무시하면 안 되는지 깨닫는다.
• 함수나 객체를 의존성 배열에 넣었을 때 불필요하게 타이머가 계속 재시작되는 원인(메모리 참조값 리셋)을 완전히 이해한다.
• 효과 내부에서 필요한 함수를 어떻게 배치해야 무한 렌더 트리거를 피할 수 있는지 우아한 설계법을 체득한다.

📋 목차

• 🤔 왜 알아야 하는가: 리액트에 거짓말을 한 대가
• 🏗️ 비유로 먼저 이해하기
• 🧩 함수와 객체, 올바르게 쥐어주기
  • ❌ 영철이의 회피 기동
  • ✅ 영호의 리팩토링: 컴포넌트 밖으로 치우거나 풀어헤쳐라
  • 함수(Functions)를 Effect 위에서 부를 때의 규칙

📌 이 문서를 읽기 전에

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

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

• 영철(신입): "의존성 배열에 뭐 넣으라고 노란색 lint 경고줄이 엄청 뜨는데, 넣으니까 페이지가 무한 새로고침 되면서 뻗어버리던데요? 그래서 그냥 경고 무시하는 주석(// eslint-disable-next-line) 달았습니다!"
• 영호(리드): "영철 님... 리액트에게 거짓말을 하면 그 대가는 사용자의 브라우저 메모리 폭발로 돌아옵니다. 지금 당장 그 주석부터 지우시죠."

🤔 왜 알아야 하는가: 리액트에 거짓말을 한 대가

useEffect를 사용하다 보면 거의 모든 주니어 프론트엔드 개발자들이 의존성 배열(Dependency Array, [])의 장벽에 부딪힙니다.

🤔 잠깐, 먼저 생각해봐
특정 옵션(options)이 바뀌면 API 데이터를 가져오려고 해.
왜 아래 코드를 실행하면 무한 루프(요청 폭격기)에 빠져서 백엔드(영수) 서버가 터져버릴까?

// ❌ 영철이의 백엔드 테러 코드 (DDOS 수준)
function ProductList() {
  const [data, setData] = useState(null);
  
  // 영철: "아! 조건 옵션 객체를 만들어둬야지."
  const options = { limit: 10, sort: 'desc' };
 
  // 영철: "API를 호출하는 effect니까, options 옵션이 바뀔 때마다 실행되어야지!"
  useEffect(() => {
    fetchData('/api/products', options).then((res) => setData(res));
  }, [options]); // 🚨 에러 폭탄 트리거! 무한 루프!
 
  return <div>{JSON.stringify(data)}</div>;
}

VS Code는 의존성에 대해 어떠한 에러도 띄우지 않습니다. 하지만 이 컴포넌트는 무한히 리렌더링되며 초당 10번씩 서버에 API 요청을 때립니다.

영철이는 당황해서 의존성 배열을 수동으로 [] 빈 껍데기로 바꾸고(거짓말), 노란 경고줄을 무시하는 주석을 달아버립니다. 과연 이 코드는 무엇이 문제였을까요?

🏗️ 비유로 먼저 이해하기

🧒 5살에게 설명한다면?
엄마(리액트)가 영철이에게 잔소리를 합니다. "네가 손에 쥐고 있는 과자 봉지(의존성 options)가 바뀌면 내가 저기 가서 창문 열어줄게(useEffect 실행)."

1. 방을 새로 꾸밀 때마다(리렌더링) 리액트는 options = { limit: 10 } 이라는 새 과자 봉지를 하나 뜯습니다.
2. 엄마가 묻습니다. "저번 렌더링 스냅샷 때 쥔 과자봉지(과거 options)랑, 방금 새로 선언된 과자봉지(현재 options)랑 똑같아?"
3. 영철이가 대답합니다. "내용물(10)은 같은데요, 포장지 껍데기(메모리 주소값)가 완전 새 거예요! 무조건 새로 뜯었거든요!" (객체 얕은 동등성 실패)
4. 엄마: "어? 과자가 바뀌었네! 창문 다시 연다!! (useEffect 실행 -> setData 호출 -> 리렌더링 발생 -> 1번으로 돌아가 무한 반복)"

✅ 핵심 원리:
03. 불변성 문서에서 배웠지? 자바스크립트는 객체나 배열, 함수를 매번 호출(새 리렌더링)할 때마다 내용이 완벽히 똑같아도 힙(Heap) 메모리에 새로운 주소로 할당해버립니다.
이 객체/함수 참조(Reference)가 useEffect의 의존성 감시기(감시봇)에 들어가면, 감시봇은 "앗! 주소가 달라졌다! 데이터가 바뀌었네!" 라고 착각하고 무조건 Effect 훅을 재실행해 버립니다. Effect 안에서 setData까지 쳤으니, 이는 끝없는 재렌더링과 Effect 재호출의 무간지옥(무한 루프)이 되는 겁니다.

🧩 함수와 객체, 올바르게 쥐어주기

❌ 영철이의 회피 기동

영철이는 이 무한 루프를 겪자, 무서워서 강제로 의존성 배열에서 options를 지워버립니다.

  useEffect(() => {
    fetchData('/api/products', options).then((res) => setData(res));
    // eslint-disable-next-line react-hooks/exhaustive-deps
  }, []); // 🚨 리액트에 거짓말을 했음.

이렇게 하면 루프는 멈춥니다! 하지만 진짜 치명적인 버그가 잠복하게 됩니다. 만약 유저가 옵션을 '10개 보기'에서 '50개 보기'로 버튼을 눌러 변경하면, options 변수는 바뀌지만 useEffect는 자신이 의존하는 값이 안 바뀌었다([]이므로 변할 일 없음)고 생각해서 평생 새 데이터를 동기화(Fetch)해 오지 않는 얼어붙은 UI 상태 가 됩니다. 리액트에게 거짓말을 한 대가죠.

✅ 영호의 리팩토링: 컴포넌트 밖으로 치우거나 풀어헤쳐라

방법 1. 어차피 고정인 데이터면 컴포넌트 스코프 밖으로 탈옥시켜라!
의존성에 걸리적거리는 객체가 상태(State)와 전혀 무관한 정적(Static) 환경 설정이라면, 컴포넌트 함수 밖(모듈 스코프)으로 올리면 끝납니다. 이 객체는 평생 딱 한 번만 만들어지므로 참조 주소가 바뀔 일이 없죠.

// ✅ 우아한 탈출 (Pro Approach 1)
const options = { limit: 10, sort: 'desc' }; // 밖으로 빼버리기!
 
function ProductList() {
  const [data, setData] = useState(null);
  
  useEffect(() => {
    // 이제 options는 의존성 배열의 감시대상에서 완벽히 면제됩니다.
    fetchData('/api/products', options).then((res) => setData(res));
  }, []); 
}

방법 2. 객체 말고 원시값(Primitive) 그 자체로 분해해서 감시해라!
나중에 버튼으로 limit을 바꿀 수 있는 (State와 연동되는) 유동적 객체라면? 껍데기(객체 참조)를 파괴하고 속성 알맹이(숫자, 문자열 등 원시 타입)로 직접 풀어헤쳐서 감시망에 넣으세요.

// ✅ 원시값 추출법 (Pro Approach 2)
function ProductList({ limit }) { // limit는 props (숫자 타입)
  const [data, setData] = useState(null);
  
  // 객체를 렌더링 내부에 선언하지 말고 리터럴로 직투입
  useEffect(() => {
    fetchData('/api/products', { limit: limit, sort: 'desc' })
      .then((res) => setData(res));
  // 🎯 객체 껍데기가 아니라 변하지 않는 원시값(숫자 형의 limit)을 의존성으로!
  }, [limit]); 
}

함수(Functions)를 Effect 위에서 부를 때의 규칙

함수도 객체와 100% 동일하게 취급되어, 매 렌더링마다 껍데기(주소)가 바뀝니다. fetchProduct() 같은 함수를 무심코 Effect 안에서 호출하고 의존성 배열에 넣으면 무한루프를 타죠.
이 딜레마를 푸는 기법은 아주 명확합니다.

1. 최고의 방법: 정말 useEffect 안에서만 쓰는 함수라면, 함수 정의 자체를 아예 useEffect 괄호 안쪽 방구석으로 밀어 넣으세요. 의존성 배열에 그 함수 이름을 통째로 적지 않아도 됩니다.
2. 부득이하게 컴포넌트 다른 곳(버튼 클릭 등)에서도 그 바깥 함수를 호출해야 한다면? 그때만 어쩔 수 없이 useCallback으로 껍데기(참조)를 얼려버리고 의존성 배열에 넣어야 합니다.

🏁 이번에 배운 내용 총정리

💡 한 줄로 기억하기
단언컨대, 노란색 lint 경고(exhaustive-deps)가 뜨면 무시 주석을 치는 대신 당신의 컴포넌트 객체/함수 분리 구조가 더럽다는 것을 시인하라. 리액트의 감시봇은 객체와 함수의 내용물은 까보지도 않은 채, 그저 '껍데기(포장지)가 새로 나왔군' 하며 무조건 사이렌을 울릴 뿐이다.

🐣 영철이의 퇴근 일기

진짜 여태껏 내가 짰던 코드 중에 조용히 좀비처럼 멈춰있던 버그들이 다 의존성 배열 거짓말 때문이었다니. 노란 줄 띄우는 lint가 나를 괴롭히는 악마인 줄 알았는데 사실 내 생명줄을 잡아주고 있었던 거다.

💡 "리액트에게 거짓말 치지 말자! 객체 껍데기와 함수 참조값이 매번 새로 붕어빵 찍히듯 만들어지는 원리를 알면, 의존성 배열은 무섭지 않다."

기획이 바뀌면 언제든지 터질 시한폭탄을 만들고 있었다니 식은땀이 난다. 그래도 영호 리드 님이 어떻게든 원시값 뽑아내거나 함수 위치를 깊숙이 넣어서 해결하는 꿀팁을 다 전수해 주셨다. 오늘은 뭔가 깨달음의 밀도가 대단히 높았다. 기분 좋게 퇴근해서 넷플릭스 한 편 때리고 꿀잠 가야겠다!

📝 마무리 퀴즈

Q1. 아래 영철이가 무한 렌더링 폭탄을 피하기 위해 짠 코드입니다. lint에서 fetchUserData 함수를 의존성 배열에 넣으라고 경고하지만, 영철이는 그냥 주석으로 무시했습니다. 가장 올바르고 깔끔한 리팩토링 해결책은 무엇인가요?

function UserCard({ userId }) {
  const [user, setUser] = useState();
 
  // 밖에서 선언해버림!
  const fetchUserData = async () => {
    const res = await fetch(`/api/user/${userId}`);
    setUser(res);
  };
 
  useEffect(() => {
    fetchUserData();
    // eslint-disable-next-line
  }, [userId]); 
 
  // ...
}

• A) fetchUserData 함수를 useCallback으로 무조건 감싸고 의존성 배열에 넣는다.
• B) fetchUserData 함수 자체를 아예 useEffect 괄호 내부 깊숙이(콜백 안쪽으로) 이동시킨다. (다른 버튼에서 이 함수를 누를 일이 없으므로)
• C) 무한 루프가 돌더라도 경고 주석을 포기하고 의존성에 [userId, fetchUserData]를 몽땅 넣는다.
• D) useRef를 만들어서 함수를 그 안에 숨겨 넣는다.

✅ 정답: B

💡 상세 해설: 가장 흔하면서 고귀한 해결책입니다. 해당 함수가 외부 클릭 이벤트 등 어느 다른 곳에서도 쓰이지 않고 오로지 마운트/동기화 시점에 딱 한 번 저 Effect 안에서만 발동되는 것이라면, 밖에서 쓸데없이 메모리 껍데기(참조)를 새로 붕어빵 찍어낼 이유가 없습니다. useEffect(() => { const fetchUserData = async () => { ... }; fetchUserData(); }, [userId]); 처럼 이사시키면, lint 경고도 완벽히 사라지고 메모리도 깔끔해지며 '불필요한 useCallback 연산'마저 아낄 수 있습니다!

Q2. 자바스크립트의 Primitive(원시) 타입과 Reference(참조) 타입을 Effect가 감시할 때 나타나는 차이를 묻는 질문입니다. 다음 중 useEffect의 괄호 [ ] 배열에 단독으로 배치되었을 때, 매 렌더링 시마다 내용물이 같더라도 "바뀌었다!"고 리액트가 100% 착각하게 만드는 타입들만 고른 것은?

• A) 200, 'success', false (숫자, 문자, 불리언)
• B) {}, [], () => {} (빈 객체, 빈 배열, 화살표 함수)
• C) null, undefined, NaN
• D) 이 중 정답 없음 (리액트는 완벽해서 착각하지 않음)

✅ 정답: B

💡 상세 해설: 아주 중요한 0.1초의 동등성 판별 로직(Object.is)입니다. A나 C 같은 원시(Primitive) 타입들은 200 === 200 처럼 값 자체가 메모리 그 자체이므로 리액트가 렌더링 스냅샷 간에 전혀 헷갈리지 않습니다. 하지만 B와 같이 리터럴로 선언되는 참조(Reference) 타입들은 렌더링할 때마다 새로운 힙(Heap) 공간에 방이 파지며 메모리 주소(껍데기)가 교체되므로, 내용물이 비어 똑같더라도 리액트는 무조건 false(다르다) 판정을 내려버려 Effect 부작용을 트리거합니다.

Q3. 영철이가 "어차피 제가 짠 거니까 제가 제일 잘 알아요. 이 경고 주석(eslint-disable) 무시해도 앱 안 터지고 잘 돌아가는데요?" 라고 우길 때, 영호가 조용히 [categoryId] 의존성을 손으로 가리키며 짚어줄 수 있는 '미래에 닥칠 진짜 치명적인 버그 시나리오'를 구체적으로 작성해 보세요.

✅ 정답 및 주관식 해설:

"영철 님, 당장은 컴포넌트 최초 마운트 시 한 번만 호출되어서 잘 된다고 착각하시겠죠. 하지만 미래에 기획이 변경되어 화면 좌측에 사이드바 카테고리 버튼들(categoryId=1, 2, 3... 변경)이 생긴다면 어떻게 되나요?
의존성 배열을 []로 강제로 도려내고 주석을 친 순간, 우리는 리액트에게 '이 Effect 덩어리는 외부 세계의 어떠한 환경(프로퍼티 등)이 변해도 절대 다시 동기화할 필요가 없다!' 라고 거대한 서약을 맺은 셈입니다.
사용자가 백날 다른 카테고리를 눌러서 categoryId 값(State)이 변경되더라도, 이미 귀를 닫아버린 Effect는 결코 새 API 호출을 때리지 않습니다 (동기화 거부). 껍데기 UI는 전자기기 카테고리(3)를 누르고 있는데, 상품 목론은 영원히 옷 카테고리(1)에 얼어붙어 있는 '치명적인 침묵(Stale Data 렌더링) 버그'가 탄생하는 겁니다."