💡 07. useEffect 파괴하기 (3): Race Condition 방어

🎯 이 섹션을 읽고 나면:

• 프로필이나 탭을 빠르게 전환할 때 A 유저 얼굴에 B 유저 이름이 뜨는 기괴한 버그(Race Condition) 원인을 꿰뚫을 수 있다.
• useEffect의 반환 함수인 클린업(Cleanup, 뒷정리) 함수가 언제 트리거되는지 100% 이해한다.
• 무효화(Ignore) 플래그 하나만으로 비동기 호출이 꼬인 응답을 깔끔하게 무시하고 방어하는 코드를 작성할 수 있다.

📋 목차

• 🤔 왜 알아야 하는가: 승리한 자가 살아남는 경주 (Race Condition)
  • ❌ 영철이의 귀신들린 프로필 카드 코드
• 🏗️ 비유로 먼저 이해하기
• 🧩 클린업(Cleanup): 플래그 기법의 아름다움
  • ✅ 영호의 리팩토링: ignore 깃발 흔들기
• 💥 에러 해결 카탈로그
  • ❌ Cleanup을 쓰지 않은 메모리 누수 버그(Memory Leak)

📌 이 문서를 읽기 전에

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

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

• 영숙(디자이너): "영철씨! 유저 프로필 카드에서 '철수'를 눌렀다가 곧바로 '영희'를 눌렀는데... 화면에 영희 사진 밑에 철수 이름이 떠요! 귀신 들린 거 아니에요?"
• 영호(리드): "디자이너님, 귀신이 아니라 영철 님의 코드가 꼬인 겁니다. 비동기 요청들에게 레이싱 시합(Race Condition) 을 시켜놓고 뒷정리를 안 해주면 이런 대참사가 나죠."

🤔 왜 알아야 하는가: 승리한 자가 살아남는 경주 (Race Condition)

우리가 평소에 useEffect로 API를 찌르면, 리액트 안에선 이렇게 생각하기 마련이야.
"1번 유저 눌렀어 -> 1번 응답 왔네 -> 렌더링. 이제 2번 유저 눌렀어 -> 2번 응답 왔네 -> 렌더링."
순서대로 딱딱 떨어질 것 같지? 현실의 모바일 네트워크 등 통신망은 그렇지가 않아.

🤔 잠깐, 먼저 생각해봐
유저의 인터넷 환경이 1번 요청을 보낼 땐 3G 급으로 느리고(대용량 사진), 2번 요청을 보낼 땐 5G 급으로 날아다녔어(텍스트 조금). 영철이가 철수(1)를 눌렀다가 빛의 속도로 영희(2)를 클릭하면 화면은 누구의 정보로 덮일까?

❌ 영철이의 귀신들린 프로필 카드 코드

// ❌ 순진한 비동기 호출 (Naive Approach)
function UserProfile({ userId }) {
  const [user, setUser] = useState(null);
 
  useEffect(() => {
    // 💥 이 API는 인터넷 속도에 따라 응답 도착 순서가 뒤죽박죽일 수 있다!
    let active = true; 
    fetchData(`/api/users/${userId}`).then(res => {
      // "도착했으니까 무조건 setState 해야지!" 
      setUser(res);
    });
  }, [userId]);
 
  if (!user) return <p>로딩중...</p>;
  return <div>{user.name} ({userId})</div>;
}

사건의 발단은 이러합니다.

1. 사용자가 철수(userId: 1) 를 클릭! -> 1번 서버 통신 출발 (엄청난 고화질 사진 때문에 로딩 3초 딜레이).
2. 성격 급한 사용자가 화를 내며 곧바로 1초 뒤 영희(userId: 2) 를 클릭! -> 2번 서버 통신 출발 (데이터가 가벼워 바로 요청 완료).
3. 영희(2번) 응답 도착 👉 화면 상태를 "영희"로 갱신! (setUser(영희))
4. 📌 그런데... 아까 출발했던 철수(1번)의 응답이 뚝배기에 렉이 걸렸다가 이제야(3초 뒤에) 헐레벌떡 도착! 👉 "오, 나도 데이터 가져왔어!" 하고 화면 상태를 무자비하게 "철수"로 덮어씌움! (setUser(철수))

