[WEB_DEV] Web worker

로선생·2025년 8월 19일

한 주간 업무고민

과도한 스마트폰의 사용으로 인하여,
어느 번에는 긴 글이 안 읽히는 경험을 하였다!! 긴 글을 보니 자동으로 '그래서 요점이 뭐지?' '무슨 말이지?' '아 읽기 싫어' >> 실제로 읽히지도 않았다

만점왕,, 은 아니였지만 나름 국어로 이름 좀 날렸던 학창시절을 보냈는데,,
학과도 토하기 전까지 글을 읽었던 철학과였는데,,
교수님이 통탄하실 노릇이다.

너무 충격을 받아서 밤에 핸드폰을 안 해야겠다 했는데,,
핸드폰을 안 하니,,
너무 하고 싶은거예요!!!

그 때 아 나는 스마트폰에 중독된 것이 맞다. 이건 진짜 심각한 이슈라는 것을 깨닫고 몇 가지 원칙을 만들어보았습니다.

  1. 밤에 자기 전에 핸드폰 하지 말기
    -> 그래도 바로 누우면 심심해서.. 이 때 그냥 책을 읽습니다.
  2. 지하철 통근길에 핸드폰 하지 말기
    -> 그냥 자거나 기술도서 읽습니당..
  3. 밥 먹을때 그냥 밥 먹기

이제 한 일주일 되었는데, 너무 놀랐던 것은,, 침대에 자려고 눕고 책을 읽고 있는데 풀벌레 소리가 밖에서 찌르찌르 들리는 거예요....
진짜 여름 된 지 한참 되었는데 처음 듣는 느낌
에어컨이 방에는 없어서 그냥 문 열어 놓고 여름을 지냈는데도!!!! !!!!
항상 미디어 자극에 노출되어 있어서 몰랐던 것임..

진짜 딱 저 느낌으로 충격받았습니다..

그래도 긍정적인 소식 : 도파민으로 절여진 전두엽 피질도 4주면 돌아온다고 하네요 ^^,,, 종종 소식 업데이트 하도록 해보겠습니다..

(이건 계속 워라밸 고민하고 있어서 인용하려고 가져왔는데, 너무 내용 길어질 것 같아서 이건 다음 시간에... )

생산적 활동 진행한 내용

보여드리고 싶었는데,,, 팀장님 자리 비우신 사이에 급하게 퇴근하느라 회사 컴퓨터를 두고 왔다..... 이 럴 수 가....

저의 생산적 활동

  • 사내에서 사용할 피그마 플러그인 만들기

한 주간 진행한 내용

  • Figma plugin PoC를 진행한 내역을 회사 디자인 시스템에 적용하였다.

  • 제가 만든 PoC는 Restful api이고, 실제 회사에서 도입한 것은 피그마의 plugin API를 사용하였음

  • 정규화된 컴포넌트들이 package로 올라가 있는데 그 커스텀 컴포넌트별로 매핑하는 작업을 진행한 한 주!

  • 재귀함수를 돌려서 각 피그마 node의 타입을 분기하고, 각각의 props를 뽑아서 재생성하는 작업 -> 말로 하니까 너무 어려운데 이건 꼭 다음주에 코드를 보여드리도록 하겠습니다.

  • 이슈!!

"개발에서 정의하신 건 모르지만, 저희는 이렇게 해요~"

라고 답변을 받았다.. ...

디자인 영역에서 생각한 컴포넌트와 개발에서 생각한 컴포넌트 사이의 간극
^ ㅡㅡㅡㅡㅡㅡㅡ ^ ,,,

이 사이의 간극의 차이로 인하여 엄청나게 많은 예외사항이 발생하였다..

Web worker

자바스크립트는 기본적으로 메인 스레드에서 작업을 실행하는 단일 스레드 언어라고 설명되는데, 여기에는 스크립팅, 일부 렌더링 작업, HTML/CSS 파싱, 사용자 경험을 좌우하는 기타 사용자 지향 작업 등이 포함된다.
(실제로 브라우저는 GPU 스레드처럼 개발자가 직접 접근하지 않는 다른 스레드를 사용하기도 한다)

각 브라우저 탭마다 렌더링과 자바스크립트 실행을 처리하는 스레드가 하나라는 의미.

그 결과 메인 스레드는 엄청나게 과부하 상태 -> 웹 앱이 복잡해질수록 메인 스레드는 성능의 주요 병목 지점이 됨

