Event Loop 톺아보기

🥑 들어가며

최근 NestJS, FastAPI, WebFlux에 관심이 생기면서 자연스럽게 Event Loop에 대해 관심이 생기게 되었다.

세 프레임워크는 언어도, 생태계도 다르지만 공통적으로 비동기 논블로킹(Async Non-blocking) 이라는 키워드를 강조한다. 그 중심에는 항상 Event Loop가 있다. 이 글에서는 Event Loop가 무엇인지, 각 프레임워크에서 어떻게 구현되는지를 함께 살펴보려 한다.

1. 왜 Event Loop인가? — 스레드 기반 서버의 한계

전통적인 웹 서버는 요청 하나에 스레드 하나를 할당하는 방식으로 동작한다. Spring MVC나 Django(기본 설정)가 대표적이다.

요청 1 ──→ Thread 1 (DB 쿼리 대기 중... 🥱)
요청 2 ──→ Thread 2 (파일 읽기 대기 중... 🥱)
요청 3 ──→ Thread 3 (외부 API 대기 중... 🥱)
요청 4 ──→ 대기열... (스레드 풀 고갈)

이 방식의 문제는 명확하다.

• 스레드는 비싸다. 스레드 하나는 기본적으로 수 MB의 스택 메모리를 차지한다.
• I/O 작업 동안 스레드가 낭비된다. DB 응답을 기다리는 동안 스레드는 아무 일도 하지 않고 블로킹된다.
• 동시 접속자가 늘어날수록 스레드 풀이 고갈되고, 결국 요청이 큐에 쌓이거나 거절된다.

이 문제를 해결하기 위해 등장한 것이 논블로킹 I/O + Event Loop 모델이다.

핵심 아이디어: “I/O가 끝날 때까지 기다리지 말고, 끝나면 나에게 알려줘.”

2. Event Loop의 원리

식당 비유로 이해하기

블로킹 방식은 홀 직원이 손님 한 명의 음식이 나올 때까지 주방 앞에서 기다리는 식당과 같다. 손님이 10명이면 직원도 10명이 필요하다.

Event Loop 방식은 한 명의 직원이 주문을 받고, 주방에 전달한 뒤, 다른 손님을 응대하다가, 음식이 나오면 가져다주는 방식이다. 직원 한 명이 훨씬 많은 손님을 처리할 수 있다.

브라우저/런타임의 구성 요소

Event Loop는 혼자 동작하지 않는다. 브라우저(또는 Node.js) 안에서 여러 구성 요소가 협력한다.

┌─────────────────────────────────────────────────────┐
│                   브라우저 / Node.js                  │
│                                                     │
│  ┌──────────────┐   ┌──────────────────────────┐   │
│  │  Call Stack  │   │   Web APIs / Node APIs   │   │
│  │  (JS 엔진)   │   │  (Timer, fetch, I/O...)  │   │
│  └──────┬───────┘   └────────────┬─────────────┘   │
│         │                        │ 완료 시 콜백 전달  │
│  ┌──────▼───────────────────────▼─────────────┐    │
│  │              Callback Queue                 │    │
│  │  ┌─────────────────┐  ┌─────────────────┐  │    │
│  │  │ Microtask Queue │  │   Task Queue    │  │    │
│  │  │ (Promise, await)│  │(setTimeout, I/O)│  │    │
│  │  └─────────────────┘  └─────────────────┘  │    │
│  └─────────────────────────────────────────────┘    │
│                        ↑                            │
│               ┌────────┴────────┐                   │
│               │   Event Loop    │  ← 감시 & 이동     │
│               └─────────────────┘                   │
└─────────────────────────────────────────────────────┘

각 구성 요소가 하는 일은 이렇다.

