💡 06. Optimistic Updates (낙관적 업데이트) 실전

📋 목차

• ☕️ 영철이의 고민: "서버가 느리면 화면도 느려야 하나요?"
• 🤔 왜 알아야 하는가: UX의 질적 도약
• 1. 낙관적 업데이트의 필수 콜백 3총사
  • 📌 TypeScript 타입의 중요성
• 2. 실전 코드 워크샵: 좋아요 기능 완벽 구현
• 📝 배운 내용 점검하기 (Quiz)

"영숙(UX 디자이너) 님, 사용자가 좋아요 버튼 누를 때마다 0.5초씩 렉 걸리던 거 방금 고쳤습니다. 이제 번개처럼 변할 거예요."

☕️ 영철이의 고민: "서버가 느리면 화면도 느려야 하나요?"

(아침 회의 시간, 영숙 디자이너의 피드백을 듣는 영철)

🎨 영숙 (UX 디자이너): "영철 님, 우리 커뮤니티 앱 말인데요... 인스타그램이나 트위터는 '좋아요' 누르면 바로 빨갛게 변하잖아요? 근데 우리 앱은 누르고 나서 한 0.5초 뒤에야 색깔이 변해서 되게 답답해요. 가끔은 내가 안 눌렀나 싶어서 또 누르게 돼요."

🐣 영철: 아... 그게, 저희 서버 응답 속도랑 네트워크 지연(Latency) 때문에 물리적으로 어쩔 수가 없는 부분이에요. 백엔드에서 200 OK 사인이 떨어져야 제가 맘 놓고 화면 색깔을 바꿔줄 수 있다고요 .

🦁 영호: 영철 님, 프론트엔드가 백엔드 속도에 핑계를 대면 안 되죠. 데이터 변경 요청(Mutation)이 당연히 성공할 것이라 낙관(Optimistic) 하고 일단 화면부터 바로 바꿔주는 Optimistic Updates 기법을 쓰시면 됩니다.

🤔 왜 알아야 하는가: UX의 질적 도약

인스타그램, 노션, 트렐로 같은 글로벌 탑티어 앱들은 버튼을 누르는 순간 1밀리초의 지연도 없이 상호작용이 일어납니다. 사실 뒤에서는 여전히 네트워크 fetch 통신이 돌아가고 있지만 말이죠.

React Query에서 오프라인 환경 및 열악한 인터넷 환경에서도 완벽히 매끄러운 UX를 제공하기 위해 필수적으로 사용하는 기술이 바로 낙관적 업데이트입니다.

하지만 무턱대고 화면만 바꿨다가 진짜로 서버에서 오류(500 Error)가 나면 어떻게 될까요? 잘못 바뀐 화면을 원래대로 되돌리는 롤백(Rollback) 작업이 정교하게 동반되어야만 합니다. 이 챕터에서는 서버 에러에 대처하는 우아한 롤백 로직을 TypeScript와 함께 설계해봅니다.

1. 낙관적 업데이트의 필수 콜백 3총사

useMutation 훅 안에는 낙관적 생태계를 구성하는 3가지 생명주기(Lifecycle) 콜백이 있습니다.

1. onMutate: 돌연변이 실행 직전에 발동! (여기서 화면을 가짜로 바꾼다)
2. onError: 진짜로 서버 통신했는데 에러 가 났을 때! (여기서 화면을 다시 옛날로 되돌린다)
3. onSettled: 성공하든 실패하든 마지막 에 반드시 실행! (어쨌든 끝났으니 서버 최신 데이터로 최종 덮어씌운다)

📌 TypeScript 타입의 중요성

TypeScript 환경에서 낙관적 업데이트를 짤 때는 제네릭(Generic) 타입을 정확히 맞추는 것이 핵심입니다. 에러 발생 시 onError로 옛날 데이터를 넘겨주려면(Context), onMutate에서 반환하는 타입과 onError에서 받는 Context의 타입이 일치해야 합니다.

// 📝 Mutation Context 타입 표기
// 이전 캐시 데이터를 저장해뒀다가 에러가 나면 롤백할 때 쓰는 '안전 장치'
type TodoContext = {
  previousTodos: Todo[] | undefined;
};

