Worker API in Next.js — 시리즈 안내

브라우저에서 실행되는 JavaScript가 많아질수록 이상한 순간이 찾아온다. 비동기 처리를 했는데도 화면은 멈추고, 탭을 몇 개 열었을 뿐인데 서버에는 같은 소켓 연결이 여러 개 생기고, Next.js에서는 코드가 서버에서 평가될지 브라우저에서 평가될지 계속 의식해야 한다. Worker API는 이 문제를 한 번에 없애는 마법은 아니지만, 실행 위치와 브라우저 컨텍스트를 다시 설계하게 만드는 꽤 현실적인 도구다.

Worker API는 느린 코드를 숨기는 기술이 아니라, 어떤 작업을 어느 실행 컨텍스트에 둘지 결정하게 만드는 경계 설계 도구다.

시리즈 구성

1. 1. 왜 Next.js에서 Worker가 필요한가
   async 함수와 Worker의 차이를 event loop, 메인 스레드, structured clone, transferable object 관점에서 정리한다.

2. 2. Dedicated Worker를 Next.js에서 안전하게 쓰기
   new Worker(new URL(..., import.meta.url)), workerFactory, useEffect, cleanup, 이미지 처리 예제를 하나의 훅 설계 문제로 다룬다.

3. 3. SharedWorker로 멀티탭 소켓을 하나로 묶기
   여러 탭이 하나의 Socket.IO 연결을 공유하도록 SharedWorker, MessagePort, 브로드캐스트, fallback 전략을 정리한다.

추천 읽기 순서

처음 Worker API를 프로젝트에 넣으려는 상황이라면 1번부터 순서대로 읽는 편이 좋다. 첫 글에서 Worker가 필요한 조건을 먼저 잡아두면, 두 번째 글의 Dedicated Worker 패턴이 단순한 코드 분리가 아니라 생명주기 설계로 보인다. 이미 이미지 처리나 대용량 계산을 Worker로 옮겨본 경험이 있다면 2번부터 읽고, 멀티탭 소켓 연결 문제를 겪고 있다면 3번으로 바로 넘어가도 된다.

남는 질문

Worker API를 쓰기 시작하면 성능 이야기는 곧 구조 이야기가 된다. 작업을 메인 스레드 밖으로 옮기는 순간 메시지 비용, 브라우저 지원, 번들러 entrypoint, 배포 origin, cleanup까지 같이 따라온다. 이 시리즈의 목표는 Worker를 써야 한다고 주장하는 것이 아니라, Worker를 선택해야 하는 순간과 선택하지 말아야 하는 순간을 구분하는 기준을 남기는 데 있다.