💡 05. useEffect 파괴하기 (1): 진실 — 생명주기가 아니라 동기화다

🎯 이 섹션을 읽고 나면:

• useEffect를 componentDidMount 같은 생명주기 메서드로 생각하는 낡은 멘탈 모델을 버릴 수 있다.
• "리액트의 상태(State)와 외부 시스템(Network, DOM)의 상태를 언제나 같게 맞춘다(동기화)"는 개념을 설명할 수 있다.
• 불필요한 useEffect 사용을 즉각 찾아내어 삭제할 수 있다.

📋 목차

• 🤔 왜 알아야 하는가: 낡은 생명주기의 망령
• 🏗️ 비유로 먼저 이해하기
• 🧩 동기화(Synchronization)의 완벽한 적용
  • ✅ 영호의 리팩토링: 외부 시스템과의 동조
• 💥 에러 해결 카탈로그
  • ❌ 무의미한 상태 파생(Derived State)에 Effect 남용하기

📌 이 문서를 읽기 전에

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

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

• 영철(신입): "채팅방 컴포넌트가 화면에 뜰 때(mount) 서버에 연결하고, 사라질 때(unmount) 끊어야 하니까 무조건 useEffect를 써야죠!"
• 영호(리드): "영철 님... useEffect는 무언가를 '실행'하기 위한 게 아니라, 리액트 바깥 세상과 '동기화'하기 위한 도구입니다. 생명주기라는 환상에서 깨어나세요."

🤔 왜 알아야 하는가: 낡은 생명주기의 망령

과거 리액트를 클래스형 컴포넌트로 짜던 시절에는 componentDidMount (화면에 처음 뜰 때), componentDidUpdate (업데이트될 때) 같은 뚜렷한 시점(Lifecycle, 생명주기) API들이 있었어.
함수형 컴포넌트(Hooks)가 도입된 이후, 많은 개발자들이 useEffect를 그저 "옛날 생명주기 API들을 하나로 합친 만능 툴"이라고 착각했지.

🤔 잠깐, 먼저 생각해봐
"이 코드는 화면에 처음 뜰 때만 한 번 실행되어야 하니까 useEffect(..., []) 안에 쓰면 완벽해!" 라고 생각한 적 있지?

// ❌ 생명주기 마인드로 짠 영철이의 코드
function ChatRoom({ roomId }) {
  useEffect(() => {
    // "컴포넌트가 처음 마운트될 때 무조건 한 번 실행해!" (오해)
    const connection = createConnection();
    connection.connect(roomId);
    
    return () => {
      // "언마운트될 때 끊어!"
      connection.disconnect();
    };
  }, []); // 🚨 치명적 버그: 의존성 배열을 의도적으로 비웠음
  
  return <h1>{roomId}번 채팅방</h1>;
}

위 코드는 끔찍한 버그를 낳아. 사용자가 '1번 방'에서 '2번 방'으로 넘어갔어(roomId prop이 2로 바뀜).
하지만 영철이는 useEffect를 "처음 뜰 때 한 번만([]) 실행하는 놈"이라고 굳게 믿었기 때문에, 화면에는 "2번 채팅방"이라고 뜨지만 실제 네트워크 연결은 여전히 옛날 1번 방에 연결되어 있는 대참사가 발생해.

🏗️ 비유로 먼저 이해하기

🧒 5살에게 설명한다면?
❌ 영철이의 생각 (생명주기 패러다임 - 명령형):
"비서야, 내가 아침에 출근할 때(Mount)만 딱 한 번 에어컨을 24도로 틀어라! 그리고 퇴근할 때(Unmount) 꺼라!"
(만약 낮에 너무 더워서 사장님이 사내 규정을 '에어컨 20도'로 내려도, 비서는 출근할 때 이미 일을 끝냈으므로 퇴근할 때까지 온도 조절기를 쳐다보지도 않는다.)

✅ 영호의 생각 (동기화 패러다임 - 선언형):
"비서야, 사무실 온도(외부 시스템)를 항상 현재 우리 회사 사내 규정 문서(리액트 State/Props)와 일치시켜 놔라(Synchronize)."
(규정 문서에 적힌 온도가 24도에서 20도로 바뀌는 순간, 비서는 즉시 에어컨 리모컨을 조작해 사무실 온도를 규정과 동기화시킨다.)

