Worker 쓰레드는 대체 언제 쓸까 #
굳이 필요하지 않으므로 쓰지 않는 게 기본 #
자바스크립트는 메인 쓰레드를 기본으로 사용합니다. 그리고 별도의 쓰레드를 생성하지 않는 한, 메인 쓰레드만을 사용하는 것처럼 보입니다. 파일 시스템 작업과 같은 블로킹 I/O, DNS look up 등의 작업이 아닌 경우 libuv에서 제공하는 쓰레드 풀은 사용하지 않습니다. JS의 주된 사용처인 HTTP 통신은 OS 커널 단의 I/O를 사용하기 때문에 정확히는 쓰레드의 사용이라 보기 어렵습니다.
필요하다면 언제 필요한 것인가 #
대표적인 예로 CPU 집약적인 작업에 Worker 쓰레드의 필요성이 부각됩니다. 예를 들어:
- 매우 큰 수 만큼 피보나치 수열을 구하거나,
- 매우 큰 숫자가 소수인지 확인하거나,
- 매우 큰 배열을 정렬하거나,
- 그래픽 작업 등을 수행할 때 필요할 수 있습니다.
이런 작업들은 사실상 JS의 메인 무대와는 거리가 있는 편입니다.
사용한다면 #
실제 현업에서 Worker 쓰레드를 사용한다면 어떤 경우에 사용해야 좋을까요? 필자가 생각하는 괜찮을 것 같은 경우를 꼽아봤습니다. (아래의 모든 내용은 필자의 아이디어를 적어둔 것일 뿐이므로 아직 검증되지 않았습니다.)
쓰레드를 사용해봤으면 하는 목록 #
- 화면단에서 가능한 최적화를 했으나, 그럼에도 불구하고 렌더링하는 데 버벅거리는 경우
- 특정 연산이 렌더링에 영향을 미치는 경우
- 특정 연산이 렌더링에 영향을 미치지 않는 경우
목록에 대한 설명과 장점 #
-
화면단에서 가능한 최적화를 했으나, 그럼에도 불구하고...(생략)
- 가능한 최적화가 되었으나 렌더링에 부하가 생기는 경우입니다. 웹 앱을 기준으로 화면 변경에 영향을 주는 상태에 의해 화면이 변경되니 상태를 다시 기준으로 잡겠습니다.
이때, 두 가지 분기로 나뉩니다.
- 상태의 변경이 포함되는 연산을 쓰레드에 넘긴다.
- 상태의 변경을 제외한 연산을 쓰레드에 넘긴다.
상태의 변경이 포함되는 경우 #
상태의 변경이 쓰레드의 postMessage에 의해 결정되어 메인 쓰레드는 해당 UI의 변경이 워커 쓰레드에 의해 결정됩니다. 따라서 메인 쓰레드는 메시지를 받기 전까지 UI의 업데이트가 없습니다. 대신 메시지가 오기 전까지 UI는 보다 부드러워집니다. (다른 UI 변경에 메인 쓰레드가 사용되고, 이후 메시지에 의해 UI가 변경되어 디바운스 처리되는 느낌)
상태의 변경이 포함되지 않는 경우 #
이는 메인 쓰레드가 굳이 처리하지 않아도 되는 일반 연산을 워커 쓰레드에게 위임한다는 장점이 있습니다. 워커 쓰레드를 일반 연산에 사용하므로 메인 쓰레드는 보다 UI 렌더링 연산에 사용될 확률이 높아집니다. 일반 연산을 워커 쓰레드에게 위임하고 그 결과를 토대로 렌더링을 한다고 해도 메인 쓰레드가 일반 연산을 하지 않는 것은 좋은 현상입니다.
단점 #
단점은 명확합니다.
- 워커 쓰레드 생성에 오버헤드가 존재합니다.
- 메인 쓰레드보다 느립니다.
- 개발 난이도가 상승합니다. (유지보수, 코드의 이해도, 구현의 복잡함, 재사용성, 보다 많은 성능 요구)
단점은 설명할 것이 따로 없을 정도로 단순한 내용입니다.
마치며 #
위 링크의 매우 작은 토이 프로젝트를 진행하며 느낀 점을 작성해봤습니다. 쓰레드에 관심이 많아 해당 내용과 연계된 작은 프로젝트를 더 많이 만들고 포스트를 더 작성해볼 생각입니다. 감사합니다.