GitHub Issues가 클라이언트 사이드 아키텍처를 재설계한 이유
GitHub Issues 팀은 페이지 이동 시 사용자가 느끼는 지연(perceived latency)을 줄이기 위해 클라이언트 사이드 아키텍처를 전면 재설계했다. 기존에는 네비게이션이 발생할 때마다 서버에 요청을 보내고 응답을 기다리는 구조였기 때문에, 네트워크 상태나 서버 응답 속도에 따라 사용자 경험이 크게 달라지는 문제가 있었다. 실제로 즉각적인 네비게이션(instant navigation) 비율이 4%에 불과했다는 수치가 이 문제를 단적으로 보여준다.
백엔드 개발자 관점에서도 이 사례는 중요하다. API 응답 속도를 아무리 최적화해도, 클라이언트가 매번 네트워크 왕복을 기다리는 구조라면 사용자 체감 성능에는 한계가 있다. 즉, 서버 최적화만으로는 해결할 수 없는 영역이 존재하며, 아키텍처 수준의 접근이 필요하다.
핵심 기술 조합: IndexedDB + 인메모리 캐시 + Service Worker
GitHub 팀이 선택한 해법은 세 가지 캐싱 레이어를 조합하는 방식이다.
- 인메모리 캐시: 같은 세션 내에서 반복 접근하는 데이터를 가장 빠르게 제공. 휘발성이지만 접근 속도가 가장 빠르다.
- IndexedDB: 브라우저에 영속적으로 데이터를 저장하여 페이지를 새로 열어도 이전에 불러온 데이터를 즉시 활용 가능하게 한다.
- Service Worker: 네트워크 요청을 가로채고, 캐시된 데이터를 먼저 반환하면서 백그라운드에서 최신 데이터를 동기화하는 역할을 담당한다.
이 구조는 "stale-while-revalidate" 패턴과 유사하다. 사용자에게는 캐시된 데이터를 즉시 보여주고, 동시에 서버에서 최신 데이터를 받아 갱신하는 방식이다. 결과적으로 사용자는 로딩을 기다리지 않고 화면을 먼저 볼 수 있다.
예측 기반 프리페칭으로 레이턴시를 선제적으로 제거
단순 캐싱을 넘어 GitHub 팀이 도입한 또 다른 핵심 전략은 **예측 기반 프리페칭(predictive prefetching)**이다. 사용자가 특정 링크에 마우스를 올리거나 특정 패턴으로 이동하는 행동을 감지하여, 실제 클릭이 발생하기 전에 미리 데이터를 가져오는 방식이다.
// 예시: 링크 hover 시 프리페치 트리거
element.addEventListener('mouseover', () => {
prefetchData(element.href);
});
이 접근법의 핵심은 레이턴시를 숨기는 것이 아니라 제거하는 것이다. 서버 응답 시간이 200ms라도, 사용자가 클릭하기 100ms 전에 이미 요청을 보냈다면 체감 대기 시간은 0에 가까워진다. 백그라운드 동기화와 결합하면 캐시 데이터의 신선도(freshness)도 유지할 수 있다.
이 결과 즉각적인 네비게이션 비율이 4%에서 22%로 상승했으며, 전체 네비게이션 레이턴시도 의미 있게 감소했다.
정리
- 인메모리 캐시 → IndexedDB → Service Worker의 다층 캐싱 구조로 네트워크 의존도를 낮추고 즉각적인 응답을 구현할 수 있다.
- 예측 기반 프리페칭은 실제 요청이 발생하기 전에 데이터를 준비해두어 체감 레이턴시를 근본적으로 줄인다.
- 서버 API 최적화만으로는 한계가 있으며, 클라이언트 아키텍처 수준의 캐싱 전략을 함께 설계해야 사용자 경험을 실질적으로 개선할 수 있다.