본문 바로가기
C.W.K.
Stream
More →
Lesson 03 of 06 · published

Event-driven vs Persistent — Idle Worker

~11 min · service-worker, lifecycle, eviction, events, state-loss

Level 0Extension 입덕
0 XP0/56 lessons0/13 achievements
0/100 XP to next level100 XP to go0% complete
"MV3 service worker는 user 관점에서 두 상태밖에 없어: '지금 뭔가 하는 중' 과 'idle, evict 됐을 수도'. 그 on/off 형태 위에 설계하는 게 Track 2의 전체 mental model."

Idle clock은 즉시 시작

worker가 붙잡고 있던 마지막 event를 끝내는 순간 Chrome이 시계를 켜. 그러고 30 초쯤 아무 일도 없으면 — event도 안 오고, 기다리는 async도 없고, 굴러가는 Promise도 없으면 — worker를 내보내. 메모리가 풀리고, 전역이 사라지고, 최상위에 만들어 뒀던 Map 이든 Set 이든 같이 증발해.

Clock은 memory pressure 또는 Chrome 내부 휴리스틱이 worker가 안 쓸모 있다고 판단하면 더 빨리 만료. 30 초는 soft maximum으로 다뤄, 보장 아냐.

Worker를 깨우는 것

Worker가 listener 등록한 어떤 event 든. 큰 것들:

  • chrome.runtime.onMessage — popup, content script, 또는 다른 extension이 message 보냄
  • chrome.alarms.onAlarm — 예약된 alarm fire (setTimeout/setInterval의 MV3 대체)
  • chrome.tabs.* event — tab created / updated / removed / activated / replaced
  • chrome.runtime.onInstalled / onStartup — extension install 또는 Chrome launch
  • chrome.runtime.onConnect — popup 또는 content script에서 long-lived port 열림
  • chrome.webNavigation.* — page navigation event (webNavigation permission 필요)
  • chrome.contextMenus.onClicked — user가 등록된 context menu entry 활성화
  • chrome.action.onClicked — default_popup 없는 상태에서 toolbar icon 클릭

이 중 어느 게 fire 하면 Chrome이 worker를 cold로 깨워: background.js 위 부분 다시 실행, listener 재등록 (이게 중요 — 등록이 Chrome 한테 dispatch 하라는 신호), 그 다음 Chrome이 event 전달.

Eviction 때 죽는 것

Worker evict 때 잃는 거:

  • Module-level 변수 (let counter = 0, const cache = new Map() 등)
  • Chrome의 event 제한보다 오래 걸리는 in-flight work. Extension API 호출은 idle timer를 다시 잡지만, 해결 안 된 Promise 자체는 durable storage가 아니고 긴 request에는 별도 시간 제한도 있어.
  • WebSocket 연결, EventSource 연결, MediaStream handle, BroadcastChannel port
  • Listener 안에서 이전 wake에 set 된 closure-captured state

살아남는 거:

  • chrome.storage.local — eviction 전에 write 됐으면 다음 wake에 read 가능
  • chrome.storage.session — 2023 추가. worker eviction 견디지만 browser session 끝나면 죽음
  • chrome.alarms — 등록된 alarm은 worker 재시작 너머로 영속
  • 등록된 listener 자체 (Chrome이 기억. background.js 위 부분 재실행이 재attach 메커니즘)

Cold-wake 패턴

Cold wake = worker가 매번 1 행에서부터 실행. background.js를 매 event 마다 도는 main() 함수처럼 다뤄:

  1. 해당 handler 위에서 필요한 state를 chrome.storage에서 read.
  2. 일 하기.
  3. 새 state를 chrome.storage로 write back.
  4. Handler return (또는 Promise resolve).
  5. Worker idle 됨. 결국 evict. 다음 event 대기.

가장 깔끔한 mental model: 모든 event handler가 전체 프로그램. Read / work / write / return.

피할 anti-pattern