• Call Stack: JS 엔진이 코드를 실행하는 공간. 함수 호출이 쌓이고 반환되며 비워진다.
• Heap: 동적으로 생성된 객체가 저장되는 메모리 공간.
• Web APIs / Node APIs: 브라우저(또는 Node.js)가 제공하는 비동기 작업 처리 공간. Timer, fetch, 파일 I/O 등이 여기서 멀티 스레드로 처리된다.
• Event Table: 특정 이벤트(click, timeout 등)가 발생했을 때 어떤 콜백을 호출할지 기록하는 자료구조.
• Task Queue (Macrotask Queue): setTimeout, setInterval, I/O 콜백이 대기하는 곳.
• Microtask Queue: Promise.then, async/await 콜백이 대기하는 곳. Task Queue보다 우선순위가 높다.
• Event Loop: Call Stack이 비어있으면 Queue의 콜백을 꺼내 Call Stack에 올려주는 관리자.

비동기로 동작하는 핵심은 자바스크립트 언어 자체가 아니라, 브라우저 또는 런타임 소프트웨어가 가지고 있다. Node.js에서는 libuv 라이브러리가 이 역할을 담당한다.

Event Loop 동작 순서 (1 틱)

1. Call Stack이 비어있는지 확인한다.
2. Microtask Queue에 작업이 있으면 전부 처리한다. (Promise 콜백 등)
3. AnimationFrame Queue가 있으면 처리한다. (브라우저 환경 한정)
4. Task Queue에서 작업을 하나 꺼내 Call Stack에 올린다.
5. 다시 1번으로 돌아간다.

이벤트 루프는 콜 스택과 콜백 큐를 지속적으로 확인하며, 콜 스택이 비어있으면 콜백 큐에서 가장 오래된 작업(FIFO)을 꺼내서 콜 스택으로 옮긴다.

console.log('Start!'); // Call Stack에서 즉시 실행

setTimeout(() => console.log('Timeout!'), 0); // Task Queue로 이동

Promise.resolve('Promise!').then(res => console.log(res)); // Microtask Queue로 이동

console.log('End!'); // Call Stack에서 즉시 실행

// 출력 순서: 1 → 4 → 3 → 2

console.log('Start!')가 Call Stack에 올라가 즉시 실행되고 “Start!”가 출력된다.

setTimeout이 실행되면 콜백 함수가 Web API로 전달되고 타이머가 시작된다. 딜레이가 0초이므로 타이머는 곧바로 종료된다.

타이머가 끝난 콜백은 Task Queue(MacroTask Queue)에 들어가 대기한다.

Promise.resolve(...).then(...)이 실행되면 .then() 핸들러의 콜백이 Microtask Queue에 들어간다.

console.log('End!')가 실행되고 “End!”가 출력된다.

동기 코드가 모두 실행되면 Call Stack이 비워진다. Event Loop는 이 순간을 감지하고 Microtask Queue를 먼저 확인한다.

Microtask Queue에 대기 중인 Promise 콜백이 꺼내져 실행된다. Microtask Queue는 비워질 때까지 한 번에 전부 처리된다.

Microtask Queue가 모두 비워지면 Task Queue에서 setTimeout 콜백을 꺼내 실행한다.

Microtask(Promise)가 Task(setTimeout)보다 항상 먼저 처리된다는 점이 핵심이다.

3. async/await의 진짜 동작 원리

많은 사람들이 async/await를 “비동기를 동기처럼 쓰는 문법”으로만 이해한다. 하지만 내부적으로 어떻게 동작하는지를 모르면, 실행 순서를 예측하기 어려운 상황을 만나게 된다.

async 함수는 항상 Promise를 반환한다

async 키워드를 붙이면, 반환값이 무엇이든 자동으로 Promise로 감싸져 반환된다.

async function greet() {
  return 'Hello';
}

// 위 코드는 아래와 동일하다
function greet() {
  return Promise.resolve('Hello');
}

greet().then(val => console.log(val)); // "Hello"

이 점이 중요한 이유는, await가 Promise를 기다리는 문법이기 때문이다. async 함수끼리 서로를 await할 수 있는 것도 이 덕분이다.

async/await는 Promise.then의 syntactic sugar다