✅ 핵심 원리:
React의 창시자 중 한 명인 Dan Abramov가 말했어. "useEffect는 컴포넌트 생명주기와는 아무 상관이 없다."
useEffect의 유일한 목적은 리액트가 모르는 외부 세계(서버 연결, 로컬스토리지, 쌩 DOM 조작 등)를 현재 리액트의 상태(State/Props)와 맞추어 동기화(Synchronize)시키는 것이야.

🧩 동기화(Synchronization)의 완벽한 적용

✅ 영호의 리팩토링: 외부 시스템과의 동조

영철이의 코드를 '동기화' 패러다임에 맞게 고쳐볼까?
"채팅 서버와의 연결 상태(외부 시스템)를 항상 현재 컴포넌트가 받은 roomId prop과 동기화시켜라!"

// ✅ 동기화 마인드로 짠 우아한 코드
function ChatRoom({ roomId }) {
  
  // "난 이 Effect 덩어리가 언제(mount/update) 실행될지 관심 없어."
  // "다만, roomId가 바뀌면 무조건 옛날 연결을 부수고 새 방에 동기화시켜 줘!"
  useEffect(() => {
    const connection = createConnection();
    connection.connect(roomId); // roomId(현재 상태)로 서버에 연결
    
    return () => {
      // 다음 동기화가 일어나기 전, 혹은 컴포넌트가 죽기 전에 잔재를 치운다(Cleanup)
      connection.disconnect(); 
    };
  }, [roomId]); // 🎯 의존성 배열에 '동기화할 기준'을 명시
 
  return <h1>{roomId}번 채팅방</h1>;
}

이제 리액트는 이렇게 작동해:

1. roomId = 1 로 렌더링 → 1번 방 연결!
2. 유저가 방을 2로 바꿈 (roomId = 2 렌더링 스냅샷 생성)
3. 리액트: "어? 규칙([roomId])이 바뀌었네? 다시 동기화해야겠다."
4. 리액트: 먼저 1번 방 연결을 청소(disconnect)하고, 새로 2번 방 연결을 시작(connect)!

이것이 useEffect의 진짜 존재 이유야.

💥 에러 해결 카탈로그

❌ 무의미한 상태 파생(Derived State)에 Effect 남용하기

상황:

function SearchBox({ users }) {
  const [query, setQuery] = useState('');
  const [filtered, setFiltered] = useState([]); // 🚨 냄새가 난다
 
  // 사용자가 타이핑(query 변경)할 때마다 필터링된 배열을 다시 만들고 싶어!
  useEffect(() => {
    const result = users.filter(u => u.name.includes(query));
    setFiltered(result);
  }, [query, users]); 
  
  // ...

원인: 리액트 공식 문서 ("You Might Not Need an Effect") 에서 가장 경계하는 "가장 멍청한 형태의 Effect 남용" 이야.
users와 query는 무언가 화면 바깥의 외부 시스템(API 등)인가요? ❌ 아닙니다.
단순히 리액트 내부의 props와 state일 뿐이죠. 내부 데이터를 가공하는 데 useEffect를 쓰면 안 됩니다. 이 코드는 타이핑할 때마다 불필요하게 필터링을 하고, setFiltered 트리거를 통해 재앙 같은 추가 리렌더링(리렌더링이 2번씩 발생) 을 만들어냅니다.

해결책:
Effect를 과감하게 도려내세요!

function SearchBox({ users }) {
  const [query, setQuery] = useState('');
  
  // ✅ 렌더링 스냅샷 도중에 그냥 계산해버리세요! (파생 상태)
  // 어차피 query가 바뀌면 리더링이 도니까 그때 한 번 계산하면 끝.
  const filtered = users.filter(u => u.name.includes(query));
  // ...

🏁 이번에 배운 내용 총정리

💡 한 줄로 기억하기
useEffect는 콜백(함수)을 특정 시점에 실행시키기 위한 발사 버튼이 아니다. 화면 바깥의 무법지대(외부 시스템)를 내부의 리액트 국법 ("State/Props") 체제로 맞추어 강제로 동기화시키는 '국경 경찰' 이다.

🐣 영철이의 퇴근 일기

여태껏 useEffect를 그냥 부팅할 때 딱 한 번 실행되는 componentDidMount의 최신 버전이라고만 치부해 온 나를 매우 친다. 화면이랑 데이터가 따로 노는 버그가 왜 터졌는지 이제야 미스터리가 풀렸다.

💡 "useEffect는 생명주기 API가 아니라 외부 시스템과의 완벽한 '동기화 체제'다. 파생 상태 연산에 쓸데없이 남용하지도 말자!"

'에어컨 온도 동기화' 비유를 들으니까 머리가 맑아지는 기분이다. 이제 렌더링 단계에서 처리할 수 있는 파생 상태는 무조건 밖으로 빼야지. 영호 님 덕에 코드의 악취를 하나 더 알아차리게 됐다. 집에 가서 오늘은 맥주 한 캔 까며 진짜 푹 쉴 자격이 있다 내 자신!

📝 마무리 퀴즈

Q1. useEffect의 진정한 목적과 가장 부합하는 설명은 무엇인가요?

• A) 컴포넌트가 화면에 마운트(추가)되거나 언마운트(제거)되는 시점을 정확히 감지하여 코드를 실행시키기 위함.
• B) 리액트 컴포넌트 외부의 시스템(예: 브라우저 DOM API, 서버 네트워크 연결, 서드파티 라이브러리)을 현재 리액트 컴포넌트의 상태(State)와 일치(Synchronize)시키기 위함.
• C) 무거운 연산(필터링, 맵핑 등)이 메인 렌더링에 영향을 주지 않도록 백그라운드 스레드로 격리하여 실행시키기 위함.
• D) 사용자의 클릭 이벤트 등 모든 상호작용 피드백 로직을 중앙에서 관리하기 위함.

