불편한 WebWorker 통신

JS는 기본적으로 병렬처리를 염두에 두고 설계되지 않아 병목현상으로 인한 지연을 최소화하기 위해 효율적인 코드를 짜는 것이 매우 중요하다. 그래서 이러한 문제를 타파하기 위해 고안된 WebWorker는 일종의 멀티스레딩을 제공한다. 하지만 실제로 사용되는 곳은 매우 적은데 그 이유는 무엇일까?
 
첫번째로, 병렬 처리가 필요한 경우는 매우 드물다. switch문이 if문보다 속도가 빠르고, 전위연산자가 후위연산자보다 속도가 빠르지만 현대 기기의 환경에서 유의미한 성능 향상이 없는 것처럼, 대다수의 경우 웹 환경에서 수행하는 간단한 작업들에는 멀티스레딩이 필요가 없다. 특히, 무거운 연산이 필요하다면 WASM이라는 훌륭한 대체제가 이미 존재한다. 더욱이 병렬 처리는 동시성 문제가 발생할 수 있으며 각 WebWorker 간에 비동기 통신을 하는 과정에서 추가적인 시간이 소요되기에 항상 속도가 빠르지만도 않다.
 
두번째로, 통신 구현은 꽤나 귀찮다. 예를 들어 무거운 작업 A를 WebWorker에서 수행하도록 작업 A를 수행하는 함수/메서드를 전달하고 싶어도, 실제로는 많은 제약이 따른다. 각 WebWorker는 격리된 공간을 갖기 때문에, 외부 의존성부터 환경 변수까지 일일이 전달해줘야 하기 때문이다. 더불어 통신 시에는 JS의 일급객체라는 특징이 무색하게 일부 직렬화 가능한 양식의 정보만 전달 가능하다. 의존성을 사용하지 않는 순수 함수의 경우에 한해 함수를 문자열로 변환하여 전달하면 함수 전달 및 실행이 가능은 하지만...
 
특히 SharedWorker를 사용할 경우 자주 사용되는 기능(reply, broadcast)들을 기본적으로 제공하지 않는데, 이러한 경우를 위해 유용한 기능을 미리 포함하는 SharedWorker를 생성해주는 함수/메서드를 만드는 것 또한 다소 난해하다. 서술한 바와 같이 각 WebWorker는 격리된 공간을 갖기 때문이다. 따라서 boilerplate 코드가 반강제 된다.

즉 특정 작업의 평균 수행시간이 일정 시간을 초과하는 경우에는 병렬 처리가 효율적이지만, 해당 '일정 시간'에 관한 명백한 기준의 부재와 WebWorker를 사용하는 추가 코드에 의한 초기 로드시간 증가, 간이 통신규약으로 인한 코드 복잡성 증가 등을 종합적으로 고려했을 때 보편적으로 WebWorker는 크게 와닿는 매력이 없다.