await는 Promise가 resolve될 때까지 함수 실행을 일시 중단하는 문법이다. 이때 “중단”이란 스레드를 점령하며 블로킹하는 것이 아니라, 나머지 코드를 Microtask Queue에 예약하고 함수를 빠져나가는 것이다.

아래 두 코드는 완전히 동일하게 동작한다.

// async/await 버전
async function myFunc() {
  const res = await one();
  console.log(res);
  console.log('Done');
}

// 위 코드는 사실 아래와 같다
function myFunc() {
  return one().then(res => {
    console.log(res);
    console.log('Done');
  });
}

즉, await 이후의 코드들은 모두 .then() 핸들러의 콜백으로 변환되어 Microtask Queue에 들어간다.

실행 순서를 단계별로 따라가기

코드를 한 줄씩 실행하면서 Call Stack과 Microtask Queue가 어떻게 변하는지 직접 따라가 보자.

const one = () => Promise.resolve('One!');

async function myFunc() {
  console.log('In function!');   // A
  const res = await one();       // B: 여기서 함수 실행 일시 중단
  console.log(res);              // C: Microtask Queue에 예약됨
}

console.log('Before Function!'); // ①
myFunc();                        // ②
console.log('After Function!'); // ③

// 출력: Before Function! → In function! → After Function! → One!

Step 1. console.log('Before Function!') 실행

Call Stack              Microtask Queue
────────────────────    ───────────────
console.log(...)        (비어 있음)
────────────────────
출력: "Before Function!"

Step 2. myFunc() 호출 — await를 만나기 전까지 동기 실행

myFunc은 일반 함수처럼 즉시 실행된다. await를 만나기 전의 코드(A 부분)는 Call Stack에서 바로 실행된다.

Call Stack              Microtask Queue
────────────────────    ───────────────
console.log('In...')    (비어 있음)
myFunc()
────────────────────
출력: "In function!"

Step 3. await one()을 만나는 순간 — 함수가 빠져나간다

one()이 호출되어 Promise를 반환한다. await는 이 Promise가 resolve될 때까지 C 이후 코드를 Microtask Queue에 예약하고, myFunc을 Call Stack에서 꺼낸다. 스레드를 점령하는 게 아니라 “나중에 다시 와서 실행해줘”라고 예약하고 자리를 비우는 것이다.

Call Stack              Microtask Queue
────────────────────    ────────────────────────
(myFunc 빠져나감)       [console.log(res)] ← 예약
────────────────────

Step 4. console.log('After Function!') 실행

myFunc이 빠져나갔으므로 다음 줄인 console.log('After Function!')가 실행된다.

Call Stack              Microtask Queue
────────────────────    ────────────────────────
console.log(...)        [console.log(res)]
────────────────────
출력: "After Function!"

Step 5. Call Stack이 비자, Microtask Queue에서 꺼내 실행

Event Loop가 Call Stack이 비어있음을 감지하고, Microtask Queue에 예약된 콜백을 꺼내 실행한다.

Call Stack              Microtask Queue
────────────────────    ───────────────
console.log(res)        (비어 있음)
────────────────────
출력: "One!"

After Function!이 One!보다 먼저 출력되는 이유가 바로 이것이다. await는 함수를 “잠시 떠났다가 Promise가 끝나면 돌아오는” 구조로 만든다.

await가 여러 개라면?

await를 만날 때마다 그 이후 코드가 Microtask Queue에 들어가는 과정이 반복된다.

async function myFunc() {
  console.log('Step 1');
  const a = await stepA();   // ← 첫 번째 중단, Step 2 이후 예약
  console.log('Step 2');
  const b = await stepB(a);  // ← 두 번째 중단, Step 3 이후 예약
  console.log('Step 3');
}

겉으로는 순서대로 실행되는 것처럼 보이지만, 내부적으로는 Microtask Queue를 두 번 거친다. 결과적으로 Step 1 → Step 2 → Step 3 순서는 보장된다.

주의: 호출부에도 await를 붙이면?

