웹 워커와 서비스 워커

우리는 9장에서 Fetch API로 서버 통신, 로컬/세션 스토리지로 클라이언트 데이터 저장, History API로 SPA 라우팅 구현, Canvas API로 웹 그래픽 처리 등 다양한 웹 API와 브라우저 기능들을 학습했습니다.

이제 웹 애플리케이션의 성능과 사용자 경험을 한 단계 더 끌어올릴 수 있는 고급 기술인 웹 워커(Web Workers)와 서비스 워커(Service Workers)에 대해 알아볼 차례입니다.

자바스크립트는 기본적으로 단일 스레드(Single-threaded) 언어입니다.

이 절에서 다루는 페이지 자바스크립트의 이벤트 handler와 DOM 변경은 메인 실행 흐름에서 처리합니다. 그 흐름에 오래 걸리는 계산을 넣으면 다음 이벤트와 화면 갱신을 지연시킬 수 있습니다. 브라우저의 모든 내부 작업이 이 한 스레드에서만 실행된다는 뜻은 아닙니다.

만약 이 메인 스레드에서 복잡하거나 시간이 오래 걸리는 연산(예: 대용량 데이터 처리, 이미지 필터링, 복잡한 애니메이션 계산)을 수행하게 되면, 해당 작업이 끝날 때까지 UI가 멈추거나 반응이 없어지는 블로킹(Blocking) 현상이 발생하여 사용자 경험을 크게 저해합니다.

웹 워커는 메인 스레드 블로킹 문제를 줄이기 위해 자바스크립트 코드를 별도 스레드에서 실행합니다.

이를 통해 계산 비용이 큰 작업을 UI 렌더링 흐름과 분리할 수 있습니다.

서비스 워커는 네트워크 요청 가로채기, 캐싱, 오프라인 응답 같은 기능을 담당하는 브라우저의 백그라운드 실행 단위입니다.

이 절에서는 웹 워커와 서비스 워커의 동작 원리, 기본 사용법, 그리고 활용 시나리오를 정리합니다.

Progressive Web Apps (PWA)에서도 계산 분리와 오프라인 응답에 활용할 수 있습니다. 이 두 기능은 역할이 다르므로, 일반 Worker를 사용하는 페이지가 반드시 Service Worker까지 가져야 하는 것은 아닙니다.

웹 워커 (Web Workers)

웹 워커는 웹 페이지의 메인 실행 스크립트와 독립된 백그라운드 스레드에서 스크립트를 실행할 수 있도록 해줍니다.

이를 통해 메인 스레드가 무거운 연산으로 인해 블로킹되는 것을 방지하고, 웹 페이지 UI의 반응성을 개선할 수 있습니다.

웹 워커의 특징

• 독립적인 스레드: 웹 워커는 메인 스레드와 별도의 실행 환경을 가집니다.
• DOM 접근 불가: 워커 스레드는 HTML 문서의 DOM에 직접 접근할 수 없습니다. 이는 워커가 UI 업데이트를 직접 수행할 수 없다는 의미입니다.
• 통신 방식: 메인 스레드와 워커 스레드는 postMessage() 메서드를 통한 메시지 기반 통신(onmessage 이벤트 리스너)으로 데이터를 주고받습니다. 일반 데이터는 구조화 복제되고, Transferable은 소유권을 이전할 수 있습니다.
• 제한된 API: 워커는 alert(), confirm()과 같은 브라우저 UI 관련 API에 접근할 수 없습니다. 대신 XMLHttpRequest, fetch, IndexedDB, setTimeout, setInterval 등은 사용할 수 있습니다.
• 동일 출처 정책: 워커 스크립트는 메인 스크립트와 동일한 출처(origin)에 있어야 합니다.

웹 워커 사용법

// worker.js
// 이 스크립트는 웹 워커 스레드에서 실행됩니다.

