1. 들어가며WebSocket으로 실시간 데이터를 받는 컴포넌트를 구현할 때, 흔히 마주치는 UX 문제가 있습니다. WS 연결이 완료되기까지 (STOMP 핸드셰이크, 구독, 첫 메시지 수신) 수 초가 걸리는 동안 사용자는 스켈레톤 화면만 보게 됩니다. 이를 개선하기 위해 REST로 스냅샷을 먼저 받아 화면을 채우고, 이후 WS 실시간 데이터로 자연스럽게 전환하는 패턴을 도입했습니다. 그런데 이 방식을 단순하게 구현하면 REST와 WS 응답 사이에 경쟁 조건이 발생합니다. 이 글에서는 그 문제와 useRef를 활용한 해결 방법을 정리합니다.2. 문제 상황: REST와 WS가 동시에 달린다호가창 컴포넌트는 아래 두 가지 데이터 소스를 동시에 운용합니다.REST: 컴포넌트 마운트 시 /api/stocks/{s..

1. 들어가며프론트엔드 개발 환경에서 MSW(Mock Service Worker)는 API 목 처리에 있어 거의 표준에 가까운 도구가 되었습니다. REST 요청을 인터셉트하고 가짜 응답을 내려주는 역할을 깔끔하게 수행해 줍니다.그런데 MSW v2부터 WebSocket 인터셉트 기능이 추가되면서 예상치 못한 문제와 마주쳤습니다. 실제 백엔드 WebSocket 서버에 연결해야 하는 상황인데, MSW가 포트와 URL을 가리지 않고 브라우저의 모든 WebSocket 연결을 가로채 버린 것입니다.이 글은 그 문제를 해결하기 위해 시도했던 방법들과 최종적으로 SockJS의 특성을 이용해 우회한 과정을 공유합니다.2. 문제 상황: MSW v2의 WebSocket 전면 인터셉트프로젝트는 호가창(주문서) 데이터를 STO..

1. 들어가며프론트엔드 개발을 진행하다 보면 디자인 형태는 완전히 동일하지만, 주입되는 데이터의 구조가 달라 매번 새로운 컴포넌트를 생성해야 하는 상황을 마주하게 됩니다.특히 금융 도메인이나 대시보드 형태의 서비스를 개발할 때 이러한 문제가 자주 발생합니다. 주식, 현금, 부동산 등 각 자산군마다 백엔드에서 내려주는 API 응답 형태가 다르기 때문입니다. 이 글에서는 이러한 상황에서 TypeScript의 제네릭을 활용하여 컴포넌트를 유연하게 추상화하고 중복 코드를 제거한 과정을 공유합니다.2. 문제 상황: 늘어나는 보일러플레이트와 중복 코드초기에는 직관적인 구현을 위해 데이터 타입별로 컴포넌트를 분리했습니다. 백엔드에서 전달받는 주식과 현금 데이터의 타입은 다음과 같이 서로 다른 필드명을 가지고 있었습니..