console.log('Before Function!');
await myFunc();                   // 호출부에도 await
console.log('After Function!');

이 경우 myFunc()가 완전히 끝날 때까지 그 아래 코드도 함께 기다린다.

// 출력 순서:
// Before Function!
// In function!
// One!
// After Function!

await myFunc() 이후의 코드도 .then() 콜백으로 변환되기 때문이다.

흔한 실수: await를 빠뜨리면?

async function myFunc() {
  const res = fetchData(); // await 없음!
  console.log(res);        // Promise { <pending> } 출력됨
}

await를 빠뜨리면 fetchData()가 반환하는 Promise 객체 자체가 res에 담긴다. 특히 forEach 안에서 이 실수가 자주 발생한다.

// ❌ forEach는 async 콜백을 기다리지 않는다
rows.forEach(async (row) => {
  await db.insert(row); // 기다리는 것처럼 보이지만, forEach는 신경 쓰지 않는다
});
console.log('Done'); // insert가 끝나기 전에 출력됨

// ✅ for...of를 사용해야 순서가 보장된다
for (const row of rows) {
  await db.insert(row);
}
console.log('Done'); // 모든 insert 완료 후 출력됨

forEach는 콜백의 반환값(Promise)을 그냥 무시한다. 순서를 보장하고 싶다면 for...of를 쓰자.

4. Microtask Queue의 함정 — 무한루프

Task Queue와 Microtask Queue의 차이는 단순한 우선순위 차이처럼 보이지만, 실제로는 브라우저 동작 전체에 영향을 미칠 수 있다.

Microtask Queue는 브라우저가 화면을 렌더링하기 전에 처리된다. 따라서 Microtask Queue가 끊임없이 채워지면, 브라우저는 렌더링도 못 하고 사용자 입력에도 반응하지 못한 채 먹통이 된다.

// ✅ setTimeout 재귀 무한루프 → Task Queue에 쌓임
// 브라우저가 각 루프 사이에 렌더링, 이벤트 처리 가능
function loop() {
  setTimeout(() => {
    console.log('Loop');
    loop();
  }, 0);
}
loop();

// ❌ Promise 재귀 무한루프 → Microtask Queue에 쌓임
// Microtask Queue가 절대 비워지지 않아 브라우저 전체 먹통
function loop() {
  Promise.resolve().then(() => {
    console.log('Loop');
    loop();
  });
}
loop(); // 이 순간부터 브라우저가 응답을 멈춘다

백엔드 관점에서도 마찬가지다. Node.js 서버에서 Promise 체인이 무한히 이어지거나 Microtask Queue를 과도하게 채우는 로직이 있다면, 다른 요청들이 줄줄이 밀리게 된다.

5. 프레임워크별 Event Loop 비교

세 프레임워크는 각자의 언어와 런타임 위에서 Event Loop를 다르게 구현하고 있다.

Node.js (NestJS의 기반)

Node.js는 libuv라는 C 라이브러리를 통해 Event Loop를 구현한다. 싱글 스레드지만 libuv의 스레드 풀을 이용해 파일 I/O 등의 블로킹 작업을 처리한다.

Node.js Event Loop 6단계 (Phase)
   ┌───────────────────────────┐
   │           timers          │
   └─────────────┬─────────────┘
                 │
                 v
   ┌───────────────────────────┐
┌─>│     pending callbacks     │
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │       idle, prepare       │
│  └─────────────┬─────────────┘      ┌───────────────┐
│  ┌─────────────┴─────────────┐      │   incoming:   │
│  │           poll            │<─────┤  connections, │
│  └─────────────┬─────────────┘      │   data, etc.  │
│  ┌─────────────┴─────────────┐      └───────────────┘
│  │           check           │
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │      close callbacks      │
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
└──┤           timers          │
   └───────────────────────────┘

NestJS는 이 위에서 동작하며, async/await와 Promise를 자연스럽게 지원한다.

