GitHub Engineering은 2026년 5월 14일 “From latency to instant: Modernizing GitHub Issues navigation performance”라는 글을 공개했다. 핵심은 간단하다. GitHub Issues에서 화면 전환을 더 빠르게 만들기 위해 클라이언트 캐싱, 스마트 프리패칭, 서비스 워커를 조합했다는 내용이다.
이 사례가 흥미로운 이유는 “서버를 더 빠르게 만들었다”가 아니라는 점이다. 물론 서버 성능도 중요하다. 하지만 사용자가 느끼는 속도는 네트워크 왕복, 브라우저 렌더링, 데이터 재사용, 인터랙션 타이밍이 함께 만든다. GitHub Issues 같은 대형 웹앱에서는 체감 성능을 클라이언트에서 얼마나 잘 설계하느냐가 중요해진다.
빠른 웹앱과 빠르게 느껴지는 웹앱은 다르다
성능 최적화에서 자주 하는 실수가 있다. 백엔드 응답 시간을 줄이면 사용자가 무조건 빠르다고 느낄 것이라고 가정하는 것이다.
현실은 다르다. 사용자는 다음 순간에 민감하다.
- 클릭 후 화면이 반응하기까지의 시간
- 목록에서 상세로 이동할 때의 지연
- 뒤로 가기/앞으로 가기 동작
- 이미 본 데이터를 다시 볼 때의 로딩
- 네트워크가 흔들릴 때의 화면 안정성
서버 응답이 200ms라도 브라우저가 매번 빈 화면을 보여주면 느리게 느껴진다. 반대로 서버 응답이 조금 느려도 이전 데이터를 즉시 보여주고 뒤에서 갱신하면 훨씬 빠르게 느껴진다.
GitHub 사례의 핵심 3가지
GitHub 글의 메타 설명은 세 가지 키워드를 강조한다.
- client-side caching
- smart prefetching
- service workers
각각을 실무 관점에서 풀어보면 다음과 같다.
1. 클라이언트 캐싱
Issues 화면은 사용자가 반복적으로 오가는 데이터가 많다.
- 이슈 목록
- 이슈 상세
- 댓글
- 라벨
- 담당자
- 프로젝트/마일스톤 정보
이 데이터를 매번 새로 가져오면 낭비가 크다. 클라이언트 캐싱은 이미 받은 데이터를 브라우저 메모리나 스토리지에 보관하고, 다음 화면 전환에서 즉시 재사용한다.
중요한 것은 캐시 자체가 아니라 무효화 전략이다. 오래된 이슈 상태를 보여주면 협업 도구에서는 문제가 된다. 그래서 좋은 캐시는 보통 다음 방식을 섞는다.
- 먼저 캐시된 데이터를 즉시 보여준다.
- 백그라운드에서 최신 데이터를 가져온다.
- 변경이 있으면 화면을 조용히 갱신한다.
- 사용자의 입력과 충돌하지 않도록 조심한다.
이 방식은 stale-while-revalidate 패턴과 유사하다.
2. 스마트 프리패칭
프리패칭은 사용자가 아직 요청하지 않은 데이터를 미리 가져오는 기법이다. 하지만 무작정 많이 가져오면 오히려 비용이 커진다.
스마트 프리패칭은 사용자의 다음 행동 가능성을 예측한다.
- 목록에서 마우스를 올린 이슈
- 현재 viewport 안에 보이는 링크
- 최근 자주 방문한 repo
- 키보드 내비게이션으로 곧 선택될 항목
- 뒤로 가기 시 돌아갈 가능성이 높은 목록
핵심은 “맞을 가능성이 높은 것만” 미리 가져오는 것이다. 프리패칭이 과하면 모바일 데이터, 서버 비용, 브라우저 메모리를 낭비한다.
3. 서비스 워커
서비스 워커는 브라우저와 네트워크 사이에 위치한 프록시처럼 동작한다. 정적 리소스나 API 응답을 캐싱하고, 네트워크가 불안정할 때 대체 응답을 줄 수 있다.
대형 웹앱에서 서비스 워커는 다음 역할을 할 수 있다.
- 앱 shell 캐싱
- 반복 요청 응답 캐싱
- 오프라인 또는 저품질 네트워크 대응
- 백그라운드 업데이트
- 화면 전환 시 즉시 응답 제공
단, 서비스 워커는 강력한 만큼 위험하다. 잘못된 캐시 정책은 사용자를 오래된 UI에 가둘 수 있다. 배포 후 캐시 무효화가 꼬이면 “내 컴퓨터에서만 이상한” 문제가 대량 발생한다.
우리 서비스에 적용할 때의 체크리스트
GitHub 규모가 아니더라도 적용할 수 있는 원칙은 많다.
목록-상세 구조라면 캐시부터 보라
블로그, 관리자 페이지, 이슈 트래커, CRM, 주문 관리 화면은 모두 목록-상세 구조를 가진다. 사용자는 목록에서 상세로 들어갔다가 다시 목록으로 돌아온다.
이때 목록 데이터를 버리지 않는 것만으로도 체감 성능이 좋아진다.
- 스크롤 위치 보존
- 필터/검색어 보존
- 목록 데이터 재사용
- 상세에서 돌아왔을 때 즉시 표시
이 기본기가 안 되어 있으면 서버가 빨라도 서비스는 느리게 느껴진다.
프리패칭은 측정 후 적용하라
프리패칭은 멋있지만 비용이 있다. 특히 SaaS에서 API 호출 비용이 크거나 데이터 권한 검사가 무거운 경우 함부로 넣으면 안 된다.
먼저 확인할 지표는 다음이다.
- 사용자가 실제로 다음에 클릭하는 링크 분포
- 프리패치 적중률
- 프리패치로 증가한 API 호출 수
- 모바일 사용자 비율
- 캐시된 데이터의 평균 재사용 시간
적중률이 낮은 프리패칭은 최적화가 아니라 비용 낭비다.
서비스 워커는 마지막에 도입하라
서비스 워커는 초기에 넣기보다, 병목과 요구사항이 명확할 때 넣는 편이 안전하다. 캐시 버그는 디버깅이 까다롭고, 사용자 브라우저에 오래 남는다.
도입한다면 최소한 다음을 준비해야 한다.
- 버전별 캐시 키 전략
- 강제 업데이트 경로
- 캐시 제거 로직
- 개발/스테이징/프로덕션 분리
- 관측 가능한 로그
AI 시대에도 웹 성능 기본기는 중요하다
요즘은 모든 제품이 AI 기능을 붙이고 있다. 하지만 사용자가 매일 쓰는 화면의 품질은 여전히 기본적인 웹 성능에서 갈린다. AI 요약 버튼이 있어도, 이슈 상세가 늦게 열리면 사용자는 답답해한다.
GitHub Issues 사례는 좋은 reminder다. 대단한 모델을 붙이는 것보다, 클릭 후 즉시 반응하는 제품을 만드는 것이 더 큰 차이를 만들 때가 많다.
결론
GitHub의 Issues 내비게이션 성능 개선은 “체감 성능”을 설계한 사례다. 클라이언트 캐시, 스마트 프리패칭, 서비스 워커는 각각 흔한 기술이지만, 사용자의 이동 흐름에 맞게 조합하면 제품 경험이 크게 달라진다.
우리 서비스에 적용할 때는 순서를 지키는 것이 좋다.
- 사용자의 주요 이동 경로를 측정한다.
- 목록-상세 캐시와 스크롤 복원을 먼저 한다.
- 적중률이 높은 프리패칭만 넣는다.
- 서비스 워커는 캐시 전략과 업데이트 전략이 준비됐을 때 도입한다.
빠른 웹앱은 서버 지표로만 만들 수 없다. 사용자가 “이미 준비되어 있었다”고 느끼게 만드는 것이 진짜 성능 최적화다.
참고
- GitHub Engineering, 2026-05-14: “From latency to instant: Modernizing GitHub Issues navigation performance”