GitHub Issues 성능 혁신: IndexedDB 캐시로 즉각 로딩 실현

GitHub Issues가 '느리다'는 느낌, 사실은 구조 문제였다

GitHub Issues를 사용하다 보면 이슈를 열고, 링크된 스레드로 이동하고, 다시 목록으로 돌아오는 작업을 반복하게 됩니다. 이 과정에서 발생하는 짧은 지연조차 개발자의 집중 흐름(flow)을 끊는 맥락 전환(context switch)이 됩니다. GitHub 엔지니어링팀은 2026년 초, 단순한 백엔드 최적화가 아닌 데이터 흐름과 내비게이션 구조 자체를 재설계하는 프로젝트에 착수했습니다.

핵심 지표: HPC(Highest Priority Content)

GitHub은 페이지 성능을 측정할 때 'HPC(최우선 콘텐츠 렌더링 시간)'라는 내부 지표를 사용합니다. 이는 웹 표준 LCP(Largest Contentful Paint, 최대 콘텐츠 렌더링 지표)와 유사하게, 사용자가 가장 중요하게 여기는 요소(이슈 제목 또는 본문)가 처음 화면에 표시되는 시점을 측정합니다.

팀은 단순히 최악의 케이스(p99)를 줄이는 데 집중하는 대신, 전체 사용자 중 '즉각' 및 '빠름' 구간에 도달하는 비율을 높이는 것으로 목표를 전환했습니다.

3단계 성능 개선 아키텍처

1단계: IndexedDB 기반 클라이언트 캐시

첫 번째 전략은 반복 방문 패턴에 주목한 것입니다. 분석 결과 사용자들이 동일한 이슈를 협업 과정에서 자주 재방문한다는 사실이 확인됐습니다. 이를 기반으로 팀은 기존 메모리 저장소에 IndexedDB 기반 영구 캐시를 추가했습니다.

IndexedDB를 선택한 이유는 다음과 같습니다:

• 탭을 닫거나 브라우저를 재시작해도 데이터가 유지됨
• localStorage보다 훨씬 큰 저장 용량
• 키 기반 빠른 조회 지원

캐시 전략은 SWR(Stale-While-Revalidate, 오래된 데이터 즉시 반환 후 백그라운드 갱신) 방식입니다. 이슈 페이지에 진입하면 즉시 캐시 데이터로 화면을 렌더링하고, 동시에 서버에서 최신 데이터를 받아 UI를 갱신합니다. 네트워크가 불안정한 경우에도 캐시 데이터를 기반으로 페이지를 표시할 수 있어 사용성이 크게 향상됩니다.

결과: React 소프트 내비게이션 중 즉각 응답 비율이 4% → 22%로 상승, 캐시 적중률 약 33%.

2단계: 예열(Preheating) 전략으로 캐시 적중률 96%까지 끌어올리기

캐시가 있어도 사용자가 클릭하기 전까지 데이터가 없으면 소용이 없습니다. 팀은 '예열(Preheating)' 개념을 도입했습니다. 이슈 목록, 대시보드 등 사용자의 다음 행동을 예측할 수 있는 페이지에서, 아직 캐시에 없는 이슈 데이터를 미리 가져오는 방식입니다.

일반적인 프리페치(prefetch, 미리 불러오기)와 달리 예열은 캐시에 없는 항목만 요청합니다. 이미 캐시된 데이터가 있으면 요청을 건너뛰어 불필요한 서버 부하를 방지합니다. 또한 저우선순위 워커에서 실행되며 속도 제한과 서킷 브레이커가 적용되어 사용자 작업보다 항상 낮은 우선순위를 유지합니다.

결과: 전체 즉각 응답 비율 30%, React 내비게이션 기준 최대 70%, 캐시 적중률 96%.

3단계: 서비스 워커(Service Worker)로 하드 내비게이션까지 가속

소프트 내비게이션(같은 React 앱 내 이동)만으로는 부족했습니다. 새 탭 열기, 직접 URL 입력, 브라우저 새로고침 같은 하드 내비게이션 시에도 캐시를 활용할 방법이 필요했습니다.

서비스 워커(Service Worker)는 페이지 자바스크립트와 독립적으로 동작하는 브라우저 스크립트로, 네트워크 요청을 가로채어 캐시 데이터를 활용할 수 있습니다. GitHub은 이를 이용해 이슈 페이지 요청 시 캐시 적중 여부를 서버에 전달합니다. 캐시가 있으면 서버는 전체 SSR(서버 사이드 렌더링) 대신 경량 HTML 껍데기만 반환하고, 실제 데이터는 클라이언트 캐시에서 렌더링합니다.

성능 개선 결과

특히 주목할 점은 하위 백분위의 극적인 개선입니다. P10이 600ms에서 70ms로, P25가 800ms에서 120ms로 떨어졌습니다. 중앙값 역시 처음으로 1초 미만 구간으로 진입했습니다.

개발자·학생이 배울 수 있는 아키텍처 패턴

GitHub의 접근 방식은 단순한 성능 최적화를 넘어 로컬 퍼스트(Local-first) 애플리케이션 아키텍처의 실제 사례입니다. 이 패턴은 어떤 데이터 집약적 웹앱에도 적용할 수 있습니다.

핵심 원리: 네트워크를 기다리지 말고 로컬 데이터로 먼저 렌더링한 뒤, 백그라운드에서 최신 데이터를 동기화한다.

웹 개발을 공부하는 학생이라면 IndexedDB, 서비스 워커, SWR 패턴을 개인 프로젝트에 직접 적용해보거나, React Query나 SWR 라이브러리를 통해 같은 개념을 손쉽게 경험해볼 수 있습니다.

앞으로의 과제

GitHub 팀은 여기서 멈추지 않습니다. 현재 하드 내비게이션에서의 자바스크립트 실행 시간이 새로운 병목으로 떠오르고 있습니다. 팀은 엣지(edge) 기반 UI 전송 레이어와 백엔드 스택 리라이트를 계획 중입니다. 성능은 한 번의 프로젝트가 아닌 지속적인 시스템 투자임을 이 사례는 명확히 보여줍니다.