// NestJS Controller 예시
@Get('/users/:id')
async getUser(@Param('id') id: string) {
  // await 동안 Event Loop는 다른 요청을 처리한다
  const user = await this.userService.findById(id);
  return user;
}

특징

• 싱글 스레드, 싱글 Event Loop
• CPU 집약적 작업에 취약 (Worker Threads로 보완)
• I/O 집약적 서비스에 매우 적합

Python asyncio (FastAPI의 기반)

Python은 3.4부터 asyncio 표준 라이브러리를 통해 Event Loop를 제공한다. FastAPI는 이를 기반으로 하며, uvicorn(ASGI 서버)이 Event Loop를 실행한다.

# FastAPI 예시
@app.get("/users/{user_id}")
async def get_user(user_id: int):
    # await 동안 Event Loop는 다른 요청을 처리한다
    user = await db.fetch_one(
        query="SELECT * FROM users WHERE id = :id",
        values={"id": user_id}
    )
    return user

Python asyncio의 구조는 Node.js와 개념적으로 유사하지만, 중요한 차이가 있다.

항목	Node.js	Python asyncio
Event Loop 실행	자동 (런타임에 내장)	명시적 실행 (asyncio.run())
코루틴	async function	async def
양보 시점	await	await
스레드 풀	libuv 내장	ThreadPoolExecutor 연동

⚠️ FastAPI에서 자주 하는 실수

# ❌ 잘못된 예: async def 안에서 동기 블로킹 호출
@app.get("/bad")
async def bad_endpoint():
    time.sleep(5)  # Event Loop 전체가 5초 동안 멈춘다!
    return {"result": "done"}

# ✅ 올바른 예: 동기 함수는 def로, FastAPI가 스레드풀로 처리한다
@app.get("/good")
def good_endpoint():
    time.sleep(5)  # FastAPI가 별도 스레드에서 실행
    return {"result": "done"}

Project Reactor / Netty (WebFlux의 기반)

WebFlux는 JVM 위에서 동작하며, Project Reactor의 Flux/Mono와 Netty의 Event Loop를 기반으로 한다.

Netty의 구조 — Boss Group과 Worker Group

Node.js와 달리 멀티 스레드 기반의 Event Loop를 사용한다. Netty는 역할에 따라 두 종류의 EventLoopGroup을 분리해서 운영한다.

• Boss Group: 클라이언트의 TCP 연결 요청(accept)만 전담. 보통 1개 스레드
• Worker Group: 실제 I/O 읽기/쓰기를 담당. CPU 코어 수 × 2개 스레드로 구성

클라이언트 연결 요청
       │
       ▼
┌──────────────────────┐
│      Boss Group      │  ← 연결 수락만 담당
│   EventLoop Thread   │
└──────────┬───────────┘
           │ Channel 등록 (연결을 Worker에게 넘김)
           ▼
┌──────────────────────────────────────────────────┐
│                   Worker Group                   │
│  ┌─────────────┐  ┌─────────────┐  ┌──────────┐  │
│  │ EventLoop-1 │  │ EventLoop-2 │  │   ...    │  │
│  │  Channel A  │  │  Channel B  │  │          │  │
│  │  Channel C  │  │  Channel D  │  │          │  │
│  └─────────────┘  └─────────────┘  └──────────┘  │
└──────────────────────────────────────────────────┘

Channel은 하나의 클라이언트 연결을 나타내며, 한 Channel은 항상 같은 EventLoop 스레드에 고정된다. 즉, 한 요청의 생명주기 동안 담당 스레드가 바뀌지 않는다. 이 덕분에 스레드 간 동기화 없이도 스레드 안전성이 보장된다.

요청 처리 흐름 — Channel Pipeline

연결이 Worker EventLoop에 배정되고 나면, 요청은 Channel Pipeline을 따라 Handler를 하나씩 통과한다.

클라이언트 요청
      │
      ▼
Worker EventLoop (Channel 고정)
      │
      ▼
