💾 05. WebSocket, SSE 등 실시간 통신망과 캐시 동기화

📋 목차

• ☕️ 영철이의 고민: "푸시(Push)가 왔는데 또 당기(Pull)니까 느려요"
• 🤔 왜 알아야 하는가: 캐시 서버 동기화의 딜레마
• 1. 1번 채널: 부분 이벤트 (소극적 수비 - Invalidate)
• 2. 2번 채널: 완전한 이벤트 (공격적 수용 - 낙관적 캐시 주입)
• 3. SSE (Server-Sent Events) 와의 결합 아키텍처
• 📝 배운 내용 점검하기 (Quiz)

"영철 님, 웹소켓으로 '1번 게시글 지워짐' 신호 받았다고 굳이 다시 API fetch 를 날리면 그 빠른 웹소켓 서버를 튼 이유가 없잖아요!"

☕️ 영철이의 고민: "푸시(Push)가 왔는데 또 당기(Pull)니까 느려요"

(화요일 오후, 실시간 트레이딩 대시보드 화면 가격이 튀는 걸 보며 당황하는 영철)

🐣 영철: 저기, 리드 님! 팀장님이 "증권 앱처럼 비트코인 시세나 실시간 달린 댓글은 새로고침 안 해도 팍팍 바뀌게 해주세요" 라고 하셔서 어제 밤새 WebSocket(웹소켓) 연결을 마쳤거든요!

소켓 채널에서 {"event":"updated", "id":100} 이렇게 메시지가 똑 떨어지면,
제가 냉큼 queryClient.invalidateQueries({ queryKey: ['posts'] }) 으로 캐시 팍 무효화 쳐서 백그라운드 리패칭(GET /posts)을 뺑뺑 돌게 짰습니다! 어때요? 실시간 쩔죠?

🦁 영호: (이마를 짚으며) 영철 님... 지금 1초에 댓글이 50개씩 달리는 핫한 커뮤니티 글에 매초마다 웹소켓 신호(updated)가 내려올 텐데, 그때마다 백그라운드 fetch /posts 를 50번씩 날리시겠다고요...? 우리 영수(백엔드)님이 디도스(DDoS) 공격 쏘냐고 멱살 잡으러 옵니다.
WebSocket의 목적은 "서버가 이미 최신 데이터를 입에 물고 푸시(Push)해 줬으니, 클라이언트가 API를 쏘지 말고(Pull) 그 데이터로 네 캐시 통만 살짝 업데이트쳐라" 에 있습니다. 무효화(invalidate)를 남발하면 최악의 병목이 터져요.

🤔 왜 알아야 하는가: 캐시 서버 동기화의 딜레마

현대 웹 트렌드(특히 채팅, 알림, 주식, 협업 툴) 에서는 REST API (내가 당김, Pull) 와 WebSocket/SSE (서버가 쏴줌, Push) 두 가지 파이프라인이 하나의 화면(UI) 안에서 격렬하게 충돌합니다.

서버가 "야! 1번 글 바꼈다!" 라고 Push 신호를 줬을 때 React Query가 할 수 있는 행동은 두 가지 갈림길 입니다.

1. 소극적 수비 (Invalidation): "오 신호 땡큐. 근데 너가 준 이벤트 데이터 너무 쪼만해서 못 믿겠어. 귀찮지만 내가 서버에 REST API 다시 쏴서 최신 리스트 통째로 다 끌어올게."
2. 공격적 수용 (setQueryData): "오 신호 땡큐! 너가 변경된 데이터({likes: 5}) 구워줬으니까, 내가 네트워크 안 쏘고 내 로컬 메모리 캐시통 조립해서 싹 갖다 붙일게!"