// 메인 스크립트로부터 메시지를 받으면 실행되는 이벤트 핸들러
self.onmessage = function(event) {
    const number = event.data; // 메인 스크립트로부터 전달받은 데이터

    console.log(`워커: ${number}까지의 소수 계산을 시작합니다.`);

    // 복잡하고 시간이 오래 걸리는 연산 (예시: 소수 계산)
    let primes = [];
    for (let i = 2; i <= number; i++) {
        let isPrime = true;
        for (let j = 2; j * j <= i; j++) {
            if (i % j === 0) {
                isPrime = false;
                break;
            }
        }
        if (isPrime) {
            primes.push(i);
        }
    }

    console.log(`워커: ${number}까지의 소수 계산 완료.`);

    // 계산 결과를 다시 메인 스크립트로 전송
    self.postMessage(primes);
};

// main.js (또는 HTML <script>)
const startButton = document.getElementById('startButton');
const resultDiv = document.getElementById('result');
const statusDiv = document.getElementById('status');

let myWorker;

startButton.addEventListener('click', () => {
    statusDiv.textContent = "워커 시작 중... 잠시 기다려 주세요.";
    // 이전에 워커가 있다면 종료
    if (myWorker) {
        myWorker.terminate();
        myWorker = null;
    }

    // 새 워커 생성 (워커 스크립트 파일 경로 지정)
    myWorker = new Worker('worker.js');

    // 워커로부터 메시지를 받을 때 실행될 함수
    myWorker.onmessage = function(event) {
        const primes = event.data; // 워커로부터 전달받은 소수 배열
        resultDiv.textContent = `계산된 소수 개수: ${primes.length}`;
        statusDiv.textContent = "계산 완료! (메인 스레드는 블로킹되지 않았습니다.)";
        myWorker.terminate(); // 작업이 끝나면 워커 종료
        myWorker = null;
    };

    // 워커에서 에러 발생 시
    myWorker.onerror = function(error) {
        statusDiv.textContent = `워커 오류: ${error.message}`;
        console.error("워커 오류:", error);
    };

    // 워커에게 계산을 시작하도록 메시지 전송
    const numberToCalculate = 500000; // 큰 숫자
    myWorker.postMessage(numberToCalculate);

    statusDiv.textContent = `워커에게 ${numberToCalculate}까지의 소수 계산 명령을 보냈습니다. (UI는 반응 중)`;
});

// HTML에 버튼과 결과 표시 영역 추가
/*
<button id="startButton">복잡한 계산 시작 (워커 사용)</button>
<div id="status"></div>
<div id="result"></div>
*/

워커 종료: worker.terminate()

워커 인스턴스의 terminate() 메서드를 호출하여 워커 스레드를 즉시 종료할 수 있습니다.

이는 더 이상 워커가 필요하지 않을 때 리소스 누수를 방지하는 데 중요합니다.

웹 워커는 계산을 분리해 주지만, 메인 스레드와 데이터를 주고받는 비용도 함께 생깁니다.

앞의 Main thread와 Web Worker 책임 경계 다이어그램은 postMessage, 구조화 복제, Transferable 객체, 작업 종료 기준을 함께 보여줍니다.

서비스 워커 (Service Workers)

서비스 워커는 웹 워커의 한 종류로, 웹 페이지와 네트워크 사이에서 프록시(Proxy) 역할을 하는 자바스크립트 파일입니다.

웹 페이지와 독립된 백그라운드에서 실행되며, 주로 다음 기능을 제공합니다.

• 오프라인 경험: 네트워크 연결 없이도 웹 애플리케이션을 동작하게 합니다.
• 캐싱: 네트워크 요청을 가로채서 캐시에서 리소스를 반환하여 웹 페이지 로딩 속도를 향상시킵니다.
• 푸시 알림: 페이지가 열려 있지 않아도 권한·브라우저·운영체제 지원에 따라 푸시를 처리할 수 있습니다. 오프라인 전달은 연결 복구와 메시지 만료 조건에 영향을 받습니다.
• 백그라운드 동기화: 백그라운드에서 서버와 데이터를 동기화합니다.

