Summary

  • W3C는 2009년 4월 23일 첫 Web Workers 작업 초안을 공개했다. 페이지는 분리된 병렬 실행 환경에서 스크립트를 시작하고 메시지로 소통할 수 있었다.
  • 초안의 소수 계산 예시에서는 worker가 숫자를 찾아 차례로 보내고 페이지가 그 결과를 표시한다. 화면은 그동안 클릭과 다른 동작을 계속 맡는다.

버튼은 분명 화면에 있다. 눌러도 대답이 없다. 한 번 더 누르면 나중에 두 번 처리될지 모른다는 걱정만 늘어난다. 한참 뒤 페이지가 갑자기 움직인다. 계산은 열심히 했을지 몰라도 이용자에게는 접수 창구 직원이 창문을 닫고 창고에서 장부를 세는 모습이다. 줄을 선 사람은 일이 진행 중인지조차 알기 어렵다.

W3C가 2009년 4월 23일 공개한 첫 Web Workers 작업 초안은 창구와 창고를 나눴다. 클릭과 다른 상호작용을 처리하는 스크립트와 독립적으로 백그라운드 스크립트를 실행하는 API를 설명했다. 예시로 소수를 찾는다. 주 문서가 worker를 시작하고, worker가 새 소수를 찾아 보낸다. 페이지는 도착한 숫자를 표시한다. 뒤에서는 계산을 계속하고 앞에서는 이용자 말을 듣는다.

경로는 구체적이다. 페이지가 스크립트 URL로 Worker를 만든다. 브라우저는 그 스크립트를 별도의 병렬 실행 환경에서 돌린다. 양쪽은 postMessage와 메시지 처리기로 데이터를 주고받는다. worker는 숫자를 찾고 페이지는 화면을 책임진다. 새 소수를 찾았다고 해서 계산 쪽이 직접 화면의 글자를 바꾸는 방식이 아니다. 결과가 메시지로 돌아온 뒤 페이지의 코드가 보이는 숫자를 고친다.

2009년 12월 후속 초안은 메시지 전달을 조정 수단으로 쓰는 스레드 비슷한 실행 방식이라고 설명했다. 이 우편함이 책임을 나눈다. 페이지가 일을 시키고 worker가 결과를 보고하면, 페이지는 그것을 지금 보여 줄지 결정한다. 이용자가 사이에 다른 작업을 요청했다면 늦은 답은 새 상황과 맞춰 봐야 한다. 열심히 일한 숫자에게 화면 점거권까지 주지는 않는다.

소수는 문제를 드러내기에 좋은 재료다. 멀리 있는 서버의 지연도, 고장 난 회선도 없다. 오래 도는 계산이 클릭을 처리해야 할 자리까지 차지했을 뿐이다. 반복문을 worker로 옮기면 페이지는 반응을 이어 가고 메시지가 올 때마다 새 숫자를 표시할 수 있다. 이용자는 브라우저가 멎었는지 추측하는 대신 일이 진행되는 모습을 본다.

물론 뒤에서 일하는 사람도 자리를 차지한다. 2009년 말 초안은 worker마다 시작 비용과 메모리 부담이 있다고 적었다. 예로 든 과한 설계가 재미있다. 400만 화소 그림의 픽셀마다 worker를 하나씩 만들지 말라는 것이다. 점 하나마다 직원 한 명을 채용하면 그림보다 출근 명단이 먼저 화면을 채운다. 묶어서 맡길 만한 일을 고르는 판단이 필요하다.

이후 문서는 worker의 종류와 연락 방법을 더 자세히 적었다. 2012년 후보 권고안 스냅샷은 전용 worker와 공유 worker를 구분했다. 전용 worker는 만든 쪽과 암묵적인 통로로 대화하고, 공유 worker는 포트를 통해 같은 출처의 여러 문맥과 연결된다. 2015년 작업 초안은 Worker 생성, onmessage, postMessage, 공유 worker의 명시적 MessagePort를 풀어 썼다. 일터를 따로 만들었으면 보고서를 받는 주소도 정해야 한다.

이 경계는 계산이 어디서 돌아가는지를 정한다. 브라우저의 저장 공간은 값이 어느 창과 출처에 속하는지를 정한다. 한 페이지에서 두 문제는 함께 생길 수 있다. 이용자의 선택을 저장하고, 시간이 걸리는 계산을 worker에 보내고, 메시지로 돌아온 답을 화면에 올린다. 일을 하는 장소와 사람을 상대하는 장소가 분리되면서 결과가 오는 길도 눈에 보이게 된다.

W3C 발행 이력에는 2009년 초안에서 2012년과 2015년 문서로 이어지는 과정이 남아 있다. 첫 소수 예시는 여전히 질문을 정확히 던진다. 브라우저가 생각하는 동안에도 사람의 클릭을 들을 수 있는가? worker가 뒤에서 세고 페이지가 앞에서 듣는 구조는 그 질문에 대한 설계상의 대답이었다.