자바스크립트 이벤트 루프, 실행 순서가 헷갈릴 때 바로 이해하는 방법

목차

• 이벤트 루프가 필요한 이유
• 콜 스택, 태스크 큐, 마이크로태스크 큐를 분리해서 보기
• 실제로 어떤 순서로 실행되는가
• 실험 환경은 이렇게 준비하면 충분합니다
• 브라우저에서 실행 순서를 직접 확인해보기
• Node.js에서는 무엇이 다를까
• 실무에서 자주 틀리는 포인트
• 실행 순서 버그를 잡는 가장 현실적인 방법

빠른 답

• 이벤트 루프는 콜 스택이 비었을 때 대기 중인 작업을 실행 순서에 맞게 넘겨주는 구조입니다.
• Promise.then, queueMicrotask는 보통 setTimeout보다 먼저 실행되며, 이유는 마이크로태스크가 더 높은 우선순위를 가지기 때문입니다.
• setTimeout(fn, 0)은 즉시 실행이 아니라 현재 동기 코드가 끝난 뒤 다음 턴으로 미루는 동작에 가깝습니다.
• 실행 순서 버그를 잡을 때는 콜 스택, 마이크로태스크, 매크로태스크를 분리해서 로그로 확인해야 합니다.

초안을 발행용 글로 다시 정리하고 있습니다. 빠른 답을 짧게 다듬고, 브라우저·Node.js에서 바로 실행해 볼 수 있는 설정과 예제를 중심으로 본문을 재구성하겠습니다.# 자바스크립트 이벤트 루프, 실행 순서가 헷갈릴 때 바로 이해하는 방법

빠른 답

• 이벤트 루프는 콜 스택이 비는 시점마다 대기 중인 작업을 확인하고, 우선순위에 맞게 다시 실행 흐름에 올리는 런타임 메커니즘입니다.
• Promise.then, queueMicrotask, await 이후 코드는 보통 setTimeout(..., 0)보다 먼저 실행됩니다. 이들은 마이크로태스크로 처리되기 때문입니다.
• setTimeout(fn, 0)은 즉시 실행이 아니라 현재 동기 코드와 현재 턴의 마이크로태스크가 끝난 뒤 다음 태스크로 넘기는 예약에 가깝습니다.
• 실행 순서가 꼬일 때는 코드를 동기, 마이크로태스크, 매크로태스크로 나눠 로그를 찍으면 원인을 가장 빨리 찾을 수 있습니다.

이벤트 루프가 필요한 이유

자바스크립트는 기본적으로 한 번에 하나의 실행 흐름만 처리합니다. 함수가 실행되는 동안 다른 자바스크립트 코드는 끼어들 수 없고, 현재 작업이 끝나야 다음 작업으로 넘어갑니다. 이 특성은 상태 변경을 추적하기 쉽게 만들지만, 네트워크 요청이나 파일 읽기, 타이머, 사용자 입력처럼 완료 시점이 불확실한 작업을 그대로 동기식으로 처리하면 문제가 생깁니다. 브라우저라면 화면이 멈추고, 서버라면 요청 처리량이 급격히 떨어집니다.

그래서 자바스크립트 런타임은 비동기 작업을 자바스크립트 엔진 바깥으로 넘깁니다. 브라우저에서는 Web API가, Node.js에서는 런타임과 libuv가 타이머와 I/O를 관리합니다. 그리고 작업이 끝났을 때 그 결과를 다시 자바스크립트 코드로 가져오는 규칙이 바로 이벤트 루프입니다. 핵심은 "비동기를 마법처럼 동시에 실행한다"가 아니라, "지금 실행 가능한 일을 적절한 시점에 다시 콜 스택으로 올린다"는 데 있습니다.

콜 스택, 태스크 큐, 마이크로태스크 큐를 분리해서 보기

이벤트 루프를 이해할 때 가장 중요한 것은 각 구성 요소를 섞어서 생각하지 않는 것입니다.

• 콜 스택: 현재 실행 중인 함수가 쌓이는 공간입니다.
• 호스트 환경: 브라우저의 Web API, Node.js의 타이머/I/O 시스템처럼 자바스크립트 바깥에서 비동기 작업을 관리하는 부분입니다.
• 태스크 큐: 보통 setTimeout, setInterval 같은 콜백이 대기하는 곳입니다. 실무에서는 흔히 매크로태스크 큐라고 부릅니다.
• 마이크로태스크 큐: Promise.then, queueMicrotask, await 이후 코드처럼 더 높은 우선순위를 가진 작업이 대기하는 곳입니다.

실행 흐름을 단순화하면 다음처럼 기억하면 됩니다.

1. 현재 스크립트의 동기 코드를 끝까지 실행합니다.
2. 콜 스택이 비면 마이크로태스크 큐를 전부 비웁니다.
3. 브라우저는 필요하면 렌더링할 기회를 얻습니다.
4. 태스크 큐에서 작업 하나를 가져와 실행합니다.
5. 그 작업이 끝나면 다시 마이크로태스크 큐를 전부 비웁니다.