2. 실전 코드 워크샵: 좋아요 기능 완벽 구현

영조 리드가 직접 짜주는 "절대 실패하지 않는 낙관적 좋아요 버튼" 코드를 한 줄씩 뜯어봅시다.

import { useMutation, useQueryClient } from '@tanstack/react-query';
 
// DB에 저장된 Post 타입
type Post = {
  id: number;
  title: string;
  likes: number; // 좋아요 개수
};
 
export function useLikePost() {
  const queryClient = useQueryClient();
 
  return useMutation({
    // 1️⃣ 진짜 서버 통신
    mutationFn: async (postId: number) => {
      // (가정) 시간이 1초 걸리는 느린 API
      const res = await axios.post(`/posts/${postId}/like`);
      return res.data;
    },
 
    // 2️⃣ 🚀 [핵심] onMutate: 버튼 클릭 즉시 발동! (서버 대기 안 함)
    onMutate: async (postId: number) => {
      // 1. 혹시 백그라운드에서 돌고 있는 다른 페치가 있다면 강제로 취소!
      // (이 값이 이전 결과로 덮어씌워지는 가장 위험한 Race Condition 방지)
      await queryClient.cancelQueries({ queryKey: ['posts'] });
 
      // 2. 에러 났을 때를 대비해서, 업데이트 전 '원래 데이터'를 변수에 잠깐 보관 (스냅샷)
      const previousPosts = queryClient.getQueryData<Post[]>(['posts']);
 
      // 3. ✨ 드디어 낙관적 업데이트 발동! 화면에 보일 캐시 데이터를 수동으로 수정한다.
      queryClient.setQueryData<Post[]>(['posts'], (old) => {
        if (!old) return [];
        return old.map(post =>
          // 내가 지금 누른 게시물의 좋아요 수만 가짜로 +1 시켜버림 (화면 즉시 반영)
          post.id === postId ? { ...post, likes: post.likes + 1 } : post
        );
      });
 
      // 4. 원래 보관해둔 데이터를 Context(피난처)에 담아서 리턴! -> 이건 onError로 전달됨
      return { previousPosts };
    },
 
    // 3️⃣ 💣 만약 서버에서 500 에러가 났다면? (롤백)
    onError: (err, postId, context) => {
      // context에 아까 onMutate에서 리턴했던 원래 스냅샷이 들어있다.
      if (context?.previousPosts) {
        // 원래 데이터로 다시 캐시를 복구시켜버린다! (Undo)
        queryClient.setQueryData(['posts'], context.previousPosts);
      }
    },
 
    // 4️⃣ ✅ 성공이든 실패든 모든 게 끝났다면? (검증)
    onSettled: () => {
      // 혹시 로컬 조작 중 꼬였을지 모르니 서버에서 찐 최신 데이터를 다시 한번 깔끔하게 불어온다.
      queryClient.invalidateQueries({ queryKey: ['posts'] });
    },
  });
}

이 흐름은 거의 공식(Boilerplate)에 가깝습니다. 외장하드처럼 떼다 붙이셔도 될 정도로 안정적인 안정성을 자랑합니다.

📝 배운 내용 점검하기 (Quiz)

Q. 낙관적 업데이트를 구현하는 onMutate 블록의 최상단에서 가장 먼저 await queryClient.cancelQueries({ queryKey: [...] }) 를 호출하여 활성화된 네트워크 요청을 취소(Cancel)하는 근본적인 이유는 무엇인가요?

✅ 정답: 이전에 진행 중이던 백그라운드 페치(Refetch)가 한발 늦게 도착하여, 우리가 수동으로 깔아둔 낙관적 캐시(가짜 새 데이터)를 과거의 낡은 데이터로 덮어씌워버리는 참사(Race Condition)를 막기 위해서입니다.

💡 상세 해설:

