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

안녕하세요. 토스에서 광고주가 쓰는 대시보드를 만들고 있는 프론트엔드 개발자 김동희입니다. 저희 팀이 만드는 건 광고주를 위한 화면이에요. 캠페인을 만들고, 예산을 넣고, 어제 쓴 돈이 얼마나 성과로 돌아왔는지 확인하는 곳이죠.말하자면 '데이터를 보는 도구'를 만듭니다. 그리고 도구를 만드는 일은, 겉으로 보이는 것보다 훨씬 프론트엔드다운 문제들을 던져줘요. 오늘은 그중 하나, 필터 한 번 누를 때마다 서버를 기다리던 대시보드를 고친 이야기를 해보려고 해요.결론부터 말하면 저희는 서버가 하던 필터링·정렬·검색·페이지네이션을 전부 브라우저로 가져왔습니다. 그런데 흥미로웠던 건, 이 결정으로 얻은 게 속도만이 아니었다는 점이에요.광고주는 대시보드를 '한 번' 보지 않아요먼저 광고주가 이 화면에서 실제로 무엇을 하는지 짚어볼게요.광고 대시보드에는 캠페인 → 광고세트 → 소재라는 3단계 계층이 있어요. 캠페인은 ‘이 예산으로 이런 목표를 달성하겠다’를 정하는 단위, 광고세트는 그 안에서 누구에게 언제 보여줄지를 정하는 단위, 소재는 실제로 사용자 눈에 보이는 이미지와 문구예요. 캠페인 하나에 광고세트 여러 개가, 광고세트 하나에 소재 여러 개가 붙습니다.이 화면은 성과를 깊게 파고드는 분석 도구는 아니에요. 캠페인·광고세트·소재를 관리하면서 상태를 확인하는 곳에 가깝습니다.광고주는 여기서 이런 걸 합니다.한 번 보고 끝나는 화면이 아니에요. 가설을 세우고, 걸러보고, 아니다 싶으면 되돌아가는 탐색 도구에 가깝습니다.문제는 저 모든 동작이 서버 호출이었다는 것입니다.사용자: 필터 변경 → 클라이언트: API 호출 (필터 파라미터) → 서버: 수백 ms → 클라이언트: 화면 갱신한 번의 기다림은 참을 만해요. 그런데 탐색은 한 번이 아니죠. 필터 걸고, 정렬 바꾸고, 페이지 넘기고, 다시 필터 풀고. 열 번이면 수 초가 대기로만 쌓입니다. 그리고 이 시간이 만드는 진짜 비용은 대기 그 자체가 아니라 탐색 포기예요. "이 조합도 한번 볼까?" 하는 시도를 사용자가 하지 않게 되거든요.느린 도구는 덜 쓰이는 게 아니라, 다르게 쓰입니다.미리 말씀드리면 이건 저희가 지표로 확인한 게 아니라, 화면을 만들고 써보면서 세운 가정이에요. 다만 이 가정을 받아들이면 고쳐야 할 대상이 달라집니다. 응답 시간이 아니라, 사용자가 시도해볼 수 있는 횟수가 되거든요.그런데 문제는 속도만이 아니었어요여기까지만 보면 흔한 성능 개선 이야기입니다...