┌─────────────────────────┐
│     Channel Pipeline    │
│  ┌───────────────────┐  │
│  │  Decoder          │  │  HTTP 바이트 → 객체 변환
│  ├───────────────────┤  │
│  │  Business Handler │  │  컨트롤러 로직 실행
│  ├───────────────────┤  │
│  │  Encoder          │  │  객체 → HTTP 바이트 변환
│  └───────────────────┘  │
└─────────────────────────┘
      │
      ▼
클라이언트 응답

각 Handler는 비동기로 동작하고, 앞 Handler가 끝나면 다음으로 넘어간다.

WebFlux + Reactor의 스케줄러

Reactor는 어떤 스레드에서 코드를 실행할지 제어하는 스케줄러(Scheduler) 를 제공한다.

스케줄러	용도	특징
Schedulers.parallel()	CPU 연산	코어 수만큼의 고정 스레드 풀
Schedulers.boundedElastic()	블로킹 I/O	필요 시 스레드 생성, 최대 개수 제한 있음
Schedulers.single()	단일 재사용 스레드	순서 보장이 필요한 작업

Netty EventLoop 스레드에서 블로킹 코드를 실행하면, 해당 스레드에 묶인 모든 Channel(연결)이 함께 멈춘다. 블로킹 작업은 반드시 boundedElastic()으로 분리해야 한다.

// ❌ EventLoop 스레드에서 블로킹 호출 — 같은 스레드의 모든 연결이 멈춘다
@GetMapping("/bad")
public Mono<String> bad() {
    String result = blockingHttpCall(); // 동기 HTTP 호출
    return Mono.just(result);
}

// ✅ subscribeOn으로 블로킹 작업을 별도 스레드로 분리
@GetMapping("/good")
public Mono<String> good() {
    return Mono.fromCallable(() -> blockingHttpCall())
               .subscribeOn(Schedulers.boundedElastic());
}

publishOn vs subscribeOn

Reactor에서 실행 스레드를 바꾸는 방법은 두 가지다.

Flux.just(1, 2, 3)
    .subscribeOn(Schedulers.boundedElastic()) // 구독 시점부터 이 스레드 사용 (소스부터 적용)
    .map(i -> i * 2)                         // boundedElastic 스레드에서 실행
    .publishOn(Schedulers.parallel())         // 이 지점 이후로 스레드 전환
    .map(i -> i + 1);                        // parallel 스레드에서 실행

• subscribeOn: 소스 데이터를 발행하는 스레드를 지정. 체인 어디에 놓든 소스부터 적용된다.
• publishOn: 이 연산자 이후의 코드가 실행될 스레드를 지정. 위치가 중요하다.

// WebFlux Controller 예시
@GetMapping("/users/{id}")
public Mono<User> getUser(@PathVariable String id) {
    return userRepository.findById(id)  // Mono: 0 or 1개의 비동기 데이터
        .map(user -> {
            // 데이터 변환 (논블로킹)
            return user;
        });
}

특징

• Mono<T>: 0~1개의 결과를 담는 비동기 컨테이너
• Flux<T>: 0~N개의 결과를 담는 비동기 스트림
• 리액티브 프로그래밍 패러다임 — 학습 곡선이 가파르다
• 기존 Spring MVC 코드와 혼용이 어렵다 (블로킹 라이브러리 사용 불가)
• Netty EventLoop 스레드에서 블로킹 코드를 실행하면 안 된다 — WebFlux의 가장 중요한 제약

6. 세 프레임워크 한눈에 비교

항목	NestJS	FastAPI	WebFlux
언어	TypeScript/JS	Python	Java/Kotlin
Event Loop 구현	libuv (Node.js)	asyncio (Python)	Netty + Reactor
스레드 모델	싱글 스레드	싱글 스레드	멀티 스레드
비동기 문법	async/await	async/await	Mono/Flux
학습 곡선	낮음	낮음	높음
CPU 집약 작업	Worker Threads	ProcessPoolExecutor	스레드 풀
주요 사용처	REST API, MSA	ML 서빙, 데이터 API	엔터프라이즈, 스트리밍