어떤 상황에 무엇을 택하는지가 실시간 아키텍처의 퍼포먼스를 가릅니다. (TkDodo 아티클 #7)

1. 1번 채널: 부분 이벤트 (소극적 수비 - Invalidate)

만약 웹소켓 이벤트 덩어리가 매우 빈약하게 넘어오는 경우입니다.
가령 Payload가 단지 {"type": "POST_UPDATED", "postId": 5} 정도만 찍혀서 왔습니다. "무엇"이 바뀌었는지는 안 알려주고 "바뀌었음!" 이라는 파닥거림만 오는 거죠.

이럴 땐 어쩔 수 없이 무효화를 쳐야 하지만, 디도스(DDoS) 방어 매커니즘 을 세팅해야 합니다.

import { useEffect } from 'react';
import { useQueryClient } from '@tanstack/react-query';
 
function usePostSocketHandling() {
  const queryClient = useQueryClient();
 
  useEffect(() => {
    // 소켓에서 이벤트가 파바박- 수신될 때
    socket.on('POST_UPDATED', (eventMessage) => {
      // ⚠️ 영철이의 순진한 폭격
      // 1초에 10번 소켓이 오면 fetch GET 요청이 백그라운드에서 10번 터진다 💥
      // queryClient.invalidateQueries({ queryKey: ['posts'] });
 
      // 🚀 영호 리드의 디도스 방어막 (Throttling Invalidation)
      queryClient.invalidateQueries({ 
        queryKey: ['posts'],
        // "네트워크 통신이 연쇄적으로 들어와도 다 무시하고, 딱 1번만 취합해서 다시 가져와라!" 
        // 1초 간격 안에 발생한 무효화는 병합(Batch) 처리됨.
        cancelRefetch: false 
      });
    });
 
    return () => socket.off('POST_UPDATED');
  }, [queryClient]);
}

2. 2번 채널: 완전한 이벤트 (공격적 수용 - 낙관적 캐시 주입)

서버가 너무나 친절하게 바뀐 데이터 껍데기를 통째로 다 쏴주는 경우(예: { "id": 5, "title": "수정글", "likes": 12 })엔 절대로 fetch를 다시 쏠 이유가 없습니다!

메모리 안의 QueryCache 주머니를 직접 열고, 핀셋으로 해당 객체만 착! 갈아끼우는 setQueryData (프론트 조립 방식) 이 서버 비용을 0원으로 만듭니다.

// 소켓이 온전한 최신 게시글(Post) 데이터를 푸시하는 경우
type Post = { id: number; title: string; likes: number };
 
function useLivePostUpdates() {
  const queryClient = useQueryClient();
 
  useEffect(() => {
    socket.on('INCOMING_POST_UPDATE', (newPost: Post) => {
      
      // 🚀 데이터 조립식 주입 (네트워크 요청 발생률 0%)
      queryClient.setQueryData<Post[]>(['posts'], (oldPosts) => {
        // 만약 내 화면 캐시 금고가 텅 비었다면? 무시해버림 (화면에 안 띄워놨으니 알 바 아님)
        if (!oldPosts) return; 
 
        // 캐시 속에 있는 100개 리스트 중, 방금 소켓으로 날아온 녀석만 갈아끼운다!
        return oldPosts.map((post) => 
          post.id === newPost.id ? newPost : post
        );
      });
      
    });
 
    return () => socket.off('INCOMING_POST_UPDATE');
  }, [queryClient]);
}

이 패턴이 들어가면, 누군가가 게시판에 글을 올리거나 댓글을 다는 즉시 내 화면에 1ms의 로딩 스피너의 흔적도 없이 스무스하게 최신 글이 '스폰(Spawn)' 됩니다. 진정한 실시간(Realtime) 통신의 위력이죠!

3. SSE (Server-Sent Events) 와의 결합 아키텍처

채팅이 아니라 단순 단방향 알림(알림 종달기장 숫자 등) 이라면 무거운 WebSocket 대신 HTTP 기반의 SSE(Server-Sent Events) 로 가볍게 처리하는 것이 트렌드입니다. React Query에 SSE를 붙일 땐 보통 컴포넌트 생명주기와 전역 훅(QueryClient 팩토리) 중 후자에 붙이는 것이 메모리 안전성에 좋습니다.

// 📝 providers/get-query-client.ts 의 초기화 블록
let sseConnection: EventSource | null = null;
 
export function getQueryClient() {
  const client = new QueryClient({ ... });
 
  // 클라이언트(브라우저)에서 단 최초 1회만 SSE 백그라운드 터널을 영구 개통!
  if (typeof window !== 'undefined' && !sseConnection) {
    sseConnection = new EventSource('/api/stream/notifications');
    
    // 데이터가 쏟아질 때마다 캐시 금고에 즉각 꽂아버림
    sseConnection.onmessage = (event) => {
      const liveData = JSON.parse(event.data);
      client.setQueryData(['notifications'], liveData);
    };
  }
 
  return client;
}

이러면 당신의 앱은 접속하자마자 실시간 데이터의 축복을 받는 고도로 최적화된 스트리밍 앱이 됩니다.

🐣 영철이의 퇴근 일기

와, 나 그동안 웹소켓 이벤트 떨어질 때마다 생각없이 Invalidate 날렸었는데, 영수 님이 나한테 꿀밤 때리러 온 이유를 알겠다...
초당 10번 바뀌는 비트코인 시세 데이터를 10번 GET 요청으로 다시 쏘고 있었으니 서버 CPU가 터지지;;

💡 오늘의 교훈: "서버가 푸시(Push) 하는 이벤트가 Partial(일부) 이라면 invalidate 빔을 쏘되 Batch/디도스 방어를 꼭 걸어두고! 서버가 푸시 하는 이벤트가 Full(전체) 이라면 절대 네트워크를 다시 쏘지 말고 setQueryData 핀셋 조립으로 우아하게 캐시를 갈아 끼우자!"

사실 setQueryData 써서 로컬 메모리 배열 map 돌리는 로직 짜는 게 조금 귀찮긴 한데, 이거 반영하고 나니까 네트워크 탭에 불필요한 HTTP 통신이 단 1건도 안 찍히고 클라이언트 자체적으로 스무스하게 화면이 깜빡이는 거 보고 쾌감 오졌다... 내일은 유저 인풋 다루는 폼(Form) 작업 해봐야지! 💻

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

Q. 영철이는 실시간 채팅방 화면을 만들면서, "새로운 메시지(new_chat)" 웹소켓 이벤트가 오면 setQueryData로 무한 스크롤(useInfiniteQuery)의 과거 데이터 배열 끝에 메시지를 객체를 하나 푸시(Push) 해주는 코드를 작성했습니다.

그러나 치명적인 버그를 발견했습니다. 유저가 채팅방 화면을 닫았다가(다른 메뉴 이동 후 언마운트), 즉시 1분(staleTime 기본값인 0초 상태, gcTime 생존 상태) 뒤 채팅방에 다시 진입했더니 화면에 방금 웹소켓으로 열심히 추가해 넣었던 메세지가 사라졌다가 깜빡 하면서 최신 데이터로 다시 렌더링 됩니다. 왜 이 현상이 터지는 걸까요?

• A) 브라우저 탭을 바꿨더니 웹소켓 연결이 스스로 끊어져 버려서 캐시메모리가 같이 증발했기 때문이다.
• B) 소켓이 아무리 캐시(QueryCache)를 정성스레 수작업으로 채워놨어도, staleTime: 0 (기본값) 상태에서 유저가 컴포넌트에 다시 마운트(진입)하는 순간 "어? 이거 상한빵이네?" 하고 즉각 백그라운드 리패칭(GET /chats) 을 쏴버려, 수작업 이력이 서버 초깃값 트랜잭션으로 날아갔기(덮어씌워졌기) 때문이다.
• C) setQueryData는 메모리 휘발성이라서 페이지를 이동하는 순간 즉시 Garbage Collect(삭제 됨) 처리되기 때문이다.

