hyungju-lee

4.5 이벤트 루프와 비동기 통신의 이해

많은 자바스크립트 개발자가 알고 있는 것처럼 자바스크립트는 싱글 스레드에서 작동한다.
즉, 기본적으로 자바스크립트는 한 번에 하나의 작업만 동기 방식으로만 처리할 수 있다.
동기(synchronous)에 대해 간단하게 설명하자면 직렬 방식으로 작업을 처리하는 것을 의미하며, 이 요청이 시작된 이후에는 무조건 응답을 받은 이후에야 비로소 다른 작업을 처리할 수 있다.
그동안 다른 모든 작업은 대기한다.
이러한 방식은 개발자에게 매우 직관적으로 다가오지만 한 번에 다양한 많은 작업을 처리할 수 없다.
반대의 의미인 비동기(asynchronous)란 직렬 방식이 아니라 병렬 방식으로 작업을 처리하는 것을 의미한다.
요청을 하작한 후 이 응답이 오건 말건 상관없이 다음 작업이 이루어지며, 따라서 한 번에 여러 작업이 실행될 수 있다.

자바스크립트는 분명히 싱글 스레드에서 동기 방식으로 작동한다.
그러나 이러한 싱글 스레드 기반의 자바스크립트에서도 많은 양의 비동기 작업이 이뤄지고 있다.
모던 웹 애플리케이션에서는 사용자에게 많은 양의 정보를 다양한 방식으로 제공하기 위해서 많은 것이 비동기로 작동한다.
구체적으로 예를 들어보자.
사용자가 검색어를 입력해 검색을 위해 네트워크 요청이 발생하는 순간에도 사용자는 다른 작업을 처리할 수 있다.
이는 언뜻 보면 동기식의 자바스크립트 방식에서는 불가능한 시나리오다.
분명 자바스크립트는 싱글 스레드의 동기식으로 작동하므로 검색의 결과를 받기 전까지 아무런 작업도 하지 못하는 것이 자연스러워 보인다.
그러나 우리는 웹페이지에서 다양한 비동기 작업을 수행하고 있다.

리액트는 또 어떤가?
과거 렌더링 스택을 비우는 방식으로 구현됐던 동기식의 렌더링이 16 버전에 접어들면서비동기식으로 작동하는 방법도 소개됐다.
이처럼 리액트에도 비동기식으로 작동하는 작업이 존재한다.

자바스크립트 환경에서 이러한 것이 어떻게 가능한지 알기 위해서는 이러한 비동기 작업이 어떻게 처리되는지 이해하고 비동기 처리를 도와주는 이벤트 루프를 비롯한 다양한 개념에 대해 알고 있어야 한다.
비동기 코드의 작동 방식에 대해 이해한다면 자바스크립트에서 어떻게 여러 가지 요청을 동시에 처리하고 있는지, 이러한 요청받은 테스크에 대한 우선순위는 무엇인지, 또 주의할 점은 무엇인지 파악해 사용자에게 더욱 매끄러운 웹 애플리케이션 서비스를 제공할 수 있을 것이다.

4.5.1 싱글 스레드 자바스크립트

자바스크립트는 싱글 스레드 언어라는 말을 많이 들어봤을 것이다.
이것이 사실인지 확인하기 위해서는 먼저 스레드에 대해 알아야 한다.
과거에는 프로그램을 실행하는 단위가 오직 프로세스뿐이었다.
**프로세스(process)**란 프로그램을 구동해 프로그램의 상태가 메모리상에서 실행되는 작업 단위를 의미한다.
즉, 하나의 프로그램 실행은 하나의 프로세스를 가지고 그 프로세스 내부에서 모든 작업이 처리되는 것을 의미했다.
그러나 소프트웨어가 점차 복잡해지면서 하나의 프로그램에서 동시에 여러 개의 복잡한 작업을 수행할 필요성이 대두됐다.
하지만 하나의 프로그램에는 하나의 프로세스만이 할당되므로 이러한 작업을 수행하기 어려웠는데, 그래서 탄생한 더 작은 실행 단위가 바로 **스레드(thread)**다.
하나의 프로세스에서는 여러 개의 스레드를 만들 수 있고,스레드끼리는 메모리를 공유할 수 있어 여러 가지 작업을 동시에 수행할 수 있다.
이에 따라 프로세스 내부에서 여러 개의 스레드를 활용하면서 동시 다발적인 작업을 처리할 수 있게 된 것이다.