-> 더 나쁜 점은, 메인 스레드에서 코드를 실행하는 데 걸리는 시간은 기기의 성능에 크게 좌우되기 때문에 사용자마다 거의 예측할 수 없다

web workers

JavaScript는 기본적으로 메인 스레드에서 작업을 수행하지만, 추가 스레드를 등록해 사용할 수도 있다. JavaScript에서 멀티 스레딩을 가능하게 하는 기능을 웹 워커 API(Web Workers API)라고 한다.

웹 워커는 개발자가 별도의 스레드를 생성하여 메인 스레드 밖에서 작업을 처리할 수 있게 해준다.
웹 워커의 범위는 제한적이고 DOM에 직접 접근할 수는 없지만, 메인 스레드를 압도할 수 있는 상당한 작업이 필요할 때는 매우 유용할 수 있다.

  • 페이지의 Interaction to Next Paint(INP) 반응성 지표를 개선
  • Largest Contentful Paint(LCP) 개선

웹 워커는 2007년부터 존재했고 2012년부터 주요 브라우저에서 지원되었음.

다른 플랫폼과는 다르게, 웹 워커는 메인 스레드와 병렬로 실행되지만, 변수를 공유할 수는 없다.

Threading with web workers

[워커 등록 방법]

const worker = new Worker('./worker.js');

웹 워커는 Worker 클래스를 인스턴스화하여 등록한다. 이때 브라우저가 로드할 웹 워커 코드의 위치를 지정하며, 브라우저는 해당 코드를 로드하고 새로운 스레드를 생성한다. 이렇게 생성된 스레드를 보통 워커 스레드라고 한다.

[웹 워커가 window와 통신하는 방법]
웹 워커는 메시징 파이프라인을 통해 메인 스레드의 window 컨텍스트와 통신할 수 있다. 이 파이프라인을 사용하면 메인 스레드와 웹 워커 사이에 데이터를 주고받을 수 있다.

웹 워커에서 메인 스레드로 데이터를 보내려면, 웹 워커 컨텍스트에서 message 이벤트를 설정한다.

(메시지 값을 postMessage 호출 시 매개변수로 전달하고, 워커에 message 이벤트 리스너를 추가하는 방식)

worker.js

addEventListener('message', event => {
  const [a, b] = event.data;

  // Do stuff with the message
  postMessage(a + b);
});

그런 다음 메인 스레드의 window 컨텍스트에서 또 다른 message 이벤트를 이용해 웹 워커 스레드로부터 메시지를 수신할 수 있다:

main.js

const worker = new Worker('./worker.js');

worker.postMessage([40, 2]);
worker.addEventListener('message', event => {
  console.log(event.data);
});

메시지를 메인 스레드로 다시 보내려면, 웹 워커에서 동일한 postMessage API를 사용하고 메인 스레드에서 이벤트 리스너를 설정

다만, 이 접근 방식은 다소 제한적이다.

웹 워커의 제약사항

웹 워커는 window 컨텍스트에 직접 접근할 수 없으며 해당 컨텍스트가 제공하는 API 접근도 제한된다. 웹 워커에는 다음과 같은 제약이 있다:

- 웹 워커는 DOM에 직접 접근할 수 없습니다.
- 웹 워커는 메시징 파이프라인을 통해 window 컨텍스트와 통신할 수 있으므로, 간접적으로 DOM에 접근하는 효과를 낼 수 있습니다.
- 웹 워커의 전역 스코프는 window가 아니라 self입니다.
- 웹 워커 스코프에서는 JavaScript의 기본 타입과 구조체, fetch를 포함한 상당수의 웹 API에 접근할 수 있습니다.

역사적으로 웹 워커는 주로 무거운 작업 하나를 메인 스레드에서 분리하는 데 사용되었으나, 메시지에 매개변수뿐 아니라 작업 종류까지 인코딩해야 하고, 응답을 요청과 맞추기 위한 관리 작업도 필요하기 때문에 단일 웹 워커로 여러 작업을 처리하려고 하면 금세 복잡해진다.

이 일을 해주는 라이브러리가 있다!

worker.js

import {expose} from 'comlink';

const api = {
  someMethod() {
    // ...
  }
}

expose(api);

main.js

import {wrap} from 'comlink';