✅ 정답: B

💡 상세 해설: 만약 무거운 연산을 캐싱하고 싶다면 useMemo를 써야 하며(C 오답), 사용자 클릭 이벤트를 다룰 땐 useEffect가 아니라 그냥 이벤트 핸들러(onClick)를 써야 합니다(D 오답). 특히 A는 클래스형 컴포넌트 시절의 구시대적 마인드입니다. useEffect는 오로지 외부 세계(React 패러다임이 통제 못하는 곳)와의 동기화(Syncing) 만을 위해 예약된 아주 비싼(느린) 도구입니다.

Q2. 다음 영철이의 코드 중 불필요하게 useEffect를 남용한 흔적(안티 패턴)을 제거하고, 어떻게 고쳐야 할지 설명해보세요.

function ProfileForm() {
  const [firstName, setFirstName] = useState('');
  const [lastName, setLastName] = useState('');
  const [fullName, setFullName] = useState('');
 
  useEffect(() => {
    setFullName(firstName + ' ' + lastName);
  }, [firstName, lastName]);
  
  return (/* ... */);
}

✅ 정답 및 주관식 해설:

고친 코드:

function ProfileForm() {
  const [firstName, setFirstName] = useState('');
  const [lastName, setLastName] = useState('');
  
  // Effect와 부수적인 State를 몽땅 삭제하고, 렌더링 단계에서 그냥 파생(계산)해버립니다.
  const fullName = firstName + ' ' + lastName;
  
  return (/* ... */);
}

이유(Why): 리액트 컴포넌트는 내부 State 훅 호출 이후 ~ return 문 사이의 1급(top-level) 공간에서 벌어지는 연산을 렌더링의 일부로 칩니다. 사용자가 firstName을 고치면 렌더링 스냅샷이 새로 찍힐 테니, 굳이 useEffect라는 거창한 '외부 동기화 장치' 안에 넣어뒀다가 또다시 강제로 리렌더링 (setFullName)을 유발할 필요가 전혀 없습니다! 기존의 컴포넌트 내부 데이터끼리 짬뽕해서 무언가 도출해야 한다면, 주저 없이 State와 Effect를 파괴하고 일반 const 변수로 빼야 합니다.

Q3. useEffect 안에서 외부 시스템 연결(e.g., WebSocket.connect())을 맺고 나서, 함수 내부 하단에 return () => { WebSocket.disconnect() } 형태의 클린업(Cleanup) 함수 구조를 제공하는 근본적인 이유는 무엇일까요? '동기화' 패러다임 측면에서 설명해보세요.

✅ 정답 및 주관식 해설:

동기화란 '상태를 최신으로 일치시킨다'는 뜻입니다. 과거의 상태(옛날 방 번호, 구버전 유저 아이디)로 맺어두었던 네트워크 연결 동기화 작업을 파괴(Cleanup)하지 않은 채 새로운 동기화를 맺으면, 백그라운드에는 과거 연결선들과 현재 연결선들이 좀비처럼 무한히 증식하게 됩니다(메모리 누수).
따라서 **"새로운 규칙(의존성 배열 값)으로 바깥 세상과 다시 동기화해야 한다면, 무조건 이전에 내가 어질러 놓았던 구형 동기화 잔해물들을 깨끗이 치우고 새로 시작하라"**는 강제성을 부여하기 위해 클린업 함수를 제공하는 것입니다.