그렇다면 자바스크립트는 왜 싱글 스레드로 설계됐을까?
먼저 멀티 스레드는 앞서 언급한 여러 가지 이점이 있지만 내부적으로 처리가 복잡하다는 단점이 있다.
스레드는 하나의 프로세스에서 동시에 서로 같은 자원에 접근할 수 있는데, 동시에 여러 작업을 수행하다 보면 같은 자원에 대해 여러 번 수정하는 등 동시성 문제가 발생할 수 있어 이에 대한 처리가 필요하다.
또한 각각 격리돼 있는 프로세스와는 다르게, 하나의 스레드가 문제가 생기면 같은 자원을 공유하는 다른 스레드에도 동시에 문제가 일어날 수 있다.
이러한 특징을 토대로 과거 자바스크립트의 역할을 다시금 상기해볼 필요가 있다.
최초의 자바스크립트는 브라우저에서 HTML을 그리는 데 한정적인 도움을 주는 보조적인 역할로 만들어졌다.
잠시 이와 관련된 역사를 알아보자.

자바스크립트는 1995년 경에 첫선을 보였다.
그리고 그 당시에는 아직 멀티 스레드에 대한 개념이 대중화되던 시기가 아니었다. (2002년에 출시된 인텔 펜티엄4가 최초로 동시 멀티스레딩을 구현한 데스크톱이었다.)
그리고 1995년에는 넷스케이프 개발자 브랜던 아이크가 브라우저에서 아주 간단한 스크립트를 지원할 목적으로 LiveScript(자바스크립트의 전신)를 만들었던 것이 자바스크립트의 시작이다.
최초의 자바스크립트는 이름에서 유추할 수 있는 것처럼 다른 여러 가지 언어를 참고해 단 10일 만에 첫 버전이 완성됐다.
설계가 빨리 되고 다른 언어를 참고하던 것을 차치하고서라도 최초의 자바스크립트는 단순히 버튼 위에 이미지를 띄우거나, 간단한 경고창을 띄우거나, 폼을 처리하는 등 아주 기초적인 수준에서만 제한적으로 사용됐다.
즉, 설계 당시에는 약 30년 뒤 현재처럼 자바스크립트로 웹페이지에서 벌어지는 온갖 다양한 일을 처리할 것이라고 생각하지 못했을 것이다.
문제는 이뿐만이 아니다.
자바스크립트로 DOM을 조작하는 것을 생각해 보자.
만약 자바스크립트가 멀티 스레딩을 지원해서 동시에 여러 스레드가 DOM을 조작할 수 있다면 어떻게 될까?
앞서 이야기한 것처럼 멀티 스레딩은 메모리 공유로 인해 동시에 같은 자원에 접근하면 타이밍 이슈가 발생할 수 있고, 이는 브라우저의 DOM 표시에 큰 문제를 야기할 수 있다.

이러한 1995년의 상황을 빗대어 보았을 때 자바스크립트를 싱글 스레드 언어로 구현한 것은 그 당시의 상황으로 봤을 때는 합리적인 결정으로 볼 수 있다.
그 당시의 시선으로 본다면 오히려 현재의 자바스크립트 환경이 더 이상하게 보여질 수도 있다.
단순한 작업을 처리하기 위한 자바스크립트가 정말 다양한 영역에 걸쳐 활용되고 있기 때문이다.
자바스크립트가 다양한 역할을 하게 되면서 개발자에 따라서는 자바스크립트 설계 자체가 바뀔 때가 됐다고 보기도 한다.

다시 싱글 스레드 자바스크립트로 돌아와서 자바스크립트가 싱글 스레드라는 것은 무엇을 의미할까?
자바스크립트 코드의 실행이 하나의 스레드에서 순차적으로 이루어진다는 것을 의미한다.
하나의 스레드에서 순차적으로 이루어진다는 것은 코드를 한 줄 한 줄 실행한다는 것을 의미하며 궁극적으로 하나의 작업이 끝나기 전까지는 뒤이은 작업이 실행되지 않는 것을 의미한다.
C 언어나 다른 메이저 프로그래밍 언어에서는 스레드에서 실행중인 함수를 시스템이 임의로 멈추고 다른 스레드의 코드를 먼저 실행할 수 있지만 자바스크립트에는 그런 기능이 존재하지 않는다. (Node.js에서 새롭게 추가된 Worker나 브라우저에서 제공하는 WebWorker를 활용하면 동시에 여러 작업을 처리할 수 있지만 이 두 기능은 매우 최근에 나온 것으로 본 절에서는 논외로 한다.)

