전체 데이터를 브라우저에 두는 광고 대시보드 만들기

토스 광고 플랫폼팀이 광고 대시보드의 데이터 처리를 서버에서 브라우저로 전환한 프론트엔드 아키텍처 개선기다. 모든 조작(필터·정렬·검색·페이지네이션)이 서버 요청을 유발하던 구조에서, 진입 시 전체 데이터를 한 번에 내려받고 Web Worker에서 클라이언트 연산으로 처리하도록 바꿨다. 결과적으로 네 가지 버그가 동시에 자동 해소됐다.

핵심 포인트

서버 요청마다 대기가 발생하는 구조는 개별 응답이 빨라도 누적 경험이 나빠 사용자가 데이터 조합 탐색을 포기하게 만드는 근본 원인이었다
클라이언트 데이터 미보유에서 비롯된 버그 네 가지(0 실적 항목 정렬 소실, 캠페인 페이지 번호 추적 불가, 서버 정렬 기준 한계, URL 파라미터 계층 검증 불가)가 전체 데이터 보유로 자동 해소됐다
응답 특성이 다른 세 종류 API(메타데이터 5분 캐시, 성과 지표 5초 캐시, 보조 컬럼)로 분리해 데이터 신선도와 성능을 동시에 관리한다
Web Worker에서 필터·정렬·검색 연산을 처리해 메인 스레드를 차단하지 않는다
초기 로드 증가, 클라이언트 메모리 증가, Web Worker 의존성이라는 트레이드오프를 명시적으로 수용했다

상세 정리

기존 구조 문제: 필터·정렬·검색·페이지네이션이 모두 서버 API 호출을 유발했다. 개별 대기가 짧아도 조합 탐색 시 여러 번 기다려야 해 사용자가 탐색을 포기했다
버그 4가지의 공통 원인: 클라이언트가 전체 데이터를 갖고 있지 않아서 정렬 시 0 실적 항목이 사라졌고, 현재 캠페인의 페이지 번호를 알 수 없었으며, 원하는 정렬 기준을 서버가 지원하지 않았고, URL 파라미터가 실제 계층 구조와 맞는지 검증할 방법이 없었다
전체 데이터 로드 결정: 최대 항목 수를 사전에 확인해 20,000건 이내임을 파악하고, 100,000건까지 설계 여유가 있음을 확인한 뒤 진입 시 전체 데이터를 내려받기로 결정했다
API 분리 전략: 계층 정보 메타데이터 API(5분 캐시), 실시간 지표 성과 API(5초 캐시), 보조 컬럼 API로 나눠 각 데이터의 신선도 요건에 맞게 처리한다
Web Worker 적용: 필터·정렬·검색 연산을 Web Worker로 오프로드해 UI 스레드 블록킹을 방지한다. 워커 크래시 시 재시작하는 복구 절차를 별도로 마련했다
점진적 렌더링: 세 API의 응답이 순차적으로 도착하는 동안 먼저 온 데이터를 즉시 렌더링해 체감 대기 시간을 줄인다
트레이드오프 수용: 초기 페이지 로드가 느려지고 클라이언트 메모리 사용이 늘어나며 Web Worker 의존성이 생기는 단점을 명시적으로 인정하고 수용했다
결과: 네 가지 버그가 전부 자동으로 해소됐고, 이전에는 별도 서버 API가 필요했던 기능을 클라이언트에서 즉시 처리할 수 있게 됐다

왜 읽나대용량 표 형 데이터를 다루는 어드민·대시보드 프론트엔드에서 클라이언트 사이드 전환을 검토하는 프론트엔드 엔지니어에게 유용하다

토스 SLASH 블로그

원문은 여기서 이어서 읽을 수 있어요

원문 읽기

읽음 (0)

·takedown 요청

전체 데이터를 브라우저에 두는 광고 대시보드 만들기

이 글과 비슷한

토스는 어떻게 광고 속에 게임을 넣었을까

RxJS로 우아하게 사이드 이펙트 통제하기

항공 프론트엔드 구축기 (7/10): 창구를 하나만 두었습니다