배경
NMS-Web 프론트엔드는 초기 빌드아웃 단계에서 단독 인계받은 코드베이스였습니다 (백엔드는 별도 팀원이 계속 담당). 인계 시점의 현황판은 운영사와 고객사가 진입 직후 보는 화면이었고, 장애·포트·시스템·지도·Top-Nodes 등 5–7개 위젯이 동시에 호출되는 구조였습니다. 페이지 전체가 하나의 로딩 spinner를 기다렸고, 빠른 위젯이 가장 느린 위젯에 묶여 표시되는 상태였습니다.
지도 데이터는 사업장 수에 비례해 점점 무거워졌고, 카드 클릭으로 팝업을 열 때마다 리스트와 거의 같은 정보를 다시 호출하고 있었습니다. 인계 후 첫 큰 작업이 이 데이터-로딩 아키텍처를 다시 짜는 일이었습니다.
접근
먼저 로딩 경계를 잘게 자르는 일부터 시작했습니다. useQuery를 useSuspenseQuery로 통일하고, 위젯 단위 <Suspense fallback> 경계를 박아 페이지-레벨 spinner를 섹션-레벨로 쪼갰습니다. 빠른 위젯이 느린 위젯을 기다리지 않게 됐습니다.
지도 팝업은 카드 클릭 시 별도 API를 다시 치지 않고, 리스트 호출의 캐시 결과를 그대로 재사용하도록 구조를 바꿨습니다. 마커 아이콘은 외부 SVG fetch에서 base64 inline으로 전환해 추가 리소스 요청을 없앴습니다.
페이지마다 반복되던 무한스크롤 로직은 제네릭 프로바이더 팩토리로 추상화했습니다. 컨텍스트, 페이지네이션, getNextPageParam 동작을 한 곳에 봉인하고, 페이지에서는 queryKey와 queryFn만 주입하도록 만들었습니다.
같은 패턴을 여러 페이지에서 반복하지 않고, 한 곳에서 잘 만들어 재주입하는 게 결과적으로 가장 빠른 길이었습니다.
결과
- 페이지 단일 spinner → 위젯별 부분 로딩. 빠른 위젯이 느린 위젯을 기다리지 않음.
- 지도 팝업 진입 시 추가 네트워크 호출 0회 (캐시 재활용).
- 마커 로딩의 외부 SVG 요청 제거.
- 무한스크롤 사용처(장애 · 메시지 · QnA · 지도 사업장 등)를 단일 프로바이더로 통합.
- 246줄 단일 컴포넌트를 컨텍스트·훅·뷰로 분리해 약 80% 슬림화.
배운 점
데이터-로딩 아키텍처를 손볼 때 가장 큰 깨달음은 Suspense 경계를 어디에 두느냐가 곧 UX 약속이라는 점이었습니다. 위젯마다 경계를 두면 사용자는 “어느 위젯이 늦는지” 알 수 있고, 페이지 전체에 두면 “무엇이 늦는지” 알 수 없습니다. 같은 라이브러리, 다른 약속.
또 한 가지: 무한쿼리처럼 모든 페이지가 반복하게 되는 패턴은 한 번 잘 추상화해두면 후속 페이지가 패턴 비용 없이 들어옵니다. 사용처가 1개일 때는 추상화 비용이 아깝지만, 4–5개가 보이는 순간 추상화가 가장 빠른 길이 됩니다.