자바스크립트에서 하나의 코드가 실행하는 데 오래 걸리면 뒤이은 코드가 실행되지 않는다는 것을 자바스크립트 개발자라면 누구나 알고 있을 것이다.
이러한 자바스크립트의 특징을 'Run-to-Completion'이라고 부른다.
이러한 특징은 자바스크립트 개발자에게 동시성을 고민할 필요가 없다는 아주 큰 장점이 되지만, 반대로 때에 따라서 웹페이지에서는 단점이 될 수 있다.
하나의 작업이 끝나기 전까지는 다른 작업이 실행되지 않으므로 어떠한 작업이 오래 걸린다면 사용자에게 마치 웹페이지가 멈춘 것 같은 느낌을 줄 수 있다.
결론적으로 Run-to-Completion, 즉 자바스크립트의 모든 코드는 '동기식'으로 한 번에 하나씩 순차적으로 처리된다.

그렇다면 비동기는 무엇일까?
자바스크립트에서 비동기 함수를 선언할 때 쓰는 async는 영어로 asynchronous, 즉 동시에 일어나지 않는 것을 의미한다.
동기식과 다르게 요청한 즉시 결과가 주어지지 않을 수도 있고, 따라서 응답이 언제 올지도 알 수 없다.
그러나 동기식과 다르게 여러 작업을 동시에 수행할 수 있다는 장점이 있다.

console.log(1)

setTimeout(() => {
  console.log(2)
}, 0)

setTimeout(() => {
  console.log(3)
}, 100)

console.log(4)

자바스크립트 코드를 작성해본 개발자라면 누구나 자신 있게 해당 콘솔 출력 순서가 1, 4, 2, 3으로 나타난다는 것을 알 수 있을 것이다.
그런데 사실 자바스크립트의 특징, 즉 싱글 스레드로 작동하기 때문에 모든 코드는 'Run-to-Completion'으로 작동해야 하므로 결론적으로 1, 2, (0.1초 후에)3, 4로 출력되어야 정상이다.
그러나 그렇지 않다.
동기식으로 작동하는 자바스크립트 세상에서 어떻게 이런 비동기 코드를 처리할 수 있는 것일까?
이러한 사실을 이해하려면 이벤트 루프라는 개념을 이해해야 한다.

4.5.2 이벤트 루프란?

먼저 지금부터 설명하는 내용은 자바스크립트 런타임 중에서 가장 유명한 V8을 기준으로 작성됐다.
다른 자바스크립트 런타임에서는 작동에 약간의 차이가 있을 수 있다.

먼저 이벤트 루프는 ECMAScript, 즉 자바스크립트 표준에 나와 있는 내용은 아니다.
즉, 이벤트 루프란 자바스크립트 런타임 외부에서 자바스크립트의 비동기 실행을 돕기 위해 만들어진 장치라 볼 수 있다.
V8, Spider Monkey 같은 현대의 자바스크립트 런타임 엔진에는 자바스크립트 코드를 효과적으로 실행하기 위한 여러 가지 장치들이 마련돼 있다.

4.5.2.1 호출 스택과 이벤트 루프

호출 스택(call stack)은 자바스크립트에서 수행해야 할 코드나 함수를 순차적으로 담아두는 스택이다.

function bar() {
  console.log('bar')
}

function baz() {
  console.log('baz')
}

function foo() {
  console.log('foo')
  bar()
  baz()
}

foo()

