이벤트 루프와 비동기 통신

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

 반대로 비동기(asyncrhous)란 직렬 방식이 아니라 병렬 방식으로 작업을 처리하는 것을 의미한다. 요청을 시작한 후 이 응답이 오든 말든 상관없이 다음 작업이 이루어지며 따라서 한 번에 여러 작업이 실행될 수 있다.

 

자바스크립트는 분명히 싱글 스레드에서 동기 방식으로 작동한다. 그러나 이러한 싱글 스레드 기반의 자바스크립트에서도 많은 양의 비동기 작업이 이루어지고 있다. 모던 웹 애플리케이션에선느 사용자에게 많은 양의 정보를 다양한 방식으로 제공하기 위해 많은 것이 비동기로 작동한다. 

 

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

 

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

 

1. 싱글 스레드 자바스크립트

자바스크립트는 싱글 스레드 언어라는 말을 들어봤을 것이다. 이것이 사실인지 확인하기 위해서는 먼저 스레드에 대해 알아야 한다. 과거에는 프로그램을 실행하는 단위가 오직 프로세스 뿐이었다. 프로세스(process)란 프로그램을 구동해 프로그램의 상태가 메모리 상에서 실행되는 작업 단위를 의미한다. 즉, 하나의 프로그램 실행은 하나의 프로세스를 가지고 그 프로세스 내부에서 모든 작업이 처리되는 것을 의미했다.

 

그러나 소프트웨어가 복잡해지면서 하나의 프로그램에서 동시에 여러 개의 복잡한 작업을 수행할 필요성이 대두됐다. 하지만 하나의 프로그램에는 하나의 프로세스만 할당되므로 이러한 작업을 수행하기 어려웠다. 그래서 더 작은 실행 단위인 스레드(thread)가 탄생하였다. 하나의 프로세스에는 여러 개의 스레드를 만들 수 있고, 스레드끼리는 메모리를 공유할 수 있어 여러 가지 작업을 동시에 수행할 수 있다. 이에 따라 프로세스 내부에서 여러 개의 스레드를 활용하면서 동시 다발적인 작업을 처리할 수 있게 된 것이다.

 

그렇다면 자바스크립트는 왜 싱글스레드로 설계됐을까? 먼저 멀티 스레드는 앞서 언급한 여러 가지 이점이 있지만 내부적으로 처리가 복잡하다는 단점이 있다.스레드는 하나의 프로세스에서 동시에 서로 같은 자원에 접근할 수 있는데, 동시에 여러 작업을 수행하다 보면 같은 자원에 대해 여러 번 수정하는 등 동시성 문제가 발생할 수 있어 이에 대한 처리가 필요하다. 또한 각각 격리돼 있는 프로세스와는 다르게, 하나의 스레드에 문제가 생기면 같은 자원을 공유하는 다른 스레드에도 동시에 문제가 일어날 수 있다. 

 

최초의 자바스크립트는 브라우저에서 HTML을 그리는 데 한정적인 도움을 주는 보조적인 역할로 만들어졌다. 자바스크립트가 처음 등장할 무렵에는 멀티 스레드에 대한 개념이 대중화 된 시기가 아니었다. 비중이 낮은 역할인 자바스크립트에 대해 동시성까지 고려하여 설계하지는 않았던 것이다. 또한, DOM과 관련된 문제도 발생할 수 있다. 만약 자바스크립트가 멀티 스레딩을 지우너해서 동시에 여러 스레드가 DOM을 조작할 수 있다면 어떻게 될까? 멀티 스레딩은 메모리 공유로 인해 동시에 같은 자원에 접근하면 타이밍 이슈가 발생할 수 있고, 이는 브라우저의 DOM 표시에 큰 문제를 야기할 수 있다.

 

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

 

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

 

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

console.log(1)

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

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

console.log(4)

 

위 코드를 실행하면 콘솔엔 1,4,2,3 순으로 나타난다. 그런데 싱글 스레드는 차례대로 작동하므로 1, 2(0.1초 지연), 3, 4 순으로 출력되어야 하는 것 아닌가? 아니다. 그 이유를 알기 위해서는 '이벤트 루프'라는 개념을 이해해야 한다.

 

2. 이벤트 루프

 

이 내용은 V8 런타임을 기준으로 작성됐다. 다른 JS 런타임에서는 작동에 차이가 있을 수 있다.

 