유저는 영희를 누른 상태인데, 느지막이 지각 도착한 옛날 데이터(철수)가 화면을 덮어버린 거야. 이게 프론트엔드 비동기의 가장 끔찍한 적, **경쟁 상태(Race Condition)**야.

🏗️ 비유로 먼저 이해하기

🧒 5살에게 설명한다면?
엄마(리액트)가 피자집에 전화를 걸었어. "여보세요, 페퍼로니 한 판이요!"(1번 요청)
근데 5분이 지나도 배달이 안 와서 답답해진 엄마가 짜증을 내며 곧바로 다른 피자집에 전화를 걸었어. "아휴 취소취소, 그냥 치즈 피자 하나요!"(2번 요청)
총알 배송인 치즈 피자가 먼저 도착해서 맛있게 먹고 있는데...(행복한 화면)
갑자기 한 시간 뒤에 다 식어빠진 페퍼로니 피자 배달원이 문을 쾅쾅 두드리며 무작정 치즈 피자를 빼앗고 그걸 식탁 위에 올려버려!
"어? 이건 우리가 지금 원하는 피자가 아닌데요?!" 반항도 못하고 식탁(화면)이 점령당하지.

부모님(경험 많은 개발자)은 전화할 때 어떻게 할까? 치즈 피자 시켰을 때, 이전에 불렀던 페퍼로니 배달원을 향해 **"야!! 우리 방금 취소했으니까 너는 피자 나와도 가져오지 말고 무시해(Ignore) 돌아가!"**라고 철저하게 뒷정리(Cleanup) 전화를 한 통 돌렸겠지.

✅ 핵심 원리:
리액트 useEffect 안쪽의 return () => {} 코드는 유저가 컴포넌트를 떠날 때만 실행되는 게 아니야.
상태 조건([userId])이 바뀌어서 새로운 동기화(새로운 Effect)가 덮어씌워지기 직전에, 리액트는 항상 무조건 이 클린업 뒷정리 코드를 먼저 실행시켜 줘.
이 순간에 "아까 출발했던 비동기 요청의 문맥은 무시해버려라" 라고 선언해 버리면 만사 해결!

🧩 클린업(Cleanup): 플래그 기법의 아름다움

이 귀신 같은 레이스 컨디션을 막는 가장 원초적이면서 가장 완벽한 5년 차의 패턴이 있어.
API 자체를 중단(AbortController)시키는 방법도 훌륭하지만, 코드 블록을 제어하는 단순한 boolean 깃발(플래그) 기법이 가독성이 극강이지.

✅ 영호의 리팩토링: ignore 깃발 흔들기

// ✅ 방어적인 동기화 코드 (Pro Approach)
function UserProfile({ userId }) {
  const [user, setUser] = useState(null);
 
  useEffect(() => {
    // 1. 방금 내가 파놓은 이 스냅샷 세계관에서, 나는 유효하다. (true)
    let ignore = false; 
 
    async function fetchProfile() {
      const res = await fetchData(`/api/users/${userId}`);
      
      // 3. 서버 응답이 도착했을 때, 누군가 밖에서 나를 무효화(true) 
      // 시키지 않았을 때에만 화면에 덮어씌우는 걸 허락한다!
      if (!ignore) {
        setUser(res);
      }
    }
    
    fetchProfile(); // 💥 출발!
 
    // 2. 하지만 userId가 1에서 2로 바뀌거나 컴포넌트가 꺼지는 등,
    // "과거의 동기화 스냅샷 세계관"이 부서지는 순간 이 청소부(Cleanup)가 출동합니다.
    return () => {
      ignore = true; // "어이! 아까 떠난 페퍼로니 배달원! 너 돌아올 때 무시처리할거니까 다 식은 거 세팅하지 마!"
    };
  }, [userId]); // 기준: userId
 
  if (!user) return <p>로딩중...</p>;
  return <div>{user.name} ({userId})</div>;
}

이제 철수(1)를 누르고 빛의 속도로 영희(2)를 클릭하는 순간의 흐름을 쪼개볼게.