이 코드는 foo를 호출하고, 내부에서 bar, baz를 순차적으로 호출하는 구조로 돼있다.
이 코드들은 대략 다음과 같은 순서로 호출 스택에 쌓이고 비워지게 된다.

  1. foo()가 호출 스택에 먼저 들어간다.
  2. foo() 내부에 console.log('foo')가 호출 스택에 들어간다.
  3. 2의 실행이 완료된 이후에 다음 코드로 넘어간다. (아직 foo()는 호출 스택에 남아있다.)
  4. bar()가 호출 스택에 들어간다.
  5. bar() 내부에 console.log('bar')가 호출 스택에 들어간다.
  6. 5의 실행이 완료된 이후에 다음 코드로 넘어간다. (아직 foo(), bar()는 호출 스택에 남아있다.)
  7. 더 이상 bar() 내부에 실행할 코드가 없으므로 bar()를 호출 스택에서 제거한다. (아직 foo()는 호출 스택에 남아있다.)
  8. baz()가 호출 스택에 들어간다.
  9. baz() 내부에 console.log('baz')가 호출 스택에 들어간다.
  10. 9의 실행이 완료된 이후에 다음 코드로 넘어간다. (아직 foo(), baz()는 호출 스택에 남아있다.)
  11. 더 이상 baz() 내부에 실행할 코드가 없으므로 baz()를 호출 스택에서 제거한다. (아직 foo()는 호출 스택에 남아있다.)
  12. 더 이상 foo() 내부에 실행할 코드가 없으므로 foo()를 호출 스택에서 제거한다.
  13. 이제 호출 스택이 완전히 비워졌으므로 더 이상 실행할 코드가 없다.

이 호출 스택이 비어 있는지 여부를 확인하는 것이 바로 이벤트 루프다.
이벤트 루프는 단순히 이벤트 루프만의 단일 스레드 내부에서 이 호출 스택 내부에 수행해야 할 작업이 있는지 확인하고, 수행해야 할 코드가 있다면 자바스크립트 엔진을 이용해 실행한다.
한 가지 알아둘 점은 '코드를 실행하는 것'과 '호출 스택이 비어있는지 확인하는 것' 모두가 단일 스레드에서 일어난다는 점이다.
즉, 두 작업은 동시에 일어날 수 없으며 한 스레드에서 순차적으로 일어난다.

그렇다면 비동기 작업은 어떻게 이루어질까?

function bar() {
  console.log('bar')
}

function baz() {
  console.log('baz')
}

function foo() {
  console.log('foo')
  setTimeout(bar, 0) // setTimeout 만 추가했다.
  baz()
}

foo()

foo, bax, bar 순으로 출력된다.

  1. foo()가 호출 스택에 먼저 들어간다.
  2. foo() 내부에 console.log('foo')가 호출 스택에 들어간다.
  3. 2의 실행이 완료된 이후에 다음 코드로 넘어간다. (아직 foo()는 호출 스택에 남아있다.)
  4. setTimeout(bar, 0)이 호출 스택에 들어간다.
  5. 4번에 대해 타이머 이벤트가 실행되며 태스크 큐로 들어가고, 그 대신 바로 스택에서 제거된다.
  6. baz()가 호출 스택에 들어간다.
  7. baz() 내부에 console.log('baz')가 호출 스택에 들어간다.
  8. 7의 실행이 완료된 이후에 다음 코드로 넘어간다. (아직 foo(), baz()는 호출 스택에 남아있다.)
  9. 더 이상 baz() 내부에 실행할 코드가 없으므로 baz()를 호출 스택에서 제거한다. (아직 foo()는 호출 스택에 남아있다.)
  10. 더 이상 foo() 내부에 실행할 코드가 없으므로 foo()를 호출 스택에서 제거한다.
  11. 이제 호출 스택이 완전히 비워졌다.
  12. 이벤트 루프가 호출 스택이 비워져 있다는 것을 확인했다. 그리고 태스크 큐를 확인하더니 4번에 들어갔던 내용이 있어 bar()를 호출 스택에 넣는다.
  13. bar() 내부에 console.log('bar')가 호출 스택에 들어간다.
  14. 13의 실행이 완료된 이후에 다음 코드로 넘어간다. (아직 bar()는 호출 스택에 남아있다.)
  15. 더 이상 bar() 내부에 실행할 코드가 없으므로 bar()를 호출 스택에서 제거한다.

위 코드를 보면, setTimeout(() => {}, 0)이 정확하게 0초 뒤에 실행된다는 것을 보장하지 못한다는 것을 이해하게 될 것이다.