✅ 정답: B

💡 상세 해설:

• 원리 설명: TkDodo 아티클 #7에서 짚어주는 가장 흔한 WebSocket 연동 함정입니다. 당신이 setQueryData 로 아무리 열심히 프론트 캐시에 최신 데이터를 욱여넣어도... 해당 데이터의 유통기한(staleTime)이 짧거나 0이면 유저가 다른 탭을 찍고 다시 컴포넌트에 포커싱(refetchOnWindowFocus 혹은 Mount) 하는 순간 React Query는 "상한 거니까 버리고 서버에서 통째로 쎄벼오자!" 발동을 겁니다. 이때 아주 찰나의 순간 동안 깜빡임이나 데이터 미스매치가 터집니다.
• 오답 피드백: "영철 님, 웹소켓으로 열심히 캐시를 밥 먹여 놨으면, 적어도 그 데이터가 당분간은 신선하다는 걸 React Query한테 인지시켜줘야 합니다. WebSocket 연동 데이터를 유지할 때는 해당 useQuery의 staleTime을 Infinity 등으로 넉넉히 걸어 신선도 관리를 스스로 하게끔 통제권을 완전히 넘겨받으셔야 합니다!"
• 📌 핵심 기억법: 웹소켓 setQueryData 덮어쓰기 로직 짤 때는, 무조건 쌍둥이처럼 staleTime: Infinity 세팅도 챙겨라!