1. 철수(1) 렌더링 -> ignore1 = false 선언. 서버 출발! (3초 걸림)
2. 영희(2) 클릭 -> 리액트: "어? 규칙이 영희로 바뀌었네! 잠깐, 그전에 철수 때 남겨둔 찌꺼기부터 클린업(청소)한다!"
3. 철수의 클린업 발동! 👉 ignore1 = true로 변경됨. (철수 배달원 무효화!!)
4. 영희(2) 렌더링 -> ignore2 = false 선언. 서버 출발! (1초 걸림, 먼저 도착, 화면에 영희 세팅)
5. 드디어 철수(1) 3초 뒤 지각 도착. 하지만 if (!ignore) 룸에 들어가려는 찰나, 이 과거의 감옥에 갇힌 철수 세계관의 ignore1 은 이미 2번 스텝에서 true 로 바뀌어 있지!
6. "아... 무시당했군." (상태 업데이트 무산, 안전빵 유지 ✅)

이것이 리액트 디자인 철학이 선사하는 가장 직관적이고 완벽한 옛날 데이터 방어 기둥이야.

💥 에러 해결 카탈로그

❌ Cleanup을 쓰지 않은 메모리 누수 버그(Memory Leak)

언제 나오는가?

# 개발자 도구 콘솔의 빨간 경고창
Warning: Can't perform a React state update on an unmounted component. 
This is a no-op, but it indicates a memory leak in your application. 
To fix, cancel all subscriptions and asynchronous tasks in a useEffect cleanup function.

**원인:**모달창 안에서 10초짜리 API 통신을 날렸어. 근데 유저가 2초 만에 [X] 버튼을 닫아버려서 모달 컴포넌트 전체가 폭파(Unmount)됐어!
그런데 백그라운드에서는 10초 뒤에 API 데이터가 무사히 서버에서 떨어져 돌아왔고, 죽어 없어진 무덤(모달창의 setState)에 대고 삿대질을 하며 상태를 바꾸려고 하니까 리액트가 기겁을 하면서 "아, 이미 죽은 애 잡고 흔들지 마! 메모리 박살 났어!" 라고 붉은 경고창을 아우성치는 거야.

해결책:
본 가이드의 영호가 짠 코드처럼 return () => { ignore = true; } 를 꼬박꼬박 추가해! 컴포넌트가 폭파될 때 클린업이 우선 발동되어 ignore 를 바꾸니까, 망령이 되돌아와도 안전하게 무시돼. (참고: React 18+ 버전에선 StrictMode 등이 개선되어 경고가 덜 나오긴 하지만, 안전 설계의 근간은 동일해)

🏁 이번에 배운 내용 총정리

💡 한 줄로 기억하기
비동기 useEffect에서 return () => { 치우기 }를 빼먹는 것은, 화장실을 사용하고 변기 물을 내리지 않는 짓과 완벽하게 동일한 인프라 타락 행위다.

🐣 영철이의 퇴근 일기

예전에 콘솔에 빨간색으로 '죽은 컴포넌트에 setState 하지 마!' 경고 떴을 때 뭔 소린지 몰라서 무시했었는데... 피자 배달 비유를 듣자마자 내가 내 코드한테 무슨 폭력을 저질렀는지 명확해졌다. Race Condition이라는 용어도 이제 완벽히 찰떡같이 이해간다.

💡 "비동기 경주(Race Condition)를 조심하라! 빠른 클릭으로 컴포넌트를 이탈할 땐 Cleanup에서 ignore 플래그 하나만 꽂아주면 완벽 방어가 된다."

영숙 디자이너님이 귀신 들린 화면 좀비 같다고 했을 때 찔끔했는데, 이제 더 우아하고 튼튼한 방어막을 칠 수 있게 됐다. 클린업 안 하는 게 변기 물 안 내리는 거랑 똑같다니... 영호 님 팩폭 덕분에 오늘 내 코드가 훨씬 위생적으로 변했다. 기분 좋게 퇴근! 지하철에서 AbortController 한번 훑어보고 가야지.

📝 마무리 퀴즈

Q1. useEffect의 Cleanup(반환 함수) 코드가 정확히 발동되는 두 가지 순간(Timing)을 가장 잘 서술한 것은?

• A) 오직 브라우저 창(탭)을 완전히 종료할 때만 / 사용자가 새로고침 키를 누를 때.
• B) 컴포넌트가 최초 화면에 띠워질 때 / 컴포넌트 안에 있는 일반 클릭 이벤트가 발생할 때.
• C) 해당 컴포넌트가 화면에서 완전히 사라질(Unmount) 때 / 그리고! 다음 렌더링 사이클에 의해 해당 Effect가 다시 트리거(재실행) 되기 직전.
• D) 사용자가 콘솔 로그를 감시하고 있을 때 / 강제로 React Garbage Collection을 호출할 때.

