GitHub가 Issues 네비게이션의 지연을 순간의 체험으로 바꾼 기술을 공개했다. 클라이언트 캐싱, 스마트 프리페칭, 서비스 워커를 결합한 아키텍처로 'Instant' 네비게이션(200ms 이하)의 비중을 4%에서 22%로 끌어올렸으며, React 네비게이션에선 70%까지 달성했다.

이슈 트래킹 사이에 페이지를 오갈 때 매번 100ms, 500ms 단위의 지연이 누적되면 개발자의 '사고의 흐름(flow)'이 끊긴다. GitHub Issues 성능팀은 단순히 "빠르게"가 아니라 "느껴지는 속도"를 경쟁의 기준으로 삼았다. 2026년 현재, 개발자들은 로컬 우선 도구들의 빠른 응답성을 매일 경험하며, Issues도 그 수준과 비교되고 있다는 판단에서다.

문제의 본질: 아키텍처, 아니 요청 흐름

GitHub는 먼저 "빠르다"는 게 무엇인지 정의했다. 제너릭 페이지 메트릭 대신 HPC(Highest Priority Content) 지표를 도입했다. 이슈 제목이나 본문이 처음 렌더링되는 시점을 측정하는 이 지표는 웹 바이탈의 LCP(Largest Contentful Paint)와 유사하지만, 사용자 중심의 관찰에 더 가깝다.

지난 몇 년간 GitHub는 p90, p99 같은 '꼬리 개선'에 집중했다. 그러나 극소수 사용자의 경험만 나아져선 안 된다. 새로운 목표는 '대다수 사용자의 일반적 경로'를 빠르게 하기였다.

분석 결과, 이슈 조회 네비게이션은 세 가지 경로로 나뉜다:

• 하드 네비게이션 (전체 로드, 브라우저 새로고침): 네트워크 + 서버 렌더링 + 자바스크립트 부팅 비용 전부
• Turbo 네비게이션 (Rails Turbo 전환): 일부 오버헤드 회피, 여전히 서버 응답 의존
• 소프트 네비게이션 (React 내 클라이언트 전환): 가장 빠르지만, 과거 측정 데이터는 하드 네비게이션이 전체의 대다수였다.

GitHub는 "React만 빠르게" 접근을 거부했다. 대신 가장 느린 경로, 가장 많이 사용하는 경로를 모두 개선하기로 결정했다.

전략 1: 클라이언트 캐싱 + Stale-While-Revalidate

먼저 React 네비게이션부터 시작했다. 분석에서 개발자들은 협업 중 같은 이슈를 반복적으로 열고 닫는 패턴을 보였다. 캐시 히트율 가능성을 약 30%로 추정했다.

IndexedDB 기반 캐싱을 도입했다. 메모리 캐시와 달리 탭 닫기, 브라우저 재시작 후에도 데이터가 남는 브라우저 저장소다. 이 위에 Stale-While-Revalidate(SWR) 패턴을 얹었다:

1. 읽기 경로: 네비게이션 시 로컬 캐시에서 먼저 로드 → 즉시 렌더링
2. 재검증 경로: 백그라운드에서 네트워크 요청 → 데이터 변경 시만 UI 동기화
3. 네트워크 장애 시: 캐시된 데이터로 페이지 제공, 연결 복구 후 갱신

이 접근법은 "캐시 vs 정확성"이 아니라 지연 우선, 비동기 일관성 검사다.

결과: React 네비게이션의 'Instant' 비중이 4%에서 22%로 상승. 캐시 히트율은 약 33%. 단, 서버와 캐시의 불일치는 약 4.7%로 파악되었지만, 체감 성능 향상이 이를 정당화했다.

전략 2: 스마트 프리페칭(Preheating)

캐시 히트율 33%는 충분하지 않았다. 단순 '모든 이슈를 미리 페칭'은 시스템에 부담을 주었다. 대신 Preheating 개념을 도입했다: 사용자가 클릭할 가능성 높은 이슈 참조들에 미리 접근, 캐시에 데이터를 준비해 두되, 캐시에 이미 있으면 네트워크 요청을 멈춘다.

