TanStack이 개발자가 필요한 기능만 선택적으로 사용할 수 있는 데이터 그리드 라이브러리인 Table v9의 베타 버전을 출시했습니다. 번들 크기는 약 5KB로 줄어들며, 정렬이나 필터링 시 버벅거림을 유발하던 INP(interaction-to-next-paint) 지연 현상도 사라집니다.

이번 변화가 중요한 이유

v8에서는 프로젝트에서 사용 여부와 관계없이 정렬, 필터링, 페이지네이션, 행 선택, 그룹화 등 그리드 로직의 모든 요소를 함께 제공합니다. 이러한 추가 코드는 메인 스레드에서 실행되어 번들 크기를 키우고 사용자 작업에 지연을 초래합니다. 빠르고 반응성이 좋은 테이블이 필요한 대시보드의 경우, 단 몇 밀리초의 지연만으로도 INP 점수가 '나쁨(poor)' 범위로 떨어질 수 있습니다.

v9의 차별점

  • 선택적 기능 모듈(Opt-in feature modules) – 실제로 사용하는 부분만 가져오세요. 정렬 기능을 사용하지 않으면 정렬 코드가 번들에 포함되지 않습니다.
  • TanStack Store 통합 – 세밀한(fine-grained) 스토어를 통해 상태를 관리하므로, 한 행을 업데이트하더라도 필터 바나 다른 관련 없는 UI 전체가 다시 렌더링되지 않습니다.
  • 메모리 사용량 감소 – 객체와 배열의 수를 줄여 긴 세션 동안 JavaScript 힙에 가해지는 부담을 완화합니다.

이러한 변화를 통해 다운로드 크기가 줄어들고(단순한 리스트의 경우 라이브러리 크기가 5KB 내외가 될 수 있음), 그리드가 바쁜 상황에서도 더욱 매끄러운 상호작용이 가능해집니다.

혜택을 볼 수 있는 대상

  • 프론트엔드 팀 – 테이블이 주요 UI 요소인 내부 도구, 관리자 패널 또는 SaaS 대시보드를 구축하는 팀.
  • 성능 중심 사이트 – Core Web Vitals를 모니터링하는 사이트의 경우, 낮은 INP는 해당 지표를 직접적으로 개선합니다.

v9이 해결하지 못하는 것

이번 개선 사항은 개발자가 제어할 수 있는 코드를 대상으로 합니다. 거대한 JSON 페이로드를 불러오는 페이지의 속도를 마법처럼 높여주지는 않으며, 무거운 서드파티 스크립트의 비용을 상쇄해주지도 않습니다. 대규모 데이터 세트에는 여전히 적절한 페이지네이션이 필요하며, 네트워크 지연은 별개의 문제입니다.

실질적인 마이그레이션 경로

  1. 가장 무거운 테이블 식별 – 이미 눈에 띄는 지연이 발생하는 주문 목록, 재고 그리드 또는 CRM 뷰를 찾으세요.
  2. 기준 지표(baseline metrics) 캡처 – 변경 사항을 적용하기 전에 해당 페이지의 INP와 롱 태스크(long-task) 지속 시간을 기록하세요.
  3. 그리드를 하나씩 마이그레이션 – v8 임포트(import)를 v9 모듈 세트로 교체하고, 화면에서 실제로 사용하는 기능만 활성화하세요.
  4. 모든 기능을 포함하는 stockFeatures 번들 피하기 – 기본 기능 세트를 모두 불러오면 크기를 줄이려는 목적이 퇴색됩니다.
  5. 상호작용 재테스트 – 정렬, 필터링 및 선택 기능을 다시 측정하여 성능 향상을 확인하세요.

반론: 만능 해결책은 아닙니다

일부 개발자들은 v9이 모든 느린 UI 문제를 해결해 줄 것이라 기대할 수 있습니다. 하지만 실제로 라이브러리를 통한 이점은 제거할 수 있는 커스텀 코드의 양에 따라 제한됩니다. 테이블의 병목 현상이 행의 방대한 양이나 비효율적인 서버 API 때문이라면, 번들 크기 감소의 영향은 제한적일 것입니다.

향후 주목할 점

핵심 요약: TanStack Table v9은 사용하지 않는 그리드 기능에 불필요한 비용을 지불하지 않도록 하는 구체적인 방법을 제공합니다. 필요한 모듈만 임포트하고 세밀한 스토어를 사용함으로써, 합리적인 데이터 처리 전략과 병행한다면 번들 크기를 수 킬로바이트 줄이고 눈에 띄게 빠릿한 테이블 상호작용을 제공할 수 있습니다.