먼저 이벤트 루프는 ECMAScript, 즉 자바스크립트 표준에 나와 있는 내용은 아니다. 즉, 이벤트 루프란 자바스크립트 런타임 외부에서 자바스크립트의 비동기 실행을 돕기 위해 만들어진 장치라 볼 수 있다.

 

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가 존재하므로 호출 스택에 들어간다.
3. 2의 실행이 완료된 이후 다음 코드로 넘어간다. (아직 foo()는 존재)
4. bar()가 호출 스택에 들어간다.
5. bar() 내부에 console.log가 존재하므로 호출 스택에 들어간다.
6. 5의 실행이 완료된 이후에 다음 코드로 넘어간다. (아직 foo(), bar()는 존재)
7. 더 이상 bar()에 남은 것이 없으므로 호출 스택에서 제거된다.( 아직 foo()는 존재)
8. baz()가 호출 스택에 들어간다.
9. baz() 내부에 console.log가 존재하므로 호출 스택에 들어간다.
10. 9의 실행이 완료된 이후 다음 코드로 넘어간다. (아직, foo(), baz()는 존재)
11. 더 이상 baz()에 남은 것이 없으므로 호출 스택에서 제거된다. (아직 foo()는 존재)
12. 더 이상 foo()에 남은 것이 없으므로 호출스택에서 제거된다.
13. 이제 호출 스택이 완전히 비워졌다.

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

 

그렇다면 비동기 작업은 어떻게 실행될까?

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

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

foo()

 

foo,  baz, bar 순으로 출력된다. 그러나 실제 call stack(호출 스택) 내부에서는 아래와 같은 일이 발생한다.

 

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

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

 

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

 

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

 

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

 

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

 

3. 태스크 큐와 마이크로 태스크 큐

 

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

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

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

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

setTimeout(foo, 0)

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

 

예제코드를 실행하면 bar, baz, foo 순으로 실행된다. 확실히 Promise가 우선권이 있음을 알 수 있다.

각 태스크에 들어가는 대표적인 작업은 아래와 같다.

 

- 태스크 큐: setTimeout, setInterval, setImmediate

- 마이크로 태스크 큐: process.nextTick, Promises, queueMicroTask, MutationObserver

 

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

 

<!DOCTYPE html>
<body>
    <ul>
        <li>동기 코드: <button id="sync">0</button></li>
        <li>태스크: <button id="macrotask">0</button></li>
        <li>마이크로 태스크: <button id="microtask">0</button></li>
    </ul>

    <button id="macro_micro">모두 동시 실행</button>
</body>
<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', function(){
    for(let i = 0; i <= 10000; i++) {
        sync.innerHTML = 1
    }
})

// setTimeout으로 태스크 큐에 작업을 넣어서 1부터 렌더링
macrotask.addEventListener('click', function() {
    for (let i = 0; i <= 100000; i++) {
        setTimeout(() => {
            macrotask.innerHTML = i
        }, 0)
    }
})

// queueMicrotask로 마이크로 태스크 큐에 넣어서 1부터 렌더링
microtask.addEventListener('click', function() {
    for (let i = 0; i <= 100000; i++) {
        queueMicrotask(() => {
            microtask.innerHtml = i
        }) 
    }
})

macro_micro.addEventListener('click', function(){
    for (let i = 0; i <= 100000; i++) {
        sync.innerHTML = i
    

        setTimeout(() => {
            macrotask.innerHtml = i
        }, 0 )

        queueMicrotask(() => {
            microtask.innerHTML
        })
    }
})

</script>
</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 순으로 출력된다. 즉, 브라우저에 렌더링하는 작업은 마이크로 태스크 큐과 태스크 큐 사이에서 일어난다는 것을 알 수 있다.

 

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

 

4. 정리

 

자바스크립트 코드를 실행하는 것 자체는 싱글 스레드로 이루어져서 비동기를 처리하기 어렵지만 자바스크립트 코드를 실행하는 것 이외에 태스크 큐, 이벤트 루프, 마이크로 태스크 큐, 브라우저/Node.js API 등이 적절한 생태계를 이루고 있기 때문에 싱글 스레드로는 불가능한 비동기 이벤트 처리가 가능해진 것이다.

 

 

 

참고: 리액트 DeepDive