이는 전통적 프리로드가 아니라 캐시 채우기 전략이다. 신선도와 용량 사용 사이의 의식적 트레이드오프로, 약간 낡은 데이터라도 사용자가 열면 백그라운드에서 동기화하면 된다는 계산이다.

구현:

• 이슈 목록, 대시보드, 프로젝트 같은 고의도 화면에서 자동 트리거
• 로우 우선도 워커에서 실행, 서킷 브레이커로 과부하 방어
• 사용자 작업이 항상 우선순위 획득

결과: 'Instant' 네비게이션 30%로 상승. **React 네비게이션은 70%**까지 증가. 캐시 히트율 96%에 달했다.

전략 3: 서비스 워커로 하드 네비게이션도 포괄

새로고침, 새 탭, 직접 URL, 외부 링크 같은 하드 네비게이션은 항상 발생한다. JavaScript 런타임이 아직 준비되지 않은 상태에서도 이들을 개선할 수 있는 방법은 제한적이다.

GitHub는 서비스 워커를 도입했다. 이 브라우저 스크립트는 페이지 밖에서 실행되며 네트워크 요청을 가로챈다. 이슈 페이지 요청이 들어오면 캐시를 확인하고:

• 캐시 히트: 서버에 헤더로 신호 → 서버는 최소 HTML 셸만 반환, React가 로컬 캐시 데이터로 렌더링
• 캐시 미스: 일반 응답 반환 (서버가 데이터 로드 후 서버 렌더링)

이 메커니즘으로 하드 네비게이션도 캐시의 혜택을 받는다.

결과: 흐름의 연속성 회복

최종 결과는 명확했다. 전체 네비게이션 중:

• Instant (< 200ms): 4% → 약 30%
• React 기반 soft navigation: 4% → 70% instant
• 캐시 히트율: 약 33% → 96%

개발자들이 이슈를 오가며 '지연으로 인한 맥락 전환'을 겪는 빈도가 크게 줄었다. 이는 단순 성능 수치가 아니라 업무 흐름의 질을 높이는 변화다.

숨은 설계 철학: 확장성과 용량의 균형

GitHub 기술팀이 강조한 핵심은 **"성능이 무료가 아니다"**는 현실이다. 단순히 모든 데이터를 미리 로드하면 서버에 N+1 접근 패턴이 생긴다. 대신:

1. 지연 우선, 일관성은 비동기로: 사용자 화면에 빠르게 뭔가 보이되, 정확성은 나중에 확보
2. 용량 제약 인식: 프리페칭도 회로 차단기로 보호, 사용자 작업에 양보
3. 경로별 최적화: 모든 네비게이션을 같게 취급하지 않고, 하드/소프트/Turbo 각각 개선

이 사고방식은 대규모 사용자 기반의 웹 애플리케이션 설계에 그대로 적용 가능하다. 플랫폼이 커질수록, 모든 경로를 "충분히 빠르게"만 하면 평범하고, 일반적 경로를 "즉각적으로" 만들어야 경쟁력이 된다.

과제: Rails에서 React로의 전환 중

GitHub는 여전히 Rails 렌더링 페이지에서 React 기반 프론트엔드로 이행 중이다. 그 경계에서 크로스 네비게이션이 발생하면 하드 로드가 불가피하다. GitHub는 이 구조적 한계를 인식하면서도 "플랫폼 마이그레이션만으로는 기다릴 수 없다"며 현 상태에서 최대한의 개선을 추진했다. 향후 React 비중이 높아질수록 하드 네비게이션의 절대 빈도도 자연스레 낮아질 전망이다.

결론적으로, GitHub는 이슈 협업 중 일어나는 "작은 지연들의 누적"을 시스템적으로 타파했다. 이 기술 스택은 데이터 중심 웹 앱의 성능 최적화에 직접 전이 가능한 패턴으로, 대규모 개발자 도구를 만드는 팀들에게 실질적 참고 자료가 될 것이다.