[SlateKR #174] 선언만 있던 revalidate와 한 달 멈춰 있던 차트 당일 봉

About this offer

전 세션에서 목록 화면의 종목 링크 prefetch를 껐다. 목록에 보이는 종목 수만큼 KIS 호출이 나가던 것을 없앤 대신, 종목 상세에 들어가면 헤더가 채워질 때까지 스켈레톤을 1초 남짓 보게 됐다. 헤더가 조회 여러 건을 차례로 기다린다는 것까지 확인하고 그 정리를 다음 작업(F121)으로 넘겼다. 초기 계획은 헤더 조회를 병렬로 바꾸고 문서를 고치는 것이었는데, 늘 그렇듯 둘 다 계획한 모양으로 끝나지 않았다. 병렬화는 대부분의 진입에서 수십 ms밖에 줄이지 못했고, README의 캐시 서술을 대조하다가 종목 페이지에 선언해 둔 revalidate가 한 번도 동작한 적이 없다는 걸 알게 됐다. 그래서 헤더에서는 KIS 호출을 따로 떼어냈고 문서는 렌더 방식부터 다시 썼다. 같이 조사한 시세 요청 중복에서는 차트의 당일 봉이 한 달 가까이 갱신되지 않던 문제가 나와 이것도 고쳤다. 헤더가 기다리는 조회 먼저 헤더가 무엇을 기다리는지와 prod에서 얼마나 걸리는지부터 쟀다. 직전 글의 1.2초는 장중 수치라, 휴장일인 이날 기준을 다시 잡았다. layout 종목 기본 정보 (DB) 헤더 가격 (DB) → 기업 코드 (DB) → 기업개황 (DART) → 시장조치 (KIS) → NXT 대상 여부 (DB) 의존 기업 코드 → 기업개황 하나. 나머지는 티커만 있으면 됨 prod, 목록 행 클릭부터 헤더가 채워질 때까지 처음 여는 종목 0.91~0.95초 이미 열어 본 종목 0.60~0.63초 의존이 하나뿐이라 병렬로 묶는 일 자체는 간단했다. 다만 줄어드는 시간이 진입 종류에 따라 달랐다. 처음 여는 종목은 DART 캐시가 비어 있어 기업개황(약 0.28초)과 KIS 호출이 겹치는 만큼 줄어들지만, 이미 열어 본 종목은 기업개황이 캐시에서 오고 DB는 같은 리전이라 원래 빠르다. 여기서 남는 대기는 사실상 KIS 시장조치 호출 하나였고, 병렬로 돌려도 헤더가 끝까지 기다려야 하는 값이라 수십 ms밖에 줄지 않는다. 동작한 적 없는 revalidate README의 캐시 서술을 코드와 맞춰 보던 중에 의문이 하나 생겼다. 헤더의 시장조치 호출은 캐시 없이( no-store ) 요청마다 나가는데, 그렇다면 같은 route에 선언한 revalidate는 적용되고 있는 걸까. 이미 열어 본 종목에서도 서버 렌더 시간이 그대로 걸린다는 위 실측과도 맞물리는 의문이라 prod 응답 헤더를 열어 봤고, 두 번 요청해 두 번 다 private, no-store 에 캐시 MISS였다. 선언 기본 정보 24시간 · 재무 12시간 · 공시·차트 1시간 실제 요청마다 서버 렌더, 페이지 캐시 없음 원인 [ticker] 세그먼트에 generateStaticParams가 없음 캐시 없는 fetch 2곳, 공시 탭의 searchParams 원인으로 먼저 본 건 #119에서 헤더에 붙인 배지 호출이었다. 그런데 커밋 이력을 확인하니 generateStaticParams 는 한 번도 있었던 적이 없어서, 종목 페이지는 배지보다 훨씬 앞선 처음부터 요청마다 렌더되고 있었다. 주기를 적어 둔 선언도 README의 캐시 표도 동작하지 않는 설정을 설명하고 있었던 것이다. 빌드 결과로 전체를 다시 분류해 보니 페이지 단위로 캐시되는 건 홈 하나였고, 지수 페이지도 searchParams를 읽어 동적이었다. 요청 시 렌더 유지와 선언 삭제 후보 판정 ISR 도입 보류. generateStaticParams 추가와 캐시 없는 fetch 제거가 함께 필요. 방문이 드물면 마지막 생성본이 먼저 서빙되어, 장외에 전날 종가가 최신처럼 보일 수 있음 요청 시 렌더 유지, 선언 삭제 채택. 동작은 지금 그대로이고 문서와 코드를 사실에 맞추는 일만 남음 ISR은 방문이 잦을수록 이득인 구조다. 종목은 2,651개인데 방문은 드문 서비스라면 캐시가 맞는 경우보다 오래된 페이지를 먼저 내보내는 경우가 더 많을 것으로 보았고, 그걸 막으려면 EOD 적재 직후에 페이지를 다시 만들게 하는 장치가 따로 있어야 한다. 다만 이 위험은 재 본 게 아니라 추론이라서, 도입 조건과 함께 backlog에 적어 두는 데서 멈췄다. 선언은 문서에 "적용되지 않는다"고 적는 대신 코드에서 지웠다. 지워도 동작이 같은지는 먼저 확인했는데, 서버 쪽 fetch 13건이 모두 캐시 옵션을 직접 지정하고 있어 선언이 기본값으로 쓰일 자리가 없었다. README의 종목 행은 "요청 시 서버 렌더, DB는 요청마다 조회, DART만 fetch revalidate"로 고쳤고, 배포 시점의 종목 목록에 고정돼 있던 sitemap에는 하루 주기를 걸었다. 페이지 캐시 : 홈 1시간, sitemap 하루 외부 응답 캐시 : DART 공시 목록 1시간 · 기업개황 24시간, 지수·순위의 KIS 응답, AI 요약(DB) DB 조회 : 시간 캐시 없이 요청 안에서의 중복 제거만 헤더에서 KIS 호출 분리 병렬화로 줄지 않는 대기를 없애려면 헤더가 KIS 응답을 기다리지 않아야 한다. 그 전에 시장조치 결과가 배지 말고 다른 데 쓰이는지부터 확인했다. 가격 표시 분기나 폴링 제어에 물려 있다면 떼어낼 수 없기 때문인데, 쓰는 곳은 배지를 그리는 두 군데뿐이었다. 배지를 별도 서버 컴포넌트로 빼서 fallback 없는 Suspense로 감쌌고, 나머지 조회는 하나가 실패해도 그 요소만 빠지도록 Promise.allSettled 로 묶었다. 측정 전 후 로컬, KIS 응답을 3초 늦췄을 때 종목명 표시 3.37초 0.31초 (배지는 3.30초) prod, 처음 여는 종목 (화면 전환 뒤 헤더까지) 0.70초 0.40~0.59초 prod, 이미 열어 본 종목 (클릭부터 헤더까지) 0.60~0.63초 0.35초 · 0.70초 prod 수치는 방향을 확인한 정도로 본다. 이미 열어 본 종목은 두 번밖에 재지 못했고, 0.70초가 나온 회차는 화면 전환부터 0.42초로 늦은 데다 응답이 끝나고 0.3초가 지나서야 헤더가 떴는데 그 원인은 아직 보지 않았다. 대가도 하나 생겼다. 시장조치 종목에서는 배지가 뒤늦게 붙으면서 옆의 홈페이지 아이콘이 65~69px 밀리고 모바일에서는 헤더가 5px 높아진다. 배지 자리를 옮기는 건 디자인 결정이라 이번에는 그대로 두었다. 갱신되지 않던 차트 당일 봉 헤더를 조사하면서 종목 상세에 들어갈 때 시세 요청이 같은 주소로 두 번 나가는 것도 같이 봤다. 요청이 한 번 더 나가는 정도로 여겨 backlog에 두었던 항목인데, 원인을 따라가 보니 차트 쪽 기능이 멈춰 있었다. 헤더 키 = 종목 · 시장 · 종가 날짜 60초 폴링 차트 키 = 종목 · 시장 구독만, 폴링 없음 → 키가 달라 캐시 항목이 둘 → 차트는 마운트 때 한 번 요청할 뿐, 헤더의 폴링 결과를 받지 못함 → 정규장 KRX 탭에서 당일 봉이 페이지를 연 시점 값에 고정 (9월 4일부터) 키에서 날짜를 빼기 전에 날짜가 들어간 이유부터 확인했다. 9월 4일 당시에는 15:30 이후가 KRX 탭의 폴링을 멈추는 구간이어서, 키를 바꿔야 장중 마지막 값 대신 확정 종가를 다시 받아 올 수 있었다. KRX 애프터마켓이 열린 9월 14일부터는 그 시간에도 폴링이 돌고 있으므로 "날짜가 바뀌면 한 번 다시 요청"으로 같은 동작이 나온다. 키 조립을 함수 하나로 모으고 날짜를 뺐다. 새로고침 하거나 페이지를 떠났다 돌아오면 갱신되어서 그동안 눈치 못 챘던 부분이다. 키 통합 뒤 헤더로 넘어온 차트 응답 키를 합치자 반대 방향의 문제가 생겼다. 장외의 NXT 종목에서 헤더는 요청을 끄고 서버가 렌더한 값을 보여 주는데, 차트는 그 시간에도 한 번은 요청을 보낸다. 둘이 같은 캐시 항목을 보게 되면서 차트의 요청 실패가 헤더에 "일시 지연" 배지로 붙었다. 지연된 값이 아닌데 지연이라고 표시한 것이다. 성공 응답 쪽도 살펴보니 #147에서 만든 개장 전 등락 초기화 판정에 차트가 받아 둔 세션 값이 끼어들 수 있었다. 그래서 헤더는 자기 요청이 꺼져 있는 동안 공유 항목을 읽지 않게 막았다. 확인 전 후 진입 시 시세 요청 2회 1회 캐시 항목 2개, 폴링은 헤더 것만 갱신 1개를 헤더와 차트가 함께 구독 휴장일이라 브라우저 시계를 정규장으로 돌려, 폴링 결과가 두 곳에 함께 들어가는 것까지만 확인했다. 실제로 봉이 움직이는지는 다음 거래일 장중에 볼 계획이다. 정리 F121 종결 — 헤더 조회 병렬화와 시장조치 배지의 Suspense 분리. KIS 응답을 3초 늦춰도 종목명은 0.31초에 표시 종목 route 렌더 방식 정정 — revalidate 선언은 처음부터 미동작. 요청 시 렌더를 유지하고 선언 삭제, 페이지 캐시는 홈과 sitemap만 시세 캐시 키 통일 — 헤더와 차트가 한 항목을 공유, 진입 시 요청 2 → 1회. 요청이 꺼진 헤더는 공유 항목을 읽지 않음. 장중 확인은 다음 거래일 G1 반영 — README 정정 10건과 렌더 방식 서술. 코드에 없던 "처리 누락을 컴파일 단에서 검출" 주장은 삭제 부수 수정 — 종목 조회 실패가 404로 보이던 것을 오류 화면으로, 사용처 없는 조회 함수 삭제 병렬화 한 건으로 끝낼 생각이었는데, 종목 상세로 들어가는 경로 하나에서 세 가지가 차례로 나왔다. 그중 revalidate는 README에 주기까지 적어 두고도 응답 헤더를 한 번도 열어 보지 않은 설정이었다. 문서를 코드와 대조하는 일을 좀 형식적인 정리로 여겼는데, 이 건은 그 대조가 아니었으면 면접에서 동작하지 않는 캐시를 설명하고 있었을 것 같다. 다음 작업 G1 — 새 세션에서 README를 처음 읽는 사람 시점으로 검토 코드 읽기(G2) — 검색부터 차트까지 핵심 경로를 따라가며 직접 설명할 수 있게 정리. 시작은 검색 경로