JavaScript 서비스 워커(Service Worker)를 활용한 오프라인 캐싱 원리

지하철 엘리베이터 사이를 지나거나 터널을 통과할 때, 혹은 공공 Wi-Fi의 불안정한 신호로 인해 공들여 작성하던 게시물이 날아가거나 화면이 하얗게 굳어버린 경험은 누구에게나 고통스러운 기억입니다. 사용자 입장에서는 단순한 '불편'이지만, 비즈니스 관점에서 이는 곧바로 '이탈률 상승'과 '매출 감소'로 직결됩니다. 2025년 현재, 구글의 통계에 따르면 페이지 로딩 속도가 3초를 넘길 때 이탈률은 32% 증가하며, 오프라인 상태에서 아무런 대응을 하지 못하는 웹 앱은 사용자 신뢰도를 70% 이상 하락시킵니다. 이제 개발자에게 오프라인 대응은 '선택'이 아닌 '생존'의 문제입니다.

 

 

서비스 워커(Service Worker): 브라우저와 네트워크 사이의 전략적 중재자

서비스 워커는 브라우저가 백그라운드에서 실행하는 스크립트로, 웹 페이지와는 별개의 생명주기를 갖습니다. 가장 핵심적인 역할은 '네트워크 프록시'로서, 브라우저가 서버로 던지는 모든 요청(Request)을 중간에서 가로채는(Intercept) 것입니다. 이를 통해 개발자는 네트워크 상태에 상관없이 사용자에게 전달할 응답(Response)을 직접 제어할 수 있습니다.

 

 

캐싱의 핵심 메커니즘: Fetch 이벤트 제어

기존의 HTTP 캐시가 브라우저의 판단에 의존했다면, 서비스 워커는 개발자가 작성한 로직에 따라 움직입니다. 서비스 워커가 설치(Install)되고 활성화(Activate)되면, 이후 발생하는 모든 fetch 이벤트를 감시합니다. 이때 미리 저장해둔 'Cache Storage'에서 데이터를 꺼내줄지, 아니면 실시간으로 네트워크에 요청할지를 0.1ms 단위의 로직으로 결정하게 됩니다. 이것이 바로 오프라인에서도 웹 사이트가 작동하는 과학적 원리입니다.

 

 

실무에서 즉시 적용하는 오프라인 캐싱 전략 Top 3

모든 데이터를 캐싱하는 것은 저장 공간 낭비이며 기기 성능 저하를 초래합니다. 콘텐츠의 성격에 따라 최적의 전략을 선택하는 것이 10년 차 에디터가 강조하는 핵심 포인트입니다.

 

전략 명칭	동작 원리	적합한 콘텐츠	사용자 경험(UX) 이점
Cache First	캐시 확인 후 없으면 네트워크 요청	로고, 폰트, CSS, JS 파일	재방문 시 로딩 속도 80% 이상 절감
Network First	네트워크 우선 시도 후 실패 시 캐시	뉴스 피드, 실시간 가격 정보	최신 데이터 보장 및 오프라인 대비
Stale-While-Revalidate	캐시를 즉시 보여주고 백그라운드 갱신	사용자 프로필, 소셜 미디어 게시물	즉각적인 반응성과 데이터 최신성 양립

 

 

실패 없는 서비스 워커 구현을 위한 5단계 로드맵

단순히 코드를 복사하는 것이 아니라, 브라우저의 생명주기를 이해하고 다음의 순서에 따라 정교하게 설계해야 합니다.

 

1. HTTPS 환경 구축: 서비스 워커는 강력한 네트워크 제어 권한을 가지므로 보안을 위해 HTTPS(혹은 localhost)에서만 작동합니다. 보안 인증서가 없는 환경에서는 등록조차 되지 않음을 명심하십시오.
2. 서비스 워커 등록(Registration): 메인 JavaScript 파일에서 navigator.serviceWorker.register()를 호출하여 브라우저에 존재를 알립니다. 이때 범위(Scope) 설정이 중요합니다.
3. 정적 자원 프리캐싱(Pre-caching): install 이벤트 단계에서 사이트 구동에 필수적인 App Shell(HTML, CSS, 핵심 이미지)을 caches.open()을 통해 저장합니다. 보통 5MB 이내로 구성하는 것이 효율적입니다.
4. 동적 요청 가로채기(Intercepting): fetch 이벤트 리스너를 작성하여 네트워크 응답을 가로챕니다. 응답 코드가 200인 경우에만 캐시에 업데이트하는 예외 처리가 반드시 포함되어야 합니다.
5. 캐시 퍼지(Cache Purge): 서비스 워커 파일이 1바이트라도 변경되면 브라우저는 새 버전으로 인식합니다. activate 단계에서 오래된 캐시 이름을 비교하여 caches.delete()로 삭제함으로써 사용자 기기의 용량을 확보합니다.

 

수석 연구원의 제언: 흔히 범하는 실수와 FAQ

많은 개발자가 서비스 워커 도입 초기, 업데이트가 즉시 반영되지 않는 현상 때문에 당혹감을 느낍니다. 이는 서비스 워커의 강력한 캐싱 능력 때문이며, 이를 해결하기 위한 전략적인 접근이 필요합니다.

 

• Q: 왜 수정한 코드가 새로고침을 해도 반영되지 않나요?A: 기존 서비스 워커가 페이지를 제어하고 있기 때문입니다. 새 서비스 워커가 설치되어도 기존 탭이 모두 닫히기 전까지는 '대기(Waiting)' 상태에 머뭅니다. 개발 단계에서는 self.skipWaiting()을 사용하거나 DevTools의 'Update on reload' 체크박스를 활용하십시오.
• Q: 캐시 용량 제한은 어느 정도인가요?A: 브라우저와 기기 전체 용량에 따라 다르지만, 일반적으로 가용한 디스크 공간의 일정 비율(Chrome의 경우 최대 60%까지도 공유)을 사용합니다. 하지만 안정성을 위해 앱당 50MB~100MB를 넘지 않도록 관리하는 것이 권장됩니다.
• Q: API POST 요청도 캐싱이 가능한가요?A: 기본적으로 캐시 API는 GET 요청만 저장할 수 있습니다. POST 요청을 오프라인에서 처리하려면 IndexedDB를 활용하여 데이터를 임시 저장한 후, 네트워크가 복구되었을 때 Background Sync를 통해 서버로 전송하는 방식을 병행해야 합니다.

서비스 워커는 단순히 오프라인을 지원하는 도구를 넘어, 웹을 네이티브 앱 수준의 퍼포먼스로 끌어올리는 혁신적인 기술입니다. 위에서 제시한 전략과 수치들을 바탕으로 여러분의 서비스를 '언제 어디서나 연결된(Always-on)' 경험으로 탈바꿈시켜 보시기 바랍니다. 기술적 구현만큼 중요한 것은 사용자가 오프라인임을 인지하더라도 당황하지 않도록 적절한 UI 가이드(Offline UI)를 제공하는 세심함임을 잊지 마십시오.

 

수석 연구원의 다음 단계 제언: 오프라인 캐싱 구축이 완료되었다면, 이제 사용자의 기기에 직접 푸시 알림을 보내는 'Push API'와 데이터 정합성을 보장하는 'Background Sync'를 결합하여 완벽한 PWA(Progressive Web App)로 진화시켜 보시기 바랍니다.

텍스트 위주의 글이라 눈이 피로하셨을 텐데, 마지막까지 집중해 주셔서 정말 감사합니다.