여기서부터는 태스크 큐라는 새로운 개념이 등장한다.
태스크 큐란 실행해야 할 태스크의 집합을 의미한다.
이벤트 루프는 이러한 태스크 큐를 한 개 이상 가지고 있다.
그리고 이름과는 다르게 태스크 큐는 자료 구조의 큐(queue)가 아니고 set 형태를 띠고 있다.
그 이유는 선택된 큐 중에서 실행 가능한 가장 오래된 태스크를 가져와야 하기 때문이다.
자료구조인 큐는 무조건 앞에 있는 거을 FIFO(First In First Out) 형식으로 꺼내와야 하지만 태스크 큐는 그렇지 않다.
태스크 큐에서 의미하는 '실행해야 할 태스크'라는 것은 비동기 함수의 콜백 함수나 이벤트 핸들러 등을 의미한다.

즉, 이벤트 루프의 역할은 호출 스택에 실행 중인 코드가 있는지, 그리고 태스크 큐에 대기 중인 함수가 있는지 반복해서 확인하는 역할을 한다.
호출 스택이 비었다면 태스크 큐에 대기 중인 작업이 있는지 확인하고, 이 작업을 실행 가능한 오래된 것부터 순차적으로 꺼내와서 실행하게 된다.
이 작업 또한 마찬가지로 태스크 큐가 빌 때까지 이뤄진다.

그렇다면 마지막으로 궁금해지는 것은 저 비동기 함수는 누가 수행하느냐다.
n초 뒤에 setTimeout을 요청하는 작업은 누가 처리할까?
fetch를 기반으로 실행되는 네트워크 요청은 누가 보내고 응답을 받을 것인가?
이러한 작업들은 모두 자바스크립트 코드가 동기식으로 실행되는 메인 스레드가 아닌 태스크 큐가 할당되는 별도의 스레드에서 수행된다.
이 별도의 스레드에서 태스크 큐에 작업을 할당해 처리하는 것은 브라우저나 Node.js의 역할이다.
즉, 자바스크립트 코드 실행은 싱글 스레드에서 이뤄지지만 이러한 외부 Web API 등은 모두 자바스크립트 코드 외부에서 실행되고 콜백이 태스크 큐로 들어가는 것이다.
이벤트 루프는 호출 스택이 비고, 콜백이 실행 가능한 때가 오면 이것을 꺼내서 수행하는 역할을 하는 것이다.
만약 이러한 작업들도 모두 자바스크립트 코드가 실행되는 메인 스레드에서만 이뤄진다면 절대로 비동기 작업을 수행할 수 없을 것이다.

그렇다면 이 비동기 작업을 수행하는 태스크 큐는 과연 어떤 구조로 어떻게 작동할까?

4.5.3 태스크 큐와 마이크로 태스크 큐

태스크 큐와 다르게, 마이크로 태스크 큐라는 것도 있다.
이벤트 루프는 하나의 마이크로 태스크 큐를 갖고 있는데, 기존의 태스크 큐와는 다른 태스크를 처리한다.
여기에 들어가는 마이크로 태스크에는 대표적으로 Promise가 있다.
이 마이크로 태스크 큐는 기존 태스크 큐보다 우선권을 갖는다.
즉, setTimeout과 setInterval은 Promise보다 늦게 실행된다.
명세에 따르면, 마이크로 태스크 큐가 빌 때까지는 기존 태스크 큐의 실행은 뒤로 미뤄진다.

function foo() {
  console.log('foo')
}

function bar() {
  console.log('bar')
}

function baz() {
  console.log('baz')
}

setTimeout(foo, 0)

Promise.resolve().then(bar).then(baz)

bar, baz, foo 순으로 출력된다.
확실히 Promise가 우선권이 있음을 알 수 있다.
각 태스크에 들어가는 대포적인 작업은 다음과 같다.

  • 태스크 큐: setTimeout, setInterval, setImmediate
  • 마이크로 태스크 큐: Promise, process.nextTick, queueMicrotask, MutationObserver

그렇다면 렌더링은 언제 실행될까?
태스크 큐일까 마이크로 태스크 큐일까?
태스크 큐를 실행하기에 앞서 먼저 마이크로 태스크 큐를 실행하고, 이 마이크로 태스크 큐를 실행한 뒤에 렌더링이 일어난다.
각 마이크로 태스크 큐 작업이 끝날 때마다 한 번씩 렌더링할 기회를 얻게 된다.