7. Event Loop를 망가뜨리는 코드

Event Loop는 싱글 스레드다. 즉, 오래 걸리는 동기 작업이 들어오면 그동안 다른 모든 요청이 멈춘다.

CPU 집약적 작업

// Node.js ❌ — 이 함수가 실행되는 동안 서버 전체가 멈춘다
app.get('/fibonacci', (req, res) => {
  const result = fibonacci(45); // 수초 걸리는 재귀 연산
  res.json({ result });
});

// ✅ Worker Thread로 분리
const { Worker } = require('worker_threads');
app.get('/fibonacci', (req, res) => {
  const worker = new Worker('./fibonacci-worker.js', { workerData: 45 });
  worker.on('message', (result) => res.json({ result }));
});

async를 붙인다고 비동기가 되지 않는다

# Python ❌ — async def이지만 내부가 블로킹
import requests  # 동기 라이브러리!

async def get_data():
    response = requests.get("https://api.example.com")  # Event Loop 블로킹!
    return response.json()

# ✅ 비동기 라이브러리 사용
import httpx

async def get_data():
    async with httpx.AsyncClient() as client:
        response = await client.get("https://api.example.com")
        return response.json()

규칙: 비동기로 바꿀 수 없는 블로킹 코드는 별도 스레드나 프로세스 풀에서 실행해야 한다.

8. 실전 케이스 — 엑셀 대용량 Batch Insert

Event Loop의 원리를 이해했다면, 실무에서 자주 만나는 케이스를 분석해보자. “엑셀 파일을 읽어 DB에 10만 건을 Insert하는 API”는 Event Loop 관점에서 꽤 복잡한 작업이다.

작업의 구조

엑셀 업로드 수신 (I/O)
  → 엑셀 파싱 (CPU)        ← ⚠️ 블로킹 위험 구간
  → 데이터 검증/가공 (CPU)  ← ⚠️ 블로킹 위험 구간
  → DB INSERT × 10만 건 (I/O) ← 방식에 따라 천차만별
  → 응답 반환

파싱(CPU)과 DB Insert(I/O)가 섞인 작업이라, Event Loop 입장에서 신경 써야 할 구간이 두 곳이다.

1구간: 엑셀 파싱 — Event Loop를 블로킹한다

// Node.js ❌ — xlsx 파싱은 동기(CPU) 작업
const workbook = XLSX.read(buffer); // Call Stack을 수초간 점령
const rows = workbook.Sheets['Sheet1'];
// 이 동안 다른 모든 요청이 멈춘다

해결책은 Worker Thread로 파싱 작업을 분리하는 것이다.

// ✅ Worker Thread로 분리
const worker = new Worker('./excel-parser.js', { workerData: buffer });
worker.on('message', (rows) => {
  // 파싱 완료 후 콜백으로 돌아옴. Event Loop는 그동안 자유롭다.
  handleRows(rows);
});

Python(FastAPI)에서도 동일한 문제가 있다.

# ❌ pandas 파싱은 동기(CPU) 작업 → Event Loop 블로킹
@app.post("/upload")
async def upload(file: UploadFile):
    content = await file.read()
    df = pd.read_excel(io.BytesIO(content))  # 블로킹!

# ✅ run_in_executor로 별도 스레드에서 처리
@app.post("/upload")
async def upload(file: UploadFile):
    content = await file.read()
    loop = asyncio.get_event_loop()
    df = await loop.run_in_executor(None, pd.read_excel, io.BytesIO(content))

2구간: DB Insert — 방식에 따라 성능이 극단적으로 갈린다

같은 10만 건 Insert라도 어떻게 처리하느냐에 따라 Event Loop 동작이 완전히 달라진다.

❌ 최악: 건별 await (직렬)

for (const row of rows) {
  await db.insert(row); // 10만 번 순서대로 DB 왕복 대기
}

Timeline:
[await insert 1]──[await insert 2]──[await insert 3]── ... × 100,000
각 await마다 Event Loop가 다른 요청을 처리할 수 있지만,
이 API 요청 자체는 수분이 걸린다.