✅ 정답: C

💡 상세 해설: 이게 Cleanup의 치트키 원리입니다. 단순히 컴포넌트가 죽을 때(Unmount) 만 뒷정리를 하는 게 아닙니다! 사용자가 버튼을 눌러 상태 값이 바뀌어 [userId] 의존성이 달라지면, 리액트는 새로운 데이터로 동기화를 시키기 위해 반드시 과거의 스냅샷 흔적을 씻어내는 Cleanup 부터 먼저 한 번 실행 한 뒤, 그제야 새로운 Effect 본문을 돌립니다. 이 원리 때문에 변수를 ignore = true 로 바꿔서 이전 요청을 폐기시키는 플래그 기법이 우아하게 작동하는 것입니다!

Q2. 다음 중 Race Condition(비동기 경쟁 참사)이 가장 심하게 발생할 수 있는 취약한 조건을 갖춘 UI 상황은 어떤 것인가요?

• A) 유저가 장바구니에 상품 삭제 버튼을 한 번 클릭한 뒤 화면이 바로 로딩(Spinning) 스크린으로 잠기는 화면.
• B) 실시간으로 초당 5개씩 바뀌는 "관심 주식 종목(탭)" 리스트를 넘나들며 종목의 차트 그래프 데이터를 API로 쏴서 그려주는 화면.
• C) 처음에 딱 한 번 50MB짜리 통계 이미지를 가져와 화면 중앙에 박아버리는 메인 페이지 화면.
• D) 버튼을 누르면 내부 State 숫자만 count + 1 하도록 조작된 텍스트 카운터 타이머 화면.

✅ 정답: B

💡 상세 해설: 탭 전환이나 실시간 타이핑(자동완성 검색 UI)처럼 사용자가 엄청나게 빠른 속도로 키 입력이나 탭 클릭의 조건을 계속 변환시킬 때, 그리고 그것들이 전부 네트워크 지연(Latency)이 동반되는 무거운 서버 API 요청일 때 어마어마한 비동기 지옥의 레이스 컨디션들이 연출됩니다. 2번 탭의 서버요청은 번개처럼 왔는데, 아까 누른 1번 탭의 수십 MB 이미지가 5초 뒤에 멍청하게 화면을 쾅 덮어버리니까요! Cleanup 무효화 처리가 반드시 필요한 곳입니다.

Q3. useEffect 외부 통신을 캔슬하는 더 강력한 무기인 브라우저 내장 API AbortController 에 대해 들어본 적이 있을 겁니다. 이 API를 이용한 클린업 시나리오와, 영호가 쓴 빈 변수(플래그) let ignore = false 트릭 간의 실질적 성능(네트워크 레벨) 차이는 무엇일까요? 주관식으로 간략히 통찰을 써보세요.

✅ 정답 및 주관식 해설:

주관식 해설 원리:
가장 큰 차이는 망이 소모되는 자원의 중단(Cancel) 여부입니다. 영호가 가르쳐준 let ignore = false 변수 트릭은 코드가 짜기 쉽고 무난하게 쓸 순 있지만, 일단 브라우저가 첫 페퍼로니 배달원을 출발시켰다면 배달원 자체의 트래픽 이동(서버 데이터 다운로드)을 막지는 못합니다. 그저 데이터 통신이 끝나서 집에 도달했을 때 얍삽하게 문을 안 열어주고 화면 업데이트(setState)만 무시할 뿐이죠(안전망 확보).
하지만 브라우저 자체 지원 API인 AbortController.abort() 를 클린업에 물려 구현하면? 리액트가 배달원이 출발하고 중간쯤 지났을 때 "야! 배송 중지해 통신선 끊어버려(Network Cancel)!" 명령을 브라우저 망에다 꽂아버립니다. 크롬 네트워크 탭에 빨간색(canceled) 에러 창이 예쁘게 뜨면서, 데이터 낭비 트래픽 자체를 중간에 소멸시키므로 성능적으로 가장 이상적인 대기업 마인드(고성능) 해결책이 완성됩니다! (둘 다 무한 데이터 방어 효과는 같습니다.)