<!-- 동기 코드, 태스크 큐, 마이크로 태스크 큐와 렌더링과의 관계를 확인할 수 있는 코드 -->
<html>
<body>
<ul>
    <li>동기 코드: <button type="button" id="sync">0</button></li>
    <li>태스크: <button type="button" id="macrotask">0</button></li>
    <li>마이크로 태스크: <button type="button" id="microtask">0</button></li>
</ul>

<button type="button" id="macro_micro">모두 동시 실행</button>
<script>
    const button = document.getElementById('run')
    
    const sync = document.getElementById('sync')
    const macrotask = document.getElementById('macrotask')
    const microtask = document.getElementById('microtask')
    const macro_micro = document.getElementById('macro_micro')
    
    // 동기 코드로 버튼에 1부터 렌더링
    sync.addEventListener('click', () => {
        for (let i = 1; i <= 100000; i++) {
            sync.innerHTML = i
        }
    })
    
    // setTimeout으로 태스크 큐에 작업을 넣어서 1부터 렌더링
    macrotask.addEventListener('click', () => {
        for (let i = 1; i <= 100000; i++) {
            setTimeout(() => {
                macrotask.innerHTML = i
            }, 0)
        }
    })
    
    // queueMicrotask로 마이크로 태스크 큐에 작업을 넣어서 1부터 렌더링
    microtask.addEventListener('click', () => {
        for (let i = 1; i <= 100000; i++) {
            queueMicrotask(() => {
                microtask.innerHTML = i
            })
        }
    })
    
    macro_micro.addEventListener('click', () => {
        for (let i = 1; i <= 100000; i++) {
            sync.innerHTML = i
            
            setTimeout(() => {
                macrotask.innerHTML = i
            }, 0)
            
            queueMicrotask(() => {
                microtask.innerHTML = i
            })
        }
    })
</script>
</body>
</html>

위 예제 코드의 결과를 정리하면 다음과 같다.

  • 동기 코드는 우리가 예상했던 것처럼 해당 연산, 즉 100,000까지 숫자가 올라가기 전까지는 렌더링이 일어나지 않다가 for 문이 끝나야 비로소 렌더링 기회를 얻으며 100,000이라는 숫자가 한 번에 나타난다.
  • 태스크 큐(setTimeout)는 모든 setTimeout 콜백이 큐에 들어가기 전까지 잠깐의 대기 시간을 갖다가 1부터 100,000까지 순차적으로 렌더링되는 것을 볼 수 있다.
  • 마이크로 태스크 큐(queueMicrotask)는 동기 코드와 마찬가지로 렌더링이 전혀 일어나지 않다가 100,000까지 다 끝난 이후에야 한 번에 렌더링이 일어난다.
  • 모든 것을 동시에 실행했을 경우 동기 코드와 마이크로 태스크 큐만 한 번에 100,000까지 올라가고, 태스크 큐만 앞선 예제처럼 순차적으로 렌더링되는 것을 볼 수 있다.

이러한 작업 순서는 브라우저에 다음 리페인트 전에 콜백 함수 호출을 가능하게 하는 requestAnimationFrame으로도 확인할 수 있다.

console.log('a') // 동기

setTimeout(() => {
    console.log('b') // 태스크 큐
}, 0)

Promise.resolve().then(() => console.log('c')) // 마이크로 태스크 큐

window.requestAnimationFrame(() => console.log('d')) // 브라우저 리페인팅 직전

// a(동기), c(마이크로 태스크 큐), d(브라우저 리페인팅 직전), b(테스크 큐)

위 코드를 실행하면 a, c, d, b 순으로 출력된다.
즉 브라우저에 렌더링하는 작업은 마이크로 태스크 큐와 태스크 큐 사이에서 일어난다는 것을 알 수 있다.

결론적으로 동기 코드는 물론이고 마이크로 태스크 또한 마찬가지로 랜더링에 영향을 미칠 수 있다.
따라서 만약 특정 렌더링이 자바스크립트 내 무거운 작업과 연관이 있다면 이를 어떤 식으로 분리해서 사용자에게 좋은 애플리케이션 경험을 제공해 줄지 고민해 보아야 한다.

4.5.4 정리