const worker = new Worker('./worker.js');
const api = wrap(worker);

어떤 코드를 웹 워커로 써야 하나?

웹 워커는 계산량이 많은 작업을 메인 스레드에서 실행하면 긴 작업이 발생해 페이지가 반응하지 않게 되는 경우에 유용

  • DOM 접근이 전혀 필요 없는 코드
    : 워커는 DOM에 접근 불가
  • WebUSB / WebRTC / Web Audio 등 워커에서 접근 불가한 API에 의존하지 않는 코드
  • 메인 스레드에서 꼭 할 일(UI 갱신 등)과 그 외의 일을 분리했을 때,
    그 “기타 로직”을 워커로 이동
  • 상태 관리·비즈니스 로직처럼 순수 계산 위주 작업
  • PROXX 사례: 메인 스레드는 애니메이션/전환 렌더링, 워커는 게임 로직(순수 계산) 처리
  • 앱 시작 시 긴 작업을 줄여 LCP/INP에 도움이 되는 작업
  • 파싱·계산 등을 워커로 보내면 메인 스레드가 UI 반응성을 더 잘 유지

웹 워커 사용 사례

이미지의 Exif 메타데이터를 제거하거나 확인해야 하는 웹사이트를 생각해보자.

JPEG 테스트 이미지

웹 워커 없이 본 메인 스레드의 모습


이미지 메타데이터 추출 앱의 메인 스레드 활동. 모든 작업이 메인 스레드에서 발생

[메인 스레드 작업]

  1. 폼이 입력을 받아 Exif 메타데이터가 포함된 이미지의 초반부를 가져오기 위한 fetch 요청을 전송합니다.
  2. 이미지 데이터가 ArrayBuffer로 변환됩니다.
  3. exif-reader 스크립트로 이미지에서 Exif 메타데이터를 추출합니다.
  4. 메타데이터를 스크랩하여 HTML 문자열을 구성하고, 메타데이터 뷰어에 채웁니다.

c.f. ArrayBuffer

버퍼Buffer란
: 일정 구획만큼의 데이터를 쪼개서 전달되는 stream을 저장한 후 일정 크기가 도달하면 출력장치나 동영상 플레이어로 전달해주는 중개자 역할을 하는 객체. 한 마디로, 스트림 데이터를 조금씩 저장하고, 처리하고, 비우기를 반복하는 메모리 공간이다.
이런 행위를 버퍼링이라고 하며, 메모리 공간 자체 혹은 메모리에 저장된 데이터를 버퍼라고 부른다.

따라서 자바스크립트 용도가 다양해지면서 이처럼 오디오나 비디오와 같은 binary data들 역시 다룰 필요성이 생기게 되었다.
(자바스크립트는 기본적으로 객체 중심 언어라서, 숫자·문자열 같은 값도 객체처럼 동작하는데, 그 구조는 이진 데이터 처리에 비효율적이기 때문)
필요한 메모리 공간을 적절하게 할당해서 사용할 수 있는 유연성이 필요해 ArrayBuffer를 만들게 되었다.

ArrayBuffer는 고정된 길이의 메모리 조각이다. 자바스크립트에서 원시 데이터(바이너리 데이터)를 직접 다루는 수단으로 사용되며, 이는 메모리를 개발자가 수동으로 관리할 수 있게 해준다. 

// 16바이트 버퍼 생성
const buffer = new ArrayBuffer(16);

// 32비트 정수 뷰 만들기
const int32View = new Int32Array(buffer);

// 값 넣기
int32View[0] = 42;
int32View[1] = 100;

// 값 읽기
console.log(int32View[0]); // 42

웹 워커가 있을 때 메인 스레드의 모습

메인 스레드에서 모든 것을 처리하는 대신, HTML로 메타데이터 뷰어를 채우는 일을 제외한 모든 작업을 별도 스레드에서 수행한다.(exif-reader 스크립트의 다운로드, 파싱, 컴파일 비용이 메인 스레드 밖에서 발생)
그 결과 메인 스레드는 다른 작업을 처리할 여유가 생긴다.

웹 워커 코드 살펴보기

// 메인 스레드(scripts.js)

// exif-worker.js

profile
로선생
이제는 이것저것 먹어요
이전 포스트

[WEB_DEV] Lazy load images and <iframe> elements

다음 포스트

때아닌 진로고민 어쩌구

0개의 댓글