Service Worker

일반적인 웹 페이지의 JavaScript는 탭이 열려 있을 때만 실행됩니다. 사용자가 탭을 닫거나 네트워크가 끊기면, 앱은 더 이상 요청을 가로채거나 데이터를 미리 준비하거나 백그라운드 작업을 이어 갈 수 없습니다. 이 구조에서는 오프라인 경험과 백그라운드 동작이 매우 제한됩니다. 단순한 캐시만으로도 부족한 이유가 있습니다. 브라우저 저장소에 파일이 남아 있어도, 어떤 요청에 캐시를 우선 쓸지, 언제 네트워크를 다시 조회할지, 실패한 요청을 언제 재시도할지는 페이지 바깥에서 판단해 줄 실행 주체가 필요합니다.

웹을 앱처럼 쓰고 싶다는 요구가 커지면서, 모바일 네이티브 앱이 갖고 있던 오프라인 동작과 알림 기능을 브라우저에서도 기대하게 됐습니다. 초기에는 AppCache가 시도됐지만 캐시 무효화와 버전 관리가 너무 불안정해서 실무에서 신뢰하기 어려웠습니다. Service Worker는 이 실패를 교훈으로 삼아, 단순한 캐시 설정 파일이 아니라 이벤트를 처리하는 스크립트 형태로 등장했습니다. 브라우저가 관리하는 백그라운드 실행 모델 위에서, 페이지와 네트워크 사이에 개발자가 정책을 넣을 수 있게 된 것입니다.

Service Worker는 페이지가 `register()`로 스크립트를 등록하면서 시작됩니다. 브라우저는 그 스크립트를 설치하고 활성화한 뒤, 해당 범위(scope)에 속하는 페이지 요청에 대해 fetch 이벤트를 Service Worker에게 먼저 전달할 수 있습니다. Service Worker는 이 이벤트를 받으면 캐시에서 응답할지, 네트워크를 먼저 조회할지, 둘을 조합할지를 결정합니다. 정적 자산은 설치 단계에서 미리 캐시할 수 있고, API 응답은 요청 시점에 캐시 전략을 다르게 적용할 수 있습니다. 중요한 점은 Service Worker가 페이지와 독립된 생명주기를 가진다는 사실입니다. DOM은 없지만, 브라우저는 푸시 알림이나 백그라운드 동기화 같은 이벤트가 오면 페이지가 열려 있지 않아도 Service Worker를 다시 깨워 작업을 처리할 수 있습니다.

Service Worker와 Web Worker는 둘 다 메인 스레드 밖에서 실행되지만 목적과 위치가 다릅니다. Web Worker는 현재 열린 페이지가 무거운 계산을 다른 스레드로 넘기기 위한 도구이고, Service Worker는 페이지와 네트워크 사이에서 요청과 캐시를 제어하는 브라우저 측 프록시에 가깝습니다. 그래서 큰 JSON 파싱이나 이미지 처리처럼 계산을 옮기고 싶다면 Web Worker가 맞고, 오프라인 캐시, 푸시 알림, 네트워크 재시도 정책이 필요하다면 Service Worker가 맞습니다. 둘 다 DOM을 직접 다루지는 못하지만, 어느 문제를 해결하려는지에 따라 완전히 다른 실행 모델입니다.

Service Worker는 PWA에서 가장 실용적인 핵심 부품입니다. 앱 셸을 미리 캐시해 두면 네트워크가 잠시 끊겨도 기본 화면은 유지할 수 있고, 재방문 시에는 정적 자산을 즉시 보여 준 뒤 최신 내용을 백그라운드에서 갱신하는 식의 경험을 만들 수 있습니다. 운영할 때 가장 까다로운 부분은 버전 관리입니다. 오래된 캐시가 계속 남아 있으면 새 배포가 반영되지 않고, 반대로 캐시를 너무 공격적으로 지우면 오프라인 경험이 무너집니다. 캐시 이름과 활성화 전략을 계획 없이 바꾸면 사용자가 서로 다른 자산 버전을 섞어 받는 문제가 생길 수 있습니다. 또 Service Worker는 모든 문제를 해결하는 만능 백그라운드 런타임이 아닙니다. 오래 실행되는 계산 작업이나 화면 직접 조작은 맡길 수 없고, 브라우저가 허용한 이벤트와 수명 안에서만 동작합니다. 그래서 무엇을 캐시 정책으로 풀고, 무엇을 일반 애플리케이션 로직으로 남길지 경계를 분명히 해야 합니다.