여기서 실수가 많이 나는 지점은 "마이크로태스크를 먼저 처리한다"보다 "마이크로태스크를 전부 처리한다"는 점입니다. 마이크로태스크 안에서 또 다른 마이크로태스크를 만들면, 그 역시 같은 턴에서 계속 이어집니다. 그래서 Promise 체인을 깊게 만들면 setTimeout이 늦어지고, 브라우저에서는 렌더링까지 밀릴 수 있습니다.

실제로 어떤 순서로 실행되는가

async/await까지 섞이면 더 복잡해 보이지만, 규칙은 같습니다. async 함수는 호출 즉시 시작되고 첫 번째 await를 만나기 전까지는 동기 코드처럼 실행됩니다. 그리고 await 뒤의 이어지는 부분이 마이크로태스크로 예약됩니다. 그래서 await를 썼다고 해서 함수 전체가 비동기로 밀리는 것은 아닙니다.

정리하면 이런 순서를 머리에 넣으면 좋습니다.

• 동기 코드는 항상 먼저 실행됩니다.
• 같은 턴에서 예약된 마이크로태스크는 태스크보다 먼저 처리됩니다.
• setTimeout(..., 0)은 "지금 바로"가 아니라 "다음 태스크에서"에 가깝습니다.
• 마이크로태스크 안에서 또 마이크로태스크를 만들 수 있으므로, 등록 순서와 생성 시점이 실행 순서에 영향을 줍니다.

이 규칙만 제대로 잡히면 Promise.then이 왜 setTimeout보다 먼저 실행되는지, await 뒤 코드가 왜 중간에 끼어드는지 설명이 됩니다.

실험 환경은 이렇게 준비하면 충분합니다

이론만 읽으면 감이 잘 안 잡히므로, 브라우저 콘솔과 Node.js에서 직접 순서를 확인해 보는 편이 훨씬 빠릅니다. Node.js 쪽은 아래처럼 최소 설정만 있어도 충분합니다.

{
  "name": "event-loop-lab",
  "private": true,
  "type": "module",
  "scripts": {
    "order": "node order.js",
    "compare": "node node-compare.js"
  }
}

type: "module"은 최신 문법을 그대로 쓰기 위한 정도로만 이해하면 됩니다. 이 설정을 만든 뒤, 예제 코드를 각각 order.js, node-compare.js에 저장하면 바로 실행할 수 있습니다.

실행은 아래 두 줄이면 끝입니다.

npm run order
npm run compare

브라우저에서는 별도 설정이 필요 없습니다. 크롬이나 엣지의 DevTools Console에 같은 코드를 붙여 넣으면 됩니다. 다만 process.nextTick은 Node.js 전용이므로 브라우저 콘솔에서는 동작하지 않습니다. 이 차이가 곧 런타임 차이입니다.

브라우저에서 실행 순서를 직접 확인해보기

먼저 브라우저와 Node.js에서 거의 비슷하게 볼 수 있는 예제입니다. 동기 코드, 마이크로태스크, 태스크가 한 번에 섞여 있습니다.

console.log('script start');

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

queueMicrotask(() => {
  console.log('queueMicrotask');
});

Promise.resolve().then(() => {
  console.log('promise then');
});

(async () => {
  console.log('async start');
  await null;
  console.log('async after await');
})();

console.log('script end');

이 코드를 실행하면 보통 다음 순서로 출력됩니다.

1. script start
2. async start
3. script end
4. queueMicrotask
5. promise then
6. async after await
7. setTimeout

앞의 세 줄은 모두 동기 코드입니다. async 함수도 첫 await 전까지는 즉시 실행되므로 async start가 먼저 찍힙니다. 그다음 마이크로태스크가 처리됩니다. 여기에는 queueMicrotask, Promise.then, await 이후 코드가 포함됩니다. 마지막으로 setTimeout 콜백이 다음 태스크에서 실행됩니다.

중요한 포인트는 마이크로태스크끼리도 등록 순서를 따른다는 점입니다. 위 예제에서는 queueMicrotask가 먼저 예약됐고, 그다음 Promise.then, 마지막으로 await 이후 코드가 예약됐기 때문에 그 순서대로 실행됩니다. "마이크로태스크가 더 빠르다"는 설명만 외우면 놓치기 쉬운 부분입니다.

Node.js에서는 무엇이 다를까

Node.js도 큰 틀에서는 비슷하지만, 브라우저와 완전히 같다고 보면 곤란합니다. 특히 process.nextTick은 Node.js 전용이며, 일반적인 Promise 마이크로태스크보다도 먼저 처리됩니다. 아래 예제로 바로 확인할 수 있습니다.

let order = 0;
const log = (label) => console.log(`${++order}. ${label}`);