• 원리 설명: 만약 사용자가 좋아요를 누르기 0.1초 전에 다른 이유(예: 탭 이동)로 ['posts'] 쿼리가 백그라운드 패치를 보내둔 상태였다고 가정합시다. 사용자가 버튼을 눌러 하트 개수를 가짜로 +1 해두었는데, 그 직후에 아까 보내둔 백그라운드 패치의 응답이 도착해버리면 캐시는 다시 과거 데이터(하트 개수 -1) 상태로 덮어씌워져 버리며 화면의 하트가 껌뻑껌뻑이는 버그가 발생합니다.
• 오답 피드백: "영철 님, '어차피 낙관적인데 뒷단에서 뭣하러 도는 거 취소해요?' 라뇨! 수동 조작(setQueryData)을 할 때 캐시의 소유권은 현재 개발자에게 있어야 합니다. 과거의 망령(이전 페칭 결과)이 함부로 침범하지 못하게 문을 잠그는(Cancel) 행위는 낙관적 업데이트의 제1 원칙입니다!"
• 📌 핵심 기억법: 낙관적 수동 덮어쓰기 전엔 반드시 남은 잔여 쿼리들 Cancel 빔 요청 취소!

📝 마무리 퀴즈

Q1. 낙관적 업데이트에서 onMutate가 가장 먼저 해야 할 일은 무엇인가요?

✅ 정답: 관련 쿼리를 취소하고, 현재 캐시 값을 백업한 뒤, 화면에 먼저 보여줄 임시 값을 setQueryData로 반영합니다.

💡 상세 해설:
낙관적 업데이트는 “서버가 성공할 것”이라고 보고 UI를 먼저 움직이는 전략입니다. 그래서 실패 시 되돌릴 이전 값이 꼭 필요합니다. 백업 없이 화면만 바꾸면 실패했을 때 어떤 상태로 돌아가야 하는지 알 수 없습니다.

Q2. cancelQueries를 낙관적 업데이트 전에 호출하는 이유는 무엇인가요?

✅ 정답: 진행 중이던 백그라운드 응답이 뒤늦게 도착해 방금 심은 낙관적 캐시를 오래된 데이터로 덮어쓰는 것을 막기 위해서입니다.

💡 상세 해설:
낙관적 업데이트는 캐시를 수동으로 만지는 순간입니다. 이때 이전 요청의 응답이 살아 있으면 영철이 올린 좋아요 +1이 다시 원래 값으로 튕길 수 있습니다. 요청 취소는 UX 꼼수가 아니라 경합 상태 방어입니다.

Q3. 영철이의 테스트 타임: 좋아요 요청이 실패했습니다. 어떤 콜백에서 어떤 값을 사용해 롤백해야 하나요?

✅ 정답: onMutate가 반환한 이전 캐시 context를 onError에서 읽어 setQueryData로 복구합니다.

💡 상세 해설:
성공하면 최종 무효화로 서버와 다시 맞추면 됩니다. 실패하면 사용자가 본 임시 UI가 거짓이었으므로 정확히 이전 상태로 되돌려야 합니다. 영철이 이제 “빠른 UI”와 “정확한 복구”를 한 쌍으로 판단하게 된 단계입니다.

🐣 영철이의 퇴근 일기

와, 솔직히 코드 볼 땐 onMutate, cancelQueries, setQueryData 죄다 섞여 있어서 복잡해 보였는데 직접 타자 쳐보니까 원리가 기가 막힌다.
"1번 멈추고 -> 2번 과거 백업하고 -> 3번 최신인 척 위장하고 -> 4번 망하면 복구 / 성공하면 리뉴얼". 이 네 박자가 완전 예술이네.

💡 오늘의 교훈: "서버가 느리다고 내 컴포넌트까지 느릴 필요는 없다! 사용자의 입력을 믿고 (Optimistic) 화면부터 보여준 뒤, 뒷단에서 사고 나면 조용히 롤백(Rollback)해주는 우아한 사기(?)를 치자."

영숙 디자이너 님한테 이거 적용하고 시연 보여드렸더니 눈을 크게 뜨고 커피 사주셨다 . 내일은 장바구니에 아이템 담는 것도 낙관적 업데이트로 바꿔놔야지. (단, 결제 같은 치명적인 건 낙관적으로 하면 큰일난다고 영호 님이 경고하셨다... 통장 잔고 0원인데 결제 완료 띄울 뻔 )