서비스 워커는 Progressive Web Apps (PWA)의 핵심 기술이며, 웹 사이트를 모바일 앱처럼 동작하게 만드는 데 필수적입니다.

서비스 워커의 생명주기

서비스 워커는 메인 스크립트와는 다른 복잡한 생명주기를 가집니다.

서비스 워커의 fetch 이벤트에서는 method, origin, destination을 확인한 뒤 캐시와 네트워크 중 어느 경로를 사용할지 정책으로 결정합니다.

서비스 워커 사용법 (기초)

// sw.js
// 이 스크립트는 서비스 워커 스레드에서 실행됩니다.

const CACHE_NAME = 'my-pwa-cache-v1'; // 캐시 이름 정의
const urlsToCache = [ // 캐시할 파일 목록
    '/',
    '/index.html',
    '/styles.css',
    '/main.js',
    '/logo.png' // 예시 이미지
];

// install 이벤트: 서비스 워커 설치 시점에 발생
self.addEventListener('install', (event) => {
    console.log('[Service Worker] 설치 중...', event);
    // 캐싱 작업 수행 (비동기)
    event.waitUntil(
        caches.open(CACHE_NAME) // 캐시 저장소 열기
            .then((cache) => {
                console.log('[Service Worker] 모든 리소스를 캐시합니다.');
                return cache.addAll(urlsToCache); // 파일들을 캐시에 추가
            })
    );
});

// activate 이벤트: 서비스 워커 활성화 시점에 발생 (이전 워커 제거 등)
self.addEventListener('activate', (event) => {
    console.log('[Service Worker] 활성화 중...', event);
    event.waitUntil(
        // 이전 버전의 캐시를 삭제하여 업데이트 처리
        caches.keys().then((cacheNames) => {
            return Promise.all(
                cacheNames.map((cacheName) => {
                    if (cacheName !== CACHE_NAME) {
                        console.log('[Service Worker] 오래된 캐시 삭제:', cacheName);
                        return caches.delete(cacheName);
                    }
                })
            );
        })
    );
    // 서비스 워커가 페이지를 즉시 제어하도록 설정
    event.waitUntil(self.clients.claim());
});

// fetch 이벤트: 네트워크 요청을 가로챔 (가장 중요!)
self.addEventListener('fetch', (event) => {
    console.log('[Service Worker] Fetch 요청 가로챔:', event.request.url);
    event.respondWith(
        caches.match(event.request) // 요청이 캐시에 있는지 확인
            .then((response) => {
                // 캐시에 응답이 있으면 캐시된 응답 반환
                if (response) {
                    console.log('[Service Worker] 캐시에서 응답 반환:', event.request.url);
                    return response;
                }
                // 캐시에 없으면 네트워크 요청
                console.log('[Service Worker] 네트워크 요청:', event.request.url);
                return fetch(event.request);
            })
    );
});

// main.js (또는 HTML <script>)
if ('serviceWorker' in navigator) { // 브라우저가 서비스 워커를 지원하는지 확인
    window.addEventListener('load', () => {
        navigator.serviceWorker.register('/sw.js') // 서비스 워커 파일 경로 지정
            .then((registration) => {
                console.log('Service Worker 등록 성공:', registration.scope);
            })
            .catch((error) => {
                console.error('Service Worker 등록 실패:', error);
            });
    });
} else {
    console.warn('이 브라우저는 Service Worker를 지원하지 않습니다.');
}

이 예제는 나열한 캐시 파일이 모두 존재하는 전용 실습 출처를 전제로 합니다. 다른 앱과 출처를 공유한다면 캐시 삭제를 자신의 이름 접두사로 제한해야 합니다. 캐시되지 않은 요청은 오프라인에서 실패할 수 있습니다.