log('script start');

setTimeout(() => log('setTimeout'), 0);
Promise.resolve().then(() => log('promise then'));
process.nextTick(() => log('nextTick'));

log('script end');

Node.js에서 실행하면 보통 아래와 비슷한 순서가 나옵니다.

1. script start
2. script end
3. nextTick
4. promise then
5. setTimeout

즉, Node.js에서는 단순히 "마이크로태스크가 먼저"가 아니라 process.nextTick이 별도로 더 앞에 끼어든다고 이해하는 편이 정확합니다. 서버 코드에서 라이브러리 내부가 nextTick을 사용하고 있다면, 브라우저 기준 직관으로 실행 순서를 예측하면 틀릴 수 있습니다.

이 차이 때문에 브라우저와 Node.js를 같은 그림 하나로만 설명하는 글은 초심자에게 오히려 혼란을 줄 때가 많습니다. 공통 규칙은 유지하되, 런타임별 예외를 같이 기억해야 실무에서 덜 흔들립니다.

실무에서 자주 틀리는 포인트

가장 흔한 오해는 setTimeout(fn, 0)을 "즉시 실행"으로 받아들이는 것입니다. 정확히는 "최소한 현재 실행 중인 코드가 끝난 다음"입니다. 콜 스택이 길거나 그 사이에 마이크로태스크가 많이 쌓이면, 0ms라고 적어도 실제 실행 시점은 충분히 늦어질 수 있습니다.

두 번째는 await가 무거운 계산을 비동기로 바꿔준다고 오해하는 경우입니다. await는 Promise의 완료를 기다리도록 실행 흐름을 나눌 뿐이지, CPU를 많이 쓰는 동기 작업 자체를 다른 스레드로 보내지 않습니다. await 앞이나 뒤에 큰 반복문이 있으면 메인 스레드는 그대로 막힙니다.

세 번째는 렌더링과 마이크로태스크의 관계를 과소평가하는 것입니다. 브라우저는 보통 하나의 태스크와 그 뒤에 이어지는 마이크로태스크 처리가 끝난 뒤에야 화면을 그릴 기회를 얻습니다. 그래서 상태를 바꿔 놓고 곧바로 긴 Promise 체인을 이어 붙이면, DOM은 바뀌었는데 화면이 늦게 갱신되는 것처럼 보일 수 있습니다.

이럴 때는 작업을 더 잘게 쪼개서 다음 태스크로 넘겨야 합니다. 아래처럼 청크 단위로 끊고 중간에 setTimeout 기반 대기를 넣으면 브라우저가 숨 쉴 시간을 벌 수 있습니다.

async function processLargeList(items) {
  for (let i = 0; i < items.length; i += 500) {
    const chunk = items.slice(i, i + 500);

    for (const item of chunk) {
      expensiveJob(item);
    }

    await new Promise((resolve) => setTimeout(resolve, 0));
  }
}

이 코드는 처리량만 보면 가장 빠른 방식은 아닐 수 있지만, 긴 작업 때문에 UI가 완전히 멈추는 문제를 줄이는 데는 효과적입니다. 여기서 중요한 점은 await Promise.resolve()가 아니라 await new Promise(resolve => setTimeout(resolve, 0))를 썼다는 것입니다. 전자는 다시 마이크로태스크로 이어질 뿐이라 렌더링 기회를 주지 못할 수 있고, 후자는 다음 태스크로 넘기면서 화면 갱신 여지를 만듭니다.

실행 순서 버그를 잡는 가장 현실적인 방법

이벤트 루프 관련 버그는 감으로 보면 거의 틀립니다. 가장 좋은 방법은 "어느 API를 썼는가"가 아니라 "어느 큐에 들어갔는가"를 기준으로 로그를 찍는 것입니다.

실제로는 아래 기준만 지켜도 디버깅 속도가 빨라집니다.

• 현재 턴의 시작과 끝에 동기 로그를 찍습니다.
• Promise.then, queueMicrotask, await 뒤 코드에는 서로 다른 라벨을 붙입니다.
• setTimeout(..., 0)에는 "즉시"라는 이름 대신 "next task"처럼 의도가 드러나는 라벨을 씁니다.
• 브라우저에서는 렌더링이 의심되면 requestAnimationFrame 로그를 함께 찍어 화면 반영 시점을 비교합니다.
• Node.js에서는 process.nextTick 사용 여부를 먼저 확인합니다.

이벤트 루프는 개념 자체가 어려워서 헷갈리는 경우보다, 서로 다른 큐를 한 덩어리로 생각해서 헷갈리는 경우가 더 많습니다. 콜 스택, 마이크로태스크, 태스크를 분리해서 보는 습관만 들이면 setTimeout, Promise, async/await의 실행 순서는 훨씬 덜 복잡하게 느껴집니다.

원문 참고

https://www.maeil-mail.kr/question/15