프로세스와 스레드: 메인 스레드가 막히면

주문 내역 CSV를 올리면 브라우저에서 파싱해 표로 보여 주는 화면이 있다. 파일이 몇 MB를 넘자 업로드 버튼을 누른 뒤 몇 초 동안 화면이 굳는다. 취소 버튼도 눌리지 않고, 입력란에 글자도 쳐지지 않는다. 함수에 async를 붙이고 await file.text()로 읽었는데도 그렇다.

async function onUpload(file: File) {
  const text = await file.text()
  const rows = parseCsv(text)
  renderTable(rows)
}

async는 "기다리는 동안 다른 일을 해도 된다"는 표시일 뿐, 계산을 다른 곳으로 옮겨 주지 않는다. parseCsv가 2초 동안 계산하면, 그 2초 동안 페이지의 JavaScript가 도는 스레드는 다른 아무것도 하지 못한다. 이 장은 그 스레드가 무엇이고, 일을 어떤 순서로 처리하며, 어떻게 덜 막히게 하는지 본다.

프로세스와 스레드

프로세스(process)는 실행 중인 프로그램 하나다. 운영체제는 프로세스마다 메모리 공간을 따로 준다. 한 프로세스가 다른 프로세스의 메모리를 바로 읽을 수 없고, 하나가 죽어도 다른 하나는 산다. 스레드(thread)는 한 프로세스 안의 실행 흐름이다. 같은 프로세스의 스레드들은 메모리를 함께 쓴다. 그래서 값을 주고받기는 쉽지만, 두 스레드가 같은 값을 동시에 고치면 꼬일 수 있다(다음 장의 주제다).

브라우저는 여러 프로세스로 나뉘어 돈다. Chrome의 사이트 격리(Site Isolation)는 데스크톱에서는 서로 다른 웹사이트의 페이지를 항상 다른 프로세스에 넣는다(Android는 일부 사이트만)(Chromium: Site Isolation). 한 탭이 멈춰도 다른 사이트 탭이 같이 멈추지 않는 이유다. 그리고 페이지 하나의 JavaScript는 그 페이지를 맡은 프로세스의 메인 스레드(main thread) 하나에서 돈다. 클릭 처리, 스타일·레이아웃 계산도 같은 스레드의 일이다. 메인 스레드는 한 번에 작업 하나만 처리한다(web.dev: 긴 작업 최적화).

여러 일을 번갈아 진행해 함께 나아가게 하는 것을 동시성(concurrency), 여러 코어에서 같은 순간에 실제로 함께 실행하는 것을 병렬성(parallelism)이라고 구분한다. async/await가 주는 것은 동시성이다. 기다리는 동안 다른 일로 넘어갈 수는 있어도, 계산 두 개를 같은 순간에 돌리지는 않는다.

이벤트 루프: 태스크 하나, 마이크로태스크 전부

메인 스레드가 일을 고르는 규칙이 이벤트 루프(event loop)다. 할 일은 두 줄로 선다. 스크립트 실행, 이벤트 처리, setTimeout 콜백은 태스크 큐(task queue)에 들어간다. Promise의 .then 콜백과 queueMicrotask로 넣은 함수는 마이크로태스크 큐(microtask queue)에 들어간다. 이벤트 루프는 태스크를 하나 실행하고, 그 태스크가 끝나면 다음 태스크로 가기 전에 마이크로태스크 큐를 빌 때까지 실행한다. 마이크로태스크가 새 마이크로태스크를 넣으면 그것도 이번에 실행한다(MDN: 마이크로태스크 가이드). 개념 정리는 이벤트 루프 노트에 있다.

console.log('A')
setTimeout(() => console.log('B'), 0)
Promise.resolve().then(() => console.log('C'))
console.log('D')

1console.log('A')2setTimeout(() => { // timeout3  console.log('B')4}, 0)5Promise.resolve().then(() => { // then6  console.log('C')7})8console.log('D')

while (tasks.length > 0) {
  run(tasks.shift()) // 태스크 하나
  while (micros.length > 0) run(micros.shift()) // 마이크로태스크는 빌 때까지
}

긴 작업과 놓치는 프레임

화면을 그리는 것도 메인 스레드의 일이다. 60Hz 화면이라면 1초에 60번, 약 16.7ms마다 새 프레임을 그릴 기회가 온다. 그런데 메인 스레드가 태스크 하나를 끝내지 않으면 그 사이 그리기 차례가 오지 않는다. web.dev는 50ms를 넘는 태스크를 긴 작업(long task)이라 부르고, 긴 작업 동안 브라우저는 사용자 입력에 반응하지 못한다고 설명한다(web.dev: 긴 작업 최적화).

메인 스레드 밖으로 보내기

쪼개기는 계산 총량을 줄이지 않는다. 계산 자체가 크면 다른 스레드나 프로세스로 보낸다.

• 브라우저: Web Worker. 워커는 백그라운드 스레드에서 스크립트를 돌려 화면을 막지 않는다. 대신 DOM에 손댈 수 없고, 메인 스레드와는 postMessage로만 주고받는다. 보낸 데이터는 공유되지 않고 구조화된 복제(structured clone)로 복사된다. 큰 ArrayBuffer는 복사 대신 소유권을 넘길(transfer) 수 있다(MDN: Web Worker 사용하기). 처음 장면의 CSV 파싱은 워커로 보내고 결과 배열만 받아 그리면 된다.
• Node.js: libuv 스레드 풀(thread pool). Node도 JavaScript는 한 스레드에서 돈다. libuv(Node가 파일·네트워크 입출력에 쓰는 C 라이브러리) 스레드 풀이 맡는 일은 두 갈래다. 하나는 운영체제가 비동기로 해 주지 못하는 입출력으로, fs API(동기 버전과 파일 감시 제외)와 dns.lookup()이 그렇다. 다른 하나는 메인 스레드에서 돌리면 오래 막을 무거운 계산으로, crypto.pbkdf2()·crypto.scrypt() 같은 비동기 암호 API와 zlib 압축 API(동기 버전 제외)가 그렇다. 둘 다 이 풀에서 돌고, 풀의 기본 크기는 4다(Node.js 문서: UV_THREADPOOL_SIZE). 반대로 …Sync 함수는 JavaScript 스레드에서 끝날 때까지 돈다. 그동안 그 서버는 다른 요청을 하나도 처리하지 못한다. 블로킹과 동기의 차이는 동기·비동기와 블로킹 노트에 있다.
• Python: GIL과 multiprocessing. CPython에는 한 번에 한 스레드만 Python 바이트코드(bytecode, 소스를 번역해 둔 중간 명령. 9장)를 실행하게 하는 전역 인터프리터 락(global interpreter lock, GIL)이 있다. 입출력(I/O)을 기다릴 때는 GIL을 놓으므로 네트워크 요청 여러 개를 동시에 기다리는 일에는 스레드가 쓸모 있다. CPU만 쓰는 계산(CPU-bound)은 스레드를 늘려도 동시에 돌지 않는다(Python 용어집: GIL). 이럴 때 multiprocessing은 스레드 대신 프로세스를 써서 GIL을 피한다(Python 문서: multiprocessing). Python 3.13부터는 GIL을 끈 빌드(free-threaded build)를 따로 만들 수 있다. 기본 빌드에는 여전히 GIL이 있다.

console.log('A')
setTimeout(() => {
  console.log('B')
  queueMicrotask(() => console.log('C'))
}, 0)
Promise.resolve().then(() => {
  console.log('D')
  setTimeout(() => console.log('E'), 0)
  queueMicrotask(() => console.log('F'))
})
queueMicrotask(() => console.log('G'))
console.log('H')