MV2 에선 멀쩡해 보이지만 MV3 에선 능동적으로 깨지는 패턴:

  • 주기적으로 뭘 돌리려고 setInterval(fn, 60000)을 걸면, timer가 울리기도 전에 worker가 쫓겨날 수 있어. chrome.alarms.create({periodInMinutes: 1})을 써. alarm은 퇴출을 넘어 살아남고, 때가 되면 worker를 다시 깨워 주거든.
  • Module-level cache (const userCache = new Map()). 매 wake 마다 reset. Value에 명시적 expiry timestamp 박아서 chrome.storage.local 사용.
  • 조용한 WebSocket은 lifetime 보증이 아니야. Chrome 116부터 WebSocket traffic이 service worker 수명을 연장할 수 있지만 traffic이 끊기면 worker는 여전히 종료될 수 있어. 연결과 state를 복원 가능하게 설계해.
  • Event 사이 "session state" 로 global 쓰기. Module-level 변수는 항상 ephemeral로 다뤄. 잠깐 살아남는 것처럼 보여도 의존하지 마.
Worker는 프로세스가 아니라 함수. 각 event handler가 하나의 완전한 호출. State는 scope가 아니라 storage에 살아.
MV2 튜토리얼이 "background.js의 global에 state 박아둬" 라고 말하면 MV3 한테는 능동적으로 틀린 거. Worker는 evict 되고 그 state는 사라져 — 보통 최악의 타이밍에, user가 작업 중간이고 버그 재현 불가능할 때. State 얘기에 chrome.storage 언급 없는 옛 답변은 의심해.

Code

Anti-pattern — in-memory counter가 매 worker wake 마다 reset·javascript
// ❌ ANTI-PATTERN — module-level state dies on eviction
let messageCount = 0;

chrome.runtime.onMessage.addListener((message, sender, sendResponse) => {
  messageCount++;
  console.log("[ClipDeck SW] message count:", messageCount);
  sendResponse({ count: messageCount });
  return false;
});
// First few clicks: 1, 2, 3, 4...
// After ~30 seconds idle and a fresh event: 1.
// The variable is gone.
올바른 패턴 — event 마다 chrome.storage.local round-trip·javascript
// ✅ CORRECT — state lives in chrome.storage, survives eviction
chrome.runtime.onMessage.addListener(async (message, sender, sendResponse) => {
  const { messageCount = 0 } = await chrome.storage.local.get("messageCount");
  const newCount = messageCount + 1;
  await chrome.storage.local.set({ messageCount: newCount });
  console.log("[ClipDeck SW] message count:", newCount);
  sendResponse({ count: newCount });
  return true; // async sendResponse — keep channel open
});
// Across evictions: 1, 2, 3, 4, ... persistent.

External links

Exercise

Anti-pattern 코드 (module-level messageCount + onMessage listener)를 background.js에 임시로 추가. popup.js에 chrome.runtime.sendMessage({type: 'ping'}).then((r) => console.log('SW replied:', r)) 한 줄 추가 — popup 열 때마다 message 하나 보냄. Reload. ClipDeck popup을 연속 여러 번 열어 — counter 증가 (1, 2, 3...). 이제 chrome://serviceworker-internals 가서 ClipDeck 찾아 'Stop' 클릭 (강제 eviction). 몇 초 대기. 다시 popup 열기. 새 count는? Reset 확인 후 listener를 두 번째 code block의 chrome.storage.local 패턴으로 바꾸고 실험 반복 — 이제 강제 eviction 너머로도 count 영속.
Hint
chrome://serviceworker-internals의 강제 'Stop' 이 eviction 데모하는 가장 빠른 길. 자연 ~30 초 idle도 되지만 더 오래 걸려. Popup이 SW reply 기다리며 hang 하면 보통 listener가 sendResponse 호출 없이 return 한 거 — anti-pattern listener는 sendResponse 동기적으로 호출 후 false 반환, 올바른 패턴은 storage await 전에 true 반환 확인.

Progress

Progress is local-only — sign in to sync across devices.
← PreviousService Worker 등록하기Next →chrome.storage — Eviction 견디는 state layer
이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고

댓글 0

🔔 답글 알림 (로그인 필요)
로그인 — 댓글을 남기려면 로그인해 주세요.

아직 댓글이 없어요. 첫 댓글을 남겨보세요.