이 코드를 배포하면, 사용자가 처음 웹사이트에 접속할 때 서비스 워커가 설치되고, 이후에는 네트워크 요청을 서비스 워커가 가로채 캐시에서 응답을 제공하거나 네트워크 요청을 수행할 수 있습니다.

이를 통해 웹 페이지 로딩 속도를 비약적으로 향상시키고, 심지어 네트워크 연결이 없어도 일부 기능을 사용할 수 있는 오프라인 경험을 제공할 수 있습니다.

서비스 워커의 활용 분야

• 오프라인 웹 애플리케이션: PWA의 핵심으로, 네트워크 연결 유무에 상관없이 동작하는 앱 구현.
• 빠른 로딩: 캐싱 전략을 통해 반복 방문 시 페이지 로딩 속도 극대화.
• 푸시 알림: 사용자에게 서버에서 보낸 푸시 메시지 전달.
• 백그라운드 데이터 동기화: 네트워크가 재연결될 때 자동으로 서버와 데이터 동기화.
• 리소스 미리 가져오기(Pre-caching): 사용자가 방문할 가능성이 있는 페이지의 리소스를 미리 캐싱.

웹 워커와 서비스 워커는 이름이 비슷하지만 적용 기준이 다릅니다.

CPU 계산은 Web Worker, 네트워크 중간자·캐시는 Service Worker, DOM 상호작용은 main thread 책임으로 분리합니다.

워커 기반 성능 개선 정리

핵심은 메인 스레드 반응성을 유지하면서 백그라운드 작업을 어떤 기준으로 분리할지 판단하는 것입니다.

이번 절에서는 웹 애플리케이션의 성능과 사용자 경험을 개선하는 두 가지 백그라운드 스크립트 기술인 웹 워커(Web Workers)와 서비스 워커(Service Workers)를 살펴봤습니다.

웹 워커는 복잡한 연산을 메인 스레드 밖에서 처리해 UI 반응성을 유지하도록 돕습니다.

postMessage() 기반 통신과 DOM 접근 불가라는 제약을 함께 기억해야 합니다.

이어서, 서비스 워커가 웹 워커의 개념을 확장하여 웹 페이지와 네트워크 사이에서 프록시 역할을 하며, 오프라인 지원, 캐싱, 푸시 알림 등 PWA의 핵심 기능을 구현하는 데 필수적임을 배웠습니다.

서비스 워커의 생명주기(등록, 설치, 활성화, 제어)와 install, activate, fetch 이벤트를 통한 캐싱 및 네트워크 요청 가로채기 방식의 기초를 알아보았습니다.

웹 워커와 서비스 워커는 PWA와 고성능 웹 애플리케이션에서 자주 쓰입니다.

서비스 워커는 실제 배포 환경에서 HTTPS를 요구하고 디버깅이 복잡할 수 있으므로, Chrome 개발자 도구의 Application 탭에서 상태와 캐시를 확인해야 합니다.

이로써 9장 웹 API와 브라우저 기능의 주요 내용을 마무리합니다.

최신 자바스크립트 기능과 브라우저 API를 함께 이해하면, UI 반응성, 저장, 통신, 백그라운드 처리까지 한 흐름으로 점검할 수 있습니다.

웹 워커와 서비스 워커는 모두 메인 스레드 밖에서 동작하지만, 해결하는 문제가 계산 분리와 네트워크 중간자라는 점에서 다릅니다.

이 절에서는 웹 워커와 서비스 워커의 역할, 사용법, 적용 전 확인할 제약을 정리했습니다.

웹 워커와 서비스 워커를 작업 위치, 생명주기, 캐시 책임 기준으로 정리합니다. 따라하기: 작은 입력으로 Worker 결과부터 확인하기

