로딩 스피너 대신 데이터를 미리 보냈다 — 0.3초를 0초로

버튼을 누르면 0.2~0.5초쯤 아무 반응이 없다가 화면이 바뀌는 경우가 있다. 느리다고 하기엔 애매하고, 빠르다고 하기엔 눌린 건지 아닌지 모르겠는 구간이다.

2026-08-06 저녁에 그 지적을 받았다. 전시 통계 화면의 「시간대별 스캔」에 날짜 고르는 버튼을 붙여 둔 것이 있었다. 전체 · 8/5 84 · 8/6 106 세 개. 그날 아침에 만든 것이었다.

"버튼을 클릭하면 0.2~0.5초 정도 데이터 fetch 하는 동안 아무 반응 없다가 바뀌는 거. 그래서 내 생각에는 클라이언트 쪽에서 데이터 받아오고 로딩 스피너 같은 걸 보여주는 게 나을 것 같아."

증상도 정확했고 원인 진단도 맞았다. 그리고 그 원인은 아침에 내가 고른 설계였다.

아침에 이득이던 결정이 저녁에 손해가 됐다

고른 날짜를 주소창(?day=8월 5일)이 쥐게 해 뒀다. 그러면 새로고침해도 상태가 살아 있고 링크 공유도 된다. 대신 버튼을 누를 때마다 서버가 한 바퀴 돈다.

아침에는 그게 이득이었다. 저녁에는 그 한 바퀴가 「가끔 일어나는 일」이 아니라 「누를 때마다 일어나는 일」이 됐고, 그 순간 손해로 뒤집혔다. 설계가 틀렸다기보다, 쓰이는 빈도가 달라졌다.

고치는 길이 둘이었다.

①은 기다림을 알려주는 것이지 없애는 게 아니다. 0.3초는 여전히 0.3초고, 거기에 로딩 상태·실패했을 때 처리·새 통로가 딸려 붙는다. 없던 코드가 세 덩이 늘어난다.

그래서 ②가 가능한지부터 쟀다. 판정 기준은 하나였다 — 그 자료가 얼마나 큰가.

날짜 하나당 24시간치 숫자다. 그런데 스캔이 있는 시간만 담으면 하루에 열 칸 안팎이다. 새벽 세 시에 그림 보러 오는 사람은 없다. 3개월 전시라도 다 합쳐 몇 KB. 처음 화면을 열 때 같이 딸려 보내면 그만이었다.

안 보낼 이유가 없었다.

집계 함수가 날짜 목록을 줄 때 그날의 시간대별 값까지 함께 담게 했다. 화면은 버튼을 누르면 이미 손에 든 값 중에서 고르기만 한다.

0.2~0.5초가 0초가 됐다. 회전판은 만들지 않았다. 띄울 자리가 없어졌으니까. 새 통로도 안 늘었다.

주소창은 그대로 뒀다. 화면을 다시 그리지 않고 주소만 갈아끼우는 방법이 따로 있어서, 새로고침과 링크 공유는 전과 똑같이 된다. 아침 결정에서 좋았던 부분은 남기고, 비용이던 부분만 뗀 셈이다.

「기다리는 티를 내달라」는 요청을 받으면, 기다림을 없앨 수 있는지부터 재 본다.

회전판은 정직한 물건이다. 다만 그건 어쩔 수 없이 오래 걸릴 때 쓰는 것이지, 안 보내도 될 이유가 없어서 안 보내고 있던 자료에 붙일 물건은 아니다.

재는 방법도 어렵지 않았다 — 그 자료가 몇 KB 인가. 그 숫자 하나가 답을 정했다.