💾 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번씩 날리시겠다고요...? 우리 영수(백엔드)님이 의도치 않은 요청 부하를 만들었다고 급하게 연락하러 옵니다.
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;
}

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

📝 배운 내용 점검하기 (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 세팅도 챙겨라!

📝 마무리 퀴즈

Q1. WebSocket/SSE 이벤트가 “게시글 42번이 변경됨”처럼 일부 정보만 줄 때 가장 안전한 기본 대응은 무엇인가요?

✅ 정답: 관련 queryKey를 무효화해 서버에서 최신 데이터를 다시 확인하게 합니다.

💡 상세 해설:
부분 이벤트만으로는 캐시를 정확히 재구성하기 어렵습니다. 이때 invalidateQueries는 서버를 진실의 원천으로 다시 확인하는 안전한 선택입니다. 다만 이벤트가 매우 잦다면 batch나 throttle로 서버 부하를 함께 고려해야 합니다.

Q2. 이벤트 payload가 변경된 전체 객체를 포함한다면 setQueryData가 유리한 이유는 무엇인가요?

✅ 정답: 이미 최신 데이터가 도착했으므로 추가 네트워크 요청 없이 캐시를 직접 갱신할 수 있기 때문입니다.

💡 상세 해설:
서버가 Push로 완전한 데이터를 줬는데 다시 Pull을 보내면 비용이 중복됩니다. setQueryData는 네트워크를 아끼고 화면 반응을 빠르게 합니다. 단, 리스트와 상세처럼 같은 객체가 들어간 캐시들을 어디까지 갱신할지 키 설계가 필요합니다.

Q3. 영철이의 테스트 타임: 실시간 알림 이벤트가 초당 여러 번 오고, 영수네 서버 부하가 튀고 있습니다. 어떤 판단 기준을 세워야 하나요?

✅ 정답: 이벤트가 partial인지 full인지 구분하고, partial은 묶어서 무효화하며 full은 필요한 캐시에 직접 주입하는 전략을 나눕니다.

💡 상세 해설:
실시간이라고 반드시 invalidate를 날리면 HTTP 요청 급증이 됩니다. 반대로 불완전한 이벤트를 무리하게 setQueryData에 넣으면 캐시가 거짓이 됩니다. 영철이 이제 이벤트 품질에 따라 동기화 전략을 선택해야 합니다.

🐣 영철이의 퇴근 일기

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

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

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