원래 main.js의 계산을 시작하기 전에 index.html에 <button id="startButton">계산 시작</button><p id="status">대기</p><p id="result"></p><script src="main.js"></script>를 준비합니다. worker.js와 main.js는 주석의 파일 이름대로 나누어 같은 학습 사이트에서 제공합니다. 처음에는 원래 큰 입력을 그대로 기다리기보다 별도 사본에서 numberToCalculate를 10으로 바꾸어 결과 개수 4를 확인하세요. 파일을 직접 여는 file URL 대신 Worker를 제공할 수 있는 학습용 HTTP 환경을 사용합니다.

2부터 10까지 나누어 떨어지는 작은 약수가 없는 수는 2, 3, 5, 7입니다. Worker는 숫자 10을 메시지로 받아 계산한 뒤 [2, 3, 5, 7]이라는 배열을 보냅니다. 메인 스크립트는 배열의 length로 개수를 표시하고 Worker를 종료합니다. Worker에서 document를 사용하는 방식으로 UI 갱신을 옮기는 것은 이 실행 환경의 경계에 맞지 않습니다. 처음에는 버튼을 한 번만 눌러 이 순서를 확인하세요. 원래 버튼은 비활성화되지 않으며, 다시 누르면 이전 Worker를 terminate한 다음 새 Worker를 만듭니다.

독립 연습

같은 소수 알고리즘에서 입력을 30으로 바꾸었습니다. 반환할 배열과 메인 쪽 표시 개수·처리 순서를 적으세요. 또 입력 데이터를 ArrayBuffer의 transfer list로 넘겼다면, 보내고 난 뒤 원래 메인 쪽 buffer를 이전처럼 읽어도 되는지 판단하세요. 이 두 질문은 별도 실험입니다.

따라하기: Service Worker의 설치와 현재 페이지 제어를 구별하기

Service Worker 실습은 다른 앱의 캐시가 없는 전용 학습 사이트에서 시작합니다. 원래 sw.js의 캐시 목록에 든 /, /index.html, /styles.css, /main.js, /logo.png가 모두 성공 응답을 반환하는지 등록 전에 확인합니다. 없는 파일 하나를 넣으면 addAll이 실패해 설치가 끝나지 않을 수 있습니다. HTTPS의 secure context에서 실습하며, 로컬 개발에서는 loopback origin을 신뢰 가능한 출처로 다루는 경우가 있습니다. Secure Contexts의 출처 조건을 참고하고 window.isSecureContext와 navigator.serviceWorker 제공 여부도 확인합니다.

등록의 Promise가 끝났다는 사실만으로 지금 화면이 제어되고 있다고 결론 내리지 않습니다. 아래 코드를 등록하는 페이지에서 사용하면 제어 관계가 바뀌는 순간을 관찰할 수 있습니다. 별도 사이트용 배포 코드를 변경하는 실습은 아닙니다.

function showController() {
    console.log('현재 controller:', navigator.serviceWorker.controller?.scriptURL ?? null);
}
if ('serviceWorker' in navigator) {
    showController();
    navigator.serviceWorker.addEventListener('controllerchange', showController);
}

원래 activate handler는 clients.claim도 요청하지만, 등록 완료·활성화 완료·controllerchange는 서로 다른 관찰 시점입니다. 활성 상태와 controller를 확인한 뒤 네트워크를 끊고 미리 캐시한 index.html을 다시 요청해 보세요. 원래 fetch handler는 cache-first이므로 캐시한 문서는 반환할 수 있지만, 캐시에 없는 요청이 오프라인에서도 성공한다고 가정하지 않습니다. Service Worker의 상태와 client 제어 규칙에 해당합니다.

독립 연습

이미 버전 A가 페이지를 제어하고 있고, 새 버전 B의 precache는 성공했습니다. 기존 제어 페이지는 열려 있으며 B는 skipWaiting을 호출하지 않았습니다. B의 installed 상태와 registration.waiting을 관찰했다면, 현재 페이지의 controller가 즉시 B로 바뀌었다고 말할 수 있을까요? 별도 실험에서 B의 precache에 없는 파일이 하나 들어가 install의 waitUntil이 거부되었다면, B를 정상 waiting 버전으로 취급해도 될까요?