await가 있어서 Event Loop를 블로킹하진 않지만, DB 왕복 지연이 10만 번 쌓인다.

⚠️ 주의: Promise.all (무제한 병렬)

await Promise.all(rows.map(row => db.insert(row)));
// 10만 개의 Promise를 동시에 생성 → DB 커넥션 풀 즉시 고갈
// 오히려 더 느려지거나 에러 발생

✅ 실무 정석: Chunk 단위 Bulk Insert

const CHUNK_SIZE = 1000;

for (let i = 0; i < rows.length; i += CHUNK_SIZE) {
  const chunk = rows.slice(i, i + CHUNK_SIZE);
  await db.bulkInsert(chunk); // 1000건을 단 한 번의 DB 쿼리로
}

Timeline:
[bulk 1~1000]──[bulk 1001~2000]── ... × 100회
DB 왕복이 10만 번 → 100번으로 줄어든다

내부적으로 이런 쿼리 한 번으로 처리된다.

INSERT INTO users (name, email) VALUES
  ('Alice', 'a@a.com'),
  ('Bob',   'b@b.com'),
  ... (1000건)

진짜 대용량이라면: Event Loop 밖으로 꺼내라

수십만, 수백만 건 수준이 되면 API 서버의 Event Loop 안에서 처리하는 것 자체가 잘못된 설계다. Message Queue를 사용해 처리를 완전히 분리한다.

Client
  │
  ▼
API 서버 ──→ Message Queue (Redis, RabbitMQ) ──→ Worker 프로세스
  │          (파일 ID만 전달)                      (실제 처리 담당)
  │
  └──→ 202 Accepted + jobId 즉시 반환

// NestJS: API는 큐에 작업을 넣고 즉시 반환
@Post('/upload')
async uploadExcel(@UploadedFile() file) {
  const fileId = await this.storage.save(file);
  await this.queue.add('batch-insert', { fileId });
  return { status: 'accepted', jobId: fileId }; // 즉시 반환
}

// 별도 Worker: Event Loop 걱정 없이 처리
@Process('batch-insert')
async handleBatchInsert(job: Job) {
  const rows = await parseExcel(job.data.fileId);
  for (let i = 0; i < rows.length; i += 1000) {
    await db.bulkInsert(rows.slice(i, i + 1000));
  }
}

이렇게 하면 API 서버의 Event Loop는 항상 가볍고, 무거운 작업은 Worker가 전담한다.

정리

구간	Event Loop 영향	해결책
엑셀 파싱 (CPU)	⛔ 블로킹	Worker Thread / run_in_executor
건별 INSERT (직렬)	🐢 느리지만 비블로킹	Chunk Bulk INSERT로 교체
무제한 Promise.all	⛔ 커넥션 풀 고갈	Chunk 단위 처리
수백만 건 대용량	⛔ 설계 문제	Message Queue + Worker 분리

9. 어떤 상황에 어떤 프레임워크?

I/O 집약적 + 빠른 개발 + JS 생태계       →  NestJS
I/O 집약적 + ML/데이터 + Python 생태계  →  FastAPI
엔터프라이즈 + 스트리밍 + Java 생태계    →  WebFlux

🌿 마치며

Event Loop는 처음에는 추상적인 개념처럼 느껴지지만, 결국 “기다리지 말고, 끝나면 알려줘” 라는 단순한 아이디어의 구현이다.

NestJS, FastAPI, WebFlux는 각자의 방식으로 이 아이디어를 실현하고 있다. 어떤 프레임워크를 선택하든, Event Loop가 언제 블로킹되는지를 이해하고 있다면 성능 문제의 절반은 이미 해결한 셈이다.

그리고 무거운 작업 앞에서는 “어떻게 비동기로 잘 처리할까”보다 “이걸 Event Loop 밖으로 꺼낼 수 있을까” 를 먼저 떠올리는